From nobody Mon Feb 4 00:31:56 2019 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF1E130E76; Mon, 4 Feb 2019 00:31:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ggx@gigix.net, lisp-chairs@ietf.org, lisp@ietf.org, db3546@att.com X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154926910896.22931.18135743734205947038.idtracker@ietfa.amsl.com> Date: Mon, 04 Feb 2019 00:31:48 -0800 Archived-At: Subject: [lisp] lisp - New Meeting Session Request for IETF 104 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 08:31:54 -0000 A new meeting session request has just been submitted by Luigi Iannone, a Chair of the lisp working group. --------------------------------------------------------- Working Group Name: Locator/ID Separation Protocol Area Name: Routing Area Session Requester: Luigi Iannone Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 45 Conflicts to Avoid: First Priority: rtgwg nvo3 i2rs grow sfc pim intarea lsr lsvr detnet maprg Second Priority: mboned icnrg irtfopen idr spring bier tsvwg Third Priority: bess People who must be present: Joel M. Halpern Wassim Haddad Deborah Brungard Luigi Iannone Padma Pillay-Esnault Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Feb 4 09:11:05 2019 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F6F130ED4; Mon, 4 Feb 2019 09:10:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Alvaro Retana To: "The IESG" Cc: draft-ietf-lisp-rfc6833bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154930025720.28654.6669816175211800214.idtracker@ietfa.amsl.com> Date: Mon, 04 Feb 2019 09:10:57 -0800 Archived-At: Subject: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6833bis-23: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 17:11:03 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-lisp-rfc6833bis-23: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) s/rfc8113/draft-ietf-lisp-rfc8113bis (2) §5.1: "Values in the "Not Assigned" range can be assigned according to procedures in [RFC8126]." This sentence is out of place because it doesn't specify which procedure...and the action is already specified in rfc8113bis anyway. (3) s/Not assigned/Unassigned To match what the registry says. From nobody Mon Feb 4 10:12:46 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18DE12008F; Mon, 4 Feb 2019 10:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 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_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=no 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 6d_-eH5p0CaZ; Mon, 4 Feb 2019 10:12:32 -0800 (PST) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 53AE4130ED1; Mon, 4 Feb 2019 10:12:32 -0800 (PST) Received: by mail-pl1-x630.google.com with SMTP id p8so295020plo.2; Mon, 04 Feb 2019 10:12:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=B8jCTedklCMYy44Vc8v2nIhD9AM9WTLHyHVFcak1d+U=; b=G5scN6ShTklKE76VPTEmsOrjCEnhVupv8sjqWxO7U9Qla9KxS2ZmSUWiOAuakK7VPu aPUdSztxPcC7JBVdRzybtm0TNNpDqmSnAZ4BJDgK5GhKYiejbAcy+XCdDnS6IP9wO6ks lWvDPlZ6AqRBPKTvmQrZXUf6xuil95Hb//irtWTGBucrYSQjBYhZAJ5Pyz1KlvPHfD20 yvTPzukKHtajruMXB5my+Ha4ivN7Sj90dwirVUwJWu+/Arqp1P4VO0ItETBcDplX1roo QprFOXVkQmNAGEPN790LmwgjS/oaOiP28co4xjMh9VlP0qPaUdtNyGBEx8keXzkHuYZM TtYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=B8jCTedklCMYy44Vc8v2nIhD9AM9WTLHyHVFcak1d+U=; b=Z+BpMGASoXsgokk8X7XWgH1LfX+y4IsxiYhPXowxUwhDsBo9Uzf2ESoJajzU7g/jlc yYTWNilk+ITGIB4LD/DyPkElpgmoqhVyMM8G12fF580aFAKNXOVWAoexuK7Ka4sCwgWL b+EynqhqrDCs3pf1DJsto/OgLjWsvIYWrZdeJ69TVdu7pNMokoDqW05DpkC4Fx+XX3Uf ldPdH9RR4kfTv7abM4IC2qtKCGKrYjPaKqDxBthPIEWxD8FMsAVZiwOfjjEOKmDvWjse /KI2sZzQ5Pma2CAB8h1zNImzOFaEROwp/LgkSBQiiL5dfZz57DbbwqDAkCAfmNYB68RV mmPg== X-Gm-Message-State: AHQUAuabw64S8iiTzj+zSOXEv87Ktxy74Xt7qPjNwDvA3Knw/sCP94Ie bO9dXs2Jvsr1LNR+ngNnJhM= X-Google-Smtp-Source: AHgI3IbogKSWEd3Yoti4aSOOHVsDfUYhM2V/WvQLIAM/PCYVm3UirfxdW1yw0QRSRGV2B86L5gUQKA== X-Received: by 2002:a17:902:b40d:: with SMTP id x13mr646212plr.237.1549303951721; Mon, 04 Feb 2019 10:12:31 -0800 (PST) Received: from [10.31.79.74] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id u12sm993894pgo.52.2019.02.04.10.12.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Feb 2019 10:12:30 -0800 (PST) From: Dino Farinacci Message-Id: Content-Type: multipart/mixed; boundary="Apple-Mail=_D7556DB4-F540-4927-8A06-27D418BF92BE" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 4 Feb 2019 10:12:29 -0800 In-Reply-To: <154930025720.28654.6669816175211800214.idtracker@ietfa.amsl.com> Cc: The IESG , draft-ietf-lisp-rfc6833bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, lisp@ietf.org To: Alvaro Retana References: <154930025720.28654.6669816175211800214.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6833bis-23: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 18:12:37 -0000 --Apple-Mail=_D7556DB4-F540-4927-8A06-27D418BF92BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Here is a diff for -24 that incorporates the changes below and = Albert=E2=80=99s changes from Ben=E2=80=99s comments. I will submit = today. Dino --Apple-Mail=_D7556DB4-F540-4927-8A06-27D418BF92BE Content-Disposition: attachment; filename=rfcdiff-6833bis-24.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-6833bis-24.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-lisp-rfc6833bis-23.txt - = draft-ietf-lisp-rfc6833bis-24.txt=20 =20 =20 =20 =20 =20 =20 =
< draft-ietf-lisp-rfc6833bis-23.txt  =  draft-ietf-lisp-rfc6833bis-24.txt >
=
Network Working = Group V. Fuller = Network Working Group = V. Fuller
Internet-Draft = D. Farinacci Internet-Draft = D. Farinacci
Obsoletes: 6833 = (if approved) Cisco Systems = Obsoletes: 6833 (if approved) = Cisco Systems
Intended status: = Standards Track A. Cabellos (Ed.) = Intended status: Standards Track = A. Cabellos (Ed.)
Expires: June 13, 2019 = UPC/BarcelonaTech Expires: August 8, 2019 = UPC/BarcelonaTech
= December = 10, 2018 = February 4, = 2019
=
= Locator/ID Separation Protocol (LISP) Control-Plane Locator/ID Separation Protocol (LISP) = Control-Plane
= draft-ietf-lisp-rfc6833bis-23 = = draft-ietf-lisp-rfc6833bis-24
=
Abstract = Abstract
=
This document = describes the Control-Plane and Mapping Service for the = This document describes the Control-Plane = and Mapping Service for the
Locator/ID = Separation Protocol (LISP), implemented by two new types = Locator/ID Separation Protocol (LISP), = implemented by two new types
of = LISP-speaking devices -- the LISP Map-Resolver and LISP = Map-Server of LISP-speaking devices = -- the LISP Map-Resolver and LISP Map-Server
-- that = provides a simplified "front end" for one or more Endpoint ID = -- that provides a simplified "front end" = for one or more Endpoint ID
to Routing = Locator mapping databases. to = Routing Locator mapping databases.
=
By using this = Control-Plane service interface and communicating with By using this Control-Plane service interface and = communicating with
=
skipping to = change at = page 1, line 47 =C2=B6 = skipping to change at page 1, line 47 =C2=B6
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
Task Force = (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also = distribute
working = documents as Internet-Drafts. The list of current Internet- = working documents as Internet-Drafts. The = list of current Internet-
Drafts is at = https://datatracker.ietf.org/drafts/current/. Drafts is at = https://datatracker.ietf.org/drafts/current/.
=
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
and may be = updated, replaced, or obsoleted by other documents at any = and may be updated, replaced, or obsoleted = by other documents at any
time. It is = inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as = reference
material or to = cite them other than as "work in progress." material or to cite them other than as "work in = progress."
=
This = Internet-Draft will expire on June 13, = 2019. This Internet-Draft will = expire on August 8, 2019.
=
Copyright = Notice Copyright Notice
=
Copyright = (c) 2018 IETF Trust and the persons = identified as the Copyright (c) = 2019 IETF Trust and the persons identified = as the
document = authors. All rights reserved. = document authors. All rights reserved.
=
This document = is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF = Trust's Legal
Provisions = Relating to IETF Documents = Provisions Relating to IETF Documents
= (https://trustee.ietf.org/license-info) in effect on the date = of = (https://trustee.ietf.org/license-info) in effect on the date of
publication of = this document. Please review these documents publication of this document. Please review these = documents
carefully, as = they describe your rights and restrictions with respect = carefully, as they describe your rights and = restrictions with respect
to this = document. Code Components extracted from this document must = to this document. Code Components extracted = from this document must
include = Simplified BSD License text as described in Section 4.e of = include Simplified BSD License text as = described in Section 4.e of
the Trust = Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without = warranty as
=
skipping to = change at = page 3, line 12 =C2=B6 = skipping to change at page 3, line 12 =C2=B6
12.2. LISP = Packet Type Codes . . . . . . . . . . . . . . . . . 44 = 12.2. LISP Packet Type Codes . . . . . . = . . . . . . . . . . . 44
12.3. LISP = ACT and Flag Fields . . . . . . . . . . . . . . . . 44 = 12.3. LISP ACT and Flag Fields . . . . . = . . . . . . . . . . . 44
12.4. LISP = Address Type Codes . . . . . . . . . . . . . . . . 45 = 12.4. LISP Address Type Codes . . . . . = . . . . . . . . . . . 45
12.5. LISP = Algorithm ID Numbers . . . . . . . . . . . . . . . 45 = 12.5. LISP Algorithm ID Numbers . . . . = . . . . . . . . . . . 45
12.6. LISP = Bit Flags . . . . . . . . . . . . . . . . . . . . . 46 = 12.6. LISP Bit Flags . . . . . . . . . . = . . . . . . . . . . . 46
13. References = . . . . . . . . . . . . . . . . . . . . . . . . . 49 13. References . . . . . . . . . . . . . . . . . . . = . . . . . . 49
13.1. = Normative References . . . . . . . . . . . . . . . . . . 49 = 13.1. Normative References . . . . . . . = . . . . . . . . . . . 49
13.2. = Informative References . . . . . . . . . . . . . . . . . 50 = 13.2. Informative References . . . . . . = . . . . . . . . . . . 50
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 55 = Appendix A. Acknowledgments . . . . . . . = . . . . . . . . . . . 55
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 55 = Appendix B. Document Change Log . . . . . = . . . . . . . . . . . 55
B.1. = Changes to draft-ietf-lisp-rfc6833bis-23 = . . . . . . . . 55 B.1. = Changes to draft-ietf-lisp-rfc6833bis-24 = . . . . . . . . 55
B.2. = Changes to draft-ietf-lisp-rfc6833bis-22 = . . . . . . . . 55 B.2. = Changes to draft-ietf-lisp-rfc6833bis-23 = . . . . . . . . 55
B.3. = Changes to draft-ietf-lisp-rfc6833bis-21 = . . . . . . . . 56 B.3. = Changes to draft-ietf-lisp-rfc6833bis-22 = . . . . . . . . 56
B.4. = Changes to draft-ietf-lisp-rfc6833bis-20 = . . . . . . . . 56 B.4. = Changes to draft-ietf-lisp-rfc6833bis-21 = . . . . . . . . 56
B.5. = Changes to draft-ietf-lisp-rfc6833bis-19 = . . . . . . . . 56 B.5. = Changes to draft-ietf-lisp-rfc6833bis-20 = . . . . . . . . 56
B.6. = Changes to draft-ietf-lisp-rfc6833bis-18 = . . . . . . . . 56 B.6. = Changes to draft-ietf-lisp-rfc6833bis-19 = . . . . . . . . 56
B.7. = Changes to draft-ietf-lisp-rfc6833bis-17 = . . . . . . . . 56 B.7. = Changes to draft-ietf-lisp-rfc6833bis-18 = . . . . . . . . 56
B.8. = Changes to draft-ietf-lisp-rfc6833bis-16 . . . . . . . . 57 = B.8. Changes to draft-ietf-lisp-rfc6833bis-17 . . . . . . . . = 56
B.9. Changes to draft-ietf-lisp-rfc6833bis-15 = . . . . . . . . 57 B.9. Changes to = draft-ietf-lisp-rfc6833bis-16 . . . . . . . . 57
B.10. Changes to draft-ietf-lisp-rfc6833bis-14 = . . . . . . . . 57 B.10. Changes to draft-ietf-lisp-rfc6833bis-15 = . . . . . . . . 57
B.11. Changes to draft-ietf-lisp-rfc6833bis-13 = . . . . . . . . 57 B.11. Changes to draft-ietf-lisp-rfc6833bis-14 = . . . . . . . . 57
B.12. Changes to draft-ietf-lisp-rfc6833bis-12 = . . . . . . . . 57 B.12. Changes to draft-ietf-lisp-rfc6833bis-13 = . . . . . . . . 57
B.13. Changes to draft-ietf-lisp-rfc6833bis-11 = . . . . . . . . 57 B.13. Changes to draft-ietf-lisp-rfc6833bis-12 = . . . . . . . . 57
B.14. Changes to draft-ietf-lisp-rfc6833bis-10 = . . . . . . . . 58 B.14. Changes to draft-ietf-lisp-rfc6833bis-11 = . . . . . . . . 57
B.15. Changes to draft-ietf-lisp-rfc6833bis-09 = . . . . . . . . 58 B.15. Changes to draft-ietf-lisp-rfc6833bis-10 = . . . . . . . . 58
B.16. Changes to draft-ietf-lisp-rfc6833bis-08 = . . . . . . . . 58 B.16. Changes to draft-ietf-lisp-rfc6833bis-09 = . . . . . . . . 58
B.17. Changes to draft-ietf-lisp-rfc6833bis-07 = . . . . . . . . 58 B.17. Changes to draft-ietf-lisp-rfc6833bis-08 = . . . . . . . . 58
B.18. Changes to draft-ietf-lisp-rfc6833bis-06 = . . . . . . . . 59 B.18. Changes to draft-ietf-lisp-rfc6833bis-07 = . . . . . . . . 58
B.19. Changes to draft-ietf-lisp-rfc6833bis-05 = . . . . . . . . 59 B.19. Changes to draft-ietf-lisp-rfc6833bis-06 = . . . . . . . . 59
B.20. Changes to draft-ietf-lisp-rfc6833bis-04 = . . . . . . . . 59 B.20. Changes to draft-ietf-lisp-rfc6833bis-05 = . . . . . . . . 59
B.21. Changes to draft-ietf-lisp-rfc6833bis-03 = . . . . . . . . 60 B.21. Changes to draft-ietf-lisp-rfc6833bis-04 = . . . . . . . . 59
B.22. Changes to draft-ietf-lisp-rfc6833bis-02 = . . . . . . . . 60 B.22. Changes to draft-ietf-lisp-rfc6833bis-03 = . . . . . . . . 60
B.23. Changes to draft-ietf-lisp-rfc6833bis-01 = . . . . . . . . 60 B.23. Changes to draft-ietf-lisp-rfc6833bis-02 = . . . . . . . . 60
B.24. Changes to draft-ietf-lisp-rfc6833bis-00 = . . . . . . . . 60 B.24. Changes to draft-ietf-lisp-rfc6833bis-01 = . . . . . . . . 60
B.25. Changes to = draft-farinacci-lisp-rfc6833bis-00 . . . . . . 60 B.25. Changes to = draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 60
= B.26. = Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 60
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 = Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 61
=
1. = Introduction 1. Introduction
=
The Locator/ID = Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see The Locator/ID Separation Protocol = [I-D.ietf-lisp-rfc6830bis] (see
also = [I-D.ietf-lisp-introduction]) specifies an architecture and = also [I-D.ietf-lisp-introduction]) specifies = an architecture and
mechanism for = dynamic tunneling by logically separating the addresses = mechanism for dynamic tunneling by logically = separating the addresses
currently used = by IP in two separate name spaces: Endpoint IDs currently used by IP in two separate name spaces: = Endpoint IDs
(EIDs), used = within sites; and Routing Locators (RLOCs), used on the = (EIDs), used within sites; and Routing = Locators (RLOCs), used on the
transit = networks that make up the Internet infrastructure. To transit networks that make up the Internet = infrastructure. To
=
skipping to = change at = page 4, line 46 =C2=B6 = skipping to change at page 4, line 47 =C2=B6
LISP is not = intended to address problems of connectivity and scaling = LISP is not intended to address problems of = connectivity and scaling
on behalf of = arbitrary communicating parties. Relevant situations on behalf of arbitrary communicating parties. = Relevant situations
are described = in the scoping section of the introduction to are described in the scoping section of the = introduction to
= [I-D.ietf-lisp-rfc6830bis]. = [I-D.ietf-lisp-rfc6830bis].
=
This document = obsoletes RFC 6830 and 6833. This = document obsoletes RFC 6830 and 6833.
=
1.1. Scope of = Applicability 1.1. Scope of = Applicability
=
LISP was = originally developed to address the Internet-wide route = LISP was originally developed to address the = Internet-wide route
scaling = problem [RFC4984].. While there are a = number of approaches scaling = problem [RFC4984]. While there are a = number of approaches of
of interest = for that problem, as LISP as been developed and refined, = interest for that problem, as LISP as been = developed and refined, a
a large = number of other LISP uses have been found and are being used. = large number of other LISP uses have been = found and are being used.
As such, the = design and development of LISP has changed so as to As such, the design and development of LISP has = changed so as to
focus on these = use cases. The common property of these uses is a focus on these use cases. The common property of = these uses is a
large set of = cooperating entities seeking to communicate over the large set of cooperating entities seeking to = communicate over the
public = Internet or other large underlay IP infrastructures, while = public Internet or other large underlay IP = infrastructures, while
keeping the = addressing and topology of the cooperating entities keeping the addressing and topology of the = cooperating entities
separate from = the underlay and Internet topology, routing, and separate from the underlay and Internet topology, = routing, and
= addressing. addressing.
=
2. Requirements = Notation 2. Requirements = Notation
=
=
skipping to = change at = page 11, line 10 =C2=B6 = skipping to change at page 11, line = 10 =C2=B6
=
The format of = control messages includes the UDP header so the The format of control messages includes the UDP = header so the
checksum and = length fields can be used to protect and delimit message = checksum and length fields can be used to = protect and delimit message
= boundaries. boundaries.
=
5.1. LISP = Control Packet Type Allocations 5.1. = LISP Control Packet Type Allocations
=
This section = defines the LISP control message formats and summarizes = This section defines the LISP control = message formats and summarizes
for IANA the = LISP Type codes assigned by this document. For for IANA the LISP Type codes assigned by this = document. For
completeness, = the summary below includes the LISP Shared Extension completeness, the summary below includes the LISP = Shared Extension
Message = assigned by [RFC8113]. Message type = definitions are: Message assigned = by [I-D.ietf-lisp-rfc8113bis]. Message = type
= definitions are:
=
Reserved: = 0 b'0000' = Reserved: 0 b'0000'
LISP = Map-Request: 1 b'0001' LISP Map-Request: 1 = b'0001'
LISP = Map-Reply: 2 b'0010' LISP Map-Reply: 2 = b'0010'
LISP = Map-Register: 3 b'0011' LISP Map-Register: 3 = b'0011'
LISP = Map-Notify: 4 b'0100' LISP Map-Notify: 4 = b'0100'
LISP = Map-Notify-Ack: 5 b'0101' LISP Map-Notify-Ack: 5 = b'0101'
LISP = Map-Referral: 6 b'0110' LISP Map-Referral: 6 = b'0110'
Not Assigned 7 = b'0111' Unassigned 7 = b'0111'
LISP = Encapsulated Control Message: 8 b'1000' LISP Encapsulated Control Message: 8 = b'1000'
Not Assigned 9-14 = b'1001'- b'1110' Unassigned 9-14 = b'1001'- b'1110'
LISP Shared = Extension Message: 15 b'1111' [RFC8113] = LISP Shared Extension Message: 15 b'1111' [RFC8113bis]
Values in the "Not Assigned" range can be assigned = according to
procedures in [RFC8126].
=
Protocol = designers experimenting with new message formats are Protocol designers experimenting with new message = formats are
recommended to = use the LISP Shared Extension Message Type described recommended to use the LISP Shared Extension Message = Type described
in [RFC8113]. = in [I-D.ietf-lisp-rfc8113bis].
=
All LISP = Control-Plane messages use Address Family Identifiers (AFI) = All LISP Control-Plane messages use Address = Family Identifiers (AFI)
[AFI] or LISP = Canonical Address Format (LCAF) [RFC8060] formats to [AFI] or LISP Canonical Address Format (LCAF) = [RFC8060] formats to
encode either = fixed or variable length addresses. This includes encode either fixed or variable length addresses. = This includes
explicit = fields in each control message or part of EID-records or = explicit fields in each control message or = part of EID-records or
RLOC-records = in commonly formatted messages. = RLOC-records in commonly formatted messages.
=
The LISP = control-plane describes how other data-planes can encode = The LISP control-plane describes how other = data-planes can encode
messages to = support the Soliciting of Map-Requests as well as RLOC- = messages to support the Soliciting of = Map-Requests as well as RLOC-
probing = procedures. probing = procedures.
=
skipping to = change at = page 28, line 49 =C2=B6 = skipping to change at page 28, line = 49 =C2=B6
+-> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= +-> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Packet field = descriptions: Packet field = descriptions:
=
Type: 4/5 = (Map-Notify/Map-Notify-Ack) Type: = 4/5 (Map-Notify/Map-Notify-Ack)
=
The Map-Notify = message has the same contents as a Map-Register The Map-Notify message has the same contents as a = Map-Register
message. See = the Map-Register section for field descriptions and the = message. See the Map-Register section for = field descriptions and the
Map-Reply = section for EID-record and RLOC-record descriptions. Map-Reply section for EID-record and RLOC-record = descriptions.
=
= The fields of the = Map-Notify are copied from the corresponding Map-
= Register to = acknowledge its correct processing. For an unsolicited
= Map-Notify, the = fields of a Map-Notify used for publish/subscribe are
= specified in = [I-D.ietf-lisp-pubsub]].
= =
The = Map-Notify-Ack message has the same contents as a Map-Notify = The Map-Notify-Ack message has the same = contents as a Map-Notify
message. It = is used to acknowledge the receipt of a Map-Notify message. It is used to acknowledge the receipt of a = Map-Notify
(solicited or = unsolicited) and for the sender to stop retransmitting (solicited or unsolicited) and for the sender to stop = retransmitting
a Map-Notify = with the same nonce. a Map-Notify = with the same nonce. The fields of the = Map-Notify-Ack
= are copied from the = corresponding Map-Notify message to acknowledge
= its correct = processing.
=
A Map-Server = sends an unsolicited Map-Notify message (one that is not = A Map-Server sends an unsolicited Map-Notify = message (one that is not
used as an = acknowledgment to a Map-Register message) that follows the = used as an acknowledgment to a Map-Register = message) that follows the
Congestion = Control And Relability Guideline sections of [RFC8085]. A = Congestion Control And Relability Guideline = sections of [RFC8085]. A
Map-Notify is = retransmitted until a Map-Notify-Ack is received by the = Map-Notify is retransmitted until a = Map-Notify-Ack is received by the
Map-Server = with the same nonce used in the Map-Notify message. If a = Map-Server with the same nonce used in the = Map-Notify message. If a
Map-Notify-Ack = is never received by the Map-Server, it issues a log Map-Notify-Ack is never received by the Map-Server, = it issues a log
message. An = implementation SHOULD retransmit up to 3 times at 3 message. An implementation SHOULD retransmit up to 3 = times at 3
second = retransmission intervals, after which time the retransmission = second retransmission intervals, after which = time the retransmission
interval is = exponentially backed-off for another 3 retransmission interval is exponentially backed-off for another 3 = retransmission
=
skipping to = change at = page 41, line 40 =C2=B6 = skipping to change at page 41, line = 40 =C2=B6
attacker to = mount DoS and/or amplification attacks. Attackers can attacker to mount DoS and/or amplification attacks. = Attackers can
send = Map-Requests at high rates to overload LISP nodes and increase = send Map-Requests at high rates to overload = LISP nodes and increase
the state = maintained by such nodes or consume CPU cycles. Such the state maintained by such nodes or consume CPU = cycles. Such
threats can be = mitigated by systematically applying filters and rate threats can be mitigated by systematically applying = filters and rate
= limiters. limiters.
=
The 2-way LISP = control-plane header nonce exchange can be used to The 2-way LISP control-plane header nonce exchange = can be used to
avoid ITR = spoofing attacks, but active on-path attackers (e.g 'man- = avoid ITR spoofing attacks, but active = on-path attackers (e.g 'man-
= in-the-middle') capable of intercepting the nonce can exploit = the in-the-middle') capable of = intercepting the nonce can exploit the
= Map-Request/Map-Reply message exchange to inject forged = mappings Map-Request/Map-Reply = message exchange to inject forged mappings
directly in = the ITR EID-to-RLOC map-cache. In addition, valid ETRs = directly in the ITR EID-to-RLOC map-cache. = This can lead to traffic
in the = system can perform overclaiming attacks. In this case, = being redirected to = the attacker, see further details in [RFC7835].
attackers = can claim to own an EID-prefix that is larger than the In addition, valid ETRs in the system can perform = overclaiming
prefix owned = by the ETR. Such attacks can be addressed by using attacks. In this case, attackers can claim to own = an EID-prefix that
LISP-SEC = [I-D.ietf-lisp-sec]. The LISP-SEC protocol defines a is larger than the prefix owned by the ETR. Such = attacks can be
mechanism = for providing origin authentication, integrity, anti- = addressed by using LISP-SEC [I-D.ietf-lisp-sec]. The LISP-SEC
replay, protection, and prevention of 'man-in-the-middle' and 'prefix = protocol defines a mechanism for providing = origin authentication,
= overclaiming' attacks on the Map-Request/Map-Reply exchange. In = integrity, anti-replay, protection, and prevention of 'man-in-the-
addition and = while beyond the scope of securing an individual Map- middle' and 'prefix overclaiming' attacks on = the Map-Request/Map-
Server or Map-Resolver, it should be noted = that LISP-SEC can be Reply exchange. In addition and while beyond = the scope of securing
complemented = by additional security mechanisms defined by the Mapping = an individual Map-Server or Map-Resolver, it should be noted = that
System = Infrastructure. For instance, BGP-based = LISP-ALT [RFC6836] LISP-SEC can be = complemented by additional security mechanisms
can take = advantage of standards work on adding security to BGP while = defined by the Mapping System = Infrastructure. For instance, BGP-
LISP-DDT = [RFC8111] defines its own additional security mechanisms. = based = LISP-ALT [RFC6836] can take advantage of standards work on
= adding security to BGP while LISP-DDT = [RFC8111] defines its own
= additional security mechanisms.
=
To publish an = authoritative EID-to-RLOC mapping with a Map-Server To publish an authoritative EID-to-RLOC mapping with = a Map-Server
using the = Map-Register message, an ETR includes authentication data = using the Map-Register message, an ETR = includes authentication data
that is a MAC = of the entire message using a pair-wise shared key. An = that is a MAC of the entire message using a = pair-wise shared key. An
implementation = MUST support use of HMAC-SHA-1-96 [RFC2104] and SHOULD implementation MUST support use of HMAC-SHA-1-96 = [RFC2104] and SHOULD
support use of = HMAC-SHA-256-128 [RFC6234] (SHA-256 truncated to 128 support use of HMAC-SHA-256-128 [RFC6234] (SHA-256 = truncated to 128
bits). The = Map-Register message is vulnerable to replay attacks by a = bits). The Map-Register message is = vulnerable to replay attacks by a
= man-in-the-middle. A compromised ETR can overclaim the prefix = it man-in-the-middle. A = compromised ETR can overclaim the prefix it
owns and = successfully register it on its corresponding Map-Server. = owns and successfully register it on its = corresponding Map-Server.
To mitigate = this and as noted in Section 8.2, a Map-Server SHOULD To mitigate this and as noted in Section 8.2, a = Map-Server SHOULD
=
skipping to = change at = page 49, line 20 =C2=B6 = skipping to change at page 49, line = 20 =C2=B6
= Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID = Iannone, L., Saucez, D., and O. = Bonaventure, "Locator/ID
= Separation Protocol (LISP) Map-Versioning", draft-ietf- = Separation Protocol (LISP) = Map-Versioning", draft-ietf-
= lisp-6834bis-02 (work in progress), September 2018. lisp-6834bis-02 (work in progress), = September 2018.
=
= [I-D.ietf-lisp-rfc6830bis] = [I-D.ietf-lisp-rfc6830bis]
= Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. = Farinacci, D., Fuller, V., Meyer, = D., Lewis, D., and A.
= Cabellos-Aparicio, "The Locator/ID Separation Protocol Cabellos-Aparicio, "The Locator/ID = Separation Protocol
= (LISP)", draft-ietf-lisp-rfc6830bis-26 (work in progress), = (LISP)", = draft-ietf-lisp-rfc6830bis-26 (work in progress),
= November 2018. November = 2018.
=
= [I-D.ietf-lisp-rfc8113bis]
= = Boucadair, M. and C. Jacquenet, "Locator/ID Separation
= Protocol = (LISP): Shared Extension Message & IANA Registry
= for = Packet Type Allocations", draft-ietf-lisp-
= = rfc8113bis-03 (work in progress), January 2019.
= =
= [I-D.ietf-lisp-sec] = [I-D.ietf-lisp-sec]
= Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Maino, F., Ermagan, V., Cabellos-Aparicio, = A., and D.
= Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-17 = Saucez, "LISP-Security = (LISP-SEC)", draft-ietf-lisp-sec-17
= (work in progress), November 2018. = (work in progress), November 2018.
=
[RFC2404] = Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within = [RFC2404] Madson, C. and R. Glenn, "The Use = of HMAC-SHA-1-96 within
ESP = and AH", RFC 2404, DOI 10.17487/RFC2404, November ESP and AH", RFC 2404, DOI = 10.17487/RFC2404, November
= 1998, <https://www.rfc-editor.org/info/rfc2404>. 1998, = <https://www.rfc-editor.org/info/rfc2404>.
=
[RFC4086] = Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. = Crocker,
=
skipping to = change at = page 53, line 31 =C2=B6 = skipping to change at page 53, line = 37 =C2=B6
[RFC8061] = Farinacci, D. and B. Weis, "Locator/ID Separation Protocol = [RFC8061] Farinacci, D. and B. Weis, = "Locator/ID Separation Protocol
= (LISP) Data-Plane Confidentiality", RFC 8061, (LISP) Data-Plane Confidentiality", RFC = 8061,
DOI = 10.17487/RFC8061, February 2017, = DOI 10.17487/RFC8061, February 2017,
= <https://www.rfc-editor.org/info/rfc8061>. = <https://www.rfc-editor.org/info/rfc8061>.
=
[RFC8111] = Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, = A., and A.
= Smirnov, "Locator/ID Separation Protocol Delegated Smirnov, "Locator/ID Separation Protocol = Delegated
= Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, = Database Tree (LISP-DDT)", RFC = 8111, DOI 10.17487/RFC8111,
May = 2017, <https://www.rfc-editor.org/info/rfc8111>. May 2017, = <https://www.rfc-editor.org/info/rfc8111>.
=
[RFC8113] Boucadair, M. and C. Jacquenet, "Locator/ID = Separation
Protocol (LISP): Shared Extension Message = & IANA Registry
for Packet Type Allocations", RFC = 8113,
DOI 10.17487/RFC8113, March = 2017,
= <https://www.rfc-editor.org/info/rfc8113>. =
= =
[RFC8126] = Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, = "Guidelines for
= Writing an IANA Considerations Section in RFCs", BCP 26, = Writing an IANA Considerations = Section in RFCs", BCP 26,
RFC = 8126, DOI 10.17487/RFC8126, June 2017, = RFC 8126, DOI 10.17487/RFC8126, June 2017,
= <https://www.rfc-editor.org/info/rfc8126>. = <https://www.rfc-editor.org/info/rfc8126>.
=
[RFC8174] = Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs = Lowercase in RFC
= 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, = 2119 Key Words", BCP 14, RFC = 8174, DOI 10.17487/RFC8174,
May = 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, = <https://www.rfc-editor.org/info/rfc8174>.
=
[RFC8378] = Moreno, V. and D. Farinacci, "Signal-Free Locator/ID [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free = Locator/ID
=
skipping = to change at page 55, line = 30 =C2=B6 = skipping to change at page 55, line = 30 =C2=B6
Kaduk, Eric = Rescorla, Alvaro Retana, Alexey Melnikov, Alissa Cooper, = Kaduk, Eric Rescorla, Alvaro Retana, Alexey = Melnikov, Alissa Cooper,
Suresh = Krishnan, Alberto Rodriguez-Natal, Vina Ermagen, Mohamed = Suresh Krishnan, Alberto Rodriguez-Natal, = Vina Ermagen, Mohamed
Boucadair, = Brian Trammell, Sabrina Tanamal, and John Drake. The Boucadair, Brian Trammell, Sabrina Tanamal, and John = Drake. The
contributions = they offered greatly added to the security, scale, and contributions they offered greatly added to the = security, scale, and
robustness of = the LISP architecture and protocols. = robustness of the LISP architecture and protocols.
=
Appendix B. = Document Change Log Appendix B. = Document Change Log
=
[RFC Editor: = Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on = publication as RFC.]
=
B.1. Changes = to draft-ietf-lisp-rfc6833bis-23 B.1. = Changes to draft-ietf-lisp-rfc6833bis-24
=
= o Posted January = 2019.
=
= o Added suggested = text from Albert that Benjamin Kaduk agreed with.
=
= o Added suggested = editorial comments from Alvaro's rewview.
=
= B.2. Changes to = draft-ietf-lisp-rfc6833bis-23
=
o Posted = December 2018. o Posted December = 2018.
=
o Added to = Security Considerations section that deployments that o Added to Security Considerations section that = deployments that
care about = prefix over claiming should use LISP-SEC. care about prefix over claiming should use = LISP-SEC.
=
o Added to = Security Considerations section that DTLS or LISP-crypto = o Added to Security Considerations section = that DTLS or LISP-crypto
be used for = control-plane privacy. be used = for control-plane privacy.
=
o Make = LISP-SEC a normative reference. o = Make LISP-SEC a normative reference.
=
o Make it = more clear where field descriptions are spec'ed when o Make it more clear where field descriptions are = spec'ed when
referencing = to the same fields in other packet types. referencing to the same fields in other packet = types.
=
B.2. Changes to = draft-ietf-lisp-rfc6833bis-22 B.3. Changes to = draft-ietf-lisp-rfc6833bis-22
=
o Posted week = after IETF November 2018. o Posted = week after IETF November 2018.
=
o No longer = need to use IPSEC for replay attacks. = o No longer need to use IPSEC for replay attacks.
=
B.3. Changes to = draft-ietf-lisp-rfc6833bis-21 B.4. Changes to = draft-ietf-lisp-rfc6833bis-21
=
o Posted = early November 2018. o Posted = early November 2018.
=
o Added I-bit = back in because its necessary to use for Map-Register o Added I-bit back in because its necessary to use = for Map-Register
replay = attack scenarios. The Map-Server tracks the nonce per xTR- = replay attack scenarios. The Map-Server = tracks the nonce per xTR-
ID to = detect duplicate or replayed Map-Register messages. ID to detect duplicate or replayed Map-Register = messages.
=
B.4. Changes to = draft-ietf-lisp-rfc6833bis-20 B.5. Changes to = draft-ietf-lisp-rfc6833bis-20
=
o Posted late = October 2018. o Posted late = October 2018.
=
o Changed = description about "reserved" bits to state "reserved and = o Changed description about "reserved" bits = to state "reserved and
= unassigned". = unassigned".
=
o Make it = more clear how Map-Register nonce processing is performed = o Make it more clear how Map-Register nonce = processing is performed
in an ETR = and Map-Server. in an ETR and = Map-Server.
=
B.5. Changes to = draft-ietf-lisp-rfc6833bis-19 B.6. Changes to = draft-ietf-lisp-rfc6833bis-19
=
o Posted mid = October 2018. o Posted mid October = 2018.
=
o Added Fabio = text to the Security Considerations section. o Added Fabio text to the Security Considerations = section.
=
B.6. Changes to = draft-ietf-lisp-rfc6833bis-18 B.7. Changes to = draft-ietf-lisp-rfc6833bis-18
=
o Posted mid = October 2018. o Posted mid October = 2018.
=
o Fixed = comments from Eric after more email clarity. o Fixed comments from Eric after more email = clarity.
=
B.7. Changes to = draft-ietf-lisp-rfc6833bis-17 B.8. Changes to = draft-ietf-lisp-rfc6833bis-17
=
o Posted = early October 2018. o Posted early = October 2018.
=
o Changes to = reflect comments from Sep 27th Telechat. o Changes to reflect comments from Sep 27th = Telechat.
=
o Added all = flag bit definitions as request for allocation in IANA o Added all flag bit definitions as request for = allocation in IANA
= Considersations section. = Considersations section.
=
o Added an = applicability statement in section 1 to address security = o Added an applicability statement in = section 1 to address security
concerns = from Telechat. concerns from = Telechat.
=
o Moved m-bit = description and IANA request to draft-ietf-lisp-mn. o Moved m-bit description and IANA request to = draft-ietf-lisp-mn.
=
o Moved I-bit = description and IANA request to draft-ietf-lisp- o Moved I-bit description and IANA request to = draft-ietf-lisp-
= pubsub. pubsub.
=
B.8. Changes to = draft-ietf-lisp-rfc6833bis-16 B.9. Changes to = draft-ietf-lisp-rfc6833bis-16
=
o Posted = Late-September 2018. o Posted = Late-September 2018.
=
o Re-wrote = Security Considerations section. Thanks Albert. o Re-wrote Security Considerations section. Thanks = Albert.
=
o Added = Alvaro text to be more clear about IANA actions. o Added Alvaro text to be more clear about IANA = actions.
=
B.9. Changes to = draft-ietf-lisp-rfc6833bis-15 B.10. Changes to = draft-ietf-lisp-rfc6833bis-15
=
o Posted = mid-September 2018. o Posted = mid-September 2018.
=
o Changes to = reflect comments from Colin and Mirja. = o Changes to reflect comments from Colin and Mirja.
=
B.10. Changes to = draft-ietf-lisp-rfc6833bis-14 B.11. Changes to = draft-ietf-lisp-rfc6833bis-14
=
o Posted = September 2018. o Posted September = 2018.
=
o Changes to = reflect comments from Genart, RTGarea, and Secdir o Changes to reflect comments from Genart, RTGarea, = and Secdir
= reviews. reviews.
=
B.11. Changes to = draft-ietf-lisp-rfc6833bis-13 B.12. Changes to = draft-ietf-lisp-rfc6833bis-13
=
o Posted = August 2018. o Posted August = 2018.
=
o Final = editorial changes before RFC submission for Proposed o Final editorial changes before RFC submission for = Proposed
= Standard. Standard.
=
o Added = section "Changes since RFC 6833" so implementators are o Added section "Changes since RFC 6833" so = implementators are
informed of = any changes since the last RFC publication. informed of any changes since the last RFC = publication.
=
B.12. Changes to = draft-ietf-lisp-rfc6833bis-12 B.13. Changes to = draft-ietf-lisp-rfc6833bis-12
=
o Posted late = July 2018. o Posted late July = 2018.
=
o Moved = RFC6830bis and RFC6834bis to Normative References. o Moved RFC6830bis and RFC6834bis to Normative = References.
=
B.13. Changes to = draft-ietf-lisp-rfc6833bis-11 B.14. Changes to = draft-ietf-lisp-rfc6833bis-11
=
o Posted July = 2018. o Posted July 2018.
=
o Fixed Luigi = editorial comments to ready draft for RFC status and o Fixed Luigi editorial comments to ready draft for = RFC status and
ran through = IDNITs again. ran through IDNITs = again.
=
B.14. Changes to = draft-ietf-lisp-rfc6833bis-10 B.15. Changes to = draft-ietf-lisp-rfc6833bis-10
=
o Posted = after LISP WG at IETF week March. o = Posted after LISP WG at IETF week March.
=
o Move AD = field encoding after S-bit in the ECM packet format o Move AD field encoding after S-bit in the ECM = packet format
description = section. description = section.
=
o Say more = about when the new Drop actions should be sent. o Say more about when the new Drop actions should be = sent.
=
B.15. Changes to = draft-ietf-lisp-rfc6833bis-09 B.16. Changes to = draft-ietf-lisp-rfc6833bis-09
=
o Posted = March IETF week 2018. o Posted = March IETF week 2018.
=
o Fixed = editorial comments submitted by document shepherd Luigi = o Fixed editorial comments submitted by = document shepherd Luigi
= Iannone. Iannone.
=
B.16. Changes to = draft-ietf-lisp-rfc6833bis-08 B.17. Changes to = draft-ietf-lisp-rfc6833bis-08
=
o Posted = March 2018. o Posted March = 2018.
=
o Added = RLOC-probing algorithm. o Added = RLOC-probing algorithm.
=
o Added = Solicit-Map Request algorithm. o = Added Solicit-Map Request algorithm.
=
o Added = several mechanisms (from 6830bis) regarding Routing Locator = o Added several mechanisms (from 6830bis) = regarding Routing Locator
= Reachability. = Reachability.
=
o Added port = 4342 to IANA Considerations section. = o Added port 4342 to IANA Considerations section.
=
B.17. Changes to = draft-ietf-lisp-rfc6833bis-07 B.18. Changes to = draft-ietf-lisp-rfc6833bis-07
=
o Posted = December 2017. o Posted December = 2017.
=
o Make it = more clear in a couple of places that RLOCs are used to = o Make it more clear in a couple of places = that RLOCs are used to
locate ETRs = more so than for Map-Server Map-Request forwarding. locate ETRs more so than for Map-Server = Map-Request forwarding.
=
o Make it = clear that "encapsualted" for a control message is an ECM = o Make it clear that "encapsualted" for a = control message is an ECM
based = message. based message.
=
o Make it = more clear what messages use source-port 4342 and which = o Make it more clear what messages use = source-port 4342 and which
=
skipping = to change at page 59, line = 13 =C2=B6 = skipping to change at page 59, line = 13 =C2=B6
Can use = othe AFIs then IPv4 and IPv6. = Can use othe AFIs then IPv4 and IPv6.
=
o Many = editorial changes to clarify text. = o Many editorial changes to clarify text.
=
o Changed = some "must", "should", and "may" to capitalized. o Changed some "must", "should", and "may" to = capitalized.
=
o Added = definitions for Map-Request and Map-Reply messages. o Added definitions for Map-Request and Map-Reply = messages.
=
o Ran = document through IDNITs. o Ran = document through IDNITs.
=
B.18. Changes to = draft-ietf-lisp-rfc6833bis-06 B.19. Changes to = draft-ietf-lisp-rfc6833bis-06
=
o Posted = October 2017. o Posted October = 2017.
=
o Spec the = I-bit to include the xTR-ID in a Map-Request message to = o Spec the I-bit to include the xTR-ID in a = Map-Request message to
be = consistent with the Map-Register message and to anticipate the = be consistent with the Map-Register = message and to anticipate the
= introduction of pubsub functionality to allow Map-Requests to = introduction of pubsub functionality to = allow Map-Requests to
subscribe = to RLOC-set changes. subscribe = to RLOC-set changes.
=
o Updated = references for individual submissions that became working = o Updated references for individual = submissions that became working
group = documents. group = documents.
=
o Updated = references for working group documents that became RFCs. = o Updated references for working group = documents that became RFCs.
=
B.19. Changes to = draft-ietf-lisp-rfc6833bis-05 B.20. Changes to = draft-ietf-lisp-rfc6833bis-05
=
o Posted May = 2017. o Posted May 2017.
=
o Update IANA = Considerations section based on new requests from this o Update IANA Considerations section based on new = requests from this
document = and changes from what was requested in [RFC6830]. document and changes from what was requested in = [RFC6830].
=
B.20. Changes to = draft-ietf-lisp-rfc6833bis-04 B.21. Changes to = draft-ietf-lisp-rfc6833bis-04
=
o Posted May = 2017. o Posted May 2017.
=
o Clarify how = the Key-ID field is used in Map-Register and Map- o Clarify how the Key-ID field is used in = Map-Register and Map-
Notify = messages. Break the 16-bit field into a 8-bit Key-ID field = Notify messages. Break the 16-bit field = into a 8-bit Key-ID field
and a 8-bit = Algorithm-ID field. and a 8-bit = Algorithm-ID field.
=
o Move the = Control-Plane codepoints from the IANA Considerations o Move the Control-Plane codepoints from the IANA = Considerations
section of = RFC6830bis to the IANA Considerations section of this section of RFC6830bis to the IANA Considerations = section of this
= document. document.
=
o In the = "LISP Control Packet Type Allocations" section, indicate = o In the "LISP Control Packet Type = Allocations" section, indicate
how message = Types are IANA allocated and how experimental RFC8113 how message Types are IANA allocated and how = experimental RFC8113
sub-types = should be requested. sub-types = should be requested.
=
B.21. Changes to = draft-ietf-lisp-rfc6833bis-03 B.22. Changes to = draft-ietf-lisp-rfc6833bis-03
=
o Posted = April 2017. o Posted April = 2017.
=
o Add types = 9-14 and specify they are not assigned. = o Add types 9-14 and specify they are not assigned.
=
o Add the = "LISP Shared Extension Message" type and point to RFC8113. = o Add the "LISP Shared Extension Message" = type and point to RFC8113.
=
B.22. Changes to = draft-ietf-lisp-rfc6833bis-02 B.23. Changes to = draft-ietf-lisp-rfc6833bis-02
=
o Posted = April 2017. o Posted April = 2017.
=
o Clarify = that the LISP Control-Plane document defines how the LISP = o Clarify that the LISP Control-Plane = document defines how the LISP
Data-Plane = uses Map-Requests with either the SMR-bit set or the Data-Plane uses Map-Requests with either the = SMR-bit set or the
P-bit set = supporting mapping updates and RLOC-probing. Indicating = P-bit set supporting mapping updates and = RLOC-probing. Indicating
that other = Data-Planes can use the same mechanisms or their own that other Data-Planes can use the same mechanisms = or their own
defined = mechanisms to achieve the same functionality. defined mechanisms to achieve the same = functionality.
=
B.23. Changes to = draft-ietf-lisp-rfc6833bis-01 B.24. Changes to = draft-ietf-lisp-rfc6833bis-01
=
o Posted = March 2017. o Posted March = 2017.
=
o Include = references to new RFCs published. o = Include references to new RFCs published.
=
o Remove = references to self. o Remove = references to self.
=
o Change = references from RFC6830 to RFC6830bis. = o Change references from RFC6830 to RFC6830bis.
=
o Add two new = action/reasons to a Map-Reply has posted to the LISP o Add two new action/reasons to a Map-Reply has = posted to the LISP
WG mailing = list. WG mailing list.
=
o In intro = section, add refernece to I-D.ietf-lisp-introduction. o In intro section, add refernece to = I-D.ietf-lisp-introduction.
=
o Removed = Open Issues section and references to "experimental". o Removed Open Issues section and references to = "experimental".
=
B.24. Changes to = draft-ietf-lisp-rfc6833bis-00 B.25. Changes to = draft-ietf-lisp-rfc6833bis-00
=
o Posted = December 2016. o Posted December = 2016.
=
o Created = working group document from draft-farinacci-lisp o Created working group document from = draft-farinacci-lisp
-rfc6833-00 = individual submission. No other changes made. -rfc6833-00 individual submission. No other = changes made.
=
B.25. Changes to = draft-farinacci-lisp-rfc6833bis-00 B.26. Changes to = draft-farinacci-lisp-rfc6833bis-00
=
o Posted = November 2016. o Posted November = 2016.
=
o This is the = initial draft to turn RFC 6833 into RFC 6833bis. o This is the initial draft to turn RFC 6833 into = RFC 6833bis.
=
o The = document name has changed from the "Locator/ID Separation = o The document name has changed from the = "Locator/ID Separation
Protocol = (LISP) Map-Server Interface" to the "Locator/ID Protocol (LISP) Map-Server Interface" to the = "Locator/ID
Separation = Protocol (LISP) Control-Plane". = Separation Protocol (LISP) Control-Plane".
=
o The = fundamental change was to move the Control-Plane messages from = o The fundamental change was to move the = Control-Plane messages from
 End of changes. 40 change blocks. 
87 lines changed or = deleted 103 lines changed or = added

This = html diff was produced by rfcdiff 1.47. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20 = --Apple-Mail=_D7556DB4-F540-4927-8A06-27D418BF92BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 4, 2019, at 9:10 AM, Alvaro Retana = wrote: >=20 > Alvaro Retana has entered the following ballot position for > draft-ietf-lisp-rfc6833bis-23: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > (1) s/rfc8113/draft-ietf-lisp-rfc8113bis >=20 > (2) =C2=A75.1: "Values in the "Not Assigned" range can be assigned = according to > procedures in [RFC8126]." This sentence is out of place because it = doesn't > specify which procedure...and the action is already specified in = rfc8113bis > anyway. >=20 > (3) s/Not assigned/Unassigned To match what the registry says. >=20 >=20 --Apple-Mail=_D7556DB4-F540-4927-8A06-27D418BF92BE-- From nobody Mon Feb 4 10:23:32 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2BB7130EE3; Mon, 4 Feb 2019 10:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 29GyNZiS9aWL; Mon, 4 Feb 2019 10:23:19 -0800 (PST) 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 4600D130EDF; Mon, 4 Feb 2019 10:23:19 -0800 (PST) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x14I5Ya0014120; Mon, 4 Feb 2019 13:23:17 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049295.ppops.net-00191d01. with ESMTP id 2qes7x2th3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 04 Feb 2019 13:23:17 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x14INF9d007282; Mon, 4 Feb 2019 13:23:16 -0500 Received: from zlp27128.vci.att.com (zlp27128.vci.att.com [135.66.87.50]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x14IN8U2007127; Mon, 4 Feb 2019 13:23:08 -0500 Received: from zlp27128.vci.att.com (zlp27128.vci.att.com [127.0.0.1]) by zlp27128.vci.att.com (Service) with ESMTP id 8202D4000434; Mon, 4 Feb 2019 18:23:08 +0000 (GMT) Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (unknown [130.9.129.148]) by zlp27128.vci.att.com (Service) with ESMTPS id 6BA104000429; Mon, 4 Feb 2019 18:23:08 +0000 (GMT) Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.226]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0415.000; Mon, 4 Feb 2019 13:23:08 -0500 From: "BRUNGARD, DEBORAH A" To: Dino Farinacci , Alvaro Retana CC: "lisp-chairs@ietf.org" , The IESG , "draft-ietf-lisp-rfc6833bis@ietf.org" , "lisp@ietf.org" Thread-Topic: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6833bis-23: (with COMMENT) Thread-Index: AQHUvKymWo/VcH++rUytW1krPq5YhqXQRNmA//+tg3A= Date: Mon, 4 Feb 2019 18:23:07 +0000 Message-ID: References: <154930025720.28654.6669816175211800214.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.244] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C89D1002FDMISOUT7MSGUSRDE_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-04_12:, , 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-1810050000 definitions=main-1902040140 Archived-At: Subject: Re: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6833bis-23: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 18:23:21 -0000 --_000_F64C10EAA68C8044B33656FA214632C89D1002FDMISOUT7MSGUSRDE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGlubywNCg0KVGhhbmtzIOKAkyBCZW5qYW1pbiBvdmVyIHRoZSB3ZWVrZW5kIGNhdWdodCBh IGNvdXBsZSBvZiByZWZlcmVuY2VzIHdoaWNoIG5lZWQgdG8gYmUgdXBkYXRlZCB2aWEgbml0cy4g SSB3YXMganVzdCBwcmVwYXJpbmcgYW4gZW1haWwgdG8geW91IHdpdGggdGhlIGZpeGVzLiBJZiB5 b3UgY2FuLCBpbmNsdWRlIHRoZXNlIHR3ZWFrcyBhbHNvOg0KDQpUaGUgSUFCIHJlcG9ydCAoUkZD NDk4NCkgY2FuIGJlIGluZm9ybWF0aXZlLCBubyBuZWVkIHRvIGJlIG5vcm1hdGl2ZS4NCg0KUkZD NjA3MSBvbiBJUFNlYyByb2FkbWFwLCBuaXRzIChhbmQgbWUpIGNhbuKAmXQgZmluZCBpdCBpbiB0 aGUgZG9jdW1lbnQ/IEl0IGNhbiByZW1vdmVkLiBJZiBmb3Igc29tZSByZWFzb24gd2FudCB0byBr ZWVwLCBpdCBjYW4gYmUgaW5mb3JtYXRpdmUuDQoNCk5pdHMgaGFzIDUyMjYgKElBTkEpIGFzIG9i c29sZXRlZCwgaXQgc2hvdWxkIGJlIHVwZGF0ZWQgdG8gUkZDODEyNiAod2hpY2ggeW91IGhhdmUg bGlzdGVkIGluIHRoZSBpbmZvcm1hdGl2ZSkuIERlbGV0ZSA1MjI2LCBhbmQgbW92ZSA4MTI2IHRv IHRoZSBub3JtYXRpdmUgdG8gcmVwbGFjZSA1MjI2Lg0KDQpZb3UgaGF2ZSBSRkMyMTE5IGluIGlu Zm9ybWF0aXZlLiBVc3VhbGx5IHRoaXMgaXMgYWxzbyBub3JtYXRpdmUuIEFsc28sIFJGQzgxNzQg bmVlZHMgdG8gYmUgbm93IG1lbnRpb25lZCB3aXRoIFJGQzIxMTksIGFkZCB0aGF0IGluIHRoZSBk b2N1bWVudCBhbmQgYWxzbyBsaXN0IGluIHRoZSBub3JtYXRpdmUuDQoNClRoYW5rcyENCkRlYm9y YWgNCg0KRnJvbTogbGlzcCA8bGlzcC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgRGlu byBGYXJpbmFjY2kNClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMDQsIDIwMTkgMToxMiBQTQ0KVG86 IEFsdmFybyBSZXRhbmEgPGFyZXRhbmEuaWV0ZkBnbWFpbC5jb20+DQpDYzogbGlzcC1jaGFpcnNA aWV0Zi5vcmc7IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1saXNwLXJmYzY4 MzNiaXNAaWV0Zi5vcmc7IGxpc3BAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbGlzcF0gQWx2YXJv IFJldGFuYSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLWxpc3AtcmZjNjgzM2Jpcy0yMzog KHdpdGggQ09NTUVOVCkNCg0KSGVyZSBpcyBhIGRpZmYgZm9yIC0yNCB0aGF0IGluY29ycG9yYXRl cyB0aGUgY2hhbmdlcyBiZWxvdyBhbmQgQWxiZXJ04oCZcyBjaGFuZ2VzIGZyb20gQmVu4oCZcyBj b21tZW50cy4gSSB3aWxsIHN1Ym1pdCB0b2RheS4NCg0KRGlubw0KDQoNCj4gT24gRmViIDQsIDIw MTksIGF0IDk6MTAgQU0sIEFsdmFybyBSZXRhbmEgPGFyZXRhbmEuaWV0ZkBnbWFpbC5jb208bWFp bHRvOmFyZXRhbmEuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCj4NCj4gQWx2YXJvIFJldGFuYSBo YXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gZHJhZnQtaWV0 Zi1saXNwLXJmYzY4MzNiaXMtMjM6IE5vIE9iamVjdGlvbg0KPg0KPiBXaGVuIHJlc3BvbmRpbmcs IHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCj4g ZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZy ZWUgdG8gY3V0IHRoaXMNCj4gaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+DQo+ DQo+IFBsZWFzZSByZWZlciB0byBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19pZXNnX3N0YXRlbWVudF9kaXNjdXNzLTJEY3Jp dGVyaWEuaHRtbCZkPUR3SUZhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj02VWhHcFc5bHdp OWRNN2pZbHhYRDh3Jm09dF80bWRuR04xUVl2aFdvQmxWcEJVMzNvY2VMRjRmVE1qbzYwSmVzSFhC ayZzPXRGOC1FbkwtN1pkUWc5Tlp1SDBXOU4zWm5DVGNyN3pNY040WWtQWnVTZlkmZT0NCj4gZm9y IG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9u cy4NCj4NCj4NCj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlv bnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2RvY19kcmFmdC0yRGll dGYtMkRsaXNwLTJEcmZjNjgzM2Jpc18mZD1Ed0lGYVEmYz1MRllaLW85X0hVTWVNVFNRaWN2akln JnI9NlVoR3BXOWx3aTlkTTdqWWx4WEQ4dyZtPXRfNG1kbkdOMVFZdmhXb0JsVnBCVTMzb2NlTEY0 ZlRNam82MEplc0hYQmsmcz1tUFpIb1l6WUVwMnM4Tm5xaS1fSUV4WUlfM0ZrSm8wUXVjQTJ3NjdD QW9rJmU9DQo+DQo+DQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPg0KPiAoMSkgcy9yZmM4MTEzL2RyYWZ0LWlldGYtbGlzcC1yZmM4MTEzYmlzDQo+DQo+ ICgyKSDCpzUuMTogIlZhbHVlcyBpbiB0aGUgIk5vdCBBc3NpZ25lZCIgcmFuZ2UgY2FuIGJlIGFz c2lnbmVkIGFjY29yZGluZyB0bw0KPiBwcm9jZWR1cmVzIGluIFtSRkM4MTI2XS4iICBUaGlzIHNl bnRlbmNlIGlzIG91dCBvZiBwbGFjZSBiZWNhdXNlIGl0IGRvZXNuJ3QNCj4gc3BlY2lmeSB3aGlj aCBwcm9jZWR1cmUuLi5hbmQgdGhlIGFjdGlvbiBpcyBhbHJlYWR5IHNwZWNpZmllZCBpbiByZmM4 MTEzYmlzDQo+IGFueXdheS4NCj4NCj4gKDMpIHMvTm90IGFzc2lnbmVkL1VuYXNzaWduZWQgICAg IFRvIG1hdGNoIHdoYXQgdGhlIHJlZ2lzdHJ5IHNheXMuDQo+DQo+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbGlzcCBtYWlsaW5nIGxpc3QNCmxpc3BA aWV0Zi5vcmc8bWFpbHRvOmxpc3BAaWV0Zi5vcmc+DQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zw b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZv X2xpc3AmZD1Ed0lDQWcmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9NlVoR3BXOWx3aTlkTTdq WWx4WEQ4dyZtPXRfNG1kbkdOMVFZdmhXb0JsVnBCVTMzb2NlTEY0ZlRNam82MEplc0hYQmsmcz13 UGo0NlhIVGdsd1htZkhTR3ZzRkpzUlB0T3N5MEdaanp5YXlnWEw4Qm1nJmU9DQo= --_000_F64C10EAA68C8044B33656FA214632C89D1002FDMISOUT7MSGUSRDE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIERpbm8sPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoYW5rcyDigJMgQmVuamFtaW4gb3ZlciB0aGUgd2Vla2VuZCBjYXVn aHQgYSBjb3VwbGUgb2YgcmVmZXJlbmNlcyB3aGljaCBuZWVkIHRvIGJlIHVwZGF0ZWQgdmlhIG5p dHMuIEkgd2FzIGp1c3QgcHJlcGFyaW5nIGFuIGVtYWlsIHRvIHlvdSB3aXRoIHRoZSBmaXhlcy4g SWYgeW91IGNhbiwgaW5jbHVkZSB0aGVzZSB0d2Vha3MgYWxzbzo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhlIElBQiByZXBvcnQgKFJGQzQ5ODQpIGNhbiBiZSBpbmZvcm1hdGl2ZSwgbm8gbmVl ZCB0byBiZSBub3JtYXRpdmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJGQzYwNzEgb24gSVBT ZWMgcm9hZG1hcCwgbml0cyAoYW5kIG1lKSBjYW7igJl0IGZpbmQgaXQgaW4gdGhlIGRvY3VtZW50 PyBJdCBjYW4gcmVtb3ZlZC4gSWYgZm9yIHNvbWUgcmVhc29uIHdhbnQgdG8ga2VlcCwgaXQgY2Fu IGJlIGluZm9ybWF0aXZlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OaXRzIGhhcyA1MjI2IChJ QU5BKSBhcyBvYnNvbGV0ZWQsIGl0IHNob3VsZCBiZSB1cGRhdGVkIHRvIFJGQzgxMjYgKHdoaWNo IHlvdSBoYXZlIGxpc3RlZCBpbiB0aGUgaW5mb3JtYXRpdmUpLiBEZWxldGUgNTIyNiwgYW5kIG1v dmUgODEyNiB0byB0aGUgbm9ybWF0aXZlIHRvIHJlcGxhY2UgNTIyNi48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+WW91IGhhdmUgUkZDMjExOSBpbiBpbmZvcm1hdGl2ZS4gVXN1YWxseSB0aGlzIGlz IGFsc28gbm9ybWF0aXZlLiBBbHNvLCBSRkM4MTc0IG5lZWRzIHRvIGJlIG5vdyBtZW50aW9uZWQg d2l0aCBSRkMyMTE5LCBhZGQgdGhhdCBpbiB0aGUgZG9jdW1lbnQgYW5kIGFsc28gbGlzdCBpbiB0 aGUgbm9ybWF0aXZlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MhPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWJvcmFoPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gbGlzcCAmbHQ7 bGlzcC1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KRGlubyBGYXJp bmFjY2k8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBGZWJydWFyeSAwNCwgMjAxOSAxOjEyIFBN PGJyPg0KPGI+VG86PC9iPiBBbHZhcm8gUmV0YW5hICZsdDthcmV0YW5hLmlldGZAZ21haWwuY29t Jmd0Ozxicj4NCjxiPkNjOjwvYj4gbGlzcC1jaGFpcnNAaWV0Zi5vcmc7IFRoZSBJRVNHICZsdDtp ZXNnQGlldGYub3JnJmd0OzsgZHJhZnQtaWV0Zi1saXNwLXJmYzY4MzNiaXNAaWV0Zi5vcmc7IGxp c3BAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtsaXNwXSBBbHZhcm8gUmV0YW5h J3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtbGlzcC1yZmM2ODMzYmlzLTIzOiAod2l0aCBD T01NRU5UKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij5IZXJlIGlzIGEgZGlmZiBmb3IgLTI0IHRoYXQgaW5jb3Jwb3JhdGVzIHRoZSBjaGFu Z2VzIGJlbG93IGFuZCBBbGJlcnTigJlzIGNoYW5nZXMgZnJvbSBCZW7igJlzIGNvbW1lbnRzLiBJ IHdpbGwgc3VibWl0IHRvZGF5Ljxicj4NCjxicj4NCkRpbm88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48 YnI+DQo8YnI+DQomZ3Q7IE9uIEZlYiA0LCAyMDE5LCBhdCA5OjEwIEFNLCBBbHZhcm8gUmV0YW5h ICZsdDs8YSBocmVmPSJtYWlsdG86YXJldGFuYS5pZXRmQGdtYWlsLmNvbSI+YXJldGFuYS5pZXRm QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyBBbHZhcm8gUmV0 YW5hIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcjxicj4NCiZn dDsgZHJhZnQtaWV0Zi1saXNwLXJmYzY4MzNiaXMtMjM6IE5vIE9iamVjdGlvbjxicj4NCiZndDsg PGJyPg0KJmd0OyBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUg aW50YWN0IGFuZCByZXBseSB0byBhbGw8YnI+DQomZ3Q7IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRl ZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzPGJyPg0KJmd0 OyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLik8YnI+DQomZ3Q7IDxicj4NCiZndDsg PGJyPg0KJmd0OyBQbGVhc2UgcmVmZXIgdG8gPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfaWVzZ19zdGF0ZW1l bnRfZGlzY3Vzcy0yRGNyaXRlcmlhLmh0bWwmYW1wO2Q9RHdJRmFRJmFtcDtjPUxGWVotbzlfSFVN ZU1UU1FpY3ZqSWcmYW1wO3I9NlVoR3BXOWx3aTlkTTdqWWx4WEQ4dyZhbXA7bT10XzRtZG5HTjFR WXZoV29CbFZwQlUzM29jZUxGNGZUTWpvNjBKZXNIWEJrJmFtcDtzPXRGOC1FbkwtN1pkUWc5Tlp1 SDBXOU4zWm5DVGNyN3pNY040WWtQWnVTZlkmYW1wO2U9Ij4NCmh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX2llc2dfc3RhdGVt ZW50X2Rpc2N1c3MtMkRjcml0ZXJpYS5odG1sJmFtcDtkPUR3SUZhUSZhbXA7Yz1MRllaLW85X0hV TWVNVFNRaWN2aklnJmFtcDtyPTZVaEdwVzlsd2k5ZE03allseFhEOHcmYW1wO209dF80bWRuR04x UVl2aFdvQmxWcEJVMzNvY2VMRjRmVE1qbzYwSmVzSFhCayZhbXA7cz10RjgtRW5MLTdaZFFnOU5a dUgwVzlOM1puQ1Rjcjd6TWNONFlrUFp1U2ZZJmFtcDtlPTwvYT48YnI+DQomZ3Q7IGZvciBtb3Jl IGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90 aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOjxicj4NCiZndDsgPGEgaHJl Zj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19k YXRhdHJhY2tlci5pZXRmLm9yZ19kb2NfZHJhZnQtMkRpZXRmLTJEbGlzcC0yRHJmYzY4MzNiaXNf JmFtcDtkPUR3SUZhUSZhbXA7Yz1MRllaLW85X0hVTWVNVFNRaWN2aklnJmFtcDtyPTZVaEdwVzls d2k5ZE03allseFhEOHcmYW1wO209dF80bWRuR04xUVl2aFdvQmxWcEJVMzNvY2VMRjRmVE1qbzYw SmVzSFhCayZhbXA7cz1tUFpIb1l6WUVwMnM4Tm5xaS1fSUV4WUlfM0ZrSm8wUXVjQTJ3NjdDQW9r JmFtcDtlPSI+DQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cHMtM0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2RvY19kcmFmdC0yRGlldGYtMkRsaXNwLTJEcmZj NjgzM2Jpc18mYW1wO2Q9RHdJRmFRJmFtcDtjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmYW1wO3I9 NlVoR3BXOWx3aTlkTTdqWWx4WEQ4dyZhbXA7bT10XzRtZG5HTjFRWXZoV29CbFZwQlUzM29jZUxG NGZUTWpvNjBKZXNIWEJrJmFtcDtzPW1QWkhvWXpZRXAyczhObnFpLV9JRXhZSV8zRmtKbzBRdWNB Mnc2N0NBb2smYW1wO2U9PC9hPjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4N CiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgQ09NTUVOVDo8YnI+DQomZ3Q7IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS08YnI+DQomZ3Q7IDxicj4NCiZndDsgKDEpIHMvcmZjODExMy9kcmFmdC1pZXRmLWxpc3At cmZjODExM2Jpczxicj4NCiZndDsgPGJyPg0KJmd0OyAoMikgwqc1LjE6ICZxdW90O1ZhbHVlcyBp biB0aGUgJnF1b3Q7Tm90IEFzc2lnbmVkJnF1b3Q7IHJhbmdlIGNhbiBiZSBhc3NpZ25lZCBhY2Nv cmRpbmcgdG88YnI+DQomZ3Q7IHByb2NlZHVyZXMgaW4gW1JGQzgxMjZdLiZxdW90OyZuYnNwOyBU aGlzIHNlbnRlbmNlIGlzIG91dCBvZiBwbGFjZSBiZWNhdXNlIGl0IGRvZXNuJ3Q8YnI+DQomZ3Q7 IHNwZWNpZnkgd2hpY2ggcHJvY2VkdXJlLi4uYW5kIHRoZSBhY3Rpb24gaXMgYWxyZWFkeSBzcGVj aWZpZWQgaW4gcmZjODExM2Jpczxicj4NCiZndDsgYW55d2F5Ljxicj4NCiZndDsgPGJyPg0KJmd0 OyAoMykgcy9Ob3QgYXNzaWduZWQvVW5hc3NpZ25lZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBU byBtYXRjaCB3aGF0IHRoZSByZWdpc3RyeSBzYXlzLjxicj4NCiZndDsgPGJyPg0KJmd0OyA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpsaXNwIG1haWxpbmcgbGlz dDxicj4NCjxhIGhyZWY9Im1haWx0bzpsaXNwQGlldGYub3JnIj5saXNwQGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbGlzcCZhbXA7ZD1Ed0lDQWcm YW1wO2M9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZhbXA7cj02VWhHcFc5bHdpOWRNN2pZbHhYRDh3 JmFtcDttPXRfNG1kbkdOMVFZdmhXb0JsVnBCVTMzb2NlTEY0ZlRNam82MEplc0hYQmsmYW1wO3M9 d1BqNDZYSFRnbHdYbWZIU0d2c0ZKc1JQdE9zeTBHWmp6eWF5Z1hMOEJtZyZhbXA7ZT0iPmh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYu b3JnX21haWxtYW5fbGlzdGluZm9fbGlzcCZhbXA7ZD1Ed0lDQWcmYW1wO2M9TEZZWi1vOV9IVU1l TVRTUWljdmpJZyZhbXA7cj02VWhHcFc5bHdpOWRNN2pZbHhYRDh3JmFtcDttPXRfNG1kbkdOMVFZ dmhXb0JsVnBCVTMzb2NlTEY0ZlRNam82MEplc0hYQmsmYW1wO3M9d1BqNDZYSFRnbHdYbWZIU0d2 c0ZKc1JQdE9zeTBHWmp6eWF5Z1hMOEJtZyZhbXA7ZT08L2E+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F64C10EAA68C8044B33656FA214632C89D1002FDMISOUT7MSGUSRDE_-- From nobody Mon Feb 4 10:25:30 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9955130EE2; Mon, 4 Feb 2019 10:25:18 -0800 (PST) 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 0Gkxq-eJHjsg; Mon, 4 Feb 2019 10:25:16 -0800 (PST) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 9D662127AC2; Mon, 4 Feb 2019 10:25:16 -0800 (PST) Received: by mail-pg1-x52a.google.com with SMTP id d72so274157pga.9; Mon, 04 Feb 2019 10:25:16 -0800 (PST) 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=FqcbJf8TFCIUxIXMBImL/9CUQF1sapG5Z2x1DwqqjOw=; b=hKZbm1vt6nz2MIyi+XcYibPm9K8PNZ52tyaqvCPyvEW/ZX/Av8SGFxwcpwX39U9YLj ds5c0UM3Kd94jFs3yx91e/yOhx60ZRiJWeT/7GZ+VJutuff2tF1J19lCg1FY9ZVZ9d7S bv19EkP+ru3Cgbo1eLCEtDJlMEhICpT1R3ulmpKFynMhRXw7ikZRHdBL8Mu5b2pd5Xja 50A0fZG080GjQmB9dJ6xECmzUHa6uAJ4tAW3GcDxRTseK1cua2CVD0SDpxUGzKWBqC3D QjIvsblmiNS8RJ9zMV74HxmVH153w5Scaay3EpY9d+63y5tUfWvd8GfEac8pnX4nXIOn XfTA== 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=FqcbJf8TFCIUxIXMBImL/9CUQF1sapG5Z2x1DwqqjOw=; b=AnW43iQ46C70wb7pjufdhjfF7031q+WRRi9nyu/lMIW7sObxp8KIOK6dCE7C3AHGbK 2/a60oQeNWULDIAze4ZDjORYX7lMGDwY8fehNDtH5iZZeA1+xkD1yjbMxCEH1TzChmbM xUZJ/aOMX7e7KC97j353G0qj6MVSwfxuL2pLhl3uZxIlgvsY5BVT2jEV8nhmg+CMtcy2 4o6WAvQMdL6BAt+793pG6dL30R2Xixo3xCJK4vF/ZTkR7sJxejkqrS+z6AJAFJPd0U3l 1KOYNOHQ8BfIFICDoqH3mVzlIdgt7HjhfwVgl5egr0GYtFVlyz0+URV42KtyAN9zB4+V ArTA== X-Gm-Message-State: AHQUAuaWyOn32KywaMIeCqLzR/oEYQuVBzPi59+Nh5xjKsjLmNtLds5w ZYhlCdx9ys9nHGVCDW8bzUM= X-Google-Smtp-Source: AHgI3IZ14JVLmLCTfQJ86wLRodASFXPdJMfPrsBhR3yob4mgxsBCyn1gvOgZwkGOD8q60/oyhgXPQA== X-Received: by 2002:a65:6684:: with SMTP id b4mr642818pgw.55.1549304716102; Mon, 04 Feb 2019 10:25:16 -0800 (PST) Received: from [10.31.79.74] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id m9sm914023pgr.7.2019.02.04.10.25.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Feb 2019 10:25:15 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Mon, 4 Feb 2019 10:25:14 -0800 Cc: Alvaro Retana , "lisp-chairs@ietf.org" , The IESG , "draft-ietf-lisp-rfc6833bis@ietf.org" , "lisp@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3A77EC02-B7AF-4677-8203-50AEA1CC24A2@gmail.com> References: <154930025720.28654.6669816175211800214.idtracker@ietfa.amsl.com> To: "BRUNGARD, DEBORAH A" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6833bis-23: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 18:25:19 -0000 > Hi Dino, > =20 > Thanks =E2=80=93 Benjamin over the weekend caught a couple of = references which need to be updated via nits. I was just preparing an = email to you with the fixes. If you can, include these tweaks also: I didn=E2=80=99t see any comments. Do you mean run IDnits or all the = comments below? Dino > =20 > The IAB report (RFC4984) can be informative, no need to be normative. > =20 > RFC6071 on IPSec roadmap, nits (and me) can=E2=80=99t find it in the = document? It can removed. If for some reason want to keep, it can be = informative. > =20 > Nits has 5226 (IANA) as obsoleted, it should be updated to RFC8126 = (which you have listed in the informative). Delete 5226, and move 8126 = to the normative to replace 5226. > =20 > You have RFC2119 in informative. Usually this is also normative. Also, = RFC8174 needs to be now mentioned with RFC2119, add that in the document = and also list in the normative. > =20 > Thanks! > Deborah > =20 > From: lisp On Behalf Of Dino Farinacci > Sent: Monday, February 04, 2019 1:12 PM > To: Alvaro Retana > Cc: lisp-chairs@ietf.org; The IESG ; = draft-ietf-lisp-rfc6833bis@ietf.org; lisp@ietf.org > Subject: Re: [lisp] Alvaro Retana's No Objection on = draft-ietf-lisp-rfc6833bis-23: (with COMMENT) > =20 > Here is a diff for -24 that incorporates the changes below and = Albert=E2=80=99s changes from Ben=E2=80=99s comments. I will submit = today. >=20 > Dino >=20 >=20 >=20 > > On Feb 4, 2019, at 9:10 AM, Alvaro Retana = wrote: > >=20 > > Alvaro Retana has entered the following ballot position for > > draft-ietf-lisp-rfc6833bis-23: No Objection > >=20 > > When responding, please keep the subject line intact and reply to = all > > email addresses included in the To and CC lines. (Feel free to cut = this > > introductory paragraph, however.) > >=20 > >=20 > > Please refer to = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_iesg_s= tatement_discuss-2Dcriteria.html&d=3DDwIFaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3D= 6UhGpW9lwi9dM7jYlxXD8w&m=3Dt_4mdnGN1QYvhWoBlVpBU33oceLF4fTMjo60JesHXBk&s=3D= tF8-EnL-7ZdQg9NZuH0W9N3ZnCTcr7zMcN4YkPZuSfY&e=3D > > for more information about IESG DISCUSS and COMMENT positions. > >=20 > >=20 > > The document, along with other ballot positions, can be found here: > > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.or= g_doc_draft-2Dietf-2Dlisp-2Drfc6833bis_&d=3DDwIFaQ&c=3DLFYZ-o9_HUMeMTSQicv= jIg&r=3D6UhGpW9lwi9dM7jYlxXD8w&m=3Dt_4mdnGN1QYvhWoBlVpBU33oceLF4fTMjo60Jes= HXBk&s=3DmPZHoYzYEp2s8Nnqi-_IExYI_3FkJo0QucA2w67CAok&e=3D > >=20 > >=20 > >=20 > > = ---------------------------------------------------------------------- > > COMMENT: > > = ---------------------------------------------------------------------- > >=20 > > (1) s/rfc8113/draft-ietf-lisp-rfc8113bis > >=20 > > (2) =C2=A75.1: "Values in the "Not Assigned" range can be assigned = according to > > procedures in [RFC8126]." This sentence is out of place because it = doesn't > > specify which procedure...and the action is already specified in = rfc8113bis > > anyway. > >=20 > > (3) s/Not assigned/Unassigned To match what the registry says. > >=20 > >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_lisp&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3D6UhGpW9lwi9dM7jY= lxXD8w&m=3Dt_4mdnGN1QYvhWoBlVpBU33oceLF4fTMjo60JesHXBk&s=3DwPj46XHTglwXmfH= SGvsFJsRPtOsy0GZjzyaygXL8Bmg&e=3D From nobody Mon Feb 4 11:41:32 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2B5130EF3; Mon, 4 Feb 2019 11:41:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 TaIDu5ClzVro; Mon, 4 Feb 2019 11:41:22 -0800 (PST) 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 26E19130EEF; Mon, 4 Feb 2019 11:41:22 -0800 (PST) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x14IRHg5043064; Mon, 4 Feb 2019 13:27:36 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by mx0a-00191d01.pphosted.com with ESMTP id 2qesq99vrm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 04 Feb 2019 13:27:36 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x14IRZEK012923; Mon, 4 Feb 2019 13:27:35 -0500 Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [135.66.87.52]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x14IRV1Q012821; Mon, 4 Feb 2019 13:27:31 -0500 Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [127.0.0.1]) by zlp27125.vci.att.com (Service) with ESMTP id 08D8716A3EF; Mon, 4 Feb 2019 18:27:31 +0000 (GMT) Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (unknown [130.9.129.147]) by zlp27125.vci.att.com (Service) with ESMTPS id E71AE16A3EE; Mon, 4 Feb 2019 18:27:30 +0000 (GMT) Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.226]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0415.000; Mon, 4 Feb 2019 13:27:30 -0500 From: "BRUNGARD, DEBORAH A" To: Dino Farinacci CC: Alvaro Retana , "lisp-chairs@ietf.org" , The IESG , "draft-ietf-lisp-rfc6833bis@ietf.org" , "lisp@ietf.org" Thread-Topic: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6833bis-23: (with COMMENT) Thread-Index: AQHUvKymWo/VcH++rUytW1krPq5YhqXQRNmA//+tg3CAAFYNAP//rFiA Date: Mon, 4 Feb 2019 18:27:30 +0000 Message-ID: References: <154930025720.28654.6669816175211800214.idtracker@ietfa.amsl.com> <3A77EC02-B7AF-4677-8203-50AEA1CC24A2@gmail.com> In-Reply-To: <3A77EC02-B7AF-4677-8203-50AEA1CC24A2@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.244] 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=2019-02-04_12:, , 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-1810050000 definitions=main-1902040141 Archived-At: Subject: Re: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6833bis-23: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 19:41:25 -0000 SGkgRGlubywNCg0KQmVuamFtaW4gaGFkIHNlbnQgdG8gbWUgdG8gY2hlY2sgb24gdGhlbSBhcyBo ZSBzYXcgdGhlbSBpbiBuaXRzLiBJZiB5b3UgcnVuIG5pdHMsIHlvdSB3aWxsIHNlZSB0aGVtLiBQ cm9iYWJseSBhIGdvb2QgaWRlYSB0byBydW4gbml0cyAtIHRoZXJlJ3MgYSAiTVVTVCBub3QiIHdo aWNoIG5lZWRzIHRvIGZpeGVkIGFsc28uDQoNClRoYW5rcyENCkRlYm9yYWgNCg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGlubyBGYXJpbmFjY2kgPGZhcmluYWNjaUBnbWFp bC5jb20+IA0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAwNCwgMjAxOSAxOjI1IFBNDQpUbzogQlJV TkdBUkQsIERFQk9SQUggQSA8ZGIzNTQ2QGF0dC5jb20+DQpDYzogQWx2YXJvIFJldGFuYSA8YXJl dGFuYS5pZXRmQGdtYWlsLmNvbT47IGxpc3AtY2hhaXJzQGlldGYub3JnOyBUaGUgSUVTRyA8aWVz Z0BpZXRmLm9yZz47IGRyYWZ0LWlldGYtbGlzcC1yZmM2ODMzYmlzQGlldGYub3JnOyBsaXNwQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW2xpc3BdIEFsdmFybyBSZXRhbmEncyBObyBPYmplY3Rpb24g b24gZHJhZnQtaWV0Zi1saXNwLXJmYzY4MzNiaXMtMjM6ICh3aXRoIENPTU1FTlQpDQoNCg0KPiBI aSBEaW5vLA0KPiAgDQo+IFRoYW5rcyDigJMgQmVuamFtaW4gb3ZlciB0aGUgd2Vla2VuZCBjYXVn aHQgYSBjb3VwbGUgb2YgcmVmZXJlbmNlcyB3aGljaCBuZWVkIHRvIGJlIHVwZGF0ZWQgdmlhIG5p dHMuIEkgd2FzIGp1c3QgcHJlcGFyaW5nIGFuIGVtYWlsIHRvIHlvdSB3aXRoIHRoZSBmaXhlcy4g SWYgeW91IGNhbiwgaW5jbHVkZSB0aGVzZSB0d2Vha3MgYWxzbzoNCg0KSSBkaWRu4oCZdCBzZWUg YW55IGNvbW1lbnRzLiBEbyB5b3UgbWVhbiBydW4gSURuaXRzIG9yIGFsbCB0aGUgY29tbWVudHMg YmVsb3c/DQoNCkRpbm8NCg0KPiAgDQo+IFRoZSBJQUIgcmVwb3J0IChSRkM0OTg0KSBjYW4gYmUg aW5mb3JtYXRpdmUsIG5vIG5lZWQgdG8gYmUgbm9ybWF0aXZlLg0KPiAgDQo+IFJGQzYwNzEgb24g SVBTZWMgcm9hZG1hcCwgbml0cyAoYW5kIG1lKSBjYW7igJl0IGZpbmQgaXQgaW4gdGhlIGRvY3Vt ZW50PyBJdCBjYW4gcmVtb3ZlZC4gSWYgZm9yIHNvbWUgcmVhc29uIHdhbnQgdG8ga2VlcCwgaXQg Y2FuIGJlIGluZm9ybWF0aXZlLg0KPiAgDQo+IE5pdHMgaGFzIDUyMjYgKElBTkEpIGFzIG9ic29s ZXRlZCwgaXQgc2hvdWxkIGJlIHVwZGF0ZWQgdG8gUkZDODEyNiAod2hpY2ggeW91IGhhdmUgbGlz dGVkIGluIHRoZSBpbmZvcm1hdGl2ZSkuIERlbGV0ZSA1MjI2LCBhbmQgbW92ZSA4MTI2IHRvIHRo ZSBub3JtYXRpdmUgdG8gcmVwbGFjZSA1MjI2Lg0KPiAgDQo+IFlvdSBoYXZlIFJGQzIxMTkgaW4g aW5mb3JtYXRpdmUuIFVzdWFsbHkgdGhpcyBpcyBhbHNvIG5vcm1hdGl2ZS4gQWxzbywgUkZDODE3 NCBuZWVkcyB0byBiZSBub3cgbWVudGlvbmVkIHdpdGggUkZDMjExOSwgYWRkIHRoYXQgaW4gdGhl IGRvY3VtZW50IGFuZCBhbHNvIGxpc3QgaW4gdGhlIG5vcm1hdGl2ZS4NCj4gIA0KPiBUaGFua3Mh DQo+IERlYm9yYWgNCj4gIA0KPiBGcm9tOiBsaXNwIDxsaXNwLWJvdW5jZXNAaWV0Zi5vcmc+IE9u IEJlaGFsZiBPZiBEaW5vIEZhcmluYWNjaQ0KPiBTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDA0LCAy MDE5IDE6MTIgUE0NCj4gVG86IEFsdmFybyBSZXRhbmEgPGFyZXRhbmEuaWV0ZkBnbWFpbC5jb20+ DQo+IENjOiBsaXNwLWNoYWlyc0BpZXRmLm9yZzsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+OyAN Cj4gZHJhZnQtaWV0Zi1saXNwLXJmYzY4MzNiaXNAaWV0Zi5vcmc7IGxpc3BAaWV0Zi5vcmcNCj4g U3ViamVjdDogUmU6IFtsaXNwXSBBbHZhcm8gUmV0YW5hJ3MgTm8gT2JqZWN0aW9uIG9uIA0KPiBk cmFmdC1pZXRmLWxpc3AtcmZjNjgzM2Jpcy0yMzogKHdpdGggQ09NTUVOVCkNCj4gIA0KPiBIZXJl IGlzIGEgZGlmZiBmb3IgLTI0IHRoYXQgaW5jb3Jwb3JhdGVzIHRoZSBjaGFuZ2VzIGJlbG93IGFu ZCBBbGJlcnTigJlzIGNoYW5nZXMgZnJvbSBCZW7igJlzIGNvbW1lbnRzLiBJIHdpbGwgc3VibWl0 IHRvZGF5Lg0KPiANCj4gRGlubw0KPiANCj4gDQo+IA0KPiA+IE9uIEZlYiA0LCAyMDE5LCBhdCA5 OjEwIEFNLCBBbHZhcm8gUmV0YW5hIDxhcmV0YW5hLmlldGZAZ21haWwuY29tPiB3cm90ZToNCj4g PiANCj4gPiBBbHZhcm8gUmV0YW5hIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBv c2l0aW9uIGZvcg0KPiA+IGRyYWZ0LWlldGYtbGlzcC1yZmM2ODMzYmlzLTIzOiBObyBPYmplY3Rp b24NCj4gPiANCj4gPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxp bmUgaW50YWN0IGFuZCByZXBseSB0byANCj4gPiBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVk IGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gDQo+ID4gY3V0IHRoaXMgaW50 cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+ID4gDQo+ID4gDQo+ID4gUGxlYXNlIHJl ZmVyIHRvIA0KPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9fd3d3LmlldGYub3JnX2llDQo+ID4gc2dfc3RhdGVtZW50X2Rpc2N1c3MtMkRjcml0 ZXJpYS5odG1sJmQ9RHdJRmFRJmM9TEZZWi1vOV9IVU1lTVRTUWljdmoNCj4gPiBJZyZyPTZVaEdw Vzlsd2k5ZE03allseFhEOHcmbT10XzRtZG5HTjFRWXZoV29CbFZwQlUzM29jZUxGNGZUTWpvNjBK ZQ0KPiA+IHNIWEJrJnM9dEY4LUVuTC03WmRRZzlOWnVIMFc5TjNabkNUY3I3ek1jTjRZa1BadVNm WSZlPQ0KPiA+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09N TUVOVCBwb3NpdGlvbnMuDQo+ID4gDQo+ID4gDQo+ID4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRo IG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiA+IGh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRyYWNrZXIu aWV0DQo+ID4gZi5vcmdfZG9jX2RyYWZ0LTJEaWV0Zi0yRGxpc3AtMkRyZmM2ODMzYmlzXyZkPUR3 SUZhUSZjPUxGWVotbzlfSFVNZU0NCj4gPiBUU1FpY3ZqSWcmcj02VWhHcFc5bHdpOWRNN2pZbHhY RDh3Jm09dF80bWRuR04xUVl2aFdvQmxWcEJVMzNvY2VMRjRmVA0KPiA+IE1qbzYwSmVzSFhCayZz PW1QWkhvWXpZRXAyczhObnFpLV9JRXhZSV8zRmtKbzBRdWNBMnc2N0NBb2smZT0NCj4gPiANCj4g PiANCj4gPiANCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IC0tDQo+ID4gQ09NTUVOVDoNCj4gPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiA+IC0tDQo+ID4gDQo+ID4gKDEpIHMvcmZjODExMy9kcmFmdC1pZXRmLWxpc3At cmZjODExM2Jpcw0KPiA+IA0KPiA+ICgyKSDCpzUuMTogIlZhbHVlcyBpbiB0aGUgIk5vdCBBc3Np Z25lZCIgcmFuZ2UgY2FuIGJlIGFzc2lnbmVkIA0KPiA+IGFjY29yZGluZyB0byBwcm9jZWR1cmVz IGluIFtSRkM4MTI2XS4iICBUaGlzIHNlbnRlbmNlIGlzIG91dCBvZiANCj4gPiBwbGFjZSBiZWNh dXNlIGl0IGRvZXNuJ3Qgc3BlY2lmeSB3aGljaCBwcm9jZWR1cmUuLi5hbmQgdGhlIGFjdGlvbiBp cyANCj4gPiBhbHJlYWR5IHNwZWNpZmllZCBpbiByZmM4MTEzYmlzIGFueXdheS4NCj4gPiANCj4g PiAoMykgcy9Ob3QgYXNzaWduZWQvVW5hc3NpZ25lZCAgICAgVG8gbWF0Y2ggd2hhdCB0aGUgcmVn aXN0cnkgc2F5cy4NCj4gPiANCj4gPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IGxpc3AgbWFpbGluZyBsaXN0DQo+IGxpc3BAaWV0Zi5v cmcNCj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB X193d3cuaWV0Zi5vcmdfbWFpbA0KPiBtYW5fbGlzdGluZm9fbGlzcCZkPUR3SUNBZyZjPUxGWVot bzlfSFVNZU1UU1FpY3ZqSWcmcj02VWhHcFc5bHdpOWRNN2pZDQo+IGx4WEQ4dyZtPXRfNG1kbkdO MVFZdmhXb0JsVnBCVTMzb2NlTEY0ZlRNam82MEplc0hYQmsmcz13UGo0NlhIVGdsd1htZkgNCj4g U0d2c0ZKc1JQdE9zeTBHWmp6eWF5Z1hMOEJtZyZlPQ0KDQo= From nobody Mon Feb 4 11:43:50 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1127130EF3; Mon, 4 Feb 2019 11:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 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_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=no 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 RfA_M75jOai7; Mon, 4 Feb 2019 11:43:36 -0800 (PST) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 97C14130EEF; Mon, 4 Feb 2019 11:43:36 -0800 (PST) Received: by mail-pg1-x52c.google.com with SMTP id n2so381450pgm.3; Mon, 04 Feb 2019 11:43:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7nVFpiyRGJL8DLgYuKcjKb6QdXzFa1l4nvs6o025sbU=; b=jhOs/BsT/njmbMnohAsXSh8d0u+Gj7n55tJO6hWCM8+AnHj500XCli9xuUjUBE7WDd tRuFERlv+eV3RNdI28FOA+UZthw5AbVV/W0vxahsk5nfqkKh1yMT/nh7IigSGmZj41HL bkfCOFLcrK5hTZOCtA/wqTkgYrCuqm0absYyb61oNhjz7prvNvLvRuQisu+YOcgAg2TQ q+PGDXj4K45lJDt5k/vup4P/W9XzvKIGLhx+If0yWnexrokdykp8Vwi1ddgyfr8VLXLS 2z2H9GsA/pJ3ydW3KWwpL9d1x9zgKfVlfNsEvsc4I4Y4wEUCL4vc392b6gk7WkW1y/bx 3U4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=7nVFpiyRGJL8DLgYuKcjKb6QdXzFa1l4nvs6o025sbU=; b=Nj/HeXhIdUnAEv1m551YmzMDPQYoaq5bjTMqRagZG16907TxU4pyifV/6vFjlWjI5N gBDSOs0ThMke0GqCINJgTJHn1WZtN+T+EIcu13R3XO0ujMWNQdRTtmvUN6t56i+IEc/i pnU7zLvTBt+LtmOjiKT59MSwTipHlKhJmvYwfd8vp/oMONGG0T7MhSurEy4icGgb+EpC TeBcfQ/izpnwjFMw2XqJYzMoIlFdbgLShFkXX/4yH54IuuNlCzNVbUCG98GJUNH1Gfsp mqgr6coGX7ujDMGKyCxoqgh+8IYTPWnBVZFFlDIJdUsdq6OVvLV5O8GiDi15pQZz3NXQ uyQw== X-Gm-Message-State: AHQUAubqpczbYo/3pwlCinfQsvq1ViaijOf483RT6zYhklz5DbhHFq14 xbRVQrG4LKxJS8h9BQo2hrQ= X-Google-Smtp-Source: AHgI3IYemtfiDXadWhXVioEyLLzF9P7Xo93qcwsiD+OLl8K8uvMO7ni+O/KmhfxsXkgc6k9efwjWjg== X-Received: by 2002:a62:a99:: with SMTP id 25mr1000986pfk.121.1549309414957; Mon, 04 Feb 2019 11:43:34 -0800 (PST) Received: from [10.31.79.74] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id h18sm501765pfj.49.2019.02.04.11.43.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Feb 2019 11:43:34 -0800 (PST) From: Dino Farinacci Message-Id: <03F49F00-8770-4BE6-BEC0-56012D1B19BE@gmail.com> Content-Type: multipart/mixed; boundary="Apple-Mail=_F408CD70-817F-4F42-B3D7-BE22BDD7C94E" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 4 Feb 2019 11:43:32 -0800 In-Reply-To: Cc: Alvaro Retana , "lisp-chairs@ietf.org" , The IESG , "draft-ietf-lisp-rfc6833bis@ietf.org" , "lisp@ietf.org" To: "BRUNGARD, DEBORAH A" References: <154930025720.28654.6669816175211800214.idtracker@ietfa.amsl.com> <3A77EC02-B7AF-4677-8203-50AEA1CC24A2@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6833bis-23: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 19:43:43 -0000 --Apple-Mail=_F408CD70-817F-4F42-B3D7-BE22BDD7C94E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I ran nits and fixed the items below. Here is the new diff. Let me know = if that=E2=80=99s it? I=E2=80=99ll wait for an ack before submitting. Dino --Apple-Mail=_F408CD70-817F-4F42-B3D7-BE22BDD7C94E Content-Disposition: attachment; filename=rfcdiff-6833bis-24.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-6833bis-24.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-lisp-rfc6833bis-23.txt - = draft-ietf-lisp-rfc6833bis-24.txt=20 =20 =20 =20 =20 =20 =20 = = = = = = = = = =
< draft-ietf-lisp-rfc6833bis-23.txt  =  draft-ietf-lisp-rfc6833bis-24.txt >
=
Network Working = Group V. Fuller = Network Working Group = V. Fuller
Internet-Draft = D. Farinacci Internet-Draft = D. Farinacci
Obsoletes: = 6833 (if approved) = Cisco Systems Obsoletes: = 6830, 6833 (if approved) = Cisco Systems
Intended status: = Standards Track A. Cabellos (Ed.) = Intended status: Standards Track = A. Cabellos (Ed.)
Expires: June 13, 2019 = UPC/BarcelonaTech Expires: August 8, 2019 = UPC/BarcelonaTech
= December = 10, 2018 = February 4, = 2019
=
= Locator/ID Separation Protocol (LISP) Control-Plane Locator/ID Separation Protocol (LISP) = Control-Plane
= draft-ietf-lisp-rfc6833bis-23 = = draft-ietf-lisp-rfc6833bis-24
=
Abstract = Abstract
=
This document = describes the Control-Plane and Mapping Service for the = This document describes the Control-Plane = and Mapping Service for the
Locator/ID = Separation Protocol (LISP), implemented by two new types = Locator/ID Separation Protocol (LISP), = implemented by two new types
of = LISP-speaking devices -- the LISP Map-Resolver and LISP = Map-Server of LISP-speaking devices = -- the LISP Map-Resolver and LISP Map-Server
-- that = provides a simplified "front end" for one or more Endpoint ID = -- that provides a simplified "front end" = for one or more Endpoint ID
to Routing = Locator mapping databases. to = Routing Locator mapping databases.
=
By using this = Control-Plane service interface and communicating with By using this Control-Plane service interface and = communicating with
Map-Resolvers = and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and = Map-Resolvers and Map-Servers, LISP Ingress = Tunnel Routers (ITRs) and
Egress Tunnel = Routers (ETRs) are not dependent on the details of Egress Tunnel Routers (ETRs) are not dependent on the = details of
mapping = database systems, which facilitates modularity with different = mapping database systems, which facilitates = modularity with different
database = designs. Since these devices implement the "edge" of the = database designs. Since these devices = implement the "edge" of the
LISP = Control-Plane infrastructure, connecting EID addressable nodes = LISP Control-Plane infrastructure, = connecting EID addressable nodes
of a LISP = site, their implementation and operational complexity of a LISP site, their implementation and operational = complexity
reduces the = overall cost and effort of deploying LISP. reduces the overall cost and effort of deploying = LISP.
=
This = document obsoletes RFC 6830 and 6833. = This document obsoletes RFC 6830 and RFC = 6833.
=
Status of This = Memo Status of This Memo
=
This = Internet-Draft is submitted in full conformance with the = This Internet-Draft is submitted in full = conformance with the
provisions of = BCP 78 and BCP 79. provisions of = BCP 78 and BCP 79.
=
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
Task Force = (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also = distribute
working = documents as Internet-Drafts. The list of current Internet- = working documents as Internet-Drafts. The = list of current Internet-
Drafts is at = https://datatracker.ietf.org/drafts/current/. Drafts is at = https://datatracker.ietf.org/drafts/current/.
=
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
and may be = updated, replaced, or obsoleted by other documents at any = and may be updated, replaced, or obsoleted = by other documents at any
time. It is = inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as = reference
material or to = cite them other than as "work in progress." material or to cite them other than as "work in = progress."
=
This = Internet-Draft will expire on June 13, = 2019. This Internet-Draft will = expire on August 8, 2019.
=
Copyright = Notice Copyright Notice
=
Copyright = (c) 2018 IETF Trust and the persons = identified as the Copyright (c) = 2019 IETF Trust and the persons identified = as the
document = authors. All rights reserved. = document authors. All rights reserved.
=
This document = is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF = Trust's Legal
Provisions = Relating to IETF Documents = Provisions Relating to IETF Documents
= (https://trustee.ietf.org/license-info) in effect on the date = of = (https://trustee.ietf.org/license-info) in effect on the date of
publication of = this document. Please review these documents publication of this document. Please review these = documents
carefully, as = they describe your rights and restrictions with respect = carefully, as they describe your rights and = restrictions with respect
to this = document. Code Components extracted from this document must = to this document. Code Components extracted = from this document must
include = Simplified BSD License text as described in Section 4.e of = include Simplified BSD License text as = described in Section 4.e of
the Trust = Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without = warranty as
described in = the Simplified BSD License. = described in the Simplified BSD License.
=
Table of = Contents Table of Contents
=
1. = Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 3 1. Introduction . . . . . . . . = . . . . . . . . . . . . . . . . 3
1.1. Scope = of Applicability . . . . . . . . . . . . . . . . . 4 = 1.1. Scope of Applicability . . . . . . = . . . . . . . . . . . 4
2. = Requirements Notation . . . . . . . . . . . . . . . . . . . . = 5 2. Requirements Notation . . . . = . . . . . . . . . . . . . . . . 5
3. Definition = of Terms . . . . . . . . . . . . . . . . . . . . . 5 3. Definition of Terms . . . . . . . . . . . . . . . = . . . . . . 5
4. Basic = Overview . . . . . . . . . . . . . . . . . . . . . . . 6 4. = Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 7
5. LISP IPv4 = and IPv6 Control-Plane Packet Formats . . . . . . . 8 = 5. LISP IPv4 and IPv6 Control-Plane Packet = Formats . . . . . . . 8
5.1. LISP = Control Packet Type Allocations . . . . . . . . . . 11 = 5.1. LISP Control Packet Type Allocations = . . . . . . . . . . 11
5.2. = Map-Request Message Format . . . . . . . . . . . . . . . 12 = 5.2. Map-Request Message Format . . . . = . . . . . . . . . . . 12
5.3. = EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 15 = 5.3. EID-to-RLOC UDP Map-Request Message = . . . . . . . . . . . 15
5.4. = Map-Reply Message Format . . . . . . . . . . . . . . . . 17 = 5.4. Map-Reply Message Format . . . . . = . . . . . . . . . . . 17
5.5. = EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 21 = 5.5. EID-to-RLOC UDP Map-Reply Message . = . . . . . . . . . . . 21
5.6. = Map-Register Message Format . . . . . . . . . . . . . . . 24 = 5.6. Map-Register Message Format . . . . = . . . . . . . . . . . 24
5.7. = Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 28 = 5.7. Map-Notify/Map-Notify-Ack Message = Format . . . . . . . . 28
5.8. = Encapsulated Control Message Format . . . . . . . . . . . 30 = 5.8. Encapsulated Control Message Format = . . . . . . . . . . . 30
6. Changing = the Contents of EID-to-RLOC Mappings . . . . . . . . 32 = 6. Changing the Contents of EID-to-RLOC = Mappings . . . . . . . . 32
=
skipping to = change at = page 3, line 5 =C2=B6 = skipping to change at page 3, line 5 =C2=B6
8.4. = Map-Resolver Processing . . . . . . . . . . . . . . . . . 40 = 8.4. Map-Resolver Processing . . . . . . = . . . . . . . . . . . 40
8.4.1. = Anycast Operation . . . . . . . . . . . . . . . . . . 40 = 8.4.1. Anycast Operation . . . . . . . = . . . . . . . . . . . 40
9. Security = Considerations . . . . . . . . . . . . . . . . . . . 41 = 9. Security Considerations . . . . . . . . = . . . . . . . . . . . 41
10. Privacy = Considerations . . . . . . . . . . . . . . . . . . . 42 = 10. Privacy Considerations . . . . . . . . = . . . . . . . . . . . 42
11. Changes = since RFC 6833 . . . . . . . . . . . . . . . . . . . 43 = 11. Changes since RFC 6833 . . . . . . . . = . . . . . . . . . . . 43
12. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 44 = 12. IANA Considerations . . . . . . . . . . = . . . . . . . . . . . 44
12.1. LISP = UDP Port Numbers . . . . . . . . . . . . . . . . . 44 = 12.1. LISP UDP Port Numbers . . . . . . = . . . . . . . . . . . 44
12.2. LISP = Packet Type Codes . . . . . . . . . . . . . . . . . 44 = 12.2. LISP Packet Type Codes . . . . . . = . . . . . . . . . . . 44
12.3. LISP = ACT and Flag Fields . . . . . . . . . . . . . . . . 44 = 12.3. LISP ACT and Flag Fields . . . . . = . . . . . . . . . . . 44
12.4. LISP = Address Type Codes . . . . . . . . . . . . . . . . 45 = 12.4. LISP Address Type Codes . . . . . = . . . . . . . . . . . 45
12.5. = LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 45 12.5. = LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 46
12.6. LISP = Bit Flags . . . . . . . . . . . . . . . . . . . . . 46 = 12.6. LISP Bit Flags . . . . . . . . . . = . . . . . . . . . . . 46
13. References = . . . . . . . . . . . . . . . . . . . . . . . . . 49 13. References . . . . . . . . . . . . . . . . . . . = . . . . . . 49
13.1. = Normative References . . . . . . . . . . . . . . . . . . 49 = 13.1. Normative References . . . . . . . = . . . . . . . . . . . 49
13.2. = Informative References . . . . . . . . . . . . . . . . . 50 = 13.2. Informative References . . . . . . = . . . . . . . . . . . 50
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 55 = Appendix A. Acknowledgments . . . . . . . = . . . . . . . . . . . 55
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 55 = Appendix B. Document Change Log . . . . . = . . . . . . . . . . . 55
B.1. = Changes to draft-ietf-lisp-rfc6833bis-23 = . . . . . . . . 55 B.1. = Changes to draft-ietf-lisp-rfc6833bis-24 = . . . . . . . . 55
B.2. = Changes to draft-ietf-lisp-rfc6833bis-22 = . . . . . . . . 55 B.2. = Changes to draft-ietf-lisp-rfc6833bis-23 = . . . . . . . . 55
B.3. = Changes to draft-ietf-lisp-rfc6833bis-21 = . . . . . . . . 56 B.3. = Changes to draft-ietf-lisp-rfc6833bis-22 = . . . . . . . . 56
B.4. = Changes to draft-ietf-lisp-rfc6833bis-20 = . . . . . . . . 56 B.4. = Changes to draft-ietf-lisp-rfc6833bis-21 = . . . . . . . . 56
B.5. = Changes to draft-ietf-lisp-rfc6833bis-19 = . . . . . . . . 56 B.5. = Changes to draft-ietf-lisp-rfc6833bis-20 = . . . . . . . . 56
B.6. = Changes to draft-ietf-lisp-rfc6833bis-18 = . . . . . . . . 56 B.6. = Changes to draft-ietf-lisp-rfc6833bis-19 = . . . . . . . . 56
B.7. = Changes to draft-ietf-lisp-rfc6833bis-17 = . . . . . . . . 56 B.7. = Changes to draft-ietf-lisp-rfc6833bis-18 = . . . . . . . . 56
B.8. = Changes to draft-ietf-lisp-rfc6833bis-16 = . . . . . . . . 57 B.8. Changes to draft-ietf-lisp-rfc6833bis-17 . . . . . . . . = 56
B.9. = Changes to draft-ietf-lisp-rfc6833bis-15 = . . . . . . . . 57 B.9. = Changes to draft-ietf-lisp-rfc6833bis-16 = . . . . . . . . 57
B.10. = Changes to draft-ietf-lisp-rfc6833bis-14 = . . . . . . . . 57 B.10. = Changes to draft-ietf-lisp-rfc6833bis-15 = . . . . . . . . 57
B.11. = Changes to draft-ietf-lisp-rfc6833bis-13 = . . . . . . . . 57 B.11. = Changes to draft-ietf-lisp-rfc6833bis-14 = . . . . . . . . 57
B.12. = Changes to draft-ietf-lisp-rfc6833bis-12 = . . . . . . . . 57 B.12. = Changes to draft-ietf-lisp-rfc6833bis-13 = . . . . . . . . 57
B.13. = Changes to draft-ietf-lisp-rfc6833bis-11 = . . . . . . . . 57 B.13. = Changes to draft-ietf-lisp-rfc6833bis-12 = . . . . . . . . 57
B.14. = Changes to draft-ietf-lisp-rfc6833bis-10 = . . . . . . . . 58 B.14. = Changes to draft-ietf-lisp-rfc6833bis-11 = . . . . . . . . 58
B.15. = Changes to draft-ietf-lisp-rfc6833bis-09 = . . . . . . . . 58 B.15. = Changes to draft-ietf-lisp-rfc6833bis-10 = . . . . . . . . 58
B.16. = Changes to draft-ietf-lisp-rfc6833bis-08 = . . . . . . . . 58 B.16. = Changes to draft-ietf-lisp-rfc6833bis-09 = . . . . . . . . 58
B.17. = Changes to draft-ietf-lisp-rfc6833bis-07 = . . . . . . . . 58 B.17. = Changes to draft-ietf-lisp-rfc6833bis-08 = . . . . . . . . 58
B.18. = Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 59 = B.18. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . = 58
B.19. Changes to draft-ietf-lisp-rfc6833bis-05 = . . . . . . . . 59 B.19. Changes to = draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 59
B.20. Changes to draft-ietf-lisp-rfc6833bis-04 = . . . . . . . . 59 B.20. Changes to draft-ietf-lisp-rfc6833bis-05 = . . . . . . . . 59
B.21. Changes to draft-ietf-lisp-rfc6833bis-03 = . . . . . . . . 60 B.21. Changes to draft-ietf-lisp-rfc6833bis-04 = . . . . . . . . 59
B.22. Changes to draft-ietf-lisp-rfc6833bis-02 = . . . . . . . . 60 B.22. Changes to draft-ietf-lisp-rfc6833bis-03 = . . . . . . . . 60
B.23. Changes to draft-ietf-lisp-rfc6833bis-01 = . . . . . . . . 60 B.23. Changes to draft-ietf-lisp-rfc6833bis-02 = . . . . . . . . 60
B.24. Changes to draft-ietf-lisp-rfc6833bis-00 = . . . . . . . . 60 B.24. Changes to draft-ietf-lisp-rfc6833bis-01 = . . . . . . . . 60
B.25. Changes to = draft-farinacci-lisp-rfc6833bis-00 . . . . . . 60 B.25. Changes to draft-ietf-lisp-rfc6833bis-00 = . . . . . . . . 60
= B.26. = Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 61
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 = Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 61
=
1. = Introduction 1. Introduction
=
The Locator/ID = Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see The Locator/ID Separation Protocol = [I-D.ietf-lisp-rfc6830bis] (see
also = [I-D.ietf-lisp-introduction]) specifies an architecture and = also [I-D.ietf-lisp-introduction]) specifies = an architecture and
mechanism for = dynamic tunneling by logically separating the addresses = mechanism for dynamic tunneling by logically = separating the addresses
currently used = by IP in two separate name spaces: Endpoint IDs currently used by IP in two separate name spaces: = Endpoint IDs
(EIDs), used = within sites; and Routing Locators (RLOCs), used on the = (EIDs), used within sites; and Routing = Locators (RLOCs), used on the
transit = networks that make up the Internet infrastructure. To transit networks that make up the Internet = infrastructure. To
=
skipping to = change at = page 4, line 46 =C2=B6 = skipping to change at page 4, line 47 =C2=B6
LISP is not = intended to address problems of connectivity and scaling = LISP is not intended to address problems of = connectivity and scaling
on behalf of = arbitrary communicating parties. Relevant situations on behalf of arbitrary communicating parties. = Relevant situations
are described = in the scoping section of the introduction to are described in the scoping section of the = introduction to
= [I-D.ietf-lisp-rfc6830bis]. = [I-D.ietf-lisp-rfc6830bis].
=
This document = obsoletes RFC 6830 and 6833. This = document obsoletes RFC 6830 and 6833.
=
1.1. Scope of = Applicability 1.1. Scope of = Applicability
=
LISP was = originally developed to address the Internet-wide route = LISP was originally developed to address the = Internet-wide route
scaling = problem [RFC4984].. While there are a = number of approaches scaling = problem [RFC4984]. While there are a = number of approaches of
of interest = for that problem, as LISP as been developed and refined, = interest for that problem, as LISP as been = developed and refined, a
a large = number of other LISP uses have been found and are being used. = large number of other LISP uses have been = found and are being used.
As such, the = design and development of LISP has changed so as to As such, the design and development of LISP has = changed so as to
focus on these = use cases. The common property of these uses is a focus on these use cases. The common property of = these uses is a
large set of = cooperating entities seeking to communicate over the large set of cooperating entities seeking to = communicate over the
public = Internet or other large underlay IP infrastructures, while = public Internet or other large underlay IP = infrastructures, while
keeping the = addressing and topology of the cooperating entities keeping the addressing and topology of the = cooperating entities
separate from = the underlay and Internet topology, routing, and separate from the underlay and Internet topology, = routing, and
= addressing. addressing.
=
2. Requirements = Notation 2. Requirements = Notation
=
= In many IETF = documents, several words, when they are in all capitals
= as shown below, are = used to signify the requirements in the
= specification. = These capitalized words can bring significant clarity
= and consistency to = documents because their meanings are well defined.
= This document = defines how those words are interpreted in IETF
= documents when the = words are in all capitals.
=
= o These words can = be used as defined here, but using them is not
= required. = Specifically, normative text does not require the use
= of these key = words. They are used for clarity and consistency
= when that is = what's wanted, but a lot of normative text does not
= use them and is = still normative.
=
= o The words have = the meanings specified herein only when they are in
= all = capitals.
=
= o When these words = are not capitalized, they have their normal
= English meanings = and are not affected by this document.
=
= Authors who follow = these guidelines should incorporate this phrase
= near the beginning = of their document:
= =
The key words = "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", = "SHALL", "SHALL NOT",
"SHOULD", = "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and = "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT = RECOMMENDED", "MAY", and
"OPTIONAL" in = this document are to be interpreted as described in BCP = "OPTIONAL" in this document are to be = interpreted as described in BCP
14 [RFC2119] = [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they = appear in all
capitals, as = shown here. capitals, as shown = here.
=
3. Definition of = Terms 3. Definition of Terms
=
Map-Server: = A network infrastructure component that learns of EID- Map-Server: A network infrastructure component that = learns of EID-
Prefix = mapping entries from an ETR, via the registration mechanism = Prefix mapping entries from an ETR, via = the registration mechanism
=
skipping to = change at = page 11, line 10 =C2=B6 = skipping to change at page 11, line = 10 =C2=B6
=
The format of = control messages includes the UDP header so the The format of control messages includes the UDP = header so the
checksum and = length fields can be used to protect and delimit message = checksum and length fields can be used to = protect and delimit message
= boundaries. boundaries.
=
5.1. LISP = Control Packet Type Allocations 5.1. = LISP Control Packet Type Allocations
=
This section = defines the LISP control message formats and summarizes = This section defines the LISP control = message formats and summarizes
for IANA the = LISP Type codes assigned by this document. For for IANA the LISP Type codes assigned by this = document. For
completeness, = the summary below includes the LISP Shared Extension completeness, the summary below includes the LISP = Shared Extension
Message = assigned by [RFC8113]. Message type = definitions are: Message assigned = by [I-D.ietf-lisp-rfc8113bis]. Message = type
= = definitions are:
Reserved: 0 = b'0000'
LISP Map-Request: 1 = b'0001'
LISP Map-Reply: 2 = b'0010'
LISP Map-Register: 3 = b'0011'
LISP Map-Notify: 4 = b'0100'
LISP Map-Notify-Ack: 5 = b'0101'
LISP Map-Referral: 6 = b'0110'
Not Assigned 7 = b'0111'
LISP Encapsulated Control Message: 8 = b'1000'
Not Assigned 9-14 b'1001'- = b'1110'
LISP Shared Extension Message: 15 b'1111' = [RFC8113]
=
Values in the "Not Assigned" range can be assigned = according to Reserved: 0 = b'0000'
procedures in [RFC8126]. LISP Map-Request: = 1 b'0001'
= LISP Map-Reply: = 2 b'0010'
= LISP = Map-Register: 3 b'0011'
= LISP Map-Notify: = 4 b'0100'
= LISP = Map-Notify-Ack: 5 b'0101'
= LISP = Map-Referral: 6 b'0110'
= Unassigned = 7 b'0111'
= LISP = Encapsulated Control Message: 8 b'1000'
= Unassigned = 9-14 b'1001'- b'1110'
= LISP Shared = Extension Message: 15 b'1111'
=
Protocol = designers experimenting with new message formats are Protocol designers experimenting with new message = formats are
recommended to = use the LISP Shared Extension Message Type described recommended to use the LISP Shared Extension Message = Type described
in [RFC8113]. = in [I-D.ietf-lisp-rfc8113bis].
=
All LISP = Control-Plane messages use Address Family Identifiers (AFI) = All LISP Control-Plane messages use Address = Family Identifiers (AFI)
[AFI] or LISP = Canonical Address Format (LCAF) [RFC8060] formats to [AFI] or LISP Canonical Address Format (LCAF) = [RFC8060] formats to
encode either = fixed or variable length addresses. This includes encode either fixed or variable length addresses. = This includes
explicit = fields in each control message or part of EID-records or = explicit fields in each control message or = part of EID-records or
RLOC-records = in commonly formatted messages. = RLOC-records in commonly formatted messages.
=
The LISP = control-plane describes how other data-planes can encode = The LISP control-plane describes how other = data-planes can encode
messages to = support the Soliciting of Map-Requests as well as RLOC- = messages to support the Soliciting of = Map-Requests as well as RLOC-
probing = procedures. probing = procedures.
=
skipping to = change at = page 12, line 48 =C2=B6 = skipping to change at page 12, line = 48 =C2=B6
database = system returning a Map-Reply. = database system returning a Map-Reply.
=
M: This is the = map-data-present bit. When set, it indicates that a M: This is the map-data-present bit. When set, it = indicates that a
Map-Reply = Record segment is included in the Map-Request. Map-Reply Record segment is included in the = Map-Request.
=
P: This is the = probe-bit, which indicates that a Map-Request SHOULD P: This is the probe-bit, which indicates that a = Map-Request SHOULD
be treated = as a Locator reachability probe. The receiver SHOULD be treated as a Locator reachability probe. The = receiver SHOULD
respond = with a Map-Reply with the probe-bit set, indicating that = respond with a Map-Reply with the = probe-bit set, indicating that
the = Map-Reply is a Locator reachability probe reply, with the = the Map-Reply is a Locator reachability = probe reply, with the
nonce = copied from the Map-Request. See RLOC-Probing Section 7.1 = nonce copied from the Map-Request. See = RLOC-Probing Section 7.1
for more = details. This RLOC-probe Map-Request MUST not be sent to = for more details. This RLOC-probe Map-Request MUST NOT be sent to
the mapping = system. If a Map-Resolver or Map-Server receives a the mapping system. If a Map-Resolver or = Map-Server receives a
Map-Request = with the probe-bit set, it MUST drop the message. Map-Request with the probe-bit set, it MUST drop = the message.
=
S: This is the = Solicit-Map-Request (SMR) bit. See Solicit-Map- S: This is the Solicit-Map-Request (SMR) bit. See = Solicit-Map-
Request = (SMRs) Section 6.1 for details. = Request (SMRs) Section 6.1 for details.
=
p: This is the = PITR bit. This bit is set to 1 when a PITR sends a p: This is the PITR bit. This bit is set to 1 when a = PITR sends a
= Map-Request. = Map-Request.
=
s: This is the = SMR-invoked bit. This bit is set to 1 when an xTR is s: This is the SMR-invoked bit. This bit is set to 1 = when an xTR is
=
skipping to = change at = page 28, line 49 =C2=B6 = skipping to change at page 28, line = 49 =C2=B6
+-> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= +-> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Packet field = descriptions: Packet field = descriptions:
=
Type: 4/5 = (Map-Notify/Map-Notify-Ack) Type: = 4/5 (Map-Notify/Map-Notify-Ack)
=
The Map-Notify = message has the same contents as a Map-Register The Map-Notify message has the same contents as a = Map-Register
message. See = the Map-Register section for field descriptions and the = message. See the Map-Register section for = field descriptions and the
Map-Reply = section for EID-record and RLOC-record descriptions. Map-Reply section for EID-record and RLOC-record = descriptions.
=
= The fields of the = Map-Notify are copied from the corresponding Map-
= Register to = acknowledge its correct processing. For an unsolicited
= Map-Notify, the = fields of a Map-Notify used for publish/subscribe are
= specified in = [I-D.ietf-lisp-pubsub]].
= =
The = Map-Notify-Ack message has the same contents as a Map-Notify = The Map-Notify-Ack message has the same = contents as a Map-Notify
message. It = is used to acknowledge the receipt of a Map-Notify message. It is used to acknowledge the receipt of a = Map-Notify
(solicited or = unsolicited) and for the sender to stop retransmitting (solicited or unsolicited) and for the sender to stop = retransmitting
a Map-Notify = with the same nonce. a Map-Notify = with the same nonce. The fields of the = Map-Notify-Ack
= are copied from the = corresponding Map-Notify message to acknowledge
= its correct = processing.
=
A Map-Server = sends an unsolicited Map-Notify message (one that is not = A Map-Server sends an unsolicited Map-Notify = message (one that is not
used as an = acknowledgment to a Map-Register message) that follows the = used as an acknowledgment to a Map-Register = message) that follows the
Congestion = Control And Relability Guideline sections of [RFC8085]. A = Congestion Control And Relability Guideline = sections of [RFC8085]. A
Map-Notify is = retransmitted until a Map-Notify-Ack is received by the = Map-Notify is retransmitted until a = Map-Notify-Ack is received by the
Map-Server = with the same nonce used in the Map-Notify message. If a = Map-Server with the same nonce used in the = Map-Notify message. If a
Map-Notify-Ack = is never received by the Map-Server, it issues a log Map-Notify-Ack is never received by the Map-Server, = it issues a log
message. An = implementation SHOULD retransmit up to 3 times at 3 message. An implementation SHOULD retransmit up to 3 = times at 3
second = retransmission intervals, after which time the retransmission = second retransmission intervals, after which = time the retransmission
interval is = exponentially backed-off for another 3 retransmission interval is exponentially backed-off for another 3 = retransmission
=
skipping to = change at = page 41, line 40 =C2=B6 = skipping to change at page 41, line = 40 =C2=B6
attacker to = mount DoS and/or amplification attacks. Attackers can attacker to mount DoS and/or amplification attacks. = Attackers can
send = Map-Requests at high rates to overload LISP nodes and increase = send Map-Requests at high rates to overload = LISP nodes and increase
the state = maintained by such nodes or consume CPU cycles. Such the state maintained by such nodes or consume CPU = cycles. Such
threats can be = mitigated by systematically applying filters and rate threats can be mitigated by systematically applying = filters and rate
= limiters. limiters.
=
The 2-way LISP = control-plane header nonce exchange can be used to The 2-way LISP control-plane header nonce exchange = can be used to
avoid ITR = spoofing attacks, but active on-path attackers (e.g 'man- = avoid ITR spoofing attacks, but active = on-path attackers (e.g 'man-
= in-the-middle') capable of intercepting the nonce can exploit = the in-the-middle') capable of = intercepting the nonce can exploit the
= Map-Request/Map-Reply message exchange to inject forged = mappings Map-Request/Map-Reply = message exchange to inject forged mappings
directly in = the ITR EID-to-RLOC map-cache. In addition, valid ETRs = directly in the ITR EID-to-RLOC map-cache. = This can lead to traffic
in the = system can perform overclaiming attacks. In this case, = being redirected to = the attacker, see further details in [RFC7835].
attackers = can claim to own an EID-prefix that is larger than the In addition, valid ETRs in the system can perform = overclaiming
prefix owned = by the ETR. Such attacks can be addressed by using attacks. In this case, attackers can claim to own = an EID-prefix that
LISP-SEC = [I-D.ietf-lisp-sec]. The LISP-SEC protocol defines a is larger than the prefix owned by the ETR. Such = attacks can be
mechanism = for providing origin authentication, integrity, anti- = addressed by using LISP-SEC [I-D.ietf-lisp-sec]. The LISP-SEC
replay, protection, and prevention of 'man-in-the-middle' and 'prefix = protocol defines a mechanism for providing = origin authentication,
= overclaiming' attacks on the Map-Request/Map-Reply exchange. In = integrity, anti-replay, protection, and prevention of 'man-in-the-
addition and = while beyond the scope of securing an individual Map- middle' and 'prefix overclaiming' attacks on = the Map-Request/Map-
Server or Map-Resolver, it should be noted = that LISP-SEC can be Reply exchange. In addition and while beyond = the scope of securing
complemented = by additional security mechanisms defined by the Mapping = an individual Map-Server or Map-Resolver, it should be noted = that
System = Infrastructure. For instance, BGP-based = LISP-ALT [RFC6836] LISP-SEC can be = complemented by additional security mechanisms
can take = advantage of standards work on adding security to BGP while = defined by the Mapping System = Infrastructure. For instance, BGP-
LISP-DDT = [RFC8111] defines its own additional security mechanisms. = based = LISP-ALT [RFC6836] can take advantage of standards work on
= adding security to BGP while LISP-DDT = [RFC8111] defines its own
= additional security mechanisms.
=
To publish an = authoritative EID-to-RLOC mapping with a Map-Server To publish an authoritative EID-to-RLOC mapping with = a Map-Server
using the = Map-Register message, an ETR includes authentication data = using the Map-Register message, an ETR = includes authentication data
that is a MAC = of the entire message using a pair-wise shared key. An = that is a MAC of the entire message using a = pair-wise shared key. An
implementation = MUST support use of HMAC-SHA-1-96 [RFC2104] and SHOULD implementation MUST support use of HMAC-SHA-1-96 = [RFC2104] and SHOULD
support use of = HMAC-SHA-256-128 [RFC6234] (SHA-256 truncated to 128 support use of HMAC-SHA-256-128 [RFC6234] (SHA-256 = truncated to 128
bits). The = Map-Register message is vulnerable to replay attacks by a = bits). The Map-Register message is = vulnerable to replay attacks by a
= man-in-the-middle. A compromised ETR can overclaim the prefix = it man-in-the-middle. A = compromised ETR can overclaim the prefix it
owns and = successfully register it on its corresponding Map-Server. = owns and successfully register it on its = corresponding Map-Server.
To mitigate = this and as noted in Section 8.2, a Map-Server SHOULD To mitigate this and as noted in Section 8.2, a = Map-Server SHOULD
=
skipping to = change at = page 45, line 9 =C2=B6 = skipping to change at page 45, line 9 =C2=B6
=
New ACT values = can be allocated through IETF review or IESG approval. New ACT values can be allocated through IETF review = or IESG approval.
Four values = have already been allocated by [RFC6830], IANA is Four values have already been allocated by [RFC6830], = IANA is
requested to = replace the [RFC6830] reference for this registry with requested to replace the [RFC6830] reference for this = registry with
the RFC number = assigned to this document and the [RFC6830]. Action the RFC number assigned to this document and the = [RFC6830]. Action
values = references with the RFC number assigned to this document. = values references with the RFC number = assigned to this document.
This = specification changes the name of ACT type 3 value from "Drop" = This specification changes the name of ACT = type 3 value from "Drop"
to = "Drop/No-Reason" as well as adding two new ACT values, the = "Drop/ to "Drop/No-Reason" as well = as adding two new ACT values, the "Drop/
Policy-Denied" = (type 4) and "Drop/Authentication-Failure" (type 5). Policy-Denied" (type 4) and = "Drop/Authentication-Failure" (type 5).
=
Value = Action Description Reference = +-------+--------------------+-------------------------+-= -----------+
----- ------ ----------- = --------- | Value | = Action | Description = | Raeference |
4 Drop/ A Packet matching this Map-Cache RFC6833bis = +-------+--------------------+-------------------------+------------+
Policy-Denied entry is dropped because the = target = | 4 | Drop/Policy-Denied | A = packet matching this | RFC6833bis |
= EID is policy-denied by the xTR or | | = | Map-Cache entry is | = |
= the mapping system. | | | dropped = because the | |
= | | = | target EWID is policy- | |
= | | = | denied by the xTR or | |
= | | = | the mapping system. | |
= | 5 | = Drop/Auth-Failure | Packet matching the | RFC6833bis = |
= | | = | Map-Cache entry is | |
= | | = | dropped beacuse the | |
= | | = | Map-Request for the | |
= | | = | target EID fails an | |
= | | = | authentication check by | = |
= | | = | the xTR or the mapping | = |
= | | = | system. | = |
= = +-------+--------------------+-------------------------+------------+
=
5 Drop/ A Packet matching this Map-Cache = RFC6833bis = LISP Map-Reply Action Values
Auth-Failure entry is dropped because = the
Map-Request for target EID = fails an
authentication check by the = xTR or
the mapping = system.
=
In addition, = LISP has a number of flag fields and reserved fields, In addition, LISP has a number of flag fields and = reserved fields,
such as the = LISP header flags field [I-D.ietf-lisp-rfc6830bis]. New = such as the LISP header flags field = [I-D.ietf-lisp-rfc6830bis]. New
bits for flags = in these fields can be implemented after IETF review bits for flags in these fields can be implemented = after IETF review
or IESG = approval, but these need not be managed by IANA. or IESG approval, but these need not be managed by = IANA.
=
12.4. LISP = Address Type Codes 12.4. LISP Address = Type Codes
=
LISP Canonical = Address Format (LCAF) [RFC8060] is an 8-bit field that LISP Canonical Address Format (LCAF) [RFC8060] is an = 8-bit field that
defines = LISP-specific encodings for AFI value 16387. LCAF encodings = defines LISP-specific encodings for AFI = value 16387. LCAF encodings
=
skipping to = change at = page 46, line 25 =C2=B6 = skipping to change at page 46, line = 34 =C2=B6
=
This document = asks IANA to create a registry for allocation of bits This document asks IANA to create a registry for = allocation of bits
in several = headers of the LISP control plane, namely in the Map- in several headers of the LISP control plane, namely = in the Map-
Request, = Map-Reply, Map-Register, Encapsulated Control Message (ECM) = Request, Map-Reply, Map-Register, = Encapsulated Control Message (ECM)
messages. Bit = allocations are also requested for EID-records and messages. Bit allocations are also requested for = EID-records and
RLOC-records. = The registry created should be named "LISP Control RLOC-records. The registry created should be named = "LISP Control
Plane Header = Bits". A sub-registry needs to be created per each Plane Header Bits". A sub-registry needs to be = created per each
message and = record. The name of each sub-registry is indicated message and record. The name of each sub-registry is = indicated
below, along = with its format and allocation of bits defined in this below, along with its format and allocation of bits = defined in this
document. Any = additional bits allocation, requires a specification, document. Any additional bits allocation, requires a = specification,
according = with [RFC5226] policies. according with [RFC8126]= policies.
=
Sub-Registry: = Map-Request Header Bits [Section 5.2]: = Sub-Registry: Map-Request Header Bits [Section 5.2]:
=
0 = 1 2 3 0 1 2 = 3
0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 = 6 7 8 9 0 1
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=3D1 = |A|M|P|S|p|s|R|R| Rsvd |L|D| IRC | Record Count | = |Type=3D1 |A|M|P|S|p|s|R|R| Rsvd |L|D| = IRC | Record Count |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
= +----------+---------------+------------+---------------------------+ = +----------+---------------+------------+---------------------------+
| Spec | = IANA Name | Bit | Description | = | Spec | IANA Name | Bit | = Description |
| Name | = | Position | | | Name | | Position | = |
= +----------+---------------+------------+---------------------------+ = +----------+---------------+------------+---------------------------+
| A | = map-request-A | 4 | Authoritative Bit | = | A | map-request-A | 4 | = Authoritative Bit |
| M | = map-request-M | 5 | Map Data Present Bit | = | M | map-request-M | 5 | = Map Data Present Bit |
| P | = map-request-P | 6 | RLOC-Probe Request Bit | = | P | map-request-P | 6 | = RLOC-Probe Request Bit |
| S | = map-request-S | 7 | Solicit Map-Request (SMR) | = | S | map-request-S | 7 | = Solicit Map-Request (SMR) |
| | = | | Bit | | | | | Bit = |
| p | = map-request-p | 8 | Proxy-ITR Bit | = | p | map-request-p | 8 | = Proxy-ITR Bit |
=
skipping = to change at page 49, line = 20 =C2=B6 = skipping to change at page 49, line = 36 =C2=B6
= Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID = Iannone, L., Saucez, D., and O. = Bonaventure, "Locator/ID
= Separation Protocol (LISP) Map-Versioning", draft-ietf- = Separation Protocol (LISP) = Map-Versioning", draft-ietf-
= lisp-6834bis-02 (work in progress), September 2018. lisp-6834bis-02 (work in progress), = September 2018.
=
= [I-D.ietf-lisp-rfc6830bis] = [I-D.ietf-lisp-rfc6830bis]
= Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. = Farinacci, D., Fuller, V., Meyer, = D., Lewis, D., and A.
= Cabellos-Aparicio, "The Locator/ID Separation Protocol Cabellos-Aparicio, "The Locator/ID = Separation Protocol
= (LISP)", draft-ietf-lisp-rfc6830bis-26 (work in progress), = (LISP)", = draft-ietf-lisp-rfc6830bis-26 (work in progress),
= November 2018. November = 2018.
=
= [I-D.ietf-lisp-rfc8113bis]
= = Boucadair, M. and C. Jacquenet, "Locator/ID Separation
= Protocol = (LISP): Shared Extension Message & IANA Registry
= for = Packet Type Allocations", draft-ietf-lisp-
= = rfc8113bis-03 (work in progress), January 2019.
= =
= [I-D.ietf-lisp-sec] = [I-D.ietf-lisp-sec]
= Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Maino, F., Ermagan, V., Cabellos-Aparicio, = A., and D.
= Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-17 = Saucez, "LISP-Security = (LISP-SEC)", draft-ietf-lisp-sec-17
= (work in progress), November 2018. = (work in progress), November 2018.
=
= [RFC2119] Bradner, = S., "Key words for use in RFCs to Indicate
= = Requirement Levels", BCP 14, RFC 2119,
= DOI = 10.17487/RFC2119, March 1997,
= = <https://www.rfc-editor.org/info/rfc2119>.
= =
[RFC2404] = Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within = [RFC2404] Madson, C. and R. Glenn, "The Use = of HMAC-SHA-1-96 within
ESP = and AH", RFC 2404, DOI 10.17487/RFC2404, November ESP and AH", RFC 2404, DOI = 10.17487/RFC2404, November
= 1998, <https://www.rfc-editor.org/info/rfc2404>. 1998, = <https://www.rfc-editor.org/info/rfc2404>.
=
[RFC4086] = Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. = Crocker,
= "Randomness Requirements for Security", BCP 106, RFC 4086, = "Randomness Requirements for = Security", BCP 106, RFC 4086,
DOI = 10.17487/RFC4086, June 2005, = DOI 10.17487/RFC4086, June 2005,
= <https://www.rfc-editor.org/info/rfc4086>. = <https://www.rfc-editor.org/info/rfc4086>.
=
[RFC4868] = Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- = [RFC4868] Kelly, S. and S. Frankel, "Using = HMAC-SHA-256, HMAC-SHA-
= 384, and HMAC-SHA-512 with IPsec", RFC 4868, 384, and HMAC-SHA-512 with IPsec", RFC = 4868,
DOI = 10.17487/RFC4868, May 2007, = DOI 10.17487/RFC4868, May 2007,
= <https://www.rfc-editor.org/info/rfc4868>. = <https://www.rfc-editor.org/info/rfc4868>.
=
[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, = Ed., "Report
from the IAB Workshop on Routing and = Addressing",
RFC 4984, DOI 10.17487/RFC4984, September = 2007,
= <https://www.rfc-editor.org/info/rfc4984>. =
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines = for Writing an
IANA Considerations Section in RFCs", RFC = 5226,
DOI 10.17487/RFC5226, May = 2008,
= <https://www.rfc-editor.org/info/rfc5226>. =
[RFC6071] Frankel, S. and S. Krishnan, "IP Security = (IPsec) and
Internet Key Exchange (IKE) Document = Roadmap", RFC 6071,
DOI 10.17487/RFC6071, February = 2011,
= <https://www.rfc-editor.org/info/rfc6071>. =
= =
[RFC6347] = Rescorla, E. and N. Modadugu, "Datagram Transport Layer = [RFC6347] Rescorla, E. and N. Modadugu, = "Datagram Transport Layer
= Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI = 10.17487/RFC6347,
= January 2012, <https://www.rfc-editor.org/info/rfc6347>. = January 2012, = <https://www.rfc-editor.org/info/rfc6347>.
=
[RFC8085] = Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. = Shepherd, "UDP Usage
= Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI = 10.17487/RFC8085,
= March 2017, <https://www.rfc-editor.org/info/rfc8085>. = March 2017, = <https://www.rfc-editor.org/info/rfc8085>.
=
= [RFC8126] Cotton, = M., Leiba, B., and T. Narten, "Guidelines for
= Writing = an IANA Considerations Section in RFCs", BCP 26,
= RFC 8126, = DOI 10.17487/RFC8126, June 2017,
= = <https://www.rfc-editor.org/info/rfc8126>.
=
= [RFC8174] Leiba, = B., "Ambiguity of Uppercase vs Lowercase in RFC
= 2119 Key = Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
= May 2017, = <https://www.rfc-editor.org/info/rfc8174>.
= =
13.2. = Informative References 13.2. = Informative References
=
[AFI] = IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY = [AFI] IANA, "Address Family Identifier = (AFIs)", ADDRESS FAMILY
= NUMBERS http://www.iana.org/assignments/address-family- = NUMBERS = http://www.iana.org/assignments/address-family-
= numbers/address-family-numbers.xhtml?, Febuary 2007. numbers/address-family-numbers.xhtml?, = Febuary 2007.
=
= [GTP-3GPP] [GTP-3GPP]
= 3GPP, "General Packet Radio System (GPRS) Tunnelling 3GPP, "General Packet Radio System (GPRS) = Tunnelling
= Protocol User Plane (GTPv1-U)", TS.29.281 Protocol User Plane (GTPv1-U)", = TS.29.281
= https://portal.3gpp.org/desktopmodules/Specifications/ = https://portal.3gpp.org/desktopmodules/Specifications/
=
skipping = to change at page 52, line = 5 =C2=B6 = skipping to change at page 52, line = 23 =C2=B6
=
[RFC1071] = Braden, R., Borman, D., and C. Partridge, "Computing the = [RFC1071] Braden, R., Borman, D., and C. = Partridge, "Computing the
= Internet checksum", RFC 1071, DOI 10.17487/RFC1071, Internet checksum", RFC 1071, DOI = 10.17487/RFC1071,
= September 1988, = <https://www.rfc-editor.org/info/rfc1071>. September 1988, = <https://www.rfc-editor.org/info/rfc1071>.
=
[RFC2104] = Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- = [RFC2104] Krawczyk, H., Bellare, M., and R. = Canetti, "HMAC: Keyed-
= Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC = 2104,
DOI = 10.17487/RFC2104, February 1997, = DOI 10.17487/RFC2104, February 1997,
= <https://www.rfc-editor.org/info/rfc2104>. = <https://www.rfc-editor.org/info/rfc2104>.
=
[RFC2119] Bradner, S., "Key words for use in RFCs to = Indicate
Requirement Levels", BCP 14, RFC = 2119,
DOI 10.17487/RFC2119, March = 1997,
= <https://www.rfc-editor.org/info/rfc2119>. =
= =
[RFC2890] = Dommety, G., "Key and Sequence Number Extensions to GRE", = [RFC2890] Dommety, G., "Key and Sequence = Number Extensions to GRE",
RFC = 2890, DOI 10.17487/RFC2890, September 2000, RFC 2890, DOI 10.17487/RFC2890, September = 2000,
= <https://www.rfc-editor.org/info/rfc2890>. = <https://www.rfc-editor.org/info/rfc2890>.
=
= [RFC4984] Meyer, = D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report
= from the = IAB Workshop on Routing and Addressing",
= RFC 4984, = DOI 10.17487/RFC4984, September 2007,
= = <https://www.rfc-editor.org/info/rfc4984>.
= =
[RFC6234] = Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms = [RFC6234] Eastlake 3rd, D. and T. Hansen, = "US Secure Hash Algorithms
= (SHA and SHA-based HMAC and HKDF)", RFC 6234, (SHA and SHA-based HMAC and HKDF)", RFC = 6234,
DOI = 10.17487/RFC6234, May 2011, = DOI 10.17487/RFC6234, May 2011,
= <https://www.rfc-editor.org/info/rfc6234>. = <https://www.rfc-editor.org/info/rfc6234>.
=
[RFC6830] = Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The = [RFC6830] Farinacci, D., Fuller, V., Meyer, = D., and D. Lewis, "The
= Locator/ID Separation Protocol (LISP)", RFC 6830, Locator/ID Separation Protocol (LISP)", = RFC 6830,
DOI = 10.17487/RFC6830, January 2013, = DOI 10.17487/RFC6830, January 2013,
= <https://www.rfc-editor.org/info/rfc6830>. = <https://www.rfc-editor.org/info/rfc6830>.
=
=
skipping = to change at page 53, line = 31 =C2=B6 = skipping to change at page 53, line = 47 =C2=B6
[RFC8061] = Farinacci, D. and B. Weis, "Locator/ID Separation Protocol = [RFC8061] Farinacci, D. and B. Weis, = "Locator/ID Separation Protocol
= (LISP) Data-Plane Confidentiality", RFC 8061, (LISP) Data-Plane Confidentiality", RFC = 8061,
DOI = 10.17487/RFC8061, February 2017, = DOI 10.17487/RFC8061, February 2017,
= <https://www.rfc-editor.org/info/rfc8061>. = <https://www.rfc-editor.org/info/rfc8061>.
=
[RFC8111] = Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, = A., and A.
= Smirnov, "Locator/ID Separation Protocol Delegated Smirnov, "Locator/ID Separation Protocol = Delegated
= Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, = Database Tree (LISP-DDT)", RFC = 8111, DOI 10.17487/RFC8111,
May = 2017, <https://www.rfc-editor.org/info/rfc8111>. May 2017, = <https://www.rfc-editor.org/info/rfc8111>.
=
[RFC8113] Boucadair, M. and C. Jacquenet, "Locator/ID = Separation
Protocol (LISP): Shared Extension Message = & IANA Registry
for Packet Type Allocations", RFC = 8113,
DOI 10.17487/RFC8113, March = 2017,
= <https://www.rfc-editor.org/info/rfc8113>. =
[RFC8126] Cotton, M., Leiba, B., and T. Narten, = "Guidelines for
Writing an IANA Considerations Section in = RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June = 2017,
= <https://www.rfc-editor.org/info/rfc8126>. =
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs = Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI = 10.17487/RFC8174,
May 2017, = <https://www.rfc-editor.org/info/rfc8174>. =
= =
[RFC8378] = Moreno, V. and D. Farinacci, "Signal-Free Locator/ID [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free = Locator/ID
= Separation Protocol (LISP) Multicast", RFC 8378, Separation Protocol (LISP) Multicast", RFC = 8378,
DOI = 10.17487/RFC8378, May 2018, = DOI 10.17487/RFC8378, May 2018,
= <https://www.rfc-editor.org/info/rfc8378>. = <https://www.rfc-editor.org/info/rfc8378>.
=
[RFC8402] = Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., = Ginsberg, L.,
= Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. = Shakir, "Segment
= Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI = 10.17487/RFC8402,
= July 2018, <https://www.rfc-editor.org/info/rfc8402>. = July 2018, = <https://www.rfc-editor.org/info/rfc8402>.
=
=
skipping = to change at page 55, line = 30 =C2=B6 = skipping to change at page 55, line = 30 =C2=B6
Kaduk, Eric = Rescorla, Alvaro Retana, Alexey Melnikov, Alissa Cooper, = Kaduk, Eric Rescorla, Alvaro Retana, Alexey = Melnikov, Alissa Cooper,
Suresh = Krishnan, Alberto Rodriguez-Natal, Vina Ermagen, Mohamed = Suresh Krishnan, Alberto Rodriguez-Natal, = Vina Ermagen, Mohamed
Boucadair, = Brian Trammell, Sabrina Tanamal, and John Drake. The Boucadair, Brian Trammell, Sabrina Tanamal, and John = Drake. The
contributions = they offered greatly added to the security, scale, and contributions they offered greatly added to the = security, scale, and
robustness of = the LISP architecture and protocols. = robustness of the LISP architecture and protocols.
=
Appendix B. = Document Change Log Appendix B. = Document Change Log
=
[RFC Editor: = Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on = publication as RFC.]
=
B.1. Changes = to draft-ietf-lisp-rfc6833bis-23 B.1. = Changes to draft-ietf-lisp-rfc6833bis-24
=
= o Posted February = 2019.
=
= o Added suggested = text from Albert that Benjamin Kaduk agreed with.
=
= o Added suggested = editorial comments from Alvaro's rewview.
=
= o Ran document = through IDnits. Fixed bugs found.
=
= B.2. Changes to = draft-ietf-lisp-rfc6833bis-23
=
o Posted = December 2018. o Posted December = 2018.
=
o Added to = Security Considerations section that deployments that o Added to Security Considerations section that = deployments that
care about = prefix over claiming should use LISP-SEC. care about prefix over claiming should use = LISP-SEC.
=
o Added to = Security Considerations section that DTLS or LISP-crypto = o Added to Security Considerations section = that DTLS or LISP-crypto
be used for = control-plane privacy. be used = for control-plane privacy.
=
o Make = LISP-SEC a normative reference. o = Make LISP-SEC a normative reference.
=
o Make it = more clear where field descriptions are spec'ed when o Make it more clear where field descriptions are = spec'ed when
referencing = to the same fields in other packet types. referencing to the same fields in other packet = types.
=
B.2. Changes to = draft-ietf-lisp-rfc6833bis-22 B.3. Changes to = draft-ietf-lisp-rfc6833bis-22
=
o Posted week = after IETF November 2018. o Posted = week after IETF November 2018.
=
o No longer = need to use IPSEC for replay attacks. = o No longer need to use IPSEC for replay attacks.
=
B.3. Changes to = draft-ietf-lisp-rfc6833bis-21 B.4. Changes to = draft-ietf-lisp-rfc6833bis-21
=
o Posted = early November 2018. o Posted = early November 2018.
=
o Added I-bit = back in because its necessary to use for Map-Register o Added I-bit back in because its necessary to use = for Map-Register
replay = attack scenarios. The Map-Server tracks the nonce per xTR- = replay attack scenarios. The Map-Server = tracks the nonce per xTR-
ID to = detect duplicate or replayed Map-Register messages. ID to detect duplicate or replayed Map-Register = messages.
=
B.4. Changes to = draft-ietf-lisp-rfc6833bis-20 B.5. Changes to = draft-ietf-lisp-rfc6833bis-20
=
o Posted late = October 2018. o Posted late = October 2018.
=
o Changed = description about "reserved" bits to state "reserved and = o Changed description about "reserved" bits = to state "reserved and
= unassigned". = unassigned".
=
o Make it = more clear how Map-Register nonce processing is performed = o Make it more clear how Map-Register nonce = processing is performed
in an ETR = and Map-Server. in an ETR and = Map-Server.
=
B.5. Changes to = draft-ietf-lisp-rfc6833bis-19 B.6. Changes to = draft-ietf-lisp-rfc6833bis-19
=
o Posted mid = October 2018. o Posted mid October = 2018.
=
o Added Fabio = text to the Security Considerations section. o Added Fabio text to the Security Considerations = section.
=
B.6. Changes to = draft-ietf-lisp-rfc6833bis-18 B.7. Changes to = draft-ietf-lisp-rfc6833bis-18
=
o Posted mid = October 2018. o Posted mid October = 2018.
=
o Fixed = comments from Eric after more email clarity. o Fixed comments from Eric after more email = clarity.
=
B.7. Changes to = draft-ietf-lisp-rfc6833bis-17 B.8. Changes to = draft-ietf-lisp-rfc6833bis-17
=
o Posted = early October 2018. o Posted early = October 2018.
=
o Changes to = reflect comments from Sep 27th Telechat. o Changes to reflect comments from Sep 27th = Telechat.
=
o Added all = flag bit definitions as request for allocation in IANA o Added all flag bit definitions as request for = allocation in IANA
= Considersations section. = Considersations section.
=
o Added an = applicability statement in section 1 to address security = o Added an applicability statement in = section 1 to address security
concerns = from Telechat. concerns from = Telechat.
=
o Moved m-bit = description and IANA request to draft-ietf-lisp-mn. o Moved m-bit description and IANA request to = draft-ietf-lisp-mn.
=
o Moved I-bit = description and IANA request to draft-ietf-lisp- o Moved I-bit description and IANA request to = draft-ietf-lisp-
= pubsub. pubsub.
=
B.8. Changes to = draft-ietf-lisp-rfc6833bis-16 B.9. Changes to = draft-ietf-lisp-rfc6833bis-16
=
o Posted = Late-September 2018. o Posted = Late-September 2018.
=
o Re-wrote = Security Considerations section. Thanks Albert. o Re-wrote Security Considerations section. Thanks = Albert.
=
o Added = Alvaro text to be more clear about IANA actions. o Added Alvaro text to be more clear about IANA = actions.
=
B.9. Changes to = draft-ietf-lisp-rfc6833bis-15 B.10. Changes to = draft-ietf-lisp-rfc6833bis-15
=
o Posted = mid-September 2018. o Posted = mid-September 2018.
=
o Changes to = reflect comments from Colin and Mirja. = o Changes to reflect comments from Colin and Mirja.
=
B.10. Changes to = draft-ietf-lisp-rfc6833bis-14 B.11. Changes to = draft-ietf-lisp-rfc6833bis-14
=
o Posted = September 2018. o Posted September = 2018.
=
o Changes to = reflect comments from Genart, RTGarea, and Secdir o Changes to reflect comments from Genart, RTGarea, = and Secdir
= reviews. reviews.
=
B.11. Changes to = draft-ietf-lisp-rfc6833bis-13 B.12. Changes to = draft-ietf-lisp-rfc6833bis-13
=
o Posted = August 2018. o Posted August = 2018.
=
o Final = editorial changes before RFC submission for Proposed o Final editorial changes before RFC submission for = Proposed
= Standard. Standard.
=
o Added = section "Changes since RFC 6833" so implementators are o Added section "Changes since RFC 6833" so = implementators are
informed of = any changes since the last RFC publication. informed of any changes since the last RFC = publication.
=
B.12. Changes to = draft-ietf-lisp-rfc6833bis-12 B.13. Changes to = draft-ietf-lisp-rfc6833bis-12
=
o Posted late = July 2018. o Posted late July = 2018.
=
o Moved = RFC6830bis and RFC6834bis to Normative References. o Moved RFC6830bis and RFC6834bis to Normative = References.
=
B.13. Changes to = draft-ietf-lisp-rfc6833bis-11 B.14. Changes to = draft-ietf-lisp-rfc6833bis-11
=
o Posted July = 2018. o Posted July 2018.
=
o Fixed Luigi = editorial comments to ready draft for RFC status and o Fixed Luigi editorial comments to ready draft for = RFC status and
ran through = IDNITs again. ran through IDNITs = again.
=
B.14. Changes to = draft-ietf-lisp-rfc6833bis-10 B.15. Changes to = draft-ietf-lisp-rfc6833bis-10
=
o Posted = after LISP WG at IETF week March. o = Posted after LISP WG at IETF week March.
=
o Move AD = field encoding after S-bit in the ECM packet format o Move AD field encoding after S-bit in the ECM = packet format
description = section. description = section.
=
o Say more = about when the new Drop actions should be sent. o Say more about when the new Drop actions should be = sent.
=
B.15. Changes to = draft-ietf-lisp-rfc6833bis-09 B.16. Changes to = draft-ietf-lisp-rfc6833bis-09
=
o Posted = March IETF week 2018. o Posted = March IETF week 2018.
=
o Fixed = editorial comments submitted by document shepherd Luigi = o Fixed editorial comments submitted by = document shepherd Luigi
= Iannone. Iannone.
=
B.16. Changes to = draft-ietf-lisp-rfc6833bis-08 B.17. Changes to = draft-ietf-lisp-rfc6833bis-08
=
o Posted = March 2018. o Posted March = 2018.
=
o Added = RLOC-probing algorithm. o Added = RLOC-probing algorithm.
=
o Added = Solicit-Map Request algorithm. o = Added Solicit-Map Request algorithm.
=
o Added = several mechanisms (from 6830bis) regarding Routing Locator = o Added several mechanisms (from 6830bis) = regarding Routing Locator
= Reachability. = Reachability.
=
o Added port = 4342 to IANA Considerations section. = o Added port 4342 to IANA Considerations section.
=
B.17. Changes to = draft-ietf-lisp-rfc6833bis-07 B.18. Changes to = draft-ietf-lisp-rfc6833bis-07
=
o Posted = December 2017. o Posted December = 2017.
=
o Make it = more clear in a couple of places that RLOCs are used to = o Make it more clear in a couple of places = that RLOCs are used to
locate ETRs = more so than for Map-Server Map-Request forwarding. locate ETRs more so than for Map-Server = Map-Request forwarding.
=
o Make it = clear that "encapsualted" for a control message is an ECM = o Make it clear that "encapsualted" for a = control message is an ECM
based = message. based message.
=
o Make it = more clear what messages use source-port 4342 and which = o Make it more clear what messages use = source-port 4342 and which
=
skipping = to change at page 59, line = 13 =C2=B6 = skipping to change at page 59, line = 19 =C2=B6
Can use = othe AFIs then IPv4 and IPv6. = Can use othe AFIs then IPv4 and IPv6.
=
o Many = editorial changes to clarify text. = o Many editorial changes to clarify text.
=
o Changed = some "must", "should", and "may" to capitalized. o Changed some "must", "should", and "may" to = capitalized.
=
o Added = definitions for Map-Request and Map-Reply messages. o Added definitions for Map-Request and Map-Reply = messages.
=
o Ran = document through IDNITs. o Ran = document through IDNITs.
=
B.18. Changes to = draft-ietf-lisp-rfc6833bis-06 B.19. Changes to = draft-ietf-lisp-rfc6833bis-06
=
o Posted = October 2017. o Posted October = 2017.
=
o Spec the = I-bit to include the xTR-ID in a Map-Request message to = o Spec the I-bit to include the xTR-ID in a = Map-Request message to
be = consistent with the Map-Register message and to anticipate the = be consistent with the Map-Register = message and to anticipate the
= introduction of pubsub functionality to allow Map-Requests to = introduction of pubsub functionality to = allow Map-Requests to
subscribe = to RLOC-set changes. subscribe = to RLOC-set changes.
=
o Updated = references for individual submissions that became working = o Updated references for individual = submissions that became working
group = documents. group = documents.
=
o Updated = references for working group documents that became RFCs. = o Updated references for working group = documents that became RFCs.
=
B.19. Changes to = draft-ietf-lisp-rfc6833bis-05 B.20. Changes to = draft-ietf-lisp-rfc6833bis-05
=
o Posted May = 2017. o Posted May 2017.
=
o Update IANA = Considerations section based on new requests from this o Update IANA Considerations section based on new = requests from this
document = and changes from what was requested in [RFC6830]. document and changes from what was requested in = [RFC6830].
=
B.20. Changes to = draft-ietf-lisp-rfc6833bis-04 B.21. Changes to = draft-ietf-lisp-rfc6833bis-04
=
o Posted May = 2017. o Posted May 2017.
=
o Clarify how = the Key-ID field is used in Map-Register and Map- o Clarify how the Key-ID field is used in = Map-Register and Map-
Notify = messages. Break the 16-bit field into a 8-bit Key-ID field = Notify messages. Break the 16-bit field = into a 8-bit Key-ID field
and a 8-bit = Algorithm-ID field. and a 8-bit = Algorithm-ID field.
=
o Move the = Control-Plane codepoints from the IANA Considerations o Move the Control-Plane codepoints from the IANA = Considerations
section of = RFC6830bis to the IANA Considerations section of this section of RFC6830bis to the IANA Considerations = section of this
= document. document.
=
o In the = "LISP Control Packet Type Allocations" section, indicate = o In the "LISP Control Packet Type = Allocations" section, indicate
how message = Types are IANA allocated and how experimental RFC8113 how message Types are IANA allocated and how = experimental RFC8113
sub-types = should be requested. sub-types = should be requested.
=
B.21. Changes to = draft-ietf-lisp-rfc6833bis-03 B.22. Changes to = draft-ietf-lisp-rfc6833bis-03
=
o Posted = April 2017. o Posted April = 2017.
=
o Add types = 9-14 and specify they are not assigned. = o Add types 9-14 and specify they are not assigned.
=
o Add the = "LISP Shared Extension Message" type and point to RFC8113. = o Add the "LISP Shared Extension Message" = type and point to RFC8113.
=
B.22. Changes to = draft-ietf-lisp-rfc6833bis-02 B.23. Changes to = draft-ietf-lisp-rfc6833bis-02
=
o Posted = April 2017. o Posted April = 2017.
=
o Clarify = that the LISP Control-Plane document defines how the LISP = o Clarify that the LISP Control-Plane = document defines how the LISP
Data-Plane = uses Map-Requests with either the SMR-bit set or the Data-Plane uses Map-Requests with either the = SMR-bit set or the
P-bit set = supporting mapping updates and RLOC-probing. Indicating = P-bit set supporting mapping updates and = RLOC-probing. Indicating
that other = Data-Planes can use the same mechanisms or their own that other Data-Planes can use the same mechanisms = or their own
defined = mechanisms to achieve the same functionality. defined mechanisms to achieve the same = functionality.
=
B.23. Changes to = draft-ietf-lisp-rfc6833bis-01 B.24. Changes to = draft-ietf-lisp-rfc6833bis-01
=
o Posted = March 2017. o Posted March = 2017.
=
o Include = references to new RFCs published. o = Include references to new RFCs published.
=
o Remove = references to self. o Remove = references to self.
=
o Change = references from RFC6830 to RFC6830bis. = o Change references from RFC6830 to RFC6830bis.
=
o Add two new = action/reasons to a Map-Reply has posted to the LISP o Add two new action/reasons to a Map-Reply has = posted to the LISP
WG mailing = list. WG mailing list.
=
o In intro = section, add refernece to I-D.ietf-lisp-introduction. o In intro section, add refernece to = I-D.ietf-lisp-introduction.
=
o Removed = Open Issues section and references to "experimental". o Removed Open Issues section and references to = "experimental".
=
B.24. Changes to = draft-ietf-lisp-rfc6833bis-00 B.25. Changes to = draft-ietf-lisp-rfc6833bis-00
=
o Posted = December 2016. o Posted December = 2016.
=
o Created = working group document from draft-farinacci-lisp o Created working group document from = draft-farinacci-lisp
-rfc6833-00 = individual submission. No other changes made. -rfc6833-00 individual submission. No other = changes made.
=
B.25. Changes to = draft-farinacci-lisp-rfc6833bis-00 B.26. Changes to = draft-farinacci-lisp-rfc6833bis-00
=
o Posted = November 2016. o Posted November = 2016.
=
o This is the = initial draft to turn RFC 6833 into RFC 6833bis. o This is the initial draft to turn RFC 6833 into = RFC 6833bis.
=
o The = document name has changed from the "Locator/ID Separation = o The document name has changed from the = "Locator/ID Separation
Protocol = (LISP) Map-Server Interface" to the "Locator/ID Protocol (LISP) Map-Server Interface" to the = "Locator/ID
Separation = Protocol (LISP) Control-Plane". = Separation Protocol (LISP) Control-Plane".
=
o The = fundamental change was to move the Control-Plane messages from = o The fundamental change was to move the = Control-Plane messages from
 End of changes. 54 change blocks. 
142 lines changed or = deleted 179 lines changed or = added

This = html diff was produced by rfcdiff 1.47. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20 = --Apple-Mail=_F408CD70-817F-4F42-B3D7-BE22BDD7C94E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 4, 2019, at 10:27 AM, BRUNGARD, DEBORAH A = wrote: >=20 > Hi Dino, >=20 > Benjamin had sent to me to check on them as he saw them in nits. If = you run nits, you will see them. Probably a good idea to run nits - = there's a "MUST not" which needs to fixed also. >=20 > Thanks! > Deborah >=20 >=20 > -----Original Message----- > From: Dino Farinacci =20 > Sent: Monday, February 04, 2019 1:25 PM > To: BRUNGARD, DEBORAH A > Cc: Alvaro Retana ; lisp-chairs@ietf.org; The = IESG ; draft-ietf-lisp-rfc6833bis@ietf.org; lisp@ietf.org > Subject: Re: [lisp] Alvaro Retana's No Objection on = draft-ietf-lisp-rfc6833bis-23: (with COMMENT) >=20 >=20 >> Hi Dino, >>=20 >> Thanks =E2=80=93 Benjamin over the weekend caught a couple of = references which need to be updated via nits. I was just preparing an = email to you with the fixes. If you can, include these tweaks also: >=20 > I didn=E2=80=99t see any comments. Do you mean run IDnits or all the = comments below? >=20 > Dino >=20 >>=20 >> The IAB report (RFC4984) can be informative, no need to be normative. >>=20 >> RFC6071 on IPSec roadmap, nits (and me) can=E2=80=99t find it in the = document? It can removed. If for some reason want to keep, it can be = informative. >>=20 >> Nits has 5226 (IANA) as obsoleted, it should be updated to RFC8126 = (which you have listed in the informative). Delete 5226, and move 8126 = to the normative to replace 5226. >>=20 >> You have RFC2119 in informative. Usually this is also normative. = Also, RFC8174 needs to be now mentioned with RFC2119, add that in the = document and also list in the normative. >>=20 >> Thanks! >> Deborah >>=20 >> From: lisp On Behalf Of Dino Farinacci >> Sent: Monday, February 04, 2019 1:12 PM >> To: Alvaro Retana >> Cc: lisp-chairs@ietf.org; The IESG ;=20 >> draft-ietf-lisp-rfc6833bis@ietf.org; lisp@ietf.org >> Subject: Re: [lisp] Alvaro Retana's No Objection on=20 >> draft-ietf-lisp-rfc6833bis-23: (with COMMENT) >>=20 >> Here is a diff for -24 that incorporates the changes below and = Albert=E2=80=99s changes from Ben=E2=80=99s comments. I will submit = today. >>=20 >> Dino >>=20 >>=20 >>=20 >>> On Feb 4, 2019, at 9:10 AM, Alvaro Retana = wrote: >>>=20 >>> Alvaro Retana has entered the following ballot position for >>> draft-ietf-lisp-rfc6833bis-23: No Objection >>>=20 >>> When responding, please keep the subject line intact and reply to=20 >>> all email addresses included in the To and CC lines. (Feel free to=20= >>> cut this introductory paragraph, however.) >>>=20 >>>=20 >>> Please refer to=20 >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ie= >>> sg_statement_discuss-2Dcriteria.html&d=3DDwIFaQ&c=3DLFYZ-o9_HUMeMTSQic= vj >>> Ig&r=3D6UhGpW9lwi9dM7jYlxXD8w&m=3Dt_4mdnGN1QYvhWoBlVpBU33oceLF4fTMjo60= Je >>> sHXBk&s=3DtF8-EnL-7ZdQg9NZuH0W9N3ZnCTcr7zMcN4YkPZuSfY&e=3D >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.iet= >>> f.org_doc_draft-2Dietf-2Dlisp-2Drfc6833bis_&d=3DDwIFaQ&c=3DLFYZ-o9_HUM= eM >>> TSQicvjIg&r=3D6UhGpW9lwi9dM7jYlxXD8w&m=3Dt_4mdnGN1QYvhWoBlVpBU33oceLF4= fT >>> Mjo60JesHXBk&s=3DmPZHoYzYEp2s8Nnqi-_IExYI_3FkJo0QucA2w67CAok&e=3D >>>=20 >>>=20 >>>=20 >>> -------------------------------------------------------------------- >>> -- >>> COMMENT: >>> -------------------------------------------------------------------- >>> -- >>>=20 >>> (1) s/rfc8113/draft-ietf-lisp-rfc8113bis >>>=20 >>> (2) =C2=A75.1: "Values in the "Not Assigned" range can be assigned=20= >>> according to procedures in [RFC8126]." This sentence is out of=20 >>> place because it doesn't specify which procedure...and the action is=20= >>> already specified in rfc8113bis anyway. >>>=20 >>> (3) s/Not assigned/Unassigned To match what the registry says. >>>=20 >>>=20 >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail >> = man_listinfo_lisp&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3D6UhGpW9lwi9dM7= jY >> = lxXD8w&m=3Dt_4mdnGN1QYvhWoBlVpBU33oceLF4fTMjo60JesHXBk&s=3DwPj46XHTglwXmfH= >> SGvsFJsRPtOsy0GZjzyaygXL8Bmg&e=3D >=20 --Apple-Mail=_F408CD70-817F-4F42-B3D7-BE22BDD7C94E-- From nobody Mon Feb 4 19:09:21 2019 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E96126F72; Mon, 4 Feb 2019 19:09:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <154933615303.28660.9544451136070269834@ietfa.amsl.com> Date: Mon, 04 Feb 2019 19:09:13 -0800 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-rfc6833bis-24.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 03:09:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol WG of the IETF. Title : Locator/ID Separation Protocol (LISP) Control-Plane Authors : Vince Fuller Dino Farinacci Albert Cabellos Filename : draft-ietf-lisp-rfc6833bis-24.txt Pages : 62 Date : 2019-02-04 Abstract: This document describes the Control-Plane and Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two new types of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provides a simplified "front end" for one or more Endpoint ID to Routing Locator mapping databases. By using this Control-Plane service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) are not dependent on the details of mapping database systems, which facilitates modularity with different database designs. Since these devices implement the "edge" of the LISP Control-Plane infrastructure, connecting EID addressable nodes of a LISP site, their implementation and operational complexity reduces the overall cost and effort of deploying LISP. This document obsoletes RFC 6830 and RFC 6833. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-rfc6833bis-24 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6833bis-24 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6833bis-24 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 5 05:01:12 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3725713108B; Tue, 5 Feb 2019 05:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, MIME_QP_LONG_LINE=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 j5wGaf8v23gR; Tue, 5 Feb 2019 05:01:07 -0800 (PST) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 E0F52130F52; Tue, 5 Feb 2019 05:01:06 -0800 (PST) Received: by mail-wm1-x336.google.com with SMTP id m1so3541868wml.2; Tue, 05 Feb 2019 05:01:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:message-id :references:to; bh=ZpUDo3yBDc7HGFZMiAWMKA7F7hRfADn2vtDjc9cVZPk=; b=A5hBS75dfwaBMZ9kh0Xv3qG0thmKkKdcsVjUx2us+qIwc9wCXR+VApiOqbedBFQhUE UeTSdK1iL66ejOTEHHJaEQwceDooSyeN/LClJMnpiWajBWxnJjivNU7rVi4/HpwzOTHE 2a9XKlxf+sBObXnhWjQql7wCcHozb51TSWBoBxhMehDeFFrRjI3lW2LryDIs0qgqJQHF hM2nA8HJCCh0Uzl0LvV4NUhyMnRZOZThz8/CU30LsdnH/7dG2JY8c9JsR/2gL4ALmSNo 64MMXbVRTQhCF1/lfioSAt9LWKjBgW2VbJU/3CK54FsI1QzkX0M/6QOoJ6xV7HgoBMr5 3VvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:message-id:references:to; bh=ZpUDo3yBDc7HGFZMiAWMKA7F7hRfADn2vtDjc9cVZPk=; b=Ngd6FnneNO/UuNPYXB/Ms/EE0IjU7UWBLE7BjfaoUgUm5iHDmAhL4BCw/kfHZMwgZB ATgfKM33Uoo1j4CP9RSinjqYgg55os1qGVbw/eCYLxazE4WW4d71gfGka6We9H3d1d5g BTei5+uDH7nyn6yLhRx5fhwlzhSosAr/WRSuPNkjWcZmsOaDfsLQ7Tnik2PvIQmrBRA+ Y8VUhz5PyTiHVe6Sfit1n6E98i4woVYE6aY05rCjaSmVVjujKIBiq1HHb7HSRKh5K/sW Ew9NKuC48SEhjeUvYHVdHMop6Q8/6hZ5TB3smAzBugCNJajbLjRNheQjJdoY6WdZajF1 xNMw== X-Gm-Message-State: AHQUAubepR23LDu7XEI11D81moU+0nRKFpDulfBkTSfMoSqtw469HDqQ BNVwytT/FxW28jea7oTyNA== X-Google-Smtp-Source: AHgI3Ibrs75id2JlEX+8JA19PuMiIpy5zzpW38zrYP7Zz6f3YMHczkbBSDaIzpgj7h0MoPuFGmUABw== X-Received: by 2002:a1c:2e0c:: with SMTP id u12mr3673843wmu.81.1549371665268; Tue, 05 Feb 2019 05:01:05 -0800 (PST) Received: from [10.24.77.185] ([80.246.140.236]) by smtp.gmail.com with ESMTPSA id t4sm18205548wrb.64.2019.02.05.05.01.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Feb 2019 05:01:03 -0800 (PST) From: Sharon Content-Type: multipart/alternative; boundary=Apple-Mail-9E33C71B-EABB-4151-8AD5-1F2D712BBDEB Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Tue, 5 Feb 2019 15:01:02 +0200 Message-Id: References: <154935838934.32279.15114530088216516753.idtracker@ietfa.amsl.com> To: lisp@ietf.org, luigi.iannone@telecom-paristech.fr, lisp-chairs@ietf.org X-Mailer: iPhone Mail (16C101) Archived-At: Subject: [lisp] Fwd: New Version Notification for draft-barkai-lisp-nexagon-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 13:01:10 -0000 --Apple-Mail-9E33C71B-EABB-4151-8AD5-1F2D712BBDEB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear lispers,=20 In recent years been discussing - with Dino, Fabio, Albert, Alberto.. - the u= se of lisp to support a serverless-network design pattern. In this pattern the EIDs are typically mobile highly functional clients, com= municating not with any specific server nor peer-to-peer but rather with Sta= tes embedded in the network. =E2=80=9CTalking=E2=80=9D to a state typically invokes a virtual network fun= ction at the state RLOC wrapping it with proper access methods. During past months in Fermi then Nexar our team has brought a specific use c= ase as above to production. An automotive application which will greatly ben= efit from standardization - since it is inherently multi vendor. In this use case in-network states represent the geo-spatial hexagon tiles f= orming our roads - lanes, shoulders, junctions. The network hexagons are indexed using H3. Moving EIDs communicating with moving HIDs invoke publish and subscribe meth= ods at the RLOC. Publish when vision&sensory clients identify hazards snappe= d to small-hexagon-grid. Subscribe when clients wish to be aware of beyond l= ine-of-site spotted hazards, snapped to a larger area hexagon grid. Enclosed initial draft for the use-case. Interested parties include - car makers, adas-cam makers, municipalities-hig= hwayAuth-gov, navigation-mapping vendors, smart-infrastructure/lidar/active-= led vendors. Hope to present for discussion next ietf meeting, and requesting a 10-15 min= slot. --szb Cell: +972.53.2470068 WhatsApp: +1.650.492.0794 Begin forwarded message: > From: internet-drafts@ietf.org > Date: February 5, 2019 at 11:19:49 AM GMT+2 > To: "Alberto Rodriguez-Natal" , "Ohad Serfaty" , "Fabio Maino" , "Albert Cabellos-Aparicio" , "Sharon Barkai" > Subject: New Version Notification for draft-barkai-lisp-nexagon-00.txt >=20 >=20 > A new version of I-D, draft-barkai-lisp-nexagon-00.txt > has been successfully submitted by Sharon Barkai and posted to the > IETF repository. >=20 > Name: draft-barkai-lisp-nexagon > Revision: 00 > Title: Distributed Geo-Spatial LISP Blackboard for Automotive > Document date: 2019-02-04 > Group: Individual Submission > Pages: 7 > URL: https://www.ietf.org/internet-drafts/draft-barkai-lisp-nex= agon-00.txt > Status: https://datatracker.ietf.org/doc/draft-barkai-lisp-nexagon= / > Htmlized: https://tools.ietf.org/html/draft-barkai-lisp-nexagon-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-barkai-lisp-ne= xagon >=20 >=20 > Abstract: > This document specifies the use of LISP Blackboard for distributed > Geo-Spatial Publish/Subscribe automotive applications. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail-9E33C71B-EABB-4151-8AD5-1F2D712BBDEB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear lispers, 

In r= ecent years been discussing - with Dino, Fabio, Albert, Alberto.. - the use o= f lisp to support a serverless-network design pattern.

<= div>In this pattern the EIDs are typically mobile highly functional clients,= communicating not with any specific server nor peer-to-peer but rather with= States embedded in the network.

=E2=80=9CTalking=E2= =80=9D to a state typically invokes a virtual network function at the state R= LOC wrapping it with proper access methods.

During p= ast months in Fermi then Nexar our team has brought a specific use case as a= bove to production. An automotive application which will greatly benefit fro= m standardization - since it is inherently multi vendor.

In this use case in-network states represent the geo-spatial hexagon t= iles forming our roads - lanes, shoulders, junctions.
The network h= exagons are indexed using H3.

Moving EIDs communica= ting with moving HIDs invoke publish and subscribe methods at the RLOC. Publ= ish when vision&sensory clients identify hazards snapped to small-hexago= n-grid. Subscribe when clients wish to be aware of beyond line-of-site spott= ed hazards, snapped to a larger area hexagon grid.

= Enclosed initial draft for the use-case.
Interested parties includ= e - car makers, adas-cam makers, municipalities-highwayAuth-gov, navigation-= mapping vendors, smart-infrastructure/lidar/active-led vendors.
Hope to present for discussion next ietf meeting, and requestin= g a 10-15 min slot.

--szb
Cell: +972.53.2470068
WhatsApp: +1.650.492.0794

Begin forwarded message:

From: internet-drafts@ietf.org
Date: February 5, 2019 at 1= 1:19:49 AM GMT+2
To: "Alberto Rodriguez-Natal" <natal@cisco.com>, "Ohad Serfaty" <ohad@getnexar.com>, "Fabio Maino" <fmaino@cisco.com>, "Albert Cabellos-Apa= ricio" <acabello@ac.upc.edu>= ;, "Sharon Barkai" <sharon.= barkai@getnexar.com>
Subject: New Version Notification f= or draft-barkai-lisp-nexagon-00.txt


A new version of I-D= , draft-barkai-lisp-nexagon-00.txt
has been successfully sub= mitted by Sharon Barkai and posted to the
IETF repository.

Name:        draft-barka= i-lisp-nexagon
Revision:    00
Tit= le:        Distributed Geo-Spatial LISP Blackboard for A= utomotive
Document date:    2019-02-04
<= span>Group:        Individual Submission
Pages:        7
URL:    =         https://www.ietf.org/i= nternet-drafts/draft-barkai-lisp-nexagon-00.txt
Status: &= nbsp;       https://datatracker.ietf.org/doc/= draft-barkai-lisp-nexagon/
Htmlized:    &= nbsp;  https://tools.ietf.org/html/draft-barkai-lisp-nexagon-00
Htmlized:       https://datatracker= .ietf.org/doc/html/draft-barkai-lisp-nexagon

=
Abstract:
  This document s= pecifies the use of LISP Blackboard for distributed
 &= nbsp;Geo-Spatial Publish/Subscribe automotive applications.
=



Please n= ote that it may take a couple of minutes from the time of submission<= br>until the htmlized version and diff are available at tools.ietf.org.

The= IETF Secretariat

= --Apple-Mail-9E33C71B-EABB-4151-8AD5-1F2D712BBDEB-- From nobody Tue Feb 5 07:40:14 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA68130E0A; Tue, 5 Feb 2019 07:40:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 admL14twr-4T; Tue, 5 Feb 2019 07:40:04 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 DBD3C12DF71; Tue, 5 Feb 2019 07:40:03 -0800 (PST) Received: from 200116b82c34e80024f4e932ebc9f4d6.dip.versatel-1u1.de ([2001:16b8:2c34:e800:24f4:e932:ebc9:f4d6]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1gr2pN-0004Ye-Em; Tue, 05 Feb 2019 16:40:01 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <2FEB555F-16A5-4875-93ED-D14BFEEF503A@gigix.net> Date: Tue, 5 Feb 2019 16:39:59 +0100 Cc: Dino Farinacci , The IESG , lisp-chairs@ietf.org, "lisp@ietf.org list" , draft-ietf-lisp-rfc6830bis@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <153667905625.16761.12157659372502604927.idtracker@ietfa.amsl.com> <7DEBCA24-9D55-4325-85AA-48AB3FAAB91D@gmail.com> <0201F06C-DA9E-445A-A995-54BA805B595C@kuehlewind.net> <5EC21C57-D217-48A9-AFD0-24710299CF7F@kuehlewind.net> <5A3C4B1F-EA31-4698-96F4-915A77400A56@gmail.com> <2CAF25CC-01EE-49D4-B970-F8EFB24940A8@kuehlewind.net> <5F9D8F39-871D-4A96-9C0A-7BACD2ABB1F7@gmail.com> <2DC6D38E-C46B-4D38-B093-B88720BCD550@kuehlewind.net> <0BE5C929-D2FA-4786-9F5E-0A93E7700880@gmail.com> <11FBAC13-2859-4778-84CA-B546EB669727@kuehlewind.net> <2FEB555F-16A5-4875-93ED-D14BFEEF503A@gigix.net> To: Luigi Iannone X-Mailer: Apple Mail (2.3445.9.1) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1549381203;86963dd1; X-HE-SMSGID: 1gr2pN-0004Ye-Em Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 15:40:06 -0000 Hi Luigi, I just realized that I never replied to this mail. The change below is = okay, however, it did not make it into the current version of the draft = and therefore I cannot clear my discuss. Please also note that the text = on decapsulation is basically in the same section twice. I recommend to = remove it once and adapt the other one accordingly. Further, inline with RFC6040, you would also need to align the = re-encapsulation part. Currently the text says: "Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped = outer header to the new outer header.=E2=80=9C Usually re-encapsulation is performed by doing de-encapsulation and then = encapsulation again. The difference here would be, that if e.g. the = inner header is not-ETC but the tunnel changes the bits to ETC0 or ETC1 = this error is not further propagated, indicating ECN support where there = is not ECN support. Thanks, Mirja > Am 26.09.2018 um 17:27 schrieb Luigi Iannone : >=20 > Hi Mirja, >=20 > trying to follow up on this issue. >=20 > The ECN text for encapsulation is currently: >=20 > The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 > of the IPv6 'Traffic Class' field) requires special treatment in > order to avoid discarding indications of congestion [ > RFC3168 > ]. > ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner > header to the outer header. Re-encapsulation MUST copy the = 2-bit >=20 > 'ECN' field from the stripped outer header to the new outer >=20 > header. >=20 > Can we keep it as it is (updating the reference to 6040)? >=20 > The text for decapsulation is: >=20 > CURRENT: > The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 > of the IPv6 'Traffic Class' field) requires special treatment in > order to avoid discarding indications of congestion [ > RFC6040 > ]. If > the 'ECN' field contains a congestion indication codepoint (the > value is '11', the Congestion Experienced (CE) codepoint), then > ETR decapsulation MUST copy the 2-bit 'ECN' field from the > stripped outer header to the surviving inner header that is used > to forward the packet beyond the ETR. These requirements = preserve > CE indications when a packet that uses ECN traverses a LISP = tunnel > and becomes marked with a CE indication due to congestion = between > the tunnel endpoints. Implementations exist that copy the 'ECN' > field from the outer header to the inner header even though > [ > RFC6040 > ] does not recommend this behavior. It is RECOMMENDED > that implementations change to support the behavior in [ > RFC6040 > ]. >=20 >=20 > Which I suggest we shrink to: >=20 > NEW: >=20 > The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 > of the IPv6 'Traffic Class' field) requires special treatment in > order to avoid discarding indications of congestion [ > RFC6040].=20 > Note that implementations exist that copy the 'ECN' > field from the outer header to the inner header even though > [ > RFC6040 > ] does not recommend such behavior. It is RECOMMENDED > that implementations change, so to support the specifications in = [ > RFC6040 > ]. >=20 >=20 >=20 > The text above clearly states that implementations should be conform = to 6040.=20 >=20 > Is it what you were looking for? >=20 > Or am I missing something? >=20 > Ciao >=20 > L. >=20 > =20 >=20 >=20 >=20 >=20 >> On 24 Sep 2018, at 19:34, Dino Farinacci wrote: >>=20 >> Well, the implementations are out and working. And we said in the = latest updates to consider using RFC6040. So not sure we can do much = more than that. >>=20 >> Dino >>=20 >>> On Sep 24, 2018, at 5:52 AM, Mirja Kuehlewind (IETF) = wrote: >>>=20 >>> Because they don=E2=80=99t follow RFC6040 and therefore we do = something different in some corner cases. >>>=20 >>>=20 >>>=20 >>>> Am 22.09.2018 um 06:52 schrieb Dino Farinacci = : >>>>=20 >>>>> However, I totally disagree with your comment on providing details = that are not implemented. If they are not implemented correctly, it = might even be more important to spell them out in this document, so = implementors have chance to update their (future) implementation to do = the correct thing. Having deployed implementations that are non = standard-conform always happens and in this case it is probably not = specifically problematic as it doesn=E2=80=99t impact interoperability. = However, it is important though that the spec is correct. >>>>=20 >>>> And why do you think they are implemented incorrectly?=20 >>>>=20 >>>> Dino >>>>=20 >>>=20 >>=20 >=20 From nobody Tue Feb 5 09:16:02 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB81124BAA; Tue, 5 Feb 2019 09:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 c6wE3463Zhm9; Tue, 5 Feb 2019 09:15:50 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 5AE8E130E92; Tue, 5 Feb 2019 09:15:50 -0800 (PST) Received: from 200116b82c34e80024f4e932ebc9f4d6.dip.versatel-1u1.de ([2001:16b8:2c34:e800:24f4:e932:ebc9:f4d6]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1gr4K3-0003GV-No; Tue, 05 Feb 2019 18:15:47 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <0D9A60A2-FE18-4AF1-8A8E-0C6C742CF4F6@kuehlewind.net> Date: Tue, 5 Feb 2019 18:15:45 +0100 Cc: lisp-chairs@ietf.org, "lisp@ietf.org list" , The IESG , Luigi Iannone , Colin Perkins , draft-ietf-lisp-rfc6833bis@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2DB533A5-5110-482C-A005-CFF305CB77C6@kuehlewind.net> References: <153667812809.16741.10796738054406466412.idtracker@ietfa.amsl.com> <9D08CA59-8AC4-4866-944E-98553C37E547@gmail.com> <9086A458-31C0-4EB2-BC5B-D9CB7B22469E@kuehlewind.net> <0D9A60A2-FE18-4AF1-8A8E-0C6C742CF4F6@kuehlewind.net> To: Dino Farinacci X-Mailer: Apple Mail (2.3445.9.1) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1549386950;fcf80da1; X-HE-SMSGID: 1gr4K3-0003GV-No Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6833bis-13=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 17:15:54 -0000 Hi Dino, catching up from here, because I think I never got a reply from you. = Please see below. > Am 18.09.2018 um 13:05 schrieb Mirja Kuehlewind (IETF) = : >=20 > Hi Dino, >=20 > please see below. >=20 >> Am 13.09.2018 um 23:46 schrieb Dino Farinacci : >>=20 >> I have a new diff file for -15 of 6833bis. I have included changes = from your emails and from Colin=E2=80=99s. See my responses inline. I = have trimmed a bit of text to hopefully make it more readable for = others. >>=20 >> I will only submit the new revision if you agree with the changes and = there are no objections from the LISP working group. Thanks in = advance. >>=20 >>>>>=20 >>>> The multiple EID-record encoding is already spec=E2=80=99ed and is = in the protocol. And since Map-Requests are triggered by packet arrival = or network management tools, they tend to be sent for a single EID. What = is for further study is if a ITR would want the entire map-cache, so = would it request a set of aggregates and would a replier return all more = specifics for the aggregates requested. >>>=20 >>> I guess this sentence should be revised then. >>=20 >> Fixed. >=20 > The sentence still talked about =E2=80=9Efuture version of the = protocol=E2=80=9C. Is that still necessary?=20 The sentence is still there. Please fix. >=20 >>=20 >>>=20 >>>>=20 >>>>> Further given there is no new version, I wonder if the changes as = outlined in >>>>> section 10 are all backward-compatible? Especially for the = introduction of the >>>>> Message-Notify-Ack message, I guess there is no problem if a = server sends it, >>>>> however, as the sender of the Message-Notify message might not = know if the >>>>> other end supports sending of the Message-Notify-Ack it can't rely = on it. This >>>>> should be further discussed in the doc! Or is there another = strategy to achieve >>>>> backward compatibility? >>>>=20 >>>> The Map-Notify-Ack has been there since day-1 in implementations. = This is just IETF catching up. And it took over 5 years. So we really = don=E2=80=99t have a compatibility situation. And didn=E2=80=99t want to = create one in the specifications. So consider it a day 1, version 1 = message. It really wasn=E2=80=99t added later. >>>=20 >>> This should be stated in section 18. >>=20 >> Done. >=20 > I would specifically state here that for that reason no interop = problems are expected. This is okay but could be more explicit. >=20 >>=20 >>>=20 >>>>=20 >>>> And big part of this push for standardization is to have the specs = =E2=80=9Ccatch up=E2=80=9D with the implementations. The implementations = are way further ahead than the specs. >>>>=20 >>>>> 2) Size and MTU >>>>>=20 >>>>> As outlined in the TSV-ART review (Thanks Colin!) this document = does not >>>>> discuss fragmentation or Path MTU discovery. RFC8085 recommends to = either >>>>=20 >>>>> perform Path MTU discovery or limit the message to 576 bytes for = IPv4 or 1280 >>>>> bytes for IPv6 (minus any static header). As this seems to be an = appropriate >>>>> size for LISP messages, I would recommend this approach. Relying = on IP >>>>> fragmentation (as indicated in the reply to the TSV-ART review) is = not >>>>> recommended by RFC8085 as this would lead to IP packet without a = UDP header, in >>>>> the case of LISP, which can cause problem and loss when NATs are = involved. In >>>>> any case the chosen approach needs to be further discussed in the = doc. >>>>>=20 >>>>=20 >>>> This is a data-plane feature so it is discussed in 6830bis and = RFC6830. >>>=20 >>> This is a different issue. The control plane protocol as specified = in this doc also needs to consider fragmentation and MTU. Please read = RFC8085 accordingly. >>=20 >> I have added text per Colin=E2=80=99s comments. >=20 > Just pointing to RFC8085 is not enough. This spec must specify that = messages MUST not exceed the MTU and fragmentation should not be used. = And further either recommend to use MTU discovery or just restrict the = message size according to the recommendations in RFC8085. I would = recommend to just do the later for simplicity. This is still try. Just point to RFC8085 is not sufficient. RFC8085 = gives recommendations. Each protocol spec must require the respective = approach that is most appropriate for that protocol to recommend = implementing. >=20 >>=20 >>>>=20 >>>>> 3) Rate-limiting and congestion control >>>>>=20 >>>>> Sec 5.3: "Map-Requests MUST be rate-limited. It is RECOMMENDED = that a Map- >>>>> Request for the same EID-Prefix be sent no more than once per = second." >>>>> As already noted by the TSV-ART review (Thanks Colin!), RFC8085 = actually >>>>> recommends to not send more the one packet per 3 seconds, and that = is a >>>>> restriction for all traffic not on a per-receiver base, or = implement congestion >>>>> control. This limit is meant to not only protect the receiver but = also the >>>>> network from overloading. Why do you use a smaller interval here? = Also if >>>>> (appropriate) rate limiting is used, this should either be a MUST = or more >>>>> explanation when it is okay to use a smaller rate limit should be = provided. >>>>> However, after all, I don't think you those the right approach = here for rate >>>>> limiting. A Map-Request is always expected to be followed by some = reply. For >>>>> these kind of communication pattern, RFC8085 recommends to limit = the number of >>>>> outstanding requests to 1 (see sec 3.1.1 of RFC8085 recommending = one packet per >>>>> RTT), also for all traffic and not only per receiver. However, = this would also >>>>> require to implement some simple mechanism to detect a message as = lost (see >>>>> also further below in point 4). >>>>=20 >>>> We have referenced RFC8085 in the too be published -14 version of = 6833bis. >>>=20 >>> I didn=E2=80=99t find a reference in -14. However a reference is not = enough, the specified behavior is not appropriate and needs to change. = If you need further help, please consult the respective transport = experts, e.g. Gorry Fairhurst who is an author of RFC8085. >>=20 >> I have added text. We have a smaller interval because 3 seconds is = way too long (arguably 1 seond is too) to populate a map-cache. Note = during that time, packets that arrive to the ITR are discarded. So this = occurs if just one Map-Request is lost. >=20 > As I said, just providing a pointer to RFC8085 is not sufficient.=20 Again, still true! >=20 >>=20 >>>=20 >>>>=20 >>>>> Similarly I'm not sure about the intent of this requirement in = section 5.5: >>>>> "Map-Replies SHOULD be sent for an EID-Prefix no more often than = once >>>>> per second to the same requesting router. " >>>>> My understanding is that Replies are only sent when a request is = received. Why >>>>> is this additional rate limit needed? Again if used it should be 3 = seconds for >>>>> all traffic to be inline with RFC8085. Also again, why is that not = a MUST? >>>>> Further recommendation are needed here. >>>>=20 >>>> Because the source is a bad-actor and sending new Map-Requests = (with a new nonce). >>>=20 >>> Not sure if that is the right choice because it may interact badly = with loss detection. However, as I said the specified behavior need to = be refined at various places in the doc. >>=20 >> Well there is not many choices. >=20 > You can choose to not have this rate limiting but limit the total = number of request per requesting router per time interval. That would = trigger a reply immediately but still limit the total load in case of = =E2=80=9Ebad-actors=E2=80=9C. There is still further guidance missing here. >=20 >>=20 >>>=20 >>>>=20 >>>>> Further section 6.1 say "Both the SMR sender and the Map-Request = responder MUST >>>>> rate-limit >>>>> these messages. Rate-limiting can be implemented as a global = rate- >>>>> limiter or one rate-limiter per SMR destination." >>>>> This seems to be the same rate limit as mention above, or not...? = It would >>>>> probably make sense to rate limit the SMR even further. Please = clarify and >>>>> provide more guidance, e.g. what should the value of a potential = additional >>>>> rate limit for SMR be? >>>>=20 >>>> Some of this machinery is left to the implementor. But we have = published some map-cache management guidelines in the lisp-threat RFC. >>>=20 >>> I think clear default guidance must be given in this document. My = main problem is that the guidance here is not clear (in relation to = other rate limits). >>=20 >> I have tightened it up. >=20 > I don=E2=80=99t think I saw any change in the diff you=E2=80=99ve = attached. Please explain what you did. Still don=E2=80=99t see any changes=E2=80=A6 >=20 >>=20 >>>>=20 >>>>> Respectively the following sentence in section 6.1 is also = unclear: >>>>> "The remote ITR MUST rate-limit the Map-Request until it gets a = Map-Reply" >>>>> Why is the rate-limit as currently proposed depend on the fact if = a Map-Reply >>>>> is received? Is the ITR supposed to retransmit the Map-Request=E2=80= =A6? >>>>=20 >>>> If you are not getting answers to your Map-Requests because of = packet loss or MITM, sending them faster is not going to get you a = Map-Reply. >>>=20 >>> If you detect loss, you should send slower not faster for congestion = collapse avoidance. >>=20 >> That was my point. >=20 > Should should instead specify a similar loss detection and = retransmission mechanism for Map-Request as now done for Map-Notify. The = rate-limit alone is not helpful. This is also missing. >=20 >>=20 >>>=20 >>>>=20 >>>>> And finally the Map-Register, Map-Notify and Map-Notify-Ack = messages does not >>>>> seem to have any rate-limits. Recommendations inline with RFC8085 = should be >>>>> provided for the total traffic and not only for a few message = types. Again, >>>>> Map-Notify and Map-Notify-Ack messages should be send only once = per RTT as >>>>> there is a feedback mechanism. >>>>=20 >>>> We have added that in -14. >>>>=20 >>>>> For Map-Register sec 8.2 say: "Map-Register messages are sent = periodically from >>>>> an ETR to a Map- >>>>> Server with a suggested interval between messages of one minute." >>>>> However, this a rather a low bound than an upper bound. A required = (MUST) rate >>>>> limit is still needed. >>>>=20 >>>> That is not rate-limiting to avoid message reduction. It is a = soft-state way of keeping registration state alive in the map-server(s). >>>=20 >>> That fine but you also need to specify normatively an upper bound. >>=20 >> The recommended upper bound is 1 minute. If you are not getting your = point across, please be more specific. >=20 > Then you have to say =E2=80=9EMUST NOT send more than one message per = minutes=E2=80=9C. The current text just gives a recommendation what a go = value might be but does not specify an actually limit. This is still outstanding. >=20 >>=20 >>>=20 >>>>=20 >>>>> 4) Loss detection and retransmission >>>>>=20 >>>>> As also mention by the TSV-ART review (Once more thanks to = Colin!), this spec >>>>> has an ACK mechanism for Map-Requests and now also for Map-Notify, = however, it >>>>=20 >>>> And Map-Notify are acks to Map-Registers when requested. >>>>=20 >>>>> does not specify what to do if the ACK is not received (loss = detection and >>>>> retransmission scheduling). This makes the spec incomplete and = needs to be >>>>> further specified in the doc (and also has a relation to the point = 3 above of >>>>> course). >>>>=20 >>>> We focus on why a Map-Request is being generated (to populate the = map-cache) and a Map-Reply not only provides information to be put in = the map-cache, but acts as an ackl now. If the Map-Request nonce is = being replied with a Map-Reply with the same nonce, Map-Requests no = longer need to be sent and the requestor is happy with the result (and = hence it was reliable). >>>=20 >>> That all fine. However, you don=E2=80=99t specify the behavior if = the ack is not received. How/when is the message assumed to be lost? = When should it be retransmitted? How often? When to give up? Should = exponential backoff be used? This whole part s completely missing in the = spec. >>=20 >> Have added text. >=20 > Thanks! >=20 > Not sure I understand the first sentence: >=20 > =E2=80=9EA sender of an unsolicited Map-Notify message (one that is = not used=09 > as an acknowledgment to a Map-Register message) will follow = the=09 > Congestion Control And Relability Guideline sections of = [RFC8085].=E2=80=9C >=20 > The rest of the text is fine and gives a good spec. I think it is okay = to mention that that spec is inline with RFC8085 but other than that = I=E2=80=99m not sure what this first sentence is telling me=E2=80=A6? First sentence is still there and confusing from my point of view. >=20 >=20 > And also the last sentence is not fully clear: >=20 > "After this time, the Map-=09 > Notify sender can only get the RLOC-set change by later = querying the=09 > mapping system or by RLOC-probing one of the RLOCs of the = existing=09 > cached RLOC-set to get the new RLOC-set.=E2=80=9C >=20 > I don=E2=80=99t think there should be an attempt to later try again. = Probably the system should log or notify an error instead. However, if = it makes sense to try later again you have to specify what later means = (hours, days?) and how often it should try again before it finally gives = up and logs an error. Can you please further clarify this? >=20 >>=20 >>>=20 >>>>> 2) I find the security requirements in this doc very unsatisfying. = Most >>>>> important the doc requires the support of authentication mechanism = but not the >>>>> use of it. I would like to see more clear MUST requirements here. = Further, >>>>> today and at this stage of the protocol (moving from exp to PS) I = find it not >>>>> acceptable anymore to have certain security feature as optional = and outsourced >>>>> into a different work-in-process draft. However, I leave further = discussion to >>>>> the SEC ADs. >>>>=20 >>>> Can you cite where this is a problem. Are you saying we are not = supplying enough MUST text? >>>=20 >>> In section 8.2 a few SHOULDs are used but no discussion about when = it would be appropriate to not follow these SHOULDs. Further these = SHOULDs mainly just say what should be implemented and provided, however = there is no normative language that these endpoint SHOULD/MUST actually = be authenticated or that the configured EID-Prefixes list MUST be = enforced. >>>=20 >>>>=20 >>>>> Clarification questions: >>>>> 1) Sec 5.3.: >>>>> "For the initial case, the destination IP >>>>> address used for the Map-Request is the data packet's destination >>>>> address (i.e., the destination EID) that had a mapping cache = lookup >>>>> failure." >>>>> Does that mean that the Map-Request needs to use the IPv4 or IPv6 = depending on >>>>> the IP version used by the initial message from the EID. Is that = always the >>>>> case or just for this initial message? I would assume that for all = other cases >>>>> this is actually independent...? Because otherwise there would be = a constraint >>>>> on what needs to be requested. I would like t see further = clarification about >>>>> this in the doc. >>>>=20 >>>> No it doesn=E2=80=99t. It depends on the address-family of the = map-resolver. And that is configured. >>>=20 >>> Okay, if the map-resolver is IPv6 and I receive an IPv4 packet, how = can I copy the "the data packet's destination address=E2=80=9C which is = IPv4 in to the "destination IP address used for the Map-Request=E2=80=9C = which is IPv6? Or even worse, the other way around. >>=20 >> Because a Map-Request going to the mapping system is =E2=80=9CECM=E2=80= =99ed=E2=80=9D =E2=80=9CEncapsulated Control Message=E2=80=9D with the = header address-family as the EID being requested. >=20 > You say that if the EID send e.g. an IPv4 message it also has to be = encapsulated in IPv4? That is stated nowhere. If that is the intention = that has to be specified. However, I don=E2=80=99t really see why this = restriction needs to exists=E2=80=A6? This seems still to be missing. >=20 >>=20 >>>=20 >>>>=20 >>>>> 2) In section 5.3: "The ITR MAY include all locally >>>>> configured Locators in this list or just provide one locator = address >>>>> from each address family it supports." >>>>> Would it make sense to include a SHOULD requirement to at least = the address >>>>> family that is used to send the Request is included (to increase = chance to >>>>> enable a communication/get a reply)=E2=80=A6? >>>>=20 >>>> But all address-families are used all the time. And in some ITRs, = usually there is no IPv6 at the edge.=20 >>>=20 >>> What? You say all address families are used all the time but not in = some ITRs=E2=80=A6? I don=E2=80=99t understand what you want to say. = However, if e.g. an IPv4 packet is received and processed, it probably = doesn=E2=80=99t make sense to only include the IPv6 locator address (and = not the IPv4 locator address), especially as it is unknown if the ITR = support IPV6 (while it has been proven to support IPv4). Currently the = spec however would allow that. I=E2=80=99m saying it should to make sure = there is no unnecessary failure case her. >>=20 >> RLOCs for an xTR can be a collection of IPv4 and IPv6 addresses. They = are tested by remote ITRs to see if they are reachable. When they are, = they may be used. When they are not, no packets get encapsulated to = those RLOCs. >>=20 >> The Routing Locator Reachability section explains this. >=20 > This is all understood. I=E2=80=99m still wondering if there should be = more normative recommendations which locator addresses should be = included.=20 Still open I guess. >=20 >>=20 >>>=20 >>>>=20 >>>>> 3) Sec 5.4: "If all Weights for a Locator-Set are equal, >>>>> the receiver of the Map-Reply will decide how to load-split the >>>>> traffic. " >>>>> Shouldn't the receiver in this case split the traffic equally? = Otherwise how >>>>> would you signal that the traffic should be split equally? Maybe = use all zero >>>>> instead to let the receiver decide=E2=80=A6? >>>>=20 >>>> It means the ITR will load-split according to hashing. Versus if = the priorities are not equal, it is the ETR deciding how packets ingress = the LISP site. >>>=20 >>> This is not what the text says. Please clarify in the doc. >>=20 >> It says it in RFC6830bis since this decision is done by the = data-plane. >=20 > I still think the text in this doc is not correct. This is still seems to be the case. >=20 >>=20 >>>=20 >>>>=20 >>>>> 4) sec 6.1: "When an ITR receives an SMR-based Map-Request for = which it does not >>>>> have a cached mapping for the EID in the SMR message, it may not = send >>>>> an SMR-invoked Map-Request." >>>>> I guess this should be normative and probably also a MUST NOT or = at least >>>>> SHOULD NOT. >>>>=20 >>>> Yes, I changed to SHOULD NOT. Good catch. Don=E2=80=99t want to = make it a MUST NOT because both sides could be mobile and the remote = side may need to populate its map-cache. That would allow less packet = loss if we keep it SHOULD NOT versus MUST NOT. >>=20 >> While trying to change it, I noticed its already there: >>=20 >> When an ITR receives an SMR-based Map-Request for = =20 >> which it does not have a cached mapping for the EID in = =20 >>>>>> the SMR message, it SHOULD NOT send an SMR-invoked = =20 >> Map-Request. This scenario can occur when an ETR sends = =20 >> SMR messages to all Locators in the Locator-Set it has = =20 >> stored in its Map-Cache but the remote ITRs that receive the = =20 >> SMR may not be sending packets to the site. There is no = =20 >> point in updating the ITRs until they need to send, in = =20 >> which case they will send Map-Requests to obtain a = =20 >> Map-Cache entry. >=20 > Good. Thanks! I guess that was changed based on someone else comment = already. >=20 >>=20 >>>>=20 >>>>> 6) Section 8.2 says: "Note that the Map-Notify message >>>>> is sent to UDP destination port 4342, not to the source port >>>>> specified in the original Map-Register message." >>>>> Actually why is that? >>>>=20 >>>> cisco interperability. >>>=20 >>> I would expect to still see more reasoning in the doc. >>=20 >> Sorry, I was wrong in my reply. I read Map-Reply. For Map-Registers = this is normal behavior that a request is sent to a well-known port and = a reply is sent *from* the well known port. >=20 > Okay, then I still don=E2=80=99t understand WHY this is done? Would still be nice to add some reasoning. Mirja >=20 > Mirja >=20 >=20 >>=20 >> Thanks again for all the effort, >> Dino >>=20 >> >>=20 >=20 From nobody Tue Feb 5 18:22:04 2019 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BB1126C7E; Tue, 5 Feb 2019 18:21:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, ggx@gigix.net, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154941971479.32132.7227582520612116720.idtracker@ietfa.amsl.com> Date: Tue, 05 Feb 2019 18:21:54 -0800 Archived-At: Subject: [lisp] Warren Kumari's Discuss on draft-ietf-lisp-rfc6830bis-26: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 02:21:55 -0000 Warren Kumari has entered the following ballot position for draft-ietf-lisp-rfc6830bis-26: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I read much of this on a plane while overtired, so it is entirely possible / probable that I've completely misunderstood something(s) obvious. Many of the below are probably simple to address, and either I simply need to be educated, or just there needs to be a bit more text / detail provided. 1: "3. The ITR sends a LISP Map-Request as specified in [I-D.ietf-lisp-rfc6833bis]. Map-Requests SHOULD be rate-limited." What does the ITR do with the packet while waiting for the Map-Request to complete? Must it buffer the packets or can it discard them? If the former, for how long must it buffer? When you say "SHOULD be rate-limited", can you provide guidance on rates? 1 request per second? 1 million per second? Is this rate-limit per destination or per device? Apologies if this is clearly stated in RFC6833(bis) - I only skimmed it, and didn't see an answer there. 2: "6. ... Note that the Map-Cache is an on-demand cache. An ITR will manage its Map-Cache in such a way that optimizes for its resource constraints." Presumably I could cause this cache to thrash / overflow by looking at the RLOC database, and choosing EIDs to send traffic to which all require different cache entries, causing the cache to overflow (or, at least, causing maximum cache pressure). This seems like an ideal DoS vector. It seems that there should be more guidance provided on how to size the Map-Cache / the expected order of the cache size, even if it is ultimately an implementation issue (e.g: is a Map-Cache of 100 entries OK for an ITR? or should it be O(1000)? Or roughly size(database)/2? Having multiple devices with small caches, and a bot which does the above seems like a global risk). I'm quite confused by much of the MTU / Fragmentation stuff -- I did read the documents on a plane after not getting much sleep, and so it is entirely possible / probable that I'm just being stupid, but there are bits which don't seem to make sense to me. 3: "2. Define L to be the size, in octets, of the maximum-sized packet an ITR can send to an ETR without the need for the ITR or any intermediate routers to fragment the packet." How do I know what L is? The document "RECOMMENDS that L be defined as 1500" -- but 1500 isn't universally true (if it were, we would never have to do Path MTU). What happens when the *actual* MTU on the path is e.g 1476 because there is a tunnel on the path? The text also mentions "which is less than the ITR’s estimate of the path MTU between the ITR and its correspondent ETR" - this implies that the ITR is tracking / estimating the MTU, which a: doesn't align with the rest of the text, or b: sounds like the stateful solution below. I have reread this multiple times, but it still feels like it is avoiding the issue by defining it to not exist. 4: "Note that reassembly can happen at the ETR if the encapsulated packet was fragmented at or after the ITR." - I think that there needs to be more text / description about resource constraints on routers performing reassembly of fragments - in most cases a router doesn't have to / isn't expected to have to reassemble transit packets from arbitrary sources on the Internet (things where routers may reassemble are aimed at the control plane which can be rate-limited, or are from expected source addresses). It seems that spoofing lots of initial fragments without the final one will be a tax on the router. 5: "Instead of using the Map-Cache or mapping system, RLOC information MAY be gleaned from received tunneled packets or Map-Request messages. A "gleaned" Map-Cache entry, one learned from the source RLOC of a received encapsulated packet, is only stored and used for a few seconds, pending verification." - it seems that this is ripe for abuse (or I'm missing in the cache expiration). I want to hijack traffic from Site X to well known Service Y, so I look up Service Y and save the TTL from the Map-Reply. I then start spoof packets listing myself as the ETR - eventually Site X will glean from my spoofed packets, and start sending traffic to me - yes, this will only work for a few seconds -- but as soon as I stop getting packets from site X, I know site X has verified the entry and discovered it is wrong... and that the TTL is now being deprecated. I start a timer, and second or two less than the TTL later I start spoofing packets again, knowing that site X will soon expire the cache entry and will once again be willing to accept mine again. A: I get some Site X to Site Y traffic for a few seconds every TTL seconds, and B: the loss of this traffic is a signal that TTL seconds again it will need to be refreshed. 6: "10.1. Echo Nonce Algorithm" -- If I spoof lots of packets with the N- and E-bits set, the receiving ETR will need to keep false state, and presumably I can overfill a cache. This will cause the ETR to not be able to include the received nonce on legitimate traffic, and so the ITR on the far side will think this ETR is down. This seems like a fairly easy DoS. I'm guessing that this can be worked around by not setting the E bit in the RLOC-probe Map-Reply message, but this feels like a dangerous foot gun, and should at least be noted. Note that this is different to the "Note the attacker must guess a valid nonce the ITR is requesting to be echoed within a small window of time. The goal is to convince the ITR that the ETR’s RLOC is reachable even when it may not be reachable." attack listed in the document in that a: it doesn't require any guessing, and b: makes an ETR appear down, not up. The document does mention "... attack can be mitigated by preventing RLOC spoofing in the network by deploying uRPF BCP 38 [RFC2827]." - while that may be true for many of the above, BCP38 is far from being universally deployed, and this feels similar to solving world hunger by saying everyone must have enough food. :-) Again, apologies if I've completely misunderstood something, clue-bat gladly accepted... ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Comments: 1: "LISP Locator-Status-Bits (LSBs): ... The field is 32 bits when the I-bit is set to 0 and is 8 bits when the I-bit is set to 1." - I think I'm missing something fairly fundamental here (and in Section 10, 13.1, and others) - if I'm using the I bit, it sounds like I can only have 8 ETRs? And with this clear I can only have 32? I feel like I must have missed something.... 2: "When the ’DF’ field of the IP header is set to 1, or the packet is an IPv6 packet originated by the source host, the ITR will drop the packet when the size is greater than L and send an ICMPv4..." I think this needs to say when the resulting (or encapsulated) packet is greater than L (otherwise it is unclear if you are referring to the original or resulting packet). 3: "The server-side sets a Weight of zero for the RLOC subset list. In this case, the client-side can choose how the traffic load is spread across the subset list." -- please insert a reference to Section 12 here. I wrote up a long comment on what happens of the load sharing delivers packets to different ETRs, before finding this section later on in the document. Nits: 1: " LISP does not require changes to either host protocol stack or to underlay routers. " -- I think either "to either the host protocol stack" or " to either host protocol stacks" 2: "As an exmple of such attacks an off-path attacker can" -- typo for example. 3: "it can protect itself from erroneious reachability attacks" -- typo for erroneous. From nobody Tue Feb 5 18:44:03 2019 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3111129BBF; Tue, 5 Feb 2019 18:43:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Pete Resnick To: Cc: draft-ietf-lisp-rfc6833bis.all@ietf.org, ietf@ietf.org, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154942103074.32279.4509839048441396108@ietfa.amsl.com> Date: Tue, 05 Feb 2019 18:43:50 -0800 Archived-At: Subject: [lisp] Genart telechat review of draft-ietf-lisp-rfc6833bis-24 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 02:43:51 -0000 Reviewer: Pete Resnick Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-lisp-rfc6833bis-24 Reviewer: Pete Resnick Review Date: 2019-02-05 IETF LC End Date: 2018-08-31 IESG Telechat date: 2019-02-07 Summary: The changes made to this version look fine to me. No concerns save the editorial comment below. Major issues: None. Minor issues: None. Nits/editorial comments: Section 2: Get rid of everything except the last paragraph. From nobody Tue Feb 5 19:57:01 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB695128D0C; Tue, 5 Feb 2019 19:56:45 -0800 (PST) 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 0hg1CCLCeKkb; Tue, 5 Feb 2019 19:56:44 -0800 (PST) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 531C2128D09; Tue, 5 Feb 2019 19:56:41 -0800 (PST) Received: by mail-pl1-x62c.google.com with SMTP id b5so2504287plr.4; Tue, 05 Feb 2019 19:56:41 -0800 (PST) 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=/yA2Rf0Gk4oTW8A2XU127HolBTpHLYs391T6ycSd2wA=; b=NVXsdvKYtmEw8XQ09qzzEc+Tgjfo7C5ulno2DKEeQPwy4xa3OjL+69sUjfUpu9Q7wu pqjuXtPtUYF0pfYHhTANlvUYX5q8yfqFrmjjIfnV8hqirPuUA65ixd4z2otWxQp9SdYy CD5HkqkNZ8AELB+8MPgiPN01O1Y5U4YC48VECoQXo9KO3NtRtjlXBvbLpCk8rB6S9n3s V9jl67qrijL6jWIovoyr69VVbtcYOpz7l02L3dZIS3NDlLoRA7bHHu2iDqyHaimVXcsx UJVDwHwCdG8PlM/oEStjeltxRQWEL+SS+fPpycSWHTMDaVrPqwk58Qd8gCK9L9+sk0Fp fXNg== 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=/yA2Rf0Gk4oTW8A2XU127HolBTpHLYs391T6ycSd2wA=; b=WkgAYZrA3eBJ7hQ/wX+ZuaOlQvlHTBuj9WuKJ0cYm571qmb7rkTWLEDhyKn4nC8M/K 5yTwljYSsZlj26j3AhZzhRejy5TA1PpP2kpPtc/HGvI76hbZW3KpxksiW/ymVWorJQBW Nd0nwi/UDkIJJeHngOm1OEFZzLPa3EquCb1wLI6clrpOGGHtJH0qaQD2cfoCE7h5HAtc Rx44vi3NjctWVoibRAPZ1zDmyQxe4S1c+ybsb8V/uCU/GZB+cD/oavWhgwxk0b03iQew brtkqrHXOeJsiIYnFFU00iWSgxHVTcxMnWPD6yUdShwCZtPddFv/fqHN9+Fdbivbqvg+ PPjQ== X-Gm-Message-State: AHQUAuZkk+VM5ON06E+udum3uS5zVrzjHr/Dt8mjE1pYttrbyySOMO90 hd0nU4LmzQtenkpPHlg55PcKc68X X-Google-Smtp-Source: AHgI3IYizzrnBCzVhS1MculC98D51pF0vioCWfnPFBUKb4ehQDp0Kho4dms1K+QcmqRrBXfywoBnhQ== X-Received: by 2002:a17:902:6946:: with SMTP id k6mr8712108plt.101.1549425400622; Tue, 05 Feb 2019 19:56:40 -0800 (PST) Received: from ?IPv6:2601:646:9600:e494:d430:fc5a:645d:dcd7? ([2601:646:9600:e494:d430:fc5a:645d:dcd7]) by smtp.gmail.com with ESMTPSA id o1sm9787065pgn.63.2019.02.05.19.56.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Feb 2019 19:56:40 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (16D39) In-Reply-To: <154942103074.32279.4509839048441396108@ietfa.amsl.com> Date: Tue, 5 Feb 2019 19:56:39 -0800 Cc: gen-art@ietf.org, draft-ietf-lisp-rfc6833bis.all@ietf.org, ietf@ietf.org, lisp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <154942103074.32279.4509839048441396108@ietfa.amsl.com> To: Pete Resnick Archived-At: Subject: Re: [lisp] Genart telechat review of draft-ietf-lisp-rfc6833bis-24 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 03:56:46 -0000 > Nits/editorial comments: Section 2: Get rid of everything except the last p= aragraph. Are you sure? I just followed what RFC 8174 suggested. Give me reason to not= follow it? Dino= From nobody Tue Feb 5 19:59:57 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25CE6126F72; Tue, 5 Feb 2019 19:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu 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 lxcNtbCiEwHT; Tue, 5 Feb 2019 19:59:53 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-eopbgr820113.outbound.protection.outlook.com [40.107.82.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C774123FFD; Tue, 5 Feb 2019 19:59:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dzUy+SEmLfm9N53LasW+7sdEL6H6sOTJjFS1zYyPoL8=; b=h5Mce2cNUv+mX3cjXVPRu9UACj1EnYmGi1J7u3CHxVHS/Ytgp7v1yQiK8eWpAIQTiv2UKW8fA1ebqtb2nMTF0i9re9aDnZCq39OZx8ufj8ZBkmvNNziwg719a6LsWxqusmRQi7xy/uJyTuUxzjSOf2a6H3D+dP4hCr+IDLvpKTQ= Received: from SN2PR01CA0003.prod.exchangelabs.com (2603:10b6:804:2::13) by BYAPR01MB3750.prod.exchangelabs.com (2603:10b6:a02:81::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.22; Wed, 6 Feb 2019 03:59:51 +0000 Received: from CO1NAM03FT050.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::205) by SN2PR01CA0003.outlook.office365.com (2603:10b6:804:2::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.17 via Frontend Transport; Wed, 6 Feb 2019 03:59:50 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by CO1NAM03FT050.mail.protection.outlook.com (10.152.81.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.10 via Frontend Transport; Wed, 6 Feb 2019 03:59:50 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x163xk2A031620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 5 Feb 2019 22:59:48 -0500 Date: Tue, 5 Feb 2019 21:59:46 -0600 From: Benjamin Kaduk To: Dino Farinacci CC: Pete Resnick , , , , Message-ID: <20190206035946.GP63196@kduck.mit.edu> References: <154942103074.32279.4509839048441396108@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(376002)(346002)(136003)(39860400002)(396003)(2980300002)(189003)(199004)(23726003)(104016004)(55016002)(88552002)(106466001)(76176011)(47776003)(2906002)(26826003)(356004)(8676002)(8936002)(86362001)(7696005)(4744005)(6916009)(246002)(33656002)(305945005)(956004)(6246003)(126002)(476003)(11346002)(446003)(1076003)(97756001)(106002)(478600001)(426003)(336012)(16586007)(186003)(53416004)(486006)(75432002)(4326008)(54906003)(58126008)(316002)(1411001)(26005)(229853002)(786003)(50466002)(46406003)(36906005)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR01MB3750; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM03FT050; 1:FhgLQEXwHnCTi9FOnfH8AIr1HRqkC9rDDXy/bKoSBNg7TM10HDcmlDyJa0FS8FoNsRVkfXtr0t6Wm1GXUadRNlvv2nOfMy0CG5aFobJVP+cr8Yffe4zOcuhDc7nZLnav0lon6asS3PMq8UQxduAT5HeN0/GSvakmlPsp8TtVVvo= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2c49936d-6293-46f6-2168-08d68be78b22 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4608076)(4709027)(2017052603328)(7153060); SRVR:BYAPR01MB3750; X-Microsoft-Exchange-Diagnostics: 1; BYAPR01MB3750; 3:nP6t+485PvI2Y4MR15Q1lXs3dwngxi0OxEhCBZAyit3ka16FLnkt33VV8XFHOONOr57sJe90pbJCLlMkn4WbRfpB5C74hkHkJEoeaxeJP2vooaYlhZFgZBVWltUlIsfvySdYRX0uGLSm7hInrKzX2onmUfD5B9aCKamMezmYW/bmF15E7ZF2qEpKnwFw1nvgPDmX6LdYt7iZpd5FZiYujzGaVrb0wMlsEOmtBMRoa5GczYyacpnQPk98zPZAm6BQlxO6SAGy8FQBh5zdCzj02WVUm1ee1GCP/4NvuU3n9XKFJ1X0OgphCU35EMUl5JqX7RaPebZIGOWUA0+GY6MMknl9xbUyFLDTFHkzcHIKJjpJAP0RcjwubFPb7Ec/W+eh; 25:q8vV6/zpvQI9zmContFWpn0TFszNxX4KkAFQH+pI0tvWe+l+baRDhdQjdjG0B2PsG1FxtAUl88a4264ml4CURy0tarbTzzs47UUxZ14bF2OeL3hSHuYgj2oJ1vGxvsboUK6z9CwLKVecl3i6oAsk55fjcIPwtI/BHzZOGImC7klQ26KYoN3sdkjMGw1+GG5hH8LNwak5YmqruBtb//ctSJu9B7iETCW9AL0dfXh9z8SjpP3/w6DC4x5KKMRHhj4+YgrG5TYWWL4FU5PB/AG3SwkZyvd4dtbpqSkL1vfmy5l2QNLMxXL3QLWIEAHP95TkW8wvWCDe+busNruGgqoWzQ== X-MS-TrafficTypeDiagnostic: BYAPR01MB3750: X-Microsoft-Exchange-Diagnostics: 1; BYAPR01MB3750; 31:JhB06TVtzqta4vaIkkvkPktpyCW6ZgTf1tP4yzsqbW1vBdhbANrqkNtFwz1hDzxgkRtZP4fQGU2dOrPnpvd7+QWv7Hh0b0l4AGzpt6d6g4jU4ALjnKTMsFwLBAfP9qwMDRSHaRknZvVXO2q4UYK3WjQFEfLX7YeRDW6tMr59JWGdZxINKNAKlkAXYItmOSJ5SCmlTiH05IMj1lhyidHNg9FOVvLnaoiVCHUnpK4qhWs=; 20:Tlw4M8ZYPEEFm1X5S8ZP50EdpjCDzK9iAU7dtDGS6l7n1zRzdI0EuXBYIx0uJ+ex6SRNHVIG1E9Bw87ofdxMcjDwdvZUaxAYcfdvhHJNYBpFb6gY1C9/rkclc3YD0FszFJ035GGt/urzmDG+8LaxR1THSCvjhcaR5knEDhO5ty2wTTcFJOdwM1p3TRolVT7pM3ecO7epWoO++2cQhGC2qPSs6/4l/XzelNfGvexa/if2HSaIgGb61iWxTHPDybEAUlYhQkBR9T43Bvzzv4gMnIprjo0A1kpDccKhgybbIjJlc1SvmQdx/f72Ga0uxXMQi8bbFZSHwFaHLoo2gyHlqFB0AG8pMtHm1HlG5P61JO4v5X2cedd7Oki645wMrJvWw/+i2d1/4gX7oUGni6E7fKGZkauk/R/9ODUcYI7878ItntdbbOwxghQ1FVDuI8UDVkrYUCIDJR+D6X066YjoJUBmynA8zVF5DYBhoLBJw4XtDwhUbKBAMnJ0yHd7h9ARZ+zbPn+No2L9+q0MOtsK1JsYcInc/0aGB+/jrsp974DEoXMYW+c6XSFZD08ttfkCKY6nQexXJXtUjoouuIVg9u/eRYLU8zEcnPeXuJ0LcLU= X-Microsoft-Antispam-PRVS: X-Microsoft-Exchange-Diagnostics: 1; BYAPR01MB3750; 4:FYXbYEYeD3HSfsi7Flk323swcVvy/T8vHalLXJk5GKxbMrGtSXB6Xw/CWbDolCDwjC86by84WLpjg//CJpLWEvHIqW9yk2oamUtJiZhZxpn2pXECuUtxhc4dP/6yVKWJ+BtxBOmw+cRNtZdc7ZGYbxeephDvl61Up6xCV6uif+ah0MECpdbS48O/zke4c0IAWv2fx1Wga743u39qt9yjLaTSHgF5zEpOBlpk63cueEPT55osU3Oqk/uDx9XW5RD+SkQjks2jXa5qftphHl90slg2C/0RLmuPzmrLljrIKj+fayHMTLYSnEIAKFcztDXo X-Forefront-PRVS: 0940A19703 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BYAPR01MB3750; 23:lGmq4uQSocwmfRFjq4+ukLe+j5V8uG3Ab+7bZUjRK?= =?us-ascii?Q?xtw5xFEUET/9zuxTMbNih/8AD2wHZCzB3BNoWW5KMNC+nTFPz2KypjvB1KVK?= =?us-ascii?Q?a8zMnl+kJ7Y3+12RK0ma//G87OVnrpUOxpbmzfsU5z4/pkZrEO92QTz7c/LA?= =?us-ascii?Q?YAfdI8SIr4o3mVSxcuCqVnlNJmhLmpFHWsoUDIGbXeNwF513dZFdijCAXx3K?= =?us-ascii?Q?Ac24yUBMdfTGrAO8F41yVDnDet3ofwmyFAXsWSGD3Qu30ogJNeI6zAKGQk78?= =?us-ascii?Q?NQeA8QsMeJ5ltAYb23K+jdVE5XFoBqE4wfJg2sminIus9NLkMM6VE/4iTg0p?= =?us-ascii?Q?wqqDVnzz5gu/9zW0PyQDfZ+F6WldgvZvFBa/nDkUMS1/zh4N2WP3+y8RwoS1?= =?us-ascii?Q?8AQtzTvawJ3dK413TxeOyGXokyJklvOq/Pz+8hbDM7264xXXB16HVLMk20IK?= =?us-ascii?Q?monew6DAheGdJCX+Z2qCMe4WvsYdZFAjckKFnA6kVPCpcs/5rCZeX4CQM+Av?= =?us-ascii?Q?dtfdvfdvX81RQawvs3kJJimX0UN3DWuuRLdENPTjH/XUvfeXyLA1B++yIrOL?= =?us-ascii?Q?IAcPWhdiAQJ4rFrHjQBSU3y6QiPTEZ4Cq9SDx9hOfn8OR/c9tuHRCHxEgdJh?= =?us-ascii?Q?jfTvG8nDqmuiBu9x5G7K0VOHBWdprdX/pqegYmxYK3aV9uAWAUqVd+XI0a21?= =?us-ascii?Q?5FYpH8+KBw8DQqSLyzJmaQ3Q7bAMgSTKIRqfBKHhvdiTbHSBEXBQ5Sal8k1M?= =?us-ascii?Q?dlccwHqZLZf6/1XzfB6Voz7LiRkmw8bXstdCIF9cJNQiq4uIfRXF3oeh7sFj?= =?us-ascii?Q?AQjXEJhnVp9bIdxePLy8xGyGq/9Cw8rXLyCzWD1VWDvJsJyTbQVk5RvsJcuu?= =?us-ascii?Q?FC0qHkl/Y4s3bXZlFWobo2I8+pijWhsm9Wzpkjl5o03pW4HbujXgEmrL3eGq?= =?us-ascii?Q?oQIwQ/AbGaJ1LHwKwDl8gPAk1DuZDYAZnp6FDvCe1AdKaa+SbAKgQAyV+1Hi?= =?us-ascii?Q?UGGhHK3VwQsZlnD893885wd2fyFYYPTIGarN3ab1XlB0KQOUxbxUoC/0RrWV?= =?us-ascii?Q?NWTDpXRMZw4Emd0T1Xq68jxsKW99gVDNA819TS0y1J86PrbV6znng7xzTBi+?= =?us-ascii?Q?7ON87v0DBnZS5dhkUV8XRPyyJNhmtdHfEErWN9NlK+ZwswtqUoFdY1Z6tX7N?= =?us-ascii?Q?Gn8e53j7PBJ70otPEwmgGmIOuYawtO5i0M3T3kb/+Xsxg8ovljG62auyQ=3D?= =?us-ascii?Q?=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: CRjaevtzfKUPiTyIxN34926Aw4Uv2HfR4PyZsPndOXfsUgW2BIHqOH/q9NAYSysH/jPynFr93+1cNMHYpLR6yh8MP8CVB4Kf1+8oi2T8bJZOfRNKxzfxAhulUslhZQxEKS9kf9i1oI8opohtNkQhUuawOxhZYfi1gXcOWjaKrPuwz7s2+BcCXZ5MsMpjkBvz0jNleezgGr9Vx4+186srh9UjzpStpvL4DkrMrc9a9HV/qqr4Ks9cyCeLKWic+ORVqGeFaLZ57GqY8WJfuNv6H9YClUXGgdukJxx2dFLaHEgFuEDSY/dKSCiyJLLVjFa3R2G3ivaeB6BDTFKlyW1U4og/4YcmVxsdUOvxzZ/KsMO1dRscOExaqmCSAmjE1K+jYaHHABw08532UUCmEC4GtwYoxoxc4FgUe07/FTavsNU= X-Microsoft-Exchange-Diagnostics: 1; BYAPR01MB3750; 6:JiGO4F0MuN4/UfsqdOY5085nkxX76/Dkh4xa3yO9mNtZDSsL9Pu0l96RP6cjPtBW+BKFK05tSWH1wHjTi2q7Htrm83aq7TXSgxkx4984NE5XHqQR946lEMVM/PbU9MgGDP+VaMpMnmEhIhpJmmQ4etAWpt4mYlzceyNKV2dmt1ZFIhy9NP+huu23iGaaOVAgGeKJSrpkGlFKDVCTj5wuOGB7KGSyAzeHoNR5LunUTyLUVU/1MdGQunHIPjByTvQ8o30TuTDF4xcCuW4qhLJ/4qY1Bkdh1TmJdNtajSrtz2QDT+CzDyWO5mZQBypaj2dsxJQmopcr7J4vol0ozK5/OTj+YmyYIjEXuXpPiwVrQxOTGMOmmg/Xdgd+3BhRq6HnsT7Mz1oyb319BBv1XQo5ozH+kDmC4HWG1FjWoESK+WKzoDQWhBg+6uUHGYKR9SfqCih7z0c38kV8r35MIM8dtg==; 5:fuSP4FzfNVpzBGDesTKOe2OrXct4uozAaO+jjXkPag/vzO1QTi5UPTSBV5XPT/Ff+q/jV6DTANbWFLu3pRzAh0AINfSd3bBxdlOJlnQo9g2rfqtFAcMoTI2+2vDlUXLNvs3RPlT+7anZYUJgVGbmLipW6vMp7otDCAMuPxHOqA/dehFiQY7iBprD6s9PqHdX/fjg8wfjygG464g03TbbZw==; 7:YpaM61qiy0wncp6RXllorJNPXV0yvDgExbeIdgd6A6vb9WcZ/m9kKartBxmu6cXRKsHhusLkBLMF9mWV8skKS98Yo3xib0wxRgDA+mB5syFZJ+AV4j/Yp0me4tVo/qQIz3kiCJ3jxZp3SH6Ag0TNIQ== X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Feb 2019 03:59:50.2126 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2c49936d-6293-46f6-2168-08d68be78b22 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR01MB3750 Archived-At: Subject: Re: [lisp] Genart telechat review of draft-ietf-lisp-rfc6833bis-24 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 03:59:56 -0000 On Tue, Feb 05, 2019 at 07:56:39PM -0800, Dino Farinacci wrote: > > Nits/editorial comments: Section 2: Get rid of everything except the last paragraph. > > Are you sure? I just followed what RFC 8174 suggested. Give me reason to not follow it? Yes, he's sure. You pasted the text that 8174 inserted into 2119, when all you need is the bit after "Authors who follow these guidelines should incorporate this phrase near the beginning of their document:" -Benjamin From nobody Tue Feb 5 20:06:44 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C8B126F72; Tue, 5 Feb 2019 20:06:41 -0800 (PST) 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 i9PO1z5YJQ6i; Tue, 5 Feb 2019 20:06:40 -0800 (PST) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 1D38B126C7E; Tue, 5 Feb 2019 20:06:40 -0800 (PST) Received: by mail-pg1-x535.google.com with SMTP id v28so2348535pgk.10; Tue, 05 Feb 2019 20:06:40 -0800 (PST) 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=fhfY+gjMNrcxoE6lb5RuZWr9N3jrPVkljvm8jlklsoQ=; b=F4ikNYdey2Pjj5/NUlbNd3hbZYG+IOOkjf1aB9xGP3UMUbvoi814WBo2j744K+uMvE ij4+xQGV4l6ZPoeHAAMrWHUm/EKhlmFMCGQ0vJoj+e9ecmLAC1bc/Y66aV4e6eMl/oZD 5TX/WR8ac4Xv6Y2EFkseERYBPj9qZl51Y+PwCVOpnWrPGQ+U3Dzn3lDOudn/WVq/kU6E OBz2d3DPVVik5rW1XrTVt7bFYQVpnDqdoR2eXVwSaJr+vgFSWVw8f+DfvFDwOuFyQ4Ej olJj1j4H16mfSgR36kIHkLE6KQyy1XN3JqAYUbxfTzsrNUHzYDRwBLQ48rEv6EgQgFm3 EkNw== 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=fhfY+gjMNrcxoE6lb5RuZWr9N3jrPVkljvm8jlklsoQ=; b=c37Ddo3b4yXegb7LJ91Pb5FN9kuqMPSNKU01yJL4GDjCfP0DKe2RYTJxZAZNGhPsVD 0YLzUIBbacsQLTJltXqlTAA0WrtbMeiZNklzRnEnssrNBkJRU5pFeY7cOV0ShwBbOC3T gi2g1oWYUf89F9/AEQKtZM2KZ7iyEUnNb/OWeMo98A9+xytocg0opfKYzAhseuBeI8Pc vNpDj99SnL+UlAIO7F2hsMl6QqVF62xNHszOtPdJNhs+JXuQiuahzyKn1YwRFyoJT8us LbwvckfgsMpAdlpEWzFjMxWmSd94LfySfsL9zIMqRnN1uqQmc2/4XVYBKF3MIAgvEtZe ZE3w== X-Gm-Message-State: AHQUAubT50L+oO9Vi2it3lRN+hPq5r+RKezEWpDLF/2cavrlxp55O9s+ KAyUtZokY6DFeVJWsmFQnSk= X-Google-Smtp-Source: AHgI3IbjHFP1gsjoOhK7RPZTwJrR4UufL3F7rZ8FEo36Yr0mgAGXmCJdwjf4KE+c36v7UtGaB8DnPA== X-Received: by 2002:a63:2a44:: with SMTP id q65mr7192154pgq.231.1549425999700; Tue, 05 Feb 2019 20:06:39 -0800 (PST) Received: from ?IPv6:2601:646:9600:e494:d430:fc5a:645d:dcd7? ([2601:646:9600:e494:d430:fc5a:645d:dcd7]) by smtp.gmail.com with ESMTPSA id s37sm7884181pgm.19.2019.02.05.20.06.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Feb 2019 20:06:38 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (16D39) In-Reply-To: <20190206035946.GP63196@kduck.mit.edu> Date: Tue, 5 Feb 2019 20:06:38 -0800 Cc: Pete Resnick , gen-art@ietf.org, draft-ietf-lisp-rfc6833bis.all@ietf.org, ietf@ietf.org, lisp@ietf.org, Dino Farinacci Content-Transfer-Encoding: quoted-printable Message-Id: References: <154942103074.32279.4509839048441396108@ietfa.amsl.com> <20190206035946.GP63196@kduck.mit.edu> To: Benjamin Kaduk Archived-At: Subject: Re: [lisp] Genart telechat review of draft-ietf-lisp-rfc6833bis-24 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 04:06:42 -0000 Okay. I will keep the last paragraph only. Thanks.=20 Dino > On Feb 5, 2019, at 7:59 PM, Benjamin Kaduk wrote: >=20 > On Tue, Feb 05, 2019 at 07:56:39PM -0800, Dino Farinacci wrote: >>> Nits/editorial comments: Section 2: Get rid of everything except the las= t paragraph. >>=20 >> Are you sure? I just followed what RFC 8174 suggested. Give me reason to n= ot follow it? >=20 > Yes, he's sure. >=20 > You pasted the text that 8174 inserted into 2119, when all you need is the= > bit after "Authors who follow these guidelines should incorporate this > phrase near the beginning of their document:" >=20 > -Benjamin From nobody Wed Feb 6 08:11:26 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A0812F1AC for ; Wed, 6 Feb 2019 08:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-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 RhNqiuqHpYM9 for ; Wed, 6 Feb 2019 08:11:01 -0800 (PST) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 BF9D312F295 for ; Wed, 6 Feb 2019 08:10:54 -0800 (PST) Received: by mail-wm1-x32f.google.com with SMTP id g67so3378558wmd.2 for ; Wed, 06 Feb 2019 08:10:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=8G3DOXTS4pIeA8u2Kfn/Ga7jU/XGMJHlAl+af0h/nQE=; b=wK/JW0Zc6W5cvLK0Ip0/O2JMqUDxRtTjorONkiYnM71SWig5ymJHDPPDYkfLkpgHCc 6KDEfOTkR6fjqPx+qr3t0S/DiowqCt8CY726/yQrA7IpEBhcRCs7LXpapAnzUWO2Wfx6 gOu/GSdpdjmmnVoaAtiDI3mg2Et3OghfhGeaaGyAxhAqlIYLz/XT+XHqc2GJjxZDO+Oi kosvoF43SgWATySABGkzPO2e5scL+y/PSgXKe05AglDfBN6bfLXkiDbLgk6LuC6bmamS yEZvzwaHpikHpnWIIkcHdE0RKLjwRdtSCDqfrHtc3XjatK1PFad5d5cHMZxNcCKhr3BP hunA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=8G3DOXTS4pIeA8u2Kfn/Ga7jU/XGMJHlAl+af0h/nQE=; b=DB1V2INqtb7yZrN9OZejbltwd64CpyY2t5BHPaUsbZsjyF8NVtGKl4dq9NkBftZJ0i 7xjzCTFd/EXu6bfAGOZ3FQQ6IohVar5eKv9JiaNtdrGDmwECy4QsW7WG49GA84pk57pN Bqkwe1lwohE51QUMqBRtrlArmw1N0UTRCd306mTt+YQJr/Tpn4jIQAlNGEpMzvmiHdT0 gTk/6/lHKf4/SIucVZe1gVeIGXEugt77Ij6OQ0hje848+ipwSLw95RikEL3YV/3tvewa pTiwDqWASS/5pPJ/euwtZMNhRYryH/ZDegIrlBejiMKYnipV1Wt0NsponFXscAFbD+Go gktg== X-Gm-Message-State: AHQUAuYOzIkWQWUpiCwUb1zP1J7HPYhNb3VBqki6XqezuwPfOB+WCYeW busLyhi0xNKR/VhUEnbeUi/2Gw== X-Google-Smtp-Source: AHgI3IaLN3jWbJl/YYSCLt9QnvZupVMwYG3vpsaiJD06uutzP4D41/514BbhTKgWIs6xP8OmO46UTQ== X-Received: by 2002:a1c:5f8a:: with SMTP id t132mr3915247wmb.40.1549469452971; Wed, 06 Feb 2019 08:10:52 -0800 (PST) Received: from 2a01cb0404a8c700d077aef381d45a44.ipv6.abo.wanadoo.fr (2a01cb0404a8c700d077aef381d45a44.ipv6.abo.wanadoo.fr. [2a01:cb04:4a8:c700:d077:aef3:81d4:5a44]) by smtp.gmail.com with ESMTPSA id q12sm11131001wmf.2.2019.02.06.08.10.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Feb 2019 08:10:51 -0800 (PST) From: Luigi Iannone Message-Id: <1B6E2085-FFD8-4CAA-B9BB-5CBFC5AA9745@gigix.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_BFFCCB7E-1C4D-47C8-9626-19BD7985E7A8" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 6 Feb 2019 17:10:50 +0100 In-Reply-To: Cc: Dino Farinacci , The IESG , lisp-chairs@ietf.org, "lisp@ietf.org list" , draft-ietf-lisp-rfc6830bis@ietf.org To: "Mirja Kuehlewind (IETF)" References: <153667905625.16761.12157659372502604927.idtracker@ietfa.amsl.com> <7DEBCA24-9D55-4325-85AA-48AB3FAAB91D@gmail.com> <0201F06C-DA9E-445A-A995-54BA805B595C@kuehlewind.net> <5EC21C57-D217-48A9-AFD0-24710299CF7F@kuehlewind.net> <5A3C4B1F-EA31-4698-96F4-915A77400A56@gmail.com> <2CAF25CC-01EE-49D4-B970-F8EFB24940A8@kuehlewind.net> <5F9D8F39-871D-4A96-9C0A-7BACD2ABB1F7@gmail.com> <2DC6D38E-C46B-4D38-B093-B88720BCD550@kuehlewind.net> <0BE5C929-D2FA-4786-9F5E-0A93E7700880@gmail.com> <11FBAC13-2859-4778-84CA-B546EB669727@kuehlewind.net> <2FEB555F-16A5-4875-93ED-D14BFEEF503A@gigix.net> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 16:11:06 -0000 --Apple-Mail=_BFFCCB7E-1C4D-47C8-9626-19BD7985E7A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Mirja, > On 5 Feb 2019, at 16:39, Mirja Kuehlewind (IETF) = wrote: >=20 > Hi Luigi, >=20 > I just realized that I never replied to this mail. The change below is = okay, however, it did not make it into the current version of the draft = and therefore I cannot clear my discuss. Fair enough. Let me sum up the changes we agree on: Section 5.3 in the part marked as "When doing ITR/PITR encapsulation:=E2=80= =9D OLD: The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the IPv6 'Traffic Class' field) requires special treatment in order to avoid discarding indications of congestion [RFC6040 = ]. ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner header to the outer header. Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the new outer header. NEW and simplified: The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the IPv6 'Traffic Class' field) requires special treatment in order to avoid discarding indications of congestion as specified = in=20 [RFC6040 ].=20 Note the re-encapsultion test has been remove (see later on) Section 5.3 in the part marked as "When doing ETR/PETR decapsulation:" OLD:=20 The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the IPv6 'Traffic Class' field) requires special treatment in order to avoid discarding indications of congestion [RFC6040 = ]. If the 'ECN' field contains a congestion indication codepoint (the value is '11', the Congestion Experienced (CE) codepoint), then ETR decapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the surviving inner header that is used to forward the packet beyond the ETR. These requirements preserve CE indications when a packet that uses ECN traverses a LISP tunnel and becomes marked with a CE indication due to congestion between the tunnel endpoints. Implementations exist that copy the 'ECN' field from the outer header to the inner header even though [RFC6040 ] does not recommend = this behavior. It is RECOMMENDED that implementations change to support the behavior in [RFC6040 = ]. NEW and simplified: The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the IPv6 'Traffic Class' field) requires special treatment in order to avoid discarding indications of congestion as specified = in=20 [RFC6040 ]. Note that = implementations exist that copy the 'ECN' field from the outer header to the inner header even though [RFC6040 ] does not recommend = this behavior. It is RECOMMENDED that implementations change to support the behavior in [RFC6040 = ]. In the same section drop completely the last paragraph because is a = duplicate of the above. Replaced by a note on the re-encapsulation: NEW (Replacing last paragraph) Some xTRs and PxTRs performs re-encapsulation operations and need=20= to treat the 'Explicit Congestion Notification' (ECN) in a special = way. Because the re-encapsulation operation is a sequence of two = operations, namely=20 a decapsulation followed by an encapsulation, the ECN bits = MUST be treated as described=20 above for these two operations. Does it sound OK to you? Ciao L. =20 > Please also note that the text on decapsulation is basically in the = same section twice. I recommend to remove it once and adapt the other = one accordingly. >=20 > Further, inline with RFC6040, you would also need to align the = re-encapsulation part. Currently the text says: > "Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped = outer header to the new outer header.=E2=80=9C > Usually re-encapsulation is performed by doing de-encapsulation and = then encapsulation again. The difference here would be, that if e.g. the = inner header is not-ETC but the tunnel changes the bits to ETC0 or ETC1 = this error is not further propagated, indicating ECN support where there = is not ECN support. >=20 > Thanks, > Mirja >=20 >=20 >=20 >> Am 26.09.2018 um 17:27 schrieb Luigi Iannone : >>=20 >> Hi Mirja, >>=20 >> trying to follow up on this issue. >>=20 >> The ECN text for encapsulation is currently: >>=20 >> The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 >> of the IPv6 'Traffic Class' field) requires special treatment in >> order to avoid discarding indications of congestion [ >> RFC3168 >> ]. >> ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner >> header to the outer header. Re-encapsulation MUST copy the = 2-bit >>=20 >> 'ECN' field from the stripped outer header to the new outer >>=20 >> header. >>=20 >> Can we keep it as it is (updating the reference to 6040)? >>=20 >> The text for decapsulation is: >>=20 >> CURRENT: >> The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 >> of the IPv6 'Traffic Class' field) requires special treatment in >> order to avoid discarding indications of congestion [ >> RFC6040 >> ]. If >> the 'ECN' field contains a congestion indication codepoint (the >> value is '11', the Congestion Experienced (CE) codepoint), then >> ETR decapsulation MUST copy the 2-bit 'ECN' field from the >> stripped outer header to the surviving inner header that is used >> to forward the packet beyond the ETR. These requirements = preserve >> CE indications when a packet that uses ECN traverses a LISP = tunnel >> and becomes marked with a CE indication due to congestion = between >> the tunnel endpoints. Implementations exist that copy the 'ECN' >> field from the outer header to the inner header even though >> [ >> RFC6040 >> ] does not recommend this behavior. It is RECOMMENDED >> that implementations change to support the behavior in [ >> RFC6040 >> ]. >>=20 >>=20 >> Which I suggest we shrink to: >>=20 >> NEW: >>=20 >> The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 >> of the IPv6 'Traffic Class' field) requires special treatment in >> order to avoid discarding indications of congestion [ >> RFC6040].=20 >> Note that implementations exist that copy the 'ECN' >> field from the outer header to the inner header even though >> [ >> RFC6040 >> ] does not recommend such behavior. It is RECOMMENDED >> that implementations change, so to support the specifications in = [ >> RFC6040 >> ]. >>=20 >>=20 >>=20 >> The text above clearly states that implementations should be conform = to 6040.=20 >>=20 >> Is it what you were looking for? >>=20 >> Or am I missing something? >>=20 >> Ciao >>=20 >> L. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>> On 24 Sep 2018, at 19:34, Dino Farinacci = wrote: >>>=20 >>> Well, the implementations are out and working. And we said in the = latest updates to consider using RFC6040. So not sure we can do much = more than that. >>>=20 >>> Dino >>>=20 >>>> On Sep 24, 2018, at 5:52 AM, Mirja Kuehlewind (IETF) = wrote: >>>>=20 >>>> Because they don=E2=80=99t follow RFC6040 and therefore we do = something different in some corner cases. >>>>=20 >>>>=20 >>>>=20 >>>>> Am 22.09.2018 um 06:52 schrieb Dino Farinacci = : >>>>>=20 >>>>>> However, I totally disagree with your comment on providing = details that are not implemented. If they are not implemented correctly, = it might even be more important to spell them out in this document, so = implementors have chance to update their (future) implementation to do = the correct thing. Having deployed implementations that are non = standard-conform always happens and in this case it is probably not = specifically problematic as it doesn=E2=80=99t impact interoperability. = However, it is important though that the spec is correct. >>>>>=20 >>>>> And why do you think they are implemented incorrectly?=20 >>>>>=20 >>>>> Dino >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_BFFCCB7E-1C4D-47C8-9626-19BD7985E7A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Mirja,


On 5 Feb 2019, at 16:39, Mirja = Kuehlewind (IETF) <ietf@kuehlewind.net> wrote:

Hi = Luigi,

I just realized that I never replied = to this mail. The change below is okay, however, it did not make it into = the current version of the draft and therefore I cannot clear my = discuss.

Fair = enough.

Let me sum up the changes we = agree on:


Section 5.3 in the part marked as "When doing = ITR/PITR encapsulation:=E2=80=9D

OLD:
      The 'Explicit Congestion =
Notification' (ECN) field (bits 6 and 7
      of the IPv6 'Traffic Class' field) requires special treatment in
      order to avoid discarding indications of congestion [RFC6040].
      ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner
      header to the outer header.  Re-encapsulation MUST copy the =
2-bit
      'ECN' field from the stripped outer header to the new outer

      =
header.

NEW and = simplified:

      The 'Explicit Congestion =
Notification' (ECN) field (bits 6 and 7
      of the IPv6 'Traffic Class' field) requires special treatment in
      order to avoid discarding indications of congestion as =
specified in 
      [RFC6040]. 


Note the re-encapsultion test has been remove (see later =
on)


Section 5.3 in the part marked as "When doing = ETR/PETR decapsulation:"

OLD: 
      The 'Explicit Congestion =
Notification' (ECN) field (bits 6 and 7
      of the IPv6 'Traffic Class' field) requires special treatment in
      order to avoid discarding indications of congestion [RFC6040].  If
      the 'ECN' field contains a congestion indication codepoint (the
      value is '11', the Congestion Experienced (CE) codepoint), then
      ETR decapsulation MUST copy the 2-bit 'ECN' field from the
      stripped outer header to the surviving inner header that is used
      to forward the packet beyond the ETR.  These requirements preserve
      CE indications when a packet that uses ECN traverses a LISP tunnel
      and becomes marked with a CE indication due to congestion between
      the tunnel endpoints.  Implementations exist that copy the 'ECN'
      field from the outer header to the inner header even though
      [RFC6040] does not recommend this behavior.  It is =
RECOMMENDED
      that implementations change to support the behavior in [RFC6040].


NEW and = simplified:

      The 'Explicit Congestion =
Notification' (ECN) field (bits 6 and 7
      of the IPv6 'Traffic Class' field) requires special treatment in
      order to avoid discarding indications of congestion as specified =
in 
      [RFC6040]. Note that implementations exist that copy the =
'ECN'
      field from the outer header to the inner header even though
      [RFC6040] does not recommend this behavior.  It is =
RECOMMENDED
      that implementations change to support the behavior in [RFC6040].


In the same section drop completely the last paragraph because is =
a duplicate of the above.
Replaced by a note on the re-encapsulation:

NEW (Replacing last =
paragraph)

     Some xTRs and PxTRs performs re-encapsulation operations and =
need 
     to treat the 'Explicit Congestion Notification' (ECN) =
in a special way.
  Because the = re-encapsulation operation is a  sequence of two operations, = namely 
          a = decapsulation followed by an encapsulation, the ECN bits MUST be treated = as described 
        =   above for these two operations.


Does= it sound OK to you?

Ciao

L.

 




Please also note that the text on decapsulation is basically = in the same section twice. I recommend to remove it once and adapt the = other one accordingly.

Further, inline with = RFC6040, you would also need to align the re-encapsulation part. = Currently the text says:
"Re-encapsulation MUST copy the = 2-bit 'ECN' field from the stripped outer header to the new outer = header.=E2=80=9C
Usually re-encapsulation is performed by = doing de-encapsulation and then encapsulation again. The difference here = would be, that if e.g. the inner header is not-ETC but the tunnel = changes the bits to ETC0 or ETC1 this error is not further propagated, = indicating ECN support where there is not ECN support.

Thanks,
Mirja



Am 26.09.2018 um 17:27 schrieb Luigi Iannone = <ggx@gigix.net>:

Hi Mirja,

trying = to follow up on this issue.

The ECN text = for encapsulation is currently:

=      The 'Explicit Congestion Notification' = (ECN) field (bits 6 and 7
=      of the IPv6 'Traffic Class' field) = requires special treatment in
=      order to avoid discarding indications of = congestion [
RFC3168
].
=      ITR encapsulation MUST copy the 2-bit = 'ECN' field from the inner
=      header to the outer header. =  Re-encapsulation MUST copy the 2-bit

=      'ECN' field from the stripped outer header = to the new outer

=      header.

Can = we keep it as it is (updating the reference to 6040)?

The text for decapsulation is:

CURRENT:
     The = 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
     of the IPv6 'Traffic Class' = field) requires special treatment in
=      order to avoid discarding indications of = congestion [
RFC6040
].  If
     the 'ECN' field contains a = congestion indication codepoint (the
=      value is '11', the Congestion Experienced = (CE) codepoint), then
     ETR = decapsulation MUST copy the 2-bit 'ECN' field from the
=      stripped outer header to the surviving = inner header that is used
=      to forward the packet beyond the ETR. =  These requirements preserve
=      CE indications when a packet that uses ECN = traverses a LISP tunnel
     and = becomes marked with a CE indication due to congestion between
     the tunnel endpoints. =  Implementations exist that copy the 'ECN'
=      field from the outer header to the inner = header even though
     [
RFC6040
] does not recommend this behavior. =  It is RECOMMENDED
=      that implementations change to support the = behavior in [
RFC6040
].


Which I suggest we shrink to:

NEW:

=      The 'Explicit Congestion Notification' = (ECN) field (bits 6 and 7
=      of the IPv6 'Traffic Class' field) = requires special treatment in
=      order to avoid discarding indications of = congestion [
RFC6040].
=      Note that implementations exist that copy = the 'ECN'
     field from the = outer header to the inner header even though
=      [
RFC6040
] = does not recommend such behavior.  It is RECOMMENDED
=      that implementations change, so to support = the specifications in [
RFC6040
].



The text above = clearly states that implementations should be conform to 6040.

Is it what you were looking for?

Or am I missing something?

Ciao

L.





On 24 Sep 2018, at = 19:34, Dino Farinacci <farinacci@gmail.com> wrote:

Well, the implementations are out and working. And we said in = the latest updates to consider using RFC6040. So not sure we can do much = more than that.

Dino

On Sep 24, 2018, at 5:52 = AM, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net> wrote:

Because they don=E2=80=99t follow RFC6040 and therefore we do = something different in some corner cases.


Am = 22.09.2018 um 06:52 schrieb Dino Farinacci <farinacci@gmail.com>:

However, I totally = disagree with your comment on providing details that are not = implemented. If they are not implemented correctly, it might even be = more important to spell them out in this document, so implementors have = chance to update their (future) implementation to do the correct thing. = Having deployed implementations that are non standard-conform always = happens and in this case it is probably not specifically problematic as = it doesn=E2=80=99t impact interoperability. However, it is important = though that the spec is correct.

And why do you think they are implemented incorrectly?

Dino






= --Apple-Mail=_BFFCCB7E-1C4D-47C8-9626-19BD7985E7A8-- From nobody Wed Feb 6 09:48:18 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7B71277BB; Wed, 6 Feb 2019 09:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 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_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=no 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 UzZjRSv7IJdl; Wed, 6 Feb 2019 09:48:10 -0800 (PST) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 DA2E4130EA2; Wed, 6 Feb 2019 09:48:09 -0800 (PST) Received: by mail-pf1-x42b.google.com with SMTP id u6so3399659pfh.11; Wed, 06 Feb 2019 09:48:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=v5VeJWvjo8SH/Fre7R8ykMC5ORybuftEzQjDWFOyQGE=; b=MK0sEJIO+H2Zvc8T4ozOYOb5HkwwzW9XXzdcLF8aP4eJoHWGaIhBGSswBKwiWF1aS1 eLbUxLRCIv5sXUNpw6bsHpxJR/VcbGT2tBK55I9+QE8jlD9hEGItQWqofdO4Xqe7Wk/J MeJUfYYD+mCGqDDjQxRJODkaKNwrPvDUZroJLJciqLtWooxkjmzUse08GIBKIOf1b4V+ CcpeVTowadwl8W4sp74ex387ncOs8n3Pp3qFf/95Fyr1bh59LT3KzOrDRmcXVrK/OaVM EW8gwLs14d9/SZHVd5+5NSDRlcD2C2yzjVtt0tiOa+2MstGll7mk41MB7eghk79dBwZv stoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=v5VeJWvjo8SH/Fre7R8ykMC5ORybuftEzQjDWFOyQGE=; b=t6Ye8/scjuAePlCQyivnpEoYd9rHkkivkz5DwxdTz6Aw03L23a2s+BMHJXuqo/AoiL Vx3IqlHx0LWjnTcsXXuiFh73o/jNePnibSZDeT6CCwJG+RpWe8h19WTlt1Oa00EK5N1Q iDAWio9Hgn+Ol+yhKvYAuPpgMkTSIdeXbgvWWGlleQmPcUaTxi8T9RtTX/5NSPdavI0b z1wAgLx3sjsLWbp2Jnj6MV3KY5dqzxE0nT5eN+BYjeMAQXmDLB9NN5KY+6/WBJOhRwTk vraYC/U1ZddnEpyFTxpjwDy4pHAKt8qmS14swuSuuv81gzADlQNAADb1PZcZuT0yifYQ a5cQ== X-Gm-Message-State: AHQUAubFcv3Ff/bd7qbkUUaKdeFHZmVOG6s+VMOA7F7esdpVTpCVvlsw Ks7sIA7EjgAK0+eMDQMQvqtMf/Bz X-Google-Smtp-Source: AHgI3IYkPKZYmnmv60LX2EADnw40TZGhdBhcjRKsrrsewHvLIE5Mm8ohROgzAdP3XP66/cfKKtrTZQ== X-Received: by 2002:a62:9657:: with SMTP id c84mr11905380pfe.77.1549475288809; Wed, 06 Feb 2019 09:48:08 -0800 (PST) Received: from [10.31.79.74] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id y9sm9614866pfi.74.2019.02.06.09.48.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Feb 2019 09:48:07 -0800 (PST) From: Dino Farinacci Message-Id: Content-Type: multipart/mixed; boundary="Apple-Mail=_7F48DF72-0693-4ABB-B1FB-1E54B770FE77" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 6 Feb 2019 09:48:06 -0800 In-Reply-To: <154941971479.32132.7227582520612116720.idtracker@ietfa.amsl.com> Cc: The IESG , draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, lisp@ietf.org To: Warren Kumari References: <154941971479.32132.7227582520612116720.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Warren Kumari's Discuss on draft-ietf-lisp-rfc6830bis-26: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 17:48:16 -0000 --Apple-Mail=_7F48DF72-0693-4ABB-B1FB-1E54B770FE77 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Warren, thanks for the review, I have changed text to address your = comments and nits below. A new diff file is enclosed at the end. I want to send one message to the IESG. This has no reflection on Warren = or his commentary. But the standards process seems to be at an all-time = low for my prespective. And this Jan 2019 I have been coming to IETF for = 30 years. So I think I=E2=80=99m not speaking off the cuff here and = speak from what I have experienced over that long time frame. We have been trying to get these documents to move forward and it seems = with all the new people that come to the IESG that do the reviews are = not expert in the art and hence we have to explain basic LISP. It has = been happening for about 6 quarters now. We explain, people understand, = a quarter passes, there is silence, new people come into the review = process, and we explain again. We have redone text so many times that likely have undone commentary = from people that were experienced in the art who commented years ago. = What if they come back in now and say =E2=80=9Cyou change the text = again=E2=80=9D. To the authors, this seems non-sense, never ending and not productive. = One can see why open-source approaches are out competing the IETF = process. I=E2=80=99ll stop there. I=E2=80=99ll explain once again in the DISCUSS comments below because I = know Warren put effort into this when he should have been resting. ;-) > On Feb 5, 2019, at 6:21 PM, Warren Kumari wrote: >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I read much of this on a plane while overtired, so it is entirely = possible / > probable that I've completely misunderstood something(s) obvious. Many = of the > below are probably simple to address, and either I simply need to be = educated, > or just there needs to be a bit more text / detail provided. I will respond briefly and directly. > 1: "3. The ITR sends a LISP Map-Request as specified in > [I-D.ietf-lisp-rfc6833bis]. Map-Requests SHOULD be rate-limited." = What does > the ITR do with the packet while waiting for the Map-Request to = complete? Must > it buffer the packets or can it discard them? If the former, for how = long must > it buffer? When you say "SHOULD be rate-limited", can you provide = guidance on > rates? 1 request per second? 1 million per second? Is this rate-limit = per > destination or per device? Apologies if this is clearly stated in = RFC6833(bis) > - I only skimmed it, and didn't see an answer there. We have said drop or queue. We discourage queuing because one never = knows which packets are the important ones to queue. Never much the same = as the ARP resolution issue. > 2: "6. ... Note that the Map-Cache is an on-demand cache. An ITR will = manage > its Map-Cache in such a way that optimizes for its resource = constraints." > Presumably I could cause this cache to thrash / overflow by looking at = the RLOC > database, and choosing EIDs to send traffic to which all require = different > cache entries, causing the cache to overflow (or, at least, causing = maximum > cache pressure). This seems like an ideal DoS vector. It seems that = there > should be more guidance provided on how to size the Map-Cache / the = expected > order of the cache size, even if it is ultimately an implementation = issue (e.g: > is a Map-Cache of 100 entries OK for an ITR? or should it be O(1000)? = Or > roughly size(database)/2? Having multiple devices with small caches, = and a bot > which does the above seems like a global risk). What happens if you send 10,000,000 BGP routes in an update and the = receiver can=E2=80=99t store it. It is the same problem. We have lots of = research on this problem and there are pointers in the spec to it. > I'm quite confused by much of the MTU / Fragmentation stuff -- I did = read the > documents on a plane after not getting much sleep, and so it is = entirely > possible / probable that I'm just being stupid, but there are bits = which don't > seem to make sense to me. 3: "2. Define L to be the size, in octets, = of the > maximum-sized packet an ITR can send to an ETR without the need for = the ITR or > any intermediate routers to fragment the packet." How do I know what L = is? The > document "RECOMMENDS that L be defined as 1500" -- but 1500 isn't = universally > true (if it were, we would never have to do Path MTU). What happens = when the > *actual* MTU on the path is e.g 1476 because there is a tunnel on the = path? The > text also mentions "which is less than the ITR=E2=80=99s estimate of = the path MTU > between the ITR and its correspondent ETR" - this implies that the ITR = is > tracking / estimating the MTU, which a: doesn't align with the rest of = the > text, or b: sounds like the stateful solution below. I have reread = this > multiple times, but it still feels like it is avoiding the issue by = defining it > to not exist. L is an architectural constant. If there tends to be tunnels between the = ITR and ETR, then you choose L to be 1400. Or you run MTU discovery = between the ITR and ETR to determine the effective MTU. > 4: "Note that reassembly can happen at the ETR if the encapsulated = packet was > fragmented at or after the ITR." - I think that there needs to be more = text / > description about resource constraints on routers performing = reassembly of > fragments - in most cases a router doesn't have to / isn't expected to = have to > reassemble transit packets from arbitrary sources on the Internet = (things where > routers may reassemble are aimed at the control plane which can be > rate-limited, or are from expected source addresses). It seems that = spoofing > lots of initial fragments without the final one will be a tax on the = router. We have chosen 3 methods to deal with MTU issues because ETR reassembly = is the worst approach. And I certainly wouldn=E2=80=99t recommend using = it. > 5: "Instead of using the Map-Cache or mapping system, RLOC information = MAY be > gleaned from received tunneled packets or Map-Request messages. A = "gleaned" > Map-Cache entry, one learned from the source RLOC of a received = encapsulated > packet, is only stored and used for a few seconds, pending = verification." - it > seems that this is ripe for abuse (or I'm missing in the cache = expiration). I > want to hijack traffic from Site X to well known Service Y, so I look = up > Service Y and save the TTL from the Map-Reply. I then start spoof = packets > listing myself as the ETR - eventually Site X will glean from my = spoofed > packets, and start sending traffic to me - yes, this will only work = for a few > seconds -- but as soon as I stop getting packets from site X, I know = site X has > verified the entry and discovered it is wrong... and that the TTL is = now being > deprecated. I start a timer, and second or two less than the TTL later = I start > spoofing packets again, knowing that site X will soon expire the cache = entry > and will once again be willing to accept mine again. A: I get some = Site X to > Site Y traffic for a few seconds every TTL seconds, and B: the loss of = this > traffic is a signal that TTL seconds again it will need to be = refreshed. It was a Google employee in the early days that wanted this feature = (circa 2007). ;-) It was so return packets from a server side didn=E2=80=99= t have to do the mapping system lookup. It is off by default and only = used in trusted enviornments where you can control how the ITR and ETR = behave. > 6: "10.1. Echo Nonce Algorithm" -- If I spoof lots of packets with = the N- and > E-bits set, the receiving ETR will need to keep false state, and = presumably I > can overfill a cache. This will cause the ETR to not be able to = include the > received nonce on legitimate traffic, and so the ITR on the far side = will > think this ETR is down. This seems like a fairly easy DoS. I'm = guessing that > this can be worked around by not setting the E bit in the RLOC-probe = Map-Reply > message, but this feels like a dangerous foot gun, and should at least = be > noted. Note that this is different to the "Note the attacker must = guess a > valid nonce the ITR is requesting to be echoed within a small window = of time.=20 > The goal is to convince the ITR that the ETR=E2=80=99s RLOC is = reachable even when it > may not be reachable." attack listed in the document in that a: it = doesn't > require any guessing, and b: makes an ETR appear down, not up. You can=E2=80=99t overfill any cache. An xTR just remembers the last = nonce that came with the E-bit set and when it returns packets it uses = that nonce. Yes, many implementations default to not setting advertising they are = echo-nonce capable in Map-Replies. So RLOC-probing tends to be used for = RLOC reachability. Plus we added features into RLOC-probing that makes = it more useful now (lisp-crypto key exchange for one). > The document does mention "... attack can be mitigated by preventing = RLOC > spoofing in the network by deploying uRPF BCP 38 [RFC2827]." - while = that may > be true for many of the above, BCP38 is far from being universally = deployed, > and this feels similar to solving world hunger by saying everyone must = have > enough food. :-) An ETR can verify mappings if it chooses to. The more overhead you want = to put in the system for anti-spoofing, one can do. Tradeoffs. By the way food is everywhere, you just have to be willing to eat it. = ;-) > Again, apologies if I've completely misunderstood something, clue-bat = gladly > accepted=E2=80=A6 You did a pretty good job. Thanks. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Comments: > 1: "LISP Locator-Status-Bits (LSBs): ... The field is 32 bits when = the I-bit > is set to 0 and is 8 bits when the I-bit is set to 1." - I think I'm = missing > something fairly fundamental here (and in Section 10, 13.1, and = others) - if > I'm using the I bit, it sounds like I can only have 8 ETRs? And with = this clear > I can only have 32? I feel like I must have missed something=E2=80=A6. Right 8 ETRs per EID-prefix. If you needed more, then you take the = EID-prefix and cut it in half and increase the mask-length by 1, then = you can use a different set of 8 for each more specific EID-prefix. = Otherwise, you use RLOC-probing and the number of RLOCs can bee up to = 255 (the width of the RLOC-Count field in an EID-record). > 2: "When the =E2=80=99DF=E2=80=99 field of the IP header is set to 1, = or the packet is an IPv6 > packet originated by the source host, the ITR will drop the packet = when the > size is greater than L and send an ICMPv4..." I think this needs to = say when > the resulting (or encapsulated) packet is greater than L (otherwise it = is > unclear if you are referring to the original or resulting packet). Yes, I will clarify. Great point. > 3: "The server-side sets a Weight of zero for the RLOC subset list. In = this > case, the client-side can choose how the traffic load is spread = across the > subset list." -- please insert a reference to Section 12 here. I wrote = up a > long comment on what happens of the load sharing delivers packets to = different > ETRs, before finding this section later on in the document. Done. > Nits: > 1: " LISP does not require changes to either host protocol stack or to = underlay > routers. " -- I think either "to either the host protocol stack" or " = to either > host protocol stacks" >=20 > 2: "As an exmple of such attacks an off-path attacker can" -- typo for = example. >=20 > 3: "it can protect itself from erroneious reachability attacks" -- = typo for > erroneous. Fixed. Thanks again, Dino --Apple-Mail=_7F48DF72-0693-4ABB-B1FB-1E54B770FE77 Content-Disposition: attachment; filename=rfcdiff-rfc6833bis-27.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-rfc6833bis-27.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-lisp-rfc6830bis-26.txt - = draft-ietf-lisp-rfc6830bis-27.txt=20 =20 =20 =20 =20 =20 =20 = = = =
< draft-ietf-lisp-rfc6830bis-26.txt  =  draft-ietf-lisp-rfc6830bis-27.txt >
=
Network Working = Group D. Farinacci = Network Working Group = D. Farinacci
Internet-Draft = V. Fuller Internet-Draft = V. Fuller
Obsoletes: 6830 = (if approved) D. Meyer = Obsoletes: 6830 (if approved) = D. Meyer
Intended status: = Standards Track D. Lewis = Intended status: Standards Track = D. Lewis
Expires: May 8, 2019 = Cisco Systems Expires: August 10, 2019 = Cisco Systems
= A. Cabellos (Ed.) = A. Cabellos (Ed.)
= UPC/BarcelonaTech = UPC/BarcelonaTech
= November = 4, 2018 = February 6, = 2019
=
= The Locator/ID Separation Protocol (LISP) The Locator/ID Separation Protocol = (LISP)
= draft-ietf-lisp-rfc6830bis-26 = = draft-ietf-lisp-rfc6830bis-27
=
Abstract = Abstract
=
This document = describes the Data-Plane protocol for the Locator/ID This document describes the Data-Plane protocol for = the Locator/ID
Separation = Protocol (LISP). LISP defines two namespaces, End-point = Separation Protocol (LISP). LISP defines = two namespaces, End-point
Identifiers = (EIDs) that identify end-hosts and Routing Locators Identifiers (EIDs) that identify end-hosts and = Routing Locators
(RLOCs) that = identify network attachment points. With this, LISP (RLOCs) that identify network attachment points. = With this, LISP
effectively = separates control from data, and allows routers to create = effectively separates control from data, and = allows routers to create
overlay = networks. LISP-capable routers exchange encapsulated packets = overlay networks. LISP-capable routers = exchange encapsulated packets
according to = EID-to-RLOC mappings stored in a local Map-Cache. according to EID-to-RLOC mappings stored in a local = Map-Cache.
=
skipping to = change at = page 1, line 46 =C2=B6 = skipping to change at page 1, line 46 =C2=B6
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
Task Force = (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also = distribute
working = documents as Internet-Drafts. The list of current Internet- = working documents as Internet-Drafts. The = list of current Internet-
Drafts is at = https://datatracker.ietf.org/drafts/current/. Drafts is at = https://datatracker.ietf.org/drafts/current/.
=
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
and may be = updated, replaced, or obsoleted by other documents at any = and may be updated, replaced, or obsoleted = by other documents at any
time. It is = inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as = reference
material or to = cite them other than as "work in progress." material or to cite them other than as "work in = progress."
=
This = Internet-Draft will expire on May 8, = 2019. This Internet-Draft will = expire on August 10, 2019.
=
Copyright = Notice Copyright Notice
=
Copyright = (c) 2018 IETF Trust and the persons = identified as the Copyright (c) = 2019 IETF Trust and the persons identified = as the
document = authors. All rights reserved. = document authors. All rights reserved.
=
This document = is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF = Trust's Legal
Provisions = Relating to IETF Documents = Provisions Relating to IETF Documents
= (https://trustee.ietf.org/license-info) in effect on the date = of = (https://trustee.ietf.org/license-info) in effect on the date of
publication of = this document. Please review these documents publication of this document. Please review these = documents
carefully, as = they describe your rights and restrictions with respect = carefully, as they describe your rights and = restrictions with respect
to this = document. Code Components extracted from this document must = to this document. Code Components extracted = from this document must
include = Simplified BSD License text as described in Section 4.e of = include Simplified BSD License text as = described in Section 4.e of
the Trust = Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without = warranty as
=
skipping to = change at = page 2, line 40 =C2=B6 = skipping to change at page 2, line 40 =C2=B6
5.2. LISP = IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 14 = 5.2. LISP IPv6-in-IPv6 Header Format . . = . . . . . . . . . . . 14
5.3. Tunnel = Header Field Descriptions . . . . . . . . . . . . 15 5.3. Tunnel Header Field Descriptions . . . . . . = . . . . . . 15
6. LISP = EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . 20 = 6. LISP EID-to-RLOC Map-Cache . . . . . . = . . . . . . . . . . . 20
7. Dealing = with Large Encapsulated Packets . . . . . . . . . . . 20 = 7. Dealing with Large Encapsulated Packets = . . . . . . . . . . . 20
7.1. A = Stateless Solution to MTU Handling . . . . . . . . . . 21 = 7.1. A Stateless Solution to MTU Handling = . . . . . . . . . . 21
7.2. A = Stateful Solution to MTU Handling . . . . . . . . . . . 22 = 7.2. A Stateful Solution to MTU Handling = . . . . . . . . . . . 22
8. Using = Virtualization and Segmentation with LISP . . . . . . . 22 = 8. Using Virtualization and Segmentation = with LISP . . . . . . . 22
9. Routing = Locator Selection . . . . . . . . . . . . . . . . . . 23 = 9. Routing Locator Selection . . . . . . . = . . . . . . . . . . . 23
10. Routing = Locator Reachability . . . . . . . . . . . . . . . . 25 = 10. Routing Locator Reachability . . . . . = . . . . . . . . . . . 25
10.1. Echo = Nonce Algorithm . . . . . . . . . . . . . . . . . . 26 = 10.1. Echo Nonce Algorithm . . . . . . . = . . . . . . . . . . . 26
11. EID = Reachability within a LISP Site . . . . . . . . . . . . . 27 11. EID = Reachability within a LISP Site . . . . . . . . . . . . . 28
12. Routing = Locator Hashing . . . . . . . . . . . . . . . . . . . 28 = 12. Routing Locator Hashing . . . . . . . . = . . . . . . . . . . . 28
13. Changing = the Contents of EID-to-RLOC Mappings . . . . . . . . 29 = 13. Changing the Contents of EID-to-RLOC = Mappings . . . . . . . . 29
13.1. = Database Map-Versioning . . . . . . . . . . . . . . . . 30 = 13.1. Database Map-Versioning . . . . . = . . . . . . . . . . . 30
14. Multicast = Considerations . . . . . . . . . . . . . . . . . . 31 = 14. Multicast Considerations . . . . . . . = . . . . . . . . . . . 31
15. Router = Performance Considerations . . . . . . . . . . . . . . 31 15. = Router Performance Considerations . . . . . . . . . . . . . . 32
16. Security = Considerations . . . . . . . . . . . . . . . . . . . 32 = 16. Security Considerations . . . . . . . . = . . . . . . . . . . . 32
17. Network = Management Considerations . . . . . . . . . . . . . . 33 = 17. Network Management Considerations . . . = . . . . . . . . . . . 33
18. Changes = since RFC 6830 . . . . . . . . . . . . . . . . . . . 33 = 18. Changes since RFC 6830 . . . . . . . . = . . . . . . . . . . . 33
19. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 34 = 19. IANA Considerations . . . . . . . . . . = . . . . . . . . . . . 34
19.1. LISP = UDP Port Numbers . . . . . . . . . . . . . . . . . 34 = 19.1. LISP UDP Port Numbers . . . . . . = . . . . . . . . . . . 34
20. References = . . . . . . . . . . . . . . . . . . . . . . . . . 34 20. References . . . . . . . . . . . . . . . . . . . = . . . . . . 34
20.1. = Normative References . . . . . . . . . . . . . . . . . . 34 = 20.1. Normative References . . . . . . . = . . . . . . . . . . . 34
20.2. = Informative References . . . . . . . . . . . . . . . . . 35 20.2. = Informative References . . . . . . . . . . . . . . . . . 36
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 39 = Appendix A. Acknowledgments . . . . . . . = . . . . . . . . . . . 39
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 40 = Appendix B. Document Change Log . . . . . = . . . . . . . . . . . 40
B.1. = Changes to draft-ietf-lisp-rfc6830bis-26 = . . . . . . . . 40 B.1. = Changes to draft-ietf-lisp-rfc6830bis-27 = . . . . . . . . 40
B.2. = Changes to draft-ietf-lisp-rfc6830bis-25 = . . . . . . . . 40 B.2. = Changes to draft-ietf-lisp-rfc6830bis-26 = . . . . . . . . 40
B.3. = Changes to draft-ietf-lisp-rfc6830bis-24 = . . . . . . . . 40 B.3. = Changes to draft-ietf-lisp-rfc6830bis-25 = . . . . . . . . 40
B.4. = Changes to draft-ietf-lisp-rfc6830bis-23 = . . . . . . . . 40 B.4. = Changes to draft-ietf-lisp-rfc6830bis-24 = . . . . . . . . 40
B.5. = Changes to draft-ietf-lisp-rfc6830bis-22 = . . . . . . . . 40 B.5. = Changes to draft-ietf-lisp-rfc6830bis-23 = . . . . . . . . 40
B.6. = Changes to draft-ietf-lisp-rfc6830bis-21 = . . . . . . . . 40 B.6. = Changes to draft-ietf-lisp-rfc6830bis-22 = . . . . . . . . 40
B.7. = Changes to draft-ietf-lisp-rfc6830bis-20 = . . . . . . . . 41 B.7. = Changes to draft-ietf-lisp-rfc6830bis-21 = . . . . . . . . 41
B.8. = Changes to draft-ietf-lisp-rfc6830bis-19 = . . . . . . . . 41 B.8. = Changes to draft-ietf-lisp-rfc6830bis-20 = . . . . . . . . 41
B.9. = Changes to draft-ietf-lisp-rfc6830bis-18 = . . . . . . . . 41 B.9. = Changes to draft-ietf-lisp-rfc6830bis-19 = . . . . . . . . 41
B.10. = Changes to draft-ietf-lisp-rfc6830bis-17 = . . . . . . . . 41 B.10. = Changes to draft-ietf-lisp-rfc6830bis-18 = . . . . . . . . 41
B.11. = Changes to draft-ietf-lisp-rfc6830bis-16 = . . . . . . . . 41 B.11. = Changes to draft-ietf-lisp-rfc6830bis-17 = . . . . . . . . 41
B.12. = Changes to draft-ietf-lisp-rfc6830bis-15 = . . . . . . . . 41 B.12. = Changes to draft-ietf-lisp-rfc6830bis-16 = . . . . . . . . 41
B.13. = Changes to draft-ietf-lisp-rfc6830bis-14 . . . . . . . . 42 = B.13. Changes to draft-ietf-lisp-rfc6830bis-15 . . . . . . . . = 41
B.14. Changes to draft-ietf-lisp-rfc6830bis-13 = . . . . . . . . 42 B.14. Changes to = draft-ietf-lisp-rfc6830bis-14 . . . . . . . . 42
B.15. Changes to draft-ietf-lisp-rfc6830bis-12 = . . . . . . . . 42 B.15. Changes to draft-ietf-lisp-rfc6830bis-13 = . . . . . . . . 42
B.16. Changes to draft-ietf-lisp-rfc6830bis-11 = . . . . . . . . 42 B.16. Changes to draft-ietf-lisp-rfc6830bis-12 = . . . . . . . . 42
B.17. Changes to draft-ietf-lisp-rfc6830bis-10 = . . . . . . . . 42 B.17. Changes to draft-ietf-lisp-rfc6830bis-11 = . . . . . . . . 42
B.18. Changes to draft-ietf-lisp-rfc6830bis-09 = . . . . . . . . 43 B.18. Changes to draft-ietf-lisp-rfc6830bis-10 = . . . . . . . . 42
B.19. Changes to draft-ietf-lisp-rfc6830bis-08 = . . . . . . . . 43 B.19. Changes to draft-ietf-lisp-rfc6830bis-09 = . . . . . . . . 43
B.20. Changes to draft-ietf-lisp-rfc6830bis-07 = . . . . . . . . 43 B.20. Changes to draft-ietf-lisp-rfc6830bis-08 = . . . . . . . . 43
B.21. Changes to draft-ietf-lisp-rfc6830bis-06 = . . . . . . . . 43 B.21. Changes to draft-ietf-lisp-rfc6830bis-07 = . . . . . . . . 43
B.22. Changes to draft-ietf-lisp-rfc6830bis-05 = . . . . . . . . 44 B.22. Changes to draft-ietf-lisp-rfc6830bis-06 = . . . . . . . . 43
B.23. Changes to draft-ietf-lisp-rfc6830bis-04 = . . . . . . . . 44 B.23. Changes to draft-ietf-lisp-rfc6830bis-05 = . . . . . . . . 44
B.24. Changes to draft-ietf-lisp-rfc6830bis-03 = . . . . . . . . 44 B.24. Changes to draft-ietf-lisp-rfc6830bis-04 = . . . . . . . . 44
B.25. Changes to draft-ietf-lisp-rfc6830bis-02 = . . . . . . . . 44 B.25. Changes to draft-ietf-lisp-rfc6830bis-03 = . . . . . . . . 44
B.26. Changes to draft-ietf-lisp-rfc6830bis-01 = . . . . . . . . 44 B.26. Changes to draft-ietf-lisp-rfc6830bis-02 = . . . . . . . . 44
B.27. Changes to draft-ietf-lisp-rfc6830bis-00 = . . . . . . . . 45 B.27. Changes to draft-ietf-lisp-rfc6830bis-01 = . . . . . . . . 44
= B.28. = Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 45
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 = Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 45
=
1. = Introduction 1. Introduction
=
This document = describes the Locator/Identifier Separation Protocol This document describes the Locator/Identifier = Separation Protocol
(LISP). LISP = is an encapsulation protocol built around the (LISP). LISP is an encapsulation protocol built = around the
fundamental = idea of separating the topological location of a network = fundamental idea of separating the = topological location of a network
attachment = point from the node's identity [CHIAPPA]. As a result attachment point from the node's identity [CHIAPPA]. = As a result
LISP creates = two namespaces: Endpoint Identifiers (EIDs), that are LISP creates two namespaces: Endpoint Identifiers = (EIDs), that are
used to = identify end-hosts (e.g., nodes or Virtual Machines) and = used to identify end-hosts (e.g., nodes or = Virtual Machines) and
=
skipping to = change at = page 4, line 13 =C2=B6 = skipping to change at page 4, line 13 =C2=B6
provisioning = is required or necessary. = provisioning is required or necessary.
=
LISP is an = overlay protocol that separates control from Data-Plane, = LISP is an overlay protocol that separates = control from Data-Plane,
this document = specifies the Data-Plane, how LISP-capable routers this document specifies the Data-Plane, how = LISP-capable routers
(Tunnel = Routers) exchange packets by encapsulating them to the (Tunnel Routers) exchange packets by encapsulating = them to the
appropriate = location. Tunnel routers are equipped with a cache, appropriate location. Tunnel routers are equipped = with a cache,
called = Map-Cache, that contains EID-to-RLOC mappings. The Map-Cache = called Map-Cache, that contains EID-to-RLOC = mappings. The Map-Cache
is populated = using the LISP Control-Plane protocol = is populated using the LISP Control-Plane protocol
= [I-D.ietf-lisp-rfc6833bis]. = [I-D.ietf-lisp-rfc6833bis].
=
LISP does = not require changes to either host protocol stack or to = LISP does not require changes to either = the host protocol stack or to
underlay = routers. By separating the EID from the RLOC space, LISP = underlay routers. By separating the EID = from the RLOC space, LISP
offers native = Traffic Engineering, multihoming and mobility, among offers native Traffic Engineering, multihoming and = mobility, among
other = features. other features.
=
Creation of = LISP was initially motivated by discussions during the Creation of LISP was initially motivated by = discussions during the
IAB-sponsored = Routing and Addressing Workshop held in Amsterdam in IAB-sponsored Routing and Addressing Workshop held in = Amsterdam in
October 2006 = (see [RFC4984]). October 2006 (see = [RFC4984]).
=
This document = specifies the LISP Data-Plane encapsulation and other This document specifies the LISP Data-Plane = encapsulation and other
LISP = forwarding node functionality while [I-D.ietf-lisp-rfc6833bis] = LISP forwarding node functionality while = [I-D.ietf-lisp-rfc6833bis]
=
skipping to = change at = page 21, line 49 =C2=B6 = skipping to change at page 21, line = 49 =C2=B6
then forwards = each fragment to the destination host of the then forwards each fragment to the destination host = of the
destination = site. The two fragments are reassembled at the destination site. The two fragments are reassembled = at the
destination = host into the single IP datagram that was originated by = destination host into the single IP datagram = that was originated by
the source = host. Note that reassembly can happen at the ETR if the = the source host. Note that reassembly can = happen at the ETR if the
encapsulated = packet was fragmented at or after the ITR. encapsulated packet was fragmented at or after the = ITR.
=
This behavior = MUST be performed by the ITR only when the source host This behavior MUST be performed by the ITR only when = the source host
originates a = packet with the 'DF' field of the IP header set to 0. originates a packet with the 'DF' field of the IP = header set to 0.
When the 'DF' = field of the IP header is set to 1, or the packet is an = When the 'DF' field of the IP header is set = to 1, or the packet is an
IPv6 packet = originated by the source host, the ITR will drop the IPv6 packet originated by the source host, the ITR = will drop the
packet when = the size is greater than L and send an ICMPv4 ICMP packet when the size (adding = in the size of the encapsulation header)
Unreachable/Fragmentation-Needed or ICMPv6 = "Packet Too Big" message is = greater than L and send an ICMPv4 ICMP Unreachable/Fragmentation-
to the = source with a value of S, where S is (L - H). Needed or ICMPv6 = "Packet Too Big" message to the source with a value
= of S, where S is (L - H).
=
When the = outer-header encapsulation uses an IPv4 header, an When the outer-header encapsulation uses an IPv4 = header, an
implementation = SHOULD set the DF bit to 1 so ETR fragment reassembly implementation SHOULD set the DF bit to 1 so ETR = fragment reassembly
can be = avoided. An implementation MAY set the DF bit in such headers = can be avoided. An implementation MAY set = the DF bit in such headers
to 0 if it has = good reason to believe there are unresolvable path MTU to 0 if it has good reason to believe there are = unresolvable path MTU
issues between = the sending ITR and the receiving ETR. = issues between the sending ITR and the receiving ETR.
=
This = specification RECOMMENDS that L be defined as 1500. This specification RECOMMENDS that L be defined as = 1500.
=
7.2. A Stateful = Solution to MTU Handling 7.2. A = Stateful Solution to MTU Handling
=
skipping to = change at = page 24, line 14 =C2=B6 = skipping to change at page 24, line = 19 =C2=B6
splitting = across its members. The client-side can use RLOCs splitting across its members. The client-side can = use RLOCs
outside of = the subset list if it determines that the subset list outside of the subset list if it determines that = the subset list
is = unreachable (unless RLOCs are set to a Priority of 255). Some = is unreachable (unless RLOCs are set to a = Priority of 255). Some
sharing of = control exists: the server-side determines the sharing of control exists: the server-side = determines the
destination = RLOC list and load distribution while the client-side destination RLOC list and load distribution while = the client-side
has the = option of using alternatives to this list if RLOCs in the = has the option of using alternatives to = this list if RLOCs in the
list are = unreachable. list are = unreachable.
=
o The = server-side sets a Weight of zero for the RLOC subset list. = o The server-side sets a Weight of zero for = the RLOC subset list.
In this = case, the client-side can choose how the traffic load is = In this case, the client-side can choose = how the traffic load is
spread = across the subset list. Control is shared by the server- = spread across the subset list. See Section 12 = for details on
side determining the list and the = client-side determining load load-sharing mechanisms. Control is = shared by the server-side
= determining the list and the client-side = determining load
= distribution. Again, the client can use alternative RLOCs if = the distribution. Again, the = client can use alternative RLOCs if the
= server-provided list of RLOCs is unreachable. server-provided list of RLOCs is = unreachable.
=
o Either side = (more likely the server-side ETR) decides not to send o Either side (more likely the server-side ETR) = decides not to send
a = Map-Request. For example, if the server-side ETR does not send = a Map-Request. For example, if the = server-side ETR does not send
= Map-Requests, it gleans RLOCs from the client-side ITR, giving = the Map-Requests, it gleans = RLOCs from the client-side ITR, giving the
client-side = ITR responsibility for bidirectional RLOC reachability client-side ITR responsibility for bidirectional = RLOC reachability
and = preferability. Server-side ETR gleaning of the client-side = and preferability. Server-side ETR = gleaning of the client-side
ITR RLOC is = done by caching the inner-header source EID and the ITR RLOC is done by caching the inner-header = source EID and the
= outer-header source RLOC of received packets. The client-side = ITR outer-header source RLOC of = received packets. The client-side ITR
=
skipping to = change at = page 33, line 5 =C2=B6 = skipping to change at page 33, line = 13 =C2=B6
overloading = it. overloading it.
=
The LISP = Data-Plane defines several mechanisms to monitor RLOC Data- = The LISP Data-Plane defines several = mechanisms to monitor RLOC Data-
Plane = reachability, in this context Locator-Status Bits, Nonce- = Plane reachability, in this context = Locator-Status Bits, Nonce-
Present and = Echo-Nonce bits of the LISP encapsulation header can be = Present and Echo-Nonce bits of the LISP = encapsulation header can be
manipulated by = an attacker to mount a DoS attack. An off-path manipulated by an attacker to mount a DoS attack. An = off-path
attacker able = to spoof the RLOC and/or nonce of a victim's xTR can attacker able to spoof the RLOC and/or nonce of a = victim's xTR can
manipulate = such mechanisms to declare false information about the manipulate such mechanisms to declare false = information about the
RLOC's = reachability status. RLOC's = reachability status.
=
As an exmple of such attacks an off-path = attacker can exploit the For exmple of such attacks, an off-path attacker = can exploit the
echo-nonce = mechanism by sending data packets to an ITR with a random = echo-nonce mechanism by sending data packets = to an ITR with a random
nonce from an = ETR's spoofed RLOC. Note the attacker must guess a nonce from an ETR's spoofed RLOC. Note the attacker = must guess a
valid nonce = the ITR is requesting to be echoed within a small window = valid nonce the ITR is requesting to be = echoed within a small window
of time. The = goal is to convince the ITR that the ETR's RLOC is of time. The goal is to convince the ITR that the = ETR's RLOC is
reachable even = when it may not be reachable. If the attack is reachable even when it may not be reachable. If the = attack is
successful, = the ITR believes the wrong reachability status of the successful, the ITR believes the wrong reachability = status of the
ETR's RLOC = until RLOC-probing detects the correct status. This time = ETR's RLOC until RLOC-probing detects the = correct status. This time
frame is on = the order of 10s of seconds. This specific attack can be = frame is on the order of 10s of seconds. = This specific attack can be
mitigated by = preventing RLOC spoofing in the network by deploying mitigated by preventing RLOC spoofing in the network = by deploying
uRPF BCP 38 = [RFC2827]. In addition and in order to exploit this uRPF BCP 38 [RFC2827]. In addition and in order to = exploit this
vulnerability, = the off-path attacker must send echo-nonce packets at vulnerability, the off-path attacker must send = echo-nonce packets at
high rate. If = the nonces have never been requested by the ITR, it high rate. If the nonces have never been requested = by the ITR, it
can protect = itself from erroneious reachability = attacks. can protect itself from = erroneous reachability attacks.
=
Map-Versioning = is a Data-Plane mechanism used to signal a peering xTR Map-Versioning is a Data-Plane mechanism used to = signal a peering xTR
that a local = EID-to-RLOC mapping has been updated, so that the that a local EID-to-RLOC mapping has been updated, so = that the
peering xTR = uses LISP Control-Plane signaling message to retrieve a = peering xTR uses LISP Control-Plane = signaling message to retrieve a
fresh mapping. = This can be used by an attacker to forge the map- fresh mapping. This can be used by an attacker to = forge the map-
versioning = field of a LISP encapsulated header and force an excessive = versioning field of a LISP encapsulated = header and force an excessive
amount of = signaling between xTRs that may overload them. amount of signaling between xTRs that may overload = them.
=
Most of the = attack vectors can be mitigated with careful deployment = Most of the attack vectors can be mitigated = with careful deployment
and = configuration, information learned opportunistically (such as = LSB and configuration, information = learned opportunistically (such as LSB
=
skipping to = change at = page 34, line 44 =C2=B6 = skipping to change at page 35, line 8 =C2=B6
20.1. Normative = References 20.1. Normative = References
=
= [I-D.ietf-lisp-6834bis] = [I-D.ietf-lisp-6834bis]
= Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID = Iannone, L., Saucez, D., and O. = Bonaventure, "Locator/ID
= Separation Protocol (LISP) Map-Versioning", draft-ietf- = Separation Protocol (LISP) = Map-Versioning", draft-ietf-
= lisp-6834bis-02 (work in progress), September 2018. lisp-6834bis-02 (work in progress), = September 2018.
=
= [I-D.ietf-lisp-rfc6833bis] = [I-D.ietf-lisp-rfc6833bis]
= Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, Fuller, V., Farinacci, D., and A. = Cabellos-Aparicio,
= "Locator/ID Separation Protocol (LISP) Control-Plane", "Locator/ID Separation Protocol (LISP) = Control-Plane",
= draft-ietf-lisp-rfc6833bis-19 (work in = progress), October draft-ietf-lisp-rfc6833bis-24 (work in = progress), February
2018. = 2019.
=
[RFC0768] = Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD = 6, RFC 768,
DOI = 10.17487/RFC0768, August 1980, = DOI 10.17487/RFC0768, August 1980,
= <https://www.rfc-editor.org/info/rfc768>. = <https://www.rfc-editor.org/info/rfc768>.
=
[RFC0791] = Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, = RFC 791,
DOI = 10.17487/RFC0791, September 1981, = DOI 10.17487/RFC0791, September 1981,
= <https://www.rfc-editor.org/info/rfc791>. = <https://www.rfc-editor.org/info/rfc791>.
=
[RFC2119] = Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to = Indicate
=
skipping to = change at = page 36, line 13 =C2=B6 = skipping to change at page 36, line = 22 =C2=B6
= <http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>. = = <http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>.
=
= [I-D.ietf-lisp-introduction] = [I-D.ietf-lisp-introduction]
= Cabellos-Aparicio, A. and D. Saucez, "An Architectural Cabellos-Aparicio, A. and D. Saucez, "An = Architectural
= Introduction to the Locator/ID Separation Protocol Introduction to the Locator/ID Separation = Protocol
= (LISP)", draft-ietf-lisp-introduction-13 (work in (LISP)", draft-ietf-lisp-introduction-13 = (work in
= progress), April 2015. = progress), April 2015.
=
= [I-D.ietf-lisp-vpn] = [I-D.ietf-lisp-vpn]
= Moreno, V. and D. Farinacci, "LISP Virtual Private Moreno, V. and D. Farinacci, "LISP Virtual = Private
= Networks (VPNs)", draft-ietf-lisp-vpn-02 = (work in Networks = (VPNs)", draft-ietf-lisp-vpn-03 (work = in
= progress), May 2018. progress), November 2018.
=
= [OPENLISP] [OPENLISP]
= Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP Iannone, L., Saucez, D., and O. = Bonaventure, "OpenLISP
= Implementation Report", Work in Progress, July 2008. Implementation Report", Work in Progress, = July 2008.
=
[RFC1034] = Mockapetris, P., "Domain names - concepts and facilities", = [RFC1034] Mockapetris, P., "Domain names - = concepts and facilities",
STD = 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, = November 1987,
= <https://www.rfc-editor.org/info/rfc1034>. = <https://www.rfc-editor.org/info/rfc1034>.
=
[RFC1918] = Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., = [RFC1918] Rekhter, Y., Moskowitz, B., = Karrenberg, D., de Groot, G.,
=
skipping = to change at page 40, line = 12 =C2=B6 = skipping to change at page 40, line = 12 =C2=B6
Kaduk, Eric = Rescorla, Alvaro Retana, Alexey Melnikov, Alissa Cooper, = Kaduk, Eric Rescorla, Alvaro Retana, Alexey = Melnikov, Alissa Cooper,
Suresh = Krishnan, Alberto Rodriguez-Natal, Vina Ermagen, Mohamed = Suresh Krishnan, Alberto Rodriguez-Natal, = Vina Ermagen, Mohamed
Boucadair, = Brian Trammell, Sabrina Tanamal, and John Drake. The Boucadair, Brian Trammell, Sabrina Tanamal, and John = Drake. The
contributions = they offered greatly added to the security, scale, and contributions they offered greatly added to the = security, scale, and
robustness of = the LISP architecture and protocols. = robustness of the LISP architecture and protocols.
=
Appendix B. = Document Change Log Appendix B. = Document Change Log
=
[RFC Editor: = Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on = publication as RFC.]
=
B.1. Changes = to draft-ietf-lisp-rfc6830bis-26 B.1. = Changes to draft-ietf-lisp-rfc6830bis-27
=
= o Posted February = 2019 just before Thu telechat.
=
= o Made editorial = corrections per Warren's suggestions.
=
= B.2. Changes to = draft-ietf-lisp-rfc6830bis-26
=
o Posted late = October 2018. o Posted late = October 2018.
=
o Changed = description about "reserved" bits to state "reserved and = o Changed description about "reserved" bits = to state "reserved and
= unassigned". = unassigned".
=
B.2. Changes to = draft-ietf-lisp-rfc6830bis-25 B.3. Changes to = draft-ietf-lisp-rfc6830bis-25
=
o Posted mid = October 2018. o Posted mid October = 2018.
=
o Added more = to the Security Considerations section with discussion o Added more to the Security Considerations section = with discussion
about = echo-nonce attacks. about = echo-nonce attacks.
=
B.3. Changes to = draft-ietf-lisp-rfc6830bis-24 B.4. Changes to = draft-ietf-lisp-rfc6830bis-24
=
o Posted mid = October 2018. o Posted mid October = 2018.
=
o Final = editorial changes for Eric and Ben. = o Final editorial changes for Eric and Ben.
=
B.4. Changes to = draft-ietf-lisp-rfc6830bis-23 B.5. Changes to = draft-ietf-lisp-rfc6830bis-23
=
o Posted = early October 2018. o Posted early = October 2018.
=
o Added an = applicability statement in section 1 to address security = o Added an applicability statement in = section 1 to address security
concerns = from Telechat. concerns from = Telechat.
=
B.5. Changes to = draft-ietf-lisp-rfc6830bis-22 B.6. Changes to = draft-ietf-lisp-rfc6830bis-22
=
o Posted = early October 2018. o Posted early = October 2018.
=
o Changes to = reflect comments post Telechat. o = Changes to reflect comments post Telechat.
=
B.6. Changes to = draft-ietf-lisp-rfc6830bis-21 B.7. Changes to = draft-ietf-lisp-rfc6830bis-21
=
o Posted = late-September 2018. o Posted = late-September 2018.
=
o Changes to = reflect comments from Sep 27th Telechat. o Changes to reflect comments from Sep 27th = Telechat.
=
B.7. Changes to = draft-ietf-lisp-rfc6830bis-20 B.8. Changes to = draft-ietf-lisp-rfc6830bis-20
=
o Posted = late-September 2018. o Posted = late-September 2018.
=
o Fix old = reference to RFC3168, changed to RFC6040. o Fix old reference to RFC3168, changed to = RFC6040.
=
B.8. Changes to = draft-ietf-lisp-rfc6830bis-19 B.9. Changes to = draft-ietf-lisp-rfc6830bis-19
=
o Posted = late-September 2018. o Posted = late-September 2018.
=
o More = editorial changes. o More = editorial changes.
=
B.9. Changes to = draft-ietf-lisp-rfc6830bis-18 B.10. Changes to = draft-ietf-lisp-rfc6830bis-18
=
o Posted = mid-September 2018. o Posted = mid-September 2018.
=
o Changes to = reflect comments from Secdir review (Mirja). o Changes to reflect comments from Secdir review = (Mirja).
=
B.10. Changes to = draft-ietf-lisp-rfc6830bis-17 B.11. Changes to = draft-ietf-lisp-rfc6830bis-17
=
o Posted = September 2018. o Posted September = 2018.
=
o Indicate in = the "Changes since RFC 6830" section why the document o Indicate in the "Changes since RFC 6830" section = why the document
has been = shortened in length. has been = shortened in length.
=
o Make = reference to RFC 8085 about UDP congestion control. o Make reference to RFC 8085 about UDP congestion = control.
=
o More = editorial changes from multiple IESG reviews. o More editorial changes from multiple IESG = reviews.
=
B.11. Changes to = draft-ietf-lisp-rfc6830bis-16 B.12. Changes to = draft-ietf-lisp-rfc6830bis-16
=
o Posted late = August 2018. o Posted late August = 2018.
=
o Distinguish = the message type names between ICMP for IPv4 and ICMP o Distinguish the message type names between ICMP = for IPv4 and ICMP
for IPv6 = for handling MTU issues. for = IPv6 for handling MTU issues.
=
B.12. Changes to = draft-ietf-lisp-rfc6830bis-15 B.13. Changes to = draft-ietf-lisp-rfc6830bis-15
=
o Posted = August 2018. o Posted August = 2018.
=
o Final = editorial changes before RFC submission for Proposed o Final editorial changes before RFC submission for = Proposed
= Standard. Standard.
=
o Added = section "Changes since RFC 6830" so implementers are o Added section "Changes since RFC 6830" so = implementers are
informed of = any changes since the last RFC publication. informed of any changes since the last RFC = publication.
=
B.13. Changes to = draft-ietf-lisp-rfc6830bis-14 B.14. Changes to = draft-ietf-lisp-rfc6830bis-14
=
o Posted July = 2018 IETF week. o Posted July 2018 = IETF week.
=
o Put = obsolete of RFC 6830 in Intro section in addition to abstract. = o Put obsolete of RFC 6830 in Intro section = in addition to abstract.
=
B.14. Changes to = draft-ietf-lisp-rfc6830bis-13 B.15. Changes to = draft-ietf-lisp-rfc6830bis-13
=
o Posted = March IETF Week 2018. o Posted = March IETF Week 2018.
=
o Clarified = that a new nonce is required per RLOC. = o Clarified that a new nonce is required per RLOC.
=
o Removed = 'Clock Sweep' section. This text must be placed in a new = o Removed 'Clock Sweep' section. This text = must be placed in a new
OAM = document. OAM document.
=
o Some = references changed from normative to informative o Some references changed from normative to = informative
=
B.15. Changes to = draft-ietf-lisp-rfc6830bis-12 B.16. Changes to = draft-ietf-lisp-rfc6830bis-12
=
o Posted July = 2018. o Posted July 2018.
=
o Fixed Luigi = editorial comments to ready draft for RFC status. o Fixed Luigi editorial comments to ready draft for = RFC status.
=
B.16. Changes to = draft-ietf-lisp-rfc6830bis-11 B.17. Changes to = draft-ietf-lisp-rfc6830bis-11
=
o Posted = March 2018. o Posted March = 2018.
=
o Removed = sections 16, 17 and 18 (Mobility, Deployment and o Removed sections 16, 17 and 18 (Mobility, = Deployment and
Traceroute = considerations). This text must be placed in a new OAM = Traceroute considerations). This text = must be placed in a new OAM
= document. document.
=
B.17. Changes to = draft-ietf-lisp-rfc6830bis-10 B.18. Changes to = draft-ietf-lisp-rfc6830bis-10
=
o Posted = March 2018. o Posted March = 2018.
=
o Updated = section 'Router Locator Selection' stating that the Data- = o Updated section 'Router Locator = Selection' stating that the Data-
Plane MUST = follow what's stored in the Map-Cache (priorities and Plane MUST follow what's stored in the Map-Cache = (priorities and
= weights). weights).
=
o Section = 'Routing Locator Reachability': Removed bullet point 2 o Section 'Routing Locator Reachability': Removed = bullet point 2
(ICMP = Network/Host Unreachable),3 (hints from BGP),4 (ICMP Port = (ICMP Network/Host Unreachable),3 (hints = from BGP),4 (ICMP Port
= Unreachable),5 (receive a Map-Reply as a response) and RLOC = Unreachable),5 (receive a Map-Reply as a = response) and RLOC
= probing probing
=
o Removed = 'Solicit-Map Request'. o Removed = 'Solicit-Map Request'.
=
B.18. Changes to = draft-ietf-lisp-rfc6830bis-09 B.19. Changes to = draft-ietf-lisp-rfc6830bis-09
=
o Posted = January 2018. o Posted January = 2018.
=
o Add more = details in section 5.3 about DSCP processing during o Add more details in section 5.3 about DSCP = processing during
= encapsulation and decapsulation. = encapsulation and decapsulation.
=
o Added = clarity to definitions in the Definition of Terms section = o Added clarity to definitions in the = Definition of Terms section
from = various commenters. from various = commenters.
=
o Removed PA = and PI definitions from Definition of Terms section. o Removed PA and PI definitions from Definition of = Terms section.
=
o More = editorial changes. o More = editorial changes.
=
o Removed = 4342 from IANA section and move to RFC6833 IANA section. = o Removed 4342 from IANA section and move = to RFC6833 IANA section.
=
B.19. Changes to = draft-ietf-lisp-rfc6830bis-08 B.20. Changes to = draft-ietf-lisp-rfc6830bis-08
=
o Posted = January 2018. o Posted January = 2018.
=
o Remove = references to research work for any protocol mechanisms. = o Remove references to research work for = any protocol mechanisms.
=
o Document = scanned to make sure it is RFC 2119 compliant. o Document scanned to make sure it is RFC 2119 = compliant.
=
o Made = changes to reflect comments from document WG shepherd Luigi = o Made changes to reflect comments from = document WG shepherd Luigi
= Iannone. Iannone.
=
o Ran IDNITs = on the document. o Ran IDNITs on = the document.
=
B.20. Changes to = draft-ietf-lisp-rfc6830bis-07 B.21. Changes to = draft-ietf-lisp-rfc6830bis-07
=
o Posted = November 2017. o Posted November = 2017.
=
o Rephrase = how Instance-IDs are used and don't refer to [RFC1918] o Rephrase how Instance-IDs are used and don't refer = to [RFC1918]
= addresses. addresses.
=
B.21. Changes to = draft-ietf-lisp-rfc6830bis-06 B.22. Changes to = draft-ietf-lisp-rfc6830bis-06
=
o Posted = October 2017. o Posted October = 2017.
=
o Put RTR = definition before it is used. o = Put RTR definition before it is used.
=
o Rename = references that are now working group drafts. o Rename references that are now working group = drafts.
=
o Remove = "EIDs MUST NOT be used as used by a host to refer to other = o Remove "EIDs MUST NOT be used as used by = a host to refer to other
hosts. = Note that EID blocks MAY LISP RLOCs". = hosts. Note that EID blocks MAY LISP RLOCs".
=
=
skipping = to change at page 44, line = 15 =C2=B6 = skipping to change at page 44, line = 15 =C2=B6
o ETRs may, = rather than will, be the ones to send Map-Replies. o ETRs may, rather than will, be the ones to send = Map-Replies.
=
o Recommend, = rather than mandate, max encapsulation headers to 2. o Recommend, rather than mandate, max encapsulation = headers to 2.
=
o Reference = VPN draft when introducing Instance-ID. = o Reference VPN draft when introducing Instance-ID.
=
o Indicate = that SMRs can be sent when ITR/ETR are in the same node. = o Indicate that SMRs can be sent when = ITR/ETR are in the same node.
=
o Clarify = when private addresses can be used. = o Clarify when private addresses can be used.
=
B.22. Changes to = draft-ietf-lisp-rfc6830bis-05 B.23. Changes to = draft-ietf-lisp-rfc6830bis-05
=
o Posted = August 2017. o Posted August = 2017.
=
o Make it = clear that a Re-encapsulating Tunnel Router is an RTR. o Make it clear that a Re-encapsulating Tunnel = Router is an RTR.
=
B.23. Changes to = draft-ietf-lisp-rfc6830bis-04 B.24. Changes to = draft-ietf-lisp-rfc6830bis-04
=
o Posted July = 2017. o Posted July 2017.
=
o Changed = reference of IPv6 RFC2460 to RFC8200. = o Changed reference of IPv6 RFC2460 to RFC8200.
=
o Indicate = that the applicability statement for UDP zero checksums = o Indicate that the applicability statement = for UDP zero checksums
over IPv6 = adheres to RFC6936. over IPv6 = adheres to RFC6936.
=
B.24. Changes to = draft-ietf-lisp-rfc6830bis-03 B.25. Changes to = draft-ietf-lisp-rfc6830bis-03
=
o Posted May = 2017. o Posted May 2017.
=
o Move the = control-plane related codepoints in the IANA o Move the control-plane related codepoints in the = IANA
= Considerations section to RFC6833bis. = Considerations section to RFC6833bis.
=
B.25. Changes to = draft-ietf-lisp-rfc6830bis-02 B.26. Changes to = draft-ietf-lisp-rfc6830bis-02
=
o Posted = April 2017. o Posted April = 2017.
=
o Reflect = some editorial comments from Damien Sausez. o Reflect some editorial comments from Damien = Sausez.
=
B.26. Changes to = draft-ietf-lisp-rfc6830bis-01 B.27. Changes to = draft-ietf-lisp-rfc6830bis-01
=
o Posted = March 2017. o Posted March = 2017.
=
o Include = references to new RFCs published. o = Include references to new RFCs published.
=
o Change = references from RFC6833 to RFC6833bis. = o Change references from RFC6833 to RFC6833bis.
=
o Clarified = LCAF text in the IANA section. o = Clarified LCAF text in the IANA section.
=
o Remove = references to "experimental". o = Remove references to "experimental".
=
B.27. Changes to = draft-ietf-lisp-rfc6830bis-00 B.28. Changes to = draft-ietf-lisp-rfc6830bis-00
=
o Posted = December 2016. o Posted December = 2016.
=
o Created = working group document from draft-farinacci-lisp o Created working group document from = draft-farinacci-lisp
-rfc6830-00 = individual submission. No other changes made. -rfc6830-00 individual submission. No other = changes made.
=
Authors' = Addresses Authors' Addresses
=
Dino = Farinacci Dino Farinacci
Cisco = Systems Cisco Systems
 End of changes. 43 change blocks. 
74 lines changed or = deleted 83 lines changed or = added

This = html diff was produced by rfcdiff 1.47. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20 = --Apple-Mail=_7F48DF72-0693-4ABB-B1FB-1E54B770FE77 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_7F48DF72-0693-4ABB-B1FB-1E54B770FE77-- From nobody Wed Feb 6 09:57:47 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B25130EE4; Wed, 6 Feb 2019 09:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 fpvVudFng3DG; Wed, 6 Feb 2019 09:57:42 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 1C703130EA2; Wed, 6 Feb 2019 09:57:42 -0800 (PST) Received: from 200116b82cc7b500e8c6e2a2db61c90a.dip.versatel-1u1.de ([2001:16b8:2cc7:b500:e8c6:e2a2:db61:c90a]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1grRS7-00056t-9z; Wed, 06 Feb 2019 18:57:39 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <1B6E2085-FFD8-4CAA-B9BB-5CBFC5AA9745@gigix.net> Date: Wed, 6 Feb 2019 18:57:37 +0100 Cc: Dino Farinacci , The IESG , lisp-chairs@ietf.org, "lisp@ietf.org list" , draft-ietf-lisp-rfc6830bis@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <153667905625.16761.12157659372502604927.idtracker@ietfa.amsl.com> <7DEBCA24-9D55-4325-85AA-48AB3FAAB91D@gmail.com> <0201F06C-DA9E-445A-A995-54BA805B595C@kuehlewind.net> <5EC21C57-D217-48A9-AFD0-24710299CF7F@kuehlewind.net> <5A3C4B1F-EA31-4698-96F4-915A77400A56@gmail.com> <2CAF25CC-01EE-49D4-B970-F8EFB24940A8@kuehlewind.net> <5F9D8F39-871D-4A96-9C0A-7BACD2ABB1F7@gmail.com> <2DC6D38E-C46B-4D38-B093-B88720BCD550@kuehlewind.net> <0BE5C929-D2FA-4786-9F5E-0A93E7700880@gmail.com> <11FBAC13-2859-4778-84CA-B546EB669727@kuehlewind.net> <2FEB555F-16A5-4875-93ED-D14BFEEF503A@gigix.net> <1B6E2085-FFD8-4CAA-B9BB-5CBFC5AA9745@gigix.net> To: Luigi Iannone X-Mailer: Apple Mail (2.3445.9.1) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1549475862;ab2094ea; X-HE-SMSGID: 1grRS7-00056t-9z Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 17:57:45 -0000 Hi Luigi, yes that sounds great! Thanks! Mirja > Am 06.02.2019 um 17:10 schrieb Luigi Iannone : >=20 > Hi Mirja, >=20 >=20 >> On 5 Feb 2019, at 16:39, Mirja Kuehlewind (IETF) = wrote: >>=20 >> Hi Luigi, >>=20 >> I just realized that I never replied to this mail. The change below = is okay, however, it did not make it into the current version of the = draft and therefore I cannot clear my discuss. >=20 > Fair enough. >=20 > Let me sum up the changes we agree on: >=20 >=20 > Section 5.3 in the part marked as "When doing ITR/PITR = encapsulation:=E2=80=9D >=20 > OLD: > The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 > of the IPv6 'Traffic Class' field) requires special treatment in > order to avoid discarding indications of congestion [ > RFC6040 > ]. > ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner > header to the outer header. Re-encapsulation MUST copy the = 2-bit >=20 > 'ECN' field from the stripped outer header to the new outer >=20 > header. >=20 > NEW and simplified: >=20 > The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 > of the IPv6 'Traffic Class' field) requires special treatment in > order to avoid discarding indications of congestion as specified = in=20 >=20 > [RFC6040].=20 >=20 >=20 > Note the re-encapsultion test has been remove (see later on) >=20 >=20 > Section 5.3 in the part marked as "When doing ETR/PETR decapsulation:" >=20 > OLD:=20 > The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 > of the IPv6 'Traffic Class' field) requires special treatment in > order to avoid discarding indications of congestion [ > RFC6040 > ]. If > the 'ECN' field contains a congestion indication codepoint (the > value is '11', the Congestion Experienced (CE) codepoint), then > ETR decapsulation MUST copy the 2-bit 'ECN' field from the > stripped outer header to the surviving inner header that is used > to forward the packet beyond the ETR. These requirements = preserve > CE indications when a packet that uses ECN traverses a LISP = tunnel > and becomes marked with a CE indication due to congestion = between > the tunnel endpoints. Implementations exist that copy the 'ECN' > field from the outer header to the inner header even though > [ > RFC6040 > ] does not recommend this behavior. It is RECOMMENDED > that implementations change to support the behavior in [ > RFC6040]. >=20 >=20 > NEW and simplified: >=20 > The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 > of the IPv6 'Traffic Class' field) requires special treatment in > order to avoid discarding indications of congestion as specified = in=20 >=20 > [RFC6040 > ]. Note that implementations exist that copy the 'ECN' > field from the outer header to the inner header even though > [ > RFC6040 > ] does not recommend this behavior. It is RECOMMENDED > that implementations change to support the behavior in [ > RFC6040]. >=20 >=20 > In the same section drop completely the last paragraph because is a = duplicate of the above. > Replaced by a note on the re-encapsulation: >=20 > NEW (Replacing last paragraph) >=20 > Some xTRs and PxTRs performs re-encapsulation operations and need=20= > to treat the 'Explicit Congestion Notification' (ECN) in a = special way. > Because the re-encapsulation operation is a sequence of two = operations, namely=20 > a decapsulation followed by an encapsulation, the ECN bits = MUST be treated as described=20 > above for these two operations. >=20 >=20 > Does it sound OK to you? >=20 > Ciao >=20 > L. >=20 > =20 >=20 >=20 >=20 >=20 >> Please also note that the text on decapsulation is basically in the = same section twice. I recommend to remove it once and adapt the other = one accordingly. >>=20 >> Further, inline with RFC6040, you would also need to align the = re-encapsulation part. Currently the text says: >> "Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped = outer header to the new outer header.=E2=80=9C >> Usually re-encapsulation is performed by doing de-encapsulation and = then encapsulation again. The difference here would be, that if e.g. the = inner header is not-ETC but the tunnel changes the bits to ETC0 or ETC1 = this error is not further propagated, indicating ECN support where there = is not ECN support. >>=20 >> Thanks, >> Mirja >>=20 >>=20 >>=20 >>> Am 26.09.2018 um 17:27 schrieb Luigi Iannone : >>>=20 >>> Hi Mirja, >>>=20 >>> trying to follow up on this issue. >>>=20 >>> The ECN text for encapsulation is currently: >>>=20 >>> The 'Explicit Congestion Notification' (ECN) field (bits 6 and = 7 >>> of the IPv6 'Traffic Class' field) requires special treatment = in >>> order to avoid discarding indications of congestion [ >>> RFC3168 >>> ]. >>> ITR encapsulation MUST copy the 2-bit 'ECN' field from the = inner >>> header to the outer header. Re-encapsulation MUST copy the = 2-bit >>>=20 >>> 'ECN' field from the stripped outer header to the new outer >>>=20 >>> header. >>>=20 >>> Can we keep it as it is (updating the reference to 6040)? >>>=20 >>> The text for decapsulation is: >>>=20 >>> CURRENT: >>> The 'Explicit Congestion Notification' (ECN) field (bits 6 and = 7 >>> of the IPv6 'Traffic Class' field) requires special treatment = in >>> order to avoid discarding indications of congestion [ >>> RFC6040 >>> ]. If >>> the 'ECN' field contains a congestion indication codepoint (the >>> value is '11', the Congestion Experienced (CE) codepoint), then >>> ETR decapsulation MUST copy the 2-bit 'ECN' field from the >>> stripped outer header to the surviving inner header that is = used >>> to forward the packet beyond the ETR. These requirements = preserve >>> CE indications when a packet that uses ECN traverses a LISP = tunnel >>> and becomes marked with a CE indication due to congestion = between >>> the tunnel endpoints. Implementations exist that copy the = 'ECN' >>> field from the outer header to the inner header even though >>> [ >>> RFC6040 >>> ] does not recommend this behavior. It is RECOMMENDED >>> that implementations change to support the behavior in [ >>> RFC6040 >>> ]. >>>=20 >>>=20 >>> Which I suggest we shrink to: >>>=20 >>> NEW: >>>=20 >>> The 'Explicit Congestion Notification' (ECN) field (bits 6 and = 7 >>> of the IPv6 'Traffic Class' field) requires special treatment = in >>> order to avoid discarding indications of congestion [ >>> RFC6040].=20 >>> Note that implementations exist that copy the 'ECN' >>> field from the outer header to the inner header even though >>> [ >>> RFC6040 >>> ] does not recommend such behavior. It is RECOMMENDED >>> that implementations change, so to support the specifications = in [ >>> RFC6040 >>> ]. >>>=20 >>>=20 >>>=20 >>> The text above clearly states that implementations should be conform = to 6040.=20 >>>=20 >>> Is it what you were looking for? >>>=20 >>> Or am I missing something? >>>=20 >>> Ciao >>>=20 >>> L. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> On 24 Sep 2018, at 19:34, Dino Farinacci = wrote: >>>>=20 >>>> Well, the implementations are out and working. And we said in the = latest updates to consider using RFC6040. So not sure we can do much = more than that. >>>>=20 >>>> Dino >>>>=20 >>>>> On Sep 24, 2018, at 5:52 AM, Mirja Kuehlewind (IETF) = wrote: >>>>>=20 >>>>> Because they don=E2=80=99t follow RFC6040 and therefore we do = something different in some corner cases. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> Am 22.09.2018 um 06:52 schrieb Dino Farinacci = : >>>>>>=20 >>>>>>> However, I totally disagree with your comment on providing = details that are not implemented. If they are not implemented correctly, = it might even be more important to spell them out in this document, so = implementors have chance to update their (future) implementation to do = the correct thing. Having deployed implementations that are non = standard-conform always happens and in this case it is probably not = specifically problematic as it doesn=E2=80=99t impact interoperability. = However, it is important though that the spec is correct. >>>>>>=20 >>>>>> And why do you think they are implemented incorrectly?=20 >>>>>>=20 >>>>>> Dino >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 From nobody Wed Feb 6 11:01:22 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992D3130F29 for ; Wed, 6 Feb 2019 11:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-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 0JZDLPXy3NnV for ; Wed, 6 Feb 2019 11:01:15 -0800 (PST) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 02034130F35 for ; Wed, 6 Feb 2019 11:01:14 -0800 (PST) Received: by mail-wm1-x331.google.com with SMTP id a62so3621951wmh.4 for ; Wed, 06 Feb 2019 11:01:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1yoyeCH4h7+DYARx95VlYCzP2fIjYG7ZV0nn1Hskcw0=; b=Zg/obcCgiPgAErkWmM31KW1QWS6aF108WGDVlAlHyru1rYfVJz4JYc5RL2nJd3Pilg gEYNShpijo8y/TCSgZ4sH+lid5guc73xz39Zw5FzVRXjb4txfcQD9mlxUGujnKgSh7JE fdCkHR6xcKkTTXNeidfdQCKJRdVk5YWOG0BkQRY6xzLh7l4mTVJFwd3KxwFdnXIHUFYi buDOoXekFsWKk3gox2NAB4lvyF60YyzOZ0PAEKdUxLjij7G/DACxFLuKwfNFC58E/bEw 4cStCgCgrozEGhaUOw93hkCqLKWOejHytXx72pcbnjbIcPo9+ep4lT9Byj6wV+YC1Wc7 SqMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1yoyeCH4h7+DYARx95VlYCzP2fIjYG7ZV0nn1Hskcw0=; b=K3YBKRzExF5GRg/+01l6L/fjsOoU5hXhGj1xDQIygrYGQEpIacYQNkSNgA0MRvQzlu CiWvSC6qzl/TBo9CAVV6k3FZPb1KRMm1/sE1lMDMDR9c8/z55gPTu+xLzRKUelxPJpas RnMOOLCleAyHbLulR7NeL9t7zBR6LmPQVi9IUVpyvUHuc4HhCcdpqZZXDO735D1m9+hr n2l1Atv4DDvqlJ08S4WVh1QKDANxpf18ZtYvk9JkJeMdd1SudwAE+CBNJWzZ8V7AI34u STXicrfKFFQZybUyM2pm4Vn5dTK4LDFXLxT0BS4HSuZIjb1tZW0IWEw+9VHEJpXD8sPZ ucUw== X-Gm-Message-State: AHQUAuZ0cOl8ahT4LfM3i6ieyC/CZpkCA/vGIJ87uNdMskNusGksGxoO 3ncugzqG3Ou3d/ktOQbKu01cWe6jhxhDI85BYb3PtA== X-Google-Smtp-Source: AHgI3IYOQE7jLEvlgoktr7p3FgVDLENKys35H9A4jA2euAR/69AwYWi1OWKe+w4msMtlgraqc+NGSEe1CVrgDTgtJ70= X-Received: by 2002:a7b:cc13:: with SMTP id f19mr4031442wmh.83.1549479672810; Wed, 06 Feb 2019 11:01:12 -0800 (PST) MIME-Version: 1.0 References: <154941971479.32132.7227582520612116720.idtracker@ietfa.amsl.com> In-Reply-To: From: Warren Kumari Date: Wed, 6 Feb 2019 14:00:35 -0500 Message-ID: To: Dino Farinacci Cc: The IESG , draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, lisp@ietf.org Content-Type: multipart/alternative; boundary="0000000000007c2e8c05813e5924" Archived-At: Subject: Re: [lisp] Warren Kumari's Discuss on draft-ietf-lisp-rfc6830bis-26: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 19:01:20 -0000 --0000000000007c2e8c05813e5924 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 6, 2019 at 12:48 PM Dino Farinacci wrote: > Warren, thanks for the review, I have changed text to address your > comments and nits below. A new diff file is enclosed at the end. > > I want to send one message to the IESG. This has no reflection on Warren > or his commentary. But the standards process seems to be at an all-time l= ow > for my prespective. And this Jan 2019 I have been coming to IETF for 30 > years. So I think I=E2=80=99m not speaking off the cuff here and speak fr= om what I > have experienced over that long time frame. > > We have been trying to get these documents to move forward and it seems > with all the new people that come to the IESG that do the reviews are not > expert in the art and hence we have to explain basic LISP. It has been > happening for about 6 quarters now. We explain, people understand, a > quarter passes, there is silence, new people come into the review process= , > and we explain again. > > We have redone text so many times that likely have undone commentary from > people that were experienced in the art who commented years ago. What if > they come back in now and say =E2=80=9Cyou change the text again=E2=80=9D= . > > To the authors, this seems non-sense, never ending and not productive. On= e > can see why open-source approaches are out competing the IETF process. I= =E2=80=99ll > stop there. > > I=E2=80=99ll explain once again in the DISCUSS comments below because I k= now > Warren put effort into this when he should have been resting. ;-) > > > On Feb 5, 2019, at 6:21 PM, Warren Kumari wrote: > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I read much of this on a plane while overtired, so it is entirely > possible / > > probable that I've completely misunderstood something(s) obvious. Many > of the > > below are probably simple to address, and either I simply need to be > educated, > > or just there needs to be a bit more text / detail provided. > > I will respond briefly and directly. > > > 1: "3. The ITR sends a LISP Map-Request as specified in > > [I-D.ietf-lisp-rfc6833bis]. Map-Requests SHOULD be rate-limited." What > does > > the ITR do with the packet while waiting for the Map-Request to > complete? Must > > > it buffer the packets or can it discard them? If the former, for how > long must > > it buffer? When you say "SHOULD be rate-limited", can you provide > guidance on > > rates? 1 request per second? 1 million per second? Is this rate-limit p= er > > destination or per device? Apologies if this is clearly stated in > RFC6833(bis) > > - I only skimmed it, and didn't see an answer there. > > We have said drop or queue. We discourage queuing because one never knows > which packets are the important ones to queue. Never much the same as the > ARP resolution issue. > Works for me -- note that I don't see that in either the original, nor the attached diff. > > > 2: "6. ... Note that the Map-Cache is an on-demand cache. An ITR will > manage > > its Map-Cache in such a way that optimizes for its resource constraints= ." > > Presumably I could cause this cache to thrash / overflow by looking at > the RLOC > > database, and choosing EIDs to send traffic to which all require > different > > cache entries, causing the cache to overflow (or, at least, causing > maximum > > cache pressure). This seems like an ideal DoS vector. It seems that the= re > > should be more guidance provided on how to size the Map-Cache / the > expected > > order of the cache size, even if it is ultimately an implementation > issue (e.g: > > is a Map-Cache of 100 entries OK for an ITR? or should it be O(1000)? O= r > > roughly size(database)/2? Having multiple devices with small caches, an= d > a bot > > which does the above seems like a global risk). > > What happens if you send 10,000,000 BGP routes in an update and the > receiver can=E2=80=99t store it. It is the same problem. We have lots of = research > on this problem and there are pointers in the spec to it. > Well, what happens is that I tear down the session: accepted-prefix-limit { maximum {{ peer_prefix_limit }}; teardown 85 idle-timeout 10; } This is somewhat of a false analogy - I only accept BGP routes from configured peers, not just anyone on the Internet. A better analogy would be Neighbor Discovery, where a random person on the Internet can cause your router to have to build state -- and we ended up having to publish RFC6583 - "Operational Neighbor Discovery Problems" to address exactly this issue. > > > I'm quite confused by much of the MTU / Fragmentation stuff -- I did > read the > > documents on a plane after not getting much sleep, and so it is entirel= y > > possible / probable that I'm just being stupid, but there are bits whic= h > don't > > seem to make sense to me. 3: "2. Define L to be the size, in octets, o= f > the > > maximum-sized packet an ITR can send to an ETR without the need for the > ITR or > > any intermediate routers to fragment the packet." How do I know what L > is? The > > > document "RECOMMENDS that L be defined as 1500" -- but 1500 isn't > universally > > true (if it were, we would never have to do Path MTU). What happens whe= n > the > > *actual* MTU on the path is e.g 1476 because there is a tunnel on the > path? The > > text also mentions "which is less than the ITR=E2=80=99s estimate of th= e path MTU > > between the ITR and its correspondent ETR" - this implies that the ITR = is > > tracking / estimating the MTU, which a: doesn't align with the rest of > the > > text, or b: sounds like the stateful solution below. I have reread this > > multiple times, but it still feels like it is avoiding the issue by > defining it > > to not exist. > > L is an architectural constant. If there tends to be tunnels between the > ITR and ETR, then you choose L to be 1400. Or you run MTU discovery betwe= en > the ITR and ETR to determine the effective MTU. > That doesn't sound like an "architectural constant" - it sounds like a configurable value. As an example: "Both OSPF and IS-IS make a clear distinction between architectural constants and configurable parameters. Architectural constants are parameters which were fixed by the specification and cannot be changed by the network manager". (from "OSPF and IS-IS: From Link State Routing Principles to Technologies")= . See also https://tools.ietf.org/html/rfc2328#appendix-B , https://tools.ietf.org/html/rfc3719, etc. > > 4: "Note that reassembly can happen at the ETR if the encapsulated > packet was > > fragmented at or after the ITR." - I think that there needs to be more > text / > > description about resource constraints on routers performing reassembly > of > > fragments - in most cases a router doesn't have to / isn't expected to > have to > > reassemble transit packets from arbitrary sources on the Internet > (things where > > routers may reassemble are aimed at the control plane which can be > > rate-limited, or are from expected source addresses). It seems that > spoofing > > lots of initial fragments without the final one will be a tax on the > router. > > We have chosen 3 methods to deal with MTU issues because ETR reassembly i= s > the worst approach. And I certainly wouldn=E2=80=99t recommend using it. > Fair, but I think the document should say so. > > > 5: "Instead of using the Map-Cache or mapping system, RLOC information > MAY be > > gleaned from received tunneled packets or Map-Request messages. A > "gleaned" > > Map-Cache entry, one learned from the source RLOC of a received > encapsulated > > packet, is only stored and used for a few seconds, pending > verification." - it > > seems that this is ripe for abuse (or I'm missing in the cache > expiration). I > > want to hijack traffic from Site X to well known Service Y, so I look u= p > > Service Y and save the TTL from the Map-Reply. I then start spoof packe= ts > > listing myself as the ETR - eventually Site X will glean from my spoofe= d > > packets, and start sending traffic to me - yes, this will only work for > a few > > seconds -- but as soon as I stop getting packets from site X, I know > site X has > > verified the entry and discovered it is wrong... and that the TTL is no= w > being > > deprecated. I start a timer, and second or two less than the TTL later = I > start > > spoofing packets again, knowing that site X will soon expire the cache > entry > > and will once again be willing to accept mine again. A: I get some Site > X to > > Site Y traffic for a few seconds every TTL seconds, and B: the loss of > this > > traffic is a signal that TTL seconds again it will need to be refreshed= . > > It was a Google employee in the early days that wanted this feature (circ= a > 2007). ;-) It was so return packets from a server side didn=E2=80=99t hav= e to do > the mapping system lookup. It is off by default and only used in trusted > enviornments where you can control how the ITR and ETR behave. > You say that "it is off by default" -- but I don't see that in this document (nor, at a quick glance, in RFC 7832 - "Locator/ID Separation Protocol (LISP) Threat Analysis"). > > > 6: "10.1. Echo Nonce Algorithm" -- If I spoof lots of packets with the > N- and > > E-bits set, the receiving ETR will need to keep false state, and > presumably I > > can overfill a cache. This will cause the ETR to not be able to include > the > > received nonce on legitimate traffic, and so the ITR on the far side wi= ll > > think this ETR is down. This seems like a fairly easy DoS. I'm guessing > that > > this can be worked around by not setting the E bit in the RLOC-probe > Map-Reply > > message, but this feels like a dangerous foot gun, and should at least = be > > noted. Note that this is different to the "Note the attacker must guess= a > > valid nonce the ITR is requesting to be echoed within a small window of > time. > > The goal is to convince the ITR that the ETR=E2=80=99s RLOC is reachab= le even > when it > > may not be reachable." attack listed in the document in that a: it > doesn't > > require any guessing, and b: makes an ETR appear down, not up. > > You can=E2=80=99t overfill any cache. An xTR just remembers the last nonc= e that > came with the E-bit set and when it returns packets it uses that nonce. > Um, I don't think this is right (or I've misunderstood) - you don't store "the last nonce that came with the E-bit set" (one number), you have to store "the last nonce that came with the E-bit set for every ITR which is sending them". These have to be stored somewhere, and this is a limited size space (N slots). If I send you N+1 spoofed packets you will have to evict something from this space -- what am I missing? > > Yes, many implementations default to not setting advertising they are > echo-nonce capable in Map-Replies. So RLOC-probing tends to be used for > RLOC reachability. Plus we added features into RLOC-probing that makes it > more useful now (lisp-crypto key exchange for one). > > Pointer? > The document does mention "... attack can be mitigated by preventing RLOC > > spoofing in the network by deploying uRPF BCP 38 [RFC2827]." - while > that may > > be true for many of the above, BCP38 is far from being universally > deployed, > > and this feels similar to solving world hunger by saying everyone must > have > > enough food. :-) > > An ETR can verify mappings if it chooses to. The more overhead you want t= o > put in the system for anti-spoofing, one can do. Tradeoffs. > > By the way food is everywhere, you just have to be willing to eat it. ;-= ) > As someone who was born in Africa and has seen the effects of famine firsthand, I find this statement offensive -- people don't starve to death because they didn't feel like eating their broccoli, they starve to death because there isn't any food. W > > > Again, apologies if I've completely misunderstood something, clue-bat > gladly > > accepted=E2=80=A6 > > You did a pretty good job. Thanks. > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Comments: > > 1: "LISP Locator-Status-Bits (LSBs): ... The field is 32 bits when the > I-bit > > is set to 0 and is 8 bits when the I-bit is set to 1." - I think I'm > missing > > something fairly fundamental here (and in Section 10, 13.1, and others) > - if > > I'm using the I bit, it sounds like I can only have 8 ETRs? And with > this clear > > I can only have 32? I feel like I must have missed something=E2=80=A6. > > Right 8 ETRs per EID-prefix. If you needed more, then you take the > EID-prefix and cut it in half and increase the mask-length by 1, then you > can use a different set of 8 for each more specific EID-prefix. Otherwise= , > you use RLOC-probing and the number of RLOCs can bee up to 255 (the width > of the RLOC-Count field in an EID-record). > > > 2: "When the =E2=80=99DF=E2=80=99 field of the IP header is set to 1, o= r the packet is > an IPv6 > > packet originated by the source host, the ITR will drop the packet when > the > > size is greater than L and send an ICMPv4..." I think this needs to say > when > > the resulting (or encapsulated) packet is greater than L (otherwise it = is > > unclear if you are referring to the original or resulting packet). > > Yes, I will clarify. Great point. > > > 3: "The server-side sets a Weight of zero for the RLOC subset list. In > this > > case, the client-side can choose how the traffic load is spread across > the > > subset list." -- please insert a reference to Section 12 here. I wrote > up a > > long comment on what happens of the load sharing delivers packets to > different > > ETRs, before finding this section later on in the document. > > Done. > > > Nits: > > 1: " LISP does not require changes to either host protocol stack or to > underlay > > routers. " -- I think either "to either the host protocol stack" or " t= o > either > > host protocol stacks" > > > > 2: "As an exmple of such attacks an off-path attacker can" -- typo for > example. > > > > 3: "it can protect itself from erroneious reachability attacks" -- typo > for > > erroneous. > > Fixed. > > Thanks again, > Dino > > > > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --0000000000007c2e8c05813e5924 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Feb 6, 2019 at 12:48 PM Dino Farinacci <= ;farinacci@gmail.com> wrote:<= br>
Warren, thanks f= or the review, I have changed text to address your comments and nits below.= A new diff file is enclosed at the end.

I want to send one message to the IESG. This has no reflection on Warren or= his commentary. But the standards process seems to be at an all-time low f= or my prespective. And this Jan 2019 I have been coming to IETF for 30 year= s. So I think I=E2=80=99m not speaking off the cuff here and speak from wha= t I have experienced over that long time frame.

We have been trying to get these documents to move forward and it seems wit= h all the new people that come to the IESG that do the reviews are not expe= rt in the art and hence we have to explain basic LISP. It has been happenin= g for about 6 quarters now. We explain, people understand, a quarter passes= , there is silence, new people come into the review process, and we explain= again.

We have redone text so many times that likely have undone commentary from p= eople that were experienced in the art who commented years ago. What if the= y come back in now and say =E2=80=9Cyou change the text again=E2=80=9D.

To the authors, this seems non-sense, never ending and not productive. One = can see why open-source approaches are out competing the IETF process. I=E2= =80=99ll stop there.

I=E2=80=99ll explain once again in the DISCUSS comments below because I kno= w Warren put effort into this when he should have been resting.=C2=A0 ;-)
> On Feb 5, 2019, at 6:21 PM, Warren Kumari <warren@kumari.net> wrote:
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> I read much of this on a plane while overtired, so it is entirely poss= ible /
> probable that I've completely misunderstood something(s) obvious. = Many of the
> below are probably simple to address, and either I simply need to be e= ducated,
> or just there needs to be a bit more text / detail provided.

I will respond briefly and directly.

> 1: "3.=C2=A0 The ITR sends a LISP Map-Request as specified in
> [I-D.ietf-lisp-rfc6833bis].=C2=A0 Map-Requests SHOULD be rate-limited.= " What does
> the ITR do with the packet while waiting for the Map-Request to comple= te? Must

> it buffer the packets or can it discard them? If the former, for how l= ong must
> it buffer? When you say "SHOULD be rate-limited", can you pr= ovide guidance on
> rates? 1 request per second? 1 million per second? Is this rate-limit = per
> destination or per device? Apologies if this is clearly stated in RFC6= 833(bis)
> - I only skimmed it, and didn't see an answer there.

We have said drop or queue. We discourage queuing because one never knows w= hich packets are the important ones to queue. Never much the same as the AR= P resolution issue.

Works for me -- note tha= t I don't see that in either the original, nor the attached diff.
=C2=A0

> 2: "6. ... Note that the Map-Cache is an on-demand cache. An ITR = will manage
> its Map-Cache in such a way that optimizes for its resource constraint= s."
> Presumably I could cause this cache to thrash / overflow by looking at= the RLOC
> database, and choosing EIDs to send traffic to which all require diffe= rent
> cache entries, causing the cache to overflow (or, at least, causing ma= ximum
> cache pressure). This seems like an ideal DoS vector. It seems that th= ere
> should be more guidance provided on how to size the Map-Cache / the ex= pected
> order of the cache size, even if it is ultimately an implementation is= sue (e.g:
> is a Map-Cache of 100 entries OK for an ITR? or should it be O(1000)? = Or
> roughly size(database)/2? Having multiple devices with small caches, a= nd a bot
> which does the above seems like a global risk).

What happens if you send 10,000,000 BGP routes in an update and the receive= r can=E2=80=99t store it. It is the same problem. We have lots of research = on this problem and there are pointers in the spec to it.
<= div>
Well, what happens is that I tear down the session:
accepted-= prefix-limit {
=C2=A0 =C2=A0 =C2=A0 maximum {{ peer_prefix_limit }};
<= div class=3D"gmail_default" style=3D"font-family:verdana,sans-serif">=C2=A0= =C2=A0 =C2=A0 teardown 85 idle-timeout 10;
}

This is somewh= at of a false analogy - I only accept BGP routes from configured peers, not= just anyone on the Internet.=C2=A0
A better analogy would be Neighbor Disc= overy, where a random person on the Internet can cause your router to have = to build state -- and we ended up having to publish RFC6583 - "Operati= onal Neighbor Discovery Problems" to address exactly this issue.
=

=C2=A0

> I'm quite confused by much of the MTU / Fragmentation stuff -- I d= id read the
> documents on a plane after not getting much sleep, and so it is entire= ly
> possible / probable that I'm just being stupid, but there are bits= which don't
> seem to make sense to me. 3: "2.=C2=A0 Define L to be the size, i= n octets, of the
> maximum-sized packet an ITR can send to an ETR without the need for th= e ITR or
> any intermediate routers to fragment the packet." How do I know w= hat L is? The

> document "RECOMMENDS that L be defined as 1500" -- but 1500 = isn't universally
> true (if it were, we would never have to do Path MTU). What happens wh= en the
> *actual* MTU on the path is e.g 1476 because there is a tunnel on the = path? The
> text also mentions "which is less than the ITR=E2=80=99s estimate= of the path MTU
> between the ITR and its correspondent ETR" - this implies that th= e ITR is
> tracking / estimating the MTU, which a: doesn't align with the res= t of the
> text, or b: sounds like the stateful solution below. I have reread thi= s
> multiple times, but it still feels like it is avoiding the issue by de= fining it
> to not exist.

L is an architectural constant. If there tends to be tunnels between the IT= R and ETR, then you choose L to be 1400. Or you run MTU discovery between t= he ITR and ETR to determine the effective MTU.

That doesn't sound like an "architectural constant" - it s= ounds like a configurable value.
As an example:=C2=A0
"Both OSPF and = IS-IS make a clear distinction between architectural constants and configur= able parameters. Architectural constants are parameters=C2=A0which were fix= ed by the specification and cannot be changed by the network=C2=A0manager&q= uot;.=C2=A0
(from "OSPF and IS-IS: From Link State Routing Principles= to Technologies").
See also=C2=A0https://tools.ietf.org/html/rfc2328#appendix-B = ,=C2=A0https://tools.ietf.o= rg/html/rfc3719,=C2=A0etc.=C2=A0
=C2=A0


> 4: "Note that reassembly can happen at the ETR if the encapsulate= d packet was
> fragmented at or after the ITR." - I think that there needs to be= more text /
> description about resource constraints on routers performing reassembl= y of
> fragments - in most cases a router doesn't have to / isn't exp= ected to have to
> reassemble transit packets from arbitrary sources on the Internet (thi= ngs where
> routers may reassemble are aimed at the control plane which can be
> rate-limited, or are from expected source addresses). It seems that sp= oofing
> lots of initial fragments without the final one will be a tax on the r= outer.

We have chosen 3 methods to deal with MTU issues because ETR reassembly is = the worst approach. And I certainly wouldn=E2=80=99t recommend using it.

Fair, but I think the document should say so.= =C2=A0

=C2=A0

> 5: "Instead of using the Map-Cache or mapping system, RLOC inform= ation MAY be
> gleaned from received tunneled packets or Map-Request messages. A &quo= t;gleaned"
> Map-Cache entry, one learned from the source RLOC of a received encaps= ulated
> packet, is only stored and used for a few seconds, pending verificatio= n." - it
> seems that this is ripe for abuse (or I'm missing in the cache exp= iration). I
> want to hijack traffic from Site X to well known Service Y, so I look = up
> Service Y and save the TTL from the Map-Reply. I then start spoof pack= ets
> listing myself as the ETR - eventually Site X will glean from my spoof= ed
> packets, and start sending traffic to me - yes, this will only work fo= r a few
> seconds -- but as soon as I stop getting packets from site X, I know s= ite X has
> verified the entry and discovered it is wrong... and that the TTL is n= ow being
> deprecated. I start a timer, and second or two less than the TTL later= I start
> spoofing packets again, knowing that site X will soon expire the cache= entry
> and will once again be willing to accept mine again. A: I get some Sit= e X to
> Site Y traffic for a few seconds every TTL seconds, and B: the loss of= this
> traffic is a signal that TTL seconds again it will need to be refreshe= d.

It was a Google employee in the early days that wanted this feature (circa = 2007). ;-) It was so return packets from a server side didn=E2=80=99t have = to do the mapping system lookup. It is off by default and only used in trus= ted enviornments where you can control how the ITR and ETR behave.

You say that "it is off by default" -- but= I don't see that in this document (nor, at a quick glance, in RFC 7832= - "Locator/ID Separation Protocol (LISP) Threat Analysis").

=C2=A0

> 6: "10.1.=C2=A0 Echo Nonce Algorithm" -- If I spoof lots of = packets with the N- and
> E-bits set, the receiving ETR will need to keep false state, and presu= mably I
> can overfill a cache. This will cause the ETR to not be able to includ= e the
> received nonce on legitimate traffic, and so the ITR on the far side w= ill
> think this ETR is down. This seems like a fairly easy DoS. I'm gue= ssing that
> this can be worked around by not setting the E bit in the RLOC-probe M= ap-Reply
> message, but this feels like a dangerous foot gun, and should at least= be
> noted. Note that this is different to the "Note the attacker must= guess a
> valid nonce the ITR is requesting to be echoed within a small window o= f time.
> The goal is to convince the ITR that the ETR=E2=80=99s RLOC is=C2=A0 r= eachable even when it
> may not be reachable."=C2=A0 attack listed in the document in tha= t a: it doesn't
> require any guessing, and b: makes an ETR appear down, not up.

You can=E2=80=99t overfill any cache. An xTR just remembers the last nonce = that came with the E-bit set and when it returns packets it uses that nonce= .

Um, I don't think this is right (= or I've misunderstood) - you don't store "the last nonce that = came with the E-bit set" (one number), you have to store=C2=A0<= span style=3D"font-family:verdana,sans-serif">"the last nonce that cam= e with the E-bit set for every ITR which is sending them".
These have to be stored somewhere, and this is a limited size = space (N slots). If I send you N+1 spoofed packets you will have to evict s= omething from this space -- what am I missing?
=C2=A0

Yes, many implementations default to not setting advertising they are echo-= nonce capable in Map-Replies. So RLOC-probing tends to be used for RLOC rea= chability. Plus we added features into RLOC-probing that makes it more usef= ul now (lisp-crypto key exchange for one).


Pointer?

> The document does mention "... attack can be mitigated by prevent= ing RLOC
> spoofing in the network by deploying uRPF BCP 38 [RFC2827]." - wh= ile that may
> be true for many of the above, BCP38 is far from being universally dep= loyed,
> and this feels similar to solving world hunger by saying everyone must= have
> enough food. :-)

An ETR can verify mappings if it chooses to. The more overhead you want to = put in the system for anti-spoofing, one can do. Tradeoffs.

By the way food is everywhere, you just have to be willing to eat it.=C2=A0= ;-)

As someone who was born in Africa and h= as seen the effects of famine firsthand, I find this statement offensive --= people don't starve to death because they didn't feel like eating = their broccoli, they starve to death because there isn't any food.

=
W
=C2=A0

> Again, apologies if I've completely misunderstood something, clue-= bat gladly
> accepted=E2=80=A6

You did a pretty good job. Thanks.

> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> Comments:
> 1: "LISP Locator-Status-Bits (LSBs):=C2=A0 ... The field is 32 bi= ts when the I-bit
> is set to 0 and is 8 bits when the I-bit is set to 1." - I think = I'm missing
> something fairly fundamental here (and in Section 10, 13.1, and others= ) - if
> I'm using the I bit, it sounds like I can only have 8 ETRs? And wi= th this clear
> I can only have 32? I feel like I must have missed something=E2=80=A6.=

Right 8 ETRs per EID-prefix. If you needed more, then you take the EID-pref= ix and cut it in half and increase the mask-length by 1, then you can use a= different set of 8 for each more specific EID-prefix. Otherwise, you use R= LOC-probing and the number of RLOCs can bee up to 255 (the width of the RLO= C-Count field in an EID-record).

> 2: "When the =E2=80=99DF=E2=80=99 field of the IP header is set t= o 1, or the packet is an IPv6
> packet originated by the source host, the ITR will drop the packet whe= n the
> size is greater than L and send an ICMPv4..." I think this needs = to say when
> the resulting (or encapsulated) packet is greater than L (otherwise it= is
> unclear if you are referring to the original or resulting packet).

Yes, I will clarify. Great point.

> 3: "The server-side sets a Weight of zero for the RLOC subset lis= t. In this
> case, the client-side can choose how the traffic load is=C2=A0 spread = across the
> subset list." -- please insert a reference to Section 12 here. I = wrote up a
> long comment on what happens of the load sharing delivers packets to d= ifferent
> ETRs, before finding this section later on in the document.

Done.

> Nits:
> 1: " LISP does not require changes to either host protocol stack = or to underlay
> routers. " -- I think either "to either the host protocol st= ack" or " to either
> host protocol stacks"
>
> 2: "As an exmple of such attacks an off-path attacker can" -= - typo for example.
>
> 3: "it can protect itself from erroneious reachability attacks&qu= ot; -- typo for
> erroneous.

Fixed.

Thanks again,
Dino





--
I don't think the execution is relevant when= it was obviously a bad idea in the first place.
This is like putting ra= bid weasels in your pants, and later expressing regret at having chosen tho= se particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf<= /div>
--0000000000007c2e8c05813e5924-- From nobody Wed Feb 6 11:06:36 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C46612426A; Wed, 6 Feb 2019 11:06:28 -0800 (PST) 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, 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=cooperw.in header.b=oGpI2304; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GZCtQvGi 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 CXCcN4B4VEVO; Wed, 6 Feb 2019 11:06:25 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA79130F39; Wed, 6 Feb 2019 11:06:25 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 21B772208A; Wed, 6 Feb 2019 14:06:24 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 06 Feb 2019 14:06:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm2; bh=wF77bZLCm9gjBPPMgfKL3cP wU6QVVEJHoQpJQsi+Kxw=; b=oGpI2304A7DmmQF5lKx/WypirjD2mmvdH4dXaDN X4FQ9/z21SUmwSF3uuBm5Bw5M43jD9ANuw66QC5jYXNrco2hOpiLnW9CpJthOyUO +zZv6ydB7QbhFr1tfpDIsck9uobvSonSBHg2gA1dMKgT/Ir7aH5RduwUiv21VxOH 4GoIVTsKjltvsrbUHb1f5XSz+/FzD0yT8xIHKUwXBxSB0M3HGTfi0qqZyq0Q8Hrt Hu77AelJsIV/tQ9qANR8NKzn41hG0y2rGDKr+0DgFk27syr7Hj7V8yEtHAS/6lzh F1119ivnuXnvGiUsVKySg48TnXQ4iuSAcQ4MbjLapNJ9MiA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=wF77bZ LCm9gjBPPMgfKL3cPwU6QVVEJHoQpJQsi+Kxw=; b=GZCtQvGiAd0Mmu7dAHdrSQ xKOsbIuqjwFRPB/pKBBNaj/X8XaxY85MQTMCZDHQG5ALAQ+ix7T96f31EgUJBWA2 1H6TUbpUhlX88wInCuVsUOxLZ/3wqBFqc+X3qKuxUkSerttsy4kdRBvzLc8GRTr1 HDmYLmCUE1nZW45bBfJEWgOKijeZUj/IbSQldMBYXcLDd9B2sEHTY9NSibLOJLpq IlNc4uzSys6IudjOYmY7hth7zK5mf9BK/ojZcdtsVoz4mzc8oNyhNl7Dwwvlk4q9 AsVMPJVCV4aA+/Kbx5OqnfxgD8s4WXpQEY03qkXK9o9V+3t5fwwpdPJMiG6muk7Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrkeekgdduvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhkfgtggfuff gjvfhfofesrgdtmherhhdtjeenucfhrhhomheptehlihhsshgrucevohhophgvrhcuoegr lhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrghinhepihgvthhfrdhorhhgne cukfhppedujeefrdefkedruddujedrjedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpegr lhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.72]) by mail.messagingengine.com (Postfix) with ESMTPA id 7574E10310; Wed, 6 Feb 2019 14:06:22 -0500 (EST) From: Alissa Cooper Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_DEF0F809-296E-4772-A7E7-DA932A4D748D" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 6 Feb 2019 14:06:23 -0500 In-Reply-To: Cc: Warren Kumari , Luigi Iannone , lisp-chairs@ietf.org, lisp@ietf.org, IESG , draft-ietf-lisp-rfc6830bis@ietf.org To: Dino Farinacci References: <154941971479.32132.7227582520612116720.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Warren Kumari's Discuss on draft-ietf-lisp-rfc6830bis-26: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 19:06:28 -0000 --Apple-Mail=_DEF0F809-296E-4772-A7E7-DA932A4D748D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Dino, > On Feb 6, 2019, at 12:48 PM, Dino Farinacci = wrote: >=20 > Warren, thanks for the review, I have changed text to address your = comments and nits below. A new diff file is enclosed at the end. >=20 > I want to send one message to the IESG. This has no reflection on = Warren or his commentary. But the standards process seems to be at an = all-time low for my prespective. And this Jan 2019 I have been coming to = IETF for 30 years. So I think I=E2=80=99m not speaking off the cuff here = and speak from what I have experienced over that long time frame. Thanks for sharing your view with us. >=20 > We have been trying to get these documents to move forward and it = seems with all the new people that come to the IESG that do the reviews = are not expert in the art and hence we have to explain basic LISP. It = has been happening for about 6 quarters now. We explain, people = understand, a quarter passes, there is silence, new people come into the = review process, and we explain again. The full history of the processing of this document is available at: = . = As you can see, IESG processing of this document began in September = 2018, a little less than 5 months ago. The exact same IESG members were = balloting on the document then as are balloting now since there has been = no turnover in the IESG between now and then. Of course, the full WG and IETF review processes have extended further = into the past than that. Part of the point of standardizing in the IETF = is to obtain cross-area input from those who may have expertise, but not = necessarily expertise in dealing with the protocol being specified. If = there was no interest in getting cross-area review for LISP, it = shouldn=E2=80=99t have been put forth on the IETF standards track. And = part of the value of IESG review in particular is to determine if an = independent implementer could pick up the spec and produce an = interoperable implementation with those written by, say, the spec = authors. The DISCUSS criteria are available here: = . For this document and its companions in particular, there has been more = back-and-forth with the IESG than is typical. Clearly many of us are not = LISP experts and we appreciate the insights that you and your co-authors = have shared to help us understand the protocol better. We also had = holidays intervene to lengthen the review process. But typically our = engagements with authors are also more comprehensive: authors implement = agreed-upon changes fully and in a single or small number of revs so = that it=E2=80=99s easy to re-evaluate the document, the authors check = for internal consistency between inter-dependent documents before = posting revs, and the answers they provide in email offer specific = pointers to text or list discussion to back up their arguments. The = re-review process for these documents has suffered from a lack of this = kind of engagement, in my opinion.=20 >=20 > We have redone text so many times that likely have undone commentary = from people that were experienced in the art who commented years ago. = What if they come back in now and say =E2=80=9Cyou change the text = again=E2=80=9D. IETF work is based on the consensus of people present. Hopefully the = changes being made in this round will not require sending these = documents back for another WG consensus call. But if they do, the = question is whether the people engaged now want the documents published = as-is. That is the best that we can do. >=20 > To the authors, this seems non-sense, never ending and not productive. = One can see why open-source approaches are out competing the IETF = process. I=E2=80=99ll stop there. In many cases open source and open standards aren=E2=80=99t really even = adversarial to one another. But it=E2=80=99s true that if what you were = after was an open source implementation, or a process where a limited = set of contributors could decide on an implementation design, an IETF = standard is not a good fit for that. >=20 > I=E2=80=99ll explain once again in the DISCUSS comments below because = I know Warren put effort into this when he should have been resting. = ;-) The IESG typically processes 300-400 pages of IETF documents every two = weeks. =46rom what I=E2=80=99ve seen it is a hard working group that = puts in a tremendous amount of effort to do a job that is important for = the Internet but mostly thankless. Alissa --Apple-Mail=_DEF0F809-296E-4772-A7E7-DA932A4D748D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Dino,

On Feb 6, 2019, at 12:48 PM, Dino Farinacci = <farinacci@gmail.com> wrote:

Warren, thanks for the review, I = have changed text to address your comments and nits below. A new diff = file is enclosed at the end.

I want to send one message to the IESG. This has no = reflection on Warren or his commentary. But the standards process seems = to be at an all-time low for my prespective. And this Jan 2019 I have = been coming to IETF for 30 years. So I think I=E2=80=99m not speaking = off the cuff here and speak from what I have experienced over that long = time frame.

Thanks= for sharing your view with us.


We have been trying to get these documents to move forward = and it seems with all the new people that come to the IESG that do the = reviews are not expert in the art and hence we have to explain basic = LISP. It has been happening for about 6 quarters now. We explain, people = understand, a quarter passes, there is silence, new people come into the = review process, and we explain again.

The full history of the processing of this = document is available at: <https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/his= tory/>. As you can see, IESG processing of this document began in = September 2018, a little less than 5 months ago. The exact same IESG = members were balloting on the document then as are balloting now since = there has been no turnover in the IESG between now and = then.

Of course, the full WG and = IETF review processes have extended further into the past than that. = Part of the point of standardizing in the IETF is to obtain cross-area = input from those who may have expertise, but not necessarily expertise = in dealing with the protocol being specified. If there was no interest = in getting cross-area review for LISP, it shouldn=E2=80=99t have been = put forth on the IETF standards track. And part of the value of IESG = review in particular is to determine if an independent implementer could = pick up the spec and produce an interoperable implementation with those = written by, say, the spec authors. The DISCUSS criteria are available = here: <https://www.ietf.org/blog/discuss-criteria-iesg-review/>= .

For this document and its = companions in particular, there has been more back-and-forth with the = IESG than is typical. Clearly many of us are not LISP experts and we = appreciate the insights that you and your co-authors have shared to help = us understand the protocol better. We also had holidays intervene to = lengthen the review process. But typically our engagements with authors = are also more comprehensive: authors implement agreed-upon changes fully = and in a single or small number of revs so that it=E2=80=99s easy to = re-evaluate the document, the authors check for internal consistency = between inter-dependent documents before posting revs, and the answers = they provide in email offer specific pointers to text or list discussion = to back up their arguments. The re-review process for these documents = has suffered from a lack of this kind of engagement, in my = opinion. 


We have redone text so many times that likely have undone = commentary from people that were experienced in the art who commented = years ago. What if they come back in now and say =E2=80=9Cyou change the = text again=E2=80=9D.

IETF work is based on the consensus of people = present. Hopefully the changes being made in this round will not require = sending these documents back for another WG consensus call. But if they = do, the question is whether the people engaged now want the documents = published as-is. That is the best that we can do.


To the authors, this seems = non-sense, never ending and not productive. One can see why open-source = approaches are out competing the IETF process. I=E2=80=99ll stop = there.

In = many cases open source and open standards aren=E2=80=99t really even = adversarial to one another. But it=E2=80=99s true that if what you were = after was an open source implementation, or a process where a limited = set of contributors could decide on an implementation design, an IETF = standard is not a good fit for that.


I=E2=80=99ll explain once again in the DISCUSS comments below = because I know Warren put effort into this when he should have been = resting.  ;-)

The = IESG typically processes 300-400 pages of IETF documents every two = weeks. =46rom what I=E2=80=99ve seen it is a hard working group that = puts in a tremendous amount of effort to do a job that is important for = the Internet but mostly thankless.

Alissa


= --Apple-Mail=_DEF0F809-296E-4772-A7E7-DA932A4D748D-- From nobody Wed Feb 6 11:30:59 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24BB130F29; Wed, 6 Feb 2019 11:30:51 -0800 (PST) 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 YGmCc_hFG70r; Wed, 6 Feb 2019 11:30:47 -0800 (PST) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 39239130F37; Wed, 6 Feb 2019 11:30:47 -0800 (PST) Received: by mail-pl1-x631.google.com with SMTP id k15so3543781pls.8; Wed, 06 Feb 2019 11:30:47 -0800 (PST) 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=W8Vt5UKgfoc4xoyPhnFFYa6QfG8zMcgDQcITjUOdWwc=; b=ShzQWddhx/RpSalOXgaUTFwv+/qaeirLuqLtxCYBrMXARDkpxuiQz3p1SY/QyG+Xru K8bZIcuXSqKSHC1jXMSqP5bgMHtTpqXEhANuDfG59Q0t/BlgpFMBe2AmGiriAV76qNfu /PJXG2ykMpDHJ6A3c0GJe6gfc5loIHjBqefH3w3w1VXm0PQqHo02CY/YxidPZgYuvvBs /DljskZovI/gcero2WicasfYZHKN7K8esdH2reFV/KFN54uaiI4gMNAUs3KYiPh3NTRg E8aAHszKbnDHGQ3Rzl37b8DAV2SINVy2KlUp0v8G6Na8P9itZqVh1MdWzFWvhHJmZIKh sZkw== 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=W8Vt5UKgfoc4xoyPhnFFYa6QfG8zMcgDQcITjUOdWwc=; b=J5ovPRKTktXw4ttzdr3a8+6QI0DQ0KOxS3BcmM0+w/2wGNWEsB+MYP2TfodmCGQivc GitbmDG+UflrRNrc7/lWjhqIc+iVRQtGjL6vSyJVJo98v3jclFyxHCk62glUTqrdNKgs jFGI70IGhJlXhhCgkIjv1w+H9o0JexPIKR65nka34rTJVRZzoZ7B3MefOip+hTmHjuNX QEOILpU0Q656+Hf0Y+YJTfuSI4oDYL/IpZnA045bWr4Gz86/LsYcweS2FIzIelkGvnG9 Bjn2DXo2uybvNdDCgau6YdQKbARPoAUmHlbIvSH4z7GkamGD4BojrrK+t7AMfJ0Gjj8t 8Wyw== X-Gm-Message-State: AHQUAuYI8aOMXt32LR2FP54KllX9alMHJ5FcC5lOKKKITN9R7UC0SR/A 6LNnUQhPLhxQTUnnfNtPBuFIE5q6 X-Google-Smtp-Source: AHgI3IZ93VIXbUODI0vDECtW/NVNAIAEN9iOZqdqb0VxrVIbOPJrQDLBK/xEpnX0vOyhAXtHJ7EumQ== X-Received: by 2002:a17:902:22f:: with SMTP id 44mr12254413plc.137.1549481446695; Wed, 06 Feb 2019 11:30:46 -0800 (PST) Received: from [10.31.79.74] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id f67sm19757233pff.29.2019.02.06.11.30.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Feb 2019 11:30:45 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Wed, 6 Feb 2019 11:30:44 -0800 Cc: Warren Kumari , Luigi Iannone , lisp-chairs@ietf.org, lisp@ietf.org, IESG , draft-ietf-lisp-rfc6830bis@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <154941971479.32132.7227582520612116720.idtracker@ietfa.amsl.com> To: Alissa Cooper X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Warren Kumari's Discuss on draft-ietf-lisp-rfc6830bis-26: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 19:30:52 -0000 > The full history of the processing of this document is available at: = . = As you can see, IESG processing of this document began in September = 2018, a little less than 5 months ago. The exact same IESG members were = balloting on the document then as are balloting now since there has been = no turnover in the IESG between now and then. Rather than questioning my accuracy of the past, don=E2=80=99t lose the = point of the comment. =46rom my point of view, this has gone on for 1.5 = years. Just this last epoch review. Note the working group started in = 2009. > For this document and its companions in particular, there has been = more back-and-forth with the IESG than is typical. Clearly many of us = are not LISP experts and we appreciate the insights that you and your = co-authors have=20 And why do you think that has been the case? > shared to help us understand the protocol better. We also had holidays = intervene to lengthen the review process. But typically our engagements = with authors are also more comprehensive: authors implement agreed-upon = changes fully and in a single or small number of revs so that it=E2=80=99s= easy to re-evaluate the document, the authors check for internal = consistency between inter-dependent documents before posting revs, and = the answers they provide in email offer specific pointers to text or = list discussion to back up their arguments. The re-review process for = these documents has suffered from a lack of this kind of engagement, in = my opinion.=20 Well the reviewers don=E2=80=99t have the history of the past nearly 12 = years this effort has gone on for. So we can=E2=80=99t just change fully = or else we disrespect the reviewers that have commented from the past. = Not to mention implementations that have been around or 7 years and = deployments in place. We really want an IETF document to reflect reality. >=20 >> We have redone text so many times that likely have undone commentary = from people that were experienced in the art who commented years ago. = What if they come back in now and say =E2=80=9Cyou change the text = again=E2=80=9D. >=20 > IETF work is based on the consensus of people present. Hopefully the = changes being made in this round will not require sending these = documents back for another WG consensus call. But if they do, the = question is whether the people engaged now want the documents published = as-is. That is the best that we can do. I remember working at cisco when we had to build chips for = next-generation routers. Estimates indicated that it would take 5 years = to build for a new cutting edge next-generation tech. If it takes that = long, then when you release you have an obsolete product. I fear this is what is happening to this document series. I am trying to = avoid that and hence some push back on changing text that was agreed = upon many times and many years ago. >=20 >> To the authors, this seems non-sense, never ending and not = productive. One can see why open-source approaches are out competing the = IETF process. I=E2=80=99ll stop there. >=20 > In many cases open source and open standards aren=E2=80=99t really = even adversarial to one another. But it=E2=80=99s true that if what you = were after was an open source implementation, or a process where a = limited set of contributors could decide on an implementation design, an = IETF standard is not a good fit for that. Adversarial is not the right word I think. More people are going to = open-source projects than building technology through SDOs. This should = be totally obvious. >>=20 >> I=E2=80=99ll explain once again in the DISCUSS comments below because = I know Warren put effort into this when he should have been resting. = ;-) >=20 > The IESG typically processes 300-400 pages of IETF documents every two = weeks. =46rom what I=E2=80=99ve seen it is a hard working group that = puts in a tremendous amount of effort to do a job that is important for = the Internet but mostly thankless. Yes, I understand the load. So it would seem the IESG would want to = close issues quicker. Dino From nobody Wed Feb 6 11:41:42 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FF5130F39; Wed, 6 Feb 2019 11:41:34 -0800 (PST) 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 LTnpD5xtC037; Wed, 6 Feb 2019 11:41:31 -0800 (PST) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC3B7130F29; Wed, 6 Feb 2019 11:41:31 -0800 (PST) Received: by mail-pg1-x532.google.com with SMTP id v28so3343020pgk.10; Wed, 06 Feb 2019 11:41:31 -0800 (PST) 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=wYlK7Js9Q5OUv1M7f/AOUyxP1y5QEeBXkFvoK/K8t2w=; b=jj3eqaOXTQaEFMg4FDQUL2XVwHrjiUuC8dcXEbSX+ij8JqcbT+xPKPOVm9Hv8f08p9 BcNyhCuwgEKxy2ifH3kxjEEPZFxhAigba30EWPtIqD+2PhfTUYocdLn+w2SFS0c2j273 8B8/ujtbodzk4181ftzXE/0FQUWSVyYIfRvQUXb7mPtvtDfJAtA+iygaoyuqAeY3z13Z xopj5fm+FDiSswKubAeZH86FkdZLWB0F8ve6jLLBXbJ+ztM4uKVsfLCEwV4u7C+8dXxU IxgmKmclxesQ9ITw+9x3fvz1mQ9gvCpEx0LZd2PpSUyPe60UVNtRZlMtAoBwT5r3NsrU Ri8A== 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=wYlK7Js9Q5OUv1M7f/AOUyxP1y5QEeBXkFvoK/K8t2w=; b=WrD/Haqv00uQ8UOrjasS7lBzO5qZrqs75lU3SsgKw/zQnlo1cFpb1Sln12RYcTAwgk 1/V3t5fn0ilox7N+J3h4b5udHpEkWSJaqCxAofw8skCQvRSB8qOqdFNOANchx5HYNB71 rUSar6+UsV4u9EgKrTzrAxWRmnDPh9KpsVXVeewMfOX1FdDGHw/CIULeNLhp0zY2ddOp 2jU/rp/8slao6p3n6Es5f079+lYEhKSZtQXPQuE6Aqguf9I69yWnIsFytUusqQuD8QmF cChpd1eh9IY+9J3yTwFsmvZd7v8bLkggjlavrUwDg3BY5vc6fH7K2ESyaLnqv0Svg/3s boJA== X-Gm-Message-State: AHQUAuYmYRVNghfb0jhR4D1gM6H9U82uV8eW/8xRh7e9ol9WQ+uVVBVo mMJhRNO64xGqRZyPtdx8Fbbmy4so X-Google-Smtp-Source: AHgI3IafkEh+Wrb+cnDkUecJzR8GMQKdzXgFj69cfR8llU/zA0F08zuzJmsGEy8mZlMteHQtS1i95w== X-Received: by 2002:a65:6110:: with SMTP id z16mr11213953pgu.330.1549482091234; Wed, 06 Feb 2019 11:41:31 -0800 (PST) Received: from [10.31.79.74] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id z1sm9894726pfi.155.2019.02.06.11.41.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Feb 2019 11:41:30 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Wed, 6 Feb 2019 11:41:29 -0800 Cc: The IESG , draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, lisp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0D72CB4B-2016-4978-97C9-E943AFD19D31@gmail.com> References: <154941971479.32132.7227582520612116720.idtracker@ietfa.amsl.com> To: Warren Kumari X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Warren Kumari's Discuss on draft-ietf-lisp-rfc6830bis-26: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 19:41:34 -0000 >=20 > What happens if you send 10,000,000 BGP routes in an update and the = receiver can=E2=80=99t store it. It is the same problem. We have lots of = research on this problem and there are pointers in the spec to it. >=20 > Well, what happens is that I tear down the session: > accepted-prefix-limit { > maximum {{ peer_prefix_limit }}; > teardown 85 idle-timeout 10; > } >=20 > This is somewhat of a false analogy - I only accept BGP routes from = configured peers, not just anyone on the Internet.=20 > A better analogy would be Neighbor Discovery, where a random person on = the Internet can cause your router to have to build state -- and we = ended up having to publish RFC6583 - "Operational Neighbor Discovery = Problems" to address exactly this issue. I don=E2=80=99t think it is. Because a BGP table and a cache is still = allocable memory that has to be managed. And it doesn=E2=80=99t matter = if peers are configured or not, a bad peer can still damage a BGP cache. And those limits can be placed on the LISP table as well. > L is an architectural constant. If there tends to be tunnels between = the ITR and ETR, then you choose L to be 1400. Or you run MTU discovery = between the ITR and ETR to determine the effective MTU. >=20 > That doesn't sound like an "architectural constant" - it sounds like a = configurable value. > As an example:=20 > "Both OSPF and IS-IS make a clear distinction between architectural = constants and configurable parameters. Architectural constants are = parameters which were fixed by the specification and cannot be changed = by the network manager".=20 > (from "OSPF and IS-IS: =46rom Link State Routing Principles to = Technologies"). > See also https://tools.ietf.org/html/rfc2328#appendix-B , = https://tools.ietf.org/html/rfc3719, etc.=20 Was the changed text sufficient? > > 4: "Note that reassembly can happen at the ETR if the encapsulated = packet was > > fragmented at or after the ITR." - I think that there needs to be = more text / > > description about resource constraints on routers performing = reassembly of > > fragments - in most cases a router doesn't have to / isn't expected = to have to > > reassemble transit packets from arbitrary sources on the Internet = (things where > > routers may reassemble are aimed at the control plane which can be > > rate-limited, or are from expected source addresses). It seems that = spoofing > > lots of initial fragments without the final one will be a tax on the = router. >=20 > We have chosen 3 methods to deal with MTU issues because ETR = reassembly is the worst approach. And I certainly wouldn=E2=80=99t = recommend using it. >=20 > Fair, but I think the document should say so.=20 I don=E2=80=99t think it should. If someone has ETR resources to do so, = it should be able to do it. Fragmentation/assembly is in the protocol to = be used. Is it a good idea, that=E2=80=99s another question. Is it = practical, that is another question. > > deprecated. I start a timer, and second or two less than the TTL = later I start > > spoofing packets again, knowing that site X will soon expire the = cache entry > > and will once again be willing to accept mine again. A: I get some = Site X to > > Site Y traffic for a few seconds every TTL seconds, and B: the loss = of this > > traffic is a signal that TTL seconds again it will need to be = refreshed. >=20 > It was a Google employee in the early days that wanted this feature = (circa 2007). ;-) It was so return packets from a server side didn=E2=80=99= t have to do the mapping system lookup. It is off by default and only = used in trusted enviornments where you can control how the ITR and ETR = behave. >=20 > You say that "it is off by default" -- but I don't see that in this = document (nor, at a quick glance, in RFC 7832 - "Locator/ID Separation = Protocol (LISP) Threat Analysis=E2=80=9D). It has been implemented in products as off by default. > > valid nonce the ITR is requesting to be echoed within a small window = of time.=20 > > The goal is to convince the ITR that the ETR=E2=80=99s RLOC is = reachable even when it > > may not be reachable." attack listed in the document in that a: it = doesn't > > require any guessing, and b: makes an ETR appear down, not up. >=20 > You can=E2=80=99t overfill any cache. An xTR just remembers the last = nonce that came with the E-bit set and when it returns packets it uses = that nonce. >=20 > Um, I don't think this is right (or I've misunderstood) - you don't = store "the last nonce that came with the E-bit set" (one number), you = have to store "the last nonce that came with the E-bit set for every ITR = which is sending them=E2=80=9D. Right. The context was from a single encapsulator. > These have to be stored somewhere, and this is a limited size space (N = slots). If I send you N+1 spoofed packets you will have to evict = something from this space -- what am I missing? They are stored in the map-cache since you encap to that ITR (which is = now an ETR). So its a 24-bit number you use in an RLOC data structure in = your implemenation. I have implemented this way twice (in 2 different = implementations). > Yes, many implementations default to not setting advertising they are = echo-nonce capable in Map-Replies. So RLOC-probing tends to be used for = RLOC reachability. Plus we added features into RLOC-probing that makes = it more useful now (lisp-crypto key exchange for one). >=20 >=20 > Pointer? The LISP WG can provide pointes. Damien and Luigi did extensive research = on this. > > The document does mention "... attack can be mitigated by preventing = RLOC > > spoofing in the network by deploying uRPF BCP 38 [RFC2827]." - while = that may > > be true for many of the above, BCP38 is far from being universally = deployed, > > and this feels similar to solving world hunger by saying everyone = must have > > enough food. :-) >=20 > An ETR can verify mappings if it chooses to. The more overhead you = want to put in the system for anti-spoofing, one can do. Tradeoffs. >=20 > By the way food is everywhere, you just have to be willing to eat it. = ;-) >=20 > As someone who was born in Africa and has seen the effects of famine = firsthand, I find this statement offensive -- people don't starve to = death because they didn't feel like eating their broccoli, they starve = to death because there isn't any food. It wasn=E2=80=99t intended to be offensive. And if that is how it was = received, I am sorry for that. Dino From nobody Wed Feb 6 13:39:50 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBAC4130EEC for ; Wed, 6 Feb 2019 13:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=kumari-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 jhOmvs5gQYOb for ; Wed, 6 Feb 2019 13:39:38 -0800 (PST) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 61E62130EE0 for ; Wed, 6 Feb 2019 13:39:38 -0800 (PST) Received: by mail-wr1-x430.google.com with SMTP id x10so9257703wrs.8 for ; Wed, 06 Feb 2019 13:39:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h2vA8yVhZyp3UGI48Sg88G0AfnUujCSC4m47IdEgdSQ=; b=Hu4bSFoGejZtH8IkJgrXkIb0bcR4tXCrQ/C159QD/2HPyke57sWzY19Vkl10srxRbS jJ+jo1/moAGAJhGpcJvV6xeOJIXqha9uqa17cJ43E3vJcTPBuFNXl2Dlqa8BzxqEnTcT FrGQzcawCz4i1okCYzr2E1EuF8Opg4rzPNL8nrxTUsQYIFb+XVEZ2I3MD3Dq6TGQsUJu vbfkxGnCdSBrvct8ra5/TX0R81Y4Eh9s9763VEfLISBVLG118lzV1+8TjgTnMrQoLuaI z37TyjH3EfEMsxCVNuaA4dQaWfWtttXdS3KFEQgyTIE5whT/uavo7hKGEc6YKCyNnSMF FgcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=h2vA8yVhZyp3UGI48Sg88G0AfnUujCSC4m47IdEgdSQ=; b=sslc+zfgjcrDqwlSn3bpwOqExlcQ1gxXV5KWiqEzCnQLzI40t9yCxe9wG05oQHih6C XegSlGRx6F7aP+ZWuENuP/9sA65ZDVWwdg+WqEVCGzVnMkGfWE0uxgbj2zAejKQd3aKX ekPkKsrloMA76vTbBkBamuqD4NRy9hiib+gsb6ilbRzFbSjNip7HFbl3HTU1UpmsLsr8 DPymt2Eg0PCoFe04BIWjmikApiwVxBjU86Go1rrqAETR0LqBm/ekf8RJs2j6i9aSawAh nYC+bJsToSN+djKh7PRHvGRh/iXwQ865nVhrRduIbFXxCXabPzGkpY9dN4pZgsxOXmK4 TQIg== X-Gm-Message-State: AHQUAubmLya8sZ6gSG6XTHqnIjTLC1+FSZ9NeHMBf1xdA72dUlbk6QdG 0CJzirM11qSDFRToqaeQJa4VRS+7QYQPcyIPFuRFwA== X-Google-Smtp-Source: AHgI3IagU3j0dnO1cooiBm8EkVgGBJ1QlZUrIBqjkWtBIlQkpCHjXF6b9KMDvNIArg3S7i1jm0maisqG6v74eWG8x4A= X-Received: by 2002:adf:fa90:: with SMTP id h16mr8808636wrr.326.1549489176112; Wed, 06 Feb 2019 13:39:36 -0800 (PST) MIME-Version: 1.0 References: <154941971479.32132.7227582520612116720.idtracker@ietfa.amsl.com> <0D72CB4B-2016-4978-97C9-E943AFD19D31@gmail.com> In-Reply-To: <0D72CB4B-2016-4978-97C9-E943AFD19D31@gmail.com> From: Warren Kumari Date: Wed, 6 Feb 2019 16:38:59 -0500 Message-ID: To: Dino Farinacci Cc: The IESG , draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, lisp@ietf.org Content-Type: multipart/alternative; boundary="000000000000ed171f0581408fb7" Archived-At: Subject: Re: [lisp] Warren Kumari's Discuss on draft-ietf-lisp-rfc6830bis-26: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 21:39:42 -0000 --000000000000ed171f0581408fb7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 6, 2019 at 2:41 PM Dino Farinacci wrote: > > > > > What happens if you send 10,000,000 BGP routes in an update and the > receiver can=E2=80=99t store it. It is the same problem. We have lots of = research > on this problem and there are pointers in the spec to it. > > > > Well, what happens is that I tear down the session: > > accepted-prefix-limit { > > maximum {{ peer_prefix_limit }}; > > teardown 85 idle-timeout 10; > > } > > > > This is somewhat of a false analogy - I only accept BGP routes from > configured peers, not just anyone on the Internet. > > A better analogy would be Neighbor Discovery, where a random person on > the Internet can cause your router to have to build state -- and we ended > up having to publish RFC6583 - "Operational Neighbor Discovery Problems" = to > address exactly this issue. > > I don=E2=80=99t think it is. Because a BGP table and a cache is still all= ocable > memory that has to be managed. And it doesn=E2=80=99t matter if peers are > configured or not, a bad peer can still damage a BGP cache. > > And those limits can be placed on the LISP table as well. > > > L is an architectural constant. If there tends to be tunnels between th= e > ITR and ETR, then you choose L to be 1400. Or you run MTU discovery betwe= en > the ITR and ETR to determine the effective MTU. > > > > That doesn't sound like an "architectural constant" - it sounds like a > configurable value. > > As an example: > > "Both OSPF and IS-IS make a clear distinction between architectural > constants and configurable parameters. Architectural constants are > parameters which were fixed by the specification and cannot be changed by > the network manager". > > (from "OSPF and IS-IS: From Link State Routing Principles to > Technologies"). > > See also https://tools.ietf.org/html/rfc2328#appendix-B , > https://tools.ietf.org/html/rfc3719, etc. > > Was the changed text sufficient? > Which changed text? It wasn't (as far as I could see) in the diff which you attacked earlier. Also, in the diff there is still the "example" typo: "For exmple of such attacks" > > > > 4: "Note that reassembly can happen at the ETR if the encapsulated > packet was > > > fragmented at or after the ITR." - I think that there needs to be mor= e > text / > > > description about resource constraints on routers performing > reassembly of > > > fragments - in most cases a router doesn't have to / isn't expected t= o > have to > > > reassemble transit packets from arbitrary sources on the Internet > (things where > > > routers may reassemble are aimed at the control plane which can be > > > rate-limited, or are from expected source addresses). It seems that > spoofing > > > lots of initial fragments without the final one will be a tax on the > router. > > > > We have chosen 3 methods to deal with MTU issues because ETR reassembly > is the worst approach. And I certainly wouldn=E2=80=99t recommend using i= t. > > > > Fair, but I think the document should say so. > > I don=E2=80=99t think it should. If someone has ETR resources to do so, i= t should > be able to do it. Fragmentation/assembly is in the protocol to be used. I= s > it a good idea, that=E2=80=99s another question. Is it practical, that is= another > question. > > > > deprecated. I start a timer, and second or two less than the TTL late= r > I start > > > spoofing packets again, knowing that site X will soon expire the cach= e > entry > > > and will once again be willing to accept mine again. A: I get some > Site X to > > > Site Y traffic for a few seconds every TTL seconds, and B: the loss o= f > this > > > traffic is a signal that TTL seconds again it will need to be > refreshed. > > > > It was a Google employee in the early days that wanted this feature > (circa 2007). ;-) It was so return packets from a server side didn=E2=80= =99t have > to do the mapping system lookup. It is off by default and only used in > trusted enviornments where you can control how the ITR and ETR behave. > > > > You say that "it is off by default" -- but I don't see that in this > document (nor, at a quick glance, in RFC 7832 - "Locator/ID Separation > Protocol (LISP) Threat Analysis=E2=80=9D). > > It has been implemented in products as off by default. > ... and someone reading this document is supposed to know that how? The purpose of publishing documents like this is to allow for interoperable implementations - expecting implementers to have to examine other implementations to learn how not to shoot themselves in the foot doesn't help anyone. > > > > valid nonce the ITR is requesting to be echoed within a small window > of time. > > > The goal is to convince the ITR that the ETR=E2=80=99s RLOC is reach= able even > when it > > > may not be reachable." attack listed in the document in that a: it > doesn't > > > require any guessing, and b: makes an ETR appear down, not up. > > > > You can=E2=80=99t overfill any cache. An xTR just remembers the last no= nce that > came with the E-bit set and when it returns packets it uses that nonce. > > > > Um, I don't think this is right (or I've misunderstood) - you don't > store "the last nonce that came with the E-bit set" (one number), you hav= e > to store "the last nonce that came with the E-bit set for every ITR which > is sending them=E2=80=9D. > > Right. The context was from a single encapsulator. > > > These have to be stored somewhere, and this is a limited size space (N > slots). If I send you N+1 spoofed packets you will have to evict somethin= g > from this space -- what am I missing? > > They are stored in the map-cache since you encap to that ITR (which is no= w > an ETR). So its a 24-bit number you use in an RLOC data structure in your > implemenation. I have implemented this way twice (in 2 different > implementations). > Ok, this seems seems like a good optimization (but does require that the RLOC storage needs to be larger ) - why not suggest this in the document? It would only take a sentence or two, and would make future implementations more likely / resilient. > > > Yes, many implementations default to not setting advertising they are > echo-nonce capable in Map-Replies. So RLOC-probing tends to be used for > RLOC reachability. Plus we added features into RLOC-probing that makes it > more useful now (lisp-crypto key exchange for one). > > > > > > Pointer? > > The LISP WG can provide pointes. Damien and Luigi did extensive research > on this. > > Again, something like "many implementations default to not advertising that they are echo-nonce capable in Map-Replies and so RLOC-probing tends to be used for RLOC reachability." would help - there is no harm in trying to make things easier for your readers / future implementors. > > > The document does mention "... attack can be mitigated by preventing > RLOC > > > spoofing in the network by deploying uRPF BCP 38 [RFC2827]." - while > that may > > > be true for many of the above, BCP38 is far from being universally > deployed, > > > and this feels similar to solving world hunger by saying everyone mus= t > have > > > enough food. :-) > > > > An ETR can verify mappings if it chooses to. The more overhead you want > to put in the system for anti-spoofing, one can do. Tradeoffs. > > > > By the way food is everywhere, you just have to be willing to eat it. > ;-) > > > > As someone who was born in Africa and has seen the effects of famine > firsthand, I find this statement offensive -- people don't starve to deat= h > because they didn't feel like eating their broccoli, they starve to death > because there isn't any food. > > It wasn=E2=80=99t intended to be offensive. And if that is how it was rec= eived, I > am sorry for that. > > Ok. No worries. W > Dino > > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --000000000000ed171f0581408fb7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On= Wed, Feb 6, 2019 at 2:41 PM Dino Farinacci <farinacci@gmail.com> wrote:

>
> What happens if you send 10,000,000 BGP routes in an update and the re= ceiver can=E2=80=99t store it. It is the same problem. We have lots of rese= arch on this problem and there are pointers in the spec to it.
>
> Well, what happens is that I tear down the session:
> accepted-prefix-limit {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0maximum {{ peer_prefix_limit }};
>=C2=A0 =C2=A0 =C2=A0 =C2=A0teardown 85 idle-timeout 10;
> }
>
> This is somewhat of a false analogy - I only accept BGP routes from co= nfigured peers, not just anyone on the Internet.
> A better analogy would be Neighbor Discovery, where a random person on= the Internet can cause your router to have to build state -- and we ended = up having to publish RFC6583 - "Operational Neighbor Discovery Problem= s" to address exactly this issue.

I don=E2=80=99t think it is. Because a BGP table and a cache is still alloc= able memory that has to be managed. And it doesn=E2=80=99t matter if peers = are configured or not, a bad peer can still damage a BGP cache.

And those limits can be placed on the LISP table as well.

> L is an architectural constant. If there tends to be tunnels between t= he ITR and ETR, then you choose L to be 1400. Or you run MTU discovery betw= een the ITR and ETR to determine the effective MTU.
>
> That doesn't sound like an "architectural constant" - it= sounds like a configurable value.
> As an example:
> "Both OSPF and IS-IS make a clear distinction between architectur= al constants and configurable parameters. Architectural constants are param= eters which were fixed by the specification and cannot be changed by the ne= twork manager".
> (from "OSPF and IS-IS: From Link State Routing Principles to Tech= nologies").
> See also https://tools.ietf.org/html/rfc2328#appe= ndix-B , https://tools.ietf.org/html/rfc3719, etc.

Was the changed text sufficient?

Which chang= ed text? It wasn't (as far as I could see) in the diff which you attack= ed earlier.=C2=A0
Also, in the diff there is still the "example"= typo: "For exmple of such attacks"

=C2=A0

>=C2=A0 > 4: "Note that reassembly can happen at the ETR if the = encapsulated packet was
> > fragmented at or after the ITR." - I think that there needs = to be more text /
> > description about resource constraints on routers performing reas= sembly of
> > fragments - in most cases a router doesn't have to / isn'= t expected to have to
> > reassemble transit packets from arbitrary sources on the Internet= (things where
> > routers may reassemble are aimed at the control plane which can b= e
> > rate-limited, or are from expected source addresses). It seems th= at spoofing
> > lots of initial fragments without the final one will be a tax on = the router.
>
> We have chosen 3 methods to deal with MTU issues because ETR reassembl= y is the worst approach. And I certainly wouldn=E2=80=99t recommend using i= t.
>
> Fair, but I think the document should say so.

I don=E2=80=99t think it should. If someone has ETR resources to do so, it = should be able to do it. Fragmentation/assembly is in the protocol to be us= ed. Is it a good idea, that=E2=80=99s another question. Is it practical, th= at is another question.

> > deprecated. I start a timer, and second or two less than the TTL = later I start
> > spoofing packets again, knowing that site X will soon expire the = cache entry
> > and will once again be willing to accept mine again. A: I get som= e Site X to
> > Site Y traffic for a few seconds every TTL seconds, and B: the lo= ss of this
> > traffic is a signal that TTL seconds again it will need to be ref= reshed.
>
> It was a Google employee in the early days that wanted this feature (c= irca 2007). ;-) It was so return packets from a server side didn=E2=80=99t = have to do the mapping system lookup. It is off by default and only used in= trusted enviornments where you can control how the ITR and ETR behave.
>
> You say that "it is off by default" -- but I don't see t= hat in this document (nor, at a quick glance, in RFC 7832 - "Locator/I= D Separation Protocol (LISP) Threat Analysis=E2=80=9D).

It has been implemented in products as off by default.

... and someone reading this document is supposed to know that h= ow? The purpose of publishing documents like this is to allow for interoper= able implementations - expecting implementers to have to examine other impl= ementations to learn how not to shoot themselves in the foot doesn't he= lp anyone.=C2=A0

> > valid nonce the ITR is requesting to be echoed within a small win= dow of time.
> > The goal is to convince the ITR that the ETR=E2=80=99s RLOC is=C2= =A0 reachable even when it
> > may not be reachable."=C2=A0 attack listed in the document i= n that a: it doesn't
> > require any guessing, and b: makes an ETR appear down, not up. >
> You can=E2=80=99t overfill any cache. An xTR just remembers the last n= once that came with the E-bit set and when it returns packets it uses that = nonce.
>
> Um, I don't think this is right (or I've misunderstood) - you = don't store "the last nonce that came with the E-bit set" (on= e number), you have to store "the last nonce that came with the E-bit = set for every ITR which is sending them=E2=80=9D.

Right. The context was from a single encapsulator.

> These have to be stored somewhere, and this is a limited size space (N= slots). If I send you N+1 spoofed packets you will have to evict something= from this space -- what am I missing?

They are stored in the map-cache since you encap to that ITR (which is now = an ETR). So its a 24-bit number you use in an RLOC data structure in your i= mplemenation. I have implemented this way twice (in 2 different implementat= ions).

Ok, this seems seems like a good optimizat= ion (but does require that the RLOC storage needs to be larger ) - why not = suggest this in the document? It would only take a sentence or two, and wou= ld make future implementations more likely / resilient.=C2=A0

> Yes, many implementations default to not setting advertising they are = echo-nonce capable in Map-Replies. So RLOC-probing tends to be used for RLO= C reachability. Plus we added features into RLOC-probing that makes it more= useful now (lisp-crypto key exchange for one).
>
>
> Pointer?

The LISP WG can provide pointes. Damien and Luigi did extensive research on= this.


Again, something like "many implementa= tions default to not advertising that they are echo-nonce capable in Map-Re= plies and so RLOC-probing tends to be used for RLOC reachability." wou= ld help - there is no harm in trying to make things easier for your readers= / future implementors.

=C2=A0
> > The document does mention "... attack can be mitigated by pr= eventing RLOC
> > spoofing in the network by deploying uRPF BCP 38 [RFC2827]."= - while that may
> > be true for many of the above, BCP38 is far from being universall= y deployed,
> > and this feels similar to solving world hunger by saying everyone= must have
> > enough food. :-)
>
> An ETR can verify mappings if it chooses to. The more overhead you wan= t to put in the system for anti-spoofing, one can do. Tradeoffs.
>
> By the way food is everywhere, you just have to be willing to eat it.= =C2=A0 ;-)
>
> As someone who was born in Africa and has seen the effects of famine f= irsthand, I find this statement offensive -- people don't starve to dea= th because they didn't feel like eating their broccoli, they starve to = death because there isn't any food.

It wasn=E2=80=99t intended to be offensive. And if that is how it was recei= ved, I am sorry for that.


Ok. No worries.=C2=A0
W

=C2=A0
Dino



--
I don't think the execution is relevant when= it was obviously a bad idea in the first place.
This is like putting ra= bid weasels in your pants, and later expressing regret at having chosen tho= se particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf<= /div>
--000000000000ed171f0581408fb7-- From nobody Wed Feb 6 14:01:15 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78DE0130E62; Wed, 6 Feb 2019 14:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=ff85Mq4h; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qb0LmYwW 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 5Yk7pIKxpKPy; Wed, 6 Feb 2019 14:01:01 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B48112D4F3; Wed, 6 Feb 2019 14:01:01 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 357FF21F5F; Wed, 6 Feb 2019 17:01:00 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 06 Feb 2019 17:01:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=u vkCR3viWE/9nP6yDDa1AHrUIARa60aB2Gh0RzsbHZw=; b=ff85Mq4hK9uZ+J01D D+ANrnGBk0USMNN5VxTR9KmQDWJ0ILXrEyyHIroNImIh2kILPENR67CqSHKbC1Zm PU3ZnzgqKIET+4rgenE0lA34APDdoLehOF1IAw5ouRnaWoQTPX42YI1FhLSfcW07 ko81oyfrYtBInKeCPjZOqMFq842Gw63OhpQSYf0kMLmMDZynKEkyHBrigWKpOGZh Kcz0lvkiD2gPHtmYwc+RX/J1zyddJjjcFEmMdhtI0XyduEFSAr00N3dPAT2S5Wrn dlSKILnOblb0nZQi+KlOfrEHlI9oKpdc4FW7Cspx7ejo4VVbGxF0OMIXsaBttG95 wcqMw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=uvkCR3viWE/9nP6yDDa1AHrUIARa60aB2Gh0RzsbH Zw=; b=qb0LmYwWsEvIsdg1XkXllQ8tc3+D3+PbsqAVo9zCczSR+eojVINtY5z36 D0qQgOlhTY29mShBRknMm7PDpeCeNFjUZEMTf/5QnEIQVAOgpMDGtErzgf7Kb8sR I/OcxAN/woY6pL4/8mz1ZMD64ZWebJbeed+Lao+pCADJth2SmgEaXI/Ns4l5EAAT qA6SmeKNZZCgvml+26IZ5qiae0urRf10pDc3YcoNCMMpwkAMV3u43EHzkzEbtDJN Ncjm4MQemUSrHVzO2ORZBnsCbw27C01UuLD9d0n++oXhdv+n4k7OugxooOQOCM+a o9c6Rl2eyrozrBoIS8OFQ8gkTIZsQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrkeekgdduheelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpegtggfuhfgjff fgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhishhsrgcuvehoohhpvghruceo rghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrihhnpehivghtfhdrohhrgh enucfkphepudejfedrfeekrdduudejrdejvdenucfrrghrrghmpehmrghilhhfrhhomhep rghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.72]) by mail.messagingengine.com (Postfix) with ESMTPA id 48F9710317; Wed, 6 Feb 2019 17:00:59 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <154942103074.32279.4509839048441396108@ietfa.amsl.com> Date: Wed, 6 Feb 2019 17:01:00 -0500 Cc: IETF Gen-ART , draft-ietf-lisp-rfc6833bis.all@ietf.org, lisp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2EB9A2DB-D34E-489B-B70B-4511E424C188@cooperw.in> References: <154942103074.32279.4509839048441396108@ietfa.amsl.com> To: Pete Resnick X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] [Gen-art] Genart telechat review of draft-ietf-lisp-rfc6833bis-24 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 22:01:05 -0000 Pete, thank you for your reviews of this document. Dino, thank you for = addressing Pete=E2=80=99s comment. I have entered a No Objection ballot. Alissa > On Feb 5, 2019, at 9:43 PM, Pete Resnick wrote: >=20 > Reviewer: Pete Resnick > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-lisp-rfc6833bis-24 > Reviewer: Pete Resnick > Review Date: 2019-02-05 > IETF LC End Date: 2018-08-31 > IESG Telechat date: 2019-02-07 >=20 > Summary: >=20 > The changes made to this version look fine to me. No concerns save the = editorial comment below. >=20 > Major issues: None. >=20 > Minor issues: None. >=20 > Nits/editorial comments: Section 2: Get rid of everything except the = last paragraph. >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Feb 6 14:07:34 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00723130EF1; Wed, 6 Feb 2019 14:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 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_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=no 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 zwbjhHb6RaoZ; Wed, 6 Feb 2019 14:07:22 -0800 (PST) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 2F6C1130F40; Wed, 6 Feb 2019 14:07:22 -0800 (PST) Received: by mail-ot1-x32f.google.com with SMTP id u16so14794425otk.8; Wed, 06 Feb 2019 14:07:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=eY4GNo9zP3aIcBxtb1vhVgVk1EN6AoItg4k+01zbPWs=; b=qvftO8AIuygzuY9qzm+AhoLsuEqcc1k3fVq+tKcBPOliihcvw5pYU7KD4Vzf12z7bo Oh+M01zTW6sCJveM4A86NsyF8PFtVaM7AFOVhOcFrt48YBigTVVqr0ASuYYyQAcbPqE4 CTLp13aKSg9qAckZYAYg0MFtrmnESbB3uUVsLJBAqITXK69K5FrN5KgWBAIecdjG94X2 fwrb0wk1zpLqJIZr5M9BFg8VTR6aUJuPCh5boCNLr0H1DwdJhElcOBVPY3y9+r1snw1u Y/QWydojJxff86aG4SOO+f8S56VSxBb+UobUtp4OARuAOCO8KlweCAfCOiaxklLzX8fD fvoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=eY4GNo9zP3aIcBxtb1vhVgVk1EN6AoItg4k+01zbPWs=; b=YgAZWwg7W2zb4YKuQwyxRW5086T6Pvu3E5IW83lyk22fedDka+Xka2VGdtWOTtQPjN /n4fxasAKO2IavNxCAp4KquXfG1PFrHJhlBKdj8dIlKpDBVr+Gn8OYaATg0K9DRUS8ET kZe/SZzKpaEcdx5hlOOgr3a1HsJJEheP1H9N+tTQmFHcpMzSs4PEIglQwAbTAJO/ltzu iEmeHi0SvJWjvczLyhnImfksMEgjul2piRA5COtnb1BQRHR8MOJfWZwdtoL4j5I4snv5 g/hduGBUm5748sq9dACsGxPv1MNV6U9qW84S0ixd3I0ujkXgsxGdggX/xmGn3xaTRMbo WRQg== X-Gm-Message-State: AHQUAuYrWG4RJWQ11mR4vq9CTSmSBuvbKSCPyp5brTOFx6dhSLhl+KO5 sRx2TJZHDuglBDwLIU9PGOQtMFeX X-Google-Smtp-Source: AHgI3IZvMfqI7CbGg09cxVA7FdWzNr+SojNVYRIy90+qjoHv5XU5g22TCwXnf46tuBiRL1zpEEqzEA== X-Received: by 2002:aca:5193:: with SMTP id f141mr93347oib.114.1549490841368; Wed, 06 Feb 2019 14:07:21 -0800 (PST) Received: from dino-macbook.attlocal.net (adsl-108-94-1-57.dsl.pltn13.sbcglobal.net. [108.94.1.57]) by smtp.gmail.com with ESMTPSA id v20sm9601182otp.10.2019.02.06.14.07.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Feb 2019 14:07:19 -0800 (PST) From: Dino Farinacci Message-Id: <80010161-70A1-4B59-ADEA-2C5588CFF3F6@gmail.com> Content-Type: multipart/mixed; boundary="Apple-Mail=_9A64C7D3-A0AC-4D20-B973-F8E9FC083567" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 6 Feb 2019 14:07:04 -0800 In-Reply-To: Cc: The IESG , draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, lisp@ietf.org To: Warren Kumari References: <154941971479.32132.7227582520612116720.idtracker@ietfa.amsl.com> <0D72CB4B-2016-4978-97C9-E943AFD19D31@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Warren Kumari's Discuss on draft-ietf-lisp-rfc6830bis-26: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 22:07:27 -0000 --Apple-Mail=_9A64C7D3-A0AC-4D20-B973-F8E9FC083567 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > L is an architectural constant. If there tends to be tunnels between = the ITR and ETR, then you choose L to be 1400. Or you run MTU discovery = between the ITR and ETR to determine the effective MTU. > >=20 > > That doesn't sound like an "architectural constant" - it sounds like = a configurable value. > > As an example:=20 > > "Both OSPF and IS-IS make a clear distinction between architectural = constants and configurable parameters. Architectural constants are = parameters which were fixed by the specification and cannot be changed = by the network manager".=20 > > (from "OSPF and IS-IS: =46rom Link State Routing Principles to = Technologies"). > > See also https://tools.ietf.org/html/rfc2328#appendix-B , = https://tools.ietf.org/html/rfc3719, etc.=20 >=20 > Was the changed text sufficient? >=20 > Which changed text? It wasn't (as far as I could see) in the diff = which you attacked earlier.=20 > Also, in the diff there is still the "example" typo: "For exmple of = such attacks=E2=80=9D I was referring to the MTU text. We combined two discussion points at = the same time. I was referring to the the size of the packet that the = ITR needs to encapsulate and that L includes the size of the = encapsulation headers. Fixed the typo. > > > deprecated. I start a timer, and second or two less than the TTL = later I start > > > spoofing packets again, knowing that site X will soon expire the = cache entry > > > and will once again be willing to accept mine again. A: I get some = Site X to > > > Site Y traffic for a few seconds every TTL seconds, and B: the = loss of this > > > traffic is a signal that TTL seconds again it will need to be = refreshed. > >=20 > > It was a Google employee in the early days that wanted this feature = (circa 2007). ;-) It was so return packets from a server side didn=E2=80=99= t have to do the mapping system lookup. It is off by default and only = used in trusted enviornments where you can control how the ITR and ETR = behave. > >=20 > > You say that "it is off by default" -- but I don't see that in this = document (nor, at a quick glance, in RFC 7832 - "Locator/ID Separation = Protocol (LISP) Threat Analysis=E2=80=9D). >=20 > It has been implemented in products as off by default. >=20 > ... and someone reading this document is supposed to know that how? = The purpose of publishing documents like this is to allow for = interoperable implementations - expecting implementers to have to = examine other implementations to learn how not to shoot themselves in = the foot doesn't help anyone.=20 Tell me why this text does not satisfy your concern? --Apple-Mail=_9A64C7D3-A0AC-4D20-B973-F8E9FC083567 Content-Disposition: inline; filename=PastedGraphic-29.png Content-Type: image/png; x-unix-mode=0666; name="PastedGraphic-29.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAABBYAAABiCAYAAADk3lBuAAAMK2lDQ1BJQ0MgUHJvZmlsZQAASImV VwdYU8kWnltSSWiBUKSE3kQp0gUCoUUQkCrYCEkgocSYEFTsqKjAWlCxYEVXRRRdCyCLDQsWFsXe HxZUlHVxFRsqb5IAuvq99753vm/u/e+ZM+f859yZ+WYA0IrlSaU5qDYAuZI8WVx4MGtsSiqL9AiQ AQZ0gDXw4fHl0qDY2CgAZeD9T3l3AyDK91Vnpa+f+/+r6AiEcj4ASCzE6QI5PxfiQwDgnnypLA8A QhfUW03Nk0JMhCyBngwShNhaiTPV2FuJ09U4SmWTEMeBOA0AMo3Hk2UCoKnkxcrnZ0I/mqUQu0gE YgnEjRAH8EU8AcSfIR6amzsZYi17iO3Tv/OT+Q+f6YM+ebzMQazORSXkELFcmsOb/n+W439Lbo5i IIYVbDSRLCJOmbOybtmTI5WYBvE5SXp0DMS6EF8TC1T2SvxUpIhI7Lf/wJdzYM0AEwCUJuCFREJs ArGlJCc6ql8fkCEO40IMa48miPO4CeqxqEA2Oa7fPzpNKA+NH8A8mSqW0qZYkZ0Y1O9zk0jIHfDZ UCBKSFbzRC/ni5OiIdaE+J48Oz6y3+ZFgYgTPWAjU8QpOcN/joEMWVic2gazzpUP5IX5isTc6H4c lSdKiFCPxSbyeSpuhhBnCeVjowZ4CoQhoeq8sEKhJLGfP1YmzQuO67ffLs2J7bfHGoU54Uq9JcSt 8vz4gbHdeXCyqfPFgTQvNkHNDdfL4o2KVXPAHUEU4IAQwAIK2NLBZJAFxK1ddV3wS90TBnhABjKB EDj3awZGJKt6JPAZDwrAnxAJgXxwXLCqVwjyof7LoFb9dAYZqt581Yhs8BTiXBAJcuC3QjVKMhgt CTyBGvFP0fmQaw5syr6fdCytAR0xlBhCjCCGER1wYzwA98Oj4JMNmxvujfsM8PpmT3hKaCM8Ilwn tBNuTxIXyn5gzgKjQTvkGNafXfr32eG20KsHHoz7Q//QN87EjYEzPgJGCsIDYWwPqP2eq2Iw42+1 7PdFcaGgFAMKm2L/IwNNR02PQS/KSn1fCzWv9MFqcQZ7fsyD8139BPAd+aMlthg7iDVjJ7HzWCNW B1jYcawea8GOKvHg3HiimhsD0eJUfLKhH/FP8Xj9MZVVk7tUu3S6fO7vA3nCaXnKxcKZLJ0uE2eK 8lhBcLcWsrgS/rChLDcXV7iLKvd+9dbyhqna0xHmhW+6wrcA+Av6+voav+mi4Jo8tBAA6tNvOrtj cDkbAHCuhK+Q5at1uPJBAFSgBVeKETCDe5c9zMgNeAI/wAahYBSIAQkgBUyEdRbBeSoDU8FMMA8U gRKwHKwG68FmsA3sAnvBAVAHGsFJcBZcBJfBdXAXzpUO8BJ0g3egF0EQEkJHGIgRYo7YIE6IG+KN BCChSBQSh6QgaUgmIkEUyExkPlKClCHrka1IFfIbcgQ5iZxH2pDbyEOkE/kb+YRiKA3VQ01RW3Q4 6o0GoZFoAjoBzUSnoAXoAnQpuhatRPegtehJ9CJ6HW1HX6I9GMA0MCZmgTlj3hgHi8FSsQxMhs3G irFyrBKrwRrgn76KtWNd2EeciDNwFu4M52sEnojz8Sn4bLwUX4/vwmvx0/hV/CHejX8l0AkmBCeC L4FLGEvIJEwlFBHKCTsIhwln4NrpILwjEolMoh3RC669FGIWcQaxlLiRuI94gthGfEzsIZFIRiQn kj8phsQj5ZGKSOtIe0jHSVdIHaQPZA2yOdmNHEZOJUvIheRy8m7yMfIV8jNyL0WbYkPxpcRQBJTp lGWU7ZQGyiVKB6WXqkO1o/pTE6hZ1HnUtdQa6hnqPeobDQ0NSw0fjTEaYo25Gms19muc03io8ZGm S3OkcWjjaQraUtpO2gnabdobOp1uS2fTU+l59KX0Kvop+gP6B02G5jBNrqZAc45mhWat5hXNV1oU LRutIK2JWgVa5VoHtS5pdWlTtG21Odo87dnaFdpHtG9q9+gwdFx1YnRydUp1duuc13muS9K11Q3V Fegu0N2me0r3MQNjWDE4DD5jPmM74wyjQ4+oZ6fH1cvSK9Hbq9eq162vqz9CP0l/mn6F/lH9dibG tGVymTnMZcwDzBvMTwamBkEGQoMlBjUGVwzeGw4xZBsKDYsN9xleN/xkxDIKNco2WmFUZ3TfGDd2 NB5jPNV4k/EZ464hekP8hvCHFA85MOSOCWriaBJnMsNkm0mLSY+pmWm4qdR0nekp0y4zphnbLMts ldkxs05zhnmAudh8lflx8xcsfVYQK4e1lnWa1W1hYhFhobDYatFq0WtpZ5loWWi5z/K+FdXK2yrD apVVk1W3tbn1aOuZ1tXWd2woNt42Ips1Ns02723tbJNtF9nW2T63M7Tj2hXYVdvds6fbB9pPsa+0 v+ZAdPB2yHbY6HDZEXX0cBQ5VjheckKdPJ3EThud2oYShvoMlQytHHrTmeYc5JzvXO38cBhzWNSw wmF1w14Ntx6eOnzF8ObhX108XHJctrvcddV1HeVa6Nrg+reboxvfrcLtmjvdPcx9jnu9++sRTiOE IzaNuOXB8BjtscijyeOLp5enzLPGs9PL2ivNa4PXTW8971jvUu9zPgSfYJ85Po0+H309ffN8D/j+ 5efsl+232+/5SLuRwpHbRz72t/Tn+W/1bw9gBaQFbAloD7QI5AVWBj5iW7EF7B3sZ0EOQVlBe4Je BbsEy4IPB7/n+HJmcU6EYCHhIcUhraG6oYmh60MfhFmGZYZVh3WHe4TPCD8RQYiIjFgRcZNryuVz q7jdo7xGzRp1OpIWGR+5PvJRlGOULKphNDp61OiVo+9F20RLoutiQAw3ZmXM/Vi72Cmxv48hjokd UzHmaZxr3My45nhG/KT43fHvEoITliXcTbRPVCQ2JWkljU+qSnqfHJJcltw+dvjYWWMvphiniFPq U0mpSak7UnvGhY5bPa5jvMf4ovE3JthNmDbh/ETjiTkTj07SmsSbdDCNkJactjvtMy+GV8nrSeem b0jv5nP4a/gvBWzBKkGn0F9YJnyW4Z9RlvE80z9zZWanKFBULuoSc8Trxa+zIrI2Z73Pjsnemd2X k5yzL5ecm5Z7RKIryZacnmw2edrkNqmTtEjaPsV3yuop3bJI2Q45Ip8gr8/Tg4fsFoW9YqHiYX5A fkX+h6lJUw9O05kmmdYy3XH6kunPCsIKfp2Bz+DPaJppMXPezIezgmZtnY3MTp/dNMdqzoI5HXPD 5+6aR52XPe+PQpfCssK385PnNywwXTB3weOF4QurizSLZEU3F/kt2rwYXyxe3LrEfcm6JV+LBcUX SlxKyks+l/JLL/zi+svaX/qWZixtXea5bNNy4nLJ8hsrAlfsKtMpKyh7vHL0ytpVrFXFq96unrT6 fPmI8s1rqGsUa9rXRq2tX2e9bvm6z+tF669XBFfs22CyYcmG9xsFG69sYm+q2Wy6uWTzpy3iLbe2 hm+trbStLN9G3Ja/7en2pO3Nv3r/WrXDeEfJji87JTvbd8XtOl3lVVW122T3smq0WlHduWf8nst7 Q/bW1zjXbN3H3FeyH+xX7H/xW9pvNw5EHmg66H2w5pDNoQ2HGYeLa5Ha6bXddaK69vqU+rYjo440 Nfg1HP592O87Gy0aK47qH112jHpswbG+4wXHe05IT3SdzDz5uGlS091TY09dOz3mdOuZyDPnzoad PdUc1Hz8nP+5xvO+549c8L5Qd9HzYm2LR8vhPzz+ONzq2Vp7yetS/WWfyw1tI9uOXQm8cvJqyNWz 17jXLl6Pvt52I/HGrZvjb7bfEtx6fjvn9us7+Xd67869R7hXfF/7fvkDkweV/3L41752z/ajD0Me tjyKf3T3Mf/xyyfyJ587FjylPy1/Zv6s6rnb88bOsM7LL8a96HgpfdnbVfSnzp8bXtm/OvQX+6+W 7rHdHa9lr/v+Ln1j9Gbn2xFvm3piex68y33X+774g9GHXR+9PzZ/Sv70rHfqZ9LntV8cvjR8jfx6 ry+3r0/Kk/FURwEMNjQjA4C/dwJATwGAcRmeH8ap72YqQdT3SRUC/wmr728q8QSgBr6Ux3DOCQD2 w2Y7F/pmA6A8giewAeruPtj6RZ7h7qb2RYM3FsKHvr43pgCQGgD4Iuvr693Y1/dlOyR7G4ATU9R3 QqUo76Bb2Ep03VAwF/wg/wYEKXFozC1U3QAAAAlwSFlzAAAWJQAAFiUBSVIk8AAAAZ1pVFh0WE1M OmNvbS5hZG9iZS54bXAAAAAAADx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6 eG1wdGs9IlhNUCBDb3JlIDUuNC4wIj4KICAgPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3 LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4KICAgICAgPHJkZjpEZXNjcmlwdGlv biByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6ZXhpZj0iaHR0cDovL25zLmFkb2JlLmNv bS9leGlmLzEuMC8iPgogICAgICAgICA8ZXhpZjpQaXhlbFhEaW1lbnNpb24+MTA0NjwvZXhpZjpQ aXhlbFhEaW1lbnNpb24+CiAgICAgICAgIDxleGlmOlBpeGVsWURpbWVuc2lvbj45ODwvZXhpZjpQ aXhlbFlEaW1lbnNpb24+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICA8L3JkZjpSREY+Cjwv eDp4bXBtZXRhPgp4HoF8AAAAHGlET1QAAAACAAAAAAAAADEAAAAoAAAAMQAAADEAACJM+IrZ7QAA IhhJREFUeAHsnX+MY1d1x0+kXZL8kaHJog3arbqJEqGAFAdtRDdIBNWLhAKUOFDaRuCgREhOhFBw /ihoKgEa/gA5VZU4qqLZVKkDxBHgIMX5xxHCm2IodVQ5Eo6EIzJRZ1EnZabNpHhaeYNHur3P7917 z/tlv3ft8djL19KMn+13f5zPOffc+867977LhHwRXiAAAiAAAiAAAiAAAiAAAiAAAiAAAiBgQeAy BBYsqCEJCIAACIAACIAACIAACIAACIAACIDAiAACCzAEEAABEAABEAABEAABEAABEAABEAABawII LFijQ0IQAAEQAAEQAAEQAAEQAAEQAAEQAAEEFmADIAACIAACIAACIAACIAACIAACIAAC1gQQWLBG h4QgAAIgAAIgAAIgAAIgAAIgAAIgAAIILMAGQAAEQAAEQAAEQAAEQAAEQAAEQAAErAkgsGCNDglB AARAAARAAARAAARAAARAAARAAAQQWIANgAAIgAAIgAAIgAAIgAAIgAAIgAAIWBNAYMEaHRKCAAiA AAiAAAiAAAiAAAiAAAiAAAggsAAbAAEQAAEQAAEQAAEQAAEQAAEQAAEQsCaAwII1OiQEARAAARAA ARAAARAAARAAARAAARBAYAE2AAIgAAIgAAIgAAIgAAIgAAIgAAIgYE0AgQVrdEgIAiAAAiAAAiAA AiAAAiAAAiAAAiCAwAJsAARAAARAAARAAARAAARAAARAAARAwJoAAgvW6JAQBEAABEAABEAABEAA BEAABEAABEAAgQXYAAiAAAiAAAiAAAiAAAiAAAiAAAiAgDUBBBas0SEhCIAACIAACIAACIAACIAA CIAACIAAAguwARAAARAAARAAARAAARAAARAAARAAAWsCCCxYo0NCEAABEAABEAABEAABEAABEAAB EAABBBZgAyAAAiAAAiAAAiAAAiAAAiAAAiAAAtYEEFiwRoeEIAACIAACIAACIAACIAACIAACIAAC CCzABkAABEAABEAABEAABEAABEAABEAABKwJILBgjQ4JQQAEQAAEQAAEQAAEQAAEQAAEQAAEEFiA DYAACIAACIAACIAACIAACIAACIAACFgTQGDBGh0SggAIgAAIgAAIgAAIgAAIgAAIgAAIILAAGwAB EAABEAABEAABEAABEAABEAABELAmgMCCNTokBAEQAAEQAAEQAAEQAAEQAAEQAAEQQGAhoQ1cfOsN 2u4P6cqVa+n41VckTOWednHnDdraHRAddT9fec1JOjEhj2nKS1W50Mn7tHPhAjnVvea6G+h4OlFD ueGLP2QCF+mN17eoT0fo5KlTdNURexaH1x7G1Xmf3trZpaE85eiV19DVSsD9PdpxGpB8rVxznK6Y Qu5RJuzf3huv02u//R0dPeo5E6f0o++m9950QlK+9F7Q+zLpdHbtfd5SL6adzY7CpS7f7EghJxAY T8BmPD8+R/wKApcWAQQWEulzj86dXaEHXiTKlNr0y6+cSZSKaIee+dsCfe7bdd/5k/OwLc9XjN2H iy/T2StvJSkqldq79JUzV9vlg1SXBIFXX3iKnv91nxLHly5/D91z/x00spq9l+jsym2uLXWkLZ22 taVDbA/jtMjk4236lXN3UeYBt82XppI7XPjLD99Ct3616/8hU6bdXz7oMvf/suSfoPelUiBrD7O2 +4PlsKB2NjOhF1y+/Tfo+cf/jh598jy96cl8/dkv0Nf/pkCnT0T0PPL8Zx9/lt6I4LPyrusoc+Y2 On3Dcd+vU/Vj+zv0/JPfp823fVn6P1y8nD507xfo9PGI8G5i+d6i88/U6Tf0DqLf/57efevH6Y6b /XIQ7dOr55+j9m/+l+gdf0K5z56N8fuyzo/JOju1HFe3kRQX6aVnvkM//e/f0Tuv+xjdf+fNo2/x L0jAdjwfzAefQeASJyDwSkCgL9azJKQpiFy5k+B895RuJT9K46Rz/jLZrMjI90KlOyEPu/ImZJrs 50FH5L36lju7ydIs8FlaB7mK6C9wPRezaruinHFtV9nw5PeMaCnQM7OlQ2wP4xTD5ON+obtu2v2s 29BGoyzy+YIoFgsjXzLSR279ErVt6H2c+S3cb6w9zNruD1bWBbWzmQm9wPL1u6LojTfCfUtGVLsR Y5B+R2Rj03hjrXxZ9FQ/JKbsx/rtieU5dZc3YsIaSyNfqJw1sRXKsS/K3liUKCvaWkb/icONqm/s ma/2/Cf4Phn7oExZ0sIrioAeS3q2l3w8H5XbYn2nZcM4ebEUs6S1oSWt95yrPRDNUkFkZWBgdayD 5tVizjq/LraG/LdJxzblTcoz4e9LOziMlk9f5GXX0WFGIxrz7VC0ykWRLxREgf3ldLAhE/otX1gX m8rWZ2ZLh9gextARTL55BRZ4dXoqcCltO2Z8yU9fwmPofamUxtrDcgUWFtTOZqb8RZVvV9+wcS7M M/mSaHU7ol4usIvinAhdrzM7cy6ui6tFGWhdFYV8lqWTAQYZcHUvkqfsx4YbolzI6z4wqv9zgr2N zUFAYynl88nlBkhKre1Ann1Ryalgf050Yhy/vlBUAZixF4wsz0s2SB3AmPrjNOP51IXNPQHGyXNH fkkXiMDCgal3qDuAfGVctPjAKmCXsezccl5ntFyDw2hx9cWX7FiD3X50Cnw7iUBipmygVI4bAU0q bJF/Z/IdRmCBDwZixpeLTG9563bIel9YcIzLJdneFxb8clZswO+q5yu+wH+3YoILofETs7Pcetcn fH+joWdcOsGK9W68Z0zcj/lKECJputTyMbn07I1scAYBCwJQXGBBztDQsxpUECIrWrFTEViel2yQ OqDE1B+XdDyfUM6kNp0wO5z2B05gfnssOOvMnnx2tE7tPR+9h+64KWK99d6r9FTlx3Kzt8vpzGe+ QGdOBNerXaSXn/8OnfunH1D734mOOSvyMmfpi18q0mfOnJK+OPq1v/MyPfn9n9Pbl18n13/fSf2X nqVz//A0tbt9outP0i3v+wDd/aX7ZHlXsQz26ZUXfki/+O3vZW2819tv0zXv/yTdeeaE+sb/7qz9 kzK+KVNcTr+j5x74Ko1WWmcKtP7QB4lkeufv2JnPyPoG87AoT5dux2Xv9Z/RIw//Pf1Iwjx27Bid vO2v6aHPv4/OvffD9ITMWwYW6EHrdfG6cuwgZT09nm+8vULZe/6Cjr70I3pk/bv0Wv9NevPNY/SJ h9Zo9d7biWvNWYP4yvNP04v/+TZdLhX36ncfoEdfdKqQpdL65+md5C6UdFTxobuj10Sms5cdeuHc 9+nXMr8TkXqVRWs5iK770N105+ngukmGaAkOXzl3j9xD4GmJdJ12z98fs8ZTCiL367hH7tchz6RK d4tu/68f08OPTdKfAjBFe9i7QM/LNaO1H/wzdaWLOHb9Cp289nr6wAez9NGPf5RumtWOpEw+GVig 5x48Paq85iM/jWtDke1P7k/xf//2Iv1K1vv9n7xb+qSINcYeIl2O1ENf6sHfDhRH/p6y/cmkezuv 0r/85KfU+unP6VevORtxOq8VuuXPPkaf/qtP0e03Rdiytvc07XaUsfxnofepypMyRvnBcXqYUu9K 0mTvcq209C+b9C667tge1R7/wcimz35xjb7+qT+if/za16g66gzP0iOVb9PZU1H2kl7vum5yffn5 Hz5FlR++QF2nzz0mtX/yFvpY7tP0qT+/3b+5L+OStr0vhZ0pKKn8yyz0pwpO827RjlT2qeRTidK/ v/zYXXTrl929aKobQ/rsDXy89zo9dNmN9KiTbVbuIXOe7SHD7Iz7XVWDnfPfpGs/8o3Rx7LcJ+rB mH2iuP8c24+pjL33pOlSy6fkkutliW2j4+9D9uipu1bovhG2HHX6z9HpoOPfOU+3XPuRURZr1Qq9 9rn7Rn3wamOLvnVHcNzpCMXyTNyXeDAO4S3d+IxXMKUf9PoVu/G8U27K8ryq2svHZZ10PP04mS5e oGefeJQel3ujrGQy1O926aTcG+VLRXktdSpolJPqg98vKQJzC6zI6WQFNS2rUBNqtjQvf7NWFBLu 6K+6Ebi/3O+JtVAUVkVj5d4HpWbsHel+p+zl60yby+kyVFnOu9x8jVdFHu+Kkqove8+GzmPJ5Bo5 Zw8Fnm/k8VqwLCcPi/KcZJZctlqKSXx9ZzpjwaaeCdZSUrEe0Hs0xyg9rIXmWDpAJdJU9rIl1pTO Y9YnmvxIFBubbiFL/D/xnfKoOzCKlXoP6U+Bidbj2PYnkw63GmPbYKaUfI8UVZPYdymfmt3jn7Fg fExcG9pur0/0E5FrdlllEuvBSWPT/uQCi0l7bBSr/juGo+pZtVslmIXepyjPSg9T6F1Jmfg9tO46 3l8TrYqQd7HSu1u7/kZd23eU/wy1Jev2viR2JrGk9i/T6i+xoQRPtGhHNvIFi038WU4t11P6C6Ib GO4J2atX88rW5XIIPvGA2Rn3u6roQa+ifeu4/iKV/1SZy/dk6SzkY3JlcgWRV+Nd3zIGNrsgZsbC Zl2No50ZDdtmuUmhHjnulp2Dnl0rbxYs/LI6M55KMZ638YPTjOdtyvNszEo+Zp/JDqP9Q5Sfjxon DzYbY/uGUmMjWTVw1iVJYK5LITplNeAOdBQjtMwRh6Z/bfumdmUKJdHsdEW3VRdF5XzlhYqMyEYq qd8ND+Jzq2VRb9RFtbw22pgnHFgYil6zJirVmqjVynrznqiOzBS6K1r1uqjLv0ajKgpqLXp2TZbV GH1fr9dEqxdcN+fkYFOeJRfpMNUFkeNIVqtN0eu15TrCjO6Qne/jLoqMvEmPLOvJOtqRw8sURK3V Ee3GutaHnLIi6npRv8txo90QtZEO6qLEBicVrQOpo1pDbOxGhbdkN5vSXjZYQKwWDIhJvdaLimtB 9KKLTApyIc5LNrCSVbXSnxLRpj0MRXNVsZabpJaqot2VfqLTFrVKaWTz4XauyrN4H3R1sDTPNmTl 9lCJmoorL4R5+ytWGrL9dcR60b9GeFL7S6wHYdn+dGAhI4qlddFotUW31xVN5g+ddulvf4egd1s7 s9WDrd4tTIy3oYzckK7drvumehfWm6JVXfX8dkbUfOu8bfUuK7rr37AuWyyLltPndlqyz3QvXEJt yVYPy2Jn0pen9i+MSXr92RiMSrPo/pNdzMas69f+LXgBzZhGjcc266o9kFhrRo8JHUo6/5QX08nS WcjH5KJ8VXSbJT0eM/0IyzfIZaR6FpCRXJ14TVePu6MCOE4ilmdKFqMi5/wv7fhMWPd/tuP5Kfyu o42U4087/ENhP07eEquy3x+NyeV7bq0yGmc1q2v6O2dc3ki3sZydGEi1kATmGlgYbtS04YWCANvm TmOh6o927baNgy1UgnccZURWR74j7thI7P6GmhGVTuDCfrAtNrZ4SDyoq6GoemVEdWTBs93PAx0F Dq4DjD6ff5usPFsuGzWzftHf8coORl+Izy6wYFtPPqimzKrosbsag665KzHuzq7N2rHU9sICNaE7 JL7fWlzJS3ucbGAlxeMDJUv9uZCStQdn1o96ektmtRnBty+2d5kRRZwxj694+1v1zWAZiBoL7s0q sGDd/uSF1KYMzGxHBcPkzBC1M3vIv81b75blzUoPB2ozTLZ177aubn+ZkhwyOy85a8oLYnObsde7 EO2SugkgZ1nVeiERh1tt0WgHLtpYXdP56yWxMxv/wpik1V8IuvUXi+g/J1/Mmg0IA3sJMKZB37Pd rWm/5Fz4VPigIcBPt6OUF9PJ0lnIx+Si0Z5Q7AJOBhrcnovlGxVYYOONvLf/RJ+Nlbh/MDhYnilZ mDzmd5R2fDaNHzRSJR/PT1teWvlMHe2P0oyTt1vmeixX8o9pt9tmJnQ28Jt97ZBy2QjMNbDgRA5L 6i6+dpQusl5VXexmRdN33e8MtlV0LCOaWwMx6O+K3V3vbzAQPX3HOBe5QQ1vqLn1YGAiicqM400e WLBJo+qSJK0tF5M3UfhxRgMWLY3uhFQdk77b1lPmzzraYs0fbBJDc7d4nE6TDQL8sqS3l6Fo6FkJ RbHBLsT43ZPwbAZ/ucvyKTHTGejPZWJsdnz7Y7OecmXhu3m7MHCNLM7U9cClmeDTeCe1v2R6mKL9 +ZgNRX93WwZmXL876G+KkjdbLKSTeevdqrzZ6cGHadYfmGzKHrTe9Z1eI4s6x5lKbt9vbpo7UvJC I3bPt6CsrK62/tqZubewdibv7OqbGEn9C2OidJNMf0G403w29hFqq75sLeTzpU/xQc76UY+1jpt+ 3yyqcV9gXMeYOndG8/KJDfl8XuTY7NXR3VQ5xhx3u0jrIeXFdKJ0NvJxubw68eXBtdHAgukoIrDA L/p0UGXQ0zPrMmv+C0FXY8Y+4nSRQrMHfmq68dk0fpCLYhiNb0PTl5dOPl5H++NENu1l311XQedA uxz9zjYOTdN32FcdKReQwJwDC3JHXRZAMLvUMmMMBBycaVq6M2fTb9Q0nOB7NSJCzRuq3cVdUqfC NWyTRqVPktaWi8k7I9e3s2tgt3DWuamBkKqV3bttPWVprC7h3Z2NHHwaerCOaRymSmtjLzyNeUSU vIOuZtOElveo0pbvPTHTGejPpWN0Pb5TdwI8ajDqvudXS6Jab4hOd2PsIHN+WjCyRLc/M+Ce1P6S 6WGK9udA6W+IWqk4dt8KdWdMM5y33q3Km50etNwHccBkU/sOhfVuZDE2M4Xe2RKR8e0tIDCra2p/ vQx2JnvL1P6FMUmnvwDbqT4a+xivTwv5rOvFpovHXNh32AVM3B4LwfGf+pwtViYGlsPtKJkwydJZ yMdsxbnAHwX0hiYo4Own5QQMK2pMEQosSP2tqqWA/tm75saH/3tXYmMfyxZYmDyen8IP+szBMBrf hqYvj48lJ8vnq6T1h2Q27WbfKnlLNmParclLzaizrhYSLimBuQcWBFvyUKxvjrANN+vxSyTk5YBx pPJiIZMRmcg/50IiI6q9cIzaNNS86FjNhDZ1GO9UuBXYpFHpk6Q154w600gmDqsgF5MuNG3fKZ51 bmaQqupl827KS1fPSXUx+Y7TiXFyyTclsrMXMx2Z8jV32uJWXV+QKVu3IbhoaRIzHWtLyfTnyp7i 3LGbJuVEPcI/zJcvkyXwqLRRPaR/VIPjSe0vmR5MeanbH7vAVHUy/tcN3Djfh9rfvPVuVZ7hEpxO nVYPB2o/WjbTd2n/pAd2RhZjM+a71HrXZcrlcDEb3EbKzNN1gvMcTH1C9rIsduYInda/aCZp9RdJ 2PLLMeyDOaaVL5g+8WdTJ9Izb/yJtX8LXkBrps54sCiqtZqoVquiWqnIvZVaYmM7PAb05+x+0vnr dhR1Vvi7ZOks5ONysTqZm3Fyxu72rm9TS99TnHkQgrKi6u0p1Wg2fBufh2++sbqycsOSL8Y32v+R aVPxNWOyOTcmE4+TgzmafEL+y3eqOS+13/XySSefr3DrD8ls2sneLDeNC0LpvGS79QUErWuHhMtG YP6BBR4oGK0jY5voBDuQEU3WUC3v+pqGGlirl1hbpg7jnQrP0CaNSp8krTlHPo4p+XRVxj86sJD8 jqmq7fh323rKXFlHawbMqjST7zidaCeXosO0tRczAMiKtgxg9dgdF98AQImwpO+Jmc5Afy6iZLo2 OAdiU24yV6uURTGvpu2pC+GCb6mKSTOvIyNLdi1iHwg2hTZs8/46aj3EDMzds0156fwEe167HJAV yg2x1edRWZNvqP3NW+9W5Zn6T6sHv1Zm/EnLZvou7Z+0TzOyGJsx36XVu+N31eai+UovuUC6rlH7 85j6BO1Fr+9ddDvTJFL4F80krf50YTM4iGcfnXkK+aIzSPAtu7ObCS/JdDJorqnNbAMXKJqpDGpG BWcTlO6cov2nbkfJEiZLZyEfk8t30cb6hNxaVazrfXiMTTk1137BuYAe8xdeOmrsw1duMhxzP8vI 6Zc/uiJctjTj5GBuJp+g//Kfac5L7Xe9jNLJ5y/d9lMym3ZyZ0s9YsYdZm+Uom9fNNu6Id3yETiE wIIQ5nE4WdHa3jJPfIiami8vhKedTj59QzXOYrxT4QZgk0alT5LWlguPOEY4Wva4PjNIVfWyebet pyyLdbThuiRhxAYPMU4wSiJre9lt6Y2jipWavkuQWW1EFWO+k2sgV+XMEjUTh6ggHxNlfl60o8Sd 0Az058qeTNdxnIZyP4Aqe8zs+qHCZe1Bb75naj7cNBvchm3enOccaT3IOzfhx7Wpc1l5KQOQ2u+G lqfJvPlgtxzYt2beercqj3GZUg+K9IG8a9nMIFr7J31BZNqHsRkmXyq9+3U70XdxoXVd0wQWWD0X 3c64rOx4rH/RTNLqjxUw9aGxj+TjF1PoWPnMaSmPBqKuL5DlODA4wUXeKinrPRP8+xbxcYGNPKqi 2n/qdqR+Gf+eLJ2FfNpWZGAgUCddpi9gYGzKqTHfcDWbc/edcPaecP9yevakc8Hr28aM3WwKljue hPl1sNWVT0JreH9NsdEPLbI1J095pP1f5I3IYObMv6T1g76skrah6ctLJ5+vktYftH0lGCfrc+Ue UXw/Mbdw9hS0BHlZVxgJF5rAoQQWBNu5NivvKGY8Zxm3uz+/o2EeuxPmOozxZdM31KROhdfJJo1K nyytLRe9RkpOl2v4exjB8zSDVFUvu3eeZyr9sY42XJdkjPRGM/KuSEDUWGHs7YVFc9kAILzeOFB0 aCpw4A5N4PTD/qg7lsDgJ1SvGejPzTOZrkPlsy+GXbNbcarp3SyPWR1qftJGgu2hxXbjD9u8vwb9 jnqMrhyYjwlE2bU/FoCUS3uCrtUEh5d1KQQPzEynB79WZvxJtyFzEaH9k25/pn1wm7HTu1N/6cf0 04FkHxHcYdQTcTAIWIWua5rAwhLZ2RjVxvoXzSS9/sYUl/InYx+2F+Kx8qWsCT99u2UeTxecGTPo VfVd99CGg5pphO/hBUw41n5Yt6MJCbyfdbvyZtzGpUotH5MrdIHPxszuFHtnVoKxKf5kmFBar4Lm ce/BRwEa+3CfRhEnUfz3nbKaXeLOlogby8fnkPwX7f988sen1/qK6G95qrjrB/ccw2hSG5q2vLTy cRlsj9OMk83MXBIhPXM7jQoU21YQ6ZaKwOEEFvh0Gn0BVhC9wDhFk/Q9Uzsr1ps9mYP7Gg52RU8+ 23tVbmiTDd45886xaqjDgej3+/JvIIYDuQO69zQL5xEqA/1bXx7rWgYOkjuiUUKdZ4ryLLkMNkyn Tdk10d11hdhsqQsVt3Pgg9SAcOk+WtaT35kI1yUZX+4ER9O55a72/dHO9v3QxZISyspevMS7HXMB 6w4Aoqd5qrJG73xAMWoPfMDgO3MhPiQekDG5UuvPpj04d17yGTltvya6m9tav8PdnijL793poc5T Z2Ib7Xz4sn1myFkL294UA+nH2pWiHkw7dQ0z81ePz26gXEl0NrfE1tam2JSyK/84SmHZ/pp6IzA5 gGiqp7LIp/DUzeOmnHqGBlrz1rtteTPSg18rM/6kZTM+QfsnfUFkfKHPZiz17kjQ9/mxnKh1trz2 JJ/asN0TFfmkpkyp7RdW1zXKdk0dg/ayNHZm4180Ewv9+emm+7QM/pPNehr5O8/H9Deb5okR0r+E AvOaaYTvSUEpcT8m9d5rt0Vb/nU6bVEpehfRcn+HRrsz+r7V6gj5wDL/K618TK6o4ICakeDum+UP LPC+IG55iPYbkmnB95Qt0zZJzn6rezI58vr+Wm25f0VQSFdkzVLmnaTv8oNK98nIYdrU2Bym8IMm X8Mo6L/MOd7RlOWlli9UgfRfpBons5m5TnCr3nOnGznjLPWkKMcGzCbm6euDFMtN4JACC/LBk+xZ qI4RZqLWGzO2m03/YNZJE/yL3DNA5sEbatLNREx0N1wOLzcumCFL1Us4JjoiWUfb8uy4yGl67KKB y8OPfYNUpgubQ6t6yo5WrfUN1yUhX5+T9+synKcrmY29GCbyUW3qkarSRvOVrvkp7ihixsKhztaP q6f3vR5E6AubmART6M+uPUib0NNnXV07y0u4TVPB21gzpsrz+rqrn47jt0le1zj7NHWMniHjBCuC fs6m/fFHX47q5Wx8FeF3Q/5t3nqforzZ6MFoZOZH2jeYQbT2T7L9uUM64wuDNmOjd1eGoWiy2TPc LtVxqL+11MPS2JnTp6f1L1Pqz9aelsV/bjXNrAVlV/zd2f8kFAZmdhbyPSmAJe7H5F3YbITf4/V0 jkN3b2VdUsmnbUX2CbptM4G2m4F6mJmNvrvkcRsUy0BHQckhZ1uYSW7GfwRlCn4OBRO96pl19W5/ dpCzArX/kxe1wX6O0fId2vtBlY1hlMTmpinPRj5VS+v3lOPkoL6DdkL5itc3WdcICZeYwKEFFpw1 utrJSWcXnBIcxbS/0RzNTAgZsUyfzRXkXZXoye5m4JJkF1m35IkNx3PQoUet6YrLCKc3nbSQYAOs acqz49IXjVLef9ElZSqW1vTF/KzXoqeuJ4v4h+3D8J108d7fbIm1glxywy74HRsK5+kqz8ZetNrl QV0/DkpOOYw2SX76aL06bwvOXYOFDixUPLuZtIZuCv3ZtYeBaJYLkRe/jr6L5bo47MkKXPEbzXX/ QDFbFLVmXfvF4EUiT2uOd0WjHHwcZLT9pG5/shBnFlN4UJ0R5UZLVItu0CbkA+et9ynKczjORg9G IzM9krK5vsHoVA885VRT9+Kgr3eKj/LZNnpXMmw0K7o/8PW7mZyotAPObQo9LIWdyXlAqf3LDPSn dJHmfZn855b0MVEBy+J6KxxUcCAwO5vU949jphkl6Mf8/XN0MDhuPJFYPrnXki4nZhq52dDSqUPB 21tHBpg9X0wkN8wLRWIUBXlDKfI8M5bytXFvjMu/K1R7KjP27gS4eQDf+Cp20swObcdn0/hB50Zh mvG8I6xtebbyTQs47Ti51yhHttt8qYGgwrTKWPL0lzn1l45jqV57Oxdoa3efVlaO0GB4lI5fe5yu uuLIUslwEJW14XJRstzcI5Io6cg1J+n4VQfP0aaeB8HrYPK8QN+85Tr6Rlfmnq9Q/3v30lUHUxBy jSWwT3tv7dJef1+eMaD+/hE6eeoUzcG0Y2sU/8M+Xbwo257T/px/ez+jsysfphdlAhlYoAdPXx2f 1PKX1O1vf48uXNghuvII7Q+kvz11YkFZWgIZJZu/HqaprU3a1HrXhezTzoULtCvb0cqRfRpeeQ2d PH41zbynWBo7Wyb/opWY4uAQ5Nt/i17v/QfRsRUavtmnlT9+L524euYWloLBjE+9lOXbf5XuP/pe esJDJoM99L17b54xwNllZ+8H7eow7/LsammZyvHZG1vyAmKFBn3Zbk/eSCcWc6BlKSCS2RBYysCC jaBIAwLzIPD6sw/RjX/56KiotdY2ff324/MoFmUsGYGLb12g7eG1dOr4Fb6av/TYXXTbl+vyuww1 tjp0x4lLaHDtk3QxPkAPi6EH1AIEQGA5CVx8/Rm68sbPeZUvUHdwjm72d2vLKRhqDQIgYEUAgQUr bEgEAobA/s7L9Pj6T+h/3voFfeNR56LQea3SpvgWnXI/4D8I+Ai8/NhZuvXLL1KusEZ3feJP6QY5 MeFfn36YvvqEM1dBvop1Gj5y5+zvCru5479HAHqAKYAACICAPYFXnrqLMve54x65VILOffYm+8yQ EgRAYOkJ/D8AAAD//37scUcAAB6HSURBVO2df6gj13XHT2CTzUL82vWWNdmFrM2mJQ1YDmvSTajX VBsI+dFYduI0hirBIVQxITjyPzEqJOH1jwQZii1jgpziKj8s41gbsFyKQonsWElTmaJtqoBlkmei V3jbvFesTfUoems9uL2jmblzZ+aONPdKmn2r/Qre08zo/jjnc879OXfuvIXxD+EDAiBgTGD34iO0 dvvDvviV7oDuv/Wo7xpOQMAlcPHx83T7V15yT/3fmRJtPPsgnX67/zLOFk8Adlg8U6QIAiBw/RDY ff1n9Mw//wddOXyCMl+4l04dun50h6YgAAJhAm/BxEIYCq6AgBaBy6/RM8+9TG8ePkxve8e76OyH 7qTTR9G6ajG8zgLv7+5Q79WL1Pnlr2ln+3f0+8sjGh15J6Uzn6KPnT1N8J5kHAJ2SIYzcgEBEAAB EAABEFh9AphYWH0bQ0MQAAEQAAEQAAEQAAEQAAEQAAEQWBoBTCwsDS0SBgEQAAEQAAEQAAEQAAEQ AAEQAIHVJ4CJhdW3MTQEARAAARAAARAAARAAARAAARAAgaURwMTC0tDaCe9dvkTbwzEdWbuJjh/F bmxLxj01+b2dS7Q1GBG91Q525MaTdAI2mcrsWv9x1cvfqut3rfsf5HcJ7NPO5iZZ1e+NN5+m4zOa Qvi1xW2PLr2+RUO+48rJU6fohjk2XgFP1w9NvhdnB5Pc54kDu89DD3FBAARMCFyViYX9y6/T8z94 ip5+vk2/5VIf438n//g2ev8H/5zuOHcnnTl93ESXAxhnl548v0YP8M3fU8U2/edXzx5AGc1FuvSr F+mnnf+iN3kSN6Y+THedOTEzsd3NV6jy2BP01ItdbvhjdMvaSbrlzPvpE/fcS+dvnR1/ZgbKADv0 zN/m6K+/Vff9uoo28Sl43Z+sdvkjWnX9rnsHXh0Aexfp/JHbyXoPSrE9oK+enfbGHPj1xPC7r9D5 tQ/YzDqc2ZlpzKa5CnhOozPzt4XZYWZOCw4Auy8YKJIDARCIQ8B6K0SSn61WiXG5pvxlWGeYpETT 8+pWsrasmQrTF2vIymlb10ypMz2ja+bXMet36iyf8dswXWzP1KBXX4+2e6rEBjNTMAsgbOj4XSqd Zil+nKt0zRJErGuEgH75E75iVN6TxqKvX9ISIj8QmBAYdVjWqX9LnVk1/er6tVb9osVsmp+tLs9p Wi/st4XZYWESxUwIdo8JCsFAAAQWSIAWmNbspLabkwGdO7GQKZRYo9lizUaNlQo5Z9CZZm39Efzs vA1DdMvOxEK6bDDwHbFmMcfSfCBbqPYMJThA0cYbbN2ZKHFt6H7PmjjZavonFbLrFdZoNFi1XGTZ FJ+kWNrEgte4UrbMtsYHiCdEWTIB/fI3X3lfsjqh5PX1CyWBCyCQBAGtwdnq+rVW/aLFbJoRV5fn NK0X9tvC7LAwiWImBLvHBIVgIAACCySQ6MSCmK3ndy5Kre2wGqM+q1dqrH+ABn89acXCKCzx9XVl 2GEZ564TUZqValWWtyYF+LXpEwt9VhDxUqzaDd6xGrHt7WXNJo1ZxVldka2swOTO9eVxiWuL8p44 cmR4PRDggzO37Zi9YmF1gWjVL74B7bLax9VlvTDNYIeFoURCIAACq08gwT0W9ujCF4/Qp7/Dh6GZ Co2ev59m7N/EAwY/e3Txhe/Rk//4Q2r/1tqb4Q2+ecF5+tKX83Tv2VPBwP7z/R168bnvUuW5H1PX iss3dlg7eRt9NPNJuucvz0mbSe3Tr154ml767yt0+DDRa99/gB57yUoqTcXy5+gP6Mok3Sv86477 vkBnjgd3VOLxf/wc/eJ3bxKPbn944Bvf9wm66+yMPQT2NunCdx6jbz/1Iq2lUjTsdunk+S/Ql/Of p7OnbnBT8773L9GFpy7QpStrlP7sp+itr/yIHi1/n34zfIPeeOMYffyhdSrcf44UMb00dI72XqOH zn6G3vm1J+hv7j5HRw/t0XfvPkKf51sX8IkFev7BM8rUdi8+SWu3PzD5rVDv0zfvmmErZSoaFx0u b3ALHKb/pecfeJgmuyukclR+6INElvH437Gz93K/UdhE1w6OaPs7F+mpZ39OVw7fTJ/94l00fOUC PfnE09TuDoluOUm3vff9dN+XuS1PLMgiu5v0wjPfo9oPf0pdXhSO3bJGJ2+6he9VkqYPf+zD9J7I HdKSKEccCrfDC0//E/WHhyl9X5Zu9ZUVLsOFZ+nnl67Qn6TvoY/cGt5XxYynbvkzLe879OMnn6Vf c1c6EeVHonwS3XzHfXwPkrCOGl7tepl5/WLqL7rx5rS7tWmdUT2vK6c+fF8MM/+0kjDTb/f1n9Gj j/w9/Yg3fsd4A3byA5+hh774Efq/f3+JXuXl/32fuI/XLf5WdXfnNfrXn7xMrZd/Tq/+xtoI0Pqs 0W1/8VH65F/dQ+feE+2Tpvop5fzce+nJP72TrOafTyzQg6H9AnTLLU9IlC+z9k8p5wyeFj29j2n9 wnPh+1J8lu9L8TQ/rHS36Nz//As98njc9t2Ap6tYIuVoh17g9Wef/ohuPrZLtW//cNKGnf/SOn39 nj+kf/ja16g66eSdp0cr36Lzp/x+bYtqVo4mcWP3B3noOexgVP7m8uuk7L4I+7kOh28QAIGVIpDc 3MmI1XLuc/l5tqGb8bAXuQyfG4Rlik0WtaJguFEXd0ussMG/VFHe/2DAioowwTjW+Xo7eOfdUkod f9YeBKN+Y6qMxYaCGF9BkJ4la74eyUXXBOHwQ7EaYNqKhU4p4zDPMnvNwIgNBtt8lcI2G4yWsDxl 2PY9cqOy3eTaenhfCCM7OGCGHXf/kDTLF1yd/f7GN4wMYzS4Mt5qTNXR79NSBomVI56n5J98wzZJ COvQe0QlqmyY8dQtf+rwKp/xl/cttu6WvYjHeDz5ieUb/YD+pqdqeaMYurmY+otRvHnsbuifRnK6 cAy/PftqlHdD/bbb5VC7FfRRVRkrOSvKgmHd83w1ep8ZE/1m76HEVysq91gw8GvJz1x9Qt8R7Z8Z TxNHUesVklPVn5DulKvCT65F6GfaD0msHPE2embfxa1fqcBCtadhObIsqNcf5BGM7TBkRuVvDr9O zO7z2s+kKCEOCIDANUEg2Uch3P0KeIORyhZZux8cbEQx22Yl6dn+VK7Imp0u67b4JoLS9UJjK5zA wN+ApfMl1rLidlqsWspPOmv+wd6YbbQbrFav8z0A6qyYdQeGGVbhewLU+fXJX63BNgaqQfGY9Zo1 VqnWWK1WEo3ntIE3Y1vSowJ8koTvP9DudlmzKu9LkGKN4AYBwQYvlWO1Voe1G2WRL1/SwepLe7ZE c2IhW2LNeik0IM6uVxe898GAtRw7NRpVlnM71+l1Vhc2rLFWL/g4jqEdHK8bdsOdf2sfkTr3o2pp fWITv6+F3TXelTFrFlJioJErVif+0u20Wa1SnExQqfNJshxxTST/DA8mZvuOGU/d8mde3jdqdv1h dfBrG8FpzTGr510b5VhPVVXEM3YglK5+VnRTfzGMZ2x3U/80lDNAVvdU3z8N9eMDDfcxAsvX8pUG 6/U6rJxPizrAuq4qY/bAJsXyxTJrtNqs2+PtitQuWfGi2gdt/fhgQ5azUG1yOduslHPLgd2WhuW0 fVS73ZT8zNKD4rZ/xjx1PcTWy7g/YarfRMwk6wkDLpJuKd4vaLfrYnNPy5a5cpO1qgXHv1Os1pfr V8NyZImp3R/kcSRZtfyMT54blT/j/CwFE7K7JKO+/Sw58QEBEFhVAolOLKhnw1Msm19nlXqLbUU8 RjhoF0UHKleRVxdYZtlmZfGGgvDMdrvo3TnO1+z75bIxx1tt1mgrJiScQFrPRMoJT47HrOrINm1i Ybvl6ZcptnypbLfdu+DE0oHffA1eqsB6Uts76lYEs/CdLF8Wc5zMHhxO7kwL+7iTNKrvAttY2OBL VmnkraooR9+ds2IY28HJzt8RT7FKJzBxMdpmG1FOLos883gg3jaSKjQVoYdseyA5gxMi8XIkdT7C g4nZvjM/z3jlTwaoVd6lgVRoxYDvN3+ZlvOb7ziufmb+Yt39ct9qo+Nncr2kY3dz/zSUcz74TNc/ TfXbqLkbGxMr+Fa+WKsAvUF7mDV/gw+foN5W1at8xZN7xzgTUS/q6ifLud6U21Re1sUEvWoCJGiI mH4t1S+k0f7JcurxDMqpf65VvxjqF5YqJk/T8h7OcPYVSbdy126rxMaWqSLv1VkfvirMuSkg+7Zp ObJSNOoPSrLq+Jk1yDcqf8b5WRrKnyXaXZJR136yhDgGARBYPQKJTixY+Abdmu+uxmQG2Lrb4PyV Qkv+5UcoUqy5NWKj4YAvpXf+RiPWE3cOM6zlWwQhbRpo9FYHxkRjx+NHzHtM8YrZgycrcrfsTn4E 5bd+HXirNYI6SJV7vhZ4VGLcZTmHaaYcnIyx0l3EJ45+XhjXxoVqmw2GIzbc7rKS1OHMLuX1j17+ 0yZ3LBrGdnBQyh3x5TG3MuOPEbiTNZkS893McWQJf12FciT5p9wxtGWbbZf5ec7OI8hJr7yPWUOs SuCPd0kDuH7dvdumWs0QzNX0PK5+Jv5iyWQYz8ju8/inoZym2J14ev5pqp9nY+JLwuXhuiXGqOdN IIfLmKzgmA2tx8+cdnM07LPijFch6+kny7kellNazTVdTktmL62pdbbkZ/HbPy/t+XjKbOMfa9Uv RvqpZPF0nsrTtLyrspx1TdLN9QfBJuP2tTy53TDc46VHahPqD0qyxvezIACN8reQ/Kz8PX4Lt7sk o2ubePYLcsE5CIDAqhFIfGLBBjhkPf64QblYYJm0d8fFHXgWfW+MkDqN0gSEGzb4XZVv20tLHqdX rNFmFZXlEicWWkVnSWtEHp4M7ky+I69UuZe7wWkPr1FZzoDdksHLI5qv336hATd/hWXetWuE/tHW ifNLHBntdIzt4Ighd8TDS+PjyBo3jDWg9SbjrDKQLRRZtd5gne4Gt4rq47dDsNwEzxdSjiT/dDsf nmSz7TI/z9l5ePLYR15Zczu3wRD+c1lGr97id9DdiZ90iU8NLusTVz8Tf7FkNoxnZPc5/NNUzjnN Itt+dnk31c+zcYo/Ty/NXdnSj7piCXm4jPEgww1WK+ZDj5/J5T0bY8VCHP0qjs+r5exMl9NnC0/n 6HaFR5D8LH7756WtlnMGT5+c+ida9YuRfiqZPJ2n8kyyHEm6VZ3HyMJsPLk93zYtR5yLaX9QkjW+ nzl2MCl/8+TnM7/Hb+F2l2TUs59PQJyAAAisIIGrNLHgJzke9FltPStWLfC3RkiDI69ynHSGUimW Uv5ZAy3+KsOeNKySKr9SaPM4vwxRZ+HGLiqk6rone3TF7i3jpYiBtZCBMqwtqSd3rLyG15UjTt5u WNPvOHkMWVWsSkgHVpTY+cqbOzqrIk0FUsSLI6MVbQ47OLl6A40s64SfRFDINselqZtXZVhdLgeT bDwOiZUjufyFNmzz5IkqG/PznJ1H0AKirEWUxWB4ebkuZWv2RqlbdTGQy9f74SgLu6Khn7a/OEKa xDOyu6eLtn9aoprIOacd9PzTVD8vnvKRhe2GaDdDbYA0kBITCaLt9CYmF1P+PDlDjwVZnKf6RNAQ XlpRsk1iTE0zKg3pumpCZRrPoJgG51r1i5F+KqEknUszVi8mVY6Ebl5bKcqTqHs9uT3f9q5p1xMi T/44jk5/UI6n046Zlj/T/EKm91hNLUdWPF27Cxl17RcSEhdAAARWjMCBmFiwmfo3O/MGmF7lSLp3 /3jl524mla30jEyn1REI5eDJHl2xS0v7xBJAf0LdijvpkvftozC9sxYnb38++mfx8hAM+cRIR54Y cTKUf/dNnOgLpIgRT0bfEktdOzi5io5RhJ4K4ea8NGJ9vglprVJi+az7OI07YMj5lubznoPYayKx ciQ6H6rnqr1HfKLKxvw8PZ2j8ggaQPii6NwGQ4TPe1X3Gfg0a/MJpZ70aJPK38MpmF7R1U/HX2SZ NOMZ2d3TRds/haiacop4Zgd6/mmqnxcvva7YT2XKigXxPD9f0ZQrNfgeRvJsp5duVNkw1U89saCz EmC2bBOLTfWzqDS867o8zbzEH0urfjHSz5+ffebpHGVrf6wEypHQzesTCH8Tda8nt3JiIan+oJBV 1Y55MgbZGpc/w/z8NrTOomULh7WuaNhdyKhrP3XOuAoCILA6BA7QxALvkIsBtHxnXlr6pt2QeJ2Z VKFhZDXREYgYbE5PNF7FLvLgz9DKz2nbaUsTLkEZROWu1+BNl1nn13j69SruwEu2q5dPRwzE+Oy3 YuLBC2lyFE9GK2VjOzhiiY5RYhMLfh5j/tx0VXrNZdkH8yqUI2nQE1pCyn3XnfQLdshcrebnGd/2 bp7CB4JlzQ2g+h60xEZ4+UpNvBbXtM5RZaG+pq+fnM50f5FD+o9nxjOy+xz+6RdPnM2UU4Q0O9Dz T1P9pHhiUztP3nG/FrFiQYqXrYZfOSzZaDHlT17xpXj8R3o9rjdI9PTwH8X0a6P2T+KixdMvoemZ Vv1ipJ9Kspg8VVH5taWUI6Gb7sBUsl9S/UEhq04/S5JTt/wZ5acy3hLtLmTUtZ8k56jHCnxzTncF MlFuCf0/KT8cggAIJEIg0YmF4UaHdfpRI0deCYol8/ztDtLDpN6EA7FKaC8Bj9NYimNf5asBRJpp /rpGL6x8NBqFIoqfxYZ+qXVnp2LxU4yDeBW7d8eTWOgNDtLu8hRsoETlrtPgxRA7dpB4b1wYb1RF 5zdXDWwyKe38bD0Ksvjn0ePZwFLZ2A4OL72BRmzIWgHHXe8tIsHlnomXI2kpaNDuw44n52IGNipM 8W3vxjYr79KqI3e/EP4dmkxxM1nYt75+wayn+UswrHw+NZ6h3c39U5bMfzxVTn9Q7TPd8m6qnxiM cp8Ktn8t6a1H/gG7NNDnj+gEW7h+3XtV6qLKn9ijhnhbG3ghjqy7X04V9ph+bdj+mfFUyal/Tat+ MdQvLFVMnuGI4srCy5HQTX9gKvtSsDwIgfnBwvqDQladftYc5c8oP1lz93iJdhcy6tvPlU7e88J+ VEt940mExwEIgMA1QSDRiYVOyd6kMFsos1a3zwb8jQ5jXvsPtrr+d3LnAptU+d49nGblZk/cgRmP BnwjyDor8I2j0ornB+UBDPE7ybXOltPJ4rv0bvdYJcdnTIvtSGPJg83JclK+q/ZwsrP2MNRZmyQy 5m87GA75H9dtxHfedl6XZL0qciR+G/JjKUvpjqclY71nD6/Hg57YuduqeL3N4Zy4onLXafCkfE0O R1us02rx9063WafTZHlHv1SuzNqdzuR6u7Mh7GNnwV8bJQZcKVZqbtjseFq1gvcu9qgOromYXhyN xtXUDk5mugMNT0bdI65TNsWXN9dYt78t/NDylxK/bjfSadYMvmcu6XLEN+YsCLt7fj3o1cVqBUvW KLsb8RRlTKP8Sfi1y7sTdyBNlEz484nIiHlMKTeDQyP9DP3FWkpr4memdjf2T0M5DfDLUbT901Q/ /tx/SpSjNKu2+2zE2712xZscsHwuOGBvFty6gLcdvM61P/wtSnXv9caLLH8jaQKZ0uusO7AbuX6r LCaWVXJO5DLxa9P2z5CnbHvTY636xVQ/SzgTnqbl3QSG0M1gYGpajricRv1BIWu4jE173MC4/Bnm NzFDUnYXMhrYz/UXkYb7+KaXlhsE3yAAAtcegasysTDpeIuOklupuN98QLQlj7ptqP2mvzOkSkP5 bCcfdjWluzrx4znG9DViroz2d7AjZ8XwNiL0hw3mG5wE8fZRiIiXrYTv5vOK2V1OHpbFW4oXNXBz NNT68jfMEbLyO1bBvRKGXe+1aDYLr9Nrn+fYlMUoWjL6A+txMLKDk6E80Ajq75dp3jOuk/OqONev rOWE7vHkO+dsJBjIKulyJO7QRZb3eBMLcXmalj+BSbO8i3iMv9rWmWSz+C/rTSxm+pn6i2k8+dWt UXWE2u5m/mkup2c//SOT8m6mH+cp9vGI5hlsA+RXUU7qBGvjRkU5jGof9PUbsbo0meGrj6R8g3Ja 5I38eo72z4SnvocoYujUL3PoZ8STTyyYtisKTadfEquavMGk8DexcpHL47xpJOgzpuXIetONdn/Q 0A7G5c8wPwt4Ynaf034T5xBpuHWa5wvTnQe/ggAIHGQCiU4sDDdarJjPKjs3VicknS+xbvAuq0Rv uNGcrExQdVjSmRxfjRBYfynF3WhWxCDcFz+VYZV2dDwriWG/xdZzGf4smFsB2t+qZXgzB6ZOB0v1 iq9eo6Rkky02wpMKlmDSc7JhWay7eLacixzkhBpLqcPoceWTBPI+YZas/DPkd6qzivCpXImFXmJg R1nAf49DLuYGntp2cKT02Hg7JS9AAUUSI9Ys5ZS+YtkgX6qzKcWIv4EuyXI08K1KsX2Er1pptPhq IXsyJMo/TXjOU/5c0Drl3Y1jfdedTrD1dprgUnA53DzHZvqZ+otpPEtDc7vr++c8cppbw8Q/rdz0 9bNl3GiWxV4ek3KUzrNas85yTp0aHHxZsazVAulQnWuXv2reKX+qtyPwuGb6DVmj6G427LWX+eK6 aH/9e7/Yuhn59ZztnwlPW9r5/seuX+bQz4gnX2c4T7uiRYXrZvutt6+SmFjgj3zaD8x6b5RS+Yxp ObLk1OoPzmEHo/I3R36J2X0B9rP6r27dZfcLPF/Q8iUEBgEQOFAE3mJJwwt1wp89urwzoMHumI4c 2qfhiOjGk6fo+A2HYsmxu7NJW4N9Wls7RKPxW+n4TcfphrfHibtPO5ubNNg/RGs83/GRG+nk8aMU J2YswRYRaH+XNje2iCtHo+GQ1k6+m07E5LKI7Jefxh5tvvYbGh05RkdGQ8vwdOr4DcvPVjeHa8IO +7R7eUC7w32u3YiG3K9PnjpFcd0lyXJ0efN1GtAROrQ/pjUu49EDVeh0nUMVfpP+7rab6Rtd/lu2 QsMf3E8Hz6tN/cU0HtE8dtf3T3M5VRZd9jV9/SyJ9mlvj+gQLz+HrH+7P6Pza3fSS/wXPrFAD545 Ghbbqss2d4g3trQ/4u3lqROx64hwYvGu7PE2ur/LmzFLTl7Hx23b46W+yFAGPBeZ/YFM63ooRxb4 hPqDV6H8mbnVtWV3Mx0RCwRAYNkErtLEwrLVQvogAAIgkByB1y88RO/+9GOTDNdb2/T1c8eTyxw5 rTyBvcubtD2+iU/Cvt2n6yuP300f+EqdX0tRY6tDHzmxcjN2Pn0XdQKeiyKJdEAABEAABEDAI4CJ BY8FjkAABEAgNoH9nYv07fJP6PeXf0HfeMwa3FmfAvXZN+mUfYL/ILAQAhcfP0+3f+UlyuTW6e6P /xmd5gsT/u3pR+jh71hrFfgnX6fxo3cdrNV3tmQH8j94HkizQCgQAAEQAIFrnAAmFq5xA0J8EACB q0Ng9+IjtHb7w77MK90B3X+rYjm6LxROQECPgDsQVsbKlGjj2QfptH8xgzIoLtoEwBOeAAIgAAIg AAKLJ4CJhcUzRYogAALXA4HLr9Ezz71Mbx4+TG97x7vo7Ifu5HeSsRT9ejB90jru7+5Q79WL1Pnl r2ln+3d8lcyI71PzTkpnPkUfO3saKxU0DQKemsAQHARAAARAAARiEMDEQgxICAICIAACIAACIAAC IAACIAACIAACIKAmgIkFNRdcBQEQAAEQAAEQAAEQAAEQAAEQAAEQiEEAEwsxICEICIAACIAACIAA CIAACIAACIAACICAmgAmFtRccBUEQAAEQAAEQAAEQAAEQAAEQAAEQCAGAUwsxICEICAAAiAAAiAA AiAAAiAAAiAAAiAAAmoCmFhQc8FVEAABEAABEAABEAABEAABEAABEACBGAQwsRADEoKAAAiAAAiA AAiAAAiAAAiAAAiAAAioCWBiQc0FV0EABEAABEAABEAABEAABEAABEAABGIQwMRCDEgIAgIgAAIg AAIgAAIgAAIgAAIgAAIgoCaAiQU1F1wFARAAARAAARAAARAAARAAARAAARCIQQATCzEgIQgIgAAI gAAIgAAIgAAIgAAIgAAIgICaACYW1FxwFQRAAARAAARAAARAAARAAARAAARAIAYBTCzEgIQgIAAC IAACIAACIAACIAACIAACIAACagKYWFBzwVUQAAEQAAEQAAEQAAEQAAEQAAEQAIEYBDCxEAMSgoAA CIAACIAACIAACIAACIAACIAACKgJYGJBzQVXQQAEQAAEQAAEQAAEQAAEQAAEQAAEYhDAxEIMSAgC AiAAAiAAAiAAAiAAAiAAAiAAAiCgJoCJBTUXXAUBEAABEAABEAABEAABEAABEAABEIhBABMLMSAh CAiAAAiAAAiAAAiAAAiAAAiAAAiAgJoAJhbUXHAVBEAABEAABEAABEAABEAABEAABEAgBgFMLMSA hCAgAAIgAAIgAAIgAAIgAAIgAAIgAAJqAv8PsGaQ7CTY6XkAAAAASUVORK5CYII= --Apple-Mail=_9A64C7D3-A0AC-4D20-B973-F8E9FC083567 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It=E2=80=99s at the end of section 9. > > > valid nonce the ITR is requesting to be echoed within a small = window of time.=20 > > > The goal is to convince the ITR that the ETR=E2=80=99s RLOC is = reachable even when it > > > may not be reachable." attack listed in the document in that a: = it doesn't > > > require any guessing, and b: makes an ETR appear down, not up. > >=20 > > You can=E2=80=99t overfill any cache. An xTR just remembers the last = nonce that came with the E-bit set and when it returns packets it uses = that nonce. > >=20 > > Um, I don't think this is right (or I've misunderstood) - you don't = store "the last nonce that came with the E-bit set" (one number), you = have to store "the last nonce that came with the E-bit set for every ITR = which is sending them=E2=80=9D. >=20 > Right. The context was from a single encapsulator. >=20 > > These have to be stored somewhere, and this is a limited size space = (N slots). If I send you N+1 spoofed packets you will have to evict = something from this space -- what am I missing? >=20 > They are stored in the map-cache since you encap to that ITR (which is = now an ETR). So its a 24-bit number you use in an RLOC data structure in = your implemenation. I have implemented this way twice (in 2 different = implementations). >=20 > Ok, this seems seems like a good optimization (but does require that = the RLOC storage needs to be larger ) - why not suggest this in the = document? It would only take a sentence or two, and would make future = implementations more likely / resilient.=20 Because we have decided that many things like this be left for = implementor creativity and experimentation. >=20 > > Yes, many implementations default to not setting advertising they = are echo-nonce capable in Map-Replies. So RLOC-probing tends to be used = for RLOC reachability. Plus we added features into RLOC-probing that = makes it more useful now (lisp-crypto key exchange for one). > >=20 > >=20 > > Pointer? >=20 > The LISP WG can provide pointes. Damien and Luigi did extensive = research on this. >=20 >=20 > Again, something like "many implementations default to not advertising = that they are echo-nonce capable in Map-Replies and so RLOC-probing = tends to be used for RLOC reachability." would help - there is no harm = in trying to make things easier for your readers / future implementors. I have added your text. See new diff enclosed. Dino --Apple-Mail=_9A64C7D3-A0AC-4D20-B973-F8E9FC083567 Content-Disposition: attachment; filename=rfcdiff-rfc6830bis-27.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-rfc6830bis-27.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-lisp-rfc6830bis-26.txt - = draft-ietf-lisp-rfc6830bis-27.txt=20 =20 =20 =20 =20 =20 =20 = = = =
< draft-ietf-lisp-rfc6830bis-26.txt  =  draft-ietf-lisp-rfc6830bis-27.txt >
=
Network Working = Group D. Farinacci = Network Working Group = D. Farinacci
Internet-Draft = V. Fuller Internet-Draft = V. Fuller
Obsoletes: 6830 = (if approved) D. Meyer = Obsoletes: 6830 (if approved) = D. Meyer
Intended status: = Standards Track D. Lewis = Intended status: Standards Track = D. Lewis
Expires: May 8, 2019 = Cisco Systems Expires: August 10, 2019 = Cisco Systems
= A. Cabellos (Ed.) = A. Cabellos (Ed.)
= UPC/BarcelonaTech = UPC/BarcelonaTech
= November = 4, 2018 = February 6, = 2019
=
= The Locator/ID Separation Protocol (LISP) The Locator/ID Separation Protocol = (LISP)
= draft-ietf-lisp-rfc6830bis-26 = = draft-ietf-lisp-rfc6830bis-27
=
Abstract = Abstract
=
This document = describes the Data-Plane protocol for the Locator/ID This document describes the Data-Plane protocol for = the Locator/ID
Separation = Protocol (LISP). LISP defines two namespaces, End-point = Separation Protocol (LISP). LISP defines = two namespaces, End-point
Identifiers = (EIDs) that identify end-hosts and Routing Locators Identifiers (EIDs) that identify end-hosts and = Routing Locators
(RLOCs) that = identify network attachment points. With this, LISP (RLOCs) that identify network attachment points. = With this, LISP
effectively = separates control from data, and allows routers to create = effectively separates control from data, and = allows routers to create
overlay = networks. LISP-capable routers exchange encapsulated packets = overlay networks. LISP-capable routers = exchange encapsulated packets
according to = EID-to-RLOC mappings stored in a local Map-Cache. according to EID-to-RLOC mappings stored in a local = Map-Cache.
=
skipping to = change at = page 1, line 46 =C2=B6 = skipping to change at page 1, line 46 =C2=B6
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
Task Force = (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also = distribute
working = documents as Internet-Drafts. The list of current Internet- = working documents as Internet-Drafts. The = list of current Internet-
Drafts is at = https://datatracker.ietf.org/drafts/current/. Drafts is at = https://datatracker.ietf.org/drafts/current/.
=
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
and may be = updated, replaced, or obsoleted by other documents at any = and may be updated, replaced, or obsoleted = by other documents at any
time. It is = inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as = reference
material or to = cite them other than as "work in progress." material or to cite them other than as "work in = progress."
=
This = Internet-Draft will expire on May 8, = 2019. This Internet-Draft will = expire on August 10, 2019.
=
Copyright = Notice Copyright Notice
=
Copyright = (c) 2018 IETF Trust and the persons = identified as the Copyright (c) = 2019 IETF Trust and the persons identified = as the
document = authors. All rights reserved. = document authors. All rights reserved.
=
This document = is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF = Trust's Legal
Provisions = Relating to IETF Documents = Provisions Relating to IETF Documents
= (https://trustee.ietf.org/license-info) in effect on the date = of = (https://trustee.ietf.org/license-info) in effect on the date of
publication of = this document. Please review these documents publication of this document. Please review these = documents
carefully, as = they describe your rights and restrictions with respect = carefully, as they describe your rights and = restrictions with respect
to this = document. Code Components extracted from this document must = to this document. Code Components extracted = from this document must
include = Simplified BSD License text as described in Section 4.e of = include Simplified BSD License text as = described in Section 4.e of
the Trust = Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without = warranty as
=
skipping to = change at = page 2, line 40 =C2=B6 = skipping to change at page 2, line 40 =C2=B6
5.2. LISP = IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 14 = 5.2. LISP IPv6-in-IPv6 Header Format . . = . . . . . . . . . . . 14
5.3. Tunnel = Header Field Descriptions . . . . . . . . . . . . 15 5.3. Tunnel Header Field Descriptions . . . . . . = . . . . . . 15
6. LISP = EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . 20 = 6. LISP EID-to-RLOC Map-Cache . . . . . . = . . . . . . . . . . . 20
7. Dealing = with Large Encapsulated Packets . . . . . . . . . . . 20 = 7. Dealing with Large Encapsulated Packets = . . . . . . . . . . . 20
7.1. A = Stateless Solution to MTU Handling . . . . . . . . . . 21 = 7.1. A Stateless Solution to MTU Handling = . . . . . . . . . . 21
7.2. A = Stateful Solution to MTU Handling . . . . . . . . . . . 22 = 7.2. A Stateful Solution to MTU Handling = . . . . . . . . . . . 22
8. Using = Virtualization and Segmentation with LISP . . . . . . . 22 = 8. Using Virtualization and Segmentation = with LISP . . . . . . . 22
9. Routing = Locator Selection . . . . . . . . . . . . . . . . . . 23 = 9. Routing Locator Selection . . . . . . . = . . . . . . . . . . . 23
10. Routing = Locator Reachability . . . . . . . . . . . . . . . . 25 = 10. Routing Locator Reachability . . . . . = . . . . . . . . . . . 25
10.1. Echo = Nonce Algorithm . . . . . . . . . . . . . . . . . . 26 = 10.1. Echo Nonce Algorithm . . . . . . . = . . . . . . . . . . . 26
11. EID = Reachability within a LISP Site . . . . . . . . . . . . . 27 11. EID = Reachability within a LISP Site . . . . . . . . . . . . . 28
12. Routing = Locator Hashing . . . . . . . . . . . . . . . . . . . 28 = 12. Routing Locator Hashing . . . . . . . . = . . . . . . . . . . . 28
13. Changing = the Contents of EID-to-RLOC Mappings . . . . . . . . 29 = 13. Changing the Contents of EID-to-RLOC = Mappings . . . . . . . . 29
13.1. = Database Map-Versioning . . . . . . . . . . . . . . . . 30 = 13.1. Database Map-Versioning . . . . . = . . . . . . . . . . . 30
14. Multicast = Considerations . . . . . . . . . . . . . . . . . . 31 = 14. Multicast Considerations . . . . . . . = . . . . . . . . . . . 31
15. Router = Performance Considerations . . . . . . . . . . . . . . 31 15. = Router Performance Considerations . . . . . . . . . . . . . . 32
16. Security = Considerations . . . . . . . . . . . . . . . . . . . 32 = 16. Security Considerations . . . . . . . . = . . . . . . . . . . . 32
17. Network = Management Considerations . . . . . . . . . . . . . . 33 = 17. Network Management Considerations . . . = . . . . . . . . . . . 33
18. Changes = since RFC 6830 . . . . . . . . . . . . . . . . . . . 33 = 18. Changes since RFC 6830 . . . . . . . . = . . . . . . . . . . . 33
19. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 34 = 19. IANA Considerations . . . . . . . . . . = . . . . . . . . . . . 34
19.1. LISP = UDP Port Numbers . . . . . . . . . . . . . . . . . 34 = 19.1. LISP UDP Port Numbers . . . . . . = . . . . . . . . . . . 34
20. References = . . . . . . . . . . . . . . . . . . . . . . . . . 34 20. References . . . . . . . . . . . . . . . . . . . = . . . . . . 34
20.1. = Normative References . . . . . . . . . . . . . . . . . . 34 = 20.1. Normative References . . . . . . . = . . . . . . . . . . . 34
20.2. = Informative References . . . . . . . . . . . . . . . . . 35 20.2. = Informative References . . . . . . . . . . . . . . . . . 36
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 39 = Appendix A. Acknowledgments . . . . . . . = . . . . . . . . . . . 39
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 40 = Appendix B. Document Change Log . . . . . = . . . . . . . . . . . 40
B.1. = Changes to draft-ietf-lisp-rfc6830bis-26 = . . . . . . . . 40 B.1. = Changes to draft-ietf-lisp-rfc6830bis-27 = . . . . . . . . 40
B.2. = Changes to draft-ietf-lisp-rfc6830bis-25 = . . . . . . . . 40 B.2. = Changes to draft-ietf-lisp-rfc6830bis-26 = . . . . . . . . 40
B.3. = Changes to draft-ietf-lisp-rfc6830bis-24 = . . . . . . . . 40 B.3. = Changes to draft-ietf-lisp-rfc6830bis-25 = . . . . . . . . 40
B.4. = Changes to draft-ietf-lisp-rfc6830bis-23 = . . . . . . . . 40 B.4. = Changes to draft-ietf-lisp-rfc6830bis-24 = . . . . . . . . 40
B.5. = Changes to draft-ietf-lisp-rfc6830bis-22 = . . . . . . . . 40 B.5. = Changes to draft-ietf-lisp-rfc6830bis-23 = . . . . . . . . 40
B.6. = Changes to draft-ietf-lisp-rfc6830bis-21 = . . . . . . . . 40 B.6. = Changes to draft-ietf-lisp-rfc6830bis-22 = . . . . . . . . 40
B.7. = Changes to draft-ietf-lisp-rfc6830bis-20 = . . . . . . . . 41 B.7. = Changes to draft-ietf-lisp-rfc6830bis-21 = . . . . . . . . 41
B.8. = Changes to draft-ietf-lisp-rfc6830bis-19 = . . . . . . . . 41 B.8. = Changes to draft-ietf-lisp-rfc6830bis-20 = . . . . . . . . 41
B.9. = Changes to draft-ietf-lisp-rfc6830bis-18 = . . . . . . . . 41 B.9. = Changes to draft-ietf-lisp-rfc6830bis-19 = . . . . . . . . 41
B.10. = Changes to draft-ietf-lisp-rfc6830bis-17 = . . . . . . . . 41 B.10. = Changes to draft-ietf-lisp-rfc6830bis-18 = . . . . . . . . 41
B.11. = Changes to draft-ietf-lisp-rfc6830bis-16 = . . . . . . . . 41 B.11. = Changes to draft-ietf-lisp-rfc6830bis-17 = . . . . . . . . 41
B.12. = Changes to draft-ietf-lisp-rfc6830bis-15 = . . . . . . . . 41 B.12. = Changes to draft-ietf-lisp-rfc6830bis-16 = . . . . . . . . 41
B.13. = Changes to draft-ietf-lisp-rfc6830bis-14 . . . . . . . . 42 = B.13. Changes to draft-ietf-lisp-rfc6830bis-15 . . . . . . . . = 41
B.14. Changes to draft-ietf-lisp-rfc6830bis-13 = . . . . . . . . 42 B.14. Changes to = draft-ietf-lisp-rfc6830bis-14 . . . . . . . . 42
B.15. Changes to draft-ietf-lisp-rfc6830bis-12 = . . . . . . . . 42 B.15. Changes to draft-ietf-lisp-rfc6830bis-13 = . . . . . . . . 42
B.16. Changes to draft-ietf-lisp-rfc6830bis-11 = . . . . . . . . 42 B.16. Changes to draft-ietf-lisp-rfc6830bis-12 = . . . . . . . . 42
B.17. Changes to draft-ietf-lisp-rfc6830bis-10 = . . . . . . . . 42 B.17. Changes to draft-ietf-lisp-rfc6830bis-11 = . . . . . . . . 42
B.18. Changes to draft-ietf-lisp-rfc6830bis-09 = . . . . . . . . 43 B.18. Changes to draft-ietf-lisp-rfc6830bis-10 = . . . . . . . . 42
B.19. Changes to draft-ietf-lisp-rfc6830bis-08 = . . . . . . . . 43 B.19. Changes to draft-ietf-lisp-rfc6830bis-09 = . . . . . . . . 43
B.20. Changes to draft-ietf-lisp-rfc6830bis-07 = . . . . . . . . 43 B.20. Changes to draft-ietf-lisp-rfc6830bis-08 = . . . . . . . . 43
B.21. Changes to draft-ietf-lisp-rfc6830bis-06 = . . . . . . . . 43 B.21. Changes to draft-ietf-lisp-rfc6830bis-07 = . . . . . . . . 43
B.22. Changes to draft-ietf-lisp-rfc6830bis-05 = . . . . . . . . 44 B.22. Changes to draft-ietf-lisp-rfc6830bis-06 = . . . . . . . . 43
B.23. Changes to draft-ietf-lisp-rfc6830bis-04 = . . . . . . . . 44 B.23. Changes to draft-ietf-lisp-rfc6830bis-05 = . . . . . . . . 44
B.24. Changes to draft-ietf-lisp-rfc6830bis-03 = . . . . . . . . 44 B.24. Changes to draft-ietf-lisp-rfc6830bis-04 = . . . . . . . . 44
B.25. Changes to draft-ietf-lisp-rfc6830bis-02 = . . . . . . . . 44 B.25. Changes to draft-ietf-lisp-rfc6830bis-03 = . . . . . . . . 44
B.26. Changes to draft-ietf-lisp-rfc6830bis-01 = . . . . . . . . 44 B.26. Changes to draft-ietf-lisp-rfc6830bis-02 = . . . . . . . . 44
B.27. Changes to draft-ietf-lisp-rfc6830bis-00 = . . . . . . . . 45 B.27. Changes to draft-ietf-lisp-rfc6830bis-01 = . . . . . . . . 44
= B.28. = Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 45
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 = Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 45
=
1. = Introduction 1. Introduction
=
This document = describes the Locator/Identifier Separation Protocol This document describes the Locator/Identifier = Separation Protocol
(LISP). LISP = is an encapsulation protocol built around the (LISP). LISP is an encapsulation protocol built = around the
fundamental = idea of separating the topological location of a network = fundamental idea of separating the = topological location of a network
attachment = point from the node's identity [CHIAPPA]. As a result attachment point from the node's identity [CHIAPPA]. = As a result
LISP creates = two namespaces: Endpoint Identifiers (EIDs), that are LISP creates two namespaces: Endpoint Identifiers = (EIDs), that are
used to = identify end-hosts (e.g., nodes or Virtual Machines) and = used to identify end-hosts (e.g., nodes or = Virtual Machines) and
=
skipping to = change at = page 4, line 13 =C2=B6 = skipping to change at page 4, line 13 =C2=B6
provisioning = is required or necessary. = provisioning is required or necessary.
=
LISP is an = overlay protocol that separates control from Data-Plane, = LISP is an overlay protocol that separates = control from Data-Plane,
this document = specifies the Data-Plane, how LISP-capable routers this document specifies the Data-Plane, how = LISP-capable routers
(Tunnel = Routers) exchange packets by encapsulating them to the (Tunnel Routers) exchange packets by encapsulating = them to the
appropriate = location. Tunnel routers are equipped with a cache, appropriate location. Tunnel routers are equipped = with a cache,
called = Map-Cache, that contains EID-to-RLOC mappings. The Map-Cache = called Map-Cache, that contains EID-to-RLOC = mappings. The Map-Cache
is populated = using the LISP Control-Plane protocol = is populated using the LISP Control-Plane protocol
= [I-D.ietf-lisp-rfc6833bis]. = [I-D.ietf-lisp-rfc6833bis].
=
LISP does = not require changes to either host protocol stack or to = LISP does not require changes to either = the host protocol stack or to
underlay = routers. By separating the EID from the RLOC space, LISP = underlay routers. By separating the EID = from the RLOC space, LISP
offers native = Traffic Engineering, multihoming and mobility, among offers native Traffic Engineering, multihoming and = mobility, among
other = features. other features.
=
Creation of = LISP was initially motivated by discussions during the Creation of LISP was initially motivated by = discussions during the
IAB-sponsored = Routing and Addressing Workshop held in Amsterdam in IAB-sponsored Routing and Addressing Workshop held in = Amsterdam in
October 2006 = (see [RFC4984]). October 2006 (see = [RFC4984]).
=
This document = specifies the LISP Data-Plane encapsulation and other This document specifies the LISP Data-Plane = encapsulation and other
LISP = forwarding node functionality while [I-D.ietf-lisp-rfc6833bis] = LISP forwarding node functionality while = [I-D.ietf-lisp-rfc6833bis]
=
skipping to = change at = page 21, line 49 =C2=B6 = skipping to change at page 21, line = 49 =C2=B6
then forwards = each fragment to the destination host of the then forwards each fragment to the destination host = of the
destination = site. The two fragments are reassembled at the destination site. The two fragments are reassembled = at the
destination = host into the single IP datagram that was originated by = destination host into the single IP datagram = that was originated by
the source = host. Note that reassembly can happen at the ETR if the = the source host. Note that reassembly can = happen at the ETR if the
encapsulated = packet was fragmented at or after the ITR. encapsulated packet was fragmented at or after the = ITR.
=
This behavior = MUST be performed by the ITR only when the source host This behavior MUST be performed by the ITR only when = the source host
originates a = packet with the 'DF' field of the IP header set to 0. originates a packet with the 'DF' field of the IP = header set to 0.
When the 'DF' = field of the IP header is set to 1, or the packet is an = When the 'DF' field of the IP header is set = to 1, or the packet is an
IPv6 packet = originated by the source host, the ITR will drop the IPv6 packet originated by the source host, the ITR = will drop the
packet when = the size is greater than L and send an ICMPv4 ICMP packet when the size (adding = in the size of the encapsulation header)
Unreachable/Fragmentation-Needed or ICMPv6 = "Packet Too Big" message is = greater than L and send an ICMPv4 ICMP Unreachable/Fragmentation-
to the = source with a value of S, where S is (L - H). Needed or ICMPv6 = "Packet Too Big" message to the source with a value
= of S, where S is (L - H).
=
When the = outer-header encapsulation uses an IPv4 header, an When the outer-header encapsulation uses an IPv4 = header, an
implementation = SHOULD set the DF bit to 1 so ETR fragment reassembly implementation SHOULD set the DF bit to 1 so ETR = fragment reassembly
can be = avoided. An implementation MAY set the DF bit in such headers = can be avoided. An implementation MAY set = the DF bit in such headers
to 0 if it has = good reason to believe there are unresolvable path MTU to 0 if it has good reason to believe there are = unresolvable path MTU
issues between = the sending ITR and the receiving ETR. = issues between the sending ITR and the receiving ETR.
=
This = specification RECOMMENDS that L be defined as 1500. This specification RECOMMENDS that L be defined as = 1500.
=
7.2. A Stateful = Solution to MTU Handling 7.2. A = Stateful Solution to MTU Handling
=
skipping to = change at = page 24, line 14 =C2=B6 = skipping to change at page 24, line = 19 =C2=B6
splitting = across its members. The client-side can use RLOCs splitting across its members. The client-side can = use RLOCs
outside of = the subset list if it determines that the subset list outside of the subset list if it determines that = the subset list
is = unreachable (unless RLOCs are set to a Priority of 255). Some = is unreachable (unless RLOCs are set to a = Priority of 255). Some
sharing of = control exists: the server-side determines the sharing of control exists: the server-side = determines the
destination = RLOC list and load distribution while the client-side destination RLOC list and load distribution while = the client-side
has the = option of using alternatives to this list if RLOCs in the = has the option of using alternatives to = this list if RLOCs in the
list are = unreachable. list are = unreachable.
=
o The = server-side sets a Weight of zero for the RLOC subset list. = o The server-side sets a Weight of zero for = the RLOC subset list.
In this = case, the client-side can choose how the traffic load is = In this case, the client-side can choose = how the traffic load is
spread = across the subset list. Control is shared by the server- = spread across the subset list. See Section 12 = for details on
side determining the list and the = client-side determining load load-sharing mechanisms. Control is = shared by the server-side
= determining the list and the client-side = determining load
= distribution. Again, the client can use alternative RLOCs if = the distribution. Again, the = client can use alternative RLOCs if the
= server-provided list of RLOCs is unreachable. server-provided list of RLOCs is = unreachable.
=
o Either side = (more likely the server-side ETR) decides not to send o Either side (more likely the server-side ETR) = decides not to send
a = Map-Request. For example, if the server-side ETR does not send = a Map-Request. For example, if the = server-side ETR does not send
= Map-Requests, it gleans RLOCs from the client-side ITR, giving = the Map-Requests, it gleans = RLOCs from the client-side ITR, giving the
client-side = ITR responsibility for bidirectional RLOC reachability client-side ITR responsibility for bidirectional = RLOC reachability
and = preferability. Server-side ETR gleaning of the client-side = and preferability. Server-side ETR = gleaning of the client-side
ITR RLOC is = done by caching the inner-header source EID and the ITR RLOC is done by caching the inner-header = source EID and the
= outer-header source RLOC of received packets. The client-side = ITR outer-header source RLOC of = received packets. The client-side ITR
=
skipping to = change at = page 27, line 44 =C2=B6 = skipping to change at page 27, line = 49 =C2=B6
unidirectional = so there is no ITR returning traffic. = unidirectional so there is no ITR returning traffic.
=
The echo-nonce = algorithm is bilateral. That is, if one side sets the The echo-nonce algorithm is bilateral. That is, if = one side sets the
E-bit and the = other side is not enabled for echo-noncing, then the E-bit and the other side is not enabled for = echo-noncing, then the
echoing of the = nonce does not occur and the requesting side may echoing of the nonce does not occur and the = requesting side may
erroneously = consider the Locator unreachable. An ITR SHOULD only set = erroneously consider the Locator = unreachable. An ITR SHOULD only set
the E-bit in = an encapsulated data packet when it knows the ETR is the E-bit in an encapsulated data packet when it = knows the ETR is
enabled for = echo-noncing. This is conveyed by the E-bit in the RLOC- = enabled for echo-noncing. This is conveyed = by the E-bit in the RLOC-
probe = Map-Reply message. probe Map-Reply = message.
=
= Many implementations = default to not advertising they are echo-nonce
= capable in Map-Reply = messages and so RLOC-probing tends to be used
= for RLOC = reachability.
= =
11. EID = Reachability within a LISP Site 11. = EID Reachability within a LISP Site
=
A site MAY be = multihomed using two or more ETRs. The hosts and A site MAY be multihomed using two or more ETRs. The = hosts and
infrastructure = within a site will be addressed using one or more EID- infrastructure within a site will be addressed using = one or more EID-
Prefixes that = are mapped to the RLOCs of the relevant ETRs in the Prefixes that are mapped to the RLOCs of the relevant = ETRs in the
mapping = system. One possible failure mode is for an ETR to lose = mapping system. One possible failure mode = is for an ETR to lose
reachability = to one or more of the EID-Prefixes within its own site. = reachability to one or more of the = EID-Prefixes within its own site.
When this = occurs when the ETR sends Map-Replies, it can clear the = When this occurs when the ETR sends = Map-Replies, it can clear the
R-bit = associated with its own Locator. And when the ETR is also an = R-bit associated with its own Locator. And = when the ETR is also an
ITR, it can = clear its Locator-Status-Bit in the encapsulation data ITR, it can clear its Locator-Status-Bit in the = encapsulation data
=
skipping to = change at = page 33, line 5 =C2=B6 = skipping to change at page 33, line = 13 =C2=B6
overloading = it. overloading it.
=
The LISP = Data-Plane defines several mechanisms to monitor RLOC Data- = The LISP Data-Plane defines several = mechanisms to monitor RLOC Data-
Plane = reachability, in this context Locator-Status Bits, Nonce- = Plane reachability, in this context = Locator-Status Bits, Nonce-
Present and = Echo-Nonce bits of the LISP encapsulation header can be = Present and Echo-Nonce bits of the LISP = encapsulation header can be
manipulated by = an attacker to mount a DoS attack. An off-path manipulated by an attacker to mount a DoS attack. An = off-path
attacker able = to spoof the RLOC and/or nonce of a victim's xTR can attacker able to spoof the RLOC and/or nonce of a = victim's xTR can
manipulate = such mechanisms to declare false information about the manipulate such mechanisms to declare false = information about the
RLOC's = reachability status. RLOC's = reachability status.
=
As an exmple of such attacks an off-path = attacker can exploit the For example of such attacks, an off-path = attacker can exploit the
echo-nonce = mechanism by sending data packets to an ITR with a random = echo-nonce mechanism by sending data packets = to an ITR with a random
nonce from an = ETR's spoofed RLOC. Note the attacker must guess a nonce from an ETR's spoofed RLOC. Note the attacker = must guess a
valid nonce = the ITR is requesting to be echoed within a small window = valid nonce the ITR is requesting to be = echoed within a small window
of time. The = goal is to convince the ITR that the ETR's RLOC is of time. The goal is to convince the ITR that the = ETR's RLOC is
reachable even = when it may not be reachable. If the attack is reachable even when it may not be reachable. If the = attack is
successful, = the ITR believes the wrong reachability status of the successful, the ITR believes the wrong reachability = status of the
ETR's RLOC = until RLOC-probing detects the correct status. This time = ETR's RLOC until RLOC-probing detects the = correct status. This time
frame is on = the order of 10s of seconds. This specific attack can be = frame is on the order of 10s of seconds. = This specific attack can be
mitigated by = preventing RLOC spoofing in the network by deploying mitigated by preventing RLOC spoofing in the network = by deploying
uRPF BCP 38 = [RFC2827]. In addition and in order to exploit this uRPF BCP 38 [RFC2827]. In addition and in order to = exploit this
vulnerability, = the off-path attacker must send echo-nonce packets at vulnerability, the off-path attacker must send = echo-nonce packets at
high rate. If = the nonces have never been requested by the ITR, it high rate. If the nonces have never been requested = by the ITR, it
can protect = itself from erroneious reachability = attacks. can protect itself from = erroneous reachability attacks.
=
Map-Versioning = is a Data-Plane mechanism used to signal a peering xTR Map-Versioning is a Data-Plane mechanism used to = signal a peering xTR
that a local = EID-to-RLOC mapping has been updated, so that the that a local EID-to-RLOC mapping has been updated, so = that the
peering xTR = uses LISP Control-Plane signaling message to retrieve a = peering xTR uses LISP Control-Plane = signaling message to retrieve a
fresh mapping. = This can be used by an attacker to forge the map- fresh mapping. This can be used by an attacker to = forge the map-
versioning = field of a LISP encapsulated header and force an excessive = versioning field of a LISP encapsulated = header and force an excessive
amount of = signaling between xTRs that may overload them. amount of signaling between xTRs that may overload = them.
=
Most of the = attack vectors can be mitigated with careful deployment = Most of the attack vectors can be mitigated = with careful deployment
and = configuration, information learned opportunistically (such as = LSB and configuration, information = learned opportunistically (such as LSB
=
skipping to = change at = page 34, line 44 =C2=B6 = skipping to change at page 35, line 8 =C2=B6
20.1. Normative = References 20.1. Normative = References
=
= [I-D.ietf-lisp-6834bis] = [I-D.ietf-lisp-6834bis]
= Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID = Iannone, L., Saucez, D., and O. = Bonaventure, "Locator/ID
= Separation Protocol (LISP) Map-Versioning", draft-ietf- = Separation Protocol (LISP) = Map-Versioning", draft-ietf-
= lisp-6834bis-02 (work in progress), September 2018. lisp-6834bis-02 (work in progress), = September 2018.
=
= [I-D.ietf-lisp-rfc6833bis] = [I-D.ietf-lisp-rfc6833bis]
= Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, Fuller, V., Farinacci, D., and A. = Cabellos-Aparicio,
= "Locator/ID Separation Protocol (LISP) Control-Plane", "Locator/ID Separation Protocol (LISP) = Control-Plane",
= draft-ietf-lisp-rfc6833bis-19 (work in = progress), October draft-ietf-lisp-rfc6833bis-24 (work in = progress), February
2018. = 2019.
=
[RFC0768] = Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD = 6, RFC 768,
DOI = 10.17487/RFC0768, August 1980, = DOI 10.17487/RFC0768, August 1980,
= <https://www.rfc-editor.org/info/rfc768>. = <https://www.rfc-editor.org/info/rfc768>.
=
[RFC0791] = Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, = RFC 791,
DOI = 10.17487/RFC0791, September 1981, = DOI 10.17487/RFC0791, September 1981,
= <https://www.rfc-editor.org/info/rfc791>. = <https://www.rfc-editor.org/info/rfc791>.
=
[RFC2119] = Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to = Indicate
=
skipping = to change at page 36, line = 13 =C2=B6 = skipping to change at page 36, line = 22 =C2=B6
= <http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>. = = <http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>.
=
= [I-D.ietf-lisp-introduction] = [I-D.ietf-lisp-introduction]
= Cabellos-Aparicio, A. and D. Saucez, "An Architectural Cabellos-Aparicio, A. and D. Saucez, "An = Architectural
= Introduction to the Locator/ID Separation Protocol Introduction to the Locator/ID Separation = Protocol
= (LISP)", draft-ietf-lisp-introduction-13 (work in (LISP)", draft-ietf-lisp-introduction-13 = (work in
= progress), April 2015. = progress), April 2015.
=
= [I-D.ietf-lisp-vpn] = [I-D.ietf-lisp-vpn]
= Moreno, V. and D. Farinacci, "LISP Virtual Private Moreno, V. and D. Farinacci, "LISP Virtual = Private
= Networks (VPNs)", draft-ietf-lisp-vpn-02 = (work in Networks = (VPNs)", draft-ietf-lisp-vpn-03 (work = in
= progress), May 2018. progress), November 2018.
=
= [OPENLISP] [OPENLISP]
= Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP Iannone, L., Saucez, D., and O. = Bonaventure, "OpenLISP
= Implementation Report", Work in Progress, July 2008. Implementation Report", Work in Progress, = July 2008.
=
[RFC1034] = Mockapetris, P., "Domain names - concepts and facilities", = [RFC1034] Mockapetris, P., "Domain names - = concepts and facilities",
STD = 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, = November 1987,
= <https://www.rfc-editor.org/info/rfc1034>. = <https://www.rfc-editor.org/info/rfc1034>.
=
[RFC1918] = Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., = [RFC1918] Rekhter, Y., Moskowitz, B., = Karrenberg, D., de Groot, G.,
=
skipping = to change at page 40, line = 12 =C2=B6 = skipping to change at page 40, line = 12 =C2=B6
Kaduk, Eric = Rescorla, Alvaro Retana, Alexey Melnikov, Alissa Cooper, = Kaduk, Eric Rescorla, Alvaro Retana, Alexey = Melnikov, Alissa Cooper,
Suresh = Krishnan, Alberto Rodriguez-Natal, Vina Ermagen, Mohamed = Suresh Krishnan, Alberto Rodriguez-Natal, = Vina Ermagen, Mohamed
Boucadair, = Brian Trammell, Sabrina Tanamal, and John Drake. The Boucadair, Brian Trammell, Sabrina Tanamal, and John = Drake. The
contributions = they offered greatly added to the security, scale, and contributions they offered greatly added to the = security, scale, and
robustness of = the LISP architecture and protocols. = robustness of the LISP architecture and protocols.
=
Appendix B. = Document Change Log Appendix B. = Document Change Log
=
[RFC Editor: = Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on = publication as RFC.]
=
B.1. Changes = to draft-ietf-lisp-rfc6830bis-26 B.1. = Changes to draft-ietf-lisp-rfc6830bis-27
=
= o Posted February = 2019 just before Thu telechat.
=
= o Made editorial = corrections per Warren's suggestions.
=
= B.2. Changes to = draft-ietf-lisp-rfc6830bis-26
=
o Posted late = October 2018. o Posted late = October 2018.
=
o Changed = description about "reserved" bits to state "reserved and = o Changed description about "reserved" bits = to state "reserved and
= unassigned". = unassigned".
=
B.2. Changes to = draft-ietf-lisp-rfc6830bis-25 B.3. Changes to = draft-ietf-lisp-rfc6830bis-25
=
o Posted mid = October 2018. o Posted mid October = 2018.
=
o Added more = to the Security Considerations section with discussion o Added more to the Security Considerations section = with discussion
about = echo-nonce attacks. about = echo-nonce attacks.
=
B.3. Changes to = draft-ietf-lisp-rfc6830bis-24 B.4. Changes to = draft-ietf-lisp-rfc6830bis-24
=
o Posted mid = October 2018. o Posted mid October = 2018.
=
o Final = editorial changes for Eric and Ben. = o Final editorial changes for Eric and Ben.
=
B.4. Changes to = draft-ietf-lisp-rfc6830bis-23 B.5. Changes to = draft-ietf-lisp-rfc6830bis-23
=
o Posted = early October 2018. o Posted early = October 2018.
=
o Added an = applicability statement in section 1 to address security = o Added an applicability statement in = section 1 to address security
concerns = from Telechat. concerns from = Telechat.
=
B.5. Changes to = draft-ietf-lisp-rfc6830bis-22 B.6. Changes to = draft-ietf-lisp-rfc6830bis-22
=
o Posted = early October 2018. o Posted early = October 2018.
=
o Changes to = reflect comments post Telechat. o = Changes to reflect comments post Telechat.
=
B.6. Changes to = draft-ietf-lisp-rfc6830bis-21 B.7. Changes to = draft-ietf-lisp-rfc6830bis-21
=
o Posted = late-September 2018. o Posted = late-September 2018.
=
o Changes to = reflect comments from Sep 27th Telechat. o Changes to reflect comments from Sep 27th = Telechat.
=
B.7. Changes to = draft-ietf-lisp-rfc6830bis-20 B.8. Changes to = draft-ietf-lisp-rfc6830bis-20
=
o Posted = late-September 2018. o Posted = late-September 2018.
=
o Fix old = reference to RFC3168, changed to RFC6040. o Fix old reference to RFC3168, changed to = RFC6040.
=
B.8. Changes to = draft-ietf-lisp-rfc6830bis-19 B.9. Changes to = draft-ietf-lisp-rfc6830bis-19
=
o Posted = late-September 2018. o Posted = late-September 2018.
=
o More = editorial changes. o More = editorial changes.
=
B.9. Changes to = draft-ietf-lisp-rfc6830bis-18 B.10. Changes to = draft-ietf-lisp-rfc6830bis-18
=
o Posted = mid-September 2018. o Posted = mid-September 2018.
=
o Changes to = reflect comments from Secdir review (Mirja). o Changes to reflect comments from Secdir review = (Mirja).
=
B.10. Changes to = draft-ietf-lisp-rfc6830bis-17 B.11. Changes to = draft-ietf-lisp-rfc6830bis-17
=
o Posted = September 2018. o Posted September = 2018.
=
o Indicate in = the "Changes since RFC 6830" section why the document o Indicate in the "Changes since RFC 6830" section = why the document
has been = shortened in length. has been = shortened in length.
=
o Make = reference to RFC 8085 about UDP congestion control. o Make reference to RFC 8085 about UDP congestion = control.
=
o More = editorial changes from multiple IESG reviews. o More editorial changes from multiple IESG = reviews.
=
B.11. Changes to = draft-ietf-lisp-rfc6830bis-16 B.12. Changes to = draft-ietf-lisp-rfc6830bis-16
=
o Posted late = August 2018. o Posted late August = 2018.
=
o Distinguish = the message type names between ICMP for IPv4 and ICMP o Distinguish the message type names between ICMP = for IPv4 and ICMP
for IPv6 = for handling MTU issues. for = IPv6 for handling MTU issues.
=
B.12. Changes to = draft-ietf-lisp-rfc6830bis-15 B.13. Changes to = draft-ietf-lisp-rfc6830bis-15
=
o Posted = August 2018. o Posted August = 2018.
=
o Final = editorial changes before RFC submission for Proposed o Final editorial changes before RFC submission for = Proposed
= Standard. Standard.
=
o Added = section "Changes since RFC 6830" so implementers are o Added section "Changes since RFC 6830" so = implementers are
informed of = any changes since the last RFC publication. informed of any changes since the last RFC = publication.
=
B.13. Changes to = draft-ietf-lisp-rfc6830bis-14 B.14. Changes to = draft-ietf-lisp-rfc6830bis-14
=
o Posted July = 2018 IETF week. o Posted July 2018 = IETF week.
=
o Put = obsolete of RFC 6830 in Intro section in addition to abstract. = o Put obsolete of RFC 6830 in Intro section = in addition to abstract.
=
B.14. Changes to = draft-ietf-lisp-rfc6830bis-13 B.15. Changes to = draft-ietf-lisp-rfc6830bis-13
=
o Posted = March IETF Week 2018. o Posted = March IETF Week 2018.
=
o Clarified = that a new nonce is required per RLOC. = o Clarified that a new nonce is required per RLOC.
=
o Removed = 'Clock Sweep' section. This text must be placed in a new = o Removed 'Clock Sweep' section. This text = must be placed in a new
OAM = document. OAM document.
=
o Some = references changed from normative to informative o Some references changed from normative to = informative
=
B.15. Changes to = draft-ietf-lisp-rfc6830bis-12 B.16. Changes to = draft-ietf-lisp-rfc6830bis-12
=
o Posted July = 2018. o Posted July 2018.
=
o Fixed Luigi = editorial comments to ready draft for RFC status. o Fixed Luigi editorial comments to ready draft for = RFC status.
=
B.16. Changes to = draft-ietf-lisp-rfc6830bis-11 B.17. Changes to = draft-ietf-lisp-rfc6830bis-11
=
o Posted = March 2018. o Posted March = 2018.
=
o Removed = sections 16, 17 and 18 (Mobility, Deployment and o Removed sections 16, 17 and 18 (Mobility, = Deployment and
Traceroute = considerations). This text must be placed in a new OAM = Traceroute considerations). This text = must be placed in a new OAM
= document. document.
=
B.17. Changes to = draft-ietf-lisp-rfc6830bis-10 B.18. Changes to = draft-ietf-lisp-rfc6830bis-10
=
o Posted = March 2018. o Posted March = 2018.
=
o Updated = section 'Router Locator Selection' stating that the Data- = o Updated section 'Router Locator = Selection' stating that the Data-
Plane MUST = follow what's stored in the Map-Cache (priorities and Plane MUST follow what's stored in the Map-Cache = (priorities and
= weights). weights).
=
o Section = 'Routing Locator Reachability': Removed bullet point 2 o Section 'Routing Locator Reachability': Removed = bullet point 2
(ICMP = Network/Host Unreachable),3 (hints from BGP),4 (ICMP Port = (ICMP Network/Host Unreachable),3 (hints = from BGP),4 (ICMP Port
= Unreachable),5 (receive a Map-Reply as a response) and RLOC = Unreachable),5 (receive a Map-Reply as a = response) and RLOC
= probing probing
=
o Removed = 'Solicit-Map Request'. o Removed = 'Solicit-Map Request'.
=
B.18. Changes to = draft-ietf-lisp-rfc6830bis-09 B.19. Changes to = draft-ietf-lisp-rfc6830bis-09
=
o Posted = January 2018. o Posted January = 2018.
=
o Add more = details in section 5.3 about DSCP processing during o Add more details in section 5.3 about DSCP = processing during
= encapsulation and decapsulation. = encapsulation and decapsulation.
=
o Added = clarity to definitions in the Definition of Terms section = o Added clarity to definitions in the = Definition of Terms section
from = various commenters. from various = commenters.
=
o Removed PA = and PI definitions from Definition of Terms section. o Removed PA and PI definitions from Definition of = Terms section.
=
o More = editorial changes. o More = editorial changes.
=
o Removed = 4342 from IANA section and move to RFC6833 IANA section. = o Removed 4342 from IANA section and move = to RFC6833 IANA section.
=
B.19. Changes to = draft-ietf-lisp-rfc6830bis-08 B.20. Changes to = draft-ietf-lisp-rfc6830bis-08
=
o Posted = January 2018. o Posted January = 2018.
=
o Remove = references to research work for any protocol mechanisms. = o Remove references to research work for = any protocol mechanisms.
=
o Document = scanned to make sure it is RFC 2119 compliant. o Document scanned to make sure it is RFC 2119 = compliant.
=
o Made = changes to reflect comments from document WG shepherd Luigi = o Made changes to reflect comments from = document WG shepherd Luigi
= Iannone. Iannone.
=
o Ran IDNITs = on the document. o Ran IDNITs on = the document.
=
B.20. Changes to = draft-ietf-lisp-rfc6830bis-07 B.21. Changes to = draft-ietf-lisp-rfc6830bis-07
=
o Posted = November 2017. o Posted November = 2017.
=
o Rephrase = how Instance-IDs are used and don't refer to [RFC1918] o Rephrase how Instance-IDs are used and don't refer = to [RFC1918]
= addresses. addresses.
=
B.21. Changes to = draft-ietf-lisp-rfc6830bis-06 B.22. Changes to = draft-ietf-lisp-rfc6830bis-06
=
o Posted = October 2017. o Posted October = 2017.
=
o Put RTR = definition before it is used. o = Put RTR definition before it is used.
=
o Rename = references that are now working group drafts. o Rename references that are now working group = drafts.
=
o Remove = "EIDs MUST NOT be used as used by a host to refer to other = o Remove "EIDs MUST NOT be used as used by = a host to refer to other
hosts. = Note that EID blocks MAY LISP RLOCs". = hosts. Note that EID blocks MAY LISP RLOCs".
=
=
skipping = to change at page 44, line = 15 =C2=B6 = skipping to change at page 44, line = 15 =C2=B6
o ETRs may, = rather than will, be the ones to send Map-Replies. o ETRs may, rather than will, be the ones to send = Map-Replies.
=
o Recommend, = rather than mandate, max encapsulation headers to 2. o Recommend, rather than mandate, max encapsulation = headers to 2.
=
o Reference = VPN draft when introducing Instance-ID. = o Reference VPN draft when introducing Instance-ID.
=
o Indicate = that SMRs can be sent when ITR/ETR are in the same node. = o Indicate that SMRs can be sent when = ITR/ETR are in the same node.
=
o Clarify = when private addresses can be used. = o Clarify when private addresses can be used.
=
B.22. Changes to = draft-ietf-lisp-rfc6830bis-05 B.23. Changes to = draft-ietf-lisp-rfc6830bis-05
=
o Posted = August 2017. o Posted August = 2017.
=
o Make it = clear that a Re-encapsulating Tunnel Router is an RTR. o Make it clear that a Re-encapsulating Tunnel = Router is an RTR.
=
B.23. Changes to = draft-ietf-lisp-rfc6830bis-04 B.24. Changes to = draft-ietf-lisp-rfc6830bis-04
=
o Posted July = 2017. o Posted July 2017.
=
o Changed = reference of IPv6 RFC2460 to RFC8200. = o Changed reference of IPv6 RFC2460 to RFC8200.
=
o Indicate = that the applicability statement for UDP zero checksums = o Indicate that the applicability statement = for UDP zero checksums
over IPv6 = adheres to RFC6936. over IPv6 = adheres to RFC6936.
=
B.24. Changes to = draft-ietf-lisp-rfc6830bis-03 B.25. Changes to = draft-ietf-lisp-rfc6830bis-03
=
o Posted May = 2017. o Posted May 2017.
=
o Move the = control-plane related codepoints in the IANA o Move the control-plane related codepoints in the = IANA
= Considerations section to RFC6833bis. = Considerations section to RFC6833bis.
=
B.25. Changes to = draft-ietf-lisp-rfc6830bis-02 B.26. Changes to = draft-ietf-lisp-rfc6830bis-02
=
o Posted = April 2017. o Posted April = 2017.
=
o Reflect = some editorial comments from Damien Sausez. o Reflect some editorial comments from Damien = Sausez.
=
B.26. Changes to = draft-ietf-lisp-rfc6830bis-01 B.27. Changes to = draft-ietf-lisp-rfc6830bis-01
=
o Posted = March 2017. o Posted March = 2017.
=
o Include = references to new RFCs published. o = Include references to new RFCs published.
=
o Change = references from RFC6833 to RFC6833bis. = o Change references from RFC6833 to RFC6833bis.
=
o Clarified = LCAF text in the IANA section. o = Clarified LCAF text in the IANA section.
=
o Remove = references to "experimental". o = Remove references to "experimental".
=
B.27. Changes to = draft-ietf-lisp-rfc6830bis-00 B.28. Changes to = draft-ietf-lisp-rfc6830bis-00
=
o Posted = December 2016. o Posted December = 2016.
=
o Created = working group document from draft-farinacci-lisp o Created working group document from = draft-farinacci-lisp
-rfc6830-00 = individual submission. No other changes made. -rfc6830-00 individual submission. No other = changes made.
=
Authors' = Addresses Authors' Addresses
=
Dino = Farinacci Dino Farinacci
Cisco = Systems Cisco Systems
 End of changes. 44 change blocks. 
74 lines changed or = deleted 87 lines changed or = added

This = html diff was produced by rfcdiff 1.47. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20 = --Apple-Mail=_9A64C7D3-A0AC-4D20-B973-F8E9FC083567 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_9A64C7D3-A0AC-4D20-B973-F8E9FC083567-- From nobody Wed Feb 6 18:12:04 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E659D130FB8 for ; Wed, 6 Feb 2019 18:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 CyvzDfCXhgfX for ; Wed, 6 Feb 2019 18:12:01 -0800 (PST) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 268DB130FB4 for ; Wed, 6 Feb 2019 18:12:01 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id l142so7003270lfe.2 for ; Wed, 06 Feb 2019 18:12:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=S1QrGOgrxTM+2JjvHPt5THlnHzuLfwXRH3mtzXUQ/D0=; b=GlZnQN7uqcFXojgLYPBDhOFr7kOfCb2IkIRChDIYUr2+2DeJaLSsFHqHVIdFL1poOT wWaC6aUTJBPVEpBckhAMDXIy58XIwD37renBSRoS/mNp5EjKCJveiRsGlz4RFVuSM3u/ A8+b2fG9UdvLq+qOzi0B0N5NqQqie/sx7pg7IIzGyTn55kBY1E6L9YEFmbCmRUM5t3Jp xNlUaFtmQVWpFxOE84EnQpqe9+as787WSvLijaB+GTY8WbI8RfiYXPSdHZbATmHTcbhQ Q/gPvjVeZvuWtjefcTSvHZpf1SydVAdLrJSrgF0t1q/2xnuAe2mm2P0yRtIwDr9F+7ve Z+aA== 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; bh=S1QrGOgrxTM+2JjvHPt5THlnHzuLfwXRH3mtzXUQ/D0=; b=Ujz4ojzgMnpv/xxLVEQ6j9SfLoNXJYkavHU+GGMjTtRLynFhp7rNOMo4kJm/4SUsMy KqGRYPPBol13OKEognVEEBvKHqGh28ZXkC+/BA0nlBeXLBp3i8n+MYAREDasJ/3CL5MP KGtTMHbaKSEYKSyvcGB+meLlBnX2k78yZXRbigX3jDTpuOZnYs4/++2jRplmPNqoMA0o JQbaHfvWfbt0c3GS7alkKKAbUDzIXodiV3uvR1jYoVqO6guvJp/1udr6mhALvu7iHumR 1rVL3CDG5hqKIk5VVF6uU3Kqdq1cnzU1o8f6/13HdJaF/5ElJXbT9MzAJBV6TjepqkwS 92JA== X-Gm-Message-State: AHQUAubOUntQhD3bAa0pPNFOH42Kx3xj9xtYZyqsdAZqFecBSomTW90j 6wTV+IeBkKvbk8Ryrrw2nm8vA1VJwX7MuIyf8730yA== X-Google-Smtp-Source: AHgI3IZacwX1UqmYgl7rtqnWVSPKSqWzY0aTpnXyjuW3LUqHf1y2HFbX2UTiGz++nrNgX57UV9emal7YSNsGCN9S+5U= X-Received: by 2002:a19:1d87:: with SMTP id d129mr7614592lfd.106.1549505519204; Wed, 06 Feb 2019 18:11:59 -0800 (PST) MIME-Version: 1.0 From: Eric Rescorla Date: Wed, 6 Feb 2019 18:11:19 -0800 Message-ID: To: IESG , draft-ietf-lisp-rfc6833bis@ietf.org, "lisp@ietf.org list" Content-Type: multipart/alternative; boundary="0000000000000ccf6a0581445e0e" Archived-At: Subject: [lisp] Constructing Map-Replies with overlapping prefixes X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 02:12:03 -0000 --0000000000000ccf6a0581445e0e Content-Type: text/plain; charset="UTF-8" I'm trying to piece together the algorithm in 6833-bis S 5.5 for Map-Replies. The text says: A Map-Reply returns an EID-Prefix with a mask-length that is less than or equal to the EID being requested. So, consider the case where an MS has two mappings: 10/8 -> ETR1 11/8 -> ETR2 If the Map-Request is for 10.0.0.1, then I would return 10/8 -> ETR1 Now consider what happens when I have three mappings: 10/16 -> ETR1 10.0.2/24 -> ETR3 // New 11/16 -> ETR2 Now we turn to the remainder of this section: When an EID moves out of a LISP site [I-D.ietf-lisp-eid-mobility], the database mapping system may have overlapping EID-prefixes. Or when a LISP site is configured with multiple sets of ETRs that support different EID-prefix mask-lengths, the database mapping system may have overlapping EID-prefixes. When overlapping EID- prefixes exist, a Map-Request with an EID that best matches any EID- Prefix MUST be returned in a single Map-Reply message. For instance, if an ETR had database mapping entries for EID-Prefixes: I'm having trouble parsing this, but what I get out of the example is that the Map-Response is supposed to contain the EID-prefix that best matches the request, plus whatever exceptions would be required to create a correct routing table. So, that would mean in the case where the Map-Request contains 10.0.0.1, the MS would have to reply with: 10/16 -> ETR1 10.0.2/24 -> ETR3 // New The first of these is necessary to provide correct routing information for the requested prefix and the second to avoid providing incorrect routing information for 10.0.2.1. Do I have this correct? It seems like the alternative is that the MS or ETR synthesize a new, more specific prefix. Is that what's intended instead? The example in S 5.5 suggests otehrwise, but perhaps I am misunderstanding. Thanks, -Ekr --0000000000000ccf6a0581445e0e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm trying to piece together the algo= rithm in 6833-bis S 5.5
for Map-Replies. The text says:

=C2=A0=C2= =A0 A Map-Reply returns an EID-Prefix with a mask-length that is less
= =C2=A0=C2=A0 than or equal to the EID being requested.

So, consider = the case where an MS has two mappings:

=C2=A0=C2=A0 10/8 -> ETR1<= br>=C2=A0=C2=A0 11/8 -> ETR2

If the Map-Request is for 10.0.0.1, = then I would return

=C2=A0=C2=A0 10/8 -> ETR1

Now consider= what happens when I have three mappings:

=C2=A0=C2=A0 10/16=C2=A0= =C2=A0 -> ETR1
=C2=A0=C2=A0 10.0.2/24 -> ETR3 // New
=C2=A0=C2= =A0 11/16=C2=A0=C2=A0 -> ETR2

Now we turn to the remainder of thi= s section:

=C2=A0=C2=A0 When an EID moves out of a LISP site [I-D.ie= tf-lisp-eid-mobility],
=C2=A0=C2=A0 the database mapping system may have= overlapping EID-prefixes.=C2=A0 Or
=C2=A0=C2=A0 when a LISP site is con= figured with multiple sets of ETRs that
=C2=A0=C2=A0 support different E= ID-prefix mask-lengths, the database mapping
=C2=A0=C2=A0 system may hav= e overlapping EID-prefixes.=C2=A0 When overlapping EID-
=C2=A0=C2=A0 pre= fixes exist, a Map-Request with an EID that best matches any EID-
=C2=A0= =C2=A0 Prefix MUST be returned in a single Map-Reply message.=C2=A0 For ins= tance,
=C2=A0=C2=A0 if an ETR had database mapping entries for EID-Prefi= xes:

I'm having trouble parsing this, but what I get out of the = example
is that the Map-Response is supposed to contain the EID-prefix t= hat
best matches the request, plus whatever exceptions would be required=
to create a correct routing table. So, that would mean in the case
w= here the Map-Request contains 10.0.0.1, the MS would have to reply
with:=

=C2=A0=C2=A0 10/16=C2=A0=C2=A0 -> ETR1
=C2=A0=C2=A0 10.0.2/24= -> ETR3 // New

The first of these is necessary to provide correc= t routing information
for the requested prefix and the second to avoid p= roviding incorrect
routing information for 10.0.2.1.

Do I have th= is correct? It seems like the alternative is that the MS
or ETR synthesi= ze a new, more specific prefix. Is that what's intended
instead? The= example in S 5.5 suggests otehrwise, but perhaps I am
misunderstanding.=

Thanks,
-Ekr

=










--0000000000000ccf6a0581445e0e-- From nobody Wed Feb 6 18:22:59 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629E712870E for ; Wed, 6 Feb 2019 18:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 PVzjwtZHcUJD for ; Wed, 6 Feb 2019 18:22:54 -0800 (PST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::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 E53DC130FCF for ; Wed, 6 Feb 2019 18:22:53 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id r10-v6so2218565ljj.4 for ; Wed, 06 Feb 2019 18:22:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=SKi9ivjCiKk8Z0TRjGmzzVWvX2Kf4cW4ElI3q80NVkY=; b=xkbSVCLVakTaBFM0FxdSR+nzNrK3GMeUI7zyJK4x1Hc+Mkr/xa6bXLl7O9LoKX56Cz BERlD1MazcO09rrOv0679xG90EFmTBbavBfeY7rule4k0f4EPgqad/QxuQ9/v/33NyWr HbKZd4+ZnQLIYnjCp35QqZbdwrOXyYU6Es91m9x8vjHiUIbUHcwi5b8Agqrq6P0uavF9 drzJSHno2gSLoonDwc4s/rQ85NIudTuFwSpHBf6XFMa/uQtwHFNGJVfBAWqhBEuWw5A/ cJkhdrgETDsAzFedfJsxBb806CjuQNJ8fPfW0Bb4W/X0Ibg+HiRCbESBNV4Rt78YS+OK axcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=SKi9ivjCiKk8Z0TRjGmzzVWvX2Kf4cW4ElI3q80NVkY=; b=Ay0ImOMuhpwgebSHdxWzXQDtKEx9uVzeJHZA3JA6qTLc4trjiCb0syzt1T6ePUquJ0 5rf759BKrhhIvqOHbAK/RihYCyk+VIZa0d/Hay14qegE94aqYLWHY7IMbPB41RDHjSBM 7XTRovcY+bFWjyZ8Pf1A8+pnDbMcvN+JAdTsET3xdM/QJ84W1sTiz2vlg6+FI/PMF46K fcNcfSFFqpYkKCNTLXn6ZXhkJgAWo+GYyDScXQDlimB/WJGF4g+7giVFNMcEjWNV42Qn /WsdCTZP3ytd+jp3LrXbcBl5CYBJlZylZp/0ijqsyL0HlRY6WLSU0zGSGS58kCR3iXM4 q6Pg== X-Gm-Message-State: AHQUAuaGW3vm+ips+PGzg2ORvSACFuR8nnUtNvDZSUTwviMqAXvJyMMt oZ2MqKjKqn7Op5p2lvfV64lczqyutqThcMz5oWpFug== X-Google-Smtp-Source: AHgI3IY3c1T9E4XgURYjld51Mt3fDG0PymSHsjRpRhFk3xy1goADURg2IH2RVQ3KQlJAfSoTQhGYCU+DNWk/65ttq+Q= X-Received: by 2002:a05:651c:101:: with SMTP id a1mr454016ljb.59.1549506172018; Wed, 06 Feb 2019 18:22:52 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Wed, 6 Feb 2019 18:22:13 -0800 Message-ID: To: IESG , draft-ietf-lisp-rfc6833bis@ietf.org, "lisp@ietf.org list" Content-Type: multipart/alternative; boundary="000000000000f600090581448411" Archived-At: Subject: Re: [lisp] Constructing Map-Replies with overlapping prefixes X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 02:22:57 -0000 --000000000000f600090581448411 Content-Type: text/plain; charset="UTF-8" Another question: What does the Map Server do if it gets a request for a shorter prefix than it has an EID for. E.g., I have a mapping for 10/8 (and nothing else) but I get a request for 10/4. The text in S 5.5 suggests that I return an empty locator set. Is that correct? On Wed, Feb 6, 2019 at 6:11 PM Eric Rescorla wrote: > I'm trying to piece together the algorithm in 6833-bis S 5.5 > for Map-Replies. The text says: > > A Map-Reply returns an EID-Prefix with a mask-length that is less > than or equal to the EID being requested. > > So, consider the case where an MS has two mappings: > > 10/8 -> ETR1 > 11/8 -> ETR2 > > If the Map-Request is for 10.0.0.1, then I would return > > 10/8 -> ETR1 > > Now consider what happens when I have three mappings: > > 10/16 -> ETR1 > 10.0.2/24 -> ETR3 // New > 11/16 -> ETR2 > > Now we turn to the remainder of this section: > > When an EID moves out of a LISP site [I-D.ietf-lisp-eid-mobility], > the database mapping system may have overlapping EID-prefixes. Or > when a LISP site is configured with multiple sets of ETRs that > support different EID-prefix mask-lengths, the database mapping > system may have overlapping EID-prefixes. When overlapping EID- > prefixes exist, a Map-Request with an EID that best matches any EID- > Prefix MUST be returned in a single Map-Reply message. For instance, > if an ETR had database mapping entries for EID-Prefixes: > > I'm having trouble parsing this, but what I get out of the example > is that the Map-Response is supposed to contain the EID-prefix that > best matches the request, plus whatever exceptions would be required > to create a correct routing table. So, that would mean in the case > where the Map-Request contains 10.0.0.1, the MS would have to reply > with: > > 10/16 -> ETR1 > 10.0.2/24 -> ETR3 // New > > The first of these is necessary to provide correct routing information > for the requested prefix and the second to avoid providing incorrect > routing information for 10.0.2.1. > > Do I have this correct? It seems like the alternative is that the MS > or ETR synthesize a new, more specific prefix. Is that what's intended > instead? The example in S 5.5 suggests otehrwise, but perhaps I am > misunderstanding. > > Thanks, > -Ekr > > > > > > > > > > > > --000000000000f600090581448411 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Another question: What does the Map Server do if it g= ets a request for a shorter prefix than it has an EID for. E.g., I have a m= apping for 10/8 (and nothing else) but I get a request for 10/4. The text i= n S 5.5 suggests that I return an empty locator set. Is that correct?

On Wed, Feb 6, 2019 at 6:11 PM Eric Rescorla <ekr@rtfm.com> wrote:
I'm trying to p= iece together the algorithm in 6833-bis S 5.5
for Map-Replies. The text = says:

=C2=A0=C2=A0 A Map-Reply returns an EID-Prefix with a mask-len= gth that is less
=C2=A0=C2=A0 than or equal to the EID being requested.<= br>
So, consider the case where an MS has two mappings:

=C2=A0=C2= =A0 10/8 -> ETR1
=C2=A0=C2=A0 11/8 -> ETR2

If the Map-Reque= st is for 10.0.0.1, then I would return

=C2=A0=C2=A0 10/8 -> ETR1=

Now consider what happens when I have three mappings:

=C2=A0= =C2=A0 10/16=C2=A0=C2=A0 -> ETR1
=C2=A0=C2=A0 10.0.2/24 -> ETR3 //= New
=C2=A0=C2=A0 11/16=C2=A0=C2=A0 -> ETR2

Now we turn to the= remainder of this section:

=C2=A0=C2=A0 When an EID moves out of a = LISP site [I-D.ietf-lisp-eid-mobility],
=C2=A0=C2=A0 the database mappin= g system may have overlapping EID-prefixes.=C2=A0 Or
=C2=A0=C2=A0 when a= LISP site is configured with multiple sets of ETRs that
=C2=A0=C2=A0 su= pport different EID-prefix mask-lengths, the database mapping
=C2=A0=C2= =A0 system may have overlapping EID-prefixes.=C2=A0 When overlapping EID-=C2=A0=C2=A0 prefixes exist, a Map-Request with an EID that best matches = any EID-
=C2=A0=C2=A0 Prefix MUST be returned in a single Map-Reply mess= age.=C2=A0 For instance,
=C2=A0=C2=A0 if an ETR had database mapping ent= ries for EID-Prefixes:

I'm having trouble parsing this, but what= I get out of the example
is that the Map-Response is supposed to contai= n the EID-prefix that
best matches the request, plus whatever exceptions= would be required
to create a correct routing table. So, that would mea= n in the case
where the Map-Request contains 10.0.0.1, the MS would have= to reply
with:

=C2=A0=C2=A0 10/16=C2=A0=C2=A0 -> ETR1
=C2= =A0=C2=A0 10.0.2/24 -> ETR3 // New

The first of these is necessar= y to provide correct routing information
for the requested prefix and th= e second to avoid providing incorrect
routing information for 10.0.2.1.<= br>
Do I have this correct? It seems like the alternative is that the MS=
or ETR synthesize a new, more specific prefix. Is that what's inten= ded
instead? The example in S 5.5 suggests otehrwise, but perhaps I ammisunderstanding.

Thanks,
= -Ekr









<= br>
--000000000000f600090581448411-- From nobody Wed Feb 6 19:06:11 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C2F131001; Wed, 6 Feb 2019 19:06:03 -0800 (PST) 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 RxF1iqwCoCBf; Wed, 6 Feb 2019 19:06:02 -0800 (PST) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 68C70128BCC; Wed, 6 Feb 2019 19:06:02 -0800 (PST) Received: by mail-pg1-x52b.google.com with SMTP id r11so3868965pgp.6; Wed, 06 Feb 2019 19:06:02 -0800 (PST) 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=75l6fRuG+0HNhOYnd6bL1yQ7j7xuVkUVzBoiyBXXa24=; b=O5KtqJX25JGaBk1hpnxWDsZkThz4pqWMUMe0eSt7WojBzgvBvFZbLHHxj4uoL2J655 ZzDhRywyMMvoi2PngUf7YrEkEg4H23q/ty+q8qEi7SVQPuRkF5fierhi7JNL3CSKVUmE 5In/6BPh+Yol4ufjZ/YqwOgqBEaL5at734EV/nOb9yR8GATuZd4tryUxiJCTuVpsfFu2 3KiHDrMybKWoY6UW22y53AsN/BsBW0QX2cMyH5DK7WUdigKXwxNLYK1XWKwqD/bDR+Qg yavk6dhs0WkTXkQhp7wd7GPgJDw88XHGOLv+stGL6l2Qp/USnKLBmRi5vfsZvKsGFeJ/ /F/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:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=75l6fRuG+0HNhOYnd6bL1yQ7j7xuVkUVzBoiyBXXa24=; b=tIA+2KsXqmucb01Bflm3hN4Mr2yS7brCsT2m7iZUCX/5WL8hCDGX/R8Z5EyHI3Ch3g 5CvWrUABYarZ28LiKvtTkoV9g8pqxJYD5zVJ9/jPMCZIPoU1EPZXHeQ43D8v7u0lYCA3 H2lCwJysczCDr8BRBbrJ9sX5pU8yITTIATOfFVSKrldoYbGdZ0f4dQscfzutE85ys+S7 Hy++yQf8KlzwKKXCtcLvb/+ix3wDsYgO5hsyBtwFH8P+NV+236F/28Ag/2G9CwkVVZ9f 4akRYo8UgVdKvxqndNFvxiPgmw3ZnUPemiehj0DiOPPFQHo5I2ZYdiUATO0rtbArc1Gg BS6w== X-Gm-Message-State: AHQUAuY7SMdtm6iS2lxhl6LSZRMP2tirFvx4IF6aLiyNk+ACo3H/jnFX OfoLh0D2sZDOrpk9xAinNdDGvioO X-Google-Smtp-Source: AHgI3Ibghng1PUefOO6O8MHCY2W6rXokRpMK/Iy1xbVjzRZrWuAW+yKufHHF17UmjRrZfqo06MTozw== X-Received: by 2002:a65:4383:: with SMTP id m3mr12098686pgp.96.1549508761617; Wed, 06 Feb 2019 19:06:01 -0800 (PST) Received: from ?IPv6:2601:646:9600:e494:5510:ef8e:ae19:3230? ([2601:646:9600:e494:5510:ef8e:ae19:3230]) by smtp.gmail.com with ESMTPSA id o84sm19037388pfi.172.2019.02.06.19.06.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Feb 2019 19:06:00 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (16D39) In-Reply-To: Date: Wed, 6 Feb 2019 19:05:59 -0800 Cc: IESG , draft-ietf-lisp-rfc6833bis@ietf.org, "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Eric Rescorla Archived-At: Subject: Re: [lisp] Constructing Map-Replies with overlapping prefixes X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 03:06:04 -0000 > So, that would mean in the case > where the Map-Request contains 10.0.0.1, the MS would have to reply > with: >=20 > 10/16 -> ETR1 > 10.0.2/24 -> ETR3 // New 10.0.0.1 is not more specific than 10.0.2.0/24 because 10.0.0.1 & 0xffffff00= =3D 10.0.0.0 which is not equal to 10.0.2.0 & 0xffffff00 =3D 10.0.2.0.=20 So a lookup for 10.0.2.2 would return only the ETR3 entry. And if 10.0.0.1 w= as looked up later than the /16 would be returned.=20 But when 10.0.0.1 is looked up first, than all more specifics of the matchin= g entry, the /16, must be returned. Because you don=E2=80=99t want the cache= to match a coarse entry in the cache when there is a more specific in the m= apping system.=20 > The first of these is necessary to provide correct routing information > for the requested prefix and the second to avoid providing incorrect > routing information for 10.0.2.1. Right.=20 > Do I have this correct? It seems like the alternative is that the MS > or ETR synthesize a new, more specific prefix. Is that what's intended > instead? The example in S 5.5 suggests otehrwise, but perhaps I am > misunderstanding. Well it could return a prefix 10.0.0.1/32 with an RLOC of ETR1 so the entire= s stored in the cache are the ones actually used. But that would cause not M= ap-Request load and more entires in the cache.=20 So one trades off up front all registered entries in the cache versus all po= ssible destination EIDs that matches the coarsest prefix.=20 Dino= From nobody Wed Feb 6 19:08:23 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158F1131006; Wed, 6 Feb 2019 19:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, MIME_QP_LONG_LINE=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 R_1Z8NZJmPc4; Wed, 6 Feb 2019 19:08:19 -0800 (PST) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 33736128BCC; Wed, 6 Feb 2019 19:08:19 -0800 (PST) Received: by mail-pf1-x430.google.com with SMTP id c123so4127298pfb.0; Wed, 06 Feb 2019 19:08:19 -0800 (PST) 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=yHD78xlqPdjet1uTBefj9QM2lEjIxIA6XnD6gMcrApM=; b=OoLBjLQ6hXRbYgTY5sKhNZxs/C8THSI3o20PO9f/ipk3x2uHzehSNDt5HNkfigw5y4 AkMQ+OvnkD4dWeVL4aCg30RqFLFxskITOh9bMSHZJs4w5e1WFyFcU/VGnRJfOB1KGlIJ j9Bn53qnQS5ieAeMyiGjBCGrTIDizSmnDEAp3Jw3Uxb/tUJf40PjnY65ho63wrn/rJX9 HvYqdgonVQ0dCPiXaY0puBd8J3V3xKi2yiVNaDlN/M+eFAruJXz6LtAUDR9iOlpGhRTj enI4UCj56bje/zjRz3Y8pJm5p7+We3rNuY8uabVOkIuCIjVPjTe0w36G+If6Dkjwdh+h D7gA== 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=yHD78xlqPdjet1uTBefj9QM2lEjIxIA6XnD6gMcrApM=; b=LtYsYFNOEO+OA4yG286jna01QzRyh6DjANCyyQawfN5hDlmQN+Sysx5/lnyBP5fX3h qrTY02Wv5yT/AOGNasXSZE8basg8/j2+rckzrhz1xdsscc2IrC4Rn4s+GiiIiwSxh+GN 5lK7ND9fH8MA5a9qAur/faEsyOBgsugT2VyOL8hYXSIO8GfS/IVW34QrpMsl60wzI6Gl C+immVbT3O9qBsbe2iKfHsIk82Fmc/mLQzkPA3Ro9lqB2s7cTdUJAFNorqe3kMvwoeRH YcEXqwxKytaG8zXsjlEpUxaBei1YT3UTB34CQ6DKbgIBgDazffQnombNDyXe0uW9noLj gIDA== X-Gm-Message-State: AHQUAuYDtmXVxCeRgXWG4leaQmuXrWsVOLNcgZQlA9VFfc7G3CG4L20X MBmkwIKk8XmjXpPueGMySmk4Bid0 X-Google-Smtp-Source: AHgI3IbD28XFnMpR/TFXrFJP8mr0nFCD/NVBqUBtnEFXzubCA0F+ol3QMRtGgz6DkA0f5DeZRPhkgQ== X-Received: by 2002:a63:cf02:: with SMTP id j2mr12938571pgg.113.1549508898208; Wed, 06 Feb 2019 19:08:18 -0800 (PST) Received: from ?IPv6:2601:646:9600:e494:5510:ef8e:ae19:3230? ([2601:646:9600:e494:5510:ef8e:ae19:3230]) by smtp.gmail.com with ESMTPSA id o6sm7831553pgp.59.2019.02.06.19.08.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Feb 2019 19:08:17 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-1F0C5D16-7980-4E9D-A215-614CC1A08FA9 Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (16D39) In-Reply-To: Date: Wed, 6 Feb 2019 19:08:17 -0800 Cc: IESG , draft-ietf-lisp-rfc6833bis@ietf.org, "lisp@ietf.org list" Content-Transfer-Encoding: 7bit Message-Id: <61A6EEE3-F667-4B0D-B8AF-62982ED769BF@gmail.com> References: To: Eric Rescorla Archived-At: Subject: Re: [lisp] Constructing Map-Replies with overlapping prefixes X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 03:08:21 -0000 --Apple-Mail-1F0C5D16-7980-4E9D-A215-614CC1A08FA9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Another question: What does the Map Server do if it gets a request for a s= horter prefix than it has an EID for. E.g., I have a Returns an empty RLOC-set with action =E2=80=9Cnative-forward=E2=80=9D with a= n EID-prefix that is equal to the EID-prefix in the Map-Request.=20 > mapping for 10/8 (and nothing else) but I get a request for 10/4. The text= in S 5.5 suggests that I return an empty locator set. Is that correct? Yep.=20 Dino >=20 >> On Wed, Feb 6, 2019 at 6:11 PM Eric Rescorla wrote: >> I'm trying to piece together the algorithm in 6833-bis S 5.5 >> for Map-Replies. The text says: >>=20 >> A Map-Reply returns an EID-Prefix with a mask-length that is less >> than or equal to the EID being requested. >>=20 >> So, consider the case where an MS has two mappings: >>=20 >> 10/8 -> ETR1 >> 11/8 -> ETR2 >>=20 >> If the Map-Request is for 10.0.0.1, then I would return >>=20 >> 10/8 -> ETR1 >>=20 >> Now consider what happens when I have three mappings: >>=20 >> 10/16 -> ETR1 >> 10.0.2/24 -> ETR3 // New >> 11/16 -> ETR2 >>=20 >> Now we turn to the remainder of this section: >>=20 >> When an EID moves out of a LISP site [I-D.ietf-lisp-eid-mobility], >> the database mapping system may have overlapping EID-prefixes. Or >> when a LISP site is configured with multiple sets of ETRs that >> support different EID-prefix mask-lengths, the database mapping >> system may have overlapping EID-prefixes. When overlapping EID- >> prefixes exist, a Map-Request with an EID that best matches any EID- >> Prefix MUST be returned in a single Map-Reply message. For instance, >> if an ETR had database mapping entries for EID-Prefixes: >>=20 >> I'm having trouble parsing this, but what I get out of the example >> is that the Map-Response is supposed to contain the EID-prefix that >> best matches the request, plus whatever exceptions would be required >> to create a correct routing table. So, that would mean in the case >> where the Map-Request contains 10.0.0.1, the MS would have to reply >> with: >>=20 >> 10/16 -> ETR1 >> 10.0.2/24 -> ETR3 // New >>=20 >> The first of these is necessary to provide correct routing information >> for the requested prefix and the second to avoid providing incorrect >> routing information for 10.0.2.1. >>=20 >> Do I have this correct? It seems like the alternative is that the MS >> or ETR synthesize a new, more specific prefix. Is that what's intended >> instead? The example in S 5.5 suggests otehrwise, but perhaps I am >> misunderstanding. >>=20 >> Thanks, >> -Ekr >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 --Apple-Mail-1F0C5D16-7980-4E9D-A215-614CC1A08FA9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Ano= ther question: What does the Map Server do if it gets a request for a shorte= r prefix than it has an EID for. E.g., I have a

R= eturns an empty RLOC-set with action =E2=80=9Cnative-forward=E2=80=9D with a= n EID-prefix that is equal to the EID-prefix in the Map-Request. 
=

mapping for 10/8 (and nothing else) but I get a request= for 10/4. The text in S 5.5 suggests that I return an empty locator set. Is= that correct?
Yep. 
Dino


On Wed, Feb 6, 2019 at 6:11 PM Eric Rescorla <ekr@rtfm.com> wrote:
I'm tr= ying to piece together the algorithm in 6833-bis S 5.5
for Map-Replies. T= he text says:

   A Map-Reply returns an EID-Prefix with a m= ask-length that is less
   than or equal to the EID being reque= sted.

So, consider the case where an MS has two mappings:

&nbs= p;  10/8 -> ETR1
   11/8 -> ETR2

If the Map-R= equest is for 10.0.0.1, then I would return

   10/8 -> E= TR1

Now consider what happens when I have three mappings:

&nbs= p;  10/16   -> ETR1
   10.0.2/24 -> ETR3 /= / New
   11/16   -> ETR2

Now we turn to the= remainder of this section:

   When an EID moves out of a L= ISP site [I-D.ietf-lisp-eid-mobility],
   the database mapping s= ystem may have overlapping EID-prefixes.  Or
   when a LIS= P site is configured with multiple sets of ETRs that
   support= different EID-prefix mask-lengths, the database mapping
   sys= tem may have overlapping EID-prefixes.  When overlapping EID-
 =   prefixes exist, a Map-Request with an EID that best matches any EID-<= br>   Prefix MUST be returned in a single Map-Reply message. = For instance,
   if an ETR had database mapping entries for EI= D-Prefixes:

I'm having trouble parsing this, but what I get out of th= e example
is that the Map-Response is supposed to contain the EID-prefix t= hat
best matches the request, plus whatever exceptions would be required<= br>to create a correct routing table. So, that would mean in the case
whe= re the Map-Request contains 10.0.0.1, the MS would have to reply
with:
   10/16   -> ETR1
   10.0.2/24 -&g= t; ETR3 // New

The first of these is necessary to provide correct rou= ting information
for the requested prefix and the second to avoid providi= ng incorrect
routing information for 10.0.2.1.

Do I have this corr= ect? It seems like the alternative is that the MS
or ETR synthesize a new= , more specific prefix. Is that what's intended
instead? The example in S= 5.5 suggests otehrwise, but perhaps I am
misunderstanding.

Thanks,
-Ekr











= --Apple-Mail-1F0C5D16-7980-4E9D-A215-614CC1A08FA9-- From nobody Wed Feb 6 20:29:49 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A9613106E for ; Wed, 6 Feb 2019 20:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 q1UEROP0f8bY for ; Wed, 6 Feb 2019 20:29:46 -0800 (PST) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 915DE131059 for ; Wed, 6 Feb 2019 20:29:45 -0800 (PST) Received: by mail-lf1-x131.google.com with SMTP id z13so7101559lfe.11 for ; Wed, 06 Feb 2019 20:29:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qt7Qn+kR8CblbIi6f+dvm1nuYX4k9ro2UaALpilDA1E=; b=Vhq+kz5/YxQjx2q8yK39Zgv/uOtI8B/Qd4G7sjdpNNG1foOOhvRAA6fOBtxXKNtz6K W0j17DaOeheEmRVJFYV8sQfWZavizHIXTgUY10ignNUfLz3/CdUGSDZezcuFnQjhrxoM 6Yx/oW2c0CGweeXfzHopvFrgpWZpRllcDz6lFRVkHKTivfbFsFqn97582m213O6QGpyK ePNY+PfZRNbKb09+HySFAnkEsPerk1OpS+f5DPPrFwq2JyFtga6Jm9/L26j9HgZLX0/D UblQKIecGpGZhhCIxYut3XcxlAS8Gp2vIbeg81K9m+Oz+N5i24RLmceJNSvJbJZOChke RUxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Qt7Qn+kR8CblbIi6f+dvm1nuYX4k9ro2UaALpilDA1E=; b=qOKKegQHoFPz+K2D54tlDp6yZnWnjb6TCy7gKFm3rwCn3i+InsYiQT1JAWYP2TU600 OprQNSflB0G8QoaE9dlFZguzIH9VZWWQbEGoqFgBEg8sHiAbMYDFLMejoUbJ51U8jpib lO1Y3vTOZelRtgVIrFsbygaRld96bnCm+0MQO4a0N1TmRkb9ACqej6sJqWlOMj73FtDc dyZMqCLYz8juxdRxHGOFLSe3fmMuBskC+A9k00kofO+fP834pUQo0sXUKio/+iQswLFa W7QWEISEI0wa/R1Lut0T59XeEKkUNe3HzmLiLS0AAvUDUCJCvJblF0UVuYXSgMsatZa0 FzvQ== X-Gm-Message-State: AHQUAua54N2RSBsWqwITiBc/o4ceMAJlqgpzUaRtVtmKxgDYoJP4F3OY tP4M21zuR7b2vB/dXTOkNuPV+ePMvZTYhZRvntWb3w== X-Google-Smtp-Source: AHgI3IZ470Ac8I/tlrAU5GfNRvSzum6Ji0IXk5vzHp1tg+yR3Gi1e1lcrickXU5pLyhi5/M1kXhApRYOmQbQ00Vw5nU= X-Received: by 2002:a19:9904:: with SMTP id b4mr8729941lfe.95.1549513783603; Wed, 06 Feb 2019 20:29:43 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Wed, 6 Feb 2019 20:29:05 -0800 Message-ID: To: Dino Farinacci Cc: IESG , draft-ietf-lisp-rfc6833bis@ietf.org, "lisp@ietf.org list" Content-Type: multipart/alternative; boundary="000000000000a589030581464a3f" Archived-At: Subject: Re: [lisp] Constructing Map-Replies with overlapping prefixes X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 04:29:48 -0000 --000000000000a589030581464a3f Content-Type: text/plain; charset="UTF-8" On Wed, Feb 6, 2019 at 7:06 PM Dino Farinacci wrote: > > So, that would mean in the case > > where the Map-Request contains 10.0.0.1, the MS would have to reply > > with: > > > > 10/16 -> ETR1 > > 10.0.2/24 -> ETR3 // New > > 10.0.0.1 is not more specific than 10.0.2.0/24 because 10.0.0.1 & > 0xffffff00 = 10.0.0.0 which is not equal to 10.0.2.0 & 0xffffff00 = > 10.0.2.0. > > So a lookup for 10.0.2.2 would return only the ETR3 entry. And if 10.0.0.1 > was looked up later than the /16 would be returned. > Sorry, I think you lost me here. How does the MS know that the ITR already has the ETR3 entry? I would expect that if you had the sequence of queries: 10.0.2.2/32 and 10.0.0.1/32, you would get (10.0.2/24) and then (10/16 and 10.0.2/24). Am I confuges? > The first of these is necessary to provide correct routing information > > for the requested prefix and the second to avoid providing incorrect > > routing information for 10.0.2.1. > > Right. > Thanks. > Do I have this correct? It seems like the alternative is that the MS > > or ETR synthesize a new, more specific prefix. Is that what's intended > > instead? The example in S 5.5 suggests otehrwise, but perhaps I am > > misunderstanding. > > Well it could return a prefix 10.0.0.1/32 with an RLOC of ETR1 so the > entires stored in the cache are the ones actually used. But that would > cause not Map-Request load and more entires in the cache. > Sorry, I think you lost me here. Are you saying that the MS can *either* return both the 10/16 and 10.0.2/24 prefixes *or* 10.0.0.1/32 at its discretion? Thanks, -Ekr > So one trades off up front all registered entries in the cache versus all > possible destination EIDs that matches the coarsest prefix. > > Dino --000000000000a589030581464a3f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Feb 6, 2019 at 7:06 PM Dino F= arinacci <farinacci@gmail.com= > wrote:
>= So, that would mean in the case
> where the Map-Request contains 10.0.0.1, the MS would have to reply > with:
>
>=C2=A0 =C2=A0 10/16=C2=A0 =C2=A0-> ETR1
>=C2=A0 =C2=A0 10.0.2/24 -> ETR3 // New

10.0.0.1 is not more specific than 10.0.2.0/24 because 10.0.0.1 & 0xffffff= 00 =3D 10.0.0.0 which is not equal to 10.0.2.0 & 0xffffff00 =3D 10.0.2.= 0.

So a lookup for 10.0.2.2 would return only the ETR3 entry. And if 10.0.0.1 = was looked up later than the /16 would be returned.
<= br>
Sorry, I think you lost me here. How does the MS know that th= e ITR already has the ETR3 entry? I would expect that if you had the sequen= ce of queries: 10.0.2.2/32 and 10.0.0.1/32, you would get (10.0.2/24) and then= (10/16 and 10.0.2/24). Am I confuges?


> The first of these is necessary to provide correct routing information=
> for the requested prefix and the second to avoid providing incorrect > routing information for 10.0.2.1.

Right.

Thanks.


> Do I have this correct? It seems like the alternative is that the MS > or ETR synthesize a new, more specific prefix. Is that what's inte= nded
> instead? The example in S 5.5 suggests otehrwise, but perhaps I am
> misunderstanding.

Well it could return a prefix 10.0.0.1/32 with an RLOC of ETR1 so the entires = stored in the cache are the ones actually used. But that would cause not Ma= p-Request load and more entires in the cache.

Sorry, I think you lost me here. Are you saying that the MS can *ei= ther* return both the 10/16 and 10.0.2/24 prefixes *or* 10.0.0.1/32 at its discretion?

Tha= nks,
-Ekr


=C2=A0
So one trades off up front all registered entries in the cache versus all p= ossible destination EIDs that matches the coarsest prefix.

Dino
--000000000000a589030581464a3f-- From nobody Wed Feb 6 20:36:44 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F371E131092 for ; Wed, 6 Feb 2019 20:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 R4knIg6QEghf for ; Wed, 6 Feb 2019 20:36:35 -0800 (PST) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 EFEED131091 for ; Wed, 6 Feb 2019 20:36:32 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id j15so7138095lfh.5 for ; Wed, 06 Feb 2019 20:36:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AnijnoarWlGFgmjGJJEauWTwGLxNBEbdL0xcgyhiJfs=; b=XueBvI5VsIxlVQ5wu60F7AIGapPhApymRA2oRZFbts5KPy3foK5JtauAtk60mnoEkb eVWV0bOKrWDwxFrARUW9O1eMXxtTTIAu5SwPp4zct0/XbBD4ZNPfHRvFL1f6OlMfbU8P Jd3ogI6HSmHY8D5722QtlSYxY2wXIkItNyo5qpeebfzIblDBSXNfgDfjve3JGIImxWRx i5XanaiiaHfNsr5rwpdfyB2iqa3UR2Snhu25+zVcbH3AbvT9Rl+v4hxmV4c1NoH/N8q4 om8Fv22ip/fVjU+qEWtUEFM8YdguZ0gYdEqyiYG4Mbd2tO7znP/X/2OsTx/ZgT+ScWRs Ym5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AnijnoarWlGFgmjGJJEauWTwGLxNBEbdL0xcgyhiJfs=; b=CnRH+ZKLkhcD5xGH/w/A6wD1s/A3zmq4hmpcoDP+QQsJmvswDE0ZuUjOfOZMxgtn44 qt+gzsGG0AcWJrLVFcaigrfz0hrbqC9Ks1zaYPtb1dKIO5JzXmZLyfDCWKGAvvcWMfaw a2wtMb6qNRPW6T5t7StbtS4i0QyMg8oJbGhVx/8fRq9XtA6ER4nC6/qIxjCo5GwyzgAd 6e+4/SQyhr15AFtB4I0a+P41vAoHbB9aCXo9xlR1CcC3dhaAWeUb39fchj6+OF9aBUab TNRHJLpbx+nR5UeDHeX70H3A72WeLGC3zFs/dk8VqdRAa1n1xUHHv77dZrlPM5etGJnz jMCg== X-Gm-Message-State: AHQUAubMSohmMQ1YOzyPXBTlciYNn4KP2eueCc2ABfLz7Wzjryp/OQYP Y2ncnHuUXUzczi0qW/1ojTY6HYQ4py+U37qwIjLHow== X-Google-Smtp-Source: AHgI3IYFJgjy5jFhvse4hc14B8yAI5yUjuXXHi14oCyIbI5Bjd2DcSgez0hXzCO+0Ctfkm8Xhxpbxt3mNCSTUsYi+H0= X-Received: by 2002:a19:1d87:: with SMTP id d129mr7869558lfd.106.1549514191048; Wed, 06 Feb 2019 20:36:31 -0800 (PST) MIME-Version: 1.0 References: <61A6EEE3-F667-4B0D-B8AF-62982ED769BF@gmail.com> In-Reply-To: <61A6EEE3-F667-4B0D-B8AF-62982ED769BF@gmail.com> From: Eric Rescorla Date: Wed, 6 Feb 2019 20:35:51 -0800 Message-ID: To: Dino Farinacci Cc: IESG , draft-ietf-lisp-rfc6833bis@ietf.org, "lisp@ietf.org list" Content-Type: multipart/alternative; boundary="000000000000eeabc70581466275" Archived-At: Subject: Re: [lisp] Constructing Map-Replies with overlapping prefixes X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 04:36:38 -0000 --000000000000eeabc70581466275 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 6, 2019 at 7:08 PM Dino Farinacci wrote: > Another question: What does the Map Server do if it gets a request for a > shorter prefix than it has an EID for. E.g., I have a > > Returns an empty RLOC-set with action =E2=80=9Cnative-forward=E2=80=9D wi= th an EID-prefix > that is equal to the EID-prefix in the Map-Request. > > mapping for 10/8 (and nothing else) but I get a request for 10/4. The tex= t > in S 5.5 suggests that I return an empty locator set. Is that correct? > Yep. > Thanks. This brings me to the security question I have. As I understand it, Map-Requests are not integrity protected (except for the protected OTK if LISP-SEC is used). So consider the following situation. Let's assume that the MS has a prefix table consisting of: 10.1/16 -> ETR1 10.2/16 -> ETR2 The ITR wants to send to 10.1.0.1, so it naturally send a Map-Request for that address, but the attacker tampers with it. ITR Attacker Map Server Map-Request [10.1.0.1/32] -> Map-Request [10/8] -> <- Map-Reply [10/8, RLOC-Set=3D()] <- Map-Reply [10/8, RLOC-Set=3D()] Assuming I have understood correctly, this will cause the ITR to think that there is no available mapping for anything in 10/8. Even if there is LISP-SEC, because the Map-Request isn't integrity protected, though the Map-Reply is, the integrity protection doesn't cover the requested prefix, so that doesn't help. Is there something in the protocol that I am missing that prevents this? Thanks, -Ekr Dino > > > On Wed, Feb 6, 2019 at 6:11 PM Eric Rescorla wrote: > >> I'm trying to piece together the algorithm in 6833-bis S 5.5 >> for Map-Replies. The text says: >> >> A Map-Reply returns an EID-Prefix with a mask-length that is less >> than or equal to the EID being requested. >> >> So, consider the case where an MS has two mappings: >> >> 10/8 -> ETR1 >> 11/8 -> ETR2 >> >> If the Map-Request is for 10.0.0.1, then I would return >> >> 10/8 -> ETR1 >> >> Now consider what happens when I have three mappings: >> >> 10/16 -> ETR1 >> 10.0.2/24 -> ETR3 // New >> 11/16 -> ETR2 >> >> Now we turn to the remainder of this section: >> >> When an EID moves out of a LISP site [I-D.ietf-lisp-eid-mobility], >> the database mapping system may have overlapping EID-prefixes. Or >> when a LISP site is configured with multiple sets of ETRs that >> support different EID-prefix mask-lengths, the database mapping >> system may have overlapping EID-prefixes. When overlapping EID- >> prefixes exist, a Map-Request with an EID that best matches any EID- >> Prefix MUST be returned in a single Map-Reply message. For instance, >> if an ETR had database mapping entries for EID-Prefixes: >> >> I'm having trouble parsing this, but what I get out of the example >> is that the Map-Response is supposed to contain the EID-prefix that >> best matches the request, plus whatever exceptions would be required >> to create a correct routing table. So, that would mean in the case >> where the Map-Request contains 10.0.0.1, the MS would have to reply >> with: >> >> 10/16 -> ETR1 >> 10.0.2/24 -> ETR3 // New >> >> The first of these is necessary to provide correct routing information >> for the requested prefix and the second to avoid providing incorrect >> routing information for 10.0.2.1. >> >> Do I have this correct? It seems like the alternative is that the MS >> or ETR synthesize a new, more specific prefix. Is that what's intended >> instead? The example in S 5.5 suggests otehrwise, but perhaps I am >> misunderstanding. >> >> Thanks, >> -Ekr >> >> >> >> >> >> >> >> >> >> >> >> --000000000000eeabc70581466275 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Feb 6, 2019 at 7:08 PM Dino Farinacci= <farinacci@gmail.com> wro= te:
Another question: What does the Map Server do if it = gets a request for a shorter prefix than it has an EID for. E.g., I have a =

Returns an empty RLOC-set with action =E2=80=9Cn= ative-forward=E2=80=9D with an EID-prefix that is equal to the EID-prefix i= n the Map-Request.=C2=A0

mapping for 10/8 (and no= thing else) but I get a request for 10/4. The text in S 5.5 suggests that I= return an empty locator set. Is that correct?
Ye= p.

=
Thanks. This brings me to the security question = I have.

As I understand it, Map-Requests are not integrity protected= (except
for the protected OTK if LISP-SEC is used). So consider the fol= lowing
situation.

Let's assume that the MS has a prefix table= consisting of:

=C2=A0 10.1/16 -> ETR1
=C2=A0 10.2/16 -> ET= R2

The ITR wants to send to 10.1.0.1, so it naturally send a Map-Req= uest
for that address, but the attacker tampers with it.


ITR= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Attacker=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Map Server

Map-Request [<= a href=3D"http://10.1.0.1/32">10.1.0.1/32] ->
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Map-Request [10/8] ->
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <- Map-Reply [10/8, RLOC-Set=3D()]
= =C2=A0=C2=A0 <- Map-Reply [10/8, RLOC-Set=3D()]=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0

Assuming I have understood correctly, this= will cause the ITR to think
that there is no available mapping for anyt= hing in 10/8.=C2=A0 Even if
there is LISP-SEC, because the Map-Request i= sn't integrity protected,
though the Map-Reply is, the integrity pro= tection doesn't cover the
requested prefix, so that doesn't help= .

Is there something in the protocol that I am missing that prevents= this?

Thanks,
-Ekr

Dino<= /div>

=
On Wed= , Feb 6, 2019 at 6:11 PM Eric Rescorla <ekr@rtfm.com> wrote:
I'm try= ing to piece together the algorithm in 6833-bis S 5.5
for Map-Replies. T= he text says:

=C2=A0=C2=A0 A Map-Reply returns an EID-Prefix with a = mask-length that is less
=C2=A0=C2=A0 than or equal to the EID being req= uested.

So, consider the case where an MS has two mappings:

= =C2=A0=C2=A0 10/8 -> ETR1
=C2=A0=C2=A0 11/8 -> ETR2

If the = Map-Request is for 10.0.0.1, then I would return

=C2=A0=C2=A0 10/8 -= > ETR1

Now consider what happens when I have three mappings:
<= br>=C2=A0=C2=A0 10/16=C2=A0=C2=A0 -> ETR1
=C2=A0=C2=A0 10.0.2/24 ->= ; ETR3 // New
=C2=A0=C2=A0 11/16=C2=A0=C2=A0 -> ETR2

Now we tu= rn to the remainder of this section:

=C2=A0=C2=A0 When an EID moves = out of a LISP site [I-D.ietf-lisp-eid-mobility],
=C2=A0=C2=A0 the databa= se mapping system may have overlapping EID-prefixes.=C2=A0 Or
=C2=A0=C2= =A0 when a LISP site is configured with multiple sets of ETRs that
=C2= =A0=C2=A0 support different EID-prefix mask-lengths, the database mapping=C2=A0=C2=A0 system may have overlapping EID-prefixes.=C2=A0 When overlap= ping EID-
=C2=A0=C2=A0 prefixes exist, a Map-Request with an EID that be= st matches any EID-
=C2=A0=C2=A0 Prefix MUST be returned in a single Map= -Reply message.=C2=A0 For instance,
=C2=A0=C2=A0 if an ETR had database = mapping entries for EID-Prefixes:

I'm having trouble parsing thi= s, but what I get out of the example
is that the Map-Response is suppose= d to contain the EID-prefix that
best matches the request, plus whatever= exceptions would be required
to create a correct routing table. So, tha= t would mean in the case
where the Map-Request contains 10.0.0.1, the MS= would have to reply
with:

=C2=A0=C2=A0 10/16=C2=A0=C2=A0 -> E= TR1
=C2=A0=C2=A0 10.0.2/24 -> ETR3 // New

The first of these i= s necessary to provide correct routing information
for the requested pre= fix and the second to avoid providing incorrect
routing information for = 10.0.2.1.

Do I have this correct? It seems like the alternative is t= hat the MS
or ETR synthesize a new, more specific prefix. Is that what&#= 39;s intended
instead? The example in S 5.5 suggests otehrwise, but perh= aps I am
misunderstanding.

Thanks,<= /div>
-Ekr










--000000000000eeabc70581466275-- From nobody Thu Feb 7 00:42:36 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F204F1310FA for ; Thu, 7 Feb 2019 00:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=gigix-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 Uco9nUrBrDgt for ; Thu, 7 Feb 2019 00:42:31 -0800 (PST) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 CC8AA131104 for ; Thu, 7 Feb 2019 00:42:25 -0800 (PST) Received: by mail-wm1-x32f.google.com with SMTP id a62so5167081wmh.4 for ; Thu, 07 Feb 2019 00:42:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=38geerq+/4AW3I5y4M8TbbWP3/yxsrhiZrbCcsxHS7s=; b=NRi6C+MTVV5FnSYbTWWqnBaT63zsFooAb0Ar1uFL2v95xwrNcbXxI6bQuGJiljcJFX JbqDcflV7nb98m2j9CHDkI2h8c1qXQuhjKusHKtQfH4YYhRtzV2V+ttWPtCqMdDkjuNj rfZlsKDUJjHPyzgVJeNbLYumcSi2vOX5jjUgHXneJt/8aCP+FqgXhI63sN+qJhQGNyyz veP42MtybGsZa6xd0XmZmB9L610vcWftuynk1Y9qVMLKhLQddg4wOdXZ2nN1UoTU5IZa HJdOyy970pLjO81Ekbl2ZZ1UGQHdAVw2k+Elu6DjC2MyZmMQHUFThOej6R6vTgYbiErY RKFg== 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=38geerq+/4AW3I5y4M8TbbWP3/yxsrhiZrbCcsxHS7s=; b=oXtgC8juLOpHFOm/4n7A/hwHxkAFwQYDYAdDPCSrlv4LGlqv0oBfJ+lXn/EvUSOYqC mHZx97c2tVLx0TVy0l/IHPgYkTKwtoxf7O38dgIgZVB59+Z/Xee8AJctavLIypx+eLeC 1nr6qcA3GkLw1TTqna4s1mOgHs2Y23/CPf8ZHUdxjvvdVgyuq/G1io1b+p21qF/DUKLg 76cswZaNbmJKSf6hm5OrwizcIB8lhbebMuWeVVnZaZ/Kt1pmQwdK/a4UaCk2yfVcLSJx KXULr//06Fcv8f5yNtVVf+aE65KpTA33tQk+b7ghFwP6JUMIo1zqH0ugZhzd2t+ZqgEO XCxw== X-Gm-Message-State: AHQUAuZiZGE5OJrpEB5SlOPamnnnqynUwX56EqCmPJXpgdeSeYJCb7PL pRw/JGAgHU4SphHyMpPnpmGT6g== X-Google-Smtp-Source: AHgI3IbkyxUzBP1+MZfBZ5D1TOGHvdsyIUq6afV1iyzXbQrcEUpa77SzACUkmoeHaDyIxJc54Q+A7A== X-Received: by 2002:a1c:5a42:: with SMTP id o63mr6256259wmb.88.1549528944130; Thu, 07 Feb 2019 00:42:24 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:4082:459c:cea5:81dc? ([2001:660:330f:a4:4082:459c:cea5:81dc]) by smtp.gmail.com with ESMTPSA id m4sm5265117wrq.6.2019.02.07.00.42.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Feb 2019 00:42:22 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Luigi Iannone In-Reply-To: Date: Thu, 7 Feb 2019 09:42:25 +0100 Cc: Dino Farinacci , The IESG , lisp-chairs@ietf.org, "lisp@ietf.org list" , draft-ietf-lisp-rfc6830bis@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7BD549B6-CA14-4C84-936C-466208F1D530@gigix.net> References: <153667905625.16761.12157659372502604927.idtracker@ietfa.amsl.com> <7DEBCA24-9D55-4325-85AA-48AB3FAAB91D@gmail.com> <0201F06C-DA9E-445A-A995-54BA805B595C@kuehlewind.net> <5EC21C57-D217-48A9-AFD0-24710299CF7F@kuehlewind.net> <5A3C4B1F-EA31-4698-96F4-915A77400A56@gmail.com> <2CAF25CC-01EE-49D4-B970-F8EFB24940A8@kuehlewind.net> <5F9D8F39-871D-4A96-9C0A-7BACD2ABB1F7@gmail.com> <2DC6D38E-C46B-4D38-B093-B88720BCD550@kuehlewind.net> <0BE5C929-D2FA-4786-9F5E-0A93E7700880@gmail.com> <11FBAC13-2859-4778-84CA-B546EB669727@kuehlewind.net> <2FEB555F-16A5-4875-93ED-D14BFEEF503A@gigix.net> <1B6E2085-FFD8-4CAA-B9BB-5CBFC5AA9745@gigix.net> To: "Mirja Kuehlewind (IETF)" X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 08:42:34 -0000 Thanks Mirja. Ciao L. > On 6 Feb 2019, at 18:57, Mirja Kuehlewind (IETF) = wrote: >=20 > Hi Luigi, >=20 > yes that sounds great! >=20 > Thanks! > Mirja >=20 >=20 >> Am 06.02.2019 um 17:10 schrieb Luigi Iannone : >>=20 >> Hi Mirja, >>=20 >>=20 >>> On 5 Feb 2019, at 16:39, Mirja Kuehlewind (IETF) = wrote: >>>=20 >>> Hi Luigi, >>>=20 >>> I just realized that I never replied to this mail. The change below = is okay, however, it did not make it into the current version of the = draft and therefore I cannot clear my discuss. >>=20 >> Fair enough. >>=20 >> Let me sum up the changes we agree on: >>=20 >>=20 >> Section 5.3 in the part marked as "When doing ITR/PITR = encapsulation:=E2=80=9D >>=20 >> OLD: >> The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 >> of the IPv6 'Traffic Class' field) requires special treatment in >> order to avoid discarding indications of congestion [ >> RFC6040 >> ]. >> ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner >> header to the outer header. Re-encapsulation MUST copy the = 2-bit >>=20 >> 'ECN' field from the stripped outer header to the new outer >>=20 >> header. >>=20 >> NEW and simplified: >>=20 >> The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 >> of the IPv6 'Traffic Class' field) requires special treatment in >> order to avoid discarding indications of congestion as specified = in=20 >>=20 >> [RFC6040].=20 >>=20 >>=20 >> Note the re-encapsultion test has been remove (see later on) >>=20 >>=20 >> Section 5.3 in the part marked as "When doing ETR/PETR = decapsulation:" >>=20 >> OLD:=20 >> The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 >> of the IPv6 'Traffic Class' field) requires special treatment in >> order to avoid discarding indications of congestion [ >> RFC6040 >> ]. If >> the 'ECN' field contains a congestion indication codepoint (the >> value is '11', the Congestion Experienced (CE) codepoint), then >> ETR decapsulation MUST copy the 2-bit 'ECN' field from the >> stripped outer header to the surviving inner header that is used >> to forward the packet beyond the ETR. These requirements = preserve >> CE indications when a packet that uses ECN traverses a LISP = tunnel >> and becomes marked with a CE indication due to congestion = between >> the tunnel endpoints. Implementations exist that copy the 'ECN' >> field from the outer header to the inner header even though >> [ >> RFC6040 >> ] does not recommend this behavior. It is RECOMMENDED >> that implementations change to support the behavior in [ >> RFC6040]. >>=20 >>=20 >> NEW and simplified: >>=20 >> The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 >> of the IPv6 'Traffic Class' field) requires special treatment in >> order to avoid discarding indications of congestion as specified = in=20 >>=20 >> [RFC6040 >> ]. Note that implementations exist that copy the 'ECN' >> field from the outer header to the inner header even though >> [ >> RFC6040 >> ] does not recommend this behavior. It is RECOMMENDED >> that implementations change to support the behavior in [ >> RFC6040]. >>=20 >>=20 >> In the same section drop completely the last paragraph because is a = duplicate of the above. >> Replaced by a note on the re-encapsulation: >>=20 >> NEW (Replacing last paragraph) >>=20 >> Some xTRs and PxTRs performs re-encapsulation operations and need=20= >> to treat the 'Explicit Congestion Notification' (ECN) in a = special way. >> Because the re-encapsulation operation is a sequence of two = operations, namely=20 >> a decapsulation followed by an encapsulation, the ECN bits = MUST be treated as described=20 >> above for these two operations. >>=20 >>=20 >> Does it sound OK to you? >>=20 >> Ciao >>=20 >> L. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>> Please also note that the text on decapsulation is basically in the = same section twice. I recommend to remove it once and adapt the other = one accordingly. >>>=20 >>> Further, inline with RFC6040, you would also need to align the = re-encapsulation part. Currently the text says: >>> "Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped = outer header to the new outer header.=E2=80=9C >>> Usually re-encapsulation is performed by doing de-encapsulation and = then encapsulation again. The difference here would be, that if e.g. the = inner header is not-ETC but the tunnel changes the bits to ETC0 or ETC1 = this error is not further propagated, indicating ECN support where there = is not ECN support. >>>=20 >>> Thanks, >>> Mirja >>>=20 >>>=20 >>>=20 >>>> Am 26.09.2018 um 17:27 schrieb Luigi Iannone : >>>>=20 >>>> Hi Mirja, >>>>=20 >>>> trying to follow up on this issue. >>>>=20 >>>> The ECN text for encapsulation is currently: >>>>=20 >>>> The 'Explicit Congestion Notification' (ECN) field (bits 6 and = 7 >>>> of the IPv6 'Traffic Class' field) requires special treatment = in >>>> order to avoid discarding indications of congestion [ >>>> RFC3168 >>>> ]. >>>> ITR encapsulation MUST copy the 2-bit 'ECN' field from the = inner >>>> header to the outer header. Re-encapsulation MUST copy the = 2-bit >>>>=20 >>>> 'ECN' field from the stripped outer header to the new outer >>>>=20 >>>> header. >>>>=20 >>>> Can we keep it as it is (updating the reference to 6040)? >>>>=20 >>>> The text for decapsulation is: >>>>=20 >>>> CURRENT: >>>> The 'Explicit Congestion Notification' (ECN) field (bits 6 and = 7 >>>> of the IPv6 'Traffic Class' field) requires special treatment = in >>>> order to avoid discarding indications of congestion [ >>>> RFC6040 >>>> ]. If >>>> the 'ECN' field contains a congestion indication codepoint (the >>>> value is '11', the Congestion Experienced (CE) codepoint), then >>>> ETR decapsulation MUST copy the 2-bit 'ECN' field from the >>>> stripped outer header to the surviving inner header that is = used >>>> to forward the packet beyond the ETR. These requirements = preserve >>>> CE indications when a packet that uses ECN traverses a LISP = tunnel >>>> and becomes marked with a CE indication due to congestion = between >>>> the tunnel endpoints. Implementations exist that copy the = 'ECN' >>>> field from the outer header to the inner header even though >>>> [ >>>> RFC6040 >>>> ] does not recommend this behavior. It is RECOMMENDED >>>> that implementations change to support the behavior in [ >>>> RFC6040 >>>> ]. >>>>=20 >>>>=20 >>>> Which I suggest we shrink to: >>>>=20 >>>> NEW: >>>>=20 >>>> The 'Explicit Congestion Notification' (ECN) field (bits 6 and = 7 >>>> of the IPv6 'Traffic Class' field) requires special treatment = in >>>> order to avoid discarding indications of congestion [ >>>> RFC6040].=20 >>>> Note that implementations exist that copy the 'ECN' >>>> field from the outer header to the inner header even though >>>> [ >>>> RFC6040 >>>> ] does not recommend such behavior. It is RECOMMENDED >>>> that implementations change, so to support the specifications = in [ >>>> RFC6040 >>>> ]. >>>>=20 >>>>=20 >>>>=20 >>>> The text above clearly states that implementations should be = conform to 6040.=20 >>>>=20 >>>> Is it what you were looking for? >>>>=20 >>>> Or am I missing something? >>>>=20 >>>> Ciao >>>>=20 >>>> L. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> On 24 Sep 2018, at 19:34, Dino Farinacci = wrote: >>>>>=20 >>>>> Well, the implementations are out and working. And we said in the = latest updates to consider using RFC6040. So not sure we can do much = more than that. >>>>>=20 >>>>> Dino >>>>>=20 >>>>>> On Sep 24, 2018, at 5:52 AM, Mirja Kuehlewind (IETF) = wrote: >>>>>>=20 >>>>>> Because they don=E2=80=99t follow RFC6040 and therefore we do = something different in some corner cases. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> Am 22.09.2018 um 06:52 schrieb Dino Farinacci = : >>>>>>>=20 >>>>>>>> However, I totally disagree with your comment on providing = details that are not implemented. If they are not implemented correctly, = it might even be more important to spell them out in this document, so = implementors have chance to update their (future) implementation to do = the correct thing. Having deployed implementations that are non = standard-conform always happens and in this case it is probably not = specifically problematic as it doesn=E2=80=99t impact interoperability. = However, it is important though that the spec is correct. >>>>>>>=20 >>>>>>> And why do you think they are implemented incorrectly?=20 >>>>>>>=20 >>>>>>> Dino >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 From nobody Thu Feb 7 05:41:44 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC63126CB6 for ; Thu, 7 Feb 2019 05:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 PU9cPrcefRxI for ; Thu, 7 Feb 2019 05:41:38 -0800 (PST) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 BABE512872C for ; Thu, 7 Feb 2019 05:41:37 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id j15so8188827lfh.5 for ; Thu, 07 Feb 2019 05:41:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=/USFJdmk4zG05jsJmJhQO2T8QyWn+QsceeJ9SAdCQSo=; b=FxD6OMSqpF80MrOG8WziicEyeZh9nJcxDMj8rfpNzalizcmSWU8MopdhuSFBdDf0fO e/Fvo8+nE1jm1FSh8vQNCh7jM9WLVoocw1GcAnhnrKyZBzMjIyaZlsrbde2BTlfLGGme ekVA81yYUNB0bXdnnQorCP/gT1wBnX0CqM43qiz3UsDHWuL1Z/oq/cTq1qyEjRKm9qo9 bFM5SzbaX748qxzgix9K8YqW/V5kU1GoYReY+1tlmMnG7prLCzJ8mduoMbn7N3rdfWwb xsx55qfnUIXKVz37GVI85nOQyiLucIO9yFZ14j4C9GbZf2MVxcrhwPcRdLSCJDnnrCW4 Po0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=/USFJdmk4zG05jsJmJhQO2T8QyWn+QsceeJ9SAdCQSo=; b=Vo8X1TqLc5PF4Z7M3n1OKRWD03vgxcv3lubCMg/10WFdDLZ8jmz1XubxJnBWV5t8re Vnd/95qT6dvYE8o9h+v5notn0cCBkvZagqQEaF1xW7WRMbHxmEB2kiBhWzJdYCWzETk1 LlXgCUr8FO/nfOnL/PpteiZ7nx1BAJx7fZGVa5hf7o6mma08U0DLLvbdjCmketTIyX9l I2LNkWVVclk7MOIYAdPu7SLlKTZJVh/Wzfbx2Z1a94RuTMz76PHwvfqcW7fbbAobC44a iuPk4WVSBRr0UnFlqFZVZFxC/1yCVtD4kjqxxrZCAK92fENtFLytKqJeKUxhoadasdcH T8EQ== X-Gm-Message-State: AHQUAuZCI94b8tOke/gG5PVsjpobLbEY5u/knzU1bSpddLUTX/tzgWSi buxn201TYldbK5znmuw7o5Su7lO6YTboceyvYh0c0jZj X-Google-Smtp-Source: AHgI3IZO105wwWH0V7LFBmOoM5l4TGZIDbsn2OHCSOk9ukaMzzT95ONVmi0ZtVtQR6rzaWQw5pHoq8qtiq58I7IQt20= X-Received: by 2002:a19:f204:: with SMTP id q4mr10586417lfh.133.1549546895831; Thu, 07 Feb 2019 05:41:35 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Thu, 7 Feb 2019 05:40:56 -0800 Message-ID: To: IESG , "lisp@ietf.org list" , draft-ietf-lisp-rfc6833bis@ietf.org, draft-ietf-lisp-rfc6830bis@ietf.org Content-Type: multipart/alternative; boundary="0000000000004a0b6405814e002c" Archived-At: Subject: Re: [lisp] Reviewing the updated LISP docs X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 13:41:42 -0000 --0000000000004a0b6405814e002c Content-Type: text/plain; charset="UTF-8" Now with LISP on the To: line On Thu, Feb 7, 2019 at 5:37 AM Eric Rescorla wrote: > I apologize for the length of this e-mail, but there's a lot to > go over. > > I have gone over the responses to my DISCUSS on the LISP > documents as well as taken another look at LISP-SEC. I agree that a number > of the > issues I raised are resolved, and I note those below. However, > I believe that a number of issues remain. > > First, as a procedural I do not think it's appropriate to approve two > documents (6830bis and 6833bis) which have critical security > dependencies on documents (LISP-SEC, Map-Version) which are not yet > before the IESG and therefore have contents which might change during > IETF-LC. I'll happily re-review all these documents together. > Alternately, you can precisely state the properties of LISP-SEC > that you are depending on and we can review these documents > assuming those are correct and then subsequently review > LISP-SEC against that standard. > > Second, LISP-SEC is MTI, not MTU, but that means that we need > to evaluate the security properties of LISP in the case where > LISP-SEC is not in use; I do not believe those properties are > appropriate for a new Internet protocol, as they do not provide > reasonable security against integrity attacks. Is there a reason > that comsec is not mandatory in this case? Note the text > in RFC 3552 which says: > > Note: In general, the IESG will not approve standards track protocols > which do not provide for strong authentication, either internal to > the protocol or through tight binding to a lower layer security > protocol. > > Additionally (and this is dicta because LISP-SEC is not before > us), the design of LISP-SEC seems unnecessarily complicated and > brittle, so at some point that's worth examining. > > Moving to the DISCUSS-worthy points I raised in my review (ignoring > non-blocking comments for now). > > > RFC 6833bis > > THREAT MODEL > > I'm assuming the usual RFC 3552 threat model, I.e., > > > > - All non-Map Server elements in the system (specifically, endpoints > > and the xTRs are potentially malicious). > > > > - Aside from the links between the Map Server elements, the network > > is controlled by the attacker. > > > > Against this background, my expectation is that the attacker > > should not be able to affect traffic in any fashion significantly > > more effective than tampering with the data plane. For instance, > > it's clearly the case that an on-path attacker between two xTRs > > can drop all the packets or forward them to some third xTR, but > > it should not be able to send a small number of packets which > > would then affect the routing of a large number of packets. > > > > I do not expect that the data plane should have better security > > than native (non-IPsec) traffic. Given the nature of LISP and > > the existence of a mapping system, it seems like it's kind of > > a missed opportunity to deploy a credentials system that would > > support IPsec-style data plane security, but given that this > > isn't a generally safe assumption for IP traffic, and therefore > > you need to provide some sort of transport or application security > > anyway, I don't think it's the right standard to hold LISP to. > > This is preface. > > > > ATTACKS > > LISP appears to be vulnerable to a number of routing attacks that > > I claim above it should not be subject to. For example: > > > > 1. An on-path attacker can forge Map Replys to the ITR, > > thus redirecting traffic. > > > > 2. An ETR can perform an "overclaiming" attack in which it > > claims to be responsible for EIDs which it is not actually > > responsible for. > > I believe that both of these are intended to be protected against > by LISP-SEC, but LISP-SEC is not MTU. > > > > 3. An off-path attacker can temporarily reroute traffic by exploiting > > the "gleaning" feature to cache poison an ITR. In addition, the > > "echo noncing" feature does not appear to have a sufficiently strong > > nonce to protect against forgery, and thus turning this into a > > long-term attack > > > > 4. An attacker may be able to perform a number of cache invalidation > > and contamination attacks by exploiting the Map-Version and > > Locator-Status bits. This may lead to DoS. > > In the spreadsheet, you say that this is addressed in the 6833-bis > security considerations, but I don't see it. In any case, I don't > understand why it cannot be fixed, rather than just documented. > > > > 5. An attacker who was at time T responsible for an EID block > > can probably prolong its ability to respond for that block > > even after it is no longer responsible. > > I agree that this is addressed. > > > > 6. A number of the components appear to be subject to various replay > > attacks. > > As above, I don't believe that this is fixed. > > > > DEFENSES > > When looking at attacks, it's important to determine whether there are > > plausible defenses. For most of these, I believe that the answer is > > "yes", at varying levels of cost. As noted above, LISP-SEC appears to > > be intended to address a number of these issues, so it's possible that > > requiring LISP-SEC would go a fair ways towards addressing these > > issues. A cursory look at LISP-SEC turns up some somewhat concerning > > design choices, so I would have to examine it more closely to give a > > real opinion. > > > > I do not believe that LISP-SEC will address the attacks that do not > > involve the Mapping Server. For instance, the gleaning > > contamination/nonce attacks (3) would not appear to be fixed by > > LISP-SEC. However, it's probably possible to fix them by lengthening > > the nonce. > > It's not clear to me that these are documented, but even if they > are, they should be fixed or at least we need an explanation of > why they can't be. The nonce one is especially obvious as it > seems to be just a case of making it bigger. Relying on uBPRF > does not seem sufficient. > > > > With that said, I tend to think that the overall authentication > > architecture here would benefit from a rethink. At a high level, the > > source of most of these problems is the "non-transferability" of the > > mapping information from the Map Server. If the Map Server instead had > > an asymmetric key pair which it used to sign mappings, then almost all > > of these attacks would not work. Specifically: > > > > - The map server could send signed Map Replys so forgery wouldn't work > > > > - Map Replys from ETRs would be signed, so you couldn't overclaim > > > > - Gleaning attacks would sort of work, but because the probe would > > elicit a Map Reply, you couldn't persist them > > > > - Map Versions could be tied to signed objects, so you couldn't do > > cache invalidation by version. You'd probably need some other > > approach for Locator Status bits. > > > > And so on. > > You say that there is text about this in security considerations, > but it mostly seems to just restate the current design, not explain > why a better one is not possible. > > > IMPORTANT > > S 5.2. > > > s: This is the SMR-invoked bit. This bit is set to 1 when an xTR > is > > > sending a Map-Request in response to a received SMR-based Map- > > > Request. > > > > > > m: This is the LISP mobile-node m-bit. This bit is set by xTRs > that > > > operate as a mobile node as defined in [I-D.ietf-lisp-mn]. > > > > This would appear to create a normative reference to this document. To > > avoid that, you need to specify how I behave if I receive it but I > > don't implement lisp-mn. > > I agree that this is fixed. > > > > S 5.2. > > > m: This is the LISP mobile-node m-bit. This bit is set by xTRs > that > > > operate as a mobile node as defined in [I-D.ietf-lisp-mn]. > > > > > > I: This is the xTR-ID bit. When this bit is set, what is > appended to > > > the Map-Request is a 128-bit xTR router-ID. See LISP PubSub > usage > > > procedures in [I-D.ietf-lisp-pubsub] for details. > > > > here too you seem to be creating a normative reference. > > This as well. > > > > S 5.5. > > > is being mapped from a multicast destination EID. > > > > > > 5.5. EID-to-RLOC UDP Map-Reply Message > > > > > > A Map-Reply returns an EID-Prefix with a prefix length that is > less > > > than or equal to the EID being requested. The EID being > requested is > > > > How do I behave if I receive an EID-Prefix that is less than any of my > > mappings. So, I might have mappings for 10.1.0.0/16 and 10.2.0.0/16 > > and someone asks me for 10.0.0.0/8? Also, when you talk about prefix > > length, I assume you mean the length fo the mask? > > We had an extended back and forth on this. I still don't find the document > very clear, and I'm not sure that this text is correct. Specifically, > consider the following example, where the MS has two mappings: > > 10/8 -> ETR1 > 10.0.1/24 -> ETR2 > > The Map-Request is for 10.1/16. In email, we agreed that you cannot return > only the first mapping because that would implicitly over-claim. This means > that you either supset one of your mappings or return both (I understood > Dino to be saying you return both). However, the 10.0.1/24 mapping has > a longer prefix than the requested one, so that would seem to violate this > text. > > > > S 5.6. > > > Authentication Data: This is the message digest used from the > output > > > of the MAC algorithm. The entire Map-Register payload is > > > authenticated with this field preset to 0. After the MAC is > > > computed, it is placed in this field. Implementations of this > > > specification MUST include support for HMAC-SHA-1-96 [RFC2404], > > > and support for HMAC-SHA-256-128 [RFC4868] is RECOMMENDED. > > > > What prevents replay attacks here? I'm guessing it's the Map-Version- > > Number, but as I understand it, I can set this to 0. > > You write in your spreadsheet: > "We have fixed this, now Map-Register have an incremental nonce to > prevent replay attacks (in 6833bis: "Nonce: This 8-octet 'Nonce' field > is incremented each time a Map-Register message is sent") " > > It's not clear to me why this prevents replay. Can you please walk me > through the mechanism? > > > > > > S 6.1. > > > receives an SMR-based Map-Request and the source is not in the > > > Locator-Set for the stored Map-Cache entry, then the responding > Map- > > > Request MUST be sent with an EID destination to the mapping > database > > > system. Since the mapping database system is a more secure way to > > > reach an authoritative ETR, it will deliver the Map-Request to the > > > authoritative source of the mapping data. > > > > If I'm understanding this correctly, this allows an ETR to prevent an > > ITR from learning that it is no longer the appropriate ETR for a > > prefix. The way this attack works is that before the topology shift, I > > send SMRs, thus causing Map-Requests, which, because my entry is > > cached, refresh the cache on the ITR past the topology shift. I can > > keep doing this indefinitely. Am I missing something > > I agree with your response here and consider this resolved. > > > > > S 8.2. > > > authentication data, so prior to sending a Map-Register message, > the > > > ETR and Map-Server SHOULD be configured with a shared secret or > other > > > relevant authentication information. A Map-Server's configuration > > > SHOULD also include a list of the EID-Prefixes for which each ETR > is > > > authoritative. Upon receipt of a Map-Register from an ETR, a Map- > > > Server accepts only EID-Prefixes that are configured for that ETR. > > > > How does it know? > > This now seems to be clear. > > > > COMMENTS > > S 5. > > > \ | UDP Length | UDP > Checksum | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | | > > > | LISP > Message | > > > > | | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > What do these two diagrams correspond to? v4 and v6? This needs > > explanation. > > This seems to be resolved. > > > RFC 6830 bis > > DETAIL > > S 4.1. > > > RLOC (outer-header source IP address) in a received LISP > packet. > > > Such a cache entry is termed a "glean mapping" and only > contains > > > a single RLOC for the EID in question. More complete > information > > > about additional RLOCs SHOULD be verified by sending a LISP > Map- > > > Request for that EID. Both the ITR and the ETR MAY also > > > influence the decision the other makes in selecting an RLOC. > > > > This seems like it introduces an immediate overclaiming problem. > > I seem to have misunderstood this. > > > > S 10. > > > When an ETR decapsulates a packet, it will check for any change in > > > the 'Locator-Status-Bits' field. When a bit goes from 1 to 0, the > > > ETR, if acting also as an ITR, will refrain from encapsulating > > > packets to an RLOC that is indicated as down. It will only resume > > > using that RLOC if the corresponding Locator-Status-Bit returns > to a > > > value of 1. Locator-Status-Bits are associated with a Locator-Set > > > > This seems to enable a pretty obvious denial of service attack in > > which you send a message with all LSBs set to 0. > > The change here seems to be: > > " An ETR MUST rate-limit the action it takes when it detects changes in > the > Locator-Status-Bits." > > I'm not sure I understand what this text means, but in any case it > doesn't seem to address the concern I had, which was the use of > LSB=0 to empty the cache. It's not clear why rate limiting helps > that. > > > > > S 10. > > > list returned by the last Map-Reply will be set to zero for that > > > particular EID-Prefix. Refer to Section 16 for security related > > > issues regarding Locator-Status-Bits. > > > > > > When an ETR decapsulates a packet, it knows that it is reachable > from > > > the encapsulating ITR because that is how the packet arrived. In > > > > It doesn't even know this. It just knows that that's been claimed by > > someone who can generate traffic to it. > > This was mostly about clarity. > > > > S 10.1. > > > NOT use the lack of return traffic as an indication that the ETR > is > > > unreachable. Instead, it MUST use an alternate mechanism to > > > determine reachability. > > > > > > 10.1. Echo Nonce Algorithm > > > > > > > This mechanism seems sufficient to verify unreachability but is not a > > secure test of reachability because the nonce is way too short. > > Your response (as above) is that you updated security considerations, > to document this, but why not simply fix it? > > > > S 16. > > > Map-Versioning is a Data-Plane mechanism used to signal a peering > xTR > > > that a local EID-to-RLOC mapping has been updated, so that the > > > peering xTR uses LISP Control-Plane signaling message to retrieve > a > > > fresh mapping. This can be used by an attacker to forge the map- > > > versioning field of a LISP encapsulated header and force an > excessive > > > amount of signaling between xTRs that may overload them. > > > > Can't I also set a super-high version number, thus gagging updates? > > You say "This attack is discussed in the Security Section of 6830bis." > > The relevant text says: > > Map-Versioning is a Data-Plane mechanism used to signal a peering xTR > that a local EID-to-RLOC mapping has been updated, so that the > peering xTR uses LISP Control-Plane signaling message to retrieve a > fresh mapping. This can be used by an attacker to forge the map- > versioning field of a LISP encapsulated header and force an excessive > amount of signaling between xTRs that may overload them. > > A thorough analysis of this depends on Map-Versioning, which, as above, > is not in scope here, but why can't this be fixed? > > > --0000000000004a0b6405814e002c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Now with LISP on the To: line

On Thu, Feb 7, 2019 at 5:= 37 AM Eric Rescorla <e= kr@rtfm.com> wrote:
I apologize for the length of = this e-mail, but there's a lot to
go over.

I have gone over t= he responses to my DISCUSS on the LISP
documents as w= ell as taken another look at LISP-SEC. I agree that a number of the
issu= es I raised are resolved, and I note those below. However,
I believe tha= t a number of issues remain.

First, as a procedural I do not think i= t's appropriate to approve two
documents (6830bis and 6833bis) which= have critical security
dependencies on documents (LISP-SEC, Map-Version= ) which are not yet
before the IESG and therefore have contents which mi= ght change during
IETF-LC. I'll happily re-review all these document= s together.
Alternately, you can precisely state the properties of LISP-= SEC
that you are depending on and we can review these documents
assum= ing those are correct and then subsequently review
LISP-SEC against that= standard.

Second, LISP-SEC is MTI, not MTU, but that means that we = need
to evaluate the security properties of LISP in the case where
LI= SP-SEC is not in use; I do not believe those properties are
appropriate = for a new Internet protocol, as they do not provide
reasonable security = against integrity attacks. Is there a reason
that comsec is not mandator= y in this case? Note the text
in RFC 3552 which says:

=C2=A0=C2= =A0 Note: In general, the IESG will not approve standards track protocols=C2=A0=C2=A0 which do not provide for strong authentication, either inter= nal to
=C2=A0=C2=A0 the protocol or through tight binding to a lower lay= er security
=C2=A0=C2=A0 protocol.

Additionally (and this is dict= a because LISP-SEC is not before
us), the design of LISP-SEC seems unnec= essarily complicated and
brittle, so at some point that's worth exam= ining.

Moving to the DISCUSS-worthy points I raised in my review (ig= noring
non-blocking comments for now).


RFC 6833bis
> TH= REAT MODEL
> I'm assuming the usual RFC 3552 threat model, I.e.,<= br>>
> - All non-Map Server elements in the system (specifically,= endpoints
>=C2=A0=C2=A0 and the xTRs are potentially malicious).
= >=C2=A0=C2=A0
> - Aside from the links between the Map Server ele= ments, the network
>=C2=A0=C2=A0 is controlled by the attacker.
&g= t;
> Against this background, my expectation is that the attacker> should not be able to affect traffic in any fashion significantly
= > more effective than tampering with the data plane. For instance,
&g= t; it's clearly the case that an on-path attacker between two xTRs
&= gt; can drop all the packets or forward them to some third xTR, but
>= it should not be able to send a small number of packets which
> woul= d then affect the routing of a large number of packets.
>
> I = do not expect that the data plane should have better security
> than = native (non-IPsec) traffic. Given the nature of LISP and
> the existe= nce of a mapping system, it seems like it's kind of
> a missed op= portunity to deploy a credentials system that would
> support IPsec-s= tyle data plane security, but given that this
> isn't a generally= safe assumption for IP traffic, and therefore
> you need to provide = some sort of transport or application security
> anyway, I don't = think it's the right standard to hold LISP to.

This is preface.<= br>

> ATTACKS
> LISP appears to be vulnerable to a number o= f routing attacks that
> I claim above it should not be subject to. F= or example:
>
> 1. An on-path attacker can forge Map Replys to= the ITR,
>=C2=A0=C2=A0=C2=A0 thus redirecting traffic.
>
&= gt; 2. An ETR can perform an "overclaiming" attack in which it>=C2=A0=C2=A0=C2=A0 claims to be responsible for EIDs which it is not a= ctually
>=C2=A0=C2=A0=C2=A0 responsible for.

I believe that bo= th of these are intended to be protected against
by LISP-SEC, but LISP-S= EC is not MTU.


> 3. An off-path attacker can temporarily rero= ute traffic by exploiting
>=C2=A0=C2=A0=C2=A0 the "gleaning"= ; feature to cache poison an ITR. In addition, the
>=C2=A0=C2=A0=C2= =A0 "echo noncing" feature does not appear to have a sufficiently= strong
>=C2=A0=C2=A0=C2=A0 nonce to protect against forgery, and thu= s turning this into a
>=C2=A0=C2=A0=C2=A0 long-term attack
>> 4. An attacker may be able to perform a number of cache invalidation<= br>>=C2=A0=C2=A0=C2=A0 and contamination attacks by exploiting the Map-V= ersion and
>=C2=A0=C2=A0=C2=A0 Locator-Status bits. This may lead to = DoS.

In the spreadsheet, you say that this is addressed in the 6833-= bis
security considerations, but I don't see it. In any case, I don&= #39;t
understand why it cannot be fixed, rather than just documented.

> 5. An attacker who was at time T responsible for an EID block=
>=C2=A0=C2=A0=C2=A0 can probably prolong its ability to respond for = that block
>=C2=A0=C2=A0=C2=A0 even after it is no longer responsible= .

I agree that this is addressed.


> 6. A number of the= components appear to be subject to various replay
>=C2=A0=C2=A0=C2= =A0 attacks.

As above, I don't believe that this is fixed.

> DEFENSES
> When looking at attacks, it's important to = determine whether there are
> plausible defenses. For most of these, = I believe that the answer is
> "yes", at varying levels of = cost. As noted above, LISP-SEC appears to
> be intended to address a = number of these issues, so it's possible that
> requiring LISP-SE= C would go a fair ways towards addressing these
> issues. A cursory l= ook at LISP-SEC turns up some somewhat concerning
> design choices, s= o I would have to examine it more closely to give a
> real opinion.>
> I do not believe that LISP-SEC will address the attacks tha= t do not
> involve the Mapping Server. For instance, the gleaning
= > contamination/nonce attacks (3) would not appear to be fixed by
>= ; LISP-SEC. However, it's probably possible to fix them by lengthening<= br>> the nonce.

It's not clear to me that these are documente= d, but even if they
are, they should be fixed or at least we need an exp= lanation of
why they can't be. The nonce one is especially obvious a= s it
seems to be just a case of making it bigger. Relying on uBPRF
do= es not seem sufficient.


> With that said, I tend to think tha= t the overall authentication
> architecture here would benefit from a= rethink. At a high level, the
> source of most of these problems is = the "non-transferability" of the
> mapping information from= the Map Server. If the Map Server instead had
> an asymmetric key pa= ir which it used to sign mappings, then almost all
> of these attacks= would not work. Specifically:
>
> - The map server could send= signed Map Replys so forgery wouldn't work
>
> - Map Repl= ys from ETRs would be signed, so you couldn't overclaim
>
>= ; - Gleaning attacks would sort of work, but because the probe would
>= ;=C2=A0=C2=A0 elicit a Map Reply, you couldn't persist them
> > - Map Versions could be tied to signed objects, so you couldn't d= o
>=C2=A0=C2=A0 cache invalidation by version. You'd probably nee= d some other
>=C2=A0=C2=A0 approach for Locator Status bits.
> =
> And so on.

You say that there is text about this in securit= y considerations,
but it mostly seems to just restate the current design= , not explain
why a better one is not possible.

> IMPORTANT> S 5.2.
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 s: This is the SMR-= invoked bit.=C2=A0 This bit is set to 1 when an xTR is
> >=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sending a Map-Request in respons= e to a received SMR-based Map-
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Request.
> >=C2=A0=C2=A0
> >=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 m: This is the LISP mobile-node m-bit.=C2=A0 This bit= is set by xTRs that
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 operate as a mobile node as defined in [I-D.ietf-lisp-mn].
> <= br>> This would appear to create a normative reference to this document.= To
> avoid that, you need to specify how I behave if I receive it bu= t I
> don't implement lisp-mn.

I agree that this is fixed.=


> S 5.2.
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 m: This = is the LISP mobile-node m-bit.=C2=A0 This bit is set by xTRs that
> &= gt;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 operate as a mobile nod= e as defined in [I-D.ietf-lisp-mn].
> >=C2=A0=C2=A0
> >= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I: This is the xTR-ID bit.=C2=A0 When this b= it is set, what is appended to
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 the Map-Request is a 128-bit xTR router-ID.=C2=A0 See LI= SP PubSub usage
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 procedures in [I-D.ietf-lisp-pubsub] for details.
>
> here= too you seem to be creating a normative reference.

This as well.

> S 5.5.
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 is being mapped from a multicast destination EID.
> >=C2=A0= =C2=A0
> >=C2=A0=C2=A0 5.5.=C2=A0 EID-to-RLOC UDP Map-Reply Messa= ge
> >=C2=A0=C2=A0
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A M= ap-Reply returns an EID-Prefix with a prefix length that is less
> &g= t;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 than or equal to the EID being requested.= =C2=A0 The EID being requested is
>
> How do I behave if I rec= eive an EID-Prefix that is less than any of my
> mappings. So, I migh= t have mappings for 10.1.0= .0/16 and 10.2.0.0/16<= /a>
> and someone asks me for 10.0.0.0/8? Also, when you talk about prefix
> length, I= assume you mean the length fo the mask?

We had an extended back and= forth on this. I still don't find the document
very clear, and I= 9;m not sure that this text is correct. Specifically,
consider the follo= wing example, where the MS has two mappings:

=C2=A0=C2=A0 10/8 ->= ETR1
=C2=A0=C2=A0 10.0.1/24 -> ETR2
=C2=A0=C2=A0
The Map-Requ= est is for 10.1/16. In email, we agreed that you cannot return
only the = first mapping because that would implicitly over-claim. This means
that = you either supset one of your mappings or return both (I understood
Dino= to be saying you return both). However, the 10.0.1/24 mapping has
a lon= ger prefix than the requested one, so that would seem to violate this
te= xt.


> S 5.6.
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Authe= ntication Data:=C2=A0 This is the message digest used from the output
&g= t; >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of the MAC algorith= m.=C2=A0 The entire Map-Register payload is
> >=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 authenticated with this field preset to 0.= =C2=A0 After the MAC is
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 computed, it is placed in this field.=C2=A0 Implementations of th= is
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 specificati= on MUST include support for HMAC-SHA-1-96 [RFC2404],
> >=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and support for HMAC-SHA-256-128 [R= FC4868] is RECOMMENDED.
>
> What prevents replay attacks here?= I'm guessing it's the Map-Version-
> Number, but as I unders= tand it, I can set this to 0.

You write in your spreadsheet:
&quo= t;We have fixed this, now Map-Register have an incremental nonce to
prev= ent replay attacks (in 6833bis: "Nonce: This 8-octet 'Nonce' f= ield
is incremented each time a Map-Register message is sent") &quo= t;

It's not clear to me why this prevents replay. Can you please= walk me
through the mechanism?




> S 6.1.
> &= gt;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 receives an SMR-based Map-Request and the= source is not in the
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Locator-Se= t for the stored Map-Cache entry, then the responding Map-
> >=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Request MUST be sent with an EID destination to= the mapping database
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 system.=C2= =A0 Since the mapping database system is a more secure way to
> >= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 reach an authoritative ETR, it will deliver = the Map-Request to the
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 authorita= tive source of the mapping data.
>
> If I'm understanding = this correctly, this allows an ETR to prevent an
> ITR from learning = that it is no longer the appropriate ETR for a
> prefix. The way this= attack works is that before the topology shift, I
> send SMRs, thus = causing Map-Requests, which, because my entry is
> cached, refresh th= e cache on the ITR past the topology shift. I can
> keep doing this i= ndefinitely. Am I missing something

I agree with your response here = and consider this resolved.



> S 8.2.
> >=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 authentication data, so prior to sending a Map-Reg= ister message, the
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ETR and Map-S= erver SHOULD be configured with a shared secret or other
> >=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 relevant authentication information.=C2=A0 A Map-S= erver's configuration
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SHOULD= also include a list of the EID-Prefixes for which each ETR is
> >= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 authoritative.=C2=A0 Upon receipt of a Map-R= egister from an ETR, a Map-
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Serv= er accepts only EID-Prefixes that are configured for that ETR.
>
= > How does it know?

This now seems to be clear.


> C= OMMENTS
> S 5.
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= \ |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 UDP Length= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 UDP Checksum=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LISP = Message=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > What do these two diagrams correspond to? v4 and v6? This needs
&g= t; explanation.

This seems to be resolved.


RFC 6830 bis> DETAIL
> S 4.1.
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 RLOC (outer-header source IP address) in a received L= ISP packet.
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Such a cache entry is termed a "glean mapping" and only conta= ins
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a si= ngle RLOC for the EID in question.=C2=A0 More complete information
> = >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 about additional= RLOCs SHOULD be verified by sending a LISP Map-
> >=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Request for that EID.=C2=A0 Both= the ITR and the ETR MAY also
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 influence the decision the other makes in selecting a= n RLOC.
>
> This seems like it introduces an immediate overcla= iming problem.

I seem to have misunderstood this.


> S = 10.
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 When an ETR decapsulates a p= acket, it will check for any change in
> >=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 the 'Locator-Status-Bits' field.=C2=A0 When a bit goes from = 1 to 0, the
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ETR, if acting also = as an ITR, will refrain from encapsulating
> >=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 packets to an RLOC that is indicated as down.=C2=A0 It will on= ly resume
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 using that RLOC if the= corresponding Locator-Status-Bit returns to a
> >=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 value of 1.=C2=A0 Locator-Status-Bits are associated with a= Locator-Set
>
> This seems to enable a pretty obvious denial = of service attack in
> which you send=C2=A0 a message with all LSBs s= et to 0.

The change here seems to be:

" An ETR MUST rate= -limit the action it takes when it detects changes in the=C2=A0=C2=A0=C2=A0=
=C2=A0 Locator-Status-Bits."

I'm not sure I understand= what this text means, but in any case it
doesn't seem to address th= e concern I had, which was the use of
LSB=3D0 to empty the cache. It'= ;s not clear why rate limiting helps
that.



> S 10.
= > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 list returned by the last Map-Reply= will be set to zero for that
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pa= rticular EID-Prefix.=C2=A0 Refer to Section 16 for security related
>= >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 issues regarding Locator-Status-Bits.> >=C2=A0=C2=A0
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 When an= ETR decapsulates a packet, it knows that it is reachable from
> >= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the encapsulating ITR because that is how th= e packet arrived.=C2=A0 In
>
> It doesn't even know this. = It just knows that that's been claimed by
> someone who can gener= ate traffic to it.

This was mostly about clarity.


> S = 10.1.
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NOT use the lack of return= traffic as an indication that the ETR is
> >=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 unreachable.=C2=A0 Instead, it MUST use an alternate mechanism to=
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 determine reachability.
>= >=C2=A0=C2=A0
> >=C2=A0=C2=A0 10.1.=C2=A0 Echo Nonce Algorith= m
> >=C2=A0=C2=A0
>
> This mechanism seems sufficien= t to verify unreachability but is not a
> secure test of reachability= because the nonce is way too short.

Your response (as above) is tha= t you updated security considerations,
to document this, but why not sim= ply fix it?


> S 16.
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Map-Versioning is a Data-Plane mechanism used to signal a peering xTR> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that a local EID-to-RLOC mapping = has been updated, so that the
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pe= ering xTR uses LISP Control-Plane signaling message to retrieve a
> &= gt;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fresh mapping.=C2=A0 This can be used by = an attacker to forge the map-
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ve= rsioning field of a LISP encapsulated header and force an excessive
>= >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 amount of signaling between xTRs that m= ay overload them.
>
> Can't I also set a super-high versio= n number, thus gagging updates?

You say "This attack is discuss= ed in the Security Section of 6830bis."

The relevant text says:=

=C2=A0=C2=A0 Map-Versioning is a Data-Plane mechanism used to signa= l a peering xTR
=C2=A0=C2=A0 that a local EID-to-RLOC mapping has been u= pdated, so that the
=C2=A0=C2=A0 peering xTR uses LISP Control-Plane sig= naling message to retrieve a
=C2=A0=C2=A0 fresh mapping.=C2=A0 This can = be used by an attacker to forge the map-
=C2=A0=C2=A0 versioning field o= f a LISP encapsulated header and force an excessive
=C2=A0=C2=A0 amount = of signaling between xTRs that may overload them.

A thorough analysi= s of this depends on Map-Versioning, which, as above,
is not in scope he= re, but why can't this be fixed?


--0000000000004a0b6405814e002c-- From nobody Thu Feb 7 05:50:42 2019 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A9FD91271FF; Thu, 7 Feb 2019 05:50:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-lisp-rfc6833bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, ggx@gigix.net, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154954743968.23471.9935733647283605722.idtracker@ietfa.amsl.com> Date: Thu, 07 Feb 2019 05:50:39 -0800 Archived-At: Subject: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6833bis-24: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 13:50:40 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-lisp-rfc6833bis-24: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This document has normative dependencies on other WG drafts that are not yet mature (one could perhaps define this as having completed IETF LC). In particular, I believe there is a nontrivial chance that either or both of lisp-sec and 6834bis could require changes to this document in order to be fit for purpose, and thus that this document cannot safely be approved for publication until these normative dependencies are closer to publication. In particular, I have done a fairly full review of lisp-sec and have DISCUSS-worthy points with it (I have not done much review of 6834bis yet). This document includes a mechansism to use HMAC keyed by a pre-shared key to authenticate messages (Map-Register and Map-Notify*); it is directly using the long-term PSK as the HMAC key. This is not really consistent with current IETF best practices (e.g,. BCP 107), which tend to not use the long-term key directly for keying messages, but rather to incorporate some form of key derivation step, to protect the long-term key from cryptanalysis and reduce the need to track long-term per-key data usage limits. It is probably not feasible to directly require all LISP implementations to switch keying strategy, but it seems quite advisable to define new algorithm ID types that include a key derivation step before the HMAC, and to begin efforts to convert the ecosystem to the more sustainable cryptographic usage. I would like to discuss what actions are reasonable to take at this time, on this front. As implied by my previous discuss ballot position, I think Section 5.4 should grow a statement (akin to the one added in Section 5.6) that the "Record" format is also used in the "Map-Reply Record" field of the Map-Request message, and that the field definitions are reused wholesale for the Map-Register message. In Section 5.6, this text seems internally inconsistent: can continue using an incrementing nonce. If the the ETR cannot support saving the nonce, then when it restarts it MUST use a new authentication key to register to the mapping system. A Map- Server MUST track and save in persistent storage the last nonce received for each ETR xTR-ID that registers to it. If a Map- Register is received with a nonce value that is not greater than the saved nonce, it drops the Map-Register message and logs the fact a replay attack could have occurred. In order for a new key to be useful as stated, the Map-Server must do the nonce tracking per pair and not just per xTR-ID. Also, guidance is needed on what scope of uniqueness is needed for the Key ID to function properly -- unique per Map-Server? Per pair? Per LISP domain? Also in Section 5.6: Implementations of this specification MUST include support for either HMAC-SHA-1-96 [RFC2404] and HMAC-SHA-256-128 [RFC4868] where the latter is RECOMMENDED. I don't think this sort of "mandatory to choose" is BCP 201-compliant. I think there needs to be more description of Site-ID usage and scoping in order to be fully interoperable (more in the COMMENT section). There are multiple places where we talk about message contents being copied from a corresponding request (e.g., from Map-Request to Map-Notify); we need to explicitly state that the authentication data is recomputed to match, e.g., the new message type. I've tried to note these occurrences in the COMMENT section. The condition for Map-Notify-Ack terminating Map-Notify retransmission seems incomplete (more in the COMMENT). In Section 8.2: A Map-Register message includes authentication data, so prior to sending a Map-Register message, the ETR and Map-Server SHOULD be configured with a shared secret or other relevant authentication information. [...] We require authentication for Map-Register and do not provide any alternative mechanism for key distribution, so why is this only a SHOULD? As developers and operators gain experience with the mapping system, additional, stronger security measures may be added to the registration process. This text does not add confidence to the "proposed standard" label. In Section 9: A complete LISP threat analysis can be found in [RFC7835]. In what As I have stated previously, the threat analysis in RFC 7835 is not complete and it should not be referred to as such. 3. LISP-SEC [I-D.ietf-lisp-sec] MUST be implemented. Network operartors should carefully weight how the LISP-SEC threat model applies to their particular use case or deployment. If they decide to ignore a particular recommendation, they should make sure the risk associated with the corresponding threats is well understood. I'm concerned enough about the risk of having a "ITR requests lisp-sec but ETR didn't use it" case that causes complete breakage, that I want to talk about this a bit more. We currently in this document say that lisp-sec is mandatory to implement (which presumably covers at least ITRs, ETRs, Map-Resolvers, and Map-Servers). LISP-SEC itself says that "and ETR that supports LISP-SEC MUST set the S bit in its Map-Register messages". Is it possible that an ETR might "implement" but then not "support" LISP-SEC? If so, then we should consider the possibility that we need an authenticated signal (from the mapping system to the ITR) that downgrading from lisp-sec is allowed. There seem to be several possibilities for how one might construct such a signal; two that came to mind to me would be (1) to define a new ACT value for "repeat without lisp-sec" that could be returned as a negative Map-Response directly from the mapping system wherever the mapping system is able to discern that the ETR in question does not support lisp-sec (I don't actually know if this could happen at Map-Resolver or would need to be delayed until the final Map-Server) and (2) to have an optional Map-Request field that the ETR is required to copy unchanged to the Map-Reply; this could then include a message HMAC'd in the ITR-OTK that indicates lisp-sec non-support and binds to the nonce in the request. Whether these are workable ideas seems to depend on aspects of the mapping system to which I cannot speak. The LISP-SEC protocol defines a mechanism for providing origin authentication, integrity, anti-replay, protection, and prevention of 'man-in-the- middle' and 'prefix overclaiming' attacks on the Map-Request/Map- Reply exchange. [...] Does LISP-SEC actually provide any additional anti-replay protection not present in the base protocol? I do not remember any such additional protection. A complete LISP threat analysis has been published in [RFC7835]. Please refer to it for more detailed security related details. (1) you already said that above, (2) it's still not complete. Section 11 ("Changes since RFC 6833") is inaccurate (see COMMENT). I did not check whether it is complete, but someone needs to do so before final publication. The following items were present in my original DISCUSS position and still have not been resolved. Note that I copy below the previous ballot text even for some issues that are described above already in different words. A 64-bit nonce is used, apparently as a request/response correlator, but the actual (cryptographic?) properties required from the nonce in the protocol are not clearly covered. In some cryptographic contexts a 64-bit nonce may be too short; I do not believe that this is the case here, but without a clear picture of what the requirements are it's hard to say for sure. [ed. there was some previous discussion about 24-bit nonces that has been removed from the text, but the core question of what properties the nonce is required to provide remains unaddressed in the document text. There is also a field called 'Nonce' that is used as a s equence number, the requirements for which are partially described in the new text.] The layout of the document is somewhat confusing, in a way that could arguably lead to noninteroperable implemnetations. For example, the section on the Map-Register message format includes descriptions of the fields in the records and locators therein, and the section on Map-Notify reuses that portion of the structure, incorporating the field descriptions by reference. But the Map-Register section does not indicate that its descriptions are to apply in both cases, leading to confusing text that talks about values being set or cases that are not possible for a Map-Register (i.e., the section nominally being described). It would be most clear to have a dedicated subsection for the portion of the structure(s) that is being reused, which would allow for the per-field descriptions to clearly indicate in which scope they are defined. But the more minimal change of just indicating that the primary definition will be "dual use" would probably suffice as well. The Map-Reply record/locator descriptions are reused similarly; I made a comment on section 5.4 that lists a specific instance, though I believe the phenomenon is more general. [ed. this was partially addressed, but the request to examine all data structure reuse (note that "for example" was used) was not heeded] Similarly, there are many instances (some noted in my Comment) where a bidirectional interaction between two xTRs is described, yet the peers are identified as "ITR" and "ETR". This is very confusing when the entity named as "ITR" is described as performing ETR functionality, or vice versa; pedagogically, it would be much better to use non-role-based names for the entities while describing these exchanges. [ed. there was some improvement here; I still note some potential sites for confusion in the COMMENT] While I see that there is an entire document dedicated to Map-Versioning and thus we do not need to fully cover everything here, I think it is critically important to be clear that there are consistency requirements attached to map versions, as relating to the stability of membership of RLOCs in a given record, etc. (I cannot be very clear hear since I am not entirely confident of the details of the consistency requirements yet.) I think we need greater clarity on the 'E' and 'M' bits in the ECM format; more in the Comment section. [ed. the reader will need to consult the original ballot's COMMENT section and not the current one] Section 8.1 says: o A Negative Map-Reply, with action code of "Natively-Forward", from a Map-Server that is authoritative for an EID-Prefix that matches the requested EID but that does not have an actively registered, more-specific ID-prefix. This document provides no mechanism to establish that a Map-Server is authoritative for a given EID-Prefix, so this entire case is non-actionable. [ed. I think there may have been some previous discussion on this (e.g., that might render it moot) but couldn't find it quickly] Section 8.2 says: An ETR publishes its EID-Prefixes on a Map-Server by sending LISP Map-Register messages. A Map-Register message includes authentication data, so prior to sending a Map-Register message, the ETR and Map-Server SHOULD be configured with a shared secret or other relevant authentication information. This cannot be a SHOULD if things are to work properly; it has to be MUST. Section 8.2 also says: As developers and operators gain experience with the mapping system, additional, stronger security measures may be added to the registration process. This kind of language for forward-looking guidance indicates that the current security properties are not well-understood by the authors and is inconsistent with Proposed Standard status. I think the MUST and SHOULD requirements for implementing cryptographic primitives are generally swapped; the more-secure ones (e.g., HMAC-SHA-256-128) should be MUST, and the legacy algorithms needed for compatibility with existing deployments would be SHOULD. Section 9 currently states: [a]s noted in Section 8.2, a Map-Server SHOULD verify that all EID- Prefixes registered by an ETR match the configuration stored on the Map-Server. I think we need a MUST-level requirement for verifying authorization for a given EID-Prefix, with one way of satisfying the requirement being checking configuration, but allowing for other means as well. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Abstract This document describes the Control-Plane and Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two new types of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server This is a -bis document; is "new" really appropriate? (It also appears in the Introduction, of course.) Section 1 LISP is not intended to address problems of connectivity and scaling on behalf of arbitrary communicating parties. Relevant situations are described in the scoping section of the introduction to [I-D.ietf-lisp-rfc6830bis]. It looks like we inline that text into this document as Section 1.1, below; perhaps this paragraph is no longer needed, then? Section 2 I don't think the "In may IETF documents...near the beginning of their document" needs to be included, as the genart reviewer noted. Section 4 A Map-Server is a device that publishes EID-Prefixes in a LISP mapping database on behalf of a set of ETRs. When it receives a Map Request (typically from an ITR), it consults the mapping database to nit: isn't it typically from a Map-Resolver (or other mapping-system-internal entity)? It's originally from an ITR, of course, but the flow assumed by this document is described as ITR->Map-Resolver->mapping-system-internals->Map-Server->ETR. Note that while it is conceivable that a Map-Resolver could cache responses to improve performance, issues surrounding cache management will need to be resolved so that doing so will be reliable and nit: s/will/would/? practical. As initially deployed, Map-Resolvers will operate only in a non-caching mode, decapsulating and forwarding Encapsulated Map Requests received from ITRs. Any specification of caching functionality is out of scope for this document. I think it's better to say something like "In this specification," rather than "As initially deployed". Also, I've confused myself a couple times from this -- it's only the Map-Resolver that doesn't cache; the ITR is free to cache. It might be helpful to call out that distinction here. Section 5 I still think it's needlessly confusing to duplicate the IP/UDP header layout figure here, at least without a prefacing comment noting that this is the standard IP+UDP header with the IP addresses replaced by RLOCs. But this is a non-blocking comment and the authors have already replied, so feel free to ignore. Implementations MUST be prepared to accept packets when either the source port or destination UDP port is set to 4342 due to NATs changing port number values. It's not entirely clear to me what this requirement is saying. Section 5.2 A: This is an authoritative bit, which is set to 0 for UDP-based Map- Requests sent by an ITR. It is set to 1 when an ITR wants the destination site to return the Map-Reply rather than the mapping database system returning a Map-Reply. Given that we've already disclaimed caching in the mapping system, aren't all responses supposed to come from the destination site rather than the mapping system? Searching the rest of the document for the string "authoritative" suggests that this is perhaps intended to avoid proxying behavior from terminating Map-Servers (but when an ETR requests proxying is it still guaranteed to be able to generate its own Map-Replys?), in which case this could probably be phrased better. P: This is the probe-bit, which indicates that a Map-Request SHOULD be treated as a Locator reachability probe. The receiver SHOULD respond with a Map-Reply with the probe-bit set, indicating that the Map-Reply is a Locator reachability probe reply, with the nonce copied from the Map-Request. [...] Why are these only SHOULD? I still think it is needlessly confusing to have bit labels that differ only by letter case. While this may not be confusing for the authors, there are plenty of other people who could potentially be confused by it. (Also, why are there two bits 'R' next to a 'Rsvd' field that all have the same "reserved" semantics?) L: This is the local-xtr bit. It is used by an xTR in a LISP site to tell other xTRs in the same site that it is part of the RLOC-set for the LISP site. The L-bit is set to 1 when the RLOC is the sender's IP address. At this point in the document, we haven't seen anything to suggest that an xTR is going to be sending Map-Requests to other xTRs in the same site; a forward reference is probably in order. D: This is the dont-map-reply bit. It is used in the SMR procedure described in Section 6.1. When an xTR sends an SMR Map-Request message, it doesn't need a Map-Reply returned. When this bit is set, the receiver of the Map-Request does not return a Map-Reply. nit: I'd suggest consolidating the behavior description and leaving the explanations all at the end, so "This is the dont-map-reply bit. When this bit is set, the receiver of the Map-Request does not return a Map-Reply. It is used in the SMR procedure described in Section 6.1; when an xTR sends an SMR Map-Request message, it doesn't need a Map-Reply returned." Support for processing multiple EIDs in a single Map-Request message will be specified in a future version of the protocol. I would suggest not using the assertive future tense here, as we cannot really bind our future actions to guarantee its truth. Wordings like "may be specified" or "is left for a future version" are alternative options. EID mask-len: This is the mask length for the EID-Prefix. In bits, right? ... EID-Prefix: This prefix address length is 4 octets for an IPv4 address family and 16 octets for an IPv6 address family when the ... then maybe we shouldn't switch to bytes for just one sentence (and go back to bits later in the paragraph)? entry, the EID-Prefix is set to the destination IP address of the data packet, and the 'EID mask-len' is set to 32 or 128 for IPv4 or IPv6, respectively. When an xTR wants to query a site about Is this really an xTR-specific action, or does it apply to any ITR functionality? This allows the ETR that will receive this Map-Request to cache the data if it chooses to do so. OTOH, this one does seem to require an xTR. Section 5.3 For the initial case, the destination IP address used for the Map-Request is the data packet's destination address (i.e., the destination EID) that had a mapping cache lookup failure. [...] This seems like a type mismatch between RLOC/EID -- per the headers, the destination address should be an RLOC, but we are forced to use an EID in this case. The disparity should probably be called out and explained, e.g., clarify that it's okay to use an EID as destination inside ECM encapsulation (and, apparently, if we believe Section 5.8, that it's required to do so). A successful Map-Reply, which is one that has a nonce that matches an outstanding Map-Request nonce, will update the cached set of RLOCs associated with the EID-Prefix range. nit: A negative Map-Reply will match the nonce. Will it also update the cached set? Is it still considered to be "successful"? If the ITR erroneously provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map- Request. I see we talked about this last time around; did you want to add some text about how, despite the protocol message not definitionally allowing for this detection, in practice it is still possible? Request. When an ETR configured to accept and verify such "piggybacked" mapping data receives such a Map-Request and it does So, "(i.e., it is also an ITR)"? If the ETR (when it is an xTR co-located as an ITR) has a Map-Cache entry that matches the "piggybacked" EID and the RLOC is in the Locator-Set for the entry, then it MAY send the nit: "cached entry" would help clarify the prerequisites here. source. If the RLOC is not in the Locator-Set, then the ETR MUST send the "verifying Map-Request" to the "piggybacked" EID. [...] "send ... to the [...] EID" seems like a type mismatch again, since we only can send Map-Requests to RLOCs. Section 5.4 Map-Request. See RLOC-probing Section 7.1 for more details. When the probe-bit is set to 1 in a Map-Reply message, the A-bit in each EID-record included in the message MUST be set to 1. Do we want to specify any special handling if that NUST is disobeyed? S: This is the Security bit. When set to 1, the following authentication information will be appended to the end of the Map- Reply. The details of signing a Map-Reply message can be found in [I-D.ietf-lisp-sec]. Please do not use the word "signing" here; it is a term of art that is not appropriate to the actual operation performed. Record TTL: This is the time in minutes the recipient of the Map- Reply will store the mapping. If the TTL is 0, the entry MUST be I think "can" is more appropriate than "will"; generally a local cache can safely be invalidated at will. Locator Count: This is the number of Locator entries. A Locator Please scope this to "in the given Record". EID mask-len: This is the mask length for the EID-Prefix. (in bits, right?) ACT: This 3-bit field describes Negative Map-Reply actions. In any other message type, these bits are set to 0 and ignored on receipt. These bits are used only when the 'Locator Count' field is set to 0. The action bits are encoded only in Map-Reply messages. [...] This is the section on Map-Reply messages; why are we talking about other message types? Also, do we want to mention that the possible values are managed by IANA? A: The Authoritative bit, when set to 1, is always set to 1 by an ETR. When a Map-Server is proxy Map-Replying for a LISP site, the Authoritative bit is set to 0. This indicates to requesting ITRs that the Map-Reply was not originated by a LISP node managed at the site that owns the EID-Prefix. nit: This text is needlessly confusing. How about "The authoritative bit can only be set to 1 by an ETR (and not a Map-Server generating Map-Reply messages as a proxy). If this bit is set to 0, that indicates ..."? Section 5.5 Please provide a link/reference for Data-Probe on first usage. For each Map-Reply record, the list of Locators in a Locator-Set MUST appear in the same order for each ETR that originates a Map-Reply message. The Locator-Set MUST be sorted in order of ascending IP address where an IPv4 locator address is considered numerically 'less than' an IPv6 locator address. IIUC, there is no need for "MUST appear in the same order" if you also mandate a specific sorting function. Section 5.6 P: This is the proxy Map-Reply bit. When set to 1, an ETR sends a Map-Register message requesting the Map-Server to proxy a Map- Reply. [...] nit: "just one?" Do you want to give a mnemonic for the 'I' bit? The "Nonce" field is acting as a sequence number, not just as a number used once. I strongly suggest changing the name accordingly. Authentication Data Length: This is the length in octets of the 'Authentication Data' field that follows this field. The length of the 'Authentication Data' field is dependent on the MAC algorithm used. The length field allows a device that doesn't know the MAC algorithm to correctly parse the packet. Why does a device that won't be able to validate the authentication data need to be able to parse the packet? I thought all Map-Registers needed to be authenticated. xTR-ID: xTR-ID is a 128 bit field at the end of the Map-Register message, starting after the final Record in the message. The xTR- ID is used to uniquely identify a xTR. The same xTR-ID value MUST NOT be used in two different xTRs. Globally, over all time? Within a single LISP domain, over all time? Please be specific. Site-ID: Site-ID is a 64 bit field at the end of the Map- Register message, following the xTR-ID. Site-ID is used to uniquely identify to which site the xTR that sent the message belongs. Where is a (LISP) "site" formally defined? Are there weird topologies or edge cases that we need to consider when assigning numbers, risk of having two IDs that might validly apply to a single xTR, etc.? Section 5.7 (If Nonce is renamed above, it should be renamed here as well.) The fields of the Map-Notify are copied from the corresponding Map- Register to acknowledge its correct processing. [...] Is the authentication data recomputed? The fields of the Map-Notify-Ack are copied from the corresponding Map-Notify message to acknowledge its correct processing. (ditto) The Map-Notify-Ack message has the same contents as a Map-Notify message. It is used to acknowledge the receipt of a Map-Notify (solicited or unsolicited) and for the sender to stop retransmitting So a normal exchange would include Map-Register, Map-Notify, and Map-Notify-Ack? A Map-Server sends an unsolicited Map-Notify message (one that is not used as an acknowledgment to a Map-Register message) that follows the Congestion Control And Relability Guideline sections of [RFC8085]. A This second clause ("that follows") is rather a non sequitur here. And we still don't know what purpose the unsolicited Map-Notify serves! Map-Notify is retransmitted until a Map-Notify-Ack is received by the Map-Server with the same nonce used in the Map-Notify message. If a Presumably we care about (e.g.) the key ID matching and the authentication data validating, as well? Map-Notify-Ack is never received by the Map-Server, it issues a log message. An implementation SHOULD retransmit up to 3 times at 3 second retransmission intervals, after which time the retransmission interval is exponentially backed-off for another 3 retransmission "exponentially" is not well defined unless the base of the exponent is specified. attempts. After this time, an xTR can only get the RLOC-set change by later querying the mapping system or by RLOC-probing one of the RLOCs of the existing cached RLOC-set to get the new RLOC-set. What RLOC-set change? This text doesn't seem to indicate what functionality is going on here. Section 5.8 An Encapsulated Control Message (ECM) is used to encapsulate control packets sent between xTRs and the mapping database system. Some of the flag bit descriptions appear to describe usages that are or can be entirely within the mapping system. D: This is the DDT-bit. When set to 1, the sender is requesting a Map-Referral message to be returned. The details of this procedure are described in [RFC8111]. E.g., here, the sender can be (IIUC) within the mapping system. E: This is the to-ETR bit. When set to 1, the Map-Server's intention is to forward the ECM to an authoritative ETR. I'm not sure that "intention" is quite right, here -- as far as this document is concerned, a Map-Server will always know whether it is sending an ECM to an authoritative ETR. Also, this bit does not seem to be used for anything within this document, and no external reference is given. Are the 'M' and 'E' bits mutally exclusive? (Would we even care?) I suggest adding more text about which sender/receiver pairs are permitted (or allowed or expected) to set the D, E, and M bits. invoking Map-Request. Port number 4341 MUST NOT be assigned to either port. The checksum field MUST be non-zero. This is the only place in this document that we disallow port 4341. Should we also be disallowing it from being used as the non-4342 port for other exchanges? LCM: The format is one of the control message formats described in this section. [...] nit: "this section" means 5.8; presumably we mean Section 5. Section 6.1 I agree with Warren that the direct usage of mapping information included in an SMR presents a substantial attack surface, both for DoS and potentially for redirecting traffic wholesale (whether for snooping purposes or use as volumetric DoS to a third-party target). There is some discussion of the risks of spoofing with this sort of "gleaming" behavior, but I strongly suggest mentioning something like "this technique presents a risk of off-path spoofing; see Section 9 for details" at each such non-validated scheme for learning mapping information. Since ETRs are not required to keep track of remote ITRs that have cached their mappings, they do not know which ITRs need to have their mappings updated. As a result, an ETR will solicit Map-Requests (called an SMR message) to those sites to which it has been sending LISP encapsulated data packets for the last minute. In particular, an ETR will send an SMR to an ITR to which it has recently sent encapsulated data. This can only occur when both ITR and ETR functionality reside in the same router. I still think that this text is needlessly confusing about which action is taken by which router, and could be improved as, e.g., "this can only occur when the ETR also provides ITR functionality (that is, it is an xTR)". Both the SMR sender and the Map-Request responder MUST rate-limit these messages. Rate-limiting can be implemented as a global rate- limiter or one rate-limiter per SMR destination. What is the goal of this rate-limiting; how is the threshold determined? The following procedure shows how an SMR exchange occurs when a site is doing Locator-Set compaction for an EID-to-RLOC mapping: Where is locator-set compaction defined? Throughout this whole example, "the site with the changed mapping" and "the site that sent the Map-Request" are kind of clunky phrases; it might be cleaner writing to give them names (like "site A" and "site B"). 2. A remote ITR that receives the SMR message will schedule sending a Map-Request message to the source locator address of the SMR message or to the mapping database system. [...] How does the ITR decide which destination to send the Map-Request to? copied from the SMR message. If the source Locator is the only Locator in the cached Locator-Set, the remote ITR SHOULD send a just to double-check: this is the source Locator from the SMR? Map-Request to the database mapping system just in case the single Locator has changed and may no longer be reachable to accept the Map-Request. Is this the only case that the Map-Request would go to the mapping system? 3. The remote ITR MUST rate-limit the Map-Request until it gets a Map-Reply while continuing to use the cached mapping. When nit: I suggest a comma after "Map-Reply" to avoid the misparse that the Map-Reply must be received while the cached mapping is in use (and that the rate limiting would continue indefinitely if the cached mapping expired in the meantime). 5. The ETRs at the site with the changed mapping record the fact that the site that sent the Map-Request has received the new mapping data in the Map-Cache entry for the remote site so the Locator-Status-Bits are reflective of the new mapping for packets going to the remote site. [...] The Locator-Status-Bits in which direction? (Probably should also give a section ref to 6830bis for the definition.) For security reasons, an ITR MUST NOT process unsolicited Map- Replies. To avoid Map-Cache entry corruption by a third party, a sender of an SMR-based Map-Request MUST be verified. If an ITR To be clear, the verification here is essentially return-routability verification, aka proof that the sender actually owns the claimed address, right? I think it is appropriate to have some text noting the specific behavior, and that this is not any sort of cryptographic or strongly authenticated verification. receives an SMR-based Map-Request and the source is not in the Locator-Set for the stored Map-Cache entry, then the responding Map- Request MUST be sent with an EID destination to the mapping database system. [...] What is an "SMR-based Map-Request" (also appears in the next paragraph and one other place)? Is it just an SMR? If it's some actual Map-Request, I'm confused at why an *I*TR would be receiving it. Section 7 3. An ITR may receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [RFC6832] and LISP-encapsulated data is sent to a non-LISP-capable site. Is the ITR supposed to conclude that the RLOC is likely down in this situation? When ITRs receive ICMP Network Unreachable or Host Unreachable messages as a method to determine unreachability, they will refrain from using Locators that are described in Locator lists of Map- Replies. [...] Is this really as precise as it can be? It kind of sounds like it says that all Map-Replies will be ignored when any ICMP Network/Host Unreachable message is received. If it does not find one and BGP is running in the Default- Free Zone (DFZ), it can decide to not use the Locator even though the Is running in the DFZ consistent with the reduced scope of running in a single administrative domain? Optionally, an ITR can send a Map-Request to a Locator, and if a Map- Reply is returned, reachability of the Locator has been determined. Is this describing the same flow as item (5) above and Section 7.1 below? If so, it seems totally redundant and could be omitted. Obviously, sending such probes increases the number of control messages originated by Tunnel Routers for active flows, so Locators are assumed to be reachable when they are advertised. I'm not sure what "advertised" is intended to mean, here. Is it "advertised into the mapping system"? But that is not directly visible to the ITR, only indirectly through the results of an actual mapping request (and even then, the Map-Reply from an ETR could be invalid, e.g., overclaiming, unless LISP-SEC is used. Both Requests and Replies MUST be rate- limited. [...] I believe this requirement duplicates requirements already made elsewhere; the other locations also include more guidance on actual rates. Section 7.1 A Map-Request used as an RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or to the mapping database system as one would when soliciting mapping data. [..] I strongly suggest using a word other than "soliciting" to avoid confusion with SMR. data. The EID record encoded in the Map-Request is the EID-Prefix of the Map-Cache entry cached by the ITR or PITR. The ITR MAY include a Is it worth reminding the reader that the source EID here is zero-length and source-EID-AFI set to zero? mapping data record for its own database mapping information that contains the local EID-Prefixes and RLOCs for its site. [...] To double-check: this mapping data record is included in the "Map-Reply Record" field of the Map-Request message? It would probably help the reader to be consistent about this terminology. Section 8.1 In particular, the ITR need not connect to the LISP-ALT infrastructure or implement the BGP and GRE protocols that it uses. Why does LISP-ALT get a callout but not (e.g.) LISP-DDT? Section 8.3 In response to a Map-Request (received over the ALT if LISP-ALT is in use), the Map-Server first checks to see if the destination EID I see no reason to mention LISP-ALT here. If the EID-prefix is registered or not registered and there is a authentication failure, then a Drop/ What is the authentication flow that would be failing here? The Map-Register for the corresponding prefix? If either of these actions result as a temporary state in policy or authentication then a Send-Map-Request action with 1-minute TTL MAY be returned to allow the requestor to retry the Map-Request. How can an SMR have an associated TTL? The message format is that of a regular Map-Request, is it not? Section 8.4 Upon receipt of an Encapsulated Map-Request, a Map-Resolver decapsulates the enclosed message and then searches for the requested EID in its local database of mapping entries (statically configured or learned from associated ETRs if the Map-Resolver is also a Map- Server offering proxy reply service). This seems to be the first time the document admits the possibility for a local database of mapping entries on a Map-Resolver; this makes me wonder if there was an incomplete removal of such functionality from the document, especially given that local caching of responses on the Map-Resolver is explicitly disclaimed in Section 4. Section 8.4.1 ETRs MAY have anycast RLOC addresses which are registered as part of their RLOC-set to the mapping system. However, registrations MUST use their unique RLOC addresses or distinct authentication keys to identify security associations with the Map-Servers. xTR-IDs cannot be used for this purpose? Section 9 I think we should have some discussion here about how mapping information gleamed from SMR messages does not necessarily benefit from the on-path guarantee that the nonce provides for regular mapping-system exchanges. The 2-way LISP control-plane header nonce exchange can be used to avoid ITR spoofing attacks, but active on-path attackers (e.g 'man- Do we really need to limit ourselves to "ITR spoofing" as opposed to generic spoofing, here? The Map-Register message is vulnerable to replay attacks by a man-in-the-middle. A compromised ETR can overclaim the prefix it owns and successfully register it on its corresponding Map-Server. To mitigate this and as noted in Section 8.2, a Map-Server SHOULD verify that all EID-Prefixes registered by an ETR match the configuration stored on the Map-Server. The conversion of the Map-Register 'Nonce' field into a sequence number provides some moderate remediation against the replay attack; that should be included in this discussion. Encrypting control messages via DTLS [RFC6347] or LISP-crypto [RFC8061] SHOULD be used to support privacy to prevent eavesdroping and packet tampering for messages exchanged between xTRs, xTRs and the mapping system, and nodes that make up the mapping system. nit: "to support privacy to prevent eavesdropping and packet tampering" doesn't read as grammatical; is the "to support privacy" still needed? Section 10 Thank you for adding the Privacy Considerations section; it is imporant to document this property of the system and let the operator make informed decisions. As noted by [RFC6973] privacy is a complex issue that greatly depends on the specific protocol use-case and deployment. As noted in section 1.1 of [I-D.ietf-lisp-rfc6830bis] LISP focuses on use-cases Also Section 1.1 of this document. Section 11 o The "m", "I", "L", and "D" bits are added to the Map-Request message. See Section 5.3 for details. Isn't this more a Section 5.2 thing than 5.3? Also, I don't see "m" or "I" bits described (though I do see "M"). o The "S", "I", "E", "T", "a", and "m" bits are added to the Map- Register message. See Section 5.6 for details. I see an "M" bit but not an "m" one. Section 12.3 It feels a little weird to lump the ACT fields (which have a registry) together in a section with the flag fields scattered throughout the protocol (which do not). Is it bad to have separate subsections for them (especially when Section 12.6 already exists and does provide a registry for other flag bits)? Section 12.6 A sub-registry needs to be created per each message and record. [...] What is a "record" in this context? (It does not seem like a mapping record.) I mostly expect IANA to ask for a listing of which bits/ranges are/aren't allocatabale. From nobody Thu Feb 7 06:35:52 2019 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4821295EC; Thu, 7 Feb 2019 06:35:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, ggx@gigix.net, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154955015018.31108.12820143983477326611.idtracker@ietfa.amsl.com> Date: Thu, 07 Feb 2019 06:35:50 -0800 Archived-At: Subject: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-26: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 14:35:50 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-lisp-rfc6830bis-26: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 3 still contains text: EID-to-RLOC Database: The EID-to-RLOC Database is a global distributed database that contains all known EID-Prefix-to-RLOC that indicates that the mapping database is a single, global, distributed database; we had previously agreed that the target scope was much more narrow. I could perhaps charitably assume that this instance was missed as an editing error because the phrase "global distributed database" spans a line break, but given that this specific instance was called out in my previous discuss position, it is fairly hard to do so. Also in Section 3: Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet. [...] 6833bis says (section 5.8) that the inner header can use either RLOC or EID addresses in the header address fields, which contradicts this statement. The various places where we mention "gleaming" or similar unauthenticated (un-path-verified?) schemes for learning mapping information should all mention at their description that they are susceptible to spoofing and link to the security considerations. I'm still concerned about the synchronization requirements between map-version changes and LSB usage; with the currently described technology it seems almost inevitable for race conditions around RLOC changes to cause ITRs to make incorrect routing decisions due to misinterpreted status bits. It's unclear whether it's even worth trying to tackle this problem before the map-versioning document is more advanced along in the process, though. (Several comments throughout are relevant, especially those on Section 13.1.) I agree with Warren that clarity on whether traffic is buffered or dropped during the lookup process is needed (e.g., in Section 6). Also in the vein of Warren's comments, in Section 7.1 I was expecting (from our previous discussions) that some text would be added about the determination of L being something that is "performed once by the administrator of the LISP deployment and treated as a constant across the deployment". The discussion of Instance IDs remains incomplete, with no discussion of within what scope their values must be unique (as truncated to 24 bits). Similarly (also Section 8), Multiple Data-Planes can use the same 32-bit space as long as the low-order 24 bits don't overlap among xTRs. That's a pretty lousy property to have in a PS specification. Section 13 When a Locator record is removed from a Locator-Set, ITRs that have the mapping cached will not use the removed Locator because the xTRs will set the Locator-Status-Bit to 0. So, even if the Locator is in the list, it will not be used. For new mapping requests, the xTRs can set the Locator AFI to 0 (indicating an unspecified address), as well as setting the corresponding Locator-Status-Bit to 0. This I do not remember there being an ordering (or even consistency) requirement on the ITR-RLOC entries in the Map-Request, so it's unclear that just replacing one entry with an AFI-0 entry would convey this information. I suppose that using only a single ITR-RLOC entry, with AFI 0, would provide a usable signal to the ETR, but that does not seem to be what is being described here. (Also, on a rhetorical point, please clarify that the "as well as" is for setting the LSB to 0 in data packets; Map-Requests do not include any LSBs.) If many changes occur to a mapping over a long period of time, one will find empty record slots in the middle of the Locator-Set and new records appended to the Locator-Set. At some point, it would be useful to compact the Locator-Set so the Locator-Status-Bit settings can be efficiently packed. This text, implying that compactification must wait for some unspecified later event, seems to be assuming some requirement to preserve order of Locator-Set entries that I cannot find a description of in either 6830bis or 6833bis. Do RFCs 6831 and 8378 need to be normative references for how to do multicast as an optional protocol feature (recalling that https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/ clarifies that references that are relevant only for optional features are still classified as normative)? In Section 16: A complete LISP threat analysis can be found in [RFC7835]. In what RFC 7835 remains an incomplete analysis; please stop referring to it as such. of time. The goal is to convince the ITR that the ETR's RLOC is reachable even when it may not be reachable. If the attack is I think Warren is correct that there is also an attack that lies in convincing an ITR that an ETR is not reachable even when it is reachable. The following items were present in my original DISCUSS position and still have not been resolved. Note that I copy below the previous ballot text even for some issues that are described above already in different words. Section 4.1's Step (6) only mentions parsing "to check for format validity". I think it is appropriate to mention (and refer to) source authentication checks as well, since bad Map-Reply data can allow all sorts of attacks to occur. There are some fairly subtle ordering requirements between the order of entries in Map-Reply messages and the Locator-Status-Bits in data-plane traffic (so that the semantic meaning of the status bits are meaningful), which is only given a minimal treatment in the control-plane document. The need for synchronization in interpreting these bits should be mentioned more prominently in the data-plane document as well. The usage of the Instance ID does not seem to be adequately covered; from what I've been able to pick up so far it seems that both source and destination participants must agree on the meaning of an Instance ID, and the source and destination EIDs must be in the same Instance. This does not seem like it is compatible with Internet scale, especially if there are only 24 usable bits of Instance ID. There seems to be a lot of intra-site synchronization requirements, notably with respect to Map-Version consistency, the contents and ordering of locator sets for EIDs in the site, etc.; the actual hard requirements for synchronization within a site should be clearly called out, ideally in a single location. The security considerations attempt to defer substantially to the threat-analysis in RFC 7835, which does not really seem like a complete threat analysis and does not provide analysis as to what requirements are placed on the boundaries between the different components of LISP (data plane, control plane, mapping system, various extensions, etc.). The secdir reviewer had some good thoughts in this space. I am not convinced that this protocol meets the current IETF requirements for the security properties of Standards-Track Protocols without at least LISP-SEC as a mandatory-to-implement component, and possibly additional or stronger requirements. (I did not do a full analysis of the system in the presence of those security mechanisms, since that is not what is being presented for review.) [ed. even though LISP-SEC has been promoted to MTI, it remains difficult to be confident in the results of a full system analysis due to the number of other outstanding issues with the core documents. Consider the risk Ekr noted yesterday in email about tampering with the Map-Request causing apparently-valid repsonses that convey incorrect results with respect to the original query.] ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I note as a preface that in many places in this (and other) review, I ask questions. The ones that indicate I actually don't understand are generally accompanied by text like "just to confirm" or provide some option for possible interpretation. Others are intended as rhetorical devices, indicating that the text locally at this point in the document is unclear and the question posed should be addressed in the document, in-line. Section 1 LISP encapsulation uses a dynamic form of tunneling where no static provisioning is required or necessary. Do I interpret this correctly as meaning that no static provisioning is necessary on end-hosts? It seems that ETRs and the mapping system entities definitely need static configuration. But do end sites need to know what lisp site/administrative domain they are part of? LISP is an overlay protocol that separates control from Data-Plane, this document specifies the Data-Plane, how LISP-capable routers (Tunnel Routers) exchange packets by encapsulating them to the appropriate location. [...] nit: this is a comma splice Section 3 Anycast Address: Anycast Address is a term used in this document to How does this definition differ from the one in RFC 8499? Data-Probe: A Data-Probe is a LISP-encapsulated data packet where the inner-header destination address equals the outer-header destination address used to trigger a Map-Reply by a decapsulating ETR. [...] nit: is this better as two sentences? ("...is a LISP-encapsulated data packet where the inner-header destination address equals the outer-header destination address. It is used to trigger...") I would also say something in this paragraph about how this behavior blurs the distinction between EID and RLOC. When using Data-Probes, by sending Map-Requests on the underlying routing system, EID-Prefixes must be advertised. I don't understand why the one follows from the other (in fact, there seem to be three not-particularly-related concepts in this sentence). (I also note that "Data-Probe" is not mentioned anywhere in this document other than its own definition, which would suggest that it could be moved to 6833bis, which does mention them.) EID-to-RLOC Database: The EID-to-RLOC Database is a global distributed database that contains all known EID-Prefix-to-RLOC I thought we had agreed to remove this "global distributed database" language. addresses that are routable on the underlay. Note that there MAY be transient conditions when the EID-Prefix for the site and Locator-Set for each EID-Prefix may not be the same on all ETRs. nit: we haven't indicated a definite site for "the site" to be meaningful. EID-to-RLOC Map-Cache: The EID-to-RLOC Map-Cache is generally short-lived, on-demand table in an ITR that stores, tracks, and is responsible for timing out and otherwise validating EID-to-RLOC mappings. This cache is distinct from the full "database" of EID- to-RLOC mappings; it is dynamic, local to the ITR(s), and relatively small, while the database is distributed, relatively static, and much more global in scope to LISP nodes. "global" caught my eye again here; perhaps "global in scope to a LISP deployment"? EID-Prefix: An EID-Prefix is a power-of-two block of EIDs that are allocated to a site by an address allocation authority. EID- Prefixes are associated with a set of RLOC addresses. EID-Prefix allocations can be broken up into smaller blocks when an RLOC set is to be associated with the larger EID-Prefix block. nit: I think the causality here is backwards -- the breaking up does not occur at the moment that you associate an RLOC set to a larger EID-Prefix block. Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet. [...] 6833bis says (section 5.8) that the inner header can use either RLOC or EID addresses in the header address fields, which contradicts this statement. Specifically, when a service provider prepends a LISP header for Traffic Engineering purposes, the router that does this is also regarded as an ITR. The outer RLOC the ISP ITR uses can be based on the outer destination address (the originating ITR's supplied RLOC) or the inner destination address (the originating host's Er, that the ISP ITR uses as source or as destination? Negative Mapping Entry: A negative mapping entry, also known as a negative cache entry, is an EID-to-RLOC entry where an EID-Prefix is advertised or stored with no RLOCs. That is, the Locator-Set for the EID-to-RLOC entry is empty, one with an encoded Locator count of 0. This type of entry could be used to describe a prefix from a non-LISP site, which is explicitly not in the mapping database. There are a set of well-defined actions that are encoded in a Negative Map-Reply. This bit about Negative Map-Replys comes out of the blue; is it really needed in this paragraph? TE-ETR: A TE-ETR is an ETR that is deployed in a service provider network that strips an outer LISP header for Traffic Engineering purposes. nit: is it really the act of stripping the header that is done for TE purposes? Section 4.1 2. The LISP ITR must be able to map the destination EID to an RLOC of one of the ETRs at the destination site. The specific method used to do this is not described in this example. See [I-D.ietf-lisp-rfc6833bis] for further information. 3. The ITR sends a LISP Map-Request as specified in [I-D.ietf-lisp-rfc6833bis]. Map-Requests SHOULD be rate-limited. At risk of repeating myself, isn't (3) just doing what (2) says the ITR must be able to do? I don't see why both items are needed. 5. The ETR looks at the destination EID of the Map-Request and matches it against the prefixes in the ETR's configured EID-to- RLOC mapping database. This is the list of EID-Prefixes the ETR is supporting for the site it resides in. If there is no match, the Map-Request is dropped. Otherwise, a LISP Map-Reply is Isn't this (1) something that 6833bis should be authoritative on, and (2) a recipe for random hangs if the mapping system ever misdirects a map-request? 7. Subsequent packets from host1.abc.example.com to host2.xyz.example.com will have a LISP header prepended by the The use of "subsequent" implies that he original IP packet does not receive this treatment. But we don't say anywhere that it gets dropped, leaving us guessing as to what is supposed to happen to it. 9. In order to defer the need for a mapping lookup in the reverse direction, an ETR can OPTIONALLY create a cache entry that maps the source EID (inner-header source IP address) to the source RLOC (outer-header source IP address) in a received LISP packet. Such a cache entry is termed a "glean mapping" and only contains This gleaming seems susceptible to spoofing. Section 5.3 L: The L-bit is the 'Locator-Status-Bits' field enabled bit. When this bit is set to 1, the Locator-Status-Bits in the second 32 bits of the LISP header are in use. What happens to those bits when the L-bit is set to zero? E: The E-bit is the echo-nonce-request bit. This bit MUST be ignored and has no meaning when the N-bit is set to 0. When the N-bit is set to 1 and this bit is set to 1, an ITR is requesting that the Do we need to say what to do when N is 1 and E is 0? LISP Locator-Status-Bits (LSBs): When the L-bit is also set, the [...] the ETRs at the same site. When a site has multiple EID-Prefixes that result in multiple mappings (where each could have a different Locator-Set), the Locator-Status-Bits setting in an encapsulated packet MUST reflect the mapping for the EID-Prefix that the inner-header source EID address matches. If the LSB for I don't think there is guaranteed to be a single unique EID-Prefix that matches the inner source EID; we need to say longest-match here. o The outer-header 'Differentiated Services Code Point' (DSCP) field (or the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the outer-header DSCP field ('Traffic Class' field, in the case of IPv6) to the inner-header. IPv6 is a first-class IP protocol; it should not be relegated to a parenthetical. Note that if an ETR/PETR is also an ITR/PITR and chooses to re- encapsulate after decapsulating, the net effect of this is that the new outer header will carry the same Time to Live as the old outer header minus 1. Where is the decrementing of the TTL documented? I just see "copy" in the above text. Is the last paragraph adding anything that was not already said previously? It seems pretty redundant on first read. Section 6 Finally, the Map-Cache also contains reachability information about EIDs and RLOCs, and uses LISP reachability information mechanisms to determine the reachability of RLOCs, see Section 10 for the specific mechanisms. nit: The Map-Cache performs reachability discovery? That seems incongruous with a cache nature; perhaps it is better to say that it is updated with the results of such procedures. Section 7.1 Note that reassembly can happen at the ETR if the encapsulated packet was fragmented at or after the ITR. Why would an ETR want to take on this additional state-keeping burden instead of relegating it to the end host? When the 'DF' field of the IP header is set to 1, or the packet is an IPv6 packet originated by the source host, the ITR will drop the packet when the size is greater than L and send an ICMPv4 ICMP Which size? Section 9 o Either side (more likely the server-side ETR) decides not to send a Map-Request. For example, if the server-side ETR does not send Map-Requests, it gleans RLOCs from the client-side ITR, giving the [in the next paragraph we talk about sending Map-Requests to verify gleamed mappings, which doesn't mesh very well with "does not send Map-Requests" here] client-side ITR responsibility for bidirectional RLOC reachability and preferability. Server-side ETR gleaning of the client-side ITR RLOC is done by caching the inner-header source EID and the outer-header source RLOC of received packets. [...] Isn't this susceptible to spoofing? Instead of using the Map-Cache or mapping system, RLOC information MAY be gleaned from received tunneled packets or Map-Request messages. A "gleaned" Map-Cache entry, one learned from the source To double-check, this is describing the same behavior described in the iast bullet point? RLOC of a received encapsulated packet, is only stored and used for a few seconds, pending verification. Verification is performed by sending a Map-Request to the source EID (the inner-header IP source address) of the received encapsulated packet. A reply to this As I commented on 6833bis, I'd appreciate mention that this "verification" is akin to reverse-routability verification and does not involve any cryptographic assurances. This "gleaning" mechanism is OPTIONAL, refer to Section 16 for security issues regarding this mechanism. nit: comma splice Section 10 2. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely to be reachable. Liktely to, but not guaranteed, since that's a spoofable field and we rely on the ITR to fill it with something useful. When determining Locator up/down reachability by examining the Locator-Status-Bits from the LISP-encapsulated data packet, an ETR will receive up-to-date status from an encapsulating ITR about reachability for all ETRs at the site. [...] This ("up-to-date") wording concerns me, relating to the interaction between map-versioning, addition/removal of locators from a mapping, and propagation to values in the LSBs. I do not think there is currently a strong consistency guarantee in place that would justify the "up-to-date" wording, and 6834bis has not received IETF (or IESG) review yet. My current understanding is that the status information provided via this mechanism could be characterized as "best-effort" or "accurate in the steady-state". The security considerations of Section 16 related with data-plane reachability applies to the data-plane RLOC reachability mechanisms nit: I think this is "related to", not "related with". Section 10.1 When this packet is received by the ETR, the encapsulated packet is forwarded as normal. When the ETR is an xTR (co-located as an ITR), it next sends a data packet to the ITR (when it is an xTR co-located nit: I don't think this is grammatical; maybe "when it next sends"? erroneously consider the Locator unreachable. An ITR SHOULD only set the E-bit in an encapsulated data packet when it knows the ETR is enabled for echo-noncing. This is conveyed by the E-bit in the RLOC- probe Map-Reply message. Is this only in RLOC-probe Map-Reply messages (and not generic, including mapping-driven, Map-Reply messages)? If so, I think that 6833bis needs some clarification in Section 5.4. (If not, I think that "RLOC-probe" should be removed from here.) Section 13 ignores them. However, this can only happen for locator addresses that are lexicographically greater than the locator addresses in the existing Locator-Set. (It might be apropos to explicitly remind the reader that the entries in the locator-set are sorted by IP address.) When a Locator record is removed from a Locator-Set, ITRs that have the mapping cached will not use the removed Locator because the xTRs will set the Locator-Status-Bit to 0. So, even if the Locator is in Why will the xTRs set the Locator-Status-Bit to 0? Won't they just use the updated mapping and have a smaller number of LSBs in their data packets? If many changes occur to a mapping over a long period of time, one will find empty record slots in the middle of the Locator-Set and new records appended to the Locator-Set. At some point, it would be How can this happen when the Locator-Set is required to be sorted? Or does the sorting requirement not apply to the "Map-Reply Record" field of the Map-Request? Section 13.1 A Map-Version Number can be included in Map-Register messages as well. This is a good way for the Map-Server to assure that all ETRs for a site registering to it will be synchronized according to Map- Version Number. This seems vastly underspecified not just to the detailed semantics (for which the 6834bis reference is probably a suitable replacement) but also the goals of the synchronization that is to be obtained. It's unclear to me that it's appropriate to mention Map-Register and versions at all in this document; instead we might just note that 6834bs provides for version synchronization for the ETRs within a site. (If that's what it does; I haven't yet read it in detail.) Section 14 Just like it would if the destination EID was a unicast address. nit: this is a sentence fragment; I suggest joining to the previous sentence with a comma. Section 20.2 Maybe throw us a bone and include the string "draft-iannone-openlisp-implementation" in the [OPENLISP] entry? From nobody Thu Feb 7 08:29:51 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711A7129284; Thu, 7 Feb 2019 08:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.602 X-Spam-Level: X-Spam-Status: No, score=-12.602 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1FwHjj1iL0I; Thu, 7 Feb 2019 08:29:48 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BE981271FF; Thu, 7 Feb 2019 08:29:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2127; q=dns/txt; s=iport; t=1549556987; x=1550766587; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=NxsyyW80HLrx80OykV0pqxdEXajI2qDl/G7c/gjDWtY=; b=BYY0jt/PlHzsSOhU+MyGLBjRU1DZbKbPkPCetPfoUE4+x2CTTyvlVFlI HXcx3jjv8Jwnb1IW32tCcv0EaeDrwCwrUGUT89Mi7ja2CBUmi/D+ZzWDC 1TAvce8lCyfbAsIcAGT1HFMflq2plkhZfcJP2kcx7P4bVF1RiJgzLdARu g=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAAAlXFxc/xbLJq1kDgwBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVQCAQEBAQsBgzsyJ4QDiHmMeCV8mRAIAwEBhGwCg0o3Bg0?= =?us-ascii?q?BAwEBAgEBAm0ohUoBAQEDASNWBQsLGCoCAlcGE4MkAYF5CK0ogS+FRIRXD4J?= =?us-ascii?q?tiW2Bf4ERJwwTghc1iAoxgiYCiX+HAZIQCYRGjX8ZikqIC5kSgmoCBAYFAhS?= =?us-ascii?q?BXCJCgRQzGggbFWUBgkE+gWoXE41QPD4DMI56AQE?= X-IronPort-AV: E=Sophos; i="5.58,344,1544486400"; d="asc'?scan'208"; a="9881259" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Feb 2019 16:29:45 +0000 Received: from [10.61.203.34] ([10.61.203.34]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x17GTh2e014796 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Feb 2019 16:29:44 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_D379585D-F0B5-4989-97D2-79DF056918CE"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 7 Feb 2019 17:29:42 +0100 In-Reply-To: <154955015018.31108.12820143983477326611.idtracker@ietfa.amsl.com> Cc: The IESG , lisp-chairs@ietf.org, draft-ietf-lisp-rfc6830bis@ietf.org, lisp@ietf.org To: Benjamin Kaduk References: <154955015018.31108.12820143983477326611.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.102.3) X-Outbound-SMTP-Client: 10.61.203.34, [10.61.203.34] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-26: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 16:29:50 -0000 --Apple-Mail=_D379585D-F0B5-4989-97D2-79DF056918CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Just on this point: > On 7 Feb 2019, at 15:35, Benjamin Kaduk wrote: >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Section 3 still contains text: >=20 > EID-to-RLOC Database: The EID-to-RLOC Database is a global > distributed database that contains all known EID-Prefix-to-RLOC >=20 > that indicates that the mapping database is a single, global, = distributed > database; we had previously agreed that the target scope was much more > narrow. I could perhaps charitably assume that this instance was = missed as an > editing error because the phrase "global distributed database" spans a = line > break, but given that this specific instance was called out in my = previous > discuss position, it is fairly hard to do so. Funnily enough, I didn=E2=80=99t envision in LISP-NERD that there would = be just one. But it seems that this definition is the only reference to = the term in the document. Probably safe to remove, unless it is = normatively referenced elsewhere? Eliot --Apple-Mail=_D379585D-F0B5-4989-97D2-79DF056918CE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlxcXPYACgkQh7ZrRtnS ejNFDwgAmOMYG7PA2ZS+ZHvSf+8mBtHkpcwCU0oTjXgRpumOg3sB/pYx1d5mUCqt 6HxwUVaytB22aqolfk7RHi73TO0UH0iyQ7z8DXB7y3b0a/djmtUJ5ozbFBa5gUUS e6XwAwKmI6JEqkd4sz2hWnpZSUeteusUQyzqsMvJiQHEEZzD9cvl4Ms7vtcGeJ6B 6aCfEtjc1zXa+BWFhaqbeL4JA0HZveA84EfcgNGjFMfcEiT7XbJAAZf1qBKPojD3 hGVU1QUltw8HvKFwdfYjnkEKNpa7Bai2e2qdOGtS9fH+1TAecmu+S059X+7G6ixP S4T9xSj9S88kPyahSynDdt+pSu/Gzw== =kVZu -----END PGP SIGNATURE----- --Apple-Mail=_D379585D-F0B5-4989-97D2-79DF056918CE-- From nobody Thu Feb 7 16:14:55 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05FB130ED0; Thu, 7 Feb 2019 16:14:53 -0800 (PST) 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 SZkfpUDlVA8a; Thu, 7 Feb 2019 16:14:51 -0800 (PST) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 BBC111274D0; Thu, 7 Feb 2019 16:14:51 -0800 (PST) Received: by mail-pg1-x52a.google.com with SMTP id w7so724692pgp.13; Thu, 07 Feb 2019 16:14:51 -0800 (PST) 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=kU5WD4vCkJpSLlAP+o6vIpY3wfJWN+bwF/64TNv+L78=; b=eLnC+U+fLo3pciDf9IYRVn46hkrlUUj2dlBygENsyoBOwBndlc2K9/c1G97il1bdUe zYT5pIBooTZ3ex8GxmS+AmCCdsyYZRCNZs9yl6P2/sf1t7AsTXzeeE8PSauaZzFkdM/z jzdBB+66F7iKt5g/D2Tmu6JLBzy5/OOCVJLof43xd5Nu53iKRZFIM+qG5CxLquAe1uCG O83pfAcHd8jlBu/79Md26kx6UYsvuAaEeDRBImqYB2blbyC7P10LUQZTWh4as57hvD3G 8/9WN/Jzg25o4YfkfyXmYMPr/nV4GM1hcUJ+a/8pa1MC5PvsAhn4Gj1jfXfGF3NSmQZB L1UA== 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=kU5WD4vCkJpSLlAP+o6vIpY3wfJWN+bwF/64TNv+L78=; b=rGl9C0L/0f1dzeQ/TlbenmaNBGFW1Mktay08RqXy2x40nLxmWEjAIpomOwNAVTBSzP UHS0dZoPaXExIN1LLBxoc6kWLZXIifmXI37z4q7RiPAFFWBQsiqg04ZRgZ8Bynay5OZI 6nTTbWfk38B7HagdIrA5QIN164ANvDzU7sFS/T3v6BeV397J3RciEbZ7KzmkW5dJAelf gPkx41/1K+bpI/If1rubC6g2auL75SDsTbi9dmoS4tZjy67ezHANZ4savDgL85hO8XuY mrRPxMVI1P9gFpThF2JNnVDpmzsIyGnD/yFnv7kY0g16Nn4ChB6IgJaClorTEMRYZehN 9kUw== X-Gm-Message-State: AHQUAuZZjtxNpMrLy85fSC5yPyWhyY0VBQ9aOerEWRd4or7RMCs2Drtw KVtQENLfH565A30NbMaskbg= X-Google-Smtp-Source: AHgI3IafElaCWlfzcpoGBmE+vwkM8kZyxCEEGNq1w4l4gc933yY/thMnM7pErJQWEUBd0V7groWAAA== X-Received: by 2002:a62:6204:: with SMTP id w4mr19138014pfb.5.1549584891064; Thu, 07 Feb 2019 16:14:51 -0800 (PST) Received: from ?IPv6:2601:646:9600:e494:a990:6197:dc91:5bad? ([2601:646:9600:e494:a990:6197:dc91:5bad]) by smtp.gmail.com with ESMTPSA id v89sm395336pfk.12.2019.02.07.16.14.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Feb 2019 16:14:50 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Thu, 7 Feb 2019 16:14:49 -0800 Cc: IESG , "lisp@ietf.org list" , draft-ietf-lisp-rfc6833bis@ietf.org, draft-ietf-lisp-rfc6830bis@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <41F2EF71-BEBA-4205-893C-C0ED9A1CC462@gmail.com> References: To: Eric Rescorla X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Reviewing the updated LISP docs X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2019 00:14:54 -0000 Eric, just want to be clear on this one point. See below. > > S 5.5. > > > is being mapped from a multicast destination EID. > > > =20 > > > 5.5. EID-to-RLOC UDP Map-Reply Message > > > =20 > > > A Map-Reply returns an EID-Prefix with a prefix length that = is less > > > than or equal to the EID being requested. The EID being = requested is > >=20 > > How do I behave if I receive an EID-Prefix that is less than any of = my > > mappings. So, I might have mappings for 10.1.0.0/16 and 10.2.0.0/16 > > and someone asks me for 10.0.0.0/8? Also, when you talk about prefix > > length, I assume you mean the length fo the mask? >=20 > We had an extended back and forth on this. I still don't find the = document > very clear, and I'm not sure that this text is correct. Specifically, > consider the following example, where the MS has two mappings: >=20 > 10/8 -> ETR1 > 10.0.1/24 -> ETR2 > =20 > The Map-Request is for 10.1/16. In email, we agreed that you cannot = return > only the first mapping because that would implicitly over-claim. This = means > that you either supset one of your mappings or return both (I = understood > Dino to be saying you return both). However, the 10.0.1/24 mapping has > a longer prefix than the requested one, so that would seem to violate = this > text. With the above entries in the mapping system, a Map-Request fro = 10.1.0.0/16 gets returned the 10.0.0.0/8 entry. (1) A Map-Request for 10.0.1.1/32 returns only 10.0.1.0/24. (2) A Map-Request for 10.2.2.2/32 returns both 10.0.0.0/8 and = 10.0.1.0/24 (even though 10.2.2.2 is not more specific than = 10.0.1.0/24). (3) A Map-Request for 10.0.0.0/<8 (less than 8) returns an empty = RLOC-set. As I mentioned last night if a Map-Request matches an entry in the = mapping system and the mapping system has more specifics for that = matched prefix, then all more specifics are returned. The reason is for = when 10.0.1.1/32 is looked up in the ITR/RTR map-cache the /24 ETR2 is = used. The mapping system does not know what the ITR has cached so it must = return all more specifics. I hope this clears things up. Dino= From nobody Thu Feb 7 17:00:53 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6770C128B14; Thu, 7 Feb 2019 17:00:51 -0800 (PST) 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 fats0A9me-ZM; Thu, 7 Feb 2019 17:00:49 -0800 (PST) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 229AB1274D0; Thu, 7 Feb 2019 17:00:49 -0800 (PST) Received: by mail-pl1-x62a.google.com with SMTP id a14so837858plm.12; Thu, 07 Feb 2019 17:00:49 -0800 (PST) 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=VYoS1Fuz1dNnR4QSQfdPXaKiX7EZAzsikdMj6Y7Vb4k=; b=qY+qe2fCbAeHDfqU7WDxwhmzcUIsj1JeaxVY/gfb8/VFUnzejkd/fdHRd/cm/RqfVz ofxYDGkFQ6i1WfuMQh6ZhWmFKfZLtmxLVxbJR6Vng2oSsRIZd8vHTnpvv+fJVwx6n9gw NBpw7tENyHYDjuq1QbTPREAVcEOtb0vVN/mHmc3hmwMWi4fLJ9M7RWkcOAycBCamJc8Q SsWMTkntROJJIXW4RfpUT7qTClOfaRHF+B+YwjHlxqWC9htmRnoajN8huBM919x7eqtf ClWttyw3uM9h3WZp+UP9MxKV8g+cRr7l4dFa8/a/Fd3bfQ3R1tdnCmOAlzOpt6YP72p1 qXYg== 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=VYoS1Fuz1dNnR4QSQfdPXaKiX7EZAzsikdMj6Y7Vb4k=; b=pQoxDr8dmzx/TmktSc24OmmAOYA0Yz65yPwj3b8f6A4g8iw2kn4l5MQ3YFa+goMKpB BbC0QXWKEkJd/JD1paxDr3VsNE6xgWA+gp6H5l0ehhSCnU4VVmwHRD11lZzzknu7wzIE tZzxlrS0SHBbXN1NH6ZcTZ8T42s3lmPWLnM8ynDb7ABY33ZzdKsREahGelQXGIDQv87q 6Gl4uNCjR4Tcc/mrZGtDheFVzk6jeSRjsb5q8KmENRzhgxFR8B3eefVWxWYiBoUHfcsO YqxbbvxVTFgQslBCIVgx43MB0cIZdCsRPYbPXTrl3sjdQa6Vf8X03d+rxniRHbDqSKr5 XD4A== X-Gm-Message-State: AHQUAuZyhFndStNYnlwRgQmZFAPY26KC/PzwxCxi6/iTiMK2SmFJsLeR o1wK2spBWD9tGN/oAn4WR08= X-Google-Smtp-Source: AHgI3IaGwzjlJ5kVVVLbrEjTibm5Wvl7ZYtNknQ6MmiSHdo/kf8psO/zzsHV8yHLzUUri3fv5af/OA== X-Received: by 2002:a17:902:7044:: with SMTP id h4mr19602273plt.35.1549587648105; Thu, 07 Feb 2019 17:00:48 -0800 (PST) Received: from ?IPv6:2601:646:9600:e494:a990:6197:dc91:5bad? ([2601:646:9600:e494:a990:6197:dc91:5bad]) by smtp.gmail.com with ESMTPSA id g14sm148123pfg.27.2019.02.07.17.00.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Feb 2019 17:00:47 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Thu, 7 Feb 2019 17:00:46 -0800 Cc: "lisp@ietf.org list" , Luigi Iannone , lisp-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <154935838934.32279.15114530088216516753.idtracker@ietfa.amsl.com> To: Sharon Barkai X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] New Version Notification for draft-barkai-lisp-nexagon-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2019 01:00:52 -0000 This use-case can be solved by encoding a 64-bit H3 Hex-Tile identifier = as a Distinguished-Named EID and the RLOC record encodes the lat-long = with LCAF Geo-Coordinates encoding. This encoding, with the pubsub = draft, provides a solution that requires no new changes. Agree? And with a Geo-Prefix encoding you encode the size of the hexagonal grid = (it whould be spherical but close enough to an hexagon).=20 Speaking of spherical, is there a requirement to be 3 dimensional? The = LCAF Geo-Coordinate does encode Altitude with centimeter granularity. Dino > On Feb 5, 2019, at 5:01 AM, Sharon wrote: >=20 > Dear lispers,=20 >=20 > In recent years been discussing - with Dino, Fabio, Albert, Alberto.. = - the use of lisp to support a serverless-network design pattern. >=20 > In this pattern the EIDs are typically mobile highly functional = clients, communicating not with any specific server nor peer-to-peer but = rather with States embedded in the network. >=20 > =E2=80=9CTalking=E2=80=9D to a state typically invokes a virtual = network function at the state RLOC wrapping it with proper access = methods. >=20 > During past months in Fermi then Nexar our team has brought a specific = use case as above to production. An automotive application which will = greatly benefit from standardization - since it is inherently multi = vendor. >=20 > In this use case in-network states represent the geo-spatial hexagon = tiles forming our roads - lanes, shoulders, junctions. > The network hexagons are indexed using H3. >=20 > Moving EIDs communicating with moving HIDs invoke publish and = subscribe methods at the RLOC. Publish when vision&sensory clients = identify hazards snapped to small-hexagon-grid. Subscribe when clients = wish to be aware of beyond line-of-site spotted hazards, snapped to a = larger area hexagon grid. >=20 > Enclosed initial draft for the use-case. > Interested parties include - car makers, adas-cam makers, = municipalities-highwayAuth-gov, navigation-mapping vendors, = smart-infrastructure/lidar/active-led vendors. >=20 > Hope to present for discussion next ietf meeting, and requesting a = 10-15 min slot. >=20 > --szb > Cell: +972.53.2470068 > WhatsApp: +1.650.492.0794 >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Date: February 5, 2019 at 11:19:49 AM GMT+2 >> To: "Alberto Rodriguez-Natal" , "Ohad Serfaty" = , "Fabio Maino" , "Albert = Cabellos-Aparicio" , "Sharon Barkai" = >> Subject: New Version Notification for = draft-barkai-lisp-nexagon-00.txt >>=20 >>=20 >> A new version of I-D, draft-barkai-lisp-nexagon-00.txt >> has been successfully submitted by Sharon Barkai and posted to the >> IETF repository. >>=20 >> Name: draft-barkai-lisp-nexagon >> Revision: 00 >> Title: Distributed Geo-Spatial LISP Blackboard for Automotive >> Document date: 2019-02-04 >> Group: Individual Submission >> Pages: 7 >> URL: = https://www.ietf.org/internet-drafts/draft-barkai-lisp-nexagon-00.txt >> Status: = https://datatracker.ietf.org/doc/draft-barkai-lisp-nexagon/ >> Htmlized: = https://tools.ietf.org/html/draft-barkai-lisp-nexagon-00 >> Htmlized: = https://datatracker..ietf.org/doc/html/draft-barkai-lisp-nexagon >>=20 >>=20 >> Abstract: >> This document specifies the use of LISP Blackboard for distributed >> Geo-Spatial Publish/Subscribe automotive applications. >>=20 >>=20 >>=20 >>=20 >> 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. >>=20 >> The IETF Secretariat >>=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Fri Feb 8 03:02:54 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B132D128D52 for ; Fri, 8 Feb 2019 03:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-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 vkuDdBwLGyot for ; Fri, 8 Feb 2019 03:02:51 -0800 (PST) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 24C7F12D4F0 for ; Fri, 8 Feb 2019 03:02:49 -0800 (PST) Received: by mail-wm1-x335.google.com with SMTP id t200so2961660wmt.0 for ; Fri, 08 Feb 2019 03:02:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Vh1uC+Cx7619wja3z631/w3T2ab5LcOn30TAnipMuqc=; b=lw6EzhbpKgJvPDq8RQd9r3Ev91kTk7uQhNE0507N4KdQ6+gmkVGiMB+wDZHJHgDHId 3UU6KZqo9oA0SjbqhcDM89EF3cCe+064C15e89fZgare+P6r6EBzV39HzKcm0txdiV7M 5yZd1zl5FZDu0o6nTy3pKos/Eex2I+wHC3MfYK0MMY2frC/LOccMiF1dvzhMy5LHlny/ S69bqLZ/8FucXfQISmMfp6hxGFKHmOz4JQymFErP9R3u/TRDCLPe/dEc3TzNdw7Gy61k XmM7SftYjF0ugEznEJAa8J0G4ZLIACNz9E0pvOCII6oJHXE9pEkv3Aw1O9vcmLqvWkCr aZ2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Vh1uC+Cx7619wja3z631/w3T2ab5LcOn30TAnipMuqc=; b=lQnfMPh4ht7OL8grmIgMIeEeDNfnZgJy9WCD7bVVVP9htG2L3zKZ84Rta0nsoUaqdE 96LycxLk8jAS4GF5S+DLzdN8cvOJAnhW5uqW54hOEv8lXZryLYajrUgne1V51z8h6fda ol9Vh/uMuRAPnCNZKg4sdHEKRrfrJbTf58/W3GfRQ+rF++rYYIuvQWDC6bhwaO34+NDC U/uaGhxxMqnhSgWgvuusze+HNBqT7VJKEG8f3Bd8p23MvVmIuXaMqIa2pm9/emtlWpRQ 94aubqMXDNXvMMJA38FsABkF0PMZMyW6c5ljoFBb5f1W94sqIlLVzYldCRo0id0JG2lv HEbA== X-Gm-Message-State: AHQUAub66uHVwePFGnPXmCY6piOXXOf3FNlO/YInwOvX4Dz3PaAaMTRM zgd6XJc1g+qZQ8HrWGmfm/Nvaw== X-Google-Smtp-Source: AHgI3IaJi6pZQ2/wMey8l9ti30cPgtfPs8WgBc1OkUWe+n0XSPqA9ARnfgECR1AOE93A3CduDaN9wA== X-Received: by 2002:a1c:be04:: with SMTP id o4mr2295115wmf.19.1549623767074; Fri, 08 Feb 2019 03:02:47 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:39c7:18fc:e9da:ab6a? ([2001:660:330f:a4:39c7:18fc:e9da:ab6a]) by smtp.gmail.com with ESMTPSA id p5sm996358wmh.16.2019.02.08.03.02.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Feb 2019 03:02:45 -0800 (PST) From: Luigi Iannone Message-Id: <06FD8233-1E62-4664-833C-0FC31E1B3864@gigix.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_EA1BD877-BED1-4B98-826B-FC6124174818" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 8 Feb 2019 12:02:48 +0100 In-Reply-To: Cc: IESG , "lisp@ietf.org list" , draft-ietf-lisp-rfc6833bis@ietf.org, draft-ietf-lisp-rfc6830bis@ietf.org To: Eric Rescorla References: X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lisp] Reviewing the updated LISP docs X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2019 11:02:53 -0000 --Apple-Mail=_EA1BD877-BED1-4B98-826B-FC6124174818 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Eric, just a quick comment on one point. > On 7 Feb 2019, at 14:40, Eric Rescorla wrote: >=20 > Now with LISP on the To: line >=20 > On Thu, Feb 7, 2019 at 5:37 AM Eric Rescorla > wrote: > I apologize for the length of this e-mail, but there's a lot to > go over. >=20 > I have gone over the responses to my DISCUSS on the LISP > documents as well as taken another look at LISP-SEC. I agree that a = number of the > issues I raised are resolved, and I note those below. However, > I believe that a number of issues remain. >=20 > First, as a procedural I do not think it's appropriate to approve two > documents (6830bis and 6833bis) which have critical security > dependencies on documents (LISP-SEC, Map-Version) which are not yet > before the IESG and therefore have contents which might change during > IETF-LC. We felt that would be better to hold those two documents back. On the = one hand, to double check that they are coherent to any change = introduced in the main specs (6830bis and 6833bis), before sending them = further. On the other hand, we wanted (may be wrongly) avoid to swamp = the IESG with LISP documents all at once. Even looking at the decision now, I thing it was reasonable. But let=E2=80=99s move forward=E2=80=A6 LISP-SEC is under WG LC.=20 Map-Versioning is on my to do lisp for a final check. I asked the = shepherd (Padma) to hold on few more days before submitting the writeup = and ask formally for publication. All of this to say that soon you will have more reading ;-) Ciao L. --Apple-Mail=_EA1BD877-BED1-4B98-826B-FC6124174818 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Eric,

just a quick comment = on one point.

On 7 Feb 2019, at 14:40, Eric Rescorla <ekr@rtfm.com> = wrote:

Now with LISP on the To: line

On Thu, Feb 7, 2019 at 5:37 AM Eric = Rescorla <ekr@rtfm.com> wrote:
I apologize for the length of this e-mail, but = there's a lot to
go over.

I = have gone over the responses to my DISCUSS on the LISP
documents as well as taken another look at = LISP-SEC. I agree that a number of the
issues I raised are = resolved, and I note those below. However,
I believe that = a number of issues remain.

First, as a = procedural I do not think it's appropriate to approve two
documents (6830bis and 6833bis) which have critical = security
dependencies on documents (LISP-SEC, Map-Version) = which are not yet
before the IESG and therefore have = contents which might change during
IETF-LC. =

We felt that would be better to hold those two = documents back. On the one hand, to double check that they are coherent = to any change introduced in the main specs (6830bis and 6833bis), before = sending them further. On the other hand, we wanted (may be wrongly) = avoid to swamp the IESG with LISP documents all at once.

Even looking at the decision now, I thing it was = reasonable.

But let=E2=80=99s move = forward=E2=80=A6

LISP-SEC is under = WG LC. 

Map-Versioning is on my = to do lisp for a final check. I asked the shepherd (Padma) to hold on = few more days before submitting the writeup and ask formally for = publication.

All of this to say that = soon you will have more reading ;-)

Ciao

L.

= --Apple-Mail=_EA1BD877-BED1-4B98-826B-FC6124174818-- From nobody Fri Feb 8 11:07:21 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5D1130E2F for ; Fri, 8 Feb 2019 11:07:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 uQdLJYty8_4V for ; Fri, 8 Feb 2019 11:07:16 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::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 3CE31130E8E for ; Fri, 8 Feb 2019 11:07:14 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id g11-v6so3939261ljk.3 for ; Fri, 08 Feb 2019 11:07:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TiRtqHkFmPM4g4V/kmvjSmPTTc7ypP/bhr0f0Cs1I+E=; b=mWFR9B4OKnOQY4uMS17E/AO1x56aNIn7PWEOBVjmjKsYW9xj1fU2kU+vm4uswscWZN 1h4xTYok050k8TT/z7G2zgpkSZ3OgUMUZUuqSDwU0UnGghJgKSDts9YLdBllo+UM7dBC /CVyYhMBOzf2pIxMvplgXF8m5ZsDSlSw4E6bFGVCgX0WqWg75OOmwusRfR48UTdDhNGy PKJl3aDdJh3QWEMeN9/LQoFJZmi52gln+FrwUZ+hGArmUWcwnihetku7J95bWKNQhLAE BfP9VYUQzU+AgTlM9xfxZKps5mLsCsJYt5yuVXuGiVX04PhwW6fQ3bt8RZvUFYLF2fS2 3r1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TiRtqHkFmPM4g4V/kmvjSmPTTc7ypP/bhr0f0Cs1I+E=; b=FnIXot0l3s+zeQ8JVJaMEchWaq9C7Dtw9gf9EOtGDYvTialDcrP1Z8Ct6/dUE2yctc J3sLCDAo8JEWVT5GVNvYnUO5TOmBJIwCO7pQfDZbmpP9i2SHDiF2pCq9b4rhY526cx8r 8NWGFgyKIB9MDodfKcoF6FTMn8wuKCKNLwB2TWdGqBKRmy5nOY6SgMzGTlzQdRXcqgLP GU9EC8z4Ba3DKN8VNgM+ry7+50HARFR7VCAE1gjSOorNTJohtx4g+mWu6kRA7lRq/NBn eG1HZkaQBBtQCwjs0o/P55GPhhDRnNU6fBoslblVhAZ5bmPpMJVZDaqK/Ggkr7ujKsq+ JsWQ== X-Gm-Message-State: AHQUAubSAlFDgfTfiWAGEHeLI4U5FfKSk90dZvQ7ovkuVjB3KEPWgsqU R2HJL892djrKf7bLDqSZ3hlXUY3qQC+Z4LCMgjVUXQ== X-Google-Smtp-Source: AHgI3IbpbI1CTm0Ec895Ezy/LalyQz9uxS49XPLLA6QXIJVJGczuQSyWMGWedwF8sMi/ZQ+kNMj8PdTfokVaNPkqwLs= X-Received: by 2002:a2e:a202:: with SMTP id h2-v6mr14267072ljm.72.1549652832153; Fri, 08 Feb 2019 11:07:12 -0800 (PST) MIME-Version: 1.0 References: <06FD8233-1E62-4664-833C-0FC31E1B3864@gigix.net> In-Reply-To: <06FD8233-1E62-4664-833C-0FC31E1B3864@gigix.net> From: Eric Rescorla Date: Fri, 8 Feb 2019 11:06:33 -0800 Message-ID: To: Luigi Iannone Cc: IESG , "lisp@ietf.org list" , draft-ietf-lisp-rfc6833bis@ietf.org, draft-ietf-lisp-rfc6830bis@ietf.org Content-Type: multipart/alternative; boundary="0000000000009616b9058166aa04" Archived-At: Subject: Re: [lisp] Reviewing the updated LISP docs X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2019 19:07:18 -0000 --0000000000009616b9058166aa04 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 8, 2019 at 3:02 AM Luigi Iannone wrote: > Hi Eric, > > just a quick comment on one point. > > On 7 Feb 2019, at 14:40, Eric Rescorla wrote: > > Now with LISP on the To: line > > On Thu, Feb 7, 2019 at 5:37 AM Eric Rescorla wrote: > >> I apologize for the length of this e-mail, but there's a lot to >> go over. >> >> I have gone over the responses to my DISCUSS on the LISP >> documents as well as taken another look at LISP-SEC. I agree that a >> number of the >> issues I raised are resolved, and I note those below. However, >> I believe that a number of issues remain. >> >> First, as a procedural I do not think it's appropriate to approve two >> documents (6830bis and 6833bis) which have critical security >> dependencies on documents (LISP-SEC, Map-Version) which are not yet >> before the IESG and therefore have contents which might change during >> IETF-LC. >> > > We felt that would be better to hold those two documents back. On the one > hand, to double check that they are coherent to any change introduced in > the main specs (6830bis and 6833bis), before sending them further. On the > other hand, we wanted (may be wrongly) avoid to swamp the IESG with LISP > documents all at once. > > Even looking at the decision now, I thing it was reasonable. > > But let=E2=80=99s move forward=E2=80=A6 > > LISP-SEC is under WG LC. > > Map-Versioning is on my to do lisp for a final check. I asked the shepher= d > (Padma) to hold on few more days before submitting the writeup and ask > formally for publication. > > All of this to say that soon you will have more reading ;-) > Thanks. -Ekr > Ciao > > L. > > --0000000000009616b9058166aa04 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Feb 8, 2019 at 3:02 AM Luigi = Iannone <ggx@gigix.net> wrote:
Hi Eric,

just a quick comme= nt on one point.

On 7 Feb 2019= , at 14:40, Eric Rescorla <ekr@rtfm.com> wrote:

Now with LISP on the To:= line

On Thu, Feb 7, 2019 at 5:37 AM Eric Rescorla <ekr@rtfm.com> wrote:
I apologize for the length of this e-mail, but there's a lot to
= go over.

I have gone over the responses to my DISCUSS on the LISP
documents as well as taken another look at LISP-SEC. I = agree that a number of the
issues I raised are resolved, and I note thos= e below. However,
I believe that a number of issues remain.

First= , as a procedural I do not think it's appropriate to approve two
doc= uments (6830bis and 6833bis) which have critical security
dependencies o= n documents (LISP-SEC, Map-Version) which are not yet
before the IESG an= d therefore have contents which might change during
IETF-LC.

We felt that wou= ld be better to hold those two documents back. On the one hand, to double c= heck that they are coherent to any change introduced in the main specs (683= 0bis and 6833bis), before sending them further. On the other hand, we wante= d (may be wrongly) avoid to swamp the IESG with LISP documents all at once.=

Even looking at the decision now, I thing it was = reasonable.

But let=E2=80=99s move forward=E2=80= =A6

LISP-SEC is under WG LC.=C2=A0

<= /div>
Map-Versioning is on my to do lisp for a final check. I asked the= shepherd (Padma) to hold on few more days before submitting the writeup an= d ask formally for publication.

All of this to say= that soon you will have more reading ;-)

Thanks.

-Ekr


Ciao

L.

--0000000000009616b9058166aa04-- From nobody Sat Feb 9 14:14:20 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9545C1293B1; Sat, 9 Feb 2019 14:14:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu 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 WvJR2XJhX4ul; Sat, 9 Feb 2019 14:14:15 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770122.outbound.protection.outlook.com [40.107.77.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9FDB12426A; Sat, 9 Feb 2019 14:14:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6XLjExbULcE0DAhWqPW8GQuAnEk/W1LF9cQJxwKr8Kw=; b=pab3kTuNVkDhGU7Hu/g+yMahiq1flkMcybWVTa2+m2OsxgqtvZiBS6Kngl96idxICUI0bzYZCZbABEqY354m4AUJrKh1Ehg2McpWr1uVQHQMGSy4+sxhhaX0ftv6jDIvI2r1KNNHQabUBTBYSneR8qnJayLVpCzBABGLnqwJILs= Received: from CY4PR01CA0005.prod.exchangelabs.com (2603:10b6:903:1f::15) by BN7PR01MB3748.prod.exchangelabs.com (2603:10b6:406:81::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.19; Sat, 9 Feb 2019 22:14:12 +0000 Received: from CO1NAM03FT050.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::208) by CY4PR01CA0005.outlook.office365.com (2603:10b6:903:1f::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.17 via Frontend Transport; Sat, 9 Feb 2019 22:14:12 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by CO1NAM03FT050.mail.protection.outlook.com (10.152.81.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.10 via Frontend Transport; Sat, 9 Feb 2019 22:14:11 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x19ME85i007883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 9 Feb 2019 17:14:10 -0500 Date: Sat, 9 Feb 2019 16:14:07 -0600 From: Benjamin Kaduk To: The IESG CC: , , , Message-ID: <20190209221334.GA23225@kduck.mit.edu> References: <154954743968.23471.9935733647283605722.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <154954743968.23471.9935733647283605722.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(39860400002)(136003)(346002)(376002)(2980300002)(199004)(189003)(305945005)(97756001)(246002)(786003)(186003)(54906003)(47776003)(46406003)(26005)(7696005)(316002)(6666004)(8936002)(88552002)(356004)(1076003)(2906002)(6916009)(8676002)(106002)(486006)(76176011)(55016002)(446003)(53416004)(956004)(26826003)(75432002)(23726003)(58126008)(336012)(16586007)(11346002)(14444005)(126002)(476003)(478600001)(104016004)(36906005)(86362001)(106466001)(50466002)(426003)(4326008)(33656002)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR01MB3748; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM03FT050; 1:L1GQm/uTMxLVbEwTlkJHZVYJE1PG11gnYtiLHNt2nri1UmDIKLWCYeL0hScBzFLp2Pa+ri6mTEbCYlXIcEc+PWFk3Rf4jrttvWLIrJScAOMXZqYOGvwYaxu28OoN4dkBTVtSLXcXlIfeXt/gK/kx6uRZMyk49913JhrXSMwOPB4= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9b02ec41-a4bc-4e71-76b1-08d68edbebb8 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4608076)(4709027)(2017052603328)(7153060); SRVR:BN7PR01MB3748; X-Microsoft-Exchange-Diagnostics: 1; BN7PR01MB3748; 3:+rp9yZY4tvRrZUtuPFuYQekmJHb7BqKit5fD5UOAmeJ655wAGmtoABiSeziF4Zvsi/oTzZIEUZAY6tHddd4c99Pn0D78cJPy/+s2FRMbGRKLxrWCr59yJ0YKP0e4neIulx9oneEZwqwp1BDcta01nokt7WmzTe9t5ZDYi7sk0TkMEIh6rAIpSVy2+mo4XHtekwTMtiTAisCabVU52DxIlblNL8VLGkZZcI+Ihd24cPipMg60HiyyCDa27lJW7dlybKg+DVZ/yR1UKtCfO5jw4+YIY3BBIHkSfUOLKLjo4CYyymCHebCiuS8aVakV2E/ayFSPEvS+56hHqYlDTCOWmPVTGfdMOvr0LJn4YCRD5nRQfYjk1FRJXtSIqAME1gCP; 25:yzjgOIk4WlG/EkC63oFDsrtZbP8R8tyMP8VR35VGQOhNqCeT5SmR+47BLyouqjj7AayNiGeyZozgAqGy4SD1+P5sctMgkXlF+n1V7vw7yd+d3qJIkObXsVi8hNeMI24Vzye6YCED08WfgPdQqIPkyvytOO9dYI5LDZJ/9lAfgPzPLrTZgK4InBso/gY4UaM5WW8MkazNDLSIaILWi2vRDOlRXBK0vmlj9+P7jpT8+lgaF3qOQU1wfyXlA5Jm574kpbVls0LSDQlERfV+Ucl8ujYUj4lpiNh7f8rup4Ic24IAQ+hshZ7aR87/rDEzlX7P0Ohs2WbL3vycR9YA/MNnGw== X-MS-TrafficTypeDiagnostic: BN7PR01MB3748: X-Microsoft-Exchange-Diagnostics: 1; BN7PR01MB3748; 31:Vn37cOgGeahEb04L59HPpvdX0b/huH8Oo/ve3DtVDPZ41viL7zYtxqFnvlJxQKqXCyd8tI+JwXrOIJY7cpbry19GQ/sD1inY4LYmbkESPaLMufCfMAfDihbHPZiUQRAP7rpNc1X/nRm92l5IBOR50UmVs0UnHUjI5JJLzK9hezRPVVi/MQEiOXGCMRI+9lD73cwlBkL/rbXlZ6VrDKNlKvwSSVko83tTi9VbzPhF7xg=; 20:tTAotBUZ2vBCwNoVwgPR4kygpf6ZxCg67IsrcIh2E38s5fDAvWv0TryVRKFUH2tCb+hESi04idlhbNK11rpN3dASswA+b7IvPfwf141zkxHkgeDmyRHmfVAtMZbaQ/g57zOj1vsd0OV5IrlvDFDgTgjDkTzhG1OCByS3Bpe06tE9byr2lEZBd2AgxGoOJ8SdL7ZpuxVOLoJPxVP0RoB9JtPaWpkwMCd9RE1tc05NbzllzXwoWBvCGu0qW79Njb3UeOW/0qAwVrKDCcUaa4h8muT2R6CEXL5++707OkWojBN5t5/ogaMoY8sKIlCy7Zirnve22W40Ir70shQlnjl3My7JJiPzvIyS7opEv7E3Rn83+0MWLKU5SKTmBflByOOjNUx8C0ToXF+9Ai5+6Cvi9C4hM221soEd99tSyYVpbvt8kF+UUMguac90IhSii6x5WoyisrCc61t+uCrbmgvXUNuS/oat8KwjCIC87yd27jpiDMEaGrX1CQJwsbx32vPS5MnpKZ/89dtIz3oqZFF0kFh47k11oeKeOr+ix1kYGkge58aq0yjwhwBPONRGGzfQATIdImV+lhmyj+4D+QMzW2O2Y6MfyQeHlo9gJFPSHQ4= X-Microsoft-Antispam-PRVS: X-Microsoft-Exchange-Diagnostics: 1; BN7PR01MB3748; 4:1RXuqYxsaZgdgK2+UcZhSnYKnrIMVhISWlfoQM62D68WmyYl2zfrALen2aezWIus6OUpz6hO3UqcwzUgSrFY1b3hZKDaXjv78RkDlrNIBDra8R6sNNuvIXpQNLYRUYlQE+PYLdnIlO1LzTVaU/bZcq7XLOlu091WibfNezeJ8M6Bf0z0OH24UFVwLP4aucaD1FdE9Hkwj2kJJmMV8cNTKMqa1TsjRLZcwxVJsxAd67fngTrkA0gfkKeWYOdydsGpdbrnPUd7M+CTA38dxinYYpPlKL69aXjj/lJarkLzWoh4NeKZIad1KBQukVIy4aa/ X-Forefront-PRVS: 09435FCA72 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN7PR01MB3748; 23:5SJu0RjjA8Ca7E3vWPJ2LIq9ML3fjuKN/5iWbk1P3?= =?us-ascii?Q?YxUi8zcV5c6zIdZsIwfTBfbcejGgFt+vLw0tEW0yOT5X4r1+4cT9BsccE0PW?= =?us-ascii?Q?LYjzmZaFz115BjJ/eYlckv+kV6HosjVJT2QuW4ZoLDPg6j8F2Jw38bpnvQMb?= =?us-ascii?Q?sZ8dpj+CK+OP7mL7j9Djpo5k95lMzP46era82tJlrSsZZ4SeHbJE+ctdJBDt?= =?us-ascii?Q?vwAKchE+ub2OIpExTef4boYDLl8XfHfdgPV/XfaiDyARXSqQpznqtY1NUTQr?= =?us-ascii?Q?M/2tX0b4rVyRbBnkhe0Y7FdJKYnyytc1uOn93LIiZHrzovfbsATyY4k5qw1F?= =?us-ascii?Q?gIrbmXLhDCVh1KFxDyDWmYh65V/uQ5vD/FsUDpzzYtR63c9YEpOrxSMDsxgI?= =?us-ascii?Q?dhEN2TfR075eqKU76Zn9enPIZ7skryFKFmXX4N+RTN3oY2oPwllk7Lyqc44w?= =?us-ascii?Q?yjvigrhYvl5rktP/Bj/kIC9L6qaWuiuYJ+vX6hFJs0KsX+Vew1jzhJyOPcjj?= =?us-ascii?Q?csMuYPb9kLzw+PfenGkmDyJVx/h9zEN1XoaQNVlV7zsT4Y/ug6ODgbQmjH0d?= =?us-ascii?Q?Dt6gvJ8+dT1emCCvaMrAZ9E38O1ISTNAfQmZp/b04GlCXivetd+HgVe3sx+1?= =?us-ascii?Q?teNGH2oq6gaduNm/SQnG+/aoM3vmz/DPgCxkx8RggOuV3W2WClNQTKaknt+1?= =?us-ascii?Q?dizfa+C3fkV0y7tHwt7MnXqkDPl6l/T3XfKFihDO3nInggagZtBLvHsmiZSh?= =?us-ascii?Q?kVDmnDso7CGXTk6+rhhuNxowR/BZcetphHMrX/X02tQaLr0xxODS2u91yIto?= =?us-ascii?Q?4bm5pOySJKDRZkP51rPS/KwDPv/WulCcT7dmgDCpKis6vsjF3D1N+DrOYGd8?= =?us-ascii?Q?CVF4ntEwnP01YURQoTI/aY7F8nWgEhB7COTcJQxm8/fdAePDm59WdghnZjDg?= =?us-ascii?Q?v1JW1ndvIzrcrqyUTuecLXANz9mus2BQvX5bK9l8VQzZSJNU+wN3okRo+kHC?= =?us-ascii?Q?nvalli48cQo+M1Csxk5W2Ei2+QohpOxtM6xqURLJy/L8O28GgN0dBoal+mFI?= =?us-ascii?Q?GWHblECZPfRehv88GUcmyGjtgnQk5nca7SdgWpKOBpzTN608OpdSJY1nCkmW?= =?us-ascii?Q?LCXArKM4MzLz7l6PK4V0isSt6EzMcRdX5yLfwjbeZCAWtH9rYlleOvAiT97z?= =?us-ascii?Q?qGLTonR61Tf3QI=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: S45S7Vic3z1xzuTsTASlOSZBI7YUsMUBWVABEvahxsabzQ6/Qx/pzYmP+9VoCk7X67XUGUIRms4DC87iadCHERks6G/usj6I36KA3HxNhnCkF+Vsr6tNs05NPO8q4xXfiFuCn8QWERU/X5Tp5kUYB+T6OWwtmZfwwMLLXj+SsTscl3Gx6wzA80xXLty5JFot2JfjHcxSzK9+DRJCzbg6/lKYazObyebX6kw+EVI0OQytwAPeq9NsGb2bxdjeinP3YpSKf01mjsG21PvMfzhYzQZSxR5nvS6OtMmovjVO3cJ4rakSXoLmG+uKMYCIFEsLPfAINqW2ioVFb0MQS/HVuh4XBO0e22uFPWpx472m2TSJPE4emLmywtxbDuF02gExaql+CeYucjIO9YaGTbfsVLRh0ObO+XFY9gWsHsSHhF4= X-Microsoft-Exchange-Diagnostics: 1; BN7PR01MB3748; 6:XPRtOGSiNrSj5o2Eqlx6/74HH4zc3uuckRWNu7evcDa2NH1DbZjVrv4b8L/cWbbf6nguRJ63UL+z7pXY1g/FWZEjXo9AvoL8Z4VPx24kuHmMCG9sAgSoptKBQ3c4kdJ/1KRtbE9RK5d97mKIknxygOM/Gh4Pvbbd6hiC8m/JGAg207r5dao8SAp6QKEFIG47955/4h7MipIDdqSPApDt/h0Ap03GDbOr0qYm+W/xC6FvlxJ83+oix1beUG8GDCWlWtFX1oskSlVCTnMVJpHSlPuYU14tYrWfO0LplypR1IYJIPGUcUhOW9D5o+rPBe3nA711Z2G15iuFFU2139tF5uZj4m6jm5qcKqlWtUwov9lCpAkcRQRPMH/yc29A/yYOtIkGHOsFGgK/rKDpUDRfjlXt3DixJzNP0ELctFkwOjk09SbAK8lSdsYS7qMr03/JYEKMiSsKrSx7RmjTS268DA==; 5:/KwGhG6XP95E+umRH8eQbkeAfuOiZokUdviaZW3ILZAxbi6iJGkxvAwOxj1KN5qGVBJ0rRPAWfIjixpU855EHG80MgS4V2htvaxK2b7wK42eus8vq9lFevMxtf5N2/ORPrJ5EfIa03HSfYinir5FVwAX04l3sGwC1XdHIy1T2mLz/uXcMy39l47DohtNSPrRwQFhakZ6+RwBNvhgJZj2ZA==; 7:AzNMazVnVJjgoW83RGbtHaovmdb+oMELWCTYjGGclSeV/bhqgI+sWAcABQE0F7IdykWLAgV8oInxyzTYRHbfu3L6NPcX8GLjwbl1xRPgFGnRhOasbiG/e6nBukgdV2KwswuePZvR1/lQo6I85gzsPQ== X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Feb 2019 22:14:11.9067 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9b02ec41-a4bc-4e71-76b1-08d68edbebb8 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR01MB3748 Archived-At: Subject: [lisp] incremental transition to LISP-SEC (was Re: Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6833bis-24: (with DISCUSS and COMMENT)) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2019 22:14:18 -0000 Splitting off a sub-thread for one fairly narrow point that AFAICT needs further discussion to clarify the path forward: On Thu, Feb 07, 2019 at 05:50:39AM -0800, Benjamin Kaduk wrote: > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > [...] > > 3. LISP-SEC [I-D.ietf-lisp-sec] MUST be implemented. Network > operartors should carefully weight how the LISP-SEC threat model > applies to their particular use case or deployment. If they > decide to ignore a particular recommendation, they should make > sure the risk associated with the corresponding threats is well > understood. > > I'm concerned enough about the risk of having a "ITR requests lisp-sec but > ETR didn't use it" case that causes complete breakage, that I want to talk > about this a bit more. We currently in this document say that lisp-sec is > mandatory to implement (which presumably covers at least ITRs, ETRs, > Map-Resolvers, and Map-Servers). LISP-SEC itself says that "and ETR that > supports LISP-SEC MUST set the S bit in its Map-Register messages". Is it > possible that an ETR might "implement" but then not "support" LISP-SEC? If > so, then we should consider the possibility that we need an authenticated > signal (from the mapping system to the ITR) that downgrading from lisp-sec > is allowed. There seem to be several possibilities for how one might > construct such a signal; two that came to mind to me would be (1) to define a > new ACT value for "repeat without lisp-sec" that could be returned as a > negative Map-Response directly from the mapping system wherever the mapping > system is able to discern that the ETR in question does not support > lisp-sec (I don't actually know if this could happen at Map-Resolver or > would need to be delayed until the final Map-Server) and (2) to have an > optional Map-Request field that the ETR is required to copy unchanged to > the Map-Reply; this could then include a message HMAC'd in the ITR-OTK that > indicates lisp-sec non-support and binds to the nonce in the request. > Whether these are workable ideas seems to depend on aspects of the mapping > system to which I cannot speak. In terms of some background assumptions I've been making (that of course could be false, so I'm trying to make them explicit), I am assuming that many or most current LISP deployments do not utilize LISP-SEC at runtime. It's less clear to me how many deployments/implementations simply do not have LISP-SEC capabilities at all, or how easy it is to get software/firmware updates to the needed devices. Regardless, if there are existing RFC 6833 deployments that want to migrate to 6833bis when it is finalized, we should consider what steps would be needed to safely deploy LISP-SEC without disruption. In particular, it seems a useful goal to try to get the security benefit of LISP-SEC for those machines/sites that have LISP-SEC capability without waiting for the entire administrative domain's deployment to get updated software/firmware, which I assume is at least a 5-year lead time in many sites. Given that at this point my analyses are mostly treating the mapping system as something of a closed "magic box" that takes Map-Requests as input and emits them to the appropriate ETRs (or internal proxy function), I'm forced to conclude that any incremental update to using LISP-SEC will inherently require the entire mapping system to upgrade first, before any concrete usage of LISP-SEC should be expected. Hopefully that's less of a burden than upgrading entire deployments, since the mapping system is a more contained set of devices and does not need to handle data-plane levels of traffic. Once that's done, though, we still have the question of "which ETRs are updated to be registering themselves as LISP-SEC-capable?". For any given ITR/ETR pair, if both are LISP-SEC capable, we want them to be using LISP-SEC, while still allowing traffic if one or both are not LISP-SEC capable. If the ITR is not capable, this is easy, as the Map-Request will never attempt to use LISP-SEC. But if the ITR is capable and the ETR is not, the ITR is going to either attempt to use LISP-SEC for all Map-Requests or need some out-of-band knowledge of whether the target ETR is capabable. Now, the whole point of the mapping system is that the ITR doesn't know what ETR it's going to talk to when it sends the Map-Request, so this "out-of-band" setup seems pretty hard to fulfil. My current best thought (not expected to be perfect) in this scenario is that the ITR that is LISP-SEC capable (and configured to use it, I suppose) will always try to use LISP-SEC, but needs an authenticated signal from the mapping system that the ETR it's being mapped to is not LISP-SEC-capable, and it should try again without LISP-SEC. This signal needs to be authenticated not just for security reasons (though an insecure downgrade would render LISP-SEC useless against an active attacker until the entire deployment disabled non-LISP-SEC exchanges), but also for performance concerns. As currently specified, the Map-Server that gets a LISP-SEC Map-Request but is going to forward it to an ETR that did not register as LISP-SEC capable is going to repackage the Map-Request into a non-LISP-SEC Map-Request to send to the ETR in question. That ETR will produce a normal Map-Reply, that the ITR will proceed to drop without processing, since it does not use LISP-SEC. IIUC, that leaves the ITR in "wait to timeout" territory, which is a pretty lousy situation to be in. I know there are only a couple values left for ACT values, but it seems that this may be a big enough issue to justify allocating one for "retry with downgrade", so that the final Map-Server can send a negative Map-Reply that does use LISP-SEC, and the ITR can have this authenticated signal that the destination ETR is not LISP-SEC capable at the moment. There are of course other ways to generate an authenticated downgrade signal, but the only other ones I've been able to come up with seem less architecturally pleasing (and may not in fact work when the destination ETR is running original RFC 6833 code). I'm interested in hearing what other people think about this scenario and proposed remediation. -Benjamin From nobody Fri Feb 15 05:37:03 2019 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BECE41275F3; Fri, 15 Feb 2019 05:37:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <155023782171.4600.6092210203123334749@ietfa.amsl.com> Date: Fri, 15 Feb 2019 05:37:01 -0800 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-6834bis-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 13:37:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol WG of the IETF. Title : Locator/ID Separation Protocol (LISP) Map-Versioning Authors : Luigi Iannone Damien Saucez Olivier Bonaventure Filename : draft-ietf-lisp-6834bis-03.txt Pages : 19 Date : 2019-02-15 Abstract: This document describes the LISP (Locator/ID Separation Protocol) Map-Versioning mechanism, which provides in-packet information about Endpoint ID to Routing Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and the transport of such a version number in the LISP-specific header of LISP-encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is optional and transparent to implementations not supporting this feature, since in the LISP- specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support or do not want to use the mechanism. This document obsoletes RFC 6834 "Locator/ID Separation Protocol (LISP) Map-Versioning", which is the initial experimental specifications of the mechanisms updated by this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-6834bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-6834bis-03 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-6834bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-6834bis-03 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 18 11:35:54 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75C412D4F0; Mon, 18 Feb 2019 11:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_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 Kqvt9V5H0vzh; Mon, 18 Feb 2019 11:35:39 -0800 (PST) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::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 E749B130E68; Mon, 18 Feb 2019 11:35:38 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id l5so11949487lje.1; Mon, 18 Feb 2019 11:35:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8VzOfZ3IPng6YY8WaGFT8fBoloZp5uEWugHbBptqlag=; b=e2OhBmWE+QzvM5SlWzoSqn3lgZkUJtRuVh0oBsmMz7PppzR3StSlaWXGttEGY0uj4h G3qy5TR0WELjC5C5qW7wExaP3zQqZEsJqhKo50y+wUpRq7cjsnYZLSt+C68tuEivAM7m 2Eu2WZ1iX9QAi7DCUgW3mzvhWFZhI/bpHXtObVNGD6wQKPbYtlnLVItdqeHNWSuqMB0c LMiXSVpsArrg1DSKjgYwBqZf74C8HjejOVm5+UltKbozjHYCEbKzFJ93+7UdVYIfmEQk caw83ojK43AJnsDXLTg/JnLlgs4b3JGmKA5JTFXMVK41F3JsltIZE31qclLjYEVscnW/ MXSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8VzOfZ3IPng6YY8WaGFT8fBoloZp5uEWugHbBptqlag=; b=dnGC1bn3CdR6tpZlqwXMCqvickzsjtGPXPirBJrKu8zj1hDZf2Dtefs23olyc1REnz orPkeeNLREEjzMXBJMM+xbn31EcyZPeg6moWhDBpitfaTbiN2eRQWvoDZbqiFz8qGwVR 3Id8+TnZICwRdbzD+C/bdDpj23vvVa//0W55Uh8MQIE/NjagOGWZvw2Fsp6WCl95tbei g2h+cSzuDA51a55bBSil43mdRLsiBqvxebHmfK0cAS3sAvuIMnhSm+HWT5++4zlsSsnE K/Pgymp5Vr188ypdMXmzeKtcVuWMl/nPhNeaPJnhep6LpkoJ6AlWhoh3B5lNFi6UKAkn Z3cQ== X-Gm-Message-State: AHQUAuagonvMuE9dSYySzJecfzOtEzJOT3+h95pqi87pWqFW0fYKfTW9 QngCXJnX9x0bkMrf0r7FqchuwFZu06oesmpr8J0= X-Google-Smtp-Source: AHgI3IZjvMsWlU93Jh8i5xZPu+c3Itpxj+Wq6TyhZ2jaVGMWDLcRQ0GVgZKsEu5+kSnFUX/cyFaeaqylbt/UDmnMmAw= X-Received: by 2002:a2e:7202:: with SMTP id n2mr4860736ljc.28.1550518536820; Mon, 18 Feb 2019 11:35:36 -0800 (PST) MIME-Version: 1.0 References: <153667812809.16741.10796738054406466412.idtracker@ietfa.amsl.com> In-Reply-To: <153667812809.16741.10796738054406466412.idtracker@ietfa.amsl.com> From: Albert Cabellos Date: Mon, 18 Feb 2019 20:35:25 +0100 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: The IESG , lisp-chairs@ietf.org, "lisp@ietf.org list" , draft-ietf-lisp-rfc6833bis@ietf.org Content-Type: multipart/alternative; boundary="0000000000009adbee0582303abd" Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6833bis-13=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 19:35:45 -0000 --0000000000009adbee0582303abd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mirja Thank you very much for your comments and getting back to us again. We have been discussing them internally and you can find below specific proposed changes on the document that hopefully address them. Please let me know if you agree with them, once this is finished I=C2=B4ll = send a similar reply for your COMMENTS. Once all the comments are done I=C2=B4ll= send a diff for your review. On Tue, Sep 11, 2018 at 5:02 PM Mirja K=C3=BChlewind = wrote: > > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-lisp-rfc6833bis-13: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > 1) Versioning and backward compatibility > > Section 5.2 says: "Support for requesting multiple EIDs in a single Map-Request > message will be specified in a future version of the protocol." > However, there is no versioning mechanism for this protocol specified. How is > versioning supposed to work? > > Further given there is no new version, I wonder if the changes as outlined in > section 10 are all backward-compatible? Especially for the introduction of the > Message-Notify-Ack message, I guess there is no problem if a server sends it, > however, as the sender of the Message-Notify message might not know if th= e > other end supports sending of the Message-Notify-Ack it can't rely on it. This > should be further discussed in the doc! Or is there another strategy to achieve > backward compatibility? > There is no support for requesting multiple EID and none of the use-cases have this requirement. I suggest to remove the text. > > 2) Size and MTU > > As outlined in the TSV-ART review (Thanks Colin!) this document does not > discuss fragmentation or Path MTU discovery. RFC8085 recommends to either > perform Path MTU discovery or limit the message to 576 bytes for IPv4 or 1280 > bytes for IPv6 (minus any static header). As this seems to be an appropriate > size for LISP messages, I would recommend this approach. Relying on IP > fragmentation (as indicated in the reply to the TSV-ART review) is not > recommended by RFC8085 as this would lead to IP packet without a UDP header, in > the case of LISP, which can cause problem and loss when NATs are involved. In > any case the chosen approach needs to be further discussed in the doc. > RFC8085 states that: Although most UDP applications are expected to follow these guidelines, there do exist valid reasons why a specific application may decide not to follow a given guideline. In such cases, it is RECOMMENDED that application designers cite the respective section(s) of this document in the technical specification of their application or protocol and explain their rationale for their design choice. Our rationale is the following one, I suggest to include it on the spec: LISP is expected to be deployed by cooperating entities communicating over underlays. Deployers are expected to set the MTU according to the specific deployment guideline to prevent fragmentation. For deployments not aware of the underlay restrictions on path MTU, it is RECOMMENDED to default to the guidelines outlined in RFC8085. > 3) Rate-limiting and congestion control > I suggest to state the following rate-limiters, as specified by RFC8085: Map-Requests MUST be rate-limited, it is RECOMMENDED that a Map-Request for the same EID-Prefix be sent no more than one packets per 3 seconds. Map-Reply and SMR MUST be rate-limited, it is RECOMMENDED that a Map-Request for the same EID-Prefix be sent no more than one packets per 3 seconds to the same requesting router. Map-Register messages are sent periodically from an ETR to a Map-Server with a suggested interval between messages of one minute, MUST not be sent more than one packet per 3 seconds. Additional clarifications below: > > Sec 5.3: "Map-Requests MUST be rate-limited. It is RECOMMENDED that a Map- > Request for the same EID-Prefix be sent no more than once per second." > As already noted by the TSV-ART review (Thanks Colin!), RFC8085 actually > recommends to not send more the one packet per 3 seconds, and that is a > restriction for all traffic not on a per-receiver base, or implement congestion > control. This limit is meant to not only protect the receiver but also th= e > network from overloading. Why do you use a smaller interval here? Also if > (appropriate) rate limiting is used, this should either be a MUST or more > explanation when it is okay to use a smaller rate limit should be provided. > However, after all, I don't think you those the right approach here for rate > limiting. A Map-Request is always expected to be followed by some reply. For > these kind of communication pattern, RFC8085 recommends to limit the number of > outstanding requests to 1 (see sec 3.1.1 of RFC8085 recommending one packet per > RTT), also for all traffic and not only per receiver. However, this would also > require to implement some simple mechanism to detect a message as lost (see > also further below in point 4). > > Similarly I'm not sure about the intent of this requirement in section 5.5: > "Map-Replies SHOULD be sent for an EID-Prefix no more often than once > per second to the same requesting router. " > My understanding is that Replies are only sent when a request is received. Why > is this additional rate limit needed? Again if used it should be 3 seconds for > all traffic to be inline with RFC8085. Also again, why is that not a MUST= ? > Further recommendation are needed here. > > Further section 6.1 say "Both the SMR sender and the Map-Request responder MUST > rate-limit > these messages. Rate-limiting can be implemented as a global rate- > limiter or one rate-limiter per SMR destination." > This seems to be the same rate limit as mention above, or not...? It woul= d > probably make sense to rate limit the SMR even further. Please clarify an= d > provide more guidance, e.g. what should the value of a potential additional > rate limit for SMR be? > > Respectively the following sentence in section 6.1 is also unclear: > "The remote ITR MUST rate-limit the Map-Request until it gets a Map-Reply= " > Why is the rate-limit as currently proposed depend on the fact if a Map-Reply > is received? Is the ITR supposed to retransmit the Map-Request...? > The reason is that an attacker can forge Map-Requests. > > And finally the Map-Register, Map-Notify and Map-Notify-Ack messages does not > seem to have any rate-limits. Recommendations inline with RFC8085 should be > provided for the total traffic and not only for a few message types. Again, > Map-Notify and Map-Notify-Ack messages should be send only once per RTT a= s > there is a feedback mechanism. > The RTT between the xTR and Map-Server and Map-Resolver can be very small since they are typically deployed within the same network. > > For Map-Register sec 8.2 say: "Map-Register messages are sent periodically from > an ETR to a Map- > Server with a suggested interval between messages of one minute." > However, this a rather a low bound than an upper bound. A required (MUST) rate > limit is still needed. > > 4) Loss detection and retransmission > > As also mention by the TSV-ART review (Once more thanks to Colin!), this spec > has an ACK mechanism for Map-Requests and now also for Map-Notify, however, it > does not specify what to do if the ACK is not received (loss detection an= d > retransmission scheduling). This makes the spec incomplete and needs to b= e > further specified in the doc (and also has a relation to the point 3 above of > course). > I suggest to add the following sentence: After sending a Map-Register, if a Map-Notify-Ack is not received after 1 second the transmitter MUST re-transmit the original Map-Register with an exponential backoff, the maximum backoff is 1 minute. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Further comments: > > 1) The example given in 5.5 should probably used IPv6 addresses and use the IP > address space that is reserved for documentation purposes. > > 2) I find the security requirements in this doc very unsatisfying. Most > important the doc requires the support of authentication mechanism but not the > use of it. I would like to see more clear MUST requirements here. Further= , > today and at this stage of the protocol (moving from exp to PS) I find it not > acceptable anymore to have certain security feature as optional and outsourced > into a different work-in-process draft. However, I leave further discussion to > the SEC ADs. > > 3) Given the following statement: > "Note that while this document assumes a LISP-ALT database mapping > infrastructure to illustrate certain aspects of Map-Server and Map- > Resolver operation..." > it seems that RFC6836 should be a normative reference, as it might not be > possible to understand all details explained in this doc with knowing ALT= . > > 4) Further I would also think that I-D.ietf-lisp-mn and I-D.ietf-lisp-pubsub > should be normative references as the meaning of the respective bits it not > further specified in this doc. Or can these bits just be ignored if > I-D.ietf-lisp-mn and I-D.ietf-lisp-pubsub are not implemented? If so that > should be stated. > > Clarification questions: > 1) Sec 5.3.: > "For the initial case, the destination IP > address used for the Map-Request is the data packet's destination > address (i.e., the destination EID) that had a mapping cache lookup > failure." > Does that mean that the Map-Request needs to use the IPv4 or IPv6 depending on > the IP version used by the initial message from the EID. Is that always the > case or just for this initial message? I would assume that for all other cases > this is actually independent...? Because otherwise there would be a constraint > on what needs to be requested. I would like t see further clarification about > this in the doc. > > 2) In section 5.3: "The ITR MAY include all locally > configured Locators in this list or just provide one locator address > from each address family it supports." > Would it make sense to include a SHOULD requirement to at least the address > family that is used to send the Request is included (to increase chance t= o > enable a communication/get a reply)...? > > 3) Sec 5.4: "If all Weights for a Locator-Set are equal, > the receiver of the Map-Reply will decide how to load-split the > traffic. " > Shouldn't the receiver in this case split the traffic equally? Otherwise how > would you signal that the traffic should be split equally? Maybe use all zero > instead to let the receiver decide...? > > 4) sec 6.1: "When an ITR receives an SMR-based Map-Request for which it does not > have a cached mapping for the EID in the SMR message, it may not send > an SMR-invoked Map-Request." > I guess this should be normative and probably also a MUST NOT or at least > SHOULD NOT. > > 5) Section 7 seems to imply that if it is detected that no route is available, > the ITR should basically do nothing and just drop any incoming packets for that > ETR. Would it make sense for incremental deployability, to just forward the > packet to the IP address of the EID instead...? This way the source host would > not benefit in mobility cases but still gets connectivity otherwise. Or is that > anyway not the implication? If that is the case, that should be further > clarified in the doc. > > 6) Section 8.2 says: "Note that the Map-Notify message > is sent to UDP destination port 4342, not to the source port > specified in the original Map-Register message." > Actually why is that? > > Some minor editorial comments: > > 1) First sentence in intro: the pointer to ietf-lisp-introduction as currently > introduced, makes this reference look very normative: "The Locator/ID > Separation Protocol [I-D.ietf-lisp-introduction] and [I-D.ietf-lisp-rfc6830bis] > specifies..." I would recommend the following wording: "The Locator/ID > Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see also > [I-D.ietf-lisp-introduction]) specifies..." > > 2) Also in intro: Given that 6830bis is a normative reference "LISP RFC > 6830bis" should be replaced with the new RFC number in the text. This should be > noted to the RFC editor; probably this is more obvious if RFCXXX is used > instead. > > 3) Sec 5.4: "...for another way the R-bit MAY be used." > This looks like a lower case may would be more appropriate. > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --0000000000009adbee0582303abd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mirja

Thank you very much for your comments and = getting back to us again. We have been discussing them internally and you c= an find below specific proposed changes on the document that hopefully addr= ess them.

Please let me know if you agree with them, once this is fi= nished I=C2=B4ll send a similar reply for your COMMENTS. Once all the comme= nts are done I=C2=B4ll send a diff for your review.

On Tue, Sep 11, = 2018 at 5:02 PM Mirja K=C3=BChlewind <ietf@kuehlewind.net> wrote:
>
> Mirja K=C3=BChlewin= d has entered the following ballot position for
> draft-ietf-lisp-rfc= 6833bis-13: Discuss
>
> When responding, please keep the subjec= t line intact and reply to all
> email addresses included in the To a= nd CC lines. (Feel free to cut this
> introductory paragraph, however= .)
>
>
> Please refer to https://www.ietf.org/iesg/statement/d= iscuss-criteria.html
> for more information about IESG DISCUSS an= d COMMENT positions.
>
>
> The document, along with other= ballot positions, can be found here:
> https://datatracker.ietf.org/do= c/draft-ietf-lisp-rfc6833bis/
>
>
>
> ---------= -------------------------------------------------------------
> DISCU= SS:
> ---------------------------------------------------------------= -------
>
> 1) Versioning and backward compatibility
>> Section 5.2 says: "Support for requesting multiple EIDs in a sin= gle Map-Request
> =C2=A0 =C2=A0 =C2=A0 message will be specified in a= future version of the protocol."
> However, there is no version= ing mechanism for this protocol specified. How is
> versioning suppos= ed to work?
>
> Further given there is no new version, I wonder= if the changes as outlined in
> section 10 are all backward-compatib= le? Especially for the introduction of the
> Message-Notify-Ack messa= ge, I guess there is no problem if a server sends it,
> however, as t= he sender of the Message-Notify message might not know if the
> other= end supports sending of the Message-Notify-Ack it can't rely on it. Th= is
> should be further discussed in the doc! Or is there another stra= tegy to achieve
> backward compatibility?
>

There is no= support for requesting multiple EID and none of the use-cases have this re= quirement. I suggest to remove the text.
=C2=A0
>
> 2) Size = and MTU
>
> As outlined in the TSV-ART review (Thanks Colin!) t= his document does not
> discuss fragmentation or Path MTU discovery. = RFC8085 recommends to either
> perform Path MTU discovery or limit th= e message to 576 bytes for IPv4 or 1280
> bytes for IPv6 (minus any s= tatic header). As this seems to be an appropriate
> size for LISP mes= sages, I would recommend this approach. Relying on IP
> fragmentation= (as indicated in the reply to the TSV-ART review) is not
> recommend= ed by RFC8085 as this would lead to IP packet without a UDP header, in
&= gt; the case of LISP, which can cause problem and loss when NATs are involv= ed. In
> any case the chosen approach needs to be further discussed i= n the doc.
>

RFC8085 states that:

Although most UDP app= lications are expected to follow these guidelines, there do=C2=A0exist vali= d reasons why a specific application may decide not to follow a given guide= line.=C2=A0 In such cases, it is RECOMMENDED that application designers cit= e the respective section(s) of this document in the technical specification= of their application or protocol and explain their rationale for their des= ign choice.
=C2=A0
Our rationale is the following= one, I suggest to include it on the spec:

LISP is expected to be = deployed by cooperating entities communicating over underlays. Deployers ar= e expected to set the MTU according to the specific deployment guideline to= prevent fragmentation. For deployments not aware of the underlay restricti= ons on path MTU, it is RECOMMENDED to default to the guidelines outlined in= RFC8085.

> 3) Rate-limiting and congestion = control
>

I suggest to state the following rate-limiters, as s= pecified by RFC8085:

Map-Requests MUST be rate-limited, it is RECOMM= ENDED that a Map-Request for the same EID-Prefix be sent no more than one p= ackets per 3 seconds.

Map-Reply and SMR MUST be ra= te-limited, it is RECOMMENDED that a Map-Request for the same EID-Prefix be= sent no more than one packets per 3 seconds to the same requesting router.=

Map-Register messages are sent periodically from = an ETR to a Map-Server with a suggested interval between messages of one mi= nute, MUST not be sent more than one packet per 3 seconds.

Additional clarifications below:
=C2=A0
>
> Sec 5= .3: "Map-Requests MUST be rate-limited.=C2=A0 It is RECOMMENDED that a= Map-
> =C2=A0 =C2=A0Request for the same EID-Prefix be sent no more = than once per second."
> As already noted by the TSV-ART review = (Thanks Colin!), RFC8085 actually
> recommends to not send more the o= ne packet per 3 seconds, and that is a
> restriction for all traffic = not on a per-receiver base, or implement congestion
> control. This l= imit is meant to not only protect the receiver but also the
> network= from overloading. Why do you use a smaller interval here? Also if
> = (appropriate) rate limiting is used, this should either be a MUST or more> explanation when it is okay to use a smaller rate limit should be pr= ovided.
> However, after all, I don't think you those the right a= pproach here for rate
> limiting. A Map-Request is always expected to= be followed by some reply. For
> these kind of communication pattern= , RFC8085 recommends to limit the number of
> outstanding requests to= 1 (see sec 3.1.1 of RFC8085 recommending one packet per
> RTT), also= for all traffic and not only per receiver. However, this would also
>= ; require to implement some simple mechanism to detect a message as lost (s= ee
> also further below in point 4).
>
> Similarly I'= m not sure about the intent of this requirement in section 5.5:
> &qu= ot;Map-Replies SHOULD be sent for an EID-Prefix no more often than once
= > =C2=A0 =C2=A0per second to the same requesting router. "
> = My understanding is that Replies are only sent when a request is received. = Why
> is this additional rate limit needed? Again if used it should b= e 3 seconds for
> all traffic to be inline with RFC8085. Also again, = why is that not a MUST?
> Further recommendation are needed here.
= >
> Further section 6.1 say "Both the SMR sender and the Map-= Request responder MUST
> rate-limit
> =C2=A0 =C2=A0these messag= es.=C2=A0 Rate-limiting can be implemented as a global rate-
> =C2=A0= =C2=A0limiter or one rate-limiter per SMR destination."
> This = seems to be the same rate limit as mention above, or not...? It would
&g= t; probably make sense to rate limit the SMR even further. Please clarify a= nd
> provide more guidance, e.g. what should the value of a potential= additional
> rate limit for SMR be?
>
> Respectively the= following sentence in section 6.1 is also unclear:
> "The remot= e ITR MUST rate-limit the Map-Request until it gets a Map-Reply"
&g= t; Why is the rate-limit as currently proposed depend on the fact if a Map-= Reply
> is received? Is the ITR supposed to retransmit the Map-Reques= t...?
>

The reason is that an attacker can forge Map-Requests.=
=C2=A0
>
> And finally the Map-Register, Map-Notify and Map= -Notify-Ack messages does not
> seem to have any rate-limits. Recomme= ndations inline with RFC8085 should be
> provided for the total traff= ic and not only for a few message types. Again,
> Map-Notify and Map-= Notify-Ack messages should be send only once per RTT as
> there is a = feedback mechanism.
>

The RTT between the xTR and Map-Server a= nd Map-Resolver can be very small since they are typically deployed within = the same network.
=C2=A0
>
> For Map-Register sec 8.2 say: &= quot;Map-Register messages are sent periodically from
> an ETR to a M= ap-
> =C2=A0 =C2=A0Server with a suggested interval between messages = of one minute."
> However, this a rather a low bound than an upp= er bound. A required (MUST) rate
> limit is still needed.
>
= > 4) Loss detection and retransmission
>
> As also mention b= y the TSV-ART review (Once more thanks to Colin!), this spec
> has an= ACK mechanism for Map-Requests and now also for Map-Notify, however, it> does not specify what to do if the ACK is not received (loss detectio= n and
> retransmission scheduling). This makes the spec incomplete an= d needs to be
> further specified in the doc (and also has a relation= to the point 3 above of
> course).
>

I suggest to add t= he following sentence:

After sending a Map-Register, if a Map-Notify= -Ack is not received after 1 second the transmitter MUST re-transmit the or= iginal Map-Register with an exponential backoff, the maximum backoff is 1 m= inute.

=C2=A0
>
>
> ----------= ------------------------------------------------------------
> COMMEN= T:
> ----------------------------------------------------------------= ------
>
> Further comments:
>
> 1) The example giv= en in 5.5 should probably used IPv6 addresses and use the IP
> addres= s space that is reserved for documentation purposes.
>
> 2) I f= ind the security requirements in this doc very unsatisfying. Most
> i= mportant the doc requires the support of authentication mechanism but not t= he
> use of it. I would like to see more clear MUST requirements here= . Further,
> today and at this stage of the protocol (moving from exp= to PS) I find it not
> acceptable anymore to have certain security f= eature as optional and outsourced
> into a different work-in-process = draft. However, I leave further discussion to
> the SEC ADs.
><= br>> 3) Given the following statement:
> "Note that while thi= s document assumes a LISP-ALT database mapping
> =C2=A0 =C2=A0infrast= ructure to illustrate certain aspects of Map-Server and Map-
> =C2=A0= =C2=A0Resolver operation..."
> it seems that RFC6836 should be = a normative reference, as it might not be
> possible to understand al= l details explained in this doc with knowing ALT.
>
> 4) Furthe= r I would also think that I-D.ietf-lisp-mn and I-D.ietf-lisp-pubsub
>= should be normative references as the meaning of the respective bits it no= t
> further specified in this doc. Or can these bits just be ignored = if
> I-D.ietf-lisp-mn and I-D.ietf-lisp-pubsub are not implemented? I= f so that
> should be stated.
>
> Clarification questions= :
> 1) Sec 5.3.:
> "For the initial case, the destination = IP
> =C2=A0 =C2=A0address used for the Map-Request is the data packet= 's destination
> =C2=A0 =C2=A0address (i.e., the destination EID)= that had a mapping cache lookup
> =C2=A0 =C2=A0failure."
>= ; Does that mean that the Map-Request needs to use the IPv4 or IPv6 dependi= ng on
> the IP version used by the initial message from the EID. Is t= hat always the
> case or just for this initial message? I would assum= e that for all other cases
> this is actually independent...? Because= otherwise there would be a constraint
> on what needs to be requeste= d. I would like t see further clarification about
> this in the doc.<= br>>
> 2) In section 5.3: "The ITR MAY include all locally> =C2=A0 =C2=A0configured Locators in this list or just provide one loc= ator address
> =C2=A0 =C2=A0from each address family it supports.&quo= t;
> Would it make sense to include a SHOULD requirement to at least = the address
> family that is used to send the Request is included (to= increase chance to
> enable a communication/get a reply)...?
>=
> 3) Sec 5.4: "If all Weights for a Locator-Set are equal,
&= gt; =C2=A0 =C2=A0 =C2=A0 the receiver of the Map-Reply will decide how to l= oad-split the
> =C2=A0 =C2=A0 =C2=A0 traffic. "
> Shouldn&= #39;t the receiver in this case split the traffic equally? Otherwise how> would you signal that the traffic should be split equally? Maybe use = all zero
> instead to let the receiver decide...?
>
> 4) = sec 6.1: "When an ITR receives an SMR-based Map-Request for which it d= oes not
> =C2=A0 =C2=A0have a cached mapping for the EID in the SMR m= essage, it may not send
> =C2=A0 =C2=A0an SMR-invoked Map-Request.&qu= ot;
> I guess this should be normative and probably also a MUST NOT o= r at least
> SHOULD NOT.
>
> 5) Section 7 seems to imply = that if it is detected that no route is available,
> the ITR should b= asically do nothing and just drop any incoming packets for that
> ETR= . Would it make sense for incremental deployability, to just forward the> packet to the IP address of the EID instead...? This way the source h= ost would
> not benefit in mobility cases but still gets connectivity= otherwise. Or is that
> anyway not the implication? If that is the c= ase, that should be further
> clarified in the doc.
>
> 6= ) Section 8.2 says: "Note that the Map-Notify message
> =C2=A0 = =C2=A0is sent to UDP destination port 4342, not to the source port
> = =C2=A0 =C2=A0specified in the original Map-Register message."
> = Actually why is that?
>
> Some minor editorial comments:
>= ;
> 1) First sentence in intro: the pointer to ietf-lisp-introduction= as currently
> introduced, makes this reference look very normative:= "The Locator/ID
> Separation Protocol [I-D.ietf-lisp-introducti= on] and [I-D.ietf-lisp-rfc6830bis]
> specifies..." I would recom= mend the following wording: "The Locator/ID
> Separation Protoco= l [I-D.ietf-lisp-rfc6830bis] (see also
> [I-D.ietf-lisp-introduction]= ) specifies..."
>
> 2) Also in intro: Given that 6830bis i= s a normative reference "LISP RFC
> 6830bis" should be repl= aced with the new RFC number in the text. This should be
> noted to t= he RFC editor; probably this is more obvious if RFCXXX is used
> inst= ead.
>
> 3) Sec 5.4: "...for another way the R-bit MAY be = used."
> This looks like a lower case may would be more appropri= ate.
>
>
> ______________________________________________= _
> lisp mailing list
> lisp@i= etf.org
> = https://www.ietf.org/mailman/listinfo/lisp
--0000000000009adbee0582303abd-- From nobody Tue Feb 19 05:01:22 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3090B130ED7 for ; Tue, 19 Feb 2019 05:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-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 RC6o8B5krWpu for ; Tue, 19 Feb 2019 05:01:15 -0800 (PST) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 D180E130ED1 for ; Tue, 19 Feb 2019 05:01:14 -0800 (PST) Received: by mail-wr1-x42d.google.com with SMTP id o17so21893494wrw.3 for ; Tue, 19 Feb 2019 05:01:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=JWQEfWqv2G+72nIjQew1vIYk8icBoQUIIZNgY2lBQhA=; b=yeZD7ZgLer1AbAWHpc9B5Jix1avHtksTyOyQpgV9vOWmyd6tYPRzvG6WRCGZk1jBzN sOS56r36lRQxS30qb47i1NVvR+9Lc+UgUGmULxEfGI5Sn6dynnBtzh6GPT1g87yNxejq q++Z2SAQGxOXmpx3odLgpb0teBJ1xLzyDwH+u3jytgjRe0iJlvu8UYMh8zgl08oDroTc fFDrZK5ARncZA8XD9gfcm0Muotq2tC/cNGjtbem8Y3Gth5DmYk2W1Kr6H4/FqbJAjz4W n2SjCTBeeMsRiI8XKIAkWMMSRuzUtcQEiOsstWYirKWaJpjEeB6iYJIi0/ONLGfCuD0C oTwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=JWQEfWqv2G+72nIjQew1vIYk8icBoQUIIZNgY2lBQhA=; b=pg+TaR75RU7RYL+DbCwKjXXLzcOTgDvQDZ51AZAZnyvBosQ8vOM8/XmPaY/EiQJslg 3AgNT5rymzu09pAvW3afzRCQDqEz65T/5RZvNNnht55L9ztqTskrLEJS+tjR7gIsJXZN rZdxLXYoMmHlItPVg399lVkcF/FU1d1dY/lPmcJjkiqOwnfs/j+vViNEgzhU9nownSRm s6vsbYwTg0OxeaZGwpsXbs5QQcgXXcpjCfl0EptnHACNPirAm/Kk/4uimXF+AHZl6xD5 QoHOH425IiZXQ4hHiOevFMQalniaX11Vw4CGDfL4X91nD9M6D79MhKCVbUL31swrxrY4 EEiQ== X-Gm-Message-State: AHQUAuY4pHiAHmtVPSciSPMzbOiBZ23A1idHFr+3hrFywp2M1uWrWR20 odDhkhdQi2Mm/XFNdJA8/nKNrMntpbMVhw== X-Google-Smtp-Source: AHgI3IaX4xasNFmCDIIVXOlqp8Vb6gtM5Qeb81agD2t3KtYNOtiSvSB/XXScJq4efin43YUshnV+dg== X-Received: by 2002:adf:dc10:: with SMTP id t16mr21276043wri.40.1550581272123; Tue, 19 Feb 2019 05:01:12 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:51e1:6d8e:221:90c8? ([2001:660:330f:a4:51e1:6d8e:221:90c8]) by smtp.gmail.com with ESMTPSA id f13sm2383144wmh.41.2019.02.19.05.01.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Feb 2019 05:01:10 -0800 (PST) From: Luigi Iannone Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_AFF80732-A7C3-43CC-9F67-BB57CCAB7BFF" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 19 Feb 2019 14:01:07 +0100 In-Reply-To: <3EF5E431-BD4E-4775-B413-B4A4A6C4A887@gigix.net> Cc: lisp-chairs@ietf.org, "BRUNGARD, DEBORAH A" To: "lisp@ietf.org list" References: <3EF5E431-BD4E-4775-B413-B4A4A6C4A887@gigix.net> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lisp] WG Last Call for LISP-SEC (draft-ietf-lisp-sec-17.txt) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 13:01:21 -0000 --Apple-Mail=_AFF80732-A7C3-43CC-9F67-BB57CCAB7BFF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks, this WG Last Call has been out for a while and we did not receive = substantial feedback. Note that following the discussion on the main specs (the two bis = documents) LISP-SEC is supposed to be MTI - Mandatory To Implement. Please send your support gif you want to see this happening. Ciao L. > On 28 Jan 2019, at 14:29, Luigi Iannone wrote: >=20 > Hi All, >=20 > since work on bis documents is re-starting to move forward it is about = time to move forward other pieces of the LISP ecosystem. >=20 > As such the LISP Security document has been revised a while ago for = two reason: > - Make sure is PS quality=20 > - Make sure it is compliant with latest changes in the bis documents.=20= >=20 > The second point has been re-checked by the authors just last week, = and seems we are ready to move the document forward. >=20 > This email open the usual two weeks Working Group Last Call, to end = February 11th, 2019. >=20 > Please review this WG document and let the WG know if you agree that = it is ready for handing to the AD. > If you have objections, please state your reasons why, and explain = what it would take to address your concerns. >=20 > Thanks >=20 > Luigi & Joel >=20 >=20 >=20 > =20 >=20 --Apple-Mail=_AFF80732-A7C3-43CC-9F67-BB57CCAB7BFF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Folks,

this= WG Last Call has been out for a while and we did not receive = substantial feedback.

Note that following the discussion on the main specs (the two = bis documents) LISP-SEC is supposed to be MTI - Mandatory To = Implement.

Please send your support gif you want to see this = happening.

Ciao

L.


On 28 = Jan 2019, at 14:29, Luigi Iannone <ggx@gigix.net> wrote:

Hi All,

since work on bis = documents is re-starting to move forward it is about time to move = forward other pieces of the LISP ecosystem.

As such the LISP Security document has = been revised a while ago for two reason:
- Make = sure is PS quality 
- Make sure it is = compliant with latest changes in the bis documents. 

The second point has = been re-checked by the authors just last week, and seems we are ready to = move the document forward.

This email open the usual two weeks Working Group Last Call, = to end February 11th, 2019.

Please review this WG = document and let the WG know if you agree that it is ready for handing = to the AD.
If you have objections, please = state your reasons why, and explain what it would take to address your = concerns.

Thanks

Luigi & = Joel



 


= --Apple-Mail=_AFF80732-A7C3-43CC-9F67-BB57CCAB7BFF-- From nobody Tue Feb 19 07:55:56 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6506E130F09; Tue, 19 Feb 2019 07:55:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 WEyvZMItTguT; Tue, 19 Feb 2019 07:55:52 -0800 (PST) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 B4C54130EE2; Tue, 19 Feb 2019 07:55:51 -0800 (PST) Received: by mail-pl1-x62a.google.com with SMTP id c4so5600874pls.11; Tue, 19 Feb 2019 07:55:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=n/PBQRqUSyIVrPnjLjBy5m65E3WqLwX6nX0M3upxDYU=; b=b3mZVS2yBS5dJs00RIOcraHYoN4u+NGPU3pJOROvcVSjwwoPloQ5hwTnth3t/6ALgG EvL/1miJzPCuN92qrccfeMah27t+qDu1Ut6okGZw+5BQxVKhmJPWMA0nNAemdUQJiEOF 62YwRTOtVePt7B7yy6g7A8gsqEXY0+lmcj/pafhiPzwqfgM9e22Qypx4OV4sZbJr37gQ QfudIpVnNkTb9SRvHmgnHByLhyd4pHJcmS17Y9gmZWTBu5mjvsN+QSHhWa8WPJcRgBWG bk5MtS6dOfzvLBU0Je092EZ6Z0k7Z3ztYp16Q6Vx9jRzyAfTU/rpHia1rLBVdw4Om/b2 eblg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=n/PBQRqUSyIVrPnjLjBy5m65E3WqLwX6nX0M3upxDYU=; b=GABa5GTfd2XlE8VaRacJ+OQp7673V9qdUpqbYpwR0QbSBPHgq+ObXDUGQxZd4J94NS jdx/yw70xp389daCK7Hl6LJD007OxV0q41h9EwUJJ+auU3NR+AEw1NJLQMPX2KqqJ7Ox z3Aarx0JSrXy/YdBdKchA6EDV1tvrVGKN/6LWcmCM2yn2tVwyKsiec5myxPFWluV+lqH acfSJc1SxMEErf/krN4w+kYdYbYdqEhIXcqi/zE0uP8TfIu+tt8y++l3wV7mUBeKSOXK ZPOo5EnsgYaqG3SwGyonatayUa3XQRRENSbFDxYppiELmDzKFLOgNvcLHEEvKxNNrBu4 6EJQ== X-Gm-Message-State: AHQUAub1dA0GHzASCUoyYpqaYN8bKrTPs3J7M74iFlSswLeeHtt0S66X ArF4wnT+5FSKF29oejwvF2R4zBKt X-Google-Smtp-Source: AHgI3IbTv7VnrgH/GeOBAYRuv+8NmIlrYkgztnSwVIScCkYqOVtz/K8TyXA50I2TC6596zyoFPVY9A== X-Received: by 2002:a17:902:6b4b:: with SMTP id g11mr30893625plt.92.1550591751007; Tue, 19 Feb 2019 07:55:51 -0800 (PST) Received: from ?IPv6:2601:646:9600:e494:d893:ab45:c15e:6430? ([2601:646:9600:e494:d893:ab45:c15e:6430]) by smtp.gmail.com with ESMTPSA id t10sm17174841pfa.151.2019.02.19.07.55.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Feb 2019 07:55:48 -0800 (PST) From: Dino Farinacci Message-Id: <552D3668-0B23-4131-8D7B-AB77B83A9DE9@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_EE9B85DE-21C5-4768-A831-A1ADFF02D074" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 19 Feb 2019 07:55:47 -0800 In-Reply-To: Cc: "lisp@ietf.org list" , lisp-chairs@ietf.org To: Luigi Iannone References: <3EF5E431-BD4E-4775-B413-B4A4A6C4A887@gigix.net> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] WG Last Call for LISP-SEC (draft-ietf-lisp-sec-17.txt) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 15:55:55 -0000 --Apple-Mail=_EE9B85DE-21C5-4768-A831-A1ADFF02D074 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have one comment that will help address the SECDIR comments to = RFC6833bis. So I request this change to be made in Section 5.4 =E2=80=9CIT= R Processing=E2=80=9D: Add this paragraph after the above paragraph: If the ITR receives a Map-Reply without the S-bit set, meaning the = Map-Reply does not include an EID-AD and PKT-AD, it should not cache = the EID-prefix and RLOC-set from the Map-Reply. It should store state = for the EID-prefix from the Map-Reply noting to send a Map-Request at a = later time. The rate-limiting procedures for when and how often to = resend the Map-Request should follow the procedures in RFC 6833bis. Dino > On Feb 19, 2019, at 5:01 AM, Luigi Iannone wrote: >=20 > Folks, >=20 > this WG Last Call has been out for a while and we did not receive = substantial feedback. >=20 > Note that following the discussion on the main specs (the two bis = documents) LISP-SEC is supposed to be MTI - Mandatory To Implement. >=20 > Please send your support gif you want to see this happening. >=20 > Ciao >=20 > L. >=20 >=20 >> On 28 Jan 2019, at 14:29, Luigi Iannone wrote: >>=20 >> Hi All, >>=20 >> since work on bis documents is re-starting to move forward it is = about time to move forward other pieces of the LISP ecosystem. >>=20 >> As such the LISP Security document has been revised a while ago for = two reason: >> - Make sure is PS quality=20 >> - Make sure it is compliant with latest changes in the bis documents.=20= >>=20 >> The second point has been re-checked by the authors just last week, = and seems we are ready to move the document forward. >>=20 >> This email open the usual two weeks Working Group Last Call, to end = February 11th, 2019. >>=20 >> Please review this WG document and let the WG know if you agree that = it is ready for handing to the AD. >> If you have objections, please state your reasons why, and explain = what it would take to address your concerns. >>=20 >> Thanks >>=20 >> Luigi & Joel >>=20 >>=20 >>=20 >> =20 >>=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail=_EE9B85DE-21C5-4768-A831-A1ADFF02D074 Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_69BDCD1A-9EE0-47F2-B58A-F235D3A0C582" --Apple-Mail=_69BDCD1A-9EE0-47F2-B58A-F235D3A0C582 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I have one comment that will help = address the SECDIR comments to RFC6833bis. So I request this change to = be made in Section 5.4 =E2=80=9CITR Processing=E2=80=9D:


Add = this paragraph after the above paragraph:

If the ITR receives a Map-Reply without = the S-bit set, meaning the Map-Reply does not include an EID-AD and = PKT-AD,  it should not cache the EID-prefix and RLOC-set from the = Map-Reply. It should store state for the EID-prefix from the Map-Reply = noting to send a Map-Request at a later time. The rate-limiting = procedures for when and how often to resend the Map-Request should = follow the procedures in RFC 6833bis.

Dino


On Feb = 19, 2019, at 5:01 AM, Luigi Iannone <ggx@gigix.net> wrote:

Folks,

this WG Last Call has = been out for a while and we did not receive substantial feedback.

Note that following the discussion on the main = specs (the two bis documents) LISP-SEC is supposed to be MTI = - Mandatory To Implement.

Please send = your support gif you want to see this happening.

Ciao

L.


On 28 Jan = 2019, at 14:29, Luigi Iannone <ggx@gigix.net> wrote:

Hi = All,

since work on bis documents is = re-starting to move forward it is about time to move forward other = pieces of the LISP ecosystem.

As such = the LISP Security document has been revised a while ago for two = reason:
- Make sure is PS quality 
- = Make sure it is compliant with latest changes in the bis = documents. 

The second point has been = re-checked by the authors just last week, and seems we are ready to move = the document forward.

This email open = the usual two weeks Working Group Last Call, to end February 11th, = 2019.

Please review this WG document and = let the WG know if you agree that it is ready for handing to the AD.
If you have objections, please state your reasons why, and = explain what it would take to address your concerns.

Thanks

Luigi & Joel



 


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

= --Apple-Mail=_69BDCD1A-9EE0-47F2-B58A-F235D3A0C582 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=PastedGraphic-10.png Content-Type: image/png; x-unix-mode=0666; name="PastedGraphic-10.png" Content-Id: <1C46EB40-1D6A-492F-84BC-05C845DD0BF0@hsd1.ca.comcast.net> iVBORw0KGgoAAAANSUhEUgAABIwAAADUCAYAAAD+xLgmAAAMK2lDQ1BJQ0MgUHJvZmlsZQAASImV VwdYU8kWnltSSWiBUKSE3kQp0gUCoUUQkCrYCEkgocSYEFTsqKjAWlCxYEVXRRRdCyCLDQsWFsXe HxZUlHVxFRsqb5IAuvq99753vm/u/e+ZM+f859yZ+WYA0IrlSaU5qDYAuZI8WVx4MGtsSiqL9AiQ AQZ0gDXw4fHl0qDY2CgAZeD9T3l3AyDK91Vnpa+f+/+r6AiEcj4ASCzE6QI5PxfiQwDgnnypLA8A QhfUW03Nk0JMhCyBngwShNhaiTPV2FuJ09U4SmWTEMeBOA0AMo3Hk2UCoKnkxcrnZ0I/mqUQu0gE YgnEjRAH8EU8AcSfIR6amzsZYi17iO3Tv/OT+Q+f6YM+ebzMQazORSXkELFcmsOb/n+W439Lbo5i IIYVbDSRLCJOmbOybtmTI5WYBvE5SXp0DMS6EF8TC1T2SvxUpIhI7Lf/wJdzYM0AEwCUJuCFREJs ArGlJCc6ql8fkCEO40IMa48miPO4CeqxqEA2Oa7fPzpNKA+NH8A8mSqW0qZYkZ0Y1O9zk0jIHfDZ UCBKSFbzRC/ni5OiIdaE+J48Oz6y3+ZFgYgTPWAjU8QpOcN/joEMWVic2gazzpUP5IX5isTc6H4c lSdKiFCPxSbyeSpuhhBnCeVjowZ4CoQhoeq8sEKhJLGfP1YmzQuO67ffLs2J7bfHGoU54Uq9JcSt 8vz4gbHdeXCyqfPFgTQvNkHNDdfL4o2KVXPAHUEU4IAQwAIK2NLBZJAFxK1ddV3wS90TBnhABjKB EDj3awZGJKt6JPAZDwrAnxAJgXxwXLCqVwjyof7LoFb9dAYZqt581Yhs8BTiXBAJcuC3QjVKMhgt CTyBGvFP0fmQaw5syr6fdCytAR0xlBhCjCCGER1wYzwA98Oj4JMNmxvujfsM8PpmT3hKaCM8Ilwn tBNuTxIXyn5gzgKjQTvkGNafXfr32eG20KsHHoz7Q//QN87EjYEzPgJGCsIDYWwPqP2eq2Iw42+1 7PdFcaGgFAMKm2L/IwNNR02PQS/KSn1fCzWv9MFqcQZ7fsyD8139BPAd+aMlthg7iDVjJ7HzWCNW B1jYcawea8GOKvHg3HiimhsD0eJUfLKhH/FP8Xj9MZVVk7tUu3S6fO7vA3nCaXnKxcKZLJ0uE2eK 8lhBcLcWsrgS/rChLDcXV7iLKvd+9dbyhqna0xHmhW+6wrcA+Av6+voav+mi4Jo8tBAA6tNvOrtj cDkbAHCuhK+Q5at1uPJBAFSgBVeKETCDe5c9zMgNeAI/wAahYBSIAQkgBUyEdRbBeSoDU8FMMA8U gRKwHKwG68FmsA3sAnvBAVAHGsFJcBZcBJfBdXAXzpUO8BJ0g3egF0EQEkJHGIgRYo7YIE6IG+KN BCChSBQSh6QgaUgmIkEUyExkPlKClCHrka1IFfIbcgQ5iZxH2pDbyEOkE/kb+YRiKA3VQ01RW3Q4 6o0GoZFoAjoBzUSnoAXoAnQpuhatRPegtehJ9CJ6HW1HX6I9GMA0MCZmgTlj3hgHi8FSsQxMhs3G irFyrBKrwRrgn76KtWNd2EeciDNwFu4M52sEnojz8Sn4bLwUX4/vwmvx0/hV/CHejX8l0AkmBCeC L4FLGEvIJEwlFBHKCTsIhwln4NrpILwjEolMoh3RC669FGIWcQaxlLiRuI94gthGfEzsIZFIRiQn kj8phsQj5ZGKSOtIe0jHSVdIHaQPZA2yOdmNHEZOJUvIheRy8m7yMfIV8jNyL0WbYkPxpcRQBJTp lGWU7ZQGyiVKB6WXqkO1o/pTE6hZ1HnUtdQa6hnqPeobDQ0NSw0fjTEaYo25Gms19muc03io8ZGm S3OkcWjjaQraUtpO2gnabdobOp1uS2fTU+l59KX0Kvop+gP6B02G5jBNrqZAc45mhWat5hXNV1oU LRutIK2JWgVa5VoHtS5pdWlTtG21Odo87dnaFdpHtG9q9+gwdFx1YnRydUp1duuc13muS9K11Q3V Fegu0N2me0r3MQNjWDE4DD5jPmM74wyjQ4+oZ6fH1cvSK9Hbq9eq162vqz9CP0l/mn6F/lH9dibG tGVymTnMZcwDzBvMTwamBkEGQoMlBjUGVwzeGw4xZBsKDYsN9xleN/xkxDIKNco2WmFUZ3TfGDd2 NB5jPNV4k/EZ464hekP8hvCHFA85MOSOCWriaBJnMsNkm0mLSY+pmWm4qdR0nekp0y4zphnbLMts ldkxs05zhnmAudh8lflx8xcsfVYQK4e1lnWa1W1hYhFhobDYatFq0WtpZ5loWWi5z/K+FdXK2yrD apVVk1W3tbn1aOuZ1tXWd2woNt42Ips1Ns02723tbJNtF9nW2T63M7Tj2hXYVdvds6fbB9pPsa+0 v+ZAdPB2yHbY6HDZEXX0cBQ5VjheckKdPJ3EThud2oYShvoMlQytHHrTmeYc5JzvXO38cBhzWNSw wmF1w14Ntx6eOnzF8ObhX108XHJctrvcddV1HeVa6Nrg+reboxvfrcLtmjvdPcx9jnu9++sRTiOE IzaNuOXB8BjtscijyeOLp5enzLPGs9PL2ivNa4PXTW8971jvUu9zPgSfYJ85Po0+H309ffN8D/j+ 5efsl+232+/5SLuRwpHbRz72t/Tn+W/1bw9gBaQFbAloD7QI5AVWBj5iW7EF7B3sZ0EOQVlBe4Je BbsEy4IPB7/n+HJmcU6EYCHhIcUhraG6oYmh60MfhFmGZYZVh3WHe4TPCD8RQYiIjFgRcZNryuVz q7jdo7xGzRp1OpIWGR+5PvJRlGOULKphNDp61OiVo+9F20RLoutiQAw3ZmXM/Vi72Cmxv48hjokd UzHmaZxr3My45nhG/KT43fHvEoITliXcTbRPVCQ2JWkljU+qSnqfHJJcltw+dvjYWWMvphiniFPq U0mpSak7UnvGhY5bPa5jvMf4ovE3JthNmDbh/ETjiTkTj07SmsSbdDCNkJactjvtMy+GV8nrSeem b0jv5nP4a/gvBWzBKkGn0F9YJnyW4Z9RlvE80z9zZWanKFBULuoSc8Trxa+zIrI2Z73Pjsnemd2X k5yzL5ecm5Z7RKIryZacnmw2edrkNqmTtEjaPsV3yuop3bJI2Q45Ip8gr8/Tg4fsFoW9YqHiYX5A fkX+h6lJUw9O05kmmdYy3XH6kunPCsIKfp2Bz+DPaJppMXPezIezgmZtnY3MTp/dNMdqzoI5HXPD 5+6aR52XPe+PQpfCssK385PnNywwXTB3weOF4QurizSLZEU3F/kt2rwYXyxe3LrEfcm6JV+LBcUX SlxKyks+l/JLL/zi+svaX/qWZixtXea5bNNy4nLJ8hsrAlfsKtMpKyh7vHL0ytpVrFXFq96unrT6 fPmI8s1rqGsUa9rXRq2tX2e9bvm6z+tF669XBFfs22CyYcmG9xsFG69sYm+q2Wy6uWTzpy3iLbe2 hm+trbStLN9G3Ja/7en2pO3Nv3r/WrXDeEfJji87JTvbd8XtOl3lVVW122T3smq0WlHduWf8nst7 Q/bW1zjXbN3H3FeyH+xX7H/xW9pvNw5EHmg66H2w5pDNoQ2HGYeLa5Ha6bXddaK69vqU+rYjo440 Nfg1HP592O87Gy0aK47qH112jHpswbG+4wXHe05IT3SdzDz5uGlS091TY09dOz3mdOuZyDPnzoad PdUc1Hz8nP+5xvO+549c8L5Qd9HzYm2LR8vhPzz+ONzq2Vp7yetS/WWfyw1tI9uOXQm8cvJqyNWz 17jXLl6Pvt52I/HGrZvjb7bfEtx6fjvn9us7+Xd67869R7hXfF/7fvkDkweV/3L41752z/ajD0Me tjyKf3T3Mf/xyyfyJ587FjylPy1/Zv6s6rnb88bOsM7LL8a96HgpfdnbVfSnzp8bXtm/OvQX+6+W 7rHdHa9lr/v+Ln1j9Gbn2xFvm3piex68y33X+774g9GHXR+9PzZ/Sv70rHfqZ9LntV8cvjR8jfx6 ry+3r0/Kk/FURwEMNjQjA4C/dwJATwGAcRmeH8ap72YqQdT3SRUC/wmr728q8QSgBr6Ux3DOCQD2 w2Y7F/pmA6A8giewAeruPtj6RZ7h7qb2RYM3FsKHvr43pgCQGgD4Iuvr693Y1/dlOyR7G4ATU9R3 QqUo76Bb2Ep03VAwF/wg/wYEKXFozC1U3QAAAAlwSFlzAAAWJQAAFiUBSVIk8AAAAZ5pVFh0WE1M OmNvbS5hZG9iZS54bXAAAAAAADx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6 eG1wdGs9IlhNUCBDb3JlIDUuNC4wIj4KICAgPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3 LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4KICAgICAgPHJkZjpEZXNjcmlwdGlv biByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6ZXhpZj0iaHR0cDovL25zLmFkb2JlLmNv bS9leGlmLzEuMC8iPgogICAgICAgICA8ZXhpZjpQaXhlbFhEaW1lbnNpb24+MTE2NDwvZXhpZjpQ aXhlbFhEaW1lbnNpb24+CiAgICAgICAgIDxleGlmOlBpeGVsWURpbWVuc2lvbj4yMTI8L2V4aWY6 UGl4ZWxZRGltZW5zaW9uPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgPC9yZGY6UkRGPgo8 L3g6eG1wbWV0YT4KXTMKZQAAABxpRE9UAAAAAgAAAAAAAABqAAAAKAAAAGoAAABqAACOVkcDGpAA AEAASURBVHgB7L1vaGTHtS9aAw5I4IAEPjAKDniMD1gmedDDTbjHD8PzhByYNrmQHmSITQ6c11a+ JPeBTufTtM85MKftD/PkG5irfBnL98CEliGh9WBCT2AOUj7kSn6MH63LJHQHZCTDDOqBMbTAA90w A/V+tfeuqlW1a/ef3VtqaaYapN69d/1Z9ataq1atWrX2GY4P8x+PgEfAI+AR8Ah4BDwCHgGPgEfA I+AR8Ah4BDwCHgGPQITAGW8w8mPBI+AR8Ah4BDwCHgGPgEfAI+AR8Ah4BDwCHgGPgEeAIuANRhQN f+0R8Ah4BDwCHgGPgEfAI+AR8Ah4BDwCHgGPgEfAI8C8wcgPAo+AR8Aj4BHwCHgEPAIeAY+AR8Aj 4BHwCHgEPAIeAQMBbzAy4PA/PAIeAY+AR8Aj4BHwCHgEPAIeAY+AR8Aj4BHwCHgEvMHIjwGPgEfA I+AR8Ah4BDwCHgGPgEfAI+AR8Ah4BDwCHgEDAW8wMuDwPzwCHgGPgEfAI+AR8Ah4BDwCHgGPgEfA I+AR8Ah4BLzByI8Bj4BHwCPgEfAIeAQ8Ah4Bj4BHwCPgEfAIeAQ8Ah4BAwFvMDLg8D88Ah4Bj4BH wCPgEfAIeAQ8Ah4Bj4BHwCPgEfAIeAS8wciPAY+AR8Aj4BHwCHgEPAIeAY+AR8Aj4BHwCHgEPAIe AQMBbzAy4PA/PAIeAY+AR8Aj4BHwCHgEPAIeAY+AR8Aj4BHwCHgEvMHIjwGPgEfAI+AR8Ah4BDwC HgGPgEfAI+AR8Ah4BDwCHgEDAW8wMuDwPzwCHgGPgEfAI+AR8Ah4BDwCHgGPgEfAI+AR8Ah4BLzB yI8Bj4BHwCPgEfAIeAQ8Ah4Bj4BHwCPgEfAIeAQ8Ah4BAwFvMDLg8D88Ah4Bj4BHwCPgEfAIeAQ8 Ah4Bj4BHwCPgEfAIeAS8wciPAY+AR8Aj4BHwCHgEPAIeAY+AR8Aj4BHwCHgEPAIeAQMBbzAy4PA/ PAIeAY+AR8Aj4BHwCHgEPAIeAY+AR8Aj4BHwCHgEvMHIjwGPgEfAI+AR8Ah4BDwCHgGPgEfAI+AR 8Ah4BDwCHgEDAW8wMuDwPzwCHgGPgEdg0gj0Dg9ZzyJiamqGTU1ZN5+Vn70eO8Sf/Ew9Dyyek7/8 t0fAI3AsCDxh7PDRYVTVFJuZeYYEEtp9iPaLzzMti0MIhv/vcRseK5LyEDqA/MxgvmPjznf3b7Hz 336L7aDQ0voeW/7xOVm8//YIeASGQMAbjIYAySfxCHgEPAIegeNBYP/T99jL73wSryy3yrqNInuG lmghBk9a7NI3XmPrFJGFGuO/LdA7/toj4BE4YgQ2y2fYDz7Ulazc7bKff/cZkEgPNtmZuR/ohj+r slgjMNzV04hbZDQc24DTB8HWby6x1/5Bz3j5601WX5zvk2Pwo95f19j0/LthwsUa614vPHu6xGCY fAqPQCICEzQY9dj2p1W28wi7FYnkiQc91puaZ+/+5AKbGdfC3Lce/9AjcPQIbP7bW+wH/9Jm9XsN ln/x6OvzNXgEThsCiQajhSrr/vadAfNFNq09UXzqMhhdBBa3ssFi5/drbPvLbuC91etNs9d/XGC5 F+Ozcus/1tjmX2W6Hpv/4bvswqvY+T2tn6922Cefbgt3iYQWTLPpF2bYSy/Ns/PfPec9uhJQGus2 dv3fwq5/+3KdNT7Ij1XUyJmf7LMPvv8ye59V2N6dMjs3hH65+W/nMX8LH4XwswqDUXESBqPjxu0r GIz+hhiMjlEWS6xPwnf79x+wb/2X91n55gGr/GhuMElPC25PDtnmp79mH/3qfXZLDf8cK16+xM4+ rLEPPt5hZXjtVDLy2rENRgUYjGpjGozY/XV25tuXwj6DwYjDYDTM50TpAsMQnFGakcd6RvX6Yk4w AnxSn26D5xjjgGaIvxxvdCdFqK/XI5ARAo+bvBiN98KNZkaF+mI8Ak8fAt1Oh3fw1+12+MbVfDhH XKzyY5kGTiKfdru8+/Uer+Si+TIrLJzz8DLv2ENqtxqfp6827FSn6nfzWi7epkR9pMA37p2q5p0K Yps3ilEfFHnzWJhbw9Jt6TFdbQ1feffehtJdYTDSBR7j1URwe9zlG1cinslK/hwjZuNX1eXVhUj+ LowwF51y3Lp3a2q891uv5bOeD74+4CsXQ7xhMBq/+9obvLSQ5/mLeb6yeTBceSdRFxiO8jFTpRzr Y9bqs59sBNjkyOvw+rUyLy2VePlyOfgrSGUYSlsxuieel67UeOfx5Cj1NXsEMkEAkw/2NAIFOZMJ MBOifCEegZONgFocHdci5cTyKVHiMsSieXuVw7cjkEu5aA6uWcaRxrXQaCc3eYpXVvjWvcksljMb rQ+bvHp9lVcWo0WgwGChwlevr/AV3F++UrIWSqVjN2pk1tYTWpDibVY49k1BajAayfBDFpEj5cuw DyaFm6o3Q/mTISxHXFR6+XtqcXt8wMvR3CCMRYUrVd68d8A7Dw94Y7Oq9NnAkHRxNeMNHY33xPTl E6sLHPFQR08q4+gzyetHje/pLH+CR9IgYqyPOooAd1eOoweJnyc91n7QZjIG6OyL55iIPdj+8zb7 4/9qsS5ig06/cI69+cMLbO75xFLSP+gdsv37HZJ/is29NBe5rPfY/k6D7fz1S9Z51B1Ix+EXO2z7 8xbb/6oTHrWYmmXn/tOb7EJusLtrkPfPLdb+qgtaptns2bNsPjfPZjr7wOEBy/2owObpiYHDNuqR gVNB8yugWbQCQfn2BZ44myyCqc6dlW0hTYxdog/+3GCf/eXLIF/weOYsy33vdTZ/1u3if4g6Oo/C +qdm5tjcC1Ps8H6Lbf9ph7WBFUPbz7+Zdx6HMKoH/jufbbPWF20WtPz5WXb2lXk2f26G7X/2R/bg +RwrvNnnvDPca3f+JPLvswB1kDT7EsbLGxgvFC+j0ix+7LP3zrzMRHSWwo09VvtpiqB7aHtLjK8v HiiCZl6cB+65oxnrqhYE+3ywz/Zb+6x1/wF4TCCPUXf2PPgMdbu6fNJ8Smhno/Y50re/7ESBlyNe wb3W59ts5y/huJt96TzLv5kbfFQlNl7n2EvfwTGXefT/Vy3W2O+x19B/SUdu21+0WKvVYg8OexHu 02zuOzl24e/mncez2vf3lWycegF8JoQjePvwqzZrB4EkEawVPB7cpxg5rkeVMb2gjkjGCFn2ImEo Q/6gMvu5o35xq/Wb9xDPAFwz4jGsUXHT1WfAp6OON115eCVk8n3IZPyiMnnt7TPs3d/h5ohY2MXb v9uIG/UtEjfKOALwpM3e/8a32AckU/UeZ++4jtSij1u7GK+QTz3I9FA+n2O5H2JegLyPfQw+gxyO 5nImZMeXbQTZBQLPYU56cS6Y42P5s7jxxRo787dhbIvqLtr1CikU9K3/6wV26cPwHEZls8PKb5Ix TZKyw33MZZ+xlpAbQVMx/jEvvf5GMm8b2SFf2+Bx9DibEXwb4XUIfu5IlormTYlPdBtzP3Qgouu0 MbfJZ6IOhSutkFyPo4f0vtpnjc92WOtBqBNNg/b5V3Ls7KyYZ3fY1Hfy7MJ33ZgpnY8VWfPxKpsf 4lgYIXu8y3793q9kHBF9DzHFxDwejJeXpD4RzQuvvI55wS2bjWJH5RWSeVK4KVkc6ehy3Ej97fUf 5hP1P0U+eEroEfuY1x5Adw00ialpNv+9PHt9iCOu44w3RUPKi/WfnWGXPkbmQWsUq/xMcEOZEu80 6wWLpKF+Hn7+azb7/V8EaZ1Hzh7tsEvfPB/G18v8mGKPrb09Hcx38MiHvgydPtApIV+DxR/0MswL iSeKA6oxj2CdQGWhkK96vTYIhgx0gUFV9Hse0x2Pb62Tdqz3a86xPUshYzJbnx5bIydQ0Umycw1r he/eXY3cmPXOYH7B7V6+eifmXD9mk2F5jdwk0V2KjtVdzrutumlxV89LfM/2kHrY4MvSvVWl0+Ux VuQbrQTa21u8RLyxKB30On+NunGCbitPeW2Dry5Fxz0MGnJ8eZ3mNSE7uFNVO9K0PnmdW1zhza/N PLzbjOeBa6jMQ7+L15OPOjSul5x5aH7G8om7lc315b75i9c24scxrKaM9rPLm7drvHqjyqtXpfu9 6Ocir67hnrgv/65X+dZu0q59lzdulI+Z9qilXzd5xTHmKear23EX38nyqe6lNH3evB4fm3mLf8L2 F3njoa7LvmqsVfr2mcSwsBbnN+EKLj0/ZDrzu8i3rLpjmOcqfOPmiuUpEcqZ3OJyMu1pZAx240x6 KR/G5Q9jOGpsywkbQPwedl6QWdPgBumdEZ+C3nFkDHjNLZMZr0BOKD7MeNdPYazmgQqXHE09MeT4 i3tWdHjtcpxnZHrx7ZLrNp/lLld5PUHGF6/Wj8TTmLYv3i6Mqq8balwj+KocZvr7Mdp+tdCHz3N8 5bYjX1SCmE+l5ynFi10s841tWwbkAy+nGG7X9JwZkwHAPpd0XGQcPQTeB9Ult95ltCNneR7As6sm 5jzMf/KIdjA+rpK5UM6J641svRZA88Z6WPcy9SyDLIzNxzfqfM81HRMPo/zlirvvWIk3EtQ3Dg0j Da/wSeIWjVUtJ/K8ctk95ktreixqJgmvmusD5sPFVX5g68qykLTjTeZP+d25uxHpaFR3hI4sxyj5 rjn0IFHtuLjxcfg0ZbsDuq/LPsaR0YR+ad6I0mQ8J4k5WXq5FCAbatfcun/xWvK8sLdGdW69vnLK cYVTdrqAKjLFxSTWOlmM9RRNzTRLKhmT0fo004acwMImeCQtjoYSqoMEjyueglR0YYSQbvOh0pK9 q/PGlbhinF8sWvVq4RQzYOzWY2mLUDyWr5aVYioVrpWYwavDV8jCNbdY4dV1GCSuxRUX042zy2tL lKYhrpfi57QbagKR+fO8fKXCy0tyYpH3c7xOjzVAySrJPrK/czhXTNok2r7qCFrVubNClPIcr1zD JAKlsxKru+A4OtDl9cuWcnuxyCtXl0G71Z9wrU3U9eLDtv8dZ4wQiZHjG2fj458OX7WNi4J24F6y DaUwECQqXPGCh7rTvUtxB83orxKOjNIjpMEYtxf/E+ZToXCk7fO9NbdyIsZmzjZ0Ol2x3fyWy1lj MOIFk1fDbmlGx4CkLMihz8uXrWMyWIwZY3W3pnnE4ilZjv1djcXhSCljHu8Z7uvwoyN8CDzoAi1q t3OBbo3KoeeFKF8q3DLh0/TjLSDdMS/YfRX8Fv06aI60MBz0sxkp1sUry7wYjRsZ12UriiFVuraq Nipi/Qb8TGNhjheXcOTckk8r1ip6b13zmTlvO2RjMGZwLMyWM4MaN+D5QIPRQx2zJrbQiI15xvOL Zb58bZmXLCN7nhh1JEmNa/a86W63wia3HMj3g5vm5oEhP1xy1zVeHONteD2Ec3lMMRyTRb6yJjZG VmJ9Dm8Mw+gzWuwoxuHFk9knNpdFcsjJZ3hWWNuL100MRjRf/qIl2612q4JS8sokcZO0K1lMcXPo b1J2yHzhd5evWnNSfhEhKSz9zcUnIn/a8WbSMOov0EzbOvAac57DsDIWbmPy6agtpukp3SvbhqZB k+GImog3aNzK4Ic2GFE+c1+75wVzzaBlqyEvbUoz0QXsQkf7bdJ9XGudbMb6aC3NOnVKGZPB+jTr lpzE8k6nwShC0jBe5Eo6pgJ2/OrEqFO+LfdKM+wCMSl0GvHdJbErKDyD8PygUUd8hCIvwWtFy9ID XiGTTuDRYkww8CQxdmGsYJBkt7MY80ro8q3r2qLuFIqEZqmELq9t8QMRZBbnkjcsLxYanLl7VweJ FEJ7+aa1a4qgrOaOI5RbC/JOg3qH5XiV7Mg0b5Ldp8sbVk6qMMRjSYhAlHq3Mm4k7GySsh3eW912 Q+/eo2203TFCRrmBsVhFLIySWDwtUoUyFxhdZPwu8V2C8kTxkNWoHZxg3BR4/a45cXfvweOMjKnc lTh2sqxU3w9R/kIBscRWeWPXrLtxQy/4Sjft3g5rmxSfjt/nMNSRRV8OBtQDyciG1xWMo20TWXtB V8FOuYrDhiCYJo9jvDk8FzrC80AYBq9jp5vCLsYUGUs1apiNyFCYSwPVwjLfah0gcHKHH2DHtEza JbzdjICzY8qYTkMaGKnBKCIMso4qQzHDgwlj8Espra5FryN9Ktwy4NOxxptteEB/CV7rCrzaiLUT ee8og+OQWDjgcd6qL4XKdBHeATLIeBjE9CCSLXm+sdtQcibWbwI/LPyKSxVev2MusjsNMm8s1R31 az6TMZTEjnKzjfZjXmoiVoZhjEpaiDtKHuYWNRhVW1aOTpOvEGO9rUuoIMBC/grPWsqnKOqgYXoI 0YV05w71WIAMuFpztlnO067NIymfYvJD6BToE7W5FMNsTD0EZmpV9qJpEBIIHmyTed4aq4I/w9iV pvE7J4wHUezK4FvEr4THWaYbIPDUqATllpVhNFiA5oQxPoylGX6jbmzGbVlyXbSNWwaj/OWanheg X5WVUSSuh4T50/HKRHELCKeeMkJe5Hmtoef85po2YiYafa5jU3ShxFdvkvlQlA3ctA5TjnvkjzHe ItJTfzXWYPyF/la2PKoKwT09ZkpLmKtvuL2r1BwW6Gmj4DYun6ZudpjRMj4XIZcbd5v84EgMRDat 2mAk54XS9Q2sVaCEQYcS6yut82M8xmRcVF4gC3GNMSbnkZi8pFVnoAvQ4tJca+Po8a51shjradqb ZZ5GahkjhgiZt+ABT9djg9anWbbhpJZ1qg1GWghjYrYUNTqpx3YFs+oNS3HIXa4Tw5C7ks62VhLz fRb2dOextK4nZX6vrjwIbOVV1tiMFvF49ae8pb8NmrEIcCw2u/BSkEqqXkxq4S0UrEriWwbMdDaN VDmPK8Akr6VkigbUlft7ghcNFrqh0mE/7/BlpcShzdYxHgWOsfPnOEaoEqa8INgPbZAieYSClky7 fgObOOqz4VJ0U5JtZBMGBwQ9PGgj8KGYuIG5PE6RNAlPhk+z6HM6Hi1PHgEKecuOsYDG4l8rv9gh j3nwhIjuES+BQTKqC2Ouwh0eFtR4a9QddZbGHB4PTjljesMY43FMGaN53GEwAn36OTwJE7CJmhF8 qbY4ZAJN57oeFbegDMJzBi6uCtS98cYbNTCKecT1UUZAsehIgYWrzPCeHufCo6LbipQmeLM0sLgP FtSiPoxrqaD37TehzAsZIf6wsBCGC3m0wE23rj+YW1wbPHAZp8FXk3gquY3JT+h4FF5xwYs2YFQo Wt5RDHgYakZnS8+T9jNSXZd6xiqDmbkQXHbNp1ab45hr3NyyVz+3cR9bDyEGzpxjc0c0vwtDYaBH JDwXafSRkeQjLyLdkXzIYjhmKOxXIZEPrkUq7e94n1kFj8wrYf5J4aZkMWRQnAe72oiYtHiXzQ8M 4XJOCw3jemPMYWjLaLzJ6tN+KzmG9o3ySYvb2Hw6CpEJaTdsz/zA6CUMhuFf4fIKbxzJCxCI/EJd yy4PJxxT1Lq9a0ySRhG+dctLklZe0jzH+Gbjk7DWSTvWJXQT/x5VxoBgqguMuj6deHuPgYCnw2Dk nJy0sBlaOIwKOBEm7kVZvEA9KULY4rz2xs06r+FIGf2r30RsIXJ8w6AfdcoFuhDYuYsFHAlbxptd VvGHI1rI24AngVjLOz+E5tK6uRNM09MJLlB6SD6WWzEVZ5pRXJMFp70Q1gzpVhBVvY4FkYEdjCKF wPVftHsV8QdqiPfQgCHDUOlDyizMVoFR3cK8tl4PYr3ISVAsHByn4uyWjvYbCwDZd0af9iuFKLWJ cSii/HTROVBR7Ven/QwLvi3sssndGY2RVhrEvaQ2qT49Tj7NpM+JDHEpC4QnDLyxkJRY9ff2EsfW Qq8z54IR3g3Vq9qDKwl3o+6o7xTmiKWxJ3bYXB+MR2kAYPRYnYXdqDJG8/iEDEZj4BbAlIZPLcxG kzF6nAVyJ/HIFTEyOOSjq4uHu6frD3lYehVp/g43LbT8co25vW14jhieazq/GrtOunX9bKmWSDI1 kup5RbxtdTk4WryM48WD/irw4rE9VvR4ddCrFkVxTxczX5HXb8fncjEf1+gxbtl+MsaYMiLFm94l O55xzDVubtmrn9sGI2MuTaOHYGtMLSgERjiWJI6zibfLCT2kulbnWw14IiQqImFbtZw6gvk2Dqdx h/ZfHFsjqfmDyP2i68ga8WRIKjc9r4SkTAo3XS88HxzzivKMkOPcRI53drf48qIVAiDiMSUjjKPM soBsxpssLd03oSGhfUnlpsVtfD5Nomi0+8LLUx5V1v1kystKzNA/rmwmePeRkZwcw9fzgqN9hG/d 8tKRh8jpofM4ihn1ltHvE1nrEOxHHOujtjXr9OllDDUYjb4+zbodJ7G8p8Ng5BzQesAfGaMTATTs DpV0/U8Suq77OSv2wd66dv11pQ/v5Xk15naFIWjQnGRVQjpiqAiUHuSTxo58n6DUwSAndRSstFpJ cy8m1cTq6lMIb7rLnNR2ETjVMBvdI3FdYsqJOenpMmnA3oxY18DFOs6XUIXGyx3XychGPV6ysnZh B4ceoZT4qKMxBM8kPuvbp2ThkZTfaOOwPzLp8wEyhPQnXRjQoLN9FRjZFofizds6borEXHxL12x6 j9Yti1SYO410MpVun71TPo6M0WPWzeP6+RF4GI2JW4AM6dehx+RY4430A4zxyVKZnM93yUfZrSN/ 6/ple7eu0OOzeb4lBCrBxR5zzl1oeRySyAjbcBGSSup3GWZle0j9kk64sSjjLOWJ5Ou4XKfjMQ+D UuMONmyM4ycIzu7oFGqgT67Pml+iANC0TnbFfYwlaDZps4051FtltFF4SKyCb/3cxj0LPUR4Ig/T 7nLs6LwmUskpp5FApzuKK9oHcWz71Ej6hB4xVDnIc1e54/FKWMukcFP1Jswr6rlDPh3cpmEBJF/k tJeekhMJ80YG4031UaqLZH4aVJzCZUTcsuDTQbSN9LwLD/PdJm9swxC+tsqLxgZBNE/IAseWzRrv vp6+hN/ccjAiaNh0kn7xnSYPzZ/2euJrHY29PXekbdJx5Btbxqg1lFsGKT52yLfjaN+k6/AGo3F6 gAgTl2LgKlrtwIjF39IyXxmwK1q5uuJ8c5aIubOK2Dh5l1KuJl6HdwGh2ansSKIV40SLOmJp7+81 gQJIHXZaraSlZUjEf7mJ4KsLdnBzqYCE30XqPUV2/MSxruVrK/13ohFMegVxnRxrBIlOum+CYd+J jZROd9XxSmfyxHFJ+iz5yKAjX59bBzeJh8tFxHQQcXCkgQPfXby5ZTlSGpLa1F/I6okpKX8f8pIf ZdLnA2gj45zyvx7j6WNhUUUxfyWM56IaC9w7eCOj9GKidcs0CvMEBTVMp9tnG4zE87QyRrffzeP6 efYGo3FxC3BJwac0PsLoMob0wwCDkXpDZ6YKi65f8iDtI6UwkvFuzB1tfUxaeEhVt5umhysWGepF EU66Sf2jGoxAk+SDYYwXom9s4w9tK934ocfCXfxBY3ExxFBcgadTXw8neAJXt0OvXlpnX89RtE9u 1MT5fBBu+rnqw5DxjQDC4+ghvHuAt9rhhRt2wGelg4TzcVLgaiWnTqnBKN4nAJjwSez52LwSduCk cFP1OvmYxDiyn2PjiW72VUTczK+JhoWjec3bMlyDe94IZfN44y0a/im/kvlpUIFpcctqvTCIvqTn e/AsWsHLZfq9aIDGTTVeVjO2bNZ4T8xglEYXSAJz5PuTXOto7O25Y+RmHFeGDGSMnpfdMmgQHx9X UydVjzcYjYN8P8UgoVztahgPlJuQxbwNpliBS2/J8tyRibqdPRxn07vDsXPmhOYwqKnMaX7TYJ6B 0mMwo8MQRbJTRVouQOTjcRjyYHOF5xFU3OU4JYLg7W2SgGV0oUyEPusTT0HSeGTfJLZN3wmQEkAV zEV3bBOZnC5wYoqqTDTSN3mzlXj7mjOvjt1i97VM3l/I6okpKb8sZ6TvTPp8AG2Elwy8ad10HLoa gHHbFYqzNMKJNKRc2+CqiuhoDySj7iiBwhwL5MA7RGUkF+TtT4ZSMKaM0TyeUDcxbLpoJxQGl6ot 9iLETpgBbkGRafiU9vnIMkaPsyD+WGKMNXqEMB5o2IZj+N+6fsqDzW1xxKquAzkTfOkLF/QbBZNj p23Jl1A4+1DXzy4mH3emQcWp515nt8mbrSH/duNSTI9X24CpZZswRsXi8ZGXQDjjBfbrADpe6HFQ Kw/1YorzisbNPZfr5wZ/o46x9RCUsYHXXBfwIgDnNoYwEtIXcCQYAvVb8txHACw4sv1JPFYMA+ig WggfxPsEmfs8H59XQuImhdsgWZz4nHisx48uhW3S8Xrci7Usxtugrh30XL1peNC8bhWUiEuULul5 FnxqkTLCT3i0Sg+iK1vJ+Ujf2vwwnmym8qvPvEBixNH5K0Yw4cu+6WjGNLoAzZ/y+iSsddKOdbPJ XbxEA/EAxcufRFzAxQJelpQcCsXMO+IvMg7TyhitC7hlUBKfjkjpqU1+ogxGKpAfhPEwn0Hp5Rn7 oRfnw1RK0xABRHcmaRL7mhpT2IIjkK7MgLgxzc0aPJBW8HYavRNDj7usOi0n8Awgb18xLP6ibEKz UIJXHME299ROj9gdhCIXVb9xWXvx5K8mTCB4e5QR8LelaQ+appjarSAm9ykmDzl5JeJG3txiKOG4 L/Oizat3nCpuQF7nXpPX8GrglRtH4GFEjhC4DVcIFnu3wUUMK/U2Lphp6M7cMnmrXEBw9I96ItE+ o2lGvyaYO4O6YjIgr4VO4rPkPg0pOho+zabP+9JGeMnkfzIOMd5K6+7jh93WhvIeoAtgccxGehXk XIoadvXpm5vMukNM1cSG+sUi3I7bwrt7yjNMyIEiWdCNK2No/vhCGmOKxGdz0W6P00HjR6XPALew LKKoOo0/Lj4db7zJ19oHXjKQb7H+wrLceAPlkHOkwmbAhRznSW86DLKT8U55vali9CAov0O0CuU3 aJcYi066Cd5IU7gWf8tjd3fD8CQaaYE/oO30+HVsPJJ4fLH4UoYXo+PFG6Re8WbCKjyQqptSWTaD tRauxefTLl6nTb2n7MVYcCRNzWvlmEHfmBMs3MfVQzgxeNnHzlWzv9ZBwROPsSvjsXsDrds54A3E htogb+NS5Y97QcZzXE6hcBi9mjieWL/dML2NSb7YeBE09Xk+Pq9EjZ4QboNkcdJzOie4gheLt9zK OS/QX+gGimhyVuMtgi/tl55X4/wmyhT6o4hL2mibem8SLpKOpOdj86msINU3lcuQbwmx9aghPy6j UlWsMsl5ScwfTjmDtx6qOIxIU9tVWeMXhC/p/BVPSO8QDIbWBWj+NNeoU8r1Ca510o51o8XkjbtS B7A3Xoz0Y/wYW8aIulOvT8cg/BRlnajBqNve4028ojH4ww5hLXp1MEOg1i38Vs9iu4JQ2HfFq4al J00Rr7KnR2XwvLWlX2+KXbAm3tiijtKM00HwCDiQtOENMvJtYkUYGIJdTtkefLvrI1Z7oUDnynzj bkQbyhYTjnDxluUGTHZVxzjQFtDQeLMsXtdNBHnnHn09vGOHnwhNycD5pRUoRRt8A4rZMvFOEs+N oI70rTB4lsNrhBv3sEIQkztobyLoKVVw2aIZwLSDN2ttkVevrm6aRxcO0Ha9KCqhT/fI0QYiuAVu 0WunlWcGDGwNUnbOMmjR4KGiXeXr8vWcQi+EYojd9IrxVhzErSC4jjNkdF6zDcGr1uFdItq9ccMM Kk0NCHrnLezz4rV69GpRlIy3lm3dMGNaGcfxdOWprrau6gCV+aXVoL9FPzZuO4IgCj7bRZ8p3CbI p2jtWH2OxcIelSF4dbR4zbf6fH0QjHfJp6UbGE/kuc2necTVaoJXgtfa4/Xk1StFvYi2+QzGAfrm j+BVsnjbVDhOLNmAvCXInj3ISCpv9GQfjhlxFGcFgWg3wOd1jDVJdygDzACmNu0jyxhDScjxFSy4 xNuyhEyuRK8ol/UXJB8qYKF0Q7Zr2U9lQtmcF8TrfUmXIOfYuIVkpOPT8cabPnoU9gmOdgncwGvN 7Rovqbc8yv605jyC30iXkJtinFciBbWEoyJNQ+5GiOAtfU3iwSleJS7Gs/gY8gkeoGI+64j0WGxX rPlEzu0HD+mCysQ7aD+OeFVhON/YhKHlqskrYl6huUMKU/zHnLWHuXwrequoqLeI8RjjJWUQA/YI EC1eKiF5rXFdy0fBY6u3ozlNzOXAYAvHpwtG3+kYVfZ4YRf7tBm0uRZjxpGVYD4G9sE8G8WLUXXb 42U8PYQu4AVuBcR+2qN9CkNPVelzCW84El2mDB/A9iLeygcZKoxEYuwsL5nYyo2rFD3tzmLoQoXg FfFCPu9h08Z+2YDCXmzkbWtP5jL4ZS/ig6ASQTv0ICnfxHiiY318XomaMgHcOm3IYmnsh966BTlx oOZ6bunkQn/TfMIN3VHwCfRW6F0HrfhcKLwsxbFWA9euKR9Tjzf3SBj6Lp1XC1dCPayDdYzQh4yA /zntAToWbpB0yssHfDbqemHohjkTWnIZfR7o+ySt8OqXY13I9sQXbJA8Q11G81JZya9o3luoBC+3 aTQa0JmtmFiXzY0G8YZUpUeIdRnhWyb0Oapn4HnHNlIGhJoYDKuzD9XGxERmnZNa66QZ63aTYnMc SzqpYOdM8XtMGTPe+jQFvacwy+QMRpisDeOCEIaJf2bQSWpJpHkKUXDF5g2qaOhyV+zgBSk6LKlu Soe8TrRiY2eSWsVlevd3ntd3iXqsLKC6XUE+xDLSgjt65nqdtqEkWWVY+Lt2ejt4Va6bTqssKH/G LjkmfGd/y51PqgAROnTAb3I8ijwXtMQDMONohONYR+OGtfCwyqHtykMZIKinGCnuLHEBauEW0VSj fY6iGmRRQ+m0r/NXzUnTTcUId40ddjetNg3SUJjEK8fBp7KFafu8aSwEdbvDHWVM6HIHyBhDppza cwb51GVJ3HJYfBt2DxBPj6LIdIO+qaGQTvb98xX4xj2JVvQ9roxBMdQbMal+La+IojlqoMwoiLBs wbi4yXLS82l6GTO0bCVKdPFm/IiVbMMw30njXMtdlNJnrq6LsQO3feoFmdTf5v0iWVxYCrLBUxa/ LDi85YZpqCONPu5h1YH6TV0B3kAWTdqgD88vuYi20pjtDeuo3DS9DZs3rUVPnzKU0YK2hR5ZTspL x4sV2y+1HoIxQT2JdVuhh5D6wvv9Fgkdc0Gc1Aa8Pe8o5uMGNQYm1c3K2st6KT5WhIEjVC2T5gUS N2tsXpGdf8y4JYwzKSe6LW1E02MButk1Pd5pfDmapt+18hjJbLxJ/FJ+YzNEe0K5xkJ4T3kVZ4Cb iI+Xmk9TNjPMliSX87ywUIitN/q9dXlUMui8FJcnDtxjXrkwtMXkkCMf4Xkt001q0+oCZimj/Doh a51Rx7qjiTRMhuBzpyenI1/aW6llzNjr07QUn658EzQY7fHK0AyNCZtaf3H2XC82tBBYiY4aHTiV MLjLtzPoHCygXXW7Jj1Jj7NWWNA3rpueIbSMPF4ZX4UHjtzJVGUQK2ruotswFgRdheeRU8EiBqPq XeymiVchI4C0qFsaXvKLsOK37CWsogBeLXsxDwlNOzwZbmqPKJUrQVEqyDfAJeBKz6I2rkqPshyC fet+13Uznl8Uu5TOlgekdHA0oOxc7Ivy8ryMAH+Ne8n5VXvGuDjAroxL6cgtlPgqsHPvdMBjBq+k Nb2gCAbYna4nHFEcg9QIs7qbXoyTLWBt81vxRtT/k+RT0ug0fe5+S1hBxQOqk91zNf5sIylo6AqP P8NzTfdZwGfwxkj6NG/KIKA6j6iriCDYB10cB1QeluFz+lZEZTDCTloHcc2qV8shz0jDMl6DXYFX lHOsjStjRIMg3+q2Zwhoz8MLrXGnZo4n0Kg4TsiJBN5WOKMceZ13GMXHwY32RVo+TTPeVL1teMa6 5BM8boTHZW1JysCoz+8q5FQRo1wkGdjK1LCAw070CKTEXuwoK6+PDoLfR95j+jlozBV59Q48DWz5 LsalIlQvTERspOC1uEvFYJ6Vc1LuIsqB906Wn84d9yJXGABsg714ayGV2faxmubtVfeGiBiroH1l DZ4mxBuDtiMILn85MjSCL4V+Idq7IuZwcsTbaTBCQZ27LvkML47NBq9dKSheEf0Sj2mYUg9B761I PpQyRf4m30V4Hunj1bTV5LqLuItLJp3hGMrx0pVVeLLokUJyZXQJOQo9zKXTFZYqvA5PF8phzTXy EgjVTu2hWbf4M2gHjnMbm2dj8Qpp9nHihgWVy0BYijZpxavNXRhS/S2cE9z9XFnDWEd7zDVBkXh5 ZzjeCIRpLsXxubIryHuuwCvXEfONetplgZsgMu16IU0DSZ7aMMZwzE31jI+M2vOS8CjbWLc9o8Uc iJfYQE66Pk5eVDwbzp90rlp2hOeQ5abVBWT+Ub9PylpnpLEea6Rt1MYxTrqOj6XP4Eagd6aQMRms TzOg/sQXcUZQCKbxn0kh8KTH2g/arPfcLJtlXdZ9bprNzsywqeeSCeohfWdqls3NTDH2hLHeo0PW edQNMyD/3NmZ5MxPWuy9b7zGPkEKKKCs+F2UQT8oj/WpmyZlgvYv24w9P8vYo07w3bduI3OKH08O UV+Xzb40F+LT67HDww7rCprxmZ6ZYzPPh9eD/vcO28C9x2ZfmGLdnsg7i7wWFoMKGfO56Dc0IcB7 6vn+fW5UhXz7DzpsCjQztJ+9MBeOBSNR9j8O77dZd2oaA67LplGnGH6n6TPJPhd93X6AsQvWFONt FvhNDYNfwGMdjE+RD7IBvN1PNsj+aP3mPfbaP4DLL1ZZ99Y7bJiqZF7xPZaMMQpCuw+FbJpGG2aO b8ykxI2SLq/T8uk44633FeST6O/nMCdIWS8JOsHfgu7OE8iIJ5ARmBdmhhISPbb29jR793eIEnS9 yWqL82YLR5mTzJzH/utQzM2PwN+CX4FDMJePynyUaszXlzBfr+Oec74maQ+BvZgLp6EDzLzQRwcg edRlCj2EPcIYfaT1DaWHBPPx8LKK0nB4COEo9I/npo53PgbNAZ8HYy2qe1g9SDVgtIt0vOKoA303 Mdwc5Ay8JfQXzAmzwFfou3PDjtWsx9tAQgckEPrnI6HAMRbob+Pw+YCq1OM0fKoyp7h4sMPWft9i Z9/IswuvzrDD+y223+6xqW8y1oHqOXfuHDvXb72RospBWXqH0Jslnw41vwwqcfjnaXWB4WuIUp60 tU6asf5oh731zfPsVtQkeKCx5R+fGxmKVBnSyphUlT07mbzB6Nnp67ClxGCEwKHsnVePY5Z71kD2 7fUITBaB/U/fYy+/A4PRQpXx374zWWJ87R6BAQisvX0mNBjdgMHop5bBaEDep/qxn6+f6u71jfMI eAQ8Ak8jAoef/5rNfv8XUdNKrPl4mc0fsRH+acTxJLXJG4xOUm8cNS3C6rq7yS6dv8R2UFdprcFK b8yEXi7wbzr3yoi7kkdNry/fI+ARGBmBwwf7bPO//4Jd+lDs7ZRZY/fnDFweeCNOvXiOzQ3phTdy xT6DR2BUBAJPsBb7H2+fZ++LSWmpyvb+6U24e/SwizyFOSnyJh213FOcXvBvG15KU8Iv8OvPjPn6 /YvzQ3ptnWIAPOkeAY+AR8AjcKoRaH38FnvtZ6F/Ed7Cy1b9RtCp7k9BvDcYnfouHLYBcPvPw+3/ D8npB7m8J+f0TzwCHoGTgEDvr5+w6fn3kklJeUQtuUD/xCOQHgGqVLpKQSBSVrePqLkSPi334FH0 Fo6gSTf+eLPyrNmts3nvGByHxt/xCHgEPAIegROBwOHna+zC99+Fc0IR3kWr3rvoRPTKeER4g9F4 +J2i3D22/rNpdunjJJJzrH6vwfIvJj339z0CHoETj8AXa+zM376bTOblOuMf4H2F/uMROAEI7H/6 Sxyd/CiRErxVhVV+NJf4/Kl7AIPRL2Ew6oMI23tcYee8a/9T1/W+QR4Bj4BH4KlDIIg39dS16pls kDcYPWvdLpg36eOV0CRk/H2PwOlBwPP46ekrT2lwVDIRhmd1Tkri4WcVj8QB4h94BDwCHgGPgEfA I3DUCHiD0VEj7Mv3CHgEPAIeAY+AR8Aj4BHwCHgEPAIeAY+AR8AjcMoQ8AajU9ZhnlyPgEfAI+AR 8Ah4BDwCHgGPgEfAI+AR8Ah4BDwCR42ANxgdNcK+fI+AR8Aj4BHwCHgEPAIeAY+AR8Aj4BHwCHgE PAKnDAFvMDplHebJ9Qh4BDwCHgGPgEfAI+AR8Ah4BDwCHgGPgEfAI3DUCHiD0VEj7Mv3CHgEPAIe AY+AR8Aj4BHwCHgEPAIeAY+AR8AjcMoQ8AajU9ZhnlyPgEfAI+AR8Ah4BDwCHgGPgEfAI+AR8Ah4 BDwCR42ANxgdNcK+fI/AESBwq3yevfXhDkous73HFXbOv275CFD2RZ5KBJ702OGjXoz0qedn2NQz xCft37/PvvVfPghwqO1yVnglBkk2Nyjez02xmeensin3OEo5zbQfBz4JdfQOD5nksEz46sk+++D7 L7P3xZS2VGf8v+UTava3n0kEPJ/qbr9/i53/9ltMsEppfY8t//icfnYSr3qYj/FnfjBPzExwnrBo ykSGmQ30vzwCTx0C3mD01HVpigY9ifI8Q4upFCidoCw9tvb2NHv3dyFJ1VaXvfPqBCffE4SMJ+VZ R6DH1sEblyLeoGjkrzdZfXGe3nqqr1u/ucRe+4f1oI3FtSZb/ckRtP1Jm33wjW+x9xWSedbo1lnu NIij00y7wtu6OIa5vPfXNTY9/66u+GKVdW+9w8bq8l6LXZp+jYWjtcSaj5fZvNdHNMbP8tXTyKdj 9KfBf4s11r1eGI/3xqBlYNYnLfbeN15jnzgSrt7tsuJ3x5IajlKHuAWaLoGmUNZE6RdqjP+2MERm n8Qj8OwiMEGDUY9tf1plO4/YAGHXY72pefbuTy6wGalAPGqxtX/fZN2pIYWNsG6/+Dor/jjH2Fc7 7JNPt1FpUt5pNv3CDHvppXl2/rvnst2RfnLIbv17le2jxVNif27qHMsv5NmcTQrSbX5aYy2RBGOz 15tmF/7xHTZ3f5NV/6MF0nWGHsOzhXfY/AwSClw+3WSdoPxwUPfQ9rn/XGCF782Zozyo49fso1+9 z26JrYrgk2PFy5fY2Yc19sHHO6yM3YsK2b1o/cca2/xrNxk6WUz0LWB/faHIcmetB/7n2Ajc+qcz 7K1fhcVU4T3wzlF5D4xN6SksYEw+nX/+FLY5Ivlw5xar/k9IKCJjjNZMTbPZmbPs3Px5lntFCJ2T 9oHB6GcwGH0cp6sAg1HtGTIY7f8/v2QvFz4KgChClq8SWR5HJ7qD3eu3sHvdvlxnjQ+G8fKAwegM NRgVWLNbY/N6ikqsKusH7d9/AI+q91n55gGr/Mia75yVnRzaneSNcFPMzR/9apl98gc1mbP8Ypld +JsH7JcffsJy8NppZOS1YyxYBY0LMBj9dkyDETyMfvmNl1k4Wkvwml0eymt289/eYj/4lzar32uw /IsjAHbak47MpyenwaeZT0en/Qhwv7/Oznz7UlgwDEYcBqMT+zktBqMsjN4nthM8YR6BjBDgk/p0 GxzmG45mDPGX442uJrTbWB0ij11uPiijeS03Qt4C37in6x33qnt3JVZ37mojVuzeWjGWbrnR4dWL dpvC37lrYRmu8kN8VziBj3fv1obCPm/Q1uWrOXf9/fowH9EWa6S/MRYCW9dKPH8xz/OLK/zg8VhF +cwWAi4+Gp5PKadZBZ/4nyPy+MIJHXvgh26nwzv46369x5cjuQWD0YnvgSwJPNhc5QUhIy4W+UZ7 uJKbN+TcU+TNYYcy8D64XYnmrMLw+YYjachUXV5diOanhaox3/Ut4ETQ3pfC/g+/bvLyMPNyboV3 +pc02tPHXb5xNR/2+cUR8E6q5fEBX10qBHNa8dpWUirz/uMmL0b6Y+HGs8XbqfjURG9Cv04zn6ak PWuk2xu8tCDkep6vbB5kXXr25UFWiLm408H3vQ2ObYhAbsDDKPu6hi2x2w10g4qUnVnIsGHr9uk8 AqcUATY5uju8fq3MS0slXr5cDv4KknkhUIrRPfG8dKXGO2RR3LxRiJTTPC9F6cqXS8QIou+XFiOl hkWK7MMmr15f5ZVFYvxYqPDV6yt8BfeXr9ByRJpSdgrw4w7fuF6OaGcRvWW+R9rGodatBDhIw1aO V67V+AFk68GdKi8tyraDNiwESksVvnUvErwPG3wZeOg2I02uwFdv7+luhmJWJka6wpUqb9474J2H B7yxWeXYq1D0sYurWvHuNtWz/ILus9KCpJPBeCHvw5gRlfOsLdI00P7q1CIwJp+e2naD8M7djUAW yoWYMAYXrqzw1Wv4g4ysYFFnGIgXa1pGnMiGayXfy6LBHaQXogVjk2ZgzlY1Ghcj5htY8LAJdD+z UZX/idM+bBvj6TaWyHwNPWbj7h7m8g7fa2zwijSgBXNx9v2ixsqoeMebke4ODEZSX3nWeFthD72W bqamA/I4c51mPh2D9uOE+CTXRYy8EzUYBRj5/jzJQ8XTdvIQmOCRNCw7rM/+p++xl9/BaVe4OHO4 OCd9Wr95D7EZ4unW3j4TxHXBbhOr/TSK1/DFGjvzt+K8veUqr+4zFjvSgyMp6/96gV0KggozVtns sPKb2R2/WP/ZGePIxGoDZ3ll0IcHCGg3Fwa0C9sP92wO92wJBnHxrLZwFOlV+YB890lz+Pmv2ez3 fxEkto+cBTcf7bBL3zwfnu+lruZJZSoci4g7sKriDqi+yPAYSO+rNmsf4pyb/EzNsnMvRv3SO2Q7 Ow3W+mKfdZFk9pXzLP9Gzn2kEP2786ftIK04vidOB86+dI69+cYFNjdEN/e+2mfbf/qM7X/VBSU4 wnj2LMvhiM48jui0/7rD9rsz7PWc6jFJrfpu72yzP/6lxTqH4laPTb1wjp1/43WWk21RKc2L3iHa /xVpPx5PzcyxuReSz3+0gYeZA209ew6BacOyew9QZixA8BSbe2kujt2YuJmtGfEX2t7abaHPHrDe oy4LkH/+HMv98HU236f9I9ZiJB+LT0lJhw/22X5rn7XuP8DYFJRj1Jw9z978YS5+HFU8RFv3VT+j L15BX4j7jw7ZPvqrhzglIkjj3FlHH4l0GXyULGYmXwdFH7bY+xdeYx8Ep19ybONhg114wV3p4Rc7 bPvzFtoTcBoIB8/+pzfZhZzjyBDGV/vLjhqvsy9inIqGI+Bp+8s2O8Q3ew7tfnEuvO+u0rqr431h UZl8JC2qI8YrkgZRaoB/xyh/EP8ZiRN+HN7fZx2rYtV2mgcybv++WX+AJ5Ubw6ShZVrXffvdSkt/ 6mNK0Xh5tM82hYx8EMrIc/8Zff5dR5/TQsa8Vvw6QH+wq8mM9sNwXmiJMRwwLMb6K/PsdcxD6ji9 Xfk4vw932Fuz59ktlJFzHiE8ZJ+8PcveC+J5WfrPOPVGeZUehuMcHDGMGOTSIeboTjCfTGGemR0Y AN059sn81J/MffbemZeD+CiFG3vQ+ZLn3P7lpHwqdI7PhB7RjuajWXYW/T1/bobtf/ZH9uD5HCu8 2T9uWFpdIC2fpmxpptkmzaftL6BHtFrsAXTJcD6eZnPfybELfzcfzrN9WpuW9j5FDvkIcyDGmTlN JOhptESqS0h9Gfe2//RH1pKyOWk+puXgely9NyiOrCP6xjCy5mOqs4pybL3WOV8GFUb/xNx9P8SP 6k5ynYJNhr5x2NLyqdBd9v/cYDtC3xedhyP9cy/OY71wlh22dtjO4RTL/4iEW6E0Z3A9su5p6GCR 7ol7rc+30YZQzs2+hLXVmwlrqwxo9kWcYAROkg1L7ZoM2LFyp9PWYrrb1CW7h9TFXt9n3Gnp/rqh vGQQLDVDmDSdGBbBrmzu8oYqX7UtegZDl7mDBE8fufvvpFuU1CdN87r0EMCRA8OzSZHAlQcX7YeE nQGNI6VTt5H2ha4hxRXZTZS4MZYP2tC8uWx6PUjs4P1gf5rrCWmjPMVrG8mu+/DOql6WHmtkZ1fW R74RiNquGt4bNbUjqttAysHxsubXsWzhDYK/mTf5CMjBujxeQuoQNOYizzGME+kJZpYJbzFrzI+F W0KThrvd4bUBmBevx491Dld2v1R6DEtsRuJTUTSOi1QSjpHKMle3bZdy1Es8LUW68hq8fpZc4y7H l9ezlE0aDy2HKF/r592GPl4Lg7d+IK+Et6Ph4WCNQYZjUi3zkEzzutnG3OUqr18vOXm7eLVueJ3K auPfuh/7ySIl8wgPB32kZAjKcfYlZJCj+XE6Eu7sSs8cC59c/JiPjU84hsKj1rL0WgLmiXOFyAiv 29qNKq+uVdXcIsouXsU9cZ/+rTecHmV6HmDwCHb3GVuqJstW2YARv4VHXEgflevgC0pzdF2L8VpY 2di0wyOxdlXOq1Y/BuMpx1duZ8+n3bv6aD42vZyf7l05vpLnCWfGIW4qGbGwzOvrK8TDW2OQE3Oa yea65KSxT/UOnTq66vLm7VrY51fp/FYMxq8xVq9X+dbuOMwZq1zdaCTIpZAnZftN3lSZcZFKF8iA TykNx3l9EvhUhGJI0nfCfivyrYdxVLKgPV7qaHdcYSoEzbaeZpYa1yWEzuwMBbK4mjyfjqn3GjQR PbbfnGTPdTLshiiLyj3Jb66QAUG90MHcuhPjFcwLSj9LkDmp+DRq8MF21Y21pWOsHMXRvFS6J+c2 7sEYs/RRySsNB69ETfdfTykCEzySFkdUKSAJzCtzuNO5FwZaGTRjMuj7CQajhxuK2fsLZUnVsN+S TnHUrBLVIY03nSjeBhTMG8vRM0vRG0bg9kmjsIPQWtlO0uSg0MCtHcd89SehTI0jpVO2EYuOrGIL YNJS542JwC3aR2TIM2UYCVrR5fXL+vhcIPRwpK9ydZmX7cU4juLFkIFxpUTLjq5zOavM6L49Ge7d 1EcRQ4Gb52XUvXyZKr1C0SzwrVjlogE4quhcsLoX9EGOO3pBEdYZKrL5K5GB8vGecTyRpqmos/Fj 4hZgP8Y/xDozlbwcLy7h2CU5CinoXkGMr2w/cgyn5FMQE4uFlAuPytKjt0KBaxhGwi6v0WMmjjFH +ym4xkKcsmoWOGg54R5fnU29QLfHOt+tK9kpaS1ervDlq2WrL9Fvd3S/7a1rQ4NTqY1hgePCBnau lst+xNE6ywhKU9P2SJrFd4HEYNtwGS5zy+PFEMM8Y47viEevxuO47K1pfDSNcu4IW9O45jZcxPqI NH60uH6Mu4wTeh6Qi2XxnUOcDfob88FaloYTxNyKjQmzPo2TuI85yrFJMhbtDhmKYNN8+doyL1lt zzqeH6W70CfuTxDP6+usJQQWFyreVT/Mw2dV16Kos+XeQOmn/40U+xJ1I55V1p/OHW0sF2O8cq3K azC2xo7rivHmgD2tLpAFn2aNxXDlnQA+BaHNa9aGBPQ/M5QFxgs20/SMJFqXDe3D4ZScyhxzmt/6 zWmC9hoNvWHISiGbTd0179p4G1PvjbUoYR1hpzuw9GWjnS5Ds0tmOPQQcz6IcBQGEUf+tHwatIU4 HIg6izjWX1uv8pVYyJOE9acNyIi/0+menLt1jBCnHGJmGfjRkCUj0ueTn04ETqXB6EAuLKSnRIB9 wsJAeVGUjFhBVNnC0S7z02nyFbJTW75tewGYyUf6BQVTGh6qDezCR9bbZbFL366HDIkAlc2kncFh BG6/NJawFbvIjbtNfmAbiOxGEbrp4kPjaCpH0lJdWifxk+wy0/yGwt8h3g1SgOXhjdB8CAwRYK9x c5UXF4rY1dV1dzZlUFYh/OLeDd12Q+82iIWiZeiqG4v4Aq/dIWPi6wNeu2IKU4oRJ8ZHQW9stxnG MCN/v6Ct0YKnoZQfE/c4pAiWTsayQZdMDPokjjlpTIo2Gd2EAABAAElEQVSejYubrCL1N3bvqzAK FhGrq35H96cor9OQu+fo06V66iqcGcl4T8WnotCHWzBsFeBxscobu6Ya2rihF/+lm2QsSWI6DbWY ksaT5bUtfiCCRyLe2MYN0wBpj1dZTNpvvRiML7I7uxuKNrFgMgMqw7BLFNPAY89YpIM/101eNBdV Hb4aLbRzkWwsQEY12zBgo+1NxFkzDCz9eCVofMK84ARG1y34wcUrdHez4FKwneUOuAl5LecEtqS9 TUWubvuAH6Dt9LN1VSr6FbexSuAt5CRZ2LraIsvsiNh4QSxBM35fTsWkC2MMlkU8QchZV5B9PQ+E ymWZeCJ1MJfJMWzExZMEjPHdWINhBgbk8mXTUFYI7kV0i7h+S9gcuOH2RByH9o0rsi/Qboc3zUHD 9GpweZ6mbj6Z58V4zS0u8407mMsxXjrCQGTwXepaEjMqGRFtmuSWIOfuYayKILf3GnxlkWCDOdfk 86jYaKxyyPkwdiNwdCzeFBFiPsCiS/R5ySg/R+JZhv1ewvitJniVqfJSXOi5Nx7fsougvtIDPOYd LuoaQxfIgk9TNDeTLJPmU9EIgV9BbBJer/M9KlLFmCJjqWa96CYL2jMBUfIKdAM5BxqGlKRKiC4h 5ETpxhbvRrKh06qrshB8Iybbx9J7XfQQmdVvTgqz6vk41s4ACyIzbD3ANuTDC1LoYKLdnTbi2Eab P2rD15Y5Y/CpoJ3OvTFjeRcB/gfp5C7sRrk3ju4Jk6nUwYJ5BRuSIoZu8DE8l3K8PuTLNEYh3ac9 uQicSoNRFwwvdnS2IAD0J2lhgAUKXJhrN01XelNJxKJOKMP4K1qeCww7yLQWXV/KKxiwZKDGKtyl 5RGx3JU6b0RvRwsWf/fkYtgyCAwjcAek2bA9bcgCTwiIwuUVKH5SQsh2gtZNuIKvbxmuqxpHk84u FMbaWg1C2i5Hlpf+W9cZLk4qNwftWkvPLZE+zzeSXCkNbxZiYLxXUwYVYWwyPUJ0O+jkSifDLfk2 GWCLeFg6g3HVNTyIbKXFSIofSllP2MWk6enxodzVuOeCPo5jL/7HxI0SkcU1FiIHCNAe/MHAKRYZ yhhmT/jj1jcun9r1f90J6YYBQLwthGMHSsqBmDIk8hIeDsaspcSKJN1d+rbDhAWZSJjio8cXeAbG VykfTe8oLFKt8dTZ1p5HypPNUT/1hCmtU4OZluNCFlVcxnr0DQ3cH1PIjPp0eU6cjbTAVBnq0W51 HE0moju2pmePTJH2e0sZHuCxJAshxn3tQYcd78igZr7FUmbS31ROUnmkU8Sv9NGH0dpH63J5lTaU DDTniTgF6e8oWTCiV0lq2uEhowxhffSELjHcZW3YtnfiBc/Qv9xC2dzcSA9vLCeVEXlLDsjE6k1q Qq+wNmFkmvBb82lfgxHNRGRk/7JppvGv60vSEBZfYAelQ7aHBuD486x0gbR8On7rxy/h2PnUQXIX my6BHiHmY3ipUrnfT1ampd1BQvpbdNz38ZpVFdD0xGNWPtd8bHkTj6n3yvKNb0JLP5zDPFomuOdu /dyWGVQuIr6bQYL80VDhOSAzLf1xXD7V9UOnduhuGHHYCBVyBEYX53NJZQbfo+qegjZp0HKdtlBh XtybahlQ7Is4oQicSoORG0s9yN3CxcxFlUSqYNHrQsJuqlnSiL+IwAw8mwyhHCp7NWG1VYsFS8Em +RMF7hBpxE59MdrBp22m187FmtVcjaNFp5Uuy5+6zoQFpV0Z8JCLc9G+1ZsbiLkAI6LxV+cbN6mr uZ486W6BPqplV4LfWMiGiiKMUsryrselqLuI3a36TbvuGq/DqKl3JgcLYjrJO3duDfKo4cdaCAIb 7d1gTaxj4maQMMaPPZwFt4930HEaXFsT/hjVhVkJD6XiU1EKDFpb8ICQu4ExmqPFnVNekfr7eenp cUDGDDwkV6+II2A48jjwr8JX1uKeF7TcJLrLDo8NbXwUBpdV8FTd4jOMdfDfKnGVN9tP+GUpHoNM 9itV8PsfGdblmfXIkuxvnV60u7ZLniuZnPXRKogO4jUpd+3kZkKAv4xzR1zdE+V/RDKVk4PSylbq ftfyTz7r903rch1Z0zL0qOYJ0m8jyoK0tNN8YiOhfjs+1msY67U+C5N+mA77rNPCG9HU22BNg5Hk XdtzFHvgeEvtcnAke7CMEOnwptbIK0HSpceK/aZXmQLfxFOzv3dZiv4jRv3heJvQNcalIeOw4CsE RxBX8RbJVcRRqvGN7UbMKzCsjrRxTF1AYz8an47R7IyyEgyOiU8V4ZgXq1e1Z6/kDfs7WVamp13R kMUF0Q2GGvckvdPDURkATNmsZbbY6FTbGPEWOPXeeLLgDqElGWeZV+Ptbqd+bhp8yH1sqCZt8OK9 09ob2hiLNH9KnV1hGsrjPDbdKlfFm2YhIxA7qX57K3g7dfbb6RF24+iexGDkNMSP1IeyL/3304CA Nxhh4s5DGWrcwSLGcGvPmcGms+rtGLPRxTyEi9ypVALHFOLU8yBR4Mbq6EN8F54Pu03e2IZiu4aj XEbchXxCPB1dnlaaLTp1ksyvdJ2W8SOpJodRzlYS4r91wEq6cEvEPKlu2zU2MhLE6zMV/RVXIGFS B1UYBxuMMDXe1keY6BFLej+mTIyJGyE39aXTG84VN8qY8FNXpzPGeGhUPiXKCOlz5QJN7jmVIVJ/ rF80lcSwrA1G9NjUoHEWPHecRdfjC8oivAob8C4sG7JhBWpF/EO97IaqGzjQgJbBzlu0u+VUVmSV BB8nfjIdVX6G2Y1FPi1fwJPqqOPReRcFpJL2FAOPK9PjkDF4PAralAfXYNlH2zGs3NL9Ppo813WB LsfA0M9HK1d148ALouSPKAs0baPRrneRTdndd9wbx+gHNmq0BOIoWHsPuswWNkQQU8cyIi2TeGGw UA40ZJvt0POhJEqNFfs4iEwQfJN+GTbdsP1HeKa/DDAIGv+H5eFo4qTHggjab/gTZ6gLKOyH8DAe v8FZlkDGw7D9HFWflk+D7G0dk5T2lzz2TO8ly8r0tGeJIF0DDDXuCZ+42qZxNWXzWHpvUoMH0GJm 03i726mfJxqMEN7DMR1F1cBbV26a07GYCZ8OGYsyV+aZh98U8V6JfinH9tC65yCdaaQ+NHvU/zrd CHiDERiLxjCiRyVEwMRkYZOy4x3MRnes5CJJC3FLiSX5E49ikDT2BLEHz6IVBGnsFyx267oOxOx8 AxJpuqbTnGxIkswvR66TnPkWx3uWr63097yAd8YK4sXIvtfKmRgr8u6wzTKDVZewy9B/RxeeIeif vQHBfDVNQ+Lu3OklRhCH0QBBgsiiYnTchkUoMZ2M6RVMfgXEo2hycZpLfWDs3JCxo+iErxKMceHg oVH49OAm2cm8WOFbrQMVN0DEFunijTfLkQHGqQyR+vuOOWVYHsNg5FjE6vFFDRPm2XYpqyjKOr4H DEFLy3xlgIeT2HUz32SklUBX+aougo8TP5WQlDekwYgarYSyFXj8qCPC2XsXSVKVsW2xjnhN5LhT pPxVcUxYHe1ShiyZO/6t5aQeG/FU5h3d70PKlSi7rsudb9Bzk4o0v3Q/m4uHwWUNoi3pOd2BZ7kS 5tUBHn1XliHDzDhsg6lLTtHd3eKr4B/7bYM0x8G2fvGBEdQW/DPI81EuNMLvDAxGfWV0iv6bkIdR iG8YK7G0kPDWqYhni0YMx+x0gbR8SsfGZK5T9HNEaBIfynb0e65kK/olfyWMiSfzBfHeSCwfW2dW 6chCelQZo8vI4GrouS+qi6R3tS0JNz3G0ui9Ce0cQIuZS48Vty6gn5v9Qe4PMBipN58asik7Pj1o 1INg+C7DpJKvsaPvJgqj/hpb9yTj3KlbjdSHo1Lv059kBLzBCBOIKUTJIhrPqDdGJh3pYjbhPiiO Kd3U8YG0ELeENfLL41WJb10hRyfMxaaOf8GuxGPZqPaR/CY2KoW60HS6FwoqYYYXI9dJFEsmj3aM QA/12HAKUFoWXi3XNd5IQyYvVtbxSWieFNd6Mh8ed50HR23EkTnyWmZj91nSMyZuspi03/qNDXZs JV3i1jEajIIjZkPxKfFGySGOhSaXXGk54xxTRE70i1VDg+4qXoWnwV6ryZvD/CHg/V6bWuFCEvVY scaXYciIBz3URrX4M9L4PpeEXy6umDv0JBcNxp7tkbSoEiIDc5dX+YqKW4JAt9bRHELWWJc6/hOC 9UZBzfNXcYQ1iv8jXlAgXwOcHAtNk6DlpD3H6TT2lX5THTUU2qniv3Vd1niJkg56Hi9x9Dvq7YIj bvQMoi3pOT0WWXYFrh+9CSPlkC+WEMFqDU8WWgqRI7ac6ewOKSOEHNmNSzEqIxKPfZAjlOaijhIp rinfD7lRRzZB3AtKu45sfh9sruANUwmeAUL2bmojnbnpSNo4pi6Qlk9tBA5ur+BIXRSjDt9FxNKM zwZ2rvF+HzefUo+c+NHMqC0d7YGk5lFHM9PS7igq/a0+PO0slKR3tS1ZvulxbMuOWD0xvTeWIrwx gBYzl+YXtw6kn5uyhdwXL+VIjFna1GEgDIMRzZ9SZxfB7y9ik5N6dcrGQX8QLw7RISgspwCZLtV3 BronkcXOfh+pD1M1wmc6oQicKIORCuQHhS/NRwbqGkp5IAsC6mEU1HsveltZsEvU7wxsCioJs/UN bGzQR6Zwkl/ETXC5/+uAbbbyTgVhcrvoYsw1wRitVnSOtsAwyhj1x8h1mjsGqy4hHtHQuYeA6jdW +Ip4k4SkC4tkvRub47UEL6PmbR3wl+JGvS76vlmpg7df4SjBMB5GilfEGBh2AUuU9wKOYYZB94QL fbJRY4UcQxoZN4lfym/tEo2YUI4VkVDc1S5NSpmRSBrhs9H5FHwmcZNHTI2KunyDvP7cKa9I/aKN K44YAntkvCXJAqPaEX70G1/GURwrKKLhdbFgv6KYEAAjuQiivyI8JHYVpyEBlVHitfbmW8NECV0o W5ofLYM6qUJejjQvyEz4dr2S2PQYIImzuAR/ys0AOa6X78AAfUfLlfD+4KPCATlKTgqMhiRQeay5 DX5dyKgGYvVsNCwDgqorQR4Nej4kef2SaQOGW8kXsl3E1GrYBtJBtCU9NzwwMZ86ZJSk9+DuBq/C A6m6mZ2HkW4v5EPSnEbe9uNU/iWBKb61jMAcAl63YxwJAzt9G1C/WGyiesmnwsgy3IfICudGEF6S cLcRxExTb/kZruA+qYhsT5Rv0DfUUZdVrUeg1Mx0gbR8arSMbCAGui760YmjkWnsH3rcHhOf4vil lKs510Yp3lpF34rcT1ampn1s1EgBRDdw6g4kaXBJ0jvblijfxtN7bTKGosXIRHjNYWClBntbZjSj FwgF86VLNsHErvVfIb9MmTMun2rdNXmdpbyFRZwlqgIZGIz6g2CWVvdElVIWO8fXoPE0Ksk+/alB YKIGoy7O2zexwx38YRerFr3qUMRr2BK7WvKZY3crQFjs5sg0rS1ekZP0IlxOd8P8sd3zaPd9i7zW unh9g++hDvmqSVG2ZngIEwRvbdAjJWm7F8p28458zW4O1mfQ6Ci3c2+Pb5BAmeIVxQfilfHRhwoz huMuwatsxTPhqXSdHIWJuToSBUsoCOL8rHgNLvmI3TH15hcRN8NhjOg+jPoNfdRY17FxxJGhsM/2 DCxJ8ekvcfxIjpOtNd1GXWdUN/B0fboNvVsiJpEy+vxAnG9C+4LXdW/DddR4Qx5iWJFjYcYEJPLf QH68qSvI2xBBR+WbU4Arnos34KkPMdSIZ3m8frgZvH4YdYsYUndxtOCKPgYo0izTGQRj9sDgBwRv JEGDVxXuEQZWnyo6cKGNiSGdoi7na92jTOPiRuse9Vp7XIBW7Ohu3MUbTfB2kybijdl4S5lB+WTU +lT6DPiU4iz6W/BZB29kadx2BJvHa0ubu3vB21oUDWRSFn0UjpsVBEvc4BtYsC9b4624ltFC9Gvg i7FmjK9NeCEZY8qUI0J+BuM5IN5ahEDGiH4LZCvGsVi0169XiIxB267SoNtm2UHbcdyniuDBG5tY dF81+US8yYxwGvjZ4hXMCzKoey7AWcqo8LvjkG+qD/AWOol9+O2Whyr92BdoO+FrcXx2S4hnS36Y u6m60sBjRM2He3zrhsYqmOOoDEmQk1wtRAXP4VXEeEW7MBIJnlteyhM88nqzAs91XZjXII8OiFFG xNXZWtPzxCrGk3gzUdYfvZiDoRGeEkK+BzF9wHNG0Pwc8WAZk/bGdROT1dvRsVkx1iGrtm6ucvPN gv1iaoyGCG2vGCvVO5ABZDyLXWw59sX4NQK4j1ZVLPUB+Lgae9sqdtQRzLVxp8G3gLlcpIe8A+MA oQ2DSut3YswicDfdcd+gYxXPD0w1JaLHlBUV6EkdePcK2jZumC8b6O+FGGtenxtmnSx6XbfCHTpY g4x1+y2SNi+PrAtIytLwqcwrv2MG6mRPXpkli286bo+HT7U3rxiLJaH7QXcLx4k1F4nn2Cy01wOy 3alol5lTfos3uqm1kOAVcsyUkbWOTEPntFB2V9V8K+YBqiN1oZNofTqS3eTc/1h6r2ivzed4gYlc XwicAy9oNWfFdXe61sktirc3QwcMaK6Ec5Fc82HjdIOupbr6JEYof4RsEsHogeV2jZdUvlC3Ehtu Rn5rzh2VT+k4YTAI1SCb1foScvDgTlVvejkNOykHC7KNpXuiv/agM5UlPmJ8QQdQH6EfGn2I8USf q4T+4mlEYHIGIyyI6C5xyNSSee1vdwBqelQoOT+8bIiioo9M2HVgl44u0nGQZDlaqMmyx1M6oGhI rwOrXFqvdg+16StphQvYUUVQ0md/x1/XaCk7io48LywUlCCX5bh3BEmgOJXfphVGkaHjhQzHVtr9 Pl6XpFd+m8fwdPkNsoCSaZO+8zHXbHiFyONPfdotyiuvNXWl0VWnUSWLrQFtgBGQeo4NN85pmWQx Z1OC4I9mmxM8Aki+8XAjBY16mSr4YNFp5By+6oz41PBSpH3T55oaeB0GI7PfdDkuL5zh20tTJrdd vP7VEI/Ec0HSpbzq4HmhF3+aTpnO/M7z+i41+STJKEc5CytaJkbNGJVXBskpudMmaHbLQ4rf+NeG 9xbiL4SqmmmEKzrky+hBjJOOqZlxqsy+In2AN9gFvYYAm2WXPJRxsZLmefl8fMh0CbEFMKGX0Fha j+RzJrRjp9ow8rnrlDhWbsbnBt2A0a6SdJk85vK8VPhlu6lsGa2aWGqDx1wvIJB1qu8i31JvDQ2L G2U+D7CjRj5Ckb2hIXG2v2uGjCEFjHxJjnyo9oV9Hg8q6z4OM44uoMkdkU91RnUVw24p7s2pEmd5 MQE+NeSq1W/2WJG/nd6ko9I+Nm7D6duSZvGt57SkvJHOlySbGTVqj6f3jsrnSoeQuBlxLBNkK5F1 tM+G5jOanxwtHjq/GE+Wzq7DKZg0x2XEgDfQSRxG+R5D90zqr9AzLUk/tHTDUWj1aU8VAhM0GO1p j6CBArxsGH0UwtgBltZqKjCN69iRCdPTRKfFUSNbqcDimu6SLW8TS6siYviLemxHTggTq96HW0ad ij5YeumyikPZrSqPLFMoCW+MLQRIdX1cxyxUHbIfsKNft48ckMLqKp6HVa/Mj++VMbEi1QWXw0/4 hb5vduvgaID5tifahjwvI+B0IwE7QYjYGSiSCYZiVwyCKbpxDxohXndu7NLTuhFM9zKO58AbI/bB 28oGjnOCvfAMMHZzrQJpAEiny6mVXvwcFzdHkcPdAmbL0VuzKNYsV8SOOjxXMDka2IBPxuNSzrPi 087dupOXc4sIgg0PjIOb0S5Z1HdF+pp6YjCq3sWuD3Z1RIBVgYFUOvIop1/A2+EANlM1iGejgTdc wqnhXeQ62CZHArGLtkVjBWCnfeO69ioxy4JSi1dRV+FponbdFBnaYCQMIx0E9l1eKgZ9LNudu4i+ hyeH82OPB8oXjuvKbQe/qYKpoabPq8NV+gwuSIwoGqOOHv8JgnDbVY1sXMUxT2sRr4rs7kFOFSzD spBVOV66sgrvX8ph6C/L2y3oa+n5lUBX/srRLE67iB1Rvmh6ewb05Aq8cr3Om8RTF9vfmdHevL2a vAGG8bqyhp3YjL2qDta1B5nNX/p3jq/cpB58qpfTX9g8Bi+bLezau+bFImJwueaivZvJskHTrufH fuPlAF7RVE+T+XMLJb6KtlOPi/SN1jkbV+X4ysUNc5GMyS8K77wj0AU0GRi+o/ApzRheGy94Ad3x DcZ4nqzuTIJPmzfto73h+BJ62wFi8NhvZK0mnDEdjfbxERtG35ZjXnwvk+PrzrzyKCVkszqVQeZG F6+l1XuH19tFX7jnJLceleermw1eu2LOU7EXAbXhLePaqMcaZ6O1x2vWWiaWP6XO3iHHyHOu+Ujg fbEEz6N++kf6sePGDLrjAN1zj5wY0WNKr6nqrjXngPVG+lb4nCcNgTOCIAwM/zmlCPQO26y1+yCg vvuEsdlvn2PzL84kt+bBDlv7fYudfSPPLrw6ww7vt9h+u8emvslYp8PY3Llz7NzZPvmTSz5VTwRu 7Qc9NvvCFOv2GJuemWUzz08N3YbeV8iPfLPPMdZl0yhnhk3heqhP75C17wNs1Ml6yP18VPew+Yeq pE+iJ4es1WqzHsbLfG6eDd9qkDsmbn2o6vtI4N15Ms3YkwivmVGo7lv0kT88vN9m3SnQLvr6hTk2 FOlPWuy9b7zGPgF12HVjxe9a7UXfseMaL+Mg9KQHPsNYe26WzYJTus+BV2b68UqPrb09zd79HRy5 rzdZbXHerP0Y293b+YRNn38vqB/HNtnyj+ZMWo7o1+EXLdbuQhbPz7MZ2ccRz7JvzLD5V4+HDoa+ OzyEkBM0PDc1knw8ImiGL7YH2h+Bdnymnsd4s9hn+IJGS3mIsd55hHkBU2gX8ioY60dV95M22/zd H9nh2RwrvDnPhIzcv/cAk9kU62Eyn/obzOUvzQ0/L43WVGfq3qNDBuiDz1RfPndmH+umqhvjNehz yTtjlerIDF5sf9llsxJbMdYOO+jvMO30DGT88458rltZ6AKp+PSQfZKfZe/9ISJqscb4dZjdjvtz 3Hwq5qMvO9D3wJ898Cd03aH1Nhub46bdrn8Cv8fSe8ek9xDyTfDYNHSIGejbo3xCutHfz0EHmZpl c0MpYaSGFHzaht6n9L2ARyEjItnIoPOPTAMhZ9jLVLrnsIX7dM8cAt5g9Mx1uW+wR8AjcOIRIAYj HLFk77x6VKvOk4fE2ttnQoPRDRiMfmoZjI6N3B4WVNPRgqrCxMGrYzLTHFsLfUUeAY/AM4rAox32 1jfPs1tR86u7nL3zyjOKhW+2R8Aj4BHwCAxEwBuMBkLkE3gEPAIegWNEALv0+7ub7NL5S2wH1ZbW Gqz0xky0cz/Lzr0y2u7aMVI+XlXB7m+L/Y+3z7P3RcOXqmzvn96EZ1YP3nBTaPfReksc3t8PvAan 4I7Sa62x1/7+l2F7sPt+cDV/LDuC4wHoc3sEPAIegcEI9P4M78n/7b0w4UKVdX/7zkiexoNr8Ck8 Ah4Bj4BH4GlCwBuMnqbe9G3xCHgETjkCOJIFz5Z35VEBR2ucR9Qc6U7brdbHb7HXfib3vOPUI5gn q9tH1OLJ0t15cIudmXurb97aPc4KL/ZN4h96BDwCHoGTj8BXO+yXf3+efQTD/LPmwXryO8dT6BHw CHgETh4C3mB08vrEU+QR8Ag8swj02PrPptmlj5MAyLH6vQbLP4WGi/1Pf8lefuejpIazMuIIVY4q jhCOaFzCEY31xNoLbKtTY68/pc5dic32DzwCHoGnFwERd+moYj09vaj5lnkEPAIegWcOAW8weua6 3DfYI+AROPEICEU+6fM0K/iTbHe/ukVfPM24J401f98j4BHwCHgEPAIeAY+AR+CZRsAbjJ7p7veN 9wh4BDwCHgGPgEfAI+AR8Ah4BDwCHgGPgEfAIxBHwBuM4pj4Ox4Bj4BHwCPgEfAIeAQ8Ah4Bj4BH wCPgEfAIeASeaQS8weiZ7n7feI+AR8Aj4BHwCHgEPAIeAY+AR8Aj4BHwCHgEPAJxBLzBKI6Jv+MR 8Ah4BDwCHgGPgEfAI+AR8Ah4BDwCHgGPgEfgmUbAG4ye6e73jfcIeAQ8Ah4Bj4BHwCPgEfAIeAQ8 Ah4Bj4BHwCMQR8AbjOKY+DseAY+AR8Aj4BHwCHgEPAIeAY+AR8Aj4BHwCHgEnmkEvMHome7+p6jx vR47xJ/8TD0/w6b8a7AlHP7bI5ANAk/AZ4cRn4G/Thqf9Q4PmZQCJ422bDrAl3LiEBA88UiOOk3d qR5/fj7VHemvEhG4VT7P3vpwB8/LbO9xhZ07yTrXCeVTOmdhRmUzM1OJeB/rAwOvE0TXMCA8YZDJ h1HKU0b7MO3zaeII+D6PY5LxHW8wyhhQX9wEEHjSYpe+8Rpbp1Uv1Bj/bYHe8dceAY9ASgQO/7rJ fv3fPmLvf3wrVkJpfY8t//hc7P5x32j/x/vsW3//gao2f63J6v91Xv32Fx6B7BHosfW3p9ml38VL zl/H+Fs8hePPz6fxzvR3HAj02BrG/rvR2K+2uuydV0+IsSNG7cnk09ZvLrHX/sHQXFl1l7N3Xok1 4JhvoG/z6Ns/6GpX73ZZ8bsntX81neJqs3yG/eBDfW8FtP/8lNCuqfZXoyDg+3wUtNKlnYjBqIfF xyf/0WJTU8MJnx52u+Z/+C678OqMbmVvn63/5hZrwyLftxTknX71Anvnh1pxa/1+jW1+2UX9urjw qseEk8rsi/Ps7968wM6R6uyUY/1+BNo/3QTtYj9Bf0Td8//HJXbhuwkVPzlkt/69yvZdbUbmHu7P fec8u/BGjs2c5J0e3eRsrlwK7sUq6956x8A3m8qOuZRHLbb275usGx+sESHTbPr5KfbSqzl2/rvn LK+qHtv+tMp2HpnjTAzykCfOsc3fVFkL406NQ/VM8Mth9HwAjylIxBg8xwr/mGdzGY2/3hfbrPoH 7GBa7UcL2IWFd9h8AquwZ5xX2p+ts/X/r2PDpnpKXvR6wPGnfXAUo+Dzj9js938ps8S/c6us2yjq MRRPMfqdJ/vsg++/zN5nFbZ3pzzUznX7jx+wb114X9VVwIK9dhoW7MZYFcx4juUXwEOKKaMmId3m pzXFr0Hf/SP67nnV5FN3cbhzi1X/J2Y0i79VQ6am2ezMWXZu/jzLvZLE7Cr1BC6wEP0ZDEYfx6s+ NePPJv1pnk/ttp7W3/dvsbe+/RZrX66zxgf5ibXi1j+dYW/9Kqz+ZBg6kqA4mXzqMhidDMOMaQwU qE6MrhS6wOa/nWc/+Bfh+RZ+jp92oXuvs52vrHWmoV9L6szvfnOiWAtPzcyx83934YTOh2ZbUv9K Id8m3+epW3t6MvIJfJrX8hwIjfa3UOVdQmu3sTJC/hWdt9vguSHrLl7d0PlI3eNedu/2o73MDx67 a+ifz8Rz5XbTXcjTerfb5d2v93glF+Fw0Rwvp7XZo/Q5Yzlu9Hvfsb7Ku4+bHKqmg48ifkF+93NX Hn1vpUE5dTzkm9dyDvqiupY2EgsfBTcDs8QST9ODLl9x9qvuIyp/l/v2V5dXF3S+0vUNvtc+4Ae7 Tb61WefVtRpv3MuuvyXK3VZV9Tt2ruXtwd/dPb4cyQAs2AenPwEpXGM1d7URo2xvragwkf3Xv+9i RZywG12+KuX1MON1YSVxbpxowzBfdzsd3sGfmINO2/hzYveUzqfOtp7Cm80bUhYUeXME8Zh1U7eu lXj+Yp7nF08ob9IGn1A+7YLX9m5XlGyHcYNSPblrgde9DaUDToqutLqAoF2u9Y6d9r66N+P1dlK3 jjAngueaXyeVc7rvp5VvE+3z0w35UNRPxMPo8PM1Vvm0yQ7/+gH7JHJ5LCyV2fy0bWjrsZ0PP2LB IQjbY+SwxX79f3/C9rvYkJ0WW7E9dgtpQ5tynpUu54Id7173AZv73s9Z6ScQHcEHlt/ffMT+93/Q O9HFyxU2f3aG9R7ss21ZX5Sa5ZbZwZ1SZh4TQbFf7bCPPqyyzvQs2vd+2D5ZH75X7nTYz7/n2E19 0mZr//oL9u6H0oU1z8pXLrA5JG3vb7MPfiXvh4Xlr2yw+j9fICU/7ZdkV8QeL6e16WqsHLIPPvwk bEWuwMoXQ4+53sMW++hjs9/Ltw9Y5YdzTHjZrP9qmTXaDzA2orwoobBUYhfeLLKf/wgeRv82jZ0Y 3BTsAebJLRTZuz8Bv/w4x3p/XWPT8+8GdVL+bP3hA7Yebd4UL5fZWZGi21LjL8vdnFBWNNjULGMf /MtHAS36X541vq6znMvD4hnnldbvf80++eM+Y5CNgXTcvcU++l0kHRdLLPc3uNsVHmFz7N3L+P2C RtW4grfBezjuKUZP7soWa/zz68bjo/pBx95o40nLgFPj4SE8h/59mf3gZ+FxupAV7Zggh+zX52fZ L3YiRgXDVq69z/7PxULcE+moOuUIyj388yar/b8t9tnPfhGMMVFF4coKy4vpD0P0QWuTvU/ntcUa 614vBGP6CMjJoMhTOP4SW63bwp6W+TSxrafrQes37+Eok5DKBdbo1lhOCHn/GQEBPbZPxDwBXetM pGuNNt+N0OQ0Scn8Pym6UusCk6Qdc/qa0L0PAfrOB+wjcrRPdEP+WgPH5cVcHv+0P1tjv3j9XRVi I79YZhf+Fvp8r822P4PubZSVZxv36uzCi/FyTvOd1PJtkn1+mgEfkvaJGIwUbV9ASP6tWJAWWPNx jc07jrHsf/oee/kdTIwLOGL02/5HjNbePhOcpy7cwFGEn+ojaKo+cqHKZUXUvWrU3d5ZZ/98/pJS YI9yobTz3y+x8/+XueBnUIo5lOKkj2ynwIQDE/VBkLodLBTPF/Txkcpmh5XfdBifVKaUF4dt1tpt sdYXD1jvUZfBboejUedY7oevs/kX3NrL4YM260TBQYVb5RzSHd5vse0/7bA2yhBWgfNv5lnuRXd+ g1IEtNu/38aCF9kQ4Hru7FxwHEthc4QKbvsLtLvVYg8Q/LfbC1qOo4A5duHv5o90ISPbFhvfQb9/ hH6XRtASAlAuG8d4ZF5zzMCgVH6XXfowjEtTuLbFav9VGwT0RG3yiOIdOv6OXFD32Cc4U/+eMVky VlzbY6s/SY6f4243Bs1x8ooxcCf0Q8lasy8HUtPbYZemzwfKy7HGKlL0shFjOpCFwI09zAPn2P7O JvvsL/vCPsamXzjH3rwII/sQIqa9s83++JcW6wilD5JmCnnPv/E65NMRyFPUsP6zM8bRptUGYkbI leCDW+z83FvRhoigBzzOwePi0v6MKpuRfv8rIUnFB8eaX4EsFZdCxkJm956YMlY8yvqjZIpjPmbY HHr/wmvsg8DemWMbDxvsQoKB8/CLHbb9eQvtwXFMQSTmlHP/6U12IQeF2/Fp398PjqGLR1MvYE4S AWfR3sOv2qyNAOoCjxnMLcF9R/74LTL++h2JhPxpfxnOX7SM2RfPMRXzNsC/Qx8HxxHEvJn5Z6z5 FG35cwM89mUwVgLacIww9z3oAmeHoPUQG3V/+oy1vuywXpAcffbKPHt9iKP1va/2WeOzHdZ6EOI0 jT6cfyXHzs4esh3oFVPfyScf8U8DIhaCbUFnkDfiFdxrfb7Ndv7SDvSg2ZfOs/yb2LB06LNmlelx 68svZiWZ/+pBXrSVvAiLl/pcYmVZ4gbe2Yds/uyvkUzHsdWz6PPzuXk2g0APOzv7bGb+9QEhJYbk UzSoF8iCSD4KeULlvyE7kdh+7gDkEDKnHejBRLaQ+a6fYWZU+eaofrRbRK+rthBb6VVkh6xog98C RNDeOWy2Dx7rkKnQmxt/3mEPHkUkPDfD5nM5lnvVLZsVoQSbkY49UtpFXKiXhEzYxpol4tNXXgef Hq3OLtrQ2/mETZ9/TzUnvChh3blsrDuNBLTNEvcoQe/+Dvv1lSL75cfhBiBjy6zDSxj78U8wXv7c Ar+G65TZs2eBOfiks8/++L8esNyPCslhHeLFHdud1PItqz6HvArHyj4LNAkM9tmXoDu+ETpoHBsQ J62iofyQjiiRdjUscHoqotNq8K3GXlCrck27iCM0fenQRyeGOYqgymVm3aqKxwf6eBPL862OepLd BY4EFSNX/PLtPd64XojcUnN842FSNbqd2PVzY9LWrpjwkOLZkt7htcv9jxQWr8ePU/Cu4/gTXJnB D7E/Z34Jx9dNvrrkzle5UeWVi1F5SdjIclJ8d+/WlHuui26YL/hWYr+lqNDIovs9aXxvXZG42GNa 59VjpsNXyVGjgqPPkvhT8Q7FGP0LE2fQl1B4DMoz+bGrjyjV7x3wquxn1m98u9ptUXOkvGLVNcGf SX3pJMmQfXH+NMb+wmp28gX1bqxXccytypcXSb2Ly8G9Kvhb/9X5nnOY0T4v8TIZ45ruHK82kqVi B3wux7LOQ+k5CldwQnfER7nL+sil4jklL20eFz2ZRjajXutYWHltI0HG5vjy+tEc89Ptc7ULRyPI EXQY0uLD9mGDLzv7WvZbkW+0zD7v3l01555chW/cXFHHGGjf5zAGG0PJdt2PSXJaEN+8Ied6SV/0 vViL2oZylIyjafLZHkEacz49uFPtOyfm+h2beIzxejUBh2CcW0esaa9DVlSX+hxXlnySG6Q30kIH XzevyzlW90ne4p9w3BT7jpdUuD1s8pqQgZCPUm8UdRWvUrkYXa833Lrh4Cb2T0F0Vsof2PTtOy6P CzdFkxXCIt6o4fiUx47t58laJS47RViARsIxob3NVTevLFQwr5WVLHLqTynkW7zNKe6Q/q6s1/nK oovnwKc3k+eFbnuLl52yLOKhXFw28yx0AUJ7/nIlYU4v8T6qQArA7CwYI1KXwXx+0NBzDjbz7cTq t9bXGHeOB6TcuKL7YnnbKguYl5xyScstwSt4MYiqc+IXWci3DPq8ub6seFHJEzmfCHl7bSM7nXfi oI9GABstebapNVPgHLaK23MAW6kY1FCMcO9gvRR0Hlz4BlQ+5AQQlUIV1KQz4F3C3PDqGFD/6I87 23JgwiAlJpl2XQ3UZGVTt1Mv/uN1N65pRWykGCDxosw7sbg2OV5cKvPSghZegslWbCkMRg771RRY AUPmcAbeEm7ORcFu3anMx5halEWNGWYLUv+yY2/lLhZ5+XLJpAkKqiW6U9dnZtT9njQ2dIwTW3nT edmCWJCYxqLiDTdvaf40y1O8QzEmgjrT8RaBsHU1UtRzKwG+BzdDuSD6PmlCxTJTx9+htJrA8iPj FaueSf5M6ksnTTEed/BsIKPFfYwNJbudpQ190xXLJ8bbql7GC2vhpoJZAelzkjYH4zQcwJV8FcZd F917N7XiHtad5+Wry3z5sowZIssoZLyJIOnO8cq1SkSrpLETxcWBYn5jOXpm8mSAQazfhpHNXV5b km0a8nspYaPC7IiRfimZkrCB09mUc6WD3x3zAo6Z8+Wr5dgCDce9NV27NT0erPknadxVBxrDZT9i fPaJoUXbQ+sqED1nw7Uxgw2gpBiHumFDXjlwo7So64T5VG9wyXEDXrlS4eUlrXuEZeR4/Z5F0+M9 Xjb4EYuXxTJfvrbMS9bi0qX7NWgcTCw4VxBLrXpjJaaHwKM2U8PJ3pqedxQ+UTuEjDHuJWxypsWt bzw/C0tBB7wxjuDT4StW/4Rtdht6JQFZ4NaM1gIGxrmcJdejsdhnvg9pGo5PeWycUrkL2SmNAQT/ uD7SxeLeGhskvdEe3I/ld/DpUPJNgj/ON9HrbDpjvx3zQueONpDI9IL2iq03o92V2weK0kx0gQTa 8xfNtUrWMkI1Qlx0ttT4XN4WGx1yfYtx2kc2aX3NMR5kBV83tBHMKAs8Suaz3CIMkuuQj9Ar7I2w fnOUrOa4vjORb2P1eZfXL1tjA2u8CvS/su2kANlONInjgmji9ZwQgxF2Ltfq2N3b4HVlaSeCGUHh Bn+GnACigqiCmmQwErsLksGyNxiBXjnZLFYjqnBPTcZJwa91O/saRdIGjR0ENHYFq1AIi0sVXr9j Ltg6De0FwpbqzpI6xAgndmOq23qSaN7Ugf8Y2V0PCrIn7gXs+O4iyCgWq512k1cj5ToHBSKYmAYq DE7y+t7sYDe1IATIdXg3UGkhMCE7LzVbOe5b6rAPdb8nCfm62nG1lTedVxhiqXGv3GdniN+TCyq6 qyZ2x6PFs4GxDtZXy1pRJZNAcS0y3GJxLHmTJQa/Ju02aLUwPypesaqZ5E+tgBC52ocg4eXZuIO/ xgYvS+VjcZU37kb3xTP8Ne9RRuhT4DCPsItaWSrx0uUyL8o6hWKNBWEZ9/Qf0kAJ2nIGjiR9HuSt 8EY7mj+ERwNRCGLB2R8Sz0zkjQVDx65njSr+hpI2TAP7pIF8kwb1agPeMlH7g6DWciMBxtLmXSlj Hf04jmzuaH6ShrXltS1+III5P4Tnl5qXwwVZ1vOhkikOA2Rnd0PzOuaMDaPf4Qks+jn6C3b/DANm lzfWybwiDIWWOqEW8HLuwNyy1TpAAOsOP7iL8a/mZFFPPL/Zq3r8JclpnR6Ge1J2bKGIhNQLyuUF qssa8WrM+bSrxmGI/bI9jyD4t+kBBEMXIZHujjPhhWSJkYOG6c1rbkKQBRF0J6s7+cE2WaT2k/uE ntEuzX7LYaF8IImAx5bycsZYtYPbjoOb0D9KkI/2JlVuUdwj8jGQoaDJ4IPRWjgwdVS2Ntw55FGs kPS48Xt6M1XweuFKDbJJVxDz2BrY76PwKXRM5eHoaCew6NzRL7Kx+Zhubgnal+H91fkaA6bb4c1N 6aGnDV9m/vHlm0YpxRXRvcJ5IcdXb4N+QT7ob1gemca8QHU00WdX67xDx+TjLt+6Tg2w5GRFFroA oV3gnr+MMSP5FPOd0msSNilSoBXL0lQvqpCbP9Cf1UmS5ODXWl/rYzCiG6JUF4EhSb6sRunLijKB ud78GjxHqYxHfpGJfBujzzubpp4Q80huQz8l87Ux1o8cnZNRwQkxGGmFTyp+g1xc4/CNNgEYCqoU IrFC5c4u6LvsNoDEsgx7o6MXJ9SdkA5aYzdUlavb2ddghMWPFBrlm1RVUwWNfwGBf4DjQcHfQ8ze YsEijwUkTNhUEMbb9/+zdzUhciTZOQbGIMEsSOCDBXtZswZ7wIaeo8HXBdXiSw+6zIIvrfHFvjS9 J/VNtH0Q7YvcJ7kHG5mWYaF0aKgxCEq30kGHEmih2iBTs6ChNTALJVhBNXgg/b2siogvIiPypzK7 1OqJgu7KysyIePHFixcvXrx4Ea/bKa38b0Tawij+GBxKsWlf82yOSVReb5wYNYN3GCuC7oDfQWF5 FhYbX8jPZ6fZgF37efDw0tr+tehzWw9GBYXbUDxfbBEaPHMNg6bveG18+nwId3mcohVxyTb5Nrxg T7whKYkj45ILg1awTItZKT+so680rHPXr9t+F1B4KwrTfXqtAyRtQUTshAYfanNM7gu7l0iZ8vuR 8WKD/Ii7i+MEOlIaOjMO05bOo1dzo1Ru3B1k46XSmeP/usRgxCg1lc2OotXLhgGj9xweOdqYVG04 YWKqr41MEdl9ayufGMvkeJMNh3i2cW/kZGZlAyYEd+0WPucl/GAvwp3H7njIZYfzcFcey/uB5T+f v3ya5DePG4hd6L3CHgx2wuG9tNLPduOpraOMJ3tPXTwtQe57u9qDgFbdy7bMz2kS7ixAkbGLt23a coErFq9yXvUXnvilla+pXqGVZlqAcHUBSrcKbkSv9Sbuli+oiFqXtu/UGVeo/o1wy7LB9kJfEX7b inn7s8dgxLvLVsrSUqufmjYN19OOr94EH4sM1pMOBkTI9sKHjPVSP+aZLuRbobwmN7xxIRhyAdv6 9VyDxwXLo5DbJbLZ8hDaONRfV9UFmPaCTgwZQfKFMW8CT/m7dv6IOLj2VVqYCnlPyotRfrK55FdW ZyEHAzKuGpnrpZs8XBjqzm1u6JXX9KflnYbybeU2t20li+rRkDCOF/dONmUDaNNKfoDvXxiD0d6D o6wvbsXG4hwWzHGMmw0AVkiVlWPzZPfByfFh7qa2L1sVKv727h4E97JbyzMmuzIJFsaTP5rQFBVI qT3R5E3Y5an5UMcpV3BNitoX02dY6aJJk2+EyH9HaLOCMCwITLs46anOshoQNA4I+bQa46SvXbXy F2fwZLrHKyJWiWEMzmfwYQwwAMtRtrLNxptQCR3uaqxUyaY1Hlh4z9AcGqRLkAi3UThB+75iaVd6 u9+yr/DqO4JfBwigtGX8cI59JUDUe7ll+12ZvAuRZjGso1iHcljlnqXXVaCr87L0huWn3VLh1ofS yaQEXoSD437Whys3/w2e9J34IZ31deLB3EBmvPtsP+2LZ41RnsPtuLJspvIR3DwKs+n7PLGBXDzE VqSqsXDxfA/bh4pbYDlfI5dYRuF6N7B11okFBA+44fHAaS9puwE8lw+1Ny/ycdudPCZViQIIg56J G1M6GbV85JcTBtW+L/V2vDNNW4MftWdlOJOGd7nMFcZT4hW13CIcJYAmL73lFj3u2zLBHDwptlkf bdanlXjX4M/0o39gS7tsczl4cJgdQo88grf6aDyBB0pgch4ltMkDW35QtyJ8HPlA91fBjSm0/cX3 Jua3zv+a6fA994qlr4gbNn8YIz3ijMXMk1LeZLllMGz4ZYqIlpKtozqF5dmw3LXPvfHKGJokXkxR 7un8T59Y7wbmmS7kmy5jpW/i2Z2ShecpbRdc0M/G7ooYsGxUC+hpUWyrKkS0B/VDGOq0oYsxr8q2 9nNq+zxEh57jgZ/tTpKd4Nb4unW2/Q/zKS3uUG/jfY8xZePmJrYK70M2LuSjyNYxPGjPTTzWBij+ oq1XQ/m2apt7mB0Co4Gn+/URw0tiHFr9pCFt8ep+ME8uiMGIjQd6j6e7DaYa0WYDADOk6Wh+IcR8 VjFAOVXGEnRSy1TY2lCIe8DWTPddTidbtoqWTltPV4nyiCdh1aUwHNKWDkOrduXnegcEv1BoBWF4 4DXt4qSnOkNB1XLRq7Hknh1qA4qTvvhm4zscHJnqGTLYdIm3pZMwoPJNG+De1t2jbPJ9CB037T4C rM8xydvTWCFtfJXYUqCvwm2kn/I3ym3bV2g1hutavA4Fv6Z6l/HDOfUVRuJ9X1f1uzh9FsN6E+B4 Tk2eWHo9BbwyE6I3uBJNz3miQF4LRd6Ky+jCtrZK+iIv0FizkB/eGKEPLzC8WpSfrWQzlV80OBPN ZMTQco4Nt7WwCxhcjEwRWfR4lI2f9r2tYGG5z54HtcpG/hvexM2UHViFtjW3fMOLR/a5vrLv1e0v zOvWk4YnXKwf6XLafFsaxXARGjEWuUfGU1Kue4HDEhzKiK/0ljr2bqrbZrJYwHSKt1udtLudGtp0 zSx+wTamOus+kqdsiZsuXb4Nz8oWTgaGX1rDdTM6VsSNvC9LdV5dX5mYV34qaPHS2z4axts+d8cr vl82VjhB/Wm+0IV886rS7Cfxcum4YMYlXX+LrwrIe5eI8ncZQ6c/uZkUf1XRTs8b5VssKXjHesDH 9QeRYSFv5np1Jty8sWv62I/FGKKhV3r4R7BSa7rZTK4QUdSmQX6l506bBxboqseXpjYKovMDvbwg BiNXCMvWlj72ycrn9IkE+dzIqgd+23mCg7jXQLUYkiarNk+U03QS7O2LYGFQxZS2XF0BW8+ywZO3 tjkdQ2ezyreOpQEhJ1sGj55NXCs19jSb4H6RCbqtu9vmmhzTLk56qnOFgmvaxkmvc1/9mwfunhhm 3tDeKCgos5PB+a5WQF3WW4M2sBd7+nqaTU4m+d8U2wIlllP8Y9MKz5gPr5pXxuYwqayyWokxym3Z Vww/5DwXGvTsvSKfu/WO6dXn0lcsXBfiqqrfxYm0GBZlUTxV2yeWXq2A1s2xit7Yc1rFBq/t3Duo 8JiBR839o+62XwYUGV5d1gsWFhdaURRo2spmKj+oaGn4CxMDmOn908aq+qo3+ZesbT9n44gb80Rj oEmRbxtDBYag7f3soMrjF+068raFmLI9pZvLYS/Nrg1GTt7ALo97Y7Yedu1dJLWyfaDKYGTkN8t6 msCXbTXJ8SO+0u9yvBe1sZMdINB1qXcaVsePvG3Red7YMj14gECufhBbj/+6D/5s8QvKRKqzMya1 xC2v8/Kf4dkfg8GI8Czve4xQ1XVFG3rJrdwN6632uTte8f395zENBD0yIFeFhC7km1eVZj8J+2bj gsW3bNvpghj3Xd+DLIZNZUWIdqcf6oRVz/V7q3xT3lVzvBBP16vzqYl1GJoLzhFz5/DuDg4U8gI5 O/KxxKt2lXp3lGZl+Ua4N2pz8jaTLWn79yv0P3hUHyDGY7xHdwTEBcvmQhqMGCOjNLPCwi+Yayt0 goO4eW9xUYchecWWXcXn32Oy/nIxWdeT9uj3S3hzeJN5a3neRbDHeR5ccybBRfM/+T21LriK9qbm pNt6hoTEona0NavMzd7DpOqnPenCDzxqU5qj3SPtZQVheOA17eKkpzoHva6W5bMBxElv6VvpioSQ VnoL+VBMqqCgKiRoesNiEJo4ledm0/o8w/u4nX3WJRmG2yicoF1fgZfFcnCTuFUzBL+fm36C/oLA kfPXtH++EPw6Xm9Lbd2+gpNOHuDUJQy+sq1v6x4FULSZXdirqn4XJ9xiWEeuxvNp+IQ8CEoV1UK2 VfTGntv7SmRuId9zvkEyxsgPxIQbyba445EJFmrb0d162lo2U/m9e/GtExys2NI5z6YndcfDSTbV QcgJUiNT/Akwx7sJBBE2+kHgGWVfemnLLtk6QYtHvgx1M7d81Ki/kOfWxp3D7GBbK/nhLQtumU1/ WRrDXszL/GLjKW8hqdAv2Dik8eC4TavG0BjeR3wrBJumZRsLgixccWDXoKehfb35lcVP18nJg/qS 6SPyQkvcuAy7BYgNrPzGeq5t3wnrcy4VK+ImBk6z8BSIS+cWAv0ZeoGnc3uv4GcFLV4CK3cjMiJi 8LHpYNCuGceHeaYL+eZVpdlP4uWyLXUcI07T78yfAjHxDCEchiOkt6+qCxDtmiZTplxUPXdebvbD LkJuZP0THM4DnrRzPPwWGaVP/tWLBFQE802Qdrxry8ACF28jh5w5+BKH20S8P+ezKbZo6/EFegR5 tBEJ5vL0yUG2+eUyriC+txBX8bwNJSvLt6o2jT0nY34wjpZB48d98V4NRjYeQ3zQM8GvQoLEazvt gVFnQm3yFQW1MLggkvwyKFhuHS5defSIqPpJDFsWl4CP3T3wViZ0PUOW6Qyrbnw6SVkZVaT6z210 fwQFC2hqp09pfycwC36MYhxuc9MuXnob8wkeJbcOAyeAyOltVggKNp196LSHoFEFmB/oYN8Q/s2C 9NanUrd7Hf72c9Vpi7hYxUl4vXD8sZ8RfsfaKPBqu1ukhJVhaoyUWBnw41txvQuDXIO+Mn1sT5bQ K0b+1pZ2lT3n1BX9rqx0jeEqfFeWb+kzkpPBSSUUrgk8UQfwRPXbtYre2HNezdXbZ4I0Isj88PHR uXkYlQbSNu3oGoxay2bCW/j7IBDIeApvX837HNw0iFHDm0amiKejNx47W5iwvYGHHjZIyLjAzxwS YHybYJvbATyMhjEPI9Rb3Twoji3zabZvJqzw+KkwQMT4y6En8CN0RPcWTwQCaVa91XY8Hd6xnp29 exTQlQnCiWH65D/hG2P4dVZzEQci2mjwMH+JgxTggXT0lOJqkXIf7ad/sMdZV26bY5prXpe2MfUl f9xqhRvTZsbG4kls8pochDFGbKjh+HxN32X9lsnV16viNqbJtdruF2R+nj/4bV/rYR3PF9iLsjge QYeiGGlOmxMv5HKVTgXWmLABddFP9BP39LVV5ZvNbYUrj/7DAP2z53QqIRmQT5/QtqiQXM3JcbEL 6hhEQxF7ZBLTBSidcTBU7AAADgpJREFU0yYahqrn+r3G36RTmxOwA5nQInPBGBcZ53Uup4gj6xxA QWMm8+phRLjOn9ux/NDbAaPLWHxjWzKNffn43zDmqZtfzV+ryreqNo0+dz3MD5/HB6XZ60nWf3iQ HTxMHkY1W7Pla9LBsSI5Wgaoy49Xf44VSvHa4b9XCDKsjQABo80p8jDvn4xsTBZ00gnS6mf+iqZY WK2A72X98TQ7xWlXp0gzfARrqiiO5i/uTdMUBTlZa0iGqC0E/5yeTN1tXcg0r5djfEHg7OXx1bNX Ixt8EwEAx69AN2if4rjro/skoHP6ESCQBElTev33+cQGdXM3G75E4DTUSSZue2SxXmC3g6OJEXiS YurMQOfokaXx8Km7pe0UHdG0NwaeIWNDSuIif2yJw2RR6j551s92KB7P4vkW0ldt1fJrGPvtxhPZ eTBEvXDkMugdPtwjwb3gmx0IkinapXqVK1Ye3cdpR9Pcm21kTtuQY3wtfxc92Ch1Nsv7wYgUd+CC /LhdrOEW9MvR6QHaF/mgT6FN+3d6y/6xaOO8nyFNlx8RypYXMNkQ+eC3JyaB0n+G9zU9i6Nbdd26 7CtWMSbZULk3v0tEGuaFCYOWf9JmY9rTLltJ7bMw/0h7j3G8+wQTNnP8rPAGeEfu58+kf8fH1YYE e6//HwUZhlG/j4mPHHOeyzkv8LxdgcOpjSdDIx837kg/oX4o/PIS/UjLChknlnI1L51XOiE/e9uH i+eQobIieIq0h3ddw2F+7L1HeuOf0lbP9THiG2FeR6YzbEMdUiDgXRzPbHj9mVUAV5HNvNqqx77e 9gEMcsNsiInnviffg0FEG1ccCf6AuoOP7HiMLR0YF6bcLuQNILRtQf7advMU2o3FuJTLXshOkSOy bckq1+i/ngeV9ZLQfbsHd3NMtlH3wUPZEq/vy7fn8YMyfD1EG0lcOb3oc86x0j5etJK+aINz3C4w dwOj5lvMm4ynjucXvCe+XOooom8AkwkmNDqgbF4X7wS48QMrs2ULwOGTpS4gbQadYoSDRdwT8ijW kkf7Jrw9p6RnZOhPR2aMwjHmzzoUUpADU+iajgzh7enCzzSZ23kIXYGft8TNsIyZUIEnb+5nY5Qh RiLRxfa3XWw7i3Hk8zrGCKff8rgiOgv34ba4OeOB1HnZz8Vz443o7V4fv+WdOOjTjjZs1E+dsWEj O5C+IjqgzDuWRiotJzZFP6SIwtZLaCFHNhHSQIIOy3yjD085LW/1t5u+vXwzPNP0QviJeNnQB/pH z0UHGGVHdzcd+t1TuTAJ12NtLkMR4F7G8VxGSBgH6BaOMcKTrZpep+1r6gKyQPDMGrJ2sX3IGVO8 usmYosdSXexK39BRHMyWc1E/bxnLJ6i/lZGbFhv0lRF5SO7JOC/zU6QZPznKdrVRdDku+fFH2TtJ 2mwf6eUkZ/2Zvebj4SMec/pl8P15zYd1EcHvVeRbyzafjy2/CG67uh+L/oedDZNnA/R1ckqAV7O/ QB2syyW6+V48jCaOsrAQoloYRb+9ydn8xG3caLq8U1HARAgftwOUld/LBif++vWKrV9SLnsqsHXY r9N/DP7dEc7+c+f3zb3ugyGuFBh2a3H0IJQ8KxwJc+0JxAJiKQilPozNDEflOnWk95z7NEhtlZzs 0KQlnVXuWLne/S5Wh8v4Qdc5uCojlYthLnR6cUQ4RpPk6wRodI6SpLbz6nvYUV/xBzxdT5+uuBzZ zF78tiavSB1q9BVf6ctpuhM/xrsJb3X/Lla4HEUs3mY+pjktNds7x2DjKLza20GlxmQcycvy+G1x D9t6lyL69LiofHP9YvzChxLUljE1+aYahnhbcR+M94mdxaJAG9ksRDpKeTm/bN7viu/jdZdFJGfh k7eELfnAGArhsWJOMAvyCNcHY/ord0wvGoz4fb7ezIbe1oo68pl5V58UFuML7YEhaZxtBrEELe7X 5vXIeFo7PQwaxYUreASTVwZjFLreO57YmoJX9WTffVe2C3N7yXX5qVo203pXMRmy8GCI8bPLy+1w 03S68b1cHAiDmDeOzqbBd1NeF0Ogls1d4DZ/xRNsqqPf52E0ntAEWarYlPZQP2XvsBje2mgkhmV7 5HYzXl/kvZTrQnxL+SZZNP+4vGzrFcd9837A0xC0h/uqn09RtjLNTXWB4bafv/zW/dCtm23LtkGM Y/mibNa3Ib+CcyHw8ebDF410N0cuasDIO8nWTWiAfPT7Ssk2ScnON6KoQtgHXWjX383lWxdtPn7o Lgg6+HnY9dawNa9rVNvm914MRvUiuLsdvuAGjuNaC8zvNahu7A1n0AQjehZaec8eN76B/Zq72SFO aildDWyMvLttSdMm37vH5G79KlavzWz0u1HQ2GWUJDleFoE/+1jpObcPTtcybr+M98YWVsaxeuC3 Cyzs+fpeZEKzqU+s8dMt89574nmuvMHqXmgyjOCZ4pHU1x5py/RV+3Ob4DQ5plV8qrucTnaK+Dq8 Z1va9SjiDtqkzAyrzlV8fhBbQRXMCwr0ol+5fQIUfc+8hX3XPKmKtB3zsKxQj7payHVoYTng0jU9 tt5qDi2yNQUruSHD8Mp9BYqPy3fw1JJjzi/oZ0gr7A42xLeL+y6meXXQ3nyCXln6zdh2lE5wWcSN CvH/5vZeNoCc46l/zKiit8KExx1sr/XbUY6Jd1bpmQfh4XIH25rgXdnVZxA6eRLKrdMHY30C8tVg sKpsloqQwejoJbwosLK8c2vhqaDHxt6Xe5CxXXXyBXrxiQAmfbISTZ/TZ7TlWeTN9/QQq4sSYyzG qz2M6UfwXAp5fRqDkYxV4n18T2KVoc21go1xdQ+eIkF9IDJuxegojGdUBajn5P6/SxNO56Vuf7Qd TxFv8cjzurN1h6fWcTwellRk8uQwOnlSN7fg6YWVf2/yjxl0dqDlmG4j/Zu+zyPOXFiG2LFvEJK7 IYNZS9xyJpgjFsm26+GxwH4j27l7CA/vbvtqhpOEQrLYtrcrJ8XzSRsKO8NNtpHH+E10UHiqGXnI PaWLfgoZM7hXnFD2tuExBA9RR99gubxorGz8MCyfdmCAn77kLUbA0U/fQr4xDE2u/XFp/zEOIwrU X93cyT2A43lLiA/PA4z66c79geGTsjxEvof4L6QLTMzuFeZJ68E08OYJOQ/jJFLNr3E6yp+M7of6 I+aXiMFpPiV6+QG2QnE8KNO3IOf0de/WVrb3oI8TkU2O7gV5MW7cZG9DxgKBneF5FOwrlJtPS52Q FZS83WVD+dZVm8/Eqz40x8x5tpft4rCT8esq5NpV/aKm/kgIAyOmT0KgEQJnv3+jZj9cVeqHubr6 yXV17dqVRunbvizlvzm7qq5/PFfzK9fVjXWV/8OZevO7mbp6Tam5lP8n19SVj9vWJqX/UBA4OzvL Sb1yZb38/qHgcy50/qDU2bu36gzf6uMr6tonwH4dfe7srXrz7Uypa9dBwFLOravsFkCuJJt/OFG3 /+hT9RXKheeO2vpLj79z7FsQta6kIp+/e6POPr6uriuMDR9DRl8rl9En/3lbffp3qPnNIzX/+gvl 1XxdlKuzF1+pq5/dzsvbOT5V+397Y31ltx1P83HxjVLQBdQ79Bl838DYWPfzFm02e6fQVhhXoVfk bVbWEO8w/r+7asoQ+TB7N4c+IiV+QONyS9xyfJHH27cYl0QmavmYP7jE/zAOv/kW/KZlM77zcWEd VZZx4S14DXx2FbKlkeqZt7foj1ehP86hP95opj9K+obyrXNINL9JxsJvdQFA33z73TdqBgl7Hbw6 w+8bjev/nnSBzkE83wzPRJ7qeRFwNvIxbzMrN8upeKu+6l1Xt/97+daXfZU9gFl03R/Nb2uWb2dv McZ8d6au//EV9FX09nXKmHVjXLO8ZDCqCVR6LSGQEEgIJAQSApcSATIYwSNLffHnZbP1y4XAN/91 W/3pFzAY3TpS2W++eE+VO4NyfnWpnO+pU0SsW5+56D1VORWbEEgIJAQSAhcTgXcv1C9/8pn6eknd 0atMffHzi0lqomo9CCSD0XpwTqUkBBICCYGEQELg4iEA74xvXj1Vn3/2uXoB6nYejdXO31xTC2e6 6+pnP6/vKXLxKldOkax4P/3Xf1Sf/7Ooxbtq/OofFGqee6pc+enP1I1PytO3efr222/gJauUeCue nTxSn/7i14vssJJ7eq+3Pq/ZNpVIaRMCCYGEQELg0iFw9lt4vP7V7UW9sJgyx2LKj2cZ6dI1ZycV SgajTmBMmSQEEgIJgYRAQuBDQ+BMPYJny6+023mA/OAWtcB7H9qts/+BQvwXS4U4RPx5blH77mv1 0Y1fhko19/qvM7X5U/MzXSQEEgIJgYRAQmA9CPz+hfr1Lz5T/4JVpB+b1/F6AP7wSkkGow+vzRLF CYGEQEIgIZAQ6ACBM/X476+qz/8tltWGGrweq95lNFz87yP10Z/9KlZxpe4MVPZPOM/mPD5w9/8c 7v6Po3lvqtGsr/768jp3RWueHiQEEgIJgYTABUEAMZDWEjPyglQ3kRFHIBmM4tikJwmBhEBCICGQ ELj8CIhSGPtIsMnL+nmf9S4rW/C+zLhfVn5K9UoIJAQSAgmBhMAlRCAZjC5ho6YqJQQSAgmBhEBC ICGQEEgIJAQSAgmBhEBCICGQEGiDQDIYtUEvpU0IJAQSAgmBhEBCICGQEEgIJAQSAgmBhEBCICFw CRFIBqNL2KipSgmBhEBCICGQEEgIJAQSAgmBhEBCICGQEEgIJATaIJAMRm3QS2kTAgmBhEBCICGQ EEgIJAQSAgmBhEBCICGQEEgIXEIE/h8AAP//mMUNGQAAQABJREFU7L1/aFxHlj9ahgxIkAUJsmAt WYhDBqKw84U231n2BQZePMwX3GEWpoMHxmEX9tvR/LPLgrbzeHytvPnyvJ2B59fZAY+GL88jvwUP rcAsrQUP8oIXKQ92pYDnS2txhu4BByngoDY40IIYusGGep+691bVqbp1b9++3a0fVjVI91f9OHXq 1DmnTp06dYbjx/zPY8BjwGPAY8BjwGPAY8BjwGPAY8BjwGPAY8BjwGPAY8BjIMLAGW8w8rTgMeAx 4DHgMeAx4DHgMeAx4DHgMeAx4DHgMeAx4DHgMUAx4A1GFBv+/uRioN9nB/iTv6kXZ9jUC/LJfb2z dJ69/dMdfFxiu0+r7NyA9O5STvfb/sEBI1hnMzNTE0VI5zcfsD/68w+DOhoPOCu9NtHqfOEeAx4D HgMeAx4Dzw8GLF0pbNjUxGX3sUXgM+iOT7QWw6Zm2ITVmGOLCg+Yx8CxwsCzPfbhn77KPhDTtMV1 xv+hODnwnhywg2dh8VPgAVOTncpMrh0TLNkbjCaI3BNTdDRI2Ek1mDxrs3e+8QZbowi/1GD81yX6 xrrvs9UfTrN3/yl8XW/32OXXPYewkJT62P7VO+yNvzSwzuow4lyeoBGH1llebbGVH82nwug/egx4 DHgMeAx4DHgMAAPQld6DrnTTgYyV+z1W/tZp04FMPTBES5m1nq6w+ZOqDzv61r/yGDiRGOhjbjct 53YVjMvaZMblo012Zu67GkWFFdZrltlp44YaAe67IzQY9dn2x3W284QN6JQ+60/Ns3d/dIHNSAb+ pM1W/3GT9bKaAIXnyctvsvIPCox9tcNufryNSpNIYZpNvzTDXnllnp3/1rmBXiputCa8fXbA7vxj ne2hxVPCL2PqHCteKrI5GxSk2/y4wdoiCYrq96fZhb+6zOa+3GT1f20DdJ2hz/Dt0mU2P4OEAi8f b7JuUH4IQx9tn/uzEit9e84EKqjjF+yjn33A7gjrbfArsPKVd9jZxw324S932NLaLqv+4Jz8yNr/ uso2f99LRp1KGd4ItL95qcwKZ60P4350GYwu1lnvzuUAf0nV3fm7M+ztn4VfJ23oSILhJL+nxhvZ jkkrnXv//D57tfRRUF0Z9LlC6FPCELvKVQpWZbv3lk6FJ1nn0zW29j/BCTSriKFFvAh4y19E/MOZ wr/0GDgZGOj85kN4H37Alm7vs+r3LXl3MprgofQYmCwGjoHB6HiNU5fBqMSavQYrDJCdWTrqYOcO q/87NH4IYqEPz/1ZMa6Lo6CDz6Db/3+Rbo+E069fYJe/d4IXw4y5jhtT0y/OsrOvnGPnCwXv0eVG 0Whvnwe9F214/xuvslDjr2AnSC2T/j40j/kKBqM/JAajS5g//jp9/jha55zQ3CKG0ZH8ek0O840I uJ3hr8CbPQ1lr7mSIY9dbjEoo3W9METeEt94qOsd9a53fzlWd+FaM1bs7mo5lq7W7PL6RbtN4XPh eliGq/wQv8ucoI/37jcy4b5owNbjKwV3/Wl9WIxgizVy3C96Pd77epdXJYwX60abXdVtXa/w4sUi Ly4s8/2nrhT+3SAM9ID33btVRa8wGA3KMtL3/c0VXhJ9drHMNzrZiuq16wo+eJJly3SiU/X4cia+ Go7nGmWuJ7rdHvjTi4Eer1+K5NOlwbz/9OLJt/zUY+Bpj3e7Xfzh+nCDY5NHIB8nLbtDvB/DcQp8 9HpdvnFVzg1KvDUWNcGlMxf4VteiwKctXo7Ja1Nnt3Ic+8fkuYh7DrG8uX/s23TSAHwu9N6n+3xl sRTM08rXtzJ2QU4eAz6geECG+WNGYJ6rZEfoYQRvm5/X2OZen01Nh6b89r98yNYib5fylSUmHFP6 PZjlZ99kH/y3kvIw0p4NRVa5Uoi8SPrszk8/YmF2/b7/eId99Ms7KKnEWlg1mBdeOP+8zfZ++x77 4Jd4LX6XqmzlezPw+cEqwKM2q/9EliM+wg2uBze4Maw2MOHV84819t0fhzFYYDADvHb8nAP2i/Oz 7G92wq+MFVj1+gfsvy5ge9Vnq2hLA3/RNqCLZVZ5/Rwr/V2FvfkyAIT31Ec/a7COajMqKJTYyv9V Y+XvRZ5Czzrsg2/8EQshAFau1ln1r94KvJz2PvuEVS+8q7d2XYRb3p3ILY+4BhYvVVjhmyFC+g/u sI/+KcL6At7/oXjfZzvoiwDrN1qssXBYKyVktSiDhxEA9b9xYOD3q+zM/LtBSZP2MMoDbh/wTR9j +PK0aVCe9m9+wW5+sscYeGswIl3jFLwV/ofs3SsYty8NKtF/9xg4zhjwvP84946H7ZhigHgcHY7s Pr7jtP2r97DFXmzWi+YKoYo7UscJz6Ha//5d9uG/oBh40rCdHVaBB2SNeEAe/PYXbPZP/waavpgP INlClX3wV/+Vlf6XE+wlKXdJfHGH/c1PZNiCElu+AfMkpnSYaGEXxQdqvoc3zIeFEFgY3+806r0h 9vLzGMUD/PzRSYhHaDCKw7P38Xvs1ctg2HAH43AHS/qpTrXSrf7wTBCTpnQLRoq/iIwUn2My+00x mbWEgHoPRmXHXQGzW/vvF9g7QUBkxqqbXbb0ltjzNZ7f2o/PsHeksQpFrjSxd1z6vz66w87PvR0Z vkR9cMPjcMOTVRMBX28jXszr8gO5pqSRwkmktrecBSU82WHv/MH50GhE3fKSylR4NPd9q76YlMEI Acr2vuwEskcEuJ47OxdsH5T1soQB3z/osM5XQmLp39TMHJt7KaN2gACJe5812c7v2qwripmaZnMv z7PC/Fl20N5hOwdTrPh9sn1SVxPeifw72+zT3+8xYQudRv6zrxXgljvPZlgH+sQem5l/k51LILeD R3tsr73H2l8+Qv5eUOb02fPsre8V4lsbo7r7X6HNB6TNU7Ps3MtRBf0D1Nlk7c9DeGZfO8+K34ER Vm7/tOA/+HKPdYIAkQiSCZzPieiQigZAy5OIgwAY977smpDQNphf4k8EvthYj6d+Pt8oHJjj1NXY g0cd1o2CgMqxcfBlm23/2w76HjQH3J9/q8gKwkg97h/GR+eLcFzLomdfPqdc1g8+32HNz9ps76sM cBzsAeZPWfuLLrY1i9JA96/NszdB32p7s6zEuva/2mPNT3dY+1FId9MvzbF5jNOzsxgvwMPUnxTZ hW+RQQqZ0RH1ROUomKP2HODKXgCfenlOtcWq0ng8+LyNdu6wR9iyHfyQdx4TjsLrCZMI8LU9ydfk 2MC77X/7BG0QfGKanfvPb7ELhYT8UTVM8KdR+BvK6YC/fSL444EoFMswL2HbwXfeBL0QfMn6xnhV ctXSC7JXAdpD2z/93ResL+P6zZxlhW+/yebPToDWKWDoq/aDNvjwI9bHGAt67MVzrPA91J0gm450 nFLYcT9Un4sxAR4jtuiInxwrnc9AN//RDuUiaOat711gcy+GaRL/C3o9RHlKcc6wpebc2ZCmAxn7 VXgAxIzQJ6L3iXDjw9A8Rug8ET8SwQrmXgl1nqAOi//EvicBQvS6YWR3Hj1EgjD6OB2S3mTF8iro 74u9MMCt4MnQY2ZAZ2r+Yc8VZL681y8xB/njcEEtKMLSTTdx+Mp3o7mG+F5exVb7HymNX9eKPha6 3x5kwyPIP8EjhP45/+0ie/N1N2/tQF+T42wKMizQ18DbDgKdUDBoosfpmsZ4t8feO/NqEDOrdGsX 8zKzXe1//oC9UYoW0K9useb/8aa7brR959+2Az1VhNwQgnYW29ne+g54hLvpRjlC7997JNrLENxd j09DN5ZyE2mEnhvo97iXOpDIK34GD8Cz/T1IRP+NoIcwoZ9/KtrdiWQCtvFBh5nHBGHv00/YoxcL rPRWwoK80vkcc1wK31juMaYAo9R/wiItHhXVk2UORvEvwZs9Cz1wkDyIEuflMbZtQeib279tK733 ze8VJ68LyAYfx+tx8pdq3Yq2Yg1wB3On025opRst1Sztlme6mer3jENQqvTq5uumctUtkvLU99w3 Gk7QQ+AKXLiyoUpTbVMuqiVjOx7vafdVJ9yipJQ0rRulaHtOmbcStmG1bkVpaD8Qt1lar8YjhVO3 kfaFauQoN1+34KJYjNpgurdWb9V5VW7bo7DL+kgbJO7Dq0kbMrl93d+uZ9rKt+yiJxS2f6+uaMqs 32wHDKbx7XRot2qbog0z38q2w60XbYZvmoWvYtD3rds1632UbqFhN53vYiuYdF03YL9U5fVbS6oc ShuxQnK+aMitJlY7UuuCK+vGWp3XV+u8tkDav1AL3tVBK/pvne86WEBOcI9lNvc4dYAK3hHrZ2wB NPo86ofyjfh2WkeJQ71SvIf0dfEW+DngqiXQQcPeNvy0yxvXJJ8jfa/KLPDlu1pGGACCbuqLcmuC K2/0rrBijNHWDRNHhSt1vn6j4sbbtXXeTeC9vc4WX5I8TMFL4ChgK2bb3tMAfiu34qo8RTevWlhJ rHtU/tbFVuc4ryGwY+tv62sD2yM/dO9vROOY8rICrxnjOxzrDRd/jCAYxJsLE4A9rBq0esWkHXus OcfZEY9T2XF5+rx3Px5SoHjJPeZW7tm0Lms+AnkKWWryxgKv323wSmzsgeYxThsII+D85eIxGOMW X1gmW4lt/iNoqJaCOwUX0YlS5anMkFMPGdc4zUNvEnQIEb5xQ+sqdJzB057Xr8pxmE0f1OWm32nZ K3lhgW88jvIQXV3C49KZW2t6279MZ1zB1+2wCrFxVqjyjdvLTrlQgF7UlDClN2e4r4S+XO0SfbIs 6fqiKVNlRa01ytslDvW1fH2DJ4w03us0edXJW4q8vrnFa9bYFWOg17b4E5X1MR4g4Fh21z+KHoLG NxP0B6PfWRhqReKKH5He6wqjIuCMz51d2zSBQ4rjB3Wn3gQnAEPnUm2ObsbBY/T8u8irV9w6ZGV1 /Hqv3Zbj+syOE2CqswYQhjud20ihmTUMJGRSqN8nGIwebyjGGif6UbAm4Szw6vVqVIc03nQjBoYJ za1a9M0SXoQBJwr4lDQKdxjMy9tJbJbz7uMu9nWTdiaUqfFI4ZRtZLwsJnvj+j1YV31iMk0tPIL3 Qgg4aairhZOaWIm81NiVACwxIIo6yleXeQMGieWrlRhMrn5prTkmj4VCLG8AvwP22J7wQpFXrizx kiHwIDzsCRkEiIrrRNpcxr7gRBxS5i2ULKVIWXgm5cmyXG1PwGjm183rbljT6orhywGrhFlcS6u7 meE5iQnd49TREozzShKuQHNFg97AO8mkxVHa0K/2STws1T+IV5VmiKATJ/50ly9Z8BcXlnjteo1X pGIafXfFV2tel5MG0DomfcurDRgklnnFVjoto+4uGd/YWpA8ttS3Ssx40r1nKapIW75SheIS5zHV u9Q43OMNahRVdQg4Ctj/b07Giy5D34j8bfe2PREr8qVrNV67YsfjK8VjeAxNJTIDlE+jrYPwDhnl MNQ11SKKzA/Yr1b5UoxHFvi6bZyUoOS9IpajbYQoLy7F6G3ZNj4c8TgVzc3d50kTAtGXME6b48ct m49Enho4N8eU4lUWPVZW4/pPXh6zfsWsk8q/3dW4fuGeoFuEmqDXWanUY0yuZtJDxjNOc9ObgB5y waUHufuN6rKq6flvohiK2GrGqwthH+KE16C87nZoDCksLvPl6Fu83+KT7OJCJcafYvLsQUPLIUtu u9vNeD1hsTN34wl9xdslSpVzHjH2bYNAj9s0z6ALVCFXluxFYxib7NlMdzsuT53tVrgphnExH1rz DCrrSXt0WQ4eNaIe0r1H492KuWKdN7D4WY3JJJNWY+PT4kca5lDWjUvv7W66jXq1WGyqBF2F4ri7 5db3YvRBqXI8PIbOjxWuHHrv6YiFSvEb3p9Ig9G+VM6tia0MemkwJrUSV+G7RFnUEygwybaFmG6L L5PV7CVDObfSDvsIRiInZPVmU1m4g8CznfWQwRewEntfWllNhsAJw6IKgwFGWhpLWStfq/Pm/Rbf tw1ERoF4IHDTejUeTTjlildlbUwTcZsBX8KKyAMYtdCn3U6L16NV2gKMMMFAT2MuER1oxc2E3W66 eKYMPCZUewjMRuiF4icoCwJIMR8w8NLVBt8n0i22uu2C/fEWJhElXrm6ErSbwti8pZVF7I+nn/S9 wFOTCqFQYBThCdF6DMsgAr41b6/w8iVMku/qPtu/rcsWbaitNXn3a6RHkMjWpvSY0oavWNs1BKPd iT4TbSCCNLWux1hZWqwERrWyUgjQZhgBlmBo039IA0VuK2MA7dEacXS5k8ZpEkRd42ABrKQT74zW bbLaSbwjk8oa+n3Q112+Yhl4GFbT6tutYMyLlcMVGFLKiyvGQoAKWigUJeEVQsaZgGO/2TAm6Kbg h0FZ0sqCrbwiL1VAXWMUKquEGbvHgjFfAn9tdcCnEGRWj5fwm+FJCMMBNYqVbC8kjM8tY8WRrFJL BHfNMiq3tgJcic/d9jppdzW2Gk3H1dD8jSyuCB4R896C0bpBjc5UOZSw57w2V2EIhIFlyVoNLAXv 9DivLGKicSu+MthTcjbsk9pta4KPgxRMj7MaT+Cw+VqAVeg6JgHlxSpfv6f5riis25Q6AGBbXHeW f2TjdAx9bhjqChW+9TBaoQJO1gm9xPSvI5anGufSgFMK+JKQi92HWheRMt8cTyPyGIxxaWCMyT/B N8l3Qw92Ug9epumKrjw59ZBRxykfkd7WFyOeK+QCg/cXxprQHXtdeCJLD2mpO2IBkS4uu9AwzDu1 mACZ0tqMZCd0fEHtEq4a5FojgtHVb014RiF2KF+5Df1L9LP8ob/lfAJBJow5jkyixplsH3TnrfY+ Donp8n14aJoerebCuiwj95XQF0KFmMVgnG/QxUBLl+hKXEV9ZnvWBt5DREcwyofRwTA8J7RZyumY sQ2QqoVKW9ZH+E+bP4ymh4i65cIVFpYitiiR10Ogeh0k3TJWHaHe2yNzy4o1Z95/uIs5D2kI+r4W 9CvjdIeNbKPQ9cM/wi/tflCJw5uReQyKMQ1GRXiJamnfWtWLYi56scB5Lh9PpMGoBwOBsLZuPaCz Ae3VYjJcTIThNtwAoyXkCrdDooxBQFTE5BJ/ZXsluVCLWa5HogQYsOTEoP6gx+UWscLVdd6MTkcL GN9DCZ8lvAgDjikMErABaTaslSqp2Mhr6coyb0rlTZYJ7LU2sdq+tmUILI1HE87ewyb6qAHjBsW6 Kmzom32ygl244laelWAUjGgAcxEAaOZgwu4CTtePiZpzlRn0tygUyPgqtFQKBH4TPa7oalCCa66C Swj6h/t8v7MfnHTC4R0gacqkfZUjuNF9FSpPVXtyZCYHw94n3hpol6svrUlqIk3aZed8pm3IXBcR ZDHjcE44Tlo2jbfBtC7aptPDABDb2qB5bZZxlg9XpA4xnuFObytOsXKpkpjCt3vE6GhMxIlR2qnE CLxgEh8oopZyG8Jiwmx6AUXQgv9TDyg5maQu3YWreouy3UbNs4ATGwbC90uO0yl1XkvJRCWj8Let a1K5ZRzx/myQZcMN787YNsKEXMO8lgtGwhCX7Wf1V2w1VJZiposZMGSyUa8wCgZ8XfB2LOBwKNWq TQny7KjG6Tj63KBHm2wILdse3kctTynOGfiMvRVIkIHhDUMNpKPyGIIXp/wj39N0AUWqJL2zPJXQ cZNTD1E0nXmccj4SvcmF2GCC6jaqmN6d2WSkAyPOV2qbtaADpf9Dn2piETCACfVh7Mut96n9hol0 F3pfqP+FC6aq/ARPeT3OsEXIKVtMTx7D8OJs0RAvCX0F+m80z6os2F7j8O4xtsQRzyMsFJnfSP2G h6Z2CqBznOI1lzy12uwIO6LwlsB71XfbwDiqHoLmrQdzCaGnxxd3gtZD5w9pJ+G7SHToem+XVwN6 hhGI0JnWbcgOCDJnSd86S2RvQj8E+LD+5eExogjdpy5vO2yflAuKlKdbdT/PjyfSYOTuEE1YqQw3 ymwI/YjIpcFEXkvwvnApA+76M74lDDSYvD4kbqMRHA3h7aAGuyW8SP5EAZ8hjVjtNjwvHDhwTnis Zmo8WnBa6UZ71H0bbB+zt12pwrH9SrYjA3PRzCED7IaBEYIXnjjVa8t85cZKEENj/e4Wb0HRj5vH yDY4THq1vVoBrW5akVu5U6hj8rCF1XS5uihp1L6m0b7uK0zsrBUABQS9IW1Os6jTbUSJNEnLHeGe tiFrXXnyjADiscyqcZCB1tECnV5ulzWbpcZOhnFm5sz6RMZ8wqTMLknDLBStMl+/u45to1gsoH+3 N3iDbkEy4Cd1Cj4CV2SxJWwZY3zlhoiHtc63mvDGpCtlBhAk/2I8DphMSr1awskwddMupm/ZokZc A3aUTvi+6TkV1azGs4MG1DeBu2H4G2kz8pVvrPP12xbOgf91LNroVdGEbeASQbmuBA4bL0nlEXwx rPjbNgsjG/FqsQ0YRrocD7uIjWdvl7T5epJhVtP8YY5TgusR+lzxEKfyreswZdrRy1ONc8YbD5I6 XMNvbnmn73PwGEKzTvlHvpt4S4CTpHeWZ2cbWQ8h7c86TqFVqQlgDnprRQuxYkzFFz90A7WRwcEf dbKh7xSdo73iF9s+vBAugMo2uvqt+wDxdha0YT7GH9A2QWeuRRVVP9MGlVgjYMhS/JksWLbgdS62 gNUy/FURpiEWB4nQlxtmwH2xypu2hzfyyUVQkW8FcnudyvHgfj2IyaTLlQshlF7cBsKg/cSr14Vz hbcEOlXfLbxT/pBPDxGGC2pQK/BSsK1e6CGYb2AhfmO7iQXjVIlFdLhJyNsYBQUvlFcWvN3CuTP6 gniBycUW7dEs+8xdHjRRPfYT+iGeM0+esBTdp/DsijzJaPnK8yszLDT3yb/3BiMwo+I1eMLc28AW B3OQjjk8R0gthIGGAppa0oUCEXk0KQXeEgKx/A4izJJGZsPWov0HLd7cxkRqFVuSyOAWW0C20nkS YUoWnLL8sVwJA4hced3Fkr3eGQa0Zg5ZYMekznBrFgLa8VdY4ka4CbWiJARjfJtLrB0OJiU8fZQh jNSptt+Rdy7BJ+vQgsw9uZDp5FWnh6KVMhh6ZKtbJqVTVpDjSmHKWleePDlAO9ZZNA6y0Do1GLnT q7GThaZzYUaP+awrntpLxjEuyRgxxq2xrRntpp5+SXnwfskRm4QqN6kwE/4cjlfdVkaUdTfaUtKS cl1jI50GcvI34jFh4DUFdyJdGj9xt3vQW4qXDHxWFAd8yUmJM64TrZLgtuSKAUXTDnGvJ6mEZuXW EYrDhHGW3qdkxTQh/xCg6qRj6vN0HqL705Bpx0Ceapyny1G9sm7y0JF4DKFD1xinRmMDb7r3zLtB 5dHUY9FDdL9m0odE/SPSm6IzO0AwbRvu1WTQMgBYyYZ+VPVHY9DcaoVt/kEsUY0Xu9/ogpzmsToM gH5n0pkEVNXvNMzKVLp+vVUa74z5AOFRlDeR+9iBL4S+2EVshbu3hQUbvbVHwB6E45BgyKtjIV23 MwmOKAA0rZOl7RDRbbZxLsBQeEvgneq7RS/j0EPEIR/UEzmp7eJwjaQpmuZTh2cwonUGXsSGBxj6 LTpQR3kM4jm+yC6JQFx1H2XmF7nyhHWqPk0YK+p7Ak1QyJ/He28wAsOi21S0hRTEnUA0IxECYWZS 4FNrspxo6IEHpYSOKJJfbmeIwUPSyDpkml14Fi0jgFraaTVbN3Sg0kFBbTWcbmEl6x3tSpjGAIOR EnAZBrQa/BbDT4N1v7keBJ6Te5+djJyeMkb6Ii89GXGEsBoT7D+XhiVce49xglQk2F2CT7Zn2L7S 6cWJK5QIZYnhlaaz6c1MOfpTnrry5Bkd0uNVgsZBtnE6KL0aOxnGWT5M6DGfRtO0bL1qBd6NmCjL CHSdujJ6FSfmbZtxY4LyEJNs/UaVl6xg0fZYrz+gtYt7ArMdr4EmJTwhbJvOpxYMaHrj3kxreCyS cl3jcFCfimqG5m9QV9UpN5ClFXhdpuL8WhUByOt8N9FL1GjsEA8EL1lpkhgfqAu9s1KC24FpnQU4 XhpbZaI4OJTNYjFHHTiQ0KZBfTqZcTqePk+HTfenMf5JPxyVPNU4TzcYqfa59Iu8PIa036n/ke8G 3hzkF7wi6V08g2Ybjx6i+zX7BHA0etP9QLbE0IZF91oPzyYjHUU4X6n65RgmfCfwCgp0OY0XOQcI CqMepeCv1dUtvi9iSMoftrK17sqAw264Vf2p8xldvx5XeDeswcheWCT0RdtlyGp4AxtzHNE2EotL LFzXrg+QKzikYBm4CTBD6hQnmBFsSaxFV91m11gZhDf13RrfRttG0UMAuYgrWrlkHwRgGszKCXFi NZ86PIMRDWNRXkPIjHuSNiXM8HKDXJNbuxJjrqqe0n2UnV/kyRNWqPpUjlUFR7bvVvLn7tEbjMCE TUFpevxIF7qx9TxhZqpe4eYr3Phv6/hAdLAb2wuQX62KOuJUBHCq7WzCGEbZJTxwpAC4upXcJJJf wZiQWsPpFlYJ2YZ8TRgAYgQl72embrWDV5kVc7AYvhM4EWjuIpT6WDwXpIbA7z6ggeioAATsEucQ jLY8tevqQRkQwRj1j2xXSdzSpmnWJfhkWcP2lU5v7kmW5cmrxqM9lmSK8V0pTINoU9VKvEbM8aBS ZLgJj+QtYvVfeHaV4ZW4T4dWhhKOMonGW7ZxOii96vMEwTp6W/WYT6NpWg/d6rWUFPydZnDcb1yv 8NJiwqqdmMATYzpVgMOiNMzsYvIWJ7rCLLc3UU+T1Pg+9DQzG/cu2ULamNqno/A3FfAfbuikvsO+ VR6gqRMjApUxGUvZroEsdBKQlR5JTc5bfbIVZJq9JSPKsSWDP9t9HX1P7VOkmcw4JXQuth44Wzf4 ZTpsug4T33h/xPJU41x6h7jaSk8nNbddjMRjyBgPPVOsuol+aOLNSicfSXnp8nR8esjQ45QY4kVg 52HpTRuC0mOsyS1hSVu7JMqGvbrovNuGpw22VW21pX+IpndGD1wgunhSGAF50loS3Kr+tB0DNKg4 4TW9x7s4gKfFW+0Mf/fDQOIGfgh92fSovEwwB4vF46NGNTtWn1GB64HgErp97ORgmYUY7G3YRBKF t4TtypquTJ1qHHrI/uYyTje1ditIuGEk3N0kJ8Alybux6L2y0uzXravRYQA4dEQeRlS7u6EWtWvY yRKG1kiZy6nqSF8SulSfE26G5zFhQarPE+oa9D0BnOfm9bEyGCkXXgyAPD/J8OOKvKM0woiph1GQ ksQrEEw4keE4ih34ijDQ1ImBAR+ZmZL8Yn9szDIPADQjNhkZXQFPaxed0KQrEahMwZm+2jYQLwMS 0H3o7NKKI7aUOG1GnloCAZSBhhS9CTwaRpo4MDI4eRremir4q6kg6veAC7FNSG/qir6Gl5CceBnM iijIcruizoU7GDLISROptD9sXxm0hm0k5KQsCQIVjsIDIzaWZMJxXVUbhqiLtMNpSIAhoIUtqet3 zcD4FOTdNe11Jz1NCkkGW5rxuNwrvA2m9QDkAenV2MkwzvKiYCh+LioxViUxBqUu7gBAnA5ThwdS fZN4GBElNXHb0df69JX4Niai3GAslK7Hg232YFimccikAXP/LnHTh7HJHTsP5S/IlTqUb3sxETp3 jsOUPh2Jv6kTXQBT2nYtcSLRWn1CHkZEwU+YVIoTrDZu43CJjubAG1c0PovXEhZRwJv1SUT2IoyD uDK+0jhHUFcHrYpJg+Q1ifIspU8FGJMap3r7Tv4+HwRb0vg/anlKDUZCH9hwHBCiPMPEZJhO6Ebl MSQ/W4zzlxY5MTXGH1x0OYhnqDzj00PUpGuIcToSvanwDmKsl/iWEVw5bKCMHxmOt4wyUuEm/Wb3 VqQ7JJx0KHMr3k5kau++Ngy4DITixCy5gBzMBxx6rMY32u+SLb1dNZkX7U88mEUCOsyV0FeMHq2t hmZ8KdOrbMW1UBvBIfh649YyXxangkbvlNEiGH+O+QLGUVUGMBay2hX0msQ6XLcN+sivYj7Z84dR 9RBhIJVGccx1HKIBrdReOonb2Anu8+q9w3S1TNszTtgVYw6hTeBRbPBt0S8JhjhZjrxKOZAoA2VC ctU07zYwu3QBkX2QTBr0nYDwXN4eqcGo14ms15EFuxEdjc4QnG2rDYu2eC/+HiSsKQhLq0wDi71i AOL4ygdh3l2iHAY9KPKg7C0iWMs3Nvgu6qCeHVqZA2Ev4ChzcQylgxkPRRVQmFv35LHOOKr6HmB0 lNvFEYQbhFkt4SjzfXH0efSjwjMIGPcwYinCU4kevUy3RgV5zQkNE/F2ZN6obGG51sdRuldd6apD c01PdMSR12GfOVYaJPB5r2DQWjAKJgRvH0zwxUlhre0GrxDmL4X+BsUt+n3foCkcf0smXysK9qgN Fl40AwrrlseyBs0BXezfk0fMC0Zo7ZsmjDuADSsHG/fFsaY4hhcn/m2sVgnOkf+SGTBXGwARbwvH iIs+EydlNO86ApfDO6L1YJd35ZYPYQyJxtdWFFRbwKD7KmovcOX66VUU0W4I1qv1YCyIuFcNeGOE uA6/Bd8xlpKDArtqSH/XjcZx2IZdjFttuAnGLe3ThDbQuA6CbsRRmeJI2d37TV6/ZrYhyUCqBIUQ dPJvYLyZ9LZN9KvgNYo3IkaZc5wK/hMfq4K2tsgRoiubLU7jPO+Lo6OVcbbCN1AG/T5Ku1R/g5+r PfyEn8s27Uv6tipr3qCBQYt85W4EO8Z/9zHaBRfvksEriMu6xWNK8CLbJXyXA6dyxUzQQFyBt/ir oBO4pNcRsHNjEwaqa5p2Axoy9u8TBTCgLwTtFnQqZA7+um37+GMzKKM4HroFHiR5txgbVGb0gj6V tA7ZA35Hx+lI/I16PQF2waNagn8C7h74z/79Lb5y1Wy7M26F1ZfDPtI2lHDqqGhfFzqG4JNGUOkC 8T6lJ9oA9gJWRQOZGOAd2z0QkJoa+GQMhmFhc6XXngGgk0gmCBoVxuvqAln8COgh1Ilonx7lOBUn c1K8DNfnkMXg63V1WmsZPIToV4GsxviX41TINHGghOgT8TtKeYrqTYNRKA8q2Ga5gVX0jdtxmSxO w1W/kXmMOZEuwygtTtQTPLlxNYzBqbbLY7IZjENVuQA+0gekbAB9S55RwYQ78CSR3yx5OpIeQmDI NU5HpDc16QzGEjyNbm0ENLUL3rSsZJmW7bbMI+APdRvoSZGXYEHQMfQVOoaDwtAnu1jAUPotPMnV fMPgT0KeNXEyLvq7Dd3F4qnihF7B13dTdVfRxiK2byFgNOh1/VZN9X+o15hyZajGWokDfRv0pfQl QY9UN0V6ahATBq8NHCohdVfb8LAkdUshV4CD1jbCQxinWhf04j7oReEz6PO0NrsNRsZpqgI26OwB f0abwrI1j7bpZSQ9RBiM5OKxgP1SDadNh/I0QDHmeU2inxWSFjoMPplP77W6NNujUS/gjwxDJj7d OI/xJ+g91DC3QfV98Kl9tzVNe4cBf1l1ATEXU3NCzI23oNdSPdOUWULvJTIpG2ZOfKqjMxiBqKjC oZhKxNDNZzACInMl1k1mo5m9mRdeNlLRQEZ7AkzTmoE493nNgkVuH5D1D3clVmOrXFqvSxkJYazo VWfgjq540jbQ+/XY8e8WI1JwFHnpUskSHIhH4dwbSwJLq/xx3I+GKzdmuzjSmrYv8V4qmoCvHG1N yUYrtB1Fw3tLbx+gaTDBwPYkG46q43hm27PAzqOewahi8aUMjzezfpXP7ovIWNgyJtDpeaW3g4l9 eG4Rw1pifUb9hFbNwoZ7sgPmGXW425Jk8GkSA2xyG4B7B58RQDv5xpX4Cu9wDZxU6mRe42o75T8i 2KKTL8tVT2O1VvfBWLythulvumpvoHE4eq3ebunciXxVbEPUbQ1x6DrxMIm/2nnxfMnhRYSVySx8 PfRq0GBDfeYrMfhEndFKeaKs1cayUflbZt4sxjDisCWNM9qqoe9jkwQH3lF/ZY30OSrJDDuCtro9 v4aGNMxgrbC7xmb8XZnvCn3mKMdp1NzMeLP6PEkWl1bDfmndokZf3YeUTx2VPBVNT9bRNKyy35Zt XWBkHoPFKeqNmCATKb+inuzD6AOiDYY8HUEPiUgmvEx6nFr0FlQK3qonnvF+kv1lXKPTywzYh3jo tbV3kFGucdBCsqyW8V3WFzPCS2iBnt5HDXQGHCR9+F54yw3RwJSkaWPE1hU25BYmCQ/xsG+SBcJ0 2LFQgUUCqr712utuXUbWQ64uDyMaj2dQ3cF3Y4F+BD0ErYidpBfBGp9vpG/rGlXvTeni1E8bhGbV CcvQ76gRzzXfGJY/Mbr4QyEalseQ7Ym0ryWtJo3lwnVTl6AgPI/3R2gw2tUeQWTg0s7S95jIEaOP 6gjs0ZSrIzqtxVzhBUCNkN17CUwc1vkGXQkSlXSI1R8wxleUFSSZbtbVihqF0ar38ZYxqFS76L5m URviL9DVbpVO4BKrlVsxN+kQxCRGZOTHqrhY3U76rTtWZIz8gGE5OPkhqYQR3new8ijdNSndAGbh 6dCwYFOBIXHqwkBaoeVZkwMavK2QFAz3YoU37iXjjffQZ7FVoYgWCmV4TLUMgUex1L2/7qSLwgKC YMOLbv921TBclW81g+zZT2yAqzYdKLRyQNW8pT3JaF9XsMK5e1+vUgbfbFo1yhriYegJFbZ22K7D qrowBpGLBkqLVb6OlTmqbKhs8gYKp0l3WHFKrEtmOrrrhvLWpLzGdW/xnwScl+T2O0waXDhMiq8w FAZE3U7DRxxuBU9CBa27cp98PC+7WMYKK1bmY15KWL2XPACGYFc7BX0nx6/SBqMyJr/BUciL5aAc qegVULcY58m/HrzoLI9DCROulevwnHHIQidPlu7swKvyviVlFa9qg+dY+Fu3xVcW3ZP9AG9XloNV 2uS2j/5FbNFYcvHnQolXb6zzFvUYo9V9vZvMm8WK/O2Qn9IsY7kHztRWZNI3TMgDyJKePd7AWwM2 fZTjlDY8T58n6G1yS4oty0J54+DtRyBPRdP1ZBjeGPB02FqtRQHypWEZMe7gidtybH0KtpLIfs7F Y0Lkt27bwWTB54SXWhPHrxv6UUV7XSBrdn1A8M04zvPqISHU+n/ucZqH3mS1gc5MT0KWsgHjGzyZ euEG/Mre8ivLyXq1x27U7wVra9oWCSkQ0noIl9Jd4VGyfs0FdwFBsLGNvmfzd8TKJLJNGYwE7+iC z11b4kUhZyX9FYqBx1XXIVeyNjWWDvoSNQ7QdsUWotEvy8Sjxt4a3IX3lal7yX4T1yJfgndfM2G+ I+ZJ6ziVLVwEK0TtFnkQgxJe5jLWjdNgJBoV8Of4onAF3k7NNVvnjsv1fHqI2L4l64xgljyDXIsL 8Dyyd9DEOmJEvTdWXrYX1HtWG/q1fiR2Ebn0mN3b7nkGpR96T3UYG7KheAwWYFyLdZVoEYMnyKyx 6L024Mf4+YyADR3gfycUA/2DDms/eBRA33vG2Owfn2PzL88kt+bRDlv9TZud/U6RXXh9hh182WZ7 nT6b+gPGul3G5s6dY+fOpuRPLvlQv/S/6rBOf5rNvtBjvalZNjczNfH6O1922PRLcyyo6lmfHRx0 Wa8fVfviEDD0+0yUxWZmGev32DSuMy9mg/8A+XpT02E+CcvEWx5VgDZ3vugC3mm0u8dmz86xqRcO q/Ix1YMx0n9ywPq4shemQrwP0YY++k78pqay9VeQ2P87MgwcPOqw7hPwRbC03jPwi5kZ9F0KOE/A V55Ms7mIBwpa6T7pMSbohSE/3ifTfJ+t/nCavftP8AG60WKNhXmzooDmzFeJT0h78GiPddkUeBx4 M57nJjzexsffDsDfIEwkfwNvDPjbEOMsES9ZP2CcHjyJxuqLA/qclhnwOPBmwMyeoA2Crx+CPBTy rAv6ZM8gDwS+DkGe0WaPfN8/wj4/ZHna//0qm55/FygrsVavwebT+IkLsSPxGFKg0EG+gg6CV9PQ gQ6TZsamh+Qdp6PQG3j63iPoL5FMOIzxTXot/62A+wBwg4/2XoCMeimbnt7+1Xvsjb+8yXDKFOvd uQyJcjJ/Yq7TedRnsy9NBXr3MHqzu8UD5DXJ1D+AHgCdlwHvgQ4xpCwbWg95Bn76Bfr6lUjHFuNE zDcCPQTjfQbzkBcJgINukW8UvXdQ8fHvfbb32R7DzJKd+9Y5TXPgfe29AyhkYp56SJSYl8fEG3Xq 33iD0aknAY8AjwGPAY8Bj4FxYGD1h2dCg9EtGIz+wjIYjaMCX4bHgMfA0WLg81V25pvCYFRmracr bH7IyePRAu9rP20Y2Pv4PfbqZRiMLtUZ//Xl09b81PZ6eZ2KHv/RY8DAgDcYGejwDx4DHgMeAx4D HgNDYiDwTGmz//eH59kHO8i7WGe7f/cWlvX68GbDKttrJ9Abb0gU+OQeA887BgKP7k9+wc6XPkRT C6zebLC34J2NUc6mXjwHb7RDWjV/3hHt2zcWDAgv1c2f/w1756d3UN4Saz74azYDWhUes1Mvg16H 8VIZC0RHXIjYkQEvJeElPDV1wH7x5+fZh5DXCEjOcOgSO5fRa+uIW+Gr9xg4Egx4g9GRoN1X6jHg MeAx4DHwvGCg/cu32Rs/Fkq5+4dDANi6vUXNndS/9RjwGDiOGHjWZm9/4w2WPMpzblE7jm31MJ14 DPR/fxNbJ99LbscJ36KW3LCkL9iCdh5bxsWCTsIPQd5Z+Vve6JuAHv/6lGPAG4xOOQH45nsMeAx4 DHgMjIaBvY/fh9v/R4mFLN3eZ9XvzyV+9x88BjwGjjkGYDB6HwajlFHOdp9W2Tm/Re2Yd+QpAU9t nUxo75V1xj9EOOhT8+uztR9Ps3d+mdTgAms8bLLSy0nf/XuPgdONAW8wOt3971vvMeAx4DHgMTAO DEQBKZ1F+UmkEy3+pcfAicNA0jj3Y/zEdeVzD3ASrYqGn1Z69Th57sneN3AyGPAGo8ng1ZfqMeAx 4DHgMeAx4DHgMeAx4DHgMeAx4DHgMeAx4DFwYjHgDUYntus84B4DHgMeAx4DHgMeAx4DHgMeAx4D HgMeAx4DHgMeA5PBgDcYTQavvlSPAY8BjwGPAY8BjwGPAY8BjwGPAY8BjwGPAY8Bj4ETiwFvMDqx XecB9xjwGPAY8BjwGPAY8BjwGPAY8BjwGPAY8BjwGPAYmAwGvMFoMnj1pXoMeAx4DHgMeAx4DHgM eAx4DHgMeAx4DHgMeAx4DJxYDHiD0YntOg+4x4DHgMeAx4DHgMeAx4DHgMeAx4DHgMeAx4DHgMfA ZDBwKg1G/YMD1o/wOfXiDJsa9XjJZ3vswz99lX2wg0IX1xn/h+JkesuX6jFwmjDwrM8OnkQj9YUp NvPi1GlqvW+rx4DHgMfA84sByt9JK8eik5Hyjvtt5zcfsD/68w8DMBsPOCu9NiGIcZz4wZODqHDI 05lTIk8NOhtTu7+8w87/8dtMqPyVtV1W+8G5CXWaL9ZjwGNgLBjoYz6BP/k7bXJGtnuU6/EyGEGg Bb9RDTgpGOn/fpVNz7+rU1yss96dy2wk0dlvs3em32BrQakV1npaY/MTbIMG3t+dPgwcsM2fV9l3 //Yj1fTS1Tpb/m+X2dzzRHPPOuzDb/wR+0C1ssiavXVWGGmgqsL8jceAx4DHgMfAkWGgz9Z+OM3e +ac4AMUbLba+MB//8Jy+af/qHfbGX4baY3m1xVZ+NJm2by6dYd/9qUbi8v0e++tvHbFAnbjO32er xWn27r/odq+g3eUR223MIxYarHejNNocQoPn7zwGDAz0f7/JPvi777KPJA0Xyqz+//w9u/ztOSOd f0jBwDPM0b8h5+hRuksNxn9dSsnkP9kYOBYGo/a/rrKPflZjN/9F2OvDX3FhiV34w0fs/Z/eZAV4 7TTH5LVjMHpR1SUYjH49osEIHkbvf+NVFk7hK2wXBqNzGSbvnd98iJWlD9jS7X1W/f4pGvzSI4tV 2e69pUy4ishi9MtR1j0y9Afs5g9n2XsOJZsJXD49ZFwO0x6syL2NFbnOFYzlD7N44MFgdIYajEqs 1Wuw+SPWb7M3uc+2P66znSdsgCLZZ/2pefbujy6wGckznrTZ6j9ust5UxsaKVZOX32TlHxQY+2qH 3fx4G5Um5Z1m0y/NsFdemWfnv3VudO/K7AjxKTNi4NTKhYz4UcmeHbA7/1hnexhhU8JneOocK14q sjmb9JFu8+MGa4skyNzvT7MLf3WZzb+oSjpxNwc7d1j939HypHE+Nc1mZ86yc/PnWeG1mWPYPhiM fgyD0S/joJVgMGqcIoPR3j+/z14thdpjGd4qK1m8VYaWp4xt/v159t2faB17HIaTeO9lePMV5Nv/ +IjVfnIz8NAJchSKbAky8NHH77ObOwXWeLANTyt7IGcoO5YEBiMYJt8lOtNY2v3lGjvzx++EtcFg xGEwGvg70brnwNalJjhKmXaUdaciJcPHg9/eZLN/+p4z5ambNzqxkPGly2A0DmeRjNU/N8n4Uf6+ bvGlAuNAZvpfYZl3xwnn0x7fuFYM67xY571Ry366z1cWS7x4scjL17cyltbj9UtRuy+NAYaMtR6H ZL12XfV3vT0y9odq0lHWPRSgjsRNSbNivFyq8Y3tLV6/EtGxeLe47sh1PF61bpWjPi/zVtYuf8r5 /t1qlK+UPd9xaHKvyWG+UXSezuMKvElw0muuZMxHyy8GZbSuF4bIW+IbD48DsjwMGgOnVy5oHGS7 691fjtF64Vozlnl3VfIePV5qdMDFchz3Fz2+kkVvkvzn0jLfBy89dj/A1Ot2eRd/va93eS1qEwxG xw7USQK0v7nCS9AdixfLfKOTraZc8hRF9x5uKLkEw0m2ysaYqrW2FBuzLtlYuzdGjV/QGdqNZaqg 7rG0u7PBK5dEnxX58uZ+JgydZN0zUwMTEx2lTDvKuhMRku1Dd0vRrBgjtbUNvnV3xXjX8PpbNlyK VL1eIGeqUnaOY+6fvfbnIiU7ylZsLGoFjl2q8o37u7z7uMt3mxu8Ko0pAZMvGROqccCsBO6REQ1h ZEcGwzgwOXwZVHCORXgPAcJR1j0EmPGkXze1oCjUuFZRQEcLehytZ1Q44xVM9o0ab2zIsayMi0Pm m2xzMpTe5evXl3hlscKXriwFfyUpqMDTytE78b1ytcG7ZELXulWKlOoir0Tplq5UlKLPmH5fWZAG w8ig9rjF6zdWeJXQhOCtKzeW+TLe167ScgTdVE6WIS4D5k92ktMrF4but6ddvnFDT0BDA+0S3yVj iWOpaTkYd9KQWuDV6w2+f/hz5aGbl5ahe38jGNPlaBIsJhSlq8t85Tr+MNarWMAyJuILjdEXxtIA GvmbpvvTZjDKg7rc8vRpi0uaOWzdi3fWDZqsrm7w3Q4Mhg93+caqXBgKdRlsS8yDluQ8R9nuCKoT q3smYzXjFz222aHPdY6y7ozoSUjWvK55eJUYJXv39YI7u7KRkNu/dmPg5NKDuz2H+/botqQd7LC3 Z8+zO9BqCs5tKnT7zfi3o7R/9R72jd9kYGCMI4YREwEBv+qwbhBkd4rNnp0dGGT34Ms91tUxtNAS hnznkC+4Hfhv7cdnQpdsbIvj2BZ3qD8EAtz7rMl2ftcO2wAX9rmX51lh/iw7aO+wnYMpVvw+2Sbj AK6zs80+EfmDOIp9NvXSOXb+O2+ywssDXOA/X2VnvhnGkaojyOPl1xyFT+rVGOruf7XHmjs77ItH svOn2NnX59mbhfmJbfE5+ORDNnshjOiz3ETsARrMB+7pZ7DdS/xKt+DO/xeTiYEwSpfsffwee/Uy xhsrI8bXSuYYX3oLaZTvyR7b/LdP2d6jHsqaZuf+7C124VsZtnNiW8rOv22z9ucYs2JjCrpu9pVz 7K3vXGBzA8h1lHbTvAoHA8a74k1WutUfnglc640+VvRs8Uj1nrHYGAMu1v77BfbOT8PtCdXNLlt6 azJIOPh8h23/ts32vgqwjj1Bs+zcf0afFdx91gcP7hzIcSWwB178ypzartcBzyVxC4Pvc6/NBVuN 2EEH9ci8U0y9R6DXvUcd1gePF4EO584ivdz+RzvIus/N30Q5fdDbp4LeOiyg1Bfn2Ct/gm2A8wiO ii0Zzb0+e+PbBdUuWvWociHgT5/usPajblDs9EtzbP61Ajs7K8bADpv6kyLGzGT6W/RB+0Eb7X7E +k96UdvPscL33mTzL41jiwnFVHiv8BV9WgF/LEv++AjBaefC4LThZ2wZ59gyHi8GCsCQsI+Z3lwg DXqneIqLrx602QcX3mAfBsO8wDYeN9mFl9wlDjtO6TicAn3NiQDKkQ7VwaEiYtzOYJwF791VWm/1 1qHULWnQWzpfYCxbuWdfht4lySsY7yHty2RTM4BlRPpz6nu0XlkZxv7el2b9Ad+jelGWNLI8xzW1 3x3p1StszXgPsTyEJA7kwitSLoZ8ava1N1nxLegxKsP4bnZ+/jY7/7eBxu/cctbfucmmz4fbb1Jp IA9ItN1t6JyvoxDQSQc8MqAlyKW5s4MOwAHtgZ+btAc5A/mURZ6wNJmcp01D5hlZLhzssW3oXu0v gLOAQCDLX4Pe+x23HKPgKR5t6TQ0zaTuR68b/Y650qe/+yLQIQI4sd238G3ItLOTGCmihgP20flZ 9r7g3RdXEGe3bIzJO393hr39M5EOenEP+vSkwBBV5P0NK08Fbxd6WjTAJE/vfIZ55n+0WQ/vpzHH fOt70NmzzLGFHPgyHK9U75N6tJj7jxy/OC9uTmq+w7VP6dp69/W2Cwgu509bUse/HUWt0GBrz/ra Mlm9194ahYVl3kryjH1ArLxklW+QBV2sDNZv1fFXI6stBV4L3on3+q+xrf1InAjK+XJ/u+5sL2iY wMQ4giI6a+jeb3Ds2DbSGnkF3r62smLb3sYa2rZa5zXq/bBQC97RdtdvrfNdd9VWoRkfx1V3b9/c AhbDQYEv3x3zyljUxI0rcoXcNRb2+bF0s4S3S0PQM/pcrmoKOilf0zSu+n2t6VwBp6tyFXjHGHQm 8b9YT92y2lqjYy1Ot+XrG6n5M1LZwGSK5wxYZXOn0ysjdAVe48ekC/2ecedKMvFYG/tqrsDE4yav GV6iNt6x/aJtMVesAsttA0Y/A1/i59paFNDT2i6+Aj/Eg0u8X8IK9sqi9MCi9YPfriWP01z8LYAw /Ne0VsuNtkiaxbW0qmEYi1wAn6svSj5B22vdF1acY400Icdtlzfo9ljSTtn+8o34drEcFVlZ9LiQ 9RTIqqsaSwoel6diHtjHR29Wg4Z61O1ztQujoqm37cGQFi87xziluluA8wK8w28n6VA13nwcrzb+ Rvcj5W92Ou19adE0PKjCH8q5aH0L+r44midlkr5XiIcTaN1w8Zxwy7BsTyOBNzp5tcw0BnnKiadN 8Uo1QY+r8KbFmiUI+a+kXxCCwf3TacYuk0i7q2vrfHnBxSehv93WPNmGMUn+pMI6Lt3TBmaY51Hl Ajw5G9e0t4vks/rq1nvHItOGaSdJO6669+/V3TpJJE+COaI91yFw5L7FlkcZ0sDFD7ub2iMvlWfk BmCUjHnkKWQVsQlI2ipeco1T6LRpW1YR6sat9zFexXykKuXDAD18FAw8r3mPbEsandCUUuL+BHvc v3YoOiP2iFa0XMqF+a7uMpxgf6nTaJJKhIg9oBRXsw45QMwrJoGGe/2IjRbZyURR1FWGG3sDhpzl 2FYV90Rz97beAhDCWuRL12q8dsWOE1HiW0TpcMWbMNtq4qO0KiaB4/mNpe5uM9bfCMzOq1eXON1q JNpUuDpuN1GtTLsNkvgujXDHKB7WcPF0GHcZjimf0PRSQOwAk15wuoyDWHp8XRnaovSIE1EFvS7Z hoSLKxM3Gimek8ojOHen0zRAFQiNHzM2lH7vHsf8sVZIUhVeB1YHvnqwrpQd2WdlTE5q15Ziytcy FfxEqZf5xKaAoY0AAEAASURBVLUYyYfuPb3IQL8vbwtG0+MNusU5C5+FodGWLHn5W4gTNwyFglvp 0f04HrnQvE4mqoUyX15tYAFiGbE2rPonwSMQs8s09hV4eRFbMq26l8c+E5XjQmw1q0Z0h7EQyM1u FBcHExos0IQKuGlYDfotF+zuvqZ0Gbt30NvAsTQggeIVCVt9u5vaWB6bWOQdpw8a2nBvGWljbY7G oVOHMtom+xGG1JTtSLQ9tK7SdW2M3HAZLsU27lF0KfBLk75DeVK8Fo9ZubvqWtiQNBk2mm43oe2I 9RHB0TjkKTUY0XqLFyfNI3T/wg+abyUZERFfVISl6I3SVwRn6jZBtlAcqPuEcdq9p42vKi3oO41e x6J7qkbkuxlJLjzd5UuWLBV6b+16jVcsHaxIxqCQx0c31xlP3c0btpEMc52rVeiO9vsCXx9zLCHt LJGgvxED9mHHgR1IhbnkKUolbaLjK7hHrDBpQAu/uRdIuEOmxcoS9Czk1gA9fGA7T2GCIzMY2YKr AE+TjXstvi/2NAsD0bgFhtW5StGKlPnC4gpvPsTEQwish01rBcKcjKmiBIzBn4yTMJgIm6tgtFCk l66YTKcUvAtjnYiYJ5VFTGxvaSVI1TniDRV6MSUOHjQrZOUrpryQSaYYhDFvGqxkNK6SSQudmGAl syritaBtZapkYmIjY7yEV6RZqPKtccbiGbluquyIPq7FPM/2t1cMhoZtPiP2FM1O6qc4JUkUPbOl 0RRjUuaot12szoQxfMy4OYUFHdcn6POALupOuKnhQ9DcEvFE6mIvtxIiMPjYk3+6CgPX3ZhHS68D miRKD7Z6jdrk1PyqjwYIqv21aMJheIJoGjAU1J70yqkYsVso3uptC6xuiy+Tcb50d5yejPB2Iwpm 4L1l8PIeb67p1THRL3YQ9F7bNDitKCODxkHAf1wemMSwK2mjtrrF90Vw3cfwcrxlGryNPh+FvwHF +5YxvQpaVbGpIFfMdpsTjdHlApFBC3FDmOBPSnEaQH8WtWR7xCp0HYp0ebHK1++Zxv5uk3jjjjsw PyY0lYje6k14tUWyJQhqLWOm4NCMlor74DAYjQL7KPSWDbOpqRRPwSTcXlzqPtggixwFK6Dy6ONU TaikQRTe2lvtfQQW7fJ9eFIvEd7qGudmw/TYNvibmSh66vIVUnZMT0EqulpdGpdnG4wOktbYorko 1OvsB7orBXfrmjTCVJ2yLdQdEWWLGCJcbZFljkOe2np38QqJ5wVa1ofQJEzIJDA5rqaHjvCq3+At 0MtEDEQ2fMRgFMqFAl+5C/4MpaHX6/Km5SFnyAValtT5gStpQEyl15F1T1p5nvvR5MLGVUnD0Hsd Oy72mw2FByFfqPFidJmWp71hnlHrpgYb0a6a7XmGIP2mNy+NK5ofbpmT6m9OnkDoGaelyWzH4zqK PEULlFwRcr1Q4VsPI80e5a6T+WVMb7WNm5BHzQeh8bnbQWzPaCFBLeBNQg86Hj0wMSiOzmCEJtkK tlJoIwWwcGmJN+5NZjBoRQsr2Nfiq0QC4+okNcCTKECCrtHKzjBWS3pKWlDMIfzTOIcC6bSKoy3B toa41XyLnNKVbBDp8WWizDmj+BNLcmwyO2kc5Kmb5GFGwGkTWFPIJCiJZpaMT4PpS9Pz+BW9jECm JtPKornSmpoJH6ngLDsMOvrkOHsiKL0LIHQQJHojaUXTWA0xjS6DYBv2u+qjAYKqB+HWwDa+LQg7 /dM0YCqoMETcbfDGbXNLH8WbWNENgmvDMFe2PD4EPdNadH357rrb2qOhmOJpR1fYK2sOHk9O8xFy YWWziS1PWnmtkSCQBqREkQr63cHjevCQkMYkOpEdib8Rw0WgOLu8UgEo9WBK8uzKJReIskS3ZFHc 9GC4CdpNtmzR72O7h3Fs/yEm0OIP3gJcKJDSQDmA9oeGAQZT6elbf9DjrWhVuHB1nTej09EC2f1Q Gq1sPmHVOCzsI9CbVXOuR8VThM50qazGeczr1dJxxjFOad3usW56eGbVoUz+5kaLIWvVdjSZFt5f 0uNWGKQNg7VMk++6pSbQZIJI9APtQQcvh0gPKjpO7qO1U17tnBzSxNF9XnlqGIwci0+9jMYrB0iD XxEeZev64TM8OK6vTyYgvTVOnR5O2AYkjUBULjgbRsrLQq9BGYRODk3vJTgfWi5gF4WSkyl6AqWZ pJN6Ff8HzR32b/i6ta4l6JIGnDZhN9PFDBhm4qGeBvKEPPQ3FARjSjysPEW1Wq5gLmMrp6Tdtv6k 57bY5XHFfWK0YYwaty4yJpQd52KO1GAkENNt40Q0ddKPmNzF/1xbfFq3cRKQ2AqV4a+KbVf2PnpN lPapKqS76CTA4cGgUxLGkZkI8+TRNea+U6dOhXguQsmsXhMnq6wE8ZPW727xFhR921tDuJgqxos+ Kt9Y5+u3MVFdM//WMXml8WpcCtBAZpi7cYMz5qlbK2dYaQi2vyTXQ2MNuUJGJOdM+0Jwn0Bfmp7j HhtpJR/WNw3fcAYt2l+uLWt6ddaaCEKwyImk4CkrtzcQq8yk1QZiGYjYG5rnDAfbsLhTOEjow/Ty NA1kUVAp3nT7TN5auuL26kqHI/2rEWNkYQX4XY/zCPTFiprQmZ42RumGAq9hr942PViMPEShqASx jYyv6kH1haCNwLij8SvwNTR/I0fguuSVqhh8tBEY5MFLnEYvAsdQdELyAX5WKOIkvmpwMt7KDRFH bJ1vNeHBK5bUJ/TbRWw8e5tCjPaGalMGQEl/B5Owh2S7lMAD/hrCW1VN1iw+EVWRG3ZS/3D0horh 6beCLQ5ZdJjaNfTlatzjmNJxDNdR+5ccnsrjGKe67hRDOwx6Sh/IqENl4W+2PtJ4QGhF9TXGsXOr Mkk75C2NCSVPJJVGygD/0hhLtv67dCBaLeXVg9LKfBr3Q8osQq9l17Z/4jmTFRYJU6YrjMcbt6rE MKP5uqbf+GLlyGOFtLuS4pGxK717MXZS20/Ky0av5uJXatmZEJk1UX65QOlSGNDW78ZleQOyvEG3 bjn5O4HB+T1rW/Kky1E36VsG71TbZmFA8VCf/GcbMIx0Qz5Q3DtphcCYbogfsuIxJc8tT1G/4m0O gzbl++a4I/0stmcnxpUinrWHTotjQu4RFnPkBiPVdlgiu51d3ry3hYkdAlNZRqQajXUhjBfEi0UL GpfwCd/ZAZzTiVJCRYjQSbyOdJmJkJSdOY+sb5RrxtgLhSXTuktWKrLgW6bBiV4xYAcyw1iO8b3I U7eilVRGFMLYila1hVdHMtMatj2EVhLoULkOJ3wftsZxp6c4tLcgpdWl+8ttCNPfrYmgY+IoaTL5 agYmTYMrzzeFg1zjXdOAKSjdkGi8CA/KBvgqjDTGNtgCdwxNd2FDvF1fTObBSXgvGLEPrMo60jMk Kveie+VI5SKKFHWPV9/lDZlUBgrZiPyNboHJpDgmej3ofh7GW1U0S3hOJeGYvl8a8yRa1K0N5aT/ 5ValyHARwJCL9kUNCT/S36FiTT0LAYtcGVcLJRafQLEjwU7qH4reUC+lGdo/ifcOg4viKcBxdW2L Nzcb1lawZcfiD+fjGKeq7lSZQ+g5Y7os/E1QA+Vx2rNhct5Fok7qoVMOPCNNj2rGYDwTsClPy8Ee TrQdzslhULH5T+EeesYw8pTC76RXQs9ZYTEhy/4k4pPutpt8C4aI+g3LiGRN1EceK6RdznZLsBWf eF4MRvnlAvXYSORJlLeLe2MbvUQq4QHj5v+yisRrjrpBK3KxsThoOyuhq7FtfUVbKE9w0isJij3p cZqI2oQPI8lTlKl4m5NWdH+ackK/F0a++KxTAgvPTxkSxVm+TOevLgwcmcGo92CLr8CzJXZSDoGS xl0wBy6IY1iDkTU7UkSZUYlJV94JsWYmwjx5CHJGvN1vriOmUIkX5OCxGb94Nly9sRea4LyCvktf GcXK6fU633VYeikzPGxml6duvRqLbXxJW5ui/lB0lbYNaui+I7TijFGk3d9xBGcKsxy64rFl0HgZ TsHV/eXOl/idrJSKrUm16wPoFSv9y4h1kyxoRkeFwkFmHkHr1DRgCkqaRt9rvIi4Avo93QrGUnmf zjPMHQ2wWVis8eUBHqDCu3ELW4mSfhuO01mWXbGLZAFEgXMqWjJdbGIwGn+j+B5txU/3c7rMkQ2x rohDt47JV8kOYmvxd5e3nlVS9kcZKyioo8Tr260gNogqADFCNmTsgVy0r0qK35D+lrJE82u9lVz3 j2V4HhV2Uv9w9IZJgeNUmNSJmWMypniKsfXKjPHjosdxjFNVdyofIfScMV0W/hYSAikbtBd4/Kit h+P3LpLEp4xtC+u8R7ftRGOsjpgbaqt0hphdmjYHGCkkALgq3I9gMJLjhRRrGMSc343Ewzz0+Nbq CjweU04kRQxMHUPT9JwaeayMME6drSTlZaXXPP3srDvPyxxyQXtvC0NQhS8j0HWqzn8VJx5vu7x/ yTgdN/8fiIscdZNtzunewqic0MHAtANh1QkorbhiFPWaOibheMephiHX3ajyFJUq3uakFd2f5rjT 7wcZjJTtwFl+rlafmkxHZjDSR49Wk13+yGA0iQPK1uNdBLJsIWhehr/7u7FTFxRRpnmCELfidOWd EOsQRKhO9UlVpMZMi4gNUr4Ipd7w2IrqwKq3CJSpXMiNgLSkjcJoMQpYZCU8VckepY6kvDnqpist adsOgD1iVHMbOJLAGvReb4uDu7YdEJzE4Unap07L37+7zEsLUbwLXMuI95E8Zac5899rV+/BK660 Fi043fhM/E6EPpPbBGjBR3CveM4QPEKDqcefzQt1Gn2n8WJPQkwPjHHuuxe168m6g041eJnujBhy 2F4lV/3EpNq9nQvFEpmRFjtEeeShrFDh0vhlefgbpbdB/BzetL2Ugx3yyoWN6xVewgk/Thd6YbS5 oU+ydBkRMnWKI5E+FcoOrKwTbx2iwUjETNoS26Vvb6mg43Q8UJkzMuy56U3Qag8eFhn0F5EGus5u J86lFU+xDQeGISM+FscxTnXdReNEVN3ruKOB5FP5nh5/WfibqoN4ChauwCARbfcUnj7jjF2k6sON jv9UwTb+MIh+8Rq26EcxHsvX9NHNybEedYmUNrNO/vLKU8ofnXURenZ+12APd0d0lDScaD3Hkvej jhXSLvM0L7MZdEEltf2kvMz0mkP3NKHL95RXLtA4YS6jxTDQ5JVpw9SRlHboumG41CfDpWy3RYXU qJaZDpIApe8Jfbn0V02nyTJXFQfv6WWh54vDZYI4lthemLJIp/LluBlZnqJOJVec8iJJTuj3jKUs 7ENPU/NbZ/k5Gn2KshydweiWVl6No5Up8omyMdbBiDq0YIL1/NJK/BQLKJ16tYPxdEMB1/F9MFnI +lMDI2GC0n3YCmKANB2KYtY67HR6v33ylim1OiaMaURHpauSqe6XXZxGhG2FSR5GVGlxCiJMblrY QrOOUyxI9XZT8j0TRpy5brh/6pXfknXajAajRY/THTRp1Nmy3dG90tfMIO16Gxwmv7TDnCUTb6Ro RdQlkJxZR3mpPDrikxdRbA8004Rr+kbTMkWqCUGCoSnxOzXeAS8uA2nUHjHOGjh+fPnWZD2MFM8Z gkdQlMsYYpkm+wovpodRUB6hpfFunTQVKMFXncYLAQT4awvbZ5aFl6lDeaEBqMvSLRxeY0rYg3ar rtPdyPgWY3bZESdo964OzE2Dm47G30BvxFuzsuY+ca+HmH3S8JW0dS2XXCAGq0Te/LUOYmp67FIq G/5eyxQEl3d0+P4miROWk/YToSL97TxgQWY0xoOWKiPDTuoflt4kaKNcFU8xPIzCEulCh/A8pV1D Jzp5x6mmU+hQF5fjOlRvl9eIV7Lr0ALa9qH4G8moA1wDjkimlVPil5Gs+W6xkCjHsKyvdg9G4HuU rwhYUgxptGaDNumHlPu88pTQK/U8VTUN+q4SDnlDyrVpkZakPBFtAyhNlOee1g8aWXF4qXbvaa+N YGth4rZhAEDKyySPBcwkT2bdM09baZ5R5ILhpY25AGUgtA7ci1MR6/BAqm+6PIyIEeAQ5zoSRM2n 3AvdrnnWxhXNS5IOReJfk1MTQVN0IULWPcpVeTLafITQUZYdBTTuWsivMhiZcgI+sjxFvUqmJegK SXKCzoOcc3pIQONku4Tyczb9VGQ7FgYjIVjr4ihewqCFp4s6whSD0QhqOGLX7GOCWCcn7oSDCF43 CPjcvCf2VNcthcA6qlwYNIR3k/zDJEBPZMTx3eQb0uwnMFrNyOA6Dy8PEZA0iOOE+o3goYX4Mcl5 UUDrFJPFBvDek3jHdR9HoauTImT8B1kZ9bhCnxQXVxAgG41DPnE06f59bDO8qg2BAq/B8cYyv7xS hidggJFAHMW7e7/J69eiI8WRV+RPXeWR5Q1zzVm3NqIJuAp8GadSBfFjRdsf6yMbQ1qC8HBMgocB M57WNPTUosmycWS1EMayL+MFhG9iyu7khIcBglJwgb+LOO6yg+MuYSQShsHaYlEp+oIXqJgM+L6l DMuFYKvLPjGeirGytaqPSV/ZxFYYsgWSuu2KflmCO3wQ9Ff0GeIntLaxLdM4NQxxfUh+A/4cDz3A p3kEjFLRsZ5CGd2iPOKBZSSTdYlVVcVjtnhVGiRwbHrrQYLXgciDsrdu6XFURrt3UYca5yhfC3b0 B4JTN8Vx2INoR8KVejXplCEW2sb9qGzAJpQzsWVKnb4ixjk5RWgf7Vq/XiL0UDFourtdJd/Qp9hG aMRxNsa3GKuCTy3D+LzBN2CQrC3ok9bENyPw64j8jXoKBPUiqLjgj8Ex4w/A2yzeaNRNcEp5dGa5 QCYGou4S4lbtPtaGEY6xJI+VFd8HBe8n4Ay81R4XYmyH/d19HI7tqoVvSfv7FLaBNSQkCPiHPNYZ /OEexoSDjrsPd+FdpWlqaa2J09tC3IwM+yj0ltCsTK+/Bn4xzuskeLzgf7tCHqsfXXUVgdxxjLn6 Pto4FVVQOhU0JXj3MoKrb2Csrd+qmWPc9vgBL9inPLC9pfS9ArzkJH+T/LObxpuI50YIR7pXgEJP 7hvgleBdGYYs/pHkld6NeHfQtjZkmJJxYR8FXmeK7yfIhjzyVBjpt7VRRPBOg17EeELgesmbBb3I cZIbVTKjNU4K4I2GXgzYNm5omWWGQ5CF5Lxa7QppROjcOIkU+n6zuQXerPmD+G573vYEP5N9Iq4E j4zIY5nGSa8GDg5J7x1RLjRvmLrZyt1ou7GQ5cDJFg4fMk9kdMePobwis0zL2d12tlx1Gx6aOHVr AQcnRXMd4RkqxomaJwneZ4TvsCHI92wYeqAz7woeiHFCeY9Np66atDdSqA9NcoF4NHkKmQDeqOfm Yi5N9NJAZmzxJakHCzkhDmiSssGidTG/rcPpYL8j+FqDV2S+QFYJXFjlu5Dn3xkYOEKDkcmgJRMv Xirxot2xYxyMxl5oV1BORUzR4AJRbVlbgPR2OplmwDXJ4BObvLvLSVqtNnoy44N2GTTrKjhw4TpO 0jRQmGXIPlTXi1U9+bfgM443jOFclruUmN8qbqjHfHVb1ulEmDEZc3k+DAVhQmLrqHFmjZN6wlHe tDTbiMIWN+jnCd6bcTUUjdh4XGyEXmWGW7CkB1xlHA8oX4bAluXI71FLmkQZT6wzylsc59a8JPgk nMbVHYDa4FVGeoIPsRIrBSbarLea0DThvRmAfp/XrDKTPF6GJgrLEygd70XlHr1/Vxv/jDyS/8cm hlEb6UqRoZTHcUDLLV2P0/6o/G33rmnQovXR+8KVhuHxYeA4j1xAu+kCi66r4IhTVx1tS7EBLB5y BQwvhwqwXVbmZ0zaifeKbi+8yoiXpW3E0+kiQ+SosI9Ib5mbayRMbrtYzCDNN7eEReNdLcLkHKcS FDoR03h1jTl45T6UucJrNt6myxrEm+Sqs4BjkDe4CUm+J8N7SwVoNo1wzhPayNasdJzptqv+MkAd Up4i78aiLlPXLekliabGdBBEbDIXwYLTHEuXqFEifN94QIzdRruHfTDbJY1huv1xnJSumx7cWF7S gXItmZlUThK95tM9h20zST+yXDANFEntle+rt92etTyPTCPNGOk2Z92ZdQEYcwYu1OZsgDOAtKRB 6D2DR0mcT8RCWuSEzZltBHmaJBNK0SEdrVtxPiHojsr7zH1G5k7llFMTnW08xS+PzGC0v2Z6okiG Y15DT46x9g+2YxhC41KNb8H6WCYEJGEoY1+6ixHs3k6Y2MiBbF2LV+MTE9mmHowAS64ApYUSr95Y 561xrMTKynDtErfpgqteAfvFCjyPEla2RFniOGDDK8QUuuUr2GYCr4L0Xw8rSktmX0R4Ky1W+ToC pw5mhuk1JH/NX7c4LtJcUdFtF54MzQFBsZNhyval15Yr6rpeQa9pW65oyfZqw7qlyNO0Y7/HFoUV BFqX40tfC7xydQVeN9bqeMw7AW2G8SCgiwTB5BprXbhLLyVMLsXq8BKCszcRqHSsP8CnPIIsfqDb LfsQhlFi9FFwwEBi8CpXObGtJnoF2aynAC9Nq43Yakm3VozT60SshInxbcIg2wuvn4UluK9jjJN2 J03u1ZY0TDriq0RYlaenrJEJfP0+vBbFUe/RhEQaxYsL1dTDFkblb72HTctzjbYbdQ/kjZiiDC0X sCVO0geM/0l0U4bn0b5FBoreRrmBTKhd0u1U/V4ow/MHq4C23MWqPB3teapej3kJi/otOn+8ZdC4 ggv1KzSMAvs46C1H45MnnnFesr9NtgTCwLxFZVSOcSrBVQYj0ZfdXXgHL4WLfZL+YAyo3kKQYzLG ZV5u04Ok3YSrc/upKowaapZGNESqQtNviAcCjYmjtlOgHc6JWYLcUnQZaz+2eVoLlgqwoeQpFhPo lnlVj471tL5oel8GMMHL3KUDKxiy3qDd2gvfwScieAJPDuJFnLX4tHQ2n6it4Sj4a475h9B77S3x UcFO3CgcxtuTGGMPXOdw9d7xyIXW3RX3Ap3AwcUyPAvhjTbAO3t4mZbWq8N9y1331+BrlmewHqvw qMROg8n+enxdxv+j9CZ4rouv2sDAWGYsrGYIwm8XMfRzXnmaoO/KkDX7t12LcQ7+2IEXkkvfR+D2 DXh0Niw+l2WhfWgcPKcZzoh2YQAc/u9Zh23+0yfs4GyBld6aZ/2vOmzv4SPGpqdYv9tlU394jp17 ZY5NvXB4oPWfHLB+P6xvambmUOsWFR88CSufehF1T02u3Z0vO2z6pTk2I+p4hnoPuqwXtZu9OMvm gg8Z6u8fsM6XXcZmZhnr99g08s68iEKH6bNnyCrwjit7YWr4/BnATEwyQt2CXjsHjM3OMNYV15cj fCZWNsYPzw5Ye2cPlYqx0mfnvlUI+3JgFQfsZnGWvfcvUcKFBuM3YDI47F9AcyA4QSeyzw8Bhv4B +uxRn82+NBXQ+zToNqDXQ6j71FaBvu486rD+C7NslvVY74VpjJkJ8tZnbfbeN95gN4FwrMyz8rcs RhrwmYy9MSJ/E3yt86gX8AjBX2fBc4fm68PIhSeg7yfTbO4smBJ+ov7ukx54vHgC3vF+0vJU8MXu s2nUGcmDrLJEgHjEv1ywj5PejrL9OcZp+1fvsTf+EiPtYp317lxm1kg7tNb0d26y6fPvBfVVbu+z 2vfnDqXug8/brIPhNTc/z2akziNkc7vD2Ddm2PzrhwNHqMMdvjwdFsmdnU32ye8OWOH7JTb/IuTC 53sM7BF00wfPmGLnvnkuu+45bOWu9FIPEd+EHnKYvGoE3dPVlNR3Y5QLB5Dl3Seh3tsDnw9k+bAD fxiZltqwHB/z1i344xcY15jjsCeY84h5UiRnc0AxdJaDL9ts7zHGygt91p8+xwqvhTJ+UEH9nV+A N/6NSobQLqz0mnqc6E0ueTpGiII5Wh80+gL0zqkh5rVjhOF5K+roDEbPGyZ9ezwGjjsGnuywt//g PLsTwVmH8Lh8SMLjuKPGw/ecYIBM4BGEkl1+fVht9jnBg2/G4WDgFNPb3sfvsVcvw2B0qc74ry8f Dr5jtfSxCDIdLYJUmTjf6JDMNDFI/AuPAY8Bj4HjhIGdn7/Nzv9tpPEf1QLxcUKIh2UkDHiD0Ujo 85k9Bk4OBvqfYSX2P4UrsULJ70HJ99Ppk9N/HtIBGIBHzd6DTfbO+XfYDpJWVpus8p2ZyGt0lp3L uCo3oBb/2WMgxMAppreDR3ts8+d/w975qZiMLLHmg79mGGmBN9vUy/AUeXFyRHLw5R7roKopuOv1 26vsjf/yflgZJkT714qH66UyuWb6kj0GPAY8BkbAADWmM+YX0EZApc8aYMAbjDwheAycFgx8tcPe /y/n2UeYTXvhcVo6/bS0s89W4Wnwrtxu6Wi2c4uaI51/5TEwGAOnl976v8fCw3y08OBC1CS3qD26 w87Mve2qVb1rPMS2i5fVo7/xGPAY8Bg4lRjY+dX77PxffsRwkh/r3fALxKeSCMbYaG8wGiMyfVEe AycCA8PEcTkRDfJAegz02dqPp9k7v0zCRIGtP2yyop9IJiHIvx8KA6eY3j5fZWe++W4ytq6sM/4h Qq1O4odt1e9gW/VaYtklttVtsDezhfhILMV/8BjwGPAYeC4w4PX956Ibj0MjvMHoOPSCh8FjwGPA Y8BjYHQMCOUo6fdC0gf/3mMgJwZOK70dZbvT6hbd6Md5TmL22TwGPAY8BjwGPAbcGPAGIzde/FuP AY8BjwGPAY8BjwGPAY8BjwGPAY8BjwGPAY8Bj4FTiwFvMDq1Xe8b7jHgMeAx4DHgMeAx4DHgMeAx 4DHgMeAx4DHgMeAx4MaANxi58eLfegx4DHgMeAx4DHgMeAx4DHgMeAx4DHgMeAx4DHgMnFoMeIPR qe1633CPAY8BjwGPAY8BjwGPAY8BjwGPAY8BjwGPAY8BjwE3BrzByI0X/9ZjwGPAY8BjwGPAY8Bj wGPAY8BjwGPAY8BjwGPAY+DUYsAbjE5t1/uGewx4DHgMeAx4DHgMeAx4DHgMeAx4DHgMeAx4DHgM uDFwYg1G/YMD1o/aNPXiDJvyR6m6e9i/9RiYIAboOGRsis3MTKXX9myPffinr7IPdpBscZ3xfyim p/df4xh41mcHTyT3w+epGTYI7fFCJvQGR14fPDmICs9ADxMCwxd7yjDQx5jAn/k7efTX+c0H7I/+ /MOgGY0HnJVeM1uU+UnwiIMIH9CNjpuOROXGcYMtM44PO6HB98dE21/eYef/+G0mxHFlbZfVfnDu sFuVu76xjZXcEPiMHgMeAx4DpwgD/AT+9u8ucXSR+iteb53AVniQAww8xX/xdxQ/WfdR1X8UbR5j na1bJTUG5XisPxhQQa/FS2rsVnjL434AwuzPPV6/pHlfiPfyscHjxhUTtuX7PbsB/tljYLwYeNri ZcVTTPpbOWH0R3lqeXV4vabb3uDVhWKMLws+AYPAePGes7TnUn+TukROnAzOBr5/cfy03WvXNa0s NPhJ4tajjpXBOPcpPAY8BjwGPAYkBo7ew0h6HLAq2723xM5l8BTqfPIh+6MLH0AHCn+lGy3WWJiX j8f+2v9ym9X/GWs6U+neGH2smM7/r++yC9+aidp0wDZ/VWft/hR8ObL8+vDCOsdKf1Vkc8Drzm9W 2fYXvcRqp6em2czZV9h84Tw791K2GrJA4UrT/tdV9tHPauzmv4i1rfBXXFhiF/7wEXv/pzdZAd4n TeJ9crBzh9X/fQ+wa7j6bJpd+NFlNj/VYXc+vsP2sKCqvgJ3039SZJffiq+YtT9B3f+3WTcrlNjy //kBK3+/oMuI4BKwbv6e4k1UNM/e+dEFNgO89n+/yer/2jb6Uyx2v3npXVZ4oc1ufrxtfJPtFVfR x+fQx0XVx/Qr7p8dsDv/WGdoeQwuZEb/TrG5PznPLnynEMBi5Z7oY/tX77A3/nLNqAMTNFb+luoF 41vwgPH+/jdeZR8FDxW2+7SWaczHCzqtb/ps9YfT7N1/ou0vsWavwQopaKepM9/n4M2bf3+effcn ekwPpIfMwEw44Vc7epwK3vHym6z0gzgvYF+12erHm6wX8CGMP/CBd/8CfGDC4E2y+OMkF3K181mb vfeNN9hNR+YTQ38R7Hv//D57tRRyxzI8PlaG8Pg4+O1HbPZP33dgIXpVWGG9ZjkuR5JzZPqy+fdv Y8x32PrDJiu+PDjLSdffVAsFL/gfH7HaT24GHjrB+0KRLUEvePTx++zmToE1HmzDS2wcjDnO98dC 21+usTN//E7YpIUG4zewnDPol0MuDCoyz/dRxkqe+k56nmHH6Ulvr4ffY8BjYMwYkJajo7rSFY56 e4j1jd4urxXCFRcYjI4K/Fz1tq4X9KpOwsooujlIU7jW1HX0mhwbeDLnlWUsN4FX5C0Mkbd0bUPX O867r1t8Keo3CZ/zWljmXVVvj68k5Cmu7nP+YCUBJ8vmitnTfb4S886w8HmxyluUDLF6nYTzAK+A MbE/0XeJ34y+WDHhVO1Gt91fTmibBTfKW757+OOg1+vx3btVBSOUWAK941b0wWKJFy8Wefn6liOB fzUQA097vNfr8o2rko+UTJodWEC2BHl5c+/hhuI1A+khGygTT+Uap7V7mgOFALi8uwpcsNcT+zsu cmFUBGJMdLtd/OEK+pM8+6TQn2z+/uYKL4E3Fi+W+UZHvs1yNWmzcmOD73b2+f6DFt/aXOf11QZv PpwAoRLvrtKtIeTPCdbfRG+01kwvd6cOA5kc5yFZ+jIhDbyYBG8dK213NnjlkqC3Il/ehC6V4ZdX LmQoeqgk+cfKUNU8H4nzjtPno/W+FR4DHgNjwAAbQxkjFUGFz3DKnVaQTprBqHt/nS8tVnhlcYkv XcEfJtBK4YCiGLy7gu8LFV5v6kkLxVVJ5kX+EjGmlEV5VpkSr63bdb5yXU/uRZ1L11f48vVl/NWg OMgJaGiMqKwNoQBmpIKNRWLouFTlG/d3efdxl+824UpvGHNKxkRsf7tOtjKhjEKJV67UeIAeGKGW 0ebKAsEjvtcM+PeVgTHEdYnXN5t8H0p1a7vBKwSHjC0ZW3yaqzVeJrgpol+Wrtb5frSdqnuvEeC8 TFzGC5eW+AYMoL0HaJfoawGfXYZ4h28raYoaDCz1K6RdrIi6a0F/GXQTGaCKVydk6EvrX+LWLmkt Lbn/Nh4MtG6VI74xeYPRUP1KlNOh8o0HLflKedziK1fkVp6IDy6um2V9HRnsJa8olPnKWjPR2Gtm Pr5Px0EujBU7J5H+RkUAaXPh6iEa4lGv3GI8nB52cvU33lnX+hrkbnVVGOdgrHy4yzdWTf2qOO7F TNLPR8VbqR56VDCMOlxOXf7c4/TUYco32GPAYyABA0e/Je3zVXbmm+9iDs8Y4p+wy68Ftxn+aRfd 0q1d1viLc2xvZ5N9+rs91sN2oOmXzrG3Ll5gcxm8gTs72+yT37VZN4jVik0+yHv+O2+ywsuHtNGA uNTX28DB6+7m93+/yqbnBa7KrPV0hc1H2/f2Pn6PvXoZDvmX6oz/+nKYmZQJoW5sE1r74Rn2jtjS QtNHVR58tsYu/Kd3IhfrGuvyyvi2WxzssLdnz7M7qKtwBVvOPsRamfE7YDd/OMveC7bblFgL22zm af9RWnHhibTZxmMbOHpD4Ej8Li2z/dW/DrbphS/E/wO2+ncX2Ls/C7fTwLOLNf83+GTJn6obcD0F XBHu5efgOijNoO9GYebDKvos2IZk9xkCYe785hfsfElvRahudtnSW5Oh3YMv91gnCLiMoJtn59ic iLas2sWYTWuyFSJfF+OS/mbPnmMzL9I3yff9r/ZY89Md1n7UDRJNvzTH5l8rsLOzB2zn33bYFLYf 6q2bjnL6SPfpNmt/3mE9fJ5+cY698ifz7Pw8tixia0ET+xnf+HbCtj5sC9xr77G9z9vs0Ve9ID/D 9s35bxfZm68n4Bn90vmiowLzC4hmX0Z7I3o++HyHNT9rsz2Ux6Zm2fm3iuA3lNhJG4Ky9tgBAkqz F2bYHPAu8KbGPXOMFZI99y3p16F4Mx2Hgqe/IvpI4372tTdZ8a35wVtjgPcwH2hHpAb9zL4Cvv4d 8PUEtOdua5Bxj7135lWytcnc6keDrAbJU7ZwHDwCvYBm2l8+gjwSFAeaO3uevfW9glMmHTzqsK4M ZP7iLDt3Nmxg/6sO63wVHvAwM4PxFr0PChzzv3HJhaHkKfq480VXjRM1RqLxc4BrQPMvg+YThkcM DYT+kvhRkMcxRsV7BYN4QAD3vYjniEfxmxL9MM4t2+BNe1+GfC2sQVQCGhhG/+jvsHemzzOxQfhw gxfrMSP1MNWG1JuTq7/t/Pxtdv5vAy3GueWsv3OTTZ9/L2j92MMlENpWOg5otAMaDcQr6EbwiPRD YCCbIAdNcYyt7a/MDcgXdWheuZBKDxk/jjpWMOb3PmuyHaHvCwRAjs+9PM8K82fZQXuH7RxMseL3 w1ADGSEaKpmQ+9uQ+x0h9xFSYfbsWYSAmGcz3T32yX88YoXvl9h8imwL8v9W6A2BRAz5xH9+i10o zA2AI+84HVCs/+wx4DFwejCQYEia7Gt4TWys1eEmXee1BeJxslAL3tVv4Zv6W+e7Tk9qvULFLsLj w/BOkWUWDA8du1Hd+w21OoYeN1aNgueFZd762s41gWcEApZBO9NWbPTKjul9ozwNLtb1ajcJLmyW SfFG0pNmNa/LlXazHpIk123vvt46lhQcuXdfBmGMe03o9jNutikCJwmPWF2pqP5NaRPockmlK/Im 6Xtdd3L+QWkGfU9G6uA+43AtV1sOCzWynS+51GG+7GKrhHSFN8YKvMTqt7R7vrNfHsg+tcYYpdck YISH1aLp+WbUL/urkLytr2mt+jrzo5ySI8hsa81cMY7lXVhRnma0CTQgp8xTFFs2QKM1J69ivPGQ liDue3zjhsatLEdcS/Bwq1/V49TYRmkXM8zzOHgzWQUvXqkm8NhK6B2YAFtrrRbnx7KvcS1f3xg7 jXOyCitxXVXef2QMSjhc9AtvxyrxNJTl0OvKtrX1A/WaYwty667t9RiNHXg1NYjXaQL6crwm7XO1 CyUOkgt55GnrhqThsH2FK3W+fqPi7PvytXXezRIkn9Cfkx9F2HGN0aCfEPw3/AEnzr4sjnULaCOB H6TBHsCHsVqV3m6SJpOul1bGOF56vAX6DHS0a9LLUfRfOa6/3ajzrQcuBY7S20nS3whNXKpHdGJf dJpJehhV19b58oJLNhb48u1k7/DdVdpnWianwjoOuWCjKcdz7rGCuoSXutKRksYJ3k/koIbOluXF rvFOZUPiAT6Pm4l6Q5gfW1jbejdCiNpxjNMcneSzeAx4DDyXGDiSLWnDxGURzLC06jrdgygchPkX sBfbFAruE4R2b9sTMWz1uVbjtSu2MC3xLZsPj5sUMiq41OBAJ4hOgxEp04wNRfCWMDHYIhPRccbn 0PCjT1Pi1/RELIqv40omzY/VtfiPtJkq2zRfkcaEipfAW0SZ0pNFTN3Vtqu4IUsWMyjNoO+ynPh1 cJ+JPM3reuua2efxErO/gdFC0YNbyaEKD8W7qqO75TYaJNCfyocbPUlF3ZgsLyMWR/3WsrG9L6gf yruDYniDboGM+ESh4FKyQZOx7QPx2FnBdkS6hRRlFq+TOGMR8PskrpPCD7abyu0b6h3hXTImVlDE 093sk0GWTJMUl1nux8KbyTik7SxetPCe0GfrV6x0wFsVvHlp0TQusIvjnAQDOwpu0NnVSA5IGEHD gVwpYAvp9eibg35j+CsUg+2odNsww7ZSaowW9WqDttV2Qh8UlxWHcTNL/yanGcxj0uRCXnm6u6aN Q6bcTuI1OFmRGPKd7VH9mLCwEGXqbrqNkiUynjfUNkUCDwzycjuys/4hX1K+TfvYyUtp2UPFNASP yGJso+Un3Q8Z9wqezI6SCL0RGj/++huFG7rhY0fTxCsRUwtb7XvjwrmshtA2pRXn/aJLJnLeveeO ixiXf7JS6D9DxFIUsLh1dl1e3rvcY0VuJ45orXx1mTewaL18tWLNF9J5Rj64u3yZGHYLC1hkW4Me g/AQtj7g7IMH6zEYy1iIqV1bshYaYOyicffGMk7ztdjn8hjwGHj+MHAkBiMOa7mM61ImjFRMCMP4 PVEcniCOT5VvOYM/UsEtJpNV3uxEU8anXd4gkw5jIib68DHxxoAAiQULxmpKg06S5aRhUv1PlIBU JfFhI1p5xYSDzI6dBiNMn2Wg6MYDCjjBm0ORa92lykR1rIqxnpCFyncBHmUb91qIIxQZiAYoV9rg Ag8DBPVstVu82Yz+7rcQi0ivIFE8dje1lwh9T7Ei72kddMVNv0+enA9KM+i7hCF+JX3mmKSq9Mqo xfi4DEb7t/WETiiCNcRsCYx5CLrc2qxHCktBKTSJ+BV9G/wR5SmtLUGjSNqFuPK7v6091pijrH3L KFwVsEsag0LftLyHXMpaEx4+xUswEtwmeQVs3SaZ5C/xXVluAHf0L2rvSsxLocjr261gMtHrNBE7 p8LLiyuG18K6YeiCV8m93TB9F96Z0qNLGb6SaZKCk+l+HLyZ8DNBM8UrDb4v+RXwpoPex7316FgV Hgv2qqnAF/XgGSrQ7iAEPJD8Fd5PiDMXGjBCXivHQRGG7pY0cjhojj/GSvIlxFe7usKbD8yVhuYt PZYqty0vI8DWbUp6lkYjxFkDnYjx1n3YQiwz02BWHxRgflB7je+ExwwrF0aWp10ux0gh0gdK1+q8 BbkgFg80n4mMNoPkMaG/RH6k2q7rFrTqSk89Y0s34sZhVdQoNwGvMCfzLljsKrrtJm/ewx9iAKpx Ba/H5v3ovfiGv9ZDkxbtcoZ6hn5Vx0RbxGCsGB4uhcA4SnW4IA6j7VEXVEboDXg/Sfqb6aFT4LVb QhfZn4yByO4YQtshfyrwlbuQTeCv4iCE5u1lJYsDw01SIPKI3oQck96NLvmnqh+HXFCFjXiTY6xQ I1mMb/bMw1CyjLuhWkCMVeWYob/Ht27oRep4H8CLUIyP6C/wrBXtVz9bj8ECuZS1YxmnqiJ/4zHg MXDKMXA0BiOKdLJdxek1QtMa91ThKBsGlCAZYdI2E966phVvxHsxStUPPb5MJnrx7SI65ch3RAlI FVYQbGIr3/q26XHlNhjBBffeBlzEEZDRWJGleMNkDgGcReDlymLZUDSEgKptJ+Emf4vtSbwUhPIq gkU37sUnU6JGbXDRAlTms68Uj60b2vOGvne2gtLN/9/e2YTIkWR3PAbG0A1akGAMI/DBMt6D5lZz 9G0uBvWwlzaagxefeuW73HNS70n0XoR8Ee2L3OuDoNuHpXQQ1BoEpTm1DjrUwGBaBi0lg4ZqwSxU wwiqYQS5/5dZkfEiMjKzsqq6qtTz70GTWZkZX7/4fvHihRpsubDLJ+d139S9j8YnfajyLDZJtQ4x cbODv53IhNR+NvEVglO3Ra+VdGJbCzDg1KtktXwhyDywWzCq0iKRhJaNDb91J27Me9QbCwnD93Dr tDYgQCuZXGvNCC0gLDDCIG0opw69wT+ZyOK329JSFHw49yq944lRPqBzH/l3nlHVuDBq+MIKF6Qu lJdJ3+OGv6Ztm1V7JtoFdvxqQx+pFW6/vAyVYfqNpFu2eu9pVmzHhXU2sAZXVz9FKxX5Nm7/dyEs PBhvnRZB7MBqIdaV3x+H4/KCyaTM6NC22LoS9kkSTRe+TKDjWiy6vMbYNkhu8KlfTpv0C7P3p37Y u08j7T+2ctq2QNr6svqcJkqVP798BUke/3TboME9345mvx0l7XzbfFxb2X45j6suA5PEXYdp29W5 ClF1ALF7xbpZuDrPP7Dxm+qXwnFH9hva6g86Tkge4zbtM8VbNBWjGk7Ynm7HASJ0r+xvlH+xNika zWn7hahn0z9sUlfcuLOVdAtbvyUOKI/p1neMc6Lvp49n8sYZSd+JtW3w+ni8mBCO24bPnRZk1YEm WvNq+3Gk/dT5rMa1M6SKTkmABH5mBJYuMGrS6Pt5owYchUGefAnthPGA3+8IlTsMPLcedpLOkzbU U/1/HezRt3aFZBDQdPDmx7Xml2rMpwmnTGAUD9VPf3zAg5XtEqFN3M9mT4cvcXLYLSe0i8WhFTnt S5cVcSNHwcr2ouyf3DtBkuaY85kkH1Ve6NUgF3b55Lzum7r3KcWoKrvKs6pJqop7s8F7Sf4pjaXY tivrSm+/0tzte/86YVpSR+pb5J3B9h5Rxd57uJ/swzbGwWEnOYKG2UAm4+EfthDZQXOsLLnPMSFM B4oQkOb2atzb4asj2FmrLqvVAhuVhhIhgAstu9PbIj0V8+DDbq5FWV4mAyeNfrry2rD9U+VwK7ad WK1qe+UF7qxAJW1zn3STTtAut2G3o4tVdNdmVAnrGiVXCWzAEwLBgdUkkrKX/ttOZCjet6fTxeoi VnWPcKqiLXsuntaP7Or3SVk8NW9fK1SnQ5UnCApzTdMhTnm7K9sUsK269h/q0GGoKaP99ePq0hDr F3x30/Wnyo/b1n6QTvOYT27fDm1/Yfuo+l6VP698qU/8WxU+8tljrybHuj/w3c/vly4Dk8Xdhu3S ECtb9qu5XyHIs3W2WbguvkUhncRyxcdvqOfdR7s19TwifJi1nqqyHdNStPmrt3pWliPl36T5N30Z tbGbz7VRPNRYRtqzjZuyzXkP44j91BZX5yk0R7EYFBlJzB7ZoF9r3dhMT7qVsGUc00Y/1xMNtUjg blEKbTI0B7tPOsW5Ctzv50Lt2NZ6JGHqejp78ukDCZDAxSBwIQRG8cmxG5B4HWHt6lB8sFzY1jbP /FeddmXnXhJmLhCJTWAKbhwXmei2n/fQCe3ngz7pTHFCWMHVuTwQ4chJHyrzR5gYHhSESPf1fmxE oHaAoDpmzVEPnmq3aqkJgi43LuzyyXndN3XvhbEdIPgTIpVnVXmsBkU6/dPmnYsvtm3mM9Oib6Oe m8DXhzthWsbBjPJtQvF6aSezO4Gqt95G4rMsxj994ql5Z99oQZgNB+f7FTTxJhUYxdupYnzy+iy2 biKDSOvC2XcqL5P222muOv/r81WFoNqzaH1T7z1/8y231Xnt8kK+q2akYlV769KbCYySob91uXUv O648z5+wLooR4lSw5Mc/ZjNLty02Yi78ak0WtyXG5bsu7z4fPy75O9h/8ouWqpdN+oW59Kcu7Mo6 ospNjJ/lqLc+e+Ur/6B449iD1+3O+IPFahdJoDoek8Y9i6xiWCVMG6dsbpdJ86QQoIpvVONBvdfp mUt5K0RmpgeybbKPrYFHTzvJwcNAiNTa84yNz1xPFe9o22pTMulYQPlXWaesv7hOX0aVJ3O4bRYP WRgqaQt1m93aqTyMYdpo9x+HNlNjccFW9eBAA39resxN8VlL2WDL4ztFPudueUMCJEACIHAxBEZ6 QJFna8mAQ61cyeB5G6sM1SuyWLV9cBBs68oDmc+NasybDRKz4EsnMNHYOS6eMcpga1Glyn/U3/qH I2hr7IN3aJdEu9R2aTYCexG1A4QSjtodjhzWwRXutSFUrR3h/HCTtNCx/iY20dfvy9TEbV76gzeV Z+EkVUVC23+Zphwpr9JbF19o37zwp5f6W/1dfbiTpUX7n2ArZgcD8c3QaLIe6OFen7yn41Q5CfUC Uj+87Xgm2T08SgbaEDuEncdPrbp4eZnA8DrfgufnqQoruLVloGAcufCd3WpZFX7gqMFPzbA+X5XH JfUw/6LsvdI8krTff1DTNkOjZg/5Ul4y8xAnunHptTyRd2pbsp2g5fkTbLezdo5SocwN2N7DqnFu 9BYCydEPOCEvqvWaRc+FXy0wysNXWxEbT0QLpwq6ctqsX3CaINP3py7syrqqyk1lXVLfTV5uXRwk HR2xm/jGne64CO0iKQWuDDTU6puinclK3Yz/n1pzwfGO52XZ+3mUt1nSDJszh/vQcq04pRF9x77d dq21ACV/1UmxaTsR9GGFZ2E9VWXbtkfR1FBgFMUy6HVgP3XT00YvMI/uWIh61+hhaq8Qtr82ctuD RWGPMf4Wa7cohIXc2/eTvRrtUdGaip5KOHU9bZREfkwCJHCBCSxdYJQoDYLKDrCQCWUDCvth2Xv3 3JiddIuBdbG0qxoETD7AdbHNJxAVwgT3tUp/8L3eL23MnA1eIwLuCOVdb9XNxQ13ikU4kKwdTCu3 HkfPKGtF2GrQLYMIbbdKh12mbeNW/uMTPueHnZB6KU9/2Lz0016eZ84Hrd3gDzrcN83uXHwxWIls EbS+2TgLM4+7/cC7TpIW56D7YDvZxGkvUWtaMPLZ1QYj9Uq1GiDV2nqB8GckwiCtZaQ0zaI2VRBF V1/K83M6gZEVBEFQVWFjzdosqdZwciwb303bNpfVQxuBsvc6z0KbVNbtOV5deVdbvSDkkW1xHRif tn+uvOPErrzMKG0UHMAQsSIB585Gk1+/M59d+FX24/RR6iqeKMP9lzD8P8k/HBDQtwdE2ETptq9R v6Dq89T9qfLjhq+RkUdP6KnDCyq1BsvKl/Ysdq/qfOsOhALjraoyiXP5HHM4v2e6DNS3pTpcxzBW tvSXc72Hxo+1FVcp7CsEWhffsvfu+VLGb8p+WnnbjG2r1s6ZEuqmCGatp6psV20T1zZtKsuR8m/i cjNtv1AoA7M9aFRX3nSTLWwFOwi01rM8QdvyCu9z4V2N3aem0YYAcQ/b2reDBVDrzWjYx5Yye9CB b5/NapyLZnMqxLaOml6nrqd+QP1n2I0wNgOxgUNrem/mtVzjh8NfJEACq0dg+QIj1WGFBt9SXHIa E4w3d3ASRNg02QlT2UCl7L2W2leeeiInEmGr1CI1jJoZ/s4KVD44iZxuEytylou3kjz+UKvAVg1I Yv7WPXMTreD4T+1QCXcKAxg1oI9yUmUpfN+96zrkrZKOe/DEnaZWEDKoFTsTObFLTwZjJ3alSczj HxcoyTc2L8O06zwL64Fo4GQGG7MVq7mthiueIgzai5x24xmMxTchd5219l6nxT6LXpUAobSe/jg+ 7hxh+xppWIlWNq22H7sJvw5rBHta1gaHnoTqleCY8fcRBqDWXWpYNBccaN+ze5vesnaq4EKXNUw4 YoZNjw/diVt14Rf8n/SByv9GbbNyFy0Ppe997YH92OB+HHc5Naz9aC/ZezQ/DaMkr59YSKjIT1tH U0Fd/h0mslYbCbaqigLOUdJ94ASBsbKgJ0Did7cwGIcf53h6py2nTfuF2ftTLQSADY4HRQP3I0zo tF2oysWl0vJVX/CdgWu3+r9Vo5Va72uDL/IyOFlbqn22+RcrW/q7+d6rvIsKeWEkHie2dWBnJT8p cRyBuviWvZ+9vM1AQJUtg22dxXqe+e3qadViwhTx0OGjz9uP9Mn+gQg1i0fKv4nLjXLTqF+YIrmV ThrUFXfwCYTs3iEwLoRefhiOEsS711Pf6bHEfrDlzHo6emG1lZGnSj1dn+5mbpaXtwQ2tY6ftaGB BA3+V4URIoKZvp7aOCaxLePYchkLLXfDGxIggQtDYKUERjJIbvegxo/TZfoYZBzc05Mirb2AQQgm enZFoHUHR/C+0ur/4v5IHTOL9/pYWXUSlkyEN+RIa3mPwb8cTTqA2/277qhL+ea+asRnzn007n05 Bt7+e2GPJ4cRbkyA0lXi8btBSec2fDV2jxXldn7c8ja2QYyfg0f4N4K9oOPvuvmKYHpsNcIZ/KCa fKyguYkwmD/r4VQo9T70tMFvLTCSLScHOCpca3XIKo9drRTmnvFR5Is+fnRLjrJVeT4QHuCYHTWL rYbg6LHztrsgz++qo77FgOVDv6x5Yadp9I9f3kCZy40t/9gPBDZq25usKEpeIl96+T72Vnpcdp7/ thyovNQCIzG8bMt6evww0j3AiV1pHXkQ7o2fr2aYW+HKJlCbdw9SA43Cuw3m5IaYAAANBklEQVTt H8kn/W8Tqvo5F+EmAl+bvpSDq7dp+bPldfzNQI/AR86gqoSxea+d9HVZhUBXHzUeCnb8CTjyXNoJ 1HNpXwav0L4EdVxvQUxgNNuWJSmr6dHFsFUxgK2K0J2s/snx533Vxrj6iXbIMoKg8djWW5veaP1W g7ux210p7zDKKe2a03xw7Pef4fj1+VRTV6N/OnblbtK2WQauz90JbjvYMqa5JMiz4+eunm5JeVF5 OsqPls/StmPLk7TNcsT6c2wpuOmEv8K+bALgElJ/Jyfg9R5bgfFO2o568RYvUJel3LvtJtKGybH3 mf/6tDDpU3ooD6m/Tw+SLSW8TOsLtOaOX/Vzt+JDWF7lu21sh+4+7cLOXNGPg+jEIItLk//P3C/M 3J8Wy7tpbScHEDJ0n+Gkz3t+XyxGkr2iHrYxqnxJP6D7Uzn+vPJPaU9k7VrNhLvSs/qXeTuRto39 5MgaVEfeS91ItcbGbUUs7uK+1+ul/fqOLWMwjtuDG3mevkMb67Wr9dFq8IWfd7uPccQ7tDUHEOh2 H/nG351A/gMev3ltIjRv03GAwhWOJea5vSloO7PyiX4RffLRC8nrI/RNTigt78NTuUY/oP215Umu qq2WhbCwfxrmAnGdxin6BeV82ttZ6oo/9sQ8A2NPvV14oMbgckKlHoZMG1/rLmzX76d1xL7FUuOb XrJrFxsw1jjyAh8l+/k79ImwsdT9bjzXQX8kCyeyXd+NVfBN1AbpNPXUxTG9UwI6W/ZkzjbPqVEQ In+SAAmsEIHlC4wAo6eOPXcNkZsMZc928uNBPVsR4wmVfGO3CrmtT74fe+po7SGO4y4Py3dnYI+i zObMNHlZFr9YfKIG7JRadMyNfbaPI6DzPwx0tCDIfpNeg33yWvU/+24+q2Sh8MHGYePmJvZ1B8y9 gRY6O91pqjzfkuPjox0Z/AvSNXrV8TtW5Y+Ni1xjq3bCcTIDzP4x6GVp1uHF7q3AKBxsxL7Nn825 nGZlZ5gfKZ6HU8LNvcdpUuOBZpOynrpvqWPYUWa1ANH5LyfjBeVFtlDmhd3d9J9aIUD4vf+7dadd GCRqbTsXtu8ufJ4KGiesn6nbwA5OHnMIOHMhYS3vcZxuWWO9uS8z3zRtm7u3Y3wg1EmborJ67Buu 7qlJc8g3/L1xt+MLD6ZJMcqZ1l5xYdh4Z56W1mVrJFkdn+z8iPFQz1Q716Su70VO9Jsm6bIFeB79 wmz9qT+ZqWR3cy9vW2x6m7YxlVt04KnVbJF41Nm8s3GY6tqknRi3AV7cm7jX7epUkS13FAp5y/Kv PRZwftDjt2ARI08rTvDcvFk8TdOmuZzepG/8ttMTEJT0D5sPMiP9LgQIHwr9pmqLIv44IZ/zRe6a 9gu+6yl+NSnrkbrS9zRyXZpjBxLszqtttcksHZ9GDtCIbf1vNBbYSDolCwlN66mNvr3G+6dqbVzr llcSIIEPn8BKCIwwFYeGx050Mr95eze1H6FEH9GVWOm4rZp6/ESCjaQrhiz1nxxxervYydtBwNYd qHdCmj/vP2/rU6STtuHLNTpgneikEGxl8VYqoCGTG2J0HaaE0cJRxpqvpPfogVrVrbAr0YTN4LHy szTdrWTvSfGUNr0nX/NJ1XdP4oKg1p3IBBp5vqf2i2u/zM3dpFenTXUCjZES4VWqdRSAdHZufOZe uBEWeb5D0yU2ocsFJnLUPIwhtpWNlSZ5Mtm3o6T3KNRkytKzje0jfRx37Q1g1Za9/pO4u7L0b3gD JmxRsmxk37y9D65b0DwKtzvodI1kBc/TSnF5sXFrt7yOY7W4c89fsc3i3YIRbGyRHfWTXW8AvpVp u0j99J678MJ0b8ZONLGR/0k0qGLhbyR7T7XGWub/lrbhZP2Y+dqsbfa3ytl0OxswndwujH2HK1Z0 rYDRRncITciyeiYaXzvQvJmb/YSy9hSruX21wj587k4D1PmouQ+/68TrK8rZEdqWsO3feuTaOjcg By9oUx0d3h8bercC0layBW2C4x8spXlc59gvTN2fOoGRbKcVjcr7t7fS+m4ndK0bW8kBynzsb9Co jYmMAzxP9Yq+n//eZ/P4UVbugvbNlbUg7nDvtz+qTgV+bN4LhQfzSIDzYyC2TYIwJd6tm9vJPvpz raniyrkf3w9i/AbmkwjyW7f26scSDt9Ed507WrMSWu+Pu0k71L6TPLixnWrqxzyNtr+RfLNl7n6p 8KRZvxCLS6NnM9aVodry1So7PEO4vZj/eF9rK7dulM03cMgDNI+C4aNDlGqulY+lNm7tJAfQMs61 ppxL765JPfUcpj+GajeD1F2M1SNbIovu+IQESOAiEPhIEoHOYTX+3htz9u7UnOFqPl4zly+t4bqA qJ2dmpPvh8ZcvoIIjMz6pSuLC3sByVuZIN6fmGd/+Macftoym19cN2d/PjGv37w1Zn3NnA2HZu2v r5lrf3vVrC0gz89OEfbrt+YshYOydhVhf4ryNuHf6fcvzeuTzPUIbq5du26ufjK5+wmDWa3P3p+Z k/8fmvXL62aEenLl0wXk1bsTc/Ju3Vz99HLKQtqH4TsQlzbCrCMOlycuL+L25C3iDa9GyLornyD+ k2QZ3L0+hTuUy9HHiMsnWVwWljkSvo33e8diYeFLQEtqm6Wenrw9Q16tpXm2jjY67RcWmvjmgZ1+ f2JGa+tZf4JydnmCcnb2f4dm/fqvEdimOR61zfUJ3DSP2QJcNO5Pz8zhV+vm139Ayh8em/at634k 0/GA/+i8fp19+3uz/vlvUu+3nwzM/V9dPa+gLqS/6fhNukW0lWuXJm+bZ4LRuLzNFJo5+faZ+eZ/ T03rV5vm+iX0iX96bdA8G4xizPD9mrn2y2vm6iQVfrZoONfol09Ps7FIOm5eaNhLGrO71E98d4I2 ed22xSmzYdqnpB5gzH+eeXb29sQM18ZhjPvSdBwjgcuYYjy+qU2MjMHg19nHV8wVM0rHI1cuN69n M9XTs6ysnWGOtoixei0TfkACJLAQAqslMFpIkhkICZAACZAACawYgT8dmo9+KQKjLXP80765vgDB +aoQOPzqo0xg9AgCo38JBEYLi+SZ+f3GuvnN/0iAu2YA62MUFy0MPgMiARIgARIgARJYUQIUGK1o xjBaJEACJEACPw8Cokn18pv/MJ9v/g4JbpmDXtt88Qus3uO/tUvQWGig/fhBEUu1Fl+a//rqc/Pb bxHz2wem/29fIOFIuWhr/P35ajGefv/aiKLoGlQNz14ems/+8esM3622GdzbOFetgw8qnxhZEiAB EiABEiCBny0BCox+tlnPhJMACZAACSydwPuX5su/+sz8sTQiH/gWtdJ0GfPyP780n/1recphdNd0 wi1qFf41evX2j+ajq19WOmm/Sczm31R+wpckQAIkQAIkQAIkcKEJUGB0obOXiSMBEiABElhpAhAY fQ2B0b+XRnLH9H/aNdcu4Ba11//9tfm7f65IOewI7Z6XHaF335p/+sXn5nEp901zNGybf1iwybLS 6PAFCZAACZAACZAACSyBAAVGS4DOIEmABEiABEjAIyDGnWN/F1BQ5CWzLN3y0XmnvSrsRYTvgeAP EiABEiABEiABElg9AhQYrV6eMEYkQAIkQAIkQAIkQAIkQAIkQAIkQAIksFQCFBgtFT8DJwESIAES IAESIAESIAESIAESIAESIIHVI0CB0erlCWNEAiRAAiRAAiRAAiRAAiRAAiRAAiRAAkslQIHRUvEz cBIgARIgARIgARIgARIgARIgARIgARJYPQIUGK1enjBGJEACJEACJEACJEACJEACJEACJEACJLBU AhQYLRU/AycBEiABEiABEiABEiABEiABEiABEiCB1SNAgdHq5QljRAIkQAIkQAIkQAIkQAIkQAIk QAIkQAJLJUCB0VLxM3ASIAESIAESIAESIAESIAESIAESIAESWD0CFBitXp4wRiRAAiRAAiRAAiRA AiRAAiRAAiRAAiSwVAIUGC0VPwMnARIgARIgARIgARIgARIgARIgARIggdUjQIHR6uUJY0QCJEAC JEACJEACJEACJEACJEACJEACSyVAgdFS8TNwEiABEiABEiABEiABEiABEiABEiABElg9AhQYrV6e MEYkQAIkQAIkQAIkQAIkQAIkQAIkQAIksFQCFBgtFT8DJwESIAESIAESIAESIAESIAESIAESIIHV I0CB0erlCWNEAiRAAiRAAiRAAiRAAiRAAiRAAiRAAkslQIHRUvEzcBIgARIgARIgARIgARIgARIg ARIgARJYPQIUGK1enjBGJEACJEACJEACJEACJEACJEACJEACJLBUAhQYLRU/AycBEiABEiABEiAB EiABEiABEiABEiCB1SNAgdHq5QljRAIkQAIkQAIkQAIkQAIkQAIkQAIkQAJLJUCB0VLxM3ASIAES IAESIAESIAESIAESIAESIAESWD0CfwHxqkDnyb/thwAAAABJRU5ErkJggg== --Apple-Mail=_69BDCD1A-9EE0-47F2-B58A-F235D3A0C582-- --Apple-Mail=_EE9B85DE-21C5-4768-A831-A1ADFF02D074-- From nobody Tue Feb 19 08:08:10 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B3C130F0F for ; Tue, 19 Feb 2019 08:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu 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 JZRe5ywagAyF for ; Tue, 19 Feb 2019 08:08:03 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750110.outbound.protection.outlook.com [40.107.75.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78FCB130EE2 for ; Tue, 19 Feb 2019 08:08:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eg+mlfBb94hCde/vCRpE5CmtQ3Hfoaqj8r57/0fYe4M=; b=bxvT79XMuLUlyicx/9SIE4G4Izvg5QzoSta2niqHSYdfWSUM8c98g3BJvT8SexeApw3b/kc374P7jN5IlMxJV9QMRrKF7+bHjeBEslUqau2952B5vuM3RVrMbV8MzdODt7ixsKhZzqE0K71oJmutr7ESy5skZJNxBSm+oNZQ6/c= Received: from SN2PR01CA0051.prod.exchangelabs.com (2603:10b6:800::19) by DM6PR01MB3995.prod.exchangelabs.com (2603:10b6:5:92::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.14; Tue, 19 Feb 2019 16:08:00 +0000 Received: from DM3NAM03FT049.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::208) by SN2PR01CA0051.outlook.office365.com (2603:10b6:800::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1622.16 via Frontend Transport; Tue, 19 Feb 2019 16:08:00 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by DM3NAM03FT049.mail.protection.outlook.com (10.152.83.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.13 via Frontend Transport; Tue, 19 Feb 2019 16:07:59 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x1JG7uMh024964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 19 Feb 2019 11:07:58 -0500 Date: Tue, 19 Feb 2019 10:07:56 -0600 From: Benjamin Kaduk To: Message-ID: <20190219160755.GS24387@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(39860400002)(376002)(396003)(346002)(136003)(2980300002)(189003)(199004)(5660300002)(46406003)(50466002)(104016004)(1076003)(7696005)(16586007)(106002)(58126008)(336012)(36906005)(86362001)(786003)(186003)(316002)(26005)(23726003)(305945005)(126002)(246002)(476003)(33656002)(486006)(356004)(106466001)(55016002)(47776003)(88552002)(426003)(6916009)(97756001)(956004)(26826003)(2351001)(75432002)(30864003)(14444005)(8676002)(8936002)(478600001)(53416004)(2906002)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR01MB3995; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4bcf710f-6b48-4469-82d0-08d696846b74 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060); SRVR:DM6PR01MB3995; X-MS-TrafficTypeDiagnostic: DM6PR01MB3995: X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB3995; 20:q+VLJbbmbhl6D4nLb32DWYxYjmgxvzj/VlCIHl3iXX9r7uoJWlXKOkgRcnoy1dRb4Hcn62mNOIjWvsjWxmvAkFXoEpOCwjLlGzg1PW/LqRo4Ppwxu+avZG/d4fFrxA+vH6Nu+IgIZh9A5/mXDGAAHIA2u9cgUs48zueieNm5R09/HxMUZpd69YyK3SY5ynRTUrhWJfJ8FhhHpWcp2Xl3sLIJZ/prBzxTrXgMvU1yyqULO3IpWFxsjJIEC/6HYYnDzNibs8m0kZa+Q0R2W6tvx7wf0QQDO/EKyHjsoJ0uTonwzJo6Oqd/acpZvPOekZ7VG1xJ1g9Jwnqu12pEXnZ0VXEAeXAuU3ZgH5OuIXsBcAoXT1N2ttJB0Z/ggLQcmEB3kMiWCn37FH2NKe3Jg0B6I3UmjKLc0yWvCa7SGUrTeFc4ZSm/qf/DAkLDMnp73aut8Drf3XoZUiOvoi9oNnSctjjNglcfcHrDiZA6ocMXrF5oMBumYgiGnUHisBtRwhGYYhepzgWYiS6MW9xIn0E9W73Qt9GC4p5O4P2XMQWkft2sOqfFv6Ca/VxHhyzCHVrDGfCP1Ei6LSpktumUxtWop4eCZjkwcSxorsRZYekeAy0= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 09538D3531 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM6PR01MB3995; 23:BERxpRpfSTZJIU7Ds7BqbwrDoew9iPkW0naSABzkD?= =?us-ascii?Q?JVGf2nD8UpSTmpNo/1lMQNKGbdaZ6t1TNVHGjSMXU4CKbdal6Wg7iTcMihG5?= =?us-ascii?Q?lSVDQ3ODgkhr/vJU95aFLwi4MMslm996H55+j0WU49PB8q/hiXteiRPciavw?= =?us-ascii?Q?Jx/lGCk+xltj4qPEkrTYeG5QbgjDdVc6cxtHAgJFqQpOTZHdOHCzwMyJylim?= =?us-ascii?Q?/ia2rFBgoPKuw1rDhEUZ+eVgpAPZq8KagNIZtoJ3Xb4komycoY5S08xg0QYG?= =?us-ascii?Q?34HL1V9V55hSztP4XaEtTft2zwLUwx1VJVRUm35n6VfNx6lSCk+9JvMGcBQL?= =?us-ascii?Q?pHkak35GwhEU1Rwzh6fFK3HV0qxt82n1ykIv9eKAVOesmE2abEO+5WB+H411?= =?us-ascii?Q?lDSz2Cu+7ssr6Yy5Urqt/o6AlvxExlRy+5hVR5wtsj8eC1/zWp2QWSG/zAJC?= =?us-ascii?Q?hRvNcSLLeEEsK8p4NfZ1b73dnrFKz9XKhhZPmR7NS+5FzLDY3DkIer9U1DYA?= =?us-ascii?Q?ELxqIN7mF+pplrh5duyh4+sO/ck6Xh0otDEM1M7C/qNNzJ6I3Kt35FeaYgsE?= =?us-ascii?Q?EbY2zPbAQ51/AuydrR8rY8qmQvXU7FVX7pe6NgiyQj1PUbBeyjdXrldiH2l0?= =?us-ascii?Q?BqgQzBeycLUaj/yvBrgosVfDndbH2JoEDqFmp820H3stDcmypaBezfJkrlP+?= =?us-ascii?Q?VFeZqDW2n/uShPkpgr2sex1C91YVKd4Q1O4OYyXzP8ZqyeLf42t69puQmVSx?= =?us-ascii?Q?L2KTt4XFpB3kANiCnm/LxbaK7SqppkAnF/ImtUvykkd1yr6DeAyrwnSl2NGw?= =?us-ascii?Q?w9cIQKNb5Tfli8xjorrVavUWDOFeOuZ+OxY2Idx/YVDAkzVy9uQJTbMwh+QD?= =?us-ascii?Q?y/wo0qLjw4t9vkzNI7Po4SK0tDLJRylAyP88O5SpXDHY83j6qzs1kF4c5V66?= =?us-ascii?Q?DbkKRu2+u6VZILCI9VZQSsa8HcAe0YexgdjOtuf3XgJ97ZtVTJX3YnwA6h+O?= =?us-ascii?Q?6MWk2wNc7+Xg26OBlVjgd8bcRnrzLv0IS2rfI7ea1xQBYIy4RuXUSPQv+5oh?= =?us-ascii?Q?F84USKgQ5kjQgRagy6LMMiC/bA5aaNUQJ6xwjq7yROSDCtOc+bry5KomW1Xj?= =?us-ascii?Q?eGnQrzFJ+g=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: TYEi1dt1jn72N8v63o6NgamRd68gmrDBgGUwi4wUuVHlLN9SQDeZLZF/ssjswA/76yNNhZFaNNLoz752E1qTT7eQN6WqVJVxXHr6nTixn/JnWN3Ke3E02WWNuyxIWMC3Woj2sRXjDHNb45ujpTXo1qopbJ9TNNwb9Vn0f1swiJ/hhTcPW2vRjhFp3iqAwjU76zBZgEDQR2jyj+GBqjIR6Tnu3uX1GvDOy/cBqm8ykteie0fC3Lc4SvdQGTMxx7kIVQAtISZMpAeiRcnC66xmrduS30PAoKcyPQwbJqpjVZZCWkV/XxG2EMlRw4+sYD8f51wRv7fEzJ7/kcL1+ju+EdQYGfowy+/zY0Ndcz2dBb5wTl2cP9cd8awhJ91jD7uCQjuToGF6nBMLdEKP8lBpLiRtcT5IEA/yIbNOPorkiLo= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Feb 2019 16:07:59.9579 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4bcf710f-6b48-4469-82d0-08d696846b74 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR01MB3995 Archived-At: Subject: [lisp] comments on draft-ietf-lisp-sec-17 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 16:08:09 -0000 Hi folks, Since this document is still sort-of in WGLC, I'm sending my notes on it. They were originally written as notes to myself during my review of 6833bis, so my apologies for the parts that are inscrutable. I can try to clarify as needed. -Ben Section 3 authoritative. In this way the ETR can maliciously redirect traffic directed to a large number of hosts. needs clarification Section 4 LISP-SEC builds on top of the security mechanisms defined in [I-D.ietf-lisp-rfc6833bis] to address the threats described in Section 3 by leveraging the trust relationships existing among the LISP entities participating to the exchange of the Map-Request/Map- Reply messages. [...] I think this may be better as "participating in" (or maybe "party to"). o The ITR, upon needing to transmit a Map-Request message, generates and stores an OTK (ITR-OTK). This ITR-OTK is included into the Encapsulated Control Message (ECM) that contains the Map-Request sent to the Map-Resolver. To provide confidentiality to the ITR- OTK over the path between the ITR and its Map-Resolver, the ITR- OTK SHOULD be encrypted using a preconfigured key shared between the ITR and the Map-Resolver, similar to the key shared between the ETR and the Map-Server in order to secure ETR registration [I-D.ietf-lisp-rfc6833bis]. I think this is "MUST be protected; SHOULD encrypt using the preconfigured key". o The Map-Server derives a new OTK, the MS-OTK, by applying a Key Derivation Function (KDF) to the ITR-OTK. This MS-OTK is included in the Encapsulated Control Message that the Map-Server uses to forward the Map-Request to the ETR. To provide MS-OTK confidentiality over the path between the Map-Server and the ETR, the MS-OTK SHOULD be encrypted using the key shared between the ETR and the Map-Server in order to secure ETR registration [I-D.ietf-lisp-rfc6833bis]. and likewise this would be "MUST be protected; SHOULD encrypt using the key used for registration". o If the Map-Server is acting in proxy mode, as specified in [I-D.ietf-lisp-rfc6833bis], the ETR is not involved in the generation of the Map-Reply. In this case the Map-Server generates the Map-Reply on behalf of the ETR as described below. nit: is what's "described below" the normal ETR procedure (as opposed to the "on behalf of" behavior)? Perhaps "using the same procedure the ETR would use, as described below". o The ETR, upon receiving the ECM encapsulated Map-Request from the Map-Server, decrypts the MS-OTK, if needed, and originates a standard Map-Reply that contains the EID-to-RLOC mapping information as specified in [I-D.ietf-lisp-rfc6833bis]. nit: is this really "originates" (vs. "constructs") if we're going to add the HMAC AD before sending, per the next step? o The ITR, upon receiving the Map-Reply, uses the locally stored ITR-OTK to verify the integrity of the EID-prefix authorization data included in the Map-Reply by the Map-Server. The ITR computes the MS-OTK by applying the same KDF used by the Map- Server, and verifies the integrity of the Map-Reply. If the integrity checks fail, the Map-Reply MUST be discarded. [...] A typical crypto workflow would be to verify the outer message first before inspecting the inner contents. Because this flow is using OTKs, I don't see an actual attack (and perhaps the EID-prefix authorization is still useful), but it's unclear that there's any reason to deviate from the normal practice (which would put the MS-OTK computation and Map-Reply verification first, then the EID-prefix authorization data integrity verification). Section 5.1 OTK Length: The length (in bytes) of the OTK Authentication Data (OTK-AD), that contains the OTK Preamble and the OTK. nit: it also contains the "OTK length" and "OTK encryption ID" fields, if the figure is to be believed about the definition of "OTK-AD". EID HMAC: HMAC of the EID-AD computed and inserted by Map-Server. Before computing the HMAC operation the EID HMAC field MUST be set to 0. The HMAC covers the entire EID-AD. nit: could note that the length of the HMAC depends on the algorithms used. Section 5.2 There's a bit of churn between the EID-AD field descriptions in Section 5.1 and the ones here. The Section 5.1 text does have to cover the ITR-to-Map-Server version that is somewhat abbreviated, so it's unclear if the best choice is to do a full consolidation and have Section 5.2 just say "The EID-AD fields are copied unchanged from the Map-Request received at the ETR". Perhaps there's a middle ground of "the X, Y, and Z fields have the same content and interpretation as in Section 5.1; the A, B, and C fields are similar to those in Section 5.1 but correspond to Map-Reply instead of Map-Request messages. More detail on Map-Reply (as opposed to Map-Request) is in Section 5.7." PKT HMAC: HMAC of the whole Map-Reply packet, including the LISP- SEC Authentication Data. The scope of the authentication goes from the Map-Reply Type field to the PKT HMAC field included. [...] I could see clarifying that this is the top-level "Type=2, Map-Reply" as opposed to the "MR AD Type" field in the figure in this section. Section 5.4 The Map-Request MUST be encapsulated in an ECM, with the S-bit set to 1, to indicate the presence of Authentication Data. If the ITR and the Map-Resolver are configured with a shared key, the ITR-OTK confidentiality SHOULD be protected by wrapping the ITR-OTK with the This seems to duplicate the normative requirement from Section 4. algorithm specified by the OTK Encryption ID field. See Section 5.5 for further details on OTK encryption. nit: this text implies that you could specify an algorithm in the OTK Encryption ID field and then not use it for key wrapping. Maybe "by wrapping the ITR-OTK; the algorithm used for wrapping is specified in the OTK Encryption ID field". not-nit: we need some text about how the Map-Resolver knows what KEK was used for key wrapping. Presumably we assume it is the configured shared key unless otherwise specified by manual configuration, but this needs to be explicitly stated. The Requested HMAC ID field contains the suggested HMAC algorithm to be used by the Map-Server and the ETR to protect the integrity of the ECM Authentication data and of the Map-Reply. To be clear: the Map-Server and ETR can use different HMAC algorithms if local configuration requires it, right? The (lack of) negotiation story and downgrade protection for this algorithm selection is not very good, but I guess most of the protection here relies on keeping the OTKs secret via the mapping system and it would be hard for an attacker to spoof an HMAC without the OTK. The KDF ID field specifies the suggested key derivation function to be used by the Map-Server to derive the MS-OTK. A KDF Value of NONE (0), MAY be used to specify that the ITR has no preferred KDF ID. This also doesn't have much of a negotiation story; attempts at protocol agility (viz. BCP 201) will probably involve some amount of connection failures. In response to an encapsulated Map-Request that has the S-bit set, an ITR MUST receive a Map-Reply with the S-bit set, that includes an EID-AD and a PKT-AD. If the Map-Reply does not include both ADs, the ITR MUST discard it. [...] This seems to be necessary behavior for security, but also seems to be a deployability nightmare -- all Map-Servers and ETRs must get software upgrades to support LISP-SEC before any ITR can safely start setting the S bit, if I understand correctly. (And of course the presence of xTRs makes the needed configuration a bit more exciting.) Upon receiving a Map-Reply, the ITR must verify the integrity of both the EID-AD and the PKT-AD, and MUST discard the Map-Reply if one of the integrity checks fails. After processing the Map-Reply, the ITR must discard the pair associated to the Map-Reply nit: "one or both of the integrity checks". not-nit: it's not entirely clear whether discarding after *any* reply is appropriate, or only one which has at least one HMAC validate. That is, discard-after-any-reply opens up a DoS attack where an attacker can cause the ITR to fail to accept valid responses, if the attacker is faster than the valid response. The integrity of the EID-AD is verified using the locally stored ITR- OTK to re-compute the HMAC of the EID-AD using the algorithm specified in the EID HMAC ID field. If the EID HMAC ID field does not match the Requested HMAC ID the ITR SHOULD discard the Map-Reply and send, at the first opportunity it needs to, a new Map-Request with a different Requested HMAC ID field, according to ITR's local policy. [...] I'm a bit confused by this procedure for HMAC ID mismatch. If the ITR supports the returned algorithm and the returned algorithm is secure, there should be no problem with validating the HMAC and using the data (if it validates). So "SHOULD discard" doesn't seem to make sense in that case. I can sort-of see some desire to start a new mapping transaction that will result in the requested HMAC ID being used, but this guidance ("according to local policy", "different Requested HMAC ID field" does not seem to be sufficient to get a high likelihood of HMAC ID agreement. I also note that BCP 201 says that the algorithm negotiation/selection SHOULD be integrity protected; I don't think that the current procedure meets that threshold. If the KDF ID in the Map-Reply does not match the KDF ID requested in the Map-Request, the ITR SHOULD discard the Map- Reply and send, at the first opportunity it needs to, a new Map- Request with a different KDF ID, according to ITR's local policy. (ditto) The derived MS-OTK is then used to re-compute the HMAC of the PKT-AD using the Algorithm specified in the PKT HMAC ID field. If the PKT HMAC ID field does not match the Requested HMAC ID the ITR SHOULD discard the Map-Reply and send, at the first opportunity it needs to, a new Map-Request with a different Requested HMAC ID according to ITR's local policy or until all HMAC IDs supported by the ITR have been attempted. (and here) Each individual Map-Reply EID-record is considered valid only if: (1) both EID-AD and PKT-AD are valid, and (2) the intersection of the EID-prefix in the Map-Reply EID-record with one of the EID-prefixes contained in the EID-AD is not empty. [...] nit: from a terminology sense, the "intersection" is inferred to be set intersection, which acts on a pair of sets. "One of" the EID-prefixes is perhaps not the intended set. Do I understand correctly that we require an exact match of prefix-length and value, or is it okay to have more of a subset relation? The ITR SHOULD send SMR triggered Map-Requests over the mapping We don't seem to expand Solicit-Map-Request in this document, and only use it once, so maybe we could just expand it out here and not rely on the reader also having 6833bis up, ... system in order to receive a secure Map-Reply. If an ITR accepts piggybacked Map-Replies, it SHOULD also send a Map-Request over the mapping system in order to verify the piggybacked Map-Reply with a secure Map-Reply. though it's actually not entirely clear to me why this guidance needs to be in LISP-SEC (and, actually, is not already covered by 6833bis as-is). Section 5.4.1 We talk a bit more about the "intersection" and "empty set" here; similar comments as above apply. Section 5.4.2 System such as LISP+ALT [RFC6836], the PITR performs the functions of both the ITR and the Map-Resolver forwarding the Map-Request encapsulated in an ECM header that includes the Authentication Data fields as described in Section 5.6. editorial: could you mention that it is forwarded to the Map-Server, for clarity? Section 5.5 For both the ITR/Map-Resolver and Map-Server/ETR exchanges, if it is no mandatory to use the preconfigured shared key, we need some text about how to know what other key might be used. MS-OTK confidentiality is required in the path between the Map-Server and the ETR, the MS-OTK SHOULD be encrypted using the preconfigured key shared between the Map-Server and the ETR for the purpose of securing ETR registration [I-D.ietf-lisp-rfc6833bis]. Similarly, if This duplicates noramtive requirements from Section 4. (Also, it's a comma splice.) ITR-OTK confidentiality is required in the path between the ITR and the Map-Resolver, the ITR-OTK SHOULD be encrypted with a key shared between the ITR and the Map-Resolver. This one's not a comma splice, but still duplicates Section 4. Section 5.5 The OTK is encrypted using the algorithm specified in the OTK Encryption ID field. When the AES Key Wrap algorithm is used to encrypt a 128-bit OTK, according to [RFC3394], the AES Key Wrap Initialization Value MUST be set to 0xA6A6A6A6A6A6A6A6 (64 bits). The output of the AES Key Wrap operation is 192-bit long. The most significant 64-bit are copied in the One-Time Key Preamble field, while the 128 less significant bits are copied in the One-Time Key field of the LISP-SEC Authentication Data. Limiting to 128-bit keys is a bit risky given the threat of quantum computers and Grover's algorithm; systems that are targetting post-quantum security with symmetric crypto are ensuring that they can use 256-bit symmetric keys to retain the desired safety margin. Note also that BCP 201 tells us to expect the MTI key size to increase over time. Also, it is generally a more useful mindset to think of the key wrapping (or any crypto algorithm, really) as an operation from byte array to byte array, with the input and output sizes not necessarily being the same. So here we would just have a 192-bit wrapped key and not try to assign any internal structure. The rhetorical gymnastics to retain the current encoding and possibility of unencrypted keys would then be to define a "null wrapping" algorithm that just prepends 64 bits of zeroes to the key being wrapped. When decrypting an encrypted OTK the receiver MUST verify that the Initialization Value resulting from the AES Key Wrap decryption operation is equal to 0xA6A6A6A6A6A6A6A6. [...] nit: we could mention that this is the default IV (from RFC 3394 section 2.2.3.1), since we only need an integrity check for the duration that the key is wrapped. Section 5.6 Protecting the confidentiality of the ITR-OTK and, in general, the security of how the Map-Request is handed by the Map-Resolver to the Map-Server, is specific to the particular Mapping System used, and outside of the scope of this memo. It may be appropriate to reiterate the need for confidentiality protection of the ITR-OTK, here. In Mapping Systems where the Map-Server is compliant with [I-D.ietf-lisp-rfc6833bis], the Map-Resolver originates a new ECM header with the S-bit set, that contains the unencrypted ITR-OTK, as specified in Section 5.5, and the other data derived from the ECM Authentication Data of the received encapsulated Map-Request. I don't really understand what this is trying to say. Why is 6833bis compliance important? Do we need to phrase it as "with the S bit set" instead of (or in addition to?) "the security mechanism specified in this document?" The part about copying the contents into the new encapuslated Map-Request does seem straightforward, though. The Map-Resolver then forwards to the Map-Server the received Map- Request, encapsulated in the new ECM header that includes the newly computed Authentication Data fields. I would suggest not using the term "forwards" when the authentication data has been recomputed. Section 5.7 If the S-bit contained in the Map-Register was clear the Map-Server decapsulates the ECM and generates a new ECM encapsulated Map-Request that does not contain an ECM Authentication Data, as specified in [I-D.ietf-lisp-rfc6833bis]. The Map-Server does not perform any further LISP-SEC processing, and the Map-Reply will not be protected. This doesn't make sense -- such an unprotected Map-Reply will be rejected by the ITR, per Section 5.4. If the algorithm specified in the KDF ID field is not supported, the Map-Server uses a different algorithm to derive the key and updates the KDF ID field accordingly. Do we need to give any guidance on how this "different algorithm" is selected? If MS- OTK confidentiality is required, then the MS-OTK SHOULD be encrypted, by wrapping the MS-OTK with the algorithm specified by the OTK Encryption ID field as specified in Section 5.5. Similarly to my previous comments, I'd expect this language to be more of a "the MS-OTK MUST have confidentiality protection for transit, which SHOULD be provided by encryption using the shared key from mapping registration". Also, the way to know what KEK should be used to unwrap the key needs to be talked about. It's fine to assume the share key for mapping registration unless otherwise indicated by configuration, but if we do not mandate the use of that key, we need to say how an other key would be used. The Map-Server then forwards the updated ECM encapsulated Map- Request, that contains the OTK-AD, the EID-AD, and the received Map- Request to an authoritative ETR as specified in [I-D.ietf-lisp-rfc6833bis]. As above, I would suggest a different word than "forwards" here. Section 5.8 If the ETR does not support the Requested HMAC ID, it uses a different algorithm and updates the PKT HMAC ID field accordingly. (as above) "how does it pick the different algorithm?" Section 6.1 We also assume that the mapping system globally supports lisp-sec; there is no provision for incremnetal deployment as specified. Section 6.4 With a title like "Deploying LISP-SEC" I expected something like "deployment considerations", i.e., guidance on what steps to do in what order. Does this feel more like an applicability statement to you? As an example, in certain closed and controlled deployments, it is possible that the threat associated with a MiTM between the xTR and the Mapping System is very low, and after carfeul consideration it may be decided to allow a NULL key wrapping algorithm while carrying the OTKs between the xTR and the Mapping System. I would be more comfortable if this included phrasing similar to "the physical and network security of the closed environment is deemed to be sufficient to provide confidentiality protection to the OTKs". Section 6.6 If a replayed Map-Reply arrives at the ITR, there is no that matches the incoming Map-Reply and will be discarded. I think it is more relevant to just say that there is no matching nonce; the ITR-OTK is not used in the lookup process. In case of replayed Map-Request, the Map-Server, Map-Resolver and ETR will have to do a LISP-SEC computation. This is equivalent to a valid LISP-SEC computation and an attacker does not obtain any benefit. Perhaps, "does not obtain any benefit from the replay as compared to generating a new Map-Request". Section 6.8 We say that we protect from attacks, but from a rhetoric point of view, we should probably say what those attacks would be targetting, i.e., what systems/protocol exchanges we are protecting. Section 7.1, 7.2 It's surprising to see the registry creation in this document, given that 6833bis defines the fields that carry the AD type values. (That is, I'd expect 6833bis to create the registries as empty registries and this document to just make registrations.) Section 7.3 I don't really think that SHA1-96 is considered to provide an adequate level of security anymore, so I'd suggest making SHA256-128 the MUST and demoting SHA1-96 to a "SHOULD (for legacy compatibility)". BTW, BCP 201 suggests to break the MTI algorithm list into a separate document to make it easier to update without revving the base spec. Also, these HMAC algorithm IDs seem to be exactly duplicating the "LISP Algorithm ID Numbers" from rfc6833bis; do they somehow offer different functionality such that a common registry could not be used? Section 7.4 The currently defined AD type formats only admit 196 bits of (wrapped) key material; it seems prudent to mention that values allocated here need to produce wrapped keys that fit within that space, or that they will need to define corresponding new AD types to hold the wrapped keys. From nobody Wed Feb 20 13:14:41 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B8012D4F0 for ; Wed, 20 Feb 2019 13:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N_0kDiCLt4V4 for ; Wed, 20 Feb 2019 13:14:35 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69E3E12F295 for ; Wed, 20 Feb 2019 13:14:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22641; q=dns/txt; s=iport; t=1550697275; x=1551906875; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=FCQMwPzfS927LcfjhonLIiI9CITpjDg+k3AHvJXx1+k=; b=cWDid+Pe5kfsipKU9xMPoMAiT+BtXl53oVBTLXHyL3PJwXkiF/W/TNjs biI3ks8G4FSMuDDNwY3Toar7MrQim4NJZnbWpfXvpZYHghC3apLoiYsyj JksWQ6bRpehSrQG/SaMVJBk7LzCshmjO3pnM9fB6D6O3virmAgBe2RrVF w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAADOwm1c/5ldJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVAIBAQEBCwGCA2dQMyeEB5QDgWAIJXyZFwQNGAuBVIJ1AoN?= =?us-ascii?q?0IjcGDQEDAQECAQECbRwMhUsBAQQBARgJFTYEFwsYAgImAgInMBMGAgEBgxw?= =?us-ascii?q?BgXIPrjCBL4VEhGkFgQuIcYEGgSQBHReBQD+BEScMgWFJNYMeAQGBSwmDFoJ?= =?us-ascii?q?XAol4OIZnO1qRIAmLK4cpBhmBcIhxiCWLV5EbgV0igVYzGggbFRohgmyCJQM?= =?us-ascii?q?XiF+FYB4DMI1AK4IgAQE?= X-IronPort-AV: E=Sophos;i="5.58,392,1544486400"; d="scan'208";a="303825897" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Feb 2019 21:14:09 +0000 Received: from [10.41.34.78] ([10.41.34.78]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id x1KLE8aM007505 for ; Wed, 20 Feb 2019 21:14:09 GMT To: lisp@ietf.org References: <20190219160755.GS24387@kduck.mit.edu> From: Fabio Maino Message-ID: <9b9963f4-1718-7eab-fdca-4d724625a5d1@cisco.com> Date: Wed, 20 Feb 2019 13:14:07 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190219160755.GS24387@kduck.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Outbound-SMTP-Client: 10.41.34.78, [10.41.34.78] X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [lisp] comments on draft-ietf-lisp-sec-17 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 21:14:39 -0000 Thanks Ben, we will indeed be looking at these comments with the perspective of the RFCbis in mind. Fabio On 2/19/19 8:07 AM, Benjamin Kaduk wrote: > Hi folks, > > Since this document is still sort-of in WGLC, I'm sending my notes on it. > They were originally written as notes to myself during my review of > 6833bis, so my apologies for the parts that are inscrutable. I can try to > clarify as needed. > > -Ben > > > Section 3 > > authoritative. In this way the ETR can maliciously redirect traffic > directed to a large number of hosts. > > needs clarification > > Section 4 > > LISP-SEC builds on top of the security mechanisms defined in > [I-D.ietf-lisp-rfc6833bis] to address the threats described in > Section 3 by leveraging the trust relationships existing among the > LISP entities participating to the exchange of the Map-Request/Map- > Reply messages. [...] > > I think this may be better as "participating in" (or maybe "party to"). > > o The ITR, upon needing to transmit a Map-Request message, generates > and stores an OTK (ITR-OTK). This ITR-OTK is included into the > Encapsulated Control Message (ECM) that contains the Map-Request > sent to the Map-Resolver. To provide confidentiality to the ITR- > OTK over the path between the ITR and its Map-Resolver, the ITR- > OTK SHOULD be encrypted using a preconfigured key shared between > the ITR and the Map-Resolver, similar to the key shared between > the ETR and the Map-Server in order to secure ETR registration > [I-D.ietf-lisp-rfc6833bis]. > > I think this is "MUST be protected; SHOULD encrypt using the preconfigured > key". > > o The Map-Server derives a new OTK, the MS-OTK, by applying a Key > Derivation Function (KDF) to the ITR-OTK. This MS-OTK is included > in the Encapsulated Control Message that the Map-Server uses to > forward the Map-Request to the ETR. To provide MS-OTK > confidentiality over the path between the Map-Server and the ETR, > the MS-OTK SHOULD be encrypted using the key shared between the > ETR and the Map-Server in order to secure ETR registration > [I-D.ietf-lisp-rfc6833bis]. > > and likewise this would be "MUST be protected; SHOULD encrypt using the key > used for registration". > > o If the Map-Server is acting in proxy mode, as specified in > [I-D.ietf-lisp-rfc6833bis], the ETR is not involved in the > generation of the Map-Reply. In this case the Map-Server > generates the Map-Reply on behalf of the ETR as described below. > > nit: is what's "described below" the normal ETR procedure (as opposed to > the "on behalf of" behavior)? Perhaps "using the same procedure the ETR > would use, as described below". > > o The ETR, upon receiving the ECM encapsulated Map-Request from the > Map-Server, decrypts the MS-OTK, if needed, and originates a > standard Map-Reply that contains the EID-to-RLOC mapping > information as specified in [I-D.ietf-lisp-rfc6833bis]. > > nit: is this really "originates" (vs. "constructs") if we're going to add > the HMAC AD before sending, per the next step? > > o The ITR, upon receiving the Map-Reply, uses the locally stored > ITR-OTK to verify the integrity of the EID-prefix authorization > data included in the Map-Reply by the Map-Server. The ITR > computes the MS-OTK by applying the same KDF used by the Map- > Server, and verifies the integrity of the Map-Reply. If the > integrity checks fail, the Map-Reply MUST be discarded. [...] > > A typical crypto workflow would be to verify the outer message first before > inspecting the inner contents. Because this flow is using OTKs, I don't > see an actual attack (and perhaps the EID-prefix authorization is still > useful), but it's unclear that there's any reason to deviate from the > normal practice (which would put the MS-OTK computation and Map-Reply > verification first, then the EID-prefix authorization data integrity > verification). > > Section 5.1 > > OTK Length: The length (in bytes) of the OTK Authentication Data > (OTK-AD), that contains the OTK Preamble and the OTK. > > nit: it also contains the "OTK length" and "OTK encryption ID" fields, if > the figure is to be believed about the definition of "OTK-AD". > > EID HMAC: HMAC of the EID-AD computed and inserted by Map-Server. > Before computing the HMAC operation the EID HMAC field MUST be set > to 0. The HMAC covers the entire EID-AD. > > nit: could note that the length of the HMAC depends on the algorithms used. > > Section 5.2 > > There's a bit of churn between the EID-AD field descriptions in Section 5.1 > and the ones here. The Section 5.1 text does have to cover the > ITR-to-Map-Server version that is somewhat abbreviated, so it's unclear if > the best choice is to do a full consolidation and have Section 5.2 just say > "The EID-AD fields are copied unchanged from the Map-Request received at > the ETR". Perhaps there's a middle ground of "the X, Y, and Z fields have > the same content and interpretation as in Section 5.1; the A, B, and C > fields are similar to those in Section 5.1 but correspond to Map-Reply > instead of Map-Request messages. More detail on Map-Reply (as opposed to > Map-Request) is in Section 5.7." > > PKT HMAC: HMAC of the whole Map-Reply packet, including the LISP- > SEC Authentication Data. The scope of the authentication goes > from the Map-Reply Type field to the PKT HMAC field included. [...] > > I could see clarifying that this is the top-level "Type=2, Map-Reply" as > opposed to the "MR AD Type" field in the figure in this section. > > Section 5.4 > > The Map-Request MUST be encapsulated in an ECM, with the S-bit set to > 1, to indicate the presence of Authentication Data. If the ITR and > the Map-Resolver are configured with a shared key, the ITR-OTK > confidentiality SHOULD be protected by wrapping the ITR-OTK with the > > This seems to duplicate the normative requirement from Section 4. > > algorithm specified by the OTK Encryption ID field. See Section 5.5 > for further details on OTK encryption. > > nit: this text implies that you could specify an algorithm in the OTK > Encryption ID field and then not use it for key wrapping. Maybe "by > wrapping the ITR-OTK; the algorithm used for wrapping is specified in the > OTK Encryption ID field". > not-nit: we need some text about how the Map-Resolver knows what KEK was > used for key wrapping. Presumably we assume it is the configured shared > key unless otherwise specified by manual configuration, but this needs to > be explicitly stated. > > The Requested HMAC ID field contains the suggested HMAC algorithm to > be used by the Map-Server and the ETR to protect the integrity of the > ECM Authentication data and of the Map-Reply. > > To be clear: the Map-Server and ETR can use different HMAC algorithms if > local configuration requires it, right? The (lack of) negotiation story > and downgrade protection for this algorithm selection is not very good, but > I guess most of the protection here relies on keeping the OTKs secret via > the mapping system and it would be hard for an attacker to spoof an HMAC > without the OTK. > > The KDF ID field specifies the suggested key derivation function to > be used by the Map-Server to derive the MS-OTK. A KDF Value of NONE > (0), MAY be used to specify that the ITR has no preferred KDF ID. > > This also doesn't have much of a negotiation story; attempts at protocol > agility (viz. BCP 201) will probably involve some amount of connection > failures. > > In response to an encapsulated Map-Request that has the S-bit set, an > ITR MUST receive a Map-Reply with the S-bit set, that includes an > EID-AD and a PKT-AD. If the Map-Reply does not include both ADs, the > ITR MUST discard it. [...] > > This seems to be necessary behavior for security, but also seems to be a > deployability nightmare -- all Map-Servers and ETRs must get software > upgrades to support LISP-SEC before any ITR can safely start setting the S > bit, if I understand correctly. (And of course the presence of xTRs makes > the needed configuration a bit more exciting.) > > Upon receiving a Map-Reply, the ITR must verify the integrity of both > the EID-AD and the PKT-AD, and MUST discard the Map-Reply if one of > the integrity checks fails. After processing the Map-Reply, the ITR > must discard the pair associated to the Map-Reply > > nit: "one or both of the integrity checks". > not-nit: it's not entirely clear whether discarding after > *any* reply is appropriate, or only one which has at least one HMAC > validate. That is, discard-after-any-reply opens up a DoS attack where an > attacker can cause the ITR to fail to accept valid responses, if the > attacker is faster than the valid response. > > The integrity of the EID-AD is verified using the locally stored ITR- > OTK to re-compute the HMAC of the EID-AD using the algorithm > specified in the EID HMAC ID field. If the EID HMAC ID field does > not match the Requested HMAC ID the ITR SHOULD discard the Map-Reply > and send, at the first opportunity it needs to, a new Map-Request > with a different Requested HMAC ID field, according to ITR's local > policy. [...] > > I'm a bit confused by this procedure for HMAC ID mismatch. If the ITR > supports the returned algorithm and the returned algorithm is secure, there > should be no problem with validating the HMAC and using the data (if it > validates). So "SHOULD discard" doesn't seem to make sense in that case. > I can sort-of see some desire to start a new mapping transaction that will > result in the requested HMAC ID being used, but this guidance ("according > to local policy", "different Requested HMAC ID field" does not seem to be > sufficient to get a high likelihood of HMAC ID agreement. > > I also note that BCP 201 says that the algorithm negotiation/selection > SHOULD be integrity protected; I don't think that the current procedure > meets that threshold. > > If the KDF ID in the Map-Reply does not match the > KDF ID requested in the Map-Request, the ITR SHOULD discard the Map- > Reply and send, at the first opportunity it needs to, a new Map- > Request with a different KDF ID, according to ITR's local policy. > > (ditto) > > The derived MS-OTK is then used to re-compute the HMAC of the PKT-AD > using the Algorithm specified in the PKT HMAC ID field. If the PKT > HMAC ID field does not match the Requested HMAC ID the ITR SHOULD > discard the Map-Reply and send, at the first opportunity it needs to, > a new Map-Request with a different Requested HMAC ID according to > ITR's local policy or until all HMAC IDs supported by the ITR have > been attempted. > > (and here) > > Each individual Map-Reply EID-record is considered valid only if: (1) > both EID-AD and PKT-AD are valid, and (2) the intersection of the > EID-prefix in the Map-Reply EID-record with one of the EID-prefixes > contained in the EID-AD is not empty. [...] > > nit: from a terminology sense, the "intersection" is inferred to be set > intersection, which acts on a pair of sets. "One of" the EID-prefixes is > perhaps not the intended set. > Do I understand correctly that we require an exact match of prefix-length > and value, or is it okay to have more of a subset relation? > > The ITR SHOULD send SMR triggered Map-Requests over the mapping > > We don't seem to expand Solicit-Map-Request in this document, and only use > it once, so maybe we could just expand it out here and not rely on the > reader also having 6833bis up, ... > > system in order to receive a secure Map-Reply. If an ITR accepts > piggybacked Map-Replies, it SHOULD also send a Map-Request over the > mapping system in order to verify the piggybacked Map-Reply with a > secure Map-Reply. > > though it's actually not entirely clear to me why this guidance needs to be > in LISP-SEC (and, actually, is not already covered by 6833bis as-is). > > Section 5.4.1 > > We talk a bit more about the "intersection" and "empty set" here; similar > comments as above apply. > > Section 5.4.2 > > System such as LISP+ALT [RFC6836], the PITR performs the functions of > both the ITR and the Map-Resolver forwarding the Map-Request > encapsulated in an ECM header that includes the Authentication Data > fields as described in Section 5.6. > > editorial: could you mention that it is forwarded to the Map-Server, for > clarity? > > Section 5.5 > > For both the ITR/Map-Resolver and Map-Server/ETR exchanges, if it is no > mandatory to use the preconfigured shared key, we need some text about how > to know what other key might be used. > > MS-OTK confidentiality is required in the path between the Map-Server > and the ETR, the MS-OTK SHOULD be encrypted using the preconfigured > key shared between the Map-Server and the ETR for the purpose of > securing ETR registration [I-D.ietf-lisp-rfc6833bis]. Similarly, if > > This duplicates noramtive requirements from Section 4. (Also, it's a comma > splice.) > > ITR-OTK confidentiality is required in the path between the ITR and > the Map-Resolver, the ITR-OTK SHOULD be encrypted with a key shared > between the ITR and the Map-Resolver. > > This one's not a comma splice, but still duplicates Section 4. > > Section 5.5 > > The OTK is encrypted using the algorithm specified in the OTK > Encryption ID field. When the AES Key Wrap algorithm is used to > encrypt a 128-bit OTK, according to [RFC3394], the AES Key Wrap > Initialization Value MUST be set to 0xA6A6A6A6A6A6A6A6 (64 bits). > The output of the AES Key Wrap operation is 192-bit long. The most > significant 64-bit are copied in the One-Time Key Preamble field, > while the 128 less significant bits are copied in the One-Time Key > field of the LISP-SEC Authentication Data. > > Limiting to 128-bit keys is a bit risky given the threat of quantum > computers and Grover's algorithm; systems that are targetting post-quantum > security with symmetric crypto are ensuring that they can use 256-bit > symmetric keys to retain the desired safety margin. > Note also that BCP 201 tells us to expect the MTI key size to increase over > time. > > Also, it is generally a more useful mindset to think of the key wrapping > (or any crypto algorithm, really) as an operation from byte array to byte > array, with the input and output sizes not necessarily being the same. So > here we would just have a 192-bit wrapped key and not try to assign any > internal structure. The rhetorical gymnastics to retain the current > encoding and possibility of unencrypted keys would then be to define a > "null wrapping" algorithm that just prepends 64 bits of zeroes to the key > being wrapped. > > When decrypting an encrypted OTK the receiver MUST verify that the > Initialization Value resulting from the AES Key Wrap decryption > operation is equal to 0xA6A6A6A6A6A6A6A6. [...] > > nit: we could mention that this is the default IV (from RFC 3394 section > 2.2.3.1), since we only need an integrity check for the duration that the > key is wrapped. > > Section 5.6 > > Protecting the confidentiality of the ITR-OTK and, in general, the > security of how the Map-Request is handed by the Map-Resolver to the > Map-Server, is specific to the particular Mapping System used, and > outside of the scope of this memo. > > It may be appropriate to reiterate the need for confidentiality protection > of the ITR-OTK, here. > > In Mapping Systems where the Map-Server is compliant with > [I-D.ietf-lisp-rfc6833bis], the Map-Resolver originates a new ECM > header with the S-bit set, that contains the unencrypted ITR-OTK, as > specified in Section 5.5, and the other data derived from the ECM > Authentication Data of the received encapsulated Map-Request. > > I don't really understand what this is trying to say. Why is 6833bis > compliance important? Do we need to phrase it as "with the S bit set" > instead of (or in addition to?) "the security mechanism specified in this > document?" The part about copying the contents into the new encapuslated > Map-Request does seem straightforward, though. > > The Map-Resolver then forwards to the Map-Server the received Map- > Request, encapsulated in the new ECM header that includes the newly > computed Authentication Data fields. > > I would suggest not using the term "forwards" when the authentication data > has been recomputed. > > Section 5.7 > > If the S-bit contained in the Map-Register was clear the Map-Server > decapsulates the ECM and generates a new ECM encapsulated Map-Request > that does not contain an ECM Authentication Data, as specified in > [I-D.ietf-lisp-rfc6833bis]. The Map-Server does not perform any > further LISP-SEC processing, and the Map-Reply will not be protected. > > This doesn't make sense -- such an unprotected Map-Reply will be rejected > by the ITR, per Section 5.4. > > If the algorithm specified in the KDF ID field is not supported, the > Map-Server uses a different algorithm to derive the key and updates > the KDF ID field accordingly. > > Do we need to give any guidance on how this "different algorithm" is > selected? > > If MS- > OTK confidentiality is required, then the MS-OTK SHOULD be encrypted, > by wrapping the MS-OTK with the algorithm specified by the OTK > Encryption ID field as specified in Section 5.5. > > Similarly to my previous comments, I'd expect this language to be more of a > "the MS-OTK MUST have confidentiality protection for transit, which SHOULD > be provided by encryption using the shared key from mapping registration". > Also, the way to know what KEK should be used to unwrap the key needs to be > talked about. It's fine to assume the share key for mapping registration > unless otherwise indicated by configuration, but if we do not mandate the > use of that key, we need to say how an other key would be used. > > The Map-Server then forwards the updated ECM encapsulated Map- > Request, that contains the OTK-AD, the EID-AD, and the received Map- > Request to an authoritative ETR as specified in > [I-D.ietf-lisp-rfc6833bis]. > > As above, I would suggest a different word than "forwards" here. > > Section 5.8 > > If the ETR does not support the Requested HMAC ID, it uses a > different algorithm and updates the PKT HMAC ID field accordingly. > > (as above) "how does it pick the different algorithm?" > > Section 6.1 > > We also assume that the mapping system globally supports lisp-sec; there is > no provision for incremnetal deployment as specified. > > Section 6.4 > > With a title like "Deploying LISP-SEC" I expected something like > "deployment considerations", i.e., guidance on what steps to do in what > order. Does this feel more like an applicability statement to you? > > As an example, in certain closed and controlled deployments, it is > possible that the threat associated with a MiTM between the xTR and > the Mapping System is very low, and after carfeul consideration it > may be decided to allow a NULL key wrapping algorithm while carrying > the OTKs between the xTR and the Mapping System. > > I would be more comfortable if this included phrasing similar to "the > physical and network security of the closed environment is deemed to be > sufficient to provide confidentiality protection to the OTKs". > > Section 6.6 > > If a > replayed Map-Reply arrives at the ITR, there is no > that matches the incoming Map-Reply and will be discarded. > > I think it is more relevant to just say that there is no matching nonce; > the ITR-OTK is not used in the lookup process. > > In case of replayed Map-Request, the Map-Server, Map-Resolver and ETR > will have to do a LISP-SEC computation. This is equivalent to a > valid LISP-SEC computation and an attacker does not obtain any > benefit. > > Perhaps, "does not obtain any benefit from the replay as compared to > generating a new Map-Request". > > Section 6.8 > > We say that we protect from attacks, but from a rhetoric point of view, we > should probably say what those attacks would be targetting, i.e., what > systems/protocol exchanges we are protecting. > > Section 7.1, 7.2 > > It's surprising to see the registry creation in this document, given that > 6833bis defines the fields that carry the AD type values. (That is, I'd > expect 6833bis to create the registries as empty registries and this > document to just make registrations.) > > Section 7.3 > > I don't really think that SHA1-96 is considered to provide an adequate > level of security anymore, so I'd suggest making SHA256-128 the MUST and > demoting SHA1-96 to a "SHOULD (for legacy compatibility)". > > BTW, BCP 201 suggests to break the MTI algorithm list into a separate > document to make it easier to update without revving the base spec. > > Also, these HMAC algorithm IDs seem to be exactly duplicating the "LISP > Algorithm ID Numbers" from rfc6833bis; do they somehow offer different > functionality such that a common registry could not be used? > > Section 7.4 > > The currently defined AD type formats only admit 196 bits of (wrapped) key > material; it seems prudent to mention that values allocated here need to > produce wrapped keys that fit within that space, or that they will need to > define corresponding new AD types to hold the wrapped keys. > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Feb 25 00:58:32 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C6912894E for ; Mon, 25 Feb 2019 00:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-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 A-ZhDDUmD-mM for ; Mon, 25 Feb 2019 00:58:28 -0800 (PST) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 312E8130EE7 for ; Mon, 25 Feb 2019 00:58:28 -0800 (PST) Received: by mail-wm1-x334.google.com with SMTP id t15so7163982wmi.5 for ; Mon, 25 Feb 2019 00:58:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:cc:to; bh=ocXzkYQaOp2dyRBHXX4qConOJdwkXPaicL0JuFifCPA=; b=XfIibzD+SxkM5qwrkS/q6Tzp63xKHP6R2ghe5ZyKCrThrlFgI+IOB00N5ghfzyWJh6 u22jY9XogUBI5Ub2J65d2diYduoHnzsUCv12DDQcgSluPMmyODVPn5+tJdFIaHjB0lJo C6sUe4CsARnYD8yfnA9DX2SyCWJu7bpOzTE9+7KGah2/QKAzJod6lsD+9XJh4/nS4Dc7 dhSRU8GrUnaS25hglqHq0So+Rc6H6ykdcLmaxIV/I9f6up4exi6Bu1fnyc/31jb+YT5a DqF5HyNgeqqEjxIduljJXvSK2QcFSETnuYC+h+pSgAm6BseOCZbm8ubB4E4SjQzmsJFp aaIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=ocXzkYQaOp2dyRBHXX4qConOJdwkXPaicL0JuFifCPA=; b=ECjXiSXyk9USb318plwYDIvKflOFbiJoNFvkjxGbYyt24RzvsF9sAozoakzddI4+eC ythKhnYfq76WE9bIC/WAnUxgpWwl5b0g7yrmWewVopXiOlzINHXRxD1W+WC8oGFh5kic WQjAgajhj3i5P8k9fSuz7zdouRMQE7FY7ULgRNg97MbOUDX4ZLE/gs4IeR28G1jSqsc5 bC5YRaPZ/aXz46sgyeZOo358Q5LTLOLTjyuCLXPL7N8eqPxfxpCJXbg5wPKdsUqWYYxD R+KgzDDDG//v2Ahe4aZZ4h1xdKRXEWm3WF7TakOjq4mOYH6X1nWPTXkVZSb0DWlrkfCO gQmg== X-Gm-Message-State: AHQUAubrUqIgm3VPKrH3eWLpuuRtQBPUZYjEpRI3bCDmFitX1VFmOBJV 5HYzHX9cjHKtDJZvQuYz5CT4nnzDPuHs5A== X-Google-Smtp-Source: AHgI3IbamdWcfZFCaVbQuNBLfy3m2GLsAp1N9Zd0K7ukkWh2LC5G5/wl7d0sbGZugfb1Sh76vbqHdQ== X-Received: by 2002:a1c:9ed7:: with SMTP id h206mr9286299wme.28.1551085105984; Mon, 25 Feb 2019 00:58:25 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:351e:bebd:51d1:9ca3? ([2001:660:330f:a4:351e:bebd:51d1:9ca3]) by smtp.gmail.com with ESMTPSA id w10sm11386571wru.5.2019.02.25.00.58.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Feb 2019 00:58:24 -0800 (PST) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_532D59DF-34F1-4740-9163-FDA7FDC58906" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: <908A5302-C3B3-4F16-AFF3-78B6388416A7@gigix.net> Date: Mon, 25 Feb 2019 09:58:39 +0100 Cc: lisp-chairs@ietf.org To: "lisp@ietf.org list" X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [lisp] [Call for Agenda Items] IETF 104 Preliminary Agenda X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 08:58:31 -0000 --Apple-Mail=_532D59DF-34F1-4740-9163-FDA7FDC58906 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Folks, The preliminary agenda for our meeting in Prague has been published: = https://datatracker.ietf.org/meeting/agenda/ We will meet Friday Morning March 29. While the agenda is still subject to changes it is time to think about = presentation slots. Please send your requests for agenda items (Presenter=E2=80=99s name, = title, slot duration)=20 to lisp-chairs@tools.ietf.org Ciao L. --Apple-Mail=_532D59DF-34F1-4740-9163-FDA7FDC58906 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Folks,

The = preliminary agenda for our meeting in Prague has been published: =  https://datatracker.ietf.org/meeting/agenda/

We will meet Friday = Morning March 29.

While the agenda is still subject to changes it is time to = think about presentation slots.

Please send your requests for agenda = items (Presenter=E2=80=99s name, title, slot duration) 
to lisp-chairs@tools.ietf.org

Ciao

L.

= --Apple-Mail=_532D59DF-34F1-4740-9163-FDA7FDC58906-- From nobody Thu Feb 28 11:25:07 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9414130FC1; Thu, 28 Feb 2019 11:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_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 ZEUu-EtvKVYl; Thu, 28 Feb 2019 11:25:00 -0800 (PST) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::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 8B709130FA5; Thu, 28 Feb 2019 11:24:59 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id l5so18214507lje.1; Thu, 28 Feb 2019 11:24:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CKP36Ho/c1staenO0hJxTOW0bYNas8E6/srxNGyeibc=; b=SL6sLIbsTiilccDJ/VFg25erXy2Wpdht4SA9gD7gHl+W43+kxTbjUUoRqYEgUZwqu9 HRkrUteoscvSpL7p5pujX5aMyMqcwD7AW6Q530UCBGWQbKbF6dMBihlciUFYYsP2PlrP m/2CfWg41wgx+BpBJgL72kZY4/AbSYZ7b0iS3DQb8Q8QTjhXdmPNr8Hswge1FgR5x/L8 NMK6ux7oe9+aujsLGUT0Y+feavJOHNDrqsirpoWAAbPF23vwOGABwxUc4d7VZ62qptfU ZSnepKyvV+exMOcf88Tat2GcBhJAWN0Uw5biWqJxT2pjP5mWvIshFrjnfQA0qkMTifl/ o8Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CKP36Ho/c1staenO0hJxTOW0bYNas8E6/srxNGyeibc=; b=a9PqfH/neVNRcuRgvPX6nOxDoFK+ZBf7KdUVxG63QppuCn1Cz3kH8kziUN+PJfthae fC4rbnOrHh9eNfUzkONAFfFAaOxWEOJ30NIXCudFcA2XYAtuCkMqNllSWrc6+2zISJ56 ifxQV36fgVU947jX9BSV2a8HqxO1glBwTm48VTUkNLWfTcFhT2NxmpdXxbn+fWWHtAFt Q7chgrwHvM5wDeDk+vGYpzvvWYcNg0Mk8phi1e5xhCp7Wr0UDnLN6SQuryCjf1KM2Vd1 2memaYWX1uGQ5py5dg0tj6C5iMciLy7+qvydMDnzkgSVZEUQt7FCFLHoYGb/2FVv6vX3 WMwQ== X-Gm-Message-State: APjAAAWBW8IU9/9UEJkhTZd65gqQtwNKoPES3q5UVjgrP/ZbJqNbtm+l UyxU4Z+gMK5qOaw1OpoNpj/UzIaKvxiL1Z789GFIJg== X-Google-Smtp-Source: APXvYqx3AiYRFoTcymXchKdWzTmx3cZgTIgFPqqBP0up+/REhnUYk8yCq4medK5sq+Ngb8pC+FrJTmvJr0kZ9orUFW4= X-Received: by 2002:a2e:551d:: with SMTP id j29mr303708ljb.178.1551381897471; Thu, 28 Feb 2019 11:24:57 -0800 (PST) MIME-Version: 1.0 References: <3EF5E431-BD4E-4775-B413-B4A4A6C4A887@gigix.net> In-Reply-To: From: Alberto Rodriguez-Natal Date: Thu, 28 Feb 2019 11:24:45 -0800 Message-ID: To: Luigi Iannone Cc: "lisp@ietf.org list" , lisp-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000e8fae30582f93e7b" Archived-At: Subject: Re: [lisp] WG Last Call for LISP-SEC (draft-ietf-lisp-sec-17.txt) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 19:25:05 -0000 --000000000000e8fae30582f93e7b Content-Type: text/plain; charset="UTF-8" Luigi, all, I support handing this to the AD as soon as the few remaining open comments on this document coming from the review of 6833/30bis are closed. Thanks, Alberto On Tue, Feb 19, 2019 at 5:01 AM Luigi Iannone wrote: > Folks, > > this WG Last Call has been out for a while and we did not receive > substantial feedback. > > Note that following the discussion on the main specs (the two bis > documents) LISP-SEC is supposed to be MTI - Mandatory To Implement. > > Please send your support gif you want to see this happening. > > Ciao > > L. > > > On 28 Jan 2019, at 14:29, Luigi Iannone wrote: > > Hi All, > > since work on bis documents is re-starting to move forward it is about > time to move forward other pieces of the LISP ecosystem. > > As such the LISP Security document has been revised a while ago for two > reason: > - Make sure is PS quality > - Make sure it is compliant with latest changes in the bis documents. > > The second point has been re-checked by the authors just last week, and > seems we are ready to move the document forward. > > This email open the usual two weeks Working Group Last Call, to end > February 11th, 2019. > > Please review this WG document and let the WG know if you agree that it is > ready for handing to the AD. > If you have objections, please state your reasons why, and explain what it > would take to address your concerns. > > Thanks > > Luigi & Joel > > > > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > --000000000000e8fae30582f93e7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Luigi, all,

I support handin= g this to the AD as soon as the few remaining open comments on this documen= t coming from the review of 6833/30bis are closed.

Thanks,
Alberto

On Tue, Feb 19, 2019 at 5:01 AM Luigi I= annone <ggx@gigix.net> wrote:
Folks,

this WG Last Call has bee= n out for a while and we did not receive substantial feedback.
Note that following the discussion on the main specs (the two = bis documents) LISP-SEC is supposed to be MTI - Mandatory To Implement.

Please send your support gif you want to see this hap= pening.

Ciao

L.


On 28 Jan 2019, at 14:29, Luig= i Iannone <ggx@gigix.= net> wrote:

Hi All,
=
since work on bis documents is re-starting to move forward i= t is about time to move forward other pieces of the LISP ecosystem.

As such the LISP Security document has been revised a whi= le ago for two reason:
- Make sure is PS quality=C2=A0
= - Make sure it is compliant with latest changes in the bis documents.=C2=A0=

The second point has been re-checked by the autho= rs just last week, and seems we are ready to move the document forward.

This email open the usual two weeks Working Group Las= t Call, to end February 11th, 2019.

Plea= se review this WG document and let the WG know if you agree that it is read= y for handing to the AD.
If you have objections, please sta= te your reasons why, and explain what it would take to address your concern= s.

Thanks

Luigi & Joel



=C2=A0


_____________________________________= __________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
--000000000000e8fae30582f93e7b-- From nobody Thu Feb 28 15:39:58 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA58D1310A2 for ; Thu, 28 Feb 2019 15:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=JZIkGNwD; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=IjFQd3xH 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 MG3hGkTf00uu for ; Thu, 28 Feb 2019 15:39:53 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21AD913109F for ; Thu, 28 Feb 2019 15:39:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5214; q=dns/txt; s=iport; t=1551397193; x=1552606793; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=GOf9Tu1Vsj37zzE4/8y4u88zt2hvW6sZ0QyS9NYjR8g=; b=JZIkGNwD/i/BwYJL1eufl2GgYhPrMmy/FvahzZTYRa+y0zlH4sXB8CVM jir2Y6xUGy8tOPuHpBRKFjH399EfV9q4ex0th3E2QT+THk5AZQvWrwo8/ 3zyHP87Oqisi01ybDsqwsksajEIWin/2QYciqMZ8H6m7LDvCKzwfC0ZgX c=; IronPort-PHdr: =?us-ascii?q?9a23=3AHWzu1RwUDLhTINbXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZuPF0D9L/f2ZgQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BkAADOcHhc/5pdJa1lHgEGBwaBUQk?= =?us-ascii?q?LAYExUANodAQLJ4QIg0cDj1VKgg2JLo5yFIEQA1QLAQEYDQeDekYCF4N9IjQ?= =?us-ascii?q?JDQEDAQEDAQMCbRwBC4VKAQEBAQIBAQEbBhEMAQEMIAwPAgEIEQMBAgECAgg?= =?us-ascii?q?eAgICHwYKARUICAIEEx0Egn8BgVoDDQgBAgygZQKKFHGBL4J4AQEFgTABgRS?= =?us-ascii?q?CRA0LggsDBYELiz0XgUA/gREnH4JMgldHAQEBgS0BEQIBHgcQI4JQMYImig8?= =?us-ascii?q?uggGLHYteMwkCh0CHa4M9GYFzhV+KEIE6il2FVoEuixMCBAIEBQINAQEFgUc?= =?us-ascii?q?4ZXFwFTsqAYJBghwMF4NLhRSFP3IBgSeOfAEB?= X-IronPort-AV: E=Sophos;i="5.58,425,1544486400"; d="scan'208";a="523268271" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Feb 2019 23:39:41 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x1SNdf89021116 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 28 Feb 2019 23:39:41 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 28 Feb 2019 17:39:41 -0600 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 28 Feb 2019 18:39:40 -0500 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 28 Feb 2019 17:39:40 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GOf9Tu1Vsj37zzE4/8y4u88zt2hvW6sZ0QyS9NYjR8g=; b=IjFQd3xHdeqOXUOEc4ivL1R8Uskguxm+fE75A42cs95MXzBWxk2DdBnuRVcGOME29OrstrwVmUoS1OzkI8zPY6+p1LKxjhyNndEbxmE1eqd6i+v/dr0bJXDnN50dsUyneNoxUNKJucvmRJZH5yIsDBdNXN5bnpBvKwVdG8qCUZY= Received: from BN8PR11MB3825.namprd11.prod.outlook.com (20.178.222.29) by BN8PR11MB3732.namprd11.prod.outlook.com (20.178.220.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.16; Thu, 28 Feb 2019 23:39:39 +0000 Received: from BN8PR11MB3825.namprd11.prod.outlook.com ([fe80::a981:a20c:fe35:d5c8]) by BN8PR11MB3825.namprd11.prod.outlook.com ([fe80::a981:a20c:fe35:d5c8%4]) with mapi id 15.20.1643.019; Thu, 28 Feb 2019 23:39:39 +0000 From: "Balaji Pitta Venkatachalapathy (bvenkata)" To: "lisp@ietf.org" Thread-Topic: lisp Digest, Vol 123, Issue 23 Thread-Index: AQHUz6BNiyuqoKA9GEWUygIFXRYek6X1WF8A Date: Thu, 28 Feb 2019 23:39:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bvenkata@cisco.com; x-originating-ip: [2001:420:302:1256:741c:3f88:338:9e81] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e96c22e9-6ee2-42a9-154b-08d69dd60195 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BN8PR11MB3732; x-ms-traffictypediagnostic: BN8PR11MB3732: x-ms-exchange-purlcount: 2 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCTjhQUjExTUIzNzMyOzIzOllYWHpoOEwzNm1wUmdVK2tPU0l3elc4TVhw?= =?utf-8?B?djBIRU1wRWRkejJ0N3BHQzRqSGZ0SDVlZVcrbXM4K092aWNXaEJveGxVWU5h?= =?utf-8?B?SXVHa3pRRGh4WTFoL0RjMzhmSkIrMHAxNzhySVV5SjNrbDRiWGswQXBEbDkw?= =?utf-8?B?dEdGa2dUNGRreTRmQ1NRMzhrV2REcVVKRGZJNk03SDVhOHBjbVI5ZnJnM2dN?= =?utf-8?B?dGttODJJSS9TSkZZdEU4ZHFVSHV1ekNDMEo5dGtZZm1CelBHMTZIdGZISmpF?= =?utf-8?B?SU1RV3BMNEtlYS94c1BvVS9mVFJUR3ZBMTJnUkloaW1PakI0M2U3cjdhb3RF?= =?utf-8?B?QVQ1UEl2MWNXMFdVbW45NE1WMmF4cFAyVExQTkFQeFlydjR4K2VVN3FaN2pN?= =?utf-8?B?eDRwb25pOXJSaHRnc3RnVWk3SWE0bVA4blZOZDFjeFB4cEEvUndLRGJXWTUy?= =?utf-8?B?WExiRmtQblFONlZyMmF3YUV3SVgxWkxJWldTK0lHUHEyZmRybjYzZktQQ3V2?= =?utf-8?B?T1VucU1uODNHTkJYSHFqWWppRGtmK3JqVnIxUTNMVXJsWHpCa1dhakJHbkor?= =?utf-8?B?NEpRYzlYTnoxZk9teFlDWXdwaHZNZjZPSXYreFN0RUlTa3RyVjdPNXZ6Mnho?= =?utf-8?B?aUR5Qi9hNFVPM2V3Znpmb2E1eGJDYm9qc2tpdTMwUmtWNS92Y251c25lY2JI?= =?utf-8?B?cVUvaHVJQkt6WFY5ZHNlWHBELzVuZEpNSE9sb3BiRHlCbk0vKzNwK0hBTkhK?= =?utf-8?B?Sk5sR2RHRHJ1K0RjaWN1azdVYnFLSFovTFE3SkxIQ2lmdlBPUjBRSStWeUpE?= =?utf-8?B?d0E5NUw0NjhXYXNnK25UM2FTSTlmQXQrekNQVEEybXJqeG9uemNjVjIwOWd3?= =?utf-8?B?cFp1Vms0dnc0aE9tMEY3VWoyZGlxamNtODFpOTdnVG1IOFU0ZWtQR3JIb3ZQ?= =?utf-8?B?VjRmTVR2a3dpb08wOUZ4ckdwTnd3UVAvQ2dQNWx2M2gzUlN6bmh4VEgxbld3?= =?utf-8?B?WEtOdVQ5WExHMWU3NzF4eEhZTEU4Z0d5NEcxSEZKb3pHZHpjZ0lhZm1KRk1C?= =?utf-8?B?anNwUWwxVlNROWtoSVgwaFJaOUh0MFVkUytNQUl3NVA4bGFkWVU3UXlVdFdl?= =?utf-8?B?L3puMTY5Q2hGTlFPT3hkcXV2RHNQWmIvMkRCK2hNaE9BWkdZM2tmdXNNaXhm?= =?utf-8?B?Y3cxM0VjZFl5Mk05Z3pZSnA1Sk1ITnVyblVjMEYyQzlIM29nY25OWlE0alN5?= =?utf-8?B?NW1yMC9CaHgzSGdqODFVVE1pZWJoSVZ2QWpjeTNVMk5ld1RjODlqRjJKNVJi?= =?utf-8?B?SWNFVjdOZkJJK0VMWnRzcmZ2T0VuZnRkdkU5ZVdlMFJrQWhRN2xFSFRQSmN6?= =?utf-8?B?V2VVMGlMcklCQlZpb0tKSzd3c0dJSXFxYWhUR3gwSVJiL3ZMUHZ1dy93NFFT?= =?utf-8?B?MUVkc2tkaExUd3hPOWxxQ1FZTUtEVmxqTnRPdlFUK05Fa2ZZTGEzS2FrT1Ux?= =?utf-8?B?S1plcHFjZEZFNXJrNGEvcmhNTVVuSUhLSUoycXlTUEJJTHhSU210NVQwREVK?= =?utf-8?B?bjkva1FhUDNKMG9FVVQ2WWswQnk5S3Z6cjBmajgyODVTRldUTUc4MDRheGI2?= =?utf-8?B?eXpreS9UL05JeGdoUzhpd0FtdmFiVDk2ZUtLYXRxR3lTMFhnUzFrTk1jakhk?= =?utf-8?B?dHhLRnlWemN2NFI5aldXMThwQnpxV0dwZ1B3L3RtUjBneFJ2NklWcWtiM2k3?= =?utf-8?B?RWVLeHdrTnBKUm5FeGkxdi8vM1Job0dOQzc2T2hLSi9Yd2kwaEdYUnozRnRk?= =?utf-8?B?SkpIMkg3d25Dd1hZdGpuUXFJM3NUZWYrU0xwWkd6YVJpTDYrRHpkbU9OMlZt?= =?utf-8?B?WnN6TzZabEdmY01TKzlpKzhhOG51SURDei9RMEVLYlBFSFRRY2huMjBadXE1?= =?utf-8?B?UU5IVjdIamVBPT0=?= x-microsoft-antispam-prvs: x-forefront-prvs: 0962D394D2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(376002)(396003)(346002)(39860400002)(10533003)(53754006)(199004)(189003)(27574002)(18543002)(36756003)(6506007)(53546011)(33656002)(102836004)(478600001)(2906002)(6246003)(2351001)(105586002)(305945005)(76176011)(6512007)(6306002)(446003)(6916009)(86362001)(186003)(966005)(53936002)(316002)(11346002)(14454004)(476003)(486006)(2616005)(46003)(82746002)(68736007)(8936002)(106356001)(1730700003)(81156014)(5660300002)(81166006)(7736002)(97736004)(229853002)(5024004)(25786009)(8676002)(2501003)(99286004)(6436002)(256004)(6486002)(5640700003)(14444005)(71200400001)(71190400001)(83716004)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR11MB3732; H:BN8PR11MB3825.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: rhg1txXsee7/SLvDFQbrbmKOqyDts5eds+IQO9Ck8xnix607Ih36kGUua8g2n7mZ3ilVjt9RHSpiOkTeLLsgEAPGiw4X6CeEJ6RY8WhLo+I1SwD+508n4LiBaZ2qCxSHu/5qcjvYGp9cLLagMG/hUiDAIHOZgpVR3frrVsWNiF7ISiwLsfNo3nG+xLVNGBn2sly+ES4ug3LTYneUtsyeua5xfQJ+HEnBhP6kgvKyBzQjeclHM/+pndySUxBX1bn2sNejQ6C02GM6F+SmZkTFbF2AIa0u5TUgZBrgvHo6JJjoNix8fcVw5j/F+ts4GOYf9RW0Rs2Lmk28OwTEdQjQOwfwM2IDCJs7naModIvUKldLN0ow7SYjK9K/2p3BcntcinNfVmg2s52RawsZVf2K4DXYQCBrFI2lXfNgeUpOn64= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e96c22e9-6ee2-42a9-154b-08d69dd60195 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2019 23:39:39.2281 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3732 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.27, xch-rcd-017.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [lisp] lisp Digest, Vol 123, Issue 23 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 23:39:57 -0000 SSBzdXBwb3J0Lg0KDQpUaGFua3MNCkJhbGFqaQ0KDQrvu79PbiAyLzI4LzE5LCAxMjowMCBQTSwg Imxpc3Agb24gYmVoYWxmIG9mIGxpc3AtcmVxdWVzdEBpZXRmLm9yZyIgPGxpc3AtYm91bmNlc0Bp ZXRmLm9yZyBvbiBiZWhhbGYgb2YgbGlzcC1yZXF1ZXN0QGlldGYub3JnPiB3cm90ZToNCg0KICAg IFNlbmQgbGlzcCBtYWlsaW5nIGxpc3Qgc3VibWlzc2lvbnMgdG8NCiAgICAJbGlzcEBpZXRmLm9y Zw0KICAgIA0KICAgIFRvIHN1YnNjcmliZSBvciB1bnN1YnNjcmliZSB2aWEgdGhlIFdvcmxkIFdp ZGUgV2ViLCB2aXNpdA0KICAgIAlodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2xpc3ANCiAgICBvciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3Ig Ym9keSAnaGVscCcgdG8NCiAgICAJbGlzcC1yZXF1ZXN0QGlldGYub3JnDQogICAgDQogICAgWW91 IGNhbiByZWFjaCB0aGUgcGVyc29uIG1hbmFnaW5nIHRoZSBsaXN0IGF0DQogICAgCWxpc3Atb3du ZXJAaWV0Zi5vcmcNCiAgICANCiAgICBXaGVuIHJlcGx5aW5nLCBwbGVhc2UgZWRpdCB5b3VyIFN1 YmplY3QgbGluZSBzbyBpdCBpcyBtb3JlIHNwZWNpZmljDQogICAgdGhhbiAiUmU6IENvbnRlbnRz IG9mIGxpc3AgZGlnZXN0Li4uIg0KICAgIA0KICAgIA0KICAgIFRvZGF5J3MgVG9waWNzOg0KICAg IA0KICAgICAgIDEuIFJlOiBXRyBMYXN0IENhbGwgZm9yIExJU1AtU0VDIChkcmFmdC1pZXRmLWxp c3Atc2VjLTE3LnR4dCkNCiAgICAgICAgICAoQWxiZXJ0byBSb2RyaWd1ZXotTmF0YWwpDQogICAg DQogICAgDQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIA0KICAgIE1lc3NhZ2U6IDENCiAgICBEYXRl OiBUaHUsIDI4IEZlYiAyMDE5IDExOjI0OjQ1IC0wODAwDQogICAgRnJvbTogQWxiZXJ0byBSb2Ry aWd1ZXotTmF0YWwgPHJvZHJpZ3Vlem5hdGFsQGdtYWlsLmNvbT4NCiAgICBUbzogTHVpZ2kgSWFu bm9uZSA8Z2d4QGdpZ2l4Lm5ldD4NCiAgICBDYzogImxpc3BAaWV0Zi5vcmcgbGlzdCIgPGxpc3BA aWV0Zi5vcmc+LCBsaXNwLWNoYWlyc0BpZXRmLm9yZw0KICAgIFN1YmplY3Q6IFJlOiBbbGlzcF0g V0cgTGFzdCBDYWxsIGZvciBMSVNQLVNFQw0KICAgIAkoZHJhZnQtaWV0Zi1saXNwLXNlYy0xNy50 eHQpDQogICAgTWVzc2FnZS1JRDoNCiAgICAJPENBK1lIY0tHazljUkJoNTZxaTVuR0ZkbXNaSDY3 ck5va21ZV1hDSkdrY3MxTXotY29PQUBtYWlsLmdtYWlsLmNvbT4NCiAgICBDb250ZW50LVR5cGU6 IHRleHQvcGxhaW47IGNoYXJzZXQ9InV0Zi04Ig0KICAgIA0KICAgIEx1aWdpLCBhbGwsDQogICAg DQogICAgSSBzdXBwb3J0IGhhbmRpbmcgdGhpcyB0byB0aGUgQUQgYXMgc29vbiBhcyB0aGUgZmV3 IHJlbWFpbmluZyBvcGVuIGNvbW1lbnRzDQogICAgb24gdGhpcyBkb2N1bWVudCBjb21pbmcgZnJv bSB0aGUgcmV2aWV3IG9mIDY4MzMvMzBiaXMgYXJlIGNsb3NlZC4NCiAgICANCiAgICBUaGFua3Ms DQogICAgQWxiZXJ0bw0KICAgIA0KICAgIE9uIFR1ZSwgRmViIDE5LCAyMDE5IGF0IDU6MDEgQU0g THVpZ2kgSWFubm9uZSA8Z2d4QGdpZ2l4Lm5ldD4gd3JvdGU6DQogICAgDQogICAgPiBGb2xrcywN CiAgICA+DQogICAgPiB0aGlzIFdHIExhc3QgQ2FsbCBoYXMgYmVlbiBvdXQgZm9yIGEgd2hpbGUg YW5kIHdlIGRpZCBub3QgcmVjZWl2ZQ0KICAgID4gc3Vic3RhbnRpYWwgZmVlZGJhY2suDQogICAg Pg0KICAgID4gTm90ZSB0aGF0IGZvbGxvd2luZyB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgbWFpbiBz cGVjcyAodGhlIHR3byBiaXMNCiAgICA+IGRvY3VtZW50cykgTElTUC1TRUMgaXMgc3VwcG9zZWQg dG8gYmUgTVRJIC0gTWFuZGF0b3J5IFRvIEltcGxlbWVudC4NCiAgICA+DQogICAgPiBQbGVhc2Ug c2VuZCB5b3VyIHN1cHBvcnQgZ2lmIHlvdSB3YW50IHRvIHNlZSB0aGlzIGhhcHBlbmluZy4NCiAg ICA+DQogICAgPiBDaWFvDQogICAgPg0KICAgID4gTC4NCiAgICA+DQogICAgPg0KICAgID4gT24g MjggSmFuIDIwMTksIGF0IDE0OjI5LCBMdWlnaSBJYW5ub25lIDxnZ3hAZ2lnaXgubmV0PiB3cm90 ZToNCiAgICA+DQogICAgPiBIaSBBbGwsDQogICAgPg0KICAgID4gc2luY2Ugd29yayBvbiBiaXMg ZG9jdW1lbnRzIGlzIHJlLXN0YXJ0aW5nIHRvIG1vdmUgZm9yd2FyZCBpdCBpcyBhYm91dA0KICAg ID4gdGltZSB0byBtb3ZlIGZvcndhcmQgb3RoZXIgcGllY2VzIG9mIHRoZSBMSVNQIGVjb3N5c3Rl bS4NCiAgICA+DQogICAgPiBBcyBzdWNoIHRoZSBMSVNQIFNlY3VyaXR5IGRvY3VtZW50IGhhcyBi ZWVuIHJldmlzZWQgYSB3aGlsZSBhZ28gZm9yIHR3bw0KICAgID4gcmVhc29uOg0KICAgID4gLSBN YWtlIHN1cmUgaXMgUFMgcXVhbGl0eQ0KICAgID4gLSBNYWtlIHN1cmUgaXQgaXMgY29tcGxpYW50 IHdpdGggbGF0ZXN0IGNoYW5nZXMgaW4gdGhlIGJpcyBkb2N1bWVudHMuDQogICAgPg0KICAgID4g VGhlIHNlY29uZCBwb2ludCBoYXMgYmVlbiByZS1jaGVja2VkIGJ5IHRoZSBhdXRob3JzIGp1c3Qg bGFzdCB3ZWVrLCBhbmQNCiAgICA+IHNlZW1zIHdlIGFyZSByZWFkeSB0byBtb3ZlIHRoZSBkb2N1 bWVudCBmb3J3YXJkLg0KICAgID4NCiAgICA+IFRoaXMgZW1haWwgb3BlbiB0aGUgdXN1YWwgdHdv IHdlZWtzIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsLCB0byBlbmQNCiAgICA+IEZlYnJ1YXJ5IDEx dGgsIDIwMTkuDQogICAgPg0KICAgID4gUGxlYXNlIHJldmlldyB0aGlzIFdHIGRvY3VtZW50IGFu ZCBsZXQgdGhlIFdHIGtub3cgaWYgeW91IGFncmVlIHRoYXQgaXQgaXMNCiAgICA+IHJlYWR5IGZv ciBoYW5kaW5nIHRvIHRoZSBBRC4NCiAgICA+IElmIHlvdSBoYXZlIG9iamVjdGlvbnMsIHBsZWFz ZSBzdGF0ZSB5b3VyIHJlYXNvbnMgd2h5LCBhbmQgZXhwbGFpbiB3aGF0IGl0DQogICAgPiB3b3Vs ZCB0YWtlIHRvIGFkZHJlc3MgeW91ciBjb25jZXJucy4NCiAgICA+DQogICAgPiBUaGFua3MNCiAg ICA+DQogICAgPiBMdWlnaSAmIEpvZWwNCiAgICA+DQogICAgPg0KICAgID4NCiAgICA+DQogICAg Pg0KICAgID4NCiAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQogICAgPiBsaXNwIG1haWxpbmcgbGlzdA0KICAgID4gbGlzcEBpZXRmLm9yZw0KICAg ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9saXNwDQogICAgPg0KICAg IC0tLS0tLS0tLS0tLS0tIG5leHQgcGFydCAtLS0tLS0tLS0tLS0tLQ0KICAgIEFuIEhUTUwgYXR0 YWNobWVudCB3YXMgc2NydWJiZWQuLi4NCiAgICBVUkw6IDxodHRwczovL21haWxhcmNoaXZlLmll dGYub3JnL2FyY2gvYnJvd3NlL2xpc3AvYXR0YWNobWVudHMvMjAxOTAyMjgvYzFhZDY3NjUvYXR0 YWNobWVudC5odG1sPg0KICAgIA0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K ICAgIA0KICAgIFN1YmplY3Q6IERpZ2VzdCBGb290ZXINCiAgICANCiAgICBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIGxpc3AgbWFpbGluZyBsaXN0 DQogICAgbGlzcEBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbGlzcA0KICAgIA0KICAgIA0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KICAgIA0KICAgIEVuZCBvZiBsaXNwIERpZ2VzdCwgVm9sIDEyMywgSXNzdWUgMjMNCiAgICAq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQogICAgDQoNCg== From nobody Thu Feb 28 15:46:10 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADAC21310AD for ; Thu, 28 Feb 2019 15:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llxegz59nSm3 for ; Thu, 28 Feb 2019 15:46:05 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC7FB12D826 for ; Thu, 28 Feb 2019 15:46:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8182; q=dns/txt; s=iport; t=1551397565; x=1552607165; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=WmOrHcCYA245axpkmYYVdyabNjBtbMuBE0XggBO8V1w=; b=MoJ03F8lIqDLBwvaE3ZAk/3Weo7bBhd4+uDiQd7n7cJTNt85xfk1sheU svRVMXnd7TbVGVx8dUlXsLzLoHgiLNnxetLPtwtX6RzbeTcmITf7SC4Q9 MRULJpS8umMElkXMQ+pwUmbzMxMNLl6kFhy0onbFFGE4PafkNVg1YnWFk g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAAA8cnhc/4kNJK1lGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUQYBAQELAYIEaIEDJ4QIiBqLT4FgCCV8lySBew0YC4FUgnUChBQ?= =?us-ascii?q?iNAkNAQMBAQMBAwJtHAyFSwEBAQMBASEPAQU2GwsYAgIfBwICJzATBgIBAYM?= =?us-ascii?q?cAYFyD6tbgS+FRIRqBYELiz0XgUA/gREnDIFhSTWDHgEBgUsJgxeCVwKKCQQ?= =?us-ascii?q?vhyKSDAmSZAYZgXOIf4gqi2+RLIFHOIFWMxoIGxU7gmyCKBcTiEyFYB4DMI1?= =?us-ascii?q?ZgksBAQ?= X-IronPort-AV: E=Sophos;i="5.58,425,1544486400"; d="scan'208";a="241896427" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Feb 2019 23:46:04 +0000 Received: from [10.41.32.164] ([10.41.32.164]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id x1SNk3aw030239 for ; Thu, 28 Feb 2019 23:46:04 GMT To: lisp@ietf.org References: <154954743968.23471.9935733647283605722.idtracker@ietfa.amsl.com> <20190209221334.GA23225@kduck.mit.edu> From: Fabio Maino Message-ID: <4723572b-1883-1bba-852d-b24014d987a3@cisco.com> Date: Thu, 28 Feb 2019 15:46:04 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190209221334.GA23225@kduck.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Outbound-SMTP-Client: 10.41.32.164, [10.41.32.164] X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [lisp] incremental transition to LISP-SEC (was Re: Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6833bis-24: (with DISCUSS and COMMENT)) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 23:46:09 -0000 Hi Benjamin, thanks for bringing this up. I think it makes  sense to have a mechanism for secure downgrade, and it should indeed simplify adoption and transition to LISP-SEC. I discussed what you proposed here with the LISP-SEC authors and with Dino and Alberto. We agree to the principles of what you are proposing. I'll send detailed text, but here is a brief description of what we plan to do. The Map-Register has already the capability to encode ETR's support for  LISP-SEC. We will change the behavior of the MS to signal to the ITR when the ETR is not LISP-SEC capable. This will happen when - the ITR is sending a LISP-SEC Map-Request, AND - the corresponding ETR has not registered as LISP-SEC capable, AND - the ETR is in "non-proxy mode" (that is the mode in which the Map-reply should be originated at the ETR. (MS/ITR behavior won't change if the ETR is in "proxy mode") In this case the MS will send a Negative Map-Reply, protected by LISP-SEC, that includes an ETR-Cant-Sign bit that informs the ITR that the ETR doesn't support LISP-SEC. The integrity of the ECS bit is protected by LISP-SEC, as the rest of the Map-Reply. This will work without changes to the ETR. In this way the ITR has the option to choose to downgrade to non LISP-SEC if it wants to favor reachability. Thanks, Fabio On 2/9/19 2:14 PM, Benjamin Kaduk wrote: > Splitting off a sub-thread for one fairly narrow point that AFAICT needs > further discussion to clarify the path forward: > > On Thu, Feb 07, 2019 at 05:50:39AM -0800, Benjamin Kaduk wrote: >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> > [...] >> 3. LISP-SEC [I-D.ietf-lisp-sec] MUST be implemented. Network >> operartors should carefully weight how the LISP-SEC threat model >> applies to their particular use case or deployment. If they >> decide to ignore a particular recommendation, they should make >> sure the risk associated with the corresponding threats is well >> understood. >> >> I'm concerned enough about the risk of having a "ITR requests lisp-sec but >> ETR didn't use it" case that causes complete breakage, that I want to talk >> about this a bit more. We currently in this document say that lisp-sec is >> mandatory to implement (which presumably covers at least ITRs, ETRs, >> Map-Resolvers, and Map-Servers). LISP-SEC itself says that "and ETR that >> supports LISP-SEC MUST set the S bit in its Map-Register messages". Is it >> possible that an ETR might "implement" but then not "support" LISP-SEC? If >> so, then we should consider the possibility that we need an authenticated >> signal (from the mapping system to the ITR) that downgrading from lisp-sec >> is allowed. There seem to be several possibilities for how one might >> construct such a signal; two that came to mind to me would be (1) to define a >> new ACT value for "repeat without lisp-sec" that could be returned as a >> negative Map-Response directly from the mapping system wherever the mapping >> system is able to discern that the ETR in question does not support >> lisp-sec (I don't actually know if this could happen at Map-Resolver or >> would need to be delayed until the final Map-Server) and (2) to have an >> optional Map-Request field that the ETR is required to copy unchanged to >> the Map-Reply; this could then include a message HMAC'd in the ITR-OTK that >> indicates lisp-sec non-support and binds to the nonce in the request. >> Whether these are workable ideas seems to depend on aspects of the mapping >> system to which I cannot speak. > In terms of some background assumptions I've been making (that of course > could be false, so I'm trying to make them explicit), I am assuming that > many or most current LISP deployments do not utilize LISP-SEC at runtime. > It's less clear to me how many deployments/implementations simply do not > have LISP-SEC capabilities at all, or how easy it is to get > software/firmware updates to the needed devices. Regardless, if there > are existing RFC 6833 deployments that want to migrate to 6833bis when it > is finalized, we should consider what steps would be needed to safely > deploy LISP-SEC without disruption. In particular, it seems a useful goal > to try to get the security benefit of LISP-SEC for those machines/sites > that have LISP-SEC capability without waiting for the entire administrative > domain's deployment to get updated software/firmware, which I assume is at > least a 5-year lead time in many sites. > > Given that at this point my analyses are mostly treating the mapping system > as something of a closed "magic box" that takes Map-Requests as input and > emits them to the appropriate ETRs (or internal proxy function), I'm forced > to conclude that any incremental update to using LISP-SEC will inherently > require the entire mapping system to upgrade first, before any concrete > usage of LISP-SEC should be expected. Hopefully that's less of a burden > than upgrading entire deployments, since the mapping system is a more > contained set of devices and does not need to handle data-plane levels of > traffic. > > Once that's done, though, we still have the question of "which ETRs are > updated to be registering themselves as LISP-SEC-capable?". For any given > ITR/ETR pair, if both are LISP-SEC capable, we want them to be using > LISP-SEC, while still allowing traffic if one or both are not LISP-SEC > capable. If the ITR is not capable, this is easy, as the Map-Request will > never attempt to use LISP-SEC. But if the ITR is capable and the ETR is > not, the ITR is going to either attempt to use LISP-SEC for all > Map-Requests or need some out-of-band knowledge of whether the target ETR > is capabable. Now, the whole point of the mapping system is that the ITR > doesn't know what ETR it's going to talk to when it sends the Map-Request, > so this "out-of-band" setup seems pretty hard to fulfil. My current best > thought (not expected to be perfect) in this scenario is that the ITR that > is LISP-SEC capable (and configured to use it, I suppose) will always try > to use LISP-SEC, but needs an authenticated signal from the mapping system > that the ETR it's being mapped to is not LISP-SEC-capable, and it should > try again without LISP-SEC. This signal needs to be authenticated not just > for security reasons (though an insecure downgrade would render LISP-SEC > useless against an active attacker until the entire deployment disabled > non-LISP-SEC exchanges), but also for performance concerns. As currently > specified, the Map-Server that gets a LISP-SEC Map-Request but is going to > forward it to an ETR that did not register as LISP-SEC capable is going to > repackage the Map-Request into a non-LISP-SEC Map-Request to send to the > ETR in question. That ETR will produce a normal Map-Reply, that the ITR > will proceed to drop without processing, since it does not use LISP-SEC. > IIUC, that leaves the ITR in "wait to timeout" territory, which is a pretty > lousy situation to be in. > > I know there are only a couple values left for ACT values, but it seems > that this may be a big enough issue to justify allocating one for "retry > with downgrade", so that the final Map-Server can send a negative Map-Reply > that does use LISP-SEC, and the ITR can have this authenticated signal that > the destination ETR is not LISP-SEC capable at the moment. There are of > course other ways to generate an authenticated downgrade signal, but the > only other ones I've been able to come up with seem less architecturally > pleasing (and may not in fact work when the destination ETR is running > original RFC 6833 code). > > I'm interested in hearing what other people think about this scenario and > proposed remediation. > > -Benjamin > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp