From nobody Tue May 1 08:54:29 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7159412DA4B for ; Tue, 1 May 2018 08:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 knl02cELHU2N for ; Tue, 1 May 2018 08:54:25 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 1709512DA70 for ; Tue, 1 May 2018 08:54:25 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id z75so9153275qkb.6 for ; Tue, 01 May 2018 08:54:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=ffjfMUlH0BiysY0skgQiaqirNV9ZeBk1Kg4pji8hpiY=; b=gJEKsCHmL3SiAKHYUTCqEhv8RCLq+vb4Tv05o26PAYUi/RIGIZikiX1qIRgAiNjfyM ec44BWm2dl0X4zstLJiI1TwcylMpeO1mUwUulrhyXEP92TCTuhdtsNpw9kGWZm66rGTS RSzasYbCb+tgezTTHrPRCzDT+9z52bMdB35NQZadLlp0PkMUSybJEpjuRkPOur5EgTa2 +vSQFTIJTxL/YEJH5Vhet4B9JTwdTYwkue+ygo0udOJEifdy27IaTMMc2NdSk7OnpGIO DGLKM14LibVU63RklnCC+GWtNFbkp1CZLIqKgqYdHpVhWidY55cdkOrh3ECAXjZonWJN Ehrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=ffjfMUlH0BiysY0skgQiaqirNV9ZeBk1Kg4pji8hpiY=; b=OLRmp++9rW7vifcsLL3twF9Eopx0o0ipO8LD2A9ZggUN0HfNQaAb0htofNlvXKdsqT kgemT/kXBE+/NiGBzBc99jcrDpdo56F86s1SZUn0rstCtjdgIaTNDMQedscy6PRa0I7g ZWivAnLfRZwtcpZ+REXTrXazwZG9eJqUghvahF61enJHG5gZfunATqgR1fJh2WlTLvbc hyDKBFHJPKMC6whz0ZdzPjfDJIzVUkKd3UGkSLD3x8USlDJoaJej6FbdSzn4d32brW6a h1OkVc8CrxZ7zPK4Tqxk9BjSu9qI1OxdJhyi0GsXRzxRG/oKb95ZAjMyRaPzSvCsFI8N 7zDw== X-Gm-Message-State: ALQs6tC26FrxGmumSlfEV3nJF07+Ab0vNw1fFsSi8XOvS1TF4yPnT7u6 80EDPBlnFVDTMUfoSgASEKRw7LisMGTWshtqiC1bFQ== X-Google-Smtp-Source: AB8JxZpgJFlVIvg1E3fM7Ynao1lDVMrgvIuHoJ20/PtBFa1/U4Exv8ickwkDQD8VR9OEC7lsjZIP2QvLI9q6aj1xU8I= X-Received: by 10.55.194.13 with SMTP id i13mr12589210qkm.311.1525190063888; Tue, 01 May 2018 08:54:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.48.66 with HTTP; Tue, 1 May 2018 08:54:23 -0700 (PDT) From: Tom Herbert Date: Tue, 1 May 2018 08:54:23 -0700 Message-ID: To: Dino Farinacci Cc: Tom Herbert , 5GANGIP <5gangip@ietf.org>, Behcet Sarikaya , Christian Huitema , Dirk.von-Hugo@telekom.de, ila@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Ila] ILA forwaring [Was Re: [5gangip] Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 15:54:27 -0000 Dino, > I don=E2=80=99t want to look at code. I want you to explain clearly how a= cache misser gets the RLOC. What if the identifier is not in its shard? > RLOCs don't exist in ILA, that is a LISP term. > You are missing the point. Forward to where? How? > I will try to answer your questions in as much detail as possible. Here are the example cases that illustrate operation. Case #1: A network has a single SIR prefix and one ILA-R and some number of ILA-Ns. The ILA-Ns do not have a map cache and are only used for SIR to ILA transformation. The ILA-R advertises the SIR prefix in normal IP routing. It is the router for the SIR prefix. Packets destined to an address with the SIR prefix are thus routed the to ILA-R. Mapping entries are realized as hosts routes in the ILA-R where the destination host is composed of the SIR prefix and identifier. When an ILA-R receives a packet it performs a route lookup. If the returned route is an ILA route then the ILA transformation is performed where the SIR prefix is overridden with the locator indicated in the route. The packet is then forwarded back into the network. Normal IP routing forwards the packet to an ILA-N corresponding to the locator (each ILA-N is assigned a unique locator and routing is configured so that all packets with the locator prefix in the destination address are forwarded to the ILA-N). At the ILA-N, ILA to SIR transformation occurs so that original packet is restored. The packet is then forwarded by the ILA-N to a downstream destination (e.g. a UE). If an ILA-R receives a packet and it finds there is no route for it then it drops the packet. So if no ILA mapping exists for an identifier address then the packet is dropped. The ILA-R contains all the mappings for the ILA domain, if does not need to ask someone else if it doesn't find a mapping. ILA-Rs are not map caches. Case #2: A network has a single SIR prefix and multiple ILA-R and some number of ILA-Ns. The ILA-Ns do not have a map cache and are only use for SIR to ILA transformation. This is the case where ILA-Rs are replicated for load and availability. Each ILA-R advertises the SIR prefix in IP routing for the network. Routing techniques of ECMP, shortest path, etc. are used to route packets to the "nearest" ILA-R. Packet processing at each ILA-R is the same as described in case #1. Case #3: A network has a multiple ILA-R that shard the mapping entries and some number of ILA-Ns. The ILA-Ns do not have a map cache and are only use for SIR to ILA transformation. The low order bits of the SIR prefix contain a shard index, the high order bits are common. In this case the mapping table is not contained a single ILA-R, it is sharded across some number of them. This might be done because the table is too big, or for geographic locality, etc. Each shard is associated with an index. SIR prefixes are composed of a common prefix and the index in the low order bits (for instance index could be eight bits). Each ILA-R then advertises its SIR prefix that includes its index in IP routing. An ILA-R can also serve multiple shards so it may advertise multiple prefixes in routing. Each shard may also be replicated per case #2. Packet processing at each ILA-R is the same as described in case #1. * Note that none of these cases so far require a mapping cache. These work for all packets regardless of the source. The sender may be local to the network, or may be a host on the Internet. Case 4: Map caches are enabled on ILA-Ns. The map cache is implemented as host routes in an ILA-N similar to ILA-R routes. When a packet is sent by a downstream device (e.g. a UE) it traverses an ILA-N. The ILA-N performs a route lookup on the packet. If an ILA route is found (a map cache hit) an ILA transformation is performed an the packet is forwarded directly towards the destination. If there is no ILA route (map cache miss), then another route is found possibly the default route (remember these are just normal route lookups). The packet is forward per the route and since it still has a SIR prefix in the destination address it will be forwarded to an ILA-R as described in case #1. The ILA-N does not send a mapping request and does not remember the destination, it just forwards without incurring any additional delay. When ILA-Rs receive packets they transform and forward them as described above. It MAY also send an ILA redirect. An ILA redirect can only be sent to an ILA-N that is in the local ILA domain. To do this the ILA-R performs a reverse lookup on the source address of the received packets. If the lookup returns an ILA route then that will contain the locator corresponding to the ILA-N for the sender. A redirect message is sent the locator using ILAMP. This contains the destination and the locator. When the ILA-N receives the redirect it instantiates the routing table with an ILA route. Subsequent packets then can use the route so that packets are router directly thereby eliminating triangular routing. There are other details about managing the ILA cache that are described in draft-herbert-ila-ilamp-00. Tom From nobody Tue May 1 09:10:28 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94FF1205D3; Tue, 1 May 2018 09:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 H66wiF4aSjhg; Tue, 1 May 2018 09:10:18 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 23A791201FA; Tue, 1 May 2018 09:10:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 0AC1440001B; Tue, 1 May 2018 09:10:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1525191018; bh=5MNJaJQ00FngfCOv8RiHXygRUkRfgbZJ6BTknaF6OfU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Ixdlm8EbRrzE4sEmwfStE4hOMbIf1fXfqJsh6e6twTqcm+JiIDFiznROzPoVCeq0W irT6aVU6GrF6cpkFFPRDmZs0wfU8ahRtu7nmgNckoAaKqd8aIgFV1JSk0EQsCqQtyG 2ZkbCt2GunXpuN8IQNiC17VGoRNB8pXe38IyheBs= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 8FBBE400050; Tue, 1 May 2018 09:10:16 -0700 (PDT) To: Tom Herbert Cc: ila@ietf.org, Christian Huitema , 5GANGIP <5gangip@ietf.org>, Tom Herbert References: From: "Joel M. Halpern" Message-ID: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> Date: Tue, 1 May 2018 12:10:15 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ila] ILA forwaring [Was Re: [5gangip] Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 16:10:21 -0000 Three reactions, all personal opinion (in case someone thinks my having helped chair the BoF is in any way relevant; it isn't): 1) If ILA-Ns do not have caches, the ILA-Rs will become hot-spots in the network. Yes, you have provision for multiple of them sharing load. However, if that sharing gets to be a significant percentage of teh routers in the network, then there is no point in having bothered with ILA, you are just routing on the SIR. 2) As far as I can tell, when some ILA-N have caches, the ILA-R have no way of knowing whether the ILA-N have caches or not. I can understand what happens if all ILA-N in a network have the same cache state (either they all have caches or they all do not have caches). But I do not know what behavior you expect of an ILA-R if the ILA-N are not uniform. Given the hot-spot issue above, I think you need to really explain why ILA-N would not ahve caches. 3 - Minor) Your usage of "sharding" seems odd. You are simply dividing the domain into address blocks, and distributing responsibility for those blocks separately. In other contexts, sharding seems to be used more generally for having subcollections of the data which can be moved around. Yours, Joel On 5/1/18 11:54 AM, Tom Herbert wrote: > Dino, > >> I don’t want to look at code. I want you to explain clearly how a cache misser gets the RLOC. What if the identifier is not in its shard? >> > RLOCs don't exist in ILA, that is a LISP term. > >> You are missing the point. Forward to where? How? >> > I will try to answer your questions in as much detail as possible. > > Here are the example cases that illustrate operation. > > Case #1: A network has a single SIR prefix and one ILA-R and some > number of ILA-Ns. The ILA-Ns do not have a map cache and are only used > for SIR to ILA transformation. > > The ILA-R advertises the SIR prefix in normal IP routing. It is the > router for the SIR prefix. Packets destined to an address with the SIR > prefix are thus routed the to ILA-R. Mapping entries are realized as > hosts routes in the ILA-R where the destination host is composed of > the SIR prefix and identifier. When an ILA-R receives a packet it > performs a route lookup. If the returned route is an ILA route then > the ILA transformation is performed where the SIR prefix is overridden > with the locator indicated in the route. The packet is then forwarded > back into the network. Normal IP routing forwards the packet to an > ILA-N corresponding to the locator (each ILA-N is assigned a unique > locator and routing is configured so that all packets with the locator > prefix in the destination address are forwarded to the ILA-N). At the > ILA-N, ILA to SIR transformation occurs so that original packet is > restored. The packet is then forwarded by the ILA-N to a downstream > destination (e.g. a UE). > > If an ILA-R receives a packet and it finds there is no route for it > then it drops the packet. So if no ILA mapping exists for an > identifier address then the packet is dropped. The ILA-R contains all > the mappings for the ILA domain, if does not need to ask someone else > if it doesn't find a mapping. ILA-Rs are not map caches. > > Case #2: A network has a single SIR prefix and multiple ILA-R and some > number of ILA-Ns. The ILA-Ns do not have a map cache and are only use > for SIR to ILA transformation. > > This is the case where ILA-Rs are replicated for load and > availability. Each ILA-R advertises the SIR prefix in IP routing for > the network. Routing techniques of ECMP, shortest path, etc. are used > to route packets to the "nearest" ILA-R. Packet processing at each > ILA-R is the same as described in case #1. > > Case #3: A network has a multiple ILA-R that shard the mapping entries > and some number of ILA-Ns. The ILA-Ns do not have a map cache and are > only use for SIR to ILA transformation. The low order bits of the SIR > prefix contain a shard index, the high order bits are common. > > In this case the mapping table is not contained a single ILA-R, it is > sharded across some number of them. This might be done because the > table is too big, or for geographic locality, etc. Each shard is > associated with an index. SIR prefixes are composed of a common prefix > and the index in the low order bits (for instance index could be eight > bits). Each ILA-R then advertises its SIR prefix that includes its > index in IP routing. An ILA-R can also serve multiple shards so it may > advertise multiple prefixes in routing. Each shard may also be > replicated per case #2. Packet processing at each ILA-R is the same as > described in case #1. > > * Note that none of these cases so far require a mapping cache. These > work for all packets regardless of the source. The sender may be local > to the network, or may be a host on the Internet. > > Case 4: Map caches are enabled on ILA-Ns. > > The map cache is implemented as host routes in an ILA-N similar to > ILA-R routes. When a packet is sent by a downstream device (e.g. a UE) > it traverses an ILA-N. The ILA-N performs a route lookup on the > packet. If an ILA route is found (a map cache hit) an ILA > transformation is performed an the packet is forwarded directly > towards the destination. If there is no ILA route (map cache miss), > then another route is found possibly the default route (remember these > are just normal route lookups). The packet is forward per the route > and since it still has a SIR prefix in the destination address it will > be forwarded to an ILA-R as described in case #1. The ILA-N does not > send a mapping request and does not remember the destination, it just > forwards without incurring any additional delay. > > When ILA-Rs receive packets they transform and forward them as > described above. It MAY also send an ILA redirect. An ILA redirect can > only be sent to an ILA-N that is in the local ILA domain. To do this > the ILA-R performs a reverse lookup on the source address of the > received packets. If the lookup returns an ILA route then that will > contain the locator corresponding to the ILA-N for the sender. A > redirect message is sent the locator using ILAMP. This contains the > destination and the locator. When the ILA-N receives the redirect it > instantiates the routing table with an ILA route. Subsequent packets > then can use the route so that packets are router directly thereby > eliminating triangular routing. > > There are other details about managing the ILA cache that are > described in draft-herbert-ila-ilamp-00. > > Tom > > _______________________________________________ > ila mailing list > ila@ietf.org > https://www.ietf.org/mailman/listinfo/ila > From nobody Tue May 1 09:38:07 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB76312DA4F for ; Tue, 1 May 2018 09:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.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 rv3CHHv8ifMc for ; Tue, 1 May 2018 09:37:59 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 4A0EB12DA6F for ; Tue, 1 May 2018 09:37:56 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id f8so9326896wmc.4 for ; Tue, 01 May 2018 09:37:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7El9iGsqhrwiUSl/e2y65NW9lGvu4XQUZaSCdWK/Tbg=; b=t0todQdgVj95cjQ4wxWc0V4Q2afQViVKo5oq736LhcTHAundjGTU0yu68VCKwveCRf jQh+lqRWewKYVbWBrG3hughADr9lWWpBOh2FRZ6ksQWnzUtAPZzVCxBlvTtHV/oEryqb UWSJt+11MhqqtPr03RXIZEBMgcLS+DowJCEnCMMOg4DgTF6OvntJUQOK3fhybr0dLG2T 8V5+lJXj8JTStERirCCJodCge93lkovqw2SIw9hZFos0skUC/MRGQYImTlNvGI4hjaGI k8PylAFaXV8CveJaNQ9FXiSStVmcgBRyKsn6w0YJbfpO7f+exGreXgB72IEKrmxzayCG Shpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7El9iGsqhrwiUSl/e2y65NW9lGvu4XQUZaSCdWK/Tbg=; b=sHMi1SQqCXiK7fiDghiSD4me+soxyu4nmnqtyE6WlkUUkWUohnAsCUmM+LivX+lr1p x0MJCVkHGSj3FpPjNCg8ilxfsLnduHTtLvEE54IPEljg+mmaW+SmV+cd9/QLcXvFIqF/ dDq+z5yKyucZ64kQQOyOlSGKKhxkD4QubnYbm9o1sELolseXuINQsF9iGpvjIo9vqvtc UX+g4oIySa88ZAeHB1Yy6vDVKOwuSDqPM5lCSasHNpgEcYGaJdmhPXUbD6cbP9tHwErG M5jqt0ZPAe1RW2UuhkhMRTA3LQw3hDtGRYF43uDGmxpVTxXv5DnZfXmv6FSbigYoVZ6X CgKQ== X-Gm-Message-State: ALQs6tD9vneNQcSbGt+DSnWaqVFaZmlDciO4pLD2dq67TL/m5v0M3UCW QWGH0HaVdWfoEujfap1umcFXKfE/5HHacWCZ9c1efQ== X-Google-Smtp-Source: AB8JxZoLiSAWmLAxJKZrY3Wstc8Vd6Ya5kNDQkpXNG4LmmigzOcpqsNLB4sU+zDQaN9Rw5/t3EtCLYu0vfZYToR6e48= X-Received: by 10.28.124.10 with SMTP id x10mr9375279wmc.59.1525192674615; Tue, 01 May 2018 09:37:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.227 with HTTP; Tue, 1 May 2018 09:37:54 -0700 (PDT) In-Reply-To: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> References: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> From: Tom Herbert Date: Tue, 1 May 2018 09:37:54 -0700 Message-ID: To: "Joel M. Halpern" Cc: Tom Herbert , Christian Huitema , ila@ietf.org, 5GANGIP <5gangip@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 16:38:01 -0000 On Tue, May 1, 2018 at 9:10 AM, Joel M. Halpern wrote: > Three reactions, all personal opinion (in case someone thinks my having > helped chair the BoF is in any way relevant; it isn't): > > 1) If ILA-Ns do not have caches, the ILA-Rs will become hot-spots in the > network. Yes, you have provision for multiple of them sharing load. > However, if that sharing gets to be a significant percentage of teh routers > in the network, then there is no point in having bothered with ILA, you are > just routing on the SIR. > Joel, If you provision a network (or any system really) based on an assumption that caches will always attain some hit rate this is a fundamental mistake. One of the goals of a DOS attack would be to drive the hit rate to zero in which case someone will be in a world of hurt. Caches and DOS are a hard mix to contend with in nearly any context, that's why it's much better to view caches as an optimization rather than a requirement. They can be used to alleviate load, but that cannot be relied upon. I would also point out that caches only make sense as internal devices for intra domain communications. This does not make sense for edge routers that would need to create a working set cache for any aribtrary load of traffic from the Internet. > 2) As far as I can tell, when some ILA-N have caches, the ILA-R have no way > of knowing whether the ILA-N have caches or not. I can understand what > happens if all ILA-N in a network have the same cache state (either they all > have caches or they all do not have caches). But I do not know what > behavior you expect of an ILA-R if the ILA-N are not uniform. Given the > hot-spot issue above, I think you need to really explain why ILA-N would not > ahve caches. > ILA-Rs and ILA-Ns communicate via ILAMP protocol. That can include capabilities description. > 3 - Minor) Your usage of "sharding" seems odd. You are simply dividing the > domain into address blocks, and distributing responsibility for those blocks > separately. In other contexts, sharding seems to be used more generally for > having subcollections of the data which can be moved around. > Sharding is a database term that describes partitioning of the database into smaller chunks for manageablibilty. That is what is happening here (literally in the implementation since we are use a database backend). Tom From nobody Tue May 1 09:59:08 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4F312DB6B; Tue, 1 May 2018 09:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 S8Z1BHe_Zb9m; Tue, 1 May 2018 09:58:57 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 684041273B1; Tue, 1 May 2018 09:58:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4CE7E400055; Tue, 1 May 2018 09:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1525193937; bh=WH0Y6DKZnLdgqmvYun1o5gVeXfEJodlGfZ8mNgnsptg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=hjlPgTJ9akXrTnfvn79KDRh0noCVcy/NWuBhh79Z2OxtqZhdb3l15sIwSKPbYseHz WYK9Y7vnNBk2rQd+1y6bkG6MfolCJp57vjOjoUAo/8dEO3WsR6/4ywu8tHpBi+/uzK 3fgrmGpzruLDZZzP7/8z14pNMs/9kJgN6jJw+kIw= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 21E69400066; Tue, 1 May 2018 09:58:56 -0700 (PDT) To: Tom Herbert Cc: Tom Herbert , ila@ietf.org, 5GANGIP <5gangip@ietf.org> References: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> Date: Tue, 1 May 2018 12:58:55 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 16:58:59 -0000 If you do not use caches in your ILA-Ns (and yes, I understand your reasoning for not doing so), then you are constructing an overlay network. One of the arguments I was given for using ILA was to enable direct forwarding of packets effectively without needing to have routing track the moving entities. Without caches, you are pushing all the traffic through fewer entities. And you seem to be either using a lot of ILA-R with concomitant information distribution or few ILA-R restricting the information distribution problem but instead having traffic concentration problems. I understood from your earlier presentation that the ILA-r using the packet as a signal was to avoid dropping the first packet, and as a side-effect not needing a separate query message. Now you seem to be saying that your think it important to support not having caches in the ILA-Ns, which is a VERY different trade-off. Yours, Joel On 5/1/18 12:37 PM, Tom Herbert wrote: > On Tue, May 1, 2018 at 9:10 AM, Joel M. Halpern wrote: >> Three reactions, all personal opinion (in case someone thinks my having >> helped chair the BoF is in any way relevant; it isn't): >> >> 1) If ILA-Ns do not have caches, the ILA-Rs will become hot-spots in the >> network. Yes, you have provision for multiple of them sharing load. >> However, if that sharing gets to be a significant percentage of teh routers >> in the network, then there is no point in having bothered with ILA, you are >> just routing on the SIR. >> > Joel, > > If you provision a network (or any system really) based on an > assumption that caches will always attain some hit rate this is a > fundamental mistake. One of the goals of a DOS attack would be to > drive the hit rate to zero in which case someone will be in a world of > hurt. Caches and DOS are a hard mix to contend with in nearly any > context, that's why it's much better to view caches as an optimization > rather than a requirement. They can be used to alleviate load, but > that cannot be relied upon. > > I would also point out that caches only make sense as internal devices > for intra domain communications. This does not make sense for edge > routers that would need to create a working set cache for any > aribtrary load of traffic from the Internet. > >> 2) As far as I can tell, when some ILA-N have caches, the ILA-R have no way >> of knowing whether the ILA-N have caches or not. I can understand what >> happens if all ILA-N in a network have the same cache state (either they all >> have caches or they all do not have caches). But I do not know what >> behavior you expect of an ILA-R if the ILA-N are not uniform. Given the >> hot-spot issue above, I think you need to really explain why ILA-N would not >> ahve caches. >> > ILA-Rs and ILA-Ns communicate via ILAMP protocol. That can include > capabilities description. > >> 3 - Minor) Your usage of "sharding" seems odd. You are simply dividing the >> domain into address blocks, and distributing responsibility for those blocks >> separately. In other contexts, sharding seems to be used more generally for >> having subcollections of the data which can be moved around. >> > Sharding is a database term that describes partitioning of the > database into smaller chunks for manageablibilty. That is what is > happening here (literally in the implementation since we are use a > database backend). > > Tom > From nobody Tue May 1 10:16:23 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670D412E037; Tue, 1 May 2018 10:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 UxZllhKyi7Hm; Tue, 1 May 2018 10:16:08 -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 4443E12E03A; Tue, 1 May 2018 10:16:06 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id n202-v6so13656511ita.1; Tue, 01 May 2018 10:16:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=layXb9S/JNS0tP4fa0ekm0CpD+3g1/jrIac6D949d34=; b=TJ8ZClp9LX36QuRe6lsTyZSNSozy8YGh/FU8VamtQ2d1a+Pr319ZhW2R74YfF0pkZ3 r8EjAV+TQ4J1UwmA0FdKfPcN48mRWD0PnjrVzzDNddskBQKN2y950Xt3c0gkfk3NZVPv pRiurHOME+/OTYOiaDehTT4SwOG7h6Rfr7s+P8D3ecXV0kdWvLERR7dOJ6VaYEKyIhIK y6CsyxacTQKJqm184sf154inLcBRIUztNTq30mwr8NzktOxo+SIUfV6OMjmFz05OgR7+ Z6Wyipt2AawVtiPurZI5slX+NfdkGuoYyeMWkFCjJBlDYyZC2oYvjQQ3HFsVI8qeWUXm imHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=layXb9S/JNS0tP4fa0ekm0CpD+3g1/jrIac6D949d34=; b=tLC1Pr2pzeqaWyNF6QVS13E4N9fsu+FE2qunuFaur4X8v1SjR5Ax27Sll9xAd0laWV 9dlP5rsZqv6EWKanBAdkE+dveCd6T/H71qZNdpVaqv9ubcKaZy0AQTSPtwOti1vIS7YG O5XuspXrMXX3Xed5FSC7NNCy4mGNIIlCmbmGVkbp4Rl2odaKp+xsqPYcuAAZKMPIw4om vtf51usU4IbwyrLqtRICGG8dICdpnWocFvqCyqjchocsvuJf2m6NozybqH8WBKcjR+wG LmxnpQjko3VFiQJ6wmj1TuHBB8V8giVDT6GJJAs5w42MrM9F3bVnEcLtsCBQWzpbi214 OqjA== X-Gm-Message-State: ALQs6tBcASgwx1btZk9AVuIaFYXdYdU0ptcP+svvhBYhoTdct+p/Ec8d 6Wn/LsTRSKkpav3uYUu0hEBLUknkChvpwS469sA= X-Google-Smtp-Source: AB8JxZpofv+ytV3gEh/4Qs1zD8MFMP/bE/wU5zGyMEfPj+T8zNHKtDM3VcKptSqOOZZ8bXR1eP/btjNxPCeV7APElIA= X-Received: by 2002:a24:7b86:: with SMTP id q128-v6mr14011762itc.145.1525194965481; Tue, 01 May 2018 10:16:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.192.170.54 with HTTP; Tue, 1 May 2018 10:16:05 -0700 (PDT) Reply-To: sarikaya@ieee.org In-Reply-To: <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> References: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> From: Behcet Sarikaya Date: Tue, 1 May 2018 12:16:05 -0500 Message-ID: To: "Joel M. Halpern" Cc: Tom Herbert , Tom Herbert , ila@ietf.org, 5GANGIP <5gangip@ietf.org> Content-Type: multipart/alternative; boundary="000000000000217cc4056b2820fd" Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 17:16:15 -0000 --000000000000217cc4056b2820fd Content-Type: text/plain; charset="UTF-8" On Tue, May 1, 2018 at 11:58 AM, Joel M. Halpern wrote: If you do not use caches in your ILA-Ns (and yes, I understand your > reasoning for not doing so), then you are constructing an overlay network. You mean it is kind of tunneling? I think this is a problem with all Id-Loc systems except ILNP, I think. One of the arguments I was given for using ILA was to enable direct > forwarding of packets effectively without needing to have routing track the > moving entities. Without caches, you are pushing all the traffic through > fewer entities. And you seem to be either using a lot of ILA-R with > concomitant information distribution or few ILA-R restricting the > information distribution problem but instead having traffic concentration > problems. > > I understood from your earlier presentation that the ILA-r using the > packet as a signal was to avoid dropping the first packet, and as a > side-effect not needing a separate query message. > > Now you seem to be saying that your think it important to support not > having caches in the ILA-Ns, which is a VERY different trade-off. > > I kind of support this idea ( not having caches) looking from privacy point of view. A cache learned for one UE may have privacy issues for another UE. So using that cache entry freely may not be a good idea. Behcet Yours, > Joel > > > On 5/1/18 12:37 PM, Tom Herbert wrote: > >> On Tue, May 1, 2018 at 9:10 AM, Joel M. Halpern >> wrote: >> >>> Three reactions, all personal opinion (in case someone thinks my having >>> helped chair the BoF is in any way relevant; it isn't): >>> >>> 1) If ILA-Ns do not have caches, the ILA-Rs will become hot-spots in the >>> network. Yes, you have provision for multiple of them sharing load. >>> However, if that sharing gets to be a significant percentage of teh >>> routers >>> in the network, then there is no point in having bothered with ILA, you >>> are >>> just routing on the SIR. >>> >>> Joel, >> >> If you provision a network (or any system really) based on an >> assumption that caches will always attain some hit rate this is a >> fundamental mistake. One of the goals of a DOS attack would be to >> drive the hit rate to zero in which case someone will be in a world of >> hurt. Caches and DOS are a hard mix to contend with in nearly any >> context, that's why it's much better to view caches as an optimization >> rather than a requirement. They can be used to alleviate load, but >> that cannot be relied upon. >> >> I would also point out that caches only make sense as internal devices >> for intra domain communications. This does not make sense for edge >> routers that would need to create a working set cache for any >> aribtrary load of traffic from the Internet. >> >> 2) As far as I can tell, when some ILA-N have caches, the ILA-R have no >>> way >>> of knowing whether the ILA-N have caches or not. I can understand what >>> happens if all ILA-N in a network have the same cache state (either they >>> all >>> have caches or they all do not have caches). But I do not know what >>> behavior you expect of an ILA-R if the ILA-N are not uniform. Given the >>> hot-spot issue above, I think you need to really explain why ILA-N would >>> not >>> ahve caches. >>> >>> ILA-Rs and ILA-Ns communicate via ILAMP protocol. That can include >> capabilities description. >> >> 3 - Minor) Your usage of "sharding" seems odd. You are simply dividing >>> the >>> domain into address blocks, and distributing responsibility for those >>> blocks >>> separately. In other contexts, sharding seems to be used more generally >>> for >>> having subcollections of the data which can be moved around. >>> >>> Sharding is a database term that describes partitioning of the >> database into smaller chunks for manageablibilty. That is what is >> happening here (literally in the implementation since we are use a >> database backend). >> >> Tom >> >> > _______________________________________________ > 5gangip mailing list > 5gangip@ietf.org > https://www.ietf.org/mailman/listinfo/5gangip > --000000000000217cc4056b2820fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, May 1, 2018 at 11:58 AM, Joel M. Halpern <= jmh@joelhalpern.co= m> wrote:


If you do not use cach= es in your ILA-Ns (and yes, I understand your reasoning for not doing so), = then you are constructing an overlay network.=C2=A0


You mean it is kind of tunneling? I think this is a= problem with all Id-Loc systems except ILNP, I think.

=

One of the arguments I was g= iven for using ILA was to enable direct forwarding of packets effectively w= ithout needing to have routing track the moving entities.=C2=A0 Without cac= hes, you are pushing all the traffic through fewer entities.=C2=A0 And you = seem to be either using a lot of ILA-R with concomitant information distrib= ution or few ILA-R restricting the information distribution problem but ins= tead having traffic concentration problems.

I understood from your earlier presentation that the ILA-r using the packet= as a signal was to avoid dropping the first packet, and as a side-effect n= ot needing a separate query message.
=C2=A0
Now you seem to be saying that your think it important to support not havin= g caches in the ILA-Ns, which is a VERY different trade-off.


I kind of support this idea ( not havi= ng caches) looking from privacy point of view. A cache learned for one UE m= ay have privacy issues for another UE. So using that cache entry freely may= not be a good idea.

Behcet


Yours,
Joel


On 5/1/18 12:37 PM, Tom Herbert wrote:
On Tue, May 1, 2018 at 9:10 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
Three reactions, all personal opinion (in case someone thinks my having
helped chair the BoF is in any way relevant; it isn't):

1) If ILA-Ns do not have caches, the ILA-Rs will become hot-spots in the network.=C2=A0 Yes, you have provision for multiple of them sharing load. However, if that sharing gets to be a significant percentage of teh routers=
in the network, then there is no point in having bothered with ILA, you are=
just routing on the SIR.

Joel,

If you provision a network (or any system really) based on an
assumption that caches will always attain some hit rate this is a
fundamental mistake. One of the goals of a DOS attack would be to
drive the hit rate to zero in which case someone will be in a world of
hurt. Caches and DOS are a hard mix to contend with in nearly any
context, that's why it's much better to view caches as an optimizat= ion
rather than a requirement. They can be used to alleviate load, but
that cannot be relied upon.

I would also point out that caches only make sense as internal devices
for intra domain communications. This does not make sense for edge
routers that would need to create a working set cache for any
aribtrary load of traffic from the Internet.

2) As far as I can tell, when some ILA-N have caches, the ILA-R have no way=
of knowing whether the ILA-N have caches or not.=C2=A0 I can understand wha= t
happens if all ILA-N in a network have the same cache state (either they al= l
have caches or they all do not have caches).=C2=A0 But I do not know what behavior you expect of an ILA-R if the ILA-N are not uniform. Given the
hot-spot issue above, I think you need to really explain why ILA-N would no= t
ahve caches.

ILA-Rs and ILA-Ns communicate via ILAMP protocol. That can include
capabilities description.

3 - Minor) Your usage of "sharding" seems odd.=C2=A0 You are simp= ly dividing the
domain into address blocks, and distributing responsibility for those block= s
separately.=C2=A0 In other contexts, sharding seems to be used more general= ly for
having subcollections of the data which can be moved around.

Sharding is a database term that describes partitioning of the
database into smaller chunks for manageablibilty. That is what is
happening here (literally in the implementation since we are use a
database backend).

Tom


_______________________________________________
5gangip mailing list
5gangip@ietf.org<= br> https://www.ietf.org/mailman/listinfo/5gangip<= br>

--000000000000217cc4056b2820fd-- From nobody Tue May 1 10:17:06 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69AC912DB6D for ; Tue, 1 May 2018 10:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 vU916-db6PZV for ; Tue, 1 May 2018 10:16:37 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 B0AA912E8C9 for ; Tue, 1 May 2018 10:16:31 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id e8-v6so10427709qth.0 for ; Tue, 01 May 2018 10:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5stP3/NWIutou0D6ti8EhvfEJ85no9kBpHpVil59j44=; b=gZmlipXCmnvzynPZavKfwN20ZPkJ6K6SLvxMqOrHK/BdLC/7NN03WuYq5h75TVVB6Y IjjFkLE5+p/SPuXLm881A7dMBmvklQKV0CBuQ15Nk8/q1cvOAg7LZ5GiuNlYt3aWzHsw bDZQHHrh1eC7dYi9hgx5S0S102glrCkpFNU+D1wPGFtVg1ueNoavYuDR/FaGiQxhViEL w9PtQkqlw9B5bJnHc2tCiZKFa6ky/sNdUP8sbkYXMgiMw6O188aWc8AHzkYYK4y26OS9 6BYLtw0ygVQWoqvFlJEEFC6pFBDL8nOg6JpSkHp7o7t3HDozwjHU+KYrQk8vGVmoHRMU 5Y4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5stP3/NWIutou0D6ti8EhvfEJ85no9kBpHpVil59j44=; b=J+NggAXWQrhGXuSizO+dkq6Q4P6r3EIm8MuWYFsnCOJvpJIwBvGsdCtQLCi7B+GwUh +ivd1BJGaHnbtJr4yaox7ERa0TKECzviZqqB1+DpYNtqcb0AcsVD9wuQsChCKl1bL+q6 y7datzM962QH7UAb7v1w5zWocH8SMJh6pMey8fd5bk9SGPFEoq+ka54xf1pi1r3n4GHw JPwwCezRPqduQSmL2+LJWu3aHGZAbAraN0vqwe/0j5OJW2O/hoTVtWxEVSenoXsteQYE y1kPTzEZ6q5l1oSdDQITK7zZNIBzqw4fTdooO64yuRtmxBeN+L2eIz1bRfaf1id2lDJ8 ToYg== X-Gm-Message-State: ALQs6tD+dwcyzX+6c6/6c2WmvWLXm8BG7Owv91u2kHsdNnbLyBzVX0fO VBIvBuuczsqEyiib64NxB2zysJRlNGeuwITSN8VhIA== X-Google-Smtp-Source: AB8JxZqoaxBJqRdYHj/18Ip49SR/ex8ZKjr5fgOuflYnslZrEspZsy4PcbBW0iOHCG447b2RVuGudKJCZKx0Eo1I4q4= X-Received: by 2002:ac8:2998:: with SMTP id 24-v6mr14048463qts.197.1525194990547; Tue, 01 May 2018 10:16:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.48.66 with HTTP; Tue, 1 May 2018 10:16:29 -0700 (PDT) In-Reply-To: <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> References: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> From: Tom Herbert Date: Tue, 1 May 2018 10:16:29 -0700 Message-ID: To: "Joel M. Halpern" Cc: Tom Herbert , ila@ietf.org, 5GANGIP <5gangip@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 17:16:49 -0000 On Tue, May 1, 2018 at 9:58 AM, Joel M. Halpern wrote: > If you do not use caches in your ILA-Ns (and yes, I understand your > reasoning for not doing so), then you are constructing an overlay network. > One of the arguments I was given for using ILA was to enable direct > forwarding of packets effectively without needing to have routing track the > moving entities. Without caches, you are pushing all the traffic through > fewer entities. And you seem to be either using a lot of ILA-R with > concomitant information distribution or few ILA-R restricting the > information distribution problem but instead having traffic concentration > problems. > > I understood from your earlier presentation that the ILA-r using the packet > as a signal was to avoid dropping the first packet, and as a side-effect not > needing a separate query message. > Now you seem to be saying that your think it important to support not having > caches in the ILA-Ns, which is a VERY different trade-off. > Joel, I think you've misunderstood my position. Caches are _very_ important to eliminate the cost triangular routing (latency, average path load). This reduces latency and reduces average load on ILA-Rs. But, and this is the critical part, caches are only an _optimization_ in ILA. That means if the cache is rendered ineffective (like by a well crafted DOS attack) then the only effect is that the optimization is loss (i.e. greater latency due to triangular router)-- this is quantitively the worst effect of the attack on an ILA cache. This can be contrasted that to LISP where the worst case effects of a DOS attack on the cache is loss of service for users (infinite latency since packets can be dropped or indefinitely blocked on a cache miss). Tom > Yours, > Joel > > > On 5/1/18 12:37 PM, Tom Herbert wrote: >> >> On Tue, May 1, 2018 at 9:10 AM, Joel M. Halpern >> wrote: >>> >>> Three reactions, all personal opinion (in case someone thinks my having >>> helped chair the BoF is in any way relevant; it isn't): >>> >>> 1) If ILA-Ns do not have caches, the ILA-Rs will become hot-spots in the >>> network. Yes, you have provision for multiple of them sharing load. >>> However, if that sharing gets to be a significant percentage of teh >>> routers >>> in the network, then there is no point in having bothered with ILA, you >>> are >>> just routing on the SIR. >>> >> Joel, >> >> If you provision a network (or any system really) based on an >> assumption that caches will always attain some hit rate this is a >> fundamental mistake. One of the goals of a DOS attack would be to >> drive the hit rate to zero in which case someone will be in a world of >> hurt. Caches and DOS are a hard mix to contend with in nearly any >> context, that's why it's much better to view caches as an optimization >> rather than a requirement. They can be used to alleviate load, but >> that cannot be relied upon. >> >> I would also point out that caches only make sense as internal devices >> for intra domain communications. This does not make sense for edge >> routers that would need to create a working set cache for any >> aribtrary load of traffic from the Internet. >> >>> 2) As far as I can tell, when some ILA-N have caches, the ILA-R have no >>> way >>> of knowing whether the ILA-N have caches or not. I can understand what >>> happens if all ILA-N in a network have the same cache state (either they >>> all >>> have caches or they all do not have caches). But I do not know what >>> behavior you expect of an ILA-R if the ILA-N are not uniform. Given the >>> hot-spot issue above, I think you need to really explain why ILA-N would >>> not >>> ahve caches. >>> >> ILA-Rs and ILA-Ns communicate via ILAMP protocol. That can include >> capabilities description. >> >>> 3 - Minor) Your usage of "sharding" seems odd. You are simply dividing >>> the >>> domain into address blocks, and distributing responsibility for those >>> blocks >>> separately. In other contexts, sharding seems to be used more generally >>> for >>> having subcollections of the data which can be moved around. >>> >> Sharding is a database term that describes partitioning of the >> database into smaller chunks for manageablibilty. That is what is >> happening here (literally in the implementation since we are use a >> database backend). >> >> Tom >> > From nobody Tue May 1 10:22:37 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1FC12E8CE; Tue, 1 May 2018 10:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 T-7qssdQfxIo; Tue, 1 May 2018 10:22:27 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 8E1E112E8C9; Tue, 1 May 2018 10:22:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 7AE8440231A; Tue, 1 May 2018 10:22:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1525195347; bh=TAtUHRNkVm6iwVhXCSGXnlE5cKAf8aoeZC5nAyeO2+s=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=g/tu8HLrXrlfo0KfrnLQcyOYJomBc3J7mK1WBt7k1GB2T+t+MuSVLsKCgWGpyaIV9 OVUo1/yH3MQYoVLQS4yGtGxV9AXArQpD7D1OgSu0M4kIIu0gBiccOc6lbCnSm66xak lT5A54O3sFfxhz3rJ21oz8I/jMBTrSC/bbdNFBdU= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 971F040005A; Tue, 1 May 2018 10:22:26 -0700 (PDT) To: Tom Herbert Cc: Tom Herbert , ila@ietf.org, 5GANGIP <5gangip@ietf.org> References: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <6d25230b-aafe-e985-7e0f-f8bd3acfb800@joelhalpern.com> Date: Tue, 1 May 2018 13:22:25 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 17:22:29 -0000 I am not sure I follow. If I am reading you right, you suggest that dropping cache usage during a DOS attack is a useful feature. If the system is engineered to operate well using local caches in the ILA, then dropping cache usage would seem to result in a DOS attack on the ILA-R infrastructure as it will have to handle a sustained packet load much higher than its design target. Yours, Joel On 5/1/18 1:16 PM, Tom Herbert wrote: > On Tue, May 1, 2018 at 9:58 AM, Joel M. Halpern wrote: >> If you do not use caches in your ILA-Ns (and yes, I understand your >> reasoning for not doing so), then you are constructing an overlay network. >> One of the arguments I was given for using ILA was to enable direct >> forwarding of packets effectively without needing to have routing track the >> moving entities. Without caches, you are pushing all the traffic through >> fewer entities. And you seem to be either using a lot of ILA-R with >> concomitant information distribution or few ILA-R restricting the >> information distribution problem but instead having traffic concentration >> problems. >> >> I understood from your earlier presentation that the ILA-r using the packet >> as a signal was to avoid dropping the first packet, and as a side-effect not >> needing a separate query message. >> Now you seem to be saying that your think it important to support not having >> caches in the ILA-Ns, which is a VERY different trade-off. >> > Joel, > > I think you've misunderstood my position. Caches are _very_ important > to eliminate the cost triangular routing (latency, average path load). > This reduces latency and reduces average load on ILA-Rs. But, and this > is the critical part, caches are only an _optimization_ in ILA. That > means if the cache is rendered ineffective (like by a well crafted DOS > attack) then the only effect is that the optimization is loss (i.e. > greater latency due to triangular router)-- this is quantitively the > worst effect of the attack on an ILA cache. This can be contrasted > that to LISP where the worst case effects of a DOS attack on the cache > is loss of service for users (infinite latency since packets can be > dropped or indefinitely blocked on a cache miss). > > Tom > >> Yours, >> Joel >> >> >> On 5/1/18 12:37 PM, Tom Herbert wrote: >>> >>> On Tue, May 1, 2018 at 9:10 AM, Joel M. Halpern >>> wrote: >>>> >>>> Three reactions, all personal opinion (in case someone thinks my having >>>> helped chair the BoF is in any way relevant; it isn't): >>>> >>>> 1) If ILA-Ns do not have caches, the ILA-Rs will become hot-spots in the >>>> network. Yes, you have provision for multiple of them sharing load. >>>> However, if that sharing gets to be a significant percentage of teh >>>> routers >>>> in the network, then there is no point in having bothered with ILA, you >>>> are >>>> just routing on the SIR. >>>> >>> Joel, >>> >>> If you provision a network (or any system really) based on an >>> assumption that caches will always attain some hit rate this is a >>> fundamental mistake. One of the goals of a DOS attack would be to >>> drive the hit rate to zero in which case someone will be in a world of >>> hurt. Caches and DOS are a hard mix to contend with in nearly any >>> context, that's why it's much better to view caches as an optimization >>> rather than a requirement. They can be used to alleviate load, but >>> that cannot be relied upon. >>> >>> I would also point out that caches only make sense as internal devices >>> for intra domain communications. This does not make sense for edge >>> routers that would need to create a working set cache for any >>> aribtrary load of traffic from the Internet. >>> >>>> 2) As far as I can tell, when some ILA-N have caches, the ILA-R have no >>>> way >>>> of knowing whether the ILA-N have caches or not. I can understand what >>>> happens if all ILA-N in a network have the same cache state (either they >>>> all >>>> have caches or they all do not have caches). But I do not know what >>>> behavior you expect of an ILA-R if the ILA-N are not uniform. Given the >>>> hot-spot issue above, I think you need to really explain why ILA-N would >>>> not >>>> ahve caches. >>>> >>> ILA-Rs and ILA-Ns communicate via ILAMP protocol. That can include >>> capabilities description. >>> >>>> 3 - Minor) Your usage of "sharding" seems odd. You are simply dividing >>>> the >>>> domain into address blocks, and distributing responsibility for those >>>> blocks >>>> separately. In other contexts, sharding seems to be used more generally >>>> for >>>> having subcollections of the data which can be moved around. >>>> >>> Sharding is a database term that describes partitioning of the >>> database into smaller chunks for manageablibilty. That is what is >>> happening here (literally in the implementation since we are use a >>> database backend). >>> >>> Tom >>> >> From nobody Tue May 1 10:27:10 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 592DC12E8CE; Tue, 1 May 2018 10:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 FUcgXSglMZSy; Tue, 1 May 2018 10:27:01 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 DD13B126C89; Tue, 1 May 2018 10:27:00 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id q6-v6so15335523qtn.3; Tue, 01 May 2018 10:27:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=S+CG0bRqDI4PUUyp+sLvAekE3eODDX7zRhExrLRNe3Q=; b=Kn3UV26hPHKWe0a30KiEUgXOjkJcpWrXZ+xGXVETVlsdOP4URirWG+mLcgZo7E4j6B QVipdpd+30T4t0kMMNSaYlfKqJOHFWdKYkT1rofl3fTTtxDVsFfNf0bOf5Wdr9GUL+mk Fsbj8WIo75WO485aTW5CwlNo93h3hQ0Ysm+a5X+2tLL4xfaXlAhRrzaCuUdlCT+Ei/Xp xDEvQ7EeEZ6T2gEJkujTsfKeuE6u+AcrGTYzrFQh1JMIDhw4IrxzQMnDlWQ/fbiZzwe+ K451sFxffr66vXIc1/PPz9/UhKsdoDTlICZwsgNqz5m92wG2rkK1BxXHE4WQZzRAdjPQ 7/xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=S+CG0bRqDI4PUUyp+sLvAekE3eODDX7zRhExrLRNe3Q=; b=YXvDiWKKaIpT+/vZVrvF0qjqRoeE0udQzQP6J8UxpSgn/NpaDnYVvzhRT4Ccf71ypf KbhRKX2ccO4Lp/uDropGpeMFkWGtoNU6cIENICBB4fdvCeK9/zeRLz2pJir8aPX8eveQ Fxq/DGG7hC+Nt2kT98l1mhZ8OtHTuzo6ww4gi1GTDJuEtCnLe0saUbeTT/rwuO8nupT3 rAhxbL3TbIkBLsu70eEqJNqMZCe6ylYiub0CzF7nhsQRH/UPdTTu/mTkTfXItihww97v jvGNgaHokoi+P6sYDXxn06ojgKpLnmKNRgU3u3Ww964RCZhX73GsWDmNKjtjjKQ2y3Il xSHg== X-Gm-Message-State: ALQs6tDg3/6gCCZZJixKHrWwgX1UNzKfInPSdcLtTTlOJadKF+l4dsuI qJmmhHcHV+tUY3QzfUsJRsQ= X-Google-Smtp-Source: AB8JxZouj31xbyVnKKFLoHV/xAuwt0jZm6X9Uy7eIQHDBTHNcCPS6HJ4B0ImZ0paa8FWJYCWMSmL3w== X-Received: by 2002:ac8:2916:: with SMTP id y22-v6mr14894809qty.18.1525195619675; Tue, 01 May 2018 10:26:59 -0700 (PDT) Received: from [10.207.57.221] ([184.169.45.4]) by smtp.gmail.com with ESMTPSA id e56-v6sm8698475qtc.61.2018.05.01.10.26.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 May 2018 10:26:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Dino Farinacci In-Reply-To: Date: Tue, 1 May 2018 10:25:46 -0700 Cc: Tom Herbert , 5GANGIP <5gangip@ietf.org>, Behcet Sarikaya , Christian Huitema , Dirk.von-Hugo@telekom.de, ila@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <04561B6C-E280-4EE0-B789-3880C8B69A08@gmail.com> References: To: Tom Herbert X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Ila] ILA forwaring [Was Re: [5gangip] Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 17:27:03 -0000 > I will try to answer your questions in as much detail as possible. Thanks for more details. > Here are the example cases that illustrate operation. >=20 > Case #1: A network has a single SIR prefix and one ILA-R and some > number of ILA-Ns. The ILA-Ns do not have a map cache and are only used > for SIR to ILA transformation. >=20 > The ILA-R advertises the SIR prefix in normal IP routing. It is the > router for the SIR prefix. Packets destined to an address with the SIR > prefix are thus routed the to ILA-R. Mapping entries are realized as > hosts routes in the ILA-R where the destination host is composed of > the SIR prefix and identifier. When an ILA-R receives a packet it What do you mean by realized. Are host routes storedin ILR-R routers via = a push protocol like ILAMP? You are going to push all host routes for = all ILA-N nodes in the Internet? > * Note that none of these cases so far require a mapping cache. These > work for all packets regardless of the source. The sender may be local > to the network, or may be a host on the Internet. That is not clear for case #1. Answer my above question first. > Case 4: Map caches are enabled on ILA-Ns. >=20 > The map cache is implemented as host routes in an ILA-N similar to > ILA-R routes. When a packet is sent by a downstream device (e.g. a UE) > it traverses an ILA-N. The ILA-N performs a route lookup on the > packet. If an ILA route is found (a map cache hit) an ILA > transformation is performed an the packet is forwarded directly > towards the destination. If there is no ILA route (map cache miss), > then another route is found possibly the default route (remember these > are just normal route lookups). The packet is forward per the route > and since it still has a SIR prefix in the destination address it will > be forwarded to an ILA-R as described in case #1. The ILA-N does not > send a mapping request and does not remember the destination, it just > forwards without incurring any additional delay. Okay, so the scale of the underlay depends on the number of SIR prefixes = injected into the routing system. When using sharding, it could be a = lot. This model is kinda a hybrid overlay/underlay where the underlay = needs to take part in make packet forwarding work. So be it. Dino From nobody Tue May 1 10:30:05 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C64712E8D2; Tue, 1 May 2018 10:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 2izgpR2kWK3t; Tue, 1 May 2018 10:30:02 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 2D2BE12E8CE; Tue, 1 May 2018 10:30:02 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id e8-v6so10468311qth.0; Tue, 01 May 2018 10:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/p+3tssVBjDLgPvJjZuCWXswyaNkVT8WENXu3qNau08=; b=sYgzpie/QbgyjzMOnPpdP+xwr3KCvCiAHiqWwsQsm8yZIyxKkI2g7pWSyvu/ByvKUB oFrqeWXi+u8nbxjhzKpV2cpB0c1p4GnACYw4Pussr7UVtkJJm38g2yp20Enly7h0Jt2T wEI2So+zngtIOJrRPlKiV5IEW0oSfzRa/GbMXzFhNxZcg061wAd6WO5l2Uh+UlolhFNc YpD2LfWr0ZCtMTWepQbXkiKQHn+xM5eHHNNZXW/qbSyjyN3mvpqMGoEh/liL/l1tcBC3 UPpfpSxNI+9t1Xu+uvDofSudmZLEp5VSiKvJColXMgZaeYNYhw+7T+q4gjXyQZlnWKwW nZ/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/p+3tssVBjDLgPvJjZuCWXswyaNkVT8WENXu3qNau08=; b=p491KKvgA7Bs6HPTLP6SJ5d224DwL+769ojgOZ6j2lYtyUpSuadcmyYbajLZgORbnH eeGWUZMs+Z3Rwp9ISq76dMvTIsv5PUMyltZAhyFwPjPmueZNFJg82pKyIX2s5bnXKb6e r7fR9U68jWGWLRKUADDW5iIpOxN6AJYHje1UElSlYspr/xM/oss1fQAFlStOWTO/dEe6 KNOvy+sTG0boSZFPaKtofUJDv2Hlr3psdTPMjK+5oxanmF7O2v+6svfrAsCL+5PdMViN 667hq+owO2ArdvKbL7PP/PcS3R3Vq1lOnsVfvpbJQJWntzQapaefu10CnuTZ7Za9jDp9 VKEw== X-Gm-Message-State: ALQs6tAUin1BZCaIUUc4fFvRYX5SzceagIXL2feheJYhrU1wm4Zv97wl KbuJVF6P9IAS1/kgaCAKqgc4by83 X-Google-Smtp-Source: AB8JxZrFsxRg9lKH2epjJ+65y+S6nHYjjUJkhxcoHFaD+bkm6/nz6NTzwxlCsUeIrnYWx+zd9An9Cg== X-Received: by 2002:a0c:876e:: with SMTP id 43-v6mr11203755qvi.66.1525195801369; Tue, 01 May 2018 10:30:01 -0700 (PDT) Received: from [10.207.57.221] ([184.169.45.4]) by smtp.gmail.com with ESMTPSA id e56-v6sm8701581qtc.61.2018.05.01.10.29.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 May 2018 10:30:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Dino Farinacci In-Reply-To: <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> Date: Tue, 1 May 2018 10:28:49 -0700 Cc: Tom Herbert , Tom Herbert , ila@ietf.org, 5GANGIP <5gangip@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: References: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 17:30:04 -0000 > If you do not use caches in your ILA-Ns (and yes, I understand your = reasoning for not doing so), then you are constructing an overlay = network. One of the arguments I was given for using ILA was to enable = direct forwarding of packets effectively without needing to have routing = track the moving entities. Without caches, you are pushing all the = traffic through fewer entities. And you seem to be either using a lot = of ILA-R with concomitant information distribution or few ILA-R = restricting the information distribution problem but instead having = traffic concentration problems. As well as suboptimal paths. Dino From nobody Tue May 1 10:33:10 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6376712E8D3; Tue, 1 May 2018 10:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 pNSvXVgaDSXL; Tue, 1 May 2018 10:33:05 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 0EFED12E8CE; Tue, 1 May 2018 10:33:05 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id q6-v6so15354337qtn.3; Tue, 01 May 2018 10:33:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XgGjobNY4iSD/aCgUTSl9gCT8owcn64F5t0BQsOAWUI=; b=Ven3zi7CX6vohE2TlwLH/4xo349YjUDmAXvFAYoOwkKo8OWW9Dk9uWNJ+jwmexDzAz wyXm1GtPcnJvWGe6ofQ3ILaNfBUCPmRHT01wxOQa4HSfTDKiXE7cK4MjxRp8UUVVflQe rS5hVtbdEQVDeV1dGmuc+BnrdQI8oImvofHCg4Qqvvvg83zXOLCQVkOHj29plGfE07V5 8pQDJMF4fCfWxmMvc86LBuCB0SbCC2wky1ADZzsvVmWO/irkAcytKw++qmaZEE8rglgO dQ3pnWU1bog8atoOEo79E8KLA8PSyojEb/8bvP5P819jlyXCE/Elo37L+XuOuFP+RZkv 33Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XgGjobNY4iSD/aCgUTSl9gCT8owcn64F5t0BQsOAWUI=; b=cynXnB3O8iXunatJiG4Y6MXYFyiVbti+rkkoGiJAKinIPV7pzSDfdfJim19b5C+6Tj 2B1MVZJrm0CyJROpRo+dbK1MknNDGAu6AmCJCpxCu+yLlIERJTsc2x9JsjE9+SxbyDSe /S5eSdCNa62l/aXX1XsOqbj4O1vQr4UvQq702IBFspUOTrwSVR5ihWapxPsNKpscuu/u LkF+SeBMbWBMENpjkf/8Xk9nD4KPMrjgDB3c5sfiU6He4pEOCx8w0xtIGb7d15wKUbGo 2G0BzrmMfyEW4VkLpokGJYE4S+s2PUExAzueqWgeXc5wWCXXqvFUMtPJ3cpM1b3ELXCa 2RMw== X-Gm-Message-State: ALQs6tBIEGPOp5Qp9ekwx9J/2ha5wvTNDCXWn8uUn32a8R+EzwJ0I9Xe oRolbvAfGBcA5xCvZgtwP1E= X-Google-Smtp-Source: AB8JxZpHG2HlM1b0mAONAHOpFNy9LnKbk2djwoS7j4EvNOlJCeIoOrvd9C6eQMHmUBduU/v5+stEIw== X-Received: by 2002:aed:2864:: with SMTP id r91-v6mr14552764qtd.233.1525195984106; Tue, 01 May 2018 10:33:04 -0700 (PDT) Received: from [10.207.57.221] ([184.169.45.4]) by smtp.gmail.com with ESMTPSA id 135sm7672311qkf.26.2018.05.01.10.32.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 May 2018 10:33:03 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Dino Farinacci In-Reply-To: Date: Tue, 1 May 2018 10:31:52 -0700 Cc: "Joel M. Halpern" , ila@ietf.org, Tom Herbert , 5GANGIP <5gangip@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: <10822D91-7DCB-40F8-8A8B-10B485F9F507@gmail.com> References: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> To: Tom Herbert X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 17:33:08 -0000 > I think you've misunderstood my position. Caches are _very_ important > to eliminate the cost triangular routing (latency, average path load). > This reduces latency and reduces average load on ILA-Rs. But, and this > is the critical part, caches are only an _optimization_ in ILA. That > means if the cache is rendered ineffective (like by a well crafted DOS > attack) then the only effect is that the optimization is loss (i.e. > greater latency due to triangular router)-- this is quantitively the > worst effect of the attack on an ILA cache. This can be contrasted > that to LISP where the worst case effects of a DOS attack on the cache > is loss of service for users (infinite latency since packets can be > dropped or indefinitely blocked on a cache miss). Note in LISP, most of the time, prefixes are put in the cache. For ILA = its mostly /128 host routes. And note, when an LISP ITR gets a = Map-Reply, it can elect to put coarser EID-prefixes in the cache versus = more specifics. Or, not elect to put anything in the cache and forward = to PETRs (the same as your ILA-R routers) at the expense of suboptimal = paths. There are many options in LISP prevent DoS attack cache attacks. I = don=E2=80=99t think that is true when caches are used in ILA. Dino >=20 > Tom >=20 >> Yours, >> Joel >>=20 >>=20 >> On 5/1/18 12:37 PM, Tom Herbert wrote: >>>=20 >>> On Tue, May 1, 2018 at 9:10 AM, Joel M. Halpern = >>> wrote: >>>>=20 >>>> Three reactions, all personal opinion (in case someone thinks my = having >>>> helped chair the BoF is in any way relevant; it isn't): >>>>=20 >>>> 1) If ILA-Ns do not have caches, the ILA-Rs will become hot-spots = in the >>>> network. Yes, you have provision for multiple of them sharing = load. >>>> However, if that sharing gets to be a significant percentage of teh >>>> routers >>>> in the network, then there is no point in having bothered with ILA, = you >>>> are >>>> just routing on the SIR. >>>>=20 >>> Joel, >>>=20 >>> If you provision a network (or any system really) based on an >>> assumption that caches will always attain some hit rate this is a >>> fundamental mistake. One of the goals of a DOS attack would be to >>> drive the hit rate to zero in which case someone will be in a world = of >>> hurt. Caches and DOS are a hard mix to contend with in nearly any >>> context, that's why it's much better to view caches as an = optimization >>> rather than a requirement. They can be used to alleviate load, but >>> that cannot be relied upon. >>>=20 >>> I would also point out that caches only make sense as internal = devices >>> for intra domain communications. This does not make sense for edge >>> routers that would need to create a working set cache for any >>> aribtrary load of traffic from the Internet. >>>=20 >>>> 2) As far as I can tell, when some ILA-N have caches, the ILA-R = have no >>>> way >>>> of knowing whether the ILA-N have caches or not. I can understand = what >>>> happens if all ILA-N in a network have the same cache state (either = they >>>> all >>>> have caches or they all do not have caches). But I do not know = what >>>> behavior you expect of an ILA-R if the ILA-N are not uniform. Given = the >>>> hot-spot issue above, I think you need to really explain why ILA-N = would >>>> not >>>> ahve caches. >>>>=20 >>> ILA-Rs and ILA-Ns communicate via ILAMP protocol. That can include >>> capabilities description. >>>=20 >>>> 3 - Minor) Your usage of "sharding" seems odd. You are simply = dividing >>>> the >>>> domain into address blocks, and distributing responsibility for = those >>>> blocks >>>> separately. In other contexts, sharding seems to be used more = generally >>>> for >>>> having subcollections of the data which can be moved around. >>>>=20 >>> Sharding is a database term that describes partitioning of the >>> database into smaller chunks for manageablibilty. That is what is >>> happening here (literally in the implementation since we are use a >>> database backend). >>>=20 >>> Tom >>>=20 >>=20 >=20 > _______________________________________________ > 5gangip mailing list > 5gangip@ietf.org > https://www.ietf.org/mailman/listinfo/5gangip From nobody Tue May 1 10:33:44 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080F512E8CE for ; Tue, 1 May 2018 10:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.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 AC112Be6k_mc for ; Tue, 1 May 2018 10:33:39 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 51DEA12E8D6 for ; Tue, 1 May 2018 10:33:32 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id v5-v6so11416228wrf.9 for ; Tue, 01 May 2018 10:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HrAlUKKuY1d0wEk+nPxoZe2Q03+rymbSQiAGL5hDwyM=; b=b4DnkjhBmrDvEvIyUabWZd0xc0PqoXsdfEfcMSpS9WIgAZGidBbZu4/Vc1k4HFOSOg NdBVWtcw6HJtBpse0DFesbZMAn7SlvVDajW9x+mBOoNnPKUAFgh42spIbsKoSz5Gbo2C 1zWsSZGl3fwqicynOzXjnpAQ+GVShu+N9gDFk2sISusBPZ/mU+tDMAucNXUyLxbQPw7B t2jdQBbccqNjTb5VLdBPWAut5/81t3k/eD1SGaED5LHHO9GB8DelRPq354qZYStC3OzA kRJO8xan2rzuKQMbSh5FCdbXO4AsVxUhlNyH+Z2eLQrmokHpm+J1RhxCVxSWAiNm7RNG 0K3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HrAlUKKuY1d0wEk+nPxoZe2Q03+rymbSQiAGL5hDwyM=; b=Cy091qwMifQrfUVXbMyCYuSPCDzcWsjZWQZ7qrYKYa1akI/tDQ20WZbsmP3p9MMI+r jaDv3Ww7RgIHE2IYUnAzLG/TuQg+/9Q2SrdgGYfpHwVNkGt7YQQo7KOmegXlY9AZ2q4M J+DQlD0CIsY+aaa9EKw/deKxedDzCGVM64SVgcDQ98mt5d03aTFHSX8XvzNIFiOXiyZH Yb+zmlebI/tcCBDSoF9BnqHSToRvksdiDuwVuNRSMxHPpOEZGmbSKrdXC0q36T+OJlFr csXPQyk/YZzMNPK/+3N7tZ1WVetJBoS3p5pydlDbAJjHGNcyOtjZY8ToP7iJV9WhWAWa ubVw== X-Gm-Message-State: ALQs6tABwAiBEGnDHYATfLjP3fFcte6/bNOniyrcDKV7zLeZSBznqGMU 0Bw5lHM46CqxANQ4cY3Q80iJbJQ09viFqa+xR5K1rA== X-Google-Smtp-Source: AB8JxZp7KYsvMc/1/wWoW4mEG4NMW9US3PoU38wIvRJ6dlAG4dFYKR5jwGl3nC+RTlfctPIyaeVgtwvnVoQ1AYZ4dgA= X-Received: by 2002:adf:9162:: with SMTP id j89-v6mr12203543wrj.196.1525196010677; Tue, 01 May 2018 10:33:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.227 with HTTP; Tue, 1 May 2018 10:33:30 -0700 (PDT) In-Reply-To: <6d25230b-aafe-e985-7e0f-f8bd3acfb800@joelhalpern.com> References: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> <6d25230b-aafe-e985-7e0f-f8bd3acfb800@joelhalpern.com> From: Tom Herbert Date: Tue, 1 May 2018 10:33:30 -0700 Message-ID: To: "Joel M. Halpern" Cc: Tom Herbert , ila@ietf.org, 5GANGIP <5gangip@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 17:33:42 -0000 On Tue, May 1, 2018 at 10:22 AM, Joel M. Halpern wrote: > I am not sure I follow. > If I am reading you right, you suggest that dropping cache usage during a > DOS attack is a useful feature. No, that's not what I am saying. The DOS attack is on the cache in an attempt to make every packet, including legitimate ones, take a cache miss. This can be done by downstream devices flooding the cache node where each packet contains a randomized address in the identifier locator domain. In the case of ILA the packets are forwarded on the cache miss and will be dropped if they are being sent to bogus addresses (no route at ILA-R) packets that have routes are forwarded as normal. > If the system is engineered to operate well using local caches in the ILA, > then dropping cache usage would seem to result in a DOS attack on the ILA-R > infrastructure as it will have to handle a sustained packet load much higher > than its design target. > Yes, the network needs to be properly provisioned (although these are basically routers that would have to be in the path anyway). As I said, if you're assuming that caches will always have some hit rate that is the opening for a DOS attack. Tom > Yours, > Joel > > > On 5/1/18 1:16 PM, Tom Herbert wrote: >> >> On Tue, May 1, 2018 at 9:58 AM, Joel M. Halpern >> wrote: >>> >>> If you do not use caches in your ILA-Ns (and yes, I understand your >>> reasoning for not doing so), then you are constructing an overlay >>> network. >>> One of the arguments I was given for using ILA was to enable direct >>> forwarding of packets effectively without needing to have routing track >>> the >>> moving entities. Without caches, you are pushing all the traffic through >>> fewer entities. And you seem to be either using a lot of ILA-R with >>> concomitant information distribution or few ILA-R restricting the >>> information distribution problem but instead having traffic concentration >>> problems. >>> >>> I understood from your earlier presentation that the ILA-r using the >>> packet >>> as a signal was to avoid dropping the first packet, and as a side-effect >>> not >>> needing a separate query message. >>> Now you seem to be saying that your think it important to support not >>> having >>> caches in the ILA-Ns, which is a VERY different trade-off. >>> >> Joel, >> >> I think you've misunderstood my position. Caches are _very_ important >> to eliminate the cost triangular routing (latency, average path load). >> This reduces latency and reduces average load on ILA-Rs. But, and this >> is the critical part, caches are only an _optimization_ in ILA. That >> means if the cache is rendered ineffective (like by a well crafted DOS >> attack) then the only effect is that the optimization is loss (i.e. >> greater latency due to triangular router)-- this is quantitively the >> worst effect of the attack on an ILA cache. This can be contrasted >> that to LISP where the worst case effects of a DOS attack on the cache >> is loss of service for users (infinite latency since packets can be >> dropped or indefinitely blocked on a cache miss). >> >> Tom >> >>> Yours, >>> Joel >>> >>> >>> On 5/1/18 12:37 PM, Tom Herbert wrote: >>>> >>>> >>>> On Tue, May 1, 2018 at 9:10 AM, Joel M. Halpern >>>> wrote: >>>>> >>>>> >>>>> Three reactions, all personal opinion (in case someone thinks my having >>>>> helped chair the BoF is in any way relevant; it isn't): >>>>> >>>>> 1) If ILA-Ns do not have caches, the ILA-Rs will become hot-spots in >>>>> the >>>>> network. Yes, you have provision for multiple of them sharing load. >>>>> However, if that sharing gets to be a significant percentage of teh >>>>> routers >>>>> in the network, then there is no point in having bothered with ILA, you >>>>> are >>>>> just routing on the SIR. >>>>> >>>> Joel, >>>> >>>> If you provision a network (or any system really) based on an >>>> assumption that caches will always attain some hit rate this is a >>>> fundamental mistake. One of the goals of a DOS attack would be to >>>> drive the hit rate to zero in which case someone will be in a world of >>>> hurt. Caches and DOS are a hard mix to contend with in nearly any >>>> context, that's why it's much better to view caches as an optimization >>>> rather than a requirement. They can be used to alleviate load, but >>>> that cannot be relied upon. >>>> >>>> I would also point out that caches only make sense as internal devices >>>> for intra domain communications. This does not make sense for edge >>>> routers that would need to create a working set cache for any >>>> aribtrary load of traffic from the Internet. >>>> >>>>> 2) As far as I can tell, when some ILA-N have caches, the ILA-R have no >>>>> way >>>>> of knowing whether the ILA-N have caches or not. I can understand what >>>>> happens if all ILA-N in a network have the same cache state (either >>>>> they >>>>> all >>>>> have caches or they all do not have caches). But I do not know what >>>>> behavior you expect of an ILA-R if the ILA-N are not uniform. Given the >>>>> hot-spot issue above, I think you need to really explain why ILA-N >>>>> would >>>>> not >>>>> ahve caches. >>>>> >>>> ILA-Rs and ILA-Ns communicate via ILAMP protocol. That can include >>>> capabilities description. >>>> >>>>> 3 - Minor) Your usage of "sharding" seems odd. You are simply dividing >>>>> the >>>>> domain into address blocks, and distributing responsibility for those >>>>> blocks >>>>> separately. In other contexts, sharding seems to be used more >>>>> generally >>>>> for >>>>> having subcollections of the data which can be moved around. >>>>> >>>> Sharding is a database term that describes partitioning of the >>>> database into smaller chunks for manageablibilty. That is what is >>>> happening here (literally in the implementation since we are use a >>>> database backend). >>>> >>>> Tom >>>> >>> > From nobody Tue May 1 10:42:12 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B9412E8D8 for ; Tue, 1 May 2018 10:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.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 mPCsXYNkmQYW for ; Tue, 1 May 2018 10:42:09 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 AC57312E8D3 for ; Tue, 1 May 2018 10:42:08 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id a67so11156697wmf.3 for ; Tue, 01 May 2018 10:42:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4LhqTyNArP25VUxVjib5mPxzI6yRiAR1RZWt9WIY7bI=; b=m9nI3mYN2jJxfdQbEM2S3uDYF2wPeHUtSmxgChh6j0mIkFS3N2UFphruWI1H5kmndy 8+4SRketXfq10FZm5aOH6fZ1M/30CLNnR4y5ebJMKL5h1mRNlgrnqUbwM/m4oQPpLdRL 8R/VV5YyiEd7PTSXWTsAfCOkVbOI+Me37VJ47GVL2aT90YluKxz2LI+zA3lznXt8085q TrvZ+uSDIkgeLOsdsbUH4/AYg3V303iEwEtZ/y3RTzVJDNV1zjbWBSaC/U/VLjI0ziQ5 QZQmWU9Hyuj+LxMTDcw4V56IB3pGcedN4ySCOfjyovmjKoyGCKdlkTmtgjc1p1Cl3RID 0+ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=4LhqTyNArP25VUxVjib5mPxzI6yRiAR1RZWt9WIY7bI=; b=ja9sAWGPMGSRD44qza2BpQ5Sns2NlYnN668fw0+GNJpM6J6+nuOPkNCW8GkcP0jwzO yUb/ej4+5g/4klYFDcZqAT1+IUa469gk5zUSZk+aA68ZSYdiO+TbceQ3R1Eq2BLKOxEc ++TqGyb3SBkP8+CYZ0+0N/68pMhwIB4UD7+5kown+8D9AVSStZwc5ME0dDBelGdObsOu US2XzZUCxMF2ylVOEIYR1/Qj3ffz+bX2fvdQHAK+wF9689x/scDnVCVptagCfw80QCoB 9XF9/MVgjT+N8e6qYWXO7oyePUZzGwZNa7R5dgrMTtynjI+CydxfRpjps0hpbwceqMET Mj/g== X-Gm-Message-State: ALQs6tDfZYkEpTwwlWrH6Dba5jdE8GaXDrv58z5Akr4V7JQ1qjumpPzd 74ILKkhnX1UNTM67FSgiIPS/V/LXfKgXid5Y81uqbw== X-Google-Smtp-Source: AB8JxZp0grObt57Q4qy0zkkdat01jLD0pyS6wStwiZ6bqgqa62fHU5aeMOCUWKJ5VQxLtN3Wm1spCUJjsvPv/qD8vyc= X-Received: by 10.28.128.69 with SMTP id b66mr9717442wmd.108.1525196527073; Tue, 01 May 2018 10:42:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.227 with HTTP; Tue, 1 May 2018 10:42:06 -0700 (PDT) In-Reply-To: <10822D91-7DCB-40F8-8A8B-10B485F9F507@gmail.com> References: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> <10822D91-7DCB-40F8-8A8B-10B485F9F507@gmail.com> From: Tom Herbert Date: Tue, 1 May 2018 10:42:06 -0700 Message-ID: To: Dino Farinacci Cc: Tom Herbert , "Joel M. Halpern" , ila@ietf.org, 5GANGIP <5gangip@ietf.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 17:42:12 -0000 On Tue, May 1, 2018 at 10:31 AM, Dino Farinacci wrote= : > >> I think you've misunderstood my position. Caches are _very_ important >> to eliminate the cost triangular routing (latency, average path load). >> This reduces latency and reduces average load on ILA-Rs. But, and this >> is the critical part, caches are only an _optimization_ in ILA. That >> means if the cache is rendered ineffective (like by a well crafted DOS >> attack) then the only effect is that the optimization is loss (i.e. >> greater latency due to triangular router)-- this is quantitively the >> worst effect of the attack on an ILA cache. This can be contrasted >> that to LISP where the worst case effects of a DOS attack on the cache >> is loss of service for users (infinite latency since packets can be >> dropped or indefinitely blocked on a cache miss). > > Note in LISP, most of the time, prefixes are put in the cache. For ILA it= s mostly /128 host routes. And note, when an LISP ITR gets a Map-Reply, it = can elect to put coarser EID-prefixes in the cache versus more specifics. O= r, not elect to put anything in the cache and forward to PETRs (the same as= your ILA-R routers) at the expense of suboptimal paths. > > There are many options in LISP prevent DoS attack cache attacks. I don=E2= =80=99t think that is true when caches are used in ILA. > That is correct. For ILA I would like to have a normative description of how the protocol is intended to deal with DOS attack. IMO, when someone asks what the DOS mitigation of a protocol is the answer should be clear and concise. Tom > Dino > >> >> Tom >> >>> Yours, >>> Joel >>> >>> >>> On 5/1/18 12:37 PM, Tom Herbert wrote: >>>> >>>> On Tue, May 1, 2018 at 9:10 AM, Joel M. Halpern >>>> wrote: >>>>> >>>>> Three reactions, all personal opinion (in case someone thinks my havi= ng >>>>> helped chair the BoF is in any way relevant; it isn't): >>>>> >>>>> 1) If ILA-Ns do not have caches, the ILA-Rs will become hot-spots in = the >>>>> network. Yes, you have provision for multiple of them sharing load. >>>>> However, if that sharing gets to be a significant percentage of teh >>>>> routers >>>>> in the network, then there is no point in having bothered with ILA, y= ou >>>>> are >>>>> just routing on the SIR. >>>>> >>>> Joel, >>>> >>>> If you provision a network (or any system really) based on an >>>> assumption that caches will always attain some hit rate this is a >>>> fundamental mistake. One of the goals of a DOS attack would be to >>>> drive the hit rate to zero in which case someone will be in a world of >>>> hurt. Caches and DOS are a hard mix to contend with in nearly any >>>> context, that's why it's much better to view caches as an optimization >>>> rather than a requirement. They can be used to alleviate load, but >>>> that cannot be relied upon. >>>> >>>> I would also point out that caches only make sense as internal devices >>>> for intra domain communications. This does not make sense for edge >>>> routers that would need to create a working set cache for any >>>> aribtrary load of traffic from the Internet. >>>> >>>>> 2) As far as I can tell, when some ILA-N have caches, the ILA-R have = no >>>>> way >>>>> of knowing whether the ILA-N have caches or not. I can understand wh= at >>>>> happens if all ILA-N in a network have the same cache state (either t= hey >>>>> all >>>>> have caches or they all do not have caches). But I do not know what >>>>> behavior you expect of an ILA-R if the ILA-N are not uniform. Given t= he >>>>> hot-spot issue above, I think you need to really explain why ILA-N wo= uld >>>>> not >>>>> ahve caches. >>>>> >>>> ILA-Rs and ILA-Ns communicate via ILAMP protocol. That can include >>>> capabilities description. >>>> >>>>> 3 - Minor) Your usage of "sharding" seems odd. You are simply dividi= ng >>>>> the >>>>> domain into address blocks, and distributing responsibility for those >>>>> blocks >>>>> separately. In other contexts, sharding seems to be used more genera= lly >>>>> for >>>>> having subcollections of the data which can be moved around. >>>>> >>>> Sharding is a database term that describes partitioning of the >>>> database into smaller chunks for manageablibilty. That is what is >>>> happening here (literally in the implementation since we are use a >>>> database backend). >>>> >>>> Tom >>>> >>> >> >> _______________________________________________ >> 5gangip mailing list >> 5gangip@ietf.org >> https://www.ietf.org/mailman/listinfo/5gangip > From nobody Tue May 1 10:56:06 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F99B12E8D7; Tue, 1 May 2018 10:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 olaj7mfn-mq4; Tue, 1 May 2018 10:55:57 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 4D37A12E8D6; Tue, 1 May 2018 10:55:57 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id d3-v6so15377364qtp.11; Tue, 01 May 2018 10:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=R4KZhOK+y57vP2MVmKC70GzuGYbXPzPWjkb3t3ksiII=; b=o994o4BPyditgQJQ/UbbYt6p7LSOa6Bcvcq36XivMWn3EVlmQEaCP8Cqq+1u0spmJp juwDYv3zdXnr2H+nCQCbUf0gAj0N0FiPGctivc2wHveijzpFYg+C5KC56L04I7ZQDfOe +eC93YN1EST/tQdZRURvqepQeyw5t4z4BpcPAWPvuol2n8jfe7okiDq18wntAQFLMw/O LHJmXuamGwwgvVB1KEpQO361++Dhz9OZHiTDVorbpFtyGmzT20Gn9TikCRCLOp2pMo+O H4Q4Tk9j9BsPglAx09nXcJ8zibIoXBg7lCEjQwsTyq9Kp2UzuG8k3FAE+KMCRGnbwyeT fFPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=R4KZhOK+y57vP2MVmKC70GzuGYbXPzPWjkb3t3ksiII=; b=t+Pd8tnw8Uaas8TCB4Q0oLAFIf3AEf8OFvwIsJXhWSa+EKP+0KG62SQTAu+SfRFhT/ 8QukfiEjmnaLpUKoZJtplvBeIzMFHQuXCBkrOfTxMuApHY3ypqURavlxAMRcS/J/NZss DFVDJrI6L+Ye0hWDgX0rq514ecta0d0Wg1kVok5uC/+dKEH2gZg1rxhxB/y8GCENWygs ceRN93ySMKdS5gCR6i4D6Vs6/oj7sQWMg3HwRffBjXVyLnG55jB0U9CWRQ9+Nfe1vMKu P/5MU7H43lWrpVyxDZwwnkrzwKIgtsKMnfczLDEZjEzD8WsVa4Knka0p8yrYv8CoX45u 60+Q== X-Gm-Message-State: ALQs6tCAQfQ75UVohpwTemLcmTuhIyj+yoE4LOcRBhF2l6FiNJrULMSR 8tX6JU6ud6GMZKpyyJ8fW3Y= X-Google-Smtp-Source: AB8JxZpGFVxhchhP4ib6zMb7lKM0tQmm7bYQXk7wn0rP6n1CQ/Kam9v3XKpsMVjXByecA6hz7E0uKA== X-Received: by 2002:ac8:354f:: with SMTP id z15-v6mr14414783qtb.295.1525197356471; Tue, 01 May 2018 10:55:56 -0700 (PDT) Received: from [10.207.57.221] ([184.169.45.4]) by smtp.gmail.com with ESMTPSA id q10-v6sm9036790qtk.7.2018.05.01.10.55.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 May 2018 10:55:55 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Dino Farinacci In-Reply-To: Date: Tue, 1 May 2018 10:54:48 -0700 Cc: Tom Herbert , "Joel M. Halpern" , ila@ietf.org, 5GANGIP <5gangip@ietf.org> Content-Transfer-Encoding: 7bit Message-Id: References: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> <10822D91-7DCB-40F8-8A8B-10B485F9F507@gmail.com> To: Tom Herbert X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 17:55:59 -0000 > That is correct. For ILA I would like to have a normative description > of how the protocol is intended to deal with DOS attack. IMO, when > someone asks what the DOS mitigation of a protocol is the answer > should be clear and concise. And true. ;-) Dino From nobody Tue May 1 11:44:32 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5395012EA76 for ; Tue, 1 May 2018 11:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.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 OiqRAUs94sKR for ; Tue, 1 May 2018 11:44:23 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 3CEDD12E9D9 for ; Tue, 1 May 2018 11:44:23 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id a67so11382611wmf.3 for ; Tue, 01 May 2018 11:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/fWLTZYI1/Yh2ECBGuBfBvIbnlm/ixqpJHOi/3KT+Og=; b=IKIJYZpKkwTd/e+1+44RLvZjE0YcZ3MjVPH9WIrUNNWTYQUA+E3iVVPHtaI1uoGHGy SJnDoPBknIsVuUYjU79D/Q+vE4dV9rW12f31tj6hScB8IXfGw6/tLzTdMSVa8+tvL1fV eppeJWDclAXCaocEqIYS+cN5IMTNINLvmNJGstQqef6BqOLvVQXOkACz1Pg4e3seg3r/ 2RHFp7bviE6L6dHyXVXI32DUKT3befHfBJKh6WC1s3N64R527jIakXg7GG+xN/NARQpg 16YjKUge/rqfQP4lF8KfOEBMB7crwFi923ojUuGQGuvXrwh0rispBP5iP/h/nlGpL/2e qkXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/fWLTZYI1/Yh2ECBGuBfBvIbnlm/ixqpJHOi/3KT+Og=; b=iqt7Fts0HYu0LiegIGoF3Fi06e5W4kgOHjPIctNBEXDwCH7qsmizSXBgqnXopIDvr3 voh63XuwkuTQMfsN5cbHyIW8cCukUNv8uavNJ9j8jfgo4Ar6avNZBL0y9Jl20VX6T8ka AGd7CHE6LOFWpt2dRw30Xy1F9+Vtk1/H7CvxMvYfAZygjwOCet5JDAQp0tcfWUOHpedb pGSDxA42+ddqwaYTou18Pu+NYLtecxn67tVlope2lQbyUMjGL1YdQYXwLxRRyevPhe4t FPOssYfJHJdfWcO6wyVLgO1ISYMVwNuoCHoaz0o0c84EvIK+stEwwHVkdpftHwrREFsm WeDA== X-Gm-Message-State: ALQs6tCI0xOiKdmh7l5WWLmi1/4zb6It3124LTR3qjdtb4tHxK2JlS++ 6gbLecvq0RHimiS/Toq6roiKcWNaPjaswCMo1bUXXg== X-Google-Smtp-Source: AB8JxZoNNNmFhaV8CQImUNra5an+kMPBeHq5h9yvU4g/K7gP0bIIoyo8/514Xprctfk9xLRxDjHhH8TBtLRu1p0824c= X-Received: by 10.28.124.10 with SMTP id x10mr9581415wmc.59.1525200261645; Tue, 01 May 2018 11:44:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.227 with HTTP; Tue, 1 May 2018 11:44:21 -0700 (PDT) In-Reply-To: <04561B6C-E280-4EE0-B789-3880C8B69A08@gmail.com> References: <04561B6C-E280-4EE0-B789-3880C8B69A08@gmail.com> From: Tom Herbert Date: Tue, 1 May 2018 11:44:21 -0700 Message-ID: To: Dino Farinacci Cc: Tom Herbert , ila@ietf.org, Behcet Sarikaya , Christian Huitema , Dirk.von-Hugo@telekom.de, 5GANGIP <5gangip@ietf.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 18:44:28 -0000 On Tue, May 1, 2018 at 10:25 AM, Dino Farinacci wrote= : >> I will try to answer your questions in as much detail as possible. > > Thanks for more details. > >> Here are the example cases that illustrate operation. >> >> Case #1: A network has a single SIR prefix and one ILA-R and some >> number of ILA-Ns. The ILA-Ns do not have a map cache and are only used >> for SIR to ILA transformation. >> >> The ILA-R advertises the SIR prefix in normal IP routing. It is the >> router for the SIR prefix. Packets destined to an address with the SIR >> prefix are thus routed the to ILA-R. Mapping entries are realized as >> hosts routes in the ILA-R where the destination host is composed of >> the SIR prefix and identifier. When an ILA-R receives a packet it > > What do you mean by realized. Are host routes storedin ILR-R routers via = a push protocol like ILAMP? You are going to push all host routes for all I= LA-N nodes in the Internet? > That are host routes in the local ILA-R routing table. >> * Note that none of these cases so far require a mapping cache. These >> work for all packets regardless of the source. The sender may be local >> to the network, or may be a host on the Internet. > > That is not clear for case #1. Answer my above question first. > >> Case 4: Map caches are enabled on ILA-Ns. >> >> The map cache is implemented as host routes in an ILA-N similar to >> ILA-R routes. When a packet is sent by a downstream device (e.g. a UE) >> it traverses an ILA-N. The ILA-N performs a route lookup on the >> packet. If an ILA route is found (a map cache hit) an ILA >> transformation is performed an the packet is forwarded directly >> towards the destination. If there is no ILA route (map cache miss), >> then another route is found possibly the default route (remember these >> are just normal route lookups). The packet is forward per the route >> and since it still has a SIR prefix in the destination address it will >> be forwarded to an ILA-R as described in case #1. The ILA-N does not >> send a mapping request and does not remember the destination, it just >> forwards without incurring any additional delay. > > Okay, so the scale of the underlay depends on the number of SIR prefixes = injected into the routing system. When using sharding, it could be a lot. T= his model is kinda a hybrid overlay/underlay where the underlay needs to ta= ke part in make packet forwarding work. So be it. Yes. It's already common technique with things like load balanceres that on routing to distribute packets. > > Dino > > _______________________________________________ > 5gangip mailing list > 5gangip@ietf.org > https://www.ietf.org/mailman/listinfo/5gangip From nobody Tue May 1 12:02:47 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2D3126B6D; Tue, 1 May 2018 12:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 bHHw24u_HMO4; Tue, 1 May 2018 12:02:36 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 B1E9012EA56; Tue, 1 May 2018 12:02:33 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id w41IuIBx038413; Tue, 1 May 2018 15:02:25 -0400 Received: from flpd657.enaf.ffdc.sbc.com (sbcsmtp9.sbc.com [144.160.128.153]) by m0049297.ppops.net-00191d01. with ESMTP id 2hpu9q4vm5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 01 May 2018 15:02:25 -0400 Received: from enaf.ffdc.sbc.com (localhost [127.0.0.1]) by flpd657.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id w41J2OJj040871; Tue, 1 May 2018 12:02:24 -0700 Received: from zlp25946.vci.att.com (zlp25946.vci.att.com [135.213.92.138]) by flpd657.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id w41J2Ji8040788; Tue, 1 May 2018 12:02:19 -0700 Received: from zlp25946.vci.att.com (zlp25946.vci.att.com [127.0.0.1]) by zlp25946.vci.att.com (Service) with ESMTP id 6F2DC412C920; Tue, 1 May 2018 19:02:19 +0000 (GMT) Received: from CAFRFD1MSGHUBAF.ITServices.sbc.com (unknown [130.4.169.177]) by zlp25946.vci.att.com (Service) with ESMTPS id 4D139410F442; Tue, 1 May 2018 19:02:19 +0000 (GMT) Received: from CAFRFD1MSGUSRJI.ITServices.sbc.com ([169.254.8.94]) by CAFRFD1MSGHUBAF.ITServices.sbc.com ([130.4.169.177]) with mapi id 14.03.0389.001; Tue, 1 May 2018 12:02:18 -0700 From: "FIGURELLE, TERRY F" To: Tom Herbert , Dino Farinacci CC: Tom Herbert , "ila@ietf.org" , "Behcet Sarikaya" , Christian Huitema , "Dirk.von-Hugo@telekom.de" , 5GANGIP <5gangip@ietf.org> Thread-Topic: [5gangip] ILA forwaring [Was Re: Problem Statement] Thread-Index: AQHT4XxyJDf7s/QJxkyPjuDn5txRjKQbOoHw Date: Tue, 1 May 2018 19:02:18 +0000 Message-ID: <1AFE10CF28AE8B4C9663445736B8034D3822C614@CAFRFD1MSGUSRJI.ITServices.sbc.com> References: <04561B6C-E280-4EE0-B789-3880C8B69A08@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.2.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-01_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805010183 Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 19:02:39 -0000 You can't push routes to the Internet. ISP chose what they accept and whom = they accept it from but typically nothing smaller than a /17 is allowed. Ca= n we keep it real please! -----Original Message----- From: 5gangip <5gangip-bounces@ietf.org> On Behalf Of Tom Herbert Sent: Tuesday, May 01, 2018 11:44 AM To: Dino Farinacci Cc: Tom Herbert ; ila@ietf.org; Behcet Sarikaya ; Christian Huitema ; Dirk.von-Hugo@telek= om.de; 5GANGIP <5gangip@ietf.org> Subject: Re: [5gangip] ILA forwaring [Was Re: Problem Statement] On Tue, May 1, 2018 at 10:25 AM, Dino Farinacci wrote= : >> I will try to answer your questions in as much detail as possible. > > Thanks for more details. > >> Here are the example cases that illustrate operation. >> >> Case #1: A network has a single SIR prefix and one ILA-R and some=20 >> number of ILA-Ns. The ILA-Ns do not have a map cache and are only=20 >> used for SIR to ILA transformation. >> >> The ILA-R advertises the SIR prefix in normal IP routing. It is the=20 >> router for the SIR prefix. Packets destined to an address with the=20 >> SIR prefix are thus routed the to ILA-R. Mapping entries are realized=20 >> as hosts routes in the ILA-R where the destination host is composed=20 >> of the SIR prefix and identifier. When an ILA-R receives a packet it > > What do you mean by realized. Are host routes storedin ILR-R routers via = a push protocol like ILAMP? You are going to push all host routes for all I= LA-N nodes in the Internet? > That are host routes in the local ILA-R routing table. >> * Note that none of these cases so far require a mapping cache. These=20 >> work for all packets regardless of the source. The sender may be=20 >> local to the network, or may be a host on the Internet. > > That is not clear for case #1. Answer my above question first. > >> Case 4: Map caches are enabled on ILA-Ns. >> >> The map cache is implemented as host routes in an ILA-N similar to=20 >> ILA-R routes. When a packet is sent by a downstream device (e.g. a=20 >> UE) it traverses an ILA-N. The ILA-N performs a route lookup on the=20 >> packet. If an ILA route is found (a map cache hit) an ILA=20 >> transformation is performed an the packet is forwarded directly=20 >> towards the destination. If there is no ILA route (map cache miss),=20 >> then another route is found possibly the default route (remember=20 >> these are just normal route lookups). The packet is forward per the=20 >> route and since it still has a SIR prefix in the destination address=20 >> it will be forwarded to an ILA-R as described in case #1. The ILA-N=20 >> does not send a mapping request and does not remember the=20 >> destination, it just forwards without incurring any additional delay. > > Okay, so the scale of the underlay depends on the number of SIR prefixes = injected into the routing system. When using sharding, it could be a lot. T= his model is kinda a hybrid overlay/underlay where the underlay needs to ta= ke part in make packet forwarding work. So be it. Yes. It's already common technique with things like load balanceres that on= routing to distribute packets. > > Dino > > _______________________________________________ > 5gangip mailing list > 5gangip@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail > man_listinfo_5gangip&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NT= xwl > 2paJIf4zw&m=3Drl1QvnuE017HX7WwFbX_YthGHFRrZVDpRcgsmaQkUGE&s=3DNnvGYrVGFzM= 8 > rpmzW7gypXA6_ZW6h0Bh0YcJdXpE-AI&e=3D _______________________________________________ 5gangip mailing list 5gangip@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_5gangip&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl2p= aJIf4zw&m=3Drl1QvnuE017HX7WwFbX_YthGHFRrZVDpRcgsmaQkUGE&s=3DNnvGYrVGFzM8rpm= zW7gypXA6_ZW6h0Bh0YcJdXpE-AI&e=3D=20 From nobody Tue May 1 12:13:20 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B1F126DC2 for ; Tue, 1 May 2018 12:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.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 4HUMsvNHc0Nk for ; Tue, 1 May 2018 12:13:12 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 135AD1201F2 for ; Tue, 1 May 2018 12:13:11 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id a67so11486780wmf.3 for ; Tue, 01 May 2018 12:13:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=MWiBWmw9+hPuMOpnYUbPtLJ0vdctc1L689jjCoZ8pwQ=; b=mPZWC8ph4JSFnLXLwjUwZdJRjdtOGB8QSdQ5n9xOQqlEsLx8DyAmD7ekardRGPZhth KvnjIYmC5qQuy5MBV92NIxlgdwhsKju1wdvsd+tmqQrsPjwvRaJDxZ+iF1prOX+ldnQE xIlxUDHCs73wE4a91tpUX59j7bdvNsmzQgaXdpu25OWuQ50eNhQ6L8Qmw2WcD+0afoJr ns+TRAYBrr+S2fvv3jitUO0enNQhpeswJz4m5PDzunoBPYt1OYOt4gni7r1GIuOCgRDS wAzBOYEIWOgdSgwQYjdxM5EjzTb50o0lY1n9XDOYYdIhE9++cLOfG4+SY/wpn+MVue1w TafA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=MWiBWmw9+hPuMOpnYUbPtLJ0vdctc1L689jjCoZ8pwQ=; b=gcn7HnPdS8qICAYtvIPk+k4XDl/jikuffSd5Ri66UMTeeT4wAXje9qwJGWS/ValdGP nJejvTjh8AUXTpy/Ipb5UeoPf7Gm3szsvgM6gLVPdbIiMOIurnmqnT1PGOW50yQVOIUP whk3AwfABBi36QbX/4mwlHnQnpSa+Plcu4L0P8qQmNQkyo9JOi7Ut/RDwMSDJ+neBbin J/DOXz5UH8Qs1j6+J+sP77CEe8WkqkUNz4JmeL6fuCeOyP2X7RcOgqTp5aBVfo/xDi7L immsY+yPjMjwaCb3c2DSCWmFrGiDnceg2dpf2dX+U94NX2OB975aPffUdduw20WkJXgB Fepw== X-Gm-Message-State: ALQs6tC0w6xIImlOxN0+Sz0ehnEQUlFtIPinzGgWyn/f5Z7BojBBmLGO WRilv/DQOMCmHJ5ImEvGHsefelieTDZEegKXrvzk2Q== X-Google-Smtp-Source: AB8JxZqTMMgCiy6e1tqucq7zGf57AnyelmcZ3HNa0nk857C0+AREKk2DRXBTShZjdqwOJp0oh6ROm3vVjxySBfJ2tHw= X-Received: by 10.28.128.69 with SMTP id b66mr9861675wmd.108.1525201989357; Tue, 01 May 2018 12:13:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.227 with HTTP; Tue, 1 May 2018 12:13:08 -0700 (PDT) In-Reply-To: <1AFE10CF28AE8B4C9663445736B8034D3822C614@CAFRFD1MSGUSRJI.ITServices.sbc.com> References: <04561B6C-E280-4EE0-B789-3880C8B69A08@gmail.com> <1AFE10CF28AE8B4C9663445736B8034D3822C614@CAFRFD1MSGUSRJI.ITServices.sbc.com> From: Tom Herbert Date: Tue, 1 May 2018 12:13:08 -0700 Message-ID: To: "FIGURELLE, TERRY F" Cc: Dino Farinacci , Tom Herbert , "ila@ietf.org" , Behcet Sarikaya , Christian Huitema , "Dirk.von-Hugo@telekom.de" , 5GANGIP <5gangip@ietf.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 19:13:15 -0000 On Tue, May 1, 2018 at 12:02 PM, FIGURELLE, TERRY F wrote: > You can't push routes to the Internet. ISP chose what they accept and who= m they accept it from but typically nothing smaller than a /17 is allowed. = Can we keep it real please! > We are not pushing route to the Internet. ILA in internal to a site. > -----Original Message----- > From: 5gangip <5gangip-bounces@ietf.org> On Behalf Of Tom Herbert > Sent: Tuesday, May 01, 2018 11:44 AM > To: Dino Farinacci > Cc: Tom Herbert ; ila@ietf.org; Behcet Sarikaya ; Christian Huitema ; Dirk.von-Hugo@tel= ekom.de; 5GANGIP <5gangip@ietf.org> > Subject: Re: [5gangip] ILA forwaring [Was Re: Problem Statement] > > On Tue, May 1, 2018 at 10:25 AM, Dino Farinacci wro= te: >>> I will try to answer your questions in as much detail as possible. >> >> Thanks for more details. >> >>> Here are the example cases that illustrate operation. >>> >>> Case #1: A network has a single SIR prefix and one ILA-R and some >>> number of ILA-Ns. The ILA-Ns do not have a map cache and are only >>> used for SIR to ILA transformation. >>> >>> The ILA-R advertises the SIR prefix in normal IP routing. It is the >>> router for the SIR prefix. Packets destined to an address with the >>> SIR prefix are thus routed the to ILA-R. Mapping entries are realized >>> as hosts routes in the ILA-R where the destination host is composed >>> of the SIR prefix and identifier. When an ILA-R receives a packet it >> >> What do you mean by realized. Are host routes storedin ILR-R routers via= a push protocol like ILAMP? You are going to push all host routes for all = ILA-N nodes in the Internet? >> > That are host routes in the local ILA-R routing table. > >>> * Note that none of these cases so far require a mapping cache. These >>> work for all packets regardless of the source. The sender may be >>> local to the network, or may be a host on the Internet. >> >> That is not clear for case #1. Answer my above question first. >> >>> Case 4: Map caches are enabled on ILA-Ns. >>> >>> The map cache is implemented as host routes in an ILA-N similar to >>> ILA-R routes. When a packet is sent by a downstream device (e.g. a >>> UE) it traverses an ILA-N. The ILA-N performs a route lookup on the >>> packet. If an ILA route is found (a map cache hit) an ILA >>> transformation is performed an the packet is forwarded directly >>> towards the destination. If there is no ILA route (map cache miss), >>> then another route is found possibly the default route (remember >>> these are just normal route lookups). The packet is forward per the >>> route and since it still has a SIR prefix in the destination address >>> it will be forwarded to an ILA-R as described in case #1. The ILA-N >>> does not send a mapping request and does not remember the >>> destination, it just forwards without incurring any additional delay. >> >> Okay, so the scale of the underlay depends on the number of SIR prefixes= injected into the routing system. When using sharding, it could be a lot. = This model is kinda a hybrid overlay/underlay where the underlay needs to t= ake part in make packet forwarding work. So be it. > > Yes. It's already common technique with things like load balanceres that = on routing to distribute packets. > >> >> Dino >> >> _______________________________________________ >> 5gangip mailing list >> 5gangip@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail >> man_listinfo_5gangip&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DtO_sNxa2N= Txwl >> 2paJIf4zw&m=3Drl1QvnuE017HX7WwFbX_YthGHFRrZVDpRcgsmaQkUGE&s=3DNnvGYrVGFz= M8 >> rpmzW7gypXA6_ZW6h0Bh0YcJdXpE-AI&e=3D > > _______________________________________________ > 5gangip mailing list > 5gangip@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_5gangip&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl= 2paJIf4zw&m=3Drl1QvnuE017HX7WwFbX_YthGHFRrZVDpRcgsmaQkUGE&s=3DNnvGYrVGFzM8r= pmzW7gypXA6_ZW6h0Bh0YcJdXpE-AI&e=3D From nobody Tue May 1 13:56:22 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB19D126D0C; Tue, 1 May 2018 13:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 6m32Cbl8Ut7l; Tue, 1 May 2018 13:56:12 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 B83E21200B9; Tue, 1 May 2018 13:56:12 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id 186-v6so14540639itu.0; Tue, 01 May 2018 13:56:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:from:date:message-id:subject:to:cc; bh=4hSBIKjvGIN+qYXMwRn6QiuEblN89CuW2V2Gs9/gYJc=; b=cxSq9UIbnm6Skug1coDUkmNji7aHPnVmxDbCHPgI0r8YBg9s4D3oX6leEZnVjvSCYk 2TzF+p/OmLIRCyMFo3G37xVDWtaAeA36WOgQbf1y1Q0+zEYM68CV8SO17AQ186af0/W0 cX/4hO09m86YSsObz/MSRzs3NVqAU6WRODB+IAQ/gNAeMDTp0dk/rRU9nGLduqtcEX5M 9ksPm41Xtf6SEj+NdhrAJyZcnZwzg5I7h3R8+oRfxSDJ+uJDeWHmu0ZkfwcDyE3oiis5 yvFFVJd+Ux6pRh53SNQsJMW/i/2mnjuj0rwp2FeXLknfAqHHakiFP3AIy+/yMXlDfc3w BFWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to:cc; bh=4hSBIKjvGIN+qYXMwRn6QiuEblN89CuW2V2Gs9/gYJc=; b=W4BAvGW61u3D+R2aglgz80JfhiG5ZmjFCAO6IKSBAX9zYiyETrRjzObjdVciasm7jJ g+vgoXMCAE4eD3I7RyGArrz2yWju97e3JtNAXyUvAS1YpcbzvcCm6rYKfz5pPUr8CpGe of72fgyL+vn401PPF0gX/Wp3/Qz1x9w4BIg1MUeVLlXaYRVH/vWMCQPTzGFd0WmmEJC6 cf5+lRaWtk40+zcuIL9vEPjDpKw1WMTSFFNUckeGSbbNBAn3jKFpSB2I0O8Ih58wP2fy nN1XEH4xf6MwA1KGEtuHsTzg+QCPYJwHTL+J2uaTYTkd/oRoAqJXbx4sARuYBOLYePH6 Ko5w== X-Gm-Message-State: ALQs6tA9OJg+f7Am5y7GAc0OtlWInitwjexMfrph0OuYmtl5Qx4Q4BS3 Bv25dwr9Oj4qpOhQD8BNRWpwl/H3OJfHUL4/kaY= X-Google-Smtp-Source: AB8JxZqlu71fivSDCuZNZFWANdT5SevcpmgTnFpNO5Dkr1FAdc7WBFSzY3fapvBBVAYIXu/c9hqg5WAL/hPwVhm1a1Q= X-Received: by 2002:a24:72c5:: with SMTP id x188-v6mr18506599itc.118.1525208171956; Tue, 01 May 2018 13:56:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.192.170.54 with HTTP; Tue, 1 May 2018 13:56:11 -0700 (PDT) Reply-To: sarikaya@ieee.org From: Behcet Sarikaya Date: Tue, 1 May 2018 15:56:11 -0500 Message-ID: To: Tom Herbert Cc: 5GANGIP <5gangip@ietf.org>, ila@ietf.org Content-Type: multipart/alternative; boundary="0000000000004c5179056b2b3349" Archived-At: Subject: Re: [Ila] SIR [was ILA forwarding] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 20:56:15 -0000 --0000000000004c5179056b2b3349 Content-Type: text/plain; charset="UTF-8" Hi Tom, With SIR fixed, I wonder how do you address multi homed UEs in ILA? Maybe you did not need it for VMs because they are not multi homed but UEs definitely have multiple interfaces. ILNP treats it using two different locators but same identifier which seems reasonable. Regards, Behcet --0000000000004c5179056b2b3349 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom,

With SIR fixed, I wonder how do= you address multi homed UEs in ILA?
Maybe you did not need it fo= r VMs because they are not multi homed but UEs definitely have multiple int= erfaces.
ILNP treats it using two different locators but same ide= ntifier which seems reasonable.

Regards,
Behcet=C2=A0


--0000000000004c5179056b2b3349-- From nobody Tue May 1 14:09:57 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF4612E8E7 for ; Tue, 1 May 2018 14:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.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 z8XgB60j-pJa for ; Tue, 1 May 2018 14:09:48 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 B120612EA67 for ; Tue, 1 May 2018 14:09:47 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id i3so20792953wmf.3 for ; Tue, 01 May 2018 14:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=31YLQ1Bu2yyjCDhuzzFA3RdgoRRg4ajQLKXmltkS1Ks=; b=ym7405XnMq0T2qgmrm0UAW4uQSWM3HzI3nyqvdbcWhsrycfUXz24oVwpAuc/YfU9Wk 9gFxFadbEPQYT8vUC1ZQXQH1J0/wZd9RCzn4nyRYWjR3nHeEJ8iQofBlLpABUVN/9dw+ zPGp8mV/co7XumUAyV3VHCcUS9cuS8K3X6cXLJEzSJIAaf+V2PepaYAi3GKPDYF/C/zt uDJbwCOYilW7MUFcwljj8sKExnKr9b3UCsWszEdJo3FxmOUcMjy8KHFNDYpKTSysbJFF pHI32VOvHafV+r1W4Y6EsxIQYJHV/EpAo+lPx1mRZypZgfTpMezJX7ni1EmRH8wjBMbV /C+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=31YLQ1Bu2yyjCDhuzzFA3RdgoRRg4ajQLKXmltkS1Ks=; b=TEHRbj74HFMf2EtQ2dPk4JZIcxf4vpvzFnhSOYejuM25fJRvimKHqnVjUlWIGu3ZSO X+Ip7g094evbQsLrZBSRI7AHDzLUcoDeHkuWlud3+x84r6iio98XEnkRkI9w3ldcF+Yy sFWHNvmY82KcgLaeF7mF+s7pLtLuAnlVBqbeY90vBG1AjBsMVThUF3KBORgkdxdkWQjF PJ2kuiY0BM/HeEnxT7ERESbrmxSkbzAeF8qCUy41ZtRPaAwvQTps1Z/VPnwACuSCTc1c VgJSO8p4IVKUSjKwkMdsyJQdSiNO5vB/iKLTl6aR0G/C8S1zRT8UcKWZj6fvMAnS4Ps5 nWRA== X-Gm-Message-State: ALQs6tDFCu9JWFhphaqDm0U4Vbng4RLeQmWiULRjZKGiNdjWFnW37OSg iqbU9gDEzIyc+c2mlvVYM7iRzqK4ZGoXCGZjERN/ug== X-Google-Smtp-Source: AB8JxZpxn02qM6048JeXuafh/QcBViyLA4+mw60kj8oDod7HRtLSoHwAqahiHinyFDiaZpHyZryilQQvDVIb/EQF5z0= X-Received: by 10.28.208.70 with SMTP id h67mr2452048wmg.80.1525208986117; Tue, 01 May 2018 14:09:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.227 with HTTP; Tue, 1 May 2018 14:09:45 -0700 (PDT) In-Reply-To: References: From: Tom Herbert Date: Tue, 1 May 2018 14:09:45 -0700 Message-ID: To: Behcet Sarikaya Cc: Tom Herbert , 5GANGIP <5gangip@ietf.org>, ila@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ila] [5gangip] SIR [was ILA forwarding] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 21:09:51 -0000 On Tue, May 1, 2018 at 1:56 PM, Behcet Sarikaya wrote: > Hi Tom, > > With SIR fixed, I wonder how do you address multi homed UEs in ILA? > Maybe you did not need it for VMs because they are not multi homed but UEs > definitely have multiple interfaces. That's a tough problem. If both interfaces are in the same ILA domain, then there's no issue it should just work. If they're not then something needs to be done across domains for it to work seamlessly where addresses associated in one domain can be routed in another. > ILNP treats it using two different locators but same identifier which seems > reasonable. > But then locators are exposed to end devices-- privacy problem. > Regards, > Behcet > > > > _______________________________________________ > 5gangip mailing list > 5gangip@ietf.org > https://www.ietf.org/mailman/listinfo/5gangip > From nobody Tue May 1 14:52:05 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 131BD124205; Tue, 1 May 2018 14:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 v_30YB2blLMU; Tue, 1 May 2018 14:51:54 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 80092126DFB; Tue, 1 May 2018 14:51:54 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id o123-v6so17980455lfe.8; Tue, 01 May 2018 14:51:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=s1Y93w2oe2ONsoYuOwKdEBJHUybbAloUHtgnej33ARU=; b=ldvNuZiwRUhhZcZLvv3JHBJyWW+roFQ+8BnAz/TPzKmDmIGiaLfFIua4IVgwumMy05 Loj537hcdJbXt5X1vasbuP3Sh60YaSwZps8Cc8dPpUGHPdGygFxcj+/uOUAk3momaogB UF1loAHCWNB1Tn+YorOJFOZg7KjvdzgWkhy9VRDHwQW/mBF04aarqWRqnkJ2IMFuPDjB h6sVnIH0K20/RGmJbcYM+cvnJePGGu+N5XfIvWlyb78v3kW/kyO35wvacQ+sY1lsKI9K 0+QM9F0ny4fz8hR0e3aIUrDCA5PoIrWgoMQBtXEC6G8ZJREiU1pXOUj+zk0C8x7sDnsW bW7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=s1Y93w2oe2ONsoYuOwKdEBJHUybbAloUHtgnej33ARU=; b=F6Aympyvt5HKhFew/RKjJa197wb9T5jQ8T1CbXW/2/OrJfEcqZMfpfXj1/ZHA40X4J q1tHydLkVYFOvthLKXCL98M1j+wq+Wd/prl5StdWwOiohwdbTDR2VHXAVti5vFkDf4jr uzZOlEpvQO48ccvTX9KiiQ69z004qhLPLdY6xWkDII4ZzLpP4+jOK0+MSl2Plk4kJ4Yg RT6aaw5G2l5zsUqyFU+X5mIEAveMclhf+c/Z6hWt6p5kGjAiMGMNgYkk5kh+HtDq4jmg EBmIx0RCesmdmyKZpyOHb/CD+czt5uYCdpXkNToMf/wF/TPdfhMxDHGcpbgkgI7Eh3c/ t6og== X-Gm-Message-State: ALQs6tBUU9G7CjG1ScFLQZ6zU9Ppbuv8g9S+WuAi5ySZrO13wkXcKJ8f YhBCsIc2zj2V4i9VDTWPpe05ND0roaLk6PvruwI= X-Google-Smtp-Source: AB8JxZpXdwjD8rZq396xr3hHTJt8nP9wvaqnq4aSHF+h/rK6mnHQuHbDCI0N9U9/KtpY+PJwxrpYK5NyzY+6+hHee74= X-Received: by 2002:a19:6d02:: with SMTP id i2-v6mr10856246lfc.81.1525211512557; Tue, 01 May 2018 14:51:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.31.18 with HTTP; Tue, 1 May 2018 14:51:32 -0700 (PDT) In-Reply-To: References: From: Alberto Rodriguez-Natal Date: Tue, 1 May 2018 14:51:32 -0700 Message-ID: To: Tom Herbert Cc: Dino Farinacci , ila@ietf.org, Behcet Sarikaya , Christian Huitema , Dirk.von-Hugo@telekom.de, 5GANGIP <5gangip@ietf.org>, Tom Herbert Content-Type: multipart/alternative; boundary="00000000000069d474056b2bfae7" Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 21:51:57 -0000 --00000000000069d474056b2bfae7 Content-Type: text/plain; charset="UTF-8" Tom, These are very clear examples, thanks for your time putting them together. Just one question below. On Tue, May 1, 2018 at 8:54 AM, Tom Herbert wrote: > When ILA-Rs receive packets they transform and forward them as > described above. It MAY also send an ILA redirect. An ILA redirect can > only be sent to an ILA-N that is in the local ILA domain. To do this > the ILA-R performs a reverse lookup on the source address of the > received packets. > How does this work when the mapping information for the source address is in a different ILA-R? Thanks, Alberto --00000000000069d474056b2bfae7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tom,=

These are very clear examples, tha= nks for your time putting them together. Just one question below.
=

On Tue, May 1, 2018 at 8:54 AM, Tom Herbert = <tom@herbertland.com> wrote:
When ILA-Rs receive packets they transform and forward them as
described above. It MAY also send an ILA redirect. An ILA redirect can
only be sent to an ILA-N that is in the local ILA domain. To do this
the ILA-R performs a reverse lookup on the source address of the
received packets.

How does this work w= hen the mapping information for the source address is in a different ILA-R?=

Thanks,
Alberto

<= /div> --00000000000069d474056b2bfae7-- From nobody Tue May 1 14:59:37 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC7C1200C5; Tue, 1 May 2018 14:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 8ToKcLvr1FfM; Tue, 1 May 2018 14:59:27 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 56620126DFB; Tue, 1 May 2018 14:59:27 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id z130-v6so18033946lff.5; Tue, 01 May 2018 14:59:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1oi57z8K8P690+538nKHmi6mR11CPmLC1CIKvohsbBQ=; b=a4JZ1wrGhlEItjSoZxO80Psl9eRVAw3NsJ5c1ucGSnAamffQoMRlzTOOTBEk1fS2V5 jKXi0hZDy3GOlzkcn2jS2ZmVpOYSWzv+m8h41hi6EowHw2D3xVkTs1o+igTT7s7MM67/ n66wORuGVx/tF5bNQMgIjjsZCRTd9EqPdYhlLDXxtWeqqgTwjmwOmGuP73m4cCMwh+Jf C/1hNPUVVDFd6sGz6tsNVrPVFhiAcZn57v7qs2ETIrJFs0WKEVnrN/qkETQMTzL5iwxi rIgSjRhKktMZldBBroA6pwpQaydWUPfvM0cNbVj1X49Qpsue7S5o5dPXt+UladyRST0C D8LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1oi57z8K8P690+538nKHmi6mR11CPmLC1CIKvohsbBQ=; b=kRhTbDsj/k6ywgL+bQyXX6THA8/rViaWNg4rLHXb4joONDj8Cf1YnlEQ1BtpeN1o3L /SDK52d+QSbR5dSwr387xj0qbBy9w6ZElzHrdZwt0ov4ZnsmUYgVRco/gFFK/Gtnk6i4 mRRNj80hbnWAlN4H0TcDDPtlu2y9BIbG6U2VPjf/OXKuq3gxmkSRr7WmzG4bpkBpA8ad bNJFAvFjtYRrhhxpeGIS/CpALFveRwqkL3AyMVcz2s7/dLzMwpPtvSddZOeWrRS315ig 6Zu38E9Njrcrf6/jDgzDNzr+fPXYYk89l3xPpz4FJoKgisFl/Qeq3R0tNYrxsgLT5Ica z9BQ== X-Gm-Message-State: ALQs6tAKsUuLyh+FuYwBJi8+cQQVG3qSGgQV4R92+9UtLhcLFs7tga4T aRQLLX1KloK0zhfKv32F9Ht+8FMsDf5TBDw0djDpxg== X-Google-Smtp-Source: AB8JxZq8oyvkRy9ykmugMrXEn5VRodmulMQPzg3DhhktRb2ylZCq+WsiiF8K7EavKYVci9Ies4+CbD5/mcBf3dFgacY= X-Received: by 2002:a2e:8705:: with SMTP id m5-v6mr12041511lji.62.1525211965485; Tue, 01 May 2018 14:59:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.31.18 with HTTP; Tue, 1 May 2018 14:59:05 -0700 (PDT) In-Reply-To: References: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> From: Alberto Rodriguez-Natal Date: Tue, 1 May 2018 14:59:05 -0700 Message-ID: To: Tom Herbert Cc: "Joel M. Halpern" , ila@ietf.org, Tom Herbert , 5GANGIP <5gangip@ietf.org> Content-Type: multipart/alternative; boundary="00000000000068f912056b2c15ea" Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 21:59:30 -0000 --00000000000068f912056b2c15ea Content-Type: text/plain; charset="UTF-8" On Tue, May 1, 2018 at 10:16 AM, Tom Herbert wrote: > I think you've misunderstood my position. Caches are _very_ important > to eliminate the cost triangular routing (latency, average path load). > This reduces latency and reduces average load on ILA-Rs. But, and this > is the critical part, caches are only an _optimization_ in ILA. That > means if the cache is rendered ineffective (like by a well crafted DOS > attack) then the only effect is that the optimization is loss (i.e. > greater latency due to triangular router)-- this is quantitively the > worst effect of the attack on an ILA cache. This can be contrasted > that to LISP where the worst case effects of a DOS attack on the cache > is loss of service for users (infinite latency since packets can be > dropped or indefinitely blocked on a cache miss). > This can be misleading. This is not comparing LISP vs ILA, this is comparing the models of Request/Reply at the edge vs Notifications (aka Redirects) at the core. Both LISP-CP and ILAMP support these two models. Besides, this is assuming an scenario where the only feasible DOS mitigation is absorbing the attack. There are other scenarios where other countermeasures are possible. For instance, if you have a deployment where you can prevent address spoofing, counting and blocking misbehaving nodes offers similar DOS protection and requires way less infrastructure resources. Alberto --00000000000068f912056b2c15ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, May 1, 2018 at 10:16 AM, Tom Herbert <tom@herbertland.com> wrote:
I think you've misunderstood my position. Caches are _very_ important to eliminate the cost triangular routing (latency, average path load).
This reduces latency and reduces average load on ILA-Rs. But, and this
is the critical part, caches are only an _optimization_ in ILA. That
means if the cache is rendered ineffective (like by a well crafted DOS
attack) then the only effect is that the optimization is loss (i.e.
greater latency due to triangular router)-- this is quantitively the
worst effect of the attack on an ILA cache. This can be contrasted
that to LISP where the worst case effects of a DOS attack on the cache
is loss of service for users (infinite latency since packets can be
dropped or indefinitely blocked on a cache miss).

This can be misleading. This is not compa= ring LISP=20 vs ILA, this is comparing the models of Request/Reply at the edge vs Notifi= cations (aka Redirects) at the core. Both LISP-CP=20 and ILAMP support these two models.

Besides, this is assuming an scenario where the only feasible DOS mitigation is abs= orbing the attack. There are other scenarios where other countermeasures ar= e possible. For instance, if you have a deployment where=20 you can prevent address spoofing, counting and blocking misbehaving=20 nodes offers similar DOS protection and requires way less infrastructure resources.

Alberto
=
--00000000000068f912056b2c15ea-- From nobody Tue May 1 15:33:04 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2088D12EAE7 for ; Tue, 1 May 2018 15:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.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 EGUtLdcpapny for ; Tue, 1 May 2018 15:33:00 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (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 8EAE912EAE0 for ; Tue, 1 May 2018 15:33:00 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id o2-v6so9112901wrj.13 for ; Tue, 01 May 2018 15:33:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q+e7gUqltNmR1j848sJ8DlS71xXU6GHVvGDsJcs4rtg=; b=nl3g01NgRMvhqGQBea6GyOJ6ZHWRtu9lbNXvOO8W9uJF+wh2PCq0TE3tWwP8KHFdzW cshn2ufHRZ6fwRoeL4S7g+cVaT8srz/okDhCJQIpBghf4TqIp5g5iNnTI8joOeFUNr3p vkjHiGczeGWasTYtqK8tNCS/WM9xiboN3FV6vCWAqPVSkDquRfTj6ZHqAzaZk4ewaFAX YrEagwQpVhcKSvI9XZYdrli1gc+Np4bUXBXsuc00QvOEh6UzMTO92sXsZO0uTbvoab1D BBoHfxrhuQXf50D7mWnpDBmJWuTnm7H4oe8BIgpyifouu0dvBJdIAq77uvmOxw12obNB TEPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=q+e7gUqltNmR1j848sJ8DlS71xXU6GHVvGDsJcs4rtg=; b=mTEAA7nLkzEh8u7m0TfHoO49wG431TjQRAumPmICusUgr8psBYv64diyg7gWKSUTbq X2Kb875OKrOfa5vrdh+ooiHnl8et4EYAZ+71JuIItR3NcVwfAeWVx3VC+QQzkVU89nXD O0RFEnGH77VqPJJ+ZT3y0QLfnTctmfaViRHxtqpP6+T1pNLZpprS4LrZizlTxo+rcrPU CMwX5bZ7HZ4VHSCQAjMdoIzPohZujiUPc+vFKTYDifZ5rn+srojBuUrGFqEvRy+U677x dN13H0e7KBvWFz4Wd8KaprYXdzbt6OXtBTHTQp8vn8IP1Cyo1OYsfVKHLgBqHKN+JS4k XFGQ== X-Gm-Message-State: ALQs6tAdPjzzEoQLOWACNve0wTpBNyOeMF4i8yNsPG4guULetXtQdWNh Frb7fvWTKHvhsZcrAPw+ojobksjjeDiz9YR+2MbO0g== X-Google-Smtp-Source: AB8JxZqRvlccZzao+wbXF/OoVrXkQR/VvElN9JRF9e+PEKkbHVt1jgkrKU2uf7as6NVFx76wTiqyMZUMGf5mcVGPKJE= X-Received: by 2002:adf:dc0d:: with SMTP id t13-v6mr11552523wri.153.1525213978947; Tue, 01 May 2018 15:32:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.227 with HTTP; Tue, 1 May 2018 15:32:58 -0700 (PDT) In-Reply-To: References: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> From: Tom Herbert Date: Tue, 1 May 2018 15:32:58 -0700 Message-ID: To: Alberto Rodriguez-Natal Cc: Tom Herbert , "Joel M. Halpern" , ila@ietf.org, 5GANGIP <5gangip@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 22:33:03 -0000 On Tue, May 1, 2018 at 2:59 PM, Alberto Rodriguez-Natal wrote: > On Tue, May 1, 2018 at 10:16 AM, Tom Herbert wrote: >> >> I think you've misunderstood my position. Caches are _very_ important >> to eliminate the cost triangular routing (latency, average path load). >> This reduces latency and reduces average load on ILA-Rs. But, and this >> is the critical part, caches are only an _optimization_ in ILA. That >> means if the cache is rendered ineffective (like by a well crafted DOS >> attack) then the only effect is that the optimization is loss (i.e. >> greater latency due to triangular router)-- this is quantitively the >> worst effect of the attack on an ILA cache. This can be contrasted >> that to LISP where the worst case effects of a DOS attack on the cache >> is loss of service for users (infinite latency since packets can be >> dropped or indefinitely blocked on a cache miss). > > > This can be misleading. This is not comparing LISP vs ILA, this is comparing > the models of Request/Reply at the edge vs Notifications (aka Redirects) at > the core. Both LISP-CP and ILAMP support these two models. > > Besides, this is assuming an scenario where the only feasible DOS mitigation > is absorbing the attack. There are other scenarios where other > countermeasures are possible. For instance, if you have a deployment where > you can prevent address spoofing, counting and blocking misbehaving nodes > offers similar DOS protection and requires way less infrastructure > resources. > Alberto, The answer to my question of how does LISP address DOS attacks seems to be "there are many options". Some of the options are to assume that DOS does not exist in the network, some assume external configuration like address spoofing is enabled, some assume that attacks can be identified and can be stopped at the source, some might assume that everything is okay because there's never been a DOS attack before. I have yet to see the effects of any of these quantified, and none of these state how the LISP _protocol_ itself addresses DOS. It may seem counter-intuitive, but offering a bunch of options really is not necessarily a good thing-- sometime less is more. To put this another way LISP has been rejected from Linux precisely because of its susceptibility to DOS. If you were to try again and the best answer to the DOS question is that it's up to the operator to figure out the right options to use, then I believe it would be soundly rejected again. That approach does not work at scale. Tom From nobody Tue May 1 15:35:48 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E0012EB1F for ; Tue, 1 May 2018 15:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.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 yMVU52-bldeJ for ; Tue, 1 May 2018 15:35:34 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (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 3E50112EAF8 for ; Tue, 1 May 2018 15:35:34 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id p5-v6so12005437wre.12 for ; Tue, 01 May 2018 15:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mcdeJND4cH3cAIhoRVrCcuQPGBCIHBo765hLi8kGYrA=; b=j8MzLujYDltl6ycWt3EiXG9DV7BBf3bBcmF4l+YXU+agmLHBrzxmDOW3eTpMPmgg32 mo1GaQG8fBgIHpxJ2H5zjofleme1cTLlJ0unE0qQBxvMfVeq+2bxC6iNcgIdTa+DiU/k tjMhg8QoC23FgFs/k2Nzm6eLrU+YPnrGRrPI0C5lDu/E29LnNTLqhqz2TXz9eLP9TMPM Xxuy3Pwnt4+nfkoimvDEvKB1HD8/kRWrwhpSJgRVtLJIhHUTI4qijji104Xlbl60P5C5 I5iH7nMe6RkHisRucemdWXKbrFw7QRGWaWXal2zk9fWNNVq978ESLtVlBbnFgFYwLWHb S8eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mcdeJND4cH3cAIhoRVrCcuQPGBCIHBo765hLi8kGYrA=; b=qNh0yqTKh3PtuD27UuoSDB8nLOeZrWy4GLGaNYBZdOYWwwfK5v4rXVYzbe2vHoBy10 7EcmnWs9XXjnqJBJeFTzDavJmvqTyY1Xyt4XIeEiSh1EdbaQrAjBiLTU2ZYM76X+AotW +nGQNG9fNexWwpoK/eLoIf8CQmd7mQP/oEaqfRaWb3dknKJtnj63LD1bLvBnmRNsR45T /Et+WjOapAKCQPjK1YPSnSv+QypgvjPzPc0VqQQaPFsYMYPEERFW4yi7gBew3cyMOtDW 1AJdW0bFGaSh6I8p2PQGBvmXyG2N9WbvtLwI/F0MddyVZ7ImEYgFeol75t4kXiKAV6CN 2Fvg== X-Gm-Message-State: ALQs6tA+LXa0j3NOUhl3552yJ1iujfMnzoHvhZJuyWJcnV3qnvNnZDQX fMl4vwtp1N7JcZ3rkTDFXm4Kga07UNPxu4fmvzQkkQ== X-Google-Smtp-Source: AB8JxZrn3/qKxqOVaNGg5ft+rtex7cU5SqT4exxzWwkXgXXOmRaXCBPyxt7cPpPZ59B00TR8YcKf9u0twsUSzuRLIHk= X-Received: by 2002:adf:9162:: with SMTP id j89-v6mr12753568wrj.196.1525214132766; Tue, 01 May 2018 15:35:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.227 with HTTP; Tue, 1 May 2018 15:35:32 -0700 (PDT) In-Reply-To: References: From: Tom Herbert Date: Tue, 1 May 2018 15:35:32 -0700 Message-ID: To: Alberto Rodriguez-Natal Cc: Tom Herbert , Dino Farinacci , ila@ietf.org, Behcet Sarikaya , Christian Huitema , Dirk.von-Hugo@telekom.de, 5GANGIP <5gangip@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 22:35:40 -0000 On Tue, May 1, 2018 at 2:51 PM, Alberto Rodriguez-Natal wrote: > Tom, > > These are very clear examples, thanks for your time putting them together. > Just one question below. > > On Tue, May 1, 2018 at 8:54 AM, Tom Herbert wrote: >> >> When ILA-Rs receive packets they transform and forward them as >> described above. It MAY also send an ILA redirect. An ILA redirect can >> only be sent to an ILA-N that is in the local ILA domain. To do this >> the ILA-R performs a reverse lookup on the source address of the >> received packets. > > > How does this work when the mapping information for the source address is in > a different ILA-R? > The ILA-R can query another ILA-R for the information (or just do a DB lookup). This is not done in-line with the forwarding path. Tom > Thanks, > Alberto > From nobody Tue May 1 15:49:59 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69EE612EA67; Tue, 1 May 2018 15:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 EtVhj-OizV4f; Tue, 1 May 2018 15:49:50 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 965DE12EAE0; Tue, 1 May 2018 15:49:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4EE60680203; Tue, 1 May 2018 15:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1525214990; bh=MavdsooaqJbgdh9e8JsmEj1eA3gtr2TGpRKMAlXhxI0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=JQJV+syvqZQgP4XWUnK/3f+uOwZvX4SNnwvk+xOPHtnlQGitx+FWpwbOb85D1PEJf bG5kAe1EW4yNFy9ychxrBv7nXrWWW6PlruwNGluCCSMpYLUYZ+irqIwBlCA45M1grR oJ1r05KliGCbekGMNzhs5HeDMDBoB7NnseQw/cp4= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id DB43B680201; Tue, 1 May 2018 15:49:12 -0700 (PDT) To: Tom Herbert , Alberto Rodriguez-Natal Cc: Tom Herbert , ila@ietf.org, 5GANGIP <5gangip@ietf.org> References: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> From: "Joel M. Halpern" Message-ID: Date: Tue, 1 May 2018 18:49:07 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 22:49:53 -0000 You seem to be saying that even though not all DDOS attacks are structurally the same, and even though if ILA were widely adopted not all ILA networks would be structurally the same, there should nonetheless be one required qay of handling DDOS? Yours, Joel On 5/1/18 6:32 PM, Tom Herbert wrote: > On Tue, May 1, 2018 at 2:59 PM, Alberto Rodriguez-Natal > wrote: >> On Tue, May 1, 2018 at 10:16 AM, Tom Herbert wrote: >>> >>> I think you've misunderstood my position. Caches are _very_ important >>> to eliminate the cost triangular routing (latency, average path load). >>> This reduces latency and reduces average load on ILA-Rs. But, and this >>> is the critical part, caches are only an _optimization_ in ILA. That >>> means if the cache is rendered ineffective (like by a well crafted DOS >>> attack) then the only effect is that the optimization is loss (i.e. >>> greater latency due to triangular router)-- this is quantitively the >>> worst effect of the attack on an ILA cache. This can be contrasted >>> that to LISP where the worst case effects of a DOS attack on the cache >>> is loss of service for users (infinite latency since packets can be >>> dropped or indefinitely blocked on a cache miss). >> >> >> This can be misleading. This is not comparing LISP vs ILA, this is comparing >> the models of Request/Reply at the edge vs Notifications (aka Redirects) at >> the core. Both LISP-CP and ILAMP support these two models. >> >> Besides, this is assuming an scenario where the only feasible DOS mitigation >> is absorbing the attack. There are other scenarios where other >> countermeasures are possible. For instance, if you have a deployment where >> you can prevent address spoofing, counting and blocking misbehaving nodes >> offers similar DOS protection and requires way less infrastructure >> resources. >> > Alberto, > > The answer to my question of how does LISP address DOS attacks seems > to be "there are many options". Some of the options are to assume that > DOS does not exist in the network, some assume external configuration > like address spoofing is enabled, some assume that attacks can be > identified and can be stopped at the source, some might assume that > everything is okay because there's never been a DOS attack before. I > have yet to see the effects of any of these quantified, and none of > these state how the LISP _protocol_ itself addresses DOS. It may seem > counter-intuitive, but offering a bunch of options really is not > necessarily a good thing-- sometime less is more. To put this another > way LISP has been rejected from Linux precisely because of its > susceptibility to DOS. If you were to try again and the best answer to > the DOS question is that it's up to the operator to figure out the > right options to use, then I believe it would be soundly rejected > again. That approach does not work at scale. > > Tom > > _______________________________________________ > ila mailing list > ila@ietf.org > https://www.ietf.org/mailman/listinfo/ila > From nobody Tue May 1 16:20:27 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE0B126DFB for ; Tue, 1 May 2018 16:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.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 S7ae9zVFiZwf for ; Tue, 1 May 2018 16:20:14 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (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 5DE09126BF6 for ; Tue, 1 May 2018 16:20:14 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id 94-v6so10755112wrf.5 for ; Tue, 01 May 2018 16:20:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=n5sHZPS/Lo4D6GMmwF0iika0UsrD+oBcZwbG73cuPKg=; b=k2JeWSXxav8rZJDNrsxj8jQwO+W9oLtz+CS/Jbs9ICJlhfbJMxf1LHisA6XyxM+mMS ICWF+PSLNYcgTLm6iEoJedSwV0DWYeJl65frmxAJLVFHx+0fmdFHYoOPXkPcPDhqBIcV /x+uEFjRpNyreWN4Lbnm+RWVeukCBPEAkrVo3fW2ObPEgRFzQYFt/v1Zffc4XMOUgRW+ HLr2ukuWXKl7lZcN7gXEQ9Mr2owEIyzkB/caPtq3ipbKdlIEH/pUXZ8QsekcMkySuLE9 F/8nZyHpEW74RRi59/UErZVeA3EWZKUDxnOCdsMvFiWWGMw+WBsSCG7MgL7x2ATR1BcF E5Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=n5sHZPS/Lo4D6GMmwF0iika0UsrD+oBcZwbG73cuPKg=; b=inH0cYHkHK6cJTvpiy1bbOX7cYEISFNlgecn+iXrkBrakLSseiouJaNRr8OygERSGC Nw/aAIVVRn+tXIk029YYSePWJG0SNzMGvLOJv+tu/fwY7oD7ORtN2CGyNrpwB0T7poeU 6OXJbhNlHuYXzC1Swc/PZcwzmOvb6t44HYTmqU0CSiDSYYDBaZoSnHmwFZP7Xkk2Nh0J BA7bfEbATeg9e51CzVvLbTNb+EU/tjYFnIOB66u46+Rgg5f1zkdCFqU3SJrD2+PEaM7P HNsnk01updeeBgZR5Ojhky/F5SCLTYR9QIr72F1ceDn+aFF4REn+e8SioE2A9ubSIqCd ay3Q== X-Gm-Message-State: ALQs6tAFGJ7cSEMsBOO9Wmb2gie/gWvwODmfPKnTg4DEE4u+hC3oVSI/ SIy70EI7O0t4DVySYcbNan+HOXLllP4o/MvwNwICtQ== X-Google-Smtp-Source: AB8JxZrjP2Vn9Gqi7mSmhTd9tKVvcWyYdPr5HX6cp55bnMiCxcaNYmDG3kPivZDHkE5aJmPra4NBnt3XY97oJTly9fE= X-Received: by 2002:adf:9162:: with SMTP id j89-v6mr12821092wrj.196.1525216812725; Tue, 01 May 2018 16:20:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.227 with HTTP; Tue, 1 May 2018 16:20:12 -0700 (PDT) In-Reply-To: References: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> From: Tom Herbert Date: Tue, 1 May 2018 16:20:12 -0700 Message-ID: To: "Joel M. Halpern" Cc: Alberto Rodriguez-Natal , Tom Herbert , ila@ietf.org, 5GANGIP <5gangip@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 23:20:23 -0000 On Tue, May 1, 2018 at 3:49 PM, Joel M. Halpern wrote: > You seem to be saying that even though not all DDOS attacks are structurally > the same, and even though if ILA were widely adopted not all ILA networks > would be structurally the same, there should nonetheless be one required qay > of handling DDOS? Yes, at least as core default in the protocol. It's precisely _because_ not all DDOS attacks are structurally the same. An attacker is not going to conform to to our expectations of what they should be doing, so if we enable LISP option N to mitigate one form of attack, they will just use another attack that isn't mitigated. For example, if the mitigation is to identify attackers by address when requests from the address exceed a threshold then this works as long as the attacker strikes from one machine, but it falls apart if the attacker launches a DDOS attack from several hosts where requests from none of the hosts exceed the threshold. The ILA model works because it assumes there is no absolute way to prevent the the worst case attack on a cache which is to completely kill it (i.e. drive it to 0% hit rate). In this state the behavior sub-optimal routing, which is much better than loss of service. This is not dependent on the structure of the attack, network topology, or the network operator getting the configuration just right-- it is inherent in the protocol. Tom > > Yours, > Joel > > > On 5/1/18 6:32 PM, Tom Herbert wrote: >> >> On Tue, May 1, 2018 at 2:59 PM, Alberto Rodriguez-Natal >> wrote: >>> >>> On Tue, May 1, 2018 at 10:16 AM, Tom Herbert wrote: >>>> >>>> >>>> I think you've misunderstood my position. Caches are _very_ important >>>> to eliminate the cost triangular routing (latency, average path load). >>>> This reduces latency and reduces average load on ILA-Rs. But, and this >>>> is the critical part, caches are only an _optimization_ in ILA. That >>>> means if the cache is rendered ineffective (like by a well crafted DOS >>>> attack) then the only effect is that the optimization is loss (i.e. >>>> greater latency due to triangular router)-- this is quantitively the >>>> worst effect of the attack on an ILA cache. This can be contrasted >>>> that to LISP where the worst case effects of a DOS attack on the cache >>>> is loss of service for users (infinite latency since packets can be >>>> dropped or indefinitely blocked on a cache miss). >>> >>> >>> >>> This can be misleading. This is not comparing LISP vs ILA, this is >>> comparing >>> the models of Request/Reply at the edge vs Notifications (aka Redirects) >>> at >>> the core. Both LISP-CP and ILAMP support these two models. >>> >>> Besides, this is assuming an scenario where the only feasible DOS >>> mitigation >>> is absorbing the attack. There are other scenarios where other >>> countermeasures are possible. For instance, if you have a deployment >>> where >>> you can prevent address spoofing, counting and blocking misbehaving nodes >>> offers similar DOS protection and requires way less infrastructure >>> resources. >>> >> Alberto, >> >> The answer to my question of how does LISP address DOS attacks seems >> to be "there are many options". Some of the options are to assume that >> DOS does not exist in the network, some assume external configuration >> like address spoofing is enabled, some assume that attacks can be >> identified and can be stopped at the source, some might assume that >> everything is okay because there's never been a DOS attack before. I >> have yet to see the effects of any of these quantified, and none of >> these state how the LISP _protocol_ itself addresses DOS. It may seem >> counter-intuitive, but offering a bunch of options really is not >> necessarily a good thing-- sometime less is more. To put this another >> way LISP has been rejected from Linux precisely because of its >> susceptibility to DOS. If you were to try again and the best answer to >> the DOS question is that it's up to the operator to figure out the >> right options to use, then I believe it would be soundly rejected >> again. That approach does not work at scale. >> >> Tom >> >> _______________________________________________ >> ila mailing list >> ila@ietf.org >> https://www.ietf.org/mailman/listinfo/ila >> > From nobody Wed May 2 00:56:14 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74DEB1252BA; Wed, 2 May 2018 00:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=universityofstandrews907.onmicrosoft.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 ZQLDAZergKRx; Wed, 2 May 2018 00:56:02 -0700 (PDT) Received: from mcgraw.st-andrews.ac.uk (mcgraw.st-andrews.ac.uk [138.251.8.95]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A40A2126C2F; Wed, 2 May 2018 00:56:00 -0700 (PDT) X-StAndrews-MailScanner-From: saleem@st-andrews.ac.uk X-StAndrews-MailScanner-ID: w427tqab018353 X-StAndrews-MailScanner-Information: Please contact the ISP for more information Received: from wallace.st-andrews.ac.uk (wallace.st-andrews.ac.uk [138.251.9.23]) by mcgraw.st-andrews.ac.uk (8.14.9/8.14.9/Debian-4~bpo0+uos) with ESMTP id w427tqab018353 (version=TLSv1/SSLv3 cipher=ADH-AES256-SHA bits=256 verify=NOT); Wed, 2 May 2018 07:55:54 GMT X-StAndrews-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.89, required 5, autolearn=not spam, BAYES_00 -1.90, T_DKIM_INVALID 0.01), not spam (whitelisted), SpamAssassin (not cached, score=-4.19, required 5, autolearn=not spam, BAYES_00 -1.90, RCVD_IN_DNSWL_MED -2.30, T_DKIM_INVALID 0.01) X-StAndrews-MailScanner: No virus detected, No virus detected Received: from unimail.st-andrews.ac.uk (exch13-srv01.st-andrews.ac.uk [138.251.8.22]) by wallace.st-andrews.ac.uk (8.14.9/8.14.9/Debian-4~bpo0+uos) with ESMTP id w427thK2022358 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 2 May 2018 07:55:44 GMT Received: from exch13-srv01.st-andrews.ac.uk (138.251.8.22) by exch13-srv01.st-andrews.ac.uk (138.251.8.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 2 May 2018 08:55:43 +0100 Received: from EUR02-VE1-obe.outbound.protection.outlook.com (213.199.154.53) by exch13-srv01.st-andrews.ac.uk (138.251.8.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Wed, 2 May 2018 08:55:43 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=UniversityofStAndrews907.onmicrosoft.com; s=selector1-standrews-ac-uk0e; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oj7zq6xiirTP5/QaIn1ae2kiXrkVKSooQXFmbY2Nasc=; b=sfbHG5P/IV1R/d/QNEhzTm1do7IYixYX0HdO/9TFmwWfiA2YjZpchikpeZbXYDqOykO6h4aqKd4L5v7+BejApB+5DXJ5dPYLBMTL0UpbHD4+GHAydNqw2+R3nydcPODclsnLbLCwVlSotm8IRajPqtGZVqHW/RxOPc6xItd8tz0= Received: from DB6PR0601MB2469.eurprd06.prod.outlook.com (10.169.213.151) by DB6PR0601MB2117.eurprd06.prod.outlook.com (10.168.57.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.715.23; Wed, 2 May 2018 07:55:41 +0000 Received: from DB6PR0601MB2469.eurprd06.prod.outlook.com ([fe80::b5a0:cbd:abcd:6163]) by DB6PR0601MB2469.eurprd06.prod.outlook.com ([fe80::b5a0:cbd:abcd:6163%13]) with mapi id 15.20.0715.024; Wed, 2 May 2018 07:55:41 +0000 From: Saleem Bhatti To: Tom Herbert CC: Behcet Sarikaya , Tom Herbert , "ila@ietf.org" , 5GANGIP <5gangip@ietf.org> Thread-Topic: [5gangip] SIR [was ILA forwarding] Thread-Index: AQHT4Y7i8M5nRZXQ6kmKwX1lR7msa6QbXleAgAC0eAA= Date: Wed, 2 May 2018 07:55:41 +0000 Message-ID: <264FEFB6-E83D-4E10-BBAF-607BBEAA3849@st-andrews.ac.uk> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=saleem@st-andrews.ac.uk; x-originating-ip: [2001:8b0:d3:1:f44b:3b94:a231:e549] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6PR0601MB2117; 7:co979ytj1jJFGvmL+Onn28RfToU9kUm6gK8cqLIIkg5hCVMVQXWvaWmbtyqVLQoS1rFE8rESAkxkniWOWNf0fDOuqzP6PATdh2A2dkJDrhs49+2CLVzIdQGA9un1jIDd8kSGC9hyStpnso55TpaTJSewjTz7FIBa30C2w2eE4rcw0iDFRc3M/3n5y1C+lhO2RygQg6Tj39Wr75wHIYLA/FQ7yduNMzPRe06CAbFRM4+lqBqeEc8u6o8l5E10BFq1 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(5600026)(2017052603328)(7153060)(7193020); SRVR:DB6PR0601MB2117; x-ms-traffictypediagnostic: DB6PR0601MB2117: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231254)(944501410)(52105095)(3002001)(6041310)(20161123560045)(20161123558120)(20161123562045)(201703131423095)(201703061421075)(201703161042150)(20161123564045)(6042181)(6072148)(201708071742011); SRVR:DB6PR0601MB2117; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0601MB2117; x-forefront-prvs: 06607E485E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(199004)(189003)(2906002)(6506007)(6916009)(99286004)(3280700002)(3660700001)(74482002)(105586002)(2900100001)(6246003)(36756003)(186003)(53936002)(5250100002)(102836004)(6512007)(6306002)(7736002)(33656002)(68736007)(4326008)(305945005)(6116002)(53546011)(83716003)(81166006)(81156014)(97736004)(8676002)(966005)(46003)(76176011)(106356001)(82746002)(5660300001)(8936002)(86362001)(11346002)(6436002)(54906003)(486006)(2616005)(229853002)(446003)(476003)(498600001)(25786009)(14454004)(6486002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0601MB2117; H:DB6PR0601MB2469.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: st-andrews.ac.uk does not designate permitted sender hosts) x-microsoft-antispam-message-info: pZ6YlMJltYtY7jTT9YHO9zYoh+haRejKSlMJNZhBibNCOASYZNwoM+TzWvyjgZwAIt1T+KoBHxdUQAl4KHxjySLiaFhMXr+V5oKyvoaq3bvW9dq0SQ4q20jUsIwSFHfYzKC9HRYlcQpadHvMlyv4iBM1IduQ/yMO0M/LbQzCASDq1gdqvgZHI/Xmlniuubel spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <9565A47548A17D429A2D71B2997D005F@eurprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 703db3c3-fff8-4d61-1750-08d5b0021a05 X-MS-Exchange-CrossTenant-Network-Message-Id: 703db3c3-fff8-4d61-1750-08d5b0021a05 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2018 07:55:41.4351 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f85626cb-0da8-49d3-aa58-64ef678ef01a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0601MB2117 Archived-At: Subject: Re: [Ila] [5gangip] SIR [was ILA forwarding] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 07:56:06 -0000 > On 01 May 2018, at 22:09, Tom Herbert wrote: >=20 > On Tue, May 1, 2018 at 1:56 PM, Behcet Sarikaya = wrote: >> Hi Tom, >>=20 >> With SIR fixed, I wonder how do you address multi homed UEs in ILA? >> Maybe you did not need it for VMs because they are not multi homed but U= Es >> definitely have multiple interfaces. >=20 > That's a tough problem. If both interfaces are in the same ILA domain, > then there's no issue it should just work. If they're not then > something needs to be done across domains for it to work seamlessly > where addresses associated in one domain can be routed in another. >=20 >> ILNP treats it using two different locators but same identifier which se= ems >> reasonable. >>=20 > But then locators are exposed to end devices-- privacy problem. ILNP offers options for location privacy, without tunnelling or loss of end= -to-end semantics for a flow - please section 7 of RFC6748. Cheers, --/Saleem >=20 >> Regards, >> Behcet >>=20 >>=20 >>=20 >> _______________________________________________ >> 5gangip mailing list >> 5gangip@ietf.org >> https://www.ietf.org/mailman/listinfo/5gangip >>=20 >=20 > _______________________________________________ > 5gangip mailing list > 5gangip@ietf.org > https://www.ietf.org/mailman/listinfo/5gangip From nobody Wed May 2 10:32:01 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA29A124B17; Wed, 2 May 2018 10:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 ngH1pWDnLnDj; Wed, 2 May 2018 10:31:53 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 2DDAF1200C1; Wed, 2 May 2018 10:31:53 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id w42HPwbc005516; Wed, 2 May 2018 13:31:49 -0400 Received: from flpd657.enaf.ffdc.sbc.com (sbcsmtp9.sbc.com [144.160.128.153]) by m0049297.ppops.net-00191d01. with ESMTP id 2hqgpvt0hp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 02 May 2018 13:31:49 -0400 Received: from enaf.ffdc.sbc.com (localhost [127.0.0.1]) by flpd657.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id w42HVmsq030250; Wed, 2 May 2018 10:31:48 -0700 Received: from zlp25943.vci.att.com (zlp25943.vci.att.com [135.213.92.141]) by flpd657.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id w42HVh8d030124; Wed, 2 May 2018 10:31:43 -0700 Received: from zlp25943.vci.att.com (zlp25943.vci.att.com [127.0.0.1]) by zlp25943.vci.att.com (Service) with ESMTP id B05C640006B5; Wed, 2 May 2018 17:31:43 +0000 (GMT) Received: from CAFRFD1MSGHUBAG.ITServices.sbc.com (unknown [130.4.169.164]) by zlp25943.vci.att.com (Service) with ESMTPS id 91CFC40006B4; Wed, 2 May 2018 17:31:43 +0000 (GMT) Received: from CAFRFD1MSGUSRJI.ITServices.sbc.com ([169.254.8.94]) by CAFRFD1MSGHUBAG.ITServices.sbc.com ([130.4.169.164]) with mapi id 14.03.0389.001; Wed, 2 May 2018 10:31:43 -0700 From: "FIGURELLE, TERRY F" To: Saleem Bhatti , Tom Herbert CC: Tom Herbert , Behcet Sarikaya , "ila@ietf.org" , 5GANGIP <5gangip@ietf.org> Thread-Topic: [5gangip] multi-homed UE's Thread-Index: AdPiO27RoaP4GHvgSwG1F5ODWkFk0w== Date: Wed, 2 May 2018 17:31:43 +0000 Message-ID: <1AFE10CF28AE8B4C9663445736B8034D3822E631@CAFRFD1MSGUSRJI.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.29.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-02_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805020144 Archived-At: Subject: Re: [Ila] [5gangip] multi-homed UE's X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 17:31:55 -0000 FYI - multi-homed UE's and dealing with service latency All VoLTE smartphones have two active sessions (IMS APN/DN and general purp= ose APN/DN) and mobile operators already manage selection to work for VoLTE= based on location (tracking area) when the initial attach uses the general= purpose APN. While there was a lot of worrying about the mobile moving far= enough that the anchors were no longer ideal based on MOS score, that hasn= 't been the issue we thought it would be. Typically a target is measured mo= uth to ear for VoIP and we have that for VoLTE. 5G latency targets are much tougher (or impossible but that never stops mar= keting business units). There are several ways to re-anchor but the easiest is to send a special SM= S message to he UE/SIM which waits until the device is idle. Since there is= only one SGW (both sessions are stuck with the SGW selected for the first = session), you do have to use knowledge of your IMS solution to pick the rig= ht SGW and PGW(s). 3GPP's approach for APN topology is a bit of a pain and = our solutions can leverage out of band control and active GTP management. A= s an example we drove Syniverse to support what we called a GTP Director so= we could control the path when the UE was on our network but not our core = (roaming but the LBO use case) or the flip where our UE in on a roaming par= tners RAN. We lead VoLTE roaming and oddly enough I think we launched Veriz= on first but it could have been one of the Canada mobile operators (Bell or= Rogers). We also drove IoT with Auto VoLTE which launched with GM and now = we support this as both IoT or MVNO with partnered RAN where we don't have = RAN. Currently this is just North America and UK/Europe but Asia is coming = soon. PGW/PCEF vendors also have features to flush sessions when idle (if you bre= ak a VoLTE call it's a reportable event and we go way out of our way to avo= id that). PGW vendors also support a feature I drove years ago which for la= ck of a better term I called Gi geodiversity. At the time it was meant to m= igrate an active session from one GGSN to another in a different location o= r to deal with GGSN failures. Not all corporations want geodiversity and it= does cost a bit more. Currently this is mostly done to migrate sessions of= f equipment that we need to upgrade or make major modifications too which d= oes include RIP and replace hardware based solutions for virtualize EPC. We= always support stateful redundancy at same site. When the dust settles I would assume we'd have API's and leverage our PCF/P= CRF to install the right policies including path management as needed.=20 > -----Original Message----- > From: 5gangip <5gangip-bounces@ietf.org> On Behalf Of Saleem Bhatti > Sent: Wednesday, May 02, 2018 12:56 AM > To: Tom Herbert > Cc: Tom Herbert ; Behcet Sarikaya > ; ila@ietf.org; 5GANGIP <5gangip@ietf.org> > Subject: Re: [5gangip] SIR [was ILA forwarding] >=20 >=20 >=20 > > On 01 May 2018, at 22:09, Tom Herbert wrote: > > > > On Tue, May 1, 2018 at 1:56 PM, Behcet Sarikaya > wrote: > >> Hi Tom, > >> > >> With SIR fixed, I wonder how do you address multi homed UEs in ILA?=09 > >> Maybe you did not need it for VMs because they are not multi homed > >> but UEs definitely have multiple interfaces. [tf2934@att.com] I would assume most mobile operators would continue to follow our lead with= VoLTE/IMS. I think between us and Verizon we drove probably 95% of all the= new features for vendors for that last few years and on their current road= map. We already correct path latency for IMS and mobiles can be told to ref= resh when they are idle. In the future this would just be an IMS registrati= on event and the P-CSCF address (addresses) would be unicast. It's easy to = know the best path by tracking area for a captive service. The harder part = is developing API's and onboarding large content distribution solutions lik= e Akamai and big application service providers (Amazon, Apple, Google, etc.= ). One challenge will be replacing functionality we have for GTP that won't wo= rk without encapsulation and we will need to develop a new solution. As an example we can mark the outside packet differently from how we mark t= he inside packet with GTP. This lets us manage CoS for the transport networ= k, 3GPP QoS for RAN (e.g. QCI) and we can default map (mark based on QCI) o= r mark based on what they specify for the inside packet. We also support in= gress marking to CoS treatment on transport and RAN QoS. We expose an API to the Internet for CoS/QoS and we support signed manifest= s too. As an example Amazon could chose to cover the usage from a subscribe= r to their websites and they could chose to cover streaming usage for their= Prime service. They can also select QoS treatment including DSCP markings.= If they wanted they could setup a dedicated bearer for the streaming traff= ic. =09 Without encapsulation we would have to remark the packet at ingress (cell s= ite and service edges) then change the marking just before egress (cell sit= e and service edges). It's more work and I assume we would define a new mic= ro service at the cell site to handle packet remarking instead of trying to= get RAN vendors onboard (they can be a pain). Then we'd update our AVPN se= rvice to handle that edge again probably a micro service. Thus we would hav= e to move the functionality from PGW/PCEF to two or more edges per service = flow which is kind of a pain. I can't think of a way to handle roaming like= we do today which means some loss of functionality unless IPX sticks to GT= P only. We would selectively pick GTP or no encapsulation based on provisioning and= that would be a new feature for EPC. That is pretty common when migrating = from old to new since you have to support both (often for a very long time)= . > > > > That's a tough problem. If both interfaces are in the same ILA domain, > > then there's no issue it should just work. If they're not then > > something needs to be done across domains for it to work seamlessly > > where addresses associated in one domain can be routed in another. > > > >> ILNP treats it using two different locators but same identifier which > >> seems reasonable. > >> > > But then locators are exposed to end devices-- privacy problem. >=20 > ILNP offers options for location privacy, without tunnelling or loss of e= nd-to- > end semantics for a flow - please section 7 of RFC6748. >=20 > Cheers, > --/Saleem From nobody Wed May 2 10:36:02 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57AB51200C1 for ; Wed, 2 May 2018 10:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 YuvsX5UiLyvl for ; Wed, 2 May 2018 10:35:52 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 27A8912704A for ; Wed, 2 May 2018 10:35:52 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id a202so11862820qkg.3 for ; Wed, 02 May 2018 10:35:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=na4xYuKcvW5cQWRHYZhZ5ivLZ4SjpGC9VuUMd7yeE0A=; b=VNAdQI6i/JywLg9aJqQuRAaGRpmqmVZUwp6UJocInoyICiKpC8VrX6y3jI+mCDmSNw YPE9//TH+KhXd4LMjhYPt9vPYRojTVu7AS+2PTbCA51Jw+GYJ/agx1N/Tb9XIE6PRWPf KIuFwYgZCWi4PkWwaY1EKE6oVCV8BsjJv9Rxiwrn3CeQsPqOFcZoSKhoEEU6PfzmX0SW IuRJlcZf4x7Sc+Qg962MXkaMV0gVuk4Xsvu2zOCHd0XouwxiovSEAgjtgCVKhl7SCYP/ clE8+ZFTKXRV5JHf2Vr7M3jqdmAaAQ5myMmWAC4maf6cDMJ2ReP5pfSoC6hRnRgD3rvA 3+Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=na4xYuKcvW5cQWRHYZhZ5ivLZ4SjpGC9VuUMd7yeE0A=; b=RmowJVz18x8WmiVqg1KA0kWcS4DqDltvuzhk1aZhqGpXLGGEwryomzQfFUJC9hv7QM 3i3YPU+ZRuwMhmoy/Rn8CMV2oZBYNU2bd9td72KJFbOmD1Kf2jHMN77rS/tJ21d/6lTo EXEStj6j0HDcrsuzNqAevwCfgD7Ru5NCnkBf5/LE7lT9FFAZuG6Dv22ovddE/NYLaqqx mPdgm49xdzbYVWHCf2ehg/QcmwP+Ephum9GmyaiqlFl3v30A6Kh6Cy6x9tS/OGwfS6RJ JTreFSOKBKrKO19xas0HWbLB21XtMIVgUMrn1yJlMd5c7zVDRrNIQhybWK5DFYsVRj9t D6rQ== X-Gm-Message-State: ALQs6tBLErOyqwdrw9kOKFwRJnHgi0qZXTuXhYv7EX3EgVAkhZ7aD7cg 8mj50dtfuSVNAi31oW2/rSbrhFuevoPohp94zBGUuA== X-Google-Smtp-Source: AB8JxZpLPVaeAMWDQv/L8qIYrOParsrIDjyE56bxnkFis9DrH3TIB8hqPGAVHAe8daoY67pX9xyoKCnPnMnVHiyq6t4= X-Received: by 10.233.224.5 with SMTP id m5mr16307953qkk.333.1525282551075; Wed, 02 May 2018 10:35:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.48.66 with HTTP; Wed, 2 May 2018 10:35:50 -0700 (PDT) In-Reply-To: <264FEFB6-E83D-4E10-BBAF-607BBEAA3849@st-andrews.ac.uk> References: <264FEFB6-E83D-4E10-BBAF-607BBEAA3849@st-andrews.ac.uk> From: Tom Herbert Date: Wed, 2 May 2018 10:35:50 -0700 Message-ID: To: Saleem Bhatti Cc: Tom Herbert , Behcet Sarikaya , "ila@ietf.org" , 5GANGIP <5gangip@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ila] [5gangip] SIR [was ILA forwarding] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 17:35:55 -0000 On Wed, May 2, 2018 at 12:55 AM, Saleem Bhatti wrote: > > >> On 01 May 2018, at 22:09, Tom Herbert wrote: >> >> On Tue, May 1, 2018 at 1:56 PM, Behcet Sarikaya wrote: >>> Hi Tom, >>> >>> With SIR fixed, I wonder how do you address multi homed UEs in ILA? >>> Maybe you did not need it for VMs because they are not multi homed but UEs >>> definitely have multiple interfaces. >> >> That's a tough problem. If both interfaces are in the same ILA domain, >> then there's no issue it should just work. If they're not then >> something needs to be done across domains for it to work seamlessly >> where addresses associated in one domain can be routed in another. >> >>> ILNP treats it using two different locators but same identifier which seems >>> reasonable. >>> >> But then locators are exposed to end devices-- privacy problem. > > ILNP offers options for location privacy, without tunnelling or loss of end-to-end semantics for a flow - please section 7 of RFC6748. > Hi Saleem, >From RFC6748: "To enable this function, we use a middlebox that we call the Locator Rewriting Relay... The operation of the LRR is conceptually very simple. We assume that the LRR first has mappings as given in expressions..." Looks like an LRR is providing almost identical functionality as an ILA-R. You might even be able to leverage the ILA-R code to implement it. Tom > Cheers, > --/Saleem > > >> >>> Regards, >>> Behcet >>> >>> >>> >>> _______________________________________________ >>> 5gangip mailing list >>> 5gangip@ietf.org >>> https://www.ietf.org/mailman/listinfo/5gangip >>> >> >> _______________________________________________ >> 5gangip mailing list >> 5gangip@ietf.org >> https://www.ietf.org/mailman/listinfo/5gangip > From nobody Thu May 3 09:14:40 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE1212D944; Thu, 3 May 2018 09:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=universityofstandrews907.onmicrosoft.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 WFLQQ8048lOu; Thu, 3 May 2018 09:14:29 -0700 (PDT) Received: from mcgraw.st-andrews.ac.uk (mcgraw.st-andrews.ac.uk [138.251.8.95]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41ED112D883; Thu, 3 May 2018 09:14:28 -0700 (PDT) X-StAndrews-MailScanner-From: saleem@st-andrews.ac.uk X-StAndrews-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=0.011, required 5, autolearn=not spam, HTML_MESSAGE 0.00, T_DKIM_INVALID 0.01) X-StAndrews-MailScanner: No virus detected X-StAndrews-MailScanner-ID: w43GEHjp030293 X-StAndrews-MailScanner-Information: Please contact the ISP for more information Received: from unimail.st-andrews.ac.uk (exch13-srv03.st-andrews.ac.uk [138.251.9.20]) by mcgraw.st-andrews.ac.uk (8.14.9/8.14.9/Debian-4~bpo0+uos) with ESMTP id w43GEHjp030293 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 3 May 2018 16:14:18 GMT Received: from exch13-srv02.st-andrews.ac.uk (138.251.8.23) by exch13-srv03.st-andrews.ac.uk (138.251.9.20) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 3 May 2018 17:14:16 +0100 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (213.199.154.184) by exch13-srv02.st-andrews.ac.uk (138.251.8.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Thu, 3 May 2018 17:14:16 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=UniversityofStAndrews907.onmicrosoft.com; s=selector1-standrews-ac-uk0e; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CDRCVRx4f1zt37tvXjjKx5TNXsqZW4dZebHVW8Qprgw=; b=b0IbK8ohBvaXyyP1M9T77LdB35mkXuf7Km8kTF5//1k+bIXYP52XMTzZem9yutbBkzSU7sFks7upfxngRSCqR2xHPNgpAVNq07YKQHUWrg870QUHkXnyNg7f7ToGtj2VxAJw7xX3dRmVd6EQbdhUN3Mai456PMXQyWigVWLIJf8= Received: from VI1PR0602MB3615.eurprd06.prod.outlook.com (52.134.2.146) by VI1PR0602MB2798.eurprd06.prod.outlook.com (10.175.21.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.735.16; Thu, 3 May 2018 16:14:15 +0000 Received: from VI1PR0602MB3615.eurprd06.prod.outlook.com ([fe80::410c:e715:db77:6617]) by VI1PR0602MB3615.eurprd06.prod.outlook.com ([fe80::410c:e715:db77:6617%13]) with mapi id 15.20.0715.024; Thu, 3 May 2018 16:14:15 +0000 From: Saleem Bhatti To: Tom Herbert CC: Tom Herbert , Behcet Sarikaya , "ila@ietf.org" , 5GANGIP <5gangip@ietf.org> Thread-Topic: [5gangip] SIR [was ILA forwarding] Thread-Index: AQHT4Y7i8M5nRZXQ6kmKwX1lR7msa6QbXleAgAC0eACAAKIZAIABe4gA Date: Thu, 3 May 2018 16:14:15 +0000 Message-ID: References: <264FEFB6-E83D-4E10-BBAF-607BBEAA3849@st-andrews.ac.uk> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=saleem@st-andrews.ac.uk; x-originating-ip: [2001:8b0:d3:1::18] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0602MB2798; 7:B7T4AOxputesW7Tv1PTUR6xaYrbndVAw58NiKTF9N3B8IavbK9RggqkXGr5YfQwRyfoZV/BKvQ/yT7kugAMvbqFpK3mHFt6rwwxED8zMtHshAsn+nB/X2qrQ+DIdhQGNeV/EiBdjycThrMO7B+GIxk4Vw08kO214gZlQR31Lo9Ozjuz/c6qSADJDZ/XrJumqKvDqMNy0k+eRX9fJByDoY5tZVDAunpknh177q30L0EbDtAaNM8eook7YBhwKMfaF x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:(36968037445663); BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603328)(7153060)(7193020); SRVR:VI1PR0602MB2798; x-ms-traffictypediagnostic: VI1PR0602MB2798: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(171593684265217)(85827821059158)(36968037445663); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231254)(2017080701022)(944501410)(52105095)(10201501046)(3002001)(6041310)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:VI1PR0602MB2798; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0602MB2798; x-forefront-prvs: 066153096A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(39860400002)(346002)(396003)(39380400002)(189003)(199004)(478600001)(5250100002)(6116002)(86362001)(6436002)(93886005)(99286004)(74482002)(4326008)(53936002)(6246003)(966005)(606006)(476003)(486006)(6486002)(46003)(11346002)(446003)(2616005)(6916009)(83716003)(14454004)(105586002)(106356001)(25786009)(229853002)(82746002)(54906003)(97736004)(6506007)(8936002)(3660700001)(53546011)(8676002)(3280700002)(59450400001)(186003)(102836004)(2900100001)(786003)(6306002)(54896002)(316002)(2906002)(68736007)(236005)(76176011)(33656002)(6512007)(36756003)(5660300001)(81156014)(7736002)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0602MB2798; H:VI1PR0602MB3615.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: st-andrews.ac.uk does not designate permitted sender hosts) x-microsoft-antispam-message-info: UnPfEWzcp7XyWRihT4L7ADoTTMM1JjGKDYDBSNoUGQz1CV5R3vt4AwDgADh12AYLTsOa9AfyU364xAiKjt0aLAzgXISrGJC50LOECLf/Zl/1v7xzBtSFVg2fLRW+/P4r6xCNWU0TLpzyxf/QF2V6jx48xJgaEst7cy1SYDphDMc9K1jDiQ3SiPuxHjVALE1k spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_F7938DA0F8614543BA7884721A8D20EAstandrewsacuk_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 29dfc46e-6743-4873-4dbe-08d5b110ea85 X-MS-Exchange-CrossTenant-Network-Message-Id: 29dfc46e-6743-4873-4dbe-08d5b110ea85 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2018 16:14:15.3741 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f85626cb-0da8-49d3-aa58-64ef678ef01a X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0602MB2798 Archived-At: Subject: Re: [Ila] [5gangip] SIR [was ILA forwarding] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 16:14:33 -0000 --_000_F7938DA0F8614543BA7884721A8D20EAstandrewsacuk_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tom; On 02 May 2018, at 18:35, Tom Herbert > wrote: On Wed, May 2, 2018 at 12:55 AM, Saleem Bhatti > wrote: On 01 May 2018, at 22:09, Tom Herbert > wrote: On Tue, May 1, 2018 at 1:56 PM, Behcet Sarikaya > wrote: Hi Tom, With SIR fixed, I wonder how do you address multi homed UEs in ILA? Maybe you did not need it for VMs because they are not multi homed but UEs definitely have multiple interfaces. That's a tough problem. If both interfaces are in the same ILA domain, then there's no issue it should just work. If they're not then something needs to be done across domains for it to work seamlessly where addresses associated in one domain can be routed in another. ILNP treats it using two different locators but same identifier which seems reasonable. But then locators are exposed to end devices-- privacy problem. ILNP offers options for location privacy, without tunnelling or loss of end= -to-end semantics for a flow - please section 7 of RFC6748. Hi Saleem, >From RFC6748: "To enable this function, we use a middlebox that we call the Locator Rewriting Relay... The operation of the LRR is conceptually very simple. We assume that the LRR first has mappings as given in expressions..." Looks like an LRR is providing almost identical functionality as an ILA-R. I do not believe so - the LRR function is very simple, with no control-plan= e or management-plane defined (deliberately), but the ILA-R is a more compl= ex beast. (Possibly, the LRR function could be implemented by a suitably co= nfigured ILA-R, I am guessing.) The LRR is only a simple building block. Examples on how it could be used f= or providing some level of location privacy are: 1) a localised-/site-numbering scheme at an ingress/egress point (e.g. as d= escribed in Section 2 of RFC6748); or 2) a more complex, network-wide, Tor-like forwarding mechanism (as outlined= in Section III.C of this MILCOM-2011 paper https://tinyurl.com/yd643dm6, s= ummarised in Section 7 of RFC6748) ILNP does not mandate or exclude either of these, and does not define a con= trol-plane or management-plane that could be used specifically for either o= f those two more complex functions: only the Locator-Update handshake (via = ICMP) is defined (Section 6 of RFC6741, and RFC6743). The key point is that the locator value can be re-writtern for packets on t= he fly, as required, in order to implement various locat{or|ion} obfuscatio= n mechanisms (for privacy), and/or explicit forwarding, without impacting e= nd-to-end state. Possible examples are: - site-multihoming (Section 3 of RFC6748); - site-/network-mobility (Section 4 of RFC6748); and - and some coarse-grained traffic-engineering (Section 5 of RFC6748). Cheers, --/Saleem You might even be able to leverage the ILA-R code to implement it. Tom Cheers, --/Saleem Regards, Behcet _______________________________________________ 5gangip mailing list 5gangip@ietf.org https://www.ietf.org/mailman/listinfo/5gangip _______________________________________________ 5gangip mailing list 5gangip@ietf.org https://www.ietf.org/mailman/listinfo/5gangip --_000_F7938DA0F8614543BA7884721A8D20EAstandrewsacuk_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Tom;

On 02 May 2018, at 18:35, Tom Herbert <tom@herbertland.com> wrote:

On Wed, May 2, 2018 at 12:55 AM, Saleem Bhatti <s= aleem@st-andrews.ac.uk> wrote:


On 01 May 2018, at 22:09, Tom Herbert = <tom@quantonium.net= > wrote:

On Tue, May 1, 2018 at 1:56 PM, Behcet Sarikaya <sarikaya2012@gmail.com> wrote:
Hi Tom,

With SIR fixed, I wonder how do you address multi homed UEs in ILA?
Maybe you did not need it for VMs because they are not multi homed but UEs<= br class=3D""> definitely have multiple interfaces.

That's a tough problem. If both interfaces are in the same ILA domain,
then there's no issue it should just work. If they're not then
something needs to be done across domains for it to work seamlessly
where addresses associated in one domain can be routed in another.

ILNP treats it using two different loc= ators but same identifier which seems
reasonable.

But then locators are exposed to end devices-- privacy problem.

ILNP offers options for location privacy, without tunnelling or loss of end= -to-end semantics for a flow - please section 7 of RFC6748.

Hi Saleem,

From RFC6748:

"To enable this function, we use a middlebox that we call the Locator Rewriting Relay... The operation of the LRR is conceptually very
simple.  We assume that the LRR first has mappings as given in
expressions..."

Looks like an LRR is providing almost identical functionality as an
ILA-R.

I do not believe so - the LRR function is very simple, with no control= -plane or management-plane defined (deliberately), but the ILA-R is a more = complex beast. (Possibly, the LRR function could be implemented by a suitab= ly configured ILA-R, I am guessing.)

The LRR is only a simple building block. Examples on how it could be u= sed for providing some level of location privacy are:

1) a localised-/site-numbering scheme at an ingress/egress point (e.g.= as described in Section 2 of RFC6748); or
2) a more complex, network-wide, Tor-like forwarding mechanism (as out= lined in Section III.C of this MILCOM-2011 paper https://tinyurl.com/yd6= 43dm6, summarised in Section 7 of RFC6748)

ILNP does not mandate or exclude either of these, and does not define = a control-plane or management-plane that could be used specifically for eit= her of those two more complex functions: only the Locator-Update handshake = (via ICMP) is defined (Section 6 of RFC6741, and RFC6743).

The key point is that the locator value can be re-writtern for packets= on the fly, as required, in order to implement various locat{or|ion} obfus= cation mechanisms (for privacy), and/or explicit forwarding, without impact= ing end-to-end state. Possible examples are: 

- site-multihoming (Section 3 of RFC6748);
- site-/network-mobility (Section 4 of RFC6748); and
- and some coarse-grained traffic-engineering (Section 5 of RFC6748).<= /div>

Cheers,
--/Saleem


You might even be able to leverage the ILA-R code to implement
it.

Tom


Cheers,
--/Saleem



Regards,
Behcet



_______________________________________________
5gangip mailing list
5gangip@ietf.org
https:= //www.ietf.org/mailman/listinfo/5gangip


_______________________________________________
5gangip mailing list
5gangip@ietf.org
https:= //www.ietf.org/mailman/listinfo/5gangip

--_000_F7938DA0F8614543BA7884721A8D20EAstandrewsacuk_-- From nobody Thu May 3 09:23:44 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2865C12E8EF; Thu, 3 May 2018 09:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 qWEl59jj_ctv; Thu, 3 May 2018 09:23:35 -0700 (PDT) Received: from mailout34.telekom.de (MAILOUT34.telekom.de [194.25.225.146]) (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 5CE2A12E8FA; Thu, 3 May 2018 09:23:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1525364614; x=1556900614; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=B+4B5DiBF/2g8dl4/uThQwK5w7vTly7ufT3oVYZOY3M=; b=Wrqy2qsuSanYiaiIFK8ZvfslF9HC6yS+/0Y42gmDlyM+Hiq4SoVJwT5h Oasz+b0FZV5AlZShVP02KigfFb7478Q/DF94IZFGvJl0BcnxjyYTUzrQ4 leeRx2Cf4siwj8VmoPfKJPy57McfPgPTLa28YpvJaptqmmFAjWVlJHtfF yILZeJuEIY6LaitXvjIKBW488Mx8jUdcOc5Z3Ucqbf6svtdTU6XUBg1S6 qCTDHvEKzAhvttE4TOWvQtjYyzrHKGl07aysXAK8dUBwx4SpSm9FeQHoH MndlUVQea2oZGeokXlFFGRVh+v+Hav2o6rnGCJVRFR0IQRFI1JHe3w1zL Q==; Received: from qde9xy.de.t-internal.com ([10.171.254.32]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2018 18:23:31 +0200 X-IronPort-AV: E=Sophos;i="5.48,405,1517871600"; d="scan'208";a="38697576" Received: from he105715.emea1.cds.t-internal.com ([10.169.118.51]) by QDE9Y1.de.t-internal.com with ESMTP/TLS/AES256-SHA; 03 May 2018 18:23:30 +0200 Received: from HE105715.EMEA1.cds.t-internal.com (10.169.118.51) by HE105715.emea1.cds.t-internal.com (10.169.118.51) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 3 May 2018 18:23:29 +0200 Received: from HE105715.EMEA1.cds.t-internal.com ([fe80::e4a0:cc4:20d4:3019]) by HE105715.emea1.cds.t-internal.com ([fe80::e4a0:cc4:20d4:3019%26]) with mapi id 15.00.1365.000; Thu, 3 May 2018 18:23:29 +0200 From: To: , CC: , , , <5gangip@ietf.org> Thread-Topic: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement] Thread-Index: AQHT4Z6+IvdqzMlKcEKdXJ287nA5XKQbYSMAgALNhcA= Date: Thu, 3 May 2018 16:23:29 +0000 Message-ID: <8aee42db5f0f407c86fda881769ceb77@HE105715.emea1.cds.t-internal.com> References: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.17.15] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 16:23:42 -0000 Hi Tom, I understand you correctly that DDOS attacks can never be completely preven= ted whatever protocol you use.=20 It will however always remain related to known IP addresses and the more ve= rsatile these are handled a mitigation strategy could be designed. As you may have seen we mention improved handling of mapping systems and su= bsequently of DDOS protection also in the current version of our PS documen= t https://github.com/bsarikaya/atic/blob/master/atick_problemstatement.3.tx= t which Behcet has announced recently. May I ask you to please comment on the ideas outlined there? Thanks! Best Regards Dirk=20 -----Original Message----- From: 5gangip [mailto:5gangip-bounces@ietf.org] On Behalf Of Tom Herbert Sent: Mittwoch, 2. Mai 2018 01:20 To: Joel M. Halpern Cc: Tom Herbert ; ila@ietf.org; Alberto Rodriguez-Nata= l ; 5GANGIP <5gangip@ietf.org> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement] On Tue, May 1, 2018 at 3:49 PM, Joel M. Halpern wrote= : > You seem to be saying that even though not all DDOS attacks are=20 > structurally the same, and even though if ILA were widely adopted not=20 > all ILA networks would be structurally the same, there should=20 > nonetheless be one required qay of handling DDOS? Yes, at least as core default in the protocol. It's precisely _because_ not= all DDOS attacks are structurally the same. An attacker is not going to co= nform to to our expectations of what they should be doing, so if we enable = LISP option N to mitigate one form of attack, they will just use another at= tack that isn't mitigated. For example, if the mitigation is to identify at= tackers by address when requests from the address exceed a threshold then t= his works as long as the attacker strikes from one machine, but it falls ap= art if the attacker launches a DDOS attack from several hosts where request= s from none of the hosts exceed the threshold. The ILA model works because it assumes there is no absolute way to prevent = the the worst case attack on a cache which is to completely kill it (i.e. d= rive it to 0% hit rate). In this state the behavior sub-optimal routing, wh= ich is much better than loss of service. This is not dependent on the struc= ture of the attack, network topology, or the network operator getting the c= onfiguration just right-- it is inherent in the protocol. Tom > > Yours, > Joel > > > On 5/1/18 6:32 PM, Tom Herbert wrote: >> >> On Tue, May 1, 2018 at 2:59 PM, Alberto Rodriguez-Natal=20 >> wrote: >>> >>> On Tue, May 1, 2018 at 10:16 AM, Tom Herbert wrot= e: >>>> >>>> >>>> I think you've misunderstood my position. Caches are _very_=20 >>>> important to eliminate the cost triangular routing (latency, average p= ath load). >>>> This reduces latency and reduces average load on ILA-Rs. But, and=20 >>>> this is the critical part, caches are only an _optimization_ in=20 >>>> ILA. That means if the cache is rendered ineffective (like by a=20 >>>> well crafted DOS >>>> attack) then the only effect is that the optimization is loss (i.e. >>>> greater latency due to triangular router)-- this is quantitively=20 >>>> the worst effect of the attack on an ILA cache. This can be=20 >>>> contrasted that to LISP where the worst case effects of a DOS=20 >>>> attack on the cache is loss of service for users (infinite latency=20 >>>> since packets can be dropped or indefinitely blocked on a cache miss). >>> >>> >>> >>> This can be misleading. This is not comparing LISP vs ILA, this is=20 >>> comparing the models of Request/Reply at the edge vs Notifications=20 >>> (aka Redirects) at the core. Both LISP-CP and ILAMP support these=20 >>> two models. >>> >>> Besides, this is assuming an scenario where the only feasible DOS=20 >>> mitigation is absorbing the attack. There are other scenarios where=20 >>> other countermeasures are possible. For instance, if you have a=20 >>> deployment where you can prevent address spoofing, counting and=20 >>> blocking misbehaving nodes offers similar DOS protection and=20 >>> requires way less infrastructure resources. >>> >> Alberto, >> >> The answer to my question of how does LISP address DOS attacks seems=20 >> to be "there are many options". Some of the options are to assume=20 >> that DOS does not exist in the network, some assume external=20 >> configuration like address spoofing is enabled, some assume that=20 >> attacks can be identified and can be stopped at the source, some=20 >> might assume that everything is okay because there's never been a DOS=20 >> attack before. I have yet to see the effects of any of these=20 >> quantified, and none of these state how the LISP _protocol_ itself=20 >> addresses DOS. It may seem counter-intuitive, but offering a bunch of=20 >> options really is not necessarily a good thing-- sometime less is=20 >> more. To put this another way LISP has been rejected from Linux=20 >> precisely because of its susceptibility to DOS. If you were to try=20 >> again and the best answer to the DOS question is that it's up to the=20 >> operator to figure out the right options to use, then I believe it=20 >> would be soundly rejected again. That approach does not work at scale. >> >> Tom >> >> _______________________________________________ >> ila mailing list >> ila@ietf.org >> https://www.ietf.org/mailman/listinfo/ila >> > _______________________________________________ 5gangip mailing list 5gangip@ietf.org https://www.ietf.org/mailman/listinfo/5gangip From nobody Thu May 3 10:46:27 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98C012EA8F for ; Thu, 3 May 2018 10:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.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 LoG0axX2QoHy for ; Thu, 3 May 2018 10:46:18 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::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 33C5E124217 for ; Thu, 3 May 2018 10:46:18 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id f2-v6so6672872wrm.3 for ; Thu, 03 May 2018 10:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=KD5XeQxBIvQe+rzE1Jfyb/F7xX529Yy/9A3H4GSofVA=; b=L+n3uKvGKAbEctV4aC5il91LfrKGPwCcOloesn7LUf8gMfcsCnIcCnAPicyRyhD8Iv T6DodJUl84F6dSnmoPvoGDoMUA7tRqle7FWB0iNJK0bsZxKuIkIEgiUR+S688gcIbRYB QsWnqSyKERxFfZ9RNfWmR8cWXqHHpUsbgXlC1rax6x0DKcNDNr3GsuasIfKhwasGdrzb 1R2GzfjAWJmHma5DhD7B8Ho4k52yUQ27Lk/OWXoSAPdPM/POr70CBzii1iO/cEeAx981 4qo4m8Kuqf/ADLNsPpSgbVgngbsX1pM3U78WlYA5KwJLepAocSux7cfLYoIPNhSZ8IIF Dvcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=KD5XeQxBIvQe+rzE1Jfyb/F7xX529Yy/9A3H4GSofVA=; b=hmdK64pB15BZSaeM1iYS019qCoe8O3sRrHECzbd8S5yuNZms4VqFp3btkvj6eWegI5 PTgyGklUuyfopB4Tkrd2odEjhz5Kyd+aPLiLJFtZH4+C3zpMuweLCVr0bUf1ht9D/wsh es4aoWWfVbIcKpjmYfPMTx9sBls+RrcMoBJvsxq9KXygXaI8Kc3EUoaR5r3SvIOLzMpy kmGQeUDk3UCO3z/XlEAjHXvhOzC7u6wYHN0o0t4O4cGpuiSUY7OuQ7Qdj7PiYnD563ga wNhyZeKEdJvbtMQQU6uCaAoImF+oBshph7SFNcY0v463GhpRlOVN5M02IHhanLfBlF42 R0Ag== X-Gm-Message-State: ALQs6tD9YOH5JgEJQMUL+8xbC5R2fOn1iTtVzBAJ6XKoLpPgFy03FIgD /UsJ9RVGOdGqGdR1RZZ2bSrkx3oVbbgaAl1OkOiaYA== X-Google-Smtp-Source: AB8JxZqnReLpwMyWF7blqS45L3Op4GtUuztaZFJ09x6bIh3Dapm+PfHQE/d3D2R1WIKARmlk0ctkebNAAJORT1s+iIw= X-Received: by 2002:adf:db0b:: with SMTP id s11-v6mr18098526wri.241.1525369576447; Thu, 03 May 2018 10:46:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.227 with HTTP; Thu, 3 May 2018 10:46:15 -0700 (PDT) In-Reply-To: <8aee42db5f0f407c86fda881769ceb77@HE105715.emea1.cds.t-internal.com> References: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> <8aee42db5f0f407c86fda881769ceb77@HE105715.emea1.cds.t-internal.com> From: Tom Herbert Date: Thu, 3 May 2018 10:46:15 -0700 Message-ID: To: Dirk.von-Hugo@telekom.de Cc: "Joel M. Halpern" , Tom Herbert , ila@ietf.org, Alberto Rodriguez-Natal , 5GANGIP <5gangip@ietf.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 17:46:22 -0000 On Thu, May 3, 2018 at 9:23 AM, wrote: > Hi Tom, > I understand you correctly that DDOS attacks can never be completely prev= ented whatever protocol you use. > It will however always remain related to known IP addresses and the more = versatile these are handled a mitigation strategy could be designed. Dirk, I disagree. IP addresses can too easily be spoofed, it's easy to hide identity behind a NAT (see discussion about CGNAT and law enforcement on int-area list), and trying to turn off individual addresses doesn't work if it's a DDOS. This is nothing new. For instance, content providers have long accepted the fact that they can't prevent SYN attacks and there's little point to trying to go back to source IP address (they are always spoofed in a SYN attack). The better strategy is to absorb the attack and minimize the negative effects so that the attack is not worth the effort. > As you may have seen we mention improved handling of mapping systems and = subsequently of DDOS protection also in the current version of our PS docum= ent https://github.com/bsarikaya/atic/blob/master/atick_problemstatement.3.= txt which Behcet has announced recently. > May I ask you to please comment on the ideas outlined there? I don't see much difference in the latest version. For a problem statement, I still think there is too much focus on the solutions and not nearly enough description of what the actual problems are to be solved. Tom > Thanks! > Best Regards > Dirk > > -----Original Message----- > From: 5gangip [mailto:5gangip-bounces@ietf.org] On Behalf Of Tom Herbert > Sent: Mittwoch, 2. Mai 2018 01:20 > To: Joel M. Halpern > Cc: Tom Herbert ; ila@ietf.org; Alberto Rodriguez-Na= tal ; 5GANGIP <5gangip@ietf.org> > Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement] > > On Tue, May 1, 2018 at 3:49 PM, Joel M. Halpern wro= te: >> You seem to be saying that even though not all DDOS attacks are >> structurally the same, and even though if ILA were widely adopted not >> all ILA networks would be structurally the same, there should >> nonetheless be one required qay of handling DDOS? > > Yes, at least as core default in the protocol. It's precisely _because_ n= ot all DDOS attacks are structurally the same. An attacker is not going to = conform to to our expectations of what they should be doing, so if we enabl= e LISP option N to mitigate one form of attack, they will just use another = attack that isn't mitigated. For example, if the mitigation is to identify = attackers by address when requests from the address exceed a threshold then= this works as long as the attacker strikes from one machine, but it falls = apart if the attacker launches a DDOS attack from several hosts where reque= sts from none of the hosts exceed the threshold. > > The ILA model works because it assumes there is no absolute way to preven= t the the worst case attack on a cache which is to completely kill it (i.e.= drive it to 0% hit rate). In this state the behavior sub-optimal routing, = which is much better than loss of service. This is not dependent on the str= ucture of the attack, network topology, or the network operator getting the= configuration just right-- it is inherent in the protocol. > > Tom > >> >> Yours, >> Joel >> >> >> On 5/1/18 6:32 PM, Tom Herbert wrote: >>> >>> On Tue, May 1, 2018 at 2:59 PM, Alberto Rodriguez-Natal >>> wrote: >>>> >>>> On Tue, May 1, 2018 at 10:16 AM, Tom Herbert wro= te: >>>>> >>>>> >>>>> I think you've misunderstood my position. Caches are _very_ >>>>> important to eliminate the cost triangular routing (latency, average = path load). >>>>> This reduces latency and reduces average load on ILA-Rs. But, and >>>>> this is the critical part, caches are only an _optimization_ in >>>>> ILA. That means if the cache is rendered ineffective (like by a >>>>> well crafted DOS >>>>> attack) then the only effect is that the optimization is loss (i.e. >>>>> greater latency due to triangular router)-- this is quantitively >>>>> the worst effect of the attack on an ILA cache. This can be >>>>> contrasted that to LISP where the worst case effects of a DOS >>>>> attack on the cache is loss of service for users (infinite latency >>>>> since packets can be dropped or indefinitely blocked on a cache miss)= . >>>> >>>> >>>> >>>> This can be misleading. This is not comparing LISP vs ILA, this is >>>> comparing the models of Request/Reply at the edge vs Notifications >>>> (aka Redirects) at the core. Both LISP-CP and ILAMP support these >>>> two models. >>>> >>>> Besides, this is assuming an scenario where the only feasible DOS >>>> mitigation is absorbing the attack. There are other scenarios where >>>> other countermeasures are possible. For instance, if you have a >>>> deployment where you can prevent address spoofing, counting and >>>> blocking misbehaving nodes offers similar DOS protection and >>>> requires way less infrastructure resources. >>>> >>> Alberto, >>> >>> The answer to my question of how does LISP address DOS attacks seems >>> to be "there are many options". Some of the options are to assume >>> that DOS does not exist in the network, some assume external >>> configuration like address spoofing is enabled, some assume that >>> attacks can be identified and can be stopped at the source, some >>> might assume that everything is okay because there's never been a DOS >>> attack before. I have yet to see the effects of any of these >>> quantified, and none of these state how the LISP _protocol_ itself >>> addresses DOS. It may seem counter-intuitive, but offering a bunch of >>> options really is not necessarily a good thing-- sometime less is >>> more. To put this another way LISP has been rejected from Linux >>> precisely because of its susceptibility to DOS. If you were to try >>> again and the best answer to the DOS question is that it's up to the >>> operator to figure out the right options to use, then I believe it >>> would be soundly rejected again. That approach does not work at scale. >>> >>> Tom >>> >>> _______________________________________________ >>> ila mailing list >>> ila@ietf.org >>> https://www.ietf.org/mailman/listinfo/ila >>> >> > > _______________________________________________ > 5gangip mailing list > 5gangip@ietf.org > https://www.ietf.org/mailman/listinfo/5gangip From nobody Thu May 3 14:23:42 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7DD12E8DC; Thu, 3 May 2018 14:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 UlJjEYY-jQSh; Thu, 3 May 2018 14:23:38 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 DE5AE126CC7; Thu, 3 May 2018 14:23:37 -0700 (PDT) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id w43LFI5x004408; Thu, 3 May 2018 17:23:34 -0400 Received: from flpd657.enaf.ffdc.sbc.com (sbcsmtp9.sbc.com [144.160.128.153]) by m0083689.ppops.net-00191d01. with ESMTP id 2hr921suc0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 03 May 2018 17:23:34 -0400 Received: from enaf.ffdc.sbc.com (localhost [127.0.0.1]) by flpd657.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id w43LNWm5016343; Thu, 3 May 2018 14:23:32 -0700 Received: from zlp25946.vci.att.com (zlp25946.vci.att.com [135.213.92.138]) by flpd657.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id w43LNP0i016217; Thu, 3 May 2018 14:23:25 -0700 Received: from zlp25946.vci.att.com (zlp25946.vci.att.com [127.0.0.1]) by zlp25946.vci.att.com (Service) with ESMTP id CB9D6412C920; Thu, 3 May 2018 21:23:25 +0000 (GMT) Received: from CAFRFD1MSGHUBAA.ITServices.sbc.com (unknown [130.4.169.178]) by zlp25946.vci.att.com (Service) with ESMTPS id 9EE9F410F442; Thu, 3 May 2018 21:23:25 +0000 (GMT) Received: from CAFRFD1MSGUSRJI.ITServices.sbc.com ([169.254.8.94]) by CAFRFD1MSGHUBAA.ITServices.sbc.com ([130.4.169.178]) with mapi id 14.03.0389.001; Thu, 3 May 2018 14:23:24 -0700 From: "FIGURELLE, TERRY F" To: Tom Herbert , "Dirk.von-Hugo@telekom.de" CC: Tom Herbert , "Joel M. Halpern" , "ila@ietf.org" , Alberto Rodriguez-Natal , 5GANGIP <5gangip@ietf.org> Thread-Topic: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement] Thread-Index: AQHT4wasd9k0kyItlUiMNTfEFG8rxqQebc2g Date: Thu, 3 May 2018 21:23:23 +0000 Message-ID: <1AFE10CF28AE8B4C9663445736B8034D3822FAFE@CAFRFD1MSGUSRJI.ITServices.sbc.com> References: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> <8aee42db5f0f407c86fda881769ceb77@HE105715.emea1.cds.t-internal.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.49.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-03_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805030183 Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 21:23:41 -0000 In the case of current 3GPP operators all the major vendors support anti-sp= oofing. The default was on for all but one vendor which got corrected the l= ast time I did an RFP for EPC. So by configuration the GGSN/PGW/PGW-U/UPF w= ill not allow the UE to send packets that don't match either the exact IP = address or pushed subnet or prefix delegation that was sent in response to = the APN create message. Obviously if we remove GTP encapsulation that prote= ct MAY need to be enhanced towards an EDGE element.=20 This is being covered as part of our participation in an open source vEPC (= virtualize EPC, hypervisor, blah, blah, blah). So there will be a micro ser= vice firewall that can be deploy at the edge plus we already have planned s= upport for big network infrastructure vendors and 3GPP supplies (Cisco, Jun= iper, Ericsson, Nokia, Huawei, ...) to cover this. Since this can be a non= -3GPP element we will get this into ONAP. Thus we have this covered both for 3GPP nodes, micro services and open sour= ce efforts. To give examples without vendor names there are GTP aware firew= alls that some operators use. It really just another capability in carrier = class and business class firewalls (had to add it to load balancers, CNAT/N= AT, some Wi-Fi routers and to our DNS solution which uses open source). Ob= viously this will be supported via a RADIUS feed for backwards compatibilit= y. Today most GTP firewall simply follow the GTP-C signaling to learn the I= P address(es) assigned to the UE for an APN. If we remove GTP from user pla= ne that doesn't mean we remove it from control plane or for all hops. Howev= er, we will likely push to a micro service at the cell plus I need to check= if we ever ask RAN vendors to support this. I'll add this for 5G but we al= ready did that RFP so it's a change order (yuck). I am not good at wordsmithing but I suggest there be some paragraph that co= vers network elements that can except a RADIUS feed. I need to talk to our = standards team to see if we want this on T8 (probably). So today for all AT&T, Verizon, Vodaphone, ..... I know or am fairly confi= dent they have anti spoofing tuned on in the GGSN/PGW/UPF plus I know they = can turn this on per APN. Not sure why anyone would disable this since we i= f you are delegating a subnet to a Wi-Fi hotspot (instead of the typical pr= ivate addressing they use). We actually don't need any 3GPP changes since this is already covered using= RADIUS to pass the information where it needs to go. I suspect most will l= everage their caching SPR/UDR which already has the information. Even the G= GSN we launched EDGE/GPRS when I was much younger supported anti-spoofing a= nd many vendors cover this via a number of methods (e.g. COPS works for old= er junos and RADIUS for Cisco IOS releases ).=20 My suggestion is that I am willing to help whoever wants to craft the parag= raph because I suck at that (fortunately I am good at other things). I don't think we need any changes to any standards to cover this since we a= lready cover this and already are covering this if we strip out GTP (at lea= st for one leg). I'll make sure it gets into our RAN requirements if not th= ere since that may be the best place for that edge. Plus I'll get it covere= d thru the ONAP open source effort we drove (we donated the software to the= open source effort). That means FM, PM, CM and IM will be covered in some = future ONAP release (takes time but faster than 3GPP). It's a bit debatable what is RAN when using virtualized network functions (= VNF) and a bunch of open source stuff that we put it into all of the needed= elements like SDN, firewall, load balancer (not sure that's needed at cell= site but it is for core DNS, proxy-TDF and CNAT) out at the cell site. We = aren't there yet (still physical eNB/NR and obviously we need hardware assi= st even with virtualization plus tight control of timing). I am looking for= ward to when we start using containers. For our core I am sure we will use our UDR VNF as the cache for whatever co= mes out of this effort in final standards. The information is already there= (IMEI, device vendor, subscription information, UE IP address, APN, etc.).= If we do anything it would be to augment an open source and if needed a 3G= PP. I don't think we need any changes but it's always best to verify. For c= urrent RAN an anti-spoofing feature would come from EMS which can be via ON= AP. I don't think that is a standards effort thing since it's a feature whi= ch may or may not already be covered but it will be in future RAN releases = probably starting with eNB/NR with some vendor release if it's not already = a feature. I want to say Ericsson and Nokia already can do this in eNB but = I need to go thru channels to ask. So maybe that paragraph recommends implementing anti-spoofing at all edges = and leaves it at that. Or we could say all edges including RAN if that make= s people happy. =20 > -----Original Message----- > From: 5gangip <5gangip-bounces@ietf.org> On Behalf Of Tom Herbert > Sent: Thursday, May 03, 2018 10:46 AM > To: Dirk.von-Hugo@telekom.de > Cc: Tom Herbert ; Joel M. Halpern > ; ila@ietf.org; Alberto Rodriguez-Natal > ; 5GANGIP <5gangip@ietf.org> > Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement] >=20 > On Thu, May 3, 2018 at 9:23 AM, wrote: > > Hi Tom, > > I understand you correctly that DDOS attacks can never be completely > prevented whatever protocol you use. > > It will however always remain related to known IP addresses and the mor= e > versatile these are handled a mitigation strategy could be designed. >=20 > Dirk, >=20 > I disagree. IP addresses can too easily be spoofed, it's easy to hide ide= ntity > behind a NAT (see discussion about CGNAT and law enforcement on int-area > list), and trying to turn off individual addresses doesn't work if it's a= DDOS. This > is nothing new. For instance, content providers have long accepted the fa= ct that > they can't prevent SYN attacks and there's little point to trying to go b= ack to > source IP address (they are always spoofed in a SYN attack). The better s= trategy > is to absorb the attack and minimize the negative effects so that the att= ack is > not worth the effort. >=20 > > As you may have seen we mention improved handling of mapping systems > and subsequently of DDOS protection also in the current version of our PS > document https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__github.com_bsarikaya_atic_blob_master_atick- > 5Fproblemstatement.3.txt&d=3DDwICAg&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4 > OstVOL1OQiA98fgBJ9c1Gjo&s=3DjLL_9a56R8Ic8o3uJcR8mrF- > JkzLL97h8rmZT_EqXnQ&e=3D which Behcet has announced recently. > > May I ask you to please comment on the ideas outlined there? >=20 > I don't see much difference in the latest version. For a problem statemen= t, I still > think there is too much focus on the solutions and not nearly enough > description of what the actual problems are to be solved. >=20 > Tom >=20 > > Thanks! >=20 > > Best Regards > > Dirk > > > > -----Original Message----- > > From: 5gangip [mailto:5gangip-bounces@ietf.org] On Behalf Of Tom > > Herbert > > Sent: Mittwoch, 2. Mai 2018 01:20 > > To: Joel M. Halpern > > Cc: Tom Herbert ; ila@ietf.org; Alberto > > Rodriguez-Natal ; 5GANGIP <5gangip@ietf.org> > > Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement] > > > > On Tue, May 1, 2018 at 3:49 PM, Joel M. Halpern > wrote: > >> You seem to be saying that even though not all DDOS attacks are > >> structurally the same, and even though if ILA were widely adopted not > >> all ILA networks would be structurally the same, there should > >> nonetheless be one required qay of handling DDOS? > > > > Yes, at least as core default in the protocol. It's precisely _because_= not all > DDOS attacks are structurally the same. An attacker is not going to confo= rm to > to our expectations of what they should be doing, so if we enable LISP op= tion N > to mitigate one form of attack, they will just use another attack that is= n't > mitigated. For example, if the mitigation is to identify attackers by add= ress > when requests from the address exceed a threshold then this works as long= as > the attacker strikes from one machine, but it falls apart if the attacker= launches > a DDOS attack from several hosts where requests from none of the hosts > exceed the threshold. > > > > The ILA model works because it assumes there is no absolute way to prev= ent > the the worst case attack on a cache which is to completely kill it (i.e.= drive it to > 0% hit rate). In this state the behavior sub-optimal routing, which is mu= ch > better than loss of service. This is not dependent on the structure of th= e attack, > network topology, or the network operator getting the configuration just = right-- > it is inherent in the protocol. > > > > Tom > > > >> > >> Yours, > >> Joel > >> > >> > >> On 5/1/18 6:32 PM, Tom Herbert wrote: > >>> > >>> On Tue, May 1, 2018 at 2:59 PM, Alberto Rodriguez-Natal > >>> wrote: > >>>> > >>>> On Tue, May 1, 2018 at 10:16 AM, Tom Herbert > wrote: > >>>>> > >>>>> > >>>>> I think you've misunderstood my position. Caches are _very_ > >>>>> important to eliminate the cost triangular routing (latency, averag= e path > load). > >>>>> This reduces latency and reduces average load on ILA-Rs. But, and > >>>>> this is the critical part, caches are only an _optimization_ in > >>>>> ILA. That means if the cache is rendered ineffective (like by a > >>>>> well crafted DOS > >>>>> attack) then the only effect is that the optimization is loss (i.e. > >>>>> greater latency due to triangular router)-- this is quantitively > >>>>> the worst effect of the attack on an ILA cache. This can be > >>>>> contrasted that to LISP where the worst case effects of a DOS > >>>>> attack on the cache is loss of service for users (infinite latency > >>>>> since packets can be dropped or indefinitely blocked on a cache mis= s). > >>>> > >>>> > >>>> > >>>> This can be misleading. This is not comparing LISP vs ILA, this is > >>>> comparing the models of Request/Reply at the edge vs Notifications > >>>> (aka Redirects) at the core. Both LISP-CP and ILAMP support these > >>>> two models. > >>>> > >>>> Besides, this is assuming an scenario where the only feasible DOS > >>>> mitigation is absorbing the attack. There are other scenarios where > >>>> other countermeasures are possible. For instance, if you have a > >>>> deployment where you can prevent address spoofing, counting and > >>>> blocking misbehaving nodes offers similar DOS protection and > >>>> requires way less infrastructure resources. > >>>> > >>> Alberto, > >>> > >>> The answer to my question of how does LISP address DOS attacks seems > >>> to be "there are many options". Some of the options are to assume > >>> that DOS does not exist in the network, some assume external > >>> configuration like address spoofing is enabled, some assume that > >>> attacks can be identified and can be stopped at the source, some > >>> might assume that everything is okay because there's never been a > >>> DOS attack before. I have yet to see the effects of any of these > >>> quantified, and none of these state how the LISP _protocol_ itself > >>> addresses DOS. It may seem counter-intuitive, but offering a bunch > >>> of options really is not necessarily a good thing-- sometime less is > >>> more. To put this another way LISP has been rejected from Linux > >>> precisely because of its susceptibility to DOS. If you were to try > >>> again and the best answer to the DOS question is that it's up to the > >>> operator to figure out the right options to use, then I believe it > >>> would be soundly rejected again. That approach does not work at scale= . > >>> > >>> Tom > >>> > >>> _______________________________________________ > >>> ila mailing list > >>> ila@ietf.org > >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_m= a > >>> ilman_listinfo_ila&d=3DDwICAg&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl > >>> > 2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4OstVOL1OQiA98fgBJ9c1Gjo&s=3DBO3snt8C > RQ > >>> gy1xwhx2CY10VUbM_rgntgpV9k3-Cskd8&e=3D > >>> > >> > > > > _______________________________________________ > > 5gangip mailing list > > 5gangip@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= l > > man_listinfo_5gangip&d=3DDwICAg&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl > > > 2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4OstVOL1OQiA98fgBJ9c1Gjo&s=3DFnQLMire > MiKC > > SkPaOGFCybzDc2i2y49Cgtbl6mCLc9c&e=3D >=20 > _______________________________________________ > 5gangip mailing list > 5gangip@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_5gangip&d=3DDwICAg&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4 > OstVOL1OQiA98fgBJ9c1Gjo&s=3DFnQLMireMiKCSkPaOGFCybzDc2i2y49Cgtbl6mC > Lc9c&e=3D From nobody Thu May 3 14:33:44 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F4212EAE9 for ; Thu, 3 May 2018 14:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.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 X55XKQ8BfVyT for ; Thu, 3 May 2018 14:33:39 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::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 DEB6E12EAE3 for ; Thu, 3 May 2018 14:33:38 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id g21-v6so19034538wrb.8 for ; Thu, 03 May 2018 14:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=FX8ThAfjE0Q7R0N9Asgea+P7fU/UVdAQN+SrrP2QKhY=; b=MgjlJzVEfk8r2pbwCjJ4nESatJS/6wgBXNhFoLITyBuo8eqzJLTfWeAhlceyEWGMW0 YJ+UyBeBGamVmyr4ki7YSfycZ8co4xkTaQD88xVUoe80mKNx/fh29anYWI5Zy95ZIXYK OpWeG5OcosRwVvYFI/AqG23JO320V699GpKcRpnV633nunNVXvQ9i2Ipi2CZcVw932MC ad8RX1+cwCEbGWtw5TmC8vIwnb47yhaKXJSSqPhCDZ6wq6tpGpWbDumHob2HIH8TiUg/ MMJ2W8d8ootvUJp5qivXx1+uvGm2L9bdWvgJlZ4ZhWqV55Q3wkZpr/SAeajztMZRxXvV 0rTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=FX8ThAfjE0Q7R0N9Asgea+P7fU/UVdAQN+SrrP2QKhY=; b=iimATlLtjmsGR35yq97SRwspgy9eDgngWn2VIacAvT4DRiZGGWwvxBGRmHU9HVYNvO fop8+p6B0eVtzW67pXHa7v0jCeJ+OFX0NVNGqf7Yd9qNxqd0BRzjF9lFaMDgvw0EL4lA 1otCyfIB+GuQc4Bo9/8CVZZQIa8wHHcD7M+BDI48QFPueXWzZUEnAj9XO5bwfliKYVJr iamanNsNUnT6jQaHi82YqCvknzsmbCSAezkU/V8APxLRL+PB3+7F7U+WvYvu5T/3BeJR tOUvU9Grl0wwkv4B9mzhhmFclM3gnfldSHI/fc+VY6NRlibI9rZjdE59Ko9SN1Mp38Ez kC9w== X-Gm-Message-State: ALQs6tCG3QmwUnxCcflHubJMyeU7yftAkKgsQcPe47luNfiAlAfegSIC IZT21fjKpEgFLuoxoaD0sLNRAazQra7ysyJ3Zms3aQ== X-Google-Smtp-Source: AB8JxZqWJLdVWPaERAwx2wNjQl1C304eVHu8DmIhAXdX7CGcMgVNhX7LxMJMspZw+sTOTSr9KNrlfLzyuXO6KSe5MCo= X-Received: by 2002:adf:db0b:: with SMTP id s11-v6mr18511068wri.241.1525383217173; Thu, 03 May 2018 14:33:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.227 with HTTP; Thu, 3 May 2018 14:33:36 -0700 (PDT) In-Reply-To: <1AFE10CF28AE8B4C9663445736B8034D3822FAFE@CAFRFD1MSGUSRJI.ITServices.sbc.com> References: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> <8aee42db5f0f407c86fda881769ceb77@HE105715.emea1.cds.t-internal.com> <1AFE10CF28AE8B4C9663445736B8034D3822FAFE@CAFRFD1MSGUSRJI.ITServices.sbc.com> From: Tom Herbert Date: Thu, 3 May 2018 14:33:36 -0700 Message-ID: To: "FIGURELLE, TERRY F" Cc: "Dirk.von-Hugo@telekom.de" , Tom Herbert , "Joel M. Halpern" , "ila@ietf.org" , Alberto Rodriguez-Natal , 5GANGIP <5gangip@ietf.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 21:33:43 -0000 On Thu, May 3, 2018 at 2:23 PM, FIGURELLE, TERRY F wrote: > In the case of current 3GPP operators all the major vendors support anti-= spoofing. The default was on for all but one vendor which got corrected the= last time I did an RFP for EPC. So by configuration the GGSN/PGW/PGW-U/UPF= will not allow the UE to send packets that don't match either the exact I= P address or pushed subnet or prefix delegation that was sent in response t= o the APN create message. Obviously if we remove GTP encapsulation that pro= tect MAY need to be enhanced towards an EDGE element. > Terry, Even so, the whole Internet does not require anti-spoofing, nor do I believe that operators could require all down stream network that are connected to support anti-spoofing. These are where the DOS attacks orginate. The problem is when caches are being driven by user taffic from these external networks, mitigations to detect DOS by IP source address don't work without anti-spoofing (but even if they had anti-spoofing that still doesn't work when under a DDOS). Tom > This is being covered as part of our participation in an open source vEPC= (virtualize EPC, hypervisor, blah, blah, blah). So there will be a micro s= ervice firewall that can be deploy at the edge plus we already have planned= support for big network infrastructure vendors and 3GPP supplies (Cisco, J= uniper, Ericsson, Nokia, Huawei, ...) to cover this. Since this can be a n= on-3GPP element we will get this into ONAP. > > Thus we have this covered both for 3GPP nodes, micro services and open so= urce efforts. To give examples without vendor names there are GTP aware fir= ewalls that some operators use. It really just another capability in carrie= r class and business class firewalls (had to add it to load balancers, CNAT= /NAT, some Wi-Fi routers and to our DNS solution which uses open source). = Obviously this will be supported via a RADIUS feed for backwards compatibil= ity. Today most GTP firewall simply follow the GTP-C signaling to learn the= IP address(es) assigned to the UE for an APN. If we remove GTP from user p= lane that doesn't mean we remove it from control plane or for all hops. How= ever, we will likely push to a micro service at the cell plus I need to che= ck if we ever ask RAN vendors to support this. I'll add this for 5G but we = already did that RFP so it's a change order (yuck). > > I am not good at wordsmithing but I suggest there be some paragraph that = covers network elements that can except a RADIUS feed. I need to talk to ou= r standards team to see if we want this on T8 (probably). > > So today for all AT&T, Verizon, Vodaphone, ..... I know or am fairly con= fident they have anti spoofing tuned on in the GGSN/PGW/UPF plus I know the= y can turn this on per APN. Not sure why anyone would disable this since we= if you are delegating a subnet to a Wi-Fi hotspot (instead of the typical = private addressing they use). > > We actually don't need any 3GPP changes since this is already covered usi= ng RADIUS to pass the information where it needs to go. I suspect most will= leverage their caching SPR/UDR which already has the information. Even the= GGSN we launched EDGE/GPRS when I was much younger supported anti-spoofing= and many vendors cover this via a number of methods (e.g. COPS works for o= lder junos and RADIUS for Cisco IOS releases ). > > My suggestion is that I am willing to help whoever wants to craft the par= agraph because I suck at that (fortunately I am good at other things). > > I don't think we need any changes to any standards to cover this since we= already cover this and already are covering this if we strip out GTP (at l= east for one leg). I'll make sure it gets into our RAN requirements if not = there since that may be the best place for that edge. Plus I'll get it cove= red thru the ONAP open source effort we drove (we donated the software to t= he open source effort). That means FM, PM, CM and IM will be covered in som= e future ONAP release (takes time but faster than 3GPP). > > It's a bit debatable what is RAN when using virtualized network functions= (VNF) and a bunch of open source stuff that we put it into all of the need= ed elements like SDN, firewall, load balancer (not sure that's needed at ce= ll site but it is for core DNS, proxy-TDF and CNAT) out at the cell site. W= e aren't there yet (still physical eNB/NR and obviously we need hardware as= sist even with virtualization plus tight control of timing). I am looking f= orward to when we start using containers. > > For our core I am sure we will use our UDR VNF as the cache for whatever = comes out of this effort in final standards. The information is already the= re (IMEI, device vendor, subscription information, UE IP address, APN, etc.= ). If we do anything it would be to augment an open source and if needed a = 3GPP. I don't think we need any changes but it's always best to verify. For= current RAN an anti-spoofing feature would come from EMS which can be via = ONAP. I don't think that is a standards effort thing since it's a feature w= hich may or may not already be covered but it will be in future RAN release= s probably starting with eNB/NR with some vendor release if it's not alread= y a feature. I want to say Ericsson and Nokia already can do this in eNB bu= t I need to go thru channels to ask. > > So maybe that paragraph recommends implementing anti-spoofing at all edge= s and leaves it at that. Or we could say all edges including RAN if that ma= kes people happy. > >> -----Original Message----- >> From: 5gangip <5gangip-bounces@ietf.org> On Behalf Of Tom Herbert >> Sent: Thursday, May 03, 2018 10:46 AM >> To: Dirk.von-Hugo@telekom.de >> Cc: Tom Herbert ; Joel M. Halpern >> ; ila@ietf.org; Alberto Rodriguez-Natal >> ; 5GANGIP <5gangip@ietf.org> >> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement] >> >> On Thu, May 3, 2018 at 9:23 AM, wrote: >> > Hi Tom, >> > I understand you correctly that DDOS attacks can never be completely >> prevented whatever protocol you use. >> > It will however always remain related to known IP addresses and the mo= re >> versatile these are handled a mitigation strategy could be designed. >> >> Dirk, >> >> I disagree. IP addresses can too easily be spoofed, it's easy to hide id= entity >> behind a NAT (see discussion about CGNAT and law enforcement on int-area >> list), and trying to turn off individual addresses doesn't work if it's = a DDOS. This >> is nothing new. For instance, content providers have long accepted the f= act that >> they can't prevent SYN attacks and there's little point to trying to go = back to >> source IP address (they are always spoofed in a SYN attack). The better = strategy >> is to absorb the attack and minimize the negative effects so that the at= tack is >> not worth the effort. >> >> > As you may have seen we mention improved handling of mapping systems >> and subsequently of DDOS protection also in the current version of our P= S >> document https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__github.com_bsarikaya_atic_blob_master_atick- >> 5Fproblemstatement.3.txt&d=3DDwICAg&c=3DLFYZ- >> o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4 >> OstVOL1OQiA98fgBJ9c1Gjo&s=3DjLL_9a56R8Ic8o3uJcR8mrF- >> JkzLL97h8rmZT_EqXnQ&e=3D which Behcet has announced recently. >> > May I ask you to please comment on the ideas outlined there? >> >> I don't see much difference in the latest version. For a problem stateme= nt, I still >> think there is too much focus on the solutions and not nearly enough >> description of what the actual problems are to be solved. >> >> Tom >> >> > Thanks! >> >> > Best Regards >> > Dirk >> > >> > -----Original Message----- >> > From: 5gangip [mailto:5gangip-bounces@ietf.org] On Behalf Of Tom >> > Herbert >> > Sent: Mittwoch, 2. Mai 2018 01:20 >> > To: Joel M. Halpern >> > Cc: Tom Herbert ; ila@ietf.org; Alberto >> > Rodriguez-Natal ; 5GANGIP <5gangip@ietf.org> >> > Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement] >> > >> > On Tue, May 1, 2018 at 3:49 PM, Joel M. Halpern >> wrote: >> >> You seem to be saying that even though not all DDOS attacks are >> >> structurally the same, and even though if ILA were widely adopted not >> >> all ILA networks would be structurally the same, there should >> >> nonetheless be one required qay of handling DDOS? >> > >> > Yes, at least as core default in the protocol. It's precisely _because= _ not all >> DDOS attacks are structurally the same. An attacker is not going to conf= orm to >> to our expectations of what they should be doing, so if we enable LISP o= ption N >> to mitigate one form of attack, they will just use another attack that i= sn't >> mitigated. For example, if the mitigation is to identify attackers by ad= dress >> when requests from the address exceed a threshold then this works as lon= g as >> the attacker strikes from one machine, but it falls apart if the attacke= r launches >> a DDOS attack from several hosts where requests from none of the hosts >> exceed the threshold. >> > >> > The ILA model works because it assumes there is no absolute way to pre= vent >> the the worst case attack on a cache which is to completely kill it (i.e= . drive it to >> 0% hit rate). In this state the behavior sub-optimal routing, which is m= uch >> better than loss of service. This is not dependent on the structure of t= he attack, >> network topology, or the network operator getting the configuration just= right-- >> it is inherent in the protocol. >> > >> > Tom >> > >> >> >> >> Yours, >> >> Joel >> >> >> >> >> >> On 5/1/18 6:32 PM, Tom Herbert wrote: >> >>> >> >>> On Tue, May 1, 2018 at 2:59 PM, Alberto Rodriguez-Natal >> >>> wrote: >> >>>> >> >>>> On Tue, May 1, 2018 at 10:16 AM, Tom Herbert >> wrote: >> >>>>> >> >>>>> >> >>>>> I think you've misunderstood my position. Caches are _very_ >> >>>>> important to eliminate the cost triangular routing (latency, avera= ge path >> load). >> >>>>> This reduces latency and reduces average load on ILA-Rs. But, and >> >>>>> this is the critical part, caches are only an _optimization_ in >> >>>>> ILA. That means if the cache is rendered ineffective (like by a >> >>>>> well crafted DOS >> >>>>> attack) then the only effect is that the optimization is loss (i.e= . >> >>>>> greater latency due to triangular router)-- this is quantitively >> >>>>> the worst effect of the attack on an ILA cache. This can be >> >>>>> contrasted that to LISP where the worst case effects of a DOS >> >>>>> attack on the cache is loss of service for users (infinite latency >> >>>>> since packets can be dropped or indefinitely blocked on a cache mi= ss). >> >>>> >> >>>> >> >>>> >> >>>> This can be misleading. This is not comparing LISP vs ILA, this is >> >>>> comparing the models of Request/Reply at the edge vs Notifications >> >>>> (aka Redirects) at the core. Both LISP-CP and ILAMP support these >> >>>> two models. >> >>>> >> >>>> Besides, this is assuming an scenario where the only feasible DOS >> >>>> mitigation is absorbing the attack. There are other scenarios where >> >>>> other countermeasures are possible. For instance, if you have a >> >>>> deployment where you can prevent address spoofing, counting and >> >>>> blocking misbehaving nodes offers similar DOS protection and >> >>>> requires way less infrastructure resources. >> >>>> >> >>> Alberto, >> >>> >> >>> The answer to my question of how does LISP address DOS attacks seems >> >>> to be "there are many options". Some of the options are to assume >> >>> that DOS does not exist in the network, some assume external >> >>> configuration like address spoofing is enabled, some assume that >> >>> attacks can be identified and can be stopped at the source, some >> >>> might assume that everything is okay because there's never been a >> >>> DOS attack before. I have yet to see the effects of any of these >> >>> quantified, and none of these state how the LISP _protocol_ itself >> >>> addresses DOS. It may seem counter-intuitive, but offering a bunch >> >>> of options really is not necessarily a good thing-- sometime less is >> >>> more. To put this another way LISP has been rejected from Linux >> >>> precisely because of its susceptibility to DOS. If you were to try >> >>> again and the best answer to the DOS question is that it's up to the >> >>> operator to figure out the right options to use, then I believe it >> >>> would be soundly rejected again. That approach does not work at scal= e. >> >>> >> >>> Tom >> >>> >> >>> _______________________________________________ >> >>> ila mailing list >> >>> ila@ietf.org >> >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_= ma >> >>> ilman_listinfo_ila&d=3DDwICAg&c=3DLFYZ- >> o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl >> >>> >> 2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4OstVOL1OQiA98fgBJ9c1Gjo&s=3DBO3snt8C >> RQ >> >>> gy1xwhx2CY10VUbM_rgntgpV9k3-Cskd8&e=3D >> >>> >> >> >> > >> > _______________________________________________ >> > 5gangip mailing list >> > 5gangip@ietf.org >> > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= il >> > man_listinfo_5gangip&d=3DDwICAg&c=3DLFYZ- >> o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl >> > >> 2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4OstVOL1OQiA98fgBJ9c1Gjo&s=3DFnQLMire >> MiKC >> > SkPaOGFCybzDc2i2y49Cgtbl6mCLc9c&e=3D >> >> _______________________________________________ >> 5gangip mailing list >> 5gangip@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.ietf.org_mailman_listinfo_5gangip&d=3DDwICAg&c=3DLFYZ- >> o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4 >> OstVOL1OQiA98fgBJ9c1Gjo&s=3DFnQLMireMiKCSkPaOGFCybzDc2i2y49Cgtbl6mC >> Lc9c&e=3D From nobody Thu May 3 14:45:55 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1883E12EA67; Thu, 3 May 2018 14:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 BpdVEVXZqkFz; Thu, 3 May 2018 14:45:50 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 7E72012420B; Thu, 3 May 2018 14:45:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 5CFC8240E67; Thu, 3 May 2018 14:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1525383950; bh=TAFHU/TiJwNjRCEAfBCJMGlTPITKBBrRNJP2phKk9oo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=q2BGYfAIk7OaEJZ9D4fOqDOen5EAmVaKt81aUrmH2j7yBASKBuuKI1mCzQU2jigiT MO8hk6ZvESLfGKmu5OGum0my2p01X8E8IZdn5xXUglZNYIQ/zzIO+A5mIUQbp0ENqo 0ad8/uqGZtQ+3j7vu+NX7vBaWJp+Seo05YDe2Dlc= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 61D7B24331D; Thu, 3 May 2018 14:45:48 -0700 (PDT) To: Tom Herbert , "FIGURELLE, TERRY F" Cc: "Dirk.von-Hugo@telekom.de" , Tom Herbert , "ila@ietf.org" , Alberto Rodriguez-Natal , 5GANGIP <5gangip@ietf.org> References: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> <8aee42db5f0f407c86fda881769ceb77@HE105715.emea1.cds.t-internal.com> <1AFE10CF28AE8B4C9663445736B8034D3822FAFE@CAFRFD1MSGUSRJI.ITServices.sbc.com> From: "Joel M. Halpern" Message-ID: <0cbb9987-0b47-9428-3db7-2c9fab821268@joelhalpern.com> Date: Thu, 3 May 2018 17:45:47 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 21:45:54 -0000 I am missing something in your DDOS issue. At first, I thought the real issue (which you seem to be suggesting here) was DDOS from the Internet, using spoofed or non-spoofed addresses (with bot farms, there is much less need for or relevance of spoofing). But then I tried to map it to the cases we have for using ILA. The primary case I have heard about is to use ILA for UE<->UE and UE<->EdgeComputing traffic. If so, just filter all SIRs on incoming packets from the Internet. They aren't legal there. And similarly, if one uses LISP within the operator domain, we can block whatever blocks we use for EIDs for such local traffic. If we want to use id-locator split of any kind for handling traffic to / from the Internet, then we have to understand how that is supposed to work, and why, before we need to evaluate DDOS implications of a solution. For LISP,the working group has explicitly said that Inter-wide deployment is out of scope. Net: I do not see in currently described deployments, an issue that differentiates LISP from ILA in these regards. And Terry has very clearly spelled out that for mobile operators spoofing from UEs is not considered an issue that the infrastructure needs to deal wih. Yours, Joel On 5/3/18 5:33 PM, Tom Herbert wrote: > On Thu, May 3, 2018 at 2:23 PM, FIGURELLE, TERRY F wrote: >> In the case of current 3GPP operators all the major vendors support anti-spoofing. The default was on for all but one vendor which got corrected the last time I did an RFP for EPC. So by configuration the GGSN/PGW/PGW-U/UPF will not allow the UE to send packets that don't match either the exact IP address or pushed subnet or prefix delegation that was sent in response to the APN create message. Obviously if we remove GTP encapsulation that protect MAY need to be enhanced towards an EDGE element. >> > Terry, > > Even so, the whole Internet does not require anti-spoofing, nor do I > believe that operators could require all down stream network that are > connected to support anti-spoofing. These are where the DOS attacks > orginate. The problem is when caches are being driven by user taffic > from these external networks, mitigations to detect DOS by IP source > address don't work without anti-spoofing (but even if they had > anti-spoofing that still doesn't work when under a DDOS). > > Tom > > > >> This is being covered as part of our participation in an open source vEPC (virtualize EPC, hypervisor, blah, blah, blah). So there will be a micro service firewall that can be deploy at the edge plus we already have planned support for big network infrastructure vendors and 3GPP supplies (Cisco, Juniper, Ericsson, Nokia, Huawei, ...) to cover this. Since this can be a non-3GPP element we will get this into ONAP. >> >> Thus we have this covered both for 3GPP nodes, micro services and open source efforts. To give examples without vendor names there are GTP aware firewalls that some operators use. It really just another capability in carrier class and business class firewalls (had to add it to load balancers, CNAT/NAT, some Wi-Fi routers and to our DNS solution which uses open source). Obviously this will be supported via a RADIUS feed for backwards compatibility. Today most GTP firewall simply follow the GTP-C signaling to learn the IP address(es) assigned to the UE for an APN. If we remove GTP from user plane that doesn't mean we remove it from control plane or for all hops. However, we will likely push to a micro service at the cell plus I need to check if we ever ask RAN vendors to support this. I'll add this for 5G but we already did that RFP so it's a change order (yuck). >> >> I am not good at wordsmithing but I suggest there be some paragraph that covers network elements that can except a RADIUS feed. I need to talk to our standards team to see if we want this on T8 (probably). >> >> So today for all AT&T, Verizon, Vodaphone, ..... I know or am fairly confident they have anti spoofing tuned on in the GGSN/PGW/UPF plus I know they can turn this on per APN. Not sure why anyone would disable this since we if you are delegating a subnet to a Wi-Fi hotspot (instead of the typical private addressing they use). >> >> We actually don't need any 3GPP changes since this is already covered using RADIUS to pass the information where it needs to go. I suspect most will leverage their caching SPR/UDR which already has the information. Even the GGSN we launched EDGE/GPRS when I was much younger supported anti-spoofing and many vendors cover this via a number of methods (e.g. COPS works for older junos and RADIUS for Cisco IOS releases ). >> >> My suggestion is that I am willing to help whoever wants to craft the paragraph because I suck at that (fortunately I am good at other things). >> >> I don't think we need any changes to any standards to cover this since we already cover this and already are covering this if we strip out GTP (at least for one leg). I'll make sure it gets into our RAN requirements if not there since that may be the best place for that edge. Plus I'll get it covered thru the ONAP open source effort we drove (we donated the software to the open source effort). That means FM, PM, CM and IM will be covered in some future ONAP release (takes time but faster than 3GPP). >> >> It's a bit debatable what is RAN when using virtualized network functions (VNF) and a bunch of open source stuff that we put it into all of the needed elements like SDN, firewall, load balancer (not sure that's needed at cell site but it is for core DNS, proxy-TDF and CNAT) out at the cell site. We aren't there yet (still physical eNB/NR and obviously we need hardware assist even with virtualization plus tight control of timing). I am looking forward to when we start using containers. >> >> For our core I am sure we will use our UDR VNF as the cache for whatever comes out of this effort in final standards. The information is already there (IMEI, device vendor, subscription information, UE IP address, APN, etc.). If we do anything it would be to augment an open source and if needed a 3GPP. I don't think we need any changes but it's always best to verify. For current RAN an anti-spoofing feature would come from EMS which can be via ONAP. I don't think that is a standards effort thing since it's a feature which may or may not already be covered but it will be in future RAN releases probably starting with eNB/NR with some vendor release if it's not already a feature. I want to say Ericsson and Nokia already can do this in eNB but I need to go thru channels to ask. >> >> So maybe that paragraph recommends implementing anti-spoofing at all edges and leaves it at that. Or we could say all edges including RAN if that makes people happy. >> >>> -----Original Message----- >>> From: 5gangip <5gangip-bounces@ietf.org> On Behalf Of Tom Herbert >>> Sent: Thursday, May 03, 2018 10:46 AM >>> To: Dirk.von-Hugo@telekom.de >>> Cc: Tom Herbert ; Joel M. Halpern >>> ; ila@ietf.org; Alberto Rodriguez-Natal >>> ; 5GANGIP <5gangip@ietf.org> >>> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement] >>> >>> On Thu, May 3, 2018 at 9:23 AM, wrote: >>>> Hi Tom, >>>> I understand you correctly that DDOS attacks can never be completely >>> prevented whatever protocol you use. >>>> It will however always remain related to known IP addresses and the more >>> versatile these are handled a mitigation strategy could be designed. >>> >>> Dirk, >>> >>> I disagree. IP addresses can too easily be spoofed, it's easy to hide identity >>> behind a NAT (see discussion about CGNAT and law enforcement on int-area >>> list), and trying to turn off individual addresses doesn't work if it's a DDOS. This >>> is nothing new. For instance, content providers have long accepted the fact that >>> they can't prevent SYN attacks and there's little point to trying to go back to >>> source IP address (they are always spoofed in a SYN attack). The better strategy >>> is to absorb the attack and minimize the negative effects so that the attack is >>> not worth the effort. >>> >>>> As you may have seen we mention improved handling of mapping systems >>> and subsequently of DDOS protection also in the current version of our PS >>> document https://urldefense.proofpoint.com/v2/url?u=https- >>> 3A__github.com_bsarikaya_atic_blob_master_atick- >>> 5Fproblemstatement.3.txt&d=DwICAg&c=LFYZ- >>> o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=zYkPItjuHMuGlJXD5K_4 >>> OstVOL1OQiA98fgBJ9c1Gjo&s=jLL_9a56R8Ic8o3uJcR8mrF- >>> JkzLL97h8rmZT_EqXnQ&e= which Behcet has announced recently. >>>> May I ask you to please comment on the ideas outlined there? >>> >>> I don't see much difference in the latest version. For a problem statement, I still >>> think there is too much focus on the solutions and not nearly enough >>> description of what the actual problems are to be solved. >>> >>> Tom >>> >>>> Thanks! >>> >>>> Best Regards >>>> Dirk >>>> >>>> -----Original Message----- >>>> From: 5gangip [mailto:5gangip-bounces@ietf.org] On Behalf Of Tom >>>> Herbert >>>> Sent: Mittwoch, 2. Mai 2018 01:20 >>>> To: Joel M. Halpern >>>> Cc: Tom Herbert ; ila@ietf.org; Alberto >>>> Rodriguez-Natal ; 5GANGIP <5gangip@ietf.org> >>>> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement] >>>> >>>> On Tue, May 1, 2018 at 3:49 PM, Joel M. Halpern >>> wrote: >>>>> You seem to be saying that even though not all DDOS attacks are >>>>> structurally the same, and even though if ILA were widely adopted not >>>>> all ILA networks would be structurally the same, there should >>>>> nonetheless be one required qay of handling DDOS? >>>> >>>> Yes, at least as core default in the protocol. It's precisely _because_ not all >>> DDOS attacks are structurally the same. An attacker is not going to conform to >>> to our expectations of what they should be doing, so if we enable LISP option N >>> to mitigate one form of attack, they will just use another attack that isn't >>> mitigated. For example, if the mitigation is to identify attackers by address >>> when requests from the address exceed a threshold then this works as long as >>> the attacker strikes from one machine, but it falls apart if the attacker launches >>> a DDOS attack from several hosts where requests from none of the hosts >>> exceed the threshold. >>>> >>>> The ILA model works because it assumes there is no absolute way to prevent >>> the the worst case attack on a cache which is to completely kill it (i.e. drive it to >>> 0% hit rate). In this state the behavior sub-optimal routing, which is much >>> better than loss of service. This is not dependent on the structure of the attack, >>> network topology, or the network operator getting the configuration just right-- >>> it is inherent in the protocol. >>>> >>>> Tom >>>> >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> >>>>> On 5/1/18 6:32 PM, Tom Herbert wrote: >>>>>> >>>>>> On Tue, May 1, 2018 at 2:59 PM, Alberto Rodriguez-Natal >>>>>> wrote: >>>>>>> >>>>>>> On Tue, May 1, 2018 at 10:16 AM, Tom Herbert >>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> I think you've misunderstood my position. Caches are _very_ >>>>>>>> important to eliminate the cost triangular routing (latency, average path >>> load). >>>>>>>> This reduces latency and reduces average load on ILA-Rs. But, and >>>>>>>> this is the critical part, caches are only an _optimization_ in >>>>>>>> ILA. That means if the cache is rendered ineffective (like by a >>>>>>>> well crafted DOS >>>>>>>> attack) then the only effect is that the optimization is loss (i.e. >>>>>>>> greater latency due to triangular router)-- this is quantitively >>>>>>>> the worst effect of the attack on an ILA cache. This can be >>>>>>>> contrasted that to LISP where the worst case effects of a DOS >>>>>>>> attack on the cache is loss of service for users (infinite latency >>>>>>>> since packets can be dropped or indefinitely blocked on a cache miss). >>>>>>> >>>>>>> >>>>>>> >>>>>>> This can be misleading. This is not comparing LISP vs ILA, this is >>>>>>> comparing the models of Request/Reply at the edge vs Notifications >>>>>>> (aka Redirects) at the core. Both LISP-CP and ILAMP support these >>>>>>> two models. >>>>>>> >>>>>>> Besides, this is assuming an scenario where the only feasible DOS >>>>>>> mitigation is absorbing the attack. There are other scenarios where >>>>>>> other countermeasures are possible. For instance, if you have a >>>>>>> deployment where you can prevent address spoofing, counting and >>>>>>> blocking misbehaving nodes offers similar DOS protection and >>>>>>> requires way less infrastructure resources. >>>>>>> >>>>>> Alberto, >>>>>> >>>>>> The answer to my question of how does LISP address DOS attacks seems >>>>>> to be "there are many options". Some of the options are to assume >>>>>> that DOS does not exist in the network, some assume external >>>>>> configuration like address spoofing is enabled, some assume that >>>>>> attacks can be identified and can be stopped at the source, some >>>>>> might assume that everything is okay because there's never been a >>>>>> DOS attack before. I have yet to see the effects of any of these >>>>>> quantified, and none of these state how the LISP _protocol_ itself >>>>>> addresses DOS. It may seem counter-intuitive, but offering a bunch >>>>>> of options really is not necessarily a good thing-- sometime less is >>>>>> more. To put this another way LISP has been rejected from Linux >>>>>> precisely because of its susceptibility to DOS. If you were to try >>>>>> again and the best answer to the DOS question is that it's up to the >>>>>> operator to figure out the right options to use, then I believe it >>>>>> would be soundly rejected again. That approach does not work at scale. >>>>>> >>>>>> Tom >>>>>> >>>>>> _______________________________________________ >>>>>> ila mailing list >>>>>> ila@ietf.org >>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_ma >>>>>> ilman_listinfo_ila&d=DwICAg&c=LFYZ- >>> o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl >>>>>> >>> 2paJIf4zw&m=zYkPItjuHMuGlJXD5K_4OstVOL1OQiA98fgBJ9c1Gjo&s=BO3snt8C >>> RQ >>>>>> gy1xwhx2CY10VUbM_rgntgpV9k3-Cskd8&e= >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 5gangip mailing list >>>> 5gangip@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail >>>> man_listinfo_5gangip&d=DwICAg&c=LFYZ- >>> o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl >>>> >>> 2paJIf4zw&m=zYkPItjuHMuGlJXD5K_4OstVOL1OQiA98fgBJ9c1Gjo&s=FnQLMire >>> MiKC >>>> SkPaOGFCybzDc2i2y49Cgtbl6mCLc9c&e= >>> >>> _______________________________________________ >>> 5gangip mailing list >>> 5gangip@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=https- >>> 3A__www.ietf.org_mailman_listinfo_5gangip&d=DwICAg&c=LFYZ- >>> o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=zYkPItjuHMuGlJXD5K_4 >>> OstVOL1OQiA98fgBJ9c1Gjo&s=FnQLMireMiKCSkPaOGFCybzDc2i2y49Cgtbl6mC >>> Lc9c&e= > From nobody Thu May 3 14:59:52 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9FA81267BB for ; Thu, 3 May 2018 14:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.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 NUYSnU_wvprI for ; Thu, 3 May 2018 14:59:42 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (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 261BC12EAFC for ; Thu, 3 May 2018 14:59:42 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id i14-v6so15929007wre.2 for ; Thu, 03 May 2018 14:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/2Z4xMY5QdBkhfrv9naa0zorzNbuDjofLpw77aACW/Q=; b=oXGBm9rv9olIr58Jn66NtTvMJwhKOPAnG1aqMxf0rSWnJSVIQuGJT5+jaRaASby8Nw JtmOEgn2UqW8DU9p38YMQs1cKKIr5tYBHK4FaEdnh5vYbFTzpGD6qssBJEA6hEQnJor3 Vn4Uek6DKBybGFyI1TYD9OXdFuOAEg/tsnoLFd2my9Awn0i6pmLBQJQ3o5Yu/fesvl85 MRk7f9qP68C3ac8L/4Rpqu4W0XnwgehkBRMPM21Gm2umRg0cuob5XJ79fu1P9JpA0Ie+ FDVkHFtKTxo1JvBzqQfD9ZTjyQXhP06BX92y7wLoYzOYcK9Qp8cmeZFjWQRy33UlpyxH DKTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/2Z4xMY5QdBkhfrv9naa0zorzNbuDjofLpw77aACW/Q=; b=S7xrTSGId99OctKxLeMNDyHU6HIOvIqhk/NngxnFH1JVtjTw7XkOIq1bUzawyfQAWj mTlrT7OoxPbWj+jef7d01lbnAfbSWjDjA9AEwmHkCTRF4REX01pDB62jaHyqu9l/U3X1 ZOo9tOx/9J2mYw9pW8xwPizkzfSVcdxfKRXjKgjfR3XjBZMRw105YQB1AmFeCxgRI+Ux VAdlIiZY84XocQB/44OrlITqn84qW/H36ubfJqV7o4glPrl+C+qbtemI8y/d02ulHEbi h3aXns5IeRL3Un05U5OfvwmQKv3Tg05y8WIMxQd9lc/h7Jgd79pq2b5dBqIxAeu+nysx lk0g== X-Gm-Message-State: ALQs6tBDzFMFEZNbTD37oHnmNnQ8Nsq+BhR2r5ctdDlJQFES0mLF2BSx ZCmlHTSfVscuuNTzjoTNT7eVi6dXfnNNSXFa97qiRA== X-Google-Smtp-Source: AB8JxZqLuN7qTy2NDwwA2PSht5bBO1F0RwNoGtGHwceFenbcYje12GKqpJGPnsIl1Ik9zercB3/5waGl4XiovJCi2UI= X-Received: by 2002:adf:e181:: with SMTP id k1-v6mr20377386wri.111.1525384780360; Thu, 03 May 2018 14:59:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.227 with HTTP; Thu, 3 May 2018 14:59:39 -0700 (PDT) In-Reply-To: <0cbb9987-0b47-9428-3db7-2c9fab821268@joelhalpern.com> References: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> <8aee42db5f0f407c86fda881769ceb77@HE105715.emea1.cds.t-internal.com> <1AFE10CF28AE8B4C9663445736B8034D3822FAFE@CAFRFD1MSGUSRJI.ITServices.sbc.com> <0cbb9987-0b47-9428-3db7-2c9fab821268@joelhalpern.com> From: Tom Herbert Date: Thu, 3 May 2018 14:59:39 -0700 Message-ID: To: "Joel M. Halpern" Cc: "FIGURELLE, TERRY F" , "Dirk.von-Hugo@telekom.de" , Tom Herbert , "ila@ietf.org" , Alberto Rodriguez-Natal , 5GANGIP <5gangip@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 21:59:47 -0000 On Thu, May 3, 2018 at 2:45 PM, Joel M. Halpern wrote: > I am missing something in your DDOS issue. > > At first, I thought the real issue (which you seem to be suggesting here) > was DDOS from the Internet, using spoofed or non-spoofed addresses (with bot > farms, there is much less need for or relevance of spoofing). > > But then I tried to map it to the cases we have for using ILA. > The primary case I have heard about is to use ILA for UE<->UE and > UE<->EdgeComputing traffic. If so, just filter all SIRs on incoming packets > from the Internet. They aren't legal there. And similarly, if one uses > LISP within the operator domain, we can block whatever blocks we use for > EIDs for such local traffic. Joel, I'm not sure I understand what "filtering SIRs from the Internet" means. A SIR address is a globally visible address for devices like UEs. So an Internet sender may legitimately send packets to SIR addresses, and also an Internet attacker could easily spew a whole bunch of packets with both spoofed source addresses and spoofed UE addresses. So you'd want to allow the legitimate traffic but block the attacking packets-- this isn't feasible since it's impossible to distinguish the bad from the good packets. > > If we want to use id-locator split of any kind for handling traffic to / > from the Internet, then we have to understand how that is supposed to work, > and why, before we need to evaluate DDOS implications of a solution. For > LISP,the working group has explicitly said that Inter-wide deployment is out > of scope. > > Net: I do not see in currently described deployments, an issue that > differentiates LISP from ILA in these regards. And Terry has very clearly > spelled out that for mobile operators spoofing from UEs is not considered an > issue that the infrastructure needs to deal wih. But there may be a whole network infrastructure of hundreds or even thousands of users behind a UE, and there's no guarantee that that infrastructure properly supports anti-spoofing. This basically this case has the same problem as in the Internet case. Tom > > Yours, > Joel > > > On 5/3/18 5:33 PM, Tom Herbert wrote: >> >> On Thu, May 3, 2018 at 2:23 PM, FIGURELLE, TERRY F wrote: >>> >>> In the case of current 3GPP operators all the major vendors support >>> anti-spoofing. The default was on for all but one vendor which got corrected >>> the last time I did an RFP for EPC. So by configuration the >>> GGSN/PGW/PGW-U/UPF will not allow the UE to send packets that don't match >>> either the exact IP address or pushed subnet or prefix delegation that was >>> sent in response to the APN create message. Obviously if we remove GTP >>> encapsulation that protect MAY need to be enhanced towards an EDGE element. >>> >> Terry, >> >> Even so, the whole Internet does not require anti-spoofing, nor do I >> believe that operators could require all down stream network that are >> connected to support anti-spoofing. These are where the DOS attacks >> orginate. The problem is when caches are being driven by user taffic >> from these external networks, mitigations to detect DOS by IP source >> address don't work without anti-spoofing (but even if they had >> anti-spoofing that still doesn't work when under a DDOS). >> >> Tom >> >> >> >>> This is being covered as part of our participation in an open source vEPC >>> (virtualize EPC, hypervisor, blah, blah, blah). So there will be a micro >>> service firewall that can be deploy at the edge plus we already have planned >>> support for big network infrastructure vendors and 3GPP supplies (Cisco, >>> Juniper, Ericsson, Nokia, Huawei, ...) to cover this. Since this can be a >>> non-3GPP element we will get this into ONAP. >>> >>> Thus we have this covered both for 3GPP nodes, micro services and open >>> source efforts. To give examples without vendor names there are GTP aware >>> firewalls that some operators use. It really just another capability in >>> carrier class and business class firewalls (had to add it to load balancers, >>> CNAT/NAT, some Wi-Fi routers and to our DNS solution which uses open >>> source). Obviously this will be supported via a RADIUS feed for backwards >>> compatibility. Today most GTP firewall simply follow the GTP-C signaling to >>> learn the IP address(es) assigned to the UE for an APN. If we remove GTP >>> from user plane that doesn't mean we remove it from control plane or for all >>> hops. However, we will likely push to a micro service at the cell plus I >>> need to check if we ever ask RAN vendors to support this. I'll add this for >>> 5G but we already did that RFP so it's a change order (yuck). >>> >>> I am not good at wordsmithing but I suggest there be some paragraph that >>> covers network elements that can except a RADIUS feed. I need to talk to our >>> standards team to see if we want this on T8 (probably). >>> >>> So today for all AT&T, Verizon, Vodaphone, ..... I know or am fairly >>> confident they have anti spoofing tuned on in the GGSN/PGW/UPF plus I know >>> they can turn this on per APN. Not sure why anyone would disable this since >>> we if you are delegating a subnet to a Wi-Fi hotspot (instead of the typical >>> private addressing they use). >>> >>> We actually don't need any 3GPP changes since this is already covered >>> using RADIUS to pass the information where it needs to go. I suspect most >>> will leverage their caching SPR/UDR which already has the information. Even >>> the GGSN we launched EDGE/GPRS when I was much younger supported >>> anti-spoofing and many vendors cover this via a number of methods (e.g. COPS >>> works for older junos and RADIUS for Cisco IOS releases ). >>> >>> My suggestion is that I am willing to help whoever wants to craft the >>> paragraph because I suck at that (fortunately I am good at other things). >>> >>> I don't think we need any changes to any standards to cover this since we >>> already cover this and already are covering this if we strip out GTP (at >>> least for one leg). I'll make sure it gets into our RAN requirements if not >>> there since that may be the best place for that edge. Plus I'll get it >>> covered thru the ONAP open source effort we drove (we donated the software >>> to the open source effort). That means FM, PM, CM and IM will be covered in >>> some future ONAP release (takes time but faster than 3GPP). >>> >>> It's a bit debatable what is RAN when using virtualized network functions >>> (VNF) and a bunch of open source stuff that we put it into all of the needed >>> elements like SDN, firewall, load balancer (not sure that's needed at cell >>> site but it is for core DNS, proxy-TDF and CNAT) out at the cell site. We >>> aren't there yet (still physical eNB/NR and obviously we need hardware >>> assist even with virtualization plus tight control of timing). I am looking >>> forward to when we start using containers. >>> >>> For our core I am sure we will use our UDR VNF as the cache for whatever >>> comes out of this effort in final standards. The information is already >>> there (IMEI, device vendor, subscription information, UE IP address, APN, >>> etc.). If we do anything it would be to augment an open source and if needed >>> a 3GPP. I don't think we need any changes but it's always best to verify. >>> For current RAN an anti-spoofing feature would come from EMS which can be >>> via ONAP. I don't think that is a standards effort thing since it's a >>> feature which may or may not already be covered but it will be in future RAN >>> releases probably starting with eNB/NR with some vendor release if it's not >>> already a feature. I want to say Ericsson and Nokia already can do this in >>> eNB but I need to go thru channels to ask. >>> >>> So maybe that paragraph recommends implementing anti-spoofing at all >>> edges and leaves it at that. Or we could say all edges including RAN if that >>> makes people happy. >>> >>>> -----Original Message----- >>>> From: 5gangip <5gangip-bounces@ietf.org> On Behalf Of Tom Herbert >>>> Sent: Thursday, May 03, 2018 10:46 AM >>>> To: Dirk.von-Hugo@telekom.de >>>> Cc: Tom Herbert ; Joel M. Halpern >>>> ; ila@ietf.org; Alberto Rodriguez-Natal >>>> ; 5GANGIP <5gangip@ietf.org> >>>> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement] >>>> >>>> On Thu, May 3, 2018 at 9:23 AM, wrote: >>>>> >>>>> Hi Tom, >>>>> I understand you correctly that DDOS attacks can never be completely >>>> >>>> prevented whatever protocol you use. >>>>> >>>>> It will however always remain related to known IP addresses and the >>>>> more >>>> >>>> versatile these are handled a mitigation strategy could be designed. >>>> >>>> Dirk, >>>> >>>> I disagree. IP addresses can too easily be spoofed, it's easy to hide >>>> identity >>>> behind a NAT (see discussion about CGNAT and law enforcement on int-area >>>> list), and trying to turn off individual addresses doesn't work if it's >>>> a DDOS. This >>>> is nothing new. For instance, content providers have long accepted the >>>> fact that >>>> they can't prevent SYN attacks and there's little point to trying to go >>>> back to >>>> source IP address (they are always spoofed in a SYN attack). The better >>>> strategy >>>> is to absorb the attack and minimize the negative effects so that the >>>> attack is >>>> not worth the effort. >>>> >>>>> As you may have seen we mention improved handling of mapping systems >>>> >>>> and subsequently of DDOS protection also in the current version of our >>>> PS >>>> document https://urldefense.proofpoint.com/v2/url?u=https- >>>> 3A__github.com_bsarikaya_atic_blob_master_atick- >>>> 5Fproblemstatement.3.txt&d=DwICAg&c=LFYZ- >>>> o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=zYkPItjuHMuGlJXD5K_4 >>>> OstVOL1OQiA98fgBJ9c1Gjo&s=jLL_9a56R8Ic8o3uJcR8mrF- >>>> JkzLL97h8rmZT_EqXnQ&e= which Behcet has announced recently. >>>>> >>>>> May I ask you to please comment on the ideas outlined there? >>>> >>>> >>>> I don't see much difference in the latest version. For a problem >>>> statement, I still >>>> think there is too much focus on the solutions and not nearly enough >>>> description of what the actual problems are to be solved. >>>> >>>> Tom >>>> >>>>> Thanks! >>>> >>>> >>>>> Best Regards >>>>> Dirk >>>>> >>>>> -----Original Message----- >>>>> From: 5gangip [mailto:5gangip-bounces@ietf.org] On Behalf Of Tom >>>>> Herbert >>>>> Sent: Mittwoch, 2. Mai 2018 01:20 >>>>> To: Joel M. Halpern >>>>> Cc: Tom Herbert ; ila@ietf.org; Alberto >>>>> Rodriguez-Natal ; 5GANGIP <5gangip@ietf.org> >>>>> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement] >>>>> >>>>> On Tue, May 1, 2018 at 3:49 PM, Joel M. Halpern >>>> >>>> wrote: >>>>>> >>>>>> You seem to be saying that even though not all DDOS attacks are >>>>>> structurally the same, and even though if ILA were widely adopted not >>>>>> all ILA networks would be structurally the same, there should >>>>>> nonetheless be one required qay of handling DDOS? >>>>> >>>>> >>>>> Yes, at least as core default in the protocol. It's precisely _because_ >>>>> not all >>>> >>>> DDOS attacks are structurally the same. An attacker is not going to >>>> conform to >>>> to our expectations of what they should be doing, so if we enable LISP >>>> option N >>>> to mitigate one form of attack, they will just use another attack that >>>> isn't >>>> mitigated. For example, if the mitigation is to identify attackers by >>>> address >>>> when requests from the address exceed a threshold then this works as >>>> long as >>>> the attacker strikes from one machine, but it falls apart if the >>>> attacker launches >>>> a DDOS attack from several hosts where requests from none of the hosts >>>> exceed the threshold. >>>>> >>>>> >>>>> The ILA model works because it assumes there is no absolute way to >>>>> prevent >>>> >>>> the the worst case attack on a cache which is to completely kill it >>>> (i.e. drive it to >>>> 0% hit rate). In this state the behavior sub-optimal routing, which is >>>> much >>>> better than loss of service. This is not dependent on the structure of >>>> the attack, >>>> network topology, or the network operator getting the configuration just >>>> right-- >>>> it is inherent in the protocol. >>>>> >>>>> >>>>> Tom >>>>> >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> >>>>>> On 5/1/18 6:32 PM, Tom Herbert wrote: >>>>>>> >>>>>>> >>>>>>> On Tue, May 1, 2018 at 2:59 PM, Alberto Rodriguez-Natal >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> On Tue, May 1, 2018 at 10:16 AM, Tom Herbert >>>> >>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I think you've misunderstood my position. Caches are _very_ >>>>>>>>> important to eliminate the cost triangular routing (latency, >>>>>>>>> average path >>>> >>>> load). >>>>>>>>> >>>>>>>>> This reduces latency and reduces average load on ILA-Rs. But, and >>>>>>>>> this is the critical part, caches are only an _optimization_ in >>>>>>>>> ILA. That means if the cache is rendered ineffective (like by a >>>>>>>>> well crafted DOS >>>>>>>>> attack) then the only effect is that the optimization is loss (i.e. >>>>>>>>> greater latency due to triangular router)-- this is quantitively >>>>>>>>> the worst effect of the attack on an ILA cache. This can be >>>>>>>>> contrasted that to LISP where the worst case effects of a DOS >>>>>>>>> attack on the cache is loss of service for users (infinite latency >>>>>>>>> since packets can be dropped or indefinitely blocked on a cache >>>>>>>>> miss). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This can be misleading. This is not comparing LISP vs ILA, this is >>>>>>>> comparing the models of Request/Reply at the edge vs Notifications >>>>>>>> (aka Redirects) at the core. Both LISP-CP and ILAMP support these >>>>>>>> two models. >>>>>>>> >>>>>>>> Besides, this is assuming an scenario where the only feasible DOS >>>>>>>> mitigation is absorbing the attack. There are other scenarios where >>>>>>>> other countermeasures are possible. For instance, if you have a >>>>>>>> deployment where you can prevent address spoofing, counting and >>>>>>>> blocking misbehaving nodes offers similar DOS protection and >>>>>>>> requires way less infrastructure resources. >>>>>>>> >>>>>>> Alberto, >>>>>>> >>>>>>> The answer to my question of how does LISP address DOS attacks seems >>>>>>> to be "there are many options". Some of the options are to assume >>>>>>> that DOS does not exist in the network, some assume external >>>>>>> configuration like address spoofing is enabled, some assume that >>>>>>> attacks can be identified and can be stopped at the source, some >>>>>>> might assume that everything is okay because there's never been a >>>>>>> DOS attack before. I have yet to see the effects of any of these >>>>>>> quantified, and none of these state how the LISP _protocol_ itself >>>>>>> addresses DOS. It may seem counter-intuitive, but offering a bunch >>>>>>> of options really is not necessarily a good thing-- sometime less is >>>>>>> more. To put this another way LISP has been rejected from Linux >>>>>>> precisely because of its susceptibility to DOS. If you were to try >>>>>>> again and the best answer to the DOS question is that it's up to the >>>>>>> operator to figure out the right options to use, then I believe it >>>>>>> would be soundly rejected again. That approach does not work at >>>>>>> scale. >>>>>>> >>>>>>> Tom >>>>>>> >>>>>>> _______________________________________________ >>>>>>> ila mailing list >>>>>>> ila@ietf.org >>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_ma >>>>>>> ilman_listinfo_ila&d=DwICAg&c=LFYZ- >>>> >>>> o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl >>>>>>> >>>>>>> >>>> 2paJIf4zw&m=zYkPItjuHMuGlJXD5K_4OstVOL1OQiA98fgBJ9c1Gjo&s=BO3snt8C >>>> RQ >>>>>>> >>>>>>> gy1xwhx2CY10VUbM_rgntgpV9k3-Cskd8&e= >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 5gangip mailing list >>>>> 5gangip@ietf.org >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail >>>>> man_listinfo_5gangip&d=DwICAg&c=LFYZ- >>>> >>>> o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl >>>>> >>>>> >>>> 2paJIf4zw&m=zYkPItjuHMuGlJXD5K_4OstVOL1OQiA98fgBJ9c1Gjo&s=FnQLMire >>>> MiKC >>>>> >>>>> SkPaOGFCybzDc2i2y49Cgtbl6mCLc9c&e= >>>> >>>> >>>> _______________________________________________ >>>> 5gangip mailing list >>>> 5gangip@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=https- >>>> 3A__www.ietf.org_mailman_listinfo_5gangip&d=DwICAg&c=LFYZ- >>>> o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=zYkPItjuHMuGlJXD5K_4 >>>> OstVOL1OQiA98fgBJ9c1Gjo&s=FnQLMireMiKCSkPaOGFCybzDc2i2y49Cgtbl6mC >>>> Lc9c&e= >> >> > From nobody Thu May 3 15:53:56 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CACAD12EB0B; Thu, 3 May 2018 15:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 3seT2nGUp6Mz; Thu, 3 May 2018 15:53:45 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 9204312DA26; Thu, 3 May 2018 15:53:45 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id w43Mkcma028773; Thu, 3 May 2018 18:53:41 -0400 Received: from flpd657.enaf.ffdc.sbc.com (sbcsmtp9.sbc.com [144.160.128.153]) by m0049462.ppops.net-00191d01. with ESMTP id 2hrb320ka2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 03 May 2018 18:53:41 -0400 Received: from enaf.ffdc.sbc.com (localhost [127.0.0.1]) by flpd657.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id w43MreU1127753; Thu, 3 May 2018 15:53:40 -0700 Received: from zlp25947.vci.att.com (zlp25947.vci.att.com [135.213.92.137]) by flpd657.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id w43MrXXh127687; Thu, 3 May 2018 15:53:33 -0700 Received: from zlp25947.vci.att.com (zlp25947.vci.att.com [127.0.0.1]) by zlp25947.vci.att.com (Service) with ESMTP id 5A5DE410F454; Thu, 3 May 2018 22:53:33 +0000 (GMT) Received: from CAFRFD1MSGHUBAH.ITServices.sbc.com (unknown [130.4.169.153]) by zlp25947.vci.att.com (Service) with ESMTPS id 24D7B410F442; Thu, 3 May 2018 22:53:33 +0000 (GMT) Received: from CAFRFD1MSGUSRJI.ITServices.sbc.com ([169.254.8.94]) by CAFRFD1MSGHUBAH.ITServices.sbc.com ([130.4.169.153]) with mapi id 14.03.0389.001; Thu, 3 May 2018 15:53:32 -0700 From: "FIGURELLE, TERRY F" To: Tom Herbert , "Joel M. Halpern" CC: "Dirk.von-Hugo@telekom.de" , Tom Herbert , "ila@ietf.org" , Alberto Rodriguez-Natal , 5GANGIP <5gangip@ietf.org> Thread-Topic: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement] Thread-Index: AQHT4wasd9k0kyItlUiMNTfEFG8rxqQebc2ggACORwCAAANogIAAA9+A//+Ma9A= Date: Thu, 3 May 2018 22:53:31 +0000 Message-ID: <1AFE10CF28AE8B4C9663445736B8034D3822FC27@CAFRFD1MSGUSRJI.ITServices.sbc.com> References: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> <8aee42db5f0f407c86fda881769ceb77@HE105715.emea1.cds.t-internal.com> <1AFE10CF28AE8B4C9663445736B8034D3822FAFE@CAFRFD1MSGUSRJI.ITServices.sbc.com> <0cbb9987-0b47-9428-3db7-2c9fab821268@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.49.100] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-03_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805030198 Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 22:53:50 -0000 Tm8uIFdlIGhhdmUgYWx3YXlzIGJsb2NrIHVuc29saWNpdGVkIHRyYWZmaWMgZnJvbSB0aGUgSW50 ZXJuZXQgYW5kIGl0IGlzIHRvbyBjb21wbGljYXRlZCB0byBkaXNjdXNzIGhlcmUuDQoNCldlIGV2 ZW4gZGlkIHRoaXMgd2F5IGJhY2sgZm9yIENEUEQuIEZvciBkZWRpY2F0ZWQgQVBOJ3Mgd2UgYWxs b3cgdGhlIGVudGVycHJpc2UgdG8gdGVsbCB1cyB3aGF0IHJ1bGVzIHRoZXkgd2FudCB0byBwcm90 ZWN0IHRoZSBtb2JpbGUgZnJvbSB0aGVpciBuZXR3b3JrIGFuZCB3aGF0IHRyYWZmaWMgdG8gbm90 IGFsbG93IGZyb20gdGhlIG1vYmlsZS4gVGhpcyBpcyBvbmUgb2YgdGhlIHJlYXNvbnMgZmlyZXdh bGxzIGFuZCBDTkFUIGNvc3QgbW9yZSBpZiB0aGV5IHN1cHBvcnQgbW9iaWxpdHkgZmVhdHVyZXMu IFdlIHNwZW50IGEgbG90IG9mIHRpbWUgd29ya2luZyB3aXRoIHBvdGVudGlhbCB2ZW5kb3JzLg0K DQpTaW5jZSB0aGlzIHN0YXJ0ZWQgd2l0aCB1c2FnZSBiYXNlZCByYXRlIHBsYW5zIGZvciBhbGwg bW9iaWxlIG9wZXJhdG9ycyB0aGUgc3Vic2NyaWJlciB3b3VsZCBnZXQgY2hhcmdlZCBpZiB3ZSBh bGxvd2VkIHNwYW0gZnJvbSB0aGUgSW50ZXJuZXQgb3IgZnJvbSBvdGhlciBtb2JpbGVzLiBTbyB0 aGlzIGhhcyBhbHdheXMgYmVlbiBibG9jayBhbmQgdmVuZG9ycyBoYXZlIGZlYXR1cmVzIHRvIGhl bHAgb3V0IGluIDNHUFAgZWxlbWVudHMuIEEgR0dTTiB3aXRoIGFudGktc3Bvb2Zpbmcgbm90IGRp c2FibGVkIGRvZXNuJ3QgYWxsb3cgdHJhZmZpYyB0byBhIG1vYmlsZSB0aGF0IGRvZXNuJ3QgbWF0 Y2ggYW4gZW50cnkgaW4gdGhlIGZsb3cgdGFibGUuIFdlIGhhdmUgaHVuZHJlZHMgb2YgcG9saWN5 IHJ1bGVzIHRoYXQgZ2V0IGVuYWJsZWQgZnJvbSB0aGUgUENSRi9QQ0Ygb24gdGhlIFBHVyhQQ0VG KS9VUEYuIFdlIGFsc28gZW5hYmxlZCBvdXIgcHJveGllcyB0byBiZSB0cmFuc3BhcmVudCBwcm94 eS1UREYuIFRoYXQgbWVhbnMgdGhleSBhbHNvIGhhdmUgcG9saWN5IGludGVyZmFjZXMgYW5kIHdl IGRvIGEgYnVuY2ggb2Ygc3R1ZmYgaGVyZSBpbmNsdWRpbmcgcHJvY2Vzc2luZyBzaWduZWQgbWFu aWZlc3RzLiBQbHVzIHRoZSBydWxlcyBhcmUgcHVzaGVkIG9uIHRoZSBjb250cm9sIHBsYW5lIG5v dCB0aGUgZGF0YSBwbGFuZSBhbmQgaXQgaW5jbHVkZXMgVUUsIFJBTiwgU0dXL1BHVy9VUEYgYW5k IGlmIGFwcGxpY2FibGUgVERGJ3MgYW5kIEFTJ3MuIFdlIGNhbiBwdXNoIHJ1bGVzIHRvIHRoZSBV RSB0aGF0IGFsbG93LCAoZHJvcCksIHJvdXRlL3BhdGggKGUuZy4gYmVhcmVyKS4gV2UgZXZlbiBo YXZlIHRvIGhhdmUgc29tZSBjb3VudHJ5IHNwZWNpZmljIHRyZWF0bWVudCAoYSBiaWdnZXIgY2hh bGxlbmdlIHdlIGhhZCBmb3IgdmVoaWNsZXMgdXNpbmcgb3VyIENvbm5lY3RlZCBDYXIgc29sdXRp b24gbGlrZSBHTSBPblN0YXIpLg0KDQpXaGlsZSBhIG1vYmlsZSBjb3VsZCBnZXQgaGFja2VkIGFu ZCBpdCBjb3VsZCBicmVhayB0aGUgZmxvdyBydWxlIHRyZWF0bWVudCBzb21lIG9mIHRoYXQgaXMg ZG93biBpbiB0aGUgM0dQUCBjaGlwc2V0LiBCdXQgd2UgYXJlIGF3YXJlIG9mIHRoZSByaXNrIGFu ZCB3ZSBoYXZlIGNvdW50ZXIgbWVhc3VyZXMgYXMgYmVzdCB3ZSBjYW4uIEkgc2hvdWxkIHBvaW50 IG91dCB0aGF0IHRoZXNlIGZsb3cgcnVsZXMgZ28gaW50byBSQU4gdG9vIGFuZCBydWxlcyBoYXZl IGEgZGlyZWN0aW9uIChmcm9tIFVFLCB0byBVRSBvciBib3RoKS4NCg0KTXkgb3BpbmlvbiBpcyB0 aGF0IG1hbHdhcmUsIHNwb29maW5nLCBET1MsIERET1MgYW5kIGFueSBvdGhlciB0aHJlYXQgaXMg YSBzZXJpb3VzIG9wZXJhdGlvbmFsIGlzc3VlLiBUaGF0IGlzIHRoZSBiZXN0IHBsYWNlIHRvIGRl YWwgd2l0aCBpdCBiZWNhdXNlIHN0YW5kYXJkcyBjb3VsZCBuZXZlciBrZWVwIHBhY2UuIFdlIGFu ZCBvdGhlciBvcGVyYXRvcnMgcmVxdWVzdCBmZWF0dXJlcyBmcm9tIHZlbmRvcnMgYW5kIHRoZXkg YWxzbyBjb21lIHVwIHdpdGggc3R1ZmYgYXMgYSB2YWx1ZSBhZGQuDQoNClNpbXBseSBzdGF0ZWQg dGhlIHNvbHV0aW9uIG5lZWRzIHRvIGJlIHByb3RlY3RlZCBidXQgd2UgZG9uJ3QgbmVlZCB0b25z IG9mIGRldGFpbCBpbiBldmVyeSBzdGFuZGFyZC4NCg0KSSB3b3VsZCBuZXZlciBzYXkgZG9uJ3Qg YmUgY29uY2VybmVkIGFib3V0IHNvbWV0aGluZy4gSSBqdXN0IGRvbid0IHRoaW5rIGV2ZXJ5IHN0 YW5kYXJkIG5lZWRzIGRldGFpbHMgb24gc3Bvb2ZpbmcsIERPUyBhbmQgb3RoZXIgdGhyZWF0cy4N Cg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFRvbSBIZXJiZXJ0IDx0 b21AcXVhbnRvbml1bS5uZXQ+DQo+IFNlbnQ6IFRodXJzZGF5LCBNYXkgMDMsIDIwMTggMzowMCBQ TQ0KPiBUbzogSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPg0KPiBDYzogRklH VVJFTExFLCBURVJSWSBGIDx0ZjI5MzRAYXR0LmNvbT47IERpcmsudm9uLUh1Z29AdGVsZWtvbS5k ZTsgVG9tDQo+IEhlcmJlcnQgPHRvbUBoZXJiZXJ0bGFuZC5jb20+OyBpbGFAaWV0Zi5vcmc7IEFs YmVydG8gUm9kcmlndWV6LU5hdGFsDQo+IDxyb2RyaWd1ZXpuYXRhbEBnbWFpbC5jb20+OyA1R0FO R0lQIDw1Z2FuZ2lwQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogWzVnYW5naXBdIFtJbGFdIElM QSBmb3J3YXJpbmcgW1dhcyBSZTogUHJvYmxlbSBTdGF0ZW1lbnRdDQo+IA0KPiBPbiBUaHUsIE1h eSAzLCAyMDE4IGF0IDI6NDUgUE0sIEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNv bT4NCj4gd3JvdGU6DQo+ID4gSSBhbSBtaXNzaW5nIHNvbWV0aGluZyBpbiB5b3VyIERET1MgaXNz dWUuDQo+ID4NCj4gPiBBdCBmaXJzdCwgSSB0aG91Z2h0IHRoZSByZWFsIGlzc3VlICh3aGljaCB5 b3Ugc2VlbSB0byBiZSBzdWdnZXN0aW5nDQo+ID4gaGVyZSkgd2FzIERET1MgZnJvbSB0aGUgSW50 ZXJuZXQsIHVzaW5nIHNwb29mZWQgb3Igbm9uLXNwb29mZWQNCj4gPiBhZGRyZXNzZXMgKHdpdGgg Ym90IGZhcm1zLCB0aGVyZSBpcyBtdWNoIGxlc3MgbmVlZCBmb3Igb3IgcmVsZXZhbmNlIG9mDQo+ IHNwb29maW5nKS4NCj4gPg0KPiA+IEJ1dCB0aGVuIEkgdHJpZWQgdG8gbWFwIGl0IHRvIHRoZSBj YXNlcyB3ZSBoYXZlIGZvciB1c2luZyBJTEEuDQo+ID4gVGhlIHByaW1hcnkgY2FzZSBJIGhhdmUg aGVhcmQgYWJvdXQgaXMgdG8gdXNlIElMQSBmb3IgVUU8LT5VRSBhbmQNCj4gPiBVRTwtPkVkZ2VD b21wdXRpbmcgdHJhZmZpYy4gIElmIHNvLCBqdXN0IGZpbHRlciBhbGwgU0lScyBvbiBpbmNvbWlu Zw0KPiA+IHBhY2tldHMgZnJvbSB0aGUgSW50ZXJuZXQuICBUaGV5IGFyZW4ndCBsZWdhbCB0aGVy ZS4gIEFuZCBzaW1pbGFybHksDQo+ID4gaWYgb25lIHVzZXMgTElTUCB3aXRoaW4gdGhlIG9wZXJh dG9yIGRvbWFpbiwgd2UgY2FuIGJsb2NrIHdoYXRldmVyDQo+ID4gYmxvY2tzIHdlIHVzZSBmb3Ig RUlEcyBmb3Igc3VjaCBsb2NhbCB0cmFmZmljLg0KPiANCj4gSm9lbCwNCj4gDQo+IEknbSBub3Qg c3VyZSBJIHVuZGVyc3RhbmQgd2hhdCAiZmlsdGVyaW5nIFNJUnMgZnJvbSB0aGUgSW50ZXJuZXQi DQo+IG1lYW5zLiBBIFNJUiBhZGRyZXNzIGlzIGEgZ2xvYmFsbHkgdmlzaWJsZSBhZGRyZXNzIGZv ciBkZXZpY2VzIGxpa2UgVUVzLiBTbyBhbg0KPiBJbnRlcm5ldCBzZW5kZXIgbWF5IGxlZ2l0aW1h dGVseSBzZW5kIHBhY2tldHMgdG8gU0lSIGFkZHJlc3NlcywgYW5kIGFsc28gYW4NCj4gSW50ZXJu ZXQgYXR0YWNrZXIgY291bGQgZWFzaWx5IHNwZXcgYSB3aG9sZSBidW5jaCBvZiBwYWNrZXRzIHdp dGggYm90aCBzcG9vZmVkDQo+IHNvdXJjZSBhZGRyZXNzZXMgYW5kIHNwb29mZWQgVUUgYWRkcmVz c2VzLiBTbyB5b3UnZCB3YW50IHRvIGFsbG93IHRoZQ0KPiBsZWdpdGltYXRlIHRyYWZmaWMgYnV0 IGJsb2NrIHRoZSBhdHRhY2tpbmcgcGFja2V0cy0tIHRoaXMgaXNuJ3QgZmVhc2libGUgc2luY2Ug aXQncw0KPiBpbXBvc3NpYmxlIHRvIGRpc3Rpbmd1aXNoIHRoZSBiYWQgZnJvbSB0aGUgZ29vZCBw YWNrZXRzLg0KPiANCj4gPg0KPiA+IElmIHdlIHdhbnQgdG8gdXNlIGlkLWxvY2F0b3Igc3BsaXQg b2YgYW55IGtpbmQgZm9yIGhhbmRsaW5nIHRyYWZmaWMgdG8NCj4gPiAvIGZyb20gdGhlIEludGVy bmV0LCB0aGVuIHdlIGhhdmUgdG8gdW5kZXJzdGFuZCBob3cgdGhhdCBpcyBzdXBwb3NlZA0KPiA+ IHRvIHdvcmssIGFuZCB3aHksIGJlZm9yZSB3ZSBuZWVkIHRvIGV2YWx1YXRlIERET1MgaW1wbGlj YXRpb25zIG9mIGENCj4gPiBzb2x1dGlvbi4gIEZvciBMSVNQLHRoZSB3b3JraW5nIGdyb3VwIGhh cyBleHBsaWNpdGx5IHNhaWQgdGhhdA0KPiA+IEludGVyLXdpZGUgZGVwbG95bWVudCBpcyBvdXQg b2Ygc2NvcGUuDQo+ID4NCj4gPiBOZXQ6IEkgZG8gbm90IHNlZSBpbiBjdXJyZW50bHkgZGVzY3Jp YmVkIGRlcGxveW1lbnRzLCBhbiBpc3N1ZSB0aGF0DQo+ID4gZGlmZmVyZW50aWF0ZXMgTElTUCBm cm9tIElMQSBpbiB0aGVzZSByZWdhcmRzLiAgQW5kIFRlcnJ5IGhhcyB2ZXJ5DQo+ID4gY2xlYXJs eSBzcGVsbGVkIG91dCB0aGF0IGZvciBtb2JpbGUgb3BlcmF0b3JzIHNwb29maW5nIGZyb20gVUVz IGlzIG5vdA0KPiA+IGNvbnNpZGVyZWQgYW4gaXNzdWUgdGhhdCB0aGUgaW5mcmFzdHJ1Y3R1cmUg bmVlZHMgdG8gZGVhbCB3aWguDQo+IA0KPiBCdXQgdGhlcmUgbWF5IGJlIGEgd2hvbGUgbmV0d29y ayBpbmZyYXN0cnVjdHVyZSBvZiBodW5kcmVkcyBvciBldmVuDQo+IHRob3VzYW5kcyBvZiB1c2Vy cyBiZWhpbmQgYSBVRSwgYW5kIHRoZXJlJ3Mgbm8gZ3VhcmFudGVlIHRoYXQgdGhhdA0KPiBpbmZy YXN0cnVjdHVyZSBwcm9wZXJseSBzdXBwb3J0cyBhbnRpLXNwb29maW5nLiBUaGlzIGJhc2ljYWxs eSB0aGlzIGNhc2UgaGFzIHRoZQ0KPiBzYW1lIHByb2JsZW0gYXMgaW4gdGhlIEludGVybmV0IGNh c2UuDQo+IA0KPiBUb20NCj4gDQo+ID4NCj4gPiBZb3VycywNCj4gPiBKb2VsDQo+ID4NCj4gPg0K PiA+IE9uIDUvMy8xOCA1OjMzIFBNLCBUb20gSGVyYmVydCB3cm90ZToNCj4gPj4NCj4gPj4gT24g VGh1LCBNYXkgMywgMjAxOCBhdCAyOjIzIFBNLCBGSUdVUkVMTEUsIFRFUlJZIEYgPHRmMjkzNEBh dHQuY29tPg0KPiB3cm90ZToNCj4gPj4+DQo+ID4+PiBJbiB0aGUgY2FzZSBvZiBjdXJyZW50IDNH UFAgb3BlcmF0b3JzIGFsbCB0aGUgbWFqb3IgdmVuZG9ycyBzdXBwb3J0DQo+ID4+PiBhbnRpLXNw b29maW5nLiBUaGUgZGVmYXVsdCB3YXMgb24gZm9yIGFsbCBidXQgb25lIHZlbmRvciB3aGljaCBn b3QNCj4gPj4+IGNvcnJlY3RlZCB0aGUgbGFzdCB0aW1lIEkgZGlkIGFuIFJGUCBmb3IgRVBDLiBT byBieSBjb25maWd1cmF0aW9uDQo+ID4+PiB0aGUgR0dTTi9QR1cvUEdXLVUvVVBGIHdpbGwgbm90 IGFsbG93ICB0aGUgVUUgdG8gc2VuZCBwYWNrZXRzIHRoYXQNCj4gPj4+IGRvbid0IG1hdGNoIGVp dGhlciB0aGUgZXhhY3QgSVAgYWRkcmVzcyBvciBwdXNoZWQgc3VibmV0IG9yIHByZWZpeA0KPiA+ Pj4gZGVsZWdhdGlvbiB0aGF0IHdhcyBzZW50IGluIHJlc3BvbnNlIHRvIHRoZSBBUE4gY3JlYXRl IG1lc3NhZ2UuDQo+ID4+PiBPYnZpb3VzbHkgaWYgd2UgcmVtb3ZlIEdUUCBlbmNhcHN1bGF0aW9u IHRoYXQgcHJvdGVjdCBNQVkgbmVlZCB0byBiZQ0KPiBlbmhhbmNlZCB0b3dhcmRzIGFuIEVER0Ug ZWxlbWVudC4NCj4gPj4+DQo+ID4+IFRlcnJ5LA0KPiA+Pg0KPiA+PiBFdmVuIHNvLCB0aGUgd2hv bGUgSW50ZXJuZXQgZG9lcyBub3QgcmVxdWlyZSBhbnRpLXNwb29maW5nLCBub3IgZG8gSQ0KPiA+ PiBiZWxpZXZlIHRoYXQgb3BlcmF0b3JzIGNvdWxkIHJlcXVpcmUgYWxsIGRvd24gc3RyZWFtIG5l dHdvcmsgdGhhdCBhcmUNCj4gPj4gY29ubmVjdGVkIHRvIHN1cHBvcnQgYW50aS1zcG9vZmluZy4g VGhlc2UgYXJlIHdoZXJlIHRoZSBET1MgYXR0YWNrcw0KPiA+PiBvcmdpbmF0ZS4gVGhlIHByb2Js ZW0gaXMgd2hlbiBjYWNoZXMgYXJlIGJlaW5nIGRyaXZlbiBieSB1c2VyIHRhZmZpYw0KPiA+PiBm cm9tIHRoZXNlIGV4dGVybmFsIG5ldHdvcmtzLCBtaXRpZ2F0aW9ucyB0byBkZXRlY3QgRE9TIGJ5 IElQIHNvdXJjZQ0KPiA+PiBhZGRyZXNzIGRvbid0IHdvcmsgd2l0aG91dCBhbnRpLXNwb29maW5n IChidXQgZXZlbiBpZiB0aGV5IGhhZA0KPiA+PiBhbnRpLXNwb29maW5nIHRoYXQgc3RpbGwgZG9l c24ndCB3b3JrIHdoZW4gdW5kZXIgYSBERE9TKS4NCj4gPj4NCj4gPj4gVG9tDQo+ID4+DQo+ID4+ DQo+ID4+DQo+ID4+PiBUaGlzIGlzIGJlaW5nIGNvdmVyZWQgYXMgcGFydCBvZiBvdXIgcGFydGlj aXBhdGlvbiBpbiBhbiBvcGVuIHNvdXJjZQ0KPiA+Pj4gdkVQQyAodmlydHVhbGl6ZSBFUEMsIGh5 cGVydmlzb3IsIGJsYWgsIGJsYWgsIGJsYWgpLiBTbyB0aGVyZSB3aWxsDQo+ID4+PiBiZSBhIG1p Y3JvIHNlcnZpY2UgZmlyZXdhbGwgdGhhdCBjYW4gYmUgZGVwbG95IGF0IHRoZSBlZGdlIHBsdXMg d2UNCj4gPj4+IGFscmVhZHkgaGF2ZSBwbGFubmVkIHN1cHBvcnQgZm9yIGJpZyBuZXR3b3JrIGlu ZnJhc3RydWN0dXJlIHZlbmRvcnMNCj4gPj4+IGFuZCAzR1BQIHN1cHBsaWVzIChDaXNjbywgSnVu aXBlciwgRXJpY3Nzb24sIE5va2lhLCBIdWF3ZWksIC4uLikgdG8NCj4gPj4+IGNvdmVyIHRoaXMu IFNpbmNlIHRoaXMgY2FuICBiZSBhIG5vbi0zR1BQIGVsZW1lbnQgd2Ugd2lsbCBnZXQgdGhpcyBp bnRvDQo+IE9OQVAuDQo+ID4+Pg0KPiA+Pj4gVGh1cyB3ZSBoYXZlIHRoaXMgY292ZXJlZCBib3Ro IGZvciAzR1BQIG5vZGVzLCBtaWNybyBzZXJ2aWNlcyBhbmQNCj4gPj4+IG9wZW4gc291cmNlIGVm Zm9ydHMuIFRvIGdpdmUgZXhhbXBsZXMgd2l0aG91dCB2ZW5kb3IgbmFtZXMgdGhlcmUgYXJlDQo+ ID4+PiBHVFAgYXdhcmUgZmlyZXdhbGxzIHRoYXQgc29tZSBvcGVyYXRvcnMgdXNlLiBJdCByZWFs bHkganVzdCBhbm90aGVyDQo+ID4+PiBjYXBhYmlsaXR5IGluIGNhcnJpZXIgY2xhc3MgYW5kIGJ1 c2luZXNzIGNsYXNzIGZpcmV3YWxscyAoaGFkIHRvIGFkZA0KPiA+Pj4gaXQgdG8gbG9hZCBiYWxh bmNlcnMsIENOQVQvTkFULCBzb21lIFdpLUZpIHJvdXRlcnMgYW5kIHRvIG91ciBETlMNCj4gPj4+ IHNvbHV0aW9uIHdoaWNoIHVzZXMgb3BlbiBzb3VyY2UpLiAgT2J2aW91c2x5IHRoaXMgd2lsbCBi ZSBzdXBwb3J0ZWQNCj4gPj4+IHZpYSBhIFJBRElVUyBmZWVkIGZvciBiYWNrd2FyZHMgY29tcGF0 aWJpbGl0eS4gVG9kYXkgbW9zdCBHVFANCj4gPj4+IGZpcmV3YWxsIHNpbXBseSBmb2xsb3cgdGhl IEdUUC1DIHNpZ25hbGluZyB0byBsZWFybiB0aGUgSVANCj4gPj4+IGFkZHJlc3MoZXMpIGFzc2ln bmVkIHRvIHRoZSBVRSBmb3IgYW4gQVBOLiBJZiB3ZSByZW1vdmUgR1RQIGZyb20NCj4gPj4+IHVz ZXIgcGxhbmUgdGhhdCBkb2Vzbid0IG1lYW4gd2UgcmVtb3ZlIGl0IGZyb20gY29udHJvbCBwbGFu ZSBvciBmb3INCj4gPj4+IGFsbCBob3BzLiBIb3dldmVyLCB3ZSB3aWxsIGxpa2VseSBwdXNoIHRv IGEgbWljcm8gc2VydmljZSBhdCB0aGUNCj4gPj4+IGNlbGwgcGx1cyBJIG5lZWQgdG8gY2hlY2sg aWYgd2UgZXZlciBhc2sgUkFOIHZlbmRvcnMgdG8gc3VwcG9ydCB0aGlzLiBJJ2xsIGFkZA0KPiB0 aGlzIGZvciA1RyBidXQgd2UgYWxyZWFkeSBkaWQgdGhhdCBSRlAgc28gaXQncyBhIGNoYW5nZSBv cmRlciAoeXVjaykuDQo+ID4+Pg0KPiA+Pj4gSSBhbSBub3QgZ29vZCBhdCB3b3Jkc21pdGhpbmcg YnV0IEkgc3VnZ2VzdCB0aGVyZSBiZSBzb21lIHBhcmFncmFwaA0KPiA+Pj4gdGhhdCBjb3ZlcnMg bmV0d29yayBlbGVtZW50cyB0aGF0IGNhbiBleGNlcHQgYSBSQURJVVMgZmVlZC4gSSBuZWVkDQo+ ID4+PiB0byB0YWxrIHRvIG91ciBzdGFuZGFyZHMgdGVhbSB0byBzZWUgaWYgd2Ugd2FudCB0aGlz IG9uIFQ4IChwcm9iYWJseSkuDQo+ID4+Pg0KPiA+Pj4gU28gdG9kYXkgZm9yIGFsbCBBVCZULCBW ZXJpem9uLCBWb2RhcGhvbmUsICAuLi4uLiBJIGtub3cgb3IgYW0NCj4gPj4+IGZhaXJseSBjb25m aWRlbnQgdGhleSBoYXZlIGFudGkgc3Bvb2ZpbmcgdHVuZWQgb24gaW4gdGhlDQo+ID4+PiBHR1NO L1BHVy9VUEYgcGx1cyBJIGtub3cgdGhleSBjYW4gdHVybiB0aGlzIG9uIHBlciBBUE4uIE5vdCBz dXJlIHdoeQ0KPiA+Pj4gYW55b25lIHdvdWxkIGRpc2FibGUgdGhpcyBzaW5jZSB3ZSBpZiB5b3Ug YXJlIGRlbGVnYXRpbmcgYSBzdWJuZXQgdG8NCj4gPj4+IGEgV2ktRmkgaG90c3BvdCAoaW5zdGVh ZCBvZiB0aGUgdHlwaWNhbCBwcml2YXRlIGFkZHJlc3NpbmcgdGhleSB1c2UpLg0KPiA+Pj4NCj4g Pj4+IFdlIGFjdHVhbGx5IGRvbid0IG5lZWQgYW55IDNHUFAgY2hhbmdlcyBzaW5jZSB0aGlzIGlz IGFscmVhZHkNCj4gPj4+IGNvdmVyZWQgdXNpbmcgUkFESVVTIHRvIHBhc3MgdGhlIGluZm9ybWF0 aW9uIHdoZXJlIGl0IG5lZWRzIHRvIGdvLiBJDQo+ID4+PiBzdXNwZWN0IG1vc3Qgd2lsbCBsZXZl cmFnZSB0aGVpciBjYWNoaW5nIFNQUi9VRFIgd2hpY2ggYWxyZWFkeSBoYXMNCj4gPj4+IHRoZSBp bmZvcm1hdGlvbi4gRXZlbiB0aGUgR0dTTiB3ZSBsYXVuY2hlZCBFREdFL0dQUlMgd2hlbiBJIHdh cyBtdWNoDQo+ID4+PiB5b3VuZ2VyIHN1cHBvcnRlZCBhbnRpLXNwb29maW5nIGFuZCBtYW55IHZl bmRvcnMgY292ZXIgdGhpcyB2aWEgYQ0KPiA+Pj4gbnVtYmVyIG9mIG1ldGhvZHMgKGUuZy4gQ09Q UyB3b3JrcyBmb3Igb2xkZXIganVub3MgYW5kIFJBRElVUyBmb3IgQ2lzY28NCj4gSU9TIHJlbGVh c2VzICkuDQo+ID4+Pg0KPiA+Pj4gTXkgc3VnZ2VzdGlvbiBpcyB0aGF0IEkgYW0gd2lsbGluZyB0 byBoZWxwIHdob2V2ZXIgd2FudHMgdG8gY3JhZnQNCj4gPj4+IHRoZSBwYXJhZ3JhcGggYmVjYXVz ZSBJIHN1Y2sgYXQgdGhhdCAoZm9ydHVuYXRlbHkgSSBhbSBnb29kIGF0IG90aGVyDQo+IHRoaW5n cykuDQo+ID4+Pg0KPiA+Pj4gSSBkb24ndCB0aGluayB3ZSBuZWVkIGFueSBjaGFuZ2VzIHRvIGFu eSBzdGFuZGFyZHMgdG8gY292ZXIgdGhpcw0KPiA+Pj4gc2luY2Ugd2UgYWxyZWFkeSBjb3ZlciB0 aGlzIGFuZCBhbHJlYWR5IGFyZSBjb3ZlcmluZyB0aGlzIGlmIHdlDQo+ID4+PiBzdHJpcCBvdXQg R1RQIChhdCBsZWFzdCBmb3Igb25lIGxlZykuIEknbGwgbWFrZSBzdXJlIGl0IGdldHMgaW50bw0K PiA+Pj4gb3VyIFJBTiByZXF1aXJlbWVudHMgaWYgbm90IHRoZXJlIHNpbmNlIHRoYXQgbWF5IGJl IHRoZSBiZXN0IHBsYWNlDQo+ID4+PiBmb3IgdGhhdCBlZGdlLiBQbHVzIEknbGwgZ2V0IGl0IGNv dmVyZWQgdGhydSB0aGUgT05BUCBvcGVuIHNvdXJjZQ0KPiA+Pj4gZWZmb3J0IHdlIGRyb3ZlICh3 ZSBkb25hdGVkIHRoZSBzb2Z0d2FyZSB0byB0aGUgb3BlbiBzb3VyY2UgZWZmb3J0KS4NCj4gPj4+ IFRoYXQgbWVhbnMgRk0sIFBNLCBDTSBhbmQgSU0gd2lsbCBiZSBjb3ZlcmVkIGluIHNvbWUgZnV0 dXJlIE9OQVANCj4gcmVsZWFzZSAodGFrZXMgdGltZSBidXQgZmFzdGVyIHRoYW4gM0dQUCkuDQo+ ID4+Pg0KPiA+Pj4gSXQncyBhIGJpdCBkZWJhdGFibGUgd2hhdCBpcyBSQU4gd2hlbiB1c2luZyB2 aXJ0dWFsaXplZCBuZXR3b3JrDQo+ID4+PiBmdW5jdGlvbnMNCj4gPj4+IChWTkYpIGFuZCBhIGJ1 bmNoIG9mIG9wZW4gc291cmNlIHN0dWZmIHRoYXQgd2UgcHV0IGl0IGludG8gYWxsIG9mDQo+ID4+ PiB0aGUgbmVlZGVkIGVsZW1lbnRzIGxpa2UgU0ROLCBmaXJld2FsbCwgbG9hZCBiYWxhbmNlciAo bm90IHN1cmUNCj4gPj4+IHRoYXQncyBuZWVkZWQgYXQgY2VsbCBzaXRlIGJ1dCBpdCBpcyBmb3Ig Y29yZSBETlMsIHByb3h5LVRERiBhbmQNCj4gPj4+IENOQVQpIG91dCBhdCB0aGUgY2VsbCBzaXRl LiBXZSBhcmVuJ3QgdGhlcmUgeWV0IChzdGlsbCBwaHlzaWNhbA0KPiA+Pj4gZU5CL05SIGFuZCBv YnZpb3VzbHkgd2UgbmVlZCBoYXJkd2FyZSBhc3Npc3QgZXZlbiB3aXRoDQo+ID4+PiB2aXJ0dWFs aXphdGlvbiBwbHVzIHRpZ2h0IGNvbnRyb2wgb2YgdGltaW5nKS4gSSBhbSBsb29raW5nIGZvcndh cmQgdG8gd2hlbiB3ZQ0KPiBzdGFydCB1c2luZyBjb250YWluZXJzLg0KPiA+Pj4NCj4gPj4+IEZv ciBvdXIgY29yZSBJIGFtIHN1cmUgd2Ugd2lsbCB1c2Ugb3VyIFVEUiBWTkYgYXMgdGhlIGNhY2hl IGZvcg0KPiA+Pj4gd2hhdGV2ZXIgY29tZXMgb3V0IG9mIHRoaXMgZWZmb3J0IGluIGZpbmFsIHN0 YW5kYXJkcy4gVGhlDQo+ID4+PiBpbmZvcm1hdGlvbiBpcyBhbHJlYWR5IHRoZXJlIChJTUVJLCBk ZXZpY2UgdmVuZG9yLCBzdWJzY3JpcHRpb24NCj4gPj4+IGluZm9ybWF0aW9uLCBVRSBJUCBhZGRy ZXNzLCBBUE4sIGV0Yy4pLiBJZiB3ZSBkbyBhbnl0aGluZyBpdCB3b3VsZA0KPiA+Pj4gYmUgdG8g YXVnbWVudCBhbiBvcGVuIHNvdXJjZSBhbmQgaWYgbmVlZGVkIGEgM0dQUC4gSSBkb24ndCB0aGlu ayB3ZSBuZWVkDQo+IGFueSBjaGFuZ2VzIGJ1dCBpdCdzIGFsd2F5cyBiZXN0IHRvIHZlcmlmeS4N Cj4gPj4+IEZvciBjdXJyZW50IFJBTiBhbiBhbnRpLXNwb29maW5nIGZlYXR1cmUgd291bGQgY29t ZSBmcm9tIEVNUyB3aGljaA0KPiA+Pj4gY2FuIGJlIHZpYSBPTkFQLiBJIGRvbid0IHRoaW5rIHRo YXQgaXMgYSBzdGFuZGFyZHMgZWZmb3J0IHRoaW5nDQo+ID4+PiBzaW5jZSBpdCdzIGEgZmVhdHVy ZSB3aGljaCBtYXkgb3IgbWF5IG5vdCBhbHJlYWR5IGJlIGNvdmVyZWQgYnV0IGl0DQo+ID4+PiB3 aWxsIGJlIGluIGZ1dHVyZSBSQU4gcmVsZWFzZXMgcHJvYmFibHkgc3RhcnRpbmcgd2l0aCBlTkIv TlIgd2l0aA0KPiA+Pj4gc29tZSB2ZW5kb3IgcmVsZWFzZSBpZiBpdCdzIG5vdCBhbHJlYWR5IGEg ZmVhdHVyZS4gSSB3YW50IHRvIHNheQ0KPiA+Pj4gRXJpY3Nzb24gYW5kIE5va2lhIGFscmVhZHkg Y2FuIGRvIHRoaXMgaW4gZU5CIGJ1dCBJIG5lZWQgdG8gZ28gdGhydQ0KPiBjaGFubmVscyB0byBh c2suDQo+ID4+Pg0KPiA+Pj4gU28gbWF5YmUgdGhhdCBwYXJhZ3JhcGggcmVjb21tZW5kcyBpbXBs ZW1lbnRpbmcgYW50aS1zcG9vZmluZyBhdCBhbGwNCj4gPj4+IGVkZ2VzIGFuZCBsZWF2ZXMgaXQg YXQgdGhhdC4gT3Igd2UgY291bGQgc2F5IGFsbCBlZGdlcyBpbmNsdWRpbmcgUkFODQo+ID4+PiBp ZiB0aGF0IG1ha2VzIHBlb3BsZSBoYXBweS4NCj4gPj4+DQo+ID4+Pj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPj4+PiBGcm9tOiA1Z2FuZ2lwIDw1Z2FuZ2lwLWJvdW5jZXNAaWV0Zi5v cmc+IE9uIEJlaGFsZiBPZiBUb20gSGVyYmVydA0KPiA+Pj4+IFNlbnQ6IFRodXJzZGF5LCBNYXkg MDMsIDIwMTggMTA6NDYgQU0NCj4gPj4+PiBUbzogRGlyay52b24tSHVnb0B0ZWxla29tLmRlDQo+ ID4+Pj4gQ2M6IFRvbSBIZXJiZXJ0IDx0b21AaGVyYmVydGxhbmQuY29tPjsgSm9lbCBNLiBIYWxw ZXJuDQo+ID4+Pj4gPGptaEBqb2VsaGFscGVybi5jb20+OyBpbGFAaWV0Zi5vcmc7IEFsYmVydG8g Um9kcmlndWV6LU5hdGFsDQo+ID4+Pj4gPHJvZHJpZ3Vlem5hdGFsQGdtYWlsLmNvbT47IDVHQU5H SVAgPDVnYW5naXBAaWV0Zi5vcmc+DQo+ID4+Pj4gU3ViamVjdDogUmU6IFs1Z2FuZ2lwXSBbSWxh XSBJTEEgZm9yd2FyaW5nIFtXYXMgUmU6IFByb2JsZW0NCj4gPj4+PiBTdGF0ZW1lbnRdDQo+ID4+ Pj4NCj4gPj4+PiBPbiBUaHUsIE1heSAzLCAyMDE4IGF0IDk6MjMgQU0sICA8RGlyay52b24tSHVn b0B0ZWxla29tLmRlPiB3cm90ZToNCj4gPj4+Pj4NCj4gPj4+Pj4gSGkgVG9tLA0KPiA+Pj4+PiBJ IHVuZGVyc3RhbmQgeW91IGNvcnJlY3RseSB0aGF0IERET1MgYXR0YWNrcyBjYW4gbmV2ZXIgYmUN Cj4gPj4+Pj4gY29tcGxldGVseQ0KPiA+Pj4+DQo+ID4+Pj4gcHJldmVudGVkIHdoYXRldmVyIHBy b3RvY29sIHlvdSB1c2UuDQo+ID4+Pj4+DQo+ID4+Pj4+IEl0IHdpbGwgaG93ZXZlciBhbHdheXMg cmVtYWluIHJlbGF0ZWQgdG8ga25vd24gSVAgYWRkcmVzc2VzIGFuZA0KPiA+Pj4+PiB0aGUgbW9y ZQ0KPiA+Pj4+DQo+ID4+Pj4gdmVyc2F0aWxlIHRoZXNlIGFyZSBoYW5kbGVkIGEgbWl0aWdhdGlv biBzdHJhdGVneSBjb3VsZCBiZSBkZXNpZ25lZC4NCj4gPj4+Pg0KPiA+Pj4+IERpcmssDQo+ID4+ Pj4NCj4gPj4+PiBJIGRpc2FncmVlLiBJUCBhZGRyZXNzZXMgY2FuIHRvbyBlYXNpbHkgYmUgc3Bv b2ZlZCwgaXQncyBlYXN5IHRvDQo+ID4+Pj4gaGlkZSBpZGVudGl0eSBiZWhpbmQgYSBOQVQgKHNl ZSBkaXNjdXNzaW9uIGFib3V0IENHTkFUIGFuZCBsYXcNCj4gPj4+PiBlbmZvcmNlbWVudCBvbiBp bnQtYXJlYSBsaXN0KSwgYW5kIHRyeWluZyB0byB0dXJuIG9mZiBpbmRpdmlkdWFsDQo+ID4+Pj4g YWRkcmVzc2VzIGRvZXNuJ3Qgd29yayBpZiBpdCdzIGEgRERPUy4gVGhpcyBpcyBub3RoaW5nIG5l dy4gRm9yDQo+ID4+Pj4gaW5zdGFuY2UsIGNvbnRlbnQgcHJvdmlkZXJzIGhhdmUgbG9uZyBhY2Nl cHRlZCB0aGUgZmFjdCB0aGF0IHRoZXkNCj4gPj4+PiBjYW4ndCBwcmV2ZW50IFNZTiBhdHRhY2tz IGFuZCB0aGVyZSdzIGxpdHRsZSBwb2ludCB0byB0cnlpbmcgdG8gZ28NCj4gPj4+PiBiYWNrIHRv IHNvdXJjZSBJUCBhZGRyZXNzICh0aGV5IGFyZSBhbHdheXMgc3Bvb2ZlZCBpbiBhIFNZTg0KPiA+ Pj4+IGF0dGFjaykuIFRoZSBiZXR0ZXIgc3RyYXRlZ3kgaXMgdG8gYWJzb3JiIHRoZSBhdHRhY2sg YW5kIG1pbmltaXplDQo+ID4+Pj4gdGhlIG5lZ2F0aXZlIGVmZmVjdHMgc28gdGhhdCB0aGUgYXR0 YWNrIGlzIG5vdCB3b3J0aCB0aGUgZWZmb3J0Lg0KPiA+Pj4+DQo+ID4+Pj4+IEFzIHlvdSBtYXkg aGF2ZSBzZWVuIHdlIG1lbnRpb24gaW1wcm92ZWQgaGFuZGxpbmcgb2YgbWFwcGluZw0KPiA+Pj4+ PiBzeXN0ZW1zDQo+ID4+Pj4NCj4gPj4+PiBhbmQgc3Vic2VxdWVudGx5IG9mIERET1MgcHJvdGVj dGlvbiBhbHNvIGluIHRoZSBjdXJyZW50IHZlcnNpb24gb2YNCj4gPj4+PiBvdXIgUFMgZG9jdW1l bnQgaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLQ0KPiA+ Pj4+IDNBX19naXRodWIuY29tX2JzYXJpa2F5YV9hdGljX2Jsb2JfbWFzdGVyX2F0aWNrLQ0KPiA+ Pj4+IDVGcHJvYmxlbXN0YXRlbWVudC4zLnR4dCZkPUR3SUNBZyZjPUxGWVotDQo+ID4+Pj4NCj4g bzlfSFVNZU1UU1FpY3ZqSWcmcj10T19zTnhhMk5UeHdsMnBhSklmNHp3Jm09ellrUEl0anVITXVH bEpYRDVLXzQNCj4gPj4+PiBPc3RWT0wxT1FpQTk4ZmdCSjljMUdqbyZzPWpMTF85YTU2UjhJYzhv M3VKY1I4bXJGLQ0KPiA+Pj4+IEprekxMOTdoOHJtWlRfRXFYblEmZT0gIHdoaWNoIEJlaGNldCBo YXMgYW5ub3VuY2VkIHJlY2VudGx5Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBNYXkgSSBhc2sgeW91IHRv IHBsZWFzZSBjb21tZW50IG9uIHRoZSBpZGVhcyBvdXRsaW5lZCB0aGVyZT8NCj4gPj4+Pg0KPiA+ Pj4+DQo+ID4+Pj4gSSBkb24ndCBzZWUgbXVjaCBkaWZmZXJlbmNlIGluIHRoZSBsYXRlc3QgdmVy c2lvbi4gRm9yIGEgcHJvYmxlbQ0KPiA+Pj4+IHN0YXRlbWVudCwgSSBzdGlsbCB0aGluayB0aGVy ZSBpcyB0b28gbXVjaCBmb2N1cyBvbiB0aGUgc29sdXRpb25zDQo+ID4+Pj4gYW5kIG5vdCBuZWFy bHkgZW5vdWdoIGRlc2NyaXB0aW9uIG9mIHdoYXQgdGhlIGFjdHVhbCBwcm9ibGVtcyBhcmUNCj4g Pj4+PiB0byBiZSBzb2x2ZWQuDQo+ID4+Pj4NCj4gPj4+PiBUb20NCj4gPj4+Pg0KPiA+Pj4+PiBU aGFua3MhDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+PiBCZXN0IFJlZ2FyZHMNCj4gPj4+Pj4gRGly aw0KPiA+Pj4+Pg0KPiA+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+PiBG cm9tOiA1Z2FuZ2lwIFttYWlsdG86NWdhbmdpcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgVG9tDQo+ID4+Pj4+IEhlcmJlcnQNCj4gPj4+Pj4gU2VudDogTWl0dHdvY2gsIDIuIE1haSAy MDE4IDAxOjIwDQo+ID4+Pj4+IFRvOiBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5j b20+DQo+ID4+Pj4+IENjOiBUb20gSGVyYmVydCA8dG9tQGhlcmJlcnRsYW5kLmNvbT47IGlsYUBp ZXRmLm9yZzsgQWxiZXJ0bw0KPiA+Pj4+PiBSb2RyaWd1ZXotTmF0YWwgPHJvZHJpZ3Vlem5hdGFs QGdtYWlsLmNvbT47IDVHQU5HSVANCj4gPj4+Pj4gPDVnYW5naXBAaWV0Zi5vcmc+DQo+ID4+Pj4+ IFN1YmplY3Q6IFJlOiBbNWdhbmdpcF0gW0lsYV0gSUxBIGZvcndhcmluZyBbV2FzIFJlOiBQcm9i bGVtDQo+ID4+Pj4+IFN0YXRlbWVudF0NCj4gPj4+Pj4NCj4gPj4+Pj4gT24gVHVlLCBNYXkgMSwg MjAxOCBhdCAzOjQ5IFBNLCBKb2VsIE0uIEhhbHBlcm4NCj4gPj4+Pj4gPGptaEBqb2VsaGFscGVy bi5jb20+DQo+ID4+Pj4NCj4gPj4+PiB3cm90ZToNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBZb3Ugc2Vl bSB0byBiZSBzYXlpbmcgdGhhdCBldmVuIHRob3VnaCBub3QgYWxsIERET1MgYXR0YWNrcyBhcmUN Cj4gPj4+Pj4+IHN0cnVjdHVyYWxseSB0aGUgc2FtZSwgYW5kIGV2ZW4gdGhvdWdoIGlmIElMQSB3 ZXJlIHdpZGVseSBhZG9wdGVkDQo+ID4+Pj4+PiBub3QgYWxsIElMQSBuZXR3b3JrcyB3b3VsZCBi ZSBzdHJ1Y3R1cmFsbHkgdGhlIHNhbWUsIHRoZXJlIHNob3VsZA0KPiA+Pj4+Pj4gbm9uZXRoZWxl c3MgYmUgb25lIHJlcXVpcmVkIHFheSBvZiBoYW5kbGluZyBERE9TPw0KPiA+Pj4+Pg0KPiA+Pj4+ Pg0KPiA+Pj4+PiBZZXMsIGF0IGxlYXN0IGFzIGNvcmUgZGVmYXVsdCBpbiB0aGUgcHJvdG9jb2wu IEl0J3MgcHJlY2lzZWx5DQo+ID4+Pj4+IF9iZWNhdXNlXyBub3QgYWxsDQo+ID4+Pj4NCj4gPj4+ PiBERE9TIGF0dGFja3MgYXJlIHN0cnVjdHVyYWxseSB0aGUgc2FtZS4gQW4gYXR0YWNrZXIgaXMg bm90IGdvaW5nIHRvDQo+ID4+Pj4gY29uZm9ybSB0byB0byBvdXIgZXhwZWN0YXRpb25zIG9mIHdo YXQgdGhleSBzaG91bGQgYmUgZG9pbmcsIHNvIGlmDQo+ID4+Pj4gd2UgZW5hYmxlIExJU1Agb3B0 aW9uIE4gdG8gbWl0aWdhdGUgb25lIGZvcm0gb2YgYXR0YWNrLCB0aGV5IHdpbGwNCj4gPj4+PiBq dXN0IHVzZSBhbm90aGVyIGF0dGFjayB0aGF0IGlzbid0IG1pdGlnYXRlZC4gRm9yIGV4YW1wbGUs IGlmIHRoZQ0KPiA+Pj4+IG1pdGlnYXRpb24gaXMgdG8gaWRlbnRpZnkgYXR0YWNrZXJzIGJ5IGFk ZHJlc3Mgd2hlbiByZXF1ZXN0cyBmcm9tDQo+ID4+Pj4gdGhlIGFkZHJlc3MgZXhjZWVkIGEgdGhy ZXNob2xkIHRoZW4gdGhpcyB3b3JrcyBhcyBsb25nIGFzIHRoZQ0KPiA+Pj4+IGF0dGFja2VyIHN0 cmlrZXMgZnJvbSBvbmUgbWFjaGluZSwgYnV0IGl0IGZhbGxzIGFwYXJ0IGlmIHRoZQ0KPiA+Pj4+ IGF0dGFja2VyIGxhdW5jaGVzIGEgRERPUyBhdHRhY2sgZnJvbSBzZXZlcmFsIGhvc3RzIHdoZXJl IHJlcXVlc3RzDQo+ID4+Pj4gZnJvbSBub25lIG9mIHRoZSBob3N0cyBleGNlZWQgdGhlIHRocmVz aG9sZC4NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4gVGhlIElMQSBtb2RlbCB3b3JrcyBiZWNh dXNlIGl0IGFzc3VtZXMgdGhlcmUgaXMgbm8gYWJzb2x1dGUgd2F5IHRvDQo+ID4+Pj4+IHByZXZl bnQNCj4gPj4+Pg0KPiA+Pj4+IHRoZSB0aGUgd29yc3QgY2FzZSBhdHRhY2sgb24gYSBjYWNoZSB3 aGljaCBpcyB0byBjb21wbGV0ZWx5IGtpbGwgaXQNCj4gPj4+PiAoaS5lLiBkcml2ZSBpdCB0byAw JSBoaXQgcmF0ZSkuIEluIHRoaXMgc3RhdGUgdGhlIGJlaGF2aW9yDQo+ID4+Pj4gc3ViLW9wdGlt YWwgcm91dGluZywgd2hpY2ggaXMgbXVjaCBiZXR0ZXIgdGhhbiBsb3NzIG9mIHNlcnZpY2UuDQo+ ID4+Pj4gVGhpcyBpcyBub3QgZGVwZW5kZW50IG9uIHRoZSBzdHJ1Y3R1cmUgb2YgdGhlIGF0dGFj aywgbmV0d29yaw0KPiA+Pj4+IHRvcG9sb2d5LCBvciB0aGUgbmV0d29yayBvcGVyYXRvciBnZXR0 aW5nIHRoZSBjb25maWd1cmF0aW9uIGp1c3QNCj4gPj4+PiByaWdodC0tDQo+ID4+Pj4gaXQgaXMg aW5oZXJlbnQgaW4gdGhlIHByb3RvY29sLg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+PiBUb20N Cj4gPj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBZb3VycywNCj4gPj4+Pj4+IEpvZWwNCj4gPj4+ Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gT24gNS8xLzE4IDY6MzIgUE0sIFRvbSBIZXJiZXJ0IHdy b3RlOg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBPbiBUdWUsIE1heSAxLCAyMDE4 IGF0IDI6NTkgUE0sIEFsYmVydG8gUm9kcmlndWV6LU5hdGFsDQo+ID4+Pj4+Pj4gPHJvZHJpZ3Vl em5hdGFsQGdtYWlsLmNvbT4gd3JvdGU6DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+ Pj4+IE9uIFR1ZSwgTWF5IDEsIDIwMTggYXQgMTA6MTYgQU0sIFRvbSBIZXJiZXJ0DQo+IDx0b21A aGVyYmVydGxhbmQuY29tPg0KPiA+Pj4+DQo+ID4+Pj4gd3JvdGU6DQo+ID4+Pj4+Pj4+Pg0KPiA+ Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBJIHRoaW5rIHlvdSd2ZSBtaXN1bmRl cnN0b29kIG15IHBvc2l0aW9uLiBDYWNoZXMgYXJlIF92ZXJ5Xw0KPiA+Pj4+Pj4+Pj4gaW1wb3J0 YW50IHRvIGVsaW1pbmF0ZSB0aGUgY29zdCB0cmlhbmd1bGFyIHJvdXRpbmcgKGxhdGVuY3ksDQo+ ID4+Pj4+Pj4+PiBhdmVyYWdlIHBhdGgNCj4gPj4+Pg0KPiA+Pj4+IGxvYWQpLg0KPiA+Pj4+Pj4+ Pj4NCj4gPj4+Pj4+Pj4+IFRoaXMgcmVkdWNlcyBsYXRlbmN5IGFuZCByZWR1Y2VzIGF2ZXJhZ2Ug bG9hZCBvbiBJTEEtUnMuIEJ1dCwgYW5kDQo+ID4+Pj4+Pj4+PiB0aGlzIGlzIHRoZSBjcml0aWNh bCBwYXJ0LCBjYWNoZXMgYXJlIG9ubHkgYW4gX29wdGltaXphdGlvbl8gaW4NCj4gPj4+Pj4+Pj4+ IElMQS4gVGhhdCBtZWFucyBpZiB0aGUgY2FjaGUgaXMgcmVuZGVyZWQgaW5lZmZlY3RpdmUgKGxp a2UgYnkgYQ0KPiA+Pj4+Pj4+Pj4gd2VsbCBjcmFmdGVkIERPUw0KPiA+Pj4+Pj4+Pj4gYXR0YWNr KSB0aGVuIHRoZSBvbmx5IGVmZmVjdCBpcyB0aGF0IHRoZSBvcHRpbWl6YXRpb24gaXMgbG9zcyAo aS5lLg0KPiA+Pj4+Pj4+Pj4gZ3JlYXRlciBsYXRlbmN5IGR1ZSB0byB0cmlhbmd1bGFyIHJvdXRl ciktLSB0aGlzIGlzIHF1YW50aXRpdmVseQ0KPiA+Pj4+Pj4+Pj4gdGhlIHdvcnN0IGVmZmVjdCBv ZiB0aGUgYXR0YWNrIG9uIGFuIElMQSBjYWNoZS4gVGhpcyBjYW4gYmUNCj4gPj4+Pj4+Pj4+IGNv bnRyYXN0ZWQgdGhhdCB0byBMSVNQIHdoZXJlIHRoZSB3b3JzdCBjYXNlIGVmZmVjdHMgb2YgYSBE T1MNCj4gPj4+Pj4+Pj4+IGF0dGFjayBvbiB0aGUgY2FjaGUgaXMgbG9zcyBvZiBzZXJ2aWNlIGZv ciB1c2VycyAoaW5maW5pdGUgbGF0ZW5jeQ0KPiA+Pj4+Pj4+Pj4gc2luY2UgcGFja2V0cyBjYW4g YmUgZHJvcHBlZCBvciBpbmRlZmluaXRlbHkgYmxvY2tlZCBvbiBhIGNhY2hlDQo+ID4+Pj4+Pj4+ PiBtaXNzKS4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4N Cj4gPj4+Pj4+Pj4gVGhpcyBjYW4gYmUgbWlzbGVhZGluZy4gVGhpcyBpcyBub3QgY29tcGFyaW5n IExJU1AgdnMgSUxBLCB0aGlzIGlzDQo+ID4+Pj4+Pj4+IGNvbXBhcmluZyB0aGUgbW9kZWxzIG9m IFJlcXVlc3QvUmVwbHkgYXQgdGhlIGVkZ2UgdnMgTm90aWZpY2F0aW9ucw0KPiA+Pj4+Pj4+PiAo YWthIFJlZGlyZWN0cykgYXQgdGhlIGNvcmUuIEJvdGggTElTUC1DUCBhbmQgSUxBTVAgc3VwcG9y dCB0aGVzZQ0KPiA+Pj4+Pj4+PiB0d28gbW9kZWxzLg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBC ZXNpZGVzLCB0aGlzIGlzIGFzc3VtaW5nIGFuIHNjZW5hcmlvIHdoZXJlIHRoZSBvbmx5IGZlYXNp YmxlIERPUw0KPiA+Pj4+Pj4+PiBtaXRpZ2F0aW9uIGlzIGFic29yYmluZyB0aGUgYXR0YWNrLiBU aGVyZSBhcmUgb3RoZXIgc2NlbmFyaW9zIHdoZXJlDQo+ID4+Pj4+Pj4+IG90aGVyIGNvdW50ZXJt ZWFzdXJlcyBhcmUgcG9zc2libGUuIEZvciBpbnN0YW5jZSwgaWYgeW91IGhhdmUgYQ0KPiA+Pj4+ Pj4+PiBkZXBsb3ltZW50IHdoZXJlIHlvdSBjYW4gcHJldmVudCBhZGRyZXNzIHNwb29maW5nLCBj b3VudGluZyBhbmQNCj4gPj4+Pj4+Pj4gYmxvY2tpbmcgbWlzYmVoYXZpbmcgbm9kZXMgb2ZmZXJz IHNpbWlsYXIgRE9TIHByb3RlY3Rpb24gYW5kDQo+ID4+Pj4+Pj4+IHJlcXVpcmVzIHdheSBsZXNz IGluZnJhc3RydWN0dXJlIHJlc291cmNlcy4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+PiBBbGJlcnRv LA0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gVGhlIGFuc3dlciB0byBteSBxdWVzdGlvbiBvZiBob3cg ZG9lcyBMSVNQIGFkZHJlc3MgRE9TIGF0dGFja3MNCj4gc2VlbXMNCj4gPj4+Pj4+PiB0byBiZSAi dGhlcmUgYXJlIG1hbnkgb3B0aW9ucyIuIFNvbWUgb2YgdGhlIG9wdGlvbnMgYXJlIHRvIGFzc3Vt ZQ0KPiA+Pj4+Pj4+IHRoYXQgRE9TIGRvZXMgbm90IGV4aXN0IGluIHRoZSBuZXR3b3JrLCBzb21l IGFzc3VtZSBleHRlcm5hbA0KPiA+Pj4+Pj4+IGNvbmZpZ3VyYXRpb24gbGlrZSBhZGRyZXNzIHNw b29maW5nIGlzIGVuYWJsZWQsIHNvbWUgYXNzdW1lIHRoYXQNCj4gPj4+Pj4+PiBhdHRhY2tzIGNh biBiZSBpZGVudGlmaWVkIGFuZCBjYW4gYmUgc3RvcHBlZCBhdCB0aGUgc291cmNlLCBzb21lDQo+ ID4+Pj4+Pj4gbWlnaHQgYXNzdW1lIHRoYXQgZXZlcnl0aGluZyBpcyBva2F5IGJlY2F1c2UgdGhl cmUncyBuZXZlciBiZWVuIGENCj4gPj4+Pj4+PiBET1MgYXR0YWNrIGJlZm9yZS4gSSBoYXZlIHll dCB0byBzZWUgdGhlIGVmZmVjdHMgb2YgYW55IG9mIHRoZXNlDQo+ID4+Pj4+Pj4gcXVhbnRpZmll ZCwgYW5kIG5vbmUgb2YgdGhlc2Ugc3RhdGUgaG93IHRoZSBMSVNQIF9wcm90b2NvbF8gaXRzZWxm DQo+ID4+Pj4+Pj4gYWRkcmVzc2VzIERPUy4gSXQgbWF5IHNlZW0gY291bnRlci1pbnR1aXRpdmUs IGJ1dCBvZmZlcmluZyBhIGJ1bmNoDQo+ID4+Pj4+Pj4gb2Ygb3B0aW9ucyByZWFsbHkgaXMgbm90 IG5lY2Vzc2FyaWx5IGEgZ29vZCB0aGluZy0tIHNvbWV0aW1lIGxlc3MgaXMNCj4gPj4+Pj4+PiBt b3JlLiBUbyBwdXQgdGhpcyBhbm90aGVyIHdheSBMSVNQIGhhcyBiZWVuIHJlamVjdGVkIGZyb20g TGludXgNCj4gPj4+Pj4+PiBwcmVjaXNlbHkgYmVjYXVzZSBvZiBpdHMgc3VzY2VwdGliaWxpdHkg dG8gRE9TLiBJZiB5b3Ugd2VyZSB0byB0cnkNCj4gPj4+Pj4+PiBhZ2FpbiBhbmQgdGhlIGJlc3Qg YW5zd2VyIHRvIHRoZSBET1MgcXVlc3Rpb24gaXMgdGhhdCBpdCdzIHVwIHRvIHRoZQ0KPiA+Pj4+ Pj4+IG9wZXJhdG9yIHRvIGZpZ3VyZSBvdXQgdGhlIHJpZ2h0IG9wdGlvbnMgdG8gdXNlLCB0aGVu IEkgYmVsaWV2ZSBpdA0KPiA+Pj4+Pj4+IHdvdWxkIGJlIHNvdW5kbHkgcmVqZWN0ZWQgYWdhaW4u IFRoYXQgYXBwcm9hY2ggZG9lcyBub3Qgd29yayBhdA0KPiA+Pj4+Pj4+IHNjYWxlLg0KPiA+Pj4+ Pj4+DQo+ID4+Pj4+Pj4gVG9tDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+Pj4+IGlsYSBtYWlsaW5nIGxp c3QNCj4gPj4+Pj4+PiBpbGFAaWV0Zi5vcmcNCj4gPj4+Pj4+PiBodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+IDNBX193d3cuaWV0Zi5vcmdfbWENCj4g Pj4+Pj4+PiBpbG1hbl9saXN0aW5mb19pbGEmZD1Ed0lDQWcmYz1MRllaLQ0KPiA+Pj4+DQo+ID4+ Pj4gbzlfSFVNZU1UU1FpY3ZqSWcmcj10T19zTnhhMk5UeHdsDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+ Pg0KPiA+Pj4+DQo+IDJwYUpJZjR6dyZtPXpZa1BJdGp1SE11R2xKWEQ1S180T3N0Vk9MMU9RaUE5 OGZnQko5YzFHam8mcz1CTzNzbnQ4Qw0KPiA+Pj4+IFJRDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBn eTF4d2h4MkNZMTBWVWJNX3JnbnRncFY5azMtQ3NrZDgmZT0NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4N Cj4gPj4+Pj4NCj4gPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPj4+Pj4gNWdhbmdpcCBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4gNWdhbmdpcEBp ZXRmLm9yZw0KPiA+Pj4+PiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs P3U9aHR0cHMtDQo+IDNBX193d3cuaWV0Zi5vcmdfbWFpbA0KPiA+Pj4+PiBtYW5fbGlzdGluZm9f NWdhbmdpcCZkPUR3SUNBZyZjPUxGWVotDQo+ID4+Pj4NCj4gPj4+PiBvOV9IVU1lTVRTUWljdmpJ ZyZyPXRPX3NOeGEyTlR4d2wNCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pg0KPiAycGFKSWY0encm bT16WWtQSXRqdUhNdUdsSlhENUtfNE9zdFZPTDFPUWlBOThmZ0JKOWMxR2pvJnM9Rm5RTE1pcmUN Cj4gPj4+PiBNaUtDDQo+ID4+Pj4+DQo+ID4+Pj4+IFNrUGFPR0ZDeWJ6RGMyaTJ5NDlDZ3RibDZt Q0xjOWMmZT0NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+PiA1Z2FuZ2lwIG1haWxpbmcgbGlzdA0KPiA+ Pj4+IDVnYW5naXBAaWV0Zi5vcmcNCj4gPj4+PiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+ID4+Pj4gM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xp c3RpbmZvXzVnYW5naXAmZD1Ed0lDQWcmYz1MRllaLQ0KPiA+Pj4+DQo+IG85X0hVTWVNVFNRaWN2 aklnJnI9dE9fc054YTJOVHh3bDJwYUpJZjR6dyZtPXpZa1BJdGp1SE11R2xKWEQ1S180DQo+ID4+ Pj4NCj4gT3N0Vk9MMU9RaUE5OGZnQko5YzFHam8mcz1GblFMTWlyZU1pS0NTa1BhT0dGQ3liekRj MmkyeTQ5Q2d0Ymw2bUMNCj4gPj4+PiBMYzljJmU9DQo+ID4+DQo+ID4+DQo+ID4NCg== From nobody Thu May 3 16:40:26 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B6612DA70 for ; Thu, 3 May 2018 16:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 ZRpCjGfg-ki8 for ; Thu, 3 May 2018 16:40:19 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 4637212E036 for ; Thu, 3 May 2018 16:40:19 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id f1-v6so25259701qtj.6 for ; Thu, 03 May 2018 16:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rsl1dc1/3CbNxRtBRWL1KsLxaf1DgdK0e9CgI/XVzHE=; b=XoNoPNWmM61skuKUAeNzW7+Aj4FIKHH30oVwgMU/2mRRlj/cknERmt2dwAa3G9BcrZ qifV8hg3Q0AYHBo4+vSVIb+s8u0e4IVht5QE80iFnpWHJlOP/6TTLy+C0ATZbgELWBKN oYDyv6lCjzyBqU9r22ei8feQwzj68jgUWCebH9ClQurX/oDnLLaUO1RsJ7mjInl/djMW Bdnzux8h1rbPu8W590RRiYCdOU+bfRNj/1v/1mbBwAIRQOxM+CVNulDzHSD+GWymYtCA JH+2O3nhLr3eqWbB7QePkyZlEOnywdVxua5Qqp7cz95Z0dZlnFYvPqyQGP2abo9t/Dql e5qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=rsl1dc1/3CbNxRtBRWL1KsLxaf1DgdK0e9CgI/XVzHE=; b=dm39kWr829yGNLEuKec1ihleY+15BILOT9xJ5AZyj+9UywwSqV+D7Qdmb5LltIcW1D cRN4j4nZ3zK/nv3rLi9UWBwjTTL1Y6OrtUDFdwfshxgqtLU9OdPJ/dUaJJqh39ZFWV0f dVK6jKBZREnYGvs849kiMhXpKHceuMBzAS3CreUZk6uka33I3SuTdJShBiU4JQ2XVrb9 RmnVEJLZKosYGkJd9aPteJbCbIcjpGgMl73TtR6Nv9+gIEY9Fas5KwYXJEExUmdtPOCb +Dl4ent8o+Jkdq6+Rrz0BU4ihe4LYWAzfZ64iaekcYZa4l2HdhuuTebegUQqC9Xyy+D+ 6LLw== X-Gm-Message-State: ALQs6tD31rGlRYX6rdFl96tgmWyXcURQHnhMPC27hpLND4VzTupHV0dT fnZYbCrejUXcVhs8QKgZlFQlzatMeUJjjDBgjYiqzQ== X-Google-Smtp-Source: AB8JxZovvX/6wacPVmw1ZWDwAy+OFMpzRsWAAkcgxPZI5YFy4LJzELW4Og1M+j54gC5QzvJGKBqKdZDuTrdId0kzW9I= X-Received: by 2002:ac8:2a77:: with SMTP id l52-v6mr20672676qtl.396.1525390818074; Thu, 03 May 2018 16:40:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.48.66 with HTTP; Thu, 3 May 2018 16:40:17 -0700 (PDT) In-Reply-To: <1AFE10CF28AE8B4C9663445736B8034D3822FC27@CAFRFD1MSGUSRJI.ITServices.sbc.com> References: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> <8aee42db5f0f407c86fda881769ceb77@HE105715.emea1.cds.t-internal.com> <1AFE10CF28AE8B4C9663445736B8034D3822FAFE@CAFRFD1MSGUSRJI.ITServices.sbc.com> <0cbb9987-0b47-9428-3db7-2c9fab821268@joelhalpern.com> <1AFE10CF28AE8B4C9663445736B8034D3822FC27@CAFRFD1MSGUSRJI.ITServices.sbc.com> From: Tom Herbert Date: Thu, 3 May 2018 16:40:17 -0700 Message-ID: To: "FIGURELLE, TERRY F" Cc: Tom Herbert , "Joel M. Halpern" , "Dirk.von-Hugo@telekom.de" , "ila@ietf.org" , Alberto Rodriguez-Natal , 5GANGIP <5gangip@ietf.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 23:40:24 -0000 On Thu, May 3, 2018 at 3:53 PM, FIGURELLE, TERRY F wrote: > No. We have always block unsolicited traffic from the Internet and it is = too complicated to discuss here. > The fact that it is "too complicated to discuss" underscores the problem. These are IETF protocols under discussion, and as such they are supposed to work and be robust across a variety of use cases and environments. While AT&T may have the staff to carefully anayze their network and wade through all the complexity, not everyone has such capabilities. This is probably a major reason why your argument wouldn't help get LISP into Linux, if were accepted then people will start using it without fully understanding the ramifications and they'll be exposed to DOS-- all the protocol seems to say is there are many options to chose from and you have to decide what's best for you. As I said before, the answer to the question how does a protocol address DOS should be clear and consise. If there is an answer for LISP that does that I would like to see the details (maybe in the same fashion as how I demonstrated operation of ILA cache). Tom > We even did this way back for CDPD. For dedicated APN's we allow the ente= rprise to tell us what rules they want to protect the mobile from their net= work and what traffic to not allow from the mobile. This is one of the reas= ons firewalls and CNAT cost more if they support mobility features. We spen= t a lot of time working with potential vendors. > > Since this started with usage based rate plans for all mobile operators t= he subscriber would get charged if we allowed spam from the Internet or fro= m other mobiles. So this has always been block and vendors have features to= help out in 3GPP elements. A GGSN with anti-spoofing not disabled doesn't = allow traffic to a mobile that doesn't match an entry in the flow table. We= have hundreds of policy rules that get enabled from the PCRF/PCF on the PG= W(PCEF)/UPF. We also enabled our proxies to be transparent proxy-TDF. That = means they also have policy interfaces and we do a bunch of stuff here incl= uding processing signed manifests. Plus the rules are pushed on the control= plane not the data plane and it includes UE, RAN, SGW/PGW/UPF and if appli= cable TDF's and AS's. We can push rules to the UE that allow, (drop), route= /path (e.g. bearer). We even have to have some country specific treatment (= a bigger challenge we had for vehicles using our Connected Car solution lik= e GM OnStar). > > While a mobile could get hacked and it could break the flow rule treatmen= t some of that is down in the 3GPP chipset. But we are aware of the risk an= d we have counter measures as best we can. I should point out that these fl= ow rules go into RAN too and rules have a direction (from UE, to UE or both= ). > > My opinion is that malware, spoofing, DOS, DDOS and any other threat is a= serious operational issue. That is the best place to deal with it because = standards could never keep pace. We and other operators request features fr= om vendors and they also come up with stuff as a value add. > > Simply stated the solution needs to be protected but we don't need tons o= f detail in every standard. > > I would never say don't be concerned about something. I just don't think = every standard needs details on spoofing, DOS and other threats. > > >> -----Original Message----- >> From: Tom Herbert >> Sent: Thursday, May 03, 2018 3:00 PM >> To: Joel M. Halpern >> Cc: FIGURELLE, TERRY F ; Dirk.von-Hugo@telekom.de; Tom >> Herbert ; ila@ietf.org; Alberto Rodriguez-Natal >> ; 5GANGIP <5gangip@ietf.org> >> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement] >> >> On Thu, May 3, 2018 at 2:45 PM, Joel M. Halpern >> wrote: >> > I am missing something in your DDOS issue. >> > >> > At first, I thought the real issue (which you seem to be suggesting >> > here) was DDOS from the Internet, using spoofed or non-spoofed >> > addresses (with bot farms, there is much less need for or relevance of >> spoofing). >> > >> > But then I tried to map it to the cases we have for using ILA. >> > The primary case I have heard about is to use ILA for UE<->UE and >> > UE<->EdgeComputing traffic. If so, just filter all SIRs on incoming >> > packets from the Internet. They aren't legal there. And similarly, >> > if one uses LISP within the operator domain, we can block whatever >> > blocks we use for EIDs for such local traffic. >> >> Joel, >> >> I'm not sure I understand what "filtering SIRs from the Internet" >> means. A SIR address is a globally visible address for devices like UEs.= So an >> Internet sender may legitimately send packets to SIR addresses, and also= an >> Internet attacker could easily spew a whole bunch of packets with both s= poofed >> source addresses and spoofed UE addresses. So you'd want to allow the >> legitimate traffic but block the attacking packets-- this isn't feasible= since it's >> impossible to distinguish the bad from the good packets. >> >> > >> > If we want to use id-locator split of any kind for handling traffic to >> > / from the Internet, then we have to understand how that is supposed >> > to work, and why, before we need to evaluate DDOS implications of a >> > solution. For LISP,the working group has explicitly said that >> > Inter-wide deployment is out of scope. >> > >> > Net: I do not see in currently described deployments, an issue that >> > differentiates LISP from ILA in these regards. And Terry has very >> > clearly spelled out that for mobile operators spoofing from UEs is not >> > considered an issue that the infrastructure needs to deal wih. >> >> But there may be a whole network infrastructure of hundreds or even >> thousands of users behind a UE, and there's no guarantee that that >> infrastructure properly supports anti-spoofing. This basically this case= has the >> same problem as in the Internet case. >> >> Tom >> >> > >> > Yours, >> > Joel >> > >> > >> > On 5/3/18 5:33 PM, Tom Herbert wrote: >> >> >> >> On Thu, May 3, 2018 at 2:23 PM, FIGURELLE, TERRY F >> wrote: >> >>> >> >>> In the case of current 3GPP operators all the major vendors support >> >>> anti-spoofing. The default was on for all but one vendor which got >> >>> corrected the last time I did an RFP for EPC. So by configuration >> >>> the GGSN/PGW/PGW-U/UPF will not allow the UE to send packets that >> >>> don't match either the exact IP address or pushed subnet or prefix >> >>> delegation that was sent in response to the APN create message. >> >>> Obviously if we remove GTP encapsulation that protect MAY need to be >> enhanced towards an EDGE element. >> >>> >> >> Terry, >> >> >> >> Even so, the whole Internet does not require anti-spoofing, nor do I >> >> believe that operators could require all down stream network that are >> >> connected to support anti-spoofing. These are where the DOS attacks >> >> orginate. The problem is when caches are being driven by user taffic >> >> from these external networks, mitigations to detect DOS by IP source >> >> address don't work without anti-spoofing (but even if they had >> >> anti-spoofing that still doesn't work when under a DDOS). >> >> >> >> Tom >> >> >> >> >> >> >> >>> This is being covered as part of our participation in an open source >> >>> vEPC (virtualize EPC, hypervisor, blah, blah, blah). So there will >> >>> be a micro service firewall that can be deploy at the edge plus we >> >>> already have planned support for big network infrastructure vendors >> >>> and 3GPP supplies (Cisco, Juniper, Ericsson, Nokia, Huawei, ...) to >> >>> cover this. Since this can be a non-3GPP element we will get this i= nto >> ONAP. >> >>> >> >>> Thus we have this covered both for 3GPP nodes, micro services and >> >>> open source efforts. To give examples without vendor names there are >> >>> GTP aware firewalls that some operators use. It really just another >> >>> capability in carrier class and business class firewalls (had to add >> >>> it to load balancers, CNAT/NAT, some Wi-Fi routers and to our DNS >> >>> solution which uses open source). Obviously this will be supported >> >>> via a RADIUS feed for backwards compatibility. Today most GTP >> >>> firewall simply follow the GTP-C signaling to learn the IP >> >>> address(es) assigned to the UE for an APN. If we remove GTP from >> >>> user plane that doesn't mean we remove it from control plane or for >> >>> all hops. However, we will likely push to a micro service at the >> >>> cell plus I need to check if we ever ask RAN vendors to support this= . I'll add >> this for 5G but we already did that RFP so it's a change order (yuck). >> >>> >> >>> I am not good at wordsmithing but I suggest there be some paragraph >> >>> that covers network elements that can except a RADIUS feed. I need >> >>> to talk to our standards team to see if we want this on T8 (probably= ). >> >>> >> >>> So today for all AT&T, Verizon, Vodaphone, ..... I know or am >> >>> fairly confident they have anti spoofing tuned on in the >> >>> GGSN/PGW/UPF plus I know they can turn this on per APN. Not sure why >> >>> anyone would disable this since we if you are delegating a subnet to >> >>> a Wi-Fi hotspot (instead of the typical private addressing they use)= . >> >>> >> >>> We actually don't need any 3GPP changes since this is already >> >>> covered using RADIUS to pass the information where it needs to go. I >> >>> suspect most will leverage their caching SPR/UDR which already has >> >>> the information. Even the GGSN we launched EDGE/GPRS when I was much >> >>> younger supported anti-spoofing and many vendors cover this via a >> >>> number of methods (e.g. COPS works for older junos and RADIUS for Ci= sco >> IOS releases ). >> >>> >> >>> My suggestion is that I am willing to help whoever wants to craft >> >>> the paragraph because I suck at that (fortunately I am good at other >> things). >> >>> >> >>> I don't think we need any changes to any standards to cover this >> >>> since we already cover this and already are covering this if we >> >>> strip out GTP (at least for one leg). I'll make sure it gets into >> >>> our RAN requirements if not there since that may be the best place >> >>> for that edge. Plus I'll get it covered thru the ONAP open source >> >>> effort we drove (we donated the software to the open source effort). >> >>> That means FM, PM, CM and IM will be covered in some future ONAP >> release (takes time but faster than 3GPP). >> >>> >> >>> It's a bit debatable what is RAN when using virtualized network >> >>> functions >> >>> (VNF) and a bunch of open source stuff that we put it into all of >> >>> the needed elements like SDN, firewall, load balancer (not sure >> >>> that's needed at cell site but it is for core DNS, proxy-TDF and >> >>> CNAT) out at the cell site. We aren't there yet (still physical >> >>> eNB/NR and obviously we need hardware assist even with >> >>> virtualization plus tight control of timing). I am looking forward t= o when we >> start using containers. >> >>> >> >>> For our core I am sure we will use our UDR VNF as the cache for >> >>> whatever comes out of this effort in final standards. The >> >>> information is already there (IMEI, device vendor, subscription >> >>> information, UE IP address, APN, etc.). If we do anything it would >> >>> be to augment an open source and if needed a 3GPP. I don't think we = need >> any changes but it's always best to verify. >> >>> For current RAN an anti-spoofing feature would come from EMS which >> >>> can be via ONAP. I don't think that is a standards effort thing >> >>> since it's a feature which may or may not already be covered but it >> >>> will be in future RAN releases probably starting with eNB/NR with >> >>> some vendor release if it's not already a feature. I want to say >> >>> Ericsson and Nokia already can do this in eNB but I need to go thru >> channels to ask. >> >>> >> >>> So maybe that paragraph recommends implementing anti-spoofing at all >> >>> edges and leaves it at that. Or we could say all edges including RAN >> >>> if that makes people happy. >> >>> >> >>>> -----Original Message----- >> >>>> From: 5gangip <5gangip-bounces@ietf.org> On Behalf Of Tom Herbert >> >>>> Sent: Thursday, May 03, 2018 10:46 AM >> >>>> To: Dirk.von-Hugo@telekom.de >> >>>> Cc: Tom Herbert ; Joel M. Halpern >> >>>> ; ila@ietf.org; Alberto Rodriguez-Natal >> >>>> ; 5GANGIP <5gangip@ietf.org> >> >>>> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem >> >>>> Statement] >> >>>> >> >>>> On Thu, May 3, 2018 at 9:23 AM, wrote: >> >>>>> >> >>>>> Hi Tom, >> >>>>> I understand you correctly that DDOS attacks can never be >> >>>>> completely >> >>>> >> >>>> prevented whatever protocol you use. >> >>>>> >> >>>>> It will however always remain related to known IP addresses and >> >>>>> the more >> >>>> >> >>>> versatile these are handled a mitigation strategy could be designed= . >> >>>> >> >>>> Dirk, >> >>>> >> >>>> I disagree. IP addresses can too easily be spoofed, it's easy to >> >>>> hide identity behind a NAT (see discussion about CGNAT and law >> >>>> enforcement on int-area list), and trying to turn off individual >> >>>> addresses doesn't work if it's a DDOS. This is nothing new. For >> >>>> instance, content providers have long accepted the fact that they >> >>>> can't prevent SYN attacks and there's little point to trying to go >> >>>> back to source IP address (they are always spoofed in a SYN >> >>>> attack). The better strategy is to absorb the attack and minimize >> >>>> the negative effects so that the attack is not worth the effort. >> >>>> >> >>>>> As you may have seen we mention improved handling of mapping >> >>>>> systems >> >>>> >> >>>> and subsequently of DDOS protection also in the current version of >> >>>> our PS document https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> >>>> 3A__github.com_bsarikaya_atic_blob_master_atick- >> >>>> 5Fproblemstatement.3.txt&d=3DDwICAg&c=3DLFYZ- >> >>>> >> o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4 >> >>>> OstVOL1OQiA98fgBJ9c1Gjo&s=3DjLL_9a56R8Ic8o3uJcR8mrF- >> >>>> JkzLL97h8rmZT_EqXnQ&e=3D which Behcet has announced recently. >> >>>>> >> >>>>> May I ask you to please comment on the ideas outlined there? >> >>>> >> >>>> >> >>>> I don't see much difference in the latest version. For a problem >> >>>> statement, I still think there is too much focus on the solutions >> >>>> and not nearly enough description of what the actual problems are >> >>>> to be solved. >> >>>> >> >>>> Tom >> >>>> >> >>>>> Thanks! >> >>>> >> >>>> >> >>>>> Best Regards >> >>>>> Dirk >> >>>>> >> >>>>> -----Original Message----- >> >>>>> From: 5gangip [mailto:5gangip-bounces@ietf.org] On Behalf Of Tom >> >>>>> Herbert >> >>>>> Sent: Mittwoch, 2. Mai 2018 01:20 >> >>>>> To: Joel M. Halpern >> >>>>> Cc: Tom Herbert ; ila@ietf.org; Alberto >> >>>>> Rodriguez-Natal ; 5GANGIP >> >>>>> <5gangip@ietf.org> >> >>>>> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem >> >>>>> Statement] >> >>>>> >> >>>>> On Tue, May 1, 2018 at 3:49 PM, Joel M. Halpern >> >>>>> >> >>>> >> >>>> wrote: >> >>>>>> >> >>>>>> You seem to be saying that even though not all DDOS attacks are >> >>>>>> structurally the same, and even though if ILA were widely adopted >> >>>>>> not all ILA networks would be structurally the same, there should >> >>>>>> nonetheless be one required qay of handling DDOS? >> >>>>> >> >>>>> >> >>>>> Yes, at least as core default in the protocol. It's precisely >> >>>>> _because_ not all >> >>>> >> >>>> DDOS attacks are structurally the same. An attacker is not going to >> >>>> conform to to our expectations of what they should be doing, so if >> >>>> we enable LISP option N to mitigate one form of attack, they will >> >>>> just use another attack that isn't mitigated. For example, if the >> >>>> mitigation is to identify attackers by address when requests from >> >>>> the address exceed a threshold then this works as long as the >> >>>> attacker strikes from one machine, but it falls apart if the >> >>>> attacker launches a DDOS attack from several hosts where requests >> >>>> from none of the hosts exceed the threshold. >> >>>>> >> >>>>> >> >>>>> The ILA model works because it assumes there is no absolute way to >> >>>>> prevent >> >>>> >> >>>> the the worst case attack on a cache which is to completely kill it >> >>>> (i.e. drive it to 0% hit rate). In this state the behavior >> >>>> sub-optimal routing, which is much better than loss of service. >> >>>> This is not dependent on the structure of the attack, network >> >>>> topology, or the network operator getting the configuration just >> >>>> right-- >> >>>> it is inherent in the protocol. >> >>>>> >> >>>>> >> >>>>> Tom >> >>>>> >> >>>>>> >> >>>>>> Yours, >> >>>>>> Joel >> >>>>>> >> >>>>>> >> >>>>>> On 5/1/18 6:32 PM, Tom Herbert wrote: >> >>>>>>> >> >>>>>>> >> >>>>>>> On Tue, May 1, 2018 at 2:59 PM, Alberto Rodriguez-Natal >> >>>>>>> wrote: >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> On Tue, May 1, 2018 at 10:16 AM, Tom Herbert >> >> >>>> >> >>>> wrote: >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> I think you've misunderstood my position. Caches are _very_ >> >>>>>>>>> important to eliminate the cost triangular routing (latency, >> >>>>>>>>> average path >> >>>> >> >>>> load). >> >>>>>>>>> >> >>>>>>>>> This reduces latency and reduces average load on ILA-Rs. But, = and >> >>>>>>>>> this is the critical part, caches are only an _optimization_ i= n >> >>>>>>>>> ILA. That means if the cache is rendered ineffective (like by = a >> >>>>>>>>> well crafted DOS >> >>>>>>>>> attack) then the only effect is that the optimization is loss = (i.e. >> >>>>>>>>> greater latency due to triangular router)-- this is quantitive= ly >> >>>>>>>>> the worst effect of the attack on an ILA cache. This can be >> >>>>>>>>> contrasted that to LISP where the worst case effects of a DOS >> >>>>>>>>> attack on the cache is loss of service for users (infinite lat= ency >> >>>>>>>>> since packets can be dropped or indefinitely blocked on a cach= e >> >>>>>>>>> miss). >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> This can be misleading. This is not comparing LISP vs ILA, this= is >> >>>>>>>> comparing the models of Request/Reply at the edge vs Notificati= ons >> >>>>>>>> (aka Redirects) at the core. Both LISP-CP and ILAMP support the= se >> >>>>>>>> two models. >> >>>>>>>> >> >>>>>>>> Besides, this is assuming an scenario where the only feasible D= OS >> >>>>>>>> mitigation is absorbing the attack. There are other scenarios w= here >> >>>>>>>> other countermeasures are possible. For instance, if you have a >> >>>>>>>> deployment where you can prevent address spoofing, counting and >> >>>>>>>> blocking misbehaving nodes offers similar DOS protection and >> >>>>>>>> requires way less infrastructure resources. >> >>>>>>>> >> >>>>>>> Alberto, >> >>>>>>> >> >>>>>>> The answer to my question of how does LISP address DOS attacks >> seems >> >>>>>>> to be "there are many options". Some of the options are to assum= e >> >>>>>>> that DOS does not exist in the network, some assume external >> >>>>>>> configuration like address spoofing is enabled, some assume that >> >>>>>>> attacks can be identified and can be stopped at the source, some >> >>>>>>> might assume that everything is okay because there's never been = a >> >>>>>>> DOS attack before. I have yet to see the effects of any of these >> >>>>>>> quantified, and none of these state how the LISP _protocol_ itse= lf >> >>>>>>> addresses DOS. It may seem counter-intuitive, but offering a bun= ch >> >>>>>>> of options really is not necessarily a good thing-- sometime les= s is >> >>>>>>> more. To put this another way LISP has been rejected from Linux >> >>>>>>> precisely because of its susceptibility to DOS. If you were to t= ry >> >>>>>>> again and the best answer to the DOS question is that it's up to= the >> >>>>>>> operator to figure out the right options to use, then I believe = it >> >>>>>>> would be soundly rejected again. That approach does not work at >> >>>>>>> scale. >> >>>>>>> >> >>>>>>> Tom >> >>>>>>> >> >>>>>>> _______________________________________________ >> >>>>>>> ila mailing list >> >>>>>>> ila@ietf.org >> >>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.ietf.org_ma >> >>>>>>> ilman_listinfo_ila&d=3DDwICAg&c=3DLFYZ- >> >>>> >> >>>> o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl >> >>>>>>> >> >>>>>>> >> >>>> >> 2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4OstVOL1OQiA98fgBJ9c1Gjo&s=3DBO3snt8C >> >>>> RQ >> >>>>>>> >> >>>>>>> gy1xwhx2CY10VUbM_rgntgpV9k3-Cskd8&e=3D >> >>>>>>> >> >>>>>> >> >>>>> >> >>>>> _______________________________________________ >> >>>>> 5gangip mailing list >> >>>>> 5gangip@ietf.org >> >>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.ietf.org_mail >> >>>>> man_listinfo_5gangip&d=3DDwICAg&c=3DLFYZ- >> >>>> >> >>>> o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl >> >>>>> >> >>>>> >> >>>> >> 2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4OstVOL1OQiA98fgBJ9c1Gjo&s=3DFnQLMire >> >>>> MiKC >> >>>>> >> >>>>> SkPaOGFCybzDc2i2y49Cgtbl6mCLc9c&e=3D >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> 5gangip mailing list >> >>>> 5gangip@ietf.org >> >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> >>>> 3A__www.ietf.org_mailman_listinfo_5gangip&d=3DDwICAg&c=3DLFYZ- >> >>>> >> o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4 >> >>>> >> OstVOL1OQiA98fgBJ9c1Gjo&s=3DFnQLMireMiKCSkPaOGFCybzDc2i2y49Cgtbl6mC >> >>>> Lc9c&e=3D >> >> >> >> >> > From nobody Tue May 8 06:40:28 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B42B12E3AE for ; Tue, 8 May 2018 06:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 1rRwH2-Gb8in for ; Tue, 8 May 2018 06:40:16 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 6C31D12E87D for ; Tue, 8 May 2018 06:40:15 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id j4so18936575wme.1 for ; Tue, 08 May 2018 06:40:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l/iCAgZ+RJQ9eSrn0HCJrpvdCNUdVT0lwol7sxzgzIw=; b=l1OHLSvjvLkSd+dyJn2AFaiAvbnLNQ1iIa4fLp5g+yGo9Aixpn3chcVvqTASxgCDQe c7lL0hoAaxh3Jo/A6m0RrqYAfXeTFq36SW3Rya9yb/afsruhdT3BObfsLdD7gWjasxUQ j2ysz8mEbR2NXOVkTaDvXK2jfP+PCg9tRdtA9sVDOs4FPRgMONGAqjbVo1YB59Lek27G Zd3MBKQ1p0nxbOf3X5BMlxD2LcsKZjt+060UV31e+yv1ZYv3eyUoNnUvYG5aegbZy/Ma HQ+/jYK9LOXcgLA2UhPbXaNgSBdaVV46a1YQfD6vhwsAZKU9xekZB9Z1U4WspfPSnhUL oryA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l/iCAgZ+RJQ9eSrn0HCJrpvdCNUdVT0lwol7sxzgzIw=; b=PkjgrS4DJAbjyWJN5d6IYkayWWTygUzkplP11nVHGk9WME2earVuv9X180WwHfMhOF BpSXBKySD4ru3TomsJzvhJyP3oL1l03JIFTRopN1+hwQqg2nlwPqYq5Zmg20A4+iMUTE G2rgEDEQvVrTTjtt5tnw2pPQEa1969nWm+ST0DT0+TkIyRhtnRaoexW994WS+hg3BKY4 EKX/jIWgaN2pzWXSDVTPRU1hjRcVtDYEc1jFu+1V8MstN8jt+1+Pil1w8A9Pkb2mwGXD PaW9gwAhJ7vuEFtgOGcy7t9CnSWtsNGFgA/iCqFhvevKZCcuKeCjGmQO8qOYFJx2B4e/ wqjA== X-Gm-Message-State: ALKqPwfSl371taJ0IfdRmh2f8VZ/WiHX3zEPDYpXOpuVdoyWnKvvzXiw mHz1dVLvORn7RC7X9lDmfaohYtD63hShJtNaMl8mfg== X-Google-Smtp-Source: AB8JxZrj0Bb5GC+89UGe2DN4PMZdyKDuFrp1xf8MsWeUjrPUBaar0sShimieaK4PqGyw+3VP1u6RseMvUexyWCYBaME= X-Received: by 2002:a1c:340f:: with SMTP id b15-v6mr3172747wma.129.1525786813349; Tue, 08 May 2018 06:40:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.247.25 with HTTP; Tue, 8 May 2018 06:39:52 -0700 (PDT) In-Reply-To: <1AFE10CF28AE8B4C9663445736B8034D3822FC27@CAFRFD1MSGUSRJI.ITServices.sbc.com> References: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> <8aee42db5f0f407c86fda881769ceb77@HE105715.emea1.cds.t-internal.com> <1AFE10CF28AE8B4C9663445736B8034D3822FAFE@CAFRFD1MSGUSRJI.ITServices.sbc.com> <0cbb9987-0b47-9428-3db7-2c9fab821268@joelhalpern.com> <1AFE10CF28AE8B4C9663445736B8034D3822FC27@CAFRFD1MSGUSRJI.ITServices.sbc.com> From: Lorenzo Colitti Date: Tue, 8 May 2018 22:39:52 +0900 Message-ID: To: "FIGURELLE, TERRY F" Cc: Tom Herbert , "Joel M. Halpern" , Tom Herbert , "ila@ietf.org" , 5GANGIP <5gangip@ietf.org>, Alberto Rodriguez-Natal , "Dirk.von-Hugo@telekom.de" Content-Type: multipart/alternative; boundary="00000000000003e1d1056bb1ed10" Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 13:40:21 -0000 --00000000000003e1d1056bb1ed10 Content-Type: text/plain; charset="UTF-8" FWIW, I believe there are large operators that do not block unsolicited inbound traffic to mobile networks. One of them is T-Mobile. On Fri, May 4, 2018 at 7:53 AM, FIGURELLE, TERRY F wrote: > No. We have always block unsolicited traffic from the Internet and it is > too complicated to discuss here. > > We even did this way back for CDPD. For dedicated APN's we allow the > enterprise to tell us what rules they want to protect the mobile from their > network and what traffic to not allow from the mobile. This is one of the > reasons firewalls and CNAT cost more if they support mobility features. We > spent a lot of time working with potential vendors. > > Since this started with usage based rate plans for all mobile operators > the subscriber would get charged if we allowed spam from the Internet or > from other mobiles. So this has always been block and vendors have features > to help out in 3GPP elements. A GGSN with anti-spoofing not disabled > doesn't allow traffic to a mobile that doesn't match an entry in the flow > table. We have hundreds of policy rules that get enabled from the PCRF/PCF > on the PGW(PCEF)/UPF. We also enabled our proxies to be transparent > proxy-TDF. That means they also have policy interfaces and we do a bunch of > stuff here including processing signed manifests. Plus the rules are pushed > on the control plane not the data plane and it includes UE, RAN, > SGW/PGW/UPF and if applicable TDF's and AS's. We can push rules to the UE > that allow, (drop), route/path (e.g. bearer). We even have to have some > country specific treatment (a bigger challenge we had for vehicles using > our Connected Car solution like GM OnStar). > > While a mobile could get hacked and it could break the flow rule treatment > some of that is down in the 3GPP chipset. But we are aware of the risk and > we have counter measures as best we can. I should point out that these flow > rules go into RAN too and rules have a direction (from UE, to UE or both). > > My opinion is that malware, spoofing, DOS, DDOS and any other threat is a > serious operational issue. That is the best place to deal with it because > standards could never keep pace. We and other operators request features > from vendors and they also come up with stuff as a value add. > > Simply stated the solution needs to be protected but we don't need tons of > detail in every standard. > > I would never say don't be concerned about something. I just don't think > every standard needs details on spoofing, DOS and other threats. > > > > -----Original Message----- > > From: Tom Herbert > > Sent: Thursday, May 03, 2018 3:00 PM > > To: Joel M. Halpern > > Cc: FIGURELLE, TERRY F ; Dirk.von-Hugo@telekom.de; Tom > > Herbert ; ila@ietf.org; Alberto Rodriguez-Natal > > ; 5GANGIP <5gangip@ietf.org> > > Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement] > > > > On Thu, May 3, 2018 at 2:45 PM, Joel M. Halpern > > wrote: > > > I am missing something in your DDOS issue. > > > > > > At first, I thought the real issue (which you seem to be suggesting > > > here) was DDOS from the Internet, using spoofed or non-spoofed > > > addresses (with bot farms, there is much less need for or relevance of > > spoofing). > > > > > > But then I tried to map it to the cases we have for using ILA. > > > The primary case I have heard about is to use ILA for UE<->UE and > > > UE<->EdgeComputing traffic. If so, just filter all SIRs on incoming > > > packets from the Internet. They aren't legal there. And similarly, > > > if one uses LISP within the operator domain, we can block whatever > > > blocks we use for EIDs for such local traffic. > > > > Joel, > > > > I'm not sure I understand what "filtering SIRs from the Internet" > > means. A SIR address is a globally visible address for devices like UEs. > So an > > Internet sender may legitimately send packets to SIR addresses, and also > an > > Internet attacker could easily spew a whole bunch of packets with both > spoofed > > source addresses and spoofed UE addresses. So you'd want to allow the > > legitimate traffic but block the attacking packets-- this isn't feasible > since it's > > impossible to distinguish the bad from the good packets. > > > > > > > > If we want to use id-locator split of any kind for handling traffic to > > > / from the Internet, then we have to understand how that is supposed > > > to work, and why, before we need to evaluate DDOS implications of a > > > solution. For LISP,the working group has explicitly said that > > > Inter-wide deployment is out of scope. > > > > > > Net: I do not see in currently described deployments, an issue that > > > differentiates LISP from ILA in these regards. And Terry has very > > > clearly spelled out that for mobile operators spoofing from UEs is not > > > considered an issue that the infrastructure needs to deal wih. > > > > But there may be a whole network infrastructure of hundreds or even > > thousands of users behind a UE, and there's no guarantee that that > > infrastructure properly supports anti-spoofing. This basically this case > has the > > same problem as in the Internet case. > > > > Tom > > > > > > > > Yours, > > > Joel > > > > > > > > > On 5/3/18 5:33 PM, Tom Herbert wrote: > > >> > > >> On Thu, May 3, 2018 at 2:23 PM, FIGURELLE, TERRY F > > wrote: > > >>> > > >>> In the case of current 3GPP operators all the major vendors support > > >>> anti-spoofing. The default was on for all but one vendor which got > > >>> corrected the last time I did an RFP for EPC. So by configuration > > >>> the GGSN/PGW/PGW-U/UPF will not allow the UE to send packets that > > >>> don't match either the exact IP address or pushed subnet or prefix > > >>> delegation that was sent in response to the APN create message. > > >>> Obviously if we remove GTP encapsulation that protect MAY need to be > > enhanced towards an EDGE element. > > >>> > > >> Terry, > > >> > > >> Even so, the whole Internet does not require anti-spoofing, nor do I > > >> believe that operators could require all down stream network that are > > >> connected to support anti-spoofing. These are where the DOS attacks > > >> orginate. The problem is when caches are being driven by user taffic > > >> from these external networks, mitigations to detect DOS by IP source > > >> address don't work without anti-spoofing (but even if they had > > >> anti-spoofing that still doesn't work when under a DDOS). > > >> > > >> Tom > > >> > > >> > > >> > > >>> This is being covered as part of our participation in an open source > > >>> vEPC (virtualize EPC, hypervisor, blah, blah, blah). So there will > > >>> be a micro service firewall that can be deploy at the edge plus we > > >>> already have planned support for big network infrastructure vendors > > >>> and 3GPP supplies (Cisco, Juniper, Ericsson, Nokia, Huawei, ...) to > > >>> cover this. Since this can be a non-3GPP element we will get this > into > > ONAP. > > >>> > > >>> Thus we have this covered both for 3GPP nodes, micro services and > > >>> open source efforts. To give examples without vendor names there are > > >>> GTP aware firewalls that some operators use. It really just another > > >>> capability in carrier class and business class firewalls (had to add > > >>> it to load balancers, CNAT/NAT, some Wi-Fi routers and to our DNS > > >>> solution which uses open source). Obviously this will be supported > > >>> via a RADIUS feed for backwards compatibility. Today most GTP > > >>> firewall simply follow the GTP-C signaling to learn the IP > > >>> address(es) assigned to the UE for an APN. If we remove GTP from > > >>> user plane that doesn't mean we remove it from control plane or for > > >>> all hops. However, we will likely push to a micro service at the > > >>> cell plus I need to check if we ever ask RAN vendors to support > this. I'll add > > this for 5G but we already did that RFP so it's a change order (yuck). > > >>> > > >>> I am not good at wordsmithing but I suggest there be some paragraph > > >>> that covers network elements that can except a RADIUS feed. I need > > >>> to talk to our standards team to see if we want this on T8 > (probably). > > >>> > > >>> So today for all AT&T, Verizon, Vodaphone, ..... I know or am > > >>> fairly confident they have anti spoofing tuned on in the > > >>> GGSN/PGW/UPF plus I know they can turn this on per APN. Not sure why > > >>> anyone would disable this since we if you are delegating a subnet to > > >>> a Wi-Fi hotspot (instead of the typical private addressing they use). > > >>> > > >>> We actually don't need any 3GPP changes since this is already > > >>> covered using RADIUS to pass the information where it needs to go. I > > >>> suspect most will leverage their caching SPR/UDR which already has > > >>> the information. Even the GGSN we launched EDGE/GPRS when I was much > > >>> younger supported anti-spoofing and many vendors cover this via a > > >>> number of methods (e.g. COPS works for older junos and RADIUS for > Cisco > > IOS releases ). > > >>> > > >>> My suggestion is that I am willing to help whoever wants to craft > > >>> the paragraph because I suck at that (fortunately I am good at other > > things). > > >>> > > >>> I don't think we need any changes to any standards to cover this > > >>> since we already cover this and already are covering this if we > > >>> strip out GTP (at least for one leg). I'll make sure it gets into > > >>> our RAN requirements if not there since that may be the best place > > >>> for that edge. Plus I'll get it covered thru the ONAP open source > > >>> effort we drove (we donated the software to the open source effort). > > >>> That means FM, PM, CM and IM will be covered in some future ONAP > > release (takes time but faster than 3GPP). > > >>> > > >>> It's a bit debatable what is RAN when using virtualized network > > >>> functions > > >>> (VNF) and a bunch of open source stuff that we put it into all of > > >>> the needed elements like SDN, firewall, load balancer (not sure > > >>> that's needed at cell site but it is for core DNS, proxy-TDF and > > >>> CNAT) out at the cell site. We aren't there yet (still physical > > >>> eNB/NR and obviously we need hardware assist even with > > >>> virtualization plus tight control of timing). I am looking forward > to when we > > start using containers. > > >>> > > >>> For our core I am sure we will use our UDR VNF as the cache for > > >>> whatever comes out of this effort in final standards. The > > >>> information is already there (IMEI, device vendor, subscription > > >>> information, UE IP address, APN, etc.). If we do anything it would > > >>> be to augment an open source and if needed a 3GPP. I don't think we > need > > any changes but it's always best to verify. > > >>> For current RAN an anti-spoofing feature would come from EMS which > > >>> can be via ONAP. I don't think that is a standards effort thing > > >>> since it's a feature which may or may not already be covered but it > > >>> will be in future RAN releases probably starting with eNB/NR with > > >>> some vendor release if it's not already a feature. I want to say > > >>> Ericsson and Nokia already can do this in eNB but I need to go thru > > channels to ask. > > >>> > > >>> So maybe that paragraph recommends implementing anti-spoofing at all > > >>> edges and leaves it at that. Or we could say all edges including RAN > > >>> if that makes people happy. > > >>> > > >>>> -----Original Message----- > > >>>> From: 5gangip <5gangip-bounces@ietf.org> On Behalf Of Tom Herbert > > >>>> Sent: Thursday, May 03, 2018 10:46 AM > > >>>> To: Dirk.von-Hugo@telekom.de > > >>>> Cc: Tom Herbert ; Joel M. Halpern > > >>>> ; ila@ietf.org; Alberto Rodriguez-Natal > > >>>> ; 5GANGIP <5gangip@ietf.org> > > >>>> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem > > >>>> Statement] > > >>>> > > >>>> On Thu, May 3, 2018 at 9:23 AM, wrote: > > >>>>> > > >>>>> Hi Tom, > > >>>>> I understand you correctly that DDOS attacks can never be > > >>>>> completely > > >>>> > > >>>> prevented whatever protocol you use. > > >>>>> > > >>>>> It will however always remain related to known IP addresses and > > >>>>> the more > > >>>> > > >>>> versatile these are handled a mitigation strategy could be designed. > > >>>> > > >>>> Dirk, > > >>>> > > >>>> I disagree. IP addresses can too easily be spoofed, it's easy to > > >>>> hide identity behind a NAT (see discussion about CGNAT and law > > >>>> enforcement on int-area list), and trying to turn off individual > > >>>> addresses doesn't work if it's a DDOS. This is nothing new. For > > >>>> instance, content providers have long accepted the fact that they > > >>>> can't prevent SYN attacks and there's little point to trying to go > > >>>> back to source IP address (they are always spoofed in a SYN > > >>>> attack). The better strategy is to absorb the attack and minimize > > >>>> the negative effects so that the attack is not worth the effort. > > >>>> > > >>>>> As you may have seen we mention improved handling of mapping > > >>>>> systems > > >>>> > > >>>> and subsequently of DDOS protection also in the current version of > > >>>> our PS document https://urldefense.proofpoint.com/v2/url?u=https- > > >>>> 3A__github.com_bsarikaya_atic_blob_master_atick- > > >>>> 5Fproblemstatement.3.txt&d=DwICAg&c=LFYZ- > > >>>> > > o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=zYkPItjuHMuGlJXD5K_4 > > >>>> OstVOL1OQiA98fgBJ9c1Gjo&s=jLL_9a56R8Ic8o3uJcR8mrF- > > >>>> JkzLL97h8rmZT_EqXnQ&e= which Behcet has announced recently. > > >>>>> > > >>>>> May I ask you to please comment on the ideas outlined there? > > >>>> > > >>>> > > >>>> I don't see much difference in the latest version. For a problem > > >>>> statement, I still think there is too much focus on the solutions > > >>>> and not nearly enough description of what the actual problems are > > >>>> to be solved. > > >>>> > > >>>> Tom > > >>>> > > >>>>> Thanks! > > >>>> > > >>>> > > >>>>> Best Regards > > >>>>> Dirk > > >>>>> > > >>>>> -----Original Message----- > > >>>>> From: 5gangip [mailto:5gangip-bounces@ietf.org] On Behalf Of Tom > > >>>>> Herbert > > >>>>> Sent: Mittwoch, 2. Mai 2018 01:20 > > >>>>> To: Joel M. Halpern > > >>>>> Cc: Tom Herbert ; ila@ietf.org; Alberto > > >>>>> Rodriguez-Natal ; 5GANGIP > > >>>>> <5gangip@ietf.org> > > >>>>> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem > > >>>>> Statement] > > >>>>> > > >>>>> On Tue, May 1, 2018 at 3:49 PM, Joel M. Halpern > > >>>>> > > >>>> > > >>>> wrote: > > >>>>>> > > >>>>>> You seem to be saying that even though not all DDOS attacks are > > >>>>>> structurally the same, and even though if ILA were widely adopted > > >>>>>> not all ILA networks would be structurally the same, there should > > >>>>>> nonetheless be one required qay of handling DDOS? > > >>>>> > > >>>>> > > >>>>> Yes, at least as core default in the protocol. It's precisely > > >>>>> _because_ not all > > >>>> > > >>>> DDOS attacks are structurally the same. An attacker is not going to > > >>>> conform to to our expectations of what they should be doing, so if > > >>>> we enable LISP option N to mitigate one form of attack, they will > > >>>> just use another attack that isn't mitigated. For example, if the > > >>>> mitigation is to identify attackers by address when requests from > > >>>> the address exceed a threshold then this works as long as the > > >>>> attacker strikes from one machine, but it falls apart if the > > >>>> attacker launches a DDOS attack from several hosts where requests > > >>>> from none of the hosts exceed the threshold. > > >>>>> > > >>>>> > > >>>>> The ILA model works because it assumes there is no absolute way to > > >>>>> prevent > > >>>> > > >>>> the the worst case attack on a cache which is to completely kill it > > >>>> (i.e. drive it to 0% hit rate). In this state the behavior > > >>>> sub-optimal routing, which is much better than loss of service. > > >>>> This is not dependent on the structure of the attack, network > > >>>> topology, or the network operator getting the configuration just > > >>>> right-- > > >>>> it is inherent in the protocol. > > >>>>> > > >>>>> > > >>>>> Tom > > >>>>> > > >>>>>> > > >>>>>> Yours, > > >>>>>> Joel > > >>>>>> > > >>>>>> > > >>>>>> On 5/1/18 6:32 PM, Tom Herbert wrote: > > >>>>>>> > > >>>>>>> > > >>>>>>> On Tue, May 1, 2018 at 2:59 PM, Alberto Rodriguez-Natal > > >>>>>>> wrote: > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> On Tue, May 1, 2018 at 10:16 AM, Tom Herbert > > > > >>>> > > >>>> wrote: > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> I think you've misunderstood my position. Caches are _very_ > > >>>>>>>>> important to eliminate the cost triangular routing (latency, > > >>>>>>>>> average path > > >>>> > > >>>> load). > > >>>>>>>>> > > >>>>>>>>> This reduces latency and reduces average load on ILA-Rs. But, > and > > >>>>>>>>> this is the critical part, caches are only an _optimization_ in > > >>>>>>>>> ILA. That means if the cache is rendered ineffective (like by a > > >>>>>>>>> well crafted DOS > > >>>>>>>>> attack) then the only effect is that the optimization is loss > (i.e. > > >>>>>>>>> greater latency due to triangular router)-- this is > quantitively > > >>>>>>>>> the worst effect of the attack on an ILA cache. This can be > > >>>>>>>>> contrasted that to LISP where the worst case effects of a DOS > > >>>>>>>>> attack on the cache is loss of service for users (infinite > latency > > >>>>>>>>> since packets can be dropped or indefinitely blocked on a cache > > >>>>>>>>> miss). > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> This can be misleading. This is not comparing LISP vs ILA, this > is > > >>>>>>>> comparing the models of Request/Reply at the edge vs > Notifications > > >>>>>>>> (aka Redirects) at the core. Both LISP-CP and ILAMP support > these > > >>>>>>>> two models. > > >>>>>>>> > > >>>>>>>> Besides, this is assuming an scenario where the only feasible > DOS > > >>>>>>>> mitigation is absorbing the attack. There are other scenarios > where > > >>>>>>>> other countermeasures are possible. For instance, if you have a > > >>>>>>>> deployment where you can prevent address spoofing, counting and > > >>>>>>>> blocking misbehaving nodes offers similar DOS protection and > > >>>>>>>> requires way less infrastructure resources. > > >>>>>>>> > > >>>>>>> Alberto, > > >>>>>>> > > >>>>>>> The answer to my question of how does LISP address DOS attacks > > seems > > >>>>>>> to be "there are many options". Some of the options are to assume > > >>>>>>> that DOS does not exist in the network, some assume external > > >>>>>>> configuration like address spoofing is enabled, some assume that > > >>>>>>> attacks can be identified and can be stopped at the source, some > > >>>>>>> might assume that everything is okay because there's never been a > > >>>>>>> DOS attack before. I have yet to see the effects of any of these > > >>>>>>> quantified, and none of these state how the LISP _protocol_ > itself > > >>>>>>> addresses DOS. It may seem counter-intuitive, but offering a > bunch > > >>>>>>> of options really is not necessarily a good thing-- sometime > less is > > >>>>>>> more. To put this another way LISP has been rejected from Linux > > >>>>>>> precisely because of its susceptibility to DOS. If you were to > try > > >>>>>>> again and the best answer to the DOS question is that it's up to > the > > >>>>>>> operator to figure out the right options to use, then I believe > it > > >>>>>>> would be soundly rejected again. That approach does not work at > > >>>>>>> scale. > > >>>>>>> > > >>>>>>> Tom > > >>>>>>> > > >>>>>>> _______________________________________________ > > >>>>>>> ila mailing list > > >>>>>>> ila@ietf.org > > >>>>>>> https://urldefense.proofpoint.com/v2/url?u=https- > > 3A__www.ietf.org_ma > > >>>>>>> ilman_listinfo_ila&d=DwICAg&c=LFYZ- > > >>>> > > >>>> o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl > > >>>>>>> > > >>>>>>> > > >>>> > > 2paJIf4zw&m=zYkPItjuHMuGlJXD5K_4OstVOL1OQiA98fgBJ9c1Gjo&s=BO3snt8C > > >>>> RQ > > >>>>>>> > > >>>>>>> gy1xwhx2CY10VUbM_rgntgpV9k3-Cskd8&e= > > >>>>>>> > > >>>>>> > > >>>>> > > >>>>> _______________________________________________ > > >>>>> 5gangip mailing list > > >>>>> 5gangip@ietf.org > > >>>>> https://urldefense.proofpoint.com/v2/url?u=https- > > 3A__www.ietf.org_mail > > >>>>> man_listinfo_5gangip&d=DwICAg&c=LFYZ- > > >>>> > > >>>> o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl > > >>>>> > > >>>>> > > >>>> > > 2paJIf4zw&m=zYkPItjuHMuGlJXD5K_4OstVOL1OQiA98fgBJ9c1Gjo&s=FnQLMire > > >>>> MiKC > > >>>>> > > >>>>> SkPaOGFCybzDc2i2y49Cgtbl6mCLc9c&e= > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> 5gangip mailing list > > >>>> 5gangip@ietf.org > > >>>> https://urldefense.proofpoint.com/v2/url?u=https- > > >>>> 3A__www.ietf.org_mailman_listinfo_5gangip&d=DwICAg&c=LFYZ- > > >>>> > > o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=zYkPItjuHMuGlJXD5K_4 > > >>>> > > OstVOL1OQiA98fgBJ9c1Gjo&s=FnQLMireMiKCSkPaOGFCybzDc2i2y49Cgtbl6mC > > >>>> Lc9c&e= > > >> > > >> > > > > _______________________________________________ > 5gangip mailing list > 5gangip@ietf.org > https://www.ietf.org/mailman/listinfo/5gangip > --00000000000003e1d1056bb1ed10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FWIW, I believe there are large operators that do not bloc= k unsolicited inbound traffic to mobile networks. One of them is T-Mobile.<= /div>

On Fri, May = 4, 2018 at 7:53 AM, FIGURELLE, TERRY F <tf2934@att.com> wrote:<= br>
No. We have always block unsolicited traf= fic from the Internet and it is too complicated to discuss here.

We even did this way back for CDPD. For dedicated APN's we allow the en= terprise to tell us what rules they want to protect the mobile from their n= etwork and what traffic to not allow from the mobile. This is one of the re= asons firewalls and CNAT cost more if they support mobility features. We sp= ent a lot of time working with potential vendors.

Since this started with usage based rate plans for all mobile operators the= subscriber would get charged if we allowed spam from the Internet or from = other mobiles. So this has always been block and vendors have features to h= elp out in 3GPP elements. A GGSN with anti-spoofing not disabled doesn'= t allow traffic to a mobile that doesn't match an entry in the flow tab= le. We have hundreds of policy rules that get enabled from the PCRF/PCF on = the PGW(PCEF)/UPF. We also enabled our proxies to be transparent proxy-TDF.= That means they also have policy interfaces and we do a bunch of stuff her= e including processing signed manifests. Plus the rules are pushed on the c= ontrol plane not the data plane and it includes UE, RAN, SGW/PGW/UPF and if= applicable TDF's and AS's. We can push rules to the UE that allow,= (drop), route/path (e.g. bearer). We even have to have some country specif= ic treatment (a bigger challenge we had for vehicles using our Connected Ca= r solution like GM OnStar).

While a mobile could get hacked and it could break the flow rule treatment = some of that is down in the 3GPP chipset. But we are aware of the risk and = we have counter measures as best we can. I should point out that these flow= rules go into RAN too and rules have a direction (from UE, to UE or both).=

My opinion is that malware, spoofing, DOS, DDOS and any other threat is a s= erious operational issue. That is the best place to deal with it because st= andards could never keep pace. We and other operators request features from= vendors and they also come up with stuff as a value add.

Simply stated the solution needs to be protected but we don't need tons= of detail in every standard.

I would never say don't be concerned about something. I just don't = think every standard needs details on spoofing, DOS and other threats.


> -----Original Message-----
> From: Tom Herbert <tom@quanto= nium.net>
> Sent: Thursday, May 03, 2018 3:00 PM
> To: Joel M. Halpern <jmh@joe= lhalpern.com>
> Cc: FIGURELLE, TERRY F = <tf2934@att.com>; Dirk.von-Hugo@telekom.de; Tom
> Herbert <tom@herbertland.com= >; ila@ietf.org; Alberto Rodrigu= ez-Natal
> <rodrigueznatal@gmail.c= om>; 5GANGIP <5gangip@ietf.or= g>
> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement]=
>
> On Thu, May 3, 2018 at 2:45 PM, Joel M. Halpern <jmh@joelhalpern.com>
> wrote:
> > I am missing something in your DDOS issue.
> >
> > At first, I thought the real issue (which you seem to be suggesti= ng
> > here) was DDOS from the Internet, using spoofed or non-spoofed > > addresses (with bot farms, there is much less need for or relevan= ce of
> spoofing).
> >
> > But then I tried to map it to the cases we have for using ILA. > > The primary case I have heard about is to use ILA for UE<->= UE and
> > UE<->EdgeComputing traffic.=C2=A0 If so, just filter all SI= Rs on incoming
> > packets from the Internet.=C2=A0 They aren't legal there.=C2= =A0 And similarly,
> > if one uses LISP within the operator domain, we can block whateve= r
> > blocks we use for EIDs for such local traffic.
>
> Joel,
>
> I'm not sure I understand what "filtering SIRs from the Inter= net"
> means. A SIR address is a globally visible address for devices like UE= s. So an
> Internet sender may legitimately send packets to SIR addresses, and al= so an
> Internet attacker could easily spew a whole bunch of packets with both= spoofed
> source addresses and spoofed UE addresses. So you'd want to allow = the
> legitimate traffic but block the attacking packets-- this isn't fe= asible since it's
> impossible to distinguish the bad from the good packets.
>
> >
> > If we want to use id-locator split of any kind for handling traff= ic to
> > / from the Internet, then we have to understand how that is suppo= sed
> > to work, and why, before we need to evaluate DDOS implications of= a
> > solution.=C2=A0 For LISP,the working group has explicitly said th= at
> > Inter-wide deployment is out of scope.
> >
> > Net: I do not see in currently described deployments, an issue th= at
> > differentiates LISP from ILA in these regards.=C2=A0 And Terry ha= s very
> > clearly spelled out that for mobile operators spoofing from UEs i= s not
> > considered an issue that the infrastructure needs to deal wih. >
> But there may be a whole network infrastructure of hundreds or even > thousands of users behind a UE, and there's no guarantee that that=
> infrastructure properly supports anti-spoofing. This basically this ca= se has the
> same problem as in the Internet case.
>
> Tom
>
> >
> > Yours,
> > Joel
> >
> >
> > On 5/3/18 5:33 PM, Tom Herbert wrote:
> >>
> >> On Thu, May 3, 2018 at 2:23 PM, FIGURELLE, TERRY F <tf2934@att.com>
> wrote:
> >>>
> >>> In the case of current 3GPP operators all the major vendo= rs support
> >>> anti-spoofing. The default was on for all but one vendor = which got
> >>> corrected the last time I did an RFP for EPC. So by confi= guration
> >>> the GGSN/PGW/PGW-U/UPF will not allow=C2=A0 the UE to sen= d packets that
> >>> don't match either the exact IP address or pushed sub= net or prefix
> >>> delegation that was sent in response to the APN create me= ssage.
> >>> Obviously if we remove GTP encapsulation that protect MAY= need to be
> enhanced towards an EDGE element.
> >>>
> >> Terry,
> >>
> >> Even so, the whole Internet does not require anti-spoofing, n= or do I
> >> believe that operators could require all down stream network = that are
> >> connected to support anti-spoofing. These are where the DOS a= ttacks
> >> orginate. The problem is when caches are being driven by user= taffic
> >> from these external networks, mitigations to detect DOS by IP= source
> >> address don't work without anti-spoofing (but even if the= y had
> >> anti-spoofing that still doesn't work when under a DDOS).=
> >>
> >> Tom
> >>
> >>
> >>
> >>> This is being covered as part of our participation in an = open source
> >>> vEPC (virtualize EPC, hypervisor, blah, blah, blah). So t= here will
> >>> be a micro service firewall that can be deploy at the edg= e plus we
> >>> already have planned support for big network infrastructu= re vendors
> >>> and 3GPP supplies (Cisco, Juniper, Ericsson, Nokia, Huawe= i, ...) to
> >>> cover this. Since this can=C2=A0 be a non-3GPP element we= will get this into
> ONAP.
> >>>
> >>> Thus we have this covered both for 3GPP nodes, micro serv= ices and
> >>> open source efforts. To give examples without vendor name= s there are
> >>> GTP aware firewalls that some operators use. It really ju= st another
> >>> capability in carrier class and business class firewalls = (had to add
> >>> it to load balancers, CNAT/NAT, some Wi-Fi routers and to= our DNS
> >>> solution which uses open source).=C2=A0 Obviously this wi= ll be supported
> >>> via a RADIUS feed for backwards compatibility. Today most= GTP
> >>> firewall simply follow the GTP-C signaling to learn the I= P
> >>> address(es) assigned to the UE for an APN. If we remove G= TP from
> >>> user plane that doesn't mean we remove it from contro= l plane or for
> >>> all hops. However, we will likely push to a micro service= at the
> >>> cell plus I need to check if we ever ask RAN vendors to s= upport this. I'll add
> this for 5G but we already did that RFP so it's a change order (yu= ck).
> >>>
> >>> I am not good at wordsmithing but I suggest there be some= paragraph
> >>> that covers network elements that can except a RADIUS fee= d. I need
> >>> to talk to our standards team to see if we want this on T= 8 (probably).
> >>>
> >>> So today for all AT&T, Verizon, Vodaphone,=C2=A0 ....= . I know or am
> >>> fairly confident they have anti spoofing tuned on in the<= br> > >>> GGSN/PGW/UPF plus I know they can turn this on per APN. N= ot sure why
> >>> anyone would disable this since we if you are delegating = a subnet to
> >>> a Wi-Fi hotspot (instead of the typical private addressin= g they use).
> >>>
> >>> We actually don't need any 3GPP changes since this is= already
> >>> covered using RADIUS to pass the information where it nee= ds to go. I
> >>> suspect most will leverage their caching SPR/UDR which al= ready has
> >>> the information. Even the GGSN we launched EDGE/GPRS when= I was much
> >>> younger supported anti-spoofing and many vendors cover th= is via a
> >>> number of methods (e.g. COPS works for older junos and RA= DIUS for Cisco
> IOS releases ).
> >>>
> >>> My suggestion is that I am willing to help whoever wants = to craft
> >>> the paragraph because I suck at that (fortunately I am go= od at other
> things).
> >>>
> >>> I don't think we need any changes to any standards to= cover this
> >>> since we already cover this and already are covering this= if we
> >>> strip out GTP (at least for one leg). I'll make sure = it gets into
> >>> our RAN requirements if not there since that may be the b= est place
> >>> for that edge. Plus I'll get it covered thru the ONAP= open source
> >>> effort we drove (we donated the software to the open sour= ce effort).
> >>> That means FM, PM, CM and IM will be covered in some futu= re ONAP
> release (takes time but faster than 3GPP).
> >>>
> >>> It's a bit debatable what is RAN when using virtualiz= ed network
> >>> functions
> >>> (VNF) and a bunch of open source stuff that we put it int= o all of
> >>> the needed elements like SDN, firewall, load balancer (no= t sure
> >>> that's needed at cell site but it is for core DNS, pr= oxy-TDF and
> >>> CNAT) out at the cell site. We aren't there yet (stil= l physical
> >>> eNB/NR and obviously we need hardware assist even with > >>> virtualization plus tight control of timing). I am lookin= g forward to when we
> start using containers.
> >>>
> >>> For our core I am sure we will use our UDR VNF as the cac= he for
> >>> whatever comes out of this effort in final standards. The=
> >>> information is already there (IMEI, device vendor, subscr= iption
> >>> information, UE IP address, APN, etc.). If we do anything= it would
> >>> be to augment an open source and if needed a 3GPP. I don&= #39;t think we need
> any changes but it's always best to verify.
> >>> For current RAN an anti-spoofing feature would come from = EMS which
> >>> can be via ONAP. I don't think that is a standards ef= fort thing
> >>> since it's a feature which may or may not already be = covered but it
> >>> will be in future RAN releases probably starting with eNB= /NR with
> >>> some vendor release if it's not already a feature. I = want to say
> >>> Ericsson and Nokia already can do this in eNB but I need = to go thru
> channels to ask.
> >>>
> >>> So maybe that paragraph recommends implementing anti-spoo= fing at all
> >>> edges and leaves it at that. Or we could say all edges in= cluding RAN
> >>> if that makes people happy.
> >>>
> >>>> -----Original Message-----
> >>>> From: 5gangip <5gangip-bounces@ietf.org> On Behalf Of Tom Herbert
> >>>> Sent: Thursday, May 03, 2018 10:46 AM
> >>>> To: Dirk.= von-Hugo@telekom.de
> >>>> Cc: Tom Herbert <tom@herbertland.com>; Joel M. Halpern
> >>>> <jmh@joelha= lpern.com>; ila@ietf.org; Albert= o Rodriguez-Natal
> >>>> <rodri= gueznatal@gmail.com>; 5GANGIP <5gangip@ietf.org>
> >>>> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: P= roblem
> >>>> Statement]
> >>>>
> >>>> On Thu, May 3, 2018 at 9:23 AM,=C2=A0 <Dirk.von-Hugo@telekom.de> wrote: > >>>>>
> >>>>> Hi Tom,
> >>>>> I understand you correctly that DDOS attacks can = never be
> >>>>> completely
> >>>>
> >>>> prevented whatever protocol you use.
> >>>>>
> >>>>> It will however always remain related to known IP= addresses and
> >>>>> the more
> >>>>
> >>>> versatile these are handled a mitigation strategy cou= ld be designed.
> >>>>
> >>>> Dirk,
> >>>>
> >>>> I disagree. IP addresses can too easily be spoofed, i= t's easy to
> >>>> hide identity behind a NAT (see discussion about CGNA= T and law
> >>>> enforcement on int-area list), and trying to turn off= individual
> >>>> addresses doesn't work if it's a DDOS. This i= s nothing new. For
> >>>> instance, content providers have long accepted the fa= ct that they
> >>>> can't prevent SYN attacks and there's little = point to trying to go
> >>>> back to source IP address (they are always spoofed in= a SYN
> >>>> attack). The better strategy is to absorb the attack = and minimize
> >>>> the negative effects so that the attack is not worth = the effort.
> >>>>
> >>>>> As you may have seen we mention improved handling= of mapping
> >>>>> systems
> >>>>
> >>>> and subsequently of DDOS protection also in the curre= nt version of
> >>>> our PS document https://url= defense.proofpoint.com/v2/url?u=3Dhttps-
> >>>> 3A__github.com_bsarikaya_atic_blob_master_atick-=
> >>>> 5Fproblemstatement.3.txt&d=3DDwICAg&c=3D= LFYZ-
> >>>>
> o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl2paJIf4zw&m=3DzYk= PItjuHMuGlJXD5K_4
> >>>> OstVOL1OQiA98fgBJ9c1Gjo&s=3DjLL_9a56R8Ic8o3u= JcR8mrF-
> >>>> JkzLL97h8rmZT_EqXnQ&e=3D=C2=A0 which Behcet has a= nnounced recently.
> >>>>>
> >>>>> May I ask you to please comment on the ideas outl= ined there?
> >>>>
> >>>>
> >>>> I don't see much difference in the latest version= . For a problem
> >>>> statement, I still think there is too much focus on t= he solutions
> >>>> and not nearly enough description of what the actual = problems are
> >>>> to be solved.
> >>>>
> >>>> Tom
> >>>>
> >>>>> Thanks!
> >>>>
> >>>>
> >>>>> Best Regards
> >>>>> Dirk
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: 5gangip [mailto:5gangip-bounces@ietf.org] On Behalf Of Tom
> >>>>> Herbert
> >>>>> Sent: Mittwoch, 2. Mai 2018 01:20
> >>>>> To: Joel M. Halpern <jmh@joelhalpern.com>
> >>>>> Cc: Tom Herbert <tom@herbertland.com>; ila@= ietf.org; Alberto
> >>>>> Rodriguez-Natal <rodrigueznatal@gmail.com>; 5GANGIP
> >>>>> <5gangip@i= etf.org>
> >>>>> Subject: Re: [5gangip] [Ila] ILA forwaring [Was R= e: Problem
> >>>>> Statement]
> >>>>>
> >>>>> On Tue, May 1, 2018 at 3:49 PM, Joel M. Halpern > >>>>> <jmh@jo= elhalpern.com>
> >>>>
> >>>> wrote:
> >>>>>>
> >>>>>> You seem to be saying that even though not al= l DDOS attacks are
> >>>>>> structurally the same, and even though if ILA= were widely adopted
> >>>>>> not all ILA networks would be structurally th= e same, there should
> >>>>>> nonetheless be one required qay of handling D= DOS?
> >>>>>
> >>>>>
> >>>>> Yes, at least as core default in the protocol. It= 's precisely
> >>>>> _because_ not all
> >>>>
> >>>> DDOS attacks are structurally the same. An attacker i= s not going to
> >>>> conform to to our expectations of what they should be= doing, so if
> >>>> we enable LISP option N to mitigate one form of attac= k, they will
> >>>> just use another attack that isn't mitigated. For= example, if the
> >>>> mitigation is to identify attackers by address when r= equests from
> >>>> the address exceed a threshold then this works as lon= g as the
> >>>> attacker strikes from one machine, but it falls apart= if the
> >>>> attacker launches a DDOS attack from several hosts wh= ere requests
> >>>> from none of the hosts exceed the threshold.
> >>>>>
> >>>>>
> >>>>> The ILA model works because it assumes there is n= o absolute way to
> >>>>> prevent
> >>>>
> >>>> the the worst case attack on a cache which is to comp= letely kill it
> >>>> (i.e. drive it to 0% hit rate). In this state the beh= avior
> >>>> sub-optimal routing, which is much better than loss o= f service.
> >>>> This is not dependent on the structure of the attack,= network
> >>>> topology, or the network operator getting the configu= ration just
> >>>> right--
> >>>> it is inherent in the protocol.
> >>>>>
> >>>>>
> >>>>> Tom
> >>>>>
> >>>>>>
> >>>>>> Yours,
> >>>>>> Joel
> >>>>>>
> >>>>>>
> >>>>>> On 5/1/18 6:32 PM, Tom Herbert wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> On Tue, May 1, 2018 at 2:59 PM, Alberto R= odriguez-Natal
> >>>>>>> <rodrigueznatal@gmail.com> wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Tue, May 1, 2018 at 10:16 AM, Tom = Herbert
> <tom@herbertland.com>=
> >>>>
> >>>> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I think you've misunderstood = my position. Caches are _very_
> >>>>>>>>> important to eliminate the cost t= riangular routing (latency,
> >>>>>>>>> average path
> >>>>
> >>>> load).
> >>>>>>>>>
> >>>>>>>>> This reduces latency and reduces = average load on ILA-Rs. But, and
> >>>>>>>>> this is the critical part, caches= are only an _optimization_ in
> >>>>>>>>> ILA. That means if the cache is r= endered ineffective (like by a
> >>>>>>>>> well crafted DOS
> >>>>>>>>> attack) then the only effect is t= hat the optimization is loss (i.e.
> >>>>>>>>> greater latency due to triangular= router)-- this is quantitively
> >>>>>>>>> the worst effect of the attack on= an ILA cache. This can be
> >>>>>>>>> contrasted that to LISP where the= worst case effects of a DOS
> >>>>>>>>> attack on the cache is loss of se= rvice for users (infinite latency
> >>>>>>>>> since packets can be dropped or i= ndefinitely blocked on a cache
> >>>>>>>>> miss).
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> This can be misleading. This is not c= omparing LISP vs ILA, this is
> >>>>>>>> comparing the models of Request/Reply= at the edge vs Notifications
> >>>>>>>> (aka Redirects) at the core. Both LIS= P-CP and ILAMP support these
> >>>>>>>> two models.
> >>>>>>>>
> >>>>>>>> Besides, this is assuming an scenario= where the only feasible DOS
> >>>>>>>> mitigation is absorbing the attack. T= here are other scenarios where
> >>>>>>>> other countermeasures are possible. F= or instance, if you have a
> >>>>>>>> deployment where you can prevent addr= ess spoofing, counting and
> >>>>>>>> blocking misbehaving nodes offers sim= ilar DOS protection and
> >>>>>>>> requires way less infrastructure reso= urces.
> >>>>>>>>
> >>>>>>> Alberto,
> >>>>>>>
> >>>>>>> The answer to my question of how does LIS= P address DOS attacks
> seems
> >>>>>>> to be "there are many options".= Some of the options are to assume
> >>>>>>> that DOS does not exist in the network, s= ome assume external
> >>>>>>> configuration like address spoofing is en= abled, some assume that
> >>>>>>> attacks can be identified and can be stop= ped at the source, some
> >>>>>>> might assume that everything is okay beca= use there's never been a
> >>>>>>> DOS attack before. I have yet to see the = effects of any of these
> >>>>>>> quantified, and none of these state how t= he LISP _protocol_ itself
> >>>>>>> addresses DOS. It may seem counter-intuit= ive, but offering a bunch
> >>>>>>> of options really is not necessarily a go= od thing-- sometime less is
> >>>>>>> more. To put this another way LISP has be= en rejected from Linux
> >>>>>>> precisely because of its susceptibility t= o DOS. If you were to try
> >>>>>>> again and the best answer to the DOS ques= tion is that it's up to the
> >>>>>>> operator to figure out the right options = to use, then I believe it
> >>>>>>> would be soundly rejected again. That app= roach does not work at
> >>>>>>> scale.
> >>>>>>>
> >>>>>>> Tom
> >>>>>>>
> >>>>>>> ____________________________________= ___________
> >>>>>>> ila mailing list
> >>>>>>> ila@ietf.= org
> >>>>>>> https://urldefe= nse.proofpoint.com/v2/url?u=3Dhttps-
> 3A__www.ietf.org_ma
> >>>>>>> ilman_listinfo_ila&d=3DDwICAg&c= =3DLFYZ-
> >>>>
> >>>> o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl
> >>>>>>>
> >>>>>>>
> >>>>
> 2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4OstVOL1OQiA98fgBJ9c1Gj= o&s=3DBO3snt8C
> >>>> RQ
> >>>>>>>
> >>>>>>> gy1xwhx2CY10VUbM_rgntgpV9k3-Cskd8&am= p;e=3D
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>> ____________________________________________= ___
> >>>>> 5gangip mailing list
> >>>>> 5gangip@ietf.= org
> >>>>> https://urldefense.proo= fpoint.com/v2/url?u=3Dhttps-
> 3A__www.ietf.org_mail
> >>>>> man_listinfo_5gangip&d=3DDwICAg&c=3D= LFYZ-
> >>>>
> >>>> o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl
> >>>>>
> >>>>>
> >>>>
> 2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4OstVOL1OQiA98fgBJ9c1Gj= o&s=3DFnQLMire
> >>>> MiKC
> >>>>>
> >>>>> SkPaOGFCybzDc2i2y49Cgtbl6mCLc9c&e=3D
> >>>>
> >>>>
> >>>> _______________________________________________<= br> > >>>> 5gangip mailing list
> >>>> 5gangip@ietf.org<= /a>
> >>>> https://urldefense.proofpoi= nt.com/v2/url?u=3Dhttps-
> >>>> 3A__www.ietf.org_mailman_listinfo_5gangip&d= =3DDwICAg&c=3DLFYZ-
> >>>>
> o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl2paJIf4zw&m=3DzYk= PItjuHMuGlJXD5K_4
> >>>>
> OstVOL1OQiA98fgBJ9c1Gjo&s=3DFnQLMireMiKCSkPaOGFCybzDc2i2y49Cgtbl6mC
> >>>> Lc9c&e=3D
> >>
> >>
> >
_______________________________________________
5gangip mailing list
5gangip@ietf.org
https://www.ietf.org/mailman/listinfo/5gangip<= br>

--00000000000003e1d1056bb1ed10-- From nobody Tue May 8 07:44:42 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCE8124235 for ; Tue, 8 May 2018 07:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.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 4rlTsu54vuJn for ; Tue, 8 May 2018 07:44:30 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (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 B7875124319 for ; Tue, 8 May 2018 07:44:29 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id v5-v6so32577135wrf.9 for ; Tue, 08 May 2018 07:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SezDiQ7TQsFeP9DqJGSDszftwAoIiUW0cs6kV/gPmJE=; b=vb3+RJ/1+9wQVlpV/w2r+lITGGM8uASKKXLVs9QvtFMyMirlKXA7oSt4w5vpCyDzCz DTQxftlCEYkba5ezDZrZptLUzlnmkR8T+Hz2ixmke6da1aHUYUqfeDlY+UIjAuoJ4tAg rnO2m1yRwMw9Xp0ucLQRrk1kT2e3JJ9JClouWr1xI8wJ/LyHrJn6Y33T3kYeFSsuqevu dbw/2e52fcFRoyBycjAss86380/JKIdb/AQpR5smkV8dVosfLXXZLVT/mZB5nJcJoIIs VmmJnLMQCPkYyyNsm8tFFTknBxGTas2nAQSA2TsCaJGaxCDifdnchcJU/lLVXUy+8Lrh rP2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SezDiQ7TQsFeP9DqJGSDszftwAoIiUW0cs6kV/gPmJE=; b=nIv/dIKBd18Zsube+AUpqbumPzkyiEZMSp98kjdV53/sCw0n0eVe8p7nYOnSKnsT0G VkMsLwG7gIWOt3wvgi06u3/O4R662RYFJrwjxrnGdv83savVIT+4mnKKRHrTWicapEBx Wm9EYDDnSJpvhvi9mHvCJVG42DNMruilYbvhu63acwzcAOLu1FCnykdwxequqGBFUY5e hniWxP/MfxexQVN5xaXtYBtaz1mwme2tQHbDWwkLPzeoI88xqJvjJkcjyY/ID9zEw5y3 4isdQovpkB9ScR6XzfLJlk+f8ULV18OW/QH9dKl29GYr0r7k/3BD2NO/k5MPgtFjsYQz vNMQ== X-Gm-Message-State: ALQs6tB626kJpqGghZm62oLOc8Yd0XvNBSrIxef+aFttMFDSJ7D+0hZI c3tA9h3ZH8wYxBS/43dNW0degxFfSNe+79KOo19EKA== X-Google-Smtp-Source: AB8JxZpl5/TDSC+aNcx6qmtW1yqn7JvHn5eidYjJGCv+Mg1R97k7lq1/6tXbQ2XUojDHqxYDYzsk0SzvchRaGeWHO2w= X-Received: by 2002:adf:dc0d:: with SMTP id t13-v6mr29811945wri.153.1525790667954; Tue, 08 May 2018 07:44:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.227 with HTTP; Tue, 8 May 2018 07:44:27 -0700 (PDT) In-Reply-To: References: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> <8aee42db5f0f407c86fda881769ceb77@HE105715.emea1.cds.t-internal.com> <1AFE10CF28AE8B4C9663445736B8034D3822FAFE@CAFRFD1MSGUSRJI.ITServices.sbc.com> <0cbb9987-0b47-9428-3db7-2c9fab821268@joelhalpern.com> <1AFE10CF28AE8B4C9663445736B8034D3822FC27@CAFRFD1MSGUSRJI.ITServices.sbc.com> From: Tom Herbert Date: Tue, 8 May 2018 07:44:27 -0700 Message-ID: To: Lorenzo Colitti Cc: "FIGURELLE, TERRY F" , "Joel M. Halpern" , Tom Herbert , "ila@ietf.org" , 5GANGIP <5gangip@ietf.org>, Alberto Rodriguez-Natal , "Dirk.von-Hugo@telekom.de" Content-Type: multipart/alternative; boundary="000000000000c3f38f056bb2d26c" Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 14:44:35 -0000 --000000000000c3f38f056bb2d26c Content-Type: text/plain; charset="UTF-8" On Tue, May 8, 2018 at 6:39 AM, Lorenzo Colitti wrote: > FWIW, I believe there are large operators that do not block unsolicited > inbound traffic to mobile networks. One of them is T-Mobile. > > I should hope that a majority of access networks don't do that, lest it would be impossible to deploy new transport protocols (like QUIC for instance) and the ossification of the Internet would be complete. Tom On Fri, May 4, 2018 at 7:53 AM, FIGURELLE, TERRY F wrote: > >> No. We have always block unsolicited traffic from the Internet and it is >> too complicated to discuss here. >> >> We even did this way back for CDPD. For dedicated APN's we allow the >> enterprise to tell us what rules they want to protect the mobile from their >> network and what traffic to not allow from the mobile. This is one of the >> reasons firewalls and CNAT cost more if they support mobility features. We >> spent a lot of time working with potential vendors. >> >> Since this started with usage based rate plans for all mobile operators >> the subscriber would get charged if we allowed spam from the Internet or >> from other mobiles. So this has always been block and vendors have features >> to help out in 3GPP elements. A GGSN with anti-spoofing not disabled >> doesn't allow traffic to a mobile that doesn't match an entry in the flow >> table. We have hundreds of policy rules that get enabled from the PCRF/PCF >> on the PGW(PCEF)/UPF. We also enabled our proxies to be transparent >> proxy-TDF. That means they also have policy interfaces and we do a bunch of >> stuff here including processing signed manifests. Plus the rules are pushed >> on the control plane not the data plane and it includes UE, RAN, >> SGW/PGW/UPF and if applicable TDF's and AS's. We can push rules to the UE >> that allow, (drop), route/path (e.g. bearer). We even have to have some >> country specific treatment (a bigger challenge we had for vehicles using >> our Connected Car solution like GM OnStar). >> >> While a mobile could get hacked and it could break the flow rule >> treatment some of that is down in the 3GPP chipset. But we are aware of the >> risk and we have counter measures as best we can. I should point out that >> these flow rules go into RAN too and rules have a direction (from UE, to UE >> or both). >> >> My opinion is that malware, spoofing, DOS, DDOS and any other threat is a >> serious operational issue. That is the best place to deal with it because >> standards could never keep pace. We and other operators request features >> from vendors and they also come up with stuff as a value add. >> >> Simply stated the solution needs to be protected but we don't need tons >> of detail in every standard. >> >> I would never say don't be concerned about something. I just don't think >> every standard needs details on spoofing, DOS and other threats. >> >> >> > -----Original Message----- >> > From: Tom Herbert >> > Sent: Thursday, May 03, 2018 3:00 PM >> > To: Joel M. Halpern >> > Cc: FIGURELLE, TERRY F ; Dirk.von-Hugo@telekom.de; Tom >> > Herbert ; ila@ietf.org; Alberto Rodriguez-Natal >> > ; 5GANGIP <5gangip@ietf.org> >> > Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement] >> > >> > On Thu, May 3, 2018 at 2:45 PM, Joel M. Halpern >> > wrote: >> > > I am missing something in your DDOS issue. >> > > >> > > At first, I thought the real issue (which you seem to be suggesting >> > > here) was DDOS from the Internet, using spoofed or non-spoofed >> > > addresses (with bot farms, there is much less need for or relevance of >> > spoofing). >> > > >> > > But then I tried to map it to the cases we have for using ILA. >> > > The primary case I have heard about is to use ILA for UE<->UE and >> > > UE<->EdgeComputing traffic. If so, just filter all SIRs on incoming >> > > packets from the Internet. They aren't legal there. And similarly, >> > > if one uses LISP within the operator domain, we can block whatever >> > > blocks we use for EIDs for such local traffic. >> > >> > Joel, >> > >> > I'm not sure I understand what "filtering SIRs from the Internet" >> > means. A SIR address is a globally visible address for devices like >> UEs. So an >> > Internet sender may legitimately send packets to SIR addresses, and >> also an >> > Internet attacker could easily spew a whole bunch of packets with both >> spoofed >> > source addresses and spoofed UE addresses. So you'd want to allow the >> > legitimate traffic but block the attacking packets-- this isn't >> feasible since it's >> > impossible to distinguish the bad from the good packets. >> > >> > > >> > > If we want to use id-locator split of any kind for handling traffic to >> > > / from the Internet, then we have to understand how that is supposed >> > > to work, and why, before we need to evaluate DDOS implications of a >> > > solution. For LISP,the working group has explicitly said that >> > > Inter-wide deployment is out of scope. >> > > >> > > Net: I do not see in currently described deployments, an issue that >> > > differentiates LISP from ILA in these regards. And Terry has very >> > > clearly spelled out that for mobile operators spoofing from UEs is not >> > > considered an issue that the infrastructure needs to deal wih. >> > >> > But there may be a whole network infrastructure of hundreds or even >> > thousands of users behind a UE, and there's no guarantee that that >> > infrastructure properly supports anti-spoofing. This basically this >> case has the >> > same problem as in the Internet case. >> > >> > Tom >> > >> > > >> > > Yours, >> > > Joel >> > > >> > > >> > > On 5/3/18 5:33 PM, Tom Herbert wrote: >> > >> >> > >> On Thu, May 3, 2018 at 2:23 PM, FIGURELLE, TERRY F >> > wrote: >> > >>> >> > >>> In the case of current 3GPP operators all the major vendors support >> > >>> anti-spoofing. The default was on for all but one vendor which got >> > >>> corrected the last time I did an RFP for EPC. So by configuration >> > >>> the GGSN/PGW/PGW-U/UPF will not allow the UE to send packets that >> > >>> don't match either the exact IP address or pushed subnet or prefix >> > >>> delegation that was sent in response to the APN create message. >> > >>> Obviously if we remove GTP encapsulation that protect MAY need to be >> > enhanced towards an EDGE element. >> > >>> >> > >> Terry, >> > >> >> > >> Even so, the whole Internet does not require anti-spoofing, nor do I >> > >> believe that operators could require all down stream network that are >> > >> connected to support anti-spoofing. These are where the DOS attacks >> > >> orginate. The problem is when caches are being driven by user taffic >> > >> from these external networks, mitigations to detect DOS by IP source >> > >> address don't work without anti-spoofing (but even if they had >> > >> anti-spoofing that still doesn't work when under a DDOS). >> > >> >> > >> Tom >> > >> >> > >> >> > >> >> > >>> This is being covered as part of our participation in an open source >> > >>> vEPC (virtualize EPC, hypervisor, blah, blah, blah). So there will >> > >>> be a micro service firewall that can be deploy at the edge plus we >> > >>> already have planned support for big network infrastructure vendors >> > >>> and 3GPP supplies (Cisco, Juniper, Ericsson, Nokia, Huawei, ...) to >> > >>> cover this. Since this can be a non-3GPP element we will get this >> into >> > ONAP. >> > >>> >> > >>> Thus we have this covered both for 3GPP nodes, micro services and >> > >>> open source efforts. To give examples without vendor names there are >> > >>> GTP aware firewalls that some operators use. It really just another >> > >>> capability in carrier class and business class firewalls (had to add >> > >>> it to load balancers, CNAT/NAT, some Wi-Fi routers and to our DNS >> > >>> solution which uses open source). Obviously this will be supported >> > >>> via a RADIUS feed for backwards compatibility. Today most GTP >> > >>> firewall simply follow the GTP-C signaling to learn the IP >> > >>> address(es) assigned to the UE for an APN. If we remove GTP from >> > >>> user plane that doesn't mean we remove it from control plane or for >> > >>> all hops. However, we will likely push to a micro service at the >> > >>> cell plus I need to check if we ever ask RAN vendors to support >> this. I'll add >> > this for 5G but we already did that RFP so it's a change order (yuck). >> > >>> >> > >>> I am not good at wordsmithing but I suggest there be some paragraph >> > >>> that covers network elements that can except a RADIUS feed. I need >> > >>> to talk to our standards team to see if we want this on T8 >> (probably). >> > >>> >> > >>> So today for all AT&T, Verizon, Vodaphone, ..... I know or am >> > >>> fairly confident they have anti spoofing tuned on in the >> > >>> GGSN/PGW/UPF plus I know they can turn this on per APN. Not sure why >> > >>> anyone would disable this since we if you are delegating a subnet to >> > >>> a Wi-Fi hotspot (instead of the typical private addressing they >> use). >> > >>> >> > >>> We actually don't need any 3GPP changes since this is already >> > >>> covered using RADIUS to pass the information where it needs to go. I >> > >>> suspect most will leverage their caching SPR/UDR which already has >> > >>> the information. Even the GGSN we launched EDGE/GPRS when I was much >> > >>> younger supported anti-spoofing and many vendors cover this via a >> > >>> number of methods (e.g. COPS works for older junos and RADIUS for >> Cisco >> > IOS releases ). >> > >>> >> > >>> My suggestion is that I am willing to help whoever wants to craft >> > >>> the paragraph because I suck at that (fortunately I am good at other >> > things). >> > >>> >> > >>> I don't think we need any changes to any standards to cover this >> > >>> since we already cover this and already are covering this if we >> > >>> strip out GTP (at least for one leg). I'll make sure it gets into >> > >>> our RAN requirements if not there since that may be the best place >> > >>> for that edge. Plus I'll get it covered thru the ONAP open source >> > >>> effort we drove (we donated the software to the open source effort). >> > >>> That means FM, PM, CM and IM will be covered in some future ONAP >> > release (takes time but faster than 3GPP). >> > >>> >> > >>> It's a bit debatable what is RAN when using virtualized network >> > >>> functions >> > >>> (VNF) and a bunch of open source stuff that we put it into all of >> > >>> the needed elements like SDN, firewall, load balancer (not sure >> > >>> that's needed at cell site but it is for core DNS, proxy-TDF and >> > >>> CNAT) out at the cell site. We aren't there yet (still physical >> > >>> eNB/NR and obviously we need hardware assist even with >> > >>> virtualization plus tight control of timing). I am looking forward >> to when we >> > start using containers. >> > >>> >> > >>> For our core I am sure we will use our UDR VNF as the cache for >> > >>> whatever comes out of this effort in final standards. The >> > >>> information is already there (IMEI, device vendor, subscription >> > >>> information, UE IP address, APN, etc.). If we do anything it would >> > >>> be to augment an open source and if needed a 3GPP. I don't think we >> need >> > any changes but it's always best to verify. >> > >>> For current RAN an anti-spoofing feature would come from EMS which >> > >>> can be via ONAP. I don't think that is a standards effort thing >> > >>> since it's a feature which may or may not already be covered but it >> > >>> will be in future RAN releases probably starting with eNB/NR with >> > >>> some vendor release if it's not already a feature. I want to say >> > >>> Ericsson and Nokia already can do this in eNB but I need to go thru >> > channels to ask. >> > >>> >> > >>> So maybe that paragraph recommends implementing anti-spoofing at all >> > >>> edges and leaves it at that. Or we could say all edges including RAN >> > >>> if that makes people happy. >> > >>> >> > >>>> -----Original Message----- >> > >>>> From: 5gangip <5gangip-bounces@ietf.org> On Behalf Of Tom Herbert >> > >>>> Sent: Thursday, May 03, 2018 10:46 AM >> > >>>> To: Dirk.von-Hugo@telekom.de >> > >>>> Cc: Tom Herbert ; Joel M. Halpern >> > >>>> ; ila@ietf.org; Alberto Rodriguez-Natal >> > >>>> ; 5GANGIP <5gangip@ietf.org> >> > >>>> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem >> > >>>> Statement] >> > >>>> >> > >>>> On Thu, May 3, 2018 at 9:23 AM, wrote: >> > >>>>> >> > >>>>> Hi Tom, >> > >>>>> I understand you correctly that DDOS attacks can never be >> > >>>>> completely >> > >>>> >> > >>>> prevented whatever protocol you use. >> > >>>>> >> > >>>>> It will however always remain related to known IP addresses and >> > >>>>> the more >> > >>>> >> > >>>> versatile these are handled a mitigation strategy could be >> designed. >> > >>>> >> > >>>> Dirk, >> > >>>> >> > >>>> I disagree. IP addresses can too easily be spoofed, it's easy to >> > >>>> hide identity behind a NAT (see discussion about CGNAT and law >> > >>>> enforcement on int-area list), and trying to turn off individual >> > >>>> addresses doesn't work if it's a DDOS. This is nothing new. For >> > >>>> instance, content providers have long accepted the fact that they >> > >>>> can't prevent SYN attacks and there's little point to trying to go >> > >>>> back to source IP address (they are always spoofed in a SYN >> > >>>> attack). The better strategy is to absorb the attack and minimize >> > >>>> the negative effects so that the attack is not worth the effort. >> > >>>> >> > >>>>> As you may have seen we mention improved handling of mapping >> > >>>>> systems >> > >>>> >> > >>>> and subsequently of DDOS protection also in the current version of >> > >>>> our PS document https://urldefense.proofpoint.com/v2/url?u=https- >> > >>>> 3A__github.com_bsarikaya_atic_blob_master_atick- >> > >>>> 5Fproblemstatement.3.txt&d=DwICAg&c=LFYZ- >> > >>>> >> > o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=zYkPItjuHMuGlJXD5K_4 >> > >>>> OstVOL1OQiA98fgBJ9c1Gjo&s=jLL_9a56R8Ic8o3uJcR8mrF- >> > >>>> JkzLL97h8rmZT_EqXnQ&e= which Behcet has announced recently. >> > >>>>> >> > >>>>> May I ask you to please comment on the ideas outlined there? >> > >>>> >> > >>>> >> > >>>> I don't see much difference in the latest version. For a problem >> > >>>> statement, I still think there is too much focus on the solutions >> > >>>> and not nearly enough description of what the actual problems are >> > >>>> to be solved. >> > >>>> >> > >>>> Tom >> > >>>> >> > >>>>> Thanks! >> > >>>> >> > >>>> >> > >>>>> Best Regards >> > >>>>> Dirk >> > >>>>> >> > >>>>> -----Original Message----- >> > >>>>> From: 5gangip [mailto:5gangip-bounces@ietf.org] On Behalf Of Tom >> > >>>>> Herbert >> > >>>>> Sent: Mittwoch, 2. Mai 2018 01:20 >> > >>>>> To: Joel M. Halpern >> > >>>>> Cc: Tom Herbert ; ila@ietf.org; Alberto >> > >>>>> Rodriguez-Natal ; 5GANGIP >> > >>>>> <5gangip@ietf.org> >> > >>>>> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem >> > >>>>> Statement] >> > >>>>> >> > >>>>> On Tue, May 1, 2018 at 3:49 PM, Joel M. Halpern >> > >>>>> >> > >>>> >> > >>>> wrote: >> > >>>>>> >> > >>>>>> You seem to be saying that even though not all DDOS attacks are >> > >>>>>> structurally the same, and even though if ILA were widely adopted >> > >>>>>> not all ILA networks would be structurally the same, there should >> > >>>>>> nonetheless be one required qay of handling DDOS? >> > >>>>> >> > >>>>> >> > >>>>> Yes, at least as core default in the protocol. It's precisely >> > >>>>> _because_ not all >> > >>>> >> > >>>> DDOS attacks are structurally the same. An attacker is not going to >> > >>>> conform to to our expectations of what they should be doing, so if >> > >>>> we enable LISP option N to mitigate one form of attack, they will >> > >>>> just use another attack that isn't mitigated. For example, if the >> > >>>> mitigation is to identify attackers by address when requests from >> > >>>> the address exceed a threshold then this works as long as the >> > >>>> attacker strikes from one machine, but it falls apart if the >> > >>>> attacker launches a DDOS attack from several hosts where requests >> > >>>> from none of the hosts exceed the threshold. >> > >>>>> >> > >>>>> >> > >>>>> The ILA model works because it assumes there is no absolute way to >> > >>>>> prevent >> > >>>> >> > >>>> the the worst case attack on a cache which is to completely kill it >> > >>>> (i.e. drive it to 0% hit rate). In this state the behavior >> > >>>> sub-optimal routing, which is much better than loss of service. >> > >>>> This is not dependent on the structure of the attack, network >> > >>>> topology, or the network operator getting the configuration just >> > >>>> right-- >> > >>>> it is inherent in the protocol. >> > >>>>> >> > >>>>> >> > >>>>> Tom >> > >>>>> >> > >>>>>> >> > >>>>>> Yours, >> > >>>>>> Joel >> > >>>>>> >> > >>>>>> >> > >>>>>> On 5/1/18 6:32 PM, Tom Herbert wrote: >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> On Tue, May 1, 2018 at 2:59 PM, Alberto Rodriguez-Natal >> > >>>>>>> wrote: >> > >>>>>>>> >> > >>>>>>>> >> > >>>>>>>> On Tue, May 1, 2018 at 10:16 AM, Tom Herbert >> > >> > >>>> >> > >>>> wrote: >> > >>>>>>>>> >> > >>>>>>>>> >> > >>>>>>>>> >> > >>>>>>>>> I think you've misunderstood my position. Caches are _very_ >> > >>>>>>>>> important to eliminate the cost triangular routing (latency, >> > >>>>>>>>> average path >> > >>>> >> > >>>> load). >> > >>>>>>>>> >> > >>>>>>>>> This reduces latency and reduces average load on ILA-Rs. But, >> and >> > >>>>>>>>> this is the critical part, caches are only an _optimization_ >> in >> > >>>>>>>>> ILA. That means if the cache is rendered ineffective (like by >> a >> > >>>>>>>>> well crafted DOS >> > >>>>>>>>> attack) then the only effect is that the optimization is loss >> (i.e. >> > >>>>>>>>> greater latency due to triangular router)-- this is >> quantitively >> > >>>>>>>>> the worst effect of the attack on an ILA cache. This can be >> > >>>>>>>>> contrasted that to LISP where the worst case effects of a DOS >> > >>>>>>>>> attack on the cache is loss of service for users (infinite >> latency >> > >>>>>>>>> since packets can be dropped or indefinitely blocked on a >> cache >> > >>>>>>>>> miss). >> > >>>>>>>> >> > >>>>>>>> >> > >>>>>>>> >> > >>>>>>>> >> > >>>>>>>> This can be misleading. This is not comparing LISP vs ILA, >> this is >> > >>>>>>>> comparing the models of Request/Reply at the edge vs >> Notifications >> > >>>>>>>> (aka Redirects) at the core. Both LISP-CP and ILAMP support >> these >> > >>>>>>>> two models. >> > >>>>>>>> >> > >>>>>>>> Besides, this is assuming an scenario where the only feasible >> DOS >> > >>>>>>>> mitigation is absorbing the attack. There are other scenarios >> where >> > >>>>>>>> other countermeasures are possible. For instance, if you have a >> > >>>>>>>> deployment where you can prevent address spoofing, counting and >> > >>>>>>>> blocking misbehaving nodes offers similar DOS protection and >> > >>>>>>>> requires way less infrastructure resources. >> > >>>>>>>> >> > >>>>>>> Alberto, >> > >>>>>>> >> > >>>>>>> The answer to my question of how does LISP address DOS attacks >> > seems >> > >>>>>>> to be "there are many options". Some of the options are to >> assume >> > >>>>>>> that DOS does not exist in the network, some assume external >> > >>>>>>> configuration like address spoofing is enabled, some assume that >> > >>>>>>> attacks can be identified and can be stopped at the source, some >> > >>>>>>> might assume that everything is okay because there's never been >> a >> > >>>>>>> DOS attack before. I have yet to see the effects of any of these >> > >>>>>>> quantified, and none of these state how the LISP _protocol_ >> itself >> > >>>>>>> addresses DOS. It may seem counter-intuitive, but offering a >> bunch >> > >>>>>>> of options really is not necessarily a good thing-- sometime >> less is >> > >>>>>>> more. To put this another way LISP has been rejected from Linux >> > >>>>>>> precisely because of its susceptibility to DOS. If you were to >> try >> > >>>>>>> again and the best answer to the DOS question is that it's up >> to the >> > >>>>>>> operator to figure out the right options to use, then I believe >> it >> > >>>>>>> would be soundly rejected again. That approach does not work at >> > >>>>>>> scale. >> > >>>>>>> >> > >>>>>>> Tom >> > >>>>>>> >> > >>>>>>> _______________________________________________ >> > >>>>>>> ila mailing list >> > >>>>>>> ila@ietf.org >> > >>>>>>> https://urldefense.proofpoint.com/v2/url?u=https- >> > 3A__www.ietf.org_ma >> > >>>>>>> ilman_listinfo_ila&d=DwICAg&c=LFYZ- >> > >>>> >> > >>>> o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl >> > >>>>>>> >> > >>>>>>> >> > >>>> >> > 2paJIf4zw&m=zYkPItjuHMuGlJXD5K_4OstVOL1OQiA98fgBJ9c1Gjo&s=BO3snt8C >> > >>>> RQ >> > >>>>>>> >> > >>>>>>> gy1xwhx2CY10VUbM_rgntgpV9k3-Cskd8&e= >> > >>>>>>> >> > >>>>>> >> > >>>>> >> > >>>>> _______________________________________________ >> > >>>>> 5gangip mailing list >> > >>>>> 5gangip@ietf.org >> > >>>>> https://urldefense.proofpoint.com/v2/url?u=https- >> > 3A__www.ietf.org_mail >> > >>>>> man_listinfo_5gangip&d=DwICAg&c=LFYZ- >> > >>>> >> > >>>> o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl >> > >>>>> >> > >>>>> >> > >>>> >> > 2paJIf4zw&m=zYkPItjuHMuGlJXD5K_4OstVOL1OQiA98fgBJ9c1Gjo&s=FnQLMire >> > >>>> MiKC >> > >>>>> >> > >>>>> SkPaOGFCybzDc2i2y49Cgtbl6mCLc9c&e= >> > >>>> >> > >>>> >> > >>>> _______________________________________________ >> > >>>> 5gangip mailing list >> > >>>> 5gangip@ietf.org >> > >>>> https://urldefense.proofpoint.com/v2/url?u=https- >> > >>>> 3A__www.ietf.org_mailman_listinfo_5gangip&d=DwICAg&c=LFYZ- >> > >>>> >> > o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=zYkPItjuHMuGlJXD5K_4 >> > >>>> >> > OstVOL1OQiA98fgBJ9c1Gjo&s=FnQLMireMiKCSkPaOGFCybzDc2i2y49Cgtbl6mC >> > >>>> Lc9c&e= >> > >> >> > >> >> > > >> _______________________________________________ >> 5gangip mailing list >> 5gangip@ietf.org >> https://www.ietf.org/mailman/listinfo/5gangip >> > > --000000000000c3f38f056bb2d26c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, May 8, 2018 at 6:39 AM, Lorenzo Colitti <<= a href=3D"mailto:lorenzo@google.com" target=3D"_blank">lorenzo@google.com> wrote:
FWI= W, I believe there are large operators that do not block unsolicited inboun= d traffic to mobile networks. One of them is T-Mobile.

I should hope that a majority of ac= cess networks don't do that, lest it would be impossible to deploy new = transport protocols (like QUIC for instance) and the ossification of the In= ternet would be complete.

Tom

=
On Fri, May 4, 2018 at 7:53 AM, FIGURELLE,= TERRY F <tf2934@att.com> wrote:
No. We have always block unsolicited= traffic from the Internet and it is too complicated to discuss here.

We even did this way back for CDPD. For dedicated APN's we allow the en= terprise to tell us what rules they want to protect the mobile from their n= etwork and what traffic to not allow from the mobile. This is one of the re= asons firewalls and CNAT cost more if they support mobility features. We sp= ent a lot of time working with potential vendors.

Since this started with usage based rate plans for all mobile operators the= subscriber would get charged if we allowed spam from the Internet or from = other mobiles. So this has always been block and vendors have features to h= elp out in 3GPP elements. A GGSN with anti-spoofing not disabled doesn'= t allow traffic to a mobile that doesn't match an entry in the flow tab= le. We have hundreds of policy rules that get enabled from the PCRF/PCF on = the PGW(PCEF)/UPF. We also enabled our proxies to be transparent proxy-TDF.= That means they also have policy interfaces and we do a bunch of stuff her= e including processing signed manifests. Plus the rules are pushed on the c= ontrol plane not the data plane and it includes UE, RAN, SGW/PGW/UPF and if= applicable TDF's and AS's. We can push rules to the UE that allow,= (drop), route/path (e.g. bearer). We even have to have some country specif= ic treatment (a bigger challenge we had for vehicles using our Connected Ca= r solution like GM OnStar).

While a mobile could get hacked and it could break the flow rule treatment = some of that is down in the 3GPP chipset. But we are aware of the risk and = we have counter measures as best we can. I should point out that these flow= rules go into RAN too and rules have a direction (from UE, to UE or both).=

My opinion is that malware, spoofing, DOS, DDOS and any other threat is a s= erious operational issue. That is the best place to deal with it because st= andards could never keep pace. We and other operators request features from= vendors and they also come up with stuff as a value add.

Simply stated the solution needs to be protected but we don't need tons= of detail in every standard.

I would never say don't be concerned about something. I just don't = think every standard needs details on spoofing, DOS and other threats.


> -----Original Message-----
> From: Tom Herbert <tom@quantonium.net>
> Sent: Thursday, May 03, 2018 3:00 PM
> To: Joel M. Halpern <jmh@joelhalpern.com>
> Cc: FIGURELLE, TE= RRY F <tf2934@att.co= m>; Di= rk.von-Hugo@telekom.de; Tom
> Herbert <t= om@herbertland.com>; ila@ietf.org; Alberto Rodriguez-Natal
> <rodr= igueznatal@gmail.com>; 5GANGIP <5gangip@ietf.org>
> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement]=
>
> On Thu, May 3, 2018 at 2:45 PM, Joel M. Halpern <jmh@joelhalpern.com>
> wrote:
> > I am missing something in your DDOS issue.
> >
> > At first, I thought the real issue (which you seem to be suggesti= ng
> > here) was DDOS from the Internet, using spoofed or non-spoofed > > addresses (with bot farms, there is much less need for or relevan= ce of
> spoofing).
> >
> > But then I tried to map it to the cases we have for using ILA. > > The primary case I have heard about is to use ILA for UE<->= UE and
> > UE<->EdgeComputing traffic.=C2=A0 If so, just filter all SI= Rs on incoming
> > packets from the Internet.=C2=A0 They aren't legal there.=C2= =A0 And similarly,
> > if one uses LISP within the operator domain, we can block whateve= r
> > blocks we use for EIDs for such local traffic.
>
> Joel,
>
> I'm not sure I understand what "filtering SIRs from the Inter= net"
> means. A SIR address is a globally visible address for devices like UE= s. So an
> Internet sender may legitimately send packets to SIR addresses, and al= so an
> Internet attacker could easily spew a whole bunch of packets with both= spoofed
> source addresses and spoofed UE addresses. So you'd want to allow = the
> legitimate traffic but block the attacking packets-- this isn't fe= asible since it's
> impossible to distinguish the bad from the good packets.
>
> >
> > If we want to use id-locator split of any kind for handling traff= ic to
> > / from the Internet, then we have to understand how that is suppo= sed
> > to work, and why, before we need to evaluate DDOS implications of= a
> > solution.=C2=A0 For LISP,the working group has explicitly said th= at
> > Inter-wide deployment is out of scope.
> >
> > Net: I do not see in currently described deployments, an issue th= at
> > differentiates LISP from ILA in these regards.=C2=A0 And Terry ha= s very
> > clearly spelled out that for mobile operators spoofing from UEs i= s not
> > considered an issue that the infrastructure needs to deal wih. >
> But there may be a whole network infrastructure of hundreds or even > thousands of users behind a UE, and there's no guarantee that that=
> infrastructure properly supports anti-spoofing. This basically this ca= se has the
> same problem as in the Internet case.
>
> Tom
>
> >
> > Yours,
> > Joel
> >
> >
> > On 5/3/18 5:33 PM, Tom Herbert wrote:
> >>
> >> On Thu, May 3, 2018 at 2:23 PM, FIGURELLE, TERRY F <tf2934@att.com>
> wrote:
> >>>
> >>> In the case of current 3GPP operators all the major vendo= rs support
> >>> anti-spoofing. The default was on for all but one vendor = which got
> >>> corrected the last time I did an RFP for EPC. So by confi= guration
> >>> the GGSN/PGW/PGW-U/UPF will not allow=C2=A0 the UE to sen= d packets that
> >>> don't match either the exact IP address or pushed sub= net or prefix
> >>> delegation that was sent in response to the APN create me= ssage.
> >>> Obviously if we remove GTP encapsulation that protect MAY= need to be
> enhanced towards an EDGE element.
> >>>
> >> Terry,
> >>
> >> Even so, the whole Internet does not require anti-spoofing, n= or do I
> >> believe that operators could require all down stream network = that are
> >> connected to support anti-spoofing. These are where the DOS a= ttacks
> >> orginate. The problem is when caches are being driven by user= taffic
> >> from these external networks, mitigations to detect DOS by IP= source
> >> address don't work without anti-spoofing (but even if the= y had
> >> anti-spoofing that still doesn't work when under a DDOS).=
> >>
> >> Tom
> >>
> >>
> >>
> >>> This is being covered as part of our participation in an = open source
> >>> vEPC (virtualize EPC, hypervisor, blah, blah, blah). So t= here will
> >>> be a micro service firewall that can be deploy at the edg= e plus we
> >>> already have planned support for big network infrastructu= re vendors
> >>> and 3GPP supplies (Cisco, Juniper, Ericsson, Nokia, Huawe= i, ...) to
> >>> cover this. Since this can=C2=A0 be a non-3GPP element we= will get this into
> ONAP.
> >>>
> >>> Thus we have this covered both for 3GPP nodes, micro serv= ices and
> >>> open source efforts. To give examples without vendor name= s there are
> >>> GTP aware firewalls that some operators use. It really ju= st another
> >>> capability in carrier class and business class firewalls = (had to add
> >>> it to load balancers, CNAT/NAT, some Wi-Fi routers and to= our DNS
> >>> solution which uses open source).=C2=A0 Obviously this wi= ll be supported
> >>> via a RADIUS feed for backwards compatibility. Today most= GTP
> >>> firewall simply follow the GTP-C signaling to learn the I= P
> >>> address(es) assigned to the UE for an APN. If we remove G= TP from
> >>> user plane that doesn't mean we remove it from contro= l plane or for
> >>> all hops. However, we will likely push to a micro service= at the
> >>> cell plus I need to check if we ever ask RAN vendors to s= upport this. I'll add
> this for 5G but we already did that RFP so it's a change order (yu= ck).
> >>>
> >>> I am not good at wordsmithing but I suggest there be some= paragraph
> >>> that covers network elements that can except a RADIUS fee= d. I need
> >>> to talk to our standards team to see if we want this on T= 8 (probably).
> >>>
> >>> So today for all AT&T, Verizon, Vodaphone,=C2=A0 ....= . I know or am
> >>> fairly confident they have anti spoofing tuned on in the<= br> > >>> GGSN/PGW/UPF plus I know they can turn this on per APN. N= ot sure why
> >>> anyone would disable this since we if you are delegating = a subnet to
> >>> a Wi-Fi hotspot (instead of the typical private addressin= g they use).
> >>>
> >>> We actually don't need any 3GPP changes since this is= already
> >>> covered using RADIUS to pass the information where it nee= ds to go. I
> >>> suspect most will leverage their caching SPR/UDR which al= ready has
> >>> the information. Even the GGSN we launched EDGE/GPRS when= I was much
> >>> younger supported anti-spoofing and many vendors cover th= is via a
> >>> number of methods (e.g. COPS works for older junos and RA= DIUS for Cisco
> IOS releases ).
> >>>
> >>> My suggestion is that I am willing to help whoever wants = to craft
> >>> the paragraph because I suck at that (fortunately I am go= od at other
> things).
> >>>
> >>> I don't think we need any changes to any standards to= cover this
> >>> since we already cover this and already are covering this= if we
> >>> strip out GTP (at least for one leg). I'll make sure = it gets into
> >>> our RAN requirements if not there since that may be the b= est place
> >>> for that edge. Plus I'll get it covered thru the ONAP= open source
> >>> effort we drove (we donated the software to the open sour= ce effort).
> >>> That means FM, PM, CM and IM will be covered in some futu= re ONAP
> release (takes time but faster than 3GPP).
> >>>
> >>> It's a bit debatable what is RAN when using virtualiz= ed network
> >>> functions
> >>> (VNF) and a bunch of open source stuff that we put it int= o all of
> >>> the needed elements like SDN, firewall, load balancer (no= t sure
> >>> that's needed at cell site but it is for core DNS, pr= oxy-TDF and
> >>> CNAT) out at the cell site. We aren't there yet (stil= l physical
> >>> eNB/NR and obviously we need hardware assist even with > >>> virtualization plus tight control of timing). I am lookin= g forward to when we
> start using containers.
> >>>
> >>> For our core I am sure we will use our UDR VNF as the cac= he for
> >>> whatever comes out of this effort in final standards. The=
> >>> information is already there (IMEI, device vendor, subscr= iption
> >>> information, UE IP address, APN, etc.). If we do anything= it would
> >>> be to augment an open source and if needed a 3GPP. I don&= #39;t think we need
> any changes but it's always best to verify.
> >>> For current RAN an anti-spoofing feature would come from = EMS which
> >>> can be via ONAP. I don't think that is a standards ef= fort thing
> >>> since it's a feature which may or may not already be = covered but it
> >>> will be in future RAN releases probably starting with eNB= /NR with
> >>> some vendor release if it's not already a feature. I = want to say
> >>> Ericsson and Nokia already can do this in eNB but I need = to go thru
> channels to ask.
> >>>
> >>> So maybe that paragraph recommends implementing anti-spoo= fing at all
> >>> edges and leaves it at that. Or we could say all edges in= cluding RAN
> >>> if that makes people happy.
> >>>
> >>>> -----Original Message-----
> >>>> From: 5gangip <5gangip-bounces@ietf.org> On Behalf Of To= m Herbert
> >>>> Sent: Thursday, May 03, 2018 10:46 AM
> >>>> To: Dirk.von-Hugo@telekom.de
> >>>> Cc: Tom Herbert <tom@herbertland.com>; Joel M. Halpern
> >>>> <jmh@joelhalpern.com>; ila@ietf.org; Alberto Rodriguez-Natal
> >>>> <rodrigueznatal@gmail.com>; 5GANGIP <5gangip@ietf.org>
> >>>> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: P= roblem
> >>>> Statement]
> >>>>
> >>>> On Thu, May 3, 2018 at 9:23 AM,=C2=A0 <Dirk.von-Hugo@telekom.de= > wrote:
> >>>>>
> >>>>> Hi Tom,
> >>>>> I understand you correctly that DDOS attacks can = never be
> >>>>> completely
> >>>>
> >>>> prevented whatever protocol you use.
> >>>>>
> >>>>> It will however always remain related to known IP= addresses and
> >>>>> the more
> >>>>
> >>>> versatile these are handled a mitigation strategy cou= ld be designed.
> >>>>
> >>>> Dirk,
> >>>>
> >>>> I disagree. IP addresses can too easily be spoofed, i= t's easy to
> >>>> hide identity behind a NAT (see discussion about CGNA= T and law
> >>>> enforcement on int-area list), and trying to turn off= individual
> >>>> addresses doesn't work if it's a DDOS. This i= s nothing new. For
> >>>> instance, content providers have long accepted the fa= ct that they
> >>>> can't prevent SYN attacks and there's little = point to trying to go
> >>>> back to source IP address (they are always spoofed in= a SYN
> >>>> attack). The better strategy is to absorb the attack = and minimize
> >>>> the negative effects so that the attack is not worth = the effort.
> >>>>
> >>>>> As you may have seen we mention improved handling= of mapping
> >>>>> systems
> >>>>
> >>>> and subsequently of DDOS protection also in the curre= nt version of
> >>>> our PS document https://url= defense.proofpoint.com/v2/url?u=3Dhttps-
> >>>> 3A__github.com_bsarikaya_atic_blob_master_atick-=
> >>>> 5Fproblemstatement.3.txt&d=3DDwICAg&c=3D= LFYZ-
> >>>>
> o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl2paJIf4zw&m=3DzYkPItju= HMuGlJXD5K_4
> >>>> OstVOL1OQiA98fgBJ9c1Gjo&s=3DjLL_9a56R8Ic8o3u= JcR8mrF-
> >>>> JkzLL97h8rmZT_EqXnQ&e=3D=C2=A0 which Behcet has a= nnounced recently.
> >>>>>
> >>>>> May I ask you to please comment on the ideas outl= ined there?
> >>>>
> >>>>
> >>>> I don't see much difference in the latest version= . For a problem
> >>>> statement, I still think there is too much focus on t= he solutions
> >>>> and not nearly enough description of what the actual = problems are
> >>>> to be solved.
> >>>>
> >>>> Tom
> >>>>
> >>>>> Thanks!
> >>>>
> >>>>
> >>>>> Best Regards
> >>>>> Dirk
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: 5gangip [mailto:5gangip-bounces@ietf.org] On Be= half Of Tom
> >>>>> Herbert
> >>>>> Sent: Mittwoch, 2. Mai 2018 01:20
> >>>>> To: Joel M. Halpern <jmh@joelhalpern.com>
> >>>>> Cc: Tom Herbert <tom@herbertland.com>; ila@ietf.org; Alberto
> >>>>> Rodriguez-Natal <rodrigueznatal@gmail.com>; 5GANGIP<= br> > >>>>> <5gangip@ietf.org>
> >>>>> Subject: Re: [5gangip] [Ila] ILA forwaring [Was R= e: Problem
> >>>>> Statement]
> >>>>>
> >>>>> On Tue, May 1, 2018 at 3:49 PM, Joel M. Halpern > >>>>> <jmh@joelhalpern.com>
> >>>>
> >>>> wrote:
> >>>>>>
> >>>>>> You seem to be saying that even though not al= l DDOS attacks are
> >>>>>> structurally the same, and even though if ILA= were widely adopted
> >>>>>> not all ILA networks would be structurally th= e same, there should
> >>>>>> nonetheless be one required qay of handling D= DOS?
> >>>>>
> >>>>>
> >>>>> Yes, at least as core default in the protocol. It= 's precisely
> >>>>> _because_ not all
> >>>>
> >>>> DDOS attacks are structurally the same. An attacker i= s not going to
> >>>> conform to to our expectations of what they should be= doing, so if
> >>>> we enable LISP option N to mitigate one form of attac= k, they will
> >>>> just use another attack that isn't mitigated. For= example, if the
> >>>> mitigation is to identify attackers by address when r= equests from
> >>>> the address exceed a threshold then this works as lon= g as the
> >>>> attacker strikes from one machine, but it falls apart= if the
> >>>> attacker launches a DDOS attack from several hosts wh= ere requests
> >>>> from none of the hosts exceed the threshold.
> >>>>>
> >>>>>
> >>>>> The ILA model works because it assumes there is n= o absolute way to
> >>>>> prevent
> >>>>
> >>>> the the worst case attack on a cache which is to comp= letely kill it
> >>>> (i.e. drive it to 0% hit rate). In this state the beh= avior
> >>>> sub-optimal routing, which is much better than loss o= f service.
> >>>> This is not dependent on the structure of the attack,= network
> >>>> topology, or the network operator getting the configu= ration just
> >>>> right--
> >>>> it is inherent in the protocol.
> >>>>>
> >>>>>
> >>>>> Tom
> >>>>>
> >>>>>>
> >>>>>> Yours,
> >>>>>> Joel
> >>>>>>
> >>>>>>
> >>>>>> On 5/1/18 6:32 PM, Tom Herbert wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> On Tue, May 1, 2018 at 2:59 PM, Alberto R= odriguez-Natal
> >>>>>>> <rodrigueznatal@gmail.com> wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Tue, May 1, 2018 at 10:16 AM, Tom = Herbert
> <tom@herbe= rtland.com>
> >>>>
> >>>> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I think you've misunderstood = my position. Caches are _very_
> >>>>>>>>> important to eliminate the cost t= riangular routing (latency,
> >>>>>>>>> average path
> >>>>
> >>>> load).
> >>>>>>>>>
> >>>>>>>>> This reduces latency and reduces = average load on ILA-Rs. But, and
> >>>>>>>>> this is the critical part, caches= are only an _optimization_ in
> >>>>>>>>> ILA. That means if the cache is r= endered ineffective (like by a
> >>>>>>>>> well crafted DOS
> >>>>>>>>> attack) then the only effect is t= hat the optimization is loss (i.e.
> >>>>>>>>> greater latency due to triangular= router)-- this is quantitively
> >>>>>>>>> the worst effect of the attack on= an ILA cache. This can be
> >>>>>>>>> contrasted that to LISP where the= worst case effects of a DOS
> >>>>>>>>> attack on the cache is loss of se= rvice for users (infinite latency
> >>>>>>>>> since packets can be dropped or i= ndefinitely blocked on a cache
> >>>>>>>>> miss).
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> This can be misleading. This is not c= omparing LISP vs ILA, this is
> >>>>>>>> comparing the models of Request/Reply= at the edge vs Notifications
> >>>>>>>> (aka Redirects) at the core. Both LIS= P-CP and ILAMP support these
> >>>>>>>> two models.
> >>>>>>>>
> >>>>>>>> Besides, this is assuming an scenario= where the only feasible DOS
> >>>>>>>> mitigation is absorbing the attack. T= here are other scenarios where
> >>>>>>>> other countermeasures are possible. F= or instance, if you have a
> >>>>>>>> deployment where you can prevent addr= ess spoofing, counting and
> >>>>>>>> blocking misbehaving nodes offers sim= ilar DOS protection and
> >>>>>>>> requires way less infrastructure reso= urces.
> >>>>>>>>
> >>>>>>> Alberto,
> >>>>>>>
> >>>>>>> The answer to my question of how does LIS= P address DOS attacks
> seems
> >>>>>>> to be "there are many options".= Some of the options are to assume
> >>>>>>> that DOS does not exist in the network, s= ome assume external
> >>>>>>> configuration like address spoofing is en= abled, some assume that
> >>>>>>> attacks can be identified and can be stop= ped at the source, some
> >>>>>>> might assume that everything is okay beca= use there's never been a
> >>>>>>> DOS attack before. I have yet to see the = effects of any of these
> >>>>>>> quantified, and none of these state how t= he LISP _protocol_ itself
> >>>>>>> addresses DOS. It may seem counter-intuit= ive, but offering a bunch
> >>>>>>> of options really is not necessarily a go= od thing-- sometime less is
> >>>>>>> more. To put this another way LISP has be= en rejected from Linux
> >>>>>>> precisely because of its susceptibility t= o DOS. If you were to try
> >>>>>>> again and the best answer to the DOS ques= tion is that it's up to the
> >>>>>>> operator to figure out the right options = to use, then I believe it
> >>>>>>> would be soundly rejected again. That app= roach does not work at
> >>>>>>> scale.
> >>>>>>>
> >>>>>>> Tom
> >>>>>>>
> >>>>>>> ____________________________________= ___________
> >>>>>>> ila mailing list
> >>>>>>> ila@ietf.org
> >>>>>>> https://urldefe= nse.proofpoint.com/v2/url?u=3Dhttps-
> 3A__www.ietf.org_ma
> >>>>>>> ilman_listinfo_ila&d=3DDwICAg&c= =3DLFYZ-
> >>>>
> >>>> o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl
> >>>>>>>
> >>>>>>>
> >>>>
> 2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4OstVOL1OQiA98fgBJ9c1Gjo&= ;s=3DBO3snt8C
> >>>> RQ
> >>>>>>>
> >>>>>>> gy1xwhx2CY10VUbM_rgntgpV9k3-Cskd8&am= p;e=3D
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>> ____________________________________________= ___
> >>>>> 5gangip mailing list
> >>>>> 5gangip@ietf.org
> >>>>> https://urldefense.proo= fpoint.com/v2/url?u=3Dhttps-
> 3A__www.ietf.org_mail
> >>>>> man_listinfo_5gangip&d=3DDwICAg&c=3D= LFYZ-
> >>>>
> >>>> o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl
> >>>>>
> >>>>>
> >>>>
> 2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4OstVOL1OQiA98fgBJ9c1Gjo&= ;s=3DFnQLMire
> >>>> MiKC
> >>>>>
> >>>>> SkPaOGFCybzDc2i2y49Cgtbl6mCLc9c&e=3D
> >>>>
> >>>>
> >>>> _______________________________________________<= br> > >>>> 5gangip mailing list
> >>>> 5gangip@ietf.org
> >>>> https://urldefense.proofpoi= nt.com/v2/url?u=3Dhttps-
> >>>> 3A__www.ietf.org_mailman_listinfo_5gangip&d= =3DDwICAg&c=3DLFYZ-
> >>>>
> o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl2paJIf4zw&m=3DzYkPItju= HMuGlJXD5K_4
> >>>>
> OstVOL1OQiA98fgBJ9c1Gjo&s=3DFnQLMireMiKCSkPaOGFCybzDc2i2y49Cg= tbl6mC
> >>>> Lc9c&e=3D
> >>
> >>
> >
_______________________________________________
5gangip mailing list
5gangip@ietf.org<= br>
https://www.ietf.org/mailman/listinf= o/5gangip


--000000000000c3f38f056bb2d26c-- From nobody Tue May 8 10:49:19 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD68127599; Tue, 8 May 2018 10:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 smBD9ewbmgyE; Tue, 8 May 2018 10:49:05 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 92A321274D2; Tue, 8 May 2018 10:49:05 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id w48HjsTF048783; Tue, 8 May 2018 13:48:53 -0400 Received: from flpd657.enaf.ffdc.sbc.com (sbcsmtp9.sbc.com [144.160.128.153]) by m0049458.ppops.net-00191d01. with ESMTP id 2hug1as31g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 May 2018 13:48:52 -0400 Received: from enaf.ffdc.sbc.com (localhost [127.0.0.1]) by flpd657.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id w48Hmofq086505; Tue, 8 May 2018 10:48:51 -0700 Received: from zlp25944.vci.att.com (zlp25944.vci.att.com [135.213.92.140]) by flpd657.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id w48Hmkhs086423; Tue, 8 May 2018 10:48:46 -0700 Received: from zlp25944.vci.att.com (zlp25944.vci.att.com [127.0.0.1]) by zlp25944.vci.att.com (Service) with ESMTP id DA669410F455; Tue, 8 May 2018 17:48:46 +0000 (GMT) Received: from CAFRFD1MSGHUBAD.ITServices.sbc.com (unknown [130.4.169.143]) by zlp25944.vci.att.com (Service) with ESMTPS id 96D48410F440; Tue, 8 May 2018 17:48:46 +0000 (GMT) Received: from CAFRFD1MSGUSRJI.ITServices.sbc.com ([169.254.8.94]) by CAFRFD1MSGHUBAD.ITServices.sbc.com ([130.4.169.143]) with mapi id 14.03.0389.001; Tue, 8 May 2018 10:48:46 -0700 From: "FIGURELLE, TERRY F" To: Tom Herbert CC: Lorenzo Colitti , "Joel M. Halpern" , Tom Herbert , "ila@ietf.org" , 5GANGIP <5gangip@ietf.org>, Alberto Rodriguez-Natal , "Dirk.von-Hugo@telekom.de" Thread-Topic: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement] Thread-Index: AQHT4wasd9k0kyItlUiMNTfEFG8rxqQebc2ggACORwCAAANogIAAA9+A//+Ma9CAB8OaAIAAEgyA//++Jp8= Date: Tue, 8 May 2018 17:48:46 +0000 Message-ID: <55875A79-0D4A-48EF-BCA9-A7462EBE3A38@att.com> References: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> <8aee42db5f0f407c86fda881769ceb77@HE105715.emea1.cds.t-internal.com> <1AFE10CF28AE8B4C9663445736B8034D3822FAFE@CAFRFD1MSGUSRJI.ITServices.sbc.com> <0cbb9987-0b47-9428-3db7-2c9fab821268@joelhalpern.com> <1AFE10CF28AE8B4C9663445736B8034D3822FC27@CAFRFD1MSGUSRJI.ITServices.sbc.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_55875A790D4A48EFBCA9A7462EBE3A38attcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-08_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805080170 Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 17:49:12 -0000 --_000_55875A790D4A48EFBCA9A7462EBE3A38attcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Nope, we handle QUIC. Spent lots of time with Google on that one. Many peop= le here have worked at T-Mobile USA and the flip. T-Mo USA does block unsol= icited but this gets deep into the details of unsolicited and fine lines of= block or do not support or enable it to happen. T-Mobile by country does have differences. They got a lot more address spac= e from RIPE than T-Mo USA got from ARIN. So in the states they use NAPT. Th= ey do support NAT traversal but do not host TURN. If the T-Mo USA and Sprin= t deal goes through they will have some huge challenges to efficiently comb= ine things. They also use the exact same SGW/PGW vendor and hardware model as we do. So= does Verizon (Cisco ASR5500). They may still have some of the older ASR500= 0 and Verizon may too. Neither has a virtualized solution in production. We= have both Cisco and Affirmed carrying live paying production traffic. We s= topped adding hardware based solutions more than a year ago. We also have v= irtualized MME (Ericsson) since last year and Nokia is in certification tes= ting. We have virtualize most of the IMS domain and mobility systems except= RAN. We are working on RAN. We are using CUPS for launch of 5G this year. Still debating the options lo= nger term but we also need standards to make decisions. Back to unsolicited. We all support methods so traffic flows like video chat can work but key is= we all work directly with those ASP=92s (Application service providers). A= ll of us have special handling of traffic to Amazon, Apple, Google and so o= n. The difference is in the functionality, scale and number of ASP=92s supp= ort where we smoke everyone! So you can build an App for Apple iOS or Google=92s Android and it can work= well. You can also do peer-to-peer but only as long as the setup goes thru= servers that are enabled. In our case you could also use our API=92s. Mobi= le to mobile is only allowed when enabled. While unsolicited is the common term used in the mobile industry perhaps un= wanted or undesired gives a better view. User=92s don=92t want SPAM and the= y don=92t want threats (risk of device being compromised). But if they down= load and setup an App they do want that to work. It also gets to the definition of Internet. In the US very little mobile tr= affic ever goes over the =93Internet=94. It=92s all protected private netwo= rks between mobile operators and data centers. Even inside the data centers= the traffic uses servers dedicated to mobile users. Within the data center= it may go from mobile servers to non-mobile servers. We also have major hosting companies and cloud providers covered. A startup= may rent capacity from Amazon but mobile traffic goes over a protected (en= crypted) path on a private network to Amazon data centers worldwide. Same f= or most major hosting facilities worldwide. This is true for most mobile operators and often even when they don=92t kno= w it. There are some places where things are different like China. Everyone= does what they are told to do in China or you won=92t be in China. Lots of= complicated partnerships to make anything work. So your traffic is visible= to some parties when there is no other option. All of the big CDN solutions and CDN supplies work with this model. So Akam= ai for Verizon mobiles is different from Akamai on AT&T mobiles. In our cas= e this only goes to Akamai servers in AT&T hosting facilities. So for all o= f the major mobile operators in the entire Western Hemisphere. In reality i= t=92s true for all mobile operators in Western Hemisphere to any significan= t service even when they don=92t know it. It doesn=92t matter who is the lo= cal LEC or what ISP the mobile operator uses. We even protect open WiFi and I wanted to protect all mobile =93Internet se= rvices traffic=94 but that is in the future. We detect if a VPN is in use o= r if one starts to stay out of the way in the current open WiFi case. We ca= n split and run traffic from UE over one VPN while running tethered (mobile= hotspot, USB, Bluetooth) traffic outside the VPN or in a different VPN. We= even support corporate VPN so the traffic actually goes over private netwo= rk to corporate servers instead of coming in their =93Internet=94 connectio= n. You may ask about ISP peering points but in those cases for partnered conte= nt we use encryption. A company could use Level3 as an ISP then serve Inter= net content on that connection. If we don=92t have a partnership deal with = that company then traffic would be protected to our closest to content peer= ing point with Level3. Another way to say it is for the top X websites by clicks/hits, top Y sites= by volume (bytes) or top Z sites by connection for the busiest hour, busy = period, day of week, etc. for any operator you can draw a line. Above that = line the traffic is secured mobile to/from content. Below the line it may b= e secured or it may not. The rules for handling the Internet in a given country can be very complex.= In many countries you can count on one or two fingers your options as a mo= bile operator when they are not THE LEC/ISP. Sent from my iPhone On May 8, 2018, at 7:44 AM, Tom Herbert > wrote: On Tue, May 8, 2018 at 6:39 AM, Lorenzo Colitti > wrote: FWIW, I believe there are large operators that do not block unsolicited inb= ound traffic to mobile networks. One of them is T-Mobile. I should hope that a majority of access networks don't do that, lest it wou= ld be impossible to deploy new transport protocols (like QUIC for instance)= and the ossification of the Internet would be complete. Tom On Fri, May 4, 2018 at 7:53 AM, FIGURELLE, TERRY F > wrote: No. We have always block unsolicited traffic from the Internet and it is to= o complicated to discuss here. We even did this way back for CDPD. For dedicated APN's we allow the enterp= rise to tell us what rules they want to protect the mobile from their netwo= rk and what traffic to not allow from the mobile. This is one of the reason= s firewalls and CNAT cost more if they support mobility features. We spent = a lot of time working with potential vendors. Since this started with usage based rate plans for all mobile operators the= subscriber would get charged if we allowed spam from the Internet or from = other mobiles. So this has always been block and vendors have features to h= elp out in 3GPP elements. A GGSN with anti-spoofing not disabled doesn't al= low traffic to a mobile that doesn't match an entry in the flow table. We h= ave hundreds of policy rules that get enabled from the PCRF/PCF on the PGW(= PCEF)/UPF. We also enabled our proxies to be transparent proxy-TDF. That me= ans they also have policy interfaces and we do a bunch of stuff here includ= ing processing signed manifests. Plus the rules are pushed on the control p= lane not the data plane and it includes UE, RAN, SGW/PGW/UPF and if applica= ble TDF's and AS's. We can push rules to the UE that allow, (drop), route/p= ath (e.g. bearer). We even have to have some country specific treatment (a = bigger challenge we had for vehicles using our Connected Car solution like = GM OnStar). While a mobile could get hacked and it could break the flow rule treatment = some of that is down in the 3GPP chipset. But we are aware of the risk and = we have counter measures as best we can. I should point out that these flow= rules go into RAN too and rules have a direction (from UE, to UE or both). My opinion is that malware, spoofing, DOS, DDOS and any other threat is a s= erious operational issue. That is the best place to deal with it because st= andards could never keep pace. We and other operators request features from= vendors and they also come up with stuff as a value add. Simply stated the solution needs to be protected but we don't need tons of = detail in every standard. I would never say don't be concerned about something. I just don't think ev= ery standard needs details on spoofing, DOS and other threats. > -----Original Message----- > From: Tom Herbert > > Sent: Thursday, May 03, 2018 3:00 PM > To: Joel M. Halpern > > Cc: FIGURELLE, TERRY F >; Dirk.von-= Hugo@telekom.de; Tom > Herbert >; ila@ietf.org; Alberto Rodriguez-Natal > >; 5GANGIP <5ga= ngip@ietf.org> > Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement] > > On Thu, May 3, 2018 at 2:45 PM, Joel M. Halpern > > wrote: > > I am missing something in your DDOS issue. > > > > At first, I thought the real issue (which you seem to be suggesting > > here) was DDOS from the Internet, using spoofed or non-spoofed > > addresses (with bot farms, there is much less need for or relevance of > spoofing). > > > > But then I tried to map it to the cases we have for using ILA. > > The primary case I have heard about is to use ILA for UE<->UE and > > UE<->EdgeComputing traffic. If so, just filter all SIRs on incoming > > packets from the Internet. They aren't legal there. And similarly, > > if one uses LISP within the operator domain, we can block whatever > > blocks we use for EIDs for such local traffic. > > Joel, > > I'm not sure I understand what "filtering SIRs from the Internet" > means. A SIR address is a globally visible address for devices like UEs. = So an > Internet sender may legitimately send packets to SIR addresses, and also = an > Internet attacker could easily spew a whole bunch of packets with both sp= oofed > source addresses and spoofed UE addresses. So you'd want to allow the > legitimate traffic but block the attacking packets-- this isn't feasible = since it's > impossible to distinguish the bad from the good packets. > > > > > If we want to use id-locator split of any kind for handling traffic to > > / from the Internet, then we have to understand how that is supposed > > to work, and why, before we need to evaluate DDOS implications of a > > solution. For LISP,the working group has explicitly said that > > Inter-wide deployment is out of scope. > > > > Net: I do not see in currently described deployments, an issue that > > differentiates LISP from ILA in these regards. And Terry has very > > clearly spelled out that for mobile operators spoofing from UEs is not > > considered an issue that the infrastructure needs to deal wih. > > But there may be a whole network infrastructure of hundreds or even > thousands of users behind a UE, and there's no guarantee that that > infrastructure properly supports anti-spoofing. This basically this case = has the > same problem as in the Internet case. > > Tom > > > > > Yours, > > Joel > > > > > > On 5/3/18 5:33 PM, Tom Herbert wrote: > >> > >> On Thu, May 3, 2018 at 2:23 PM, FIGURELLE, TERRY F > > wrote: > >>> > >>> In the case of current 3GPP operators all the major vendors support > >>> anti-spoofing. The default was on for all but one vendor which got > >>> corrected the last time I did an RFP for EPC. So by configuration > >>> the GGSN/PGW/PGW-U/UPF will not allow the UE to send packets that > >>> don't match either the exact IP address or pushed subnet or prefix > >>> delegation that was sent in response to the APN create message. > >>> Obviously if we remove GTP encapsulation that protect MAY need to be > enhanced towards an EDGE element. > >>> > >> Terry, > >> > >> Even so, the whole Internet does not require anti-spoofing, nor do I > >> believe that operators could require all down stream network that are > >> connected to support anti-spoofing. These are where the DOS attacks > >> orginate. The problem is when caches are being driven by user taffic > >> from these external networks, mitigations to detect DOS by IP source > >> address don't work without anti-spoofing (but even if they had > >> anti-spoofing that still doesn't work when under a DDOS). > >> > >> Tom > >> > >> > >> > >>> This is being covered as part of our participation in an open source > >>> vEPC (virtualize EPC, hypervisor, blah, blah, blah). So there will > >>> be a micro service firewall that can be deploy at the edge plus we > >>> already have planned support for big network infrastructure vendors > >>> and 3GPP supplies (Cisco, Juniper, Ericsson, Nokia, Huawei, ...) to > >>> cover this. Since this can be a non-3GPP element we will get this in= to > ONAP. > >>> > >>> Thus we have this covered both for 3GPP nodes, micro services and > >>> open source efforts. To give examples without vendor names there are > >>> GTP aware firewalls that some operators use. It really just another > >>> capability in carrier class and business class firewalls (had to add > >>> it to load balancers, CNAT/NAT, some Wi-Fi routers and to our DNS > >>> solution which uses open source). Obviously this will be supported > >>> via a RADIUS feed for backwards compatibility. Today most GTP > >>> firewall simply follow the GTP-C signaling to learn the IP > >>> address(es) assigned to the UE for an APN. If we remove GTP from > >>> user plane that doesn't mean we remove it from control plane or for > >>> all hops. However, we will likely push to a micro service at the > >>> cell plus I need to check if we ever ask RAN vendors to support this.= I'll add > this for 5G but we already did that RFP so it's a change order (yuck). > >>> > >>> I am not good at wordsmithing but I suggest there be some paragraph > >>> that covers network elements that can except a RADIUS feed. I need > >>> to talk to our standards team to see if we want this on T8 (probably)= . > >>> > >>> So today for all AT&T, Verizon, Vodaphone, ..... I know or am > >>> fairly confident they have anti spoofing tuned on in the > >>> GGSN/PGW/UPF plus I know they can turn this on per APN. Not sure why > >>> anyone would disable this since we if you are delegating a subnet to > >>> a Wi-Fi hotspot (instead of the typical private addressing they use). > >>> > >>> We actually don't need any 3GPP changes since this is already > >>> covered using RADIUS to pass the information where it needs to go. I > >>> suspect most will leverage their caching SPR/UDR which already has > >>> the information. Even the GGSN we launched EDGE/GPRS when I was much > >>> younger supported anti-spoofing and many vendors cover this via a > >>> number of methods (e.g. COPS works for older junos and RADIUS for Cis= co > IOS releases ). > >>> > >>> My suggestion is that I am willing to help whoever wants to craft > >>> the paragraph because I suck at that (fortunately I am good at other > things). > >>> > >>> I don't think we need any changes to any standards to cover this > >>> since we already cover this and already are covering this if we > >>> strip out GTP (at least for one leg). I'll make sure it gets into > >>> our RAN requirements if not there since that may be the best place > >>> for that edge. Plus I'll get it covered thru the ONAP open source > >>> effort we drove (we donated the software to the open source effort). > >>> That means FM, PM, CM and IM will be covered in some future ONAP > release (takes time but faster than 3GPP). > >>> > >>> It's a bit debatable what is RAN when using virtualized network > >>> functions > >>> (VNF) and a bunch of open source stuff that we put it into all of > >>> the needed elements like SDN, firewall, load balancer (not sure > >>> that's needed at cell site but it is for core DNS, proxy-TDF and > >>> CNAT) out at the cell site. We aren't there yet (still physical > >>> eNB/NR and obviously we need hardware assist even with > >>> virtualization plus tight control of timing). I am looking forward to= when we > start using containers. > >>> > >>> For our core I am sure we will use our UDR VNF as the cache for > >>> whatever comes out of this effort in final standards. The > >>> information is already there (IMEI, device vendor, subscription > >>> information, UE IP address, APN, etc.). If we do anything it would > >>> be to augment an open source and if needed a 3GPP. I don't think we n= eed > any changes but it's always best to verify. > >>> For current RAN an anti-spoofing feature would come from EMS which > >>> can be via ONAP. I don't think that is a standards effort thing > >>> since it's a feature which may or may not already be covered but it > >>> will be in future RAN releases probably starting with eNB/NR with > >>> some vendor release if it's not already a feature. I want to say > >>> Ericsson and Nokia already can do this in eNB but I need to go thru > channels to ask. > >>> > >>> So maybe that paragraph recommends implementing anti-spoofing at all > >>> edges and leaves it at that. Or we could say all edges including RAN > >>> if that makes people happy. > >>> > >>>> -----Original Message----- > >>>> From: 5gangip <5gangip-bounces@ietf.org> On Behalf Of Tom Herbert > >>>> Sent: Thursday, May 03, 2018 10:46 AM > >>>> To: Dirk.von-Hugo@telekom.de > >>>> Cc: Tom Herbert >; J= oel M. Halpern > >>>> >; ila@ietf.org; Alberto Rodriguez-Natal > >>>> >; 5GANGIP= <5gangip@ietf.org> > >>>> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem > >>>> Statement] > >>>> > >>>> On Thu, May 3, 2018 at 9:23 AM, > wrote: > >>>>> > >>>>> Hi Tom, > >>>>> I understand you correctly that DDOS attacks can never be > >>>>> completely > >>>> > >>>> prevented whatever protocol you use. > >>>>> > >>>>> It will however always remain related to known IP addresses and > >>>>> the more > >>>> > >>>> versatile these are handled a mitigation strategy could be designed. > >>>> > >>>> Dirk, > >>>> > >>>> I disagree. IP addresses can too easily be spoofed, it's easy to > >>>> hide identity behind a NAT (see discussion about CGNAT and law > >>>> enforcement on int-area list), and trying to turn off individual > >>>> addresses doesn't work if it's a DDOS. This is nothing new. For > >>>> instance, content providers have long accepted the fact that they > >>>> can't prevent SYN attacks and there's little point to trying to go > >>>> back to source IP address (they are always spoofed in a SYN > >>>> attack). The better strategy is to absorb the attack and minimize > >>>> the negative effects so that the attack is not worth the effort. > >>>> > >>>>> As you may have seen we mention improved handling of mapping > >>>>> systems > >>>> > >>>> and subsequently of DDOS protection also in the current version of > >>>> our PS document https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > >>>> 3A__github.com_bsarikaya_atic_blob_master_atick- > >>>> 5Fproblemstatement.3.txt&d=3DDwICAg&c=3DLFYZ- > >>>> > o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4 > >>>> OstVOL1OQiA98fgBJ9c1Gjo&s=3DjLL_9a56R8Ic8o3uJcR8mrF- > >>>> JkzLL97h8rmZT_EqXnQ&e=3D which Behcet has announced recently. > >>>>> > >>>>> May I ask you to please comment on the ideas outlined there? > >>>> > >>>> > >>>> I don't see much difference in the latest version. For a problem > >>>> statement, I still think there is too much focus on the solutions > >>>> and not nearly enough description of what the actual problems are > >>>> to be solved. > >>>> > >>>> Tom > >>>> > >>>>> Thanks! > >>>> > >>>> > >>>>> Best Regards > >>>>> Dirk > >>>>> > >>>>> -----Original Message----- > >>>>> From: 5gangip [mailto:5gangip-bounces@ietf.org] On Behalf Of Tom > >>>>> Herbert > >>>>> Sent: Mittwoch, 2. Mai 2018 01:20 > >>>>> To: Joel M. Halpern > > >>>>> Cc: Tom Herbert >; = ila@ietf.org; Alberto > >>>>> Rodriguez-Natal >; 5GANGIP > >>>>> <5gangip@ietf.org> > >>>>> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem > >>>>> Statement] > >>>>> > >>>>> On Tue, May 1, 2018 at 3:49 PM, Joel M. Halpern > >>>>> > > >>>> > >>>> wrote: > >>>>>> > >>>>>> You seem to be saying that even though not all DDOS attacks are > >>>>>> structurally the same, and even though if ILA were widely adopted > >>>>>> not all ILA networks would be structurally the same, there should > >>>>>> nonetheless be one required qay of handling DDOS? > >>>>> > >>>>> > >>>>> Yes, at least as core default in the protocol. It's precisely > >>>>> _because_ not all > >>>> > >>>> DDOS attacks are structurally the same. An attacker is not going to > >>>> conform to to our expectations of what they should be doing, so if > >>>> we enable LISP option N to mitigate one form of attack, they will > >>>> just use another attack that isn't mitigated. For example, if the > >>>> mitigation is to identify attackers by address when requests from > >>>> the address exceed a threshold then this works as long as the > >>>> attacker strikes from one machine, but it falls apart if the > >>>> attacker launches a DDOS attack from several hosts where requests > >>>> from none of the hosts exceed the threshold. > >>>>> > >>>>> > >>>>> The ILA model works because it assumes there is no absolute way to > >>>>> prevent > >>>> > >>>> the the worst case attack on a cache which is to completely kill it > >>>> (i.e. drive it to 0% hit rate). In this state the behavior > >>>> sub-optimal routing, which is much better than loss of service. > >>>> This is not dependent on the structure of the attack, network > >>>> topology, or the network operator getting the configuration just > >>>> right-- > >>>> it is inherent in the protocol. > >>>>> > >>>>> > >>>>> Tom > >>>>> > >>>>>> > >>>>>> Yours, > >>>>>> Joel > >>>>>> > >>>>>> > >>>>>> On 5/1/18 6:32 PM, Tom Herbert wrote: > >>>>>>> > >>>>>>> > >>>>>>> On Tue, May 1, 2018 at 2:59 PM, Alberto Rodriguez-Natal > >>>>>>> > wrote= : > >>>>>>>> > >>>>>>>> > >>>>>>>> On Tue, May 1, 2018 at 10:16 AM, Tom Herbert > > > >>>> > >>>> wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> I think you've misunderstood my position. Caches are _very_ > >>>>>>>>> important to eliminate the cost triangular routing (latency, > >>>>>>>>> average path > >>>> > >>>> load). > >>>>>>>>> > >>>>>>>>> This reduces latency and reduces average load on ILA-Rs. But, a= nd > >>>>>>>>> this is the critical part, caches are only an _optimization_ in > >>>>>>>>> ILA. That means if the cache is rendered ineffective (like by a > >>>>>>>>> well crafted DOS > >>>>>>>>> attack) then the only effect is that the optimization is loss (= i.e. > >>>>>>>>> greater latency due to triangular router)-- this is quantitivel= y > >>>>>>>>> the worst effect of the attack on an ILA cache. This can be > >>>>>>>>> contrasted that to LISP where the worst case effects of a DOS > >>>>>>>>> attack on the cache is loss of service for users (infinite late= ncy > >>>>>>>>> since packets can be dropped or indefinitely blocked on a cache > >>>>>>>>> miss). > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> This can be misleading. This is not comparing LISP vs ILA, this = is > >>>>>>>> comparing the models of Request/Reply at the edge vs Notificatio= ns > >>>>>>>> (aka Redirects) at the core. Both LISP-CP and ILAMP support thes= e > >>>>>>>> two models. > >>>>>>>> > >>>>>>>> Besides, this is assuming an scenario where the only feasible DO= S > >>>>>>>> mitigation is absorbing the attack. There are other scenarios wh= ere > >>>>>>>> other countermeasures are possible. For instance, if you have a > >>>>>>>> deployment where you can prevent address spoofing, counting and > >>>>>>>> blocking misbehaving nodes offers similar DOS protection and > >>>>>>>> requires way less infrastructure resources. > >>>>>>>> > >>>>>>> Alberto, > >>>>>>> > >>>>>>> The answer to my question of how does LISP address DOS attacks > seems > >>>>>>> to be "there are many options". Some of the options are to assume > >>>>>>> that DOS does not exist in the network, some assume external > >>>>>>> configuration like address spoofing is enabled, some assume that > >>>>>>> attacks can be identified and can be stopped at the source, some > >>>>>>> might assume that everything is okay because there's never been a > >>>>>>> DOS attack before. I have yet to see the effects of any of these > >>>>>>> quantified, and none of these state how the LISP _protocol_ itsel= f > >>>>>>> addresses DOS. It may seem counter-intuitive, but offering a bunc= h > >>>>>>> of options really is not necessarily a good thing-- sometime less= is > >>>>>>> more. To put this another way LISP has been rejected from Linux > >>>>>>> precisely because of its susceptibility to DOS. If you were to tr= y > >>>>>>> again and the best answer to the DOS question is that it's up to = the > >>>>>>> operator to figure out the right options to use, then I believe i= t > >>>>>>> would be soundly rejected again. That approach does not work at > >>>>>>> scale. > >>>>>>> > >>>>>>> Tom > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> ila mailing list > >>>>>>> ila@ietf.org > >>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_ma > >>>>>>> ilman_listinfo_ila&d=3DDwICAg&c=3DLFYZ- > >>>> > >>>> o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl > >>>>>>> > >>>>>>> > >>>> > 2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4OstVOL1OQiA98fgBJ9c1Gjo&s=3DBO3snt8C > >>>> RQ > >>>>>>> > >>>>>>> gy1xwhx2CY10VUbM_rgntgpV9k3-Cskd8&e=3D > >>>>>>> > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 5gangip mailing list > >>>>> 5gangip@ietf.org > >>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mail > >>>>> man_listinfo_5gangip&d=3DDwICAg&c=3DLFYZ- > >>>> > >>>> o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl > >>>>> > >>>>> > >>>> > 2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4OstVOL1OQiA98fgBJ9c1Gjo&s=3DFnQLMire > >>>> MiKC > >>>>> > >>>>> SkPaOGFCybzDc2i2y49Cgtbl6mCLc9c&e=3D > >>>> > >>>> > >>>> _______________________________________________ > >>>> 5gangip mailing list > >>>> 5gangip@ietf.org > >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > >>>> 3A__www.ietf.org_mailman_listinfo_5gangip&d=3DDwICAg&c=3DLFYZ- > >>>> > o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4 > >>>> > OstVOL1OQiA98fgBJ9c1Gjo&s=3DFnQLMireMiKCSkPaOGFCybzDc2i2y49Cgtbl6mC > >>>> Lc9c&e=3D > >> > >> > > _______________________________________________ 5gangip mailing list 5gangip@ietf.org https://www.ietf.org/mailman/listinfo/5gangip --_000_55875A790D4A48EFBCA9A7462EBE3A38attcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Nope, we handle QUIC. Spent lots of time with Google on that one. Many peop= le here have worked at T-Mobile USA and the flip. T-Mo USA does block unsol= icited but this gets deep into the details of unsolicited and fine lines of= block or do not support or enable it to happen.

T-Mobile by country does have differences. They got a lot more address= space from RIPE than T-Mo USA got from ARIN. So in the states they use NAP= T. They do support NAT traversal but do not host TURN. If the T-Mo USA and = Sprint deal goes through they will have some huge challenges to efficiently combine things.

They also use the exact same SGW/PGW vendor and hardware model as we d= o. So does Verizon (Cisco ASR5500). They may still have some of the older A= SR5000 and Verizon may too. Neither has a virtualized solution in productio= n. We have both Cisco and Affirmed carrying live paying production traffic. We stopped adding hardware based = solutions more than a year ago. We also have virtualized MME (Ericsson) sin= ce last year and Nokia is in certification testing. We have virtualize most= of the IMS domain and mobility systems except RAN. We are working on RAN.

We are using CUPS for launch of 5G this year. Still debating the optio= ns longer term but we also need standards to make decisions.

Back to unsolicited.

We all support methods so traffic flows like video chat can work but k= ey is we all work directly with those ASP=92s (Application service provider= s). All of us have special handling of traffic to Amazon, Apple, Google and= so on. The difference is in the functionality, scale and number of ASP=92s support where we smoke everyone!

So you can build an App for Apple iOS or Google=92s Android and it can= work well. You can also do peer-to-peer but only as long as the setup goes= thru servers that are enabled. In our case you could also use our API=92s.= Mobile to mobile is only allowed when enabled. 

While unsolicited is the common term used in the mobile industry perha= ps unwanted or undesired gives a better view. User=92s don=92t want SPAM an= d they don=92t want threats (risk of device being compromised). But if they= download and setup an App they do want that to work.

It also gets to the definition of Internet. In the US very little mobi= le traffic ever goes over the =93Internet=94. It=92s all protected private = networks between mobile operators and data centers. Even inside the data ce= nters the traffic uses servers dedicated to mobile users. Within the data center it may go from mobile servers to n= on-mobile servers.

We also have major hosting companies and cloud providers covered. A st= artup may rent capacity from Amazon but mobile traffic goes over a protecte= d (encrypted) path on a private network to Amazon data centers worldwide. S= ame for most major hosting facilities worldwide.

This is true for most mobile operators and often even when they don=92= t know it. There are some places where things are different like China. Eve= ryone does what they are told to do in China or you won=92t be in China. Lo= ts of complicated partnerships to make anything work. So your traffic is visible to some parties when there is no= other option.

All of the big CDN solutions and CDN supplies work with this model. So= Akamai for Verizon mobiles is different from Akamai on AT&T mobiles. I= n our case this only goes to Akamai servers in AT&T hosting facilities.= So for all of the major mobile operators in the entire Western Hemisphere. In reality it=92s true for all mobile op= erators in Western Hemisphere to any significant service even when they don= =92t know it. It doesn=92t matter who is the local LEC or what ISP the mobi= le operator uses.

We even protect open WiFi and I wanted to protect all mobile =93Intern= et services traffic=94 but that is in the future. We detect if a VPN is in = use or if one starts to stay out of the way in the current open WiFi case. = We can split and run traffic from UE over one VPN while running tethered (mobile hotspot, USB, Bluetooth) traff= ic outside the VPN or in a different VPN. We even support corporate VPN so = the traffic actually goes over private network to corporate servers instead= of coming in their =93Internet=94 connection.

You may ask about ISP peering points but in those cases for partnered = content we use encryption. A company could use Level3 as an ISP then serve = Internet content on that connection. If we don=92t have a partnership deal = with that company then traffic would be protected to our closest to content peering point with Level3.

Another way to say it is for the top X websites by clicks/hits, top Y = sites by volume (bytes) or top Z sites by connection for the busiest hour, = busy period, day of week, etc. for any operator you can draw a line. Above = that line the traffic is secured mobile to/from content. Below the line it may be secured or it may not.

The rules for handling the Internet in a given country can be very com= plex. In many countries you can count on one or two fingers your options as= a mobile operator when they are not THE LEC/ISP. 

Sent from my iPhone

On May 8, 2018, at 7:44 AM, Tom Herbert <tom@quantonium.net> wrote:



On Tue, May 8, 2018 at 6:39 AM, Lorenzo Colitti = <lorenzo@google.= com> wrote:
FWIW, I believe there are large operators that do not bloc= k unsolicited inbound traffic to mobile networks. One of them is T-Mobile.<= /div>

I should hope that a majority of access networks don't do that, lest i= t would be impossible to deploy new transport protocols (like QUIC for inst= ance) and the ossification of the Internet would be complete.

Tom

On Fri, May 4, 2018 at 7:53 AM, FIGURELLE, TERRY F <tf2934@att.com&= gt; wrote:
No. We have always block unsolicited traffic from the Int= ernet and it is too complicated to discuss here.

We even did this way back for CDPD. For dedicated APN's we allow the enterp= rise to tell us what rules they want to protect the mobile from their netwo= rk and what traffic to not allow from the mobile. This is one of the reason= s firewalls and CNAT cost more if they support mobility features. We spent a lot of time working with potent= ial vendors.

Since this started with usage based rate plans for all mobile operators the= subscriber would get charged if we allowed spam from the Internet or from = other mobiles. So this has always been block and vendors have features to h= elp out in 3GPP elements. A GGSN with anti-spoofing not disabled doesn't allow traffic to a mobile that doe= sn't match an entry in the flow table. We have hundreds of policy rules tha= t get enabled from the PCRF/PCF on the PGW(PCEF)/UPF. We also enabled our p= roxies to be transparent proxy-TDF. That means they also have policy interfaces and we do a bunch of stuff her= e including processing signed manifests. Plus the rules are pushed on the c= ontrol plane not the data plane and it includes UE, RAN, SGW/PGW/UPF and if= applicable TDF's and AS's. We can push rules to the UE that allow, (drop), route/path (e.g. bearer). We even= have to have some country specific treatment (a bigger challenge we had fo= r vehicles using our Connected Car solution like GM OnStar).

While a mobile could get hacked and it could break the flow rule treatment = some of that is down in the 3GPP chipset. But we are aware of the risk and = we have counter measures as best we can. I should point out that these flow= rules go into RAN too and rules have a direction (from UE, to UE or both).

My opinion is that malware, spoofing, DOS, DDOS and any other threat is a s= erious operational issue. That is the best place to deal with it because st= andards could never keep pace. We and other operators request features from= vendors and they also come up with stuff as a value add.

Simply stated the solution needs to be protected but we don't need tons of = detail in every standard.

I would never say don't be concerned about something. I just don't think ev= ery standard needs details on spoofing, DOS and other threats.


> -----Original Message-----
> From: Tom Herbert <tom@quantonium.net>
> Sent: Thursday, May 03, 2018 3:00 PM
> To: Joel M. Halpern <jmh@joelhalpern.com>
> Cc: FIGURELLE, TERRY F <tf2934@att.com>; Dirk.von-Hugo= @telekom.de; Tom
> Herbert <t= om@herbertland.com>; ila@ietf.org; Alberto= Rodriguez-Natal
> <rodr= igueznatal@gmail.com>; 5GANGIP <5gangip@ietf.org>
> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement]=
>
> On Thu, May 3, 2018 at 2:45 PM, Joel M. Halpern <jmh@joelhalpern.com>
> wrote:
> > I am missing something in your DDOS issue.
> >
> > At first, I thought the real issue (which you seem to be suggesti= ng
> > here) was DDOS from the Internet, using spoofed or non-spoofed > > addresses (with bot farms, there is much less need for or relevan= ce of
> spoofing).
> >
> > But then I tried to map it to the cases we have for using ILA. > > The primary case I have heard about is to use ILA for UE<->= UE and
> > UE<->EdgeComputing traffic.  If so, just filter all SI= Rs on incoming
> > packets from the Internet.  They aren't legal there.  A= nd similarly,
> > if one uses LISP within the operator domain, we can block whateve= r
> > blocks we use for EIDs for such local traffic.
>
> Joel,
>
> I'm not sure I understand what "filtering SIRs from the Internet&= quot;
> means. A SIR address is a globally visible address for devices like UE= s. So an
> Internet sender may legitimately send packets to SIR addresses, and al= so an
> Internet attacker could easily spew a whole bunch of packets with both= spoofed
> source addresses and spoofed UE addresses. So you'd want to allow the<= br> > legitimate traffic but block the attacking packets-- this isn't feasib= le since it's
> impossible to distinguish the bad from the good packets.
>
> >
> > If we want to use id-locator split of any kind for handling traff= ic to
> > / from the Internet, then we have to understand how that is suppo= sed
> > to work, and why, before we need to evaluate DDOS implications of= a
> > solution.  For LISP,the working group has explicitly said th= at
> > Inter-wide deployment is out of scope.
> >
> > Net: I do not see in currently described deployments, an issue th= at
> > differentiates LISP from ILA in these regards.  And Terry ha= s very
> > clearly spelled out that for mobile operators spoofing from UEs i= s not
> > considered an issue that the infrastructure needs to deal wih. >
> But there may be a whole network infrastructure of hundreds or even > thousands of users behind a UE, and there's no guarantee that that
> infrastructure properly supports anti-spoofing. This basically this ca= se has the
> same problem as in the Internet case.
>
> Tom
>
> >
> > Yours,
> > Joel
> >
> >
> > On 5/3/18 5:33 PM, Tom Herbert wrote:
> >>
> >> On Thu, May 3, 2018 at 2:23 PM, FIGURELLE, TERRY F <tf2934@att.com>
> wrote:
> >>>
> >>> In the case of current 3GPP operators all the major vendo= rs support
> >>> anti-spoofing. The default was on for all but one vendor = which got
> >>> corrected the last time I did an RFP for EPC. So by confi= guration
> >>> the GGSN/PGW/PGW-U/UPF will not allow  the UE to sen= d packets that
> >>> don't match either the exact IP address or pushed subnet = or prefix
> >>> delegation that was sent in response to the APN create me= ssage.
> >>> Obviously if we remove GTP encapsulation that protect MAY= need to be
> enhanced towards an EDGE element.
> >>>
> >> Terry,
> >>
> >> Even so, the whole Internet does not require anti-spoofing, n= or do I
> >> believe that operators could require all down stream network = that are
> >> connected to support anti-spoofing. These are where the DOS a= ttacks
> >> orginate. The problem is when caches are being driven by user= taffic
> >> from these external networks, mitigations to detect DOS by IP= source
> >> address don't work without anti-spoofing (but even if they ha= d
> >> anti-spoofing that still doesn't work when under a DDOS).
> >>
> >> Tom
> >>
> >>
> >>
> >>> This is being covered as part of our participation in an = open source
> >>> vEPC (virtualize EPC, hypervisor, blah, blah, blah). So t= here will
> >>> be a micro service firewall that can be deploy at the edg= e plus we
> >>> already have planned support for big network infrastructu= re vendors
> >>> and 3GPP supplies (Cisco, Juniper, Ericsson, Nokia, Huawe= i, ...) to
> >>> cover this. Since this can  be a non-3GPP element we= will get this into
> ONAP.
> >>>
> >>> Thus we have this covered both for 3GPP nodes, micro serv= ices and
> >>> open source efforts. To give examples without vendor name= s there are
> >>> GTP aware firewalls that some operators use. It really ju= st another
> >>> capability in carrier class and business class firewalls = (had to add
> >>> it to load balancers, CNAT/NAT, some Wi-Fi routers and to= our DNS
> >>> solution which uses open source).  Obviously this wi= ll be supported
> >>> via a RADIUS feed for backwards compatibility. Today most= GTP
> >>> firewall simply follow the GTP-C signaling to learn the I= P
> >>> address(es) assigned to the UE for an APN. If we remove G= TP from
> >>> user plane that doesn't mean we remove it from control pl= ane or for
> >>> all hops. However, we will likely push to a micro service= at the
> >>> cell plus I need to check if we ever ask RAN vendors to s= upport this. I'll add
> this for 5G but we already did that RFP so it's a change order (yuck).=
> >>>
> >>> I am not good at wordsmithing but I suggest there be some= paragraph
> >>> that covers network elements that can except a RADIUS fee= d. I need
> >>> to talk to our standards team to see if we want this on T= 8 (probably).
> >>>
> >>> So today for all AT&T, Verizon, Vodaphone,  ....= . I know or am
> >>> fairly confident they have anti spoofing tuned on in the<= br> > >>> GGSN/PGW/UPF plus I know they can turn this on per APN. N= ot sure why
> >>> anyone would disable this since we if you are delegating = a subnet to
> >>> a Wi-Fi hotspot (instead of the typical private addressin= g they use).
> >>>
> >>> We actually don't need any 3GPP changes since this is alr= eady
> >>> covered using RADIUS to pass the information where it nee= ds to go. I
> >>> suspect most will leverage their caching SPR/UDR which al= ready has
> >>> the information. Even the GGSN we launched EDGE/GPRS when= I was much
> >>> younger supported anti-spoofing and many vendors cover th= is via a
> >>> number of methods (e.g. COPS works for older junos and RA= DIUS for Cisco
> IOS releases ).
> >>>
> >>> My suggestion is that I am willing to help whoever wants = to craft
> >>> the paragraph because I suck at that (fortunately I am go= od at other
> things).
> >>>
> >>> I don't think we need any changes to any standards to cov= er this
> >>> since we already cover this and already are covering this= if we
> >>> strip out GTP (at least for one leg). I'll make sure it g= ets into
> >>> our RAN requirements if not there since that may be the b= est place
> >>> for that edge. Plus I'll get it covered thru the ONAP ope= n source
> >>> effort we drove (we donated the software to the open sour= ce effort).
> >>> That means FM, PM, CM and IM will be covered in some futu= re ONAP
> release (takes time but faster than 3GPP).
> >>>
> >>> It's a bit debatable what is RAN when using virtualized n= etwork
> >>> functions
> >>> (VNF) and a bunch of open source stuff that we put it int= o all of
> >>> the needed elements like SDN, firewall, load balancer (no= t sure
> >>> that's needed at cell site but it is for core DNS, proxy-= TDF and
> >>> CNAT) out at the cell site. We aren't there yet (still ph= ysical
> >>> eNB/NR and obviously we need hardware assist even with > >>> virtualization plus tight control of timing). I am lookin= g forward to when we
> start using containers.
> >>>
> >>> For our core I am sure we will use our UDR VNF as the cac= he for
> >>> whatever comes out of this effort in final standards. The=
> >>> information is already there (IMEI, device vendor, subscr= iption
> >>> information, UE IP address, APN, etc.). If we do anything= it would
> >>> be to augment an open source and if needed a 3GPP. I don'= t think we need
> any changes but it's always best to verify.
> >>> For current RAN an anti-spoofing feature would come from = EMS which
> >>> can be via ONAP. I don't think that is a standards effort= thing
> >>> since it's a feature which may or may not already be cove= red but it
> >>> will be in future RAN releases probably starting with eNB= /NR with
> >>> some vendor release if it's not already a feature. I want= to say
> >>> Ericsson and Nokia already can do this in eNB but I need = to go thru
> channels to ask.
> >>>
> >>> So maybe that paragraph recommends implementing anti-spoo= fing at all
> >>> edges and leaves it at that. Or we could say all edges in= cluding RAN
> >>> if that makes people happy.
> >>>
> >>>> -----Original Message-----
> >>>> From: 5gangip <5gangip-bounces@ietf.org> On Behalf Of To= m Herbert
> >>>> Sent: Thursday, May 03, 2018 10:46 AM
> >>>> To: Dirk.von-Hugo@telekom.de
> >>>> Cc: Tom Herbert <tom@herbertland.com>; Joel M. Halpern
> >>>> <jmh@joelhalpern.com>; ila@ietf.org; Alberto= Rodriguez-Natal
> >>>> <rodrigueznatal@gmail.com>; 5GANGIP <5gangip@ietf.org>
> >>>> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: P= roblem
> >>>> Statement]
> >>>>
> >>>> On Thu, May 3, 2018 at 9:23 AM,  <Dirk.von-Hugo@telekom.de= > wrote:
> >>>>>
> >>>>> Hi Tom,
> >>>>> I understand you correctly that DDOS attacks can = never be
> >>>>> completely
> >>>>
> >>>> prevented whatever protocol you use.
> >>>>>
> >>>>> It will however always remain related to known IP= addresses and
> >>>>> the more
> >>>>
> >>>> versatile these are handled a mitigation strategy cou= ld be designed.
> >>>>
> >>>> Dirk,
> >>>>
> >>>> I disagree. IP addresses can too easily be spoofed, i= t's easy to
> >>>> hide identity behind a NAT (see discussion about CGNA= T and law
> >>>> enforcement on int-area list), and trying to turn off= individual
> >>>> addresses doesn't work if it's a DDOS. This is nothin= g new. For
> >>>> instance, content providers have long accepted the fa= ct that they
> >>>> can't prevent SYN attacks and there's little point to= trying to go
> >>>> back to source IP address (they are always spoofed in= a SYN
> >>>> attack). The better strategy is to absorb the attack = and minimize
> >>>> the negative effects so that the attack is not worth = the effort.
> >>>>
> >>>>> As you may have seen we mention improved handling= of mapping
> >>>>> systems
> >>>>
> >>>> and subsequently of DDOS protection also in the curre= nt version of
> >>>> our PS document https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
> >>>> 3A__github.com_bsarikaya_atic_blob_master_atick-=
> >>>> 5Fproblemstatement.3.txt&d=3DDwICAg&c=3D= LFYZ-
> >>>>
> o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl2paJIf4zw&m=3DzYkPItju= HMuGlJXD5K_4
> >>>> OstVOL1OQiA98fgBJ9c1Gjo&s=3DjLL_9a56R8Ic8o3u= JcR8mrF-
> >>>> JkzLL97h8rmZT_EqXnQ&e=3D  which Behcet has a= nnounced recently.
> >>>>>
> >>>>> May I ask you to please comment on the ideas outl= ined there?
> >>>>
> >>>>
> >>>> I don't see much difference in the latest version. Fo= r a problem
> >>>> statement, I still think there is too much focus on t= he solutions
> >>>> and not nearly enough description of what the actual = problems are
> >>>> to be solved.
> >>>>
> >>>> Tom
> >>>>
> >>>>> Thanks!
> >>>>
> >>>>
> >>>>> Best Regards
> >>>>> Dirk
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: 5gangip [mailto:5gangip-bounces@ietf.org] On Be= half Of Tom
> >>>>> Herbert
> >>>>> Sent: Mittwoch, 2. Mai 2018 01:20
> >>>>> To: Joel M. Halpern <jmh@joelhalpern.com>
> >>>>> Cc: Tom Herbert <tom@herbertland.com>; ila@ietf.org; Alberto=
> >>>>> Rodriguez-Natal <rodrigueznatal@gmail.com>; 5GANGIP<= br> > >>>>> <5gangip@ietf.org>
> >>>>> Subject: Re: [5gangip] [Ila] ILA forwaring [Was R= e: Problem
> >>>>> Statement]
> >>>>>
> >>>>> On Tue, May 1, 2018 at 3:49 PM, Joel M. Halpern > >>>>> <jmh@joelhalpern.com>
> >>>>
> >>>> wrote:
> >>>>>>
> >>>>>> You seem to be saying that even though not al= l DDOS attacks are
> >>>>>> structurally the same, and even though if ILA= were widely adopted
> >>>>>> not all ILA networks would be structurally th= e same, there should
> >>>>>> nonetheless be one required qay of handling D= DOS?
> >>>>>
> >>>>>
> >>>>> Yes, at least as core default in the protocol. It= 's precisely
> >>>>> _because_ not all
> >>>>
> >>>> DDOS attacks are structurally the same. An attacker i= s not going to
> >>>> conform to to our expectations of what they should be= doing, so if
> >>>> we enable LISP option N to mitigate one form of attac= k, they will
> >>>> just use another attack that isn't mitigated. For exa= mple, if the
> >>>> mitigation is to identify attackers by address when r= equests from
> >>>> the address exceed a threshold then this works as lon= g as the
> >>>> attacker strikes from one machine, but it falls apart= if the
> >>>> attacker launches a DDOS attack from several hosts wh= ere requests
> >>>> from none of the hosts exceed the threshold.
> >>>>>
> >>>>>
> >>>>> The ILA model works because it assumes there is n= o absolute way to
> >>>>> prevent
> >>>>
> >>>> the the worst case attack on a cache which is to comp= letely kill it
> >>>> (i.e. drive it to 0% hit rate). In this state the beh= avior
> >>>> sub-optimal routing, which is much better than loss o= f service.
> >>>> This is not dependent on the structure of the attack,= network
> >>>> topology, or the network operator getting the configu= ration just
> >>>> right--
> >>>> it is inherent in the protocol.
> >>>>>
> >>>>>
> >>>>> Tom
> >>>>>
> >>>>>>
> >>>>>> Yours,
> >>>>>> Joel
> >>>>>>
> >>>>>>
> >>>>>> On 5/1/18 6:32 PM, Tom Herbert wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> On Tue, May 1, 2018 at 2:59 PM, Alberto R= odriguez-Natal
> >>>>>>> <rodrigueznatal@gmail.com> wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Tue, May 1, 2018 at 10:16 AM, Tom = Herbert
> <tom@herbe= rtland.com>
> >>>>
> >>>> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I think you've misunderstood my p= osition. Caches are _very_
> >>>>>>>>> important to eliminate the cost t= riangular routing (latency,
> >>>>>>>>> average path
> >>>>
> >>>> load).
> >>>>>>>>>
> >>>>>>>>> This reduces latency and reduces = average load on ILA-Rs. But, and
> >>>>>>>>> this is the critical part, caches= are only an _optimization_ in
> >>>>>>>>> ILA. That means if the cache is r= endered ineffective (like by a
> >>>>>>>>> well crafted DOS
> >>>>>>>>> attack) then the only effect is t= hat the optimization is loss (i.e.
> >>>>>>>>> greater latency due to triangular= router)-- this is quantitively
> >>>>>>>>> the worst effect of the attack on= an ILA cache. This can be
> >>>>>>>>> contrasted that to LISP where the= worst case effects of a DOS
> >>>>>>>>> attack on the cache is loss of se= rvice for users (infinite latency
> >>>>>>>>> since packets can be dropped or i= ndefinitely blocked on a cache
> >>>>>>>>> miss).
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> This can be misleading. This is not c= omparing LISP vs ILA, this is
> >>>>>>>> comparing the models of Request/Reply= at the edge vs Notifications
> >>>>>>>> (aka Redirects) at the core. Both LIS= P-CP and ILAMP support these
> >>>>>>>> two models.
> >>>>>>>>
> >>>>>>>> Besides, this is assuming an scenario= where the only feasible DOS
> >>>>>>>> mitigation is absorbing the attack. T= here are other scenarios where
> >>>>>>>> other countermeasures are possible. F= or instance, if you have a
> >>>>>>>> deployment where you can prevent addr= ess spoofing, counting and
> >>>>>>>> blocking misbehaving nodes offers sim= ilar DOS protection and
> >>>>>>>> requires way less infrastructure reso= urces.
> >>>>>>>>
> >>>>>>> Alberto,
> >>>>>>>
> >>>>>>> The answer to my question of how does LIS= P address DOS attacks
> seems
> >>>>>>> to be "there are many options".= Some of the options are to assume
> >>>>>>> that DOS does not exist in the network, s= ome assume external
> >>>>>>> configuration like address spoofing is en= abled, some assume that
> >>>>>>> attacks can be identified and can be stop= ped at the source, some
> >>>>>>> might assume that everything is okay beca= use there's never been a
> >>>>>>> DOS attack before. I have yet to see the = effects of any of these
> >>>>>>> quantified, and none of these state how t= he LISP _protocol_ itself
> >>>>>>> addresses DOS. It may seem counter-intuit= ive, but offering a bunch
> >>>>>>> of options really is not necessarily a go= od thing-- sometime less is
> >>>>>>> more. To put this another way LISP has be= en rejected from Linux
> >>>>>>> precisely because of its susceptibility t= o DOS. If you were to try
> >>>>>>> again and the best answer to the DOS ques= tion is that it's up to the
> >>>>>>> operator to figure out the right options = to use, then I believe it
> >>>>>>> would be soundly rejected again. That app= roach does not work at
> >>>>>>> scale.
> >>>>>>>
> >>>>>>> Tom
> >>>>>>>
> >>>>>>> ____________________________________= ___________
> >>>>>>> ila mailing list
> >>>>>>> ila@ietf.org
> >>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
> 3A__www.ietf.org_ma
> >>>>>>> ilman_listinfo_ila&d=3DDwICAg&c= =3DLFYZ-
> >>>>
> >>>> o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl
> >>>>>>>
> >>>>>>>
> >>>>
> 2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4OstVOL1OQiA98fgBJ9c1Gjo&= ;s=3DBO3snt8C
> >>>> RQ
> >>>>>>>
> >>>>>>> gy1xwhx2CY10VUbM_rgntgpV9k3-Cskd8&am= p;e=3D
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>> ____________________________________________= ___
> >>>>> 5gangip mailing list
> >>>>> 5gangip@ietf.org
> >>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
> 3A__www.ietf.org_mail
> >>>>> man_listinfo_5gangip&d=3DDwICAg&c=3D= LFYZ-
> >>>>
> >>>> o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl
> >>>>>
> >>>>>
> >>>>
> 2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4OstVOL1OQiA98fgBJ9c1Gjo&= ;s=3DFnQLMire
> >>>> MiKC
> >>>>>
> >>>>> SkPaOGFCybzDc2i2y49Cgtbl6mCLc9c&e=3D
> >>>>
> >>>>
> >>>> _______________________________________________<= br> > >>>> 5gangip mailing list
> >>>> 5gangip@ietf.org
> >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
> >>>> 3A__www.ietf.org_mailman_listinfo_5gangip&d= =3DDwICAg&c=3DLFYZ-
> >>>>
> o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl2paJIf4zw&m=3DzYkPItju= HMuGlJXD5K_4
> >>>>
> OstVOL1OQiA98fgBJ9c1Gjo&s=3DFnQLMireMiKCSkPaOGFCybzDc2i2y49Cg= tbl6mC
> >>>> Lc9c&e=3D
> >>
> >>
> >
_______________________________________________
5gangip mailing list
5gangip@ietf.org<= br>
https://www.ietf.org/mailman/listinf= o/5gangip


--_000_55875A790D4A48EFBCA9A7462EBE3A38attcom_-- From nobody Wed May 9 08:08:32 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854641242F5 for ; Wed, 9 May 2018 08:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 Ao5ZEh2NVXmK for ; Wed, 9 May 2018 08:08:17 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 3914D127444 for ; Wed, 9 May 2018 08:08:17 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id f13-v6so36275174qtp.10 for ; Wed, 09 May 2018 08:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+LRO1r2PFkg7O+Pnn4YNJs+AFybMZArmVa6QJaoDJko=; b=xIVntTh17oE9m4yL9TeYcdQdX3nVwUF4j+Aoj8wdxpCt1DBegvhCCYNdA8Nc5NdTa7 TQBZNdwCz56xMeZieEhbay/hBekLqqwslMXwfh2pLF8SHYD8MNS8OquPDeJP8R14BgjE o44HvaFwu0ugkx1AOLQRlaj1Ty+rqYkKCDbwqLnmIErVn4YJkrC3XWLSiYJB9bANPX8H xkCLRsWLiIRdGdbsZbaHsM3nE4hgV3xWVbrpxd91i+PgMg5Aclqk/XZccXzgX42EIoGQ L8R08IZUFIse3FgiLmDvcQ9mkOWlrn4vqu0I5PMOAl0N5tw71YaW3Wu5qgcovSLqEWNU 0i1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=+LRO1r2PFkg7O+Pnn4YNJs+AFybMZArmVa6QJaoDJko=; b=gYmRm51v2WwrUo5hs3R7HLgMQUwQAQ+FrJOhk8ROUJC8EPqB3QTmXgb9C4QasbOuy8 9+KlKpfWxBu1U+ZAgoxYeOANeXaQ4QHOy4eTpmPnMmyeqz8LkWoh20bkiyF6B3a4Oujg fp6XNcESUwqIGluBkjsaxXIzJKIWeuIGZ6dUCbJo6qD9uTpruPlzkDcH37gOHzQ6gMJe 6VfhUutFQijjKjskHP7I+DPAy2zsisKm5J7TKBgNgjvYFHmyTeWdwovZnt4UJMk9mRKn htYD200WEWxbD8Bcritc3y7/TZzA+r7m+kXyqq4SqGYq4pgH+hPLdQ1JuQavXbEOnQVe 0jKw== X-Gm-Message-State: ALQs6tAKVC5J3fCAHRK+uuqZt48iRFoUNXJHYRXzs7kQv5O0ZBCrVTNv RvyfLOepL50oYmzoEGy2WVLpMl+d2awcYc9WjCeCOw== X-Google-Smtp-Source: AB8JxZoxna1CxDkxtSsTJ2it7rZZDUKKT7GyRxQWLr0qzXemhleCPHMiGraOCaQ+w4VprvLPuQ6ebq5XucGAOOu2otM= X-Received: by 2002:ac8:321a:: with SMTP id x26-v6mr41683423qta.130.1525878495638; Wed, 09 May 2018 08:08:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.48.66 with HTTP; Wed, 9 May 2018 08:08:15 -0700 (PDT) In-Reply-To: <55875A79-0D4A-48EF-BCA9-A7462EBE3A38@att.com> References: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> <8aee42db5f0f407c86fda881769ceb77@HE105715.emea1.cds.t-internal.com> <1AFE10CF28AE8B4C9663445736B8034D3822FAFE@CAFRFD1MSGUSRJI.ITServices.sbc.com> <0cbb9987-0b47-9428-3db7-2c9fab821268@joelhalpern.com> <1AFE10CF28AE8B4C9663445736B8034D3822FC27@CAFRFD1MSGUSRJI.ITServices.sbc.com> <55875A79-0D4A-48EF-BCA9-A7462EBE3A38@att.com> From: Tom Herbert Date: Wed, 9 May 2018 08:08:15 -0700 Message-ID: To: "FIGURELLE, TERRY F" Cc: Tom Herbert , Lorenzo Colitti , "Joel M. Halpern" , "ila@ietf.org" , 5GANGIP <5gangip@ietf.org>, Alberto Rodriguez-Natal , "Dirk.von-Hugo@telekom.de" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 15:08:22 -0000 On Tue, May 8, 2018 at 10:48 AM, FIGURELLE, TERRY F wrote: > Nope, we handle QUIC. Spent lots of time with Google on that one. Many Terry, QUIC was only an example. I'm am concerned with the next QUIC, next real time gaming protocol, next application protocol that might benefit from a different transport. There's no reason to believe that QUIC and TCP constitutent the complete set of transport protocols that we'll ever need and that those are the only ones we should be allowed to use on the Internet. NATPT and proxies enforce their concept as to what transport protocols are allowed. Proxies introduce the addional complexity in that they make it harder to deploy new options and make it impossible to use end to end transport header authentication. This is why protocols like ILA are explicitily independent of transport layer. They don't require DPI, they don't require flow state to be tracked in the network, and they don't require packets of a flow to always hit the same devices in the network. They can however solve problems at the network layer (the aforementioned privacy in addressing for example). Tom > people here have worked at T-Mobile USA and the flip. T-Mo USA does block > unsolicited but this gets deep into the details of unsolicited and fine > lines of block or do not support or enable it to happen. > > T-Mobile by country does have differences. They got a lot more address sp= ace > from RIPE than T-Mo USA got from ARIN. So in the states they use NAPT. Th= ey > do support NAT traversal but do not host TURN. If the T-Mo USA and Sprint > deal goes through they will have some huge challenges to efficiently comb= ine > things. > > They also use the exact same SGW/PGW vendor and hardware model as we do. = So > does Verizon (Cisco ASR5500). They may still have some of the older ASR50= 00 > and Verizon may too. Neither has a virtualized solution in production. We > have both Cisco and Affirmed carrying live paying production traffic. We > stopped adding hardware based solutions more than a year ago. We also hav= e > virtualized MME (Ericsson) since last year and Nokia is in certification > testing. We have virtualize most of the IMS domain and mobility systems > except RAN. We are working on RAN. > > We are using CUPS for launch of 5G this year. Still debating the options > longer term but we also need standards to make decisions. > > Back to unsolicited. > > We all support methods so traffic flows like video chat can work but key = is > we all work directly with those ASP=E2=80=99s (Application service provid= ers). All > of us have special handling of traffic to Amazon, Apple, Google and so on= . > The difference is in the functionality, scale and number of ASP=E2=80=99s= support > where we smoke everyone! > > So you can build an App for Apple iOS or Google=E2=80=99s Android and it = can work > well. You can also do peer-to-peer but only as long as the setup goes thr= u > servers that are enabled. In our case you could also use our API=E2=80=99= s. Mobile > to mobile is only allowed when enabled. > > While unsolicited is the common term used in the mobile industry perhaps > unwanted or undesired gives a better view. User=E2=80=99s don=E2=80=99t w= ant SPAM and they > don=E2=80=99t want threats (risk of device being compromised). But if the= y download > and setup an App they do want that to work. > > It also gets to the definition of Internet. In the US very little mobile > traffic ever goes over the =E2=80=9CInternet=E2=80=9D. It=E2=80=99s all p= rotected private networks > between mobile operators and data centers. Even inside the data centers t= he > traffic uses servers dedicated to mobile users. Within the data center it > may go from mobile servers to non-mobile servers. > > We also have major hosting companies and cloud providers covered. A start= up > may rent capacity from Amazon but mobile traffic goes over a protected > (encrypted) path on a private network to Amazon data centers worldwide. S= ame > for most major hosting facilities worldwide. > > This is true for most mobile operators and often even when they don=E2=80= =99t know > it. There are some places where things are different like China. Everyone > does what they are told to do in China or you won=E2=80=99t be in China. = Lots of > complicated partnerships to make anything work. So your traffic is visibl= e > to some parties when there is no other option. > > All of the big CDN solutions and CDN supplies work with this model. So > Akamai for Verizon mobiles is different from Akamai on AT&T mobiles. In o= ur > case this only goes to Akamai servers in AT&T hosting facilities. So for = all > of the major mobile operators in the entire Western Hemisphere. In realit= y > it=E2=80=99s true for all mobile operators in Western Hemisphere to any s= ignificant > service even when they don=E2=80=99t know it. It doesn=E2=80=99t matter w= ho is the local LEC > or what ISP the mobile operator uses. > > We even protect open WiFi and I wanted to protect all mobile =E2=80=9CInt= ernet > services traffic=E2=80=9D but that is in the future. We detect if a VPN i= s in use or > if one starts to stay out of the way in the current open WiFi case. We ca= n > split and run traffic from UE over one VPN while running tethered (mobile > hotspot, USB, Bluetooth) traffic outside the VPN or in a different VPN. W= e > even support corporate VPN so the traffic actually goes over private netw= ork > to corporate servers instead of coming in their =E2=80=9CInternet=E2=80= =9D connection. > > You may ask about ISP peering points but in those cases for partnered > content we use encryption. A company could use Level3 as an ISP then serv= e > Internet content on that connection. If we don=E2=80=99t have a partnersh= ip deal > with that company then traffic would be protected to our closest to conte= nt > peering point with Level3. > > Another way to say it is for the top X websites by clicks/hits, top Y sit= es > by volume (bytes) or top Z sites by connection for the busiest hour, busy > period, day of week, etc. for any operator you can draw a line. Above tha= t > line the traffic is secured mobile to/from content. Below the line it may= be > secured or it may not. > > The rules for handling the Internet in a given country can be very comple= x. > In many countries you can count on one or two fingers your options as a > mobile operator when they are not THE LEC/ISP. > > Sent from my iPhone > > On May 8, 2018, at 7:44 AM, Tom Herbert wrote: > > > > On Tue, May 8, 2018 at 6:39 AM, Lorenzo Colitti wrot= e: >> >> FWIW, I believe there are large operators that do not block unsolicited >> inbound traffic to mobile networks. One of them is T-Mobile. >> > I should hope that a majority of access networks don't do that, lest it > would be impossible to deploy new transport protocols (like QUIC for > instance) and the ossification of the Internet would be complete. > > Tom > >> On Fri, May 4, 2018 at 7:53 AM, FIGURELLE, TERRY F wrot= e: >>> >>> No. We have always block unsolicited traffic from the Internet and it i= s >>> too complicated to discuss here. >>> >>> We even did this way back for CDPD. For dedicated APN's we allow the >>> enterprise to tell us what rules they want to protect the mobile from t= heir >>> network and what traffic to not allow from the mobile. This is one of t= he >>> reasons firewalls and CNAT cost more if they support mobility features.= We >>> spent a lot of time working with potential vendors. >>> >>> Since this started with usage based rate plans for all mobile operators >>> the subscriber would get charged if we allowed spam from the Internet o= r >>> from other mobiles. So this has always been block and vendors have feat= ures >>> to help out in 3GPP elements. A GGSN with anti-spoofing not disabled do= esn't >>> allow traffic to a mobile that doesn't match an entry in the flow table= . We >>> have hundreds of policy rules that get enabled from the PCRF/PCF on the >>> PGW(PCEF)/UPF. We also enabled our proxies to be transparent proxy-TDF.= That >>> means they also have policy interfaces and we do a bunch of stuff here >>> including processing signed manifests. Plus the rules are pushed on the >>> control plane not the data plane and it includes UE, RAN, SGW/PGW/UPF a= nd if >>> applicable TDF's and AS's. We can push rules to the UE that allow, (dro= p), >>> route/path (e.g. bearer). We even have to have some country specific >>> treatment (a bigger challenge we had for vehicles using our Connected C= ar >>> solution like GM OnStar). >>> >>> While a mobile could get hacked and it could break the flow rule >>> treatment some of that is down in the 3GPP chipset. But we are aware of= the >>> risk and we have counter measures as best we can. I should point out th= at >>> these flow rules go into RAN too and rules have a direction (from UE, t= o UE >>> or both). >>> >>> My opinion is that malware, spoofing, DOS, DDOS and any other threat is= a >>> serious operational issue. That is the best place to deal with it becau= se >>> standards could never keep pace. We and other operators request feature= s >>> from vendors and they also come up with stuff as a value add. >>> >>> Simply stated the solution needs to be protected but we don't need tons >>> of detail in every standard. >>> >>> I would never say don't be concerned about something. I just don't thin= k >>> every standard needs details on spoofing, DOS and other threats. >>> >>> >>> > -----Original Message----- >>> > From: Tom Herbert >>> > Sent: Thursday, May 03, 2018 3:00 PM >>> > To: Joel M. Halpern >>> > Cc: FIGURELLE, TERRY F ; Dirk.von-Hugo@telekom.de; To= m >>> > Herbert ; ila@ietf.org; Alberto Rodriguez-Natal >>> > ; 5GANGIP <5gangip@ietf.org> >>> > Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement= ] >>> > >>> > On Thu, May 3, 2018 at 2:45 PM, Joel M. Halpern >>> > wrote: >>> > > I am missing something in your DDOS issue. >>> > > >>> > > At first, I thought the real issue (which you seem to be suggesting >>> > > here) was DDOS from the Internet, using spoofed or non-spoofed >>> > > addresses (with bot farms, there is much less need for or relevance >>> > > of >>> > spoofing). >>> > > >>> > > But then I tried to map it to the cases we have for using ILA. >>> > > The primary case I have heard about is to use ILA for UE<->UE and >>> > > UE<->EdgeComputing traffic. If so, just filter all SIRs on incomin= g >>> > > packets from the Internet. They aren't legal there. And similarly= , >>> > > if one uses LISP within the operator domain, we can block whatever >>> > > blocks we use for EIDs for such local traffic. >>> > >>> > Joel, >>> > >>> > I'm not sure I understand what "filtering SIRs from the Internet" >>> > means. A SIR address is a globally visible address for devices like >>> > UEs. So an >>> > Internet sender may legitimately send packets to SIR addresses, and >>> > also an >>> > Internet attacker could easily spew a whole bunch of packets with bot= h >>> > spoofed >>> > source addresses and spoofed UE addresses. So you'd want to allow the >>> > legitimate traffic but block the attacking packets-- this isn't >>> > feasible since it's >>> > impossible to distinguish the bad from the good packets. >>> > >>> > > >>> > > If we want to use id-locator split of any kind for handling traffic >>> > > to >>> > > / from the Internet, then we have to understand how that is suppose= d >>> > > to work, and why, before we need to evaluate DDOS implications of a >>> > > solution. For LISP,the working group has explicitly said that >>> > > Inter-wide deployment is out of scope. >>> > > >>> > > Net: I do not see in currently described deployments, an issue that >>> > > differentiates LISP from ILA in these regards. And Terry has very >>> > > clearly spelled out that for mobile operators spoofing from UEs is >>> > > not >>> > > considered an issue that the infrastructure needs to deal wih. >>> > >>> > But there may be a whole network infrastructure of hundreds or even >>> > thousands of users behind a UE, and there's no guarantee that that >>> > infrastructure properly supports anti-spoofing. This basically this >>> > case has the >>> > same problem as in the Internet case. >>> > >>> > Tom >>> > >>> > > >>> > > Yours, >>> > > Joel >>> > > >>> > > >>> > > On 5/3/18 5:33 PM, Tom Herbert wrote: >>> > >> >>> > >> On Thu, May 3, 2018 at 2:23 PM, FIGURELLE, TERRY F >>> > wrote: >>> > >>> >>> > >>> In the case of current 3GPP operators all the major vendors suppo= rt >>> > >>> anti-spoofing. The default was on for all but one vendor which go= t >>> > >>> corrected the last time I did an RFP for EPC. So by configuration >>> > >>> the GGSN/PGW/PGW-U/UPF will not allow the UE to send packets tha= t >>> > >>> don't match either the exact IP address or pushed subnet or prefi= x >>> > >>> delegation that was sent in response to the APN create message. >>> > >>> Obviously if we remove GTP encapsulation that protect MAY need to >>> > >>> be >>> > enhanced towards an EDGE element. >>> > >>> >>> > >> Terry, >>> > >> >>> > >> Even so, the whole Internet does not require anti-spoofing, nor do= I >>> > >> believe that operators could require all down stream network that >>> > >> are >>> > >> connected to support anti-spoofing. These are where the DOS attack= s >>> > >> orginate. The problem is when caches are being driven by user taff= ic >>> > >> from these external networks, mitigations to detect DOS by IP sour= ce >>> > >> address don't work without anti-spoofing (but even if they had >>> > >> anti-spoofing that still doesn't work when under a DDOS). >>> > >> >>> > >> Tom >>> > >> >>> > >> >>> > >> >>> > >>> This is being covered as part of our participation in an open >>> > >>> source >>> > >>> vEPC (virtualize EPC, hypervisor, blah, blah, blah). So there wil= l >>> > >>> be a micro service firewall that can be deploy at the edge plus w= e >>> > >>> already have planned support for big network infrastructure vendo= rs >>> > >>> and 3GPP supplies (Cisco, Juniper, Ericsson, Nokia, Huawei, ...) = to >>> > >>> cover this. Since this can be a non-3GPP element we will get thi= s >>> > >>> into >>> > ONAP. >>> > >>> >>> > >>> Thus we have this covered both for 3GPP nodes, micro services and >>> > >>> open source efforts. To give examples without vendor names there >>> > >>> are >>> > >>> GTP aware firewalls that some operators use. It really just anoth= er >>> > >>> capability in carrier class and business class firewalls (had to >>> > >>> add >>> > >>> it to load balancers, CNAT/NAT, some Wi-Fi routers and to our DNS >>> > >>> solution which uses open source). Obviously this will be support= ed >>> > >>> via a RADIUS feed for backwards compatibility. Today most GTP >>> > >>> firewall simply follow the GTP-C signaling to learn the IP >>> > >>> address(es) assigned to the UE for an APN. If we remove GTP from >>> > >>> user plane that doesn't mean we remove it from control plane or f= or >>> > >>> all hops. However, we will likely push to a micro service at the >>> > >>> cell plus I need to check if we ever ask RAN vendors to support >>> > >>> this. I'll add >>> > this for 5G but we already did that RFP so it's a change order (yuck)= . >>> > >>> >>> > >>> I am not good at wordsmithing but I suggest there be some paragra= ph >>> > >>> that covers network elements that can except a RADIUS feed. I nee= d >>> > >>> to talk to our standards team to see if we want this on T8 >>> > >>> (probably). >>> > >>> >>> > >>> So today for all AT&T, Verizon, Vodaphone, ..... I know or am >>> > >>> fairly confident they have anti spoofing tuned on in the >>> > >>> GGSN/PGW/UPF plus I know they can turn this on per APN. Not sure >>> > >>> why >>> > >>> anyone would disable this since we if you are delegating a subnet >>> > >>> to >>> > >>> a Wi-Fi hotspot (instead of the typical private addressing they >>> > >>> use). >>> > >>> >>> > >>> We actually don't need any 3GPP changes since this is already >>> > >>> covered using RADIUS to pass the information where it needs to go= . >>> > >>> I >>> > >>> suspect most will leverage their caching SPR/UDR which already ha= s >>> > >>> the information. Even the GGSN we launched EDGE/GPRS when I was >>> > >>> much >>> > >>> younger supported anti-spoofing and many vendors cover this via a >>> > >>> number of methods (e.g. COPS works for older junos and RADIUS for >>> > >>> Cisco >>> > IOS releases ). >>> > >>> >>> > >>> My suggestion is that I am willing to help whoever wants to craft >>> > >>> the paragraph because I suck at that (fortunately I am good at >>> > >>> other >>> > things). >>> > >>> >>> > >>> I don't think we need any changes to any standards to cover this >>> > >>> since we already cover this and already are covering this if we >>> > >>> strip out GTP (at least for one leg). I'll make sure it gets into >>> > >>> our RAN requirements if not there since that may be the best plac= e >>> > >>> for that edge. Plus I'll get it covered thru the ONAP open source >>> > >>> effort we drove (we donated the software to the open source >>> > >>> effort). >>> > >>> That means FM, PM, CM and IM will be covered in some future ONAP >>> > release (takes time but faster than 3GPP). >>> > >>> >>> > >>> It's a bit debatable what is RAN when using virtualized network >>> > >>> functions >>> > >>> (VNF) and a bunch of open source stuff that we put it into all of >>> > >>> the needed elements like SDN, firewall, load balancer (not sure >>> > >>> that's needed at cell site but it is for core DNS, proxy-TDF and >>> > >>> CNAT) out at the cell site. We aren't there yet (still physical >>> > >>> eNB/NR and obviously we need hardware assist even with >>> > >>> virtualization plus tight control of timing). I am looking forwar= d >>> > >>> to when we >>> > start using containers. >>> > >>> >>> > >>> For our core I am sure we will use our UDR VNF as the cache for >>> > >>> whatever comes out of this effort in final standards. The >>> > >>> information is already there (IMEI, device vendor, subscription >>> > >>> information, UE IP address, APN, etc.). If we do anything it woul= d >>> > >>> be to augment an open source and if needed a 3GPP. I don't think = we >>> > >>> need >>> > any changes but it's always best to verify. >>> > >>> For current RAN an anti-spoofing feature would come from EMS whic= h >>> > >>> can be via ONAP. I don't think that is a standards effort thing >>> > >>> since it's a feature which may or may not already be covered but = it >>> > >>> will be in future RAN releases probably starting with eNB/NR with >>> > >>> some vendor release if it's not already a feature. I want to say >>> > >>> Ericsson and Nokia already can do this in eNB but I need to go th= ru >>> > channels to ask. >>> > >>> >>> > >>> So maybe that paragraph recommends implementing anti-spoofing at >>> > >>> all >>> > >>> edges and leaves it at that. Or we could say all edges including >>> > >>> RAN >>> > >>> if that makes people happy. >>> > >>> >>> > >>>> -----Original Message----- >>> > >>>> From: 5gangip <5gangip-bounces@ietf.org> On Behalf Of Tom Herber= t >>> > >>>> Sent: Thursday, May 03, 2018 10:46 AM >>> > >>>> To: Dirk.von-Hugo@telekom.de >>> > >>>> Cc: Tom Herbert ; Joel M. Halpern >>> > >>>> ; ila@ietf.org; Alberto Rodriguez-Natal >>> > >>>> ; 5GANGIP <5gangip@ietf.org> >>> > >>>> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem >>> > >>>> Statement] >>> > >>>> >>> > >>>> On Thu, May 3, 2018 at 9:23 AM, wrot= e: >>> > >>>>> >>> > >>>>> Hi Tom, >>> > >>>>> I understand you correctly that DDOS attacks can never be >>> > >>>>> completely >>> > >>>> >>> > >>>> prevented whatever protocol you use. >>> > >>>>> >>> > >>>>> It will however always remain related to known IP addresses and >>> > >>>>> the more >>> > >>>> >>> > >>>> versatile these are handled a mitigation strategy could be >>> > >>>> designed. >>> > >>>> >>> > >>>> Dirk, >>> > >>>> >>> > >>>> I disagree. IP addresses can too easily be spoofed, it's easy to >>> > >>>> hide identity behind a NAT (see discussion about CGNAT and law >>> > >>>> enforcement on int-area list), and trying to turn off individual >>> > >>>> addresses doesn't work if it's a DDOS. This is nothing new. For >>> > >>>> instance, content providers have long accepted the fact that the= y >>> > >>>> can't prevent SYN attacks and there's little point to trying to = go >>> > >>>> back to source IP address (they are always spoofed in a SYN >>> > >>>> attack). The better strategy is to absorb the attack and minimiz= e >>> > >>>> the negative effects so that the attack is not worth the effort. >>> > >>>> >>> > >>>>> As you may have seen we mention improved handling of mapping >>> > >>>>> systems >>> > >>>> >>> > >>>> and subsequently of DDOS protection also in the current version = of >>> > >>>> our PS document https://urldefense.proofpoint.com/v2/url?u=3Dhtt= ps- >>> > >>>> 3A__github.com_bsarikaya_atic_blob_master_atick- >>> > >>>> 5Fproblemstatement.3.txt&d=3DDwICAg&c=3DLFYZ- >>> > >>>> >>> > o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4 >>> > >>>> OstVOL1OQiA98fgBJ9c1Gjo&s=3DjLL_9a56R8Ic8o3uJcR8mrF- >>> > >>>> JkzLL97h8rmZT_EqXnQ&e=3D which Behcet has announced recently. >>> > >>>>> >>> > >>>>> May I ask you to please comment on the ideas outlined there? >>> > >>>> >>> > >>>> >>> > >>>> I don't see much difference in the latest version. For a problem >>> > >>>> statement, I still think there is too much focus on the solution= s >>> > >>>> and not nearly enough description of what the actual problems ar= e >>> > >>>> to be solved. >>> > >>>> >>> > >>>> Tom >>> > >>>> >>> > >>>>> Thanks! >>> > >>>> >>> > >>>> >>> > >>>>> Best Regards >>> > >>>>> Dirk >>> > >>>>> >>> > >>>>> -----Original Message----- >>> > >>>>> From: 5gangip [mailto:5gangip-bounces@ietf.org] On Behalf Of To= m >>> > >>>>> Herbert >>> > >>>>> Sent: Mittwoch, 2. Mai 2018 01:20 >>> > >>>>> To: Joel M. Halpern >>> > >>>>> Cc: Tom Herbert ; ila@ietf.org; Alberto >>> > >>>>> Rodriguez-Natal ; 5GANGIP >>> > >>>>> <5gangip@ietf.org> >>> > >>>>> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem >>> > >>>>> Statement] >>> > >>>>> >>> > >>>>> On Tue, May 1, 2018 at 3:49 PM, Joel M. Halpern >>> > >>>>> >>> > >>>> >>> > >>>> wrote: >>> > >>>>>> >>> > >>>>>> You seem to be saying that even though not all DDOS attacks ar= e >>> > >>>>>> structurally the same, and even though if ILA were widely >>> > >>>>>> adopted >>> > >>>>>> not all ILA networks would be structurally the same, there >>> > >>>>>> should >>> > >>>>>> nonetheless be one required qay of handling DDOS? >>> > >>>>> >>> > >>>>> >>> > >>>>> Yes, at least as core default in the protocol. It's precisely >>> > >>>>> _because_ not all >>> > >>>> >>> > >>>> DDOS attacks are structurally the same. An attacker is not going >>> > >>>> to >>> > >>>> conform to to our expectations of what they should be doing, so = if >>> > >>>> we enable LISP option N to mitigate one form of attack, they wil= l >>> > >>>> just use another attack that isn't mitigated. For example, if th= e >>> > >>>> mitigation is to identify attackers by address when requests fro= m >>> > >>>> the address exceed a threshold then this works as long as the >>> > >>>> attacker strikes from one machine, but it falls apart if the >>> > >>>> attacker launches a DDOS attack from several hosts where request= s >>> > >>>> from none of the hosts exceed the threshold. >>> > >>>>> >>> > >>>>> >>> > >>>>> The ILA model works because it assumes there is no absolute way >>> > >>>>> to >>> > >>>>> prevent >>> > >>>> >>> > >>>> the the worst case attack on a cache which is to completely kill >>> > >>>> it >>> > >>>> (i.e. drive it to 0% hit rate). In this state the behavior >>> > >>>> sub-optimal routing, which is much better than loss of service. >>> > >>>> This is not dependent on the structure of the attack, network >>> > >>>> topology, or the network operator getting the configuration just >>> > >>>> right-- >>> > >>>> it is inherent in the protocol. >>> > >>>>> >>> > >>>>> >>> > >>>>> Tom >>> > >>>>> >>> > >>>>>> >>> > >>>>>> Yours, >>> > >>>>>> Joel >>> > >>>>>> >>> > >>>>>> >>> > >>>>>> On 5/1/18 6:32 PM, Tom Herbert wrote: >>> > >>>>>>> >>> > >>>>>>> >>> > >>>>>>> On Tue, May 1, 2018 at 2:59 PM, Alberto Rodriguez-Natal >>> > >>>>>>> wrote: >>> > >>>>>>>> >>> > >>>>>>>> >>> > >>>>>>>> On Tue, May 1, 2018 at 10:16 AM, Tom Herbert >>> > >>> > >>>> >>> > >>>> wrote: >>> > >>>>>>>>> >>> > >>>>>>>>> >>> > >>>>>>>>> >>> > >>>>>>>>> I think you've misunderstood my position. Caches are _very_ >>> > >>>>>>>>> important to eliminate the cost triangular routing (latency= , >>> > >>>>>>>>> average path >>> > >>>> >>> > >>>> load). >>> > >>>>>>>>> >>> > >>>>>>>>> This reduces latency and reduces average load on ILA-Rs. Bu= t, >>> > >>>>>>>>> and >>> > >>>>>>>>> this is the critical part, caches are only an _optimization= _ >>> > >>>>>>>>> in >>> > >>>>>>>>> ILA. That means if the cache is rendered ineffective (like = by >>> > >>>>>>>>> a >>> > >>>>>>>>> well crafted DOS >>> > >>>>>>>>> attack) then the only effect is that the optimization is lo= ss >>> > >>>>>>>>> (i.e. >>> > >>>>>>>>> greater latency due to triangular router)-- this is >>> > >>>>>>>>> quantitively >>> > >>>>>>>>> the worst effect of the attack on an ILA cache. This can be >>> > >>>>>>>>> contrasted that to LISP where the worst case effects of a D= OS >>> > >>>>>>>>> attack on the cache is loss of service for users (infinite >>> > >>>>>>>>> latency >>> > >>>>>>>>> since packets can be dropped or indefinitely blocked on a >>> > >>>>>>>>> cache >>> > >>>>>>>>> miss). >>> > >>>>>>>> >>> > >>>>>>>> >>> > >>>>>>>> >>> > >>>>>>>> >>> > >>>>>>>> This can be misleading. This is not comparing LISP vs ILA, >>> > >>>>>>>> this is >>> > >>>>>>>> comparing the models of Request/Reply at the edge vs >>> > >>>>>>>> Notifications >>> > >>>>>>>> (aka Redirects) at the core. Both LISP-CP and ILAMP support >>> > >>>>>>>> these >>> > >>>>>>>> two models. >>> > >>>>>>>> >>> > >>>>>>>> Besides, this is assuming an scenario where the only feasibl= e >>> > >>>>>>>> DOS >>> > >>>>>>>> mitigation is absorbing the attack. There are other scenario= s >>> > >>>>>>>> where >>> > >>>>>>>> other countermeasures are possible. For instance, if you hav= e >>> > >>>>>>>> a >>> > >>>>>>>> deployment where you can prevent address spoofing, counting >>> > >>>>>>>> and >>> > >>>>>>>> blocking misbehaving nodes offers similar DOS protection and >>> > >>>>>>>> requires way less infrastructure resources. >>> > >>>>>>>> >>> > >>>>>>> Alberto, >>> > >>>>>>> >>> > >>>>>>> The answer to my question of how does LISP address DOS attack= s >>> > seems >>> > >>>>>>> to be "there are many options". Some of the options are to >>> > >>>>>>> assume >>> > >>>>>>> that DOS does not exist in the network, some assume external >>> > >>>>>>> configuration like address spoofing is enabled, some assume >>> > >>>>>>> that >>> > >>>>>>> attacks can be identified and can be stopped at the source, >>> > >>>>>>> some >>> > >>>>>>> might assume that everything is okay because there's never be= en >>> > >>>>>>> a >>> > >>>>>>> DOS attack before. I have yet to see the effects of any of >>> > >>>>>>> these >>> > >>>>>>> quantified, and none of these state how the LISP _protocol_ >>> > >>>>>>> itself >>> > >>>>>>> addresses DOS. It may seem counter-intuitive, but offering a >>> > >>>>>>> bunch >>> > >>>>>>> of options really is not necessarily a good thing-- sometime >>> > >>>>>>> less is >>> > >>>>>>> more. To put this another way LISP has been rejected from Lin= ux >>> > >>>>>>> precisely because of its susceptibility to DOS. If you were t= o >>> > >>>>>>> try >>> > >>>>>>> again and the best answer to the DOS question is that it's up >>> > >>>>>>> to the >>> > >>>>>>> operator to figure out the right options to use, then I belie= ve >>> > >>>>>>> it >>> > >>>>>>> would be soundly rejected again. That approach does not work = at >>> > >>>>>>> scale. >>> > >>>>>>> >>> > >>>>>>> Tom >>> > >>>>>>> >>> > >>>>>>> _______________________________________________ >>> > >>>>>>> ila mailing list >>> > >>>>>>> ila@ietf.org >>> > >>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >>> > 3A__www.ietf.org_ma >>> > >>>>>>> ilman_listinfo_ila&d=3DDwICAg&c=3DLFYZ- >>> > >>>> >>> > >>>> o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl >>> > >>>>>>> >>> > >>>>>>> >>> > >>>> >>> > 2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4OstVOL1OQiA98fgBJ9c1Gjo&s=3DBO3snt8= C >>> > >>>> RQ >>> > >>>>>>> >>> > >>>>>>> gy1xwhx2CY10VUbM_rgntgpV9k3-Cskd8&e=3D >>> > >>>>>>> >>> > >>>>>> >>> > >>>>> >>> > >>>>> _______________________________________________ >>> > >>>>> 5gangip mailing list >>> > >>>>> 5gangip@ietf.org >>> > >>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >>> > 3A__www.ietf.org_mail >>> > >>>>> man_listinfo_5gangip&d=3DDwICAg&c=3DLFYZ- >>> > >>>> >>> > >>>> o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl >>> > >>>>> >>> > >>>>> >>> > >>>> >>> > 2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4OstVOL1OQiA98fgBJ9c1Gjo&s=3DFnQLMir= e >>> > >>>> MiKC >>> > >>>>> >>> > >>>>> SkPaOGFCybzDc2i2y49Cgtbl6mCLc9c&e=3D >>> > >>>> >>> > >>>> >>> > >>>> _______________________________________________ >>> > >>>> 5gangip mailing list >>> > >>>> 5gangip@ietf.org >>> > >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >>> > >>>> 3A__www.ietf.org_mailman_listinfo_5gangip&d=3DDwICAg&c=3DLFYZ- >>> > >>>> >>> > o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4 >>> > >>>> >>> > OstVOL1OQiA98fgBJ9c1Gjo&s=3DFnQLMireMiKCSkPaOGFCybzDc2i2y49Cgtbl6mC >>> > >>>> Lc9c&e=3D >>> > >> >>> > >> >>> > > >>> _______________________________________________ >>> 5gangip mailing list >>> 5gangip@ietf.org >>> https://www.ietf.org/mailman/listinfo/5gangip >> >> > From nobody Wed May 9 08:21:09 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1221C127775 for ; Wed, 9 May 2018 08:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 rfL67C_3bEtJ for ; Wed, 9 May 2018 08:21:05 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 D34F21276AF for ; Wed, 9 May 2018 08:21:04 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id j42-v6so46085494qtj.12 for ; Wed, 09 May 2018 08:21:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Pa3XxOefBqe1VzdcFMOd2Y0bOg0rCAiQXjAHVF/CfMs=; b=xtQJyFdrqrSv4wsXcsb04B6yBuoH0IJsy2vUD3XQtOqwJwf6PRV7QAt3TlpmvhIpIv +3oLiaIiyfb/sKOQ1rQTR4VYD4H2OneiuPiadVexYwub/tzBpC34pKBlN0HYnZ7xACkg LrNEl/dzkOmg6cFdcQ5xX87DNzzLOxfDZjKqZcE9AUV0F2C0SOl7ARqEhl3uvAgvjKIp ThsT/8yS+I9U98/4qlE51EX06Gcdr0N/WjeMiajyPb6vgeQSjFgYlbDGtb92WK/GKn5J c3QyMtZ6GfIUgJpCbaDAQd0xZxSKQNuzwekqgwzkKGUZMIYNK20EZKwLvMVUmoTT4UfK 90Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Pa3XxOefBqe1VzdcFMOd2Y0bOg0rCAiQXjAHVF/CfMs=; b=CC0TzOUW3aeXpLxSEo+TpEAJ+Tg31mrCdU+gayBB9Z47PSfc6L+vXQKXce5Y14sqau rENxSQ5OaToyqy52fw8daodawvJu1lOk/2zXZdoMyo2BXhzjFJB4vlMG/PR3+jxjzXrH iTy/B9gnt37yFxYZpZchgRHq9wtzq1F828kRFBD2hcKeF6oOg9nvgPZXMlDuWeHLrudt mwWFkkBZbBd5zWOPWUHiWIbfji51aq2chrfR40OIg69fn9wrmZ80ggUxN5NNtVlU61e7 DJT75WpxgdHyIJSsn8z+9Co6WNPL3Msgp9zcrOJJBJOi3dBbDFjDXFmHpmaUY6D+lXFY e5Bg== X-Gm-Message-State: ALQs6tDWUyVv2TbEzGKZo0/oW7NozgDKU7MKjbiSkXIzYl9h7AsKKyp/ HEh/iq70Rkgn1sSpU1W1Iud0IVCEko2mCEit2xAivg== X-Google-Smtp-Source: AB8JxZonOXH/mMLI4zk08e1PCm6TjFYeHzf/bs6Xe2ldbQh7xblYg/t3bkkSuAGQK+BbCPcU/5KXO637sjarGMrvfJg= X-Received: by 2002:ac8:321a:: with SMTP id x26-v6mr41740760qta.130.1525879263359; Wed, 09 May 2018 08:21:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.48.66 with HTTP; Wed, 9 May 2018 08:21:02 -0700 (PDT) In-Reply-To: References: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> <8aee42db5f0f407c86fda881769ceb77@HE105715.emea1.cds.t-internal.com> <1AFE10CF28AE8B4C9663445736B8034D3822FAFE@CAFRFD1MSGUSRJI.ITServices.sbc.com> <0cbb9987-0b47-9428-3db7-2c9fab821268@joelhalpern.com> <1AFE10CF28AE8B4C9663445736B8034D3822FC27@CAFRFD1MSGUSRJI.ITServices.sbc.com> <55875A79-0D4A-48EF-BCA9-A7462EBE3A38@att.com> From: Tom Herbert Date: Wed, 9 May 2018 08:21:02 -0700 Message-ID: To: "FIGURELLE, TERRY F" Cc: Tom Herbert , Lorenzo Colitti , "Joel M. Halpern" , "ila@ietf.org" , 5GANGIP <5gangip@ietf.org>, Alberto Rodriguez-Natal , "Dirk.von-Hugo@telekom.de" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 15:21:08 -0000 On Wed, May 9, 2018 at 8:08 AM, Tom Herbert wrote: > On Tue, May 8, 2018 at 10:48 AM, FIGURELLE, TERRY F wrot= e: >> Nope, we handle QUIC. Spent lots of time with Google on that one. Many > > Terry, > > QUIC was only an example. I'm am concerned with the next QUIC, next > real time gaming protocol, next application protocol that might > benefit from a different transport. There's no reason to believe that > QUIC and TCP constitutent the complete set of transport protocols that > we'll ever need and that those are the only ones we should be allowed > to use on the Internet. NATPT and proxies enforce their concept as to > what transport protocols are allowed. Proxies introduce the addional > complexity in that they make it harder to deploy new options and make > it impossible to use end to end transport header authentication. > > This is why protocols like ILA are explicitily independent of > transport layer. They don't require DPI, they don't require flow state > to be tracked in the network, and they don't require packets of a flow > to always hit the same devices in the network. They can however solve > problems at the network layer (the aforementioned privacy in > addressing for example). > I should also mention that blocking unsoliticted traffic and providing flow specific services are still relevant, but these can also be done in a transport independent manner. See FAST proposal (draft-herbert-fast-00). Tom > Tom > > >> people here have worked at T-Mobile USA and the flip. T-Mo USA does bloc= k >> unsolicited but this gets deep into the details of unsolicited and fine >> lines of block or do not support or enable it to happen. >> >> T-Mobile by country does have differences. They got a lot more address s= pace >> from RIPE than T-Mo USA got from ARIN. So in the states they use NAPT. T= hey >> do support NAT traversal but do not host TURN. If the T-Mo USA and Sprin= t >> deal goes through they will have some huge challenges to efficiently com= bine >> things. >> >> They also use the exact same SGW/PGW vendor and hardware model as we do.= So >> does Verizon (Cisco ASR5500). They may still have some of the older ASR5= 000 >> and Verizon may too. Neither has a virtualized solution in production. W= e >> have both Cisco and Affirmed carrying live paying production traffic. We >> stopped adding hardware based solutions more than a year ago. We also ha= ve >> virtualized MME (Ericsson) since last year and Nokia is in certification >> testing. We have virtualize most of the IMS domain and mobility systems >> except RAN. We are working on RAN. >> >> We are using CUPS for launch of 5G this year. Still debating the options >> longer term but we also need standards to make decisions. >> >> Back to unsolicited. >> >> We all support methods so traffic flows like video chat can work but key= is >> we all work directly with those ASP=E2=80=99s (Application service provi= ders). All >> of us have special handling of traffic to Amazon, Apple, Google and so o= n. >> The difference is in the functionality, scale and number of ASP=E2=80=99= s support >> where we smoke everyone! >> >> So you can build an App for Apple iOS or Google=E2=80=99s Android and it= can work >> well. You can also do peer-to-peer but only as long as the setup goes th= ru >> servers that are enabled. In our case you could also use our API=E2=80= =99s. Mobile >> to mobile is only allowed when enabled. >> >> While unsolicited is the common term used in the mobile industry perhaps >> unwanted or undesired gives a better view. User=E2=80=99s don=E2=80=99t = want SPAM and they >> don=E2=80=99t want threats (risk of device being compromised). But if th= ey download >> and setup an App they do want that to work. >> >> It also gets to the definition of Internet. In the US very little mobile >> traffic ever goes over the =E2=80=9CInternet=E2=80=9D. It=E2=80=99s all = protected private networks >> between mobile operators and data centers. Even inside the data centers = the >> traffic uses servers dedicated to mobile users. Within the data center i= t >> may go from mobile servers to non-mobile servers. >> >> We also have major hosting companies and cloud providers covered. A star= tup >> may rent capacity from Amazon but mobile traffic goes over a protected >> (encrypted) path on a private network to Amazon data centers worldwide. = Same >> for most major hosting facilities worldwide. >> >> This is true for most mobile operators and often even when they don=E2= =80=99t know >> it. There are some places where things are different like China. Everyon= e >> does what they are told to do in China or you won=E2=80=99t be in China.= Lots of >> complicated partnerships to make anything work. So your traffic is visib= le >> to some parties when there is no other option. >> >> All of the big CDN solutions and CDN supplies work with this model. So >> Akamai for Verizon mobiles is different from Akamai on AT&T mobiles. In = our >> case this only goes to Akamai servers in AT&T hosting facilities. So for= all >> of the major mobile operators in the entire Western Hemisphere. In reali= ty >> it=E2=80=99s true for all mobile operators in Western Hemisphere to any = significant >> service even when they don=E2=80=99t know it. It doesn=E2=80=99t matter = who is the local LEC >> or what ISP the mobile operator uses. >> >> We even protect open WiFi and I wanted to protect all mobile =E2=80=9CIn= ternet >> services traffic=E2=80=9D but that is in the future. We detect if a VPN = is in use or >> if one starts to stay out of the way in the current open WiFi case. We c= an >> split and run traffic from UE over one VPN while running tethered (mobil= e >> hotspot, USB, Bluetooth) traffic outside the VPN or in a different VPN. = We >> even support corporate VPN so the traffic actually goes over private net= work >> to corporate servers instead of coming in their =E2=80=9CInternet=E2=80= =9D connection. >> >> You may ask about ISP peering points but in those cases for partnered >> content we use encryption. A company could use Level3 as an ISP then ser= ve >> Internet content on that connection. If we don=E2=80=99t have a partners= hip deal >> with that company then traffic would be protected to our closest to cont= ent >> peering point with Level3. >> >> Another way to say it is for the top X websites by clicks/hits, top Y si= tes >> by volume (bytes) or top Z sites by connection for the busiest hour, bus= y >> period, day of week, etc. for any operator you can draw a line. Above th= at >> line the traffic is secured mobile to/from content. Below the line it ma= y be >> secured or it may not. >> >> The rules for handling the Internet in a given country can be very compl= ex. >> In many countries you can count on one or two fingers your options as a >> mobile operator when they are not THE LEC/ISP. >> >> Sent from my iPhone >> >> On May 8, 2018, at 7:44 AM, Tom Herbert wrote: >> >> >> >> On Tue, May 8, 2018 at 6:39 AM, Lorenzo Colitti wro= te: >>> >>> FWIW, I believe there are large operators that do not block unsolicited >>> inbound traffic to mobile networks. One of them is T-Mobile. >>> >> I should hope that a majority of access networks don't do that, lest it >> would be impossible to deploy new transport protocols (like QUIC for >> instance) and the ossification of the Internet would be complete. >> >> Tom >> >>> On Fri, May 4, 2018 at 7:53 AM, FIGURELLE, TERRY F wro= te: >>>> >>>> No. We have always block unsolicited traffic from the Internet and it = is >>>> too complicated to discuss here. >>>> >>>> We even did this way back for CDPD. For dedicated APN's we allow the >>>> enterprise to tell us what rules they want to protect the mobile from = their >>>> network and what traffic to not allow from the mobile. This is one of = the >>>> reasons firewalls and CNAT cost more if they support mobility features= . We >>>> spent a lot of time working with potential vendors. >>>> >>>> Since this started with usage based rate plans for all mobile operator= s >>>> the subscriber would get charged if we allowed spam from the Internet = or >>>> from other mobiles. So this has always been block and vendors have fea= tures >>>> to help out in 3GPP elements. A GGSN with anti-spoofing not disabled d= oesn't >>>> allow traffic to a mobile that doesn't match an entry in the flow tabl= e. We >>>> have hundreds of policy rules that get enabled from the PCRF/PCF on th= e >>>> PGW(PCEF)/UPF. We also enabled our proxies to be transparent proxy-TDF= . That >>>> means they also have policy interfaces and we do a bunch of stuff here >>>> including processing signed manifests. Plus the rules are pushed on th= e >>>> control plane not the data plane and it includes UE, RAN, SGW/PGW/UPF = and if >>>> applicable TDF's and AS's. We can push rules to the UE that allow, (dr= op), >>>> route/path (e.g. bearer). We even have to have some country specific >>>> treatment (a bigger challenge we had for vehicles using our Connected = Car >>>> solution like GM OnStar). >>>> >>>> While a mobile could get hacked and it could break the flow rule >>>> treatment some of that is down in the 3GPP chipset. But we are aware o= f the >>>> risk and we have counter measures as best we can. I should point out t= hat >>>> these flow rules go into RAN too and rules have a direction (from UE, = to UE >>>> or both). >>>> >>>> My opinion is that malware, spoofing, DOS, DDOS and any other threat i= s a >>>> serious operational issue. That is the best place to deal with it beca= use >>>> standards could never keep pace. We and other operators request featur= es >>>> from vendors and they also come up with stuff as a value add. >>>> >>>> Simply stated the solution needs to be protected but we don't need ton= s >>>> of detail in every standard. >>>> >>>> I would never say don't be concerned about something. I just don't thi= nk >>>> every standard needs details on spoofing, DOS and other threats. >>>> >>>> >>>> > -----Original Message----- >>>> > From: Tom Herbert >>>> > Sent: Thursday, May 03, 2018 3:00 PM >>>> > To: Joel M. Halpern >>>> > Cc: FIGURELLE, TERRY F ; Dirk.von-Hugo@telekom.de; T= om >>>> > Herbert ; ila@ietf.org; Alberto Rodriguez-Natal >>>> > ; 5GANGIP <5gangip@ietf.org> >>>> > Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statemen= t] >>>> > >>>> > On Thu, May 3, 2018 at 2:45 PM, Joel M. Halpern >>>> > wrote: >>>> > > I am missing something in your DDOS issue. >>>> > > >>>> > > At first, I thought the real issue (which you seem to be suggestin= g >>>> > > here) was DDOS from the Internet, using spoofed or non-spoofed >>>> > > addresses (with bot farms, there is much less need for or relevanc= e >>>> > > of >>>> > spoofing). >>>> > > >>>> > > But then I tried to map it to the cases we have for using ILA. >>>> > > The primary case I have heard about is to use ILA for UE<->UE and >>>> > > UE<->EdgeComputing traffic. If so, just filter all SIRs on incomi= ng >>>> > > packets from the Internet. They aren't legal there. And similarl= y, >>>> > > if one uses LISP within the operator domain, we can block whatever >>>> > > blocks we use for EIDs for such local traffic. >>>> > >>>> > Joel, >>>> > >>>> > I'm not sure I understand what "filtering SIRs from the Internet" >>>> > means. A SIR address is a globally visible address for devices like >>>> > UEs. So an >>>> > Internet sender may legitimately send packets to SIR addresses, and >>>> > also an >>>> > Internet attacker could easily spew a whole bunch of packets with bo= th >>>> > spoofed >>>> > source addresses and spoofed UE addresses. So you'd want to allow th= e >>>> > legitimate traffic but block the attacking packets-- this isn't >>>> > feasible since it's >>>> > impossible to distinguish the bad from the good packets. >>>> > >>>> > > >>>> > > If we want to use id-locator split of any kind for handling traffi= c >>>> > > to >>>> > > / from the Internet, then we have to understand how that is suppos= ed >>>> > > to work, and why, before we need to evaluate DDOS implications of = a >>>> > > solution. For LISP,the working group has explicitly said that >>>> > > Inter-wide deployment is out of scope. >>>> > > >>>> > > Net: I do not see in currently described deployments, an issue tha= t >>>> > > differentiates LISP from ILA in these regards. And Terry has very >>>> > > clearly spelled out that for mobile operators spoofing from UEs is >>>> > > not >>>> > > considered an issue that the infrastructure needs to deal wih. >>>> > >>>> > But there may be a whole network infrastructure of hundreds or even >>>> > thousands of users behind a UE, and there's no guarantee that that >>>> > infrastructure properly supports anti-spoofing. This basically this >>>> > case has the >>>> > same problem as in the Internet case. >>>> > >>>> > Tom >>>> > >>>> > > >>>> > > Yours, >>>> > > Joel >>>> > > >>>> > > >>>> > > On 5/3/18 5:33 PM, Tom Herbert wrote: >>>> > >> >>>> > >> On Thu, May 3, 2018 at 2:23 PM, FIGURELLE, TERRY F >>>> > wrote: >>>> > >>> >>>> > >>> In the case of current 3GPP operators all the major vendors supp= ort >>>> > >>> anti-spoofing. The default was on for all but one vendor which g= ot >>>> > >>> corrected the last time I did an RFP for EPC. So by configuratio= n >>>> > >>> the GGSN/PGW/PGW-U/UPF will not allow the UE to send packets th= at >>>> > >>> don't match either the exact IP address or pushed subnet or pref= ix >>>> > >>> delegation that was sent in response to the APN create message. >>>> > >>> Obviously if we remove GTP encapsulation that protect MAY need t= o >>>> > >>> be >>>> > enhanced towards an EDGE element. >>>> > >>> >>>> > >> Terry, >>>> > >> >>>> > >> Even so, the whole Internet does not require anti-spoofing, nor d= o I >>>> > >> believe that operators could require all down stream network that >>>> > >> are >>>> > >> connected to support anti-spoofing. These are where the DOS attac= ks >>>> > >> orginate. The problem is when caches are being driven by user taf= fic >>>> > >> from these external networks, mitigations to detect DOS by IP sou= rce >>>> > >> address don't work without anti-spoofing (but even if they had >>>> > >> anti-spoofing that still doesn't work when under a DDOS). >>>> > >> >>>> > >> Tom >>>> > >> >>>> > >> >>>> > >> >>>> > >>> This is being covered as part of our participation in an open >>>> > >>> source >>>> > >>> vEPC (virtualize EPC, hypervisor, blah, blah, blah). So there wi= ll >>>> > >>> be a micro service firewall that can be deploy at the edge plus = we >>>> > >>> already have planned support for big network infrastructure vend= ors >>>> > >>> and 3GPP supplies (Cisco, Juniper, Ericsson, Nokia, Huawei, ...)= to >>>> > >>> cover this. Since this can be a non-3GPP element we will get th= is >>>> > >>> into >>>> > ONAP. >>>> > >>> >>>> > >>> Thus we have this covered both for 3GPP nodes, micro services an= d >>>> > >>> open source efforts. To give examples without vendor names there >>>> > >>> are >>>> > >>> GTP aware firewalls that some operators use. It really just anot= her >>>> > >>> capability in carrier class and business class firewalls (had to >>>> > >>> add >>>> > >>> it to load balancers, CNAT/NAT, some Wi-Fi routers and to our DN= S >>>> > >>> solution which uses open source). Obviously this will be suppor= ted >>>> > >>> via a RADIUS feed for backwards compatibility. Today most GTP >>>> > >>> firewall simply follow the GTP-C signaling to learn the IP >>>> > >>> address(es) assigned to the UE for an APN. If we remove GTP from >>>> > >>> user plane that doesn't mean we remove it from control plane or = for >>>> > >>> all hops. However, we will likely push to a micro service at the >>>> > >>> cell plus I need to check if we ever ask RAN vendors to support >>>> > >>> this. I'll add >>>> > this for 5G but we already did that RFP so it's a change order (yuck= ). >>>> > >>> >>>> > >>> I am not good at wordsmithing but I suggest there be some paragr= aph >>>> > >>> that covers network elements that can except a RADIUS feed. I ne= ed >>>> > >>> to talk to our standards team to see if we want this on T8 >>>> > >>> (probably). >>>> > >>> >>>> > >>> So today for all AT&T, Verizon, Vodaphone, ..... I know or am >>>> > >>> fairly confident they have anti spoofing tuned on in the >>>> > >>> GGSN/PGW/UPF plus I know they can turn this on per APN. Not sure >>>> > >>> why >>>> > >>> anyone would disable this since we if you are delegating a subne= t >>>> > >>> to >>>> > >>> a Wi-Fi hotspot (instead of the typical private addressing they >>>> > >>> use). >>>> > >>> >>>> > >>> We actually don't need any 3GPP changes since this is already >>>> > >>> covered using RADIUS to pass the information where it needs to g= o. >>>> > >>> I >>>> > >>> suspect most will leverage their caching SPR/UDR which already h= as >>>> > >>> the information. Even the GGSN we launched EDGE/GPRS when I was >>>> > >>> much >>>> > >>> younger supported anti-spoofing and many vendors cover this via = a >>>> > >>> number of methods (e.g. COPS works for older junos and RADIUS fo= r >>>> > >>> Cisco >>>> > IOS releases ). >>>> > >>> >>>> > >>> My suggestion is that I am willing to help whoever wants to craf= t >>>> > >>> the paragraph because I suck at that (fortunately I am good at >>>> > >>> other >>>> > things). >>>> > >>> >>>> > >>> I don't think we need any changes to any standards to cover this >>>> > >>> since we already cover this and already are covering this if we >>>> > >>> strip out GTP (at least for one leg). I'll make sure it gets int= o >>>> > >>> our RAN requirements if not there since that may be the best pla= ce >>>> > >>> for that edge. Plus I'll get it covered thru the ONAP open sourc= e >>>> > >>> effort we drove (we donated the software to the open source >>>> > >>> effort). >>>> > >>> That means FM, PM, CM and IM will be covered in some future ONAP >>>> > release (takes time but faster than 3GPP). >>>> > >>> >>>> > >>> It's a bit debatable what is RAN when using virtualized network >>>> > >>> functions >>>> > >>> (VNF) and a bunch of open source stuff that we put it into all o= f >>>> > >>> the needed elements like SDN, firewall, load balancer (not sure >>>> > >>> that's needed at cell site but it is for core DNS, proxy-TDF and >>>> > >>> CNAT) out at the cell site. We aren't there yet (still physical >>>> > >>> eNB/NR and obviously we need hardware assist even with >>>> > >>> virtualization plus tight control of timing). I am looking forwa= rd >>>> > >>> to when we >>>> > start using containers. >>>> > >>> >>>> > >>> For our core I am sure we will use our UDR VNF as the cache for >>>> > >>> whatever comes out of this effort in final standards. The >>>> > >>> information is already there (IMEI, device vendor, subscription >>>> > >>> information, UE IP address, APN, etc.). If we do anything it wou= ld >>>> > >>> be to augment an open source and if needed a 3GPP. I don't think= we >>>> > >>> need >>>> > any changes but it's always best to verify. >>>> > >>> For current RAN an anti-spoofing feature would come from EMS whi= ch >>>> > >>> can be via ONAP. I don't think that is a standards effort thing >>>> > >>> since it's a feature which may or may not already be covered but= it >>>> > >>> will be in future RAN releases probably starting with eNB/NR wit= h >>>> > >>> some vendor release if it's not already a feature. I want to say >>>> > >>> Ericsson and Nokia already can do this in eNB but I need to go t= hru >>>> > channels to ask. >>>> > >>> >>>> > >>> So maybe that paragraph recommends implementing anti-spoofing at >>>> > >>> all >>>> > >>> edges and leaves it at that. Or we could say all edges including >>>> > >>> RAN >>>> > >>> if that makes people happy. >>>> > >>> >>>> > >>>> -----Original Message----- >>>> > >>>> From: 5gangip <5gangip-bounces@ietf.org> On Behalf Of Tom Herbe= rt >>>> > >>>> Sent: Thursday, May 03, 2018 10:46 AM >>>> > >>>> To: Dirk.von-Hugo@telekom.de >>>> > >>>> Cc: Tom Herbert ; Joel M. Halpern >>>> > >>>> ; ila@ietf.org; Alberto Rodriguez-Natal >>>> > >>>> ; 5GANGIP <5gangip@ietf.org> >>>> > >>>> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem >>>> > >>>> Statement] >>>> > >>>> >>>> > >>>> On Thu, May 3, 2018 at 9:23 AM, wro= te: >>>> > >>>>> >>>> > >>>>> Hi Tom, >>>> > >>>>> I understand you correctly that DDOS attacks can never be >>>> > >>>>> completely >>>> > >>>> >>>> > >>>> prevented whatever protocol you use. >>>> > >>>>> >>>> > >>>>> It will however always remain related to known IP addresses an= d >>>> > >>>>> the more >>>> > >>>> >>>> > >>>> versatile these are handled a mitigation strategy could be >>>> > >>>> designed. >>>> > >>>> >>>> > >>>> Dirk, >>>> > >>>> >>>> > >>>> I disagree. IP addresses can too easily be spoofed, it's easy t= o >>>> > >>>> hide identity behind a NAT (see discussion about CGNAT and law >>>> > >>>> enforcement on int-area list), and trying to turn off individua= l >>>> > >>>> addresses doesn't work if it's a DDOS. This is nothing new. For >>>> > >>>> instance, content providers have long accepted the fact that th= ey >>>> > >>>> can't prevent SYN attacks and there's little point to trying to= go >>>> > >>>> back to source IP address (they are always spoofed in a SYN >>>> > >>>> attack). The better strategy is to absorb the attack and minimi= ze >>>> > >>>> the negative effects so that the attack is not worth the effort= . >>>> > >>>> >>>> > >>>>> As you may have seen we mention improved handling of mapping >>>> > >>>>> systems >>>> > >>>> >>>> > >>>> and subsequently of DDOS protection also in the current version= of >>>> > >>>> our PS document https://urldefense.proofpoint.com/v2/url?u=3Dht= tps- >>>> > >>>> 3A__github.com_bsarikaya_atic_blob_master_atick- >>>> > >>>> 5Fproblemstatement.3.txt&d=3DDwICAg&c=3DLFYZ- >>>> > >>>> >>>> > o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_= 4 >>>> > >>>> OstVOL1OQiA98fgBJ9c1Gjo&s=3DjLL_9a56R8Ic8o3uJcR8mrF- >>>> > >>>> JkzLL97h8rmZT_EqXnQ&e=3D which Behcet has announced recently. >>>> > >>>>> >>>> > >>>>> May I ask you to please comment on the ideas outlined there? >>>> > >>>> >>>> > >>>> >>>> > >>>> I don't see much difference in the latest version. For a proble= m >>>> > >>>> statement, I still think there is too much focus on the solutio= ns >>>> > >>>> and not nearly enough description of what the actual problems a= re >>>> > >>>> to be solved. >>>> > >>>> >>>> > >>>> Tom >>>> > >>>> >>>> > >>>>> Thanks! >>>> > >>>> >>>> > >>>> >>>> > >>>>> Best Regards >>>> > >>>>> Dirk >>>> > >>>>> >>>> > >>>>> -----Original Message----- >>>> > >>>>> From: 5gangip [mailto:5gangip-bounces@ietf.org] On Behalf Of T= om >>>> > >>>>> Herbert >>>> > >>>>> Sent: Mittwoch, 2. Mai 2018 01:20 >>>> > >>>>> To: Joel M. Halpern >>>> > >>>>> Cc: Tom Herbert ; ila@ietf.org; Alberto >>>> > >>>>> Rodriguez-Natal ; 5GANGIP >>>> > >>>>> <5gangip@ietf.org> >>>> > >>>>> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem >>>> > >>>>> Statement] >>>> > >>>>> >>>> > >>>>> On Tue, May 1, 2018 at 3:49 PM, Joel M. Halpern >>>> > >>>>> >>>> > >>>> >>>> > >>>> wrote: >>>> > >>>>>> >>>> > >>>>>> You seem to be saying that even though not all DDOS attacks a= re >>>> > >>>>>> structurally the same, and even though if ILA were widely >>>> > >>>>>> adopted >>>> > >>>>>> not all ILA networks would be structurally the same, there >>>> > >>>>>> should >>>> > >>>>>> nonetheless be one required qay of handling DDOS? >>>> > >>>>> >>>> > >>>>> >>>> > >>>>> Yes, at least as core default in the protocol. It's precisely >>>> > >>>>> _because_ not all >>>> > >>>> >>>> > >>>> DDOS attacks are structurally the same. An attacker is not goin= g >>>> > >>>> to >>>> > >>>> conform to to our expectations of what they should be doing, so= if >>>> > >>>> we enable LISP option N to mitigate one form of attack, they wi= ll >>>> > >>>> just use another attack that isn't mitigated. For example, if t= he >>>> > >>>> mitigation is to identify attackers by address when requests fr= om >>>> > >>>> the address exceed a threshold then this works as long as the >>>> > >>>> attacker strikes from one machine, but it falls apart if the >>>> > >>>> attacker launches a DDOS attack from several hosts where reques= ts >>>> > >>>> from none of the hosts exceed the threshold. >>>> > >>>>> >>>> > >>>>> >>>> > >>>>> The ILA model works because it assumes there is no absolute wa= y >>>> > >>>>> to >>>> > >>>>> prevent >>>> > >>>> >>>> > >>>> the the worst case attack on a cache which is to completely kil= l >>>> > >>>> it >>>> > >>>> (i.e. drive it to 0% hit rate). In this state the behavior >>>> > >>>> sub-optimal routing, which is much better than loss of service. >>>> > >>>> This is not dependent on the structure of the attack, network >>>> > >>>> topology, or the network operator getting the configuration jus= t >>>> > >>>> right-- >>>> > >>>> it is inherent in the protocol. >>>> > >>>>> >>>> > >>>>> >>>> > >>>>> Tom >>>> > >>>>> >>>> > >>>>>> >>>> > >>>>>> Yours, >>>> > >>>>>> Joel >>>> > >>>>>> >>>> > >>>>>> >>>> > >>>>>> On 5/1/18 6:32 PM, Tom Herbert wrote: >>>> > >>>>>>> >>>> > >>>>>>> >>>> > >>>>>>> On Tue, May 1, 2018 at 2:59 PM, Alberto Rodriguez-Natal >>>> > >>>>>>> wrote: >>>> > >>>>>>>> >>>> > >>>>>>>> >>>> > >>>>>>>> On Tue, May 1, 2018 at 10:16 AM, Tom Herbert >>>> > >>>> > >>>> >>>> > >>>> wrote: >>>> > >>>>>>>>> >>>> > >>>>>>>>> >>>> > >>>>>>>>> >>>> > >>>>>>>>> I think you've misunderstood my position. Caches are _very= _ >>>> > >>>>>>>>> important to eliminate the cost triangular routing (latenc= y, >>>> > >>>>>>>>> average path >>>> > >>>> >>>> > >>>> load). >>>> > >>>>>>>>> >>>> > >>>>>>>>> This reduces latency and reduces average load on ILA-Rs. B= ut, >>>> > >>>>>>>>> and >>>> > >>>>>>>>> this is the critical part, caches are only an _optimizatio= n_ >>>> > >>>>>>>>> in >>>> > >>>>>>>>> ILA. That means if the cache is rendered ineffective (like= by >>>> > >>>>>>>>> a >>>> > >>>>>>>>> well crafted DOS >>>> > >>>>>>>>> attack) then the only effect is that the optimization is l= oss >>>> > >>>>>>>>> (i.e. >>>> > >>>>>>>>> greater latency due to triangular router)-- this is >>>> > >>>>>>>>> quantitively >>>> > >>>>>>>>> the worst effect of the attack on an ILA cache. This can b= e >>>> > >>>>>>>>> contrasted that to LISP where the worst case effects of a = DOS >>>> > >>>>>>>>> attack on the cache is loss of service for users (infinite >>>> > >>>>>>>>> latency >>>> > >>>>>>>>> since packets can be dropped or indefinitely blocked on a >>>> > >>>>>>>>> cache >>>> > >>>>>>>>> miss). >>>> > >>>>>>>> >>>> > >>>>>>>> >>>> > >>>>>>>> >>>> > >>>>>>>> >>>> > >>>>>>>> This can be misleading. This is not comparing LISP vs ILA, >>>> > >>>>>>>> this is >>>> > >>>>>>>> comparing the models of Request/Reply at the edge vs >>>> > >>>>>>>> Notifications >>>> > >>>>>>>> (aka Redirects) at the core. Both LISP-CP and ILAMP support >>>> > >>>>>>>> these >>>> > >>>>>>>> two models. >>>> > >>>>>>>> >>>> > >>>>>>>> Besides, this is assuming an scenario where the only feasib= le >>>> > >>>>>>>> DOS >>>> > >>>>>>>> mitigation is absorbing the attack. There are other scenari= os >>>> > >>>>>>>> where >>>> > >>>>>>>> other countermeasures are possible. For instance, if you ha= ve >>>> > >>>>>>>> a >>>> > >>>>>>>> deployment where you can prevent address spoofing, counting >>>> > >>>>>>>> and >>>> > >>>>>>>> blocking misbehaving nodes offers similar DOS protection an= d >>>> > >>>>>>>> requires way less infrastructure resources. >>>> > >>>>>>>> >>>> > >>>>>>> Alberto, >>>> > >>>>>>> >>>> > >>>>>>> The answer to my question of how does LISP address DOS attac= ks >>>> > seems >>>> > >>>>>>> to be "there are many options". Some of the options are to >>>> > >>>>>>> assume >>>> > >>>>>>> that DOS does not exist in the network, some assume external >>>> > >>>>>>> configuration like address spoofing is enabled, some assume >>>> > >>>>>>> that >>>> > >>>>>>> attacks can be identified and can be stopped at the source, >>>> > >>>>>>> some >>>> > >>>>>>> might assume that everything is okay because there's never b= een >>>> > >>>>>>> a >>>> > >>>>>>> DOS attack before. I have yet to see the effects of any of >>>> > >>>>>>> these >>>> > >>>>>>> quantified, and none of these state how the LISP _protocol_ >>>> > >>>>>>> itself >>>> > >>>>>>> addresses DOS. It may seem counter-intuitive, but offering a >>>> > >>>>>>> bunch >>>> > >>>>>>> of options really is not necessarily a good thing-- sometime >>>> > >>>>>>> less is >>>> > >>>>>>> more. To put this another way LISP has been rejected from Li= nux >>>> > >>>>>>> precisely because of its susceptibility to DOS. If you were = to >>>> > >>>>>>> try >>>> > >>>>>>> again and the best answer to the DOS question is that it's u= p >>>> > >>>>>>> to the >>>> > >>>>>>> operator to figure out the right options to use, then I beli= eve >>>> > >>>>>>> it >>>> > >>>>>>> would be soundly rejected again. That approach does not work= at >>>> > >>>>>>> scale. >>>> > >>>>>>> >>>> > >>>>>>> Tom >>>> > >>>>>>> >>>> > >>>>>>> _______________________________________________ >>>> > >>>>>>> ila mailing list >>>> > >>>>>>> ila@ietf.org >>>> > >>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >>>> > 3A__www.ietf.org_ma >>>> > >>>>>>> ilman_listinfo_ila&d=3DDwICAg&c=3DLFYZ- >>>> > >>>> >>>> > >>>> o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl >>>> > >>>>>>> >>>> > >>>>>>> >>>> > >>>> >>>> > 2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4OstVOL1OQiA98fgBJ9c1Gjo&s=3DBO3snt= 8C >>>> > >>>> RQ >>>> > >>>>>>> >>>> > >>>>>>> gy1xwhx2CY10VUbM_rgntgpV9k3-Cskd8&e=3D >>>> > >>>>>>> >>>> > >>>>>> >>>> > >>>>> >>>> > >>>>> _______________________________________________ >>>> > >>>>> 5gangip mailing list >>>> > >>>>> 5gangip@ietf.org >>>> > >>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >>>> > 3A__www.ietf.org_mail >>>> > >>>>> man_listinfo_5gangip&d=3DDwICAg&c=3DLFYZ- >>>> > >>>> >>>> > >>>> o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl >>>> > >>>>> >>>> > >>>>> >>>> > >>>> >>>> > 2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4OstVOL1OQiA98fgBJ9c1Gjo&s=3DFnQLMi= re >>>> > >>>> MiKC >>>> > >>>>> >>>> > >>>>> SkPaOGFCybzDc2i2y49Cgtbl6mCLc9c&e=3D >>>> > >>>> >>>> > >>>> >>>> > >>>> _______________________________________________ >>>> > >>>> 5gangip mailing list >>>> > >>>> 5gangip@ietf.org >>>> > >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >>>> > >>>> 3A__www.ietf.org_mailman_listinfo_5gangip&d=3DDwICAg&c=3DLFYZ- >>>> > >>>> >>>> > o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_= 4 >>>> > >>>> >>>> > OstVOL1OQiA98fgBJ9c1Gjo&s=3DFnQLMireMiKCSkPaOGFCybzDc2i2y49Cgtbl6mC >>>> > >>>> Lc9c&e=3D >>>> > >> >>>> > >> >>>> > > >>>> _______________________________________________ >>>> 5gangip mailing list >>>> 5gangip@ietf.org >>>> https://www.ietf.org/mailman/listinfo/5gangip >>> >>> >> From nobody Wed May 9 12:44:32 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2C6127873; Wed, 9 May 2018 12:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 0-gXuWZJoln3; Wed, 9 May 2018 12:44:24 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 53A34127863; Wed, 9 May 2018 12:44:24 -0700 (PDT) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id w49JaEOC042952; Wed, 9 May 2018 15:44:16 -0400 Received: from flpd657.enaf.ffdc.sbc.com (sbcsmtp9.sbc.com [144.160.128.153]) by m0048589.ppops.net-00191d01. with ESMTP id 2hv642j1e4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 May 2018 15:44:14 -0400 Received: from enaf.ffdc.sbc.com (localhost [127.0.0.1]) by flpd657.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id w49JiDDG049083; Wed, 9 May 2018 12:44:13 -0700 Received: from zlp25946.vci.att.com (zlp25946.vci.att.com [135.213.92.138]) by flpd657.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id w49Ji93Z049006; Wed, 9 May 2018 12:44:09 -0700 Received: from zlp25946.vci.att.com (zlp25946.vci.att.com [127.0.0.1]) by zlp25946.vci.att.com (Service) with ESMTP id 4ADFB412C923; Wed, 9 May 2018 19:44:09 +0000 (GMT) Received: from CAFRFD1MSGHUBAB.ITServices.sbc.com (unknown [130.4.169.165]) by zlp25946.vci.att.com (Service) with ESMTPS id F0FCD412C921; Wed, 9 May 2018 19:44:08 +0000 (GMT) Received: from CAFRFD1MSGUSRJI.ITServices.sbc.com ([169.254.8.94]) by CAFRFD1MSGHUBAB.ITServices.sbc.com ([130.4.169.165]) with mapi id 14.03.0389.001; Wed, 9 May 2018 12:44:08 -0700 From: "FIGURELLE, TERRY F" To: Tom Herbert CC: Tom Herbert , Lorenzo Colitti , "Joel M. Halpern" , "ila@ietf.org" , 5GANGIP <5gangip@ietf.org>, Alberto Rodriguez-Natal , "Dirk.von-Hugo@telekom.de" Thread-Topic: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement] Thread-Index: AQHT4wasd9k0kyItlUiMNTfEFG8rxqQebc2ggACORwCAAANogIAAA9+A//+Ma9CAB8OaAIAAEgyA//++Jp+AAdrVgIAAA5IA///UKeU= Date: Wed, 9 May 2018 19:44:08 +0000 Message-ID: References: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> <8aee42db5f0f407c86fda881769ceb77@HE105715.emea1.cds.t-internal.com> <1AFE10CF28AE8B4C9663445736B8034D3822FAFE@CAFRFD1MSGUSRJI.ITServices.sbc.com> <0cbb9987-0b47-9428-3db7-2c9fab821268@joelhalpern.com> <1AFE10CF28AE8B4C9663445736B8034D3822FC27@CAFRFD1MSGUSRJI.ITServices.sbc.com> <55875A79-0D4A-48EF-BCA9-A7462EBE3A38@att.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_D64AA7DF39D94CC89A88944F421E9A6Fattcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-09_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805090184 Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 19:44:30 -0000 --_000_D64AA7DF39D94CC89A88944F421E9A6Fattcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable When you need to manage how usage is rated that plays a big role in how pac= kets are handled. There it makes a whole lot of difference how the 3GPP pol= icy rules are built. All 3GPP operators of significance do this and where y= ou discard packets makes a huge difference. If you intentionally discard pa= ckets that have already been metered it is illegal in some countries. But let=92s take this back to where it began. SPOOFING: 1. I=92ve checked and NR edge can be or is covered by RAN (some RAN doesn= =92t exist yet). Thus it=92s not possible for a UE to spoof IP addresses be= cause the RAN can protect the upstream. It is already protected today by SG= W/PGW and UPF. You can also protect for 3GPP RAN and WiFi via ePDG by installing a policy = rule. The rule has the valid subnet/prefix for the UE in the 5-Tuple. There= is actually short hand in rule definitions which just substitutes the UE I= P/subnet when it gets to PGW (before flowing down to RAN and UE). 2. EDGE use cases require tight coordination all the way down to transport = to meet requirements. This includes definition of address ranges to be used= in both directions exchanged between all parties involved. We actually hav= e to go into great detail to make sure specific protocols can work. This al= so requires non-default CoS/QoS treatment which requires 3-tuple knowledge = before the first packet. Thus we must know the flow before even the first p= acket is sent. Since you know what is valid, it trivial to block at the ser= vices edge what isn=92t valid. FYI VoLTE smartphone requires a proxy on the general purpose APN. I checked and= none of the vendors have or are working on a proxy that can get an unexpec= ted SYN from services edge. This is true for CGNAT too. You need some form of NAT traversal and these a= ll require a packet up to get things plumbed. Sent from my iPhone On May 9, 2018, at 8:21 AM, Tom Herbert > wrote: On Wed, May 9, 2018 at 8:08 AM, Tom Herbert > wrote: On Tue, May 8, 2018 at 10:48 AM, FIGURELLE, TERRY F > wrote: Nope, we handle QUIC. Spent lots of time with Google on that one. Many Terry, QUIC was only an example. I'm am concerned with the next QUIC, next real time gaming protocol, next application protocol that might benefit from a different transport. There's no reason to believe that QUIC and TCP constitutent the complete set of transport protocols that we'll ever need and that those are the only ones we should be allowed to use on the Internet. NATPT and proxies enforce their concept as to what transport protocols are allowed. Proxies introduce the addional complexity in that they make it harder to deploy new options and make it impossible to use end to end transport header authentication. This is why protocols like ILA are explicitily independent of transport layer. They don't require DPI, they don't require flow state to be tracked in the network, and they don't require packets of a flow to always hit the same devices in the network. They can however solve problems at the network layer (the aforementioned privacy in addressing for example). I should also mention that blocking unsoliticted traffic and providing flow specific services are still relevant, but these can also be done in a transport independent manner. See FAST proposal (draft-herbert-fast-00). Tom Tom people here have worked at T-Mobile USA and the flip. T-Mo USA does block unsolicited but this gets deep into the details of unsolicited and fine lines of block or do not support or enable it to happen. T-Mobile by country does have differences. They got a lot more address spac= e from RIPE than T-Mo USA got from ARIN. So in the states they use NAPT. They do support NAT traversal but do not host TURN. If the T-Mo USA and Sprint deal goes through they will have some huge challenges to efficiently combin= e things. They also use the exact same SGW/PGW vendor and hardware model as we do. So does Verizon (Cisco ASR5500). They may still have some of the older ASR5000 and Verizon may too. Neither has a virtualized solution in production. We have both Cisco and Affirmed carrying live paying production traffic. We stopped adding hardware based solutions more than a year ago. We also have virtualized MME (Ericsson) since last year and Nokia is in certification testing. We have virtualize most of the IMS domain and mobility systems except RAN. We are working on RAN. We are using CUPS for launch of 5G this year. Still debating the options longer term but we also need standards to make decisions. Back to unsolicited. We all support methods so traffic flows like video chat can work but key is we all work directly with those ASP=92s (Application service providers). Al= l of us have special handling of traffic to Amazon, Apple, Google and so on. The difference is in the functionality, scale and number of ASP=92s support where we smoke everyone! So you can build an App for Apple iOS or Google=92s Android and it can work well. You can also do peer-to-peer but only as long as the setup goes thru servers that are enabled. In our case you could also use our API=92s. Mobil= e to mobile is only allowed when enabled. While unsolicited is the common term used in the mobile industry perhaps unwanted or undesired gives a better view. User=92s don=92t want SPAM and t= hey don=92t want threats (risk of device being compromised). But if they downlo= ad and setup an App they do want that to work. It also gets to the definition of Internet. In the US very little mobile traffic ever goes over the =93Internet=94. It=92s all protected private net= works between mobile operators and data centers. Even inside the data centers the traffic uses servers dedicated to mobile users. Within the data center it may go from mobile servers to non-mobile servers. We also have major hosting companies and cloud providers covered. A startup may rent capacity from Amazon but mobile traffic goes over a protected (encrypted) path on a private network to Amazon data centers worldwide. Sam= e for most major hosting facilities worldwide. This is true for most mobile operators and often even when they don=92t kno= w it. There are some places where things are different like China. Everyone does what they are told to do in China or you won=92t be in China. Lots of complicated partnerships to make anything work. So your traffic is visible to some parties when there is no other option. All of the big CDN solutions and CDN supplies work with this model. So Akamai for Verizon mobiles is different from Akamai on AT&T mobiles. In our case this only goes to Akamai servers in AT&T hosting facilities. So for al= l of the major mobile operators in the entire Western Hemisphere. In reality it=92s true for all mobile operators in Western Hemisphere to any significa= nt service even when they don=92t know it. It doesn=92t matter who is the loca= l LEC or what ISP the mobile operator uses. We even protect open WiFi and I wanted to protect all mobile =93Internet services traffic=94 but that is in the future. We detect if a VPN is in use= or if one starts to stay out of the way in the current open WiFi case. We can split and run traffic from UE over one VPN while running tethered (mobile hotspot, USB, Bluetooth) traffic outside the VPN or in a different VPN. We even support corporate VPN so the traffic actually goes over private networ= k to corporate servers instead of coming in their =93Internet=94 connection. You may ask about ISP peering points but in those cases for partnered content we use encryption. A company could use Level3 as an ISP then serve Internet content on that connection. If we don=92t have a partnership deal with that company then traffic would be protected to our closest to content peering point with Level3. Another way to say it is for the top X websites by clicks/hits, top Y sites by volume (bytes) or top Z sites by connection for the busiest hour, busy period, day of week, etc. for any operator you can draw a line. Above that line the traffic is secured mobile to/from content. Below the line it may b= e secured or it may not. The rules for handling the Internet in a given country can be very complex. In many countries you can count on one or two fingers your options as a mobile operator when they are not THE LEC/ISP. Sent from my iPhone On May 8, 2018, at 7:44 AM, Tom Herbert > wrote: On Tue, May 8, 2018 at 6:39 AM, Lorenzo Colitti > wrote: FWIW, I believe there are large operators that do not block unsolicited inbound traffic to mobile networks. One of them is T-Mobile. I should hope that a majority of access networks don't do that, lest it would be impossible to deploy new transport protocols (like QUIC for instance) and the ossification of the Internet would be complete. Tom On Fri, May 4, 2018 at 7:53 AM, FIGURELLE, TERRY F > wrote: No. We have always block unsolicited traffic from the Internet and it is too complicated to discuss here. We even did this way back for CDPD. For dedicated APN's we allow the enterprise to tell us what rules they want to protect the mobile from their network and what traffic to not allow from the mobile. This is one of the reasons firewalls and CNAT cost more if they support mobility features. We spent a lot of time working with potential vendors. Since this started with usage based rate plans for all mobile operators the subscriber would get charged if we allowed spam from the Internet or from other mobiles. So this has always been block and vendors have features to help out in 3GPP elements. A GGSN with anti-spoofing not disabled doesn'= t allow traffic to a mobile that doesn't match an entry in the flow table. We have hundreds of policy rules that get enabled from the PCRF/PCF on the PGW(PCEF)/UPF. We also enabled our proxies to be transparent proxy-TDF. Tha= t means they also have policy interfaces and we do a bunch of stuff here including processing signed manifests. Plus the rules are pushed on the control plane not the data plane and it includes UE, RAN, SGW/PGW/UPF and i= f applicable TDF's and AS's. We can push rules to the UE that allow, (drop), route/path (e.g. bearer). We even have to have some country specific treatment (a bigger challenge we had for vehicles using our Connected Car solution like GM OnStar). While a mobile could get hacked and it could break the flow rule treatment some of that is down in the 3GPP chipset. But we are aware of the risk and we have counter measures as best we can. I should point out that these flow rules go into RAN too and rules have a direction (from UE, to UE or both). My opinion is that malware, spoofing, DOS, DDOS and any other threat is a serious operational issue. That is the best place to deal with it because standards could never keep pace. We and other operators request features from vendors and they also come up with stuff as a value add. Simply stated the solution needs to be protected but we don't need tons of detail in every standard. I would never say don't be concerned about something. I just don't think every standard needs details on spoofing, DOS and other threats. -----Original Message----- From: Tom Herbert > Sent: Thursday, May 03, 2018 3:00 PM To: Joel M. Halpern > Cc: FIGURELLE, TERRY F >; Dirk.von-Hu= go@telekom.de; Tom Herbert >; ila@ietf.org; Alberto Rodriguez-Natal >; 5GANGIP <5gang= ip@ietf.org> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement] On Thu, May 3, 2018 at 2:45 PM, Joel M. Halpern > wrote: I am missing something in your DDOS issue. At first, I thought the real issue (which you seem to be suggesting here) was DDOS from the Internet, using spoofed or non-spoofed addresses (with bot farms, there is much less need for or relevance of spoofing). But then I tried to map it to the cases we have for using ILA. The primary case I have heard about is to use ILA for UE<->UE and UE<->EdgeComputing traffic. If so, just filter all SIRs on incoming packets from the Internet. They aren't legal there. And similarly, if one uses LISP within the operator domain, we can block whatever blocks we use for EIDs for such local traffic. Joel, I'm not sure I understand what "filtering SIRs from the Internet" means. A SIR address is a globally visible address for devices like UEs. So an Internet sender may legitimately send packets to SIR addresses, and also an Internet attacker could easily spew a whole bunch of packets with both spoofed source addresses and spoofed UE addresses. So you'd want to allow the legitimate traffic but block the attacking packets-- this isn't feasible since it's impossible to distinguish the bad from the good packets. If we want to use id-locator split of any kind for handling traffic to / from the Internet, then we have to understand how that is supposed to work, and why, before we need to evaluate DDOS implications of a solution. For LISP,the working group has explicitly said that Inter-wide deployment is out of scope. Net: I do not see in currently described deployments, an issue that differentiates LISP from ILA in these regards. And Terry has very clearly spelled out that for mobile operators spoofing from UEs is not considered an issue that the infrastructure needs to deal wih. But there may be a whole network infrastructure of hundreds or even thousands of users behind a UE, and there's no guarantee that that infrastructure properly supports anti-spoofing. This basically this case has the same problem as in the Internet case. Tom Yours, Joel On 5/3/18 5:33 PM, Tom Herbert wrote: On Thu, May 3, 2018 at 2:23 PM, FIGURELLE, TERRY F > wrote: In the case of current 3GPP operators all the major vendors support anti-spoofing. The default was on for all but one vendor which got corrected the last time I did an RFP for EPC. So by configuration the GGSN/PGW/PGW-U/UPF will not allow the UE to send packets that don't match either the exact IP address or pushed subnet or prefix delegation that was sent in response to the APN create message. Obviously if we remove GTP encapsulation that protect MAY need to be enhanced towards an EDGE element. Terry, Even so, the whole Internet does not require anti-spoofing, nor do I believe that operators could require all down stream network that are connected to support anti-spoofing. These are where the DOS attacks orginate. The problem is when caches are being driven by user taffic from these external networks, mitigations to detect DOS by IP source address don't work without anti-spoofing (but even if they had anti-spoofing that still doesn't work when under a DDOS). Tom This is being covered as part of our participation in an open source vEPC (virtualize EPC, hypervisor, blah, blah, blah). So there will be a micro service firewall that can be deploy at the edge plus we already have planned support for big network infrastructure vendors and 3GPP supplies (Cisco, Juniper, Ericsson, Nokia, Huawei, ...) to cover this. Since this can be a non-3GPP element we will get this into ONAP. Thus we have this covered both for 3GPP nodes, micro services and open source efforts. To give examples without vendor names there are GTP aware firewalls that some operators use. It really just another capability in carrier class and business class firewalls (had to add it to load balancers, CNAT/NAT, some Wi-Fi routers and to our DNS solution which uses open source). Obviously this will be supported via a RADIUS feed for backwards compatibility. Today most GTP firewall simply follow the GTP-C signaling to learn the IP address(es) assigned to the UE for an APN. If we remove GTP from user plane that doesn't mean we remove it from control plane or for all hops. However, we will likely push to a micro service at the cell plus I need to check if we ever ask RAN vendors to support this. I'll add this for 5G but we already did that RFP so it's a change order (yuck). I am not good at wordsmithing but I suggest there be some paragraph that covers network elements that can except a RADIUS feed. I need to talk to our standards team to see if we want this on T8 (probably). So today for all AT&T, Verizon, Vodaphone, ..... I know or am fairly confident they have anti spoofing tuned on in the GGSN/PGW/UPF plus I know they can turn this on per APN. Not sure why anyone would disable this since we if you are delegating a subnet to a Wi-Fi hotspot (instead of the typical private addressing they use). We actually don't need any 3GPP changes since this is already covered using RADIUS to pass the information where it needs to go. I suspect most will leverage their caching SPR/UDR which already has the information. Even the GGSN we launched EDGE/GPRS when I was much younger supported anti-spoofing and many vendors cover this via a number of methods (e.g. COPS works for older junos and RADIUS for Cisco IOS releases ). My suggestion is that I am willing to help whoever wants to craft the paragraph because I suck at that (fortunately I am good at other things). I don't think we need any changes to any standards to cover this since we already cover this and already are covering this if we strip out GTP (at least for one leg). I'll make sure it gets into our RAN requirements if not there since that may be the best place for that edge. Plus I'll get it covered thru the ONAP open source effort we drove (we donated the software to the open source effort). That means FM, PM, CM and IM will be covered in some future ONAP release (takes time but faster than 3GPP). It's a bit debatable what is RAN when using virtualized network functions (VNF) and a bunch of open source stuff that we put it into all of the needed elements like SDN, firewall, load balancer (not sure that's needed at cell site but it is for core DNS, proxy-TDF and CNAT) out at the cell site. We aren't there yet (still physical eNB/NR and obviously we need hardware assist even with virtualization plus tight control of timing). I am looking forward to when we start using containers. For our core I am sure we will use our UDR VNF as the cache for whatever comes out of this effort in final standards. The information is already there (IMEI, device vendor, subscription information, UE IP address, APN, etc.). If we do anything it would be to augment an open source and if needed a 3GPP. I don't think we need any changes but it's always best to verify. For current RAN an anti-spoofing feature would come from EMS which can be via ONAP. I don't think that is a standards effort thing since it's a feature which may or may not already be covered but it will be in future RAN releases probably starting with eNB/NR with some vendor release if it's not already a feature. I want to say Ericsson and Nokia already can do this in eNB but I need to go thru channels to ask. So maybe that paragraph recommends implementing anti-spoofing at all edges and leaves it at that. Or we could say all edges including RAN if that makes people happy. -----Original Message----- From: 5gangip <5gangip-bounces@ietf.org> O= n Behalf Of Tom Herbert Sent: Thursday, May 03, 2018 10:46 AM To: Dirk.von-Hugo@telekom.de Cc: Tom Herbert >; Joel M. = Halpern >; ila@ietf.org; Alberto Rodriguez-Natal >; 5GANGIP <5gang= ip@ietf.org> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement] On Thu, May 3, 2018 at 9:23 AM, > wrote: Hi Tom, I understand you correctly that DDOS attacks can never be completely prevented whatever protocol you use. It will however always remain related to known IP addresses and the more versatile these are handled a mitigation strategy could be designed. Dirk, I disagree. IP addresses can too easily be spoofed, it's easy to hide identity behind a NAT (see discussion about CGNAT and law enforcement on int-area list), and trying to turn off individual addresses doesn't work if it's a DDOS. This is nothing new. For instance, content providers have long accepted the fact that they can't prevent SYN attacks and there's little point to trying to go back to source IP address (they are always spoofed in a SYN attack). The better strategy is to absorb the attack and minimize the negative effects so that the attack is not worth the effort. As you may have seen we mention improved handling of mapping systems and subsequently of DDOS protection also in the current version of our PS document https://urldefense.proofpoint.com/v2/url?u=3Dhttps- 3A__github.com_bsarikaya_atic_blob_master_atick- 5Fproblemstatement.3.txt&d=3DDwICAg&c=3DLFYZ- o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4 OstVOL1OQiA98fgBJ9c1Gjo&s=3DjLL_9a56R8Ic8o3uJcR8mrF- JkzLL97h8rmZT_EqXnQ&e=3D which Behcet has announced recently. May I ask you to please comment on the ideas outlined there? I don't see much difference in the latest version. For a problem statement, I still think there is too much focus on the solutions and not nearly enough description of what the actual problems are to be solved. Tom Thanks! Best Regards Dirk -----Original Message----- From: 5gangip [mailto:5gangip-bounces@ietf.org] On Behalf Of Tom Herbert Sent: Mittwoch, 2. Mai 2018 01:20 To: Joel M. Halpern > Cc: Tom Herbert >; ila@ietf= .org; Alberto Rodriguez-Natal >= ; 5GANGIP <5gangip@ietf.org> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement] On Tue, May 1, 2018 at 3:49 PM, Joel M. Halpern > wrote: You seem to be saying that even though not all DDOS attacks are structurally the same, and even though if ILA were widely adopted not all ILA networks would be structurally the same, there should nonetheless be one required qay of handling DDOS? Yes, at least as core default in the protocol. It's precisely _because_ not all DDOS attacks are structurally the same. An attacker is not going to conform to to our expectations of what they should be doing, so if we enable LISP option N to mitigate one form of attack, they will just use another attack that isn't mitigated. For example, if the mitigation is to identify attackers by address when requests from the address exceed a threshold then this works as long as the attacker strikes from one machine, but it falls apart if the attacker launches a DDOS attack from several hosts where requests from none of the hosts exceed the threshold. The ILA model works because it assumes there is no absolute way to prevent the the worst case attack on a cache which is to completely kill it (i.e. drive it to 0% hit rate). In this state the behavior sub-optimal routing, which is much better than loss of service. This is not dependent on the structure of the attack, network topology, or the network operator getting the configuration just right-- it is inherent in the protocol. Tom Yours, Joel On 5/1/18 6:32 PM, Tom Herbert wrote: On Tue, May 1, 2018 at 2:59 PM, Alberto Rodriguez-Natal > wrote: On Tue, May 1, 2018 at 10:16 AM, Tom Herbert > wrote: I think you've misunderstood my position. Caches are _very_ important to eliminate the cost triangular routing (latency, average path load). This reduces latency and reduces average load on ILA-Rs. But, and this is the critical part, caches are only an _optimization_ in ILA. That means if the cache is rendered ineffective (like by a well crafted DOS attack) then the only effect is that the optimization is loss (i.e. greater latency due to triangular router)-- this is quantitively the worst effect of the attack on an ILA cache. This can be contrasted that to LISP where the worst case effects of a DOS attack on the cache is loss of service for users (infinite latency since packets can be dropped or indefinitely blocked on a cache miss). This can be misleading. This is not comparing LISP vs ILA, this is comparing the models of Request/Reply at the edge vs Notifications (aka Redirects) at the core. Both LISP-CP and ILAMP support these two models. Besides, this is assuming an scenario where the only feasible DOS mitigation is absorbing the attack. There are other scenarios where other countermeasures are possible. For instance, if you have a deployment where you can prevent address spoofing, counting and blocking misbehaving nodes offers similar DOS protection and requires way less infrastructure resources. Alberto, The answer to my question of how does LISP address DOS attacks seems to be "there are many options". Some of the options are to assume that DOS does not exist in the network, some assume external configuration like address spoofing is enabled, some assume that attacks can be identified and can be stopped at the source, some might assume that everything is okay because there's never been a DOS attack before. I have yet to see the effects of any of these quantified, and none of these state how the LISP _protocol_ itself addresses DOS. It may seem counter-intuitive, but offering a bunch of options really is not necessarily a good thing-- sometime less is more. To put this another way LISP has been rejected from Linux precisely because of its susceptibility to DOS. If you were to try again and the best answer to the DOS question is that it's up to the operator to figure out the right options to use, then I believe it would be soundly rejected again. That approach does not work at scale. Tom _______________________________________________ ila mailing list ila@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps- 3A__www.ietf.org_ma ilman_listinfo_ila&d=3DDwICAg&c=3DLFYZ- o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl 2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4OstVOL1OQiA98fgBJ9c1Gjo&s=3DBO3snt8C RQ gy1xwhx2CY10VUbM_rgntgpV9k3-Cskd8&e=3D _______________________________________________ 5gangip mailing list 5gangip@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps- 3A__www.ietf.org_mail man_listinfo_5gangip&d=3DDwICAg&c=3DLFYZ- o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl 2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4OstVOL1OQiA98fgBJ9c1Gjo&s=3DFnQLMire MiKC SkPaOGFCybzDc2i2y49Cgtbl6mCLc9c&e=3D _______________________________________________ 5gangip mailing list 5gangip@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps- 3A__www.ietf.org_mailman_listinfo_5gangip&d=3DDwICAg&c=3DLFYZ- o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4 OstVOL1OQiA98fgBJ9c1Gjo&s=3DFnQLMireMiKCSkPaOGFCybzDc2i2y49Cgtbl6mC Lc9c&e=3D _______________________________________________ 5gangip mailing list 5gangip@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_5gangip&d=3DDwIFaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl2p= aJIf4zw&m=3DZjufntGbjGmejHErlAs_yMfAbCNZooJ8tcy1HcoFqYQ&s=3DTgdJsREjP7miSUi= 64kzMgXcx0cGF4oVYbcT14WlpKJE&e=3D --_000_D64AA7DF39D94CC89A88944F421E9A6Fattcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable When you need to manage how usage is rated that plays a big role in how pac= kets are handled. There it makes a whole lot of difference how the 3GPP pol= icy rules are built. All 3GPP operators of significance do this and where y= ou discard packets makes a huge difference. If you intentionally discard packets that have already been me= tered it is illegal in some countries.

But let=92s take this back to where it began.

SPOOFING:

1. I=92ve checked and NR edge can be or is covered by RAN (some RAN do= esn=92t exist yet). Thus it=92s not possible for a UE to spoof IP addresses= because the RAN can protect the upstream. It is already protected today by= SGW/PGW and UPF.

You can also protect for 3GPP RAN and WiFi via ePDG by installing a po= licy rule. The rule has the valid subnet/prefix for the UE in the 5-Tuple. = There is actually short hand in rule definitions which just substitutes the= UE IP/subnet when it gets to PGW (before flowing down to RAN and UE).

2. EDGE use cases require tight coordination all the way down to trans= port to meet requirements. This includes definition of address ranges to be= used in both directions exchanged between all parties involved. We actuall= y have to go into great detail to make sure specific protocols can work. This also requires non-default CoS/= QoS treatment which requires 3-tuple knowledge before the first packet. Thu= s we must know the flow before even the first packet is sent. Since you kno= w what is valid, it trivial to block at the services edge what isn=92t valid.

FYI

VoLTE smartphone requires a proxy on the general purpose APN. I checke= d and none of the vendors have or are working on a proxy that can get an un= expected SYN from services edge.

This is true for CGNAT too. You need some form of NAT traversal and th= ese all require a packet up to get things plumbed.

Sent from my iPhone

On May 9, 2018, at 8:21 AM, Tom Herbert <tom@herbertland.com> wrote:

On Wed, May 9, 2018 at 8:08 AM, Tom Herbert <tom@herbertland.com> wrote:
On Tue, May 8, 2018 at 10:48 AM, FIGURELLE,= TERRY F <tf2934@att.com> wrote= :
Nope, we handle QUIC. Spent lots of time wi= th Google on that one. Many

Terry,

QUIC was only an example. I'm am concerned = with the next QUIC, next
real time gaming protocol, next application= protocol that might
benefit from a different transport. There's= no reason to believe that
QUIC and TCP constitutent the complete set = of transport protocols that
we'll ever need and that those are the only= ones we should be allowed
to use on the Internet. NATPT and proxies e= nforce their concept as to
what transport protocols are allowed. Proxi= es introduce the addional
complexity in that they make it harder to d= eploy new options and make
it impossible to use end to end transport h= eader authentication.

This is why protocols like ILA are explicit= ily independent of
transport layer. They don't require DPI, th= ey don't require flow state
to be tracked in the network, and they don'= t require packets of a flow
to always hit the same devices in the netwo= rk. They can however solve
problems at the network layer (the aforemen= tioned privacy in
addressing for example).


I should also mention that blocking unsoliticted traffic and providin= g
flow specific services are still relevant, but these can also be done=
in a transport independent manner. See FAST proposal
(draft-herbert-fast-00).

Tom

Tom


people here have worked at T-Mobile USA and= the flip. T-Mo USA does block
unsolicited but this gets deep into the det= ails of unsolicited and fine
lines of block or do not support or enable = it to happen.

T-Mobile by country does have differences. = They got a lot more address space
from RIPE than T-Mo USA got from ARIN. So i= n the states they use NAPT. They
do support NAT traversal but do not host TU= RN. If the T-Mo USA and Sprint
deal goes through they will have some huge = challenges to efficiently combine
things.

They also use the exact same SGW/PGW vendor= and hardware model as we do. So
does Verizon (Cisco ASR5500). They may stil= l have some of the older ASR5000
and Verizon may too. Neither has a virtuali= zed solution in production. We
have both Cisco and Affirmed carrying live = paying production traffic. We
stopped adding hardware based solutions mor= e than a year ago. We also have
virtualized MME (Ericsson) since last year = and Nokia is in certification
testing. We have virtualize most of the IMS= domain and mobility systems
except RAN. We are working on RAN.

We are using CUPS for launch of 5G this yea= r. Still debating the options
longer term but we also need standards to m= ake decisions.

Back to unsolicited.

We all support methods so traffic flows lik= e video chat can work but key is
we all work directly with those ASP=92s (Ap= plication service providers). All
of us have special handling of traffic to A= mazon, Apple, Google and so on.
The difference is in the functionality, sca= le and number of ASP=92s support
where we smoke everyone!

So you can build an App for Apple iOS or Go= ogle=92s Android and it can work
well. You can also do peer-to-peer but only= as long as the setup goes thru
servers that are enabled. In our case you c= ould also use our API=92s. Mobile
to mobile is only allowed when enabled.

While unsolicited is the common term used i= n the mobile industry perhaps
unwanted or undesired gives a better view. = User=92s don=92t want SPAM and they
don=92t want threats (risk of device being = compromised). But if they download
and setup an App they do want that to work.=

It also gets to the definition of Internet.= In the US very little mobile
traffic ever goes over the =93Internet=94. = It=92s all protected private networks
between mobile operators and data centers. = Even inside the data centers the
traffic uses servers dedicated to mobile us= ers. Within the data center it
may go from mobile servers to non-mobile se= rvers.

We also have major hosting companies and cl= oud providers covered. A startup
may rent capacity from Amazon but mobile tr= affic goes over a protected
(encrypted) path on a private network to Am= azon data centers worldwide. Same
for most major hosting facilities worldwide= .

This is true for most mobile operators and = often even when they don=92t know
it. There are some places where things are = different like China. Everyone
does what they are told to do in China or y= ou won=92t be in China. Lots of
complicated partnerships to make anything w= ork. So your traffic is visible
to some parties when there is no other opti= on.

All of the big CDN solutions and CDN suppli= es work with this model. So
Akamai for Verizon mobiles is different fro= m Akamai on AT&T mobiles. In our
case this only goes to Akamai servers in AT= &T hosting facilities. So for all
of the major mobile operators in the entire= Western Hemisphere. In reality
it=92s true for all mobile operators in Wes= tern Hemisphere to any significant
service even when they don=92t know it. It = doesn=92t matter who is the local LEC
or what ISP the mobile operator uses.

We even protect open WiFi and I wanted to p= rotect all mobile =93Internet
services traffic=94 but that is in the futu= re. We detect if a VPN is in use or
if one starts to stay out of the way in the= current open WiFi case. We can
split and run traffic from UE over one VPN = while running tethered (mobile
hotspot, USB, Bluetooth) traffic outside th= e VPN or in a different VPN. We
even support corporate VPN so the traffic a= ctually goes over private network
to corporate servers instead of coming in t= heir =93Internet=94 connection.

You may ask about ISP peering points but in= those cases for partnered
content we use encryption. A company could = use Level3 as an ISP then serve
Internet content on that connection. If we = don=92t have a partnership deal
with that company then traffic would be pro= tected to our closest to content
peering point with Level3.

Another way to say it is for the top X webs= ites by clicks/hits, top Y sites
by volume (bytes) or top Z sites by connect= ion for the busiest hour, busy
period, day of week, etc. for any operator = you can draw a line. Above that
line the traffic is secured mobile to/from = content. Below the line it may be
secured or it may not.

The rules for handling the Internet in a gi= ven country can be very complex.
In many countries you can count on one or t= wo fingers your options as a
mobile operator when they are not THE LEC/I= SP.

Sent from my iPhone

On May 8, 2018, at 7:44 AM, Tom Herbert <= ;tom@quantonium.net> wrote:



On Tue, May 8, 2018 at 6:39 AM, Lorenzo Col= itti <lorenzo@google.com> w= rote:

FWIW, I believe there are large operators t= hat do not block unsolicited
inbound traffic to mobile networks. One of = them is T-Mobile.

I should hope that a majority of access net= works don't do that, lest it
would be impossible to deploy new transport= protocols (like QUIC for
instance) and the ossification of the Inter= net would be complete.

Tom

On Fri, May 4, 2018 at 7:53 AM, FIGURELLE, = TERRY F <tf2934@att.com> wrote:=

No. We have always block unsolicited traffi= c from the Internet and it is
too complicated to discuss here.

We even did this way back for CDPD. For ded= icated APN's we allow the
enterprise to tell us what rules they want = to protect the mobile from their
network and what traffic to not allow from = the mobile. This is one of the
reasons firewalls and CNAT cost more if the= y support mobility features. We
spent a lot of time working with potential = vendors.

Since this started with usage based rate pl= ans for all mobile operators
the subscriber would get charged if we allo= wed spam from the Internet or
from other mobiles. So this has always been= block and vendors have features
to help out in 3GPP elements. A GGSN with a= nti-spoofing not disabled doesn't
allow traffic to a mobile that doesn't matc= h an entry in the flow table. We
have hundreds of policy rules that get enab= led from the PCRF/PCF on the
PGW(PCEF)/UPF. We also enabled our proxies = to be transparent proxy-TDF. That
means they also have policy interfaces and = we do a bunch of stuff here
including processing signed manifests. Plus= the rules are pushed on the
control plane not the data plane and it inc= ludes UE, RAN, SGW/PGW/UPF and if
applicable TDF's and AS's. We can push rule= s to the UE that allow, (drop),
route/path (e.g. bearer). We even have to h= ave some country specific
treatment (a bigger challenge we had for ve= hicles using our Connected Car
solution like GM OnStar).

While a mobile could get hacked and it coul= d break the flow rule
treatment some of that is down in the 3GPP = chipset. But we are aware of the
risk and we have counter measures as best w= e can. I should point out that
these flow rules go into RAN too and rules = have a direction (from UE, to UE
or both).

My opinion is that malware, spoofing, DOS, = DDOS and any other threat is a
serious operational issue. That is the best= place to deal with it because
standards could never keep pace. We and oth= er operators request features
from vendors and they also come up with stu= ff as a value add.

Simply stated the solution needs to be prot= ected but we don't need tons
of detail in every standard.

I would never say don't be concerned about = something. I just don't think
every standard needs details on spoofing, D= OS and other threats.


-----Original Message-----
From: Tom Herbert <tom@quantonium.net>
Sent: Thursday, May 03, 2018 3:00 PM=
To: Joel M. Halpern <jmh@joelhalpern.com>
Cc: FIGURELLE, TERRY F <tf2934@att.com>; Dirk.von-Hugo@telekom.de; T= om
Herbert <tom@herbertland.com>; ila@ietf.org; Alberto Rodriguez-Natal
<rodrigueznatal@gmail.com>; 5GANGIP <5gangip@ietf.org>
Subject: Re: [5gangip] [Ila] ILA forwaring = [Was Re: Problem Statement]

On Thu, May 3, 2018 at 2:45 PM, Joel M. Hal= pern <jmh@joelhalpern.com>=
wrote:
I am missing something in your DDOS issue.<= /span>

At first, I thought the real issue (which y= ou seem to be suggesting
here) was DDOS from the Internet, using spo= ofed or non-spoofed
addresses (with bot farms, there is much le= ss need for or relevance
of
spoofing).

But then I tried to map it to the cases we = have for using ILA.
The primary case I have heard about is to u= se ILA for UE<->UE and
UE<->EdgeComputing traffic.  If = so, just filter all SIRs on incoming
packets from the Internet.  They aren'= t legal there.  And similarly,
if one uses LISP within the operator domain= , we can block whatever
blocks we use for EIDs for such local traff= ic.

Joel,

I'm not sure I understand what "filter= ing SIRs from the Internet"
means. A SIR address is a globally visible = address for devices like
UEs. So an
Internet sender may legitimately send packe= ts to SIR addresses, and
also an
Internet attacker could easily spew a whole= bunch of packets with both
spoofed
source addresses and spoofed UE addresses. = So you'd want to allow the
legitimate traffic but block the attacking = packets-- this isn't
feasible since it's
impossible to distinguish the bad from the = good packets.


If we want to use id-locator split of any k= ind for handling traffic
to
/ from the Internet, then we have to unders= tand how that is supposed
to work, and why, before we need to evaluat= e DDOS implications of a
solution.  For LISP,the working group = has explicitly said that
Inter-wide deployment is out of scope.

Net: I do not see in currently described de= ployments, an issue that
differentiates LISP from ILA in these regar= ds.  And Terry has very
clearly spelled out that for mobile operato= rs spoofing from UEs is
not
considered an issue that the infrastructure= needs to deal wih.

But there may be a whole network infrastruc= ture of hundreds or even
thousands of users behind a UE, and there's= no guarantee that that
infrastructure properly supports anti-spoof= ing. This basically this
case has the
same problem as in the Internet case.

Tom


Yours,
Joel


On 5/3/18 5:33 PM, Tom Herbert wrote:

On Thu, May 3, 2018 at 2:23 PM, FIGURELLE, = TERRY F <tf2934@att.com>=
wrote:

In the case of current 3GPP operators all t= he major vendors support
anti-spoofing. The default was on for all b= ut one vendor which got
corrected the last time I did an RFP for EP= C. So by configuration
the GGSN/PGW/PGW-U/UPF will not allow  = ;the UE to send packets that
don't match either the exact IP address or = pushed subnet or prefix
delegation that was sent in response to the= APN create message.
Obviously if we remove GTP encapsulation th= at protect MAY need to
be
enhanced towards an EDGE element.

Terry,

Even so, the whole Internet does not requir= e anti-spoofing, nor do I
believe that operators could require all do= wn stream network that
are
connected to support anti-spoofing. These a= re where the DOS attacks
orginate. The problem is when caches are be= ing driven by user taffic
from these external networks, mitigations t= o detect DOS by IP source
address don't work without anti-spoofing (b= ut even if they had
anti-spoofing that still doesn't work when = under a DDOS).

Tom



This is being covered as part of our partic= ipation in an open
source
vEPC (virtualize EPC, hypervisor, blah, bla= h, blah). So there will
be a micro service firewall that can be dep= loy at the edge plus we
already have planned support for big networ= k infrastructure vendors
and 3GPP supplies (Cisco, Juniper, Ericsson= , Nokia, Huawei, ...) to
cover this. Since this can  be a non-3= GPP element we will get this
into
ONAP.

Thus we have this covered both for 3GPP nod= es, micro services and
open source efforts. To give examples witho= ut vendor names there
are
GTP aware firewalls that some operators use= . It really just another
capability in carrier class and business cl= ass firewalls (had to
add
it to load balancers, CNAT/NAT, some Wi-Fi = routers and to our DNS
solution which uses open source).  Obv= iously this will be supported
via a RADIUS feed for backwards compatibili= ty. Today most GTP
firewall simply follow the GTP-C signaling = to learn the IP
address(es) assigned to the UE for an APN. = If we remove GTP from
user plane that doesn't mean we remove it f= rom control plane or for
all hops. However, we will likely push to a= micro service at the
cell plus I need to check if we ever ask RA= N vendors to support
this. I'll add
this for 5G but we already did that RFP so = it's a change order (yuck).

I am not good at wordsmithing but I suggest= there be some paragraph
that covers network elements that can excep= t a RADIUS feed. I need
to talk to our standards team to see if we = want this on T8
(probably).

So today for all AT&T, Verizon, Vodapho= ne,  ..... I know or am
fairly confident they have anti spoofing tu= ned on in the
GGSN/PGW/UPF plus I know they can turn this= on per APN. Not sure
why
anyone would disable this since we if you a= re delegating a subnet
to
a Wi-Fi hotspot (instead of the typical pri= vate addressing they
use).

We actually don't need any 3GPP changes sin= ce this is already
covered using RADIUS to pass the informatio= n where it needs to go.
I
suspect most will leverage their caching SP= R/UDR which already has
the information. Even the GGSN we launched = EDGE/GPRS when I was
much
younger supported anti-spoofing and many ve= ndors cover this via a
number of methods (e.g. COPS works for olde= r junos and RADIUS for
Cisco
IOS releases ).

My suggestion is that I am willing to help = whoever wants to craft
the paragraph because I suck at that (fortu= nately I am good at
other
things).

I don't think we need any changes to any st= andards to cover this
since we already cover this and already are= covering this if we
strip out GTP (at least for one leg). I'll = make sure it gets into
our RAN requirements if not there since tha= t may be the best place
for that edge. Plus I'll get it covered thr= u the ONAP open source
effort we drove (we donated the software to= the open source
effort).
That means FM, PM, CM and IM will be covere= d in some future ONAP
release (takes time but faster than 3GPP).<= /span>

It's a bit debatable what is RAN when using= virtualized network
functions
(VNF) and a bunch of open source stuff that= we put it into all of
the needed elements like SDN, firewall, loa= d balancer (not sure
that's needed at cell site but it is for co= re DNS, proxy-TDF and
CNAT) out at the cell site. We aren't there= yet (still physical
eNB/NR and obviously we need hardware assis= t even with
virtualization plus tight control of timing= ). I am looking forward
to when we
start using containers.

For our core I am sure we will use our UDR = VNF as the cache for
whatever comes out of this effort in final = standards. The
information is already there (IMEI, device = vendor, subscription
information, UE IP address, APN, etc.). If = we do anything it would
be to augment an open source and if needed = a 3GPP. I don't think we
need
any changes but it's always best to verify.=
For current RAN an anti-spoofing feature wo= uld come from EMS which
can be via ONAP. I don't think that is a st= andards effort thing
since it's a feature which may or may not a= lready be covered but it
will be in future RAN releases probably sta= rting with eNB/NR with
some vendor release if it's not already a f= eature. I want to say
Ericsson and Nokia already can do this in e= NB but I need to go thru
channels to ask.

So maybe that paragraph recommends implemen= ting anti-spoofing at
all
edges and leaves it at that. Or we could sa= y all edges including
RAN
if that makes people happy.

-----Original Message-----
From: 5gangip <5gangip-bounces@ietf.org> On Behalf Of Tom Herber= t
Sent: Thursday, May 03, 2018 10:46 AM
To: Dirk.von-Hugo@telekom.de
Cc: Tom Herbert <tom@herbertland.com>; Joel M. Halpern
<= jmh@joelhalpern.com>; ila@ietf.org; Alberto Rodriguez-Natal
<rodrigueznatal@gmail.com>; 5GANGIP <5gangip@ietf.org>
Subject: Re: [5gangip] [Ila] ILA forwaring = [Was Re: Problem
Statement]

On Thu, May 3, 2018 at 9:23 AM,  <<= a href=3D"mailto:Dirk.von-Hugo@telekom.de">Dirk.von-Hugo@telekom.de>= wrote:

Hi Tom,
I understand you correctly that DDOS attack= s can never be
completely

prevented whatever protocol you use.=

It will however always remain related to kn= own IP addresses and
the more

versatile these are handled a mitigation st= rategy could be
designed.

Dirk,

I disagree. IP addresses can too easily be = spoofed, it's easy to
hide identity behind a NAT (see discussion = about CGNAT and law
enforcement on int-area list), and trying t= o turn off individual
addresses doesn't work if it's a DDOS. This= is nothing new. For
instance, content providers have long accep= ted the fact that they
can't prevent SYN attacks and there's littl= e point to trying to go
back to source IP address (they are always = spoofed in a SYN
attack). The better strategy is to absorb t= he attack and minimize
the negative effects so that the attack is = not worth the effort.

As you may have seen we mention improved ha= ndling of mapping
systems

and subsequently of DDOS protection also in= the current version of
our PS document https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
3A__github.com_bsarikaya_atic_blob_master_a= tick-
5Fproblemstatement.3.txt&d=3DDwICAg&= ;c=3DLFYZ-

o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl2paJ= If4zw&m=3DzYkPItjuHMuGlJXD5K_4
OstVOL1OQiA98fgBJ9c1Gjo&s=3DjLL_9a56R8I= c8o3uJcR8mrF-
JkzLL97h8rmZT_EqXnQ&e=3D  which Be= hcet has announced recently.

May I ask you to please comment on the idea= s outlined there?


I don't see much difference in the latest v= ersion. For a problem
statement, I still think there is too much = focus on the solutions
and not nearly enough description of what t= he actual problems are
to be solved.

Tom

Thanks!


Best Regards
Dirk

-----Original Message-----
From: 5gangip [mailto:5gangip-bounces@ietf.org] On Behalf Of Tom
Herbert
Sent: Mittwoch, 2. Mai 2018 01:20
To: Joel M. Halpern <jmh@joelhalpern.com>
Cc: Tom Herbert <tom@herbertland.com>; ila@ietf.org; Alberto
Rodriguez-Natal <rodrigueznatal@gmail.com>; 5GANGIP
<5ga= ngip@ietf.org>
Subject: Re: [5gangip] [Ila] ILA forwaring = [Was Re: Problem
Statement]

On Tue, May 1, 2018 at 3:49 PM, Joel M. Hal= pern
<= jmh@joelhalpern.com>

wrote:

You seem to be saying that even though not = all DDOS attacks are
structurally the same, and even though if I= LA were widely
adopted
not all ILA networks would be structurally = the same, there
should
nonetheless be one required qay of handling= DDOS?


Yes, at least as core default in the protoc= ol. It's precisely
_because_ not all

DDOS attacks are structurally the same. An = attacker is not going
to
conform to to our expectations of what they= should be doing, so if
we enable LISP option N to mitigate one for= m of attack, they will
just use another attack that isn't mitigate= d. For example, if the
mitigation is to identify attackers by addr= ess when requests from
the address exceed a threshold then this wo= rks as long as the
attacker strikes from one machine, but it f= alls apart if the
attacker launches a DDOS attack from severa= l hosts where requests
from none of the hosts exceed the threshold= .


The ILA model works because it assumes ther= e is no absolute way
to
prevent

the the worst case attack on a cache which = is to completely kill
it
(i.e. drive it to 0% hit rate). In this sta= te the behavior
sub-optimal routing, which is much better t= han loss of service.
This is not dependent on the structure of t= he attack, network
topology, or the network operator getting t= he configuration just
right--
it is inherent in the protocol.


Tom


Yours,
Joel


On 5/1/18 6:32 PM, Tom Herbert wrote:


On Tue, May 1, 2018 at 2:59 PM, Alberto Rod= riguez-Natal
<rodrigueznatal@gmail.com> wrote:


On Tue, May 1, 2018 at 10:16 AM, Tom Herber= t
<= tom@herbertland.com>

wrote:



I think you've misunderstood my position. C= aches are _very_
important to eliminate the cost triangular = routing (latency,
average path

load).

This reduces latency and reduces average lo= ad on ILA-Rs. But,
and
this is the critical part, caches are only = an _optimization_
in
ILA. That means if the cache is rendered in= effective (like by
a
well crafted DOS
attack) then the only effect is that the op= timization is loss
(i.e.
greater latency due to triangular router)--= this is
quantitively
the worst effect of the attack on an ILA ca= che. This can be
contrasted that to LISP where the worst cas= e effects of a DOS
attack on the cache is loss of service for = users (infinite
latency
since packets can be dropped or indefinitel= y blocked on a
cache
miss).




This can be misleading. This is not compari= ng LISP vs ILA,
this is
comparing the models of Request/Reply at th= e edge vs
Notifications
(aka Redirects) at the core. Both LISP-CP a= nd ILAMP support
these
two models.

Besides, this is assuming an scenario where= the only feasible
DOS
mitigation is absorbing the attack. There a= re other scenarios
where
other countermeasures are possible. For ins= tance, if you have
a
deployment where you can prevent address sp= oofing, counting
and
blocking misbehaving nodes offers similar D= OS protection and
requires way less infrastructure resources.=

Alberto,

The answer to my question of how does LISP = address DOS attacks
seems
to be "there are many options". S= ome of the options are to
assume
that DOS does not exist in the network, som= e assume external
configuration like address spoofing is enab= led, some assume
that
attacks can be identified and can be stoppe= d at the source,
some
might assume that everything is okay becaus= e there's never been
a
DOS attack before. I have yet to see the ef= fects of any of
these
quantified, and none of these state how the= LISP _protocol_
itself
addresses DOS. It may seem counter-intuitiv= e, but offering a
bunch
of options really is not necessarily a good= thing-- sometime
less is
more. To put this another way LISP has been= rejected from Linux
precisely because of its susceptibility to = DOS. If you were to
try
again and the best answer to the DOS questi= on is that it's up
to the
operator to figure out the right options to= use, then I believe
it
would be soundly rejected again. That appro= ach does not work at
scale.

Tom

___________________________________________= ____
ila mailing list
ila@ietf.or= g
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
3A__www.ietf.org_ma
ilman_listinfo_ila&d=3DDwICAg&c=3DL= FYZ-

o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl



2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4OstVO= L1OQiA98fgBJ9c1Gjo&s=3DBO3snt8C
RQ

gy1xwhx2CY10VUbM_rgntgpV9k3-Cskd8&e=3D<= /span>



___________________________________________= ____
5gangip mailing list
5gangip= @ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
3A__www.ietf.org_mail
man_listinfo_5gangip&d=3DDwICAg&c= =3DLFYZ-

o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl



2paJIf4zw&m=3DzYkPItjuHMuGlJXD5K_4OstVO= L1OQiA98fgBJ9c1Gjo&s=3DFnQLMire
MiKC

SkPaOGFCybzDc2i2y49Cgtbl6mCLc9c&e=3D


___________________________________________= ____
5gangip mailing list
5gangip= @ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
3A__www.ietf.org_mailman_listinfo_5gangip&a= mp;d=3DDwICAg&c=3DLFYZ-

o9_HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl2paJ= If4zw&m=3DzYkPItjuHMuGlJXD5K_4

OstVOL1OQiA98fgBJ9c1Gjo&s=3DFnQLMireMiK= CSkPaOGFCybzDc2i2y49Cgtbl6mC
Lc9c&e=3D



___________________________________________= ____
5gangip mailing list
5gangip= @ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhtt= ps-3A__www.ietf.org_mailman_listinfo_5gangip&d=3DDwIFaQ&c=3DLFYZ-o9= _HUMeMTSQicvjIg&r=3DtO_sNxa2NTxwl2paJIf4zw&m=3DZjufntGbjGmejHErlAs_= yMfAbCNZooJ8tcy1HcoFqYQ&s=3DTgdJsREjP7miSUi64kzMgXcx0cGF4oVYbcT14WlpKJE= &e=3D



--_000_D64AA7DF39D94CC89A88944F421E9A6Fattcom_-- From nobody Thu May 10 01:51:46 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F76012D87A for ; Thu, 10 May 2018 01:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.209 X-Spam-Level: X-Spam-Status: No, score=-18.209 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, 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 Wq762QVsOAFg for ; Thu, 10 May 2018 01:51:42 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 442A5127137 for ; Thu, 10 May 2018 01:51:42 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id a137-v6so26539397wme.1 for ; Thu, 10 May 2018 01:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QQgXMph0KpeboAMQdXNFSm7i0/04gctFk4Um4lFcd9I=; b=NgQQB34a/EA+LbQfHvFnVfUYUCXCTmW/LHRudHKLmH7AV90chfQ8qbFFAtptW2s/6+ y89XVeD9IRdGsZYywOQXroYwabsX1QoF/qM1EArW4bPdMgZ1fK37F1C2nKStu07+6+DC a7bMqDdN43Hcjt2W4MSQlXBmCAxG9DYRtjtX4+wVmsF3BfxHrEriYKbRnhIBetvgOEvK UClk2crde695Oi8PaEt+Ta3ntcCDYS3NbnlHM6NjCnAzB9BqVl/fvP085ZhiOD8bqbfY TFz7yfvMFs+qb1UFPQ6/y+LKp6Y20wm6FJ/S/F9qoyaxnXC+/n315tP5O4seWgeWiNe7 4Duw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QQgXMph0KpeboAMQdXNFSm7i0/04gctFk4Um4lFcd9I=; b=P8/w8bSDpUol+XFmeuP/ZVmv8AgCOxBQAQSDTQfoFBTbXABKHXhMGm037TowBUFZIy JUULJUYmaQQXyitUSJcQndzqLbAibZKbxBvqvZdwjRQdemCOUDCPJ8fkABw6VMLfrxFW 2QUUDBTvz3ScBPVRObop1sqEfEmbGG+3x1x39NKcG0Dsa55oNIa5ng739QIEqHatI3Rg f3l78XdvUhKHko41uc+yll2Y1CQg7WeZa50SlyM8nlZhxz02Hz3/Gl0z+yROl0ZS7x9V p+yWuR7pOhHv8PEoD1rQ1/U+9MafZCDClJ9s66FQgRVFW89hcxwXy7JOFiMWgJQp7GeL s3hQ== X-Gm-Message-State: ALKqPwdEb9Hivbt2zJO86on2IeUNqpMh9XVLj1fASrXTp8Ea8A6v6M3p iqY+VqYp3sYyWbqi4uY7sJYDZ1MFWhBIaaOkqXdOMg== X-Google-Smtp-Source: AB8JxZrdNN9I0WfZmK4CnHIA2xgjuifOrHMEBQV1z7YaWxNpeLNA4dnhCWoM5lTBKpwLircSbyRcnP66S/0ifz4f75M= X-Received: by 2002:a1c:a906:: with SMTP id s6-v6mr586532wme.116.1525942300186; Thu, 10 May 2018 01:51:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.247.25 with HTTP; Thu, 10 May 2018 01:51:19 -0700 (PDT) In-Reply-To: <55875A79-0D4A-48EF-BCA9-A7462EBE3A38@att.com> References: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> <8aee42db5f0f407c86fda881769ceb77@HE105715.emea1.cds.t-internal.com> <1AFE10CF28AE8B4C9663445736B8034D3822FAFE@CAFRFD1MSGUSRJI.ITServices.sbc.com> <0cbb9987-0b47-9428-3db7-2c9fab821268@joelhalpern.com> <1AFE10CF28AE8B4C9663445736B8034D3822FC27@CAFRFD1MSGUSRJI.ITServices.sbc.com> <55875A79-0D4A-48EF-BCA9-A7462EBE3A38@att.com> From: Lorenzo Colitti Date: Thu, 10 May 2018 17:51:19 +0900 Message-ID: To: "FIGURELLE, TERRY F" Cc: Tom Herbert , "Joel M. Halpern" , Tom Herbert , "ila@ietf.org" , 5GANGIP <5gangip@ietf.org>, Alberto Rodriguez-Natal , "Dirk.von-Hugo@telekom.de" Content-Type: multipart/alternative; boundary="000000000000c16d91056bd620c5" Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 08:51:44 -0000 --000000000000c16d91056bd620c5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 9, 2018 at 2:48 AM, FIGURELLE, TERRY F wrote: > We all support methods so traffic flows like video chat can work but key > is we all work directly with those ASP=E2=80=99s (Application service pro= viders). > All of us have special handling of traffic to Amazon, Apple, Google and s= o > on. The difference is in the functionality, scale and number of ASP=E2=80= =99s > support where we smoke everyone! > Actually this is not a good thing at all. It means that any new video service doesn't work on your network until you support it. This is pretty much the definition of ossification of the Internet. It's also the reason why the QUIC working group is doing its best to ensure that the protocol provides zero cleartext information to the network, so the network cannot make decisions like this. --000000000000c16d91056bd620c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, May 9, 2018 at 2:48 AM, FIGURELLE, TERRY F <tf2934@att.com>= wrote:
We all support methods so traffic flows like video c= hat can work but key is we all work directly with those ASP=E2=80=99s (Appl= ication service providers). All of us have special handling of traffic to A= mazon, Apple, Google and so on. The difference is in the functionality, scale and number of ASP=E2=80=99s support where we smoke everyone!

Actually this is not a good thing at a= ll. It means that any new video service doesn't work on your network un= til you support it. This is pretty much the definition of ossification of t= he Internet. It's also the reason why the QUIC working group is doing i= ts best to ensure that the protocol provides zero cleartext information to = the network, so the network cannot make decisions like this.
--000000000000c16d91056bd620c5-- From nobody Thu May 10 07:24:22 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D1512EADE for ; Thu, 10 May 2018 07:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 ob7Ugm7AKUBo for ; Thu, 10 May 2018 07:24:20 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 3EC3412EAC4 for ; Thu, 10 May 2018 07:24:20 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id 11-v6so1686880qkk.4 for ; Thu, 10 May 2018 07:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=x9lBQcVRKzCDqIzQyrER4XeICeS74mAyb+DIzLIJKE0=; b=1ssQT0rdjl1rflGuFM2POaP9p27L2E375xGTimJHbE5PLqy5v/V7oP/Jodjqk0qz5T yYIqY4MsYw7AL7ai3rYYPft1AIE5rX5A93oY72spUtnsvxmGZwGuzEzvRo2V3q4MRNxp /iNeHAbbUgt58n6UrBG6VbQYp+JB8aCh+5aIPqKMpjEk0TCnjunQ2Sk4Z8hEZAZ5g12I Z+x03ISEGTeK5kEOFQkuzUsh4r7pmAx399fyTowY2R29I/B5CsPoMtx4Fh3H5gdB+89X fQyz6/3/g7nUPbU56b8I1MSN6oUreVl1uGpCE88DBE85H8Q1tA+LP8bR77dVQ/tUn0DZ c15A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=x9lBQcVRKzCDqIzQyrER4XeICeS74mAyb+DIzLIJKE0=; b=EDOJmLoYY+Le4ueMHm1dVxRwO4iXbxXENSQpl7WxcLhsgbdT1+HSew653ItOg9CdV1 +HGtqNCc+3tqwQUwk7N47CIGJt661FwvZAcac7bWBpBkujn0CO2j6l1+nwWG38M5mmMJ jH81Ter93Nm2H/r4odfZ+tZ8+BfW3ku9wWBiHv3owlz5hMlEl8AABxuByPdVmdq34tUq l/9U32oL3IIc2jwhygKlN2IT3SEayWfg8/3PXTg0O2kBkcHakrDA3e1PYVIXyNoxLYC4 WnJwkG5oIwyh6+zu3pCItFTwsXScUv/XB0UOvmBO/ulRaJOqmGUXP5I4a43flA52SOTA oP3w== X-Gm-Message-State: ALKqPwdyUg6FMTHeiW1RDGI5RiKbdKU/+/Si2//uz19YHs4xbvzVJ6Ho E+ZDyAqBfG9dVggAZ+Apr2LuIcQB+nsSiJ2bkdFrPA== X-Google-Smtp-Source: AB8JxZqqr3KnEmkaqzssKRfuBZCJZPT2hkO6bCcFaJ6qhi1tQxANKWwpTVVOzDl3CVJwmHAyKetmShlU6PZLWGXBPQo= X-Received: by 2002:a37:a64c:: with SMTP id p73-v6mr1425846qke.248.1525962258968; Thu, 10 May 2018 07:24:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.48.66 with HTTP; Thu, 10 May 2018 07:24:18 -0700 (PDT) In-Reply-To: References: <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> <8aee42db5f0f407c86fda881769ceb77@HE105715.emea1.cds.t-internal.com> <1AFE10CF28AE8B4C9663445736B8034D3822FAFE@CAFRFD1MSGUSRJI.ITServices.sbc.com> <0cbb9987-0b47-9428-3db7-2c9fab821268@joelhalpern.com> <1AFE10CF28AE8B4C9663445736B8034D3822FC27@CAFRFD1MSGUSRJI.ITServices.sbc.com> <55875A79-0D4A-48EF-BCA9-A7462EBE3A38@att.com> From: Tom Herbert Date: Thu, 10 May 2018 07:24:18 -0700 Message-ID: To: Lorenzo Colitti Cc: "FIGURELLE, TERRY F" , Tom Herbert , "Joel M. Halpern" , "ila@ietf.org" , 5GANGIP <5gangip@ietf.org>, Alberto Rodriguez-Natal , "Dirk.von-Hugo@telekom.de" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement] X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 14:24:21 -0000 On Thu, May 10, 2018 at 1:51 AM, Lorenzo Colitti wrote= : > On Wed, May 9, 2018 at 2:48 AM, FIGURELLE, TERRY F wrote= : >> >> We all support methods so traffic flows like video chat can work but key >> is we all work directly with those ASP=E2=80=99s (Application service pr= oviders). >> All of us have special handling of traffic to Amazon, Apple, Google and = so >> on. The difference is in the functionality, scale and number of ASP=E2= =80=99s >> support where we smoke everyone! > > > Actually this is not a good thing at all. It means that any new video > service doesn't work on your network until you support it. This is pretty > much the definition of ossification of the Internet. It's also the reason > why the QUIC working group is doing its best to ensure that the protocol > provides zero cleartext information to the network, so the network cannot > make decisions like this. +1 I'd also point out that "All of us have special handling of traffic to Amazon, Apple, Google and so on" is the antithesis of net neutrality. IMO, it's reasonable to discriminate types (video, bulk transfer, real time chat, etc.) of traffic without discriminating based on the source of the traffic or the transport protocol. This is what IP layer network signalling, like in FAST as I mentioned, endeavours to do. Tom From nobody Tue May 15 00:20:36 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964DE12D778; Tue, 15 May 2018 00:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 aKcVknDzrGzS; Tue, 15 May 2018 00:20:19 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id D5904127023; Tue, 15 May 2018 00:20:18 -0700 (PDT) Received: from vc1.ecl.ntt.co.jp (vc1.ecl.ntt.co.jp [129.60.86.153]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id w4F7KGuJ001521; Tue, 15 May 2018 16:20:16 +0900 Received: from vc1.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 0A071EA8093; Tue, 15 May 2018 16:20:16 +0900 (JST) Received: from jcms-pop21.ecl.ntt.co.jp (jcms-pop21.ecl.ntt.co.jp [129.60.87.134]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id F2CC3EA7EE1; Tue, 15 May 2018 16:20:15 +0900 (JST) Received: from [IPv6:::1] (unknown [129.60.13.28]) by jcms-pop21.ecl.ntt.co.jp (Postfix) with ESMTPSA id DE6D74005EF; Tue, 15 May 2018 16:20:15 +0900 (JST) References: <152636802001.3766.7474220122681922811.idtracker@ietfa.amsl.com> From: Shunsuke Homma X-Forwarded-Message-Id: <152636802001.3766.7474220122681922811.idtracker@ietfa.amsl.com> Message-ID: <379a638d-3ff2-3991-ab4e-a846be9820f1@lab.ntt.co.jp> Date: Tue, 15 May 2018 16:19:47 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <152636802001.3766.7474220122681922811.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CC-Mail-RelayStamp: 1 To: dmm@ietf.org, 5gangip@ietf.org, ila@ietf.org X-TM-AS-MML: disable Archived-At: Subject: [Ila] Fwd: New Version Notification for draft-homma-dmm-5gs-id-loc-coexistence-01.txt X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 07:20:22 -0000 Hi, We've updated the draft which describes an approach for introducing ID-LOC architecture into 5GS with low-impact. https://www.ietf.org/internet-drafts/draft-homma-dmm-5gs-id-loc-coexistence-01.txt Your feedback would be highly appreciated. Best regards, Shunsuke -------- Forwarded Message -------- Subject: New Version Notification for draft-homma-dmm-5gs-id-loc-coexistence-01.txt Date: Tue, 15 May 2018 00:07:00 -0700 From: internet-drafts@ietf.org To: Kenta Kawakami , Arashmid Akhavain , Shunsuke Homma A new version of I-D, draft-homma-dmm-5gs-id-loc-coexistence-01.txt has been successfully submitted by Shunsuke Homma and posted to the IETF repository. Name: draft-homma-dmm-5gs-id-loc-coexistence Revision: 01 Title: Co-existence of 3GPP 5GS and Identifier Locator Separation Architecture Document date: 2018-05-15 Group: Individual Submission Pages: 37 URL: https://www.ietf.org/internet-drafts/draft-homma-dmm-5gs-id-loc-coexistence-01.txt Status: https://datatracker.ietf.org/doc/draft-homma-dmm-5gs-id-loc-coexistence/ Htmlized: https://tools.ietf.org/html/draft-homma-dmm-5gs-id-loc-coexistence-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-homma-dmm-5gs-id-loc-coexistence Diff: https://www.ietf.org/rfcdiff?url2=draft-homma-dmm-5gs-id-loc-coexistence-01 Abstract: This document describes an approach to introduce Identifier Locator Separation architecture into 3GPP 5GS with low-impact on its specification, and shows the features and considerations of this approach. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Wed May 30 17:38:29 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05C61200FC; Wed, 30 May 2018 17:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 JCKq6MvFqHqs; Wed, 30 May 2018 17:38:17 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 85ACA12DA40; Wed, 30 May 2018 17:38:17 -0700 (PDT) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w4V0ZKah017742; Wed, 30 May 2018 20:38:09 -0400 Received: from flpd657.enaf.ffdc.sbc.com (sbcsmtp9.sbc.com [144.160.128.153]) by m0049459.ppops.net-00191d01. with ESMTP id 2ja4w71qvh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 May 2018 20:38:08 -0400 Received: from enaf.ffdc.sbc.com (localhost [127.0.0.1]) by flpd657.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id w4V0c7O7026193; Wed, 30 May 2018 17:38:07 -0700 Received: from zlp25946.vci.att.com (zlp25946.vci.att.com [135.213.92.138]) by flpd657.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id w4V0c6Y5026179; Wed, 30 May 2018 17:38:06 -0700 Received: from zlp25946.vci.att.com (zlp25946.vci.att.com [127.0.0.1]) by zlp25946.vci.att.com (Service) with ESMTP id 262D6412C920; Thu, 31 May 2018 00:38:06 +0000 (GMT) Received: from CAFRFD1MSGHUBAG.ITServices.sbc.com (unknown [130.4.169.164]) by zlp25946.vci.att.com (Service) with ESMTPS id 0B1A7410F442; Thu, 31 May 2018 00:38:06 +0000 (GMT) Received: from CAFRFD1MSGUSRJI.ITServices.sbc.com ([169.254.8.118]) by CAFRFD1MSGHUBAG.ITServices.sbc.com ([130.4.169.164]) with mapi id 14.03.0389.001; Wed, 30 May 2018 17:38:05 -0700 From: "FIGURELLE, TERRY F" To: Tom Herbert , Lorenzo Colitti CC: Tom Herbert , "ila@ietf.org" , Alexandre Petrescu , Behcet Sarikaya , Dino Farinacci , 5GANGIP <5gangip@ietf.org> Thread-Topic: [5gangip] [Ila] Scaling mapping systems (was Re: BOF Description) Thread-Index: AQHTnc+dXgqKXRMVlEW8c4cGVUt1yqOVceOAgAEG+oCAAV1+WoCxwj7g Date: Thu, 31 May 2018 00:38:05 +0000 Message-ID: <1AFE10CF28AE8B4C9663445736B8034D38255422@CAFRFD1MSGUSRJI.ITServices.sbc.com> References: <5067FA81-B416-4A19-9F11-A08B35BB8B6D@gmail.com> <9C425F56-738C-4600-9DFF-9D30FC3872DC@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.35.62] Content-Type: multipart/alternative; boundary="_000_1AFE10CF28AE8B4C9663445736B8034D38255422CAFRFD1MSGUSRJI_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-30_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1805310005 Archived-At: Subject: Re: [Ila] [5gangip] Scaling mapping systems (was Re: BOF Description) X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 00:38:21 -0000 --_000_1AFE10CF28AE8B4C9663445736B8034D38255422CAFRFD1MSGUSRJI_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91IGhhdmUgYSBzY2FsaW5nIHByb2JsZW0gdGhlcmUgc2luY2UgeW91IGNhbiBoYW5kbGUgdGhh dCB0cmFmZmljIGV4YW1wbGUgb24gbXVjaCBsZXNzIHRoYW4gNTMwIFVQRuKAmXMgKGUuZy4gMjAr MjAgaXMgZW5vdWdoIGZyb20gY2FwYWNpdHkgcG9pbnQgb2YgdmlldykuIFRvIGNvdmVyIGFsbCBv ZiB0aGUgbGF5ZXIxIGZpYmVyIHBhdGhzIG9mIGltcG9ydGFuY2UgaW4gY29udGluZW50YWwgVVMg eW91IG9ubHkgbmVlZCBhIG1heCBvZiAxODAgbG9jYXRpb25zLiBJIGRvdWJ0IGFueW9uZSBidXQg QVQmVCB3b3VsZCBnbyB0byB0aGF0IGV4dHJlbWUgb24gZmliZXIgcGxhbnQgY29ubmVjdGl2aXR5 LiBBZGRpbmcgbW9yZSBsb2NhdGlvbnMgYWN0dWFsbHkgaW5jcmVhc2VzIGxhdGVuY3kgYW5kIGlz IG5vdCBkZXNpcmVkLg0KDQpGcm9tOiA1Z2FuZ2lwIDw1Z2FuZ2lwLWJvdW5jZXNAaWV0Zi5vcmc+ IE9uIEJlaGFsZiBPZiBUb20gSGVyYmVydA0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMDYsIDIw MTggMTI6MjggUE0NClRvOiBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbT4NCkNj OiBUb20gSGVyYmVydCA8dG9tQGhlcmJlcnRsYW5kLmNvbT47IGlsYUBpZXRmLm9yZzsgQWxleGFu ZHJlIFBldHJlc2N1IDxhbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tPjsgQmVoY2V0IFNhcmlr YXlhIDxzYXJpa2F5YUBpZWVlLm9yZz47IERpbm8gRmFyaW5hY2NpIDxmYXJpbmFjY2lAZ21haWwu Y29tPjsgNUdBTkdJUCA8NWdhbmdpcEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbNWdhbmdpcF0g W0lsYV0gU2NhbGluZyBtYXBwaW5nIHN5c3RlbXMgKHdhcyBSZTogQk9GIERlc2NyaXB0aW9uKQ0K DQoNCg0KT24gTW9uLCBGZWIgNSwgMjAxOCBhdCAxMDozNCBQTSwgTG9yZW56byBDb2xpdHRpIDxs b3JlbnpvQGdvb2dsZS5jb208bWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbT4+IHdyb3RlOg0KT24g VHVlLCBGZWIgNiwgMjAxOCBhdCAxMjozNyBBTSwgVG9tIEhlcmJlcnQgPHRvbUBxdWFudG9uaXVt Lm5ldDxtYWlsdG86dG9tQHF1YW50b25pdW0ubmV0Pj4gd3JvdGU6DQpBcyB0aW1lIGhhcyBnb25l IG9uIHdpdGggZXhwZXJpZW5jZSBpbiBkZXBsb3ltZW50LCBmb3J3YXJkaW5nIHRvIGFub3RoZXIg bm9kZSB0aGF0IGhhcyBhIGxhcmdlIHNoYXJlZCBjYWNoZSwgbGlrZSBhbiBSVFIsIHNlZW1zIHRv IGRlYWwgd2l0aCB0aGUgaXNzdWUgaW4gYSBjb21wcm9taXNlZCB3YXkuDQoNCkluIElMQU1QICho dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGVyYmVydC1pbGEtaWxhbXAtMDA8aHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5p ZXRmLm9yZ19odG1sX2RyYWZ0LTJEaGVyYmVydC0yRGlsYS0yRGlsYW1wLTJEMDAmZD1Ed01GYVEm Yz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9dE9fc054YTJOVHh3bDJwYUpJZjR6dyZtPVp1V0JM VnphYW16OEFudnNSTmRIb01pVjlnc2tKU3BEZFpqNXMzSEd0UEEmcz1RVTBoRHVPMVNLOThta2pT WnBQcE5pSnRObGcwMlVFY0RwSmFrdXN4djYwJmU9Pikgc2VjdXJlIHJlZGlyZWN0cyBhcmUgZGVm aW5lZCB0byBiZSB0aGUgcHJpbWFyeSBtZWFucyBvZiBwb3B1bGF0aW5nIGEgY2FjaGUuIE9uIGEg Y2FjaGUgbWlzcywgYSBwYWNrZXQgaXMgZm9yd2FyZGVkIGludG8gdGhlIG5ldHdvcmsgYW5kIHJv dXRpbmcgc2hvdWxkIGZvcndhcmQgdGhlIHBhY2tldCB0byBhbiBJTEEgcm91dGVyIHRoYXQgY29u dGFpbnMgdGhlIGNvbXBsZXRlIHNldCBvZiBtYXBwaW5ncyBmb3IgdGhlIGFzc29jaWF0ZWQgc2hh cmQuIFRoZSByb3V0ZXIgcGVyZm9ybXMgdGhlIHRyYW5zZm9ybWF0aW9uIGFuZCBjYW4gc2VuZCBh IHJlZGlyZWN0IGJhY2sgdG8gdGhlIGNhY2hpbmcgbm9kZS4gVGhlIHJlZGlyZWN0IGNhbiBiZSBj YWNoZWQgc28gdGhhdCBzdWJzZXF1ZW50IHBhY2tldHMgdGFrZSBhIGRpcmVjdCByb3V0ZSBhbmQg YXZvaWQgdGhlIHRyaWFuZ2x1bGFyIHJvdXRpbmcuIFJlZGlyZWN0cyBtdXN0IGJlIHNlY3VyZSBz byB0aGF0IHRoZXkgY2Fubm90IGJlIHNwb29mZWQsIHNvIGZvciB0aGF0IHJlYXNvbiAoYW5kIHNv bWUgb3RoZXJzKSB0aGUgcHJvdG9jb2wgaXMgb3ZlciBUQ1AuIFRoZSBtYXBwaW5nIGNhY2hlIGlz IG9ubHkgYW4gb3B0aW1pemF0aW9uIGFuZCBwYWNrZXRzIGFyZSBuZXZlciBkcm9wcGVkIG9yIHF1 ZXVlZCBmb3IgcGVuZGluZyBjYWNoZSByZXNvbHV0aW9uLiBJZiB0aGUgY2FjaGUgd2VyZW4ndCBw cmVzZW50LCBjb21tdW5pY2F0aW9ucyB3b3VsZCBzdGlsbCBiZSB2aWFibGUgYnV0IHN1Yi1vcHRp bWFsOyB0aGF0IGNoYXJhY3RlcmlzdGljIGVzdGFibGlzaGVzIGEgYm91bmQgZm9yIHRoZSB3b3Jz dCBjYXNlIERPUyBhdHRhY2suDQoNCkFueSB0aG91Z2hzIG9uIHRoaXMgYXBwcm9hY2g/DQoNCkhp IExvcmVuem8sDQoNClRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrIQ0KDQpUaGUgb2J2aW91cyBvbmVz IHdvdWxkIHNlZW06DQoNCiAgKiAgIFdpbGwgdGhlIHdvcmtpbmcgc2V0IG9mIGNhY2hlIG1hcHBp bnMgZml0IGluIHdoYXRldmVyIG1lbW9yeSBpcyBhdmFpbGFibGUgaW4sIHNheSwgYSBsYXJnZSBw ZWVyaW5nIHJvdXRlcj8NClRoZSBjYWNoZSBuZWVkcyB0byBiZSBzaXplZCB0byBmaXQgdGhlIHdv cmtpbmcgc2V0LiBQbGVhc2UgbG9vayBhdCB0aGUgcmVmZXJlbmNlIHRvcG9sb2d5IG9mIHNlY3Rp b24gTi4gVGhlIGludGVudCBpcyB0aGF0IGNhY2hlcyB3b3VsZCBub3QgYmUgdXNlZCBhdCBlZGdl IG9yIHBlZXIgcm91dGVycywgSUxBIHJvdXRlciBhcmUgdXNlZCB0aGVyZSB3aGljaCBzaGFyZCB0 aGUgbWFwcGluZyBkYXRhYmFzZSBhY3Jvc3Mgc29tZSBudW1iZXIgb2YgIG5vZGVzLiBNYXBwaW5n IGNhY2hlcyBhcmUgYXQgSUxBLU5zIHdoaWNoIGFyZSBkZXBsb3llZCBkZWVwZXIgaW4gdGhlIG5l dHdvcmsgdG93YXJkcyB0aGUgZW5kIGhvc3RzIChsaWtlIHRvd2FyZCBnTkIpLiBUaGVyZSBhcmUg bW9yZSBvZiB0aGVzZSB0aGFuIElMQS1ScywgaG93ZXZlciB0aGV5IGFyZSBzZXJ2ZSBhIHNtYWxs IHNldCBvZiB1c2VycyBhbmQgd291bGQgYmUgaW1wbGVtZW50ZWQgb24gbG93ZXIgZW5kIGRldmlj ZXMuIFRoZSBwdXJwb3NlIG9mIHRoZSBjYWNoZSBpcyB0byBvcHRpbWl6ZSBsYXRlbmN5IGFuZCB0 aHJvdWdocHV0IG9mIHBlcmZvcm1hbmNlIGNyaXRpY2FsIGludHJhLW5ldHdvcmsgY29tbXVuaWNh dGlvbnMgKFVlIHRvIFVFLCBVRSB0byBhcHBsaWNhdGlvbiBzZXJ2ZXIgaW4gbmV0d29yaykuDQoN Cg0KICAqICAgUmVtZW1iZXIgdGhhdCBtZW1vcnkgdGhhdCBpcyBjYXBhYmxlIG9mIHN1c3RhaW5p bmcgcm91dGluZyBsb29rdXBzIGF0IHRlbnMgb2YgZ2lnYWJpdHMgcGVyIHNlY29uZCBpcyBleHRy ZW1lbHkgZXhwZW5zaXZlLg0KICAqICAgSG93IGRvIHlvdSBkZWZlbmQgYWdhaW5zdCBzdGF0ZSBl eGhhdXN0aW9uIGF0dGFja3Mgd2hlcmVieSBhIGxhcmdlIG51bWJlciBvZiBzcG9vZmVkIHNvdXJj ZXMgc2VuZCBwYWNrZXRzIHRvIG5vbmV4aXN0ZW50IGRlc3RpbmF0aW9ucz8NCk5vIGNhY2hlIHN0 YXRlIGlzIGNyZWF0ZWQgZm9yIG5vbmV4aXN0ZW50IGRlc3RpbmF0aW9ucy4NCg0KDQogICogICBI b3cgbXVjaCBiYW5kd2lkdGggd2lsbCBiZSB1c2VkIGZvciB0aGUgcmVkaXJlY3RzPyBIb3cgbXVj aCBDUFUgdGltZSB3aWxsIGJlIHVzZWQgdG8gcHJvY2VzcyB0aGVtPw0KICAqICAgSG93IG1hbnkg c2VydmVycyBhcmUgbmVlZGVkIHRvIHN0b3JlDQpTdWdnZXN0IGdhbWluZyB0aGlzIG91dCBmb3Ig YSBsYXJnZSBtb2JpbGUgb3BlcmF0b3Igd2l0aCwgc2F5LCAxMDBNIGNsaWVudHMsIDEwMCBJbnRl cm5ldCBjb25uZWN0aW9uIHBvaW50cyBhbmQgMTBUIG9mIHRyYWZmaWMuDQoNCkkgZGlkIGFuIGFu YWx5c2lzIG9mIElMQSBzY2FsYWJpbGl0eSBmb3IgYSBjb3VwbGUgb2Ygc2NlbmFyaW9zIChzZWUg YXR0YWNoZWQpLCBGb3IgdGhlIDEwME0gVUVzLCB0aGUgbnVtYmVyIG9mIElMQSByb3V0ZXJzIGNh bWUgb3V0IHRvIDUzMC4NCg0KVG9tDQoNCg0K --_000_1AFE10CF28AE8B4C9663445736B8034D38255422CAFRFD1MSGUSRJI_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9y bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv bm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv LWxpc3QtaWQ6MTY3NjQxNjA4ODsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTE1MTYzNjI1MDt9 DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTc0ODkxNTI3NjsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6OTg2ODk1MTA2O30NCkBsaXN0IGwxOmxldmVsMQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTps ZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZl bDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMg0KCXttc28tbGlzdC1pZDoyMTA3MDczMDU3Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlk czotOTc1NjcyNzg2O30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBp bjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91IGhhdmUgYSBzY2FsaW5nIHByb2JsZW0gdGhl cmUgc2luY2UgeW91IGNhbiBoYW5kbGUgdGhhdCB0cmFmZmljIGV4YW1wbGUgb24gbXVjaCBsZXNz IHRoYW4gNTMwIFVQRuKAmXMgKGUuZy4gMjAmIzQzOzIwIGlzIGVub3VnaCBmcm9tIGNhcGFjaXR5 IHBvaW50IG9mIHZpZXcpLiBUbyBjb3ZlciBhbGwgb2YgdGhlIGxheWVyMSBmaWJlciBwYXRocyBv ZiBpbXBvcnRhbmNlIGluIGNvbnRpbmVudGFsIFVTIHlvdSBvbmx5IG5lZWQNCiBhIG1heCBvZiAx ODAgbG9jYXRpb25zLiBJIGRvdWJ0IGFueW9uZSBidXQgQVQmYW1wO1Qgd291bGQgZ28gdG8gdGhh dCBleHRyZW1lIG9uIGZpYmVyIHBsYW50IGNvbm5lY3Rpdml0eS4gQWRkaW5nIG1vcmUgbG9jYXRp b25zIGFjdHVhbGx5IGluY3JlYXNlcyBsYXRlbmN5IGFuZCBpcyBub3QgZGVzaXJlZC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gNWdhbmdpcCAmbHQ7NWdhbmdpcC1ib3Vu Y2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5Ub20gSGVyYmVydDxicj4NCjxi PlNlbnQ6PC9iPiBUdWVzZGF5LCBGZWJydWFyeSAwNiwgMjAxOCAxMjoyOCBQTTxicj4NCjxiPlRv OjwvYj4gTG9yZW56byBDb2xpdHRpICZsdDtsb3JlbnpvQGdvb2dsZS5jb20mZ3Q7PGJyPg0KPGI+ Q2M6PC9iPiBUb20gSGVyYmVydCAmbHQ7dG9tQGhlcmJlcnRsYW5kLmNvbSZndDs7IGlsYUBpZXRm Lm9yZzsgQWxleGFuZHJlIFBldHJlc2N1ICZsdDthbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29t Jmd0OzsgQmVoY2V0IFNhcmlrYXlhICZsdDtzYXJpa2F5YUBpZWVlLm9yZyZndDs7IERpbm8gRmFy aW5hY2NpICZsdDtmYXJpbmFjY2lAZ21haWwuY29tJmd0OzsgNUdBTkdJUCAmbHQ7NWdhbmdpcEBp ZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFs1Z2FuZ2lwXSBbSWxhXSBTY2Fs aW5nIG1hcHBpbmcgc3lzdGVtcyAod2FzIFJlOiBCT0YgRGVzY3JpcHRpb24pPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBGZWIgNSwgMjAxOCBhdCAxMDozNCBQTSwg TG9yZW56byBDb2xpdHRpICZsdDs8YSBocmVmPSJtYWlsdG86bG9yZW56b0Bnb29nbGUuY29tIiB0 YXJnZXQ9Il9ibGFuayI+bG9yZW56b0Bnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gVHVlLCBGZWIgNiwgMjAxOCBhdCAxMjozNyBBTSwgVG9tIEhlcmJlcnQgJmx0Ozxh IGhyZWY9Im1haWx0bzp0b21AcXVhbnRvbml1bS5uZXQiIHRhcmdldD0iX2JsYW5rIj50b21AcXVh bnRvbml1bS5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMg dGltZSBoYXMgZ29uZSBvbiB3aXRoIGV4cGVyaWVuY2UgaW4gZGVwbG95bWVudCwgZm9yd2FyZGlu ZyB0byBhbm90aGVyIG5vZGUgdGhhdCBoYXMgYSBsYXJnZSBzaGFyZWQgY2FjaGUsIGxpa2UgYW4g UlRSLCBzZWVtcyB0byBkZWFsIHdpdGggdGhlIGlzc3VlIGluIGEgY29tcHJvbWlzZWQgd2F5Ljxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkluIElMQU1QICg8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfZHJh ZnQtMkRoZXJiZXJ0LTJEaWxhLTJEaWxhbXAtMkQwMCZhbXA7ZD1Ed01GYVEmYW1wO2M9TEZZWi1v OV9IVU1lTVRTUWljdmpJZyZhbXA7cj10T19zTnhhMk5UeHdsMnBhSklmNHp3JmFtcDttPVp1V0JM VnphYW16OEFudnNSTmRIb01pVjlnc2tKU3BEZFpqNXMzSEd0UEEmYW1wO3M9UVUwaER1TzFTSzk4 bWtqU1pwUHBOaUp0TmxnMDJVRWNEcEpha3VzeHY2MCZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGVyYmVydC1pbGEtaWxhbXAtMDA8L2E+ KQ0KIHNlY3VyZSByZWRpcmVjdHMgYXJlIGRlZmluZWQgdG8gYmUgdGhlIHByaW1hcnkgbWVhbnMg b2YgcG9wdWxhdGluZyBhIGNhY2hlLiBPbiBhIGNhY2hlIG1pc3MsIGEgcGFja2V0IGlzIGZvcndh cmRlZCBpbnRvIHRoZSBuZXR3b3JrIGFuZCByb3V0aW5nIHNob3VsZCBmb3J3YXJkIHRoZSBwYWNr ZXQgdG8gYW4gSUxBIHJvdXRlciB0aGF0IGNvbnRhaW5zIHRoZSBjb21wbGV0ZSBzZXQgb2YgbWFw cGluZ3MgZm9yIHRoZSBhc3NvY2lhdGVkIHNoYXJkLg0KIFRoZSByb3V0ZXIgcGVyZm9ybXMgdGhl IHRyYW5zZm9ybWF0aW9uIGFuZCBjYW4gc2VuZCBhIHJlZGlyZWN0IGJhY2sgdG8gdGhlIGNhY2hp bmcgbm9kZS4gVGhlIHJlZGlyZWN0IGNhbiBiZSBjYWNoZWQgc28gdGhhdCBzdWJzZXF1ZW50IHBh Y2tldHMgdGFrZSBhIGRpcmVjdCByb3V0ZSBhbmQgYXZvaWQgdGhlIHRyaWFuZ2x1bGFyIHJvdXRp bmcuIFJlZGlyZWN0cyBtdXN0IGJlIHNlY3VyZSBzbyB0aGF0IHRoZXkgY2Fubm90IGJlIHNwb29m ZWQsIHNvDQogZm9yIHRoYXQgcmVhc29uIChhbmQgc29tZSBvdGhlcnMpIHRoZSBwcm90b2NvbCBp cyBvdmVyIFRDUC4gVGhlIG1hcHBpbmcgY2FjaGUgaXMgb25seSBhbiBvcHRpbWl6YXRpb24gYW5k IHBhY2tldHMgYXJlIG5ldmVyIGRyb3BwZWQgb3IgcXVldWVkIGZvciBwZW5kaW5nIGNhY2hlIHJl c29sdXRpb24uIElmIHRoZSBjYWNoZSB3ZXJlbid0IHByZXNlbnQsIGNvbW11bmljYXRpb25zIHdv dWxkIHN0aWxsIGJlIHZpYWJsZSBidXQgc3ViLW9wdGltYWw7DQogdGhhdCBjaGFyYWN0ZXJpc3Rp YyBlc3RhYmxpc2hlcyBhIGJvdW5kIGZvciB0aGUgd29yc3QgY2FzZSBET1MgYXR0YWNrLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbnkgdGhv dWdocyBvbiB0aGlzIGFwcHJvYWNoPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIExvcmVuem8sPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgdGhlIGZlZWRiYWNr ITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIG9idmlvdXMgb25lcyB3b3VsZCBz ZWVtOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpXaWxsIHRoZSB3 b3JraW5nIHNldCBvZiBjYWNoZSBtYXBwaW5zIGZpdCBpbiB3aGF0ZXZlciBtZW1vcnkgaXMgYXZh aWxhYmxlIGluLCBzYXksIGEgbGFyZ2UgcGVlcmluZyByb3V0ZXI/DQo8bzpwPjwvbzpwPjwvbGk+ PC91bD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjYWNoZSBuZWVkcyB0byBiZSBzaXplZCB0byBm aXQgdGhlIHdvcmtpbmcgc2V0LiBQbGVhc2UgbG9vayBhdCB0aGUgcmVmZXJlbmNlIHRvcG9sb2d5 IG9mIHNlY3Rpb24gTi4gVGhlIGludGVudCBpcyB0aGF0IGNhY2hlcyB3b3VsZCBub3QgYmUgdXNl ZCBhdCBlZGdlIG9yIHBlZXIgcm91dGVycywgSUxBIHJvdXRlciBhcmUgdXNlZCB0aGVyZSB3aGlj aCBzaGFyZCB0aGUgbWFwcGluZyBkYXRhYmFzZSBhY3Jvc3MNCiBzb21lIG51bWJlciBvZiZuYnNw OyBub2Rlcy4gTWFwcGluZyBjYWNoZXMgYXJlIGF0IElMQS1OcyB3aGljaCBhcmUgZGVwbG95ZWQg ZGVlcGVyIGluIHRoZSBuZXR3b3JrIHRvd2FyZHMgdGhlIGVuZCBob3N0cyAobGlrZSB0b3dhcmQg Z05CKS4gVGhlcmUgYXJlIG1vcmUgb2YgdGhlc2UgdGhhbiBJTEEtUnMsIGhvd2V2ZXIgdGhleSBh cmUgc2VydmUgYSBzbWFsbCBzZXQgb2YgdXNlcnMgYW5kIHdvdWxkIGJlIGltcGxlbWVudGVkIG9u IGxvd2VyIGVuZCBkZXZpY2VzLg0KIFRoZSBwdXJwb3NlIG9mIHRoZSBjYWNoZSBpcyB0byBvcHRp bWl6ZSBsYXRlbmN5IGFuZCB0aHJvdWdocHV0IG9mIHBlcmZvcm1hbmNlIGNyaXRpY2FsIGludHJh LW5ldHdvcmsgY29tbXVuaWNhdGlvbnMgKFVlIHRvIFVFLCBVRSB0byBhcHBsaWNhdGlvbiBzZXJ2 ZXIgaW4gbmV0d29yaykuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj4NClJlbWVtYmVyIHRoYXQgbWVtb3J5 IHRoYXQgaXMgY2FwYWJsZSBvZiBzdXN0YWluaW5nIHJvdXRpbmcgbG9va3VwcyBhdCB0ZW5zIG9m IGdpZ2FiaXRzIHBlciBzZWNvbmQgaXMgZXh0cmVtZWx5IGV4cGVuc2l2ZS48bzpwPjwvbzpwPjwv bGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+DQpIb3cg ZG8geW91IGRlZmVuZCBhZ2FpbnN0IHN0YXRlIGV4aGF1c3Rpb24gYXR0YWNrcyB3aGVyZWJ5IGEg bGFyZ2UgbnVtYmVyIG9mIHNwb29mZWQgc291cmNlcyBzZW5kIHBhY2tldHMgdG8gbm9uZXhpc3Rl bnQgZGVzdGluYXRpb25zPzxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Tm8gY2FjaGUgc3RhdGUgaXMgY3JlYXRlZCBmb3Igbm9uZXhpc3RlbnQgZGVzdGluYXRpb25zLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlz dDpsMiBsZXZlbDEgbGZvMyI+DQpIb3cgbXVjaCBiYW5kd2lkdGggd2lsbCBiZSB1c2VkIGZvciB0 aGUgcmVkaXJlY3RzPyBIb3cgbXVjaCBDUFUgdGltZSB3aWxsIGJlIHVzZWQgdG8gcHJvY2VzcyB0 aGVtPzxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxl dmVsMSBsZm8zIj4NCkhvdyBtYW55IHNlcnZlcnMgYXJlIG5lZWRlZCB0byBzdG9yZTxvOnA+PC9v OnA+PC9saT48L3VsPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1Z2dlc3QgZ2FtaW5n IHRoaXMgb3V0IGZvciBhIGxhcmdlIG1vYmlsZSBvcGVyYXRvciB3aXRoLCBzYXksIDEwME0gY2xp ZW50cywgMTAwIEludGVybmV0IGNvbm5lY3Rpb24gcG9pbnRzIGFuZCAxMFQgb2YgdHJhZmZpYy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRpZCBhbiBhbmFs eXNpcyBvZiBJTEEgc2NhbGFiaWxpdHkgZm9yIGEgY291cGxlIG9mIHNjZW5hcmlvcyAoc2VlIGF0 dGFjaGVkKSwgRm9yIHRoZSAxMDBNIFVFcywgdGhlIG51bWJlciBvZiBJTEEgcm91dGVycyBjYW1l IG91dCB0byA1MzAuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRvbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_1AFE10CF28AE8B4C9663445736B8034D38255422CAFRFD1MSGUSRJI_-- From nobody Thu May 31 09:49:28 2018 Return-Path: X-Original-To: ila@ietfa.amsl.com Delivered-To: ila@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A3812EC47 for ; Thu, 31 May 2018 09:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 W1b0KaYuTF1D for ; Thu, 31 May 2018 09:49:06 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 782DC127241 for ; Thu, 31 May 2018 09:48:51 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id e8-v6so28677628qth.0 for ; Thu, 31 May 2018 09:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=XKccfS44/Wl0cVjAlY1F/2r9ubhsVbgYAvLhEdUn7i0=; b=mAsfTERh5B9sroLXot3Ur3gHO9aaEm17WVnpEyzXuazPJC7CG5Wuc30haw694BoPvW Top06KE/sIb29JgAriN1LT7Jqq4wro4e5I0Hd7QeovAhSFNNsRMRO0kUPjLRF/tAe3e/ VfcMMpsmXD+XZOT7cbQXOGrbmeSDsM/fHH7cPNIclzlP0fIfrc4rP23g0ZWcGA9kTs/8 y3aBaWnx7yNhoF9sesyGAp2Sda51PirP7Y+qO9ToMbnLsphBqHID47eZjfaxcuF0/ahp G9f90s6QJPjKgdedOW9Quv1fVXcscPFxHR4sBAsQt/cDSJoUsx+alLMkKnk+MjfHvs4f WK0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=XKccfS44/Wl0cVjAlY1F/2r9ubhsVbgYAvLhEdUn7i0=; b=o0JanCSkzW6H6277yyaajv7AYjWdAJmoZC58Uk7aym7KWosiSgACiBQicH7RZckC5I DZTOruzBA3VV8KR7bym0/194QyEAb0uBwtjWYVj0CWgwIxXveZmogRpakNUDVEdZAcIn hjSOIjgRvnR301KQrT8MwArdxcXiUvJSq3w+G2Dylo3ukBRRcL/LrZ1n0vjVx/r0HdwZ 9//toud6MOnBWRfkFJFhvFqFTNoI/ncX0EPAsYaJF0V4X3e3LnbVVARI+u5niDqnZ7Il ybo96/G49rjlR7NooUU+FKfigHg4Z8rV5fvmJ0P3N1lxCx+vWS4eIkd5D9TQ/l5Iyy1c ZBvQ== X-Gm-Message-State: APt69E1g40gvFZLRP9nKoNJP4XWmks5LQJhcQnmUa8gfXmpWmqV8lpKm xKWLL19aHztlERJhpDA+4C4FG3V4f58ruO4iGxADZQ== X-Google-Smtp-Source: ADUXVKKzlHmz16eAkM054JiwmmbY8SXH+PBmmt94EACRHKMTFf55NXdFxdnJZB4bmjcoC3xKskgpAPbbm8yI8ZSJbtU= X-Received: by 2002:a0c:e4d3:: with SMTP id g19-v6mr7358255qvm.242.1527785330366; Thu, 31 May 2018 09:48:50 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:3042:0:0:0:0:0 with HTTP; Thu, 31 May 2018 09:48:49 -0700 (PDT) In-Reply-To: <1AFE10CF28AE8B4C9663445736B8034D38255422@CAFRFD1MSGUSRJI.ITServices.sbc.com> References: <5067FA81-B416-4A19-9F11-A08B35BB8B6D@gmail.com> <9C425F56-738C-4600-9DFF-9D30FC3872DC@gmail.com> <1AFE10CF28AE8B4C9663445736B8034D38255422@CAFRFD1MSGUSRJI.ITServices.sbc.com> From: Tom Herbert Date: Thu, 31 May 2018 09:48:49 -0700 Message-ID: To: "FIGURELLE, TERRY F" Cc: Tom Herbert , Lorenzo Colitti , "ila@ietf.org" , Alexandre Petrescu , Behcet Sarikaya , Dino Farinacci , 5GANGIP <5gangip@ietf.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ila] [5gangip] Scaling mapping systems (was Re: BOF Description) X-BeenThere: ila@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Identifier Locator Addressing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 16:49:19 -0000 On Wed, May 30, 2018 at 5:38 PM, FIGURELLE, TERRY F wrote: > You have a scaling problem there since you can handle that traffic exampl= e > on much less than 530 UPF=E2=80=99s (e.g. 20+20 is enough from capacity p= oint of > view). To cover all of the layer1 fiber paths of importance in continenta= l > US you only need a max of 180 locations. I doubt anyone but AT&T would go= to > that extreme on fiber plant connectivity. Adding more locations actually > increases latency and is not desired. > Terry, 530 would be the number of devices not locations. They can be co-located. That number is based one some back of the envelope calculations assuming memory and bandwidth. I believe an ILA-R would contain roughly the same amount of state as an anchor device in LTE would. In order to service critical low latency applications like those that would benefit from the 1ms latency target in 5G, proximity and number of hops become relevant. For 1ms RTT latency the devices must be within 93 miles of each just based on speed of light alone. Device processing reduces the maximum distance even more. The result is that the application servers need to be pushed far to the edge and a direct path between the client and server is needed for latency. This implies both geographic proximity as well as minimizing number of hops which is also desirable for increasing reliability, so MEC servers are deployed in central office, or even cell towers or RSUs to be close to the user. This is a motivation for anchorless routing that is in identifier/locator proposals. For ILA, the in intent is that critical low latency communications would have a direct path from ILA-N to ILA-N or ILA-N to ILA-H-- where ILA-H are the end servers themselves. Tom > > > From: 5gangip <5gangip-bounces@ietf.org> On Behalf Of Tom Herbert > Sent: Tuesday, February 06, 2018 12:28 PM > To: Lorenzo Colitti > Cc: Tom Herbert ; ila@ietf.org; Alexandre Petrescu > ; Behcet Sarikaya ; Dino > Farinacci ; 5GANGIP <5gangip@ietf.org> > Subject: Re: [5gangip] [Ila] Scaling mapping systems (was Re: BOF > Description) > > > > > > > > On Mon, Feb 5, 2018 at 10:34 PM, Lorenzo Colitti wro= te: > > On Tue, Feb 6, 2018 at 12:37 AM, Tom Herbert wrote: > > As time has gone on with experience in deployment, forwarding to another > node that has a large shared cache, like an RTR, seems to deal with the > issue in a compromised way. > > > > In ILAMP (https://tools.ietf.org/html/draft-herbert-ila-ilamp-00) secure > redirects are defined to be the primary means of populating a cache. On a > cache miss, a packet is forwarded into the network and routing should > forward the packet to an ILA router that contains the complete set of > mappings for the associated shard. The router performs the transformation > and can send a redirect back to the caching node. The redirect can be cac= hed > so that subsequent packets take a direct route and avoid the trianglular > routing. Redirects must be secure so that they cannot be spoofed, so for > that reason (and some others) the protocol is over TCP. The mapping cache= is > only an optimization and packets are never dropped or queued for pending > cache resolution. If the cache weren't present, communications would stil= l > be viable but sub-optimal; that characteristic establishes a bound for th= e > worst case DOS attack. > > > > Any thoughs on this approach? > > > > Hi Lorenzo, > > > > Thanks for the feedback! > > > > The obvious ones would seem: > > Will the working set of cache mappins fit in whatever memory is available > in, say, a large peering router? > > The cache needs to be sized to fit the working set. Please look at the > reference topology of section N. The intent is that caches would not be u= sed > at edge or peer routers, ILA router are used there which shard the mappin= g > database across some number of nodes. Mapping caches are at ILA-Ns which > are deployed deeper in the network towards the end hosts (like toward gNB= ). > There are more of these than ILA-Rs, however they are serve a small set o= f > users and would be implemented on lower end devices. The purpose of the > cache is to optimize latency and throughput of performance critical > intra-network communications (Ue to UE, UE to application server in > network). > > > > Remember that memory that is capable of sustaining routing lookups at ten= s > of gigabits per second is extremely expensive. > How do you defend against state exhaustion attacks whereby a large number= of > spoofed sources send packets to nonexistent destinations? > > No cache state is created for nonexistent destinations. > > > > How much bandwidth will be used for the redirects? How much CPU time will= be > used to process them? > How many servers are needed to store > > Suggest gaming this out for a large mobile operator with, say, 100M clien= ts, > 100 Internet connection points and 10T of traffic. > > > > I did an analysis of ILA scalability for a couple of scenarios (see > attached), For the 100M UEs, the number of ILA routers came out to 530. > > > > Tom > > > >