From nobody Thu Sep 1 00:31:37 2016 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 3F55112D786 for ; Thu, 1 Sep 2016 00:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 plZPD7xLEgJR for ; Thu, 1 Sep 2016 00:31:32 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F2D512D181 for ; Thu, 1 Sep 2016 00:31:32 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id w2so62092289wmd.0 for ; Thu, 01 Sep 2016 00:31:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=VcCHdpK6N5ChSgK6pTOG6pCj/c82yEwur8JrLuv3kYQ=; b=TIlxPbdXCm0hDS0kP2RH1weSBatXb+khINTAjDkC6Xaik2DnzbZIiLnDwmBZ3b2vMu SifW9kr9FR+LtafNJV4ilTUbDxKkFKI0vv2UDxkWiZ609Ojcr6eGUSDbXpzMf3Bc7FHH /AlY1nocbpNewnTWKYkmkyBYNFCgKwfly2bX2aaooGnaec3gikc2sl37ekZ+DHw7XTyq cnVHHex5icuk8tO7nEc0kdLMLxT0BorOj9Q9jsdvkxCUYegpQpuakrSqcDo6jBQKFO/K WSWIqQGPQOQ3OuFtt6QUKmoCurAYJy0zmioHBOuKMh+1de3HqBJzJXGhJiX0yUs1stja Vsdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=VcCHdpK6N5ChSgK6pTOG6pCj/c82yEwur8JrLuv3kYQ=; b=egOi3f1Y2WcQQkglP22Tj9YW1Y9wQ516iv4tH9NERTbhKzS812P4dnObMA8So+xFA3 YS86vpX4vy1UgIpt/+ynbl9Ng90h/2lSJbWVQVzNKzyueK3Q5zgTv8hoT8g37disXGZu iIikuwQHqNEbOnX9HZwpOUYG5ULIjUukyON+xrN2RzFbxg2cskxNq7WanYlnZq78UyDs JO1s3n9kxYd+K+2g0eWapQL3Df+yPA1XwZht9MklrbfGgtq0DTT8ngT7iZFVVEJZQ4Cl Zj2dIpkYSGhd5viHm5BYz+kFKUEvCxlF2SOFrKNtl4UKTuoOXfBixC58uLgLH3Nuad+B gTuQ== X-Gm-Message-State: AE9vXwOzqQSCpZoYBN7SPaxTuxsshRES2esWNW3RXHjsZXj9EmCygN62TxojtWazASo4gw== X-Received: by 10.195.13.18 with SMTP id eu18mr12767091wjd.121.1472715090573; Thu, 01 Sep 2016 00:31:30 -0700 (PDT) Received: from [192.168.1.107] ([90.74.25.36]) by smtp.gmail.com with ESMTPSA id cw7sm3709650wjb.38.2016.09.01.00.31.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 01 Sep 2016 00:31:29 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_941E65C4-9A5A-4EF6-914B-E1E798F81160" From: Florin Coras In-Reply-To: <94c95e23-b2d8-ced7-64e4-7f00bb13c834@cisco.com> Date: Thu, 1 Sep 2016 09:31:28 +0200 Message-Id: <9A9492B9-8BD3-4A9D-B00B-C2B8EBD62D22@gmail.com> References: <983495DD-BDFE-474C-90D1-F32DDE09D286@gigix.net> <94c95e23-b2d8-ced7-64e4-7f00bb13c834@cisco.com> To: Fabio Maino X-Mailer: Apple Mail (2.3124) Archived-At: Cc: lisp@ietf.org Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-type-iana-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 01 Sep 2016 07:31:35 -0000 --Apple-Mail=_941E65C4-9A5A-4EF6-914B-E1E798F81160 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 +1 Florin > On Sep 1, 2016, at 2:45 AM, Fabio Maino wrote: >=20 > I support moving this document forward.=20 >=20 > Fabio >=20 > On 8/17/16 1:58 PM, Luigi Iannone wrote: >> Hi All, >>=20 >> The authors of the LISP Experimental Message & IANA Registry for LISP = Packet=20 >> Type Allocations = [https://tools.ietf.org/html/draft-ietf-lisp-type-iana-00 = ] asked for WG = Last Call.=20 >>=20 >> This email starts the usual two weeks WG Last Call, to end August = 31st, 2016. >>=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 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp = >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail=_941E65C4-9A5A-4EF6-914B-E1E798F81160 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=windows-1252 +1

Florin

On Sep 1, 2016, at 2:45 AM, Fabio Maino <fmaino@cisco.com> wrote:

I support moving this document forward.

Fabio

On 8/17/16 1:58 PM, Luigi Iannone wrote:
Hi All,

The authors of the LISP Experimental Message & IANA Registry for LISP Packet 
Type Allocations [https://tools.ietf.org/html/draft-ietf-lisp-type-iana-00] asked for WG Last Call. 

This email starts the usual two weeks WG Last Call, to end August 31st, 2016.

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


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

--Apple-Mail=_941E65C4-9A5A-4EF6-914B-E1E798F81160-- From nobody Thu Sep 1 12:49:05 2016 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 BD74912D6B2 for ; Thu, 1 Sep 2016 12:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 JSEpsmyyY60E for ; Thu, 1 Sep 2016 12:49:02 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E19E612D5FF for ; Thu, 1 Sep 2016 12:49:01 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id c15so132367618oig.0 for ; Thu, 01 Sep 2016 12:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=MPLqQGQGTS+waxKrcVGW/8cPhUsJPo0tORKCY2jqM3A=; b=ZSlV+SFFFeKks6K2z3WLNQLaOP3IbpR7LXgbgwZeB4wnCsfvPmmsQOq8d02ikbOKjV eyjqn4+ZHtrHJ/vg9x65EG3H8dSTQjzJX54MpbTRIVSFEBL7iKOm+hmNH8pyn8W1KSqw b3j30v1Z+ruB7wm3fIqAt6AtEeoakmcXV5OOFhhL7CMOByp/VWRtskCt+SC1RphvOp/V 2SEdNLUhG0Bd4JWg6Px3H/euKyvIX3rriMbIX3lVIj9x6kewJfn8306rpHzZTOsqgrNy t+m1gf/orVJVtJ57ZDQuxJizZI9DU4Nce5MZXkv3WvGHnqnWrcfywQrcDVhp8EiQNMnl fJtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=MPLqQGQGTS+waxKrcVGW/8cPhUsJPo0tORKCY2jqM3A=; b=WorhK0PRegiiJgTMRVjiXPLPtEWOjfkl5zDWhsLMFDhrQZCIVJhaxep7QaIdVQs74Z qahWWLkpLAo7vCC5hYkYaS9OA7FVzW4JbM5hiZe3qUaCZYqkkt8oKloVh+7edbwtb81C hmYWzhmeK82pXkCBj23SdiklrzMr5wRqur1bJuzI+wNhHfNXw2B4d848KSMSXgyW7jbG TAumbF1n7+76pN5lR7IxASEiI2Tnh/bHXQZTbpbR/ch5rdwqwY/2hEB94NO5sxIa/pLO zzM7TappF4c4p7LLz2v/Ym76KBsMdHZb+KE+/6CcDBO9i4SJWlIpCp9Jfin9X5n6ACLy B8Zg== X-Gm-Message-State: AE9vXwOm13O5Oz5JICUl/bMWD6W0XtDYf4Hv8D4HvwJ5n+j1ZQu9SQ0KJnVTzUTvTgj4+o/Bx7y2z9CutfBMTQ== X-Received: by 10.202.53.132 with SMTP id c126mr15291371oia.3.1472759341149; Thu, 01 Sep 2016 12:49:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.76.214 with HTTP; Thu, 1 Sep 2016 12:49:00 -0700 (PDT) In-Reply-To: <9A9492B9-8BD3-4A9D-B00B-C2B8EBD62D22@gmail.com> References: <983495DD-BDFE-474C-90D1-F32DDE09D286@gigix.net> <94c95e23-b2d8-ced7-64e4-7f00bb13c834@cisco.com> <9A9492B9-8BD3-4A9D-B00B-C2B8EBD62D22@gmail.com> From: Yue LI Date: Thu, 1 Sep 2016 21:49:00 +0200 Message-ID: To: LISP mailing list list Content-Type: multipart/alternative; boundary=001a113cf3e65e773a053b778194 Archived-At: Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-type-iana-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 01 Sep 2016 19:49:04 -0000 --001a113cf3e65e773a053b778194 Content-Type: text/plain; charset=UTF-8 Dear all, I also support. Yue On Thu, Sep 1, 2016 at 9:31 AM, Florin Coras wrote: > +1 > > Florin > > On Sep 1, 2016, at 2:45 AM, Fabio Maino wrote: > > I support moving this document forward. > > Fabio > > On 8/17/16 1:58 PM, Luigi Iannone wrote: > > Hi All, > > The authors of the LISP Experimental Message & IANA Registry for LISP > Packet > Type Allocations [https://tools.ietf.org/html/draft-ietf-lisp-type-iana-00] > asked for WG Last Call. > > This email starts the usual two weeks WG Last Call, to end August 31st, > 2016. > > 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 listlisp@ietf.orghttps://www.ietf.org/mailman/listinfo/lisp > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > > -- Yue LI PhD student, Telecom ParisTech Tel: +33 (0)661091840 E-mail: yueli.cnfr@gmail.com --001a113cf3e65e773a053b778194 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

I also support.
Yue

On Thu, Sep 1, 2016 at 9:31 AM, Florin Coras <fcoras.lists@gmail.= com> wrote:
+1
=
Florin

On Sep 1, 2016, at 2:45 AM, Fabio Maino &= lt;fmaino@cisco.com> wrote:

=20 =20 =20
I support moving this document forward.

Fabio

On 8/17/16 1:58 PM, Luigi Iannone wrote:
=20 Hi All,

The authors of the LISP Experimental Message & IANA Registry for LISP Packet=C2=A0

This email starts the usual two weeks WG Last Call, to end August 31st, 2016.

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
ht=
tps://www.ietf.org/mailman/listinfo/lisp


_______________________________________________
lisp mailing listlisp@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/lisp" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/lisp


____________________________________= ___________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp




--
= Yue LI
PhD student, Telecom ParisTech
Tel: +33 (0)661091840
--001a113cf3e65e773a053b778194-- From nobody Thu Sep 1 15:35:44 2016 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 4EB8912D96A; Thu, 1 Sep 2016 15:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 HFM_HNxOe1Yn; Thu, 1 Sep 2016 15:35:40 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD17A12D7AE; Thu, 1 Sep 2016 15:35:40 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id p186so102688813oia.2; Thu, 01 Sep 2016 15:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RJh+NAUXiwTaXMk6/qG2jrGd9+IBCZhjPYRG+WZSyJI=; b=ReWnDJdg2/N3azBz4wN40es41YRIxfrpDlVTYMvyPHNaatmiSIOkYR/S0SCWtvhAOI +nekzBwX5t80H73jGYaBu2SZpIYUaTCYkrlnidfFz1SXUXpahiXdapi8xRfi3r/Dla1A CY5a/gZdzLAwbBGpCTk119i+SwrFRtFxYyiCT/q7SmZjoEiZZRDt8p+AS/9R0GWZjYm/ XilzzdmFdYO/YNlOpLJ2ASsgiQnZKHSVuaNIpd4JekyVD21Rs+A/AW2w2DQzhcAiUCBw lugMhH5bwV0StGgaIrQicapzVIBax5Iz65P2jf9ixfvLg8eadlrySiqw3mNBdmxX3L79 cCLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RJh+NAUXiwTaXMk6/qG2jrGd9+IBCZhjPYRG+WZSyJI=; b=jxatU6qq5KDaMZPaZzFFtGMKLf4j/soA7m4QEQfPWYddstElJpL5B6Dat/5VpUT+pu UXXv+Yg+7e8aoxjsc2bZPC4F5lwQcDCfy0+iG271lCveWnoxdEZ3IFutB+KNftaljizH 3Rn9KCORvoAQy0nQmVE/5BAO+B9OHpevhpWWEb/xqnWjxhb7h4GiR+LI9d5M8GDZK0fl VxfBlZ0GPv6egc/sjXGFSvGDI5nvgVA3Wpcqwq9JsGE2Coe+cessbqzvjFA/2jzfRFYb 2ZSyc7R0ieX6yFerlNhsY+MbR/DoSadTL/SLecZzNAF2/cH+J/JWyyyzFrqMqHFnBKNK XI5Q== X-Gm-Message-State: AE9vXwOFgZ2llJzJ+zM2hoL2xreRSzD6giMQZnxZkANqPKhVML5yaZ/kTE7f3DTF4JgmMWRz7LD6uZaSjjyfzg== X-Received: by 10.202.237.4 with SMTP id l4mr11509387oih.21.1472769339874; Thu, 01 Sep 2016 15:35:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.199.102 with HTTP; Thu, 1 Sep 2016 15:35:19 -0700 (PDT) In-Reply-To: References: <983495DD-BDFE-474C-90D1-F32DDE09D286@gigix.net> From: Alberto Rodriguez-Natal Date: Thu, 1 Sep 2016 15:35:19 -0700 Message-ID: To: Luigi Iannone Content-Type: multipart/alternative; boundary=001a113d22dc56e5a5053b79d5cf Archived-At: Cc: lisp-chairs@ietf.org, LISP mailing list list Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-type-iana-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 01 Sep 2016 22:35:42 -0000 --001a113d22dc56e5a5053b79d5cf Content-Type: text/plain; charset=UTF-8 +1 Alberto On Tue, Aug 30, 2016 at 3:09 AM, Luigi Iannone wrote: > Folks, > > This call will close soon, please express your opinion on whether this > document is ready or not for the IESG. > > Silence is not consensus. > > ciao > > L. > > > On 17 Aug 2016, at 22:58, Luigi Iannone wrote: > > Hi All, > > The authors of the LISP Experimental Message & IANA Registry for LISP > Packet > Type Allocations [https://tools.ietf.org/html/draft-ietf-lisp-type-iana-00] > asked for WG Last Call. > > This email starts the usual two weeks WG Last Call, to end August 31st, > 2016. > > 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 > > --001a113d22dc56e5a5053b79d5cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

Alberto

On Tue, Aug 30, 2016 at 3:09 AM, Luig= i Iannone <ggx@gigix.net> wrote:
Folks,

This c= all will close soon, please express your opinion on whether this document i= s ready or not for the IESG.

Silence is not consen= sus.

ciao

L.


On 17 Aug 20= 16, at 22:58, Luigi Iannone <ggx@gigix.net> wrote:

Hi All,

The authors of the LISP Experimental Message & IANA Registry f= or LISP Packet=C2=A0
Type Allocations [https://tools.= ietf.org/html/draft-ietf-lisp-type-iana-00] asked for WG Last Call= .=C2=A0

This email starts the usual two weeks WG L= ast Call, to end August 31st, 2016.

Please re= view 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 yo= ur 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


--001a113d22dc56e5a5053b79d5cf-- From nobody Fri Sep 2 00:48:48 2016 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 30AEF12D162 for ; Fri, 2 Sep 2016 00:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5f1HFHcKmf-e for ; Fri, 2 Sep 2016 00:48:41 -0700 (PDT) Received: from osiris.lip6.fr (osiris.lip6.fr [132.227.60.30]) (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 3553A12D0DB for ; Fri, 2 Sep 2016 00:48:40 -0700 (PDT) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by osiris.lip6.fr (8.15.2/lip6) with ESMTP id u827mbqB027104 for ; Fri, 2 Sep 2016 09:48:37 +0200 (CEST) X-pt: osiris.lip6.fr Received: from [192.168.1.40] (bre75-4-78-194-65-24.fbxo.proxad.net [78.194.65.24]) (authenticated bits=0) by tibre.lip6.fr (8.15.1/8.14.7) with ESMTPSA id u827mb8b014395 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 2 Sep 2016 09:48:37 +0200 (MEST) Content-Type: multipart/signed; boundary="Apple-Mail=_43E33332-4F83-4464-B000-884A2E95C235"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Pgp-Agent: GPGMail From: Stefano Secci In-Reply-To: Date: Fri, 2 Sep 2016 09:48:37 +0200 Message-Id: References: To: lisp@ietf.org X-Mailer: Apple Mail (2.1993) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (osiris.lip6.fr [132.227.60.30]); Fri, 02 Sep 2016 09:48:37 +0200 (CEST) X-Scanned-By: MIMEDefang 2.78 on 132.227.60.30 Archived-At: Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-type-iana-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 02 Sep 2016 07:48:46 -0000 --Apple-Mail=_43E33332-4F83-4464-B000-884A2E95C235 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii +1 Cheers, Stefano > On 8/17/16 1:58 PM, Luigi Iannone wrote: >> Hi All, >> >> The authors of the LISP Experimental Message & IANA Registry for LISP >> Packet >> Type Allocations >> [https://tools.ietf.org/html/draft-ietf-lisp-type-iana-00] asked for >> WG Last Call. >> >> This email starts the usual two weeks WG Last Call, to end August >> 31st, 2016. >> >> 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 -- Stefano Secci Associate Professor Univ. Pierre et Marie Curie LIP6 - Office 25-26/518 - BC 169 4 place Jussieu, 75005 Paris, France Tel: +33 (0) 1 4427 3678 http://www-phare.lip6.fr/~secci --Apple-Mail=_43E33332-4F83-4464-B000-884A2E95C235 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJXyS7VAAoJECh52zwQv802vf8P/02Utss3wCpX0nUxEiTg/Nfp 7gQwlUDqfUfGcXnOBHGfXIr1KvQnlhFTT9Nt27X9CVxaFAxVdsz98pnH9cgVH1zK xdGLvrcnA8eSeqOjNe1031RBP8SOGLwKAREbEl0eRYw4sXHYi3If0QF5HRn0WVGS Ggk1J3nlc1RL3RXio0UhtI6Xk/m7Pfmaa60c0K0fjTKhGnzeK9RQXI9puvGwxmyF EGj5vJ5vZu06q+YAA6HKnYg/sdDRur6CSLV5GbSYfeffHeSmgxmELOOB148auy01 ACgJEKwbJdBAHXJZ9nhT3g0hURdSHmaPh1pcM65vuhBh7+AErqiGtwmkKR2w67+r Z5pay9PwtZ5LKM6RywvenBvXoDc6y2/s7Mpp3DSBWuGgo4mjr7Ru2qie4DdiH50i A4txxhtMSitvkmD+/rJgywJoAL/EvJyJHtrcSni9KkwxruG4ZT2L+LqAakQjwhZ8 WPmDjbGaMCLKBKwdsX7cYq/szq2532QxEHrIb3AXB2UdDy+fDzPc3ELTjS2ssjQL 6qMob5suUkd4mTIqy1ZZYkOaPMyMc7UewzoCt7R/0rn1b42aoBEp9aJuzORF/OWK iM1fDq3RTJ7Ngjrf3MEZWEVRD6CZOhtZwzYdQ7IqSeMbsFpVNi1ILmXRX/Gi83tW 64xZLO6wSn4o1flBU1Te =fkPc -----END PGP SIGNATURE----- --Apple-Mail=_43E33332-4F83-4464-B000-884A2E95C235-- From nobody Sat Sep 3 07:10:00 2016 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 828EA12D142 for ; Sat, 3 Sep 2016 07:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Xx379f09Xlcy for ; Sat, 3 Sep 2016 07:09:57 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09DFB12B028 for ; Sat, 3 Sep 2016 07:09:57 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id v143so16770677wmv.0 for ; Sat, 03 Sep 2016 07:09:56 -0700 (PDT) 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:message-id:references :to; bh=12EJx7MhJAzRhODMoWoU1z0obYhKLR8BdsFaqG3cnyM=; b=lVokhh96ejWSZ/lTRe5fapeOxZlf0/OaNEY8Tb53sx6JM+JKm60IR1THxGxk/0i8Dd KFB5lhDUaNnp0zb+MgQ7g6Ifnun+MLhk1TRTgYu96Qd8YQc4hskN7LUwOYZBGkUxFE02 NCNCy/q7bzP0iqpS7T6/k9Uu6mpJEyjSZbDVD2rPKUfAT9entIAamMjfj+bz5kQMe7aV 7Grl/TFCFJoE2VmhjcuKSeiDFvagKi86DoDUTuCr4gSgkLFzp7fqV4sAu/dl2HhAQ1NO wMX+3PA4d4EFlryKCbdVOF8yswicH6gjplPixwWAGG2F3KUSXj3bN83SNRmBkB1l8H8+ TFHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=12EJx7MhJAzRhODMoWoU1z0obYhKLR8BdsFaqG3cnyM=; b=jbv3oWLJne35PJaqzCunC6amU/ooUKkdrsviPymVE68mYNhcBE8WJAmFhyT0Ur8SE1 oonED7yHwuVoJXmwAe5sSdUtYf+A32Wf8HAB/VOTTpMeKB6ha2CrmTyIbubC/XeZVzci YPDGnR15HqqrcPQGLzhZmK0BMVWP3+Mt2v6bG2OzK6ylknNFESpc4gDW3Mo/iaVVdoX2 aVGCld62cR1TUhEvPT+E87Ib2s77E02N578cKpwoPYtGvUws9WPAnGfLOnJaarAa40WL QjeLxZxETDpwEDIB2bbeC56qkCZ0Gny21uRtG8WJNnTxcSwslJz1kolUQXhbaK+er6+G +IKA== X-Gm-Message-State: AE9vXwOcnQuOsvArpYTY4H73u4p0d0Avt0JO83WDg0ww94Ijo3sMR5xMf3uYf3ZiB4NHKg== X-Received: by 10.28.13.143 with SMTP id 137mr8101388wmn.46.1472911795077; Sat, 03 Sep 2016 07:09:55 -0700 (PDT) Received: from ?IPv6:2a01:e35:1381:3430:4d9:b556:6d1e:856e? ([2a01:e35:1381:3430:4d9:b556:6d1e:856e]) by smtp.gmail.com with ESMTPSA id p83sm8814181wma.18.2016.09.03.07.09.53 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 03 Sep 2016 07:09:54 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_AD5F5BDD-3C93-4CA1-A633-5ADCED189038" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Luigi Iannone In-Reply-To: <983495DD-BDFE-474C-90D1-F32DDE09D286@gigix.net> Date: Sat, 3 Sep 2016 16:09:53 +0200 Message-Id: <7DC808EF-B930-4BCF-8CCA-692A7D93CD8F@gigix.net> References: <983495DD-BDFE-474C-90D1-F32DDE09D286@gigix.net> To: LISP mailing list list X-Mailer: Apple Mail (2.3124) Archived-At: Cc: lisp-chairs@ietf.org Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-type-iana-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 03 Sep 2016 14:09:59 -0000 --Apple-Mail=_AD5F5BDD-3C93-4CA1-A633-5ADCED189038 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, the WG LC for draft-ietf-lisp-iana-00 is now closed. Several email were in favour of moving this document forward and no = objections were raised. It seems that there is consensus to request publication of this = document. The next step is having a shepherd. Any volunteer for this task? Thanks Luigi & Joel > On 17 Aug 2016, at 22:58, Luigi Iannone wrote: >=20 > Hi All, >=20 > The authors of the LISP Experimental Message & IANA Registry for LISP = Packet=20 > Type Allocations = [https://tools.ietf.org/html/draft-ietf-lisp-type-iana-00 = ] asked for WG = Last Call.=20 >=20 > This email starts the usual two weeks WG Last Call, to end August = 31st, 2016. >=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 --Apple-Mail=_AD5F5BDD-3C93-4CA1-A633-5ADCED189038 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi All,

the= WG LC for draft-ietf-lisp-iana-00 is now closed.
Several email were in favour of moving = this document forward and no objections were raised.
It seems that there is consensus to request publication of = this document.

The next step is having a shepherd. Any volunteer for this = task?

Thanks

Luigi & Joel


On 17 = Aug 2016, at 22:58, Luigi Iannone <ggx@gigix.net> wrote:

Hi All,

The authors of the LISP Experimental Message & IANA = Registry for LISP Packet 
Type Allocations [https://tools.ietf.org/html/draft-ietf-lisp-type-iana-00] = asked for WG Last Call. 

This email starts the usual two weeks = WG Last Call, to end August 31st, 2016.

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=_AD5F5BDD-3C93-4CA1-A633-5ADCED189038-- From nobody Mon Sep 5 00:10:31 2016 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 4B07F12B0D1 for ; Mon, 5 Sep 2016 00:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.829 X-Spam-Level: X-Spam-Status: No, score=-3.829 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHBvTsfc0bGO for ; Mon, 5 Sep 2016 00:10:27 -0700 (PDT) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AA73128E18 for ; Mon, 5 Sep 2016 00:10:26 -0700 (PDT) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) (authenticated bits=0) by huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id u857ALJl013927; Mon, 5 Sep 2016 09:10:21 +0200 From: "Jose Saldana" To: Date: Mon, 5 Sep 2016 09:10:25 +0200 Message-ID: <005b01d20744$935a87c0$ba0f9740$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005C_01D20755.56E4DE60" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIr2ICXVE2JVEbYqIUOhZq/XStrbw== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Archived-At: Cc: =?iso-8859-1?Q?'Jos=E9_Ruiz_Mas'?= Subject: [lisp] Next steps with the LISP multiplexing draft X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 05 Sep 2016 07:10:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_005C_01D20755.56E4DE60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 Regarding the multiplexing draft (https://datatracker.ietf.org/doc/draft-saldana-lisp-compress-mux/), = these are the next steps we would consider: =20 1) Signaling: How to signal that some traffic flows will be multiplexed. = We would use LCAF, as suggested by Dino in July: =20 > You could also use the =93Encapsulation Format=94 LCAF type which = tells the ITR, on a > lookup what the ETR is willing to accept. We COULD treat this new capability as a > different encapsulation type. >=20 > Dino =20 Our plan is to include this in the next version of the draft, and in the implementation. =20 =20 2) How to distinguish between a multiplexed and a non-multiplexed packet (once the negotiation is finished). =20 In the ETR we must be able to distinguish between a multiplexed and a non-multiplexed packet. There would be two options for this: =20 a) the use of a port number different from 4341 in the UDP header = preceding the LISP header. b) something in the LISP header that flags the fact. =20 We are currently using a) in the draft, and also in the implementation (https://github.com/Simplemux/lispmob-with-simplemux), but perhaps b) = could be considered instead. =20 =20 Any thoughts? =20 Jose PS: We have also received some feedback about an adaptive encapsulation scheme that maximizes the number IP packets encapsulated into a single = one (see http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=3D4151444). =20 ------=_NextPart_000_005C_01D20755.56E4DE60 Content-Type: text/html; boundary="----=_NextPart_000_0158_01D20515.DD785A70"; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Regarding the multiplexing draft (https://datatracker.ietf.org/doc/draft-saldana-lisp-compress-mux/),= these are the next steps we would consider:

 

1) Signaling: How to signal that some traffic flows will be = multiplexed. We would use LCAF, as suggested by Dino in = July:

 

> You could also use = the “Encapsulation Format” LCAF type which tells the ITR, on = a

> lookup what the ETR is willing to = accept. We COULD treat this new capability as a

> different encapsulation = type.

>

> Dino

 

Our plan is to include this in the next version of the draft, and = in the implementation.

 

 

2) How to distinguish between a multiplexed and a non-multiplexed = packet (once the negotiation is finished).

 

In the ETR we must be able to distinguish between a multiplexed = and a non-multiplexed packet. There would be two options for = this:

 

a) the use of a port number different from 4341 in the UDP header = preceding the LISP header.

b) something in the LISP header that flags the = fact.

 

We are currently using a) in the draft, and also in the = implementation (https://gith= ub.com/Simplemux/lispmob-with-simplemux), but perhaps b) could be = considered instead.

 

 

Any thoughts?

 

Jose

PS: We have also received some feedback about an adaptive = encapsulation scheme that maximizes the number IP packets encapsulated = into a single one (see <= span lang=3DEN-US = style=3D'font-family:"Arial",sans-serif;mso-fareast-font-family:"Times = New = Roman";mso-ansi-language:EN-US;mso-fareast-language:ES;mso-no-proof:yes'>= http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=3D4151444= ).

 

------=_NextPart_000_005C_01D20755.56E4DE60-- From nobody Mon Sep 5 10:07:49 2016 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 6568012B2B1; Mon, 5 Sep 2016 10:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 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_LOW=-0.7, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] 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 f-L68f7KQ9IE; Mon, 5 Sep 2016 10:07:36 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EC1C12B2FE; Mon, 5 Sep 2016 10:07:30 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id g202so42964414pfb.0; Mon, 05 Sep 2016 10:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=R1LS+qBKS8JnkkzOPyftwOkpS6zUnoaIg88pscC9OFU=; b=zTr3q+Y67OIBKuOU3V6lCa1cwcCbd90JamduavUeYH5io7ZX2QDThx3itTzbXXzDgQ 4gET94J0oZ3v72iGurn8L4IGVn/pgLhT3W+RtYTmgK69f4RZPVNf5P+kTII6ao4ugd6t SUtD5LB+HbXZ4uyfwlGhNconkqMbAqX8RtB2tNdwK2sueadUwKPNBcmhnCFBg94KN6Gg e/7VqOKJNXG22hF0iUloPN1uarTeMnHoS41UoDBA7447hM16MPOOFTClbcJhMlu4bAvv keglRKIuCwOi5Z7M+aONPxcBQz7V5mU+uw2KP1BtBHsRQlexdWr2CNEz39U3iymvXnCT Jn9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=R1LS+qBKS8JnkkzOPyftwOkpS6zUnoaIg88pscC9OFU=; b=OhQl3lInDGqlQeR2I46I14MOdApdoi8bbZ8hHRfM2cRWzJB8n2IIcubSwXANaJdmEm jNuVTfHzYVbGhyG5GdB8yFNT/9zWlFjf0nGdFr8AJma1UMZiWn9an+8tY+eI/h+p6WAq XxZXnXXhH1bGpLFtKLzNOGF2zjNN0PTw0NDse0cESZ0c9XtYNuoscqlkesYR4QD4W4Hp 8MCGYvNeo/HNGwleF9zdTzDy00se233CIK5Z0gLTN21pkgOjautMLUK6aG1Dv9WU+FAu gi0ubnPmJMVj1nEYT8rgWw8Ya42KQWc8he/SXwyg2MQ8sHmn7T18b1+LNHuxJu8xHLPa U1PQ== X-Gm-Message-State: AE9vXwOT8Fc69z32ivav6+Q+/i81S++ZKCRO0YXw/9ECsbMaMZLRn1NEl3stpfFE0uaJ7g== X-Received: by 10.98.59.145 with SMTP id w17mr14772507pfj.93.1473095249720; Mon, 05 Sep 2016 10:07:29 -0700 (PDT) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id z187sm34818240pfz.39.2016.09.05.10.07.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 05 Sep 2016 10:07:27 -0700 (PDT) Content-Type: multipart/mixed; boundary="Apple-Mail=_F5B063EC-7A1D-485E-8968-9CD81E984DD2" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: Date: Mon, 5 Sep 2016 10:07:25 -0700 Message-Id: References: <9a0ab6afeff3fc8b86cc320a757ccbf8@tcb.net> To: Luigi Iannone , Danny McPherson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: zhang.xian@huawei.com, LISP mailing list list , Jonathan.Hardwick@metaswitch.com, draft-ietf-lisp-crypto.authors@ietf.org, Jon Hudson Subject: Re: [lisp] RTG-DIR REVIEW: draft-ietf-lisp-crypto-06.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 05 Sep 2016 17:07:46 -0000 --Apple-Mail=_F5B063EC-7A1D-485E-8968-9CD81E984DD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 See responses inline. A new draft is attached (but not submitted since I = had some open questions). >> Document: draft-ietf-lisp-crypto-06.txt >>=20 >> Reviewer: Danny McPherson >>=20 >> Review Date: August 24, 2016 >>=20 >> Intended Status: Experimental Thanks for the review Danny. >> Summary: >>=20 >> I have some minor concerns about this document that should be = considered before publication. >>=20 >> Comments: >>=20 >> I believe the draft is technically sound.=20 >>=20 >> Major Issues: >>=20 >> I have no =E2=80=9CMajor=E2=80=9D issues with this I-D. Good to hear. >> Minor Issues: >>=20 >> In the Security Considerations section a small amount of text might = be useful that discusses end-end v. encryption from middle boxes, and = the risks therein. There are clearly benefits to this over no = encryption, but there are risks about assumptions that may be made = thereafter as well. I added some text. Please review. >> Nits: >>=20 >> S.1: s/typically not modified. Which means/typically not modified, = which means/ Changed. >> S.1: Is there in fact a case where asymmetries result in the *same* = egress xTRs but different keys are used? I believe this would just = apply to "different xTRs", no? : Right, when the same ETR is used by different ITRs to encapsulate = traffic, different keys are used. >> However, return traffic uses the same procedures but with = different key values by the same xTRs or potentially different xTRs when = the paths between LISP sites are asymmetric. Right, a unique set of keys are used for each {ITR, ETR} combination. = Did you want me to say something specific here? >> S.1: Regarding "[t]his document has the following requirements for = the solutions space", it might be useful to reference some general IETF = privacy work, even RFC 6973 or the like. Given that it's Experimental I = think it's fine as is, but some references for the broader community may = be in order. In particular, references to not requiring a separate PKI = (and therefore external or circular dependencies!), avoiding third party = trust anchor, rekeying as good operational practice, not just = compromises, and other such arguments might be reinforced.=20 I added a reference to 6973. >> S.3: Could include LCAF here, perhaps. Added plus its reference. >> S.4: You could probably strike this entire sentence and lessen = confusion: "When an ETR (when it is also an ITR) encapsulates packets to = this ITR (when it is also an ETR), a separate key exchange and = shared-secret computation is performed.=E2=80=9D Okay, removed. >> S.7: It=E2=80=99s unclear what constitutes =E2=80=9CDiffie-Hellman = *group*=E2=80=9D. I will change =E2=80=9Cgroup=E2=80=9D to =E2=80=9Cparameters=E2=80=9D. >>=20 >> S.7: s/the the/the/ >>=20 >> S.7: s/integrity-check/integrity check/ Changed both. >> S.8: Editors note to strike text in last paragraph here, unclear what = resolution was from this text. =20 We allocated two new bits from a 3-bit reserved field now leaving 1 = reserve bit. I added that the reserved bit remaining is documented in = RFC6830. >> S.12.1: A reference to the SAAG comments might be useful here? We don=E2=80=99t have one. But I will add a list of recommendations they = provided. >> S 13: Are you sure you want a default FCFS allocation policy here and = not a slightly higher bar? I have no opinion. What is the benefit on not doing FCFS? >> Throughout: Consistent hyphenation in the document would help (e.g., = =E2=80=9Cnetwork-byte=E2=80=9D ..). =20 Done. >> Throughout: Expanding on first use of each acronym would be useful, = perhaps with references. Done. A new revision is attached (plus a htmlized diff file). Let me know if = you like the text and then I=E2=80=99ll submit -07. Thanks again, Dino & Brian --Apple-Mail=_F5B063EC-7A1D-485E-8968-9CD81E984DD2 Content-Disposition: attachment; filename=rfcdiff.html Content-Type: text/html; name="rfcdiff.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-lisp-crypto-06.txt - = draft-ietf-lisp-crypto-07.txt=20 =20 =20 =20 =20 =20 =20 = = =
< draft-ietf-lisp-crypto-06.txt  =  draft-ietf-lisp-crypto-07.txt >
=
Internet = Engineering Task Force D. Farinacci = Internet Engineering Task Force = D. Farinacci
Internet-Draft = lispers.net Internet-Draft = lispers.net
Intended status: = Experimental B. Weis = Intended status: Experimental = B. Weis
Expires: December 31, 2016 = cisco Systems Expires: March 9, 2017 = cisco Systems
= June = 29, 2016 = September = 5, 2016
=
= LISP Data-Plane Confidentiality = LISP Data-Plane Confidentiality
= draft-ietf-lisp-crypto-06 = = draft-ietf-lisp-crypto-07
=
Abstract = Abstract
=
This document = describes a mechanism for encrypting LISP encapsulated This document describes a mechanism for encrypting = LISP encapsulated
traffic. The = design describes how key exchange is achieved using traffic. The design describes how key exchange is = achieved using
existing LISP = control-plane mechanisms as well as how to secure the existing LISP control-plane mechanisms as well as how = to secure the
LISP = data-plane from third-party surveillance attacks. LISP data-plane from third-party surveillance = attacks.
=
Status of This = Memo Status of This Memo
=
=
skipping to = change at = page 1, line 34 =C2=B6 = skipping to change at page 1, line 34 =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 = http://datatracker.ietf.org/drafts/current/. Drafts is at = http://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 December 31, = 2016. This Internet-Draft = will expire on March 9, 2017.
=
Copyright = Notice Copyright Notice
=
Copyright (c) = 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
= (http://trustee.ietf.org/license-info) in effect on the date of = (http://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
=
skipping to = change at = page 2, line 20 =C2=B6 = skipping to change at page 2, line 20 =C2=B6
4. Overview = . . . . . . . . . . . . . . . . . . . . . . . . . . 3 = 4. Overview . . . . . . . . . . . . . . . = . . . . . . . . . . . 3
5. = Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . . = 4 5. Diffie-Hellman Key Exchange . = . . . . . . . . . . . . . . . . 4
6. Encoding = and Transmitting Key Material . . . . . . . . . . . 5 = 6. Encoding and Transmitting Key Material = . . . . . . . . . . . 5
7. Shared = Keys used for the Data-Plane . . . . . . . . . . . . . 7 = 7. Shared Keys used for the Data-Plane . . = . . . . . . . . . . . 7
8. Data-Plane = Operation . . . . . . . . . . . . . . . . . . . . 9 8. Data-Plane Operation . . . . . . . . . . . . . . = . . . . . . 9
9. Procedures = for Encryption and Decryption . . . . . . . . . . 10 9. Procedures for Encryption and Decryption . . . . = . . . . . . 10
10. Dynamic = Rekeying . . . . . . . . . . . . . . . . . . . . . . 11 = 10. Dynamic Rekeying . . . . . . . . . . . = . . . . . . . . . . . 11
11. Future = Work . . . . . . . . . . . . . . . . . . . . . . . . . 12 = 11. Future Work . . . . . . . . . . . . . . = . . . . . . . . . . . 12
12. Security = Considerations . . . . . . . . . . . . . . . . . . . 12 = 12. Security Considerations . . . . . . . . = . . . . . . . . . . . 12
12.1. SAAG = Support . . . . . . . . . . . . . . . . . . . . . . 12 = 12.1. SAAG Support . . . . . . . . . . . = . . . . . . . . . . . 12
12.2. = LISP-Crypto Security Threats . . . . . . . . . . . . . . 12 12.2. = LISP-Crypto Security Threats . . . . . . . . . . . . . . 13
13. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 13 = 13. IANA Considerations . . . . . . . . . . = . . . . . . . . . . . 13
14. = References . . . . . . . . . . . . . . . . . . . . . . . . . 13 14. = References . . . . . . . . . . . . . . . . . . . . . . . . . 14
14.1. = Normative References . . . . . . . . . . . . . . . . . . 13 14.1. = Normative References . . . . . . . . . . . . . . . . . . 14
14.2. = Informative References . . . . . . . . . . . . . . . . . 15 = 14.2. Informative References . . . . . . = . . . . . . . . . . . 15
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 15 Appendix = A. Acknowledgments . . . . . . . . . . . . . . . . . . 16
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 16 = Appendix B. Document Change Log . . . . . = . . . . . . . . . . . 16
B.1. = Changes to draft-ietf-lisp-crypto-06.txt = . . . . . . . . 16 B.1. = Changes to draft-ietf-lisp-crypto-07.txt = . . . . . . . . 16
B.2. = Changes to draft-ietf-lisp-crypto-05.txt = . . . . . . . . 16 B.2. Changes to draft-ietf-lisp-crypto-06.txt . . . . . . . . = 17
B.3. = Changes to draft-ietf-lisp-crypto-04.txt = . . . . . . . . 16 B.3. Changes to draft-ietf-lisp-crypto-05.txt . . . . . . . . = 17
B.4. = Changes to draft-ietf-lisp-crypto-03.txt = . . . . . . . . 16 B.4. Changes to draft-ietf-lisp-crypto-04.txt . . . . . . . . = 17
B.5. = Changes to draft-ietf-lisp-crypto-02.txt = . . . . . . . . 17 B.5. = Changes to draft-ietf-lisp-crypto-03.txt = . . . . . . . . 17
B.6. = Changes to draft-ietf-lisp-crypto-01.txt = . . . . . . . . 17 B.6. Changes to draft-ietf-lisp-crypto-02.txt . . . . . . . . = 18
B.7. = Changes to draft-ietf-lisp-crypto-00.txt = . . . . . . . . 17 B.7. Changes to draft-ietf-lisp-crypto-01.txt . . . . . . . . = 18
B.8. = Changes to draft-farinacci-lisp-crypto-01.txt . . . . . . = 17 = B.8. Changes to draft-ietf-lisp-crypto-00.txt . . . . . . . . 18
B.9. = Changes to draft-farinacci-lisp-crypto-00.txt . . . . . . = 18 B.9. Changes to draft-farinacci-lisp-crypto-01.txt . . . . . . = 18
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 B.10. Changes to draft-farinacci-lisp-crypto-00.txt . . = . . . . 19
= Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 19
=
1. = Introduction 1. Introduction
=
The Locator/ID = Separation Protocol [RFC6830] defines a set of The Locator/ID Separation Protocol [RFC6830] defines = a set of
functions for = routers to exchange information used to map from non- functions for routers to exchange information used to = map from non-
routable = Endpoint Identifiers (EIDs) to routable Routing Locators = routable Endpoint Identifiers (EIDs) to = routable Routing Locators
(RLOCs). = LISP ITRs and PITRs encapsulate packets to ETRs and RTRs. = (RLOCs). LISP Ingress Tunnel Routers = (ITRs) and Proxy Ingress = Tunnel
Packets that = arrive at the ITR or PITR are typically not modified. Routers (PITRs) encapsulate packets to Egress Tunnel Routers (ETRs)
Which means no protection or privacy of the = data is added. If the and Reencapsulating Tunnel Routers (RTRs). Packets = that arrive at
source host = encrypts the data stream then the encapsulated packets the ITR or PITR are typically not modified, which means no protection
can be = encrypted but would be redundant. However, when plaintext = or privacy of the data is added. If the = source host encrypts the
packets are = sent by hosts, this design can encrypt the user payload = data stream then the encapsulated packets = can be encrypted but would
to maintain = privacy on the path between the encapsulator (the ITR or = be redundant. However, when plaintext = packets are sent by hosts,
PITR) to a = decapsulator (ETR or RTR). The encrypted payload is this design can encrypt the user payload to maintain = privacy on the
= unidirectional. However, return traffic uses the same procedures = but path between the encapsulator = (the ITR or PITR) to a decapsulator
with = different key values by the same xTRs or potentially different = (ETR or RTR). The encrypted payload is = unidirectional. However,
xTRs when = the paths between LISP sites are asymmetric. return traffic uses the same procedures but with = different key values
= by the same xTRs or potentially different = xTRs when the paths between
= LISP sites are asymmetric.
=
This = document has the following requirements for the solution space: = This document has the following = requirements (as well as the = general
= requirements from = [RFC6973]) for the solution space:
=
o Do not = require a separate Public Key Infrastructure (PKI) that is = o Do not require a separate Public Key = Infrastructure (PKI) that is
out of = scope of the LISP control-plane architecture. out of scope of the LISP control-plane = architecture.
=
o The budget = for key exchange MUST be one round-trip time. That is, = o The budget for key exchange MUST be one = round-trip time. That is,
only a two = packet exchange can occur. only = a two packet exchange can occur.
=
o Use = symmetric keying so faster cryptography can be performed in = o Use symmetric keying so faster = cryptography can be performed in
the LISP = data plane. the LISP data = plane.
=
=
skipping to = change at = page 3, line 39 =C2=B6 = skipping to change at page 3, line 42 =C2=B6
The key words = "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", = "SHALL", "SHALL NOT",
"SHOULD", = "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this = "SHOULD", "SHOULD NOT", "RECOMMENDED", = "MAY", and "OPTIONAL" in this
document are = to be interpreted as described in [RFC2119]. document are to be interpreted as described in = [RFC2119].
=
3. Definition of = Terms 3. Definition of Terms
=
AEAD: = Authenticated Encryption with Additional Data. AEAD: Authenticated Encryption with Additional = Data.
=
ICV: Integrity = Check Value. ICV: Integrity Check = Value.
=
= LCAF: LISP Canonical = Address Format ([LCAF]).
=
= xTR: A general = reference to ITRs, ETRs, RTRs, and PxTRs.
= =
4. = Overview 4. Overview
=
The approach = proposed in this document is to NOT rely on the LISP The approach proposed in this document is to NOT rely = on the LISP
mapping system = (or any other key infrastructure system) to store mapping system (or any other key infrastructure = system) to store
security keys. = This will provide for a simpler and more secure security keys. This will provide for a simpler and = more secure
mechanism. = Secret shared keys will be negotiated between the ITR and = mechanism. Secret shared keys will be = negotiated between the ITR and
the ETR in = Map-Request and Map-Reply messages. Therefore, when an = the ETR in Map-Request and Map-Reply = messages. Therefore, when an
ITR needs to = obtain the RLOC of an ETR, it will get security material = ITR needs to obtain the RLOC of an ETR, it = will get security material
to compute a = shared secret with the ETR. to = compute a shared secret with the ETR.
=
The ITR can = compute 3 shared-secrets per ETR the ITR is encapsulating = The ITR can compute 3 shared-secrets per ETR = the ITR is encapsulating
to. When the = ITR encrypts a packet before encapsulation, it will to. When the ITR encrypts a packet before = encapsulation, it will
identify the = key it used for the crypto calculation so the ETR knows = identify the key it used for the crypto = calculation so the ETR knows
which key to = use for decrypting the packet after decapsulation. By which key to use for decrypting the packet after = decapsulation. By
using key-ids = in the LISP header, we can also get fast rekeying using key-ids in the LISP header, we can also get = fast rekeying
= functionality. = functionality.
=
When an ETR (when it is also an ITR) encapsulates = packets to this ITR The key = management described in this documemnt is unidirectional from
(when it is also an ETR), a separate key exchange = and shared-secret the ITR = (the encapsulator) to the ETR (the decapsultor).
computation is performed. The key management = described in this
documemnt is = unidirectional from the ITR (the encapsulator) to the
ETR (the = decapsultor).
=
5. = Diffie-Hellman Key Exchange 5. = Diffie-Hellman Key Exchange
=
LISP will use = a Diffie-Hellman [RFC2631] key exchange sequence and LISP will use a Diffie-Hellman [RFC2631] key exchange = sequence and
computation = for computing a shared secret. The Diffie-Hellman computation for computing a shared secret. The = Diffie-Hellman
parameters = will be passed via Cipher Suite code-points in Map-Request = parameters will be passed via Cipher Suite = code-points in Map-Request
and Map-Reply = messages. and Map-Reply = messages.
=
Here is a = brief description how Diff-Hellman works: Here is a brief description how Diff-Hellman = works:
=
=
skipping to = change at = page 7, line 27 =C2=B6 = skipping to change at page 7, line 27 =C2=B6
use. = use.
=
7. Shared Keys = used for the Data-Plane 7. Shared = Keys used for the Data-Plane
=
When an ITR or = PITR receives a Map-Reply accepting the Cipher Suite When an ITR or PITR receives a Map-Reply accepting = the Cipher Suite
sent in the = Map-Request, it is ready to create data plane keys. The = sent in the Map-Request, it is ready to = create data plane keys. The
same process = is followed by the ETR or RTR returning the Map-Reply. same process is followed by the ETR or RTR returning = the Map-Reply.
=
The first step = is to create a shared secret, using the peer's shared The first step is to create a shared secret, using = the peer's shared
Diffie-Hellman = Public Key Material combined with device's own private Diffie-Hellman Public Key Material combined with = device's own private
keying = material as described in Section 5. The Diffie-Hellman group = keying material as described in Section 5. The Diffie-Hellman
used is = defined in the cipher suite sent in the Map-Request and parameters used is = defined in the cipher suite sent in the Map-
copied into = the Map-Reply. = Request and copied into the Map-Reply.
=
The resulting = shared secret is used to compute an AEAD-key for the The resulting shared secret is used to compute an = AEAD-key for the
algorithms = specified in the cipher suite. A Key Derivation Function = algorithms specified in the cipher suite. A = Key Derivation Function
(KDF) in = counter mode as specified by [NIST-SP800-108] is used to = (KDF) in counter mode as specified by = [NIST-SP800-108] is used to
generate the = data-plane keys. The amount of keying material that is = generate the data-plane keys. The amount of = keying material that is
derived = depends on the algorithms in the cipher suite. derived depends on the algorithms in the cipher = suite.
=
The inputs to = the KDF are as follows: The inputs = to the KDF are as follows:
=
o KDF = function. This is HMAC-SHA-256. o = KDF function. This is HMAC-SHA-256.
=
skipping to = change at = page 7, line 51 =C2=B6 = skipping to change at page 7, line 51 =C2=B6
o A key for = the KDF function. This is the computed Diffie-Hellman o A key for the KDF function. This is the computed = Diffie-Hellman
shared = secret. shared secret.
=
o Context = that binds the use of the data-plane keys to this session. = o Context that binds the use of the = data-plane keys to this session.
The context = is made up of the following fields, which are The context is made up of the following fields, = which are
= concatenated and provided as the data to be acted upon by the = KDF concatenated and provided as = the data to be acted upon by the KDF
= function. function.
=
= Context: Context:
=
o A = counter, represented as a two-octet value in network-byte order. = o A counter, represented as a two-octet value in network byte order.
=
o The = null-terminated string "lisp-crypto". = o The null-terminated string "lisp-crypto".
=
o The ITR's = nonce from the the Map-Request the cipher = suite was o The ITR's nonce from = the Map-Request the cipher suite was included
included = in. in.
=
o The number = of bits of keying material required (L), represented as = o The number of bits of keying material = required (L), represented as
a two-octet = value in network byte order. a = two-octet value in network byte order.
=
The counter = value in the context is first set to 1. When the amount = The counter value in the context is first = set to 1. When the amount
of keying = material exceeds the number of bits returned by the KDF = of keying material exceeds the number of = bits returned by the KDF
function, then = the KDF function is called again with the same inputs function, then the KDF function is called again with = the same inputs
except that = the counter increments for each call. When enough keying = except that the counter increments for each = call. When enough keying
material is = returned, it is concatenated and used to create keys. material is returned, it is concatenated and used to = create keys.
=
=
skipping to = change at = page 9, line 4 =C2=B6 = skipping to change at page 9, line 4 =C2=B6
=
where: = context =3D 0x0002 || "lisp-crypto" || <itr-nonce> || = 0x0200 where: context =3D = 0x0002 || "lisp-crypto" || <itr-nonce> || 0x0200
=
key-material =3D= key-material-1 || key-material-2 = key-material =3D key-material-1 || key-material-2
=
If the = key-material is longer than the required number of bits (L), = If the key-material is longer than the = required number of bits (L),
then only the = most significant L bits are used. = then only the most significant L bits are used.
=
=46rom the = derived key-material, the most significant 256 bits are used = =46rom the derived key-material, the most = significant 256 bits are used
for the = AEAD-key by AEAD ciphers. The 256-bit AEAD-key is divided = for the AEAD-key by AEAD ciphers. The = 256-bit AEAD-key is divided
into a = 128-bit encryption key and a 128-bit integrity-check key = into a 128-bit encryption key and a 128-bit integrity check key
internal to = the cipher used by the ITR. = internal to the cipher used by the ITR.
=
8. Data-Plane = Operation 8. Data-Plane = Operation
=
The LISP = encapsulation header [RFC6830] requires changes to encode = The LISP encapsulation header [RFC6830] = requires changes to encode
the key-id for = the key being used for encryption. = the key-id for the key being used for encryption.
=
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
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
skipping to = change at = page 10, line 11 =C2=B6 = skipping to change at page 10, line = 11 =C2=B6
and use that = key to encrypt all packet data that follows the LISP and use that key to encrypt all packet data that = follows the LISP
header. = Therefore, the outer header, UDP header, and LISP header = header. Therefore, the outer header, UDP = header, and LISP header
travel as = plaintext. travel as = plaintext.
=
There is an = open working group item to discuss if the data There is an open working group item to discuss if the = data
encapsulation = header needs change for encryption or any new encapsulation header needs change for encryption or = any new
applications. = This document proposes changes to the existing header applications. This document proposes changes to the = existing header
so = experimentation can continue without making large changes to = the so experimentation can continue = without making large changes to the
data-plane at = this time. This document allocates 2 bits of the data-plane at this time. This document allocates 2 = bits of the
previously = unused 3 flag bits (note the R-bit above is still a previously unused 3 flag bits (note the R-bit above = is still a
reserved = flag bit) for the KK bits. = reserved flag bit as documented in = [RFC6830]) for the KK bits.
=
9. Procedures = for Encryption and Decryption 9. = Procedures for Encryption and Decryption
=
When an ITR, = PITR, or RTR encapsulate a packet and have already When an ITR, PITR, or RTR encapsulate a packet and = have already
computed an = AEAD-key (detailed in section Section 7) that is computed an AEAD-key (detailed in section Section 7) = that is
associated = with a destination RLOC, the following encryption and associated with a destination RLOC, the following = encryption and
encapsulation = procedures are performed: = encapsulation procedures are performed:
=
1. The = encapsulator creates an IV and prepends the IV value to the = 1. The encapsulator creates an IV and = prepends the IV value to the
packet = being encapsulated. For GCM and Chacha cipher suites, the = packet being encapsulated. For GCM and = Chacha cipher suites, the
=
skipping to = change at = page 12, line 36 =C2=B6 = skipping to change at page 12, line = 36 =C2=B6
=
12. Security = Considerations 12. Security = Considerations
=
12.1. SAAG = Support 12.1. SAAG Support
=
The LISP = working group received security advice and guidance from the = The LISP working group received security = advice and guidance from the
Security Area = Advisory Group (SAAG). The SAAG has been involved Security Area Advisory Group (SAAG). The SAAG has = been involved
early in the = design process and their input and reviews have been early in the design process and their input and = reviews have been
included in = this document. included in this = document.
=
= Comments from the = SAAG included:
=
= 1. Do not use = assymmetric ciphers in the data-plane.
=
= 2. Consider adding = ECDH early in the design.
=
= 3. Add cipher = suites because ciphers are created more frequently
= than protocols = that use them.
=
= 4. Consider the = newer AEAD technology so authentication comes with
= doing = encryption.
= =
12.2. = LISP-Crypto Security Threats 12.2. = LISP-Crypto Security Threats
=
Since ITRs and = ETRs participate in key exchange over a public non- Since ITRs and ETRs participate in key exchange over = a public non-
secure = network, a man-in-the-middle (MITM) could circumvent the key = secure network, a man-in-the-middle (MITM) = could circumvent the key
exchange and = compromise data-plane confidentiality. This can happen = exchange and compromise data-plane = confidentiality. This can happen
when the MITM = is acting as a Map-Replier, provides its own public key = when the MITM is acting as a Map-Replier, = provides its own public key
so the ITR and = the MITM generate a shared secret key among each so the ITR and the MITM generate a shared secret key = among each
other. If the = MITM is in the data path between the ITR and ETR, it other. If the MITM is in the data path between the = ITR and ETR, it
can use the = shared secret key to decrypt traffic from the ITR. can use the shared secret key to decrypt traffic from = the ITR.
=
=
skipping = to change at page 14, line = 49 =C2=B6 = skipping to change at page 15, line = 30 =C2=B6
[RFC6090] = McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic = [RFC6090] McGrew, D., Igoe, K., and M. = Salter, "Fundamental Elliptic
= Curve Cryptography Algorithms", RFC 6090, Curve Cryptography Algorithms", RFC = 6090,
DOI = 10.17487/RFC6090, February 2011, = DOI 10.17487/RFC6090, February 2011,
= <http://www.rfc-editor.org/info/rfc6090>. = <http://www.rfc-editor.org/info/rfc6090>.
=
[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,
= <http://www.rfc-editor.org/info/rfc6830>. = <http://www.rfc-editor.org/info/rfc6830>.
=
= [RFC6973] Cooper, = A., Tschofenig, H., Aboba, B., Peterson, J.,
= Morris, = J., Hansen, M., and R. Smith, "Privacy
= = Considerations for Internet Protocols", RFC 6973,
= DOI = 10.17487/RFC6973, July 2013,
= = <http://www.rfc-editor.org/info/rfc6973>.
= =
[RFC7539] = Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF = [RFC7539] Nir, Y. and A. Langley, "ChaCha20 = and Poly1305 for IETF
= Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, Protocols", RFC 7539, DOI = 10.17487/RFC7539, May 2015,
= <http://www.rfc-editor.org/info/rfc7539>. = <http://www.rfc-editor.org/info/rfc7539>.
=
14.2. = Informative References 14.2. = Informative References
=
[AES-CBC] = McGrew, D., Foley, J., and K. Paterson, "Authenticated [AES-CBC] McGrew, D., Foley, J., and K. Paterson, = "Authenticated
= Encryption with AES-CBC and HMAC-SHA", draft-mcgrew-aead- = Encryption with AES-CBC and = HMAC-SHA", draft-mcgrew-aead-
= aes-cbc-hmac-sha2-05.txt (work in progress). aes-cbc-hmac-sha2-05.txt (work in = progress).
=
=
skipping = to change at page 16, line = 9 =C2=B6 = skipping to change at page 16, line = 45 =C2=B6
security = expertise to make lisp-crypto as secure as the state of the = security expertise to make lisp-crypto as = secure as the state of the
art in = cryptography. art in = cryptography.
=
In addition, = the support and suggestions from the SAAG working group = In addition, the support and suggestions = from the SAAG working group
were helpful = and appreciative. were helpful and = appreciative.
=
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-crypto-06.txt B.1. = Changes to draft-ietf-lisp-crypto-07.txt
=
= o Posted September = 2016.
=
= o Addressed = comments from Routing Directorate reviewer Danny
= = McPherson.
=
= B.2. Changes to = draft-ietf-lisp-crypto-06.txt
=
o Posted June = 2016. o Posted June 2016.
=
o Fixed = IDnits errors. o Fixed IDnits = errors.
=
B.2. Changes to = draft-ietf-lisp-crypto-05.txt B.3. Changes to = draft-ietf-lisp-crypto-05.txt
=
o Posted June = 2016. o Posted June 2016.
=
o Update = document which reflects comments Luigi provided as document = o Update document which reflects comments = Luigi provided as document
= shepherd. shepherd.
=
B.3. Changes to = draft-ietf-lisp-crypto-04.txt B.4. Changes to = draft-ietf-lisp-crypto-04.txt
=
o Posted May = 2016. o Posted May 2016.
=
o Update = document timer from expiration. o = Update document timer from expiration.
=
B.4. Changes to = draft-ietf-lisp-crypto-03.txt B.5. Changes to = draft-ietf-lisp-crypto-03.txt
=
o Posted = December 2015. o Posted December = 2015.
=
o Changed = cipher suite allocations. We now have 2 AES-CBC cipher = o Changed cipher suite allocations. We now = have 2 AES-CBC cipher
suites for = compatibility, 3 AES-GCM cipher suites that are faster suites for compatibility, 3 AES-GCM cipher suites = that are faster
ciphers = that include AE and a Chacha20-Poly1305 cipher suite which = ciphers that include AE and a = Chacha20-Poly1305 cipher suite which
is the = fastest but not totally proven/accepted.. is the fastest but not totally = proven/accepted..
=
o Remove = 1024-bit DH keys for key exchange. = o Remove 1024-bit DH keys for key exchange.
=
=
skipping = to change at page 17, line = 13 =C2=B6 = skipping to change at page 18, line = 9 =C2=B6
= endian). endian).
=
o Remove = A-bit from Security Type LCAF. No need to do o Remove A-bit from Security Type LCAF. No need to = do
= authentication only with the introduction of AEAD ciphers. = These authentication only with = the introduction of AEAD ciphers. These
ciphers can = do authentication. So you get ciphertext for free. ciphers can do authentication. So you get = ciphertext for free.
=
o Remove = language that refers to "encryption-key" and "integrity- = o Remove language that refers to = "encryption-key" and "integrity-
key". Used = term "AEAD-key" that is used by the AEAD cipher suites key". Used term "AEAD-key" that is used by the = AEAD cipher suites
that do = encryption and authenticaiton internal to the cipher. that do encryption and authenticaiton internal to = the cipher.
=
B.5. Changes to = draft-ietf-lisp-crypto-02.txt B.6. Changes to = draft-ietf-lisp-crypto-02.txt
=
o Posted = September 2015. o Posted September = 2015.
=
o Add cipher = suite for Elliptic Curve 25519 DH exchange. o Add cipher suite for Elliptic Curve 25519 DH = exchange.
=
o Add cipher = suite for Chacha20/Poly1305 ciphers. = o Add cipher suite for Chacha20/Poly1305 ciphers.
=
B.6. Changes to = draft-ietf-lisp-crypto-01.txt B.7. Changes to = draft-ietf-lisp-crypto-01.txt
=
o Posted May = 2015. o Posted May 2015.
=
o Create = cipher suites and encode them in the Security LCAF. o Create cipher suites and encode them in the = Security LCAF.
=
o Add IV to = beginning of packet header and ICV to end of packet. o Add IV to beginning of packet header and ICV to = end of packet.
=
o AEAD = procedures are now part of encrpytion process. o AEAD procedures are now part of encrpytion = process.
=
B.7. Changes to = draft-ietf-lisp-crypto-00.txt B.8. Changes to = draft-ietf-lisp-crypto-00.txt
=
o Posted = January 2015. o Posted January = 2015.
=
o Changing = draft-farinacci-lisp-crypto-01 to draft-ietf-lisp-crypto- = o Changing draft-farinacci-lisp-crypto-01 = to draft-ietf-lisp-crypto-
00. This = draft has become a working group document 00. This draft has become a working group = document
=
o Add text to = indicate the working group may work on a new data o Add text to indicate the working group may work on = a new data
= encapsulation header format for data-plane encryption. encapsulation header format for data-plane = encryption.
=
B.8. Changes to = draft-farinacci-lisp-crypto-01.txt B.9. Changes to = draft-farinacci-lisp-crypto-01.txt
=
o Posted July = 2014. o Posted July 2014.
=
o Add = Group-ID to the encoding format of Key Material in a Security = o Add Group-ID to the encoding format of = Key Material in a Security
Type LCAF = and modify the IANA Considerations so this draft can use = Type LCAF and modify the IANA = Considerations so this draft can use
key = exchange parameters from the IANA registry. key exchange parameters from the IANA = registry.
=
o Indicate = that the R-bit in the Security Type LCAF is not used by = o Indicate that the R-bit in the Security = Type LCAF is not used by
= lisp-crypto. = lisp-crypto.
=
=
skipping = to change at page 18, line = 20 =C2=B6 = skipping to change at page 19, line = 17 =C2=B6
= process. process.
=
o Add text = indicating that when RLOC-probing is used for RLOC o Add text indicating that when RLOC-probing is used = for RLOC
= reachability purposes and rekeying is not desired, that the = same reachability purposes and = rekeying is not desired, that the same
key = exchange parameters should be used so a reallocation of a = key exchange parameters should be used so = a reallocation of a
pubic key = does not happen at the ETR. = pubic key does not happen at the ETR.
=
o Add text to = indicate that ECDH can be used to reduce CPU o Add text to indicate that ECDH can be used to = reduce CPU
= requirements for computing shared secret-keys. requirements for computing shared = secret-keys.
=
B.9. Changes to = draft-farinacci-lisp-crypto-00.txt B.10. Changes to = draft-farinacci-lisp-crypto-00.txt
=
o Initial = draft posted February 2014. o = Initial draft posted February 2014.
=
Authors' = Addresses Authors' Addresses
=
Dino = Farinacci Dino Farinacci
= lispers.net lispers.net
San Jose, = California 95120 San Jose, = California 95120
USA = USA
=
 End of changes. 27 change blocks. 
52 lines changed or = deleted 82 lines changed or = added

This = html diff was produced by rfcdiff 1.45. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20 = --Apple-Mail=_F5B063EC-7A1D-485E-8968-9CD81E984DD2 Content-Disposition: attachment; filename=draft-ietf-lisp-crypto-07.txt Content-Type: text/plain; name="draft-ietf-lisp-crypto-07.txt" Content-Transfer-Encoding: quoted-printable Internet Engineering Task Force D. Farinacci Internet-Draft lispers.net Intended status: Experimental B. Weis Expires: March 9, 2017 cisco Systems September 5, 2016 LISP Data-Plane Confidentiality draft-ietf-lisp-crypto-07 Abstract This document describes a mechanism for encrypting LISP encapsulated traffic. The design describes how key exchange is achieved using existing LISP control-plane mechanisms as well as how to secure the LISP data-plane from third-party surveillance attacks. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 9, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Farinacci & Weis Expires March 9, 2017 [Page 1] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . . 4 6. Encoding and Transmitting Key Material . . . . . . . . . . . 5 7. Shared Keys used for the Data-Plane . . . . . . . . . . . . . 7 8. Data-Plane Operation . . . . . . . . . . . . . . . . . . . . 9 9. Procedures for Encryption and Decryption . . . . . . . . . . 10 10. Dynamic Rekeying . . . . . . . . . . . . . . . . . . . . . . 11 11. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 12 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 12.1. SAAG Support . . . . . . . . . . . . . . . . . . . . . . 12 12.2. LISP-Crypto Security Threats . . . . . . . . . . . . . . 13 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 14.1. Normative References . . . . . . . . . . . . . . . . . . 14 14.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 16 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 16 B.1. Changes to draft-ietf-lisp-crypto-07.txt . . . . . . . . 16 B.2. Changes to draft-ietf-lisp-crypto-06.txt . . . . . . . . 17 B.3. Changes to draft-ietf-lisp-crypto-05.txt . . . . . . . . 17 B.4. Changes to draft-ietf-lisp-crypto-04.txt . . . . . . . . 17 B.5. Changes to draft-ietf-lisp-crypto-03.txt . . . . . . . . 17 B.6. Changes to draft-ietf-lisp-crypto-02.txt . . . . . . . . 18 B.7. Changes to draft-ietf-lisp-crypto-01.txt . . . . . . . . 18 B.8. Changes to draft-ietf-lisp-crypto-00.txt . . . . . . . . 18 B.9. Changes to draft-farinacci-lisp-crypto-01.txt . . . . . . 18 B.10. Changes to draft-farinacci-lisp-crypto-00.txt . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction The Locator/ID Separation Protocol [RFC6830] defines a set of functions for routers to exchange information used to map from non- routable Endpoint Identifiers (EIDs) to routable Routing Locators (RLOCs). LISP Ingress Tunnel Routers (ITRs) and Proxy Ingress Tunnel Routers (PITRs) encapsulate packets to Egress Tunnel Routers (ETRs) and Reencapsulating Tunnel Routers (RTRs). Packets that arrive at the ITR or PITR are typically not modified, which means no protection or privacy of the data is added. If the source host encrypts the data stream then the encapsulated packets can be encrypted but would be redundant. However, when plaintext packets are sent by hosts, this design can encrypt the user payload to maintain privacy on the path between the encapsulator (the ITR or PITR) to a decapsulator Farinacci & Weis Expires March 9, 2017 [Page 2] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 (ETR or RTR). The encrypted payload is unidirectional. However, return traffic uses the same procedures but with different key values by the same xTRs or potentially different xTRs when the paths between LISP sites are asymmetric. This document has the following requirements (as well as the general requirements from [RFC6973]) for the solution space: o Do not require a separate Public Key Infrastructure (PKI) that is out of scope of the LISP control-plane architecture. o The budget for key exchange MUST be one round-trip time. That is, only a two packet exchange can occur. o Use symmetric keying so faster cryptography can be performed in the LISP data plane. o Avoid a third-party trust anchor if possible. o Provide for rekeying when secret keys are compromised. o Support Authenticated Encryption with packet integrity checks. o Support multiple cipher suites so new crypto algorithms can be easily introduced. 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Definition of Terms AEAD: Authenticated Encryption with Additional Data. ICV: Integrity Check Value. LCAF: LISP Canonical Address Format ([LCAF]). xTR: A general reference to ITRs, ETRs, RTRs, and PxTRs. 4. Overview The approach proposed in this document is to NOT rely on the LISP mapping system (or any other key infrastructure system) to store security keys. This will provide for a simpler and more secure mechanism. Secret shared keys will be negotiated between the ITR and Farinacci & Weis Expires March 9, 2017 [Page 3] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 the ETR in Map-Request and Map-Reply messages. Therefore, when an ITR needs to obtain the RLOC of an ETR, it will get security material to compute a shared secret with the ETR. The ITR can compute 3 shared-secrets per ETR the ITR is encapsulating to. When the ITR encrypts a packet before encapsulation, it will identify the key it used for the crypto calculation so the ETR knows which key to use for decrypting the packet after decapsulation. By using key-ids in the LISP header, we can also get fast rekeying functionality. The key management described in this documemnt is unidirectional from the ITR (the encapsulator) to the ETR (the decapsultor). 5. Diffie-Hellman Key Exchange LISP will use a Diffie-Hellman [RFC2631] key exchange sequence and computation for computing a shared secret. The Diffie-Hellman parameters will be passed via Cipher Suite code-points in Map-Request and Map-Reply messages. Here is a brief description how Diff-Hellman works: +----------------------------+---------+----------------------------+ | ITR | | ETR | +------+--------+------------+---------+------------+---------------+ |Secret| Public | Calculates | Sends | Calculates | Public |Secret| +------|--------|------------|---------|------------|--------|------+ | i | p,g | | p,g --> | | | e | +------|--------|------------|---------|------------|--------|------+ | i | p,g,I |g^i mod p=3DI | I --> | | p,g,I | e = | +------|--------|------------|---------|------------|--------|------+ | i | p,g,I | | <-- E |g^e mod p=3DE | p,g | e = | +------|--------|------------|---------|------------|--------|------+ | i,s |p,g,I,E |E^i mod p=3Ds | |I^e mod p=3Ds |p,g,I,E | = e,s | +------|--------|------------|---------|------------|--------|------+ Public-key exchange for computing a shared private key [DH] Diffie-Hellman parameters 'p' and 'g' must be the same values used by the ITR and ETR. The ITR computes public-key 'I' and transmits 'I' in a Map-Request packet. When the ETR receives the Map-Request, it uses parameters 'p' and 'g' to compute the ETR's public key 'E'. The ETR transmits 'E' in a Map-Reply message. At this point, the ETR has enough information to compute 's', the shared secret, by using 'I' as the base and the ETR's private key 'e' as the exponent. When the ITR receives the Map-Reply, it uses the ETR's public-key 'E' with the ITR's private key 'i' to compute the same 's' shared secret the ETR Farinacci & Weis Expires March 9, 2017 [Page 4] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 computed. The value 'p' is used as a modulus to create the width of the shared secret 's' (see Section 6). 6. Encoding and Transmitting Key Material The Diffie-Hellman key material is transmitted in Map-Request and Map-Reply messages. Diffie-Hellman parameters are encoded in the LISP Security Type LCAF [LCAF]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 11 | Rsvd2 | 6 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Count | Rsvd3 | Cipher Suite | Rsvd4 |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Length | Public Key Material ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Public Key Material | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Locator Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cipher Suite field contains DH Key Exchange and Cipher/Hash Functions The 'Key Count' field encodes the number of {'Key-Length', 'Key- Material'} fields included in the encoded LCAF. The maximum number of keys that can be encoded are 3, each identified by key-id 1, followed by key-id 2, an finally key-id 3. The 'R' bit is not used for this use-case of the Security Type LCAF but is reserved for [LISP-DDT] security. Therefore, the R bit is transmitted as 0 and ignored on receipt. Farinacci & Weis Expires March 9, 2017 [Page 5] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 Cipher Suite 0: Reserved Cipher Suite 1: Diffie-Hellman Group: 2048-bit MODP [RFC3526] Encryption: AES with 128-bit keys in CBC mode [AES-CBC] Integrity: Integrated with [AES-CBC] AEAD_AES_128_CBC_HMAC_SHA_256 IV length: 16 bytes Cipher Suite 2: Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519] Encryption: AES with 128-bit keys in CBC mode [AES-CBC] Integrity: Integrated with [AES-CBC] AEAD_AES_128_CBC_HMAC_SHA_256 IV length: 16 bytes Cipher Suite 3: Diffie-Hellman Group: 2048-bit MODP [RFC3526] Encryption: AES with 128-bit keys in GCM mode [RFC5116] Integrity: Integrated with [RFC5116] AEAD_AES_128_GCM IV length: 12 bytes Cipher Suite 4: Diffie-Hellman Group: 3072-bit MODP [RFC3526] Encryption: AES with 128-bit keys in GCM mode [RFC5116] Integrity: Integrated with [RFC5116] AEAD_AES_128_GCM IV length: 12 bytes Cipher Suite 5: Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519] Encryption: AES with 128-bit keys in GCM mode [RFC5116] Integrity: Integrated with [RFC5116] AEAD_AES_128_GCM IV length: 12 bytes Cipher Suite 6: Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519] Encryption: Chacha20-Poly1305 [CHACHA-POLY] [RFC7539] Integrity: Integrated with [CHACHA-POLY] AEAD_CHACHA20_POLY1305 IV length: 8 bytes The "Public Key Material" field contains the public key generated by one of the Cipher Suites defined above. The length of the key in octets is encoded in the "Key Length" field. When an ITR, PITR, or RTR sends a Map-Request, they will encode their own RLOC in the Security Type LCAF format within the ITR-RLOCs field. When a ETR or RTR sends a Map-Reply, they will encode their RLOCs in Farinacci & Weis Expires March 9, 2017 [Page 6] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 Security Type LCAF format within the RLOC-record field of each EID- record supplied. If an ITR, PITR, or RTR sends a Map-Request with the Security Type LCAF included and the ETR or RTR does not want to have encapsulated traffic encrypted, they will return a Map-Reply with no RLOC records encoded with the Security Type LCAF. This signals to the ITR, PITR or RTR not to encrypt traffic (it cannot encrypt traffic anyways since no ETR public-key was returned). Likewise, if an ITR or PITR wish to include multiple key-ids in the Map-Request but the ETR or RTR wish to use some but not all of the key-ids, they return a Map-Reply only for those key-ids they wish to use. 7. Shared Keys used for the Data-Plane When an ITR or PITR receives a Map-Reply accepting the Cipher Suite sent in the Map-Request, it is ready to create data plane keys. The same process is followed by the ETR or RTR returning the Map-Reply. The first step is to create a shared secret, using the peer's shared Diffie-Hellman Public Key Material combined with device's own private keying material as described in Section 5. The Diffie-Hellman parameters used is defined in the cipher suite sent in the Map- Request and copied into the Map-Reply. The resulting shared secret is used to compute an AEAD-key for the algorithms specified in the cipher suite. A Key Derivation Function (KDF) in counter mode as specified by [NIST-SP800-108] is used to generate the data-plane keys. The amount of keying material that is derived depends on the algorithms in the cipher suite. The inputs to the KDF are as follows: o KDF function. This is HMAC-SHA-256. o A key for the KDF function. This is the computed Diffie-Hellman shared secret. o Context that binds the use of the data-plane keys to this session. The context is made up of the following fields, which are concatenated and provided as the data to be acted upon by the KDF function. Context: o A counter, represented as a two-octet value in network byte order. Farinacci & Weis Expires March 9, 2017 [Page 7] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 o The null-terminated string "lisp-crypto". o The ITR's nonce from the Map-Request the cipher suite was included in. o The number of bits of keying material required (L), represented as a two-octet value in network byte order. The counter value in the context is first set to 1. When the amount of keying material exceeds the number of bits returned by the KDF function, then the KDF function is called again with the same inputs except that the counter increments for each call. When enough keying material is returned, it is concatenated and used to create keys. For example, AES with 128-bit keys requires 16 octets (128 bits) of keying material, and HMAC-SHA1-96 requires another 16 octets (128 bits) of keying material in order to maintain a consistent 128-bits of security. Since 32 octets (256 bits) of keying material are required, and the KDF function HMAC-SHA-256 outputs 256 bits, only one call is required. The inputs are as follows: key-material =3D HMAC-SHA-256(dh-shared-secret, context) where: context =3D 0x0001 || "lisp-crypto" || || = 0x0100 In contrast, a cipher suite specifying AES with 256-bit keys requires 32 octets (256 bits) of keying material, and HMAC-SHA256-128 requires another 32 octets (256 bits) of keying material in order to maintain a consistent 256-bits of security. Since 64 octets (512 bits) of keying material are required, and the KDF function HMAC-SHA-256 outputs 256 bits, two calls are required. key-material-1 =3D HMAC-SHA-256(dh-shared-secret, context) where: context =3D 0x0001 || "lisp-crypto" || || = 0x0200 key-material-2 =3D HMAC-SHA-256(dh-shared-secret, context) where: context =3D 0x0002 || "lisp-crypto" || || = 0x0200 key-material =3D key-material-1 || key-material-2 If the key-material is longer than the required number of bits (L), then only the most significant L bits are used. =46rom the derived key-material, the most significant 256 bits are = used for the AEAD-key by AEAD ciphers. The 256-bit AEAD-key is divided Farinacci & Weis Expires March 9, 2017 [Page 8] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 into a 128-bit encryption key and a 128-bit integrity check key internal to the cipher used by the ITR. 8. Data-Plane Operation The LISP encapsulation header [RFC6830] requires changes to encode the key-id for the key being used for encryption. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L / |N|L|E|V|I|R|K|K| Nonce/Map-Version |\ \ I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A S \ | Instance ID/Locator-Status-Bits | |D P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |/ | Initialization Vector (IV) | I E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C n / | | V c | | | r | Packet Payload with EID Header ... | | y | | | p \ | |/ t +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ K-bits indicate when packet is encrypted and which key used When the KK bits are 00, the encapsulated packet is not encrypted. When the value of the KK bits are 1, 2, or 3, it encodes the key-id of the secret keys computed during the Diffie-Hellman Map-Request/ Map-Reply exchange. When the KK bits are not 0, the payload is prepended with an Initialization Vector (IV). The length of the IV field is based on the cipher suite used. Since all cipher suites defined in this document do Authenticated Encryption (AEAD), an ICV field does not need to be present in the packet since it is included in the ciphertext. The Additional Data (AD) used for the ICV is shown above and includes the LISP header, the IV field and the packet payload. When an ITR or PITR receives a packet to be encapsulated, they will first decide what key to use, encode the key-id into the LISP header, and use that key to encrypt all packet data that follows the LISP header. Therefore, the outer header, UDP header, and LISP header travel as plaintext. Farinacci & Weis Expires March 9, 2017 [Page 9] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 There is an open working group item to discuss if the data encapsulation header needs change for encryption or any new applications. This document proposes changes to the existing header so experimentation can continue without making large changes to the data-plane at this time. This document allocates 2 bits of the previously unused 3 flag bits (note the R-bit above is still a reserved flag bit as documented in [RFC6830]) for the KK bits. 9. Procedures for Encryption and Decryption When an ITR, PITR, or RTR encapsulate a packet and have already computed an AEAD-key (detailed in section Section 7) that is associated with a destination RLOC, the following encryption and encapsulation procedures are performed: 1. The encapsulator creates an IV and prepends the IV value to the packet being encapsulated. For GCM and Chacha cipher suites, the IV is incremented for every packet (beginning with a value of 1 in the first packet) and sent to the destination RLOC. For CBC cipher suites, the IV is a new random number for every packet sent to the destination RLOC. For the Chacha cipher suite, the IV is an 8-byte random value that is appended to a 4-byte counter that is incremented for every packet (beginning with a value of 1 in the first packet). 2. Next encrypt with cipher function AES or Chacha20 using the AEAD- key over the packet payload following the AEAD specification referenced in the cipher suite definition. This does not include the IV. The IV must be transmitted as plaintext so the decrypter can use it as input to the decryption cipher. The payload should be padded to an integral number of bytes a block cipher may require. The result of the AEAD operation may contain an ICV, the size of which is defined by the referenced AEAD specification. Note that the AD (i.e. the LISP header exactly as will be prepended in the next step and the IV) must be given to the AEAD encryption function as the "associated data" argument. 3. Prepend the LISP header. The key-id field of the LISP header is set to the key-id value that corresponds to key-pair used for the encryption cipher. 4. Lastly, prepend the UDP header and outer IP header onto the encrypted packet and send packet to destination RLOC. When an ETR, PETR, or RTR receive an encapsulated packet, the following decapsulation and decryption procedures are performed: Farinacci & Weis Expires March 9, 2017 [Page 10] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 1. The outer IP header, UDP header, LISP header, and IV field are stripped from the start of the packet. The LISP header and IV are retained and given to the AEAD decryption operation as the "associated data" argument. 2. The packet is decrypted using the AEAD-key and the IV from the packet. The AEAD-key is obtained from a local-cache associated with the key-id value from the LISP header. The result of the decryption function is a plaintext packet payload if the cipher returned a verified ICV. Otherwise, the packet has been tampered with and is discarded. If the AEAD specification included an ICV, the AEAD decryption function will locate the ICV in the ciphertext and compare it to a version of the ICV that the AEAD decryption function computes. If the computed ICV is different than the ICV located in the ciphertext, then it will be considered tampered. 3. If the packet was not tampered with, the decrypted packet is forwarded to the destination EID. 10. Dynamic Rekeying Since multiple keys can be encoded in both control and data messages, an ITR can encapsulate and encrypt with a specific key while it is negotiating other keys with the same ETR. Soon as an ETR or RTR returns a Map-Reply, it should be prepared to decapsulate and decrypt using the new keys computed with the new Diffie-Hellman parameters received in the Map-Request and returned in the Map-Reply. RLOC-probing can be used to change keys or cipher suites by the ITR at any time. And when an initial Map-Request is sent to populate the ITR's map-cache, the Map-Request flows across the mapping system where a single ETR from the Map-Reply RLOC-set will respond. If the ITR decides to use the other RLOCs in the RLOC-set, it MUST send a Map-Request directly to negotiate security parameters with the ETR. This process may be used to test reachability from an ITR to an ETR initially when a map-cache entry is added for the first time, so an ITR can get both reachability status and keys negotiated with one Map-Request/Map-Reply exchange. A rekeying event is defined to be when an ITR or PITR changes the cipher suite or public-key in the Map-Request. The ETR or RTR compares the cipher suite and public-key it last received from the ITR for the key-id, and if any value has changed, it computes a new public-key and cipher suite requested by the ITR from the Map-Request and returns it in the Map-Reply. Now a new shared secret is computed and can be used for the key-id for encryption by the ITR and decryption by the ETR. When the ITR or PITR starts this process of Farinacci & Weis Expires March 9, 2017 [Page 11] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 negotiating a new key, it must not use the corresponding key-id in encapsulated packets until it receives a Map-Reply from the ETR with the same cipher suite value it expects (the values it sent in a Map- Request). Note when RLOC-probing continues to maintain RLOC reachability and rekeying is not desirable, the ITR or RTR can either not include the Security Type LCAF in the Map-Request or supply the same key material as it received from the last Map-Reply from the ETR or RTR. This approach signals to the ETR or RTR that no rekeying event is requested. 11. Future Work For performance considerations, newer Elliptic-Curve Diffie-Hellman (ECDH) groups can be used as specified in [RFC4492] and [RFC6090] to reduce CPU cycles required to compute shared secret keys. For better security considerations as well as to be able to build faster software implementations, newer approaches to ciphers and authentication methods will be researched and tested. Some examples are Chacha20 and Poly1305 [CHACHA-POLY] [RFC7539]. 12. Security Considerations 12.1. SAAG Support The LISP working group received security advice and guidance from the Security Area Advisory Group (SAAG). The SAAG has been involved early in the design process and their input and reviews have been included in this document. Comments from the SAAG included: 1. Do not use assymmetric ciphers in the data-plane. 2. Consider adding ECDH early in the design. 3. Add cipher suites because ciphers are created more frequently than protocols that use them. 4. Consider the newer AEAD technology so authentication comes with doing encryption. Farinacci & Weis Expires March 9, 2017 [Page 12] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 12.2. LISP-Crypto Security Threats Since ITRs and ETRs participate in key exchange over a public non- secure network, a man-in-the-middle (MITM) could circumvent the key exchange and compromise data-plane confidentiality. This can happen when the MITM is acting as a Map-Replier, provides its own public key so the ITR and the MITM generate a shared secret key among each other. If the MITM is in the data path between the ITR and ETR, it can use the shared secret key to decrypt traffic from the ITR. Since LISP can secure Map-Replies by the authentication process specified in [LISP-SEC], the ITR can detect when a MITM has signed a Map-Reply for an EID-prefix it is not authoritative for. When an ITR determines the signature verification fails, it discards and does not reuse the key exchange parameters, avoids using the ETR for encapsulation, and issues a severe log message to the network administrator. Optionally, the ITR can send RLOC-probes to the compromised RLOC to determine if can reach the authoritative ETR. And when the ITR validates the signature of a Map-Reply, it can begin encrypting and encapsulating packets to the RLOC of ETR. 13. IANA Considerations This document describes a mechanism for encrypting LISP encapsulated packets based on Diffie-Hellman key exchange procedures. During the exchange the devices have to agree on a Cipher Suite used (i.e. the cipher and hash functions used to encrypt/decrypt and to sign/verify packets). The 8-bit Cipher Suite field is reserved for such purpose in the security material section of the Map-Request and Map-Reply messages. This document requests IANA to create and maintain a new registry (as outlined in [RFC5226]) entitled "LISP Crypto Cipher Suite". Initial values for the registry are provided below. Future assignments are to be made on a First Come First Served Basis. Farinacci & Weis Expires March 9, 2017 [Page 13] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 +-----+--------------------------------------------+------------+ |Value| Suite | Definition | +-----+--------------------------------------------+------------+ | 0 | Reserved | Section 6 | +-----+--------------------------------------------+------------+ | 1 | LISP_2048MODP_AES128_CBC_SHA256 | Section 6 | +-----+--------------------------------------------+------------+ | 2 | LISP_EC25519_AES128_CBC_SHA256 | Section 6 | +-----+--------------------------------------------+------------+ | 3 | LISP_2048MODP_AES128_GCM | Section 6 | +-----+--------------------------------------------+------------+ | 4 | LISP_3072MODP_AES128_GCM M-3072 | Section 6 | +-----+--------------------------------------------+------------+ | 5 | LISP_256_EC25519_AES128_GCM | Section 6 | +-----+--------------------------------------------+------------+ | 6 | LISP_256_EC25519_CHACHA20_POLY1305 | Section 6 | +-----+--------------------------------------------+------------+ LISP Crypto Cipher Suites 14. References 14.1. Normative References [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format", draft-ietf-lisp-lcaf-13.txt (work in progress). [NIST-SP800-108] "National Institute of Standards and Technology, "Recommendation for Key Derivation Using Pseudorandom Functions NIST SP800-108"", NIST SP 800-108, October 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, DOI 10.17487/RFC2631, June 1999, . [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, DOI 10.17487/RFC3526, May 2003, . Farinacci & Weis Expires March 9, 2017 [Page 14] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, DOI 10.17487/RFC4492, May 2006, . [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/RFC6090, February 2011, . [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, . [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, . 14.2. Informative References [AES-CBC] McGrew, D., Foley, J., and K. Paterson, "Authenticated Encryption with AES-CBC and HMAC-SHA", draft-mcgrew-aead- aes-cbc-hmac-sha2-05.txt (work in progress). [CHACHA-POLY] Langley, A., "ChaCha20 and Poly1305 based Cipher Suites for TLS", draft-agl-tls-chacha20poly1305-04 (work in progress). Farinacci & Weis Expires March 9, 2017 [Page 15] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 [CURVE25519] Bernstein, D., "Curve25519: new Diffie-Hellman speed records", Publication http://www.iacr.org/cryptodb/archive/2006/ PKC/3351/3351.pdf. [DH] "Diffie-Hellman key exchange", Wikipedia http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange. [LISP-DDT] Fuller, V., Lewis, D., Ermaagan, V., and A. Jain, "LISP Delegated Database Tree", draft-fuller-lisp-ddt-04 (work in progress). [LISP-SEC] Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, "LISP-Secuirty (LISP-SEC)", draft-ietf-lisp-sec-10 (work in progress). Appendix A. Acknowledgments The authors would like to thank Dan Harkins, Joel Halpern, Fabio Maino, Ed Lopez, Roger Jorgensen, and Watson Ladd for their interest, suggestions, and discussions about LISP data-plane security. An individual thank you to LISP WG chair Luigi Iannone for shepherding this document as well as contributing to the IANA Considerations section. The authors would like to give a special thank you to Ilari Liusvaara for his extensive commentary and discussion. He has contributed his security expertise to make lisp-crypto as secure as the state of the art in cryptography. In addition, the support and suggestions from the SAAG working group were helpful and appreciative. Appendix B. Document Change Log [RFC Editor: Please delete this section on publication as RFC.] B.1. Changes to draft-ietf-lisp-crypto-07.txt o Posted September 2016. o Addressed comments from Routing Directorate reviewer Danny McPherson. Farinacci & Weis Expires March 9, 2017 [Page 16] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 B.2. Changes to draft-ietf-lisp-crypto-06.txt o Posted June 2016. o Fixed IDnits errors. B.3. Changes to draft-ietf-lisp-crypto-05.txt o Posted June 2016. o Update document which reflects comments Luigi provided as document shepherd. B.4. Changes to draft-ietf-lisp-crypto-04.txt o Posted May 2016. o Update document timer from expiration. B.5. Changes to draft-ietf-lisp-crypto-03.txt o Posted December 2015. o Changed cipher suite allocations. We now have 2 AES-CBC cipher suites for compatibility, 3 AES-GCM cipher suites that are faster ciphers that include AE and a Chacha20-Poly1305 cipher suite which is the fastest but not totally proven/accepted.. o Remove 1024-bit DH keys for key exchange. o Make clear that AES and chacha20 ciphers use AEAD so part of encrytion/decryption does authentication. o Make it more clear that separate key pairs are used in each direction between xTRs. o Indicate that the IV length is different per cipher suite. o Use a counter based IV for every packet for AEAD ciphers. Previously text said to use a random number. But CBC ciphers, use a random number. o Indicate that key material is sent in network byte order (big endian). o Remove A-bit from Security Type LCAF. No need to do authentication only with the introduction of AEAD ciphers. These ciphers can do authentication. So you get ciphertext for free. Farinacci & Weis Expires March 9, 2017 [Page 17] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 o Remove language that refers to "encryption-key" and "integrity- key". Used term "AEAD-key" that is used by the AEAD cipher suites that do encryption and authenticaiton internal to the cipher. B.6. Changes to draft-ietf-lisp-crypto-02.txt o Posted September 2015. o Add cipher suite for Elliptic Curve 25519 DH exchange. o Add cipher suite for Chacha20/Poly1305 ciphers. B.7. Changes to draft-ietf-lisp-crypto-01.txt o Posted May 2015. o Create cipher suites and encode them in the Security LCAF. o Add IV to beginning of packet header and ICV to end of packet. o AEAD procedures are now part of encrpytion process. B.8. Changes to draft-ietf-lisp-crypto-00.txt o Posted January 2015. o Changing draft-farinacci-lisp-crypto-01 to draft-ietf-lisp-crypto- 00. This draft has become a working group document o Add text to indicate the working group may work on a new data encapsulation header format for data-plane encryption. B.9. Changes to draft-farinacci-lisp-crypto-01.txt o Posted July 2014. o Add Group-ID to the encoding format of Key Material in a Security Type LCAF and modify the IANA Considerations so this draft can use key exchange parameters from the IANA registry. o Indicate that the R-bit in the Security Type LCAF is not used by lisp-crypto. o Add text to indicate that ETRs/RTRs can negotiate less number of keys from which the ITR/PITR sent in a Map-Request. Farinacci & Weis Expires March 9, 2017 [Page 18] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 o Add text explaining how LISP-SEC solves the problem when a man-in- the-middle becomes part of the Map-Request/Map-Reply key exchange process. o Add text indicating that when RLOC-probing is used for RLOC reachability purposes and rekeying is not desired, that the same key exchange parameters should be used so a reallocation of a pubic key does not happen at the ETR. o Add text to indicate that ECDH can be used to reduce CPU requirements for computing shared secret-keys. B.10. Changes to draft-farinacci-lisp-crypto-00.txt o Initial draft posted February 2014. Authors' Addresses Dino Farinacci lispers.net San Jose, California 95120 USA Phone: 408-718-2001 Email: farinacci@gmail.com Brian Weis cisco Systems 170 West Tasman Drive San Jose, California 95124-1706 USA Phone: 408-526-4796 Email: bew@cisco.com Farinacci & Weis Expires March 9, 2017 [Page 19] --Apple-Mail=_F5B063EC-7A1D-485E-8968-9CD81E984DD2 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_F5B063EC-7A1D-485E-8968-9CD81E984DD2-- From nobody Wed Sep 7 13:41:25 2016 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 D5D9912B2BB for ; Wed, 7 Sep 2016 13:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=venaas-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 dzuJ3-zqdo1X for ; Wed, 7 Sep 2016 13:41:17 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49C0C12B287 for ; Wed, 7 Sep 2016 13:41:17 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id u14so7035135lfd.1 for ; Wed, 07 Sep 2016 13:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=eo+7P5SumJnQtShPKG3lcDTb9tF5fiV3TYEraqv6oow=; b=Q+w6TPEs97J9hdLEwSndr0SuqO8vvizxohw6zqHh21bZUBjVGznmNJXOy6+iVyNknk fIDVvzUyEViN4oKWrfcglMsQpB5ReZkUOFUYhad1rB8YICH304R9GA3fDkQobjkOcRif pCwVTmj8crCAy2pPHbkJEmIVtGp7BESAPRBkzMtJSe3THk8UMpZJ+ck0i1L8CU7TbO7E O3y2OdTUcklaw34EyJ42/6lDiX7qaZdkzFBLC8e31xRVEcL4ngvACf/8vIrbGZYenXt0 KOsnK99Z6/sEYpUkDmJFfXtoJvpXGhq/aIfVfADuZzAreOEZ8bkB3RGve1tgBq0K5bvg kTEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=eo+7P5SumJnQtShPKG3lcDTb9tF5fiV3TYEraqv6oow=; b=YzDiaKKimSyfhw2Sw7bfZN0MHuovxzTaGaRyTAWpWoZts/5QE2X1SoJfXYg6oiaD4K bNnMwjQdb8NOI4RImCGaqn1z3jHexkUJ8WQFeSa/NuNPIdn+Ds1+oBHpRQH1xUNFD6xS SkQH91lx8FQoV6gfeMANVBiWvqFZoUQmzYbUbHQu/XbpskOgO1QEnn3J3v/XlkvWBQBe zb7X6xjNnHUZm7Kxs6Zlmy/WnhgcYO0A64WKV9E6rMx9y4WxpFkwHc1b1USwZU+FCXlG BzwR9p9e48AjGQf3B7wI5QTOmtP0dK89ekKi1CHLI2/3/833srRCoOhanT/FmN4N3pgm gi4A== X-Gm-Message-State: AE9vXwMH9f+HAe8o43+c8oDTE8mgB8HqRUzGwDq7qIHqrovqGNP71x5qgwv+lcCGyJcoQU2kGNAly27oAL1qnw== X-Received: by 10.25.44.142 with SMTP id s136mr430206lfs.156.1473280875129; Wed, 07 Sep 2016 13:41:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.28.15 with HTTP; Wed, 7 Sep 2016 13:41:14 -0700 (PDT) From: Stig Venaas Date: Wed, 7 Sep 2016 13:41:14 -0700 Message-ID: To: rtg-ads@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: rtg-dir@ietf.org, LISP mailing list list , draft-ietf-lisp-lcaf.all@ietf.org Subject: [lisp] RtgDir review: draft-ietf-lisp-lcaf-14.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 07 Sep 2016 20:41:21 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-lisp-lcaf-14.txt Reviewer: Stig Venaas Review Date: 2016-09-07 IETF LC End Date: Intended Status: Experimental Summary: I have some minor concerns about this document that I think should be resolved before publication. The draft is almost ready but there are several places where the text is a bit unclear, and where there could be potential interoperability issues if people get it wrong. Here are the issues I found in the order they appear in the document. They are all mostly minor issues, but a few of them are just nits. In section 1 I find this sentence a bit misleading since [AFI] doesn't talk about the formatting. Currently defined AFIs include IPv4 and IPv6 addresses, which are formatted according to code-points assigned in [AFI] as follows: Is the formatting shown here for AFI 1 and 2 defined in another document? It would be good to have a reference. If it is introduced in this document, then it should not be in the introduction. In section 2, first paragraph it says: There is an address family currently defined for IPv4 or IPv6 addresses. It would be better to say that address families are defined for IPv4 and IPv6 addresses. In section 3 we have this paragraph: The Address Family AFI definitions from [AFI] only allocate code- points for the AFI value itself. The length of the address or entity that follows is not defined and is implied based on conventional experience. Where the LISP protocol uses LISP Canonical Addresses specifically, the address length definitions will be in this specification and take precedent over any other specification. I'm not sure what conventional experience means. Please try to find a better way to say it. Regarding the last sentence, what if a you want to define new LCAF encodings in the future? Is it good to say that this specification takes precedent over any other? In section 3 we have this paragraph: Length: this 16-bit field is in units of bytes and covers all of the LISP Canonical Address payload, starting and including the byte after the Length field. So any LCAF encoded address will have a minimum length of 8 bytes when the Length field is 0. The 8 bytes include the AFI, Flags, Type, Reserved, and Length fields. When the AFI is not next to encoded address in a control message, then the encoded address will have a minimum length of 6 bytes when the Length field is 0. The 6 bytes include the Flags, Type, Reserved, and Length fields. Can you phrase this differently? First it says that any LCAF encoded address has a minimum length of 8, but then it goes on to say how it sometimes is only 6. I understand what you're trying to say, but there may be a better way of stating it. In section 3 it says: Rsvd2: this 8-bit field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. Some of the LCAFs specified in this document are using it though. Hence you may need to change this text, and maybe not make it reserved. The last sentence of section 3 is: Therefore, when a locator-set has a mix of AFI records and LCAF records, all LCAF records will appear after all the AFI records. This is not necessarily true. Isn't it possible that one at some point in the future might use other AFI records that have AFI > 16387? IANA has assigned several values beyond 16387. In 4.1 it says: AFI = x: x can be any AFI value from [AFI]. Is 16387 always or sometimes allowed? Might be good to clarify that. This also applies to all the other LCAF types with similar language. Section 4.4: RTR RLOC Address: this is an encapsulation address used by an ITR or PITR which resides behind a NAT device. This address is known to have state in a NAT device so packets can flow from it to the LISP ETR behind the NAT. There can be one or more NAT Tunnel Router (NTR) [I-D.ermagan-lisp-nat-traversal] addresses supplied in these set of fields. The number of NTRs encoded is determined by the LCAF length field. When there are no NTRs supplied, the NTR fields can be omitted and reflected by the LCAF length field or an AFI of 0 can be used to indicate zero NTRs encoded. It is not quite clear to me if the NTR fields here are the RTR RLOC addresses. Does no NTR fields mean that there are no RTR RLOC addresses? If AFI 0 is used, would there be exactly 1 RTR RLOC address (of length 0), and that would have AFI 0? Section 4.5 first paragraph: Multicast group information can be published in the mapping database. So a lookup on an group address EID can return a replication list of RLOC group addresses or RLOC unicast addresses. Can you have a mix of group addresses and unicast addresses? It's also not so clear from the format what source prefixes are. Are the source prefixes the same as the unicast RLOCs mentioned above? Can you have both multiple source addresses and then multiple group addresses? Can they be in arbitrarty order, or all sources followed by all groups? It seems one will need to inspect the address itself to tell whether it is a unicast or multicast address. This is probably fine. Section 4.6 Add description of Rsvd3. Section 4.7 Add description of Rsvd3 and Rsvd4. Section 4.10 In this section there are several examples of using the AFI List Type, but I miss a general definition. It appears that there can be a variable number of AFIs in the list. Any number > 0? It might be useful to have a length field associated with each AFI, or is it OK that parsing fails if an AFI is unknown, so that the address length is not known? Section 4.10.3 Isn't it unusual to include the 0 termination? Since you know the length it is not really needed. When parsing one will need to check the length either way, what should one do it the string accidentally is not 0-terminated? Section 4.10.4 I'm assuming that the recursion is more generic than this example? It might be worth trying to explain the more generic concept and format, and make sure that this is described as just an example. Section 4.10.5 This also appears to be just an example. Section 5.2 Key Field Num: the number of fields (minus 1) the key can be broken up into. The width of the fields are fixed length. So for a key size of 8 bytes, with a Key Field Num of 4 allows 4 fields of 2 bytes in length. Allowing for a reasonable number of 16 field separators, valid values range from 0 to 15. It says minus 1. Doesn't that mean that a Key Field Num of 4 indicates 5 fields? Key Wildcard Fields: describes which fields in the key are not used as part of the key lookup. This wildcard encoding is a bitfield. Each bit is a don't-care bit for a corresponding field in the key. Bit 0 (the low-order bit) in this bitfield corresponds the first field, right-justified in the key, bit 1 the second field, and so on. When a bit is set in the bitfield it is a don't-care bit and What does right-justified mean? Does it mean that the first field is the "low order" one? Basically at the end of the message? And the highest order bit corresponds to the part of the key right after the wilcards? I think this need to be explained better to ensure interoperability. Key: the variable length key used to do a LISP Database Mapping lookup. The length of the key is the value n (shown above) minus 3. Isn't it exactly the value n, since the length is n + 3? Section 5.4 Length value n: length in bytes of fields that follow. This is a bit confusing. I think 2+n is the length in bytes that follow the lenght field. While n is the number of bytes after the JSON length. Section 5.5 It says "AFI = x" twice in the diagram. Based on this and the way it is described it might seem that the two AFI values must be the same value x, but they can differ, right? I this applies to several other messages types as well. Section 7 It looks like the table in the IANA considerations doesn't include all the types defined in this document. I'm happy to discuss my comments if needed, and also review any updates to this draft. Stig From nobody Wed Sep 7 14:12:15 2016 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 CECCC12B1B9; Wed, 7 Sep 2016 14:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DT26-9hvpxq0; Wed, 7 Sep 2016 14:12:12 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB80212B118; Wed, 7 Sep 2016 14:12:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id BFE8D1C003B; Wed, 7 Sep 2016 14:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1473282731; bh=JVQ7F2rjNsS5R1m9V9MAH2DS3pPWw6vh5N6hEFqpMLA=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Jdc2tiVCnT22YRkdjHlRveNIRr7B3pEqeF41NSLMrNKYFgiQ3ObD6remvdOt8gVVn 8FRFlWJAIDJARCFfNqVicmANk5HizlGnKxFO6tmMDD8s1pgc3MppnMt7XZt6lYn+DM 5euEOI3ikIWAKJoWe/A+j/ew9WV5LJDh2fb4YJDY= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id D75CDD80038; Wed, 7 Sep 2016 14:12:10 -0700 (PDT) To: Stig Venaas , rtg-ads@ietf.org References: From: "Joel M. Halpern" Message-ID: <23099e24-4575-5231-84b9-8a5a6f6ab2be@joelhalpern.com> Date: Wed, 7 Sep 2016 17:14:22 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: rtg-dir@ietf.org, LISP mailing list list , draft-ietf-lisp-lcaf.all@ietf.org Subject: Re: [lisp] RtgDir review: draft-ietf-lisp-lcaf-14.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 07 Sep 2016 21:12:14 -0000 Thanks Stig. This looks very useful. Authors, can you please respond? Yours, Joel On 9/7/16 4:41 PM, Stig Venaas wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through IETF last call and IESG > review, and sometimes on special request. The purpose of the review is > to provide assistance to the Routing ADs. For more information about > the Routing Directorate, please see > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, > it would be helpful if you could consider them along with any other > IETF Last Call comments that you receive, and strive to resolve them > through discussion or by updating the draft. > > Document: draft-ietf-lisp-lcaf-14.txt > Reviewer: Stig Venaas > Review Date: 2016-09-07 > IETF LC End Date: > Intended Status: Experimental > > Summary: > I have some minor concerns about this document that I think should be > resolved before publication. > > The draft is almost ready but there are several places where the text > is a bit unclear, > and where there could be potential interoperability issues if people > get it wrong. Here > are the issues I found in the order they appear in the document. They > are all mostly > minor issues, but a few of them are just nits. > > In section 1 I find this sentence a bit misleading since [AFI] doesn't > talk about the formatting. > > Currently defined AFIs include IPv4 and IPv6 addresses, which are > formatted according to code-points assigned in [AFI] as follows: > > Is the formatting shown here for AFI 1 and 2 defined in another > document? It would be good to have a reference. If it is introduced > in this document, then it should not be in the introduction. > > In section 2, first paragraph it says: > There is an address family currently defined for IPv4 or IPv6 > addresses. > > It would be better to say that address families are defined for IPv4 > and IPv6 addresses. > > In section 3 we have this paragraph: > > The Address Family AFI definitions from [AFI] only allocate code- > points for the AFI value itself. The length of the address or entity > that follows is not defined and is implied based on conventional > experience. Where the LISP protocol uses LISP Canonical Addresses > specifically, the address length definitions will be in this > specification and take precedent over any other specification. > > I'm not sure what conventional experience means. Please try to find a > better way to say it. Regarding the last sentence, what if a you want > to define new LCAF encodings in the future? Is it good to say that this > specification takes precedent over any other? > > In section 3 we have this paragraph: > > Length: this 16-bit field is in units of bytes and covers all of the > LISP Canonical Address payload, starting and including the byte > after the Length field. So any LCAF encoded address will have a > minimum length of 8 bytes when the Length field is 0. The 8 bytes > include the AFI, Flags, Type, Reserved, and Length fields. When > the AFI is not next to encoded address in a control message, then > the encoded address will have a minimum length of 6 bytes when the > Length field is 0. The 6 bytes include the Flags, Type, Reserved, > and Length fields. > > Can you phrase this differently? First it says that any LCAF encoded > address has a minimum length of 8, but then it goes on to say how it > sometimes is only 6. I understand what you're trying to say, but there > may be a better way of stating it. > > In section 3 it says: > > Rsvd2: this 8-bit field is reserved for future use and MUST be > transmitted as 0 and ignored on receipt. > > Some of the LCAFs specified in this document are using it though. Hence > you may need to change this text, and maybe not make it reserved. > > The last sentence of section 3 is: > > Therefore, when a locator-set has a mix of AFI records and > LCAF records, all LCAF records will appear after all the AFI records. > > This is not necessarily true. Isn't it possible that one at some point > in the future might use other AFI records that have AFI > 16387? IANA > has assigned several values beyond 16387. > > In 4.1 it says: > AFI = x: x can be any AFI value from [AFI]. > > Is 16387 always or sometimes allowed? Might be good to clarify that. > This also applies > to all the other LCAF types with similar language. > > Section 4.4: > > RTR RLOC Address: this is an encapsulation address used by an ITR or > PITR which resides behind a NAT device. This address is known to > have state in a NAT device so packets can flow from it to the LISP > ETR behind the NAT. There can be one or more NAT Tunnel Router > (NTR) [I-D.ermagan-lisp-nat-traversal] addresses supplied in these > set of fields. The number of NTRs encoded is determined by the > LCAF length field. When there are no NTRs supplied, the NTR > fields can be omitted and reflected by the LCAF length field or an > AFI of 0 can be used to indicate zero NTRs encoded. > > It is not quite clear to me if the NTR fields here are the RTR RLOC > addresses. Does no NTR fields mean that there are no RTR RLOC addresses? > If AFI 0 is used, would there be exactly 1 RTR RLOC address (of length > 0), and that would have AFI 0? > > Section 4.5 first paragraph: > > Multicast group information can be published in the mapping database. > So a lookup on an group address EID can return a replication list of > RLOC group addresses or RLOC unicast addresses. > > Can you have a mix of group addresses and unicast addresses? It's also > not so clear from the format what source prefixes are. Are the source > prefixes the same as the unicast RLOCs mentioned above? Can you have > both multiple source addresses and then multiple group addresses? Can > they be in arbitrarty order, or all sources followed by all groups? > It seems one will need to inspect the address itself to tell whether it > is a unicast or multicast address. This is probably fine. > > Section 4.6 > Add description of Rsvd3. > > Section 4.7 > Add description of Rsvd3 and Rsvd4. > > Section 4.10 > In this section there are several examples of using the AFI List Type, > but I miss a general definition. It appears that there can be a variable > number of AFIs in the list. Any number > 0? It might be useful to have > a length field associated with each AFI, or is it OK that parsing fails if > an AFI is unknown, so that the address length is not known? > > Section 4.10.3 > Isn't it unusual to include the 0 termination? Since you know the > length it is not really needed. When parsing one will need to check > the length either way, what should one do it the string accidentally > is not 0-terminated? > > Section 4.10.4 > I'm assuming that the recursion is more generic than this example? > It might be worth trying to explain the more generic concept and > format, and make sure that this is described as just an example. > > Section 4.10.5 > This also appears to be just an example. > > Section 5.2 > Key Field Num: the number of fields (minus 1) the key can be broken > up into. The width of the fields are fixed length. So for a key > size of 8 bytes, with a Key Field Num of 4 allows 4 fields of 2 > bytes in length. Allowing for a reasonable number of 16 field > separators, valid values range from 0 to 15. > > It says minus 1. Doesn't that mean that a Key Field Num of 4 indicates > 5 fields? > > Key Wildcard Fields: describes which fields in the key are not used > as part of the key lookup. This wildcard encoding is a bitfield. > Each bit is a don't-care bit for a corresponding field in the key. > Bit 0 (the low-order bit) in this bitfield corresponds the first > field, right-justified in the key, bit 1 the second field, and so > on. When a bit is set in the bitfield it is a don't-care bit and > > What does right-justified mean? Does it mean that the first field is the > "low order" one? Basically at the end of the message? And the highest > order bit corresponds to the part of the key right after the wilcards? > I think this need to be explained better to ensure interoperability. > > Key: the variable length key used to do a LISP Database Mapping > lookup. The length of the key is the value n (shown above) minus > 3. > > Isn't it exactly the value n, since the length is n + 3? > > Section 5.4 > Length value n: length in bytes of fields that follow. > This is a bit confusing. I think 2+n is the length in bytes that follow > the lenght field. While n is the number of bytes after the JSON length. > > Section 5.5 > > It says "AFI = x" twice in the diagram. Based on this and the way it > is described it might seem that the two AFI values must be the same > value x, but they can differ, right? I this applies to several other > messages types as well. > > Section 7 > It looks like the table in the IANA considerations doesn't include all > the types defined in this document. > > I'm happy to discuss my comments if needed, and also review any > updates to this draft. > > Stig > From nobody Wed Sep 7 14:31:56 2016 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 5BC1B12B2EC; Wed, 7 Sep 2016 14:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQJjfQ_iOGmP; Wed, 7 Sep 2016 14:31:47 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CE3512B278; Wed, 7 Sep 2016 14:31:47 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id g202so10480087pfb.0; Wed, 07 Sep 2016 14:31:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jQBS1D6QUFiXKy9GJwzoGCD0JK3poDou0JoJ1B2a9Hc=; b=N8AcS6FWUxNscJi5TSkRbawZ59Zfl20owT0hDBMpqRNM4zyPpE0ZfAtjZfjD7mmH6L GxBL0g6z4bvUmb/hSWoFNbjJVSdZ4b2s3IwdICS7UiA1+foUPS0Xa/cI1fOEAs6BcsnW qAzx1YxRO4gFYMvhoYCuT/st+zqZf3vdciszWf/+6ZTT1DIXZ7P2hzCEBVDSoxrHcaEg KStE7kkiSYnC/BJ7diLdyQ5XM7AGW5xIwYN0rkz9lHiQQoYpxg2J6++f2VkNmhlc3Dxu 6d9V977wXENGAkMthBNjH2OiH8BUMK5vgx0lGgwaFlhbaD4klAWcvSjrXO0Gtoz2o2gb 5Qmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jQBS1D6QUFiXKy9GJwzoGCD0JK3poDou0JoJ1B2a9Hc=; b=ieQHlKcwUs9jXBbvYKYKZ8MoY8UL4bPA330e4VENizLEaT5B+sdk+Wg+xSX9LYE1tQ LMp+lNxyMRt95YBgifu0WPSYMKku3LB+LANXEly43t9+GVz7UtGgrO0VyC3zT0R8/z+Z aagRQxF475IDaytv+XTgb7nOB5gqozDzNTzS3fmQtEnUJ6qcqNfv0QVOKaEl+xzuuzsh HJM65pTOZTzyiux/bfRHUUsRoG0vII2ehnlRClrdUi1ZdnoD50YMRH77HVunz5GBQ3jO QO74xoweSXuZgteFWzbg57Tgweby13otvqspETtNGoIXT2+1GXqt52sLkqN9p1Yd9SNf /0Mw== X-Gm-Message-State: AE9vXwPWKQfaRkuXiUPiHsi+yk4fwnjjg9kP4l9MYMQ/LdEscFiru9aiv8q5hrmAta3iLQ== X-Received: by 10.98.71.150 with SMTP id p22mr34409153pfi.156.1473283906619; Wed, 07 Sep 2016 14:31:46 -0700 (PDT) Received: from [13.7.28.189] ([13.7.28.189]) by smtp.gmail.com with ESMTPSA id h66sm27936649pfc.47.2016.09.07.14.31.44 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 07 Sep 2016 14:31:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: <23099e24-4575-5231-84b9-8a5a6f6ab2be@joelhalpern.com> Date: Wed, 7 Sep 2016 14:31:44 -0700 Content-Transfer-Encoding: 7bit Message-Id: <6AF00186-F8C4-4169-9960-BF3EF572D0D4@gmail.com> References: <23099e24-4575-5231-84b9-8a5a6f6ab2be@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: rtg-ads@ietf.org, LISP mailing list list , draft-ietf-lisp-lcaf.all@ietf.org, rtg-dir@ietf.org Subject: Re: [lisp] RtgDir review: draft-ietf-lisp-lcaf-14.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 07 Sep 2016 21:31:50 -0000 I will try to respond tomorrow. Thanks for your comments Stig. Dino > On Sep 7, 2016, at 2:14 PM, Joel M. Halpern wrote: > > Thanks Stig. This looks very useful. > > Authors, can you please respond? > Yours, > Joel > > On 9/7/16 4:41 PM, Stig Venaas wrote: >> Hello, >> >> I have been selected as the Routing Directorate reviewer for this >> draft. The Routing Directorate seeks to review all routing or >> routing-related drafts as they pass through IETF last call and IESG >> review, and sometimes on special request. The purpose of the review is >> to provide assistance to the Routing ADs. For more information about >> the Routing Directorate, please see >> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >> >> Although these comments are primarily for the use of the Routing ADs, >> it would be helpful if you could consider them along with any other >> IETF Last Call comments that you receive, and strive to resolve them >> through discussion or by updating the draft. >> >> Document: draft-ietf-lisp-lcaf-14.txt >> Reviewer: Stig Venaas >> Review Date: 2016-09-07 >> IETF LC End Date: >> Intended Status: Experimental >> >> Summary: >> I have some minor concerns about this document that I think should be >> resolved before publication. >> >> The draft is almost ready but there are several places where the text >> is a bit unclear, >> and where there could be potential interoperability issues if people >> get it wrong. Here >> are the issues I found in the order they appear in the document. They >> are all mostly >> minor issues, but a few of them are just nits. >> >> In section 1 I find this sentence a bit misleading since [AFI] doesn't >> talk about the formatting. >> >> Currently defined AFIs include IPv4 and IPv6 addresses, which are >> formatted according to code-points assigned in [AFI] as follows: >> >> Is the formatting shown here for AFI 1 and 2 defined in another >> document? It would be good to have a reference. If it is introduced >> in this document, then it should not be in the introduction. >> >> In section 2, first paragraph it says: >> There is an address family currently defined for IPv4 or IPv6 >> addresses. >> >> It would be better to say that address families are defined for IPv4 >> and IPv6 addresses. >> >> In section 3 we have this paragraph: >> >> The Address Family AFI definitions from [AFI] only allocate code- >> points for the AFI value itself. The length of the address or entity >> that follows is not defined and is implied based on conventional >> experience. Where the LISP protocol uses LISP Canonical Addresses >> specifically, the address length definitions will be in this >> specification and take precedent over any other specification. >> >> I'm not sure what conventional experience means. Please try to find a >> better way to say it. Regarding the last sentence, what if a you want >> to define new LCAF encodings in the future? Is it good to say that this >> specification takes precedent over any other? >> >> In section 3 we have this paragraph: >> >> Length: this 16-bit field is in units of bytes and covers all of the >> LISP Canonical Address payload, starting and including the byte >> after the Length field. So any LCAF encoded address will have a >> minimum length of 8 bytes when the Length field is 0. The 8 bytes >> include the AFI, Flags, Type, Reserved, and Length fields. When >> the AFI is not next to encoded address in a control message, then >> the encoded address will have a minimum length of 6 bytes when the >> Length field is 0. The 6 bytes include the Flags, Type, Reserved, >> and Length fields. >> >> Can you phrase this differently? First it says that any LCAF encoded >> address has a minimum length of 8, but then it goes on to say how it >> sometimes is only 6. I understand what you're trying to say, but there >> may be a better way of stating it. >> >> In section 3 it says: >> >> Rsvd2: this 8-bit field is reserved for future use and MUST be >> transmitted as 0 and ignored on receipt. >> >> Some of the LCAFs specified in this document are using it though. Hence >> you may need to change this text, and maybe not make it reserved. >> >> The last sentence of section 3 is: >> >> Therefore, when a locator-set has a mix of AFI records and >> LCAF records, all LCAF records will appear after all the AFI records. >> >> This is not necessarily true. Isn't it possible that one at some point >> in the future might use other AFI records that have AFI > 16387? IANA >> has assigned several values beyond 16387. >> >> In 4.1 it says: >> AFI = x: x can be any AFI value from [AFI]. >> >> Is 16387 always or sometimes allowed? Might be good to clarify that. >> This also applies >> to all the other LCAF types with similar language. >> >> Section 4.4: >> >> RTR RLOC Address: this is an encapsulation address used by an ITR or >> PITR which resides behind a NAT device. This address is known to >> have state in a NAT device so packets can flow from it to the LISP >> ETR behind the NAT. There can be one or more NAT Tunnel Router >> (NTR) [I-D.ermagan-lisp-nat-traversal] addresses supplied in these >> set of fields. The number of NTRs encoded is determined by the >> LCAF length field. When there are no NTRs supplied, the NTR >> fields can be omitted and reflected by the LCAF length field or an >> AFI of 0 can be used to indicate zero NTRs encoded. >> >> It is not quite clear to me if the NTR fields here are the RTR RLOC >> addresses. Does no NTR fields mean that there are no RTR RLOC addresses? >> If AFI 0 is used, would there be exactly 1 RTR RLOC address (of length >> 0), and that would have AFI 0? >> >> Section 4.5 first paragraph: >> >> Multicast group information can be published in the mapping database. >> So a lookup on an group address EID can return a replication list of >> RLOC group addresses or RLOC unicast addresses. >> >> Can you have a mix of group addresses and unicast addresses? It's also >> not so clear from the format what source prefixes are. Are the source >> prefixes the same as the unicast RLOCs mentioned above? Can you have >> both multiple source addresses and then multiple group addresses? Can >> they be in arbitrarty order, or all sources followed by all groups? >> It seems one will need to inspect the address itself to tell whether it >> is a unicast or multicast address. This is probably fine. >> >> Section 4.6 >> Add description of Rsvd3. >> >> Section 4.7 >> Add description of Rsvd3 and Rsvd4. >> >> Section 4.10 >> In this section there are several examples of using the AFI List Type, >> but I miss a general definition. It appears that there can be a variable >> number of AFIs in the list. Any number > 0? It might be useful to have >> a length field associated with each AFI, or is it OK that parsing fails if >> an AFI is unknown, so that the address length is not known? >> >> Section 4.10.3 >> Isn't it unusual to include the 0 termination? Since you know the >> length it is not really needed. When parsing one will need to check >> the length either way, what should one do it the string accidentally >> is not 0-terminated? >> >> Section 4.10.4 >> I'm assuming that the recursion is more generic than this example? >> It might be worth trying to explain the more generic concept and >> format, and make sure that this is described as just an example. >> >> Section 4.10.5 >> This also appears to be just an example. >> >> Section 5.2 >> Key Field Num: the number of fields (minus 1) the key can be broken >> up into. The width of the fields are fixed length. So for a key >> size of 8 bytes, with a Key Field Num of 4 allows 4 fields of 2 >> bytes in length. Allowing for a reasonable number of 16 field >> separators, valid values range from 0 to 15. >> >> It says minus 1. Doesn't that mean that a Key Field Num of 4 indicates >> 5 fields? >> >> Key Wildcard Fields: describes which fields in the key are not used >> as part of the key lookup. This wildcard encoding is a bitfield. >> Each bit is a don't-care bit for a corresponding field in the key. >> Bit 0 (the low-order bit) in this bitfield corresponds the first >> field, right-justified in the key, bit 1 the second field, and so >> on. When a bit is set in the bitfield it is a don't-care bit and >> >> What does right-justified mean? Does it mean that the first field is the >> "low order" one? Basically at the end of the message? And the highest >> order bit corresponds to the part of the key right after the wilcards? >> I think this need to be explained better to ensure interoperability. >> >> Key: the variable length key used to do a LISP Database Mapping >> lookup. The length of the key is the value n (shown above) minus >> 3. >> >> Isn't it exactly the value n, since the length is n + 3? >> >> Section 5.4 >> Length value n: length in bytes of fields that follow. >> This is a bit confusing. I think 2+n is the length in bytes that follow >> the lenght field. While n is the number of bytes after the JSON length. >> >> Section 5.5 >> >> It says "AFI = x" twice in the diagram. Based on this and the way it >> is described it might seem that the two AFI values must be the same >> value x, but they can differ, right? I this applies to several other >> messages types as well. >> >> Section 7 >> It looks like the table in the IANA considerations doesn't include all >> the types defined in this document. >> >> I'm happy to discuss my comments if needed, and also review any >> updates to this draft. >> >> Stig >> From nobody Thu Sep 8 00:42:19 2016 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 DADC612B109; Thu, 8 Sep 2016 00:42:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147332053489.7457.13357960738561807033.idtracker@ietfa.amsl.com> Date: Thu, 08 Sep 2016 00:42:14 -0700 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-type-iana-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 08 Sep 2016 07:42:15 -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 of the IETF. Title : LISP Experimental Message & IANA Registry for LISP Packet Type Allocations Authors : Mohamed Boucadair Christian Jacquenet Filename : draft-ietf-lisp-type-iana-01.txt Pages : 5 Date : 2016-09-08 Abstract: This document defines a registry for LISP Packet Type allocations. It also specifies a shared LISP message type for experimentation purposes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-type-iana/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lisp-type-iana-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-type-iana-01 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 Thu Sep 8 13:06:08 2016 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 EC85A12B1E6; Thu, 8 Sep 2016 13:06:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.32.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147336516396.21882.3780019816243874818.idtracker@ietfa.amsl.com> Date: Thu, 08 Sep 2016 13:06:03 -0700 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-ddt-08.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 08 Sep 2016 20:06:04 -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 of the IETF. Title : LISP Delegated Database Tree Authors : Vince Fuller Darrel Lewis Vina Ermagan Amit Jain Anton Smirnov Filename : draft-ietf-lisp-ddt-08.txt Pages : 37 Date : 2016-09-08 Abstract: This document describes the LISP Delegated Database Tree (LISP-DDT), a hierarchical, distributed database which embodies the delegation of authority to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs). It is a statically-defined distribution of the EID namespace among a set of LISP-speaking servers, called DDT nodes. Each DDT node is configured as "authoritative" for one or more EID-prefixes, along with the set of RLOCs for Map Servers or "child" DDT nodes to which more-specific EID-prefixes are delegated. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-ddt/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lisp-ddt-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-ddt-08 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 Thu Sep 8 14:03:28 2016 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 4EF6512B258; Thu, 8 Sep 2016 14:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.288 X-Spam-Level: X-Spam-Status: No, score=-1.288 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_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_HTML_ATTACH=0.01] 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 n6xPIi3miANz; Thu, 8 Sep 2016 14:03:15 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 8248C12B0CA; Thu, 8 Sep 2016 14:03:15 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id s131so90239146oie.2; Thu, 08 Sep 2016 14:03:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=UjpFVFvIE2uXflcL07c6LmkSCfqlgKob5QTeyEXQB60=; b=dRt3fMQdrONRQUUCV5MKM7cBuBRFyrZzvSbGLXYLs8oyKzUSxcSfv9hjaaVw9pvhBd NtQ1i823aXpuJa8W2gLRQf2Z7FSS/cxUFA4bBIo6CblHkAlHMMwIn6gBxwn88QTn03BJ X+7ORkzUffpoyPY5hxliOZIolTSIt6Zh8bktA0knKKj0p4hu95Q3qK3M7d7X3oX5bxY1 j1adWVBi7DlL6/MiAQUq8BSAoZRuigdjTFv48G1BYYf5Dc/lLE7RxenJaIAp/PYp6GXn Q8CNpCSHRZv9zT9jL1/8MG8PR/esF2JLFTvrOox4j+M3w4APKQMdUJtDR9f/YJGi+xhV KSDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=UjpFVFvIE2uXflcL07c6LmkSCfqlgKob5QTeyEXQB60=; b=GSlgTAatHpkhDRHWI6butd5RzfYxobykphvrUhYYxCp9VFoK74sXAJJID85eM2dE2C xBL7+vta8RyYHH7tIxZz6u4AHoB+bBlYeKz8okHjAbmme48sJB6QTu60qQMoZc3jtY78 9qvhXIGHtDP6GfBXzQkk+Otu7O2IgdIJMFHikI8wWCnNhhyya2AeGLTLjU2e+SWD037D okXN5ZA60Nc5NWRfgtW0w2od48RkOGuj+WWF4vJGZgCQsRNK11iVIUclmJm1xf3upLqz o4ZCV94RDbM/dMvm251jTz6uicYOPhWSvgWtATCEvg0Olocp4S3FsMiAwMWB3s86yrYJ uWMg== X-Gm-Message-State: AE9vXwMufu3cTs8X0dY5q1g3H0YDaXlQJIaPpC6wTO1fhW5NuoO4izBIpzNVtcHyauvE2A== X-Received: by 10.202.235.9 with SMTP id j9mr2516333oih.103.1473368594014; Thu, 08 Sep 2016 14:03:14 -0700 (PDT) Received: from [172.19.131.158] ([12.130.117.42]) by smtp.gmail.com with ESMTPSA id g12sm232173iog.33.2016.09.08.14.02.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 08 Sep 2016 14:03:10 -0700 (PDT) Content-Type: multipart/mixed; boundary="Apple-Mail=_F14C54DF-FC1E-47EB-B6F8-161931C27CC9" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: Date: Thu, 8 Sep 2016 14:02:54 -0700 Message-Id: <551BDE7B-6BA3-4336-B92A-395FBE4A571D@gmail.com> References: To: Stig Venaas X-Mailer: Apple Mail (2.3124) Archived-At: Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, LISP mailing list list , draft-ietf-lisp-lcaf.all@ietf.org Subject: Re: [lisp] RtgDir review: draft-ietf-lisp-lcaf-14.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 08 Sep 2016 21:03:23 -0000 --Apple-Mail=_F14C54DF-FC1E-47EB-B6F8-161931C27CC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Document: draft-ietf-lisp-lcaf-14.txt > Reviewer: Stig Venaas > Review Date: 2016-09-07 > IETF LC End Date: > Intended Status: Experimental Thanks Stig for your comments. See responses below. As well as a new = version -15 not submitted yet but for your quick review. Also find a = lcaf-rfcdiff.html file for easy diff viewing. > Summary: > I have some minor concerns about this document that I think should be > resolved before publication. >=20 > The draft is almost ready but there are several places where the text > is a bit unclear, No problem. This document has had a long history and many opinions = related to it has come and gone but we tried to reflect everyone=E2=80=99s= point of view. > In section 1 I find this sentence a bit misleading since [AFI] doesn't > talk about the formatting. >=20 > Currently defined AFIs include IPv4 and IPv6 addresses, which are > formatted according to code-points assigned in [AFI] as follows: >=20 > Is the formatting shown here for AFI 1 and 2 defined in another > document? It would be good to have a reference. If it is introduced > in this document, then it should not be in the introduction. No it is not shown in any document. All the AFI document says is that a = 16-bit AFI value of 1 means an IP address follows. That means 4 bytes of = address. And 16 for IPv6 when AFI is 2. As you can see the reference to the AFI document is at the end of the = sentence. > In section 2, first paragraph it says: > There is an address family currently defined for IPv4 or IPv6 > addresses. >=20 > It would be better to say that address families are defined for IPv4 > and IPv6 addresses. Changed. > In section 3 we have this paragraph: >=20 > The Address Family AFI definitions from [AFI] only allocate code- > points for the AFI value itself. The length of the address or = entity > that follows is not defined and is implied based on conventional > experience. Where the LISP protocol uses LISP Canonical Addresses > specifically, the address length definitions will be in this > specification and take precedent over any other specification. >=20 > I'm not sure what conventional experience means. Please try to find a Well like I said above, the AFI values defined in the AFI document are = just type values and there is no length defined. So =E2=80=9Cconventional = wisdom=E2=80=9D means that if a spec says an AFI value 1 is IPv4, we = know what follows is 4 bytes. Ditto for IPv6, MAC addresses, etc. > better way to say it. Regarding the last sentence, what if a you want > to define new LCAF encodings in the future? Is it good to say that = this > specification takes precedent over any other? LCAF encodings and definitions do not change the length of an AFI = encoded address. So I am not sure what you mean. > In section 3 we have this paragraph: >=20 > Length: this 16-bit field is in units of bytes and covers all of = the > LISP Canonical Address payload, starting and including the byte > after the Length field. So any LCAF encoded address will have a > minimum length of 8 bytes when the Length field is 0. The 8 = bytes > include the AFI, Flags, Type, Reserved, and Length fields. When > the AFI is not next to encoded address in a control message, then > the encoded address will have a minimum length of 6 bytes when = the > Length field is 0. The 6 bytes include the Flags, Type, = Reserved, > and Length fields. >=20 > Can you phrase this differently? First it says that any LCAF encoded No not really. It is precise up to the sentence =E2=80=9CWhen the AFI is = not ..=E2=80=9D.=20 > address has a minimum length of 8, but then it goes on to say how it > sometimes is only 6. I understand what you're trying to say, but there=20= > may be a better way of stating it. This special case is for some LISP control-messages where the AFI is = another place in the message but the address is somewhere else. Rather = than have the AFI appear twice, the LCAF length needs to be different. The length field always includes the entire contiguous set of LCAF bytes = including type, flags, length field, etc. The language is precise and accurate. Let me know how you think stating = what I did in this comment response can be put in without writing a lot = of text about a special case. > In section 3 it says: >=20 > Rsvd2: this 8-bit field is reserved for future use and MUST be > transmitted as 0 and ignored on receipt. >=20 > Some of the LCAFs specified in this document are using it though. = Hence > you may need to change this text, and maybe not make it reserved. I change to say the field is LCAF Type dependent and check the LCAF Type = definition to see what bits of this field is not reserved. > The last sentence of section 3 is: >=20 > Therefore, when a locator-set has a mix of AFI records and > LCAF records, all LCAF records will appear after all the AFI = records. >=20 > This is not necessarily true. Isn't it possible that one at some point > in the future might use other AFI records that have AFI > 16387? IANA > has assigned several values beyond 16387. I will change to order must be in AFI value order. > In 4.1 it says: > AFI =3D x: x can be any AFI value from [AFI]. >=20 > Is 16387 always or sometimes allowed? Might be good to clarify that. > This also applies > to all the other LCAF types with similar language. Always. And since 16387 is in [AFI] and the sentence above says =E2=80=9Cc= an be any AFI value from [AFI]=E2=80=9D that implies it can be an LCAF = AFI. If I said =E2=80=9Cincluding the LCAF AFI, I would have to make = this change in a dozen places and would be repetitive. > Section 4.4: >=20 > RTR RLOC Address: this is an encapsulation address used by an ITR = or > PITR which resides behind a NAT device. This address is known to > have state in a NAT device so packets can flow from it to the = LISP > ETR behind the NAT. There can be one or more NAT Tunnel Router > (NTR) [I-D.ermagan-lisp-nat-traversal] addresses supplied in = these > set of fields. The number of NTRs encoded is determined by the > LCAF length field. When there are no NTRs supplied, the NTR > fields can be omitted and reflected by the LCAF length field or = an > AFI of 0 can be used to indicate zero NTRs encoded. >=20 > It is not quite clear to me if the NTR fields here are the RTR RLOC > addresses. Does no NTR fields mean that there are no RTR RLOC = addresses? > If AFI 0 is used, would there be exactly 1 RTR RLOC address (of length > 0), and that would have AFI 0? Good catch. NTR was an old term and the NAT-traversal draft now uses the = term RTR. I will fix. > Section 4.5 first paragraph: >=20 > Multicast group information can be published in the mapping = database. > So a lookup on an group address EID can return a replication list of > RLOC group addresses or RLOC unicast addresses. >=20 > Can you have a mix of group addresses and unicast addresses? It's also Yes, it just depends what address you put following the AFI value. > not so clear from the format what source prefixes are. Are the source I will state that when an (S,G) is encoded that is what the source = address field is used for. > prefixes the same as the unicast RLOCs mentioned above? Can you have > both multiple source addresses and then multiple group addresses? Can > they be in arbitrarty order, or all sources followed by all groups? As shown it is not a list. And if the AFI=3D0 precedes the Source/Subnet = Address field it means there is no source address encoded. > It seems one will need to inspect the address itself to tell whether = it > is a unicast or multicast address. This is probably fine. Right. > Section 4.6 > Add description of Rsvd3. >=20 > Section 4.7 > Add description of Rsvd3 and Rsvd4. Changed. > Section 4.10 > In this section there are several examples of using the AFI List Type, > but I miss a general definition. It appears that there can be a = variable > number of AFIs in the list. Any number > 0? It might be useful to have Yes, a variable number.=20 > a length field associated with each AFI, or is it OK that parsing = fails if > an AFI is unknown, so that the address length is not known? Well each AFI has an implicit length per address entry and the LCAF Type = length has the total length. So why would we need to have yet another = length and complicate parsing even more? Please be aware (and I=E2=80=99m = sure you are being a senior coder), that the more fields you add to = parse, the more cross-checking of field semantics and lengths have to be = done. This really complicates the code and if part of the LCAF Type is = parseable and others are not, then you have a question about what you = use and what you discard. > Section 4.10.3 > Isn't it unusual to include the 0 termination? Since you know the > length it is not really needed. When parsing one will need to check > the length either way, what should one do it the string accidentally > is not 0-terminated? Well the AFI definition in [AFI] doesn=E2=80=99t say how to terminate = the string. But the length field will imply it. However, I wrote the = =E2=80=9Cdistinguished-name=E2=80=9D draft to specify when AFI=3D17 is = used (not only in a LCAF but by itself), how to terminate the string. I = could include that reference, but that draft is not a working group = document. So please advise. > Section 4.10.4 > I'm assuming that the recursion is more generic than this example? Yes. > It might be worth trying to explain the more generic concept and > format, and make sure that this is described as just an example. I think that can raise too many combinations. It will be hard to explain = why someone will want to recurse a lot unless we have a well defined = use-case. The fact that an LCAF has an AFI value. It means that an LCAF = can be encoded wherever an AFI value is allowed. This section shows a practical example and not a general one that no one = would know how to use. > Section 4.10.5 > This also appears to be just an example. But a useful one that is already implemented in cisco code. > Section 5.2 > Key Field Num: the number of fields (minus 1) the key can be broken > up into. The width of the fields are fixed length. So for a key > size of 8 bytes, with a Key Field Num of 4 allows 4 fields of 2 > bytes in length. Allowing for a reasonable number of 16 field > separators, valid values range from 0 to 15. >=20 > It says minus 1. Doesn't that mean that a Key Field Num of 4 indicates > 5 fields? I fixed the description to be more clear. > Key Wildcard Fields: describes which fields in the key are not used > as part of the key lookup. This wildcard encoding is a bitfield. > Each bit is a don't-care bit for a corresponding field in the = key. > Bit 0 (the low-order bit) in this bitfield corresponds the first > field, right-justified in the key, bit 1 the second field, and so > on. When a bit is set in the bitfield it is a don't-care bit and >=20 > What does right-justified mean? Does it mean that the first field is = the > "low order" one? Basically at the end of the message? And the highest Yes, I will make that more clear. > order bit corresponds to the part of the key right after the wilcards? > I think this need to be explained better to ensure interoperability. >=20 > Key: the variable length key used to do a LISP Database Mapping > lookup. The length of the key is the value n (shown above) minus > 3. >=20 > Isn't it exactly the value n, since the length is n + 3? Yes, you are right. Fixed. > Section 5.4 > Length value n: length in bytes of fields that follow. > This is a bit confusing. I think 2+n is the length in bytes that = follow > the lenght field. While n is the number of bytes after the JSON = length. The 2 is for the JSON length field, since it is a fixed field. The = =E2=80=9Cn=E2=80=9D is for the remaining variable length fields which = include the JSON-binary-text and the AFI address. I=E2=80=99ll make the = Length description reflect this. Thanks. > Section 5.5 >=20 > It says "AFI =3D x" twice in the diagram. Based on this and the way it > is described it might seem that the two AFI values must be the same > value x, but they can differ, right? I this applies to several other > messages types as well. I=E2=80=99ll change x to y in the second occurence and a description for = each. > Section 7 > It looks like the table in the IANA considerations doesn't include all > the types defined in this document. That was done intentionally. The ones that are experimental are not in = this section 7 list because there is no use-case document for it yet. = Maybe the chairs can explain this better than me. > I'm happy to discuss my comments if needed, and also review any > updates to this draft. >=20 > Stig Let me know about the response where I didn=E2=80=99t make any changes. Thanks again, Dino/Dave/Job --Apple-Mail=_F14C54DF-FC1E-47EB-B6F8-161931C27CC9 Content-Disposition: attachment; filename=draft-ietf-lisp-lcaf-15.txt Content-Type: text/plain; name="draft-ietf-lisp-lcaf-15.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft lispers.net Intended status: Experimental D. Meyer Expires: March 12, 2017 Brocade J. Snijders NTT Communications September 8, 2016 LISP Canonical Address Format (LCAF) draft-ietf-lisp-lcaf-15 Abstract This draft defines a canonical address format encoding used in LISP control messages and in the encoding of lookup keys for the LISP Mapping Database System. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 12, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Farinacci, et al. Expires March 12, 2017 [Page 1] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. LISP Canonical Address Format Encodings . . . . . . . . . . . 5 4. LISP Canonical Address Applications . . . . . . . . . . . . . 7 4.1. Segmentation using LISP . . . . . . . . . . . . . . . . . 7 4.2. Carrying AS Numbers in the Mapping Database . . . . . . . 9 4.3. Assigning Geo Coordinates to Locator Addresses . . . . . 10 4.4. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . 12 4.5. Multicast Group Membership Information . . . . . . . . . 14 4.6. Traffic Engineering using Re-encapsulating Tunnels . . . 16 4.7. Storing Security Data in the Mapping Database . . . . . . 17 4.8. Source/Destination 2-Tuple Lookups . . . . . . . . . . . 19 4.9. Replication List Entries for Multicast Forwarding . . . . 21 4.10. Applications for AFI List Type . . . . . . . . . . . . . 22 4.10.1. Binding IPv4 and IPv6 Addresses . . . . . . . . . . 22 4.10.2. Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . 23 4.10.3. ASCII Names in the Mapping Database . . . . . . . . 24 4.10.4. Using Recursive LISP Canonical Address Encodings . . 25 4.10.5. Compatibility Mode Use Case . . . . . . . . . . . . 26 5. Experimental LISP Canonical Address Applications . . . . . . 27 5.1. Convey Application Specific Data . . . . . . . . . . . . 27 5.2. Generic Database Mapping Lookups . . . . . . . . . . . . 28 5.3. PETR Admission Control Functionality . . . . . . . . . . 30 5.4. Data Model Encoding . . . . . . . . . . . . . . . . . . . 31 5.5. Encoding Key/Value Address Pairs . . . . . . . . . . . . 32 5.6. Multiple Data-Planes . . . . . . . . . . . . . . . . . . 33 6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 8.1. Normative References . . . . . . . . . . . . . . . . . . 37 8.2. Informative References . . . . . . . . . . . . . . . . . 38 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 39 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 40 B.1. Changes to draft-ietf-lisp-lcaf-15.txt . . . . . . . . . 40 B.2. Changes to draft-ietf-lisp-lcaf-14.txt . . . . . . . . . 40 B.3. Changes to draft-ietf-lisp-lcaf-13.txt . . . . . . . . . 40 B.4. Changes to draft-ietf-lisp-lcaf-12.txt . . . . . . . . . 40 B.5. Changes to draft-ietf-lisp-lcaf-11.txt . . . . . . . . . 40 Farinacci, et al. Expires March 12, 2017 [Page 2] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 B.6. Changes to draft-ietf-lisp-lcaf-10.txt . . . . . . . . . 41 B.7. Changes to draft-ietf-lisp-lcaf-09.txt . . . . . . . . . 41 B.8. Changes to draft-ietf-lisp-lcaf-08.txt . . . . . . . . . 41 B.9. Changes to draft-ietf-lisp-lcaf-07.txt . . . . . . . . . 41 B.10. Changes to draft-ietf-lisp-lcaf-06.txt . . . . . . . . . 41 B.11. Changes to draft-ietf-lisp-lcaf-05.txt . . . . . . . . . 41 B.12. Changes to draft-ietf-lisp-lcaf-04.txt . . . . . . . . . 42 B.13. Changes to draft-ietf-lisp-lcaf-03.txt . . . . . . . . . 42 B.14. Changes to draft-ietf-lisp-lcaf-02.txt . . . . . . . . . 42 B.15. Changes to draft-ietf-lisp-lcaf-01.txt . . . . . . . . . 42 B.16. Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 1. Introduction The LISP architecture and protocols [RFC6830] introduces two new numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). To provide flexibility for current and future applications, these values can be encoded in LISP control messages using a general syntax that includes Address Family Identifier (AFI), length, and value fields. Currently defined AFIs include IPv4 and IPv6 addresses, which are formatted according to code-points assigned in [AFI] as follows: IPv4 Encoded Address: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 1 | IPv4 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires March 12, 2017 [Page 3] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 IPv6 Encoded Address: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 2 | IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This document describes the currently-defined AFIs the LISP protocol uses along with their encodings and introduces the LISP Canonical Address Format (LCAF) that can be used to define the LISP-specific encodings for arbitrary AFI values. 2. Definition of Terms Address Family Identifier (AFI): a term used to describe an address encoding in a packet. Address families are defined for IPv4 and IPv6. See [AFI] and [RFC3232] for details. The reserved AFI value of 0 is used in this specification to indicate an unspecified encoded address where the length of the address is 0 bytes following the 16-bit AFI value of 0. Unspecified Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 0 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Endpoint ID (EID): 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. The host obtains a destination EID the same way it obtains a destination address today, for example through a DNS lookup or SIP exchange. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID is allocated to a host from an EID-prefix block associated with the site where the host is located. An EID can be used by a host to refer to other hosts. Farinacci, et al. Expires March 12, 2017 [Page 4] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Routing Locator (RLOC): the IPv4 or IPv6 address of an egress tunnel router (ETR). It is the output of a EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as PA addresses. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site. 3. LISP Canonical Address Format Encodings IANA has assigned AFI value 16387 (0x4003) to the LISP architecture and protocols. This specification defines the encoding format of the LISP Canonical Address (LCA). This section defines all types for which an initial allocation in the LISP-LCAF registry is requested. See IANA Considerations section for the complete list of such types. The Address Family AFI definitions from [AFI] only allocate code- points for the AFI value itself. The length of the address or entity that follows is not defined and is implied based on conventional experience. Where the LISP protocol uses LISP Canonical Addresses specifically, the address length definitions will be in this specification and take precedent over any other specification. The first 6 bytes of an LISP Canonical Address are followed by a variable number of fields of variable length: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Rsvd2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rsvd1: this 8-bit field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. Flags: this 8-bit field is for future definition and use. For now, set to zero on transmission and ignored on receipt. Type: this 8-bit field is specific to the LISP Canonical Address formatted encodings, currently allocated values are: Type 0: Null Body Type Type 1: AFI List Type Farinacci, et al. Expires March 12, 2017 [Page 5] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Type 2: Instance ID Type Type 3: AS Number Type Type 4: Application Data Type Type 5: Geo Coordinates Type Type 6: Opaque Key Type Type 7: NAT-Traversal Type Type 8: Nonce Locator Type Type 9: Multicast Info Type Type 10: Explicit Locator Path Type Type 11: Security Key Type Type 12: Source/Dest Key Type Type 13: Replication List Entry Type Type 14: JSON Data Model Type Type 15: Key/Value Address Pair Type Type 16: Encapsulation Format Type Rsvd2: this LCAF Type dependent 8-bit field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. See specific LCAF Type for specific bits not reserved. Length: this 16-bit field is in units of bytes and covers all of the LISP Canonical Address payload, starting and including the byte after the Length field. So any LCAF encoded address will have a minimum length of 8 bytes when the Length field is 0. The 8 bytes include the AFI, Flags, Type, Reserved, and Length fields. When the AFI is not next to encoded address in a control message, then the encoded address will have a minimum length of 6 bytes when the Length field is 0. The 6 bytes include the Flags, Type, Reserved, and Length fields. [RFC6830] states RLOC records are sorted when encoded in control messages so the locator-set has consistent order across all xTRs for a given EID. The sort order is based on sort-key {afi, RLOC- address}. When an RLOC is LCAF encoded, the sort-key is {afi, LCAF- Farinacci, et al. Expires March 12, 2017 [Page 6] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Type}. Therefore, when a locator-set has a mix of AFI records and LCAF records, they are ordered from smallest to largest AFI value. 4. LISP Canonical Address Applications 4.1. Segmentation using LISP When multiple organizations inside of a LISP site are using private addresses [RFC1918] as EID-prefixes, their address spaces must remain segregated due to possible address duplication. An Instance ID in the address encoding can aid in making the entire AFI based address unique. Another use for the Instance ID LISP Canonical Address Format is when creating multiple segmented VPNs inside of a LISP site where keeping EID-prefix based subnets is desirable. Farinacci, et al. Expires March 12, 2017 [Page 7] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Instance ID LISP Canonical Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 2 | IID mask-len | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IID mask-len: if the AFI is set to 0, then this format is not encoding an extended EID-prefix but rather an instance-ID range where the 'IID mask-len' indicates the number of high-order bits used in the Instance ID field for the range. Length value n: length in bytes of the AFI address that follows the Instance ID field including the AFI field itself. Instance ID: the low-order 24-bits that can go into a LISP data header when the I-bit is set. See [RFC6830] for details. The reason for the length difference is so that the maximum number of instances supported per mapping system is 2^32 while conserving space in the LISP data header. This comes at the expense of limiting the maximum number of instances per xTR to 2^24. If an xTR is configured with multiple instance-IDs where the value in the high-order 8 bits are the same, then the low-order 24 bits MUST be unique. AFI =3D x: x can be any AFI value from [AFI]. This LISP Canonical Address Type can be used to encode either EID or RLOC addresses. Usage: When used as a lookup key, the EID is regarded as a extended- EID in the mapping system. This encoding is used in EID records in Map-Requests, Map-Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. Farinacci, et al. Expires March 12, 2017 [Page 8] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.2. Carrying AS Numbers in the Mapping Database When an AS number is stored in the LISP Mapping Database System for either policy or documentation reasons, it can be encoded in a LISP Canonical Address. AS Number LISP Canonical Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 3 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AS Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the AS Number field including the AFI field itself. AS Number: the 32-bit AS number of the autonomous system that has been assigned either the EID or RLOC that follows. AFI =3D x: x can be any AFI value from [AFI]. The AS Number Canonical Address Type can be used to encode either EID or RLOC addresses. The former is used to describe the LISP-ALT AS number the EID-prefix for the site is being carried for. The latter is used to describe the AS that is carrying RLOC based prefixes in the underlying routing system. Usage: This encoding can be used in EID or RLOC records in Map- Requests, Map-Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. Farinacci, et al. Expires March 12, 2017 [Page 9] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.3. Assigning Geo Coordinates to Locator Addresses If an ETR desires to send a Map-Reply describing the Geo Coordinates for each locator in its locator-set, it can use the Geo Coordinate Type to convey physical location information. Coordinates are specified using the WGS-84 (World Geodetic System) reference coordinate system [WGS-84]. Geo Coordinate LISP Canonical Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 5 | Rsvd2 | 12 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N| Latitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Longitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Altitude | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the 8-byte Longitude and Latitude fields including the AFI field itself. N: When set to 1 means North, otherwise South. Latitude Degrees: Valid values range from 0 to 90 degrees above or below the equator (northern or southern hemisphere, respectively). Latitude Minutes: Valid values range from 0 to 59. Latitude Seconds: Valid values range from 0 to 59. E: When set to 1 means East, otherwise West. Longitude Degrees: Value values are from 0 to 180 degrees right or left of the Prime Meridian. Longitude Minutes: Valid values range from 0 to 59. Longitude Seconds: Valid values range from 0 to 59. Farinacci, et al. Expires March 12, 2017 [Page 10] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Altitude: Height relative to sea level in meters. This is a signed integer meaning that the altitude could be below sea level. A value of 0x7fffffff indicates no Altitude value is encoded. AFI =3D x: x can be any AFI value from [AFI]. The Geo Coordinates Canonical Address Type can be used to encode either EID or RLOC addresses. When used for EID encodings, you can determine the physical location of an EID along with the topological location by observing the locator-set. Usage: This encoding can be used in EID or RLOC records in Map- Requests, Map-Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. Farinacci, et al. Expires March 12, 2017 [Page 11] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.4. NAT Traversal Scenarios When a LISP system is conveying global address and mapped port information when traversing through a NAT device, the NAT-Traversal LCAF Type is used. See [I-D.ermagan-lisp-nat-traversal] for details. NAT-Traversal Canonical Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 7 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MS UDP Port Number | ETR UDP Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Global ETR RLOC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | MS RLOC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Private ETR RLOC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR RLOC Address 1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR RLOC Address k ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI addresses that follows the UDP Port Number field including the AFI fields themselves. MS UDP Port Number: this is the UDP port number of the Map-Server and is set to 4342. ETR UDP Port Number: this is the port number returned to a LISP system which was copied from the source port from a packet that has flowed through a NAT device. AFI =3D x: x can be any AFI value from [AFI]. Global ETR RLOC Address: this is an address known to be globally unique built by NAT-traversal functionality in a LISP router. MS RLOC Address: this is the address of the Map-Server used in the destination RLOC of a packet that has flowed through a NAT device. Farinacci, et al. Expires March 12, 2017 [Page 12] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Private ETR RLOC Address: this is an address known to be a private address inserted in this LCAF format by a LISP router that resides on the private side of a NAT device. RTR RLOC Address: this is an encapsulation address used by an ITR or PITR which resides behind a NAT device. This address is known to have state in a NAT device so packets can flow from it to the LISP ETR behind the NAT. There can be one or more NAT Reencapsulating Tunnel Router (RTR) [I-D.ermagan-lisp-nat-traversal] addresses supplied in these set of fields. The number of RTRs encoded is determined by the LCAF length field. When there are no RTRs supplied, the RTR fields can be omitted and reflected by the LCAF length field or an AFI of 0 can be used to indicate zero RTRs encoded. Usage: This encoding can be used in Info-Request and Info-Reply messages. The mapping system does not store this information. The information is used by an xTR and Map-Server to convey private and public address information when traversing NAT and firewall devices. Farinacci, et al. Expires March 12, 2017 [Page 13] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.5. Multicast Group Membership Information Multicast group information can be published in the mapping database. So a lookup on an group address EID can return a replication list of RLOC group addresses or RLOC unicast addresses. The intent of this type of unicast replication is to deliver packets to multiple ETRs at receiver LISP multicast sites. The locator-set encoding for this EID record type can be a list of ETRs when they each register with "Merge Semantics". The encoding can be a typical AFI encoded locator address. When an RTR list is being registered (with multiple levels according to [I-D.coras-lisp-re]), the Replication List Entry LCAF type is used for locator encoding. This LCAF encoding can be used to send broadcast packets to all members of a subnet when each EIDs are away from their home subnet location. Multicast Info Canonical Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 9 | Rsvd2 | 8 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Source MaskLen| Group MaskLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Source/Subnet Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Group Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Reserved: must be set to zero and ignore on receipt. Instance ID: the low-order 24-bits that can go into a LISP data header when the I-bit is set. See [RFC6830] for details. The use of the Instance-ID in this LCAF type is to associate a multicast forwarding entry for a given VPN. The instance-ID describes the VPN and is registered to the mapping database system as a 3-tuple of (Instance-ID, S-prefix, G-prefix). Source MaskLen: the mask length of the source prefix that follows. Farinacci, et al. Expires March 12, 2017 [Page 14] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Group MaskLen: the mask length of the group prefix that follows. AFI =3D x: x can be any AFI value from [AFI]. When a specific AFI = has its own encoding of a multicast address, this field must be either a group address or a broadcast address. Source/Subnet Address is the source address or prefix for encoding a (S,G) multicast entry. Group Address is the group address or group prefix for encoding (S,G) or (*,G) multicast entries. Usage: This encoding can be used in EID records in Map-Requests, Map- Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. Farinacci, et al. Expires March 12, 2017 [Page 15] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.6. Traffic Engineering using Re-encapsulating Tunnels For a given EID lookup into the mapping database, this LCAF format can be returned to provide a list of locators in an explicit re- encapsulation path. See [I-D.farinacci-lisp-te] for details. Explicit Locator Path (ELP) Canonical Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 10 | Rsvd2 | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 |L|P|S| AFI =3D x | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reencap Hop 1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 |L|P|S| AFI =3D x | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reencap Hop k ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Rsvd3: this field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. Lookup bit (L): this is the Lookup bit used to indicate to the user of the ELP to not use this address for encapsulation but to look it up in the mapping database system to obtain an encapsulating RLOC address. RLOC-Probe bit (P): this is the RLOC-probe bit which means the Reencap Hop allows RLOC-probe messages to be sent to it. When the R-bit is set to 0, RLOC-probes must not be sent. When a Reencap Hop is an anycast address then multiple physical Reencap Hops are using the same RLOC address. In this case, RLOC-probes are not needed because when the closest RLOC address is not reachable another RLOC address can be reachable. Strict bit (S): this is the strict bit which means the associated Rencap Hop is required to be used. If this bit is 0, the reencapsulator can skip this Reencap Hop and go to the next one in the list. Farinacci, et al. Expires March 12, 2017 [Page 16] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 AFI =3D x: x can be any AFI value from [AFI]. When a specific AFI = has its own encoding of a multicast address, this field must be either a group address or a broadcast address. Usage: This encoding can be used in RLOC records in Map-Requests, Map-Replies, Map-Registers, and Map-Notify messages. This encoding does not need to be understood by the mapping system for mapping database lookups since this LCAF type is not a lookup key. 4.7. Storing Security Data in the Mapping Database When a locator in a locator-set has a security key associated with it, this LCAF format will be used to encode key material. See [I-D.ietf-lisp-ddt] for details. Farinacci, et al. Expires March 12, 2017 [Page 17] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Security Key Canonical Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 11 | Rsvd2 | 6 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Count | Rsvd3 | Key Algorithm | Rsvd4 |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Length | Key Material ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Key Material | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Locator Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that start with the Key Material field. Key Count: the Key Count field declares the number of Key sections included in this LCAF. Rsvd3: this field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. Key Algorithm: the Algorithm field identifies the key's cryptographic algorithm and specifies the format of the Public Key field. Rsvd4: this field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. R bit: this is the revoke bit and, if set, it specifies that this Key is being Revoked. Key Length: this field determines the length in bytes of the Key Material field. Key Material: the Key Material field stores the key material. The format of the key material stored depends on the Key Algorithm field. AFI =3D x: x can be any AFI value from [AFI].This is the locator address that owns the encoded security key. Farinacci, et al. Expires March 12, 2017 [Page 18] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Usage: This encoding can be used in EID or RLOC records in Map- Requests, Map-Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. 4.8. Source/Destination 2-Tuple Lookups When both a source and destination address of a flow needs consideration for different locator-sets, this 2-tuple key is used in EID fields in LISP control messages. When the Source/Dest key is registered to the mapping database, it can be encoded as a source- prefix and destination-prefix. When the Source/Dest is used as a key for a mapping database lookup the source and destination come from a data packet. Farinacci, et al. Expires March 12, 2017 [Page 19] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Source/Dest Key Canonical Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 12 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Source-ML | Dest-ML | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Source-Prefix ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Destination-Prefix ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Reserved: must be set to zero and ignore on receipt. Source-ML: the mask length of the source prefix that follows. Dest-ML: the mask length of the destination prefix that follows. AFI =3D x: x can be any AFI value from [AFI]. When a specific AFI = has its own encoding of a multicast address, this field must be either a group address or a broadcast address. Usage: This encoding can be used in EID records in Map-Requests, Map- Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. Refer to [I-D.farinacci-lisp-te] for usage details of this LCAF type. Farinacci, et al. Expires March 12, 2017 [Page 20] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.9. Replication List Entries for Multicast Forwarding The Replication List Entry LCAF type is an encoding for a locator being used for unicast replication according to the specification in [I-D.coras-lisp-re]. This locator encoding is pointed to by a Multicast Info LCAF Type and is registered by Re-encapsulating Tunnel Routers (RTRs) that are participating in an overlay distribution tree. Each RTR will register its locator address and its configured level in the distribution tree. Replication List Entry Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 13 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 | Rsvd4 | Level Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR/ETR #1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 | Rsvd4 | Level Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR/ETR #n ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Rsvd{1,2,3,4}: must be set to zero and ignore on receipt. Level Value: this value is associated with the level within the overlay distribution tree hierarchy where the RTR resides. The level numbers are ordered from lowest value being close to the ITR (meaning that ITRs replicate to level-0 RTRs) and higher levels are further downstream on the distribution tree closer to ETRs of multicast receiver sites. AFI =3D x: x can be any AFI value from [AFI]. A specific AFI has = its own encoding of either a unicast or multicast locator address. For efficiency reasons, all RTR/ETR entries for the same level should be combined together by a Map-Server to avoid searching through the entire multi-level list of locator entries in a Map- Reply message. Usage: This encoding can be used in RLOC records in Map-Requests, Map-Replies, Map-Registers, and Map-Notify messages. Farinacci, et al. Expires March 12, 2017 [Page 21] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.10. Applications for AFI List Type 4.10.1. Binding IPv4 and IPv6 Addresses When header translation between IPv4 and IPv6 is desirable a LISP Canonical Address can use the AFI List Type to carry multiple AFIs in one LCAF AFI. Address Binding LISP Canonical Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 2 + 4 + 2 + 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 1 | IPv4 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv4 Address | AFI =3D 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes is fixed at 24 when IPv4 and IPv6 AFI encoded addresses are used. This type of address format can be included in a Map-Request when the address is being used as an EID, but the Mapping Database System lookup destination can use only the IPv4 address. This is so a Mapping Database Service Transport System, such as LISP-ALT [RFC6836], can use the Map-Request destination address to route the control message to the desired LISP site. Usage: This encoding can be used in EID or RLOC records in Map- Requests, Map-Replies, Map-Registers, and Map-Notify messages. See subsections in this section for specific use cases. Farinacci, et al. Expires March 12, 2017 [Page 22] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.10.2. Layer-2 VPNs When MAC addresses are stored in the LISP Mapping Database System, the AFI List Type can be used to carry AFI 6. MAC Address LISP Canonical Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 2 + 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 6 | Layer-2 MAC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Layer-2 MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes is fixed at 8 when MAC address AFI encoded addresses are used. This address format can be used to connect layer-2 domains together using LISP over an IPv4 or IPv6 core network to create a layer-2 VPN. In this use-case, a MAC address is being used as an EID, and the locator-set that this EID maps to can be an IPv4 or IPv6 RLOCs, or even another MAC address being used as an RLOC. See [I-D.portoles-lisp-eid-mobility] for how layer-2 VPNs operate when doing EID mobility. Farinacci, et al. Expires March 12, 2017 [Page 23] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.10.3. ASCII Names in the Mapping Database If DNS names or URIs are stored in the LISP Mapping Database System, the AFI List Type can be used to carry an ASCII string where it is delimited by length 'n' of the LCAF Length encoding. ASCII LISP Canonical Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 2 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 17 | DNS Name or URI ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes AFI=3D17 field and the = null-terminated ASCII string (the last byte of 0 is included). Farinacci, et al. Expires March 12, 2017 [Page 24] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.10.4. Using Recursive LISP Canonical Address Encodings When any combination of above is desirable, the AFI List Type value can be used to carry within the LCAF AFI another LCAF AFI (for example, Application Specific Data see Section 5.1. Recursive LISP Canonical Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 8 + 18 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 4 | Rsvd2 | 12 + 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP TOS, IPv6 QQS or Flow Label | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Port (lower-range) | Local Port (upper-range) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Port (lower-range) | Remote Port (upper-range) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 1 | IPv4 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes is fixed at 18 when an AFI=3D1 IPv4 address = is included. This format could be used by a Mapping Database Transport System, such as LISP-ALT [RFC6836], where the AFI=3D1 IPv4 address is used as an EID and placed in the Map-Request destination address by the sending LISP system. The ALT system can deliver the Map-Request to the LISP destination site independent of the Application Data Type AFI payload values. When this AFI is processed by the destination LISP site, it can return different locator-sets based on the type of application or level of service that is being requested. Farinacci, et al. Expires March 12, 2017 [Page 25] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.10.5. Compatibility Mode Use Case A LISP system should use the AFI List Type format when sending to LISP systems that do not support a particular LCAF Type used to encode locators. This allows the receiving system to be able to parse a locator address for encapsulation purposes. The list of AFIs in an AFI List LCAF Type has no semantic ordering and a receiver should parse each AFI element no matter what the ordering. Compatibility Mode Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 8 + 14 + 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 5 | Rsvd2 | 12 + 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N| Latitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Longitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Altitude | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 0 | AFI =3D 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If a system does not recognized the Geo Coordinate LCAF Type that is accompanying a locator address, an encoder can include the Geo Coordinate LCAF Type embedded in a AFI List LCAF Type where the AFI in the Geo Coordinate LCAF is set to 0 and the AFI encoded next in the list is encoded with a valid AFI value to identify the locator address. A LISP system is required to support the AFI List LCAF Type to use this procedure. It would skip over 10 bytes of the Geo Coordinate LCAF Type to get to the locator address encoding (an IPv4 locator address). A LISP system that does support the Geo Coordinate LCAF Type can support parsing the locator address within the Geo Coordinate LCAF encoding or in the locator encoding that follows in the AFI List LCAF. Farinacci, et al. Expires March 12, 2017 [Page 26] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 5. Experimental LISP Canonical Address Applications 5.1. Convey Application Specific Data When a locator-set needs to be conveyed based on the type of application or the Per-Hop Behavior (PHB) of a packet, the Application Data Type can be used. Application Data LISP Canonical Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 4 | Rsvd2 | 12 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP TOS, IPv6 TC, or Flow Label | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Port (lower-range) | Local Port (upper-range) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Port (lower-range) | Remote Port (upper-range) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the 8-byte Application Data fields including the AFI field itself. IP TOS, IPv6 TC, or Flow Label: this field stores the 8-bit IPv4 TOS field used in an IPv4 header, the 8-bit IPv6 Traffic Class or Flow Label used in an IPv6 header. Local Port/Remote Port Ranges: these fields are from the TCP, UDP, or SCTP transport header. A range can be specified by using a lower value and an upper value. When a single port is encoded, the lower and upper value fields are the same. AFI =3D x: x can be any AFI value from [AFI]. The Application Data Canonical Address Type is used for an EID encoding when an ITR wants a locator-set for a specific application. When used for an RLOC encoding, the ETR is supplying a locator-set for each specific application is has been configured to advertise. Usage: This encoding can be used in EID records in Map-Requests, Map- Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended Farinacci, et al. Expires March 12, 2017 [Page 27] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 EIDs are used in Map-Referral messages. This LCAF type is used as a lookup key to the mapping system that can return a longest-match or exact-match entry. 5.2. Generic Database Mapping Lookups When the LISP Mapping Database system holds information accessed by a generic formatted key (where the key is not the usual IPv4 or IPv6 address), an opaque key may be desirable. Opaque Key LISP Canonical Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 6 | Rsvd2 | 3 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Field Num | Key Wildcard Fields | Key . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the type's payload. The value n is the number of bytes that follow this Length field. Farinacci, et al. Expires March 12, 2017 [Page 28] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Key Field Num: the value of this field is the the number of "Key" sub-fields minus 1, the "Key" field can be broken up into. So if this field has a value of 0, there is 1 sub-field in the "Key". The width of the sub-fields are fixed length. So for a key size of 8 bytes, with a Key Field Num of 3, allows 4 sub-fields of 2 bytes each in length. Allowing for a reasonable number of 16 sub- field separators, valid values range from 0 to 15. Key Wildcard Fields: describes which fields in the key are not used as part of the key lookup. This wildcard encoding is a bitfield. Each bit is a don't-care bit for a corresponding field in the key. Bit 0 (the low-order bit) in this bitfield corresponds the first field, the low-order field in the key, bit 1 the second field, and so on. When a bit is set in the bitfield it is a don't-care bit and should not be considered as part of the database lookup. When the entire 16-bits is set to 0, then all bits of the key are used for the database lookup. Key: the variable length key used to do a LISP Database Mapping lookup. The length of the key is the value n (as shown above). Usage: This is an experimental type where the usage has not been defined yet. Farinacci, et al. Expires March 12, 2017 [Page 29] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 5.3. PETR Admission Control Functionality When a public PETR device wants to verify who is encapsulating to it, it can check for a specific nonce value in the LISP encapsulated packet. To convey the nonce to admitted ITRs or PITRs, this LCAF format is used in a Map-Register or Map-Reply locator-record. Nonce Locator Canonical Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 8 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the Nonce field including the AFI field itself. Reserved: must be set to zero and ignore on receipt. Nonce: this is a nonce value returned by an ETR in a Map-Reply locator-record to be used by an ITR or PITR when encapsulating to the locator address encoded in the AFI field of this LCAF type. This nonce value is inserted in the nonce field in the LISP header encapsulation. AFI =3D x: x can be any AFI value from [AFI]. Usage: This is an experimental type where the usage has not been defined yet. Farinacci, et al. Expires March 12, 2017 [Page 30] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 5.4. Data Model Encoding This type allows a JSON data model to be encoded either as an EID or RLOC. JSON Data Model Type Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 14 | Rsvd2 |B| 2 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | JSON length | JSON binary/text encoding ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Optional Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the fields that follow the "JSON length" field. Rsvd{1,2}: must be set to zero and ignore on receipt. B bit: indicates that the JSON field is binary encoded according to [JSON-BINARY] when the bit is set to 1. Otherwise the encoding is based on text encoding according to [RFC7159]. JSON length: length in octets of the following 'JSON binary/text encoding' field. JSON binary/text encoding field: a variable length field that contains either binary or text encodings. AFI =3D x: x can be any AFI value from [AFI]. A specific AFI has = its own encoding of either a unicast or multicast locator address. All RTR/ETR entries for the same level should be combined together by a Map-Server to avoid searching through the entire multi-level list of locator entries in a Map-Reply message. Usage: This is an experimental type where the usage has not been defined yet. Farinacci, et al. Expires March 12, 2017 [Page 31] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 5.5. Encoding Key/Value Address Pairs The Key/Value pair is for example useful for attaching attributes to other elements of LISP packets, such as EIDs or RLOCs. When attaching attributes to EIDs or RLOCs, it's necessary to distinguish between the element that should be used as EID or RLOC, and hence as key for lookups, and additional attributes. This is especially the case when the difference cannot be determined from the types of the elements, such as when two IP addresses are being used. Key/Value Pair Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 15 | Rsvd2 | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address as Key ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D y | Address as Value ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Rsvd{1,2}: must be set to zero and ignore on receipt. AFI =3D x: x is the "Address as Key" AFI that can have any value = from [AFI]. A specific AFI has its own encoding of either a unicast or multicast locator address. All RTR/ETR entries for the same level should be combined together by a Map-Server to avoid searching through the entire multi-level list of locator entries in a Map- Reply message. Address as Key: this AFI encoded address will be attached with the attributes encoded in "Address as Value" which follows this field. AFI =3D y: y is the "Address of Value" AFI that can have any value from [AFI]. A specific AFI has its own encoding of either a unicast or multicast locator address. All RTR/ETR entries for the same level should be combined together by a Map-Server to avoid searching through the entire multi-level list of locator entries in a Map-Reply message. Address as Value: this AFI encoded address will be the attribute address that goes along with "Address as Key" which precedes this field. Farinacci, et al. Expires March 12, 2017 [Page 32] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Usage: This is an experimental type where the usage has not been defined yet. 5.6. Multiple Data-Planes Overlays are becoming popular in many parts of the network which have created an explosion of data-plane encapsulation headers. Since the LISP mapping system can hold many types of address formats, it can represent the encapsulation format supported by an RLOC as well. When an encapsulator receives a Map-Reply with an Encapsulation Format LCAF Type encoded in an RLOC-record, it can select an encapsulation format, that it can support, from any of the encapsulation protocols which have the bit set to 1 in this LCAF type. Farinacci, et al. Expires March 12, 2017 [Page 33] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Encapsulation Format Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 16 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved-for-Future-Encapsulations |U|G|N|v|V|l|L| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rsvd1/Rsvd2: must be set to zero and ignored on receipt. Length value n: length in bytes of the AFI address that follows the next 32-bits including the AFI field itself. Reserved-for-Future-Encapsulations: must be set to zero and ignored on receipt. This field will get bits allocated to future encapsulations, as they are created. L: The RLOCs listed in the AFI encoded addresses in the next longword can accept layer3 LISP encapsulation using destination UDP port 4341 [RFC6830]. l: The RLOCs listed in the AFI encoded addresses in the next longword can accept layer2 LISP encapsulation using destination UDP port 8472 [I-D.smith-lisp-layer2]. V: The RLOCs listed in the AFI encoded addresses in the next longword can accept VXLAN encapsulation using destination UDP port 4789 [RFC7348]. v: The RLOCs listed in the AFI encoded addresses in the next longword can accept VXLAN-GPE encapsulation using destination UDP port 4790 [I-D.quinn-vxlan-gpe]. N: The RLOCs listed in the AFI encoded addresses in the next longword can accept NV-GRE encapsulation using IPv4/ IPv6 protocol number 47 [RFC7637]. G: The RLOCs listed in the AFI encoded addresses in the next longword can accept GENEVE encapsulation using destination UDP port 6081 [I-D.gross-geneve]. Farinacci, et al. Expires March 12, 2017 [Page 34] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 U: The RLOCs listed in the AFI encoded addresses in the next longword can accept GUE encapsulation using destination UDP port TBD [I-D.herbert-gue]. Usage: This encoding can be used in RLOC records in Map-Requests, Map-Replies, Map-Registers, and Map-Notify messages. Farinacci, et al. Expires March 12, 2017 [Page 35] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 6. Security Considerations There are no security considerations for this specification. The security considerations are documented for the protocols that use LISP Canonical Addressing. The use of the Geo-Coordinates LCAF Type may raise physical privacy issues. Care should be taken when configuring the mapping system to use specific policy parameters so geo-location information is not returned gratutiosly. 7. IANA Considerations This document defines a canonical address format encoding used in LISP control messages and in the encoding of lookup keys for the LISP Mapping Database System. Such address format is based on a fixed AFI (16387) and a LISP LCAF Type field. The LISP LCAF Type field is an 8-bit field specific to the LISP Canonical Address formatted encodings, for which IANA is to create and maintain a new registry (as outlined in [RFC5226]) entitled "LISP LCAF Type". Initial values for the LISP LCAF Type registry are given below. Future assignments are to be made through expert review with a specification required publication. Assignments consist of a LISP LCAF Type name and its associated value: +-------+------------------------------+------------+ | Value | LISP LCAF Type Name | Definition | +-------+------------------------------+------------+ | 0 | Null Body Type | Section 3 | | 1 | AFI List Type | Section 3 | | 2 | Instance ID Type | Section 3 | | 3 | AS Number Type | Section 3 | | 5 | Geo Coordinates Type | Section 3 | | 7 | NAT-Traversal Type | Section 3 | | 9 | Multicast Info Type | Section 3 | | 10 | Explicit Locator Path Type | Section 3 | | 11 | Security Key Type | Section 3 | | 12 | Source/Dest Key Type | Section 3 | | 13 | Replication List Entry Type | Section 3 | +-------+------------------------------+------------+ Table 1: LISP LCAF Type Initial Values Farinacci, et al. Expires March 12, 2017 [Page 36] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 8. References 8.1. Normative References [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, DOI 10.17487/RFC3232, January 2002, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, . [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, January 2013, . [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, . [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, . [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network Virtualization Using Generic Routing Encapsulation", RFC 7637, DOI 10.17487/RFC7637, September 2015, . Farinacci, et al. Expires March 12, 2017 [Page 37] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 8.2. Informative References [AFI] IANA, , "Address Family Identifier (AFIs)", ADDRESS FAMILY NUMBERS http://www.iana.org/numbers.html, Febuary 2007. [I-D.coras-lisp-re] Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., Maino, F., and D. Farinacci, "LISP Replication Engineering", draft-coras-lisp-re-08 (work in progress), November 2015. [I-D.ermagan-lisp-nat-traversal] Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, F., and C. White, "NAT traversal for LISP", draft-ermagan- lisp-nat-traversal-11 (work in progress), August 2016. [I-D.farinacci-lisp-te] Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic Engineering Use-Cases", draft-farinacci-lisp-te-11 (work in progress), September 2016. [I-D.gross-geneve] Gross, J., Sridhar, T., Garg, P., Wright, C., Ganga, I., Agarwal, P., Duda, K., Dutt, D., and J. Hudson, "Geneve: Generic Network Virtualization Encapsulation", draft- gross-geneve-02 (work in progress), October 2014. [I-D.herbert-gue] Herbert, T., Yong, L., and O. Zia, "Generic UDP Encapsulation", draft-herbert-gue-03 (work in progress), March 2015. [I-D.ietf-lisp-ddt] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp- ddt-07 (work in progress), May 2016. [I-D.portoles-lisp-eid-mobility] Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a Unified Control Plane", draft-portoles-lisp-eid- mobility-00 (work in progress), April 2016. Farinacci, et al. Expires March 12, 2017 [Page 38] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 [I-D.quinn-vxlan-gpe] Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F., Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg, P., and D. Melman, "Generic Protocol Extension for VXLAN", draft-quinn-vxlan-gpe-04 (work in progress), February 2015. [I-D.smith-lisp-layer2] Smith, M., Dutt, D., Farinacci, D., and F. Maino, "Layer 2 (L2) LISP Encapsulation Format", draft-smith-lisp- layer2-03 (work in progress), September 2013. [JSON-BINARY] "Universal Binary JSON Specification", URL http://ubjson.org. [WGS-84] Geodesy and Geophysics Department, DoD., "World Geodetic System 1984", NIMA TR8350.2, January 2000, . Appendix A. Acknowledgments The authors would like to thank Vince Fuller, Gregg Schudel, Jesper Skriver, Luigi Iannone, Isidor Kouvelas, and Sander Steffann for their technical and editorial commentary. The authors would like to thank Victor Moreno for discussions that lead to the definition of the Multicast Info LCAF type. The authors would like to thank Parantap Lahiri and Michael Kowal for discussions that lead to the definition of the Explicit Locator Path (ELP) LCAF type. The authors would like to thank Fabio Maino and Vina Ermagan for discussions that lead to the definition of the Security Key LCAF type. The authors would like to thank Albert Cabellos-Aparicio and Florin Coras for discussions that lead to the definition of the Replication List Entry LCAF type. Thanks goes to Michiel Blokzijl and Alberto Rodriguez-Natal for suggesting new LCAF types. Thanks also goes to Terry Manderson for assistance obtaining a LISP AFI value from IANA. Farinacci, et al. Expires March 12, 2017 [Page 39] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Appendix B. Document Change Log [RFC Editor: Please delete this section on publication as RFC.] B.1. Changes to draft-ietf-lisp-lcaf-15.txt o Submitted September 2016. o Addressed comments from Routing Directorate reviewer Stig Venass. B.2. Changes to draft-ietf-lisp-lcaf-14.txt o Submitted July 2016. o Fix IDnits errors and comments from Luigi Iannone, document shepherd. B.3. Changes to draft-ietf-lisp-lcaf-13.txt o Submitted May 2016. o Explain the Instance-ID LCAF Type is 32-bits in length and the Instance-ID field in the LISP encapsulation header is 24-bits. B.4. Changes to draft-ietf-lisp-lcaf-12.txt o Submitted March 2016. o Updated references and document timer. o Removed the R, J, and L bits from the Multicast Info Type LCAF since working group decided to not go forward with draft- farinacci-lisp-mr-signaling-03.txt in favor of draft- ietf-lisp- signal-free-00.txt. B.5. Changes to draft-ietf-lisp-lcaf-11.txt o Submitted September 2015. o Reflecting comments from Prague LISP working group. o Readying document for a LISP LCAF registry, RFC publication, and for new use-cases that will be defined in the new charter. Farinacci, et al. Expires March 12, 2017 [Page 40] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 B.6. Changes to draft-ietf-lisp-lcaf-10.txt o Submitted June 2015. o Fix coauthor Job's contact information. B.7. Changes to draft-ietf-lisp-lcaf-09.txt o Submitted June 2015. o Fix IANA Considerations section to request a registry to allocate and track LCAF Type values. B.8. Changes to draft-ietf-lisp-lcaf-08.txt o Submitted April 2015. o Comment from Florin. The Application Data Type length field has a typo. The field should be labeled "12 + n" and not "8 + n". o Fix length fields in the sections titled "Using Recursive LISP Canonical Address Encodings", "Generic Database Mapping Lookups", and "Data Model Encoding". B.9. Changes to draft-ietf-lisp-lcaf-07.txt o Submitted December 2014. o Add a new LCAF Type called "Encapsulation Format" so decapsulating xTRs can inform encapsulating xTRs what data-plane encapsulations they support. B.10. Changes to draft-ietf-lisp-lcaf-06.txt o Submitted October 2014. o Make it clear how sorted RLOC records are done when LCAFs are used as the RLOC record. B.11. Changes to draft-ietf-lisp-lcaf-05.txt o Submitted May 2014. o Add a length field of the JSON payload that can be used for either binary or text encoding of JSON data. Farinacci, et al. Expires March 12, 2017 [Page 41] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 B.12. Changes to draft-ietf-lisp-lcaf-04.txt o Submitted January 2014. o Agreement among ELP implementors to have the AFI 16-bit field adjacent to the address. This will make the encoding consistent with all other LCAF type address encodings. B.13. Changes to draft-ietf-lisp-lcaf-03.txt o Submitted September 2013. o Updated references and author's affilations. o Added Instance-ID to the Multicast Info Type so there is relative ease in parsing (S,G) entries within a VPN. o Add port range encodings to the Application Data LCAF Type. o Add a new JSON LCAF Type. o Add Address Key/Value LCAF Type to allow attributes to be attached to an address. B.14. Changes to draft-ietf-lisp-lcaf-02.txt o Submitted March 2013. o Added new LCAF Type "Replication List Entry" to support LISP replication engineering use-cases. o Changed references to new LISP RFCs. B.15. Changes to draft-ietf-lisp-lcaf-01.txt o Submitted January 2013. o Change longitude range from 0-90 to 0-180 in section 4.4. o Added reference to WGS-84 in section 4.4. B.16. Changes to draft-ietf-lisp-lcaf-00.txt o Posted first working group draft August 2012. o This draft was renamed from draft-farinacci-lisp-lcaf-10.txt. Farinacci, et al. Expires March 12, 2017 [Page 42] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Authors' Addresses Dino Farinacci lispers.net San Jose, CA USA Email: farinacci@gmail.com Dave Meyer Brocade San Jose, CA USA Email: dmm@1-4-5.net Job Snijders NTT Communications Theodorus Majofskistraat 100 Amsterdam 1065 SZ NL Email: job@ntt.net Farinacci, et al. Expires March 12, 2017 [Page 43] --Apple-Mail=_F14C54DF-FC1E-47EB-B6F8-161931C27CC9 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_F14C54DF-FC1E-47EB-B6F8-161931C27CC9 Content-Disposition: attachment; filename=lcaf-rfcdiff.html Content-Type: text/html; name="lcaf-rfcdiff.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-lisp-lcaf-14.txt - = draft-ietf-lisp-lcaf-15.txt=20 =20 =20 =20 =20 =20 =20= = = = = =
< draft-ietf-lisp-lcaf-14.txt  =  draft-ietf-lisp-lcaf-15.txt >
=
Network Working = Group D. Farinacci = Network Working Group = D. Farinacci
Internet-Draft = lispers.net Internet-Draft = lispers.net
Intended status: = Experimental D. Meyer = Intended status: Experimental = D. Meyer
Expires: January 20, 2017 = Brocade Expires: March 12, 2017 = Brocade
= J. Snijders = J. Snijders
= NTT Communications = NTT Communications
= July = 19, 2016 = September = 8, 2016
=
= LISP Canonical Address Format (LCAF) = LISP Canonical Address Format (LCAF)
= draft-ietf-lisp-lcaf-14 = = draft-ietf-lisp-lcaf-15
=
Abstract = Abstract
=
This draft = defines a canonical address format encoding used in LISP = This draft defines a canonical address = format encoding used in LISP
control = messages and in the encoding of lookup keys for the LISP = control messages and in the encoding of = lookup keys for the LISP
Mapping = Database System. Mapping Database = System.
=
Requirements = Language Requirements Language
=
The key words = "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", = "SHALL", "SHALL NOT",
=
skipping to = change at = page 1, line 41 =C2=B6 = skipping to change at page 1, line 41 =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 = http://datatracker.ietf.org/drafts/current/. Drafts is at = http://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 January 20, = 2017. This Internet-Draft will = expire on March 12, 2017.
=
Copyright = Notice Copyright Notice
=
Copyright (c) = 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
= (http://trustee.ietf.org/license-info) in effect on the date of = (http://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
=
skipping to = change at = page 2, line 23 =C2=B6 = skipping to change at page 2, line 23 =C2=B6
=
1. = Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 3 1. Introduction . . . . . . . . = . . . . . . . . . . . . . . . . 3
2. Definition = of Terms . . . . . . . . . . . . . . . . . . . . . 4 2. Definition of Terms . . . . . . . . . . . . . . . = . . . . . . 4
3. LISP = Canonical Address Format Encodings . . . . . . . . . . . 5 = 3. LISP Canonical Address Format Encodings = . . . . . . . . . . . 5
4. LISP = Canonical Address Applications . . . . . . . . . . . . . 7 = 4. LISP Canonical Address Applications . . = . . . . . . . . . . . 7
4.1. = Segmentation using LISP . . . . . . . . . . . . . . . . . 7 = 4.1. Segmentation using LISP . . . . . . = . . . . . . . . . . . 7
4.2. = Carrying AS Numbers in the Mapping Database . . . . . . . 9 = 4.2. Carrying AS Numbers in the Mapping = Database . . . . . . . 9
4.3. = Assigning Geo Coordinates to Locator Addresses . . . . . 10 = 4.3. Assigning Geo Coordinates to Locator = Addresses . . . . . 10
4.4. NAT = Traversal Scenarios . . . . . . . . . . . . . . . . . 12 = 4.4. NAT Traversal Scenarios . . . . . . = . . . . . . . . . . . 12
4.5. = Multicast Group Membership Information . . . . . . . . . 14 = 4.5. Multicast Group Membership = Information . . . . . . . . . 14
4.6. = Traffic Engineering using Re-encapsulating Tunnels . . . 15 4.6. = Traffic Engineering using Re-encapsulating Tunnels . . . 16
4.7. = Storing Security Data in the Mapping Database . . . . . . 17 = 4.7. Storing Security Data in the Mapping = Database . . . . . . 17
4.8. = Source/Destination 2-Tuple Lookups . . . . . . . . . . . 18 4.8. = Source/Destination 2-Tuple Lookups . . . . . . . . . . . 19
4.9. = Replication List Entries for Multicast Forwarding . . . . 20 4.9. = Replication List Entries for Multicast Forwarding . . . . 21
4.10. = Applications for AFI List Type . . . . . . . . . . . . . 21 4.10. = Applications for AFI List Type . . . . . . . . . . . . . 22
4.10.1. = Binding IPv4 and IPv6 Addresses . . . . . . . . . . 21 = 4.10.1. Binding IPv4 and IPv6 Addresses . . . . . . . . . . 22
4.10.2. = Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . 22 = 4.10.2. Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . 23
4.10.3. = ASCII Names in the Mapping Database . . . . . . . . 23 = 4.10.3. ASCII Names in the Mapping Database . . . . . . . . 24
4.10.4. = Using Recursive LISP Canonical Address Encodings . . 24 = 4.10.4. Using Recursive LISP Canonical Address Encodings . . 25
4.10.5. = Compatibility Mode Use Case . . . . . . . . . . . . 25 = 4.10.5. Compatibility Mode Use Case . . . . . . . . . . . . 26
5. = Experimental LISP Canonical Address Applications . . . . . . 26 5. = Experimental LISP Canonical Address Applications . . . . . . 27
5.1. = Convey Application Specific Data . . . . . . . . . . . . 26 5.1. = Convey Application Specific Data . . . . . . . . . . . . 27
5.2. = Generic Database Mapping Lookups . . . . . . . . . . . . 27 5.2. = Generic Database Mapping Lookups . . . . . . . . . . . . 28
5.3. PETR = Admission Control Functionality . . . . . . . . . . 29 5.3. = PETR Admission Control Functionality . . . . . . . . . . 30
5.4. Data = Model Encoding . . . . . . . . . . . . . . . . . . . 30 5.4. = Data Model Encoding . . . . . . . . . . . . . . . . . . . 31
5.5. = Encoding Key/Value Address Pairs . . . . . . . . . . . . 31 5.5. = Encoding Key/Value Address Pairs . . . . . . . . . . . . 32
5.6. = Multiple Data-Planes . . . . . . . . . . . . . . . . . . 32 5.6. = Multiple Data-Planes . . . . . . . . . . . . . . . . . . 33
6. Security = Considerations . . . . . . . . . . . . . . . . . . . 34 6. = Security Considerations . . . . . . . . . . . . . . . . . . . 36
7. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 34 7. = IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
8. = References . . . . . . . . . . . . . . . . . . . . . . . . . 35 8. = References . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.1. = Normative References . . . . . . . . . . . . . . . . . . 35 8.1. = Normative References . . . . . . . . . . . . . . . . . . 37
8.2. = Informative References . . . . . . . . . . . . . . . . . 36 8.2. = Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 37 = Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 39
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 38 = Appendix B. Document Change Log . . . . . . . . . . . . . . . . 40
B.1. = Changes to draft-ietf-lisp-lcaf-14.txt . = . . . . . . . . 38 B.1. Changes to draft-ietf-lisp-lcaf-15.txt . . . . . . . . . = 40
B.2. = Changes to draft-ietf-lisp-lcaf-13.txt . = . . . . . . . . 38 B.2. Changes to draft-ietf-lisp-lcaf-14.txt . . . . . . . . . = 40
B.3. = Changes to draft-ietf-lisp-lcaf-12.txt . = . . . . . . . . 38 B.3. Changes to draft-ietf-lisp-lcaf-13.txt . . . . . . . . . = 40
B.4. = Changes to draft-ietf-lisp-lcaf-11.txt . = . . . . . . . . 38 B.4. Changes to draft-ietf-lisp-lcaf-12.txt . . . . . . . . . = 40
B.5. = Changes to draft-ietf-lisp-lcaf-10.txt . = . . . . . . . . 38 B.5. Changes to draft-ietf-lisp-lcaf-11.txt . . . . . . . . . = 40
B.6. = Changes to draft-ietf-lisp-lcaf-09.txt . = . . . . . . . . 39 B.6. Changes to draft-ietf-lisp-lcaf-10.txt . . . . . . . . . = 41
B.7. = Changes to draft-ietf-lisp-lcaf-08.txt . = . . . . . . . . 39 B.7. Changes to draft-ietf-lisp-lcaf-09.txt . . . . . . . . . = 41
B.8. = Changes to draft-ietf-lisp-lcaf-07.txt . = . . . . . . . . 39 B.8. Changes to draft-ietf-lisp-lcaf-08.txt . . . . . . . . . = 41
B.9. = Changes to draft-ietf-lisp-lcaf-06.txt . = . . . . . . . . 39 B.9. Changes to draft-ietf-lisp-lcaf-07.txt . . . . . . . . . = 41
B.10. = Changes to draft-ietf-lisp-lcaf-05.txt . = . . . . . . . . 39 B.10. Changes to draft-ietf-lisp-lcaf-06.txt . . . . . . . . . = 41
B.11. = Changes to draft-ietf-lisp-lcaf-04.txt . = . . . . . . . . 39 B.11. Changes to draft-ietf-lisp-lcaf-05.txt . . . . . . . . . = 41
B.12. = Changes to draft-ietf-lisp-lcaf-03.txt . = . . . . . . . . 40 B.12. Changes to draft-ietf-lisp-lcaf-04.txt . . . . . . . . . = 42
B.13. = Changes to draft-ietf-lisp-lcaf-02.txt . = . . . . . . . . 40 B.13. Changes to draft-ietf-lisp-lcaf-03.txt . . . . . . . . . = 42
B.14. = Changes to draft-ietf-lisp-lcaf-01.txt . = . . . . . . . . 40 B.14. Changes to draft-ietf-lisp-lcaf-02.txt . . . . . . . . . = 42
B.15. = Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . 40 B.15. = Changes to draft-ietf-lisp-lcaf-01.txt . . . . . = . . . . 42
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 B.16. Changes to = draft-ietf-lisp-lcaf-00.txt . . . . . . . . . 42
= Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 43
=
1. = Introduction 1. Introduction
=
The LISP = architecture and protocols [RFC6830] introduces two new = The LISP architecture and protocols = [RFC6830] introduces two new
numbering = spaces, Endpoint Identifiers (EIDs) and Routing Locators = numbering spaces, Endpoint Identifiers = (EIDs) and Routing Locators
(RLOCs). To = provide flexibility for current and future applications, = (RLOCs). To provide flexibility for current = and future applications,
these values = can be encoded in LISP control messages using a general = these values can be encoded in LISP control = messages using a general
syntax that = includes Address Family Identifier (AFI), length, and syntax that includes Address Family Identifier (AFI), = length, and
value = fields. value fields.
=
=
skipping to = change at = page 4, line 28 =C2=B6 = skipping to change at page 4, line 28 =C2=B6
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
This document = describes the currently-defined AFIs the LISP protocol This document describes the currently-defined AFIs = the LISP protocol
uses along = with their encodings and introduces the LISP Canonical uses along with their encodings and introduces the = LISP Canonical
Address Format = (LCAF) that can be used to define the LISP-specific Address Format (LCAF) that can be used to define the = LISP-specific
encodings for = arbitrary AFI values. encodings for = arbitrary AFI values.
=
2. Definition of = Terms 2. Definition of Terms
=
Address Family = Identifier (AFI): a term used to describe an address Address Family Identifier (AFI): a term used to = describe an address
encoding = in a packet. There is an address family = currently encoding in a = packet. Address families are defined for = IPv4 and
defined = for IPv4 or IPv6 addresses. See [AFI] and = [RFC3232] for = IPv6. See [AFI] and [RFC3232] for details. The reserved = AFI
details. = The reserved AFI value of 0 is used in this value of 0 is used in this specification to = indicate an
= specification to indicate an unspecified encoded address where = the unspecified encoded address = where the length of the address is 0
length of = the address is 0 bytes following the 16-bit AFI value of = bytes following the 16-bit AFI value of = 0.
= 0.
=
Unspecified = Address Format: Unspecified Address = Format:
=
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
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D 0 | <nothing follows AFI=3D0> | = | AFI =3D 0 | = <nothing follows AFI=3D0> |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Endpoint ID = (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value = Endpoint ID (EID): a 32-bit (for IPv4) or = 128-bit (for IPv6) value
=
skipping to = change at = page 6, line 34 =C2=B6 = skipping to change at page 6, line 34 =C2=B6
Type 12: = Source/Dest Key Type Type 12: = Source/Dest Key Type
=
Type 13: = Replication List Entry Type Type = 13: Replication List Entry Type
=
Type 14: = JSON Data Model Type Type 14: = JSON Data Model Type
=
Type 15: = Key/Value Address Pair Type Type = 15: Key/Value Address Pair Type
=
Type 16: = Encapsulation Format Type Type = 16: Encapsulation Format Type
=
Rsvd2: this = 8-bit field is reserved for future use and MUST be Rsvd2: this LCAF Type = dependent 8-bit field is reserved for future
= transmitted as 0 and ignored on receipt. use and MUST be transmitted as 0 and ignored on = receipt. See
= specific LCAF = Type for specific bits not reserved.
=
Length: this = 16-bit field is in units of bytes and covers all of the = Length: this 16-bit field is in units of = bytes and covers all of the
LISP = Canonical Address payload, starting and including the byte = LISP Canonical Address payload, starting = and including the byte
after the = Length field. So any LCAF encoded address will have a after the Length field. So any LCAF encoded = address will have a
minimum = length of 8 bytes when the Length field is 0. The 8 bytes = minimum length of 8 bytes when the Length = field is 0. The 8 bytes
include the = AFI, Flags, Type, Reserved, and Length fields. When include the AFI, Flags, Type, Reserved, and Length = fields. When
the AFI is = not next to encoded address in a control message, then the AFI is not next to encoded address in a = control message, then
the encoded = address will have a minimum length of 6 bytes when the the encoded address will have a minimum length of = 6 bytes when the
Length = field is 0. The 6 bytes include the Flags, Type, Reserved, = Length field is 0. The 6 bytes include = the Flags, Type, Reserved,
and Length = fields. and Length = fields.
=
[RFC6830] = states RLOC records are sorted when encoded in control [RFC6830] states RLOC records are sorted when encoded = in control
messages so = the locator-set has consistent order across all xTRs for = messages so the locator-set has consistent = order across all xTRs for
a given EID. = The sort order is based on sort-key {afi, RLOC- a given EID. The sort order is based on sort-key = {afi, RLOC-
address}. When = an RLOC is LCAF encoded, the sort-key is {afi, LCAF- address}. When an RLOC is LCAF encoded, the sort-key = is {afi, LCAF-
Type}. = Therefore, when a locator-set has a mix of AFI records and = Type}. Therefore, when a locator-set has a = mix of AFI records and
LCAF = records, all LCAF records will appear after all = the AFI records. LCAF = records, they are ordered from smallest to = largest AFI value.
=
4. LISP = Canonical Address Applications 4. = LISP Canonical Address Applications
=
4.1. = Segmentation using LISP 4.1. = Segmentation using LISP
=
When multiple = organizations inside of a LISP site are using private When multiple organizations inside of a LISP site are = using private
addresses = [RFC1918] as EID-prefixes, their address spaces must remain = addresses [RFC1918] as EID-prefixes, their = address spaces must remain
segregated due = to possible address duplication. An Instance ID in segregated due to possible address duplication. An = Instance ID in
the address = encoding can aid in making the entire AFI based address = the address encoding can aid in making the = entire AFI based address
= unique. unique.
=
skipping to = change at = page 13, line 12 =C2=B6 = skipping to change at page 13, line = 12 =C2=B6
MS RLOC = Address: this is the address of the Map-Server used in the = MS RLOC Address: this is the address of the = Map-Server used in the
destination = RLOC of a packet that has flowed through a NAT device. destination RLOC of a packet that has flowed = through a NAT device.
=
Private ETR = RLOC Address: this is an address known to be a private = Private ETR RLOC Address: this is an = address known to be a private
address = inserted in this LCAF format by a LISP router that resides = address inserted in this LCAF format by a = LISP router that resides
on the = private side of a NAT device. on = the private side of a NAT device.
=
RTR RLOC = Address: this is an encapsulation address used by an ITR or = RTR RLOC Address: this is an encapsulation = address used by an ITR or
PITR which = resides behind a NAT device. This address is known to PITR which resides behind a NAT device. This = address is known to
have state = in a NAT device so packets can flow from it to the LISP = have state in a NAT device so packets can = flow from it to the LISP
ETR = behind the NAT. There can be one or more NAT Tunnel Router = ETR behind the NAT. There can be one or = more NAT Reencapsulating
(NTR) [I-D.ermagan-lisp-nat-traversal] addresses = supplied in these Tunnel Router = (RTR) [I-D.ermagan-lisp-nat-traversal] = addresses
set of = fields. The number of NTRs encoded is = determined by the supplied in = these set of fields. The number of RTRs = encoded is
LCAF = length field. When there are no NTRs = supplied, the NTR determined by the LCAF length field. When there = are no RTRs
fields = can be omitted and reflected by the LCAF length field or an = supplied, the RTR fields can be omitted and reflected by the = LCAF
AFI of 0 = can be used to indicate zero NTRs = encoded. length field or an AFI = of 0 can be used to indicate zero RTRs
= encoded.
=
Usage: This = encoding can be used in Info-Request and Info-Reply Usage: This encoding can be used in Info-Request and = Info-Reply
messages. The = mapping system does not store this information. The messages. The mapping system does not store this = information. The
information is = used by an xTR and Map-Server to convey private and information is used by an xTR and Map-Server to = convey private and
public address = information when traversing NAT and firewall devices. public address information when traversing NAT and = firewall devices.
=
4.5. Multicast = Group Membership Information 4.5. = Multicast Group Membership Information
=
Multicast = group information can be published in the mapping database. = Multicast group information can be published = in the mapping database.
So a lookup on = an group address EID can return a replication list of So a lookup on an group address EID can return a = replication list of
=
skipping to = change at = page 15, line 11 =C2=B6 = skipping to change at page 15, line = 11 =C2=B6
of = (Instance-ID, S-prefix, G-prefix). = of (Instance-ID, S-prefix, G-prefix).
=
Source = MaskLen: the mask length of the source prefix that follows. = Source MaskLen: the mask length of the = source prefix that follows.
=
Group MaskLen: = the mask length of the group prefix that follows. Group MaskLen: the mask length of the group prefix = that follows.
=
AFI =3D x: x = can be any AFI value from [AFI]. When a specific AFI has = AFI =3D x: x can be any AFI value from = [AFI]. When a specific AFI has
its own = encoding of a multicast address, this field must be either = its own encoding of a multicast address, = this field must be either
a group = address or a broadcast address. = a group address or a broadcast address.
=
= Source/Subnet = Address is the source address or prefix for encoding a
= (S,G) multicast = entry.
=
= Group Address is = the group address or group prefix for encoding
= (S,G) or (*,G) = multicast entries.
= =
Usage: This = encoding can be used in EID records in Map-Requests, Map- = Usage: This encoding can be used in EID = records in Map-Requests, Map-
Replies, = Map-Registers, and Map-Notify messages. When LISP-DDT Replies, Map-Registers, and Map-Notify messages. = When LISP-DDT
= [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, = extended [I-D.ietf-lisp-ddt] is = used as the mapping system mechanism, extended
EIDs are used = in Map-Referral messages. EIDs are = used in Map-Referral messages.
=
4.6. Traffic = Engineering using Re-encapsulating Tunnels 4.6. Traffic Engineering using Re-encapsulating = Tunnels
=
For a given = EID lookup into the mapping database, this LCAF format For a given EID lookup into the mapping database, = this LCAF format
can be = returned to provide a list of locators in an explicit re- = can be returned to provide a list of = locators in an explicit re-
encapsulation = path. See [I-D.farinacci-lisp-te] for details. encapsulation path. See [I-D.farinacci-lisp-te] for = details.
=
skipping to = change at = page 16, line 25 =C2=B6 = skipping to change at page 16, line = 31 =C2=B6
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = Reencap Hop 1 ... | | Reencap Hop 1 ... = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = Rsvd3 |L|P|S| AFI =3D x | = | Rsvd3 |L|P|S| = AFI =3D x |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = Reencap Hop k ... | | Reencap Hop k ... = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Length value = n: length in bytes of fields that follow. Length value n: length in bytes of fields that = follow.
=
= Rsvd3: this field = is reserved for future use and MUST be transmitted
= as 0 and ignored = on receipt.
= =
Lookup bit = (L): this is the Lookup bit used to indicate to the user = Lookup bit (L): this is the Lookup bit used = to indicate to the user
of the ELP = to not use this address for encapsulation but to look of the ELP to not use this address for = encapsulation but to look
it up in = the mapping database system to obtain an encapsulating it up in the mapping database system to obtain an = encapsulating
RLOC = address. RLOC address.
=
RLOC-Probe bit = (P): this is the RLOC-probe bit which means the RLOC-Probe bit (P): this is the RLOC-probe bit which = means the
Reencap Hop = allows RLOC-probe messages to be sent to it. When the Reencap Hop allows RLOC-probe messages to be sent = to it. When the
R-bit is = set to 0, RLOC-probes must not be sent. When a Reencap = R-bit is set to 0, RLOC-probes must not = be sent. When a Reencap
Hop is an = anycast address then multiple physical Reencap Hops are = Hop is an anycast address then multiple = physical Reencap Hops are
using the = same RLOC address. In this case, RLOC-probes are not using the same RLOC address. In this case, = RLOC-probes are not
=
skipping to = change at = page 17, line 35 =C2=B6 = skipping to change at page 18, line = 29 =C2=B6
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D x | Locator Address ... | | AFI =3D x | Locator = Address ... |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Length value = n: length in bytes of fields that start with the Key Length value n: length in bytes of fields that start = with the Key
Material = field. Material field.
=
Key Count: = the Key Count field declares the number of Key sections = Key Count: the Key Count field declares the = number of Key sections
included in = this LCAF. included in this = LCAF.
=
= Rsvd3: this field = is reserved for future use and MUST be transmitted
= as 0 and ignored = on receipt.
= =
Key Algorithm: = the Algorithm field identifies the key's Key Algorithm: the Algorithm field identifies the = key's
= cryptographic algorithm and specifies the format of the Public = Key cryptographic algorithm and = specifies the format of the Public Key
= field. field.
=
= Rsvd4: this field = is reserved for future use and MUST be transmitted
= as 0 and ignored = on receipt.
= =
R bit: this = is the revoke bit and, if set, it specifies that this R bit: this is the revoke bit and, if set, it = specifies that this
Key is = being Revoked. Key is being = Revoked.
=
Key Length: = this field determines the length in bytes of the Key Key Length: this field determines the length in = bytes of the Key
Material = field. Material field.
=
Key Material: = the Key Material field stores the key material. The Key Material: the Key Material field stores the key = material. The
format of = the key material stored depends on the Key Algorithm format of the key material stored depends on the = Key Algorithm
= field. field.
=
=
skipping = to change at page 28, line = 5 =C2=B6 = skipping to change at page 29, line = 5 =C2=B6
| Type =3D 6 = | Rsvd2 | 3 + n | | Type =3D 6 | Rsvd2 | 3 + n = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Field = Num | Key Wildcard Fields | Key . . . | | Key Field Num | Key Wildcard Fields | = Key . . . |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = . . . Key | | . . . Key = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Length value = n: length in bytes of the type's payload. The value n = Length value n: length in bytes of the = type's payload. The value n
is the = number of bytes that follow this Length field. is the number of bytes that follow this Length = field.
=
Key Field = Num: the number of fields (minus 1) the = key can be broken Key Field Num: the value of = this field is the the number of "Key"
up into. = The width of the fields are fixed length. = So for a key = sub-fields minus 1, the "Key" = field can be broken up into. So = if
size of 8 = bytes, with a Key Field Num of 4 allows 4 = fields of 2 this field has a value of = 0, there is 1 sub-field in the "Key".
bytes in = length. Allowing for a reasonable number of 16 field The width of the sub-fields are fixed length. So for a key = size
= separators, valid values range from 0 to 15. of 8 bytes, with a Key Field Num of 3, allows 4 sub-fields of 2
= bytes each = in length. Allowing for a reasonable number of 16 sub-
= field separators, valid values range = from 0 to 15.
=
Key Wildcard = Fields: describes which fields in the key are not used = Key Wildcard Fields: describes which fields = in the key are not used
as part of = the key lookup. This wildcard encoding is a bitfield. as part of the key lookup. This wildcard encoding = is a bitfield.
Each bit is = a don't-care bit for a corresponding field in the key. Each bit is a don't-care bit for a corresponding = field in the key.
Bit 0 (the = low-order bit) in this bitfield corresponds the first Bit 0 (the low-order bit) in this bitfield = corresponds the first
field, = right-justified in the key, bit 1 the = second field, and so field, = the low-order field in the key, bit 1 the = second field, and
on. When = a bit is set in the bitfield it is a don't-care bit and = so on. When a bit is set in the = bitfield it is a don't-care bit
should = not be considered as part of the database lookup. When the = and should not be considered as part of = the database lookup. When
entire = 16-bits is set to 0, then all bits of the key are used for = the entire 16-bits is set to 0, then all = bits of the key are used
the = database lookup. for the = database lookup.
=
Key: the = variable length key used to do a LISP Database Mapping Key: the variable length key used to do a LISP = Database Mapping
lookup. = The length of the key is the value n (shown = above) minus lookup. = The length of the key is the value n (as shown = above).
3.
=
Usage: This is = an experimental type where the usage has not been Usage: This is an experimental type where the usage = has not been
defined = yet. defined yet.
=
5.3. PETR = Admission Control Functionality 5.3. = PETR Admission Control Functionality
=
When a public = PETR device wants to verify who is encapsulating to it, = When a public PETR device wants to verify = who is encapsulating to it,
it can check = for a specific nonce value in the LISP encapsulated it can check for a specific nonce value in the LISP = encapsulated
packet. To = convey the nonce to admitted ITRs or PITRs, this LCAF packet. To convey the nonce to admitted ITRs or = PITRs, this LCAF
format is used = in a Map-Register or Map-Reply locator-record. format is used in a Map-Register or Map-Reply = locator-record.
=
skipping = to change at page 30, line = 24 =C2=B6 = skipping to change at page 31, line = 24 =C2=B6
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D 16387 | Rsvd1 | Flags | = | AFI =3D 16387 | = Rsvd1 | Flags |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type =3D = 14 | Rsvd2 |B| 2 + n | | Type =3D 14 | Rsvd2 |B| 2 + n = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = JSON length | JSON binary/text encoding ... | | JSON length | JSON binary/text = encoding ... |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D x | Optional Address ... | | AFI =3D x | Optional = Address ... |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Length value = n: length in bytes of fields that follow. = Length value n: length in bytes of the = fields that follow the "JSON
= length" = field.
=
Rsvd{1,2}: = must be set to zero and ignore on receipt. Rsvd{1,2}: must be set to zero and ignore on = receipt.
=
B bit: = indicates that the JSON field is binary encoded according to = B bit: indicates that the JSON field is = binary encoded according to
= [JSON-BINARY] when the bit is set to 1. Otherwise the encoding = is [JSON-BINARY] when the bit is = set to 1. Otherwise the encoding is
based on = text encoding according to [RFC7159]. = based on text encoding according to [RFC7159].
=
JSON length: = length in octets of the following 'JSON binary/text JSON length: length in octets of the following 'JSON = binary/text
encoding' = field. encoding' field.
=
=
skipping = to change at page 31, line = 26 =C2=B6 = skipping to change at page 32, line = 26 =C2=B6
=
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
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D 16387 | Rsvd1 | Flags | = | AFI =3D 16387 | = Rsvd1 | Flags |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type =3D = 15 | Rsvd2 | n | | Type =3D 15 | Rsvd2 | n = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D x | Address as Key ... | | AFI =3D x | Address as = Key ... |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D x | Address as = Value ... | | AFI = =3D y | Address as Value = ... |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Length value = n: length in bytes of fields that follow. Length value n: length in bytes of fields that = follow.
=
Rsvd{1,2}: = must be set to zero and ignore on receipt. Rsvd{1,2}: must be set to zero and ignore on = receipt.
=
AFI =3D x: = x can be any AFI value from [AFI]. A specific AFI has = its AFI =3D x: x is the "Address as Key" AFI that can have any value from
own = encoding of either a unicast or multicast locator address. = [AFI]. A specific AFI has its own = encoding of either a unicast or
All = RTR/ETR entries for the same level should be combined together = multicast locator address. All RTR/ETR = entries for the same level
by a = Map-Server to avoid searching through the entire multi-level = should be combined together by a = Map-Server to avoid searching
list of = locator entries in a Map-Reply = message. through the entire = multi-level list of locator entries in a Map-
= Reply = message.
=
Address as = Key: this AFI encoded address will be attached with the = Address as Key: this AFI encoded address = will be attached with the
attributes = encoded in "Address as Value" which follows this field. = attributes encoded in "Address as Value" = which follows this field.
=
= AFI =3D y: y is the = "Address of Value" AFI that can have any value
= from [AFI]. A = specific AFI has its own encoding of either a
= unicast or = multicast locator address. All RTR/ETR entries for the
= same level should = be combined together by a Map-Server to avoid
= searching through = the entire multi-level list of locator entries
= in a Map-Reply = message.
= =
Address as = Value: this AFI encoded address will be the attribute Address as Value: this AFI encoded address will be = the attribute
address = that goes along with "Address as Key" which precedes this = address that goes along with "Address as = Key" which precedes this
= field. field.
=
Usage: This is = an experimental type where the usage has not been Usage: This is an experimental type where the usage = has not been
defined = yet. defined yet.
=
5.6. Multiple = Data-Planes 5.6. Multiple = Data-Planes
=
Overlays are = becoming popular in many parts of the network which have = Overlays are becoming popular in many parts = of the network which have
=
skipping = to change at page 36, line = 19 =C2=B6 = skipping to change at page 38, line = 19 =C2=B6
=
= [I-D.coras-lisp-re] = [I-D.coras-lisp-re]
= Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., Coras, F., Cabellos-Aparicio, A., = Domingo-Pascual, J.,
= Maino, F., and D. Farinacci, "LISP Replication Maino, F., and D. Farinacci, "LISP = Replication
= Engineering", draft-coras-lisp-re-08 (work in progress), = Engineering", = draft-coras-lisp-re-08 (work in progress),
= November 2015. November = 2015.
=
= [I-D.ermagan-lisp-nat-traversal] = [I-D.ermagan-lisp-nat-traversal]
= Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, = Ermagan, V., Farinacci, D., = Lewis, D., Skriver, J., Maino,
F., = and C. White, "NAT traversal for LISP", draft-ermagan- F., and C. White, "NAT traversal for = LISP", draft-ermagan-
= lisp-nat-traversal-10 (work in progress), = February 2016. = lisp-nat-traversal-11 (work in progress), = August 2016.
=
= [I-D.farinacci-lisp-te] = [I-D.farinacci-lisp-te]
= Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic Farinacci, D., Kowal, M., and P. Lahiri, = "LISP Traffic
= Engineering Use-Cases", draft-farinacci-lisp-te-10 (work = Engineering Use-Cases", draft-farinacci-lisp-te-11 (work
= in progress), March 2016. = in progress), September 2016.
=
= [I-D.gross-geneve] = [I-D.gross-geneve]
= Gross, J., Sridhar, T., Garg, P., Wright, C., Ganga, I., = Gross, J., Sridhar, T., Garg, P., = Wright, C., Ganga, I.,
= Agarwal, P., Duda, K., Dutt, D., and J. Hudson, "Geneve: = Agarwal, P., Duda, K., Dutt, D., = and J. Hudson, "Geneve:
= Generic Network Virtualization Encapsulation", draft- Generic Network Virtualization = Encapsulation", draft-
= gross-geneve-02 (work in progress), October 2014. gross-geneve-02 (work in progress), = October 2014.
=
= [I-D.herbert-gue] = [I-D.herbert-gue]
= Herbert, T., Yong, L., and O. Zia, "Generic UDP Herbert, T., Yong, L., and O. Zia, = "Generic UDP
= Encapsulation", draft-herbert-gue-03 (work in progress), = Encapsulation", = draft-herbert-gue-03 (work in progress),
=
skipping = to change at page 38, line = 9 =C2=B6 = skipping to change at page 40, line = 9 =C2=B6
Thanks goes to = Michiel Blokzijl and Alberto Rodriguez-Natal for Thanks goes to Michiel Blokzijl and Alberto = Rodriguez-Natal for
suggesting new = LCAF types. suggesting new LCAF = types.
=
Thanks also = goes to Terry Manderson for assistance obtaining a LISP = Thanks also goes to Terry Manderson for = assistance obtaining a LISP
AFI value from = IANA. AFI value from IANA.
=
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-lcaf-14.txt B.1. = Changes to draft-ietf-lisp-lcaf-15.txt
=
= o Submitted = September 2016.
=
= o Addressed = comments from Routing Directorate reviewer Stig Venass.
=
= B.2. Changes to = draft-ietf-lisp-lcaf-14.txt
=
o Submitted = July 2016. o Submitted July = 2016.
=
o Fix IDnits = errors and comments from Luigi Iannone, document o Fix IDnits errors and comments from Luigi Iannone, = document
= shepherd. shepherd.
=
B.2. Changes to = draft-ietf-lisp-lcaf-13.txt B.3. Changes to = draft-ietf-lisp-lcaf-13.txt
=
o Submitted = May 2016. o Submitted May = 2016.
=
o Explain the = Instance-ID LCAF Type is 32-bits in length and the o Explain the Instance-ID LCAF Type is 32-bits in = length and the
Instance-ID = field in the LISP encapsulation header is 24-bits. Instance-ID field in the LISP encapsulation header = is 24-bits.
=
B.3. Changes to = draft-ietf-lisp-lcaf-12.txt B.4. Changes to = draft-ietf-lisp-lcaf-12.txt
=
o Submitted = March 2016. o Submitted March = 2016.
=
o Updated = references and document timer. o = Updated references and document timer.
=
o Removed the = R, J, and L bits from the Multicast Info Type LCAF o Removed the R, J, and L bits from the Multicast = Info Type LCAF
since = working group decided to not go forward with draft- since working group decided to not go forward with = draft-
= farinacci-lisp-mr-signaling-03.txt in favor of draft- = ietf-lisp- = farinacci-lisp-mr-signaling-03.txt in favor of draft- ietf-lisp-
= signal-free-00.txt. = signal-free-00.txt.
=
B.4. Changes to = draft-ietf-lisp-lcaf-11.txt B.5. Changes to = draft-ietf-lisp-lcaf-11.txt
=
o Submitted = September 2015. o Submitted = September 2015.
=
o Reflecting = comments from Prague LISP working group. o Reflecting comments from Prague LISP working = group.
=
o Readying = document for a LISP LCAF registry, RFC publication, and = o Readying document for a LISP LCAF = registry, RFC publication, and
for new = use-cases that will be defined in the new charter. for new use-cases that will be defined in the new = charter.
=
B.5. Changes to = draft-ietf-lisp-lcaf-10.txt B.6. Changes to = draft-ietf-lisp-lcaf-10.txt
=
o Submitted = June 2015. o Submitted June = 2015.
=
o Fix = coauthor Job's contact information. = o Fix coauthor Job's contact information.
=
B.6. Changes to = draft-ietf-lisp-lcaf-09.txt B.7. Changes to = draft-ietf-lisp-lcaf-09.txt
=
o Submitted = June 2015. o Submitted June = 2015.
=
o Fix IANA = Considerations section to request a registry to allocate = o Fix IANA Considerations section to = request a registry to allocate
and track = LCAF Type values. and track LCAF = Type values.
=
B.7. Changes to = draft-ietf-lisp-lcaf-08.txt B.8. Changes to = draft-ietf-lisp-lcaf-08.txt
=
o Submitted = April 2015. o Submitted April = 2015.
=
o Comment = from Florin. The Application Data Type length field has a = o Comment from Florin. The Application = Data Type length field has a
typo. The = field should be labeled "12 + n" and not "8 + n". typo. The field should be labeled "12 + n" and = not "8 + n".
=
o Fix length = fields in the sections titled "Using Recursive LISP o Fix length fields in the sections titled "Using = Recursive LISP
Canonical = Address Encodings", "Generic Database Mapping Lookups", = Canonical Address Encodings", "Generic = Database Mapping Lookups",
and "Data = Model Encoding". and "Data Model = Encoding".
=
B.8. Changes to = draft-ietf-lisp-lcaf-07.txt B.9. Changes to = draft-ietf-lisp-lcaf-07.txt
=
o Submitted = December 2014. o Submitted = December 2014.
=
o Add a new = LCAF Type called "Encapsulation Format" so decapsulating = o Add a new LCAF Type called "Encapsulation = Format" so decapsulating
xTRs can = inform encapsulating xTRs what data-plane encapsulations = xTRs can inform encapsulating xTRs what = data-plane encapsulations
they = support. they support.
=
B.9. Changes to = draft-ietf-lisp-lcaf-06.txt B.10. Changes to = draft-ietf-lisp-lcaf-06.txt
=
o Submitted = October 2014. o Submitted October = 2014.
=
o Make it = clear how sorted RLOC records are done when LCAFs are used = o Make it clear how sorted RLOC records are = done when LCAFs are used
as the RLOC = record. as the RLOC = record.
=
B.10. Changes to = draft-ietf-lisp-lcaf-05.txt B.11. Changes to = draft-ietf-lisp-lcaf-05.txt
=
o Submitted = May 2014. o Submitted May = 2014.
=
o Add a = length field of the JSON payload that can be used for either = o Add a length field of the JSON payload = that can be used for either
binary or = text encoding of JSON data. = binary or text encoding of JSON data.
=
B.11. Changes to = draft-ietf-lisp-lcaf-04.txt B.12. Changes to = draft-ietf-lisp-lcaf-04.txt
=
o Submitted = January 2014. o Submitted January = 2014.
=
o Agreement = among ELP implementors to have the AFI 16-bit field o Agreement among ELP implementors to have the AFI = 16-bit field
adjacent to = the address. This will make the encoding consistent adjacent to the address. This will make the = encoding consistent
with all = other LCAF type address encodings. = with all other LCAF type address encodings.
=
B.12. Changes to = draft-ietf-lisp-lcaf-03.txt B.13. Changes to = draft-ietf-lisp-lcaf-03.txt
=
o Submitted = September 2013. o Submitted = September 2013.
=
o Updated = references and author's affilations. = o Updated references and author's affilations.
=
o Added = Instance-ID to the Multicast Info Type so there is relative = o Added Instance-ID to the Multicast Info = Type so there is relative
ease in = parsing (S,G) entries within a VPN. = ease in parsing (S,G) entries within a VPN.
=
o Add port = range encodings to the Application Data LCAF Type. o Add port range encodings to the Application Data = LCAF Type.
=
o Add a new = JSON LCAF Type. o Add a new JSON = LCAF Type.
=
o Add Address = Key/Value LCAF Type to allow attributes to be attached o Add Address Key/Value LCAF Type to allow = attributes to be attached
to an = address. to an address.
=
B.13. Changes to = draft-ietf-lisp-lcaf-02.txt B.14. Changes to = draft-ietf-lisp-lcaf-02.txt
=
o Submitted = March 2013. o Submitted March = 2013.
=
o Added new = LCAF Type "Replication List Entry" to support LISP o Added new LCAF Type "Replication List Entry" to = support LISP
replication = engineering use-cases. = replication engineering use-cases.
=
o Changed = references to new LISP RFCs. o = Changed references to new LISP RFCs.
=
B.14. Changes to = draft-ietf-lisp-lcaf-01.txt B.15. Changes to = draft-ietf-lisp-lcaf-01.txt
=
o Submitted = January 2013. o Submitted January = 2013.
=
o Change = longitude range from 0-90 to 0-180 in section 4.4. o Change longitude range from 0-90 to 0-180 in = section 4.4.
=
o Added = reference to WGS-84 in section 4.4. = o Added reference to WGS-84 in section 4.4.
=
B.15. Changes to = draft-ietf-lisp-lcaf-00.txt B.16. Changes to = draft-ietf-lisp-lcaf-00.txt
=
o Posted = first working group draft August 2012. = o Posted first working group draft August 2012.
=
o This draft = was renamed from draft-farinacci-lisp-lcaf-10.txt. o This draft was renamed from = draft-farinacci-lisp-lcaf-10.txt.
=
Authors' = Addresses Authors' Addresses
=
Dino = Farinacci Dino Farinacci
= lispers.net lispers.net
San Jose, = CA San Jose, CA
 End of changes. 38 change blocks. 
95 lines changed or = deleted 128 lines changed or = added

This = html diff was produced by rfcdiff 1.45. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20 = --Apple-Mail=_F14C54DF-FC1E-47EB-B6F8-161931C27CC9 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_F14C54DF-FC1E-47EB-B6F8-161931C27CC9-- From nobody Fri Sep 9 16:15:23 2016 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 D928212B028 for ; Fri, 9 Sep 2016 16:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=venaas-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 a3dmoN53yKqG for ; Fri, 9 Sep 2016 16:15:20 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D492412B041 for ; Fri, 9 Sep 2016 16:15:17 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id l131so53906953lfl.2 for ; Fri, 09 Sep 2016 16:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=e+VjUqgsVGCpJnnAWCvrL7l8RoM35oSKHIZ7Y+rnExc=; b=zFITBfVPbsj2busSoeUw693vBm97K/RuUZjFqbJnU7wqN/3L2Chc9joNUd+tF0+gBI veuqreaidMGz7usajw++n8zGgnMrCgSoIuPJyyfQuJTfJj2IiZ1rcyiQdCMg98QLz7bn bEmgSvtfbLD5IkI/TjR95+hE6K3LJoxMCKLIQlePo3qouPt1EPvDe44VU+PjlK3oKnrL Cw/8Fol9M8owMC7Mbtd/y9ReikypzlT0nJlj6xXmp4iWoW9iXAPBy6rTvcKPRk92TTLE XsSHtU3LGaLP2r7cZk2xxpT/7T1MBKFGxJYKcdUl+Q0Hz6wbEv7XFZ6aWhtThdkw0hkB D8Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=e+VjUqgsVGCpJnnAWCvrL7l8RoM35oSKHIZ7Y+rnExc=; b=Q7GEw6sj8bxeJkAuHlKk8Q1dSvxkrpS0Vck8u8EtzVxh+1ZyuyKLe6YSXWObfPwul1 gvJKCGM9CxONLU0hxJ+zSIwY36rZHBKa31sb4W0HRtUO0TM+aMJkM/GKyD4j3Zqi2Qfy iHS1cSLfyCPA0w9moxcRhAkLisbglK01OfHOxQwslKsNbzFZgr4zq//N0gFyqBl8w0a8 s1SAKOZvlT8j2Lh2zt38vMcUO6Jhyaztuu8Twx8n03yM/MBqtqJvole5CvKdays/yE57 A4UD5F79mus/Aruti+B4NDKTgbi6xDDXQ7MUiVtaH83FeRpvY51wSpMF6AZgqS7X1ksE DNZA== X-Gm-Message-State: AE9vXwMsNWhFGW0pAAS8kDCzjuKT+zKfqlJiM9ZEkD5gPjXNcAhkhTpoQXBhJGl3bzRDbyhIxXTQuEI7iCGQ2g== X-Received: by 10.25.29.85 with SMTP id d82mr2101062lfd.60.1473462915703; Fri, 09 Sep 2016 16:15:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.28.15 with HTTP; Fri, 9 Sep 2016 16:15:14 -0700 (PDT) In-Reply-To: <551BDE7B-6BA3-4336-B92A-395FBE4A571D@gmail.com> References: <551BDE7B-6BA3-4336-B92A-395FBE4A571D@gmail.com> From: Stig Venaas Date: Fri, 9 Sep 2016 16:15:14 -0700 Message-ID: To: Dino Farinacci Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, LISP mailing list list , draft-ietf-lisp-lcaf.all@ietf.org Subject: Re: [lisp] RtgDir review: draft-ietf-lisp-lcaf-14.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 09 Sep 2016 23:15:22 -0000 Hi On Thu, Sep 8, 2016 at 2:02 PM, Dino Farinacci wrote: >> Document: draft-ietf-lisp-lcaf-14.txt >> Reviewer: Stig Venaas >> Review Date: 2016-09-07 >> IETF LC End Date: >> Intended Status: Experimental > > Thanks Stig for your comments. See responses below. As well as a new vers= ion -15 not submitted yet but for your quick review. Also find a lcaf-rfcdi= ff.html file for easy diff viewing. Thanks. I have some comments inline. >> Summary: >> I have some minor concerns about this document that I think should be >> resolved before publication. >> >> The draft is almost ready but there are several places where the text >> is a bit unclear, > > No problem. This document has had a long history and many opinions relate= d to it has come and gone but we tried to reflect everyone=E2=80=99s point = of view. > >> In section 1 I find this sentence a bit misleading since [AFI] doesn't >> talk about the formatting. >> >> Currently defined AFIs include IPv4 and IPv6 addresses, which are >> formatted according to code-points assigned in [AFI] as follows: >> >> Is the formatting shown here for AFI 1 and 2 defined in another >> document? It would be good to have a reference. If it is introduced >> in this document, then it should not be in the introduction. > > No it is not shown in any document. All the AFI document says is that a 1= 6-bit AFI value of 1 means an IP address follows. That means 4 bytes of add= ress. And 16 for IPv6 when AFI is 2. > > As you can see the reference to the AFI document is at the end of the sen= tence. > >> In section 2, first paragraph it says: >> There is an address family currently defined for IPv4 or IPv6 >> addresses. >> >> It would be better to say that address families are defined for IPv4 >> and IPv6 addresses. > > Changed. > >> In section 3 we have this paragraph: >> >> The Address Family AFI definitions from [AFI] only allocate code- >> points for the AFI value itself. The length of the address or entity >> that follows is not defined and is implied based on conventional >> experience. Where the LISP protocol uses LISP Canonical Addresses >> specifically, the address length definitions will be in this >> specification and take precedent over any other specification. >> >> I'm not sure what conventional experience means. Please try to find a > > Well like I said above, the AFI values defined in the AFI document are ju= st type values and there is no length defined. So =E2=80=9Cconventional wis= dom=E2=80=9D means that if a spec says an AFI value 1 is IPv4, we know what= follows is 4 bytes. Ditto for IPv6, MAC addresses, etc. In theory there should be standards/documents specifying this for each of the address types, and maybe could write that people should see the respective standards or something. I don't know if this exists for all the types though. >> better way to say it. Regarding the last sentence, what if a you want >> to define new LCAF encodings in the future? Is it good to say that this >> specification takes precedent over any other? > > LCAF encodings and definitions do not change the length of an AFI encoded= address. So I am not sure what you mean. The last sentence says "Where the LISP protocol uses LISP Canonical Addresses specifically, the address length definitions will be in this specification and take precedent over any other specification.". What if you in the future would like to write a separate specification that defines additional LISP Canonical address formats? >> In section 3 we have this paragraph: >> >> Length: this 16-bit field is in units of bytes and covers all of the >> LISP Canonical Address payload, starting and including the byte >> after the Length field. So any LCAF encoded address will have a >> minimum length of 8 bytes when the Length field is 0. The 8 bytes >> include the AFI, Flags, Type, Reserved, and Length fields. When >> the AFI is not next to encoded address in a control message, then >> the encoded address will have a minimum length of 6 bytes when the >> Length field is 0. The 6 bytes include the Flags, Type, Reserved, >> and Length fields. >> >> Can you phrase this differently? First it says that any LCAF encoded > > No not really. It is precise up to the sentence =E2=80=9CWhen the AFI is = not ..=E2=80=9D. > >> address has a minimum length of 8, but then it goes on to say how it >> sometimes is only 6. I understand what you're trying to say, but there >> may be a better way of stating it. > > This special case is for some LISP control-messages where the AFI is anot= her place in the message but the address is somewhere else. Rather than hav= e the AFI appear twice, the LCAF length needs to be different. > > The length field always includes the entire contiguous set of LCAF bytes = including type, flags, length field, etc. > > The language is precise and accurate. Let me know how you think stating w= hat I did in this comment response can be put in without writing a lot of t= ext about a special case. The problem I see is that first you write "So any LCAF encoded address will have a minimum length of 8 bytes when the Length field is 0." and then you write "then the encoded address will have a minimum length of 6 bytes when the Length field is 0." I understand what you mean, but I feel this is a bit confusing. Maybe you could say something like: When including the AFI, an LCAF encoded address will have a minimum length of 8 bytes when the Length field is 0. Or start by saying that the minimal length is 6, and then say that it will then be 8 when the AFI is included. >> In section 3 it says: >> >> Rsvd2: this 8-bit field is reserved for future use and MUST be >> transmitted as 0 and ignored on receipt. >> >> Some of the LCAFs specified in this document are using it though. Hence >> you may need to change this text, and maybe not make it reserved. > > I change to say the field is LCAF Type dependent and check the LCAF Type = definition to see what bits of this field is not reserved. > >> The last sentence of section 3 is: >> >> Therefore, when a locator-set has a mix of AFI records and >> LCAF records, all LCAF records will appear after all the AFI records. >> >> This is not necessarily true. Isn't it possible that one at some point >> in the future might use other AFI records that have AFI > 16387? IANA >> has assigned several values beyond 16387. > > I will change to order must be in AFI value order. > >> In 4.1 it says: >> AFI =3D x: x can be any AFI value from [AFI]. >> >> Is 16387 always or sometimes allowed? Might be good to clarify that. >> This also applies >> to all the other LCAF types with similar language. > > Always. And since 16387 is in [AFI] and the sentence above says =E2=80=9C= can be any AFI value from [AFI]=E2=80=9D that implies it can be an LCAF AFI= . If I said =E2=80=9Cincluding the LCAF AFI, I would have to make this chan= ge in a dozen places and would be repetitive. I'll leave this to you, but one option could be to just mention it here, and just say that it is true for other types as well. Or mention somewhere before this in the draft that this is allowed. But you already say "any AFI", so that should mean that this is allowed. >> Section 4.4: >> >> RTR RLOC Address: this is an encapsulation address used by an ITR or >> PITR which resides behind a NAT device. This address is known to >> have state in a NAT device so packets can flow from it to the LISP >> ETR behind the NAT. There can be one or more NAT Tunnel Router >> (NTR) [I-D.ermagan-lisp-nat-traversal] addresses supplied in these >> set of fields. The number of NTRs encoded is determined by the >> LCAF length field. When there are no NTRs supplied, the NTR >> fields can be omitted and reflected by the LCAF length field or an >> AFI of 0 can be used to indicate zero NTRs encoded. >> >> It is not quite clear to me if the NTR fields here are the RTR RLOC > >> addresses. Does no NTR fields mean that there are no RTR RLOC addresses? >> If AFI 0 is used, would there be exactly 1 RTR RLOC address (of length >> 0), and that would have AFI 0? > > Good catch. NTR was an old term and the NAT-traversal draft now uses the = term RTR. I will fix. > >> Section 4.5 first paragraph: >> >> Multicast group information can be published in the mapping database. >> So a lookup on an group address EID can return a replication list of >> RLOC group addresses or RLOC unicast addresses. >> >> Can you have a mix of group addresses and unicast addresses? It's also > > Yes, it just depends what address you put following the AFI value. > >> not so clear from the format what source prefixes are. Are the source > > I will state that when an (S,G) is encoded that is what the source addres= s field is used for. > >> prefixes the same as the unicast RLOCs mentioned above? Can you have >> both multiple source addresses and then multiple group addresses? Can >> they be in arbitrarty order, or all sources followed by all groups? > > As shown it is not a list. And if the AFI=3D0 precedes the Source/Subnet = Address field it means there is no source address encoded. > >> It seems one will need to inspect the address itself to tell whether it >> is a unicast or multicast address. This is probably fine. > > Right. > >> Section 4.6 >> Add description of Rsvd3. >> >> Section 4.7 >> Add description of Rsvd3 and Rsvd4. > > Changed. > >> Section 4.10 >> In this section there are several examples of using the AFI List Type, >> but I miss a general definition. It appears that there can be a variable >> number of AFIs in the list. Any number > 0? It might be useful to have > > Yes, a variable number. How about adding a few lines of text to 4.10 saying that you can have a variable number etc., explaining briefly what the general format is. And then say that what follows are examples? >> a length field associated with each AFI, or is it OK that parsing fails = if >> an AFI is unknown, so that the address length is not known? > > Well each AFI has an implicit length per address entry and the LCAF Type = length has the total length. So why would we need to have yet another lengt= h and complicate parsing even more? Please be aware (and I=E2=80=99m sure y= ou are being a senior coder), that the more fields you add to parse, the mo= re cross-checking of field semantics and lengths have to be done. This real= ly complicates the code and if part of the LCAF Type is parseable and other= s are not, then you have a question about what you use and what you discard= . I guess I agree with you. Only issue I see is if you at some point need an implementation to be able to parse past an unkown AFI, basically not knowing the expected address length of the AFI. >> Section 4.10.3 >> Isn't it unusual to include the 0 termination? Since you know the >> length it is not really needed. When parsing one will need to check >> the length either way, what should one do it the string accidentally >> is not 0-terminated? > > Well the AFI definition in [AFI] doesn=E2=80=99t say how to terminate the= string. But the length field will imply it. However, I wrote the =E2=80=9C= distinguished-name=E2=80=9D draft to specify when AFI=3D17 is used (not onl= y in a LCAF but by itself), how to terminate the string. I could include th= at reference, but that draft is not a working group document. > > So please advise. Currently it says: Length value n: length in bytes AFI=3D17 field and the null-terminated ASCII string (the last byte of 0 is included). It might make sense to 0 terminate the DN in some cases, but at least here we know the string length from the value of n, so I think it would be better to drop it here. And as I mentioned, you cannot rely on the 0 for parsing, to be on the safe side you would use n anyway. >> Section 4.10.4 >> I'm assuming that the recursion is more generic than this example? > > Yes. > >> It might be worth trying to explain the more generic concept and >> format, and make sure that this is described as just an example. > > I think that can raise too many combinations. It will be hard to explain = why someone will want to recurse a lot unless we have a well defined use-ca= se. The fact that an LCAF has an AFI value. It means that an LCAF can be en= coded wherever an AFI value is allowed. > > This section shows a practical example and not a general one that no one = would know how to use. > >> Section 4.10.5 >> This also appears to be just an example. > > But a useful one that is already implemented in cisco code. > >> Section 5.2 >> Key Field Num: the number of fields (minus 1) the key can be broken >> up into. The width of the fields are fixed length. So for a key >> size of 8 bytes, with a Key Field Num of 4 allows 4 fields of 2 >> bytes in length. Allowing for a reasonable number of 16 field >> separators, valid values range from 0 to 15. >> >> It says minus 1. Doesn't that mean that a Key Field Num of 4 indicates >> 5 fields? > > I fixed the description to be more clear. > >> Key Wildcard Fields: describes which fields in the key are not used >> as part of the key lookup. This wildcard encoding is a bitfield. >> Each bit is a don't-care bit for a corresponding field in the key. >> Bit 0 (the low-order bit) in this bitfield corresponds the first >> field, right-justified in the key, bit 1 the second field, and so >> on. When a bit is set in the bitfield it is a don't-care bit and >> >> What does right-justified mean? Does it mean that the first field is the >> "low order" one? Basically at the end of the message? And the highest > > Yes, I will make that more clear. > >> order bit corresponds to the part of the key right after the wilcards? >> I think this need to be explained better to ensure interoperability. >> >> Key: the variable length key used to do a LISP Database Mapping >> lookup. The length of the key is the value n (shown above) minus >> 3. >> >> Isn't it exactly the value n, since the length is n + 3? > > Yes, you are right. Fixed. > >> Section 5.4 >> Length value n: length in bytes of fields that follow. >> This is a bit confusing. I think 2+n is the length in bytes that follow >> the lenght field. While n is the number of bytes after the JSON length. > > The 2 is for the JSON length field, since it is a fixed field. The =E2=80= =9Cn=E2=80=9D is for the remaining variable length fields which include the= JSON-binary-text and the AFI address. I=E2=80=99ll make the Length descrip= tion reflect this. Thanks. > >> Section 5.5 >> >> It says "AFI =3D x" twice in the diagram. Based on this and the way it >> is described it might seem that the two AFI values must be the same >> value x, but they can differ, right? I this applies to several other >> messages types as well. > > I=E2=80=99ll change x to y in the second occurence and a description for = each. > >> Section 7 >> It looks like the table in the IANA considerations doesn't include all >> the types defined in this document. > > That was done intentionally. The ones that are experimental are not in th= is section 7 list because there is no use-case document for it yet. Maybe t= he chairs can explain this better than me. I think it's still useful. If someone sees the type used, they can look it up in the registry. It also helps avoid that someone perhaps tries to reuse one of these types in new documents. If you really want to use one of the code points for something else in the future, a new document could always update the registry. BTW, it also makes me wonder if it is worth reserving any LCAF types for experiments. Regards, Stig >> I'm happy to discuss my comments if needed, and also review any >> updates to this draft. >> >> Stig > > Let me know about the response where I didn=E2=80=99t make any changes. > > Thanks again, > Dino/Dave/Job > > > > > > > > > From nobody Mon Sep 12 05:02:04 2016 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 5A29F12B256; Mon, 12 Sep 2016 05:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81aHXNgt1Hn5; Mon, 12 Sep 2016 05:01:56 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (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 EF5A312B211; Mon, 12 Sep 2016 05:01:55 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id 128so51820957pfb.3; Mon, 12 Sep 2016 05:01:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WXK4+MIDry5NK9y+lmB0PCenZwFfuACmO+qMeWG3KfE=; b=VIaXtfWtonMmvjLKHfOrhLm5se5KQclIZRmRtOALELwB0BTa1hGsHzqEsdkvx6jhE+ fMjd9+CqgXA6QtWh9yRfVUU7mghds80BTJ0e4mJBcnt5hMziFIOgFXNG/dfoHYDXbQy5 9zwlEosFzPoNs8vBN+/6tt1kmOBfaTgIaNUl9Mc8mG4wuIjvMEA3ktb8nAmuHxX0OSFP tZDQnNSaRED2rSPKXh1Dxa3NGOw9cg4x55Td6Vwq3UFarXTbuhpyQuRnuQe3b2sNhEbN PUVqO66SkcMLnGmC4zCRX5fvZMj3PtJRPn0nz1oWWpLm1jrNkQnuBAwJ3WwXAd7JWBOC nq1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WXK4+MIDry5NK9y+lmB0PCenZwFfuACmO+qMeWG3KfE=; b=PF73L+kQR0e7ZDEZZzt8ld5SKYskPcJ+83RMndLITsk6kzCZmkWcos/AmBYOMFil/6 IcdvMgDRdl751HMfwZLDeai3bFOq2hphN5xQFW10SLa0aUMqb6mM0t78SJ9PtS/DW1AX q+bvh1775NCHICqkSMoZZ1hRBkMoLftDFzTEqTRM3Ku18azxON2TwLwsa30nrAO9cemY 8+NUqubidEKUvmbj6lbCWxUreGRKxwsJrvkBML5ixJ4o3M+WHNF/yBiM9t3RN8hE77y9 ud8tziJvf0NouuopNf5V1mIfJu9NqmVd3tp2m+Ic9oyokNiTVq8AzkcuiiVSOVWJjwUb iUqw== X-Gm-Message-State: AE9vXwNG9HIsqFudN7MjAPkI+SkNHplvVwqMRwparTaNs5z4Ik/2SDUcGPzX8bm8Jwob8A== X-Received: by 10.98.64.93 with SMTP id n90mr32864822pfa.29.1473681715158; Mon, 12 Sep 2016 05:01:55 -0700 (PDT) Received: from [10.70.110.216] ([166.170.41.34]) by smtp.gmail.com with ESMTPSA id w63sm4236296pfk.43.2016.09.12.05.01.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 12 Sep 2016 05:01:54 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-E20CC696-ECBE-4FFE-854A-234B01640854 Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (14A5346a) In-Reply-To: Date: Mon, 12 Sep 2016 13:01:48 +0100 Content-Transfer-Encoding: 7bit Message-Id: <6E7490D9-BFC1-442A-A828-0841F2B831EF@gmail.com> References: <551BDE7B-6BA3-4336-B92A-395FBE4A571D@gmail.com> To: Stig Venaas Archived-At: Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, LISP mailing list list , draft-ietf-lisp-lcaf.all@ietf.org Subject: Re: [lisp] RtgDir review: draft-ietf-lisp-lcaf-14.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 12 Sep 2016 12:01:59 -0000 --Apple-Mail-E20CC696-ECBE-4FFE-854A-234B01640854 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Stig, I'm traveling this week. I'll get you a reply over this coming weekend= .=20 Dino > On Sep 10, 2016, at 12:15 AM, Stig Venaas wrote: >=20 > Hi >=20 > On Thu, Sep 8, 2016 at 2:02 PM, Dino Farinacci wrote= : >>> Document: draft-ietf-lisp-lcaf-14.txt >>> Reviewer: Stig Venaas >>> Review Date: 2016-09-07 >>> IETF LC End Date: >>> Intended Status: Experimental >>=20 >> Thanks Stig for your comments. See responses below. As well as a new vers= ion -15 not submitted yet but for your quick review. Also find a lcaf-rfcdif= f.html file for easy diff viewing. >=20 > Thanks. I have some comments inline. >=20 >>> Summary: >>> I have some minor concerns about this document that I think should be >>> resolved before publication. >>>=20 >>> The draft is almost ready but there are several places where the text >>> is a bit unclear, >>=20 >> No problem. This document has had a long history and many opinions relate= d to it has come and gone but we tried to reflect everyone=E2=80=99s point o= f view. >>=20 >>> In section 1 I find this sentence a bit misleading since [AFI] doesn't >>> talk about the formatting. >>>=20 >>> Currently defined AFIs include IPv4 and IPv6 addresses, which are >>> formatted according to code-points assigned in [AFI] as follows: >>>=20 >>> Is the formatting shown here for AFI 1 and 2 defined in another >>> document? It would be good to have a reference. If it is introduced >>> in this document, then it should not be in the introduction. >>=20 >> No it is not shown in any document. All the AFI document says is that a 1= 6-bit AFI value of 1 means an IP address follows. That means 4 bytes of addr= ess. And 16 for IPv6 when AFI is 2. >>=20 >> As you can see the reference to the AFI document is at the end of the sen= tence. >>=20 >>> In section 2, first paragraph it says: >>> There is an address family currently defined for IPv4 or IPv6 >>> addresses. >>>=20 >>> It would be better to say that address families are defined for IPv4 >>> and IPv6 addresses. >>=20 >> Changed. >>=20 >>> In section 3 we have this paragraph: >>>=20 >>> The Address Family AFI definitions from [AFI] only allocate code- >>> points for the AFI value itself. The length of the address or entity >>> that follows is not defined and is implied based on conventional >>> experience. Where the LISP protocol uses LISP Canonical Addresses >>> specifically, the address length definitions will be in this >>> specification and take precedent over any other specification. >>>=20 >>> I'm not sure what conventional experience means. Please try to find a >>=20 >> Well like I said above, the AFI values defined in the AFI document are ju= st type values and there is no length defined. So =E2=80=9Cconventional wisd= om=E2=80=9D means that if a spec says an AFI value 1 is IPv4, we know what f= ollows is 4 bytes. Ditto for IPv6, MAC addresses, etc. >=20 > In theory there should be standards/documents specifying this for each > of the address types, and maybe could write that people should see the > respective standards or something. I don't know if this exists for all > the types though. >=20 >>> better way to say it. Regarding the last sentence, what if a you want >>> to define new LCAF encodings in the future? Is it good to say that this >>> specification takes precedent over any other? >>=20 >> LCAF encodings and definitions do not change the length of an AFI encoded= address. So I am not sure what you mean. >=20 > The last sentence says "Where the LISP protocol uses LISP Canonical > Addresses specifically, the address length definitions will be in this > specification and take precedent over any other specification.". What > if you in the future would like to write a separate specification that > defines additional LISP Canonical address formats? >=20 >>> In section 3 we have this paragraph: >>>=20 >>> Length: this 16-bit field is in units of bytes and covers all of the >>> LISP Canonical Address payload, starting and including the byte >>> after the Length field. So any LCAF encoded address will have a >>> minimum length of 8 bytes when the Length field is 0. The 8 bytes >>> include the AFI, Flags, Type, Reserved, and Length fields. When >>> the AFI is not next to encoded address in a control message, then >>> the encoded address will have a minimum length of 6 bytes when the >>> Length field is 0. The 6 bytes include the Flags, Type, Reserved, >>> and Length fields. >>>=20 >>> Can you phrase this differently? First it says that any LCAF encoded >>=20 >> No not really. It is precise up to the sentence =E2=80=9CWhen the AFI is n= ot ..=E2=80=9D. >>=20 >>> address has a minimum length of 8, but then it goes on to say how it >>> sometimes is only 6. I understand what you're trying to say, but there >>> may be a better way of stating it. >>=20 >> This special case is for some LISP control-messages where the AFI is anot= her place in the message but the address is somewhere else. Rather than have= the AFI appear twice, the LCAF length needs to be different. >>=20 >> The length field always includes the entire contiguous set of LCAF bytes i= ncluding type, flags, length field, etc. >>=20 >> The language is precise and accurate. Let me know how you think stating w= hat I did in this comment response can be put in without writing a lot of te= xt about a special case. >=20 > The problem I see is that first you write "So any LCAF encoded address > will have a minimum length of 8 bytes when the Length field is 0." and > then you write "then the encoded address will have a minimum length of > 6 bytes when the Length field is 0." I understand what you mean, but I > feel this is a bit confusing. >=20 > Maybe you could say something like: >=20 > When including the AFI, an LCAF encoded address will have a minimum > length of 8 bytes when the Length field is 0. Or start by saying that > the minimal length is 6, and then say that it will then be 8 when the > AFI is included. >=20 >>> In section 3 it says: >>>=20 >>> Rsvd2: this 8-bit field is reserved for future use and MUST be >>> transmitted as 0 and ignored on receipt. >>>=20 >>> Some of the LCAFs specified in this document are using it though. Hence >>> you may need to change this text, and maybe not make it reserved. >>=20 >> I change to say the field is LCAF Type dependent and check the LCAF Type d= efinition to see what bits of this field is not reserved. >>=20 >>> The last sentence of section 3 is: >>>=20 >>> Therefore, when a locator-set has a mix of AFI records and >>> LCAF records, all LCAF records will appear after all the AFI records. >>>=20 >>> This is not necessarily true. Isn't it possible that one at some point >>> in the future might use other AFI records that have AFI > 16387? IANA >>> has assigned several values beyond 16387. >>=20 >> I will change to order must be in AFI value order. >>=20 >>> In 4.1 it says: >>> AFI =3D x: x can be any AFI value from [AFI]. >>>=20 >>> Is 16387 always or sometimes allowed? Might be good to clarify that. >>> This also applies >>> to all the other LCAF types with similar language. >>=20 >> Always. And since 16387 is in [AFI] and the sentence above says =E2=80=9C= can be any AFI value from [AFI]=E2=80=9D that implies it can be an LCAF AFI.= If I said =E2=80=9Cincluding the LCAF AFI, I would have to make this change= in a dozen places and would be repetitive. >=20 > I'll leave this to you, but one option could be to just mention it > here, and just say that it is true for other types as well. Or mention > somewhere before this in the draft that this is allowed. But you > already say "any AFI", so that should mean that this is allowed. >=20 >>> Section 4.4: >>>=20 >>> RTR RLOC Address: this is an encapsulation address used by an ITR or >>> PITR which resides behind a NAT device. This address is known to >>> have state in a NAT device so packets can flow from it to the LISP >>> ETR behind the NAT. There can be one or more NAT Tunnel Router >>> (NTR) [I-D.ermagan-lisp-nat-traversal] addresses supplied in these >>> set of fields. The number of NTRs encoded is determined by the >>> LCAF length field. When there are no NTRs supplied, the NTR >>> fields can be omitted and reflected by the LCAF length field or an >>> AFI of 0 can be used to indicate zero NTRs encoded. >>>=20 >>> It is not quite clear to me if the NTR fields here are the RTR RLOC >>=20 >>> addresses. Does no NTR fields mean that there are no RTR RLOC addresses?= >>> If AFI 0 is used, would there be exactly 1 RTR RLOC address (of length >>> 0), and that would have AFI 0? >>=20 >> Good catch. NTR was an old term and the NAT-traversal draft now uses the t= erm RTR. I will fix. >>=20 >>> Section 4.5 first paragraph: >>>=20 >>> Multicast group information can be published in the mapping database. >>> So a lookup on an group address EID can return a replication list of >>> RLOC group addresses or RLOC unicast addresses. >>>=20 >>> Can you have a mix of group addresses and unicast addresses? It's also >>=20 >> Yes, it just depends what address you put following the AFI value. >>=20 >>> not so clear from the format what source prefixes are. Are the source >>=20 >> I will state that when an (S,G) is encoded that is what the source addres= s field is used for. >>=20 >>> prefixes the same as the unicast RLOCs mentioned above? Can you have >>> both multiple source addresses and then multiple group addresses? Can >>> they be in arbitrarty order, or all sources followed by all groups? >>=20 >> As shown it is not a list. And if the AFI=3D0 precedes the Source/Subnet A= ddress field it means there is no source address encoded. >>=20 >>> It seems one will need to inspect the address itself to tell whether it >>> is a unicast or multicast address. This is probably fine. >>=20 >> Right. >>=20 >>> Section 4.6 >>> Add description of Rsvd3. >>>=20 >>> Section 4.7 >>> Add description of Rsvd3 and Rsvd4. >>=20 >> Changed. >>=20 >>> Section 4.10 >>> In this section there are several examples of using the AFI List Type, >>> but I miss a general definition. It appears that there can be a variable= >>> number of AFIs in the list. Any number > 0? It might be useful to have >>=20 >> Yes, a variable number. >=20 > How about adding a few lines of text to 4.10 saying that you can have > a variable number etc., explaining briefly what the general format is. > And then say that what follows are examples? >=20 >>> a length field associated with each AFI, or is it OK that parsing fails i= f >>> an AFI is unknown, so that the address length is not known? >>=20 >> Well each AFI has an implicit length per address entry and the LCAF Type l= ength has the total length. So why would we need to have yet another length a= nd complicate parsing even more? Please be aware (and I=E2=80=99m sure you a= re being a senior coder), that the more fields you add to parse, the more cr= oss-checking of field semantics and lengths have to be done. This really com= plicates the code and if part of the LCAF Type is parseable and others are n= ot, then you have a question about what you use and what you discard. >=20 > I guess I agree with you. Only issue I see is if you at some point > need an implementation to be able to parse past an unkown AFI, > basically not knowing the expected address length of the AFI. >=20 >>> Section 4.10.3 >>> Isn't it unusual to include the 0 termination? Since you know the >>> length it is not really needed. When parsing one will need to check >>> the length either way, what should one do it the string accidentally >>> is not 0-terminated? >>=20 >> Well the AFI definition in [AFI] doesn=E2=80=99t say how to terminate the= string. But the length field will imply it. However, I wrote the =E2=80=9Cd= istinguished-name=E2=80=9D draft to specify when AFI=3D17 is used (not only i= n a LCAF but by itself), how to terminate the string. I could include that r= eference, but that draft is not a working group document. >>=20 >> So please advise. >=20 > Currently it says: >=20 > Length value n: length in bytes AFI=3D17 field and the null-terminated > ASCII string (the last byte of 0 is included). >=20 > It might make sense to 0 terminate the DN in some cases, but at least > here we know the string length from the value of n, so I think it > would be better to drop it here. And as I mentioned, you cannot rely > on the 0 for parsing, to be on the safe side you would use n anyway. >=20 >>> Section 4.10.4 >>> I'm assuming that the recursion is more generic than this example? >>=20 >> Yes. >>=20 >>> It might be worth trying to explain the more generic concept and >>> format, and make sure that this is described as just an example. >>=20 >> I think that can raise too many combinations. It will be hard to explain w= hy someone will want to recurse a lot unless we have a well defined use-case= . The fact that an LCAF has an AFI value. It means that an LCAF can be encod= ed wherever an AFI value is allowed. >>=20 >> This section shows a practical example and not a general one that no one w= ould know how to use. >>=20 >>> Section 4.10.5 >>> This also appears to be just an example. >>=20 >> But a useful one that is already implemented in cisco code. >>=20 >>> Section 5.2 >>> Key Field Num: the number of fields (minus 1) the key can be broken >>> up into. The width of the fields are fixed length. So for a key >>> size of 8 bytes, with a Key Field Num of 4 allows 4 fields of 2 >>> bytes in length. Allowing for a reasonable number of 16 field >>> separators, valid values range from 0 to 15. >>>=20 >>> It says minus 1. Doesn't that mean that a Key Field Num of 4 indicates >>> 5 fields? >>=20 >> I fixed the description to be more clear. >>=20 >>> Key Wildcard Fields: describes which fields in the key are not used >>> as part of the key lookup. This wildcard encoding is a bitfield. >>> Each bit is a don't-care bit for a corresponding field in the key. >>> Bit 0 (the low-order bit) in this bitfield corresponds the first >>> field, right-justified in the key, bit 1 the second field, and so >>> on. When a bit is set in the bitfield it is a don't-care bit and >>>=20 >>> What does right-justified mean? Does it mean that the first field is the= >>> "low order" one? Basically at the end of the message? And the highest >>=20 >> Yes, I will make that more clear. >>=20 >>> order bit corresponds to the part of the key right after the wilcards? >>> I think this need to be explained better to ensure interoperability. >>>=20 >>> Key: the variable length key used to do a LISP Database Mapping >>> lookup. The length of the key is the value n (shown above) minus >>> 3. >>>=20 >>> Isn't it exactly the value n, since the length is n + 3? >>=20 >> Yes, you are right. Fixed. >>=20 >>> Section 5.4 >>> Length value n: length in bytes of fields that follow. >>> This is a bit confusing. I think 2+n is the length in bytes that follow >>> the lenght field. While n is the number of bytes after the JSON length. >>=20 >> The 2 is for the JSON length field, since it is a fixed field. The =E2=80= =9Cn=E2=80=9D is for the remaining variable length fields which include the J= SON-binary-text and the AFI address. I=E2=80=99ll make the Length descriptio= n reflect this. Thanks. >>=20 >>> Section 5.5 >>>=20 >>> It says "AFI =3D x" twice in the diagram. Based on this and the way it >>> is described it might seem that the two AFI values must be the same >>> value x, but they can differ, right? I this applies to several other >>> messages types as well. >>=20 >> I=E2=80=99ll change x to y in the second occurence and a description for e= ach. >>=20 >>> Section 7 >>> It looks like the table in the IANA considerations doesn't include all >>> the types defined in this document. >>=20 >> That was done intentionally. The ones that are experimental are not in th= is section 7 list because there is no use-case document for it yet. Maybe th= e chairs can explain this better than me. >=20 > I think it's still useful. If someone sees the type used, they can > look it up in the registry. It also helps avoid that someone perhaps > tries to reuse one of these types in new documents. If you really want > to use one of the code points for something else in the future, a new > document could always update the registry. >=20 > BTW, it also makes me wonder if it is worth reserving any LCAF types > for experiments. >=20 > Regards, > Stig >=20 >>> I'm happy to discuss my comments if needed, and also review any >>> updates to this draft. >>>=20 >>> Stig >>=20 >> Let me know about the response where I didn=E2=80=99t make any changes. >>=20 >> Thanks again, >> Dino/Dave/Job >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 --Apple-Mail-E20CC696-ECBE-4FFE-854A-234B01640854 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Stig, I'm traveling this week. I'll get you a reply over this coming week= end. 

Dino

On Sep 10, 2016, at 12:15 AM, Stig Ve= naas <stig@venaas.com> wrote:
Hi
<= br>On Thu, Sep 8, 2016 at 2:02 PM, Dino Farinacci <farinacci@gmail.com> wrote:
Document: draft-ietf-lisp-= lcaf-14.txt
Reviewer: Stig Venaas
<= /blockquote>
Review= Date: 2016-09-07
IETF LC End Date:
Inte= nded Status: Experimental

Th= anks Stig for your comments. See responses below. As well as a new version -= 15 not submitted yet but for your quick review. Also find a lcaf-rfcdiff.htm= l file for easy diff viewing.

= Thanks. I have some comments inline.

Summary:
I ha= ve some minor concerns about this document that I think should be
=
resolved before publication.

Th= e draft is almost ready but there are several places where the text
is a bit unclear,

N= o problem. This document has had a long history and many opinions related to= it has come and gone but we tried to reflect everyone=E2=80=99s point of vi= ew.

In section 1= I find this sentence a bit misleading since [AFI] doesn't
talk about the formatting.

 Curre= ntly defined AFIs include IPv4 and IPv6 addresses, which are
 formatted according to code-points assigned in [AFI] as follows:

Is the formatting shown here for AFI 1 a= nd 2 defined in another
document? It would be good to have= a reference. If it is introduced
in this document, then i= t should not be in the introduction.

No it is not shown in any document. All the AFI document says is th= at a 16-bit AFI value of 1 means an IP address follows. That means 4 bytes o= f address. And 16 for IPv6 when AFI is 2.

As you can see the reference to the AFI document is at the end of the sente= nce.

In section= 2, first paragraph it says:
 There is an address fa= mily currently defined for IPv4 or IPv6
=
 addresses.<= /span>

It would be better to say that address f= amilies are defined for IPv4
and IPv6 addresses.

Changed.

In section 3 we have this paragraph:=

<= blockquote type=3D"cite">  The Address Family AFI definitions fro= m [AFI] only allocate code-
 points for the AFI value= itself.  The length of the address or entity
 = that follows is not defined and is implied based on conventional
<= /blockquote>
 experience.  Where the LISP protocol uses LISP Canonical A= ddresses
 specifically, the address length definitio= ns will be in this
 specification and take precedent= over any other specification.

I'm not s= ure what conventional experience means. Please try to find a

Well like I said above, the AFI values defi= ned in the AFI document are just type values and there is no length defined.= So =E2=80=9Cconventional wisdom=E2=80=9D means that if a spec says an AFI v= alue 1 is IPv4, we know what follows is 4 bytes. Ditto for IPv6, MAC address= es, etc.

In theory there shoul= d be standards/documents specifying this for each
of the add= ress types, and maybe could write that people should see the
respective standards or something. I don't know if this exists for all
the types though.

better way to say it. Regarding the l= ast sentence, what if a you want
to define new LCAF encodi= ngs in the future? Is it good to say that this
specificati= on takes precedent over any other?

LCAF encodings and definitions do not change the length of an AFI enc= oded address. So I am not sure what you mean.
<= /span>
The last sentence says "Where the LISP protocol uses LISP Ca= nonical
Addresses specifically, the address length definitio= ns will be in this
specification and take precedent over any= other specification.". What
if you in the future would like= to write a separate specification that
defines additional L= ISP Canonical address formats?

In section 3 we have this paragraph:<= /span>

 Length:  this 16-bit field i= s in units of bytes and covers all of the
  &nb= sp; LISP Canonical Address payload, starting and including the byte
    after the Length field.  So any L= CAF encoded address will have a
    m= inimum length of 8 bytes when the Length field is 0.  The 8 bytes
    include the AFI, Flags, Type, Reserved= , and Length fields.  When
    t= he AFI is not next to encoded address in a control message, then
<= /blockquote>
    the encoded address will have a minimum leng= th of 6 bytes when the
    Length field= is 0.  The 6 bytes include the Flags, Type, Reserved,
    and Length fields.

<= /blockquote>
Can you phrase this differently? First it says that any LCAF encoded<= /span>
<= br>
No not really. It is precise= up to the sentence =E2=80=9CWhen the AFI is not ..=E2=80=9D.

address has a minimum length o= f 8, but then it goes on to say how it
<= blockquote type=3D"cite">
sometimes is only 6= . I understand what you're trying to say, but there
<= /blockquote>
may be= a better way of stating it.

This special case is for some LISP control-messages where the AFI is anothe= r place in the message but the address is somewhere else. Rather than have t= he AFI appear twice, the LCAF length needs to be different.

The length field always includes the entire contiguous se= t of LCAF bytes including type, flags, length field, etc.

The language is precise and accurate. Let me know how you t= hink stating what I did in this comment response can be put in without writi= ng a lot of text about a special case.
<= br>The problem I see is that first you write "So any LCAF encoded addr= ess
will have a minimum length of 8 bytes when the Length fi= eld is 0." and
then you write "then the encoded address will= have a minimum length of
6 bytes when the Length field is 0= ." I understand what you mean, but I
feel this is a bit conf= using.

Maybe you could say something like:<= /span>

When including the AFI, an LCAF encoded add= ress will have a minimum
length of 8 bytes when the Length f= ield is 0. Or start by saying that
the minimal length is 6, a= nd then say that it will then be 8 when the
AFI is included.=

In section 3 it says:

 = Rsvd2:  this 8-bit field is reserved for future use and MUST be<= br>
    transmitted as 0 and ignored on receipt.=

Some of the LCAFs specified in this do= cument are using it though. Hence
you may need to change t= his text, and maybe not make it reserved.

I change to say the field is LCAF Type dependent and check the L= CAF Type definition to see what bits of this field is not reserved.

The last sentence of se= ction 3 is:

 Therefore, when a lo= cator-set has a mix of AFI records and
<= blockquote type=3D"cite">
 LCAF records= , all LCAF records will appear after all the AFI records.
=
This is not necessarily true. Isn't it possible that one a= t some point
<= blockquote type=3D"cite">in the future might use other AFI records tha= t have AFI > 16387? IANA
has assigned several values bey= ond 16387.

I will change to o= rder must be in AFI value order.

In 4.1 it says:
 AFI =3D x:  = x can be any AFI value from [AFI].

Is 1= 6387 always or sometimes allowed? Might be good to clarify that.
<= /blockquote>
This also applies
to all the other LCAF types with s= imilar language.

Always. And= since 16387 is in [AFI] and the sentence above says =E2=80=9Ccan be any AFI= value from [AFI]=E2=80=9D that implies it can be an LCAF AFI. If I said =E2= =80=9Cincluding the LCAF AFI, I would have to make this change in a dozen pl= aces and would be repetitive.

= I'll leave this to you, but one option could be to just mention ithere, and just say that it is true for other types as well. Or mentio= n
somewhere before this in the draft that this is allowed. B= ut you
already say "any AFI", so that should mean that this i= s allowed.

Section 4.4:

 = RTR RLOC Address:  this is an encapsulation address used by an ITR or
    PITR which resides behind a NAT de= vice.  This address is known to
   &n= bsp;have state in a NAT device so packets can flow from it to the LISP
    ETR behind the NAT.  There can be= one or more NAT Tunnel Router
    (N= TR) [I-D.ermagan-lisp-nat-traversal] addresses supplied in these
<= /blockquote>
    set of fields.  The number of NTRs enco= ded is determined by the
    LCAF len= gth field.  When there are no NTRs supplied, the NTR
=     fields can be omitted and reflected by the LCAF len= gth field or an
    AFI of 0 can be u= sed to indicate zero NTRs encoded.

It i= s not quite clear to me if the NTR fields here are the RTR RLOC

addresses. Doe= s no NTR fields mean that there are no RTR RLOC addresses?
If AFI 0 is used, would there be exactly 1 RTR RLOC address (of length
0), and that would have AFI 0?

Good catch. NTR was an old term and the NAT-traversal draft n= ow uses the term RTR. I will fix.

Section 4.5 first paragraph:
 Multicast group information can be published in the mapping d= atabase.
 So a lookup on an group address EID can re= turn a replication list of
 RLOC group addresses or R= LOC unicast addresses.

=
Can you have a mix= of group addresses and unicast addresses? It's also
=

Yes, it just depends what address you put following= the AFI value.

not so clear from the format what source prefixes are. Are the source

I will state that when an (S,G) i= s encoded that is what the source address field is used for.

prefixes the same as the unicas= t RLOCs mentioned above? Can you have
both multiple source= addresses and then multiple group addresses? Can
they be i= n arbitrarty order, or all sources followed by all groups?

<= blockquote type=3D"cite">As shown it is not a list. And if the AFI=3D0= precedes the Source/Subnet Address field it means there is no source addres= s encoded.
It s= eems one will need to inspect the address itself to tell whether it
is a unicast or multicast address. This is probably fine.

Right.

=
Section 4.6
Add descriptio= n of Rsvd3.

Section 4.7
Add description of Rsvd3 and Rsvd4.
<= blockquote type=3D"cite">
Changed.
<= /span>
<= span>Section 4.10
In this section there are several exampl= es of using the AFI List Type,
but I miss a general defini= tion. It appears that there can be a variable
number of AFI= s in the list. Any number > 0? It might be useful to have

Yes, a variable number.

How about adding a few lines of text to 4.10 sayi= ng that you can have
a variable number etc., explaining brie= fly what the general format is.
And then say that what follo= ws are examples?

a length field associated with each AFI, or is it O= K that parsing fails if
an AFI is unknown, so that the add= ress length is not known?

We= ll each AFI has an implicit length per address entry and the LCAF Type lengt= h has the total length. So why would we need to have yet another length and c= omplicate parsing even more? Please be aware (and I=E2=80=99m sure you are b= eing a senior coder), that the more fields you add to parse, the more cross-= checking of field semantics and lengths have to be done. This really complic= ates the code and if part of the LCAF Type is parseable and others are not, t= hen you have a question about what you use and what you discard.
<= /blockquote>
I guess I agree with you. Only issue I se= e is if you at some point
need an implementation to be able t= o parse past an unkown AFI,
basically not knowing the expect= ed address length of the AFI.

Section 4.10.3
Isn'= t it unusual to include the 0 termination? Since you know the
length it is not really needed. When parsing one will need to check
the length either way, what should one do it the string acciden= tally
is not 0-terminated?

Well the AFI definition in [AFI] doesn=E2=80=99t say how to= terminate the string. But the length field will imply it. However, I wrote t= he =E2=80=9Cdistinguished-name=E2=80=9D draft to specify when AFI=3D17 is us= ed (not only in a LCAF but by itself), how to terminate the string. I could i= nclude that reference, but that draft is not a working group document.

So please advise.

Currently it says:

 = ; Length value n:  length in bytes AFI=3D17 field and the null-ter= minated
     ASCII string (the las= t byte of 0 is included).

It might make sen= se to 0 terminate the DN in some cases, but at least
here we= know the string length from the value of n, so I think it
w= ould be better to drop it here. And as I mentioned, you cannot relyon the 0 for parsing, to be on the safe side you would use n anyway.=

Section 4.10.4
I'm assuming that the recursion i= s more generic than this example?

= Yes.
It m= ight be worth trying to explain the more generic concept and
format, and make sure that this is described as just an example.

I think that can raise too many comb= inations. It will be hard to explain why someone will want to recurse a lot u= nless we have a well defined use-case. The fact that an LCAF has an AFI valu= e. It means that an LCAF can be encoded wherever an AFI value is allowed.

This section shows a practical example and n= ot a general one that no one would know how to use.
<= blockquote type=3D"cite">
Section 4.10.5
<= /blockquote>
This a= lso appears to be just an example.

But a useful one that is already implemented in cisco code.

Section 5.2
=  Key Field Num:  the number of fields (minus 1) the key can= be broken
    up into.  The wid= th of the fields are fixed length.  So for a key
&nb= sp;   size of 8 bytes, with a Key Field Num of 4 allows 4 fie= lds of 2
    bytes in length.  A= llowing for a reasonable number of 16 field
  &= nbsp; separators, valid values range from 0 to 15.

It says minus 1. Doesn't that mean that a Key Field Num of 4= indicates
5 fields?
<= blockquote type=3D"cite">
I fixed the description to be more clear.
=

 Key Wildcard Fields:  desc= ribes which fields in the key are not used
  &n= bsp; as part of the key lookup.  This wildcard encoding is a bitfi= eld.
    Each bit is a don't-care bit= for a corresponding field in the key.
<= blockquote type=3D"cite">
   =  Bit 0 (the low-order bit) in this bitfield corresponds the first
    field, right-justified in the key, bit= 1 the second field, and so
    on. &n= bsp;When a bit is set in the bitfield it is a don't-care bit and
<= /blockquote>

What does right-justified mean? Does it mean that t= he first field is the
"low order" one? Basically at the end= of the message? And the highest

<= span>Yes, I will make that more clear.

order bit corresponds to the part of the key right a= fter the wilcards?
I think this need to be explained bette= r to ensure interoperability.

 Ke= y:  the variable length key used to do a LISP Database Mapping
    lookup.  The length of the key is th= e value n (shown above) minus
    3.<= /span>

Isn't it exactly the value n, since the= length is n + 3?

Yes, you a= re right. Fixed.

Section 5.4
=
 Length value n:  length in bytes= of fields that follow.
This is a bit confusing. I think 2= +n is the length in bytes that follow
the lenght field. Wh= ile n is the number of bytes after the JSON length.
<= /blockquote>

The 2 is for the JSON length field, since it is a fi= xed field. The =E2=80=9Cn=E2=80=9D is for the remaining variable length fiel= ds which include the JSON-binary-text and the AFI address. I=E2=80=99ll make= the Length description reflect this. Thanks.

<= blockquote type=3D"cite">Section 5.5

It says "AFI =3D x" twice in the diagram. Based on this and the way it
is described it might seem that the two AFI values must be t= he same
value x, but they can differ, right? I this applie= s to several other
messages types as well.

I=E2=80=99ll change x to y in the second oc= curence and a description for each.

Section 7
It looks like the table in th= e IANA considerations doesn't include all
the types define= d in this document.

That was= done intentionally. The ones that are experimental are not in this section 7= list because there is no use-case document for it yet. Maybe the chairs can= explain this better than me.

= I think it's still useful. If someone sees the type used, they canlook it up in the registry. It also helps avoid that someone perhaps<= /span>
tries to reuse one of these types in new documents. If you r= eally want
to use one of the code points for something else i= n the future, a new
document could always update the registr= y.

BTW, it also makes me wonder if it is wo= rth reserving any LCAF types
for experiments.

Regards,
Stig

=
I'm happy to discu= ss my comments if needed, and also review any
updates to t= his draft.

Stig
=

Let me know about the response where I didn=E2=80=99= t make any changes.
<= /span>
Thanks again,<= br>
Dino/Dave/Job









= = --Apple-Mail-E20CC696-ECBE-4FFE-854A-234B01640854-- From nobody Tue Sep 13 03:08:44 2016 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 EE5D512B2C8 for ; Tue, 13 Sep 2016 03:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 m_TD3A8dffr6 for ; Tue, 13 Sep 2016 03:08:31 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 B663D12B2D3 for ; Tue, 13 Sep 2016 03:08:30 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id 1so191687442wmz.1 for ; Tue, 13 Sep 2016 03:08:30 -0700 (PDT) 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=cUozONWHxZOmPIq3yNqXNDMMFryCFAJE17GQAkK9vOU=; b=zuYUPJrx8udlG2fGTbff6gTxtdo1SPz0fKjADecpl5S+kTJ6+EKmMXftlXwwWT+HQh xo5JecTo9CL6rC6lwrIQBUlrq5MrbteLfh4EEwK6+AmOatXa/OUFE2V36eJYN8Wm9LsQ L/Ew6ivIvEdYjopFIWdqD0Ub85uGgre5AW5azJ/WqiPAzYkOK/OaA8+iH1l53bCR38i9 QZqX5yrKStVhagHvkbjFCxdEM4A0/jXBWwhhS6oRPmkPzXq86pAuw+R4pZVqi+D7nf/r Qh1XhjY8uduCJWiUAaEs56OeWtd2b8zcF6+vpQsFdWvR+cHfgFNA86gSqxrZNLeWMWoO IGtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cUozONWHxZOmPIq3yNqXNDMMFryCFAJE17GQAkK9vOU=; b=MEqb/x2NKC/+rttMWn6T590gCbZkskU4WuGvITVxJ9d2MXyjS/TId+6dmDq4E/B6Ej CxHwbfCxNvonBMI2LfQh3XSiJoLE0e8EmzBQr4hlIeT6BBCSuqoQ+oQcNJl0Mnwt2N37 iZV+4YRR6BP3e9j84cAzA9pvtGGYLb544CogilBrTQOS4G+afzN0RMyBgBlEzc8e4Yg+ T7U2GPkJHr+I6bBU794MIpGoD8zdeU5Rhd5tD1hwUeMqKss6O4I8/fYLyxqJ1Lp1Fvxb uHeRXdsb6t3ODWWQhGE572mobNc0UwjOJ02MS3oqCf1gW8UXhoKgqEPJ1OPmd/rqG/Fu rYiQ== X-Gm-Message-State: AE9vXwMEEhkJQN4WpqecxcJpM+XcrkcSGFJ6a200a6A3fy+moyVYRYc+BpHja76ZuyXiuw== X-Received: by 10.28.14.144 with SMTP id 138mr15835218wmo.96.1473761309174; Tue, 13 Sep 2016 03:08:29 -0700 (PDT) Received: from ?IPv6:2a01:e35:1381:3430:5d2a:dbd5:c77c:ac65? ([2a01:e35:1381:3430:5d2a:dbd5:c77c:ac65]) by smtp.gmail.com with ESMTPSA id m5sm28735894wmd.1.2016.09.13.03.08.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 13 Sep 2016 03:08:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Luigi Iannone In-Reply-To: <551BDE7B-6BA3-4336-B92A-395FBE4A571D@gmail.com> Date: Tue, 13 Sep 2016 12:08:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <551BDE7B-6BA3-4336-B92A-395FBE4A571D@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.3124) Archived-At: Cc: rtg-ads@ietf.org, LISP mailing list list , draft-ietf-lisp-lcaf.all@ietf.org, rtg-dir@ietf.org Subject: Re: [lisp] RtgDir review: draft-ietf-lisp-lcaf-14.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 13 Sep 2016 10:08:37 -0000 Hi Stig, thanks for the review. Just a quick comment on one of the last point you raised: > On 08 Sep 2016, at 23:02, Dino Farinacci wrote: >=20 [snip] >=20 >> Section 7 >> It looks like the table in the IANA considerations doesn't include = all >> the types defined in this document. >=20 > That was done intentionally. The ones that are experimental are not in = this section 7 list because there is no use-case document for it yet. = Maybe the chairs can explain this better than me. >=20 AFAIR the rationale was that since these types are experimental = proposals, with no (or at least not yet) detailed use-case, there is no = need to allocate these values now. If new documents will use them, than those documents will require = allocation in their IANA section. ciao L. =20 >> I'm happy to discuss my comments if needed, and also review any >> updates to this draft. >>=20 >> Stig >=20 > Let me know about the response where I didn=E2=80=99t make any = changes. >=20 > Thanks again, > Dino/Dave/Job >=20 > >=20 > From nobody Fri Sep 16 10:29:40 2016 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 D6E7C12B154 for ; Fri, 16 Sep 2016 10:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lispers-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 wAi5pQK75p9U for ; Fri, 16 Sep 2016 10:29:36 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 457CF12B061 for ; Fri, 16 Sep 2016 10:29:36 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id b187so48511593wme.1 for ; Fri, 16 Sep 2016 10:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lispers-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:subject:date:references:to :message-id:mime-version; bh=W8tbiu7kdYLzu0AlskFmi0Ci+qv9PJfipGDwbLZjQmU=; b=1WWF12k+B+9ro6Fdikayh3FX6qplDx2/Knp6O/Vpz9ylCwLG3LfvBJu7OupfJ3/68b pCs5RvXnXglfr1Ca3sokSJeRnsJsOEZHYvTPQIhM6biha4ciMp1vlfcjDWSGxSzXbnrl ggcB8ktD4zXyfYYdDR9wwurVGsCcxWI22VqW4IAFmdjArrITUuGSH82vVdISxJIzVqT1 NI/mrCaEUNo6hkL2/yYe9G6waJB6Z+/mljsKrOz9IqeF+y9fphZiqJQn001FRZ7rfDC0 Xs5tbblnbEHDDBA9YH+uEegp5hvbIfxqLjQiK2tPj+SxPZa69nGpNQz14JtAr9gwEPiD JPrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject:date :references:to:message-id:mime-version; bh=W8tbiu7kdYLzu0AlskFmi0Ci+qv9PJfipGDwbLZjQmU=; b=kgoy2wVqzHm4BRvRFmrPEwgD4tn9oisICGqQw3DrHMjTw9FBKWJu8Wekfi88i3z9Dl dmB61HDLErXCvoq53v7x0ZpUgj8ayBoqJGpWyDSDib6kg55AxnzMiWsx+6xpyUP0w9BU a0BqYwNzaJfLrwyo272WN0R43Q+3vu/RsurRj9ZP/9LyyUBcAX/HIOvi/xTwsgeR3pqd i/mjtkcGzka6OnWJWbaR5BbSH6W7vJyvtk0jhO/P52gdq5Fw9jM4FfFUnxnm5Thcs0GR 2ROEZ9SjJSSSxLAge4MSfts9/SZvgjzJaKBlQBY+kfnt7ULA9sBaniSaPQj2p/R7hMwa NQzg== X-Gm-Message-State: AE9vXwP4k0bV8sC62+cym0+ZaNpsSvqBH3iL2bLDmD1xR4hjzkiGvnoKdo9UtHsPBfIqrA== X-Received: by 10.194.105.37 with SMTP id gj5mr14801770wjb.113.1474046974233; Fri, 16 Sep 2016 10:29:34 -0700 (PDT) Received: from [192.168.0.46] ([31.216.237.178]) by smtp.gmail.com with ESMTPSA id ml1sm9318247wjb.46.2016.09.16.10.29.33 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 16 Sep 2016 10:29:33 -0700 (PDT) From: Dino Farinacci Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Sep 2016 10:29:36 -0700 References: <147389225542.29861.17903245494719063870.idtracker@ietfa.amsl.com> To: LISP mailing list list Message-Id: <3884EBC9-1BFB-4BFE-9217-983250C62ED8@lispers.net> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [lisp] Fwd: I-D Action: draft-padma-ideas-problem-statement-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 16 Sep 2016 17:29:39 -0000 FYI. Dino > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: I-D Action: draft-padma-ideas-problem-statement-00.txt > Date: September 14, 2016 at 3:30:55 PM PDT > To: > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Problem Statement for Mapping Systems in = Identity Enabled Networks > Authors : Padma Pillay-Esnault > Dino Farinacci > Dave Meyer > David Lake > Tom Herbert > Michael Menthe > Dipenkar (Ray) Raychaudhuri > Julius Mueller > Filename : draft-padma-ideas-problem-statement-00.txt > Pages : 25 > Date : 2016-09-14 >=20 > Abstract: > This document provides a brief overview of Identity Enabled Networks > (IDEAS) and discusses the need for a standardized network mapping > system that is scalable, robust and flexible for future networks. > This memo also identifies several key areas that should be > investigated for the architecture design of these network mapping > systems and their protocol interfaces. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-padma-ideas-problem-statement/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-padma-ideas-problem-statement-00 >=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 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Sep 19 08:57:23 2016 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 7352F12B4A5; Mon, 19 Sep 2016 08:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.288 X-Spam-Level: X-Spam-Status: No, score=-1.288 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_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_HTML_ATTACH=0.01] 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 wOM1SG6HZkOC; Mon, 19 Sep 2016 08:57:10 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBCA812B46D; Mon, 19 Sep 2016 08:55:04 -0700 (PDT) Received: by mail-pa0-x231.google.com with SMTP id oz2so45335346pac.2; Mon, 19 Sep 2016 08:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=PB+eTparWnoZlMg5Y52rkU+qIXvWYxlCuY1aUDsdbDk=; b=t16Hh3BiJqTnciihMfJri5zXkLc4o6nxC198NN/vjNcKeQLSt+S/+9qftzzunqMxci SUdgcuPnh6m5IkxEX8UCj6D6k8nFGg3urynJl3wcdnB6+HVRnJfimIIl18OTXBLwCOaD vLl2xlUQsOPsUxoIjgUc0/LAnpEoe4OpbruUOjL6XG5w8Sp6P7JDcw/EeShLTU+UrUrZ A3oIP8Z5pEL2DlxMAH2uZ1TU/KIXkq4m2yqeFVoYhUMLR6QOPLVHcA6KqEeD2JhHQ+EI RLH3BkVuxRt3Fx9bhYEYqw1RhIn45jGpFQW7Fa9CXmLPpmzGuT889AXfIoMRBXiCW0Ft 1qAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=PB+eTparWnoZlMg5Y52rkU+qIXvWYxlCuY1aUDsdbDk=; b=VIHK9LYZnam6Bx4iXrRNM1iy/Eo6RYEtJimbtIlGBSRxy9LHDBv31aGB3fC6xLaiV4 RTNPM/iACrTr8xFSCVzCvnbXVXGeG5lBrVJAur+Z3CKu1m+b1wd1bzK7LHyIepksKdpc KaVPcsa5s4n5g3w8esYcZUrsSknY/ndCp7yUnUDD4z2aQuBAko3yWe2UhCo/jRzP6Fi7 hYD028LeNpjDicEYIZFY5QGZx2bdo/lBj1wvho+6hwqQ6Tei+1UQlxTNvDFtBqMWVjnt 7p3Ea+IV35NElD7/o89e+0Sa36+xI3AWUCnEcPIHNtbSfdcrzkXdNBnNwxB9GvQ+m2qf f5Sw== X-Gm-Message-State: AE9vXwPD3iIzpRNjvsdKki0wsQgXmRzDbwvthzsyVULcoL/vLVYkpn1vH7PYKLjlIvj8Rg== X-Received: by 10.66.120.69 with SMTP id la5mr37858718pab.65.1474300504350; Mon, 19 Sep 2016 08:55:04 -0700 (PDT) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id e1sm32669087pap.11.2016.09.19.08.54.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 19 Sep 2016 08:55:02 -0700 (PDT) Content-Type: multipart/mixed; boundary="Apple-Mail=_3612B9A9-65E7-45CD-BFD8-EE24EBFDD2E4" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: Date: Mon, 19 Sep 2016 08:54:55 -0700 Message-Id: <606F6D6C-B9A9-402E-8C04-96EF867C6E89@gmail.com> References: <551BDE7B-6BA3-4336-B92A-395FBE4A571D@gmail.com> To: Stig Venaas X-Mailer: Apple Mail (2.3124) Archived-At: Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, LISP mailing list list , draft-ietf-lisp-lcaf.all@ietf.org Subject: Re: [lisp] RtgDir review: draft-ietf-lisp-lcaf-14.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 19 Sep 2016 15:57:19 -0000 --Apple-Mail=_3612B9A9-65E7-45CD-BFD8-EE24EBFDD2E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 9, 2016, at 4:15 PM, Stig Venaas wrote: >=20 >>> In section 3 we have this paragraph: >>>=20 >>> The Address Family AFI definitions from [AFI] only allocate code- >>> points for the AFI value itself. The length of the address or = entity >>> that follows is not defined and is implied based on conventional >>> experience. Where the LISP protocol uses LISP Canonical Addresses >>> specifically, the address length definitions will be in this >>> specification and take precedent over any other specification. >>>=20 >>> I'm not sure what conventional experience means. Please try to find = a >>=20 >> Well like I said above, the AFI values defined in the AFI document = are just type values and there is no length defined. So =E2=80=9Cconventio= nal wisdom=E2=80=9D means that if a spec says an AFI value 1 is IPv4, we = know what follows is 4 bytes. Ditto for IPv6, MAC addresses, etc. >=20 > In theory there should be standards/documents specifying this for each > of the address types, and maybe could write that people should see the > respective standards or something. I don't know if this exists for all > the types though. It does not. But how about I promise you that when there is a new = use-case for a specific AFI, we=E2=80=99ll make sure that the AFI and = its length are defined in that use-case document. Like I said, we have this for AFI=3D17 already. So I have already set an = example. >> better way to say it. Regarding the last sentence, what if a you want >>> to define new LCAF encodings in the future? Is it good to say that = this >>> specification takes precedent over any other? >>=20 >> LCAF encodings and definitions do not change the length of an AFI = encoded address. So I am not sure what you mean. >=20 > The last sentence says "Where the LISP protocol uses LISP Canonical > Addresses specifically, the address length definitions will be in this > specification and take precedent over any other specification.". What > if you in the future would like to write a separate specification that > defines additional LISP Canonical address formats? Okay, I have clarified that new LCAFs that are defined in other = documents will specify length and formatting definitions. >> In section 3 we have this paragraph: >>>=20 >>> Length: this 16-bit field is in units of bytes and covers all of = the >>> LISP Canonical Address payload, starting and including the byte >>> after the Length field. So any LCAF encoded address will have a >>> minimum length of 8 bytes when the Length field is 0. The 8 = bytes >>> include the AFI, Flags, Type, Reserved, and Length fields. When >>> the AFI is not next to encoded address in a control message, = then >>> the encoded address will have a minimum length of 6 bytes when = the >>> Length field is 0. The 6 bytes include the Flags, Type, = Reserved, >>> and Length fields. >>>=20 >>> Can you phrase this differently? First it says that any LCAF encoded >>=20 >> No not really. It is precise up to the sentence =E2=80=9CWhen the AFI = is not ..=E2=80=9D. >>=20 >>> address has a minimum length of 8, but then it goes on to say how it >>> sometimes is only 6. I understand what you're trying to say, but = there >>> may be a better way of stating it. >>=20 >> This special case is for some LISP control-messages where the AFI is = another place in the message but the address is somewhere else. Rather = than have the AFI appear twice, the LCAF length needs to be different. >>=20 >> The length field always includes the entire contiguous set of LCAF = bytes including type, flags, length field, etc. >>=20 >> The language is precise and accurate. Let me know how you think = stating what I did in this comment response can be put in without = writing a lot of text about a special case. >=20 > The problem I see is that first you write "So any LCAF encoded address > will have a minimum length of 8 bytes when the Length field is 0." and > then you write "then the encoded address will have a minimum length of > 6 bytes when the Length field is 0." I understand what you mean, but I > feel this is a bit confusing. >=20 > Maybe you could say something like: >=20 > When including the AFI, an LCAF encoded address will have a minimum > length of 8 bytes when the Length field is 0. Or start by saying that > the minimal length is 6, and then say that it will then be 8 when the > AFI is included. Changed to add your suggestion. Thanks. >>> Section 4.10 >>> In this section there are several examples of using the AFI List = Type, >>> but I miss a general definition. It appears that there can be a = variable >>> number of AFIs in the list. Any number > 0? It might be useful to = have >>=20 >> Yes, a variable number. >=20 > How about adding a few lines of text to 4.10 saying that you can have > a variable number etc., explaining briefly what the general format is. > And then say that what follows are examples? Done. > Section 4.10.3 >>> Isn't it unusual to include the 0 termination? Since you know the >>> length it is not really needed. When parsing one will need to check >>> the length either way, what should one do it the string accidentally >>> is not 0-terminated? >>=20 >> Well the AFI definition in [AFI] doesn=E2=80=99t say how to terminate = the string. But the length field will imply it. However, I wrote the = =E2=80=9Cdistinguished-name=E2=80=9D draft to specify when AFI=3D17 is = used (not only in a LCAF but by itself), how to terminate the string. I = could include that reference, but that draft is not a working group = document. >>=20 >> So please advise. >=20 > Currently it says: >=20 > Length value n: length in bytes AFI=3D17 field and the = null-terminated > ASCII string (the last byte of 0 is included). >=20 > It might make sense to 0 terminate the DN in some cases, but at least > here we know the string length from the value of n, so I think it > would be better to drop it here. And as I mentioned, you cannot rely > on the 0 for parsing, to be on the safe side you would use n anyway. You want to terminate the string in all cases. Because there are cases = where AFI=3D17 is not used inside an LCAF encoding. And where there is = no length to convey the string length. And the Distinguished-Name = use-case Internet Draft specs this for both LCAF and non-LCAF = applications. >>> Section 7 >>> It looks like the table in the IANA considerations doesn't include = all >>> the types defined in this document. >>=20 >> That was done intentionally. The ones that are experimental are not = in this section 7 list because there is no use-case document for it yet. = Maybe the chairs can explain this better than me. >=20 > I think it's still useful. If someone sees the type used, they can > look it up in the registry. It also helps avoid that someone perhaps > tries to reuse one of these types in new documents. If you really want > to use one of the code points for something else in the future, a new > document could always update the registry. Did Luigi=E2=80=99s response satisfy your comment? > BTW, it also makes me wonder if it is worth reserving any LCAF types > for experiments. The space is large enough for FCFS.=20 > Regards, > Stig See new version enclosed. Let me know when I can post it if you like the = changes. Thanks again, Dino --Apple-Mail=_3612B9A9-65E7-45CD-BFD8-EE24EBFDD2E4 Content-Disposition: attachment; filename=lcaf-rfcdiff.html Content-Type: text/html; name="lcaf-rfcdiff.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-lisp-lcaf-14.txt - = draft-ietf-lisp-lcaf-15.txt=20 =20 =20 =20 =20 =20 =20= = = = = =
< draft-ietf-lisp-lcaf-14.txt  =  draft-ietf-lisp-lcaf-15.txt >
=
Network Working = Group D. Farinacci = Network Working Group = D. Farinacci
Internet-Draft = lispers.net Internet-Draft = lispers.net
Intended status: = Experimental D. Meyer = Intended status: Experimental = D. Meyer
Expires: January 20, 2017 = Brocade Expires: March 23, 2017 = Brocade
= J. Snijders = J. Snijders
= NTT Communications = NTT Communications
= = July 19, 2016 = September 19, 2016
=
= LISP Canonical Address Format (LCAF) = LISP Canonical Address Format (LCAF)
= draft-ietf-lisp-lcaf-14 = = draft-ietf-lisp-lcaf-15
=
Abstract = Abstract
=
This draft = defines a canonical address format encoding used in LISP = This draft defines a canonical address = format encoding used in LISP
control = messages and in the encoding of lookup keys for the LISP = control messages and in the encoding of = lookup keys for the LISP
Mapping = Database System. Mapping Database = System.
=
Requirements = Language Requirements Language
=
The key words = "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", = "SHALL", "SHALL NOT",
=
skipping to = change at = page 1, line 41 =C2=B6 = skipping to change at page 1, line 41 =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 = http://datatracker.ietf.org/drafts/current/. Drafts is at = http://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 January 20, = 2017. This Internet-Draft will = expire on March 23, 2017.
=
Copyright = Notice Copyright Notice
=
Copyright (c) = 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
= (http://trustee.ietf.org/license-info) in effect on the date of = (http://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
=
skipping to = change at = page 2, line 23 =C2=B6 = skipping to change at page 2, line 23 =C2=B6
=
1. = Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 3 1. Introduction . . . . . . . . = . . . . . . . . . . . . . . . . 3
2. Definition = of Terms . . . . . . . . . . . . . . . . . . . . . 4 2. Definition of Terms . . . . . . . . . . . . . . . = . . . . . . 4
3. LISP = Canonical Address Format Encodings . . . . . . . . . . . 5 = 3. LISP Canonical Address Format Encodings = . . . . . . . . . . . 5
4. LISP = Canonical Address Applications . . . . . . . . . . . . . 7 = 4. LISP Canonical Address Applications . . = . . . . . . . . . . . 7
4.1. = Segmentation using LISP . . . . . . . . . . . . . . . . . 7 = 4.1. Segmentation using LISP . . . . . . = . . . . . . . . . . . 7
4.2. = Carrying AS Numbers in the Mapping Database . . . . . . . 9 = 4.2. Carrying AS Numbers in the Mapping = Database . . . . . . . 9
4.3. = Assigning Geo Coordinates to Locator Addresses . . . . . 10 = 4.3. Assigning Geo Coordinates to Locator = Addresses . . . . . 10
4.4. NAT = Traversal Scenarios . . . . . . . . . . . . . . . . . 12 = 4.4. NAT Traversal Scenarios . . . . . . = . . . . . . . . . . . 12
4.5. = Multicast Group Membership Information . . . . . . . . . 14 = 4.5. Multicast Group Membership = Information . . . . . . . . . 14
4.6. = Traffic Engineering using Re-encapsulating Tunnels . . . 15 4.6. = Traffic Engineering using Re-encapsulating Tunnels . . . 16
4.7. = Storing Security Data in the Mapping Database . . . . . . 17 = 4.7. Storing Security Data in the Mapping = Database . . . . . . 17
4.8. = Source/Destination 2-Tuple Lookups . . . . . . . . . . . 18 4.8. = Source/Destination 2-Tuple Lookups . . . . . . . . . . . 19
4.9. = Replication List Entries for Multicast Forwarding . . . . 20 4.9. = Replication List Entries for Multicast Forwarding . . . . 21
4.10. = Applications for AFI List Type . . . . . . . . . . . . . 21 4.10. = Applications for AFI List Type . . . . . . . . . . . . . 22
4.10.1. = Binding IPv4 and IPv6 Addresses . . . . . . . . . . 21 = 4.10.1. Binding IPv4 and IPv6 Addresses . . . . . . . . . . 22
4.10.2. = Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . 22 = 4.10.2. Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . 23
4.10.3. = ASCII Names in the Mapping Database . . . . . . . . 23 = 4.10.3. ASCII Names in the Mapping Database . . . . . . . . 24
4.10.4. = Using Recursive LISP Canonical Address Encodings . . 24 = 4.10.4. Using Recursive LISP Canonical Address Encodings . . 25
4.10.5. = Compatibility Mode Use Case . . . . . . . . . . . . 25 = 4.10.5. Compatibility Mode Use Case . . . . . . . . . . . . 26
5. = Experimental LISP Canonical Address Applications . . . . . . 26 5. = Experimental LISP Canonical Address Applications . . . . . . 27
5.1. = Convey Application Specific Data . . . . . . . . . . . . 26 5.1. = Convey Application Specific Data . . . . . . . . . . . . 27
5.2. = Generic Database Mapping Lookups . . . . . . . . . . . . 27 5.2. = Generic Database Mapping Lookups . . . . . . . . . . . . 28
5.3. PETR = Admission Control Functionality . . . . . . . . . . 29 5.3. = PETR Admission Control Functionality . . . . . . . . . . 30
5.4. Data = Model Encoding . . . . . . . . . . . . . . . . . . . 30 5.4. = Data Model Encoding . . . . . . . . . . . . . . . . . . . 31
5.5. = Encoding Key/Value Address Pairs . . . . . . . . . . . . 31 5.5. = Encoding Key/Value Address Pairs . . . . . . . . . . . . 32
5.6. = Multiple Data-Planes . . . . . . . . . . . . . . . . . . 32 5.6. = Multiple Data-Planes . . . . . . . . . . . . . . . . . . 33
6. Security = Considerations . . . . . . . . . . . . . . . . . . . 34 6. = Security Considerations . . . . . . . . . . . . . . . . . . . 36
7. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 34 7. = IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
8. = References . . . . . . . . . . . . . . . . . . . . . . . . . 35 8. = References . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.1. = Normative References . . . . . . . . . . . . . . . . . . 35 8.1. = Normative References . . . . . . . . . . . . . . . . . . 37
8.2. = Informative References . . . . . . . . . . . . . . . . . 36 8.2. = Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 37 = Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 39
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 38 = Appendix B. Document Change Log . . . . . . . . . . . . . . . . 40
B.1. = Changes to draft-ietf-lisp-lcaf-14.txt . = . . . . . . . . 38 B.1. Changes to draft-ietf-lisp-lcaf-15.txt . . . . . . . . . = 40
B.2. = Changes to draft-ietf-lisp-lcaf-13.txt . = . . . . . . . . 38 B.2. Changes to draft-ietf-lisp-lcaf-14.txt . . . . . . . . . = 40
B.3. = Changes to draft-ietf-lisp-lcaf-12.txt . = . . . . . . . . 38 B.3. Changes to draft-ietf-lisp-lcaf-13.txt . . . . . . . . . = 40
B.4. = Changes to draft-ietf-lisp-lcaf-11.txt . = . . . . . . . . 38 B.4. Changes to draft-ietf-lisp-lcaf-12.txt . . . . . . . . . = 40
B.5. = Changes to draft-ietf-lisp-lcaf-10.txt . = . . . . . . . . 38 B.5. Changes to draft-ietf-lisp-lcaf-11.txt . . . . . . . . . = 40
B.6. = Changes to draft-ietf-lisp-lcaf-09.txt . = . . . . . . . . 39 B.6. Changes to draft-ietf-lisp-lcaf-10.txt . . . . . . . . . = 41
B.7. = Changes to draft-ietf-lisp-lcaf-08.txt . = . . . . . . . . 39 B.7. Changes to draft-ietf-lisp-lcaf-09.txt . . . . . . . . . = 41
B.8. = Changes to draft-ietf-lisp-lcaf-07.txt . = . . . . . . . . 39 B.8. Changes to draft-ietf-lisp-lcaf-08.txt . . . . . . . . . = 41
B.9. = Changes to draft-ietf-lisp-lcaf-06.txt . = . . . . . . . . 39 B.9. Changes to draft-ietf-lisp-lcaf-07.txt . . . . . . . . . = 41
B.10. = Changes to draft-ietf-lisp-lcaf-05.txt . = . . . . . . . . 39 B.10. Changes to draft-ietf-lisp-lcaf-06.txt . . . . . . . . . = 41
B.11. = Changes to draft-ietf-lisp-lcaf-04.txt . = . . . . . . . . 39 B.11. Changes to draft-ietf-lisp-lcaf-05.txt . . . . . . . . . = 41
B.12. = Changes to draft-ietf-lisp-lcaf-03.txt . = . . . . . . . . 40 B.12. Changes to draft-ietf-lisp-lcaf-04.txt . . . . . . . . . = 42
B.13. = Changes to draft-ietf-lisp-lcaf-02.txt . = . . . . . . . . 40 B.13. Changes to draft-ietf-lisp-lcaf-03.txt . . . . . . . . . = 42
B.14. = Changes to draft-ietf-lisp-lcaf-01.txt . = . . . . . . . . 40 B.14. Changes to draft-ietf-lisp-lcaf-02.txt . . . . . . . . . = 42
B.15. = Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . 40 B.15. = Changes to draft-ietf-lisp-lcaf-01.txt . . . . . = . . . . 42
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 B.16. Changes to = draft-ietf-lisp-lcaf-00.txt . . . . . . . . . 42
= Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 43
=
1. = Introduction 1. Introduction
=
The LISP = architecture and protocols [RFC6830] introduces two new = The LISP architecture and protocols = [RFC6830] introduces two new
numbering = spaces, Endpoint Identifiers (EIDs) and Routing Locators = numbering spaces, Endpoint Identifiers = (EIDs) and Routing Locators
(RLOCs). To = provide flexibility for current and future applications, = (RLOCs). To provide flexibility for current = and future applications,
these values = can be encoded in LISP control messages using a general = these values can be encoded in LISP control = messages using a general
syntax that = includes Address Family Identifier (AFI), length, and syntax that includes Address Family Identifier (AFI), = length, and
value = fields. value fields.
=
=
skipping to = change at = page 4, line 28 =C2=B6 = skipping to change at page 4, line 28 =C2=B6
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
This document = describes the currently-defined AFIs the LISP protocol This document describes the currently-defined AFIs = the LISP protocol
uses along = with their encodings and introduces the LISP Canonical uses along with their encodings and introduces the = LISP Canonical
Address Format = (LCAF) that can be used to define the LISP-specific Address Format (LCAF) that can be used to define the = LISP-specific
encodings for = arbitrary AFI values. encodings for = arbitrary AFI values.
=
2. Definition of = Terms 2. Definition of Terms
=
Address Family = Identifier (AFI): a term used to describe an address Address Family Identifier (AFI): a term used to = describe an address
encoding = in a packet. There is an address family = currently encoding in a = packet. Address families are defined for = IPv4 and
defined = for IPv4 or IPv6 addresses. See [AFI] and = [RFC3232] for = IPv6. See [AFI] and [RFC3232] for details. The reserved = AFI
details. = The reserved AFI value of 0 is used in this value of 0 is used in this specification to = indicate an
= specification to indicate an unspecified encoded address where = the unspecified encoded address = where the length of the address is 0
length of = the address is 0 bytes following the 16-bit AFI value of = bytes following the 16-bit AFI value of = 0.
= 0.
=
Unspecified = Address Format: Unspecified Address = Format:
=
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
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D 0 | <nothing follows AFI=3D0> | = | AFI =3D 0 | = <nothing follows AFI=3D0> |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Endpoint ID = (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value = Endpoint ID (EID): a 32-bit (for IPv4) or = 128-bit (for IPv6) value
=
skipping to = change at = page 5, line 26 =C2=B6 = skipping to change at page 5, line 26 =C2=B6
=
IANA has = assigned AFI value 16387 (0x4003) to the LISP architecture = IANA has assigned AFI value 16387 (0x4003) = to the LISP architecture
and protocols. = This specification defines the encoding format of the and protocols. This specification defines the = encoding format of the
LISP Canonical = Address (LCA). This section defines all types for LISP Canonical Address (LCA). This section defines = all types for
which an = initial allocation in the LISP-LCAF registry is requested. = which an initial allocation in the LISP-LCAF = registry is requested.
See IANA = Considerations section for the complete list of such types. = See IANA Considerations section for the = complete list of such types.
=
The Address = Family AFI definitions from [AFI] only allocate code- The Address Family AFI definitions from [AFI] only = allocate code-
points for the = AFI value itself. The length of the address or entity points for the AFI value itself. The length of the = address or entity
that follows = is not defined and is implied based on conventional that follows is not defined and is implied based on = conventional
experience. = Where the LISP protocol uses LISP Canonical Addresses experience. When the = LISP protocol uses LCAF definitions from = this
specifically, the address length definitions will be in this = document, the = AFI-based address lengths are specified in this
specification and take precedent over any other = specification. document. When new LCAF = definitions are defined in other use-case
= documents, the = AFI-based address lengths for any new AFI encoded
= addresses are = specified in those documents.
=
The first 6 = bytes of an LISP Canonical Address are followed by a The first 6 bytes of an LISP Canonical Address are = followed by a
variable = number of fields of variable length: = variable number of fields of variable length:
=
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
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D 16387 | Rsvd1 | Flags | = | AFI =3D 16387 | = Rsvd1 | Flags |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = | Rsvd2 | Length | | Type | Rsvd2 | Length = |
=
skipping to = change at = page 6, line 34 =C2=B6 = skipping to change at page 6, line 36 =C2=B6
Type 12: = Source/Dest Key Type Type 12: = Source/Dest Key Type
=
Type 13: = Replication List Entry Type Type = 13: Replication List Entry Type
=
Type 14: = JSON Data Model Type Type 14: = JSON Data Model Type
=
Type 15: = Key/Value Address Pair Type Type = 15: Key/Value Address Pair Type
=
Type 16: = Encapsulation Format Type Type = 16: Encapsulation Format Type
=
Rsvd2: this = 8-bit field is reserved for future use and MUST be Rsvd2: this LCAF Type = dependent 8-bit field is reserved for future
= transmitted as 0 and ignored on receipt. use and MUST be transmitted as 0 and ignored on = receipt. See
= specific LCAF = Type for specific bits not reserved.
=
Length: this = 16-bit field is in units of bytes and covers all of the = Length: this 16-bit field is in units of = bytes and covers all of the
LISP = Canonical Address payload, starting and including the byte = LISP Canonical Address payload, starting = and including the byte
after the = Length field. So any LCAF encoded address = will have a after the Length = field. When including the AFI, an LCAF = encoded
minimum = length of 8 bytes when the Length field is 0. The 8 bytes = address will have a minimum length of 8 = bytes when the Length
include = the AFI, Flags, Type, Reserved, and Length fields. When = field is 0. The 8 bytes include the = AFI, Flags, Type, Reserved,
the AFI = is not next to encoded address in a control message, then = and Length fields. When the AFI is not = next to encoded address in
the = encoded address will have a minimum length of 6 bytes when the = a control message, then the encoded = address will have a minimum
Length = field is 0. The 6 bytes include the Flags, Type, Reserved, = length of 6 bytes when the Length field = is 0. The 6 bytes include
and = Length fields. the Flags, Type, = Reserved, and Length fields.
=
[RFC6830] = states RLOC records are sorted when encoded in control [RFC6830] states RLOC records are sorted when encoded = in control
messages so = the locator-set has consistent order across all xTRs for = messages so the locator-set has consistent = order across all xTRs for
a given EID. = The sort order is based on sort-key {afi, RLOC- a given EID. The sort order is based on sort-key = {afi, RLOC-
address}. When = an RLOC is LCAF encoded, the sort-key is {afi, LCAF- address}. When an RLOC is LCAF encoded, the sort-key = is {afi, LCAF-
Type}. = Therefore, when a locator-set has a mix of AFI records and = Type}. Therefore, when a locator-set has a = mix of AFI records and
LCAF = records, all LCAF records will appear after all = the AFI records. LCAF = records, they are ordered from smallest to = largest AFI value.
=
4. LISP = Canonical Address Applications 4. = LISP Canonical Address Applications
=
4.1. = Segmentation using LISP 4.1. = Segmentation using LISP
=
When multiple = organizations inside of a LISP site are using private When multiple organizations inside of a LISP site are = using private
addresses = [RFC1918] as EID-prefixes, their address spaces must remain = addresses [RFC1918] as EID-prefixes, their = address spaces must remain
segregated due = to possible address duplication. An Instance ID in segregated due to possible address duplication. An = Instance ID in
the address = encoding can aid in making the entire AFI based address = the address encoding can aid in making the = entire AFI based address
= unique. unique.
=
skipping to = change at = page 13, line 12 =C2=B6 = skipping to change at page 13, line = 12 =C2=B6
MS RLOC = Address: this is the address of the Map-Server used in the = MS RLOC Address: this is the address of the = Map-Server used in the
destination = RLOC of a packet that has flowed through a NAT device. destination RLOC of a packet that has flowed = through a NAT device.
=
Private ETR = RLOC Address: this is an address known to be a private = Private ETR RLOC Address: this is an = address known to be a private
address = inserted in this LCAF format by a LISP router that resides = address inserted in this LCAF format by a = LISP router that resides
on the = private side of a NAT device. on = the private side of a NAT device.
=
RTR RLOC = Address: this is an encapsulation address used by an ITR or = RTR RLOC Address: this is an encapsulation = address used by an ITR or
PITR which = resides behind a NAT device. This address is known to PITR which resides behind a NAT device. This = address is known to
have state = in a NAT device so packets can flow from it to the LISP = have state in a NAT device so packets can = flow from it to the LISP
ETR = behind the NAT. There can be one or more NAT Tunnel Router = ETR behind the NAT. There can be one or = more NAT Reencapsulating
(NTR) [I-D.ermagan-lisp-nat-traversal] addresses = supplied in these Tunnel Router = (RTR) [I-D.ermagan-lisp-nat-traversal] = addresses
set of = fields. The number of NTRs encoded is = determined by the supplied in = these set of fields. The number of RTRs = encoded is
LCAF = length field. When there are no NTRs = supplied, the NTR determined by the LCAF length field. When there = are no RTRs
fields = can be omitted and reflected by the LCAF length field or an = supplied, the RTR fields can be omitted and reflected by the = LCAF
AFI of 0 = can be used to indicate zero NTRs = encoded. length field or an AFI = of 0 can be used to indicate zero RTRs
= encoded.
=
Usage: This = encoding can be used in Info-Request and Info-Reply Usage: This encoding can be used in Info-Request and = Info-Reply
messages. The = mapping system does not store this information. The messages. The mapping system does not store this = information. The
information is = used by an xTR and Map-Server to convey private and information is used by an xTR and Map-Server to = convey private and
public address = information when traversing NAT and firewall devices. public address information when traversing NAT and = firewall devices.
=
4.5. Multicast = Group Membership Information 4.5. = Multicast Group Membership Information
=
Multicast = group information can be published in the mapping database. = Multicast group information can be published = in the mapping database.
So a lookup on = an group address EID can return a replication list of So a lookup on an group address EID can return a = replication list of
=
skipping to = change at = page 15, line 11 =C2=B6 = skipping to change at page 15, line = 11 =C2=B6
of = (Instance-ID, S-prefix, G-prefix). = of (Instance-ID, S-prefix, G-prefix).
=
Source = MaskLen: the mask length of the source prefix that follows. = Source MaskLen: the mask length of the = source prefix that follows.
=
Group MaskLen: = the mask length of the group prefix that follows. Group MaskLen: the mask length of the group prefix = that follows.
=
AFI =3D x: x = can be any AFI value from [AFI]. When a specific AFI has = AFI =3D x: x can be any AFI value from = [AFI]. When a specific AFI has
its own = encoding of a multicast address, this field must be either = its own encoding of a multicast address, = this field must be either
a group = address or a broadcast address. = a group address or a broadcast address.
=
= Source/Subnet = Address is the source address or prefix for encoding a
= (S,G) multicast = entry.
=
= Group Address is = the group address or group prefix for encoding
= (S,G) or (*,G) = multicast entries.
= =
Usage: This = encoding can be used in EID records in Map-Requests, Map- = Usage: This encoding can be used in EID = records in Map-Requests, Map-
Replies, = Map-Registers, and Map-Notify messages. When LISP-DDT Replies, Map-Registers, and Map-Notify messages. = When LISP-DDT
= [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, = extended [I-D.ietf-lisp-ddt] is = used as the mapping system mechanism, extended
EIDs are used = in Map-Referral messages. EIDs are = used in Map-Referral messages.
=
4.6. Traffic = Engineering using Re-encapsulating Tunnels 4.6. Traffic Engineering using Re-encapsulating = Tunnels
=
For a given = EID lookup into the mapping database, this LCAF format For a given EID lookup into the mapping database, = this LCAF format
can be = returned to provide a list of locators in an explicit re- = can be returned to provide a list of = locators in an explicit re-
encapsulation = path. See [I-D.farinacci-lisp-te] for details. encapsulation path. See [I-D.farinacci-lisp-te] for = details.
=
skipping to = change at = page 16, line 25 =C2=B6 = skipping to change at page 16, line = 31 =C2=B6
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = Reencap Hop 1 ... | | Reencap Hop 1 ... = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = Rsvd3 |L|P|S| AFI =3D x | = | Rsvd3 |L|P|S| = AFI =3D x |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = Reencap Hop k ... | | Reencap Hop k ... = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Length value = n: length in bytes of fields that follow. Length value n: length in bytes of fields that = follow.
=
= Rsvd3: this field = is reserved for future use and MUST be transmitted
= as 0 and ignored = on receipt.
= =
Lookup bit = (L): this is the Lookup bit used to indicate to the user = Lookup bit (L): this is the Lookup bit used = to indicate to the user
of the ELP = to not use this address for encapsulation but to look of the ELP to not use this address for = encapsulation but to look
it up in = the mapping database system to obtain an encapsulating it up in the mapping database system to obtain an = encapsulating
RLOC = address. RLOC address.
=
RLOC-Probe bit = (P): this is the RLOC-probe bit which means the RLOC-Probe bit (P): this is the RLOC-probe bit which = means the
Reencap Hop = allows RLOC-probe messages to be sent to it. When the Reencap Hop allows RLOC-probe messages to be sent = to it. When the
R-bit is = set to 0, RLOC-probes must not be sent. When a Reencap = R-bit is set to 0, RLOC-probes must not = be sent. When a Reencap
Hop is an = anycast address then multiple physical Reencap Hops are = Hop is an anycast address then multiple = physical Reencap Hops are
using the = same RLOC address. In this case, RLOC-probes are not using the same RLOC address. In this case, = RLOC-probes are not
=
skipping = to change at page 17, line = 35 =C2=B6 = skipping to change at page 18, line = 29 =C2=B6
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D x | Locator Address ... | | AFI =3D x | Locator = Address ... |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Length value = n: length in bytes of fields that start with the Key Length value n: length in bytes of fields that start = with the Key
Material = field. Material field.
=
Key Count: = the Key Count field declares the number of Key sections = Key Count: the Key Count field declares the = number of Key sections
included in = this LCAF. included in this = LCAF.
=
= Rsvd3: this field = is reserved for future use and MUST be transmitted
= as 0 and ignored = on receipt.
= =
Key Algorithm: = the Algorithm field identifies the key's Key Algorithm: the Algorithm field identifies the = key's
= cryptographic algorithm and specifies the format of the Public = Key cryptographic algorithm and = specifies the format of the Public Key
= field. field.
=
= Rsvd4: this field = is reserved for future use and MUST be transmitted
= as 0 and ignored = on receipt.
= =
R bit: this = is the revoke bit and, if set, it specifies that this R bit: this is the revoke bit and, if set, it = specifies that this
Key is = being Revoked. Key is being = Revoked.
=
Key Length: = this field determines the length in bytes of the Key Key Length: this field determines the length in = bytes of the Key
Material = field. Material field.
=
Key Material: = the Key Material field stores the key material. The Key Material: the Key Material field stores the key = material. The
format of = the key material stored depends on the Key Algorithm format of the key material stored depends on the = Key Algorithm
= field. field.
=
=
skipping = to change at page 21, line = 10 =C2=B6 = skipping to change at page 22, line = 10 =C2=B6
Reply = message. Reply message.
=
Usage: This = encoding can be used in RLOC records in Map-Requests, Usage: This encoding can be used in RLOC records in = Map-Requests,
Map-Replies, = Map-Registers, and Map-Notify messages. = Map-Replies, Map-Registers, and Map-Notify messages.
=
4.10. = Applications for AFI List Type 4.10. = Applications for AFI List Type
=
4.10.1. Binding = IPv4 and IPv6 Addresses 4.10.1. = Binding IPv4 and IPv6 Addresses
=
When header = translation between IPv4 and IPv6 is desirable a LISP When header translation between IPv4 and IPv6 is = desirable a LISP
Canonical = Address can use the AFI List Type to carry multiple AFIs in Canonical Address can use the AFI List Type to carry = a variable
one LCAF = AFI. number = of AFIs in one LCAF AFI.
=
Address = Binding LISP Canonical Address Format: = Address Binding LISP Canonical Address Format:
=
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
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D 16387 | Rsvd1 | Flags | = | AFI =3D 16387 | = Rsvd1 | Flags |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type =3D 1 = | Rsvd2 | 2 + 4 + 2 + 16 | | Type =3D 1 | Rsvd2 | 2 + 4 + 2 = + 16 |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
skipping = to change at page 28, line = 5 =C2=B6 = skipping to change at page 29, line = 5 =C2=B6
| Type =3D 6 = | Rsvd2 | 3 + n | | Type =3D 6 | Rsvd2 | 3 + n = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Field = Num | Key Wildcard Fields | Key . . . | | Key Field Num | Key Wildcard Fields | = Key . . . |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = . . . Key | | . . . Key = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Length value = n: length in bytes of the type's payload. The value n = Length value n: length in bytes of the = type's payload. The value n
is the = number of bytes that follow this Length field. is the number of bytes that follow this Length = field.
=
Key Field = Num: the number of fields (minus 1) the = key can be broken Key Field Num: the value of = this field is the the number of "Key"
up into. = The width of the fields are fixed length. = So for a key = sub-fields minus 1, the "Key" = field can be broken up into. So = if
size of 8 = bytes, with a Key Field Num of 4 allows 4 = fields of 2 this field has a value of = 0, there is 1 sub-field in the "Key".
bytes in = length. Allowing for a reasonable number of 16 field The width of the sub-fields are fixed length. So for a key = size
= separators, valid values range from 0 to 15. of 8 bytes, with a Key Field Num of 3, allows 4 sub-fields of 2
= bytes each = in length. Allowing for a reasonable number of 16 sub-
= field separators, valid values range = from 0 to 15.
=
Key Wildcard = Fields: describes which fields in the key are not used = Key Wildcard Fields: describes which fields = in the key are not used
as part of = the key lookup. This wildcard encoding is a bitfield. as part of the key lookup. This wildcard encoding = is a bitfield.
Each bit is = a don't-care bit for a corresponding field in the key. Each bit is a don't-care bit for a corresponding = field in the key.
Bit 0 (the = low-order bit) in this bitfield corresponds the first Bit 0 (the low-order bit) in this bitfield = corresponds the first
field, = right-justified in the key, bit 1 the = second field, and so field, = the low-order field in the key, bit 1 the = second field, and
on. When = a bit is set in the bitfield it is a don't-care bit and = so on. When a bit is set in the = bitfield it is a don't-care bit
should = not be considered as part of the database lookup. When the = and should not be considered as part of = the database lookup. When
entire = 16-bits is set to 0, then all bits of the key are used for = the entire 16-bits is set to 0, then all = bits of the key are used
the = database lookup. for the = database lookup.
=
Key: the = variable length key used to do a LISP Database Mapping Key: the variable length key used to do a LISP = Database Mapping
lookup. = The length of the key is the value n (shown = above) minus lookup. = The length of the key is the value n (as shown = above).
3.
=
Usage: This is = an experimental type where the usage has not been Usage: This is an experimental type where the usage = has not been
defined = yet. defined yet.
=
5.3. PETR = Admission Control Functionality 5.3. = PETR Admission Control Functionality
=
When a public = PETR device wants to verify who is encapsulating to it, = When a public PETR device wants to verify = who is encapsulating to it,
it can check = for a specific nonce value in the LISP encapsulated it can check for a specific nonce value in the LISP = encapsulated
packet. To = convey the nonce to admitted ITRs or PITRs, this LCAF packet. To convey the nonce to admitted ITRs or = PITRs, this LCAF
format is used = in a Map-Register or Map-Reply locator-record. format is used in a Map-Register or Map-Reply = locator-record.
=
skipping = to change at page 30, line = 24 =C2=B6 = skipping to change at page 31, line = 24 =C2=B6
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D 16387 | Rsvd1 | Flags | = | AFI =3D 16387 | = Rsvd1 | Flags |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type =3D = 14 | Rsvd2 |B| 2 + n | | Type =3D 14 | Rsvd2 |B| 2 + n = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = JSON length | JSON binary/text encoding ... | | JSON length | JSON binary/text = encoding ... |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D x | Optional Address ... | | AFI =3D x | Optional = Address ... |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Length value = n: length in bytes of fields that follow. = Length value n: length in bytes of the = fields that follow the "JSON
= length" = field.
=
Rsvd{1,2}: = must be set to zero and ignore on receipt. Rsvd{1,2}: must be set to zero and ignore on = receipt.
=
B bit: = indicates that the JSON field is binary encoded according to = B bit: indicates that the JSON field is = binary encoded according to
= [JSON-BINARY] when the bit is set to 1. Otherwise the encoding = is [JSON-BINARY] when the bit is = set to 1. Otherwise the encoding is
based on = text encoding according to [RFC7159]. = based on text encoding according to [RFC7159].
=
JSON length: = length in octets of the following 'JSON binary/text JSON length: length in octets of the following 'JSON = binary/text
encoding' = field. encoding' field.
=
=
skipping = to change at page 31, line = 26 =C2=B6 = skipping to change at page 32, line = 26 =C2=B6
=
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
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D 16387 | Rsvd1 | Flags | = | AFI =3D 16387 | = Rsvd1 | Flags |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type =3D = 15 | Rsvd2 | n | | Type =3D 15 | Rsvd2 | n = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D x | Address as Key ... | | AFI =3D x | Address as = Key ... |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D x | Address as = Value ... | | AFI = =3D y | Address as Value = ... |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Length value = n: length in bytes of fields that follow. Length value n: length in bytes of fields that = follow.
=
Rsvd{1,2}: = must be set to zero and ignore on receipt. Rsvd{1,2}: must be set to zero and ignore on = receipt.
=
AFI =3D x: = x can be any AFI value from [AFI]. A specific AFI has = its AFI =3D x: x is the "Address as Key" AFI that can have any value from
own = encoding of either a unicast or multicast locator address. = [AFI]. A specific AFI has its own = encoding of either a unicast or
All = RTR/ETR entries for the same level should be combined together = multicast locator address. All RTR/ETR = entries for the same level
by a = Map-Server to avoid searching through the entire multi-level = should be combined together by a = Map-Server to avoid searching
list of = locator entries in a Map-Reply = message. through the entire = multi-level list of locator entries in a Map-
= Reply = message.
=
Address as = Key: this AFI encoded address will be attached with the = Address as Key: this AFI encoded address = will be attached with the
attributes = encoded in "Address as Value" which follows this field. = attributes encoded in "Address as Value" = which follows this field.
=
= AFI =3D y: y is the = "Address of Value" AFI that can have any value
= from [AFI]. A = specific AFI has its own encoding of either a
= unicast or = multicast locator address. All RTR/ETR entries for the
= same level should = be combined together by a Map-Server to avoid
= searching through = the entire multi-level list of locator entries
= in a Map-Reply = message.
= =
Address as = Value: this AFI encoded address will be the attribute Address as Value: this AFI encoded address will be = the attribute
address = that goes along with "Address as Key" which precedes this = address that goes along with "Address as = Key" which precedes this
= field. field.
=
Usage: This is = an experimental type where the usage has not been Usage: This is an experimental type where the usage = has not been
defined = yet. defined yet.
=
5.6. Multiple = Data-Planes 5.6. Multiple = Data-Planes
=
Overlays are = becoming popular in many parts of the network which have = Overlays are becoming popular in many parts = of the network which have
=
skipping = to change at page 36, line = 19 =C2=B6 = skipping to change at page 38, line = 19 =C2=B6
=
= [I-D.coras-lisp-re] = [I-D.coras-lisp-re]
= Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., Coras, F., Cabellos-Aparicio, A., = Domingo-Pascual, J.,
= Maino, F., and D. Farinacci, "LISP Replication Maino, F., and D. Farinacci, "LISP = Replication
= Engineering", draft-coras-lisp-re-08 (work in progress), = Engineering", = draft-coras-lisp-re-08 (work in progress),
= November 2015. November = 2015.
=
= [I-D.ermagan-lisp-nat-traversal] = [I-D.ermagan-lisp-nat-traversal]
= Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, = Ermagan, V., Farinacci, D., = Lewis, D., Skriver, J., Maino,
F., = and C. White, "NAT traversal for LISP", draft-ermagan- F., and C. White, "NAT traversal for = LISP", draft-ermagan-
= lisp-nat-traversal-10 (work in progress), = February 2016. = lisp-nat-traversal-11 (work in progress), = August 2016.
=
= [I-D.farinacci-lisp-te] = [I-D.farinacci-lisp-te]
= Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic Farinacci, D., Kowal, M., and P. Lahiri, = "LISP Traffic
= Engineering Use-Cases", draft-farinacci-lisp-te-10 (work = Engineering Use-Cases", draft-farinacci-lisp-te-11 (work
= in progress), March 2016. = in progress), September 2016.
=
= [I-D.gross-geneve] = [I-D.gross-geneve]
= Gross, J., Sridhar, T., Garg, P., Wright, C., Ganga, I., = Gross, J., Sridhar, T., Garg, P., = Wright, C., Ganga, I.,
= Agarwal, P., Duda, K., Dutt, D., and J. Hudson, "Geneve: = Agarwal, P., Duda, K., Dutt, D., = and J. Hudson, "Geneve:
= Generic Network Virtualization Encapsulation", draft- Generic Network Virtualization = Encapsulation", draft-
= gross-geneve-02 (work in progress), October 2014. gross-geneve-02 (work in progress), = October 2014.
=
= [I-D.herbert-gue] = [I-D.herbert-gue]
= Herbert, T., Yong, L., and O. Zia, "Generic UDP Herbert, T., Yong, L., and O. Zia, = "Generic UDP
= Encapsulation", draft-herbert-gue-03 (work in progress), = Encapsulation", = draft-herbert-gue-03 (work in progress),
= March 2015. March = 2015.
=
= [I-D.ietf-lisp-ddt] = [I-D.ietf-lisp-ddt]
= Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Fuller, V., Lewis, D., Ermagan, V., Jain, = A., and A.
= Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp- = Smirnov, "LISP Delegated Database = Tree", draft-ietf-lisp-
= ddt-07 (work in progress), May = 2016. ddt-08 (work in progress), September 2016.
=
= [I-D.portoles-lisp-eid-mobility] = [I-D.portoles-lisp-eid-mobility]
= Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, = Portoles-Comeras, M., Ashtaputre, = V., Moreno, V., Maino,
F., = and D. Farinacci, "LISP L2/L3 EID Mobility Using a F., and D. Farinacci, "LISP L2/L3 EID = Mobility Using a
= Unified Control Plane", draft-portoles-lisp-eid- Unified Control Plane", = draft-portoles-lisp-eid-
= mobility-00 (work in progress), April 2016. mobility-00 (work in progress), April = 2016.
=
= [I-D.quinn-vxlan-gpe] = [I-D.quinn-vxlan-gpe]
= Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F., = Quinn, P., Manur, R., Kreeger, = L., Lewis, D., Maino, F.,
= Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg, = Smith, M., Agarwal, P., Yong, L., = Xu, X., Elzur, U., Garg,
=
skipping = to change at page 38, line = 9 =C2=B6 = skipping to change at page 40, line = 9 =C2=B6
Thanks goes to = Michiel Blokzijl and Alberto Rodriguez-Natal for Thanks goes to Michiel Blokzijl and Alberto = Rodriguez-Natal for
suggesting new = LCAF types. suggesting new LCAF = types.
=
Thanks also = goes to Terry Manderson for assistance obtaining a LISP = Thanks also goes to Terry Manderson for = assistance obtaining a LISP
AFI value from = IANA. AFI value from IANA.
=
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-lcaf-14.txt B.1. = Changes to draft-ietf-lisp-lcaf-15.txt
=
= o Submitted = September 2016.
=
= o Addressed = comments from Routing Directorate reviewer Stig Venass.
=
= B.2. Changes to = draft-ietf-lisp-lcaf-14.txt
=
o Submitted = July 2016. o Submitted July = 2016.
=
o Fix IDnits = errors and comments from Luigi Iannone, document o Fix IDnits errors and comments from Luigi Iannone, = document
= shepherd. shepherd.
=
B.2. Changes to = draft-ietf-lisp-lcaf-13.txt B.3. Changes to = draft-ietf-lisp-lcaf-13.txt
=
o Submitted = May 2016. o Submitted May = 2016.
=
o Explain the = Instance-ID LCAF Type is 32-bits in length and the o Explain the Instance-ID LCAF Type is 32-bits in = length and the
Instance-ID = field in the LISP encapsulation header is 24-bits. Instance-ID field in the LISP encapsulation header = is 24-bits.
=
B.3. Changes to = draft-ietf-lisp-lcaf-12.txt B.4. Changes to = draft-ietf-lisp-lcaf-12.txt
=
o Submitted = March 2016. o Submitted March = 2016.
=
o Updated = references and document timer. o = Updated references and document timer.
=
o Removed the = R, J, and L bits from the Multicast Info Type LCAF o Removed the R, J, and L bits from the Multicast = Info Type LCAF
since = working group decided to not go forward with draft- since working group decided to not go forward with = draft-
= farinacci-lisp-mr-signaling-03.txt in favor of draft- = ietf-lisp- = farinacci-lisp-mr-signaling-03.txt in favor of draft- ietf-lisp-
= signal-free-00.txt. = signal-free-00.txt.
=
B.4. Changes to = draft-ietf-lisp-lcaf-11.txt B.5. Changes to = draft-ietf-lisp-lcaf-11.txt
=
o Submitted = September 2015. o Submitted = September 2015.
=
o Reflecting = comments from Prague LISP working group. o Reflecting comments from Prague LISP working = group.
=
o Readying = document for a LISP LCAF registry, RFC publication, and = o Readying document for a LISP LCAF = registry, RFC publication, and
for new = use-cases that will be defined in the new charter. for new use-cases that will be defined in the new = charter.
=
B.5. Changes to = draft-ietf-lisp-lcaf-10.txt B.6. Changes to = draft-ietf-lisp-lcaf-10.txt
=
o Submitted = June 2015. o Submitted June = 2015.
=
o Fix = coauthor Job's contact information. = o Fix coauthor Job's contact information.
=
B.6. Changes to = draft-ietf-lisp-lcaf-09.txt B.7. Changes to = draft-ietf-lisp-lcaf-09.txt
=
o Submitted = June 2015. o Submitted June = 2015.
=
o Fix IANA = Considerations section to request a registry to allocate = o Fix IANA Considerations section to = request a registry to allocate
and track = LCAF Type values. and track LCAF = Type values.
=
B.7. Changes to = draft-ietf-lisp-lcaf-08.txt B.8. Changes to = draft-ietf-lisp-lcaf-08.txt
=
o Submitted = April 2015. o Submitted April = 2015.
=
o Comment = from Florin. The Application Data Type length field has a = o Comment from Florin. The Application = Data Type length field has a
typo. The = field should be labeled "12 + n" and not "8 + n". typo. The field should be labeled "12 + n" and = not "8 + n".
=
o Fix length = fields in the sections titled "Using Recursive LISP o Fix length fields in the sections titled "Using = Recursive LISP
Canonical = Address Encodings", "Generic Database Mapping Lookups", = Canonical Address Encodings", "Generic = Database Mapping Lookups",
and "Data = Model Encoding". and "Data Model = Encoding".
=
B.8. Changes to = draft-ietf-lisp-lcaf-07.txt B.9. Changes to = draft-ietf-lisp-lcaf-07.txt
=
o Submitted = December 2014. o Submitted = December 2014.
=
o Add a new = LCAF Type called "Encapsulation Format" so decapsulating = o Add a new LCAF Type called "Encapsulation = Format" so decapsulating
xTRs can = inform encapsulating xTRs what data-plane encapsulations = xTRs can inform encapsulating xTRs what = data-plane encapsulations
they = support. they support.
=
B.9. Changes to = draft-ietf-lisp-lcaf-06.txt B.10. Changes to = draft-ietf-lisp-lcaf-06.txt
=
o Submitted = October 2014. o Submitted October = 2014.
=
o Make it = clear how sorted RLOC records are done when LCAFs are used = o Make it clear how sorted RLOC records are = done when LCAFs are used
as the RLOC = record. as the RLOC = record.
=
B.10. Changes to = draft-ietf-lisp-lcaf-05.txt B.11. Changes to = draft-ietf-lisp-lcaf-05.txt
=
o Submitted = May 2014. o Submitted May = 2014.
=
o Add a = length field of the JSON payload that can be used for either = o Add a length field of the JSON payload = that can be used for either
binary or = text encoding of JSON data. = binary or text encoding of JSON data.
=
B.11. Changes to = draft-ietf-lisp-lcaf-04.txt B.12. Changes to = draft-ietf-lisp-lcaf-04.txt
=
o Submitted = January 2014. o Submitted January = 2014.
=
o Agreement = among ELP implementors to have the AFI 16-bit field o Agreement among ELP implementors to have the AFI = 16-bit field
adjacent to = the address. This will make the encoding consistent adjacent to the address. This will make the = encoding consistent
with all = other LCAF type address encodings. = with all other LCAF type address encodings.
=
B.12. Changes to = draft-ietf-lisp-lcaf-03.txt B.13. Changes to = draft-ietf-lisp-lcaf-03.txt
=
o Submitted = September 2013. o Submitted = September 2013.
=
o Updated = references and author's affilations. = o Updated references and author's affilations.
=
o Added = Instance-ID to the Multicast Info Type so there is relative = o Added Instance-ID to the Multicast Info = Type so there is relative
ease in = parsing (S,G) entries within a VPN. = ease in parsing (S,G) entries within a VPN.
=
o Add port = range encodings to the Application Data LCAF Type. o Add port range encodings to the Application Data = LCAF Type.
=
o Add a new = JSON LCAF Type. o Add a new JSON = LCAF Type.
=
o Add Address = Key/Value LCAF Type to allow attributes to be attached o Add Address Key/Value LCAF Type to allow = attributes to be attached
to an = address. to an address.
=
B.13. Changes to = draft-ietf-lisp-lcaf-02.txt B.14. Changes to = draft-ietf-lisp-lcaf-02.txt
=
o Submitted = March 2013. o Submitted March = 2013.
=
o Added new = LCAF Type "Replication List Entry" to support LISP o Added new LCAF Type "Replication List Entry" to = support LISP
replication = engineering use-cases. = replication engineering use-cases.
=
o Changed = references to new LISP RFCs. o = Changed references to new LISP RFCs.
=
B.14. Changes to = draft-ietf-lisp-lcaf-01.txt B.15. Changes to = draft-ietf-lisp-lcaf-01.txt
=
o Submitted = January 2013. o Submitted January = 2013.
=
o Change = longitude range from 0-90 to 0-180 in section 4.4. o Change longitude range from 0-90 to 0-180 in = section 4.4.
=
o Added = reference to WGS-84 in section 4.4. = o Added reference to WGS-84 in section 4.4.
=
B.15. Changes to = draft-ietf-lisp-lcaf-00.txt B.16. Changes to = draft-ietf-lisp-lcaf-00.txt
=
o Posted = first working group draft August 2012. = o Posted first working group draft August 2012.
=
o This draft = was renamed from draft-farinacci-lisp-lcaf-10.txt. o This draft was renamed from = draft-farinacci-lisp-lcaf-10.txt.
=
Authors' = Addresses Authors' Addresses
=
Dino = Farinacci Dino Farinacci
= lispers.net lispers.net
San Jose, = CA San Jose, CA
 End of changes. 42 change blocks. 
108 lines changed or = deleted 143 lines changed or = added

This = html diff was produced by rfcdiff 1.45. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20 = --Apple-Mail=_3612B9A9-65E7-45CD-BFD8-EE24EBFDD2E4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_3612B9A9-65E7-45CD-BFD8-EE24EBFDD2E4 Content-Disposition: attachment; filename=draft-ietf-lisp-lcaf-15.txt Content-Type: text/plain; name="draft-ietf-lisp-lcaf-15.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft lispers.net Intended status: Experimental D. Meyer Expires: March 23, 2017 Brocade J. Snijders NTT Communications September 19, 2016 LISP Canonical Address Format (LCAF) draft-ietf-lisp-lcaf-15 Abstract This draft defines a canonical address format encoding used in LISP control messages and in the encoding of lookup keys for the LISP Mapping Database System. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 23, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Farinacci, et al. Expires March 23, 2017 [Page 1] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. LISP Canonical Address Format Encodings . . . . . . . . . . . 5 4. LISP Canonical Address Applications . . . . . . . . . . . . . 7 4.1. Segmentation using LISP . . . . . . . . . . . . . . . . . 7 4.2. Carrying AS Numbers in the Mapping Database . . . . . . . 9 4.3. Assigning Geo Coordinates to Locator Addresses . . . . . 10 4.4. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . 12 4.5. Multicast Group Membership Information . . . . . . . . . 14 4.6. Traffic Engineering using Re-encapsulating Tunnels . . . 16 4.7. Storing Security Data in the Mapping Database . . . . . . 17 4.8. Source/Destination 2-Tuple Lookups . . . . . . . . . . . 19 4.9. Replication List Entries for Multicast Forwarding . . . . 21 4.10. Applications for AFI List Type . . . . . . . . . . . . . 22 4.10.1. Binding IPv4 and IPv6 Addresses . . . . . . . . . . 22 4.10.2. Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . 23 4.10.3. ASCII Names in the Mapping Database . . . . . . . . 24 4.10.4. Using Recursive LISP Canonical Address Encodings . . 25 4.10.5. Compatibility Mode Use Case . . . . . . . . . . . . 26 5. Experimental LISP Canonical Address Applications . . . . . . 27 5.1. Convey Application Specific Data . . . . . . . . . . . . 27 5.2. Generic Database Mapping Lookups . . . . . . . . . . . . 28 5.3. PETR Admission Control Functionality . . . . . . . . . . 30 5.4. Data Model Encoding . . . . . . . . . . . . . . . . . . . 31 5.5. Encoding Key/Value Address Pairs . . . . . . . . . . . . 32 5.6. Multiple Data-Planes . . . . . . . . . . . . . . . . . . 33 6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 8.1. Normative References . . . . . . . . . . . . . . . . . . 37 8.2. Informative References . . . . . . . . . . . . . . . . . 38 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 39 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 40 B.1. Changes to draft-ietf-lisp-lcaf-15.txt . . . . . . . . . 40 B.2. Changes to draft-ietf-lisp-lcaf-14.txt . . . . . . . . . 40 B.3. Changes to draft-ietf-lisp-lcaf-13.txt . . . . . . . . . 40 B.4. Changes to draft-ietf-lisp-lcaf-12.txt . . . . . . . . . 40 B.5. Changes to draft-ietf-lisp-lcaf-11.txt . . . . . . . . . 40 Farinacci, et al. Expires March 23, 2017 [Page 2] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 B.6. Changes to draft-ietf-lisp-lcaf-10.txt . . . . . . . . . 41 B.7. Changes to draft-ietf-lisp-lcaf-09.txt . . . . . . . . . 41 B.8. Changes to draft-ietf-lisp-lcaf-08.txt . . . . . . . . . 41 B.9. Changes to draft-ietf-lisp-lcaf-07.txt . . . . . . . . . 41 B.10. Changes to draft-ietf-lisp-lcaf-06.txt . . . . . . . . . 41 B.11. Changes to draft-ietf-lisp-lcaf-05.txt . . . . . . . . . 41 B.12. Changes to draft-ietf-lisp-lcaf-04.txt . . . . . . . . . 42 B.13. Changes to draft-ietf-lisp-lcaf-03.txt . . . . . . . . . 42 B.14. Changes to draft-ietf-lisp-lcaf-02.txt . . . . . . . . . 42 B.15. Changes to draft-ietf-lisp-lcaf-01.txt . . . . . . . . . 42 B.16. Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 1. Introduction The LISP architecture and protocols [RFC6830] introduces two new numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). To provide flexibility for current and future applications, these values can be encoded in LISP control messages using a general syntax that includes Address Family Identifier (AFI), length, and value fields. Currently defined AFIs include IPv4 and IPv6 addresses, which are formatted according to code-points assigned in [AFI] as follows: IPv4 Encoded Address: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 1 | IPv4 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires March 23, 2017 [Page 3] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 IPv6 Encoded Address: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 2 | IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This document describes the currently-defined AFIs the LISP protocol uses along with their encodings and introduces the LISP Canonical Address Format (LCAF) that can be used to define the LISP-specific encodings for arbitrary AFI values. 2. Definition of Terms Address Family Identifier (AFI): a term used to describe an address encoding in a packet. Address families are defined for IPv4 and IPv6. See [AFI] and [RFC3232] for details. The reserved AFI value of 0 is used in this specification to indicate an unspecified encoded address where the length of the address is 0 bytes following the 16-bit AFI value of 0. Unspecified Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 0 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Endpoint ID (EID): 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. The host obtains a destination EID the same way it obtains a destination address today, for example through a DNS lookup or SIP exchange. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID is allocated to a host from an EID-prefix block associated with the site where the host is located. An EID can be used by a host to refer to other hosts. Farinacci, et al. Expires March 23, 2017 [Page 4] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Routing Locator (RLOC): the IPv4 or IPv6 address of an egress tunnel router (ETR). It is the output of a EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as PA addresses. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site. 3. LISP Canonical Address Format Encodings IANA has assigned AFI value 16387 (0x4003) to the LISP architecture and protocols. This specification defines the encoding format of the LISP Canonical Address (LCA). This section defines all types for which an initial allocation in the LISP-LCAF registry is requested. See IANA Considerations section for the complete list of such types. The Address Family AFI definitions from [AFI] only allocate code- points for the AFI value itself. The length of the address or entity that follows is not defined and is implied based on conventional experience. When the LISP protocol uses LCAF definitions from this document, the AFI-based address lengths are specified in this document. When new LCAF definitions are defined in other use-case documents, the AFI-based address lengths for any new AFI encoded addresses are specified in those documents. The first 6 bytes of an LISP Canonical Address are followed by a variable number of fields of variable length: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Rsvd2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rsvd1: this 8-bit field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. Flags: this 8-bit field is for future definition and use. For now, set to zero on transmission and ignored on receipt. Type: this 8-bit field is specific to the LISP Canonical Address formatted encodings, currently allocated values are: Type 0: Null Body Type Farinacci, et al. Expires March 23, 2017 [Page 5] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Type 1: AFI List Type Type 2: Instance ID Type Type 3: AS Number Type Type 4: Application Data Type Type 5: Geo Coordinates Type Type 6: Opaque Key Type Type 7: NAT-Traversal Type Type 8: Nonce Locator Type Type 9: Multicast Info Type Type 10: Explicit Locator Path Type Type 11: Security Key Type Type 12: Source/Dest Key Type Type 13: Replication List Entry Type Type 14: JSON Data Model Type Type 15: Key/Value Address Pair Type Type 16: Encapsulation Format Type Rsvd2: this LCAF Type dependent 8-bit field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. See specific LCAF Type for specific bits not reserved. Length: this 16-bit field is in units of bytes and covers all of the LISP Canonical Address payload, starting and including the byte after the Length field. When including the AFI, an LCAF encoded address will have a minimum length of 8 bytes when the Length field is 0. The 8 bytes include the AFI, Flags, Type, Reserved, and Length fields. When the AFI is not next to encoded address in a control message, then the encoded address will have a minimum length of 6 bytes when the Length field is 0. The 6 bytes include the Flags, Type, Reserved, and Length fields. [RFC6830] states RLOC records are sorted when encoded in control messages so the locator-set has consistent order across all xTRs for Farinacci, et al. Expires March 23, 2017 [Page 6] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 a given EID. The sort order is based on sort-key {afi, RLOC- address}. When an RLOC is LCAF encoded, the sort-key is {afi, LCAF- Type}. Therefore, when a locator-set has a mix of AFI records and LCAF records, they are ordered from smallest to largest AFI value. 4. LISP Canonical Address Applications 4.1. Segmentation using LISP When multiple organizations inside of a LISP site are using private addresses [RFC1918] as EID-prefixes, their address spaces must remain segregated due to possible address duplication. An Instance ID in the address encoding can aid in making the entire AFI based address unique. Another use for the Instance ID LISP Canonical Address Format is when creating multiple segmented VPNs inside of a LISP site where keeping EID-prefix based subnets is desirable. Farinacci, et al. Expires March 23, 2017 [Page 7] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Instance ID LISP Canonical Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 2 | IID mask-len | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IID mask-len: if the AFI is set to 0, then this format is not encoding an extended EID-prefix but rather an instance-ID range where the 'IID mask-len' indicates the number of high-order bits used in the Instance ID field for the range. Length value n: length in bytes of the AFI address that follows the Instance ID field including the AFI field itself. Instance ID: the low-order 24-bits that can go into a LISP data header when the I-bit is set. See [RFC6830] for details. The reason for the length difference is so that the maximum number of instances supported per mapping system is 2^32 while conserving space in the LISP data header. This comes at the expense of limiting the maximum number of instances per xTR to 2^24. If an xTR is configured with multiple instance-IDs where the value in the high-order 8 bits are the same, then the low-order 24 bits MUST be unique. AFI =3D x: x can be any AFI value from [AFI]. This LISP Canonical Address Type can be used to encode either EID or RLOC addresses. Usage: When used as a lookup key, the EID is regarded as a extended- EID in the mapping system. This encoding is used in EID records in Map-Requests, Map-Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. Farinacci, et al. Expires March 23, 2017 [Page 8] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.2. Carrying AS Numbers in the Mapping Database When an AS number is stored in the LISP Mapping Database System for either policy or documentation reasons, it can be encoded in a LISP Canonical Address. AS Number LISP Canonical Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 3 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AS Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the AS Number field including the AFI field itself. AS Number: the 32-bit AS number of the autonomous system that has been assigned either the EID or RLOC that follows. AFI =3D x: x can be any AFI value from [AFI]. The AS Number Canonical Address Type can be used to encode either EID or RLOC addresses. The former is used to describe the LISP-ALT AS number the EID-prefix for the site is being carried for. The latter is used to describe the AS that is carrying RLOC based prefixes in the underlying routing system. Usage: This encoding can be used in EID or RLOC records in Map- Requests, Map-Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. Farinacci, et al. Expires March 23, 2017 [Page 9] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.3. Assigning Geo Coordinates to Locator Addresses If an ETR desires to send a Map-Reply describing the Geo Coordinates for each locator in its locator-set, it can use the Geo Coordinate Type to convey physical location information. Coordinates are specified using the WGS-84 (World Geodetic System) reference coordinate system [WGS-84]. Geo Coordinate LISP Canonical Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 5 | Rsvd2 | 12 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N| Latitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Longitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Altitude | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the 8-byte Longitude and Latitude fields including the AFI field itself. N: When set to 1 means North, otherwise South. Latitude Degrees: Valid values range from 0 to 90 degrees above or below the equator (northern or southern hemisphere, respectively). Latitude Minutes: Valid values range from 0 to 59. Latitude Seconds: Valid values range from 0 to 59. E: When set to 1 means East, otherwise West. Longitude Degrees: Value values are from 0 to 180 degrees right or left of the Prime Meridian. Longitude Minutes: Valid values range from 0 to 59. Longitude Seconds: Valid values range from 0 to 59. Farinacci, et al. Expires March 23, 2017 [Page 10] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Altitude: Height relative to sea level in meters. This is a signed integer meaning that the altitude could be below sea level. A value of 0x7fffffff indicates no Altitude value is encoded. AFI =3D x: x can be any AFI value from [AFI]. The Geo Coordinates Canonical Address Type can be used to encode either EID or RLOC addresses. When used for EID encodings, you can determine the physical location of an EID along with the topological location by observing the locator-set. Usage: This encoding can be used in EID or RLOC records in Map- Requests, Map-Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. Farinacci, et al. Expires March 23, 2017 [Page 11] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.4. NAT Traversal Scenarios When a LISP system is conveying global address and mapped port information when traversing through a NAT device, the NAT-Traversal LCAF Type is used. See [I-D.ermagan-lisp-nat-traversal] for details. NAT-Traversal Canonical Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 7 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MS UDP Port Number | ETR UDP Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Global ETR RLOC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | MS RLOC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Private ETR RLOC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR RLOC Address 1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR RLOC Address k ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI addresses that follows the UDP Port Number field including the AFI fields themselves. MS UDP Port Number: this is the UDP port number of the Map-Server and is set to 4342. ETR UDP Port Number: this is the port number returned to a LISP system which was copied from the source port from a packet that has flowed through a NAT device. AFI =3D x: x can be any AFI value from [AFI]. Global ETR RLOC Address: this is an address known to be globally unique built by NAT-traversal functionality in a LISP router. MS RLOC Address: this is the address of the Map-Server used in the destination RLOC of a packet that has flowed through a NAT device. Farinacci, et al. Expires March 23, 2017 [Page 12] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Private ETR RLOC Address: this is an address known to be a private address inserted in this LCAF format by a LISP router that resides on the private side of a NAT device. RTR RLOC Address: this is an encapsulation address used by an ITR or PITR which resides behind a NAT device. This address is known to have state in a NAT device so packets can flow from it to the LISP ETR behind the NAT. There can be one or more NAT Reencapsulating Tunnel Router (RTR) [I-D.ermagan-lisp-nat-traversal] addresses supplied in these set of fields. The number of RTRs encoded is determined by the LCAF length field. When there are no RTRs supplied, the RTR fields can be omitted and reflected by the LCAF length field or an AFI of 0 can be used to indicate zero RTRs encoded. Usage: This encoding can be used in Info-Request and Info-Reply messages. The mapping system does not store this information. The information is used by an xTR and Map-Server to convey private and public address information when traversing NAT and firewall devices. Farinacci, et al. Expires March 23, 2017 [Page 13] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.5. Multicast Group Membership Information Multicast group information can be published in the mapping database. So a lookup on an group address EID can return a replication list of RLOC group addresses or RLOC unicast addresses. The intent of this type of unicast replication is to deliver packets to multiple ETRs at receiver LISP multicast sites. The locator-set encoding for this EID record type can be a list of ETRs when they each register with "Merge Semantics". The encoding can be a typical AFI encoded locator address. When an RTR list is being registered (with multiple levels according to [I-D.coras-lisp-re]), the Replication List Entry LCAF type is used for locator encoding. This LCAF encoding can be used to send broadcast packets to all members of a subnet when each EIDs are away from their home subnet location. Multicast Info Canonical Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 9 | Rsvd2 | 8 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Source MaskLen| Group MaskLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Source/Subnet Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Group Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Reserved: must be set to zero and ignore on receipt. Instance ID: the low-order 24-bits that can go into a LISP data header when the I-bit is set. See [RFC6830] for details. The use of the Instance-ID in this LCAF type is to associate a multicast forwarding entry for a given VPN. The instance-ID describes the VPN and is registered to the mapping database system as a 3-tuple of (Instance-ID, S-prefix, G-prefix). Source MaskLen: the mask length of the source prefix that follows. Farinacci, et al. Expires March 23, 2017 [Page 14] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Group MaskLen: the mask length of the group prefix that follows. AFI =3D x: x can be any AFI value from [AFI]. When a specific AFI = has its own encoding of a multicast address, this field must be either a group address or a broadcast address. Source/Subnet Address is the source address or prefix for encoding a (S,G) multicast entry. Group Address is the group address or group prefix for encoding (S,G) or (*,G) multicast entries. Usage: This encoding can be used in EID records in Map-Requests, Map- Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. Farinacci, et al. Expires March 23, 2017 [Page 15] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.6. Traffic Engineering using Re-encapsulating Tunnels For a given EID lookup into the mapping database, this LCAF format can be returned to provide a list of locators in an explicit re- encapsulation path. See [I-D.farinacci-lisp-te] for details. Explicit Locator Path (ELP) Canonical Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 10 | Rsvd2 | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 |L|P|S| AFI =3D x | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reencap Hop 1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 |L|P|S| AFI =3D x | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reencap Hop k ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Rsvd3: this field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. Lookup bit (L): this is the Lookup bit used to indicate to the user of the ELP to not use this address for encapsulation but to look it up in the mapping database system to obtain an encapsulating RLOC address. RLOC-Probe bit (P): this is the RLOC-probe bit which means the Reencap Hop allows RLOC-probe messages to be sent to it. When the R-bit is set to 0, RLOC-probes must not be sent. When a Reencap Hop is an anycast address then multiple physical Reencap Hops are using the same RLOC address. In this case, RLOC-probes are not needed because when the closest RLOC address is not reachable another RLOC address can be reachable. Strict bit (S): this is the strict bit which means the associated Rencap Hop is required to be used. If this bit is 0, the reencapsulator can skip this Reencap Hop and go to the next one in the list. Farinacci, et al. Expires March 23, 2017 [Page 16] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 AFI =3D x: x can be any AFI value from [AFI]. When a specific AFI = has its own encoding of a multicast address, this field must be either a group address or a broadcast address. Usage: This encoding can be used in RLOC records in Map-Requests, Map-Replies, Map-Registers, and Map-Notify messages. This encoding does not need to be understood by the mapping system for mapping database lookups since this LCAF type is not a lookup key. 4.7. Storing Security Data in the Mapping Database When a locator in a locator-set has a security key associated with it, this LCAF format will be used to encode key material. See [I-D.ietf-lisp-ddt] for details. Farinacci, et al. Expires March 23, 2017 [Page 17] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Security Key Canonical Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 11 | Rsvd2 | 6 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Count | Rsvd3 | Key Algorithm | Rsvd4 |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Length | Key Material ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Key Material | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Locator Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that start with the Key Material field. Key Count: the Key Count field declares the number of Key sections included in this LCAF. Rsvd3: this field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. Key Algorithm: the Algorithm field identifies the key's cryptographic algorithm and specifies the format of the Public Key field. Rsvd4: this field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. R bit: this is the revoke bit and, if set, it specifies that this Key is being Revoked. Key Length: this field determines the length in bytes of the Key Material field. Key Material: the Key Material field stores the key material. The format of the key material stored depends on the Key Algorithm field. AFI =3D x: x can be any AFI value from [AFI].This is the locator address that owns the encoded security key. Farinacci, et al. Expires March 23, 2017 [Page 18] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Usage: This encoding can be used in EID or RLOC records in Map- Requests, Map-Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. 4.8. Source/Destination 2-Tuple Lookups When both a source and destination address of a flow needs consideration for different locator-sets, this 2-tuple key is used in EID fields in LISP control messages. When the Source/Dest key is registered to the mapping database, it can be encoded as a source- prefix and destination-prefix. When the Source/Dest is used as a key for a mapping database lookup the source and destination come from a data packet. Farinacci, et al. Expires March 23, 2017 [Page 19] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Source/Dest Key Canonical Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 12 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Source-ML | Dest-ML | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Source-Prefix ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Destination-Prefix ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Reserved: must be set to zero and ignore on receipt. Source-ML: the mask length of the source prefix that follows. Dest-ML: the mask length of the destination prefix that follows. AFI =3D x: x can be any AFI value from [AFI]. When a specific AFI = has its own encoding of a multicast address, this field must be either a group address or a broadcast address. Usage: This encoding can be used in EID records in Map-Requests, Map- Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. Refer to [I-D.farinacci-lisp-te] for usage details of this LCAF type. Farinacci, et al. Expires March 23, 2017 [Page 20] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.9. Replication List Entries for Multicast Forwarding The Replication List Entry LCAF type is an encoding for a locator being used for unicast replication according to the specification in [I-D.coras-lisp-re]. This locator encoding is pointed to by a Multicast Info LCAF Type and is registered by Re-encapsulating Tunnel Routers (RTRs) that are participating in an overlay distribution tree. Each RTR will register its locator address and its configured level in the distribution tree. Replication List Entry Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 13 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 | Rsvd4 | Level Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR/ETR #1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 | Rsvd4 | Level Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR/ETR #n ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Rsvd{1,2,3,4}: must be set to zero and ignore on receipt. Level Value: this value is associated with the level within the overlay distribution tree hierarchy where the RTR resides. The level numbers are ordered from lowest value being close to the ITR (meaning that ITRs replicate to level-0 RTRs) and higher levels are further downstream on the distribution tree closer to ETRs of multicast receiver sites. AFI =3D x: x can be any AFI value from [AFI]. A specific AFI has = its own encoding of either a unicast or multicast locator address. For efficiency reasons, all RTR/ETR entries for the same level should be combined together by a Map-Server to avoid searching through the entire multi-level list of locator entries in a Map- Reply message. Usage: This encoding can be used in RLOC records in Map-Requests, Map-Replies, Map-Registers, and Map-Notify messages. Farinacci, et al. Expires March 23, 2017 [Page 21] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.10. Applications for AFI List Type 4.10.1. Binding IPv4 and IPv6 Addresses When header translation between IPv4 and IPv6 is desirable a LISP Canonical Address can use the AFI List Type to carry a variable number of AFIs in one LCAF AFI. Address Binding LISP Canonical Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 2 + 4 + 2 + 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 1 | IPv4 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv4 Address | AFI =3D 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes is fixed at 24 when IPv4 and IPv6 AFI encoded addresses are used. This type of address format can be included in a Map-Request when the address is being used as an EID, but the Mapping Database System lookup destination can use only the IPv4 address. This is so a Mapping Database Service Transport System, such as LISP-ALT [RFC6836], can use the Map-Request destination address to route the control message to the desired LISP site. Usage: This encoding can be used in EID or RLOC records in Map- Requests, Map-Replies, Map-Registers, and Map-Notify messages. See subsections in this section for specific use cases. Farinacci, et al. Expires March 23, 2017 [Page 22] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.10.2. Layer-2 VPNs When MAC addresses are stored in the LISP Mapping Database System, the AFI List Type can be used to carry AFI 6. MAC Address LISP Canonical Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 2 + 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 6 | Layer-2 MAC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Layer-2 MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes is fixed at 8 when MAC address AFI encoded addresses are used. This address format can be used to connect layer-2 domains together using LISP over an IPv4 or IPv6 core network to create a layer-2 VPN. In this use-case, a MAC address is being used as an EID, and the locator-set that this EID maps to can be an IPv4 or IPv6 RLOCs, or even another MAC address being used as an RLOC. See [I-D.portoles-lisp-eid-mobility] for how layer-2 VPNs operate when doing EID mobility. Farinacci, et al. Expires March 23, 2017 [Page 23] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.10.3. ASCII Names in the Mapping Database If DNS names or URIs are stored in the LISP Mapping Database System, the AFI List Type can be used to carry an ASCII string where it is delimited by length 'n' of the LCAF Length encoding. ASCII LISP Canonical Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 2 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 17 | DNS Name or URI ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes AFI=3D17 field and the = null-terminated ASCII string (the last byte of 0 is included). Farinacci, et al. Expires March 23, 2017 [Page 24] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.10.4. Using Recursive LISP Canonical Address Encodings When any combination of above is desirable, the AFI List Type value can be used to carry within the LCAF AFI another LCAF AFI (for example, Application Specific Data see Section 5.1. Recursive LISP Canonical Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 8 + 18 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 4 | Rsvd2 | 12 + 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP TOS, IPv6 QQS or Flow Label | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Port (lower-range) | Local Port (upper-range) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Port (lower-range) | Remote Port (upper-range) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 1 | IPv4 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes is fixed at 18 when an AFI=3D1 IPv4 address = is included. This format could be used by a Mapping Database Transport System, such as LISP-ALT [RFC6836], where the AFI=3D1 IPv4 address is used as an EID and placed in the Map-Request destination address by the sending LISP system. The ALT system can deliver the Map-Request to the LISP destination site independent of the Application Data Type AFI payload values. When this AFI is processed by the destination LISP site, it can return different locator-sets based on the type of application or level of service that is being requested. Farinacci, et al. Expires March 23, 2017 [Page 25] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.10.5. Compatibility Mode Use Case A LISP system should use the AFI List Type format when sending to LISP systems that do not support a particular LCAF Type used to encode locators. This allows the receiving system to be able to parse a locator address for encapsulation purposes. The list of AFIs in an AFI List LCAF Type has no semantic ordering and a receiver should parse each AFI element no matter what the ordering. Compatibility Mode Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 8 + 14 + 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 5 | Rsvd2 | 12 + 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N| Latitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Longitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Altitude | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 0 | AFI =3D 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If a system does not recognized the Geo Coordinate LCAF Type that is accompanying a locator address, an encoder can include the Geo Coordinate LCAF Type embedded in a AFI List LCAF Type where the AFI in the Geo Coordinate LCAF is set to 0 and the AFI encoded next in the list is encoded with a valid AFI value to identify the locator address. A LISP system is required to support the AFI List LCAF Type to use this procedure. It would skip over 10 bytes of the Geo Coordinate LCAF Type to get to the locator address encoding (an IPv4 locator address). A LISP system that does support the Geo Coordinate LCAF Type can support parsing the locator address within the Geo Coordinate LCAF encoding or in the locator encoding that follows in the AFI List LCAF. Farinacci, et al. Expires March 23, 2017 [Page 26] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 5. Experimental LISP Canonical Address Applications 5.1. Convey Application Specific Data When a locator-set needs to be conveyed based on the type of application or the Per-Hop Behavior (PHB) of a packet, the Application Data Type can be used. Application Data LISP Canonical Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 4 | Rsvd2 | 12 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP TOS, IPv6 TC, or Flow Label | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Port (lower-range) | Local Port (upper-range) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Port (lower-range) | Remote Port (upper-range) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the 8-byte Application Data fields including the AFI field itself. IP TOS, IPv6 TC, or Flow Label: this field stores the 8-bit IPv4 TOS field used in an IPv4 header, the 8-bit IPv6 Traffic Class or Flow Label used in an IPv6 header. Local Port/Remote Port Ranges: these fields are from the TCP, UDP, or SCTP transport header. A range can be specified by using a lower value and an upper value. When a single port is encoded, the lower and upper value fields are the same. AFI =3D x: x can be any AFI value from [AFI]. The Application Data Canonical Address Type is used for an EID encoding when an ITR wants a locator-set for a specific application. When used for an RLOC encoding, the ETR is supplying a locator-set for each specific application is has been configured to advertise. Usage: This encoding can be used in EID records in Map-Requests, Map- Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended Farinacci, et al. Expires March 23, 2017 [Page 27] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 EIDs are used in Map-Referral messages. This LCAF type is used as a lookup key to the mapping system that can return a longest-match or exact-match entry. 5.2. Generic Database Mapping Lookups When the LISP Mapping Database system holds information accessed by a generic formatted key (where the key is not the usual IPv4 or IPv6 address), an opaque key may be desirable. Opaque Key LISP Canonical Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 6 | Rsvd2 | 3 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Field Num | Key Wildcard Fields | Key . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the type's payload. The value n is the number of bytes that follow this Length field. Farinacci, et al. Expires March 23, 2017 [Page 28] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Key Field Num: the value of this field is the the number of "Key" sub-fields minus 1, the "Key" field can be broken up into. So if this field has a value of 0, there is 1 sub-field in the "Key". The width of the sub-fields are fixed length. So for a key size of 8 bytes, with a Key Field Num of 3, allows 4 sub-fields of 2 bytes each in length. Allowing for a reasonable number of 16 sub- field separators, valid values range from 0 to 15. Key Wildcard Fields: describes which fields in the key are not used as part of the key lookup. This wildcard encoding is a bitfield. Each bit is a don't-care bit for a corresponding field in the key. Bit 0 (the low-order bit) in this bitfield corresponds the first field, the low-order field in the key, bit 1 the second field, and so on. When a bit is set in the bitfield it is a don't-care bit and should not be considered as part of the database lookup. When the entire 16-bits is set to 0, then all bits of the key are used for the database lookup. Key: the variable length key used to do a LISP Database Mapping lookup. The length of the key is the value n (as shown above). Usage: This is an experimental type where the usage has not been defined yet. Farinacci, et al. Expires March 23, 2017 [Page 29] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 5.3. PETR Admission Control Functionality When a public PETR device wants to verify who is encapsulating to it, it can check for a specific nonce value in the LISP encapsulated packet. To convey the nonce to admitted ITRs or PITRs, this LCAF format is used in a Map-Register or Map-Reply locator-record. Nonce Locator Canonical Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 8 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the Nonce field including the AFI field itself. Reserved: must be set to zero and ignore on receipt. Nonce: this is a nonce value returned by an ETR in a Map-Reply locator-record to be used by an ITR or PITR when encapsulating to the locator address encoded in the AFI field of this LCAF type. This nonce value is inserted in the nonce field in the LISP header encapsulation. AFI =3D x: x can be any AFI value from [AFI]. Usage: This is an experimental type where the usage has not been defined yet. Farinacci, et al. Expires March 23, 2017 [Page 30] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 5.4. Data Model Encoding This type allows a JSON data model to be encoded either as an EID or RLOC. JSON Data Model Type Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 14 | Rsvd2 |B| 2 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | JSON length | JSON binary/text encoding ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Optional Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the fields that follow the "JSON length" field. Rsvd{1,2}: must be set to zero and ignore on receipt. B bit: indicates that the JSON field is binary encoded according to [JSON-BINARY] when the bit is set to 1. Otherwise the encoding is based on text encoding according to [RFC7159]. JSON length: length in octets of the following 'JSON binary/text encoding' field. JSON binary/text encoding field: a variable length field that contains either binary or text encodings. AFI =3D x: x can be any AFI value from [AFI]. A specific AFI has = its own encoding of either a unicast or multicast locator address. All RTR/ETR entries for the same level should be combined together by a Map-Server to avoid searching through the entire multi-level list of locator entries in a Map-Reply message. Usage: This is an experimental type where the usage has not been defined yet. Farinacci, et al. Expires March 23, 2017 [Page 31] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 5.5. Encoding Key/Value Address Pairs The Key/Value pair is for example useful for attaching attributes to other elements of LISP packets, such as EIDs or RLOCs. When attaching attributes to EIDs or RLOCs, it's necessary to distinguish between the element that should be used as EID or RLOC, and hence as key for lookups, and additional attributes. This is especially the case when the difference cannot be determined from the types of the elements, such as when two IP addresses are being used. Key/Value Pair Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 15 | Rsvd2 | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address as Key ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D y | Address as Value ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Rsvd{1,2}: must be set to zero and ignore on receipt. AFI =3D x: x is the "Address as Key" AFI that can have any value = from [AFI]. A specific AFI has its own encoding of either a unicast or multicast locator address. All RTR/ETR entries for the same level should be combined together by a Map-Server to avoid searching through the entire multi-level list of locator entries in a Map- Reply message. Address as Key: this AFI encoded address will be attached with the attributes encoded in "Address as Value" which follows this field. AFI =3D y: y is the "Address of Value" AFI that can have any value from [AFI]. A specific AFI has its own encoding of either a unicast or multicast locator address. All RTR/ETR entries for the same level should be combined together by a Map-Server to avoid searching through the entire multi-level list of locator entries in a Map-Reply message. Address as Value: this AFI encoded address will be the attribute address that goes along with "Address as Key" which precedes this field. Farinacci, et al. Expires March 23, 2017 [Page 32] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Usage: This is an experimental type where the usage has not been defined yet. 5.6. Multiple Data-Planes Overlays are becoming popular in many parts of the network which have created an explosion of data-plane encapsulation headers. Since the LISP mapping system can hold many types of address formats, it can represent the encapsulation format supported by an RLOC as well. When an encapsulator receives a Map-Reply with an Encapsulation Format LCAF Type encoded in an RLOC-record, it can select an encapsulation format, that it can support, from any of the encapsulation protocols which have the bit set to 1 in this LCAF type. Farinacci, et al. Expires March 23, 2017 [Page 33] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Encapsulation Format Address Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 16 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved-for-Future-Encapsulations |U|G|N|v|V|l|L| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rsvd1/Rsvd2: must be set to zero and ignored on receipt. Length value n: length in bytes of the AFI address that follows the next 32-bits including the AFI field itself. Reserved-for-Future-Encapsulations: must be set to zero and ignored on receipt. This field will get bits allocated to future encapsulations, as they are created. L: The RLOCs listed in the AFI encoded addresses in the next longword can accept layer3 LISP encapsulation using destination UDP port 4341 [RFC6830]. l: The RLOCs listed in the AFI encoded addresses in the next longword can accept layer2 LISP encapsulation using destination UDP port 8472 [I-D.smith-lisp-layer2]. V: The RLOCs listed in the AFI encoded addresses in the next longword can accept VXLAN encapsulation using destination UDP port 4789 [RFC7348]. v: The RLOCs listed in the AFI encoded addresses in the next longword can accept VXLAN-GPE encapsulation using destination UDP port 4790 [I-D.quinn-vxlan-gpe]. N: The RLOCs listed in the AFI encoded addresses in the next longword can accept NV-GRE encapsulation using IPv4/ IPv6 protocol number 47 [RFC7637]. G: The RLOCs listed in the AFI encoded addresses in the next longword can accept GENEVE encapsulation using destination UDP port 6081 [I-D.gross-geneve]. Farinacci, et al. Expires March 23, 2017 [Page 34] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 U: The RLOCs listed in the AFI encoded addresses in the next longword can accept GUE encapsulation using destination UDP port TBD [I-D.herbert-gue]. Usage: This encoding can be used in RLOC records in Map-Requests, Map-Replies, Map-Registers, and Map-Notify messages. Farinacci, et al. Expires March 23, 2017 [Page 35] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 6. Security Considerations There are no security considerations for this specification. The security considerations are documented for the protocols that use LISP Canonical Addressing. The use of the Geo-Coordinates LCAF Type may raise physical privacy issues. Care should be taken when configuring the mapping system to use specific policy parameters so geo-location information is not returned gratutiosly. 7. IANA Considerations This document defines a canonical address format encoding used in LISP control messages and in the encoding of lookup keys for the LISP Mapping Database System. Such address format is based on a fixed AFI (16387) and a LISP LCAF Type field. The LISP LCAF Type field is an 8-bit field specific to the LISP Canonical Address formatted encodings, for which IANA is to create and maintain a new registry (as outlined in [RFC5226]) entitled "LISP LCAF Type". Initial values for the LISP LCAF Type registry are given below. Future assignments are to be made through expert review with a specification required publication. Assignments consist of a LISP LCAF Type name and its associated value: +-------+------------------------------+------------+ | Value | LISP LCAF Type Name | Definition | +-------+------------------------------+------------+ | 0 | Null Body Type | Section 3 | | 1 | AFI List Type | Section 3 | | 2 | Instance ID Type | Section 3 | | 3 | AS Number Type | Section 3 | | 5 | Geo Coordinates Type | Section 3 | | 7 | NAT-Traversal Type | Section 3 | | 9 | Multicast Info Type | Section 3 | | 10 | Explicit Locator Path Type | Section 3 | | 11 | Security Key Type | Section 3 | | 12 | Source/Dest Key Type | Section 3 | | 13 | Replication List Entry Type | Section 3 | +-------+------------------------------+------------+ Table 1: LISP LCAF Type Initial Values Farinacci, et al. Expires March 23, 2017 [Page 36] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 8. References 8.1. Normative References [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, DOI 10.17487/RFC3232, January 2002, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, . [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, January 2013, . [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, . [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, . [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network Virtualization Using Generic Routing Encapsulation", RFC 7637, DOI 10.17487/RFC7637, September 2015, . Farinacci, et al. Expires March 23, 2017 [Page 37] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 8.2. Informative References [AFI] IANA, , "Address Family Identifier (AFIs)", ADDRESS FAMILY NUMBERS http://www.iana.org/numbers.html, Febuary 2007. [I-D.coras-lisp-re] Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., Maino, F., and D. Farinacci, "LISP Replication Engineering", draft-coras-lisp-re-08 (work in progress), November 2015. [I-D.ermagan-lisp-nat-traversal] Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, F., and C. White, "NAT traversal for LISP", draft-ermagan- lisp-nat-traversal-11 (work in progress), August 2016. [I-D.farinacci-lisp-te] Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic Engineering Use-Cases", draft-farinacci-lisp-te-11 (work in progress), September 2016. [I-D.gross-geneve] Gross, J., Sridhar, T., Garg, P., Wright, C., Ganga, I., Agarwal, P., Duda, K., Dutt, D., and J. Hudson, "Geneve: Generic Network Virtualization Encapsulation", draft- gross-geneve-02 (work in progress), October 2014. [I-D.herbert-gue] Herbert, T., Yong, L., and O. Zia, "Generic UDP Encapsulation", draft-herbert-gue-03 (work in progress), March 2015. [I-D.ietf-lisp-ddt] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp- ddt-08 (work in progress), September 2016. [I-D.portoles-lisp-eid-mobility] Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a Unified Control Plane", draft-portoles-lisp-eid- mobility-00 (work in progress), April 2016. Farinacci, et al. Expires March 23, 2017 [Page 38] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 [I-D.quinn-vxlan-gpe] Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F., Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg, P., and D. Melman, "Generic Protocol Extension for VXLAN", draft-quinn-vxlan-gpe-04 (work in progress), February 2015. [I-D.smith-lisp-layer2] Smith, M., Dutt, D., Farinacci, D., and F. Maino, "Layer 2 (L2) LISP Encapsulation Format", draft-smith-lisp- layer2-03 (work in progress), September 2013. [JSON-BINARY] "Universal Binary JSON Specification", URL http://ubjson.org. [WGS-84] Geodesy and Geophysics Department, DoD., "World Geodetic System 1984", NIMA TR8350.2, January 2000, . Appendix A. Acknowledgments The authors would like to thank Vince Fuller, Gregg Schudel, Jesper Skriver, Luigi Iannone, Isidor Kouvelas, and Sander Steffann for their technical and editorial commentary. The authors would like to thank Victor Moreno for discussions that lead to the definition of the Multicast Info LCAF type. The authors would like to thank Parantap Lahiri and Michael Kowal for discussions that lead to the definition of the Explicit Locator Path (ELP) LCAF type. The authors would like to thank Fabio Maino and Vina Ermagan for discussions that lead to the definition of the Security Key LCAF type. The authors would like to thank Albert Cabellos-Aparicio and Florin Coras for discussions that lead to the definition of the Replication List Entry LCAF type. Thanks goes to Michiel Blokzijl and Alberto Rodriguez-Natal for suggesting new LCAF types. Thanks also goes to Terry Manderson for assistance obtaining a LISP AFI value from IANA. Farinacci, et al. Expires March 23, 2017 [Page 39] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Appendix B. Document Change Log [RFC Editor: Please delete this section on publication as RFC.] B.1. Changes to draft-ietf-lisp-lcaf-15.txt o Submitted September 2016. o Addressed comments from Routing Directorate reviewer Stig Venass. B.2. Changes to draft-ietf-lisp-lcaf-14.txt o Submitted July 2016. o Fix IDnits errors and comments from Luigi Iannone, document shepherd. B.3. Changes to draft-ietf-lisp-lcaf-13.txt o Submitted May 2016. o Explain the Instance-ID LCAF Type is 32-bits in length and the Instance-ID field in the LISP encapsulation header is 24-bits. B.4. Changes to draft-ietf-lisp-lcaf-12.txt o Submitted March 2016. o Updated references and document timer. o Removed the R, J, and L bits from the Multicast Info Type LCAF since working group decided to not go forward with draft- farinacci-lisp-mr-signaling-03.txt in favor of draft- ietf-lisp- signal-free-00.txt. B.5. Changes to draft-ietf-lisp-lcaf-11.txt o Submitted September 2015. o Reflecting comments from Prague LISP working group. o Readying document for a LISP LCAF registry, RFC publication, and for new use-cases that will be defined in the new charter. Farinacci, et al. Expires March 23, 2017 [Page 40] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 B.6. Changes to draft-ietf-lisp-lcaf-10.txt o Submitted June 2015. o Fix coauthor Job's contact information. B.7. Changes to draft-ietf-lisp-lcaf-09.txt o Submitted June 2015. o Fix IANA Considerations section to request a registry to allocate and track LCAF Type values. B.8. Changes to draft-ietf-lisp-lcaf-08.txt o Submitted April 2015. o Comment from Florin. The Application Data Type length field has a typo. The field should be labeled "12 + n" and not "8 + n". o Fix length fields in the sections titled "Using Recursive LISP Canonical Address Encodings", "Generic Database Mapping Lookups", and "Data Model Encoding". B.9. Changes to draft-ietf-lisp-lcaf-07.txt o Submitted December 2014. o Add a new LCAF Type called "Encapsulation Format" so decapsulating xTRs can inform encapsulating xTRs what data-plane encapsulations they support. B.10. Changes to draft-ietf-lisp-lcaf-06.txt o Submitted October 2014. o Make it clear how sorted RLOC records are done when LCAFs are used as the RLOC record. B.11. Changes to draft-ietf-lisp-lcaf-05.txt o Submitted May 2014. o Add a length field of the JSON payload that can be used for either binary or text encoding of JSON data. Farinacci, et al. Expires March 23, 2017 [Page 41] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 B.12. Changes to draft-ietf-lisp-lcaf-04.txt o Submitted January 2014. o Agreement among ELP implementors to have the AFI 16-bit field adjacent to the address. This will make the encoding consistent with all other LCAF type address encodings. B.13. Changes to draft-ietf-lisp-lcaf-03.txt o Submitted September 2013. o Updated references and author's affilations. o Added Instance-ID to the Multicast Info Type so there is relative ease in parsing (S,G) entries within a VPN. o Add port range encodings to the Application Data LCAF Type. o Add a new JSON LCAF Type. o Add Address Key/Value LCAF Type to allow attributes to be attached to an address. B.14. Changes to draft-ietf-lisp-lcaf-02.txt o Submitted March 2013. o Added new LCAF Type "Replication List Entry" to support LISP replication engineering use-cases. o Changed references to new LISP RFCs. B.15. Changes to draft-ietf-lisp-lcaf-01.txt o Submitted January 2013. o Change longitude range from 0-90 to 0-180 in section 4.4. o Added reference to WGS-84 in section 4.4. B.16. Changes to draft-ietf-lisp-lcaf-00.txt o Posted first working group draft August 2012. o This draft was renamed from draft-farinacci-lisp-lcaf-10.txt. Farinacci, et al. Expires March 23, 2017 [Page 42] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Authors' Addresses Dino Farinacci lispers.net San Jose, CA USA Email: farinacci@gmail.com Dave Meyer Brocade San Jose, CA USA Email: dmm@1-4-5.net Job Snijders NTT Communications Theodorus Majofskistraat 100 Amsterdam 1065 SZ NL Email: job@ntt.net Farinacci, et al. Expires March 23, 2017 [Page 43] --Apple-Mail=_3612B9A9-65E7-45CD-BFD8-EE24EBFDD2E4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_3612B9A9-65E7-45CD-BFD8-EE24EBFDD2E4-- From nobody Mon Sep 19 09:08:52 2016 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 DD45A12B44C; Mon, 19 Sep 2016 09:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJUk7IZjt04j; Mon, 19 Sep 2016 09:08:47 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::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 37CF412B451; Mon, 19 Sep 2016 09:06:49 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id q2so32197376pfj.3; Mon, 19 Sep 2016 09:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kXmiPJtIpz6vDwqjI7tt8EwgOSEqkund6HJuRugdc1U=; b=wI6GmNe4bwwlFjd3vrK4tIaysUkdCaMg6sLdPVpbkCds8Bc27IdJi2iaei66CJIH2M j5YIthxfQeO+jfyEje20CKzb1dSX62dYCYCYWto9h7J1E5i52kwAx6FeyquVpyTgNTD7 3kYIz5AZxS/sEmRBO+u5TM9WVJE5qSEImj5FqOa6GDT/xCmb9HNYamGT7H9Z3Et04jH4 NEeXueNayj7KqaJuzm/Ib7IgnizYQ9OkI/M1tbtd1GE6fHEf7ELAbuqUxU05xTzKqbkI F6a9End8oTSnIjNlEwLRhCAZcPAVcbbKUMAEBfbEe097hchDm2DCUXnDLMP27dhx0kYV Q2Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kXmiPJtIpz6vDwqjI7tt8EwgOSEqkund6HJuRugdc1U=; b=GdJ8RBeVlcDsItOVGU0aCEPYLPv8ZsPm2KssfQ4rd20Jlp9B/JzWlszoz51KyQAiLp RvdO8RztSC1vyXTHxBo9xGubJsteljsOKPdXtaHA2Xfrg8m0xSywR27OpcD/dPaZJRnn y1du8zGNhvKPxBONwXspJeZOMFhClLFHb2Dd3iPRBQIZT4nG2WxgW8vaZANvcVaOYJdi 5Cjg2lVCLUS7TtTCtIJRhSvuqXYyfkSt7pNZY2m3AL+13nMkCX0J5sC9pAH/djaKcmjm z//KONeolEQW7dfzDnE1z615+tFkDqibWQXLMGW8ODxuLFKWzjyHn1KuwzpjSjJ4njtB K1/A== X-Gm-Message-State: AE9vXwNbKnB9a7RQtfT+mz6XSs+2VxJy0fyXnz2iFbC8aKnq1vIefJlA/jykQaCmM6OziQ== X-Received: by 10.98.222.3 with SMTP id h3mr47420504pfg.146.1474301206645; Mon, 19 Sep 2016 09:06:46 -0700 (PDT) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id e71sm46885224pfc.75.2016.09.19.09.06.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 19 Sep 2016 09:06:44 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: Date: Mon, 19 Sep 2016 09:06:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9a0ab6afeff3fc8b86cc320a757ccbf8@tcb.net> To: Dino Farinacci X-Mailer: Apple Mail (2.3124) Archived-At: Cc: zhang.xian@huawei.com, LISP mailing list list , Jonathan.Hardwick@metaswitch.com, draft-ietf-lisp-crypto.authors@ietf.org, Jon Hudson Subject: Re: [lisp] RTG-DIR REVIEW: draft-ietf-lisp-crypto-06.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 19 Sep 2016 16:08:50 -0000 Any status on this? Dino > On Sep 5, 2016, at 10:07 AM, Dino Farinacci = wrote: >=20 > See responses inline. A new draft is attached (but not submitted since = I had some open questions). >=20 >>> Document: draft-ietf-lisp-crypto-06.txt >>>=20 >>> Reviewer: Danny McPherson >>>=20 >>> Review Date: August 24, 2016 >>>=20 >>> Intended Status: Experimental >=20 > Thanks for the review Danny. >=20 >>> Summary: >>>=20 >>> I have some minor concerns about this document that should be = considered before publication. >>>=20 >>> Comments: >>>=20 >>> I believe the draft is technically sound.=20 >>>=20 >>> Major Issues: >>>=20 >>> I have no =E2=80=9CMajor=E2=80=9D issues with this I-D. >=20 > Good to hear. >=20 >>> Minor Issues: >>>=20 >>> In the Security Considerations section a small amount of text might = be useful that discusses end-end v. encryption from middle boxes, and = the risks therein. There are clearly benefits to this over no = encryption, but there are risks about assumptions that may be made = thereafter as well. >=20 > I added some text. Please review. >=20 >>> Nits: >>>=20 >>> S.1: s/typically not modified. Which means/typically not modified, = which means/ >=20 > Changed. >=20 >>> S.1: Is there in fact a case where asymmetries result in the *same* = egress xTRs but different keys are used? I believe this would just = apply to "different xTRs", no? : >=20 > Right, when the same ETR is used by different ITRs to encapsulate = traffic, different keys are used. >=20 >>> However, return traffic uses the same procedures but with = different key values by the same xTRs or potentially different xTRs when = the paths between LISP sites are asymmetric. >=20 > Right, a unique set of keys are used for each {ITR, ETR} combination. = Did you want me to say something specific here? >=20 >>> S.1: Regarding "[t]his document has the following requirements for = the solutions space", it might be useful to reference some general IETF = privacy work, even RFC 6973 or the like. Given that it's Experimental I = think it's fine as is, but some references for the broader community may = be in order. In particular, references to not requiring a separate PKI = (and therefore external or circular dependencies!), avoiding third party = trust anchor, rekeying as good operational practice, not just = compromises, and other such arguments might be reinforced.=20 >=20 > I added a reference to 6973. >=20 >>> S.3: Could include LCAF here, perhaps. >=20 > Added plus its reference. >=20 >>> S.4: You could probably strike this entire sentence and lessen = confusion: "When an ETR (when it is also an ITR) encapsulates packets to = this ITR (when it is also an ETR), a separate key exchange and = shared-secret computation is performed.=E2=80=9D >=20 > Okay, removed. >=20 >>> S.7: It=E2=80=99s unclear what constitutes =E2=80=9CDiffie-Hellman = *group*=E2=80=9D. >=20 > I will change =E2=80=9Cgroup=E2=80=9D to =E2=80=9Cparameters=E2=80=9D. >=20 >>>=20 >>> S.7: s/the the/the/ >>>=20 >>> S.7: s/integrity-check/integrity check/ >=20 > Changed both. >=20 >>> S.8: Editors note to strike text in last paragraph here, unclear = what resolution was from this text. =20 >=20 > We allocated two new bits from a 3-bit reserved field now leaving 1 = reserve bit. I added that the reserved bit remaining is documented in = RFC6830. >=20 >>> S.12.1: A reference to the SAAG comments might be useful here? >=20 > We don=E2=80=99t have one. But I will add a list of recommendations = they provided. >=20 >>> S 13: Are you sure you want a default FCFS allocation policy here = and not a slightly higher bar? >=20 > I have no opinion. What is the benefit on not doing FCFS? >=20 >>> Throughout: Consistent hyphenation in the document would help (e.g., = =E2=80=9Cnetwork-byte=E2=80=9D ..). =20 >=20 > Done. >=20 >>> Throughout: Expanding on first use of each acronym would be useful, = perhaps with references. >=20 > Done. >=20 > A new revision is attached (plus a htmlized diff file). Let me know if = you like the text and then I=E2=80=99ll submit -07. >=20 > Thanks again, > Dino & Brian >=20 > >=20 >=20 >=20 >=20 From nobody Mon Sep 19 10:25:52 2016 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 7D69712B44F; Mon, 19 Sep 2016 10:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.217 X-Spam-Level: X-Spam-Status: No, score=-104.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 a9A4h7rKb_oN; Mon, 19 Sep 2016 10:25:50 -0700 (PDT) Received: from mail.tcb.net (mail.tcb.net [64.78.239.75]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F264612B11A; Mon, 19 Sep 2016 10:25:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.tcb.net (Postfix) with ESMTP id 8F609C7; Mon, 19 Sep 2016 11:25:49 -0600 (MDT) X-Virus-Scanned: Debian amavisd-new at mailnew.seatmates.net Received: from mail.tcb.net ([127.0.0.1]) by localhost (mail.chasingbugles.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NRiiIW5ulMm; Mon, 19 Sep 2016 11:25:49 -0600 (MDT) Received: from mail.tcb.net (localhost [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tcb.net (Postfix) with ESMTPSA id 11A6DC5; Mon, 19 Sep 2016 11:25:49 -0600 (MDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 19 Sep 2016 13:25:49 -0400 From: Danny McPherson To: Dino Farinacci In-Reply-To: References: <9a0ab6afeff3fc8b86cc320a757ccbf8@tcb.net> Message-ID: X-Sender: danny@tcb.net User-Agent: Roundcube Webmail/0.9.5 Archived-At: Cc: zhang.xian@huawei.com, LISP mailing list list , Jonathan.Hardwick@metaswitch.com, draft-ietf-lisp-crypto.authors@ietf.org, Jon Hudson Subject: Re: [lisp] RTG-DIR REVIEW: draft-ietf-lisp-crypto-06.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 19 Sep 2016 17:25:51 -0000 Nothing more from me (although I don't think that's where you query was directed), all the changes look good. On the IANA question, was simply a matter of if you want to require something more rigid v. the most lax codepoint allocation model, but I don't have any strong opinion there. -danny On 2016-09-19 12:06 PM, Dino Farinacci wrote: > Any status on this? > > Dino > >> On Sep 5, 2016, at 10:07 AM, Dino Farinacci >> wrote: >> >> See responses inline. A new draft is attached (but not submitted since >> I had some open questions). >> >>>> Document: draft-ietf-lisp-crypto-06.txt >>>> >>>> Reviewer: Danny McPherson >>>> >>>> Review Date: August 24, 2016 >>>> >>>> Intended Status: Experimental >> >> Thanks for the review Danny. >> >>>> Summary: >>>> >>>> I have some minor concerns about this document that should be >>>> considered before publication. >>>> >>>> Comments: >>>> >>>> I believe the draft is technically sound. >>>> >>>> Major Issues: >>>> >>>> I have no “Major” issues with this I-D. >> >> Good to hear. >> >>>> Minor Issues: >>>> >>>> In the Security Considerations section a small amount of text might >>>> be useful that discusses end-end v. encryption from middle boxes, >>>> and the risks therein. There are clearly benefits to this over no >>>> encryption, but there are risks about assumptions that may be made >>>> thereafter as well. >> >> I added some text. Please review. >> >>>> Nits: >>>> >>>> S.1: s/typically not modified. Which means/typically not modified, >>>> which means/ >> >> Changed. >> >>>> S.1: Is there in fact a case where asymmetries result in the *same* >>>> egress xTRs but different keys are used? I believe this would just >>>> apply to "different xTRs", no? : >> >> Right, when the same ETR is used by different ITRs to encapsulate >> traffic, different keys are used. >> >>>> However, return traffic uses the same procedures but with >>>> different key values by the same xTRs or potentially different xTRs >>>> when the paths between LISP sites are asymmetric. >> >> Right, a unique set of keys are used for each {ITR, ETR} combination. >> Did you want me to say something specific here? >> >>>> S.1: Regarding "[t]his document has the following requirements for >>>> the solutions space", it might be useful to reference some general >>>> IETF privacy work, even RFC 6973 or the like. Given that it's >>>> Experimental I think it's fine as is, but some references for the >>>> broader community may be in order. In particular, references to not >>>> requiring a separate PKI (and therefore external or circular >>>> dependencies!), avoiding third party trust anchor, rekeying as good >>>> operational practice, not just compromises, and other such >>>> arguments might be reinforced. >> >> I added a reference to 6973. >> >>>> S.3: Could include LCAF here, perhaps. >> >> Added plus its reference. >> >>>> S.4: You could probably strike this entire sentence and lessen >>>> confusion: "When an ETR (when it is also an ITR) encapsulates >>>> packets to this ITR (when it is also an ETR), a separate key >>>> exchange and shared-secret computation is performed.” >> >> Okay, removed. >> >>>> S.7: It’s unclear what constitutes “Diffie-Hellman *group*”. >> >> I will change “group” to “parameters”. >> >>>> >>>> S.7: s/the the/the/ >>>> >>>> S.7: s/integrity-check/integrity check/ >> >> Changed both. >> >>>> S.8: Editors note to strike text in last paragraph here, unclear >>>> what resolution was from this text. >> >> We allocated two new bits from a 3-bit reserved field now leaving 1 >> reserve bit. I added that the reserved bit remaining is documented in >> RFC6830. >> >>>> S.12.1: A reference to the SAAG comments might be useful here? >> >> We don’t have one. But I will add a list of recommendations they >> provided. >> >>>> S 13: Are you sure you want a default FCFS allocation policy here >>>> and not a slightly higher bar? >> >> I have no opinion. What is the benefit on not doing FCFS? >> >>>> Throughout: Consistent hyphenation in the document would help (e.g., >>>> “network-byte” ..). >> >> Done. >> >>>> Throughout: Expanding on first use of each acronym would be useful, >>>> perhaps with references. >> >> Done. >> >> A new revision is attached (plus a htmlized diff file). Let me know if >> you like the text and then I’ll submit -07. >> >> Thanks again, >> Dino & Brian >> >> >> >> >> >> From nobody Mon Sep 19 10:34:31 2016 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 9514212B10C; Mon, 19 Sep 2016 10:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GI1GPKUEKM_e; Mon, 19 Sep 2016 10:34:27 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::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 E965312B485; Mon, 19 Sep 2016 10:34:26 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id p64so53076750pfb.1; Mon, 19 Sep 2016 10:34:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IkM93CjbL/OYK09qxWs2nZC74QievzRUHdZHKBDWQec=; b=PEUtehRwiVnMKUL1lEOFkW4uDqEBpMWMvdftpzncRLXmCvsA2ol9NdieRMcNWyARNv OFuE9yUX2M4sJfmzZ/EDi/tJ4cbFVNG2N0FbdocY16g/aE1qCoWUNAJhhYmSuTLGChhN k1v/9BS/+FQLrsRHwCptV5B3j2EFtzPpyWGo0+VEr7IUP+3rRt3CxjLh8xoZ7YKB06C9 0V4VC/CuBdem6jKA1QWS69vIsK5IAby921X04glQFAGdIIr4oVALi/+gBIjdMH/vWinV PE2j2NLZMB4V+PA3/58erulsoaGpiHASBel1EC2nbnva2OAqiUezndSkSthBNS4/VuWz lJtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IkM93CjbL/OYK09qxWs2nZC74QievzRUHdZHKBDWQec=; b=dKV5FUzj2L2+vNCJMJd2j2d2EhkfJRdVSlAJg3vIMcW0Jc70SX/ZdxGC0d9XRJLEAi GXodW5B80I5jdp/dhhj0MrRmaABzoWycl4A3TrlH5DaDIjs4ehIy+ioYLOZTubzfpbu/ eMVuVrSYoQIxqmm1keaZSnC8fnNKChlwbdLrlmO/R8lhHdElPCAGYG5LWQ/beVaRlyW+ s0IUuXYd7oA7maZ8lQLcHPcvwZEL15ynlHEyxbWEEqForpu/MfFBoFmbjNgQYiyhDF51 VzQN79bsTdAxBKN3/ycSiOawgFa0N8VjNTh0AsBsrXx5R4//y1Gl4MDlxxhmWFzfcKAJ fHtA== X-Gm-Message-State: AE9vXwMBK6J0LYsFgZXrYKpdN7G4caTjAztfAQt84OMHTaRncRbBYn32QfEYNlrTIjbFpA== X-Received: by 10.98.33.146 with SMTP id o18mr35269503pfj.177.1474306466504; Mon, 19 Sep 2016 10:34:26 -0700 (PDT) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id i7sm33060649paf.9.2016.09.19.10.34.22 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 19 Sep 2016 10:34:25 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: Date: Mon, 19 Sep 2016 10:34:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9a0ab6afeff3fc8b86cc320a757ccbf8@tcb.net> To: Danny McPherson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: zhang.xian@huawei.com, LISP mailing list list , Jonathan.Hardwick@metaswitch.com, draft-ietf-lisp-crypto.authors@ietf.org, Jon Hudson Subject: Re: [lisp] RTG-DIR REVIEW: draft-ietf-lisp-crypto-06.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 19 Sep 2016 17:34:29 -0000 > Nothing more from me (although I don't think that's where you query = was directed), all the changes look good. The query was for you. I wanted you to agree to the changes before I = posted the new version. > On the IANA question, was simply a matter of if you want to require = something more rigid v. the most lax codepoint allocation model, but I = don't have any strong opinion there. Okay, I will post right now. Thanks all! Dino >=20 >=20 > -danny >=20 > On 2016-09-19 12:06 PM, Dino Farinacci wrote: >> Any status on this? >> Dino >>> On Sep 5, 2016, at 10:07 AM, Dino Farinacci = wrote: >>> See responses inline. A new draft is attached (but not submitted = since I had some open questions). >>>>> Document: draft-ietf-lisp-crypto-06.txt >>>>> Reviewer: Danny McPherson >>>>> Review Date: August 24, 2016 >>>>> Intended Status: Experimental >>> Thanks for the review Danny. >>>>> Summary: >>>>> I have some minor concerns about this document that should be = considered before publication. >>>>> Comments: >>>>> I believe the draft is technically sound. >>>>> Major Issues: >>>>> I have no =E2=80=9CMajor=E2=80=9D issues with this I-D. >>> Good to hear. >>>>> Minor Issues: >>>>> In the Security Considerations section a small amount of text = might be useful that discusses end-end v. encryption from middle boxes, = and the risks therein. There are clearly benefits to this over no = encryption, but there are risks about assumptions that may be made = thereafter as well. >>> I added some text. Please review. >>>>> Nits: >>>>> S.1: s/typically not modified. Which means/typically not = modified, which means/ >>> Changed. >>>>> S.1: Is there in fact a case where asymmetries result in the = *same* egress xTRs but different keys are used? I believe this would = just apply to "different xTRs", no? : >>> Right, when the same ETR is used by different ITRs to encapsulate = traffic, different keys are used. >>>>> However, return traffic uses the same procedures but with = different key values by the same xTRs or potentially different xTRs when = the paths between LISP sites are asymmetric. >>> Right, a unique set of keys are used for each {ITR, ETR} = combination. Did you want me to say something specific here? >>>>> S.1: Regarding "[t]his document has the following requirements for = the solutions space", it might be useful to reference some general IETF = privacy work, even RFC 6973 or the like. Given that it's Experimental I = think it's fine as is, but some references for the broader community may = be in order. In particular, references to not requiring a separate PKI = (and therefore external or circular dependencies!), avoiding third party = trust anchor, rekeying as good operational practice, not just = compromises, and other such arguments might be reinforced. >>> I added a reference to 6973. >>>>> S.3: Could include LCAF here, perhaps. >>> Added plus its reference. >>>>> S.4: You could probably strike this entire sentence and lessen = confusion: "When an ETR (when it is also an ITR) encapsulates packets to = this ITR (when it is also an ETR), a separate key exchange and = shared-secret computation is performed.=E2=80=9D >>> Okay, removed. >>>>> S.7: It=E2=80=99s unclear what constitutes =E2=80=9CDiffie-Hellman = *group*=E2=80=9D. >>> I will change =E2=80=9Cgroup=E2=80=9D to =E2=80=9Cparameters=E2=80=9D.= >>>>> S.7: s/the the/the/ >>>>> S.7: s/integrity-check/integrity check/ >>> Changed both. >>>>> S.8: Editors note to strike text in last paragraph here, unclear = what resolution was from this text. >>> We allocated two new bits from a 3-bit reserved field now leaving 1 = reserve bit. I added that the reserved bit remaining is documented in = RFC6830. >>>>> S.12.1: A reference to the SAAG comments might be useful here? >>> We don=E2=80=99t have one. But I will add a list of recommendations = they provided. >>>>> S 13: Are you sure you want a default FCFS allocation policy here = and not a slightly higher bar? >>> I have no opinion. What is the benefit on not doing FCFS? >>>>> Throughout: Consistent hyphenation in the document would help = (e.g., =E2=80=9Cnetwork-byte=E2=80=9D ..). >>> Done. >>>>> Throughout: Expanding on first use of each acronym would be = useful, perhaps with references. >>> Done. >>> A new revision is attached (plus a htmlized diff file). Let me know = if you like the text and then I=E2=80=99ll submit -07. >>> Thanks again, >>> Dino & Brian >>> From nobody Mon Sep 19 10:40:46 2016 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 620BB12B4A7; Mon, 19 Sep 2016 10:40:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147430684139.31156.13324742758206985320.idtracker@ietfa.amsl.com> Date: Mon, 19 Sep 2016 10:40:41 -0700 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-crypto-07.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 19 Sep 2016 17:40:41 -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 of the IETF. Title : LISP Data-Plane Confidentiality Authors : Dino Farinacci Brian Weis Filename : draft-ietf-lisp-crypto-07.txt Pages : 19 Date : 2016-09-19 Abstract: This document describes a mechanism for encrypting LISP encapsulated traffic. The design describes how key exchange is achieved using existing LISP control-plane mechanisms as well as how to secure the LISP data-plane from third-party surveillance attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-crypto/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lisp-crypto-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-crypto-07 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 Sep 19 16:07:57 2016 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 D839912B580 for ; Mon, 19 Sep 2016 16:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=venaas-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 S-4oe7ebDUWB for ; Mon, 19 Sep 2016 16:07:50 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9DDB12B54B for ; Mon, 19 Sep 2016 16:07:46 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id l131so55510lfl.2 for ; Mon, 19 Sep 2016 16:07:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=KWEoakPNxyt7E70Tq26NlIO4ra/i9W/rrgRx03b3SFI=; b=E9SSJkRzGYZUD7LABoLABQ5pYgHfnUR6bBjAg60Htsw76XuvF/GDMViO7oYSLh7f76 CNo+VAEYKSHkcpNgw4bNXydEuHXHB6qZ1xmW3PJ8CVAAwV4mukdEVsND6AGsFfG7jNLj QTeY60rFu+nAPvWywhTGaSGrOpLCFGRVdolKttTr98RDLkY+vvnH3L/OKQ9W/YlwNpFG Jfpsw68qHHTiO5FDc0AphgXHAtfudmVzBvAwcwGBZJfTiaQ4lstrGsCsD5jX4lqKkKlx xb56r3aZYmGDrXmvq0u1MxcwGPo5rw++WafUQqMCyT6ssFxjktaKbaG6DUmC0gyzjhiu ErXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=KWEoakPNxyt7E70Tq26NlIO4ra/i9W/rrgRx03b3SFI=; b=LH8i6gXDqbg0EH7nd2wYbjx8v5k6y+k95ZseIPPgynCqg86s8cWxbTg/BoMbJbYQG3 M8KYGrMjQaZUxXu3bGh89Fg8yvu5RtG6j2ZAOPHvHqDT2VKrYX28y6HMh4K39Snv1N1l hYTRZkr5rU8iEHyxZlzwzYWPfvlfBonkcA6+/uuF4MjwkFNPkqtO1qec2Ek36D0c1+sZ F8CgQol62EVbuwFE5lOYMC66xYL0RtxSFN6ChI+17njoeteOK4CfxCeY9pEE9PVuxToa FCN9AgYdQWhTtChGgAAoS+OUKICW8Rq+mQkUZ/FRCIOxx5HdR9RJ0wA1ngaFy6XHhJON bS3w== X-Gm-Message-State: AE9vXwP/ZUGSkyuwNMs+pUyqF8RXdKkTruQTD0VuuQB6Dsx+tE384B8sLBu7BeknCWO8bzEtL3f/HnKd0R0XQw== X-Received: by 10.46.1.132 with SMTP id f4mr11609488lji.57.1474326464740; Mon, 19 Sep 2016 16:07:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.28.15 with HTTP; Mon, 19 Sep 2016 16:07:44 -0700 (PDT) In-Reply-To: <606F6D6C-B9A9-402E-8C04-96EF867C6E89@gmail.com> References: <551BDE7B-6BA3-4336-B92A-395FBE4A571D@gmail.com> <606F6D6C-B9A9-402E-8C04-96EF867C6E89@gmail.com> From: Stig Venaas Date: Mon, 19 Sep 2016 16:07:44 -0700 Message-ID: To: Dino Farinacci Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, LISP mailing list list , draft-ietf-lisp-lcaf.all@ietf.org Subject: Re: [lisp] RtgDir review: draft-ietf-lisp-lcaf-14.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 19 Sep 2016 23:07:54 -0000 Hi The changes look good. Stig On Mon, Sep 19, 2016 at 8:54 AM, Dino Farinacci wrote= : >> On Sep 9, 2016, at 4:15 PM, Stig Venaas wrote: >> >>>> In section 3 we have this paragraph: >>>> >>>> The Address Family AFI definitions from [AFI] only allocate code- >>>> points for the AFI value itself. The length of the address or entity >>>> that follows is not defined and is implied based on conventional >>>> experience. Where the LISP protocol uses LISP Canonical Addresses >>>> specifically, the address length definitions will be in this >>>> specification and take precedent over any other specification. >>>> >>>> I'm not sure what conventional experience means. Please try to find a >>> >>> Well like I said above, the AFI values defined in the AFI document are = just type values and there is no length defined. So =E2=80=9Cconventional w= isdom=E2=80=9D means that if a spec says an AFI value 1 is IPv4, we know wh= at follows is 4 bytes. Ditto for IPv6, MAC addresses, etc. >> >> In theory there should be standards/documents specifying this for each >> of the address types, and maybe could write that people should see the >> respective standards or something. I don't know if this exists for all >> the types though. > > It does not. But how about I promise you that when there is a new use-cas= e for a specific AFI, we=E2=80=99ll make sure that the AFI and its length a= re defined in that use-case document. > > Like I said, we have this for AFI=3D17 already. So I have already set an = example. > >>> better way to say it. Regarding the last sentence, what if a you want >>>> to define new LCAF encodings in the future? Is it good to say that thi= s >>>> specification takes precedent over any other? >>> >>> LCAF encodings and definitions do not change the length of an AFI encod= ed address. So I am not sure what you mean. >> >> The last sentence says "Where the LISP protocol uses LISP Canonical >> Addresses specifically, the address length definitions will be in this >> specification and take precedent over any other specification.". What >> if you in the future would like to write a separate specification that >> defines additional LISP Canonical address formats? > > Okay, I have clarified that new LCAFs that are defined in other documents= will specify length and formatting definitions. > >>> In section 3 we have this paragraph: >>>> >>>> Length: this 16-bit field is in units of bytes and covers all of the >>>> LISP Canonical Address payload, starting and including the byte >>>> after the Length field. So any LCAF encoded address will have a >>>> minimum length of 8 bytes when the Length field is 0. The 8 bytes >>>> include the AFI, Flags, Type, Reserved, and Length fields. When >>>> the AFI is not next to encoded address in a control message, then >>>> the encoded address will have a minimum length of 6 bytes when the >>>> Length field is 0. The 6 bytes include the Flags, Type, Reserved, >>>> and Length fields. >>>> >>>> Can you phrase this differently? First it says that any LCAF encoded >>> >>> No not really. It is precise up to the sentence =E2=80=9CWhen the AFI i= s not ..=E2=80=9D. >>> >>>> address has a minimum length of 8, but then it goes on to say how it >>>> sometimes is only 6. I understand what you're trying to say, but there >>>> may be a better way of stating it. >>> >>> This special case is for some LISP control-messages where the AFI is an= other place in the message but the address is somewhere else. Rather than h= ave the AFI appear twice, the LCAF length needs to be different. >>> >>> The length field always includes the entire contiguous set of LCAF byte= s including type, flags, length field, etc. >>> >>> The language is precise and accurate. Let me know how you think stating= what I did in this comment response can be put in without writing a lot of= text about a special case. >> >> The problem I see is that first you write "So any LCAF encoded address >> will have a minimum length of 8 bytes when the Length field is 0." and >> then you write "then the encoded address will have a minimum length of >> 6 bytes when the Length field is 0." I understand what you mean, but I >> feel this is a bit confusing. >> >> Maybe you could say something like: >> >> When including the AFI, an LCAF encoded address will have a minimum >> length of 8 bytes when the Length field is 0. Or start by saying that >> the minimal length is 6, and then say that it will then be 8 when the >> AFI is included. > > Changed to add your suggestion. Thanks. > >>>> Section 4.10 >>>> In this section there are several examples of using the AFI List Type, >>>> but I miss a general definition. It appears that there can be a variab= le >>>> number of AFIs in the list. Any number > 0? It might be useful to have >>> >>> Yes, a variable number. >> >> How about adding a few lines of text to 4.10 saying that you can have >> a variable number etc., explaining briefly what the general format is. >> And then say that what follows are examples? > > Done. > >> Section 4.10.3 >>>> Isn't it unusual to include the 0 termination? Since you know the >>>> length it is not really needed. When parsing one will need to check >>>> the length either way, what should one do it the string accidentally >>>> is not 0-terminated? >>> >>> Well the AFI definition in [AFI] doesn=E2=80=99t say how to terminate t= he string. But the length field will imply it. However, I wrote the =E2=80= =9Cdistinguished-name=E2=80=9D draft to specify when AFI=3D17 is used (not = only in a LCAF but by itself), how to terminate the string. I could include= that reference, but that draft is not a working group document. >>> >>> So please advise. >> >> Currently it says: >> >> Length value n: length in bytes AFI=3D17 field and the null-terminate= d >> ASCII string (the last byte of 0 is included). >> >> It might make sense to 0 terminate the DN in some cases, but at least >> here we know the string length from the value of n, so I think it >> would be better to drop it here. And as I mentioned, you cannot rely >> on the 0 for parsing, to be on the safe side you would use n anyway. > > You want to terminate the string in all cases. Because there are cases wh= ere AFI=3D17 is not used inside an LCAF encoding. And where there is no len= gth to convey the string length. And the Distinguished-Name use-case Intern= et Draft specs this for both LCAF and non-LCAF applications. > >>>> Section 7 >>>> It looks like the table in the IANA considerations doesn't include all >>>> the types defined in this document. >>> >>> That was done intentionally. The ones that are experimental are not in = this section 7 list because there is no use-case document for it yet. Maybe= the chairs can explain this better than me. >> >> I think it's still useful. If someone sees the type used, they can >> look it up in the registry. It also helps avoid that someone perhaps >> tries to reuse one of these types in new documents. If you really want >> to use one of the code points for something else in the future, a new >> document could always update the registry. > > Did Luigi=E2=80=99s response satisfy your comment? > >> BTW, it also makes me wonder if it is worth reserving any LCAF types >> for experiments. > > The space is large enough for FCFS. > >> Regards, >> Stig > > See new version enclosed. Let me know when I can post it if you like the = changes. > > Thanks again, > Dino > > > > > > > > From nobody Mon Sep 19 17:06:01 2016 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 1951312B510; Mon, 19 Sep 2016 17:05:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147432995610.31141.12884978869207734259.idtracker@ietfa.amsl.com> Date: Mon, 19 Sep 2016 17:05:56 -0700 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-lcaf-15.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 20 Sep 2016 00:05:56 -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 of the IETF. Title : LISP Canonical Address Format (LCAF) Authors : Dino Farinacci Dave Meyer Job Snijders Filename : draft-ietf-lisp-lcaf-15.txt Pages : 43 Date : 2016-09-19 Abstract: This draft defines a canonical address format encoding used in LISP control messages and in the encoding of lookup keys for the LISP Mapping Database System. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-lcaf/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lisp-lcaf-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-lcaf-15 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 Sep 19 17:06:51 2016 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 697EE12B04C; Mon, 19 Sep 2016 17:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 6qstOtBH0rLL; Mon, 19 Sep 2016 17:06:45 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5847E12B03B; Mon, 19 Sep 2016 17:06:45 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id 21so508195pfy.0; Mon, 19 Sep 2016 17:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ej/NgXIKuNaGm6FTvH5CnHjlXs/HkuPCDh29wUxJjx8=; b=GxkEvjeDop4m3/dqalC56DaAsUm+YCqrzdMnroKnjXkPCwOJ4ri/nS7gRUl7/JzMD2 Rf++GH5LTvd72A4fyI/5X/0StRxC/HOf17VwRwmUujBUVGQpi5q4nRCAlsCxU2LSG+v0 d96y1CSM4ivtxVxQVMOJylYIrNeb/FPJAG8a/+Gq8C8nC56CQ4s9zHUxPheJXPAqsFFb BYNSks7cHmypAUJyVJ+fbfIo4gpti5qQqj6niHBMVGCIgp7FZo5AANCCgDP/YqdRvb2J D3Dspfm7ZohVL7UqaHkN/WMGkcvKxqXv3+46hVCQWr/hJpwUgSnaCJSHXErTtm5ideK4 rHcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ej/NgXIKuNaGm6FTvH5CnHjlXs/HkuPCDh29wUxJjx8=; b=lHBsKuBpB6cIZeezV/qJxZCtUjdQBVV7D9/XFaCnY5Jk7uYOXWl5rwMGjpn5m6BNtl hCktfDKaVaKATUmC3EeDSdjCaJnfOPIswTFxENYTorp4JyXQyyh7B9t5KFlLCcyRO/u2 vQZhF3S5j22QncZwKsKddaaf30m672ZlcEkAJrYDFenfXUw0SwmJ2OfHv+3joFMzdAMk 6yyAzzgeVEG9lDMnAnyN+8hgSiLRMJZzRX5LIZzRVIoIqaOPxzsawqJNvIRHIXUETzns sYivdsFjnx1eV5juUzjzV/7tsa/WbIk1AtghrQNmejoZcy/ttKBJt0UGnkdHP9xcg3rD tt/w== X-Gm-Message-State: AE9vXwNKYify1feM9rNkjuemc5Km0ti/QGIHpTWrM9ofAqXvYK0U5Wpyag+iOi5Sw+bcuA== X-Received: by 10.98.99.67 with SMTP id x64mr50941910pfb.26.1474330004941; Mon, 19 Sep 2016 17:06:44 -0700 (PDT) Received: from ?IPv6:2601:646:8d01:89f0:a105:345:d1c0:66ba? ([2601:646:8d01:89f0:a105:345:d1c0:66ba]) by smtp.gmail.com with ESMTPSA id 21sm25747662pfo.80.2016.09.19.17.06.44 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 19 Sep 2016 17:06:44 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: Date: Mon, 19 Sep 2016 17:06:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2A6FBD83-97A1-45F9-8875-81CF6FE5B7E8@gmail.com> References: <551BDE7B-6BA3-4336-B92A-395FBE4A571D@gmail.com> <606F6D6C-B9A9-402E-8C04-96EF867C6E89@gmail.com> To: Stig Venaas X-Mailer: Apple Mail (2.3124) Archived-At: Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, LISP mailing list list , draft-ietf-lisp-lcaf.all@ietf.org Subject: Re: [lisp] RtgDir review: draft-ietf-lisp-lcaf-14.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 20 Sep 2016 00:06:47 -0000 -15 posted. Thanks a lot Stig! Dino > On Sep 19, 2016, at 4:07 PM, Stig Venaas wrote: >=20 > Hi >=20 > The changes look good. >=20 > Stig >=20 >=20 > On Mon, Sep 19, 2016 at 8:54 AM, Dino Farinacci = wrote: >>> On Sep 9, 2016, at 4:15 PM, Stig Venaas wrote: >>>=20 >>>>> In section 3 we have this paragraph: >>>>>=20 >>>>> The Address Family AFI definitions from [AFI] only allocate code- >>>>> points for the AFI value itself. The length of the address or = entity >>>>> that follows is not defined and is implied based on conventional >>>>> experience. Where the LISP protocol uses LISP Canonical Addresses >>>>> specifically, the address length definitions will be in this >>>>> specification and take precedent over any other specification. >>>>>=20 >>>>> I'm not sure what conventional experience means. Please try to = find a >>>>=20 >>>> Well like I said above, the AFI values defined in the AFI document = are just type values and there is no length defined. So =E2=80=9Cconventio= nal wisdom=E2=80=9D means that if a spec says an AFI value 1 is IPv4, we = know what follows is 4 bytes. Ditto for IPv6, MAC addresses, etc. >>>=20 >>> In theory there should be standards/documents specifying this for = each >>> of the address types, and maybe could write that people should see = the >>> respective standards or something. I don't know if this exists for = all >>> the types though. >>=20 >> It does not. But how about I promise you that when there is a new = use-case for a specific AFI, we=E2=80=99ll make sure that the AFI and = its length are defined in that use-case document. >>=20 >> Like I said, we have this for AFI=3D17 already. So I have already set = an example. >>=20 >>>> better way to say it. Regarding the last sentence, what if a you = want >>>>> to define new LCAF encodings in the future? Is it good to say that = this >>>>> specification takes precedent over any other? >>>>=20 >>>> LCAF encodings and definitions do not change the length of an AFI = encoded address. So I am not sure what you mean. >>>=20 >>> The last sentence says "Where the LISP protocol uses LISP Canonical >>> Addresses specifically, the address length definitions will be in = this >>> specification and take precedent over any other specification.". = What >>> if you in the future would like to write a separate specification = that >>> defines additional LISP Canonical address formats? >>=20 >> Okay, I have clarified that new LCAFs that are defined in other = documents will specify length and formatting definitions. >>=20 >>>> In section 3 we have this paragraph: >>>>>=20 >>>>> Length: this 16-bit field is in units of bytes and covers all of = the >>>>> LISP Canonical Address payload, starting and including the byte >>>>> after the Length field. So any LCAF encoded address will have = a >>>>> minimum length of 8 bytes when the Length field is 0. The 8 = bytes >>>>> include the AFI, Flags, Type, Reserved, and Length fields. = When >>>>> the AFI is not next to encoded address in a control message, = then >>>>> the encoded address will have a minimum length of 6 bytes when = the >>>>> Length field is 0. The 6 bytes include the Flags, Type, = Reserved, >>>>> and Length fields. >>>>>=20 >>>>> Can you phrase this differently? First it says that any LCAF = encoded >>>>=20 >>>> No not really. It is precise up to the sentence =E2=80=9CWhen the = AFI is not ..=E2=80=9D. >>>>=20 >>>>> address has a minimum length of 8, but then it goes on to say how = it >>>>> sometimes is only 6. I understand what you're trying to say, but = there >>>>> may be a better way of stating it. >>>>=20 >>>> This special case is for some LISP control-messages where the AFI = is another place in the message but the address is somewhere else. = Rather than have the AFI appear twice, the LCAF length needs to be = different. >>>>=20 >>>> The length field always includes the entire contiguous set of LCAF = bytes including type, flags, length field, etc. >>>>=20 >>>> The language is precise and accurate. Let me know how you think = stating what I did in this comment response can be put in without = writing a lot of text about a special case. >>>=20 >>> The problem I see is that first you write "So any LCAF encoded = address >>> will have a minimum length of 8 bytes when the Length field is 0." = and >>> then you write "then the encoded address will have a minimum length = of >>> 6 bytes when the Length field is 0." I understand what you mean, but = I >>> feel this is a bit confusing. >>>=20 >>> Maybe you could say something like: >>>=20 >>> When including the AFI, an LCAF encoded address will have a minimum >>> length of 8 bytes when the Length field is 0. Or start by saying = that >>> the minimal length is 6, and then say that it will then be 8 when = the >>> AFI is included. >>=20 >> Changed to add your suggestion. Thanks. >>=20 >>>>> Section 4.10 >>>>> In this section there are several examples of using the AFI List = Type, >>>>> but I miss a general definition. It appears that there can be a = variable >>>>> number of AFIs in the list. Any number > 0? It might be useful to = have >>>>=20 >>>> Yes, a variable number. >>>=20 >>> How about adding a few lines of text to 4.10 saying that you can = have >>> a variable number etc., explaining briefly what the general format = is. >>> And then say that what follows are examples? >>=20 >> Done. >>=20 >>> Section 4.10.3 >>>>> Isn't it unusual to include the 0 termination? Since you know the >>>>> length it is not really needed. When parsing one will need to = check >>>>> the length either way, what should one do it the string = accidentally >>>>> is not 0-terminated? >>>>=20 >>>> Well the AFI definition in [AFI] doesn=E2=80=99t say how to = terminate the string. But the length field will imply it. However, I = wrote the =E2=80=9Cdistinguished-name=E2=80=9D draft to specify when = AFI=3D17 is used (not only in a LCAF but by itself), how to terminate = the string. I could include that reference, but that draft is not a = working group document. >>>>=20 >>>> So please advise. >>>=20 >>> Currently it says: >>>=20 >>> Length value n: length in bytes AFI=3D17 field and the = null-terminated >>> ASCII string (the last byte of 0 is included). >>>=20 >>> It might make sense to 0 terminate the DN in some cases, but at = least >>> here we know the string length from the value of n, so I think it >>> would be better to drop it here. And as I mentioned, you cannot rely >>> on the 0 for parsing, to be on the safe side you would use n anyway. >>=20 >> You want to terminate the string in all cases. Because there are = cases where AFI=3D17 is not used inside an LCAF encoding. And where = there is no length to convey the string length. And the = Distinguished-Name use-case Internet Draft specs this for both LCAF and = non-LCAF applications. >>=20 >>>>> Section 7 >>>>> It looks like the table in the IANA considerations doesn't include = all >>>>> the types defined in this document. >>>>=20 >>>> That was done intentionally. The ones that are experimental are not = in this section 7 list because there is no use-case document for it yet. = Maybe the chairs can explain this better than me. >>>=20 >>> I think it's still useful. If someone sees the type used, they can >>> look it up in the registry. It also helps avoid that someone perhaps >>> tries to reuse one of these types in new documents. If you really = want >>> to use one of the code points for something else in the future, a = new >>> document could always update the registry. >>=20 >> Did Luigi=E2=80=99s response satisfy your comment? >>=20 >>> BTW, it also makes me wonder if it is worth reserving any LCAF types >>> for experiments. >>=20 >> The space is large enough for FCFS. >>=20 >>> Regards, >>> Stig >>=20 >> See new version enclosed. Let me know when I can post it if you like = the changes. >>=20 >> Thanks again, >> Dino >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 From nobody Tue Sep 20 12:24:04 2016 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 24CFB12B168; Tue, 20 Sep 2016 12:24:01 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <147439944110.27740.4142750420169987842.idtracker@ietfa.amsl.com> Date: Tue, 20 Sep 2016 12:24:01 -0700 Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-crypto@ietf.org, lisp@ietf.org Subject: [lisp] Last Call: (LISP Data-Plane Confidentiality) to Experimental RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org 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, 20 Sep 2016 19:24:03 -0000 The IESG has received a request from the Locator/ID Separation Protocol WG (lisp) to consider the following document: - 'LISP Data-Plane Confidentiality' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-10-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a mechanism for encrypting LISP encapsulated traffic. The design describes how key exchange is achieved using existing LISP control-plane mechanisms as well as how to secure the LISP data-plane from third-party surveillance attacks. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lisp-crypto/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-lisp-crypto/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Sep 20 12:25:30 2016 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 C044412B481; Tue, 20 Sep 2016 12:25:23 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <147439952378.27640.3281258876415640474.idtracker@ietfa.amsl.com> Date: Tue, 20 Sep 2016 12:25:23 -0700 Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-lcaf@ietf.org, lisp@ietf.org Subject: [lisp] Last Call: (LISP Canonical Address Format (LCAF)) to Experimental RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org 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, 20 Sep 2016 19:25:24 -0000 The IESG has received a request from the Locator/ID Separation Protocol WG (lisp) to consider the following document: - 'LISP Canonical Address Format (LCAF)' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-10-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This draft defines a canonical address format encoding used in LISP control messages and in the encoding of lookup keys for the LISP Mapping Database System. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lisp-lcaf/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-lisp-lcaf/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Sep 21 14:13:06 2016 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 DA10512B489; Wed, 21 Sep 2016 14:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8ddPQfWIA1m; Wed, 21 Sep 2016 14:13:00 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 604DB12B5D4; Wed, 21 Sep 2016 14:13:00 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id 21so22938680pfy.0; Wed, 21 Sep 2016 14:13:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:date:message-id:cc:to :mime-version; bh=7CqhoQ7jLU5nZHkS9JzT/cSK5qyxv9XnkGiJzlAV/I8=; b=lGSJQ8LgIgVViOtCRMO0v8jMzGFF1Vsna0JnIRycB4sQxRSWAVdQMEYBP+VHL6v07F ERdj6bbWUaWUzL5WIReXch6dtJxztAav62Zp1AXFPYYRRMwNv4AopNr9LZEkAELWJWbx ajU77Lv8+8zLM7tIU9akjXHXwqQ7nYvpUKs4sAr5/zvVl5+kLzjajrccsdhBYxhjP5am xAMfBi1YsaI/ZVQJuXcx3w5Q9g7igu1G9lTukV4kThxKQNx9/U7+M4tdaFGgin3XhBH8 jpqPhztVaxWd/SUocDtnB3G79lPLnBSZSICkRFrEt2nPQQui5ObD17DTk0u0MtCUDeNw 2mvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject:date :message-id:cc:to:mime-version; bh=7CqhoQ7jLU5nZHkS9JzT/cSK5qyxv9XnkGiJzlAV/I8=; b=ZwMqzM8HcL888kww9EwWbjNwkBNELHlBC8duMxoj+TYetT0XdvRDd1OIqsfe12qYvx KyBrljB7xJqemd6B5+oovAQQnxgjKBubaWQu0l4lMsH4JqQkRblB7mj81KrJzecF2Db0 /5cniUwBKqmBD+wy/0Iwv7EuoTg4+kPEm2IOW572+HLQZOtdolHpLwa0DHxv3dVOnFtV nyMcH6tIuVjn/RV1O00NmQUvlpVA2vl403Zi9eHYV4mIc8QvOCShdSnBi+Cz6caxFNpZ +fqlQ0iAWSNj1vE9dciAx8i/lKFtF9iCjpNdhjagCp12Y5wPdY6WMqvEJXkRTEJIXaMm Apzw== X-Gm-Message-State: AE9vXwP9zyZ39d0nqEPE+SajpldWNwVYKwIaGfGkFgOn7ynwoenqtdlNuZFAk+yunPIq5w== X-Received: by 10.98.71.5 with SMTP id u5mr67415318pfa.98.1474492380001; Wed, 21 Sep 2016 14:13:00 -0700 (PDT) Received: from [172.31.98.172] (mobile-166-184-174-155.mycingular.net. [166.184.174.155]) by smtp.gmail.com with ESMTPSA id y1sm44285pfd.90.2016.09.21.14.12.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 21 Sep 2016 14:12:58 -0700 (PDT) From: Dino Farinacci Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Sep 2016 14:12:57 -0700 Message-Id: <32C28142-350A-4242-A9C6-9E32D9966601@gmail.com> To: ideas@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: beta@lispers.net, LISP mailing list list , NVO3 , lisp-alpha@external.cisco.com, LISPmob , 5gangip@ietf.org, lisp-ops@external.cisco.com Subject: [lisp] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 21 Sep 2016 21:13:02 -0000 Hello folks. In draft-padma-ideas-problem-statement-00.txt, we have a = section on mapping system requirements for map-n-encap and translation = based loc/id split protocols. Rather than having you go into the = document in detail (we wish you would and comment though), I will = provide the short list below to attempt a discussion on requirements.=20 I have copied the possible WGs that may want to use the mapping system = technology. And I have also copied the LISP working group who can shed = expertise on the subject as well as some beta lists that have some = operational experiences with mapping database deployment and management. The requirements below have a security and robustness twist to it but I = think that is the best place to start and to consider security =E2=80=9Cup= front=E2=80=9D. Thanks in advance, Dino ---- 6.4. Mapping System Security The secure mapping system must have the following requirements: 1. The components of the mapping system need to be robust against direct and indirect attacks. If any component is attacked, the rest of the system should act with integrity and scale and only the information associated with the compromised component is made unavailable. 2. The addition and removal of components of the mapping system must be performed in a secure matter so as to not violate the integrity and operation of the system and service it provides. 3. The information returned by components of the mapping system needs to be authenticated as to detect spoofing from masqueraders. 4. Information registered (by publishers) to the mapping system must be authenticated so the registering entity or the information is not spoofed. 5. The mapping system must allow request access (for subscribers) to be open and public. However, it is optional to provide confidentiality and authentication of the requesters and the information they are requesting. 6. Any information provided by components of the mapping system must be cryptographically signed by the provider and verified by the consumer. 7. Message rate-limiting and other heuristics must be part of the foundational support of the mapping system to protect the system from invalid overloaded conditions. 8. The mapping system should support some form of provisioned policy. Either internal to the system or via mechanisms for users of the system to describe policy rules. Access control should not use traditional granular-based access lists since they do not scale and are hard to manage. By the use of token- or key- based authentication methods as well as deploying multiple instances of the mapping system will allow acceptable policy profiles. Machine learning techniques could automate these mechanisms.= From nobody Wed Sep 21 15:51:36 2016 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 5A90A12B827; Wed, 21 Sep 2016 15:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAYlMhHarPYB; Wed, 21 Sep 2016 15:51:29 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::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 DB25912BC9F; Wed, 21 Sep 2016 15:51:09 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id z123so23616054pfz.2; Wed, 21 Sep 2016 15:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SdhnoqxT3CNMkc/RcMhr4ychF7tdTd2S5noYF4lz7sI=; b=s7UD2Q1mBZKtvJDT1ulH/C/wNaLQoWyXmxCIkJe28+7y6WtQn9i8QhUq49JftFBMC5 oOtcwtfEtOHA585Vxeic84EAncTtMNCrDjCukx0XExRQdTNWXA4MmjxWCnWAXxoKZonR 6SI9G1RBlNMgjLwhIX169FrL7jPqvenR90nG77Cf7azyrhi23exlE/kwzP3sP64pJth3 YBPc3RsYHEMzbrTFO2lwtSVTXKVl9CSLpTHUUcWJYpl+G8dr7qQmX2SARwXZkOx8t5y5 utOPBgyPecGs217fFDAx2UP7teE2zfQ6R5Vx513+vEdwLFOaV9WKofqlESIN0C74uEno yCXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SdhnoqxT3CNMkc/RcMhr4ychF7tdTd2S5noYF4lz7sI=; b=mSVmOabqvbJ0GABeE6iTzHPb2isvdaeAjyP0JAOTbTsVSpANiM3jLzfV4fLZHwZMbb 5ne0u4taz9yb6bf5vzpPdrG9FvRz+9cnir36PawO0HwRtByAqQaIqNlE+/qo34Pv9ZKz vdV7jh6xE/EsLUFbQkd+9bLjddnmrGauWTKIxFuR9nnuiO8Bb0KH8TbtVS8wUurDfNmM JjVf/fH4abv0DeR5VSG1VLQE60DhbSl6Xp+EMN0vsrjKuCOLUMayhdFyo18fEcIBqYpx 05HgPYC8j3h3ti0WIO5jipeOzWUQONvDDQ7Aat3B5+iDLYisPWWj8yBCeqmNmvbeI9To akFw== X-Gm-Message-State: AE9vXwNIxL6jIiKLLmFTFS+5+GzUJsemK5bhcShUnUveEkQB3DgleveieIlkmoO0bIp3vg== X-Received: by 10.98.58.65 with SMTP id h62mr69173756pfa.82.1474498269520; Wed, 21 Sep 2016 15:51:09 -0700 (PDT) Received: from ?IPv6:2601:646:8d01:89f0:1d22:29e0:ddaa:5135? ([2601:646:8d01:89f0:1d22:29e0:ddaa:5135]) by smtp.gmail.com with ESMTPSA id f202sm282204pfa.12.2016.09.21.15.51.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 21 Sep 2016 15:51:08 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: <32C28142-350A-4242-A9C6-9E32D9966601@gmail.com> Date: Wed, 21 Sep 2016 15:51:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8CC1E61E-0A8F-41D3-B30D-5B037BAEDEB1@gmail.com> References: <32C28142-350A-4242-A9C6-9E32D9966601@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.3124) Archived-At: Cc: beta@lispers.net, ideas@ietf.org, LISP mailing list list , NVO3 , LISPmob , 5gangip@ietf.org, lisp-beta@external.cisco.com Subject: Re: [lisp] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 21 Sep 2016 22:51:31 -0000 Reposting since the cisco mailing lists are no longer in service. Please = respond to this email. Thanks and sorry for inconvenience, Dino > On Sep 21, 2016, at 2:12 PM, Dino Farinacci = wrote: >=20 > Hello folks. In draft-padma-ideas-problem-statement-00.txt, we have a = section on mapping system requirements for map-n-encap and translation = based loc/id split protocols. Rather than having you go into the = document in detail (we wish you would and comment though), I will = provide the short list below to attempt a discussion on requirements.=20 >=20 > I have copied the possible WGs that may want to use the mapping system = technology. And I have also copied the LISP working group who can shed = expertise on the subject as well as some beta lists that have some = operational experiences with mapping database deployment and management. >=20 > The requirements below have a security and robustness twist to it but = I think that is the best place to start and to consider security =E2=80=9C= up front=E2=80=9D. >=20 > Thanks in advance, > Dino >=20 > ---- >=20 > 6.4. Mapping System Security >=20 > The secure mapping system must have the following requirements: >=20 > 1. The components of the mapping system need to be robust against > direct and indirect attacks. If any component is attacked, the > rest of the system should act with integrity and scale and only > the information associated with the compromised component is = made > unavailable. >=20 > 2. The addition and removal of components of the mapping system = must > be performed in a secure matter so as to not violate the > integrity and operation of the system and service it provides. >=20 > 3. The information returned by components of the mapping system > needs to be authenticated as to detect spoofing from > masqueraders. >=20 > 4. Information registered (by publishers) to the mapping system = must > be authenticated so the registering entity or the information is > not spoofed. >=20 > 5. The mapping system must allow request access (for subscribers) = to > be open and public. However, it is optional to provide > confidentiality and authentication of the requesters and the > information they are requesting. >=20 > 6. Any information provided by components of the mapping system = must > be cryptographically signed by the provider and verified by the > consumer. >=20 > 7. Message rate-limiting and other heuristics must be part of the > foundational support of the mapping system to protect the system > from invalid overloaded conditions. >=20 > 8. The mapping system should support some form of provisioned > policy. Either internal to the system or via mechanisms for > users of the system to describe policy rules. Access control > should not use traditional granular-based access lists since = they > do not scale and are hard to manage. By the use of token- or > key- based authentication methods as well as deploying multiple > instances of the mapping system will allow acceptable policy > profiles. Machine learning techniques could automate these > mechanisms. From nobody Wed Sep 21 16:21:15 2016 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 28B7912B529; Wed, 21 Sep 2016 16:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=KLH92tIG; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=Ho8eafmE 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 FbBMnxz2LfH1; Wed, 21 Sep 2016 16:20:55 -0700 (PDT) Received: from esa7.dell-outbound.iphmx.com (esa7.dell-outbound.iphmx.com [68.232.153.96]) (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 8F1A612D0AF; Wed, 21 Sep 2016 16:19:28 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Cc:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-Transfer-Encoding:MIME-Version: X-Sentrion-Hostname:X-RSA-Classifications; b=L8uDuKzOgP5g5DeQEDdtYLlfS8pqUGPUOvHfEf8vSOTLEpm4U1sqE1L0 XUfzh2Mrbl9JFOKItQ7n4u+bB/4mJatG5pF7L10GwZJTO5xxm1VHIg0tO aN2qnMuhr+A4wafzn/hO4Q2ngo7/u2TgX1Kj12ca7OD06kDxwQjimscCk 8=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1474499968; x=1506035968; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MFVfshT1pRRbudRcBycS1hU092ICxV9K9kTBsvTfjh8=; b=KLH92tIGqhodqVhYZLmwiluINjhtUlDfAqRyxUDNWziEVFqfqppjW2Iu Er204mk13OVrHq4nZJFbgZUH7z8Vdj2q/K3TyeBTj6slDcBC964F1k5T8 tKNKp4vSu6WcjLQvRgFJq8sfYYxXRTlTXVfOzqcDnrN9hs1WvjP9r2KNf s=; Received: from esa5.dell-outbound2.iphmx.com ([68.232.153.203]) by esa7.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Sep 2016 18:19:26 -0500 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa5.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Sep 2016 05:19:25 +0600 Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u8LNJMlF019502 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Sep 2016 19:19:24 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com u8LNJMlF019502 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1474499964; bh=9xewPXR6x/UdLoAcMFF4NguhZE4=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Ho8eafmEM9YMcj/WtW4HbeAQPn39g3UycjM+HWsb4eHCYxftLDdg7Ta+betIuazx1 xpV4KcCvRvl6Yc2YixE56ZnPOCiFzPpYFvu+5gcASfDbS2MxaU1W+K0ki/PfunZuUC Mn8VQW9bNNnQQc6UGE4uTqsTQrf5kmpzMpjRMH28= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com u8LNJMlF019502 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd04.lss.emc.com (RSA Interceptor); Wed, 21 Sep 2016 19:18:38 -0400 Received: from MXHUB319.corp.emc.com (MXHUB319.corp.emc.com [10.146.3.97]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u8LNJ1gZ001801 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 21 Sep 2016 19:19:01 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB319.corp.emc.com ([10.146.3.97]) with mapi id 14.03.0266.001; Wed, 21 Sep 2016 19:19:01 -0400 To: Dino Farinacci Thread-Topic: [nvo3] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt Thread-Index: AQHSFE0AGalANv3mDky1UF0kWTQPrqCEz7uA///BHPA= Date: Wed, 21 Sep 2016 23:19:00 +0000 Message-ID: References: <32C28142-350A-4242-A9C6-9E32D9966601@gmail.com> <8CC1E61E-0A8F-41D3-B30D-5B037BAEDEB1@gmail.com> In-Reply-To: <8CC1E61E-0A8F-41D3-B30D-5B037BAEDEB1@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.97.1.147] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "beta@lispers.net" , "ideas@ietf.org" , LISP mailing list list , NVO3 , "Black, David" , LISPmob , "5gangip@ietf.org" <5gangip@ietf.org>, "lisp-beta@external.cisco.com" Subject: Re: [lisp] [nvo3] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 21 Sep 2016 23:20:58 -0000 SGkgRGlubywNCg0KSGVyZSBhcmUgYSBjb3VwbGUgb2YgYXJlYXMgdG8gY29uc2lkZXI6DQoNCigx KSBJIGRvbid0IHNlZSBhbnkgY29uZmlkZW50aWFsaXR5IHJlcXVpcmVtZW50cy4gICBGb3IgdGhp cyBhbmQgb3RoZXIgTlZPMyBzZWN1cml0eQ0KcmVxdWlyZW1lbnRzLCBwbGVhc2Ugc2VlIHRoZSBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIG9mIFJGQyA3MzY1IChOVk8zDQpmcmFtZXdv cmspIGFuZCBkcmFmdC1pZXRmLW52bzMtYXJjaC4gIFRoZSBsYXR0ZXIgY29udGFpbnMgYSBuZXcg cGFyYWdyYXBoIG9uDQpzZW5zaXRpdml0eSBvZiBwZXJmb3JtYW5jZSBhbmQgIG90aGVyIG1vbml0 b3JpbmcgZGF0YSBnYXRoZXJlZCBieSB0aGUgY29udHJvbA0KcGxhbmUgLSB0aGF0IHBhcmFncmFw aCB3YXMgYWRkZWQgYXQgdGhlIGJlaGVzdCBvZiBib3RoIFNlY3VyaXR5IEFEczoNCg0KaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzczNjUjc2VjdGlvbi01DQpodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1udm8zLWFyY2gtMDgjc2VjdGlvbi0xNg0KDQooMikgVGhp cyBpdGVtOg0KDQo+ID4gICA3LiAgTWVzc2FnZSByYXRlLWxpbWl0aW5nIGFuZCBvdGhlciBoZXVy aXN0aWNzIG11c3QgYmUgcGFydCBvZiB0aGUNCj4gPiAgICAgICBmb3VuZGF0aW9uYWwgc3VwcG9y dCBvZiB0aGUgbWFwcGluZyBzeXN0ZW0gdG8gcHJvdGVjdCB0aGUgc3lzdGVtDQo+ID4gICAgICAg ZnJvbSBpbnZhbGlkIG92ZXJsb2FkZWQgY29uZGl0aW9ucy4NCg0Kc3VnZ2VzdHMgdGhhdCBjb25n ZXN0aW9uIGNvbnRyb2wgaXMgYWxzbyBhIGNvbnNpZGVyYXRpb24gdG8gcHJvdGVjdCB0aGUgbmV0 d29yay4NCklmIGFuIGV4aXN0aW5nIGNvbmdlc3Rpb24tY29udHJvbGxlZCB0cmFuc3BvcnQgcHJv dG9jb2wgKGUuZy4sIFRDUCwgU0NUUCwgRENDUCkgaXMNCm5vdCB1c2VkIGZvciBjb250cm9sIHRy YWZmaWMsIHRoZW4gc2VlIGRyYWZ0LWlldGYtdHN2d2ctcmZjNTQwNWJpcyBmb3IgZGlzY3Vzc2lv bg0Kb2YgYXBwbGljYWJsZSByZXF1aXJlbWVudHM6DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHN2d2ctcmZjNTQwNWJpcy8NCg0KVGhhbmtzLCAtLURhdmlk DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbnZvMyBbbWFpbHRvOm52 bzMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERpbm8gRmFyaW5hY2NpDQo+IFNlbnQ6 IFdlZG5lc2RheSwgU2VwdGVtYmVyIDIxLCAyMDE2IDY6NTEgUE0NCj4gVG86IERpbm8gRmFyaW5h Y2NpDQo+IENjOiBiZXRhQGxpc3BlcnMubmV0OyBpZGVhc0BpZXRmLm9yZzsgTElTUCBtYWlsaW5n IGxpc3QgbGlzdDsgTlZPMzsgTElTUG1vYjsNCj4gNWdhbmdpcEBpZXRmLm9yZzsgbGlzcC1iZXRh QGV4dGVybmFsLmNpc2NvLmNvbQ0KPiBTdWJqZWN0OiBSZTogW252bzNdIE1hcHBpbmcgU3lzdGVt IFJlcXVpcmVtZW50cyBhbmQgZHJhZnQtcGFkbWEtaWRlYXMtDQo+IHByb2JsZW0tc3RhdGVtZW50 LTAwLnR4dA0KPiANCj4gUmVwb3N0aW5nIHNpbmNlIHRoZSBjaXNjbyBtYWlsaW5nIGxpc3RzIGFy ZSBubyBsb25nZXIgaW4gc2VydmljZS4gUGxlYXNlIHJlc3BvbmQgdG8NCj4gdGhpcyBlbWFpbC4N Cj4gDQo+IFRoYW5rcyBhbmQgc29ycnkgZm9yIGluY29udmVuaWVuY2UsDQo+IERpbm8NCj4gDQo+ ID4gT24gU2VwIDIxLCAyMDE2LCBhdCAyOjEyIFBNLCBEaW5vIEZhcmluYWNjaSA8ZmFyaW5hY2Np QGdtYWlsLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBIZWxsbyBmb2xrcy4gSW4gZHJhZnQtcGFkbWEt aWRlYXMtcHJvYmxlbS1zdGF0ZW1lbnQtMDAudHh0LCB3ZSBoYXZlIGEgc2VjdGlvbg0KPiBvbiBt YXBwaW5nIHN5c3RlbSByZXF1aXJlbWVudHMgZm9yIG1hcC1uLWVuY2FwIGFuZCB0cmFuc2xhdGlv biBiYXNlZCBsb2MvaWQNCj4gc3BsaXQgcHJvdG9jb2xzLiBSYXRoZXIgdGhhbiBoYXZpbmcgeW91 IGdvIGludG8gdGhlIGRvY3VtZW50IGluIGRldGFpbCAod2Ugd2lzaA0KPiB5b3Ugd291bGQgYW5k IGNvbW1lbnQgdGhvdWdoKSwgSSB3aWxsIHByb3ZpZGUgdGhlIHNob3J0IGxpc3QgYmVsb3cgdG8g YXR0ZW1wdCBhDQo+IGRpc2N1c3Npb24gb24gcmVxdWlyZW1lbnRzLg0KPiA+DQo+ID4gSSBoYXZl IGNvcGllZCB0aGUgcG9zc2libGUgV0dzIHRoYXQgbWF5IHdhbnQgdG8gdXNlIHRoZSBtYXBwaW5n IHN5c3RlbQ0KPiB0ZWNobm9sb2d5LiBBbmQgSSBoYXZlIGFsc28gY29waWVkIHRoZSBMSVNQIHdv cmtpbmcgZ3JvdXAgd2hvIGNhbiBzaGVkDQo+IGV4cGVydGlzZSBvbiB0aGUgc3ViamVjdCBhcyB3 ZWxsIGFzIHNvbWUgYmV0YSBsaXN0cyB0aGF0IGhhdmUgc29tZSBvcGVyYXRpb25hbA0KPiBleHBl cmllbmNlcyB3aXRoIG1hcHBpbmcgZGF0YWJhc2UgZGVwbG95bWVudCBhbmQgbWFuYWdlbWVudC4N Cj4gPg0KPiA+IFRoZSByZXF1aXJlbWVudHMgYmVsb3cgaGF2ZSBhIHNlY3VyaXR5IGFuZCByb2J1 c3RuZXNzIHR3aXN0IHRvIGl0IGJ1dCBJIHRoaW5rDQo+IHRoYXQgaXMgdGhlIGJlc3QgcGxhY2Ug dG8gc3RhcnQgYW5kIHRvIGNvbnNpZGVyIHNlY3VyaXR5IOKAnHVwIGZyb2504oCdLg0KPiA+DQo+ ID4gVGhhbmtzIGluIGFkdmFuY2UsDQo+ID4gRGlubw0KPiA+DQo+ID4gLS0tLQ0KPiA+DQo+ID4g Ni40LiAgTWFwcGluZyBTeXN0ZW0gU2VjdXJpdHkNCj4gPg0KPiA+ICAgVGhlIHNlY3VyZSBtYXBw aW5nIHN5c3RlbSBtdXN0IGhhdmUgdGhlIGZvbGxvd2luZyByZXF1aXJlbWVudHM6DQo+ID4NCj4g PiAgIDEuICBUaGUgY29tcG9uZW50cyBvZiB0aGUgbWFwcGluZyBzeXN0ZW0gbmVlZCB0byBiZSBy b2J1c3QgYWdhaW5zdA0KPiA+ICAgICAgIGRpcmVjdCBhbmQgaW5kaXJlY3QgYXR0YWNrcy4gIElm IGFueSBjb21wb25lbnQgaXMgYXR0YWNrZWQsIHRoZQ0KPiA+ICAgICAgIHJlc3Qgb2YgdGhlIHN5 c3RlbSBzaG91bGQgYWN0IHdpdGggaW50ZWdyaXR5IGFuZCBzY2FsZSBhbmQgb25seQ0KPiA+ICAg ICAgIHRoZSBpbmZvcm1hdGlvbiBhc3NvY2lhdGVkIHdpdGggdGhlIGNvbXByb21pc2VkIGNvbXBv bmVudCBpcyBtYWRlDQo+ID4gICAgICAgdW5hdmFpbGFibGUuDQo+ID4NCj4gPiAgIDIuICBUaGUg YWRkaXRpb24gYW5kIHJlbW92YWwgb2YgY29tcG9uZW50cyBvZiB0aGUgbWFwcGluZyBzeXN0ZW0g bXVzdA0KPiA+ICAgICAgIGJlIHBlcmZvcm1lZCBpbiBhIHNlY3VyZSBtYXR0ZXIgc28gYXMgdG8g bm90IHZpb2xhdGUgdGhlDQo+ID4gICAgICAgaW50ZWdyaXR5IGFuZCBvcGVyYXRpb24gb2YgdGhl IHN5c3RlbSBhbmQgc2VydmljZSBpdCBwcm92aWRlcy4NCj4gPg0KPiA+ICAgMy4gIFRoZSBpbmZv cm1hdGlvbiByZXR1cm5lZCBieSBjb21wb25lbnRzIG9mIHRoZSBtYXBwaW5nIHN5c3RlbQ0KPiA+ ICAgICAgIG5lZWRzIHRvIGJlIGF1dGhlbnRpY2F0ZWQgYXMgdG8gZGV0ZWN0IHNwb29maW5nIGZy b20NCj4gPiAgICAgICBtYXNxdWVyYWRlcnMuDQo+ID4NCj4gPiAgIDQuICBJbmZvcm1hdGlvbiBy ZWdpc3RlcmVkIChieSBwdWJsaXNoZXJzKSB0byB0aGUgbWFwcGluZyBzeXN0ZW0gbXVzdA0KPiA+ ICAgICAgIGJlIGF1dGhlbnRpY2F0ZWQgc28gdGhlIHJlZ2lzdGVyaW5nIGVudGl0eSBvciB0aGUg aW5mb3JtYXRpb24gaXMNCj4gPiAgICAgICBub3Qgc3Bvb2ZlZC4NCj4gPg0KPiA+ICAgNS4gIFRo ZSBtYXBwaW5nIHN5c3RlbSBtdXN0IGFsbG93IHJlcXVlc3QgYWNjZXNzIChmb3Igc3Vic2NyaWJl cnMpIHRvDQo+ID4gICAgICAgYmUgb3BlbiBhbmQgcHVibGljLiAgSG93ZXZlciwgaXQgaXMgb3B0 aW9uYWwgdG8gcHJvdmlkZQ0KPiA+ICAgICAgIGNvbmZpZGVudGlhbGl0eSBhbmQgYXV0aGVudGlj YXRpb24gb2YgdGhlIHJlcXVlc3RlcnMgYW5kIHRoZQ0KPiA+ICAgICAgIGluZm9ybWF0aW9uIHRo ZXkgYXJlIHJlcXVlc3RpbmcuDQo+ID4NCj4gPiAgIDYuICBBbnkgaW5mb3JtYXRpb24gcHJvdmlk ZWQgYnkgY29tcG9uZW50cyBvZiB0aGUgbWFwcGluZyBzeXN0ZW0gbXVzdA0KPiA+ICAgICAgIGJl IGNyeXB0b2dyYXBoaWNhbGx5IHNpZ25lZCBieSB0aGUgcHJvdmlkZXIgYW5kIHZlcmlmaWVkIGJ5 IHRoZQ0KPiA+ICAgICAgIGNvbnN1bWVyLg0KPiA+DQo+ID4gICA3LiAgTWVzc2FnZSByYXRlLWxp bWl0aW5nIGFuZCBvdGhlciBoZXVyaXN0aWNzIG11c3QgYmUgcGFydCBvZiB0aGUNCj4gPiAgICAg ICBmb3VuZGF0aW9uYWwgc3VwcG9ydCBvZiB0aGUgbWFwcGluZyBzeXN0ZW0gdG8gcHJvdGVjdCB0 aGUgc3lzdGVtDQo+ID4gICAgICAgZnJvbSBpbnZhbGlkIG92ZXJsb2FkZWQgY29uZGl0aW9ucy4N Cj4gPg0KPiA+ICAgOC4gIFRoZSBtYXBwaW5nIHN5c3RlbSBzaG91bGQgc3VwcG9ydCBzb21lIGZv cm0gb2YgcHJvdmlzaW9uZWQNCj4gPiAgICAgICBwb2xpY3kuICBFaXRoZXIgaW50ZXJuYWwgdG8g dGhlIHN5c3RlbSBvciB2aWEgbWVjaGFuaXNtcyBmb3INCj4gPiAgICAgICB1c2VycyBvZiB0aGUg c3lzdGVtIHRvIGRlc2NyaWJlIHBvbGljeSBydWxlcy4gIEFjY2VzcyBjb250cm9sDQo+ID4gICAg ICAgc2hvdWxkIG5vdCB1c2UgdHJhZGl0aW9uYWwgZ3JhbnVsYXItYmFzZWQgYWNjZXNzIGxpc3Rz IHNpbmNlIHRoZXkNCj4gPiAgICAgICBkbyBub3Qgc2NhbGUgYW5kIGFyZSBoYXJkIHRvIG1hbmFn ZS4gIEJ5IHRoZSB1c2Ugb2YgdG9rZW4tIG9yDQo+ID4gICAgICAga2V5LSBiYXNlZCBhdXRoZW50 aWNhdGlvbiBtZXRob2RzIGFzIHdlbGwgYXMgZGVwbG95aW5nIG11bHRpcGxlDQo+ID4gICAgICAg aW5zdGFuY2VzIG9mIHRoZSBtYXBwaW5nIHN5c3RlbSB3aWxsIGFsbG93IGFjY2VwdGFibGUgcG9s aWN5DQo+ID4gICAgICAgcHJvZmlsZXMuICBNYWNoaW5lIGxlYXJuaW5nIHRlY2huaXF1ZXMgY291 bGQgYXV0b21hdGUgdGhlc2UNCj4gPiAgICAgICBtZWNoYW5pc21zLg0KPiANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbnZvMyBtYWlsaW5nIGxp c3QNCj4gbnZvM0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL252bzMNCg== From nobody Wed Sep 21 23:48:39 2016 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 131B412B6A0; Wed, 21 Sep 2016 23:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] 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 iFj68RcVuM8p; Wed, 21 Sep 2016 23:48:24 -0700 (PDT) Received: from mx04.uni-tuebingen.de (mx04.uni-tuebingen.de [134.2.5.214]) (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 52BC612B849; Wed, 21 Sep 2016 23:48:24 -0700 (PDT) Received: from [192.168.1.100] (hsi-kbw-109-193-156-013.hsi7.kabel-badenwuerttemberg.de [109.193.156.13]) by mx04.uni-tuebingen.de (Postfix) with ESMTPSA id 5CDA9861BF; Thu, 22 Sep 2016 08:48:22 +0200 (CEST) To: "Black, David" , Dino Farinacci References: <32C28142-350A-4242-A9C6-9E32D9966601@gmail.com> <8CC1E61E-0A8F-41D3-B30D-5B037BAEDEB1@gmail.com> From: Michael Menth Message-ID: <57E37EC3.3010407@uni-tuebingen.de> Date: Thu, 22 Sep 2016 08:48:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "beta@lispers.net" , "ideas@ietf.org" , LISP mailing list list , NVO3 , LISPmob , "5gangip@ietf.org" <5gangip@ietf.org>, "lisp-beta@external.cisco.com" Subject: Re: [lisp] [nvo3] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 22 Sep 2016 06:48:27 -0000 Hi David, 5. The mapping system must allow request access (for subscribers) to be open and public. However, it is optional to provide confidentiality and authentication of the requesters and the information they are requesting. > > (1) I don't see any confidentiality requirements. The optional requirement for confidentiality was added for potential use cases where only some users are allowed to access information about others. Motivation: snooping mapping system informatation may be a way to track the behavior of other users. Regards, Michael -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://kn.inf.uni-tuebingen.de From nobody Thu Sep 22 11:08:58 2016 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 0E8CD12B5A9; Thu, 22 Sep 2016 11:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umS0grvij324; Thu, 22 Sep 2016 11:08:51 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (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 A846E12B05A; Thu, 22 Sep 2016 11:08:51 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id z123so33012144pfz.2; Thu, 22 Sep 2016 11:08:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DUH5fPBTyYQ4XR91X/cpbZInQmjy+mjvF2FvDRoh7nk=; b=QWAxjiMlYmM7c/0WllEN48xmV+qUOngpJMluHZMBZollACRyldvr14ctMkue5mswux fhLBofePp+AaF/fJuDd4grKGVZXYJ1A0A3IIxoPdf6EwvtXbG87okqbo1yE72mVZeTbl ZsNCSJYdH5hurL6w1s6nDdzVtLYK5crsu2ZbN6hb+ARkdFbqfzIo+nossfxuAXf9dmm3 k0z+mNmcd//UsfW2wnENprD83m9hjdpzT61oEhYz4zkc0cGNta8AEda9jt1Khe9mXZos gu5OsLWVlzbr4wuX4+nOGKHuabDLBaqJk72MykypePE+p5AY3k6Q9IE+q+2CHwMJ7tpV TCbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DUH5fPBTyYQ4XR91X/cpbZInQmjy+mjvF2FvDRoh7nk=; b=SrTiNIWKiY6fDrIpAIvwYx4ZqLsNQVuZa2h47+y3xW1YdANCuZObwlKsRG3qPh9RZ0 Gf2EJkahMR2L1dXQRLMiDIQN1rcLG/ik72hUSl71YIMDIKliXmf+N9nSiWF6RlPdougb Q9k+nb2Br112jXRIGxkcLj48obczw1nDZqqbwa+W2a0Wumv1bepQBD0HMQsAHgD7XuYL 9WcvMpMGQpskKOHO5X9x0MJXLz/IMzX/1NfuvT3vjAUxdJHnbnx3fapwYx/1N/KTRIT+ jiFZsD8HU5GEUwYwAjYKFkCRWPA8eSzV7SutcvRcf6qVdLDv19FzHY1dhPFV7V2s8aDZ sPeA== X-Gm-Message-State: AE9vXwOKkOclH3oGufx+BuGpPfOtmxh6jo0So2wkEktRM92vldUsbuztEViOKTFAVze2Hw== X-Received: by 10.98.86.11 with SMTP id k11mr5360681pfb.182.1474567731287; Thu, 22 Sep 2016 11:08:51 -0700 (PDT) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id an11sm5677355pac.26.2016.09.22.11.08.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 22 Sep 2016 11:08:50 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: <57E37EC3.3010407@uni-tuebingen.de> Date: Thu, 22 Sep 2016 11:08:50 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <32C28142-350A-4242-A9C6-9E32D9966601@gmail.com> <8CC1E61E-0A8F-41D3-B30D-5B037BAEDEB1@gmail.com> <57E37EC3.3010407@uni-tuebingen.de> To: Michael Menth X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "beta@lispers.net" , "ideas@ietf.org" , LISP mailing list list , NVO3 , "Black, David" , LISPmob , "5gangip@ietf.org" <5gangip@ietf.org>, "lisp-beta@external.cisco.com" Subject: Re: [lisp] [nvo3] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 22 Sep 2016 18:08:57 -0000 > The optional requirement for confidentiality was added for potential use > cases where only some users are allowed to access information about > others. Motivation: snooping mapping system informatation may be a way > to track the behavior of other users. Especially if GPS coordinates were part of the RLOC-records. Dino From nobody Thu Sep 22 22:17:22 2016 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 250EF12BDDE; Thu, 22 Sep 2016 22:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 O6sZrDp68BY3; Thu, 22 Sep 2016 22:17:19 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 4EC7012BD09; Thu, 22 Sep 2016 22:17:19 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id g67so36634195qkd.0; Thu, 22 Sep 2016 22:17:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3pCfiWIXhMMhZN45mfQ5eTQ8VmGehL2+S1OfjUOFgf4=; b=EKBMHtCGR/0BHlM8/9SwqzNuoZPLTDGY+wjk+VEBtC5c4iLgX9cuR0Mub2cNeOtRuW EuliE8Pn/uSfF/80uPztZNVQKikVZwwb+03qiBZpXf9vtUA7xZioovOTDzau7CxhreTZ SV/1FbGn0ao2Bo5U38Mt1nVOvwBKs7Xa5CfPoNKswzvaTvoulM3Dt76Rck7fR36k0lzH u+DTscMi7cAX7fxMaxqTdw9PdZoncJ/eH5Y4dwnD876V+FMIMckPpIU6UHKOlUY1XmNp NIYpkXqxCBnjYdyP6dSom6VJA3JlM0ZrDLHHO6aY5UJ23d8BtWwqxCCHLnmPLD8ejw8S rKLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3pCfiWIXhMMhZN45mfQ5eTQ8VmGehL2+S1OfjUOFgf4=; b=KT/XxhQ/UxYjBTeVoQu9bf1oxwaA0qWjMBD6UWq7xRp8xo2ZQqDb6x0qVYGBNBLux3 ymajTO/Q2J2gCxY0fdzwV/iYI41iPJUpzh9wXAiWYVwfhxMu8Qz6MqVcsdGwFlevdZWn 8QOFLVXG2WsYD/fcMREEjSqAp4deyLm8a4D3q01V1sxsD+zxdypKwSlj+q+su2CiHwiU tkRMF5ErfidMT0DGbCyLEHSm7CBRu+kFx2bZtBv8LvsucTsqfwJA00KhFAqUpIWOOKQI VfVYy+FIDkkDRVOFjKctSEpJUq7rhMrb+tyGe48qfMra0oqXGRf7XhAjSboQ7nDvT2uy WaRw== X-Gm-Message-State: AA6/9Rm7cNXFY9I3Pyf5e0U8VkcNLkPP15lLz7vzzXHluz1k+Go6rDSrcvKSu63tNwc7+qGhZrQeJUI9bzcOqg== X-Received: by 10.55.188.193 with SMTP id m184mr5752296qkf.129.1474607838520; Thu, 22 Sep 2016 22:17:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.38.56 with HTTP; Thu, 22 Sep 2016 22:17:18 -0700 (PDT) In-Reply-To: References: <32C28142-350A-4242-A9C6-9E32D9966601@gmail.com> <8CC1E61E-0A8F-41D3-B30D-5B037BAEDEB1@gmail.com> From: Padma Pillay-Esnault Date: Thu, 22 Sep 2016 22:17:18 -0700 Message-ID: To: "Black, David" Content-Type: multipart/alternative; boundary=94eb2c0430a665f7d2053d25e4a3 Archived-At: Cc: "beta@lispers.net" , "ideas@ietf.org" , LISP mailing list list , NVO3 , LISPmob , "5gangip@ietf.org" <5gangip@ietf.org>, "lisp-beta@external.cisco.com" Subject: Re: [lisp] [nvo3] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 23 Sep 2016 05:17:21 -0000 --94eb2c0430a665f7d2053d25e4a3 Content-Type: text/plain; charset=UTF-8 Hi David Thanks for your comments. I take note of your comment (2) and pointer. Here is a pointer to the draft https://www.ietf.org/internet-drafts/draft-padma-ideas-probl em-statement-00.txt Padma On Wed, Sep 21, 2016 at 4:19 PM, Black, David wrote: > Hi Dino, > > Here are a couple of areas to consider: > > (1) I don't see any confidentiality requirements. For this and other > NVO3 security > requirements, please see the security considerations section of RFC 7365 > (NVO3 > framework) and draft-ietf-nvo3-arch. The latter contains a new paragraph > on > sensitivity of performance and other monitoring data gathered by the > control > plane - that paragraph was added at the behest of both Security ADs: > > https://tools.ietf.org/html/rfc7365#section-5 > https://tools.ietf.org/html/draft-ietf-nvo3-arch-08#section-16 > > (2) This item: > > > > 7. Message rate-limiting and other heuristics must be part of the > > > foundational support of the mapping system to protect the system > > > from invalid overloaded conditions. > > suggests that congestion control is also a consideration to protect the > network. > If an existing congestion-controlled transport protocol (e.g., TCP, SCTP, > DCCP) is > not used for control traffic, then see draft-ietf-tsvwg-rfc5405bis for > discussion > of applicable requirements: > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ > > Thanks, --David > > --94eb2c0430a665f7d2053d25e4a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi David

Thanks for your comments.
I take note of your comment (2) and pointer.

=
Here is a pointer to the draft

Padma



On Wed, Sep 21, 2016 at 4:19 PM, Black, David <David.B= lack@dell.com> wrote:
Hi Dino,

Here are a couple of areas to consider:

(1) I don't see any confidentiality requirements.=C2=A0 =C2=A0For this = and other NVO3 security
requirements, please see the security considerations section of RFC 7365 (N= VO3
framework) and draft-ietf-nvo3-arch.=C2=A0 The latter contains a new paragr= aph on
sensitivity of performance and=C2=A0 other monitoring data gathered by the = control
plane - that paragraph was added at the behest of both Security ADs:

https://tools.ietf.org/html/rfc7365#section-5<= br> https://tools.ietf.org/html/draft= -ietf-nvo3-arch-08#section-16

(2) This item:

> >=C2=A0 =C2=A07.=C2=A0 Message rate-limiting and other heuristics m= ust be part of the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0foundational support of the mapping sys= tem to protect the system
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0from invalid overloaded conditions.

suggests that congestion control is also a consideration to protect = the network.
If an existing congestion-controlled transport protocol (e.g., TCP, SCTP, D= CCP) is
not used for control traffic, then see draft-ietf-tsvwg-rfc5405bis for disc= ussion
of applicable requirements:

https://datatracker.ietf.org/doc/d= raft-ietf-tsvwg-rfc5405bis/

Thanks, --David

--94eb2c0430a665f7d2053d25e4a3-- From nobody Fri Sep 23 15:44:03 2016 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 DB38612B892; Fri, 23 Sep 2016 15:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ior9jqhIxic; Fri, 23 Sep 2016 15:43:40 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::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 5E23A12B7D8; Fri, 23 Sep 2016 15:43:40 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id s13so11760641pfd.2; Fri, 23 Sep 2016 15:43:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zftCp6Uiazu3/OFDhNpRLcYA0dsmfWljpzlgE/QfJD4=; b=rs6dwK5RW2ONlGk/sPQXtsiWEIWBBoZMsES4z5LqIMImBqrzqnWXG1t1WAV0xeAOm/ CKpYzF88eFw9UK5wbApTgh4vYgUCgX9HkFy8uIRtcR+EoGM0Dk6HZ4vkAl8rMdDPF7J/ bRZA14yMTF+eb+w2hrKuEdw9v1QukKJCxT6HwlNrjjF5GZCDLVthuH4yLZuAUn3QBbpQ 5LrJ0qjqW8xZc5jXUXwNLZq+mOR4vvvdnzjfcBeJnftONvQvejk7tp4Px8resZOdHJXn GUPrvOlCZ7o3llThhGzOrYTE/4b3nqPyMH/n0pcK7IyiGa97d8lw++CvlihV9NxCQ1Os b4hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zftCp6Uiazu3/OFDhNpRLcYA0dsmfWljpzlgE/QfJD4=; b=NPN+DEU32wCdfCFx7QcAFbIDydwzdoYrjWlaOjgpKZShs1kouBCOhFBO0QZEVRNN7i NCDxrhiVBLyZQ4fnt07kDY5nO6fkXWOeOptpSzrd44qIozyKtuHZeRvBjOjHxLf2ERpe eT0pD0MoUdzDkQEIGH6A8/Nb546roGD88gDvaCPUjDEeAWe/zgLM2gJJp4r9v9jujsY4 kzahW/iyfAhq3pLC4ZXaANo6wjBrV71y0TjmYZRUQTog4FgiKEJO8SI3LaAA3LfBye8w 1PQhRlfQaVPPHb6tloJdOxvtEnrOy+qFJP1JYUMEWJDWae4KbpGTrNCdhgdMMSOXy92S tIWA== X-Gm-Message-State: AE9vXwPiiTE4FglR2WQUweMwERAT6F1W807txytIvK8Nt0NB6hTYUOgAVrEQFK8oW0x2mg== X-Received: by 10.98.196.206 with SMTP id h75mr16554543pfk.156.1474670619940; Fri, 23 Sep 2016 15:43:39 -0700 (PDT) Received: from ?IPv6:2601:646:8d01:89f0:9852:e79f:5f4e:878c? ([2601:646:8d01:89f0:9852:e79f:5f4e:878c]) by smtp.gmail.com with ESMTPSA id tn5sm13866312pac.6.2016.09.23.15.43.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 23 Sep 2016 15:43:39 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: Date: Fri, 23 Sep 2016 15:43:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <878F281A-F391-4BED-988D-7CF6A7F6AA91@gmail.com> References: <32C28142-350A-4242-A9C6-9E32D9966601@gmail.com> <8CC1E61E-0A8F-41D3-B30D-5B037BAEDEB1@gmail.com> To: "Black, David" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "beta@lispers.net" , "ideas@ietf.org" , LISP mailing list list , NVO3 , LISPmob , "5gangip@ietf.org" <5gangip@ietf.org>, "lisp-beta@external.cisco.com" Subject: Re: [lisp] [nvo3] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 23 Sep 2016 22:43:44 -0000 > Hi Dino, Thanks so much David for the reply. The pointers you provided will be = useful. > Here are a couple of areas to consider: >=20 > (1) I don't see any confidentiality requirements. For this and other = NVO3 security > requirements, please see the security considerations section of RFC = 7365 (NVO3 I can see this for east-west traffic patterns. Assuming the mapping = database would be managed internal to a data center where there would = not be regisrations from any VTEPs/xTRs outside of the data center. But what if there was an overlay among CPE routers, access-points, and = top-of-rack data center switches. Then the registration and requesting = of mappings may travel outside of a secured physical area. Any reaction = to this? > framework) and draft-ietf-nvo3-arch. The latter contains a new = paragraph on > sensitivity of performance and other monitoring data gathered by the = control > plane - that paragraph was added at the behest of both Security ADs: >=20 > https://tools.ietf.org/html/rfc7365#section-5 For multi-tenancy, there can be an instance of a mapping system that = runs for each tennant or a single mapping system run by the = multi-tennant provider. In any case, encrypting Map-Registers and = Map-Requests COULD be desirable. Not sure. Again, this requirement we = have stated would be for private mapping systems and not a global = mapping system that would be a public service much like DNS is. > https://tools.ietf.org/html/draft-ietf-nvo3-arch-08#section-16 Since the draft-padma-ideas-problem-statement-00.txt is focusing on = control-plane, there would be no mention of data-plane security but = there are mechanisms for doing this. For the control-plane reference in section 16, there is plans to have = authentication and it could also be done with AE (Authenticated = Encryption) mechanisms. >=20 > (2) This item: >=20 >>> 7. Message rate-limiting and other heuristics must be part of the >>> foundational support of the mapping system to protect the = system >>> from invalid overloaded conditions. >=20 > suggests that congestion control is also a consideration to protect = the network. Yes. > If an existing congestion-controlled transport protocol (e.g., TCP, = SCTP, DCCP) is > not used for control traffic, then see draft-ietf-tsvwg-rfc5405bis for = discussion > of applicable requirements: We were thinking not just high-rate due to speed mismatches but more = importantly DoS attacks from rogue sources. Thanks again, Dino > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ >=20 > Thanks, --David >=20 >> -----Original Message----- >> From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Dino Farinacci >> Sent: Wednesday, September 21, 2016 6:51 PM >> To: Dino Farinacci >> Cc: beta@lispers.net; ideas@ietf.org; LISP mailing list list; NVO3; = LISPmob; >> 5gangip@ietf.org; lisp-beta@external.cisco.com >> Subject: Re: [nvo3] Mapping System Requirements and = draft-padma-ideas- >> problem-statement-00.txt >>=20 >> Reposting since the cisco mailing lists are no longer in service. = Please respond to >> this email. >>=20 >> Thanks and sorry for inconvenience, >> Dino >>=20 >>> On Sep 21, 2016, at 2:12 PM, Dino Farinacci = wrote: >>>=20 >>> Hello folks. In draft-padma-ideas-problem-statement-00.txt, we have = a section >> on mapping system requirements for map-n-encap and translation based = loc/id >> split protocols. Rather than having you go into the document in = detail (we wish >> you would and comment though), I will provide the short list below to = attempt a >> discussion on requirements. >>>=20 >>> I have copied the possible WGs that may want to use the mapping = system >> technology. And I have also copied the LISP working group who can = shed >> expertise on the subject as well as some beta lists that have some = operational >> experiences with mapping database deployment and management. >>>=20 >>> The requirements below have a security and robustness twist to it = but I think >> that is the best place to start and to consider security =E2=80=9Cup = front=E2=80=9D. >>>=20 >>> Thanks in advance, >>> Dino >>>=20 >>> ---- >>>=20 >>> 6.4. Mapping System Security >>>=20 >>> The secure mapping system must have the following requirements: >>>=20 >>> 1. The components of the mapping system need to be robust against >>> direct and indirect attacks. If any component is attacked, the >>> rest of the system should act with integrity and scale and only >>> the information associated with the compromised component is = made >>> unavailable. >>>=20 >>> 2. The addition and removal of components of the mapping system = must >>> be performed in a secure matter so as to not violate the >>> integrity and operation of the system and service it provides. >>>=20 >>> 3. The information returned by components of the mapping system >>> needs to be authenticated as to detect spoofing from >>> masqueraders. >>>=20 >>> 4. Information registered (by publishers) to the mapping system = must >>> be authenticated so the registering entity or the information = is >>> not spoofed. >>>=20 >>> 5. The mapping system must allow request access (for subscribers) = to >>> be open and public. However, it is optional to provide >>> confidentiality and authentication of the requesters and the >>> information they are requesting. >>>=20 >>> 6. Any information provided by components of the mapping system = must >>> be cryptographically signed by the provider and verified by the >>> consumer. >>>=20 >>> 7. Message rate-limiting and other heuristics must be part of the >>> foundational support of the mapping system to protect the = system >>> from invalid overloaded conditions. >>>=20 >>> 8. The mapping system should support some form of provisioned >>> policy. Either internal to the system or via mechanisms for >>> users of the system to describe policy rules. Access control >>> should not use traditional granular-based access lists since = they >>> do not scale and are hard to manage. By the use of token- or >>> key- based authentication methods as well as deploying multiple >>> instances of the mapping system will allow acceptable policy >>> profiles. Machine learning techniques could automate these >>> mechanisms. >>=20 >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 From nobody Tue Sep 27 16:06:15 2016 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 870A112B020; Tue, 27 Sep 2016 16:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exQQzD-dqZXJ; Tue, 27 Sep 2016 16:06:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB4A012B4F9; Tue, 27 Sep 2016 16:06:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CXA32643; Tue, 27 Sep 2016 23:06:05 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.218.25.36) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 28 Sep 2016 00:06:04 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.53]) by SJCEML703-CHM.china.huawei.com ([169.254.5.29]) with mapi id 14.03.0235.001; Tue, 27 Sep 2016 16:06:00 -0700 From: Lin Han To: "'Dino Farinacci'" , "ideas@ietf.org" Thread-Topic: [Ideas] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt Thread-Index: AQHSFEz/FaqdWIqsa0+j3Mkt86zi8qCN9f8Q Date: Tue, 27 Sep 2016 23:06:00 +0000 Message-ID: <1D30AF33624CDD4A99E8C395069A2A162A600B3E@SJCEML701-CHM.china.huawei.com> References: <32C28142-350A-4242-A9C6-9E32D9966601@gmail.com> In-Reply-To: <32C28142-350A-4242-A9C6-9E32D9966601@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.64.181] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.57EAFB5E.0040, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.53, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8135e4efe298bfe4a17529450d290015 Archived-At: Cc: "beta@lispers.net" , LISP mailing list list , NVO3 , "lisp-alpha@external.cisco.com" , LISPmob , "5gangip@ietf.org" <5gangip@ietf.org>, "lisp-ops@external.cisco.com" Subject: Re: [lisp] [Ideas] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 27 Sep 2016 23:06:13 -0000 SGksIERpbm8NCg0KU2hvdWxkIHdlIGNvbnNpZGVyIHRoZSBzZWN1cml0eSBvZiBzb3ZlcmVpZ250 eSBmb3IgdGhlIG1hcHBpbmcgc3lzdGVtPyBUaGlzIHF1ZXN0aW9uIGlzIHByb2JhYmx5IHRvbyBl YXJseS4gDQoNCkFzIHlvdSBrbm93LCBETlMgdHJlZSBhcmNoaXRlY3R1cmUgaW50cm9kdWNlZCBh IGxvdCBkZWJhdGUgaGlzdG9yaWNhbGx5IGZvciB0aGUgb3duZXJzaGlwIGFuZCBvcGVyYXRpb24g b2Ygcm9vdCBETlMuIER1ZSB0byBwcmVzc3VyZSBmcm9tIGluZHVzdHJ5IGFuZCBvdGhlciBjb3Vu dHJpZXMsIFVTQSBnb3Zlcm5tZW50IHBsYW5zIHRvIGhhbmQgb3ZlciB0aGUgb3BlcmF0aW9uIG9m IHJvb3QgRE5TIHRvIElBTkEgbmV4dCBtb250aCBldmVuIHRoZXJlIGlzIGEgbG90IG9wcG9zaW5n IHZvaWNlIGZyb20gY29uZ3Jlc3MuIEl0IGNvdWxkIGNoYW5nZSBiYWNrIGFnYWluLg0KDQpPbmUg c2lkZSBpcyB0aGF0IHRoZSBuYXRpb25hbCBzZWN1cml0eSBvZiBVUyBwcmVmZXIgdGhlIGdvdmVy bm1lbnQgb3BlcmF0ZXMgdGhlIHJvb3QgRE5TLCBhbm90aGVyIHNpZGUgaXMgdGhhdCBvdGhlciBj b3VudHJpZXMgZG9u4oCZdCBsaWtlIFVTIHRvIGNvbXBsZXRlbHkgY29udHJvbCB0aGUgRE5TLg0K DQpUaGlzIGlzIHJlbGF0ZWQgdG8gYm90aCB0ZWNobm9sb2d5IGFuZCBwb2xpdGljcy4gV2l0aG91 dCB0aGUgc3VwcG9ydCBvZiBvdGhlciBjb3VudHJpZXMsIG1hcHBpbmcgc2VydmVyIGRlcGxveW1l bnQgZ2xvYmFsbHkgd2lsbCBiZSBpbiBxdWVzdGlvbi4NCg0KDQpSZWdhcmRzDQoNCkxpbg0KDQoN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IElkZWFzIFttYWlsdG86aWRlYXMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERpbm8gRmFyaW5hY2NpDQpTZW50OiBXZWRu ZXNkYXksIFNlcHRlbWJlciAyMSwgMjAxNiAyOjEzIFBNDQpUbzogaWRlYXNAaWV0Zi5vcmcNCkNj OiBiZXRhQGxpc3BlcnMubmV0OyBMSVNQIG1haWxpbmcgbGlzdCBsaXN0OyBOVk8zOyBsaXNwLWFs cGhhQGV4dGVybmFsLmNpc2NvLmNvbTsgTElTUG1vYjsgNWdhbmdpcEBpZXRmLm9yZzsgbGlzcC1v cHNAZXh0ZXJuYWwuY2lzY28uY29tDQpTdWJqZWN0OiBbSWRlYXNdIE1hcHBpbmcgU3lzdGVtIFJl cXVpcmVtZW50cyBhbmQgZHJhZnQtcGFkbWEtaWRlYXMtcHJvYmxlbS1zdGF0ZW1lbnQtMDAudHh0 DQoNCkhlbGxvIGZvbGtzLiBJbiBkcmFmdC1wYWRtYS1pZGVhcy1wcm9ibGVtLXN0YXRlbWVudC0w MC50eHQsIHdlIGhhdmUgYSBzZWN0aW9uIG9uIG1hcHBpbmcgc3lzdGVtIHJlcXVpcmVtZW50cyBm b3IgbWFwLW4tZW5jYXAgYW5kIHRyYW5zbGF0aW9uIGJhc2VkIGxvYy9pZCBzcGxpdCBwcm90b2Nv bHMuIFJhdGhlciB0aGFuIGhhdmluZyB5b3UgZ28gaW50byB0aGUgZG9jdW1lbnQgaW4gZGV0YWls ICh3ZSB3aXNoIHlvdSB3b3VsZCBhbmQgY29tbWVudCB0aG91Z2gpLCBJIHdpbGwgcHJvdmlkZSB0 aGUgc2hvcnQgbGlzdCBiZWxvdyB0byBhdHRlbXB0IGEgZGlzY3Vzc2lvbiBvbiByZXF1aXJlbWVu dHMuIA0KDQpJIGhhdmUgY29waWVkIHRoZSBwb3NzaWJsZSBXR3MgdGhhdCBtYXkgd2FudCB0byB1 c2UgdGhlIG1hcHBpbmcgc3lzdGVtIHRlY2hub2xvZ3kuIEFuZCBJIGhhdmUgYWxzbyBjb3BpZWQg dGhlIExJU1Agd29ya2luZyBncm91cCB3aG8gY2FuIHNoZWQgZXhwZXJ0aXNlIG9uIHRoZSBzdWJq ZWN0IGFzIHdlbGwgYXMgc29tZSBiZXRhIGxpc3RzIHRoYXQgaGF2ZSBzb21lIG9wZXJhdGlvbmFs IGV4cGVyaWVuY2VzIHdpdGggbWFwcGluZyBkYXRhYmFzZSBkZXBsb3ltZW50IGFuZCBtYW5hZ2Vt ZW50Lg0KDQpUaGUgcmVxdWlyZW1lbnRzIGJlbG93IGhhdmUgYSBzZWN1cml0eSBhbmQgcm9idXN0 bmVzcyB0d2lzdCB0byBpdCBidXQgSSB0aGluayB0aGF0IGlzIHRoZSBiZXN0IHBsYWNlIHRvIHN0 YXJ0IGFuZCB0byBjb25zaWRlciBzZWN1cml0eSDigJx1cCBmcm9udOKAnS4NCg0KVGhhbmtzIGlu IGFkdmFuY2UsDQpEaW5vDQoNCi0tLS0NCg0KNi40LiAgTWFwcGluZyBTeXN0ZW0gU2VjdXJpdHkN Cg0KICAgVGhlIHNlY3VyZSBtYXBwaW5nIHN5c3RlbSBtdXN0IGhhdmUgdGhlIGZvbGxvd2luZyBy ZXF1aXJlbWVudHM6DQoNCiAgIDEuICBUaGUgY29tcG9uZW50cyBvZiB0aGUgbWFwcGluZyBzeXN0 ZW0gbmVlZCB0byBiZSByb2J1c3QgYWdhaW5zdA0KICAgICAgIGRpcmVjdCBhbmQgaW5kaXJlY3Qg YXR0YWNrcy4gIElmIGFueSBjb21wb25lbnQgaXMgYXR0YWNrZWQsIHRoZQ0KICAgICAgIHJlc3Qg b2YgdGhlIHN5c3RlbSBzaG91bGQgYWN0IHdpdGggaW50ZWdyaXR5IGFuZCBzY2FsZSBhbmQgb25s eQ0KICAgICAgIHRoZSBpbmZvcm1hdGlvbiBhc3NvY2lhdGVkIHdpdGggdGhlIGNvbXByb21pc2Vk IGNvbXBvbmVudCBpcyBtYWRlDQogICAgICAgdW5hdmFpbGFibGUuDQoNCiAgIDIuICBUaGUgYWRk aXRpb24gYW5kIHJlbW92YWwgb2YgY29tcG9uZW50cyBvZiB0aGUgbWFwcGluZyBzeXN0ZW0gbXVz dA0KICAgICAgIGJlIHBlcmZvcm1lZCBpbiBhIHNlY3VyZSBtYXR0ZXIgc28gYXMgdG8gbm90IHZp b2xhdGUgdGhlDQogICAgICAgaW50ZWdyaXR5IGFuZCBvcGVyYXRpb24gb2YgdGhlIHN5c3RlbSBh bmQgc2VydmljZSBpdCBwcm92aWRlcy4NCg0KICAgMy4gIFRoZSBpbmZvcm1hdGlvbiByZXR1cm5l ZCBieSBjb21wb25lbnRzIG9mIHRoZSBtYXBwaW5nIHN5c3RlbQ0KICAgICAgIG5lZWRzIHRvIGJl IGF1dGhlbnRpY2F0ZWQgYXMgdG8gZGV0ZWN0IHNwb29maW5nIGZyb20NCiAgICAgICBtYXNxdWVy YWRlcnMuDQoNCiAgIDQuICBJbmZvcm1hdGlvbiByZWdpc3RlcmVkIChieSBwdWJsaXNoZXJzKSB0 byB0aGUgbWFwcGluZyBzeXN0ZW0gbXVzdA0KICAgICAgIGJlIGF1dGhlbnRpY2F0ZWQgc28gdGhl IHJlZ2lzdGVyaW5nIGVudGl0eSBvciB0aGUgaW5mb3JtYXRpb24gaXMNCiAgICAgICBub3Qgc3Bv b2ZlZC4NCg0KICAgNS4gIFRoZSBtYXBwaW5nIHN5c3RlbSBtdXN0IGFsbG93IHJlcXVlc3QgYWNj ZXNzIChmb3Igc3Vic2NyaWJlcnMpIHRvDQogICAgICAgYmUgb3BlbiBhbmQgcHVibGljLiAgSG93 ZXZlciwgaXQgaXMgb3B0aW9uYWwgdG8gcHJvdmlkZQ0KICAgICAgIGNvbmZpZGVudGlhbGl0eSBh bmQgYXV0aGVudGljYXRpb24gb2YgdGhlIHJlcXVlc3RlcnMgYW5kIHRoZQ0KICAgICAgIGluZm9y bWF0aW9uIHRoZXkgYXJlIHJlcXVlc3RpbmcuDQoNCiAgIDYuICBBbnkgaW5mb3JtYXRpb24gcHJv dmlkZWQgYnkgY29tcG9uZW50cyBvZiB0aGUgbWFwcGluZyBzeXN0ZW0gbXVzdA0KICAgICAgIGJl IGNyeXB0b2dyYXBoaWNhbGx5IHNpZ25lZCBieSB0aGUgcHJvdmlkZXIgYW5kIHZlcmlmaWVkIGJ5 IHRoZQ0KICAgICAgIGNvbnN1bWVyLg0KDQogICA3LiAgTWVzc2FnZSByYXRlLWxpbWl0aW5nIGFu ZCBvdGhlciBoZXVyaXN0aWNzIG11c3QgYmUgcGFydCBvZiB0aGUNCiAgICAgICBmb3VuZGF0aW9u YWwgc3VwcG9ydCBvZiB0aGUgbWFwcGluZyBzeXN0ZW0gdG8gcHJvdGVjdCB0aGUgc3lzdGVtDQog ICAgICAgZnJvbSBpbnZhbGlkIG92ZXJsb2FkZWQgY29uZGl0aW9ucy4NCg0KICAgOC4gIFRoZSBt YXBwaW5nIHN5c3RlbSBzaG91bGQgc3VwcG9ydCBzb21lIGZvcm0gb2YgcHJvdmlzaW9uZWQNCiAg ICAgICBwb2xpY3kuICBFaXRoZXIgaW50ZXJuYWwgdG8gdGhlIHN5c3RlbSBvciB2aWEgbWVjaGFu aXNtcyBmb3INCiAgICAgICB1c2VycyBvZiB0aGUgc3lzdGVtIHRvIGRlc2NyaWJlIHBvbGljeSBy dWxlcy4gIEFjY2VzcyBjb250cm9sDQogICAgICAgc2hvdWxkIG5vdCB1c2UgdHJhZGl0aW9uYWwg Z3JhbnVsYXItYmFzZWQgYWNjZXNzIGxpc3RzIHNpbmNlIHRoZXkNCiAgICAgICBkbyBub3Qgc2Nh bGUgYW5kIGFyZSBoYXJkIHRvIG1hbmFnZS4gIEJ5IHRoZSB1c2Ugb2YgdG9rZW4tIG9yDQogICAg ICAga2V5LSBiYXNlZCBhdXRoZW50aWNhdGlvbiBtZXRob2RzIGFzIHdlbGwgYXMgZGVwbG95aW5n IG11bHRpcGxlDQogICAgICAgaW5zdGFuY2VzIG9mIHRoZSBtYXBwaW5nIHN5c3RlbSB3aWxsIGFs bG93IGFjY2VwdGFibGUgcG9saWN5DQogICAgICAgcHJvZmlsZXMuICBNYWNoaW5lIGxlYXJuaW5n IHRlY2huaXF1ZXMgY291bGQgYXV0b21hdGUgdGhlc2UNCiAgICAgICBtZWNoYW5pc21zLg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkZWFzIG1haWxp bmcgbGlzdA0KSWRlYXNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaWRlYXMNCg== From nobody Tue Sep 27 16:13:46 2016 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 7408312B01C; Tue, 27 Sep 2016 16:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOcFdi_gjhtT; Tue, 27 Sep 2016 16:13:41 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4631C12B4B8; Tue, 27 Sep 2016 16:13:40 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id w84so203746583wmg.1; Tue, 27 Sep 2016 16:13:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hBSFtnUIhGUP9WTkjlpdJkyBLr9e2J+9GL28hSfp5rE=; b=HSmbR6+4guyvoZdW2KB9E///b0Gd8aTVgZ0ar3DKk4Dg7y3WjioRjnrBIkb84Ckuh8 sXvL9CQsCAxbfiFVopzFuAjbtt1drH8IdtadDL0FQBs9cJES4Y3mgN+Vq8n++rVrtYtc wJLqRRxqZuOlAEPjRoSi3jOJ8hVD+7PKUn0m4gggWbTETA5Fb7tibmYmXqtFfx/pn0/q 6OsdnOEDcslxiNLkJt7VaJ5gjRVQ5JlNIhLF0FUFtHKi4DaJ4Am32sfbovaVqbcIJyKH +79vqKHv4I1SjSPxQkbPcY6mc00lWsOq40ZJRol1atmjJSh1Wl88yNYCXBlZ2yQT5HXn HMTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=hBSFtnUIhGUP9WTkjlpdJkyBLr9e2J+9GL28hSfp5rE=; b=TNM31pLCTyHUmLjcEA34Bl89WjrL8lQxiun7j2BigYz9N7nU7yZpAy4OyZvcnmkIQb S8cSfwrJmBj5JEotzakgylT9BmiY3Md4d7WJg4AOD+yymb3D6hsbL/CKIsZvujgvpZEh WJDCDYtxkbur0x02n2eH4po1rTNkyoA6cUs7Cn8jH+GLQomST54Nd1E4r+X6ap5oteaH V/Q7PPqc0nOfLWBMT/4C3fPkvEZ6eI06bLw4sOb77KLOFV4MG/OcKJT5qRWaAaO/+Tgp zL6/1zBtZl+4z9BCZF9E4Nd6xlyLUfoHeK/gM/QSjreBhn6zQTTfwjmsokDEmEAtRR0R /7sg== X-Gm-Message-State: AA6/9Rkj4EYBdV3QVGPyEaezpSFKHaYdv0VIXe5x6uH8ba1s6CLkjaqCxZEj7Xzpj09aqXlBE9u5hsWN5aSksA== X-Received: by 10.28.35.68 with SMTP id j65mr4814453wmj.61.1475018018739; Tue, 27 Sep 2016 16:13:38 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.80.153.44 with HTTP; Tue, 27 Sep 2016 16:13:37 -0700 (PDT) In-Reply-To: <1D30AF33624CDD4A99E8C395069A2A162A600B3E@SJCEML701-CHM.china.huawei.com> References: <32C28142-350A-4242-A9C6-9E32D9966601@gmail.com> <1D30AF33624CDD4A99E8C395069A2A162A600B3E@SJCEML701-CHM.china.huawei.com> From: Robert Raszuk Date: Wed, 28 Sep 2016 01:13:37 +0200 X-Google-Sender-Auth: tJ4zCPyuB-cB0v7XVEaFOi-TvGc Message-ID: To: Lin Han Content-Type: multipart/alternative; boundary=001a113e9a340b5db2053d856545 Archived-At: Cc: "beta@lispers.net" , "ideas@ietf.org" , LISP mailing list list , NVO3 , "lisp-alpha@external.cisco.com" , LISPmob , "5gangip@ietf.org" <5gangip@ietf.org>, "lisp-ops@external.cisco.com" Subject: Re: [lisp] [Ideas] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 27 Sep 2016 23:13:44 -0000 --001a113e9a340b5db2053d856545 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Lin, You bring interesting news to the table with your insight ... IMHO any global mapping plane should be fully distributed with no root under any specific gov. Look at BGP protocol ... it does not require a root .. yet it allows to dynamically interconnect quite a few of global databases. Of course from 30 years back we now know much more modern ways to share information then via distance vector protocol. But none of those should be based on any politics controlling "the root" of it no matter which side it is on. /* Side comment .... */ When I spoke to some of the 5G folks this was clearly the direction and in fact Dino's LISP was one of the strongest candidates there as control plane. Best, Robert. On Wed, Sep 28, 2016 at 1:06 AM, Lin Han wrote: > Hi, Dino > > Should we consider the security of sovereignty for the mapping system? > This question is probably too early. > > As you know, DNS tree architecture introduced a lot debate historically > for the ownership and operation of root DNS. Due to pressure from industr= y > and other countries, USA government plans to hand over the operation of > root DNS to IANA next month even there is a lot opposing voice from > congress. It could change back again. > > One side is that the national security of US prefer the government > operates the root DNS, another side is that other countries don=E2=80=99t= like US > to completely control the DNS. > > This is related to both technology and politics. Without the support of > other countries, mapping server deployment globally will be in question. > > > Regards > > Lin > > > > -----Original Message----- > From: Ideas [mailto:ideas-bounces@ietf.org] On Behalf Of Dino Farinacci > Sent: Wednesday, September 21, 2016 2:13 PM > To: ideas@ietf.org > Cc: beta@lispers.net; LISP mailing list list; NVO3; > lisp-alpha@external.cisco.com; LISPmob; 5gangip@ietf.org; > lisp-ops@external.cisco.com > Subject: [Ideas] Mapping System Requirements and draft-padma-ideas-proble= m- > statement-00.txt > > Hello folks. In draft-padma-ideas-problem-statement-00.txt, we have a > section on mapping system requirements for map-n-encap and translation > based loc/id split protocols. Rather than having you go into the document > in detail (we wish you would and comment though), I will provide the shor= t > list below to attempt a discussion on requirements. > > I have copied the possible WGs that may want to use the mapping system > technology. And I have also copied the LISP working group who can shed > expertise on the subject as well as some beta lists that have some > operational experiences with mapping database deployment and management. > > The requirements below have a security and robustness twist to it but I > think that is the best place to start and to consider security =E2=80=9Cu= p front=E2=80=9D. > > Thanks in advance, > Dino > > ---- > > 6.4. Mapping System Security > > The secure mapping system must have the following requirements: > > 1. The components of the mapping system need to be robust against > direct and indirect attacks. If any component is attacked, the > rest of the system should act with integrity and scale and only > the information associated with the compromised component is made > unavailable. > > 2. The addition and removal of components of the mapping system must > be performed in a secure matter so as to not violate the > integrity and operation of the system and service it provides. > > 3. The information returned by components of the mapping system > needs to be authenticated as to detect spoofing from > masqueraders. > > 4. Information registered (by publishers) to the mapping system must > be authenticated so the registering entity or the information is > not spoofed. > > 5. The mapping system must allow request access (for subscribers) to > be open and public. However, it is optional to provide > confidentiality and authentication of the requesters and the > information they are requesting. > > 6. Any information provided by components of the mapping system must > be cryptographically signed by the provider and verified by the > consumer. > > 7. Message rate-limiting and other heuristics must be part of the > foundational support of the mapping system to protect the system > from invalid overloaded conditions. > > 8. The mapping system should support some form of provisioned > policy. Either internal to the system or via mechanisms for > users of the system to describe policy rules. Access control > should not use traditional granular-based access lists since they > do not scale and are hard to manage. By the use of token- or > key- based authentication methods as well as deploying multiple > instances of the mapping system will allow acceptable policy > profiles. Machine learning techniques could automate these > mechanisms. > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas > --001a113e9a340b5db2053d856545 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Lin,

<= /div>
You bring interesting news to the table with your i= nsight ...

IMHO any gl= obal mapping plane should be fully distributed with no root under any speci= fic gov.=C2=A0

Look at= BGP protocol ... it does not require a root .. yet it allows to dynamicall= y interconnect quite a few of global databases. Of course from 30 years bac= k we now know much more modern ways to share information then via distance = vector protocol. But none of those should be based on any politics controll= ing "the root" of it no matter which side it is on.=C2=A0

/* Side comment .... */
=

When I spoke to some of the= 5G folks this was clearly the direction and in fact Dino's LISP was on= e of the strongest candidates there as control plane.=C2=A0

Best,
Robert.=

On We= d, Sep 28, 2016 at 1:06 AM, Lin Han <Lin.Han@huawei.com> wr= ote:
Hi, Dino

Should we consider the security of sovereignty for the mapping system? This= question is probably too early.

As you know, DNS tree architecture introduced a lot debate historically for= the ownership and operation of root DNS. Due to pressure from industry and= other countries, USA government plans to hand over the operation of root D= NS to IANA next month even there is a lot opposing voice from congress. It = could change back again.

One side is that the national security of US prefer the government operates= the root DNS, another side is that other countries don=E2=80=99t like US t= o completely control the DNS.

This is related to both technology and politics. Without the support of oth= er countries, mapping server deployment globally will be in question.


Regards

Lin



-----Original Message-----
From: Ideas [mailto:ideas-bounces= @ietf.org] On Behalf Of Dino Farinacci
Sent: Wednesday, September 21, 2016 2:13 PM
To: ideas@ietf.org
Cc: beta@lispers.net; LISP mailing = list list; NVO3; lisp-alph= a@external.cisco.com; LISPmob; 5gan= gip@ietf.org; lisp-ops@e= xternal.cisco.com
Subject: [Ideas] Mapping System Requirements and draft-padma-ideas-problem-= statement-00.txt

Hello folks. In draft-padma-ideas-problem-statement-00.txt, we have a = section on mapping system requirements for map-n-encap and translation base= d loc/id split protocols. Rather than having you go into the document in de= tail (we wish you would and comment though), I will provide the short list = below to attempt a discussion on requirements.

I have copied the possible WGs that may want to use the mapping system tech= nology. And I have also copied the LISP working group who can shed expertis= e on the subject as well as some beta lists that have some operational expe= riences with mapping database deployment and management.

The requirements below have a security and robustness twist to it but I thi= nk that is the best place to start and to consider security =E2=80=9Cup fro= nt=E2=80=9D.

Thanks in advance,
Dino

----

6.4.=C2=A0 Mapping System Security

=C2=A0 =C2=A0The secure mapping system must have the following requirements= :

=C2=A0 =C2=A01.=C2=A0 The components of the mapping system need to be robus= t against
=C2=A0 =C2=A0 =C2=A0 =C2=A0direct and indirect attacks.=C2=A0 If any compon= ent is attacked, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0rest of the system should act with integrity and= scale and only
=C2=A0 =C2=A0 =C2=A0 =C2=A0the information associated with the compromised = component is made
=C2=A0 =C2=A0 =C2=A0 =C2=A0unavailable.

=C2=A0 =C2=A02.=C2=A0 The addition and removal of components of the mapping= system must
=C2=A0 =C2=A0 =C2=A0 =C2=A0be performed in a secure matter so as to not vio= late the
=C2=A0 =C2=A0 =C2=A0 =C2=A0integrity and operation of the system and servic= e it provides.

=C2=A0 =C2=A03.=C2=A0 The information returned by components of the mapping= system
=C2=A0 =C2=A0 =C2=A0 =C2=A0needs to be authenticated as to detect spoofing = from
=C2=A0 =C2=A0 =C2=A0 =C2=A0masqueraders.

=C2=A0 =C2=A04.=C2=A0 Information registered (by publishers) to the mapping= system must
=C2=A0 =C2=A0 =C2=A0 =C2=A0be authenticated so the registering entity or th= e information is
=C2=A0 =C2=A0 =C2=A0 =C2=A0not spoofed.

=C2=A0 =C2=A05.=C2=A0 The mapping system must allow request access (for sub= scribers) to
=C2=A0 =C2=A0 =C2=A0 =C2=A0be open and public.=C2=A0 However, it is optiona= l to provide
=C2=A0 =C2=A0 =C2=A0 =C2=A0confidentiality and authentication of the reques= ters and the
=C2=A0 =C2=A0 =C2=A0 =C2=A0information they are requesting.

=C2=A0 =C2=A06.=C2=A0 Any information provided by components of the mapping= system must
=C2=A0 =C2=A0 =C2=A0 =C2=A0be cryptographically signed by the provider and = verified by the
=C2=A0 =C2=A0 =C2=A0 =C2=A0consumer.

=C2=A0 =C2=A07.=C2=A0 Message rate-limiting and other heuristics must be pa= rt of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0foundational support of the mapping system to pr= otect the system
=C2=A0 =C2=A0 =C2=A0 =C2=A0from invalid overloaded conditions.

=C2=A0 =C2=A08.=C2=A0 The mapping system should support some form of provis= ioned
=C2=A0 =C2=A0 =C2=A0 =C2=A0policy.=C2=A0 Either internal to the system or v= ia mechanisms for
=C2=A0 =C2=A0 =C2=A0 =C2=A0users of the system to describe policy rules.=C2= =A0 Access control
=C2=A0 =C2=A0 =C2=A0 =C2=A0should not use traditional granular-based access= lists since they
=C2=A0 =C2=A0 =C2=A0 =C2=A0do not scale and are hard to manage.=C2=A0 By th= e use of token- or
=C2=A0 =C2=A0 =C2=A0 =C2=A0key- based authentication methods as well as dep= loying multiple
=C2=A0 =C2=A0 =C2=A0 =C2=A0instances of the mapping system will allow accep= table policy
=C2=A0 =C2=A0 =C2=A0 =C2=A0profiles.=C2=A0 Machine learning techniques coul= d automate these
=C2=A0 =C2=A0 =C2=A0 =C2=A0mechanisms.
_______________________________________________
Ideas mailing list
Ideas@ietf.org
https://www.ietf.org/mailman/listinfo/ideas

--001a113e9a340b5db2053d856545-- From nobody Tue Sep 27 18:30:21 2016 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 878F512B3A9; Tue, 27 Sep 2016 18:30:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147502621954.11800.14680609428119507023.idtracker@ietfa.amsl.com> Date: Tue, 27 Sep 2016 18:30:19 -0700 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-crypto-08.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 28 Sep 2016 01:30:19 -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 of the IETF. Title : LISP Data-Plane Confidentiality Authors : Dino Farinacci Brian Weis Filename : draft-ietf-lisp-crypto-08.txt Pages : 19 Date : 2016-09-27 Abstract: This document describes a mechanism for encrypting LISP encapsulated traffic. The design describes how key exchange is achieved using existing LISP control-plane mechanisms as well as how to secure the LISP data-plane from third-party surveillance attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-crypto/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lisp-crypto-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-crypto-08 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 Sep 27 19:59:48 2016 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 96FEB12B053; Tue, 27 Sep 2016 19:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onmDfOvoirff; Tue, 27 Sep 2016 19:59:36 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::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 CF2B512B054; Tue, 27 Sep 2016 19:59:36 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id 21so12209064pfy.0; Tue, 27 Sep 2016 19:59:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=b8Zbk1LCFBQK4WSeT1qeUukByWQZ7nEbJWc05JaW7Rs=; b=e5PBbxeweyBS+pKe+Up+mxgP0WRqi6F/x9Z6/seAMmmHvouUM/tzgIdzv4WTarFN4D UAjlLt7U0FGHV4WzyrnvSc5R26ReYi1zKLELq0TRxGtU0rtI3Vtepx+38LddHNkgV1X+ jqC5nei0wlefRDD+ZIdLkIa9nTKTd2IIcQOuU2YgTQrGsYoj4ffCxbzgK547nCNuK2dU c4AyKpK1srRv3ZVvZa2xVQ2P3bxe2WEIbbd34OPXGCqw1LM8snXWKu1GttRXlMIcty9+ siIoqfrnIrEPjM0zEb3BXLYAsy0qDlBIAudiIhE1WwFLPl8iJS2KXgG92wXRJln/+WV1 62SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=b8Zbk1LCFBQK4WSeT1qeUukByWQZ7nEbJWc05JaW7Rs=; b=THLo156yqwlt+0jc4HwO5O97HAazc1XZxmdW65GtgV4hhBe0zcgrQuNdcBRHXtuYU3 CMRddl7TNbSGmWsg05WyemeAdGfizJ3VJcU7BR8sNGcwQ1SV3Qa0bld5IJ9+H5m23R6S cKWs0ArLLFMQaA8M7xiUKEXT1rD1A5tcL6RD9i+uF4Ab7PpTmM/+FTFLNRvQa5Y4oxES 6nRR2yO738QekpNwoy4ftwZtMOp5r1jL/n3RICqSHRttEkEndYueQu0AMlDLzRudVhCQ KNQv7/CCThUCS+WOQLYMcp9KyYjkddcWESS5LCfX2J483S3HyaqTzwGeu2rrnCTQXart 8nSA== X-Gm-Message-State: AE9vXwMgEGGQ7pyX2OyoynKcH85jVZjCx14qmxj2rzfCWyNgRkvGNThHOXxCTAZZpr2H3Q== X-Received: by 10.98.85.198 with SMTP id j189mr52960356pfb.123.1475031576299; Tue, 27 Sep 2016 19:59:36 -0700 (PDT) Received: from dino-macbook.wp.comcast.net (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by smtp.gmail.com with ESMTPSA id c28sm7867415pfj.6.2016.09.27.19.59.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 27 Sep 2016 19:59:35 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: <1D30AF33624CDD4A99E8C395069A2A162A600B3E@SJCEML701-CHM.china.huawei.com> Date: Tue, 27 Sep 2016 19:59:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <32C28142-350A-4242-A9C6-9E32D9966601@gmail.com> <1D30AF33624CDD4A99E8C395069A2A162A600B3E@SJCEML701-CHM.china.huawei.com> To: Lin Han X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "beta@lispers.net" , "ideas@ietf.org" , LISP mailing list list , NVO3 , "lisp-alpha@external.cisco.com" , LISPmob , "5gangip@ietf.org" <5gangip@ietf.org>, "lisp-ops@external.cisco.com" Subject: Re: [lisp] [Ideas] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 28 Sep 2016 02:59:39 -0000 > Hi, Dino >=20 > Should we consider the security of sovereignty for the mapping system? = This question is probably too early.=20 Yes, you bring up a very real question that needs to be answered this = early. > As you know, DNS tree architecture introduced a lot debate = historically for the ownership and operation of root DNS. Due to = pressure from industry and other countries, USA government plans to hand = over the operation of root DNS to IANA next month even there is a lot = opposing voice from congress. It could change back again. Architecturally we need root nodes as a mechanism but they do not have = to be run by any one party or spread across government/continental = boundaries. Any root could be run independently and point to the same next level = children leading to map-servers. > One side is that the national security of US prefer the government = operates the root DNS, another side is that other countries don=E2=80=99t = like US to completely control the DNS. I see this hierarchy run by commercial companies that have monetary = incentive to run a production level service. So for example, I could use = a pair of roots from say a Verisign. Or a different pair of roots = offered by an AT&T, or a possible a third-party that calls themselves a = Mapping Service Provider (MSP). It is these roots at the top of the tree that need to connect to common = parts in the middle and to the leaf map-servers of the tree. > This is related to both technology and politics. Without the support = of other countries, mapping server deployment globally will be in = question. If registrations and requests are encrypted, then anyone could run the = roots and the what goes in and out of the mapping system stays private. = But there needs to be competition so the level of service stays at a = high-quality production level. Dino >=20 >=20 > Regards >=20 > Lin >=20 >=20 >=20 > -----Original Message----- > From: Ideas [mailto:ideas-bounces@ietf.org] On Behalf Of Dino = Farinacci > Sent: Wednesday, September 21, 2016 2:13 PM > To: ideas@ietf.org > Cc: beta@lispers.net; LISP mailing list list; NVO3; = lisp-alpha@external.cisco.com; LISPmob; 5gangip@ietf.org; = lisp-ops@external.cisco.com > Subject: [Ideas] Mapping System Requirements and = draft-padma-ideas-problem-statement-00.txt >=20 > Hello folks. In draft-padma-ideas-problem-statement-00.txt, we have a = section on mapping system requirements for map-n-encap and translation = based loc/id split protocols. Rather than having you go into the = document in detail (we wish you would and comment though), I will = provide the short list below to attempt a discussion on requirements.=20 >=20 > I have copied the possible WGs that may want to use the mapping system = technology. And I have also copied the LISP working group who can shed = expertise on the subject as well as some beta lists that have some = operational experiences with mapping database deployment and management. >=20 > The requirements below have a security and robustness twist to it but = I think that is the best place to start and to consider security =E2=80=9C= up front=E2=80=9D. >=20 > Thanks in advance, > Dino >=20 > ---- >=20 > 6.4. Mapping System Security >=20 > The secure mapping system must have the following requirements: >=20 > 1. The components of the mapping system need to be robust against > direct and indirect attacks. If any component is attacked, the > rest of the system should act with integrity and scale and only > the information associated with the compromised component is = made > unavailable. >=20 > 2. The addition and removal of components of the mapping system = must > be performed in a secure matter so as to not violate the > integrity and operation of the system and service it provides. >=20 > 3. The information returned by components of the mapping system > needs to be authenticated as to detect spoofing from > masqueraders. >=20 > 4. Information registered (by publishers) to the mapping system = must > be authenticated so the registering entity or the information is > not spoofed. >=20 > 5. The mapping system must allow request access (for subscribers) = to > be open and public. However, it is optional to provide > confidentiality and authentication of the requesters and the > information they are requesting. >=20 > 6. Any information provided by components of the mapping system = must > be cryptographically signed by the provider and verified by the > consumer. >=20 > 7. Message rate-limiting and other heuristics must be part of the > foundational support of the mapping system to protect the system > from invalid overloaded conditions. >=20 > 8. The mapping system should support some form of provisioned > policy. Either internal to the system or via mechanisms for > users of the system to describe policy rules. Access control > should not use traditional granular-based access lists since = they > do not scale and are hard to manage. By the use of token- or > key- based authentication methods as well as deploying multiple > instances of the mapping system will allow acceptable policy > profiles. Machine learning techniques could automate these > mechanisms. > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas From nobody Tue Sep 27 20:02:13 2016 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 D960412B05E; Tue, 27 Sep 2016 20:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewgZ2KpgTu2y; Tue, 27 Sep 2016 20:02:06 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58E6B12B053; Tue, 27 Sep 2016 20:02:06 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id 21so12231303pfy.0; Tue, 27 Sep 2016 20:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kYrngZfsNzFsGKRvVF05rILMFZbC0Wdkj9xwEZy3P5E=; b=Glr5J+5w/zzqb1YIwzrlMDCdPXzqZjP2g1dBRqgIy3KM0no3uS5HGim8J9ociAcGeP +FBRhlMw8/C7akYagfT+Nb8W3LJLToTzA62MLTB15RwG3w/2q0tAa4a61Cu7wKKqMIdt C8iW8PSZPiCAvVmSUA+q4YmvSQcndWJpBPTwkUEAFgtjCKT4Kwmp8aFsMnzONj0Gyaa8 rbMVSAsql9etZi5xsoMiepk7Dj+LhX2UpTdlKqBMiWQoskwY9LdFsfOPVmXsmIpfum3S ZfOCm5zociGw28BqHUnNnFojhqCq5AMv76y9DIVFTUFGfs5rUp2vuNJ2zLECx6SxGS0Z 2uSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kYrngZfsNzFsGKRvVF05rILMFZbC0Wdkj9xwEZy3P5E=; b=jldL9PP8uFE8UQSsWp1bsJU9v5I7wN09RizEkPDhG9CnPgjdRa85uG2W8kQ8gbnSu1 lwC0/daTQP/JHcFd9jUtDwrukuQCK2grtiCezDq+wZmiOmfCBB/TCp7c3GU9bl2zrk+6 yv9OxO5D6UnpU1JfRPtcV7F9w6EWMkVBX/nE7CMexvSQnYqEAfIB6dOwJ9G2KlmhTT3N gp/RUKk73VyDzpEXFPoYlD0WKeGXLTQbYqHj1dXYxgmbJVHmE85rZHM/kKWAxeFZQmv6 XGjuEVQ9mWtxCrF2iiG0qQLMCHm2V5fVxwF/u7cjNQgGQlvlnKijYcIMlH/ZQpFpn7V6 21rQ== X-Gm-Message-State: AE9vXwNcMcPqoMIlWWdG7AsXKKEIm/fV3oNCzhOAvYrDGOIz3luAk/5n6COZqNNFJTAD4Q== X-Received: by 10.98.14.221 with SMTP id 90mr52819896pfo.181.1475031725849; Tue, 27 Sep 2016 20:02:05 -0700 (PDT) Received: from dino-macbook.wp.comcast.net (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by smtp.gmail.com with ESMTPSA id h8sm7830745pfk.88.2016.09.27.20.02.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 27 Sep 2016 20:02:05 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: Date: Tue, 27 Sep 2016 20:02:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8CA89FA5-D1AC-4D3B-8CB4-FD5E16DE8C4F@gmail.com> References: <32C28142-350A-4242-A9C6-9E32D9966601@gmail.com> <1D30AF33624CDD4A99E8C395069A2A162A600B3E@SJCEML701-CHM.china.huawei.com> To: Robert Raszuk X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "beta@lispers.net" , "ideas@ietf.org" , LISP mailing list list , NVO3 , "lisp-alpha@external.cisco.com" , LISPmob , "5gangip@ietf.org" <5gangip@ietf.org>, "lisp-ops@external.cisco.com" , Lin Han Subject: Re: [lisp] [Ideas] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 28 Sep 2016 03:02:08 -0000 > When I spoke to some of the 5G folks this was clearly the direction = and in fact Dino's LISP was one of the strongest candidates there as = control plane.=20 The IETF=E2=80=99s LISP-DDT borrows ideas from DNS but does not need to = be structured like the DNS deployed today. There is hierarchy for scale = with iterative lookups, but we don=E2=80=99t have to allow it to get out = of hand with too many levels of hierarchy. Dino From nobody Tue Sep 27 23:51:00 2016 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 D42FD12B26A; Tue, 27 Sep 2016 23:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] 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 ik89pD8KvZDw; Tue, 27 Sep 2016 23:50:57 -0700 (PDT) Received: from mx04.uni-tuebingen.de (mx04.uni-tuebingen.de [134.2.5.214]) (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 4997C12B077; Tue, 27 Sep 2016 23:50:57 -0700 (PDT) Received: from [192.168.1.100] (hsi-kbw-109-192-128-060.hsi6.kabel-badenwuerttemberg.de [109.192.128.60]) by mx04.uni-tuebingen.de (Postfix) with ESMTPSA id 76977E5117; Wed, 28 Sep 2016 08:50:55 +0200 (CEST) To: Dino Farinacci , Robert Raszuk References: <32C28142-350A-4242-A9C6-9E32D9966601@gmail.com> <1D30AF33624CDD4A99E8C395069A2A162A600B3E@SJCEML701-CHM.china.huawei.com> <8CA89FA5-D1AC-4D3B-8CB4-FD5E16DE8C4F@gmail.com> From: Michael Menth X-Enigmail-Draft-Status: N1110 Message-ID: <57EB684E.1000601@uni-tuebingen.de> Date: Wed, 28 Sep 2016 08:50:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <8CA89FA5-D1AC-4D3B-8CB4-FD5E16DE8C4F@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "beta@lispers.net" , "ideas@ietf.org" , LISP mailing list list , NVO3 , "lisp-alpha@external.cisco.com" , LISPmob , "5gangip@ietf.org" <5gangip@ietf.org>, "lisp-ops@external.cisco.com" , Lin Han Subject: Re: [lisp] [Ideas] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 28 Sep 2016 06:50:59 -0000 Hi Dino, Am 28.09.2016 um 05:02 schrieb Dino Farinacci: >> When I spoke to some of the 5G folks this was clearly the direction and in fact Dino's LISP was one of the strongest candidates there as control plane. > The IETF’s LISP-DDT borrows ideas from DNS but does not need to be structured like the DNS deployed today. There is hierarchy for scale with iterative lookups, but we don’t have to allow it to get out of hand with too many levels of hierarchy. What do you mean by that exactly? What's the problem with DNS and what's the advantage of LISP-DDT? Michael > > Dino > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Tue Sep 27 23:58:00 2016 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 3E9FC12B337; Tue, 27 Sep 2016 23:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=unavailable 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 zTMgBJYqBiAF; Tue, 27 Sep 2016 23:57:53 -0700 (PDT) Received: from mx04.uni-tuebingen.de (mx04.uni-tuebingen.de [134.2.5.214]) (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 5A27B12B38D; Tue, 27 Sep 2016 23:50:43 -0700 (PDT) Received: from [192.168.1.100] (hsi-kbw-109-192-128-060.hsi6.kabel-badenwuerttemberg.de [109.192.128.60]) by mx04.uni-tuebingen.de (Postfix) with ESMTPSA id 5CC2BE5117; Wed, 28 Sep 2016 08:50:41 +0200 (CEST) To: Dino Farinacci , Lin Han References: <32C28142-350A-4242-A9C6-9E32D9966601@gmail.com> <1D30AF33624CDD4A99E8C395069A2A162A600B3E@SJCEML701-CHM.china.huawei.com> From: Michael Menth X-Enigmail-Draft-Status: N1110 Message-ID: <57EB6840.1070808@uni-tuebingen.de> Date: Wed, 28 Sep 2016 08:50:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "beta@lispers.net" , "ideas@ietf.org" , LISP mailing list list , NVO3 , "lisp-alpha@external.cisco.com" , LISPmob , "5gangip@ietf.org" <5gangip@ietf.org>, "lisp-ops@external.cisco.com" Subject: Re: [lisp] [Ideas] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 28 Sep 2016 06:57:54 -0000 Hi Dino, Am 28.09.2016 um 04:59 schrieb Dino Farinacci: >> One side is that the national security of US prefer the government operates the root DNS, another side is that other countries don’t like US to completely control the DNS. > I see this hierarchy run by commercial companies that have monetary incentive to run a production level service. So for example, I could use a pair of roots from say a Verisign. Or a different pair of roots offered by an AT&T, or a possible a third-party that calls themselves a Mapping Service Provider (MSP). > > It is these roots at the top of the tree that need to connect to common parts in the middle and to the leaf map-servers of the tree. > >> This is related to both technology and politics. Without the support of other countries, mapping server deployment globally will be in question. > If registrations and requests are encrypted, then anyone could run the roots and the what goes in and out of the mapping system stays private. But there needs to be competition so the level of service stays at a high-quality production level. What is your vision? How much of the mapping data can be encrypted and how much information about the mapping owner can be hidden from the mapping system operator? The ID cannot be encrypted as it is used as retrieval key. When we want to make sure that only rightful owners of IDs can register, the mapping system provider needs to authenticate the mapping owner. Can you elaborate the problem you are tackling and the solution in more detail? Michael From nobody Wed Sep 28 02:24:55 2016 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 9F12E12B58E; Wed, 28 Sep 2016 02:24:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147505469360.16545.11504437649087964541.idtracker@ietfa.amsl.com> Date: Wed, 28 Sep 2016 02:24:53 -0700 Archived-At: Cc: lisp-chairs@ietf.org, lisp@ietf.org, luigi.iannone@telecom-paristech.fr Subject: [lisp] lisp - New Meeting Session Request for IETF 97 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 28 Sep 2016 09:24:53 -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: 50 Conflicts to Avoid: First Priority: rtgwg nvo3 i2rs sidr grow sfc sdnrg nfvrg pim intarea Second Priority: mboned icnrg irtfopen idr spring bier maprg Third Priority: l2tpext bess Special Requests: --------------------------------------------------------- From nobody Wed Sep 28 07:05:03 2016 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 459DB12B166; Wed, 28 Sep 2016 07:04:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147507149727.16539.11556071735672545257.idtracker@ietfa.amsl.com> Date: Wed, 28 Sep 2016 07:04:57 -0700 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-type-iana-02.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 28 Sep 2016 14:04:57 -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 of the IETF. Title : LISP Experimental Message & IANA Registry for LISP Packet Type Allocations Authors : Mohamed Boucadair Christian Jacquenet Filename : draft-ietf-lisp-type-iana-02.txt Pages : 5 Date : 2016-09-28 Abstract: This document defines a registry for LISP Packet Type allocations. It also specifies a shared LISP message type for experimentation purposes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-type-iana/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lisp-type-iana-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-type-iana-02 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 Wed Sep 28 13:24:46 2016 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 4720E12B2C4; Wed, 28 Sep 2016 13:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvYc7g0tcpTt; Wed, 28 Sep 2016 13:24:42 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::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 91F93127058; Wed, 28 Sep 2016 13:24:42 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id 21so20823136pfy.0; Wed, 28 Sep 2016 13:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ggzbmrr+znHGrbOtAA9QCo4ZlWm4oc7rDg5fA/IVJF4=; b=dT37GfdwW/Tf6GTa0NlZHuS98e8NROcGAcFQzI7/pHqMJCZpcSqkRiCNBGSSgw+0fk XzAZcS1BK7aoEo7gjdG/FrQsIQ5w6fK+umUDHklIdtj4t3Wd+3HNhMmHbIPhiJvY3FK8 8SS8Ex03mziWsFYH3FOP8IpPVAAO747WVZB4fEb9Wg57LE94+8VgMbNg0IGog3W0uf87 yGmCzv6qnqNtF1c0ub3N4oFxG8shlKLCQdVjpZTie6wClYJ1DI8XCw1bL2zSD28o7Cag cFFkXUhkxxpHi+A7Bph5/WvtcnCZxWofYWgvmq0BW4h/0UFFEU4HaUH5Nczis4fAkw7x i3FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ggzbmrr+znHGrbOtAA9QCo4ZlWm4oc7rDg5fA/IVJF4=; b=V9uu/yW/gz8tmCChymPU0Yb1ouJqDmCjaJxY80JkDhNNYIhsNYche0z5CxguVkdBGl nNmN8fUDfS0PRjjwawEBkVaOlREJFjvFQPamaaYEpcfDPEdXrSdeCjf5kHcEabFh89rK r2szjPxD1O8EFYOZynaZjcu9L4T4I/I+rM//85JilGaD+o++RVX/keJ5Mlec//Q9hRz9 Zi+hQLpAg2gI4cFVfMdTJp242GPZ0wD0GxeQAUI+z83t3ecnCiSut4UmWkfcQrIbdomD LKaN7ly17nhq3o9MwKh3eiROSlG+B3BnmZ2WIwOtaDTleOVtQLgVeKveYm23K77TR7Io jT/A== X-Gm-Message-State: AE9vXwMzUKJl53s5tbamyCapuxgaMYhGJU/+HOmF3ICFMb48Zdo1ep6DkvCLKLao0WpY2Q== X-Received: by 10.98.155.7 with SMTP id r7mr59931543pfd.171.1475094282171; Wed, 28 Sep 2016 13:24:42 -0700 (PDT) Received: from [10.197.31.157] ([216.216.202.69]) by smtp.gmail.com with ESMTPSA id 28sm14551129pfp.33.2016.09.28.13.24.40 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 28 Sep 2016 13:24:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: <57EB6840.1070808@uni-tuebingen.de> Date: Wed, 28 Sep 2016 13:24:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <737C63AF-6C5B-480C-B1EF-29AEBE0434EB@gmail.com> References: <32C28142-350A-4242-A9C6-9E32D9966601@gmail.com> <1D30AF33624CDD4A99E8C395069A2A162A600B3E@SJCEML701-CHM.china.huawei.com> <57EB6840.1070808@uni-tuebingen.de> To: Michael Menth X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "beta@lispers.net" , "ideas@ietf.org" , LISP mailing list list , NVO3 , "lisp-alpha@external.cisco.com" , LISPmob , "5gangip@ietf.org" <5gangip@ietf.org>, "lisp-ops@external.cisco.com" , Lin Han Subject: Re: [lisp] [Ideas] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 28 Sep 2016 20:24:44 -0000 >> If registrations and requests are encrypted, then anyone could run = the roots and the what goes in and out of the mapping system stays = private. But there needs to be competition so the level of service stays = at a high-quality production level. > What is your vision? How much of the mapping data can be encrypted and > how much information about the mapping owner can be hidden from the Well I think we can encrypt the transport of messages from LISP sites to = the mapping system. As to encrypting the stored state at the map-servers = could also be done but here are some caveats: (1) If the MSP is providing proxy-reply services it has to return = Map-Replies to ITRs/PITRs. It can do so with lisp-sec for security. But = the information needs to be stored in plaintext. (2) All the map-servers need to know when they are not proxy-replying is = to know the RLOCs of the ETRs of the site that registered the = information (and not so much all of the RLOC-records that were = registered) so the map-servers can forward Map-Requests to the ETRs so = they can Map-Reply. > mapping system operator? The ID cannot be encrypted as it is used as > retrieval key. When we want to make sure that only rightful owners of Right. At a minimum, the amount of plaintext that is stored in the = map-servers are EID-prefix and the RLOCs in the RLOC-set (for case (2) = above). > IDs can register, the mapping system provider needs to authenticate = the That is done today with a Map-Register that contains an authentication = hash across the entire Map-Register message. > mapping owner. Can you elaborate the problem you are tackling and the > solution in more detail? I was solely asking if the messaging to the mapping system should be = confidential. Dino From nobody Wed Sep 28 13:30:17 2016 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 884D012B4A4; Wed, 28 Sep 2016 13:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOPbMFHYFr4X; Wed, 28 Sep 2016 13:30:14 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC32F12B2E1; Wed, 28 Sep 2016 13:30:14 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id s13so20831165pfd.2; Wed, 28 Sep 2016 13:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1bzZKdccEQlYzQYoQTBE1g1vaWdiiQDFahgs1l0uuUY=; b=eNNOyIVgHfLuVcmRDHl9/SH6o/DZKPe599U5D5dx8X0uFTAJ5r4Qzp/J6kzcr64+P0 0kc1+/lLrKZX6AdCqoX9pzWJ9IaWP0AovNJX4A58NVNVmdpQ17avA8LNRGqTUjSYgfxH CwqI0vOSvlZ3x8HW8sZYmBcyTz+mMb+7Vfmbomq7CkIsB/mW9/hrC2q5SmQuNap2KFZh mV+w14yEbC5wMIpAyW9W8HRfSnrch4AWy8NcHpq1KG2wCfk6C3UFOYWq25gtNL16FzUw T/0KUmdFCeKyLTRRyQkdpeffh0/0FasOjvRFEcUYvoK8GdJb4xZRrubfnwxdsN1wGgDC YDAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1bzZKdccEQlYzQYoQTBE1g1vaWdiiQDFahgs1l0uuUY=; b=d9oO+1Na+R/XSx7lQJhK1yEdJF1qYRlQfFe0RkA7LK/kA6HQL58s2X9NqlyJFxe7fA De7eqyrq/dk1uA4l0CleSGF0ipfCOEKyqew8T9MURRVT7qwRGnkmao4ct3l5JMQRv8N0 TRpKKmNVQK5Va9oeB9rve5Hs1gjcSexE+ACD3Yb4t0AEXGdGk/oJZg3IpQPGNQw14eFi yvwdqGO7M1Yv0Kjs83OQ7TULeUoo86OuEo5Wg4h3+8eHjYNyOY/5rC9tOijNUWqyb2kX 5bKiHIvgEiJqfOb6ddPpOzAgMadLl+BjUAzdS6joaP9m6QuvcxzsLOagbyBdj++lXjeI pVlA== X-Gm-Message-State: AE9vXwOc9KGcoIiGoJpUJKINmB3HYAfYVy70HE+UZnM+qewzrFvt+N6TbZm3fXsOh3kH6w== X-Received: by 10.98.31.133 with SMTP id l5mr60005964pfj.178.1475094614248; Wed, 28 Sep 2016 13:30:14 -0700 (PDT) Received: from [10.197.31.157] ([216.216.202.69]) by smtp.gmail.com with ESMTPSA id t5sm14581998pfi.26.2016.09.28.13.30.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 28 Sep 2016 13:30:13 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: <57EB684E.1000601@uni-tuebingen.de> Date: Wed, 28 Sep 2016 13:30:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <32C28142-350A-4242-A9C6-9E32D9966601@gmail.com> <1D30AF33624CDD4A99E8C395069A2A162A600B3E@SJCEML701-CHM.china.huawei.com> <8CA89FA5-D1AC-4D3B-8CB4-FD5E16DE8C4F@gmail.com> <57EB684E.1000601@uni-tuebingen.de> To: Michael Menth X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "beta@lispers.net" , "ideas@ietf.org" , LISP mailing list list , NVO3 , "lisp-alpha@external.cisco.com" , LISPmob , "5gangip@ietf.org" <5gangip@ietf.org>, "lisp-ops@external.cisco.com" , Lin Han Subject: Re: [lisp] [Ideas] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 28 Sep 2016 20:30:16 -0000 > Am 28.09.2016 um 05:02 schrieb Dino Farinacci: >>> When I spoke to some of the 5G folks this was clearly the direction = and in fact Dino's LISP was one of the strongest candidates there as = control plane.=20 >> The IETF=E2=80=99s LISP-DDT borrows ideas from DNS but does not need = to be structured like the DNS deployed today. There is hierarchy for = scale with iterative lookups, but we don=E2=80=99t have to allow it to = get out of hand with too many levels of hierarchy. > What do you mean by that exactly? What's the problem with DNS and = what's > the advantage of LISP-DDT? These were the main reasons we didn=E2=80=99t consider DNS as a mapping = system back in the RRG days when we were designing the mapping system = for LISP: (1) DNS didn=E2=80=99t work easily on bit boundaries. So delegation = would have to be on byte boundaries and that restricts the flexibility = of how EID address allocation occurs on the LISP-DDT hierarchy. (2) DNS doesn=E2=80=99t have a pub/sub model. LISP needed notification = support so old RLOCs new when an EID has moved to a new set of RLOCs. (3) Architecturally, we didn=E2=80=99t want routing information to be in = an applicaiton Directory. Since DNS depends on routing, we didn=E2=80=99t = want routing to depend on DNS and cause a circular dependency to be = created. (4) And we thought it would be too hard to get IETF to allow network = layer information to be stored in what is really a application level = database. So the architectural definition of a LISP EID would be in the DNS = pointed to by names and the dynamic binding of EIDs to RLOCs would be in = a new network layer database, which we refer to as the LISP Mapping = System. Dino >=20 > Michael >=20 >>=20 >> Dino >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp From nobody Wed Sep 28 14:11:51 2016 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 86E5C12B127; Wed, 28 Sep 2016 14:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uALO2QbSwnrJ; Wed, 28 Sep 2016 14:11:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0CC912B00E; Wed, 28 Sep 2016 14:11:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CSB76645; Wed, 28 Sep 2016 21:11:41 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 28 Sep 2016 22:11:40 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Wed, 28 Sep 2016 14:11:34 -0700 From: Richard Li To: "ideas@ietf.org" , "lisp@ietf.org" Thread-Topic: RE: [lisp] [Ideas] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt Thread-Index: AdIZzOP8v2BaiL1kTEal3ROYmzzdQA== Date: Wed, 28 Sep 2016 21:11:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.254] Content-Type: multipart/alternative; boundary="_000_F061CEB6876F904F8EA6D6B92877731C39C37147dfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.57EC320E.0070, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: bbc91c133a4024ef7c50246026de9994 Archived-At: Subject: Re: [lisp] [Ideas] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 28 Sep 2016 21:11:46 -0000 --_000_F061CEB6876F904F8EA6D6B92877731C39C37147dfweml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dino and Padma, With great interest, I have read draft-padma-ideas-problem-statement-00.txt= . Since some efforts have been made, at least partially, in LISP, why do we s= till want to work on it? Appreciated if you could explain it a little bit. Thanks, Richard --_000_F061CEB6876F904F8EA6D6B92877731C39C37147dfweml501mbb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dino and Padma,

 

With great interest, I have read draft-padma-ideas-p= roblem-statement-00.txt.

 

Since some efforts have been made, at least partiall= y, in LISP, why do we still want to work on it? Appreciated if you could ex= plain it a little bit.

 

Thanks,

 

Richard

 

 

--_000_F061CEB6876F904F8EA6D6B92877731C39C37147dfweml501mbb_-- From nobody Wed Sep 28 15:21:28 2016 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 7834D12B00D; Wed, 28 Sep 2016 15:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6VA7mZ0yy22; Wed, 28 Sep 2016 15:21:22 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 011B712B1F7; Wed, 28 Sep 2016 15:21:21 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id j129so53652578qkd.1; Wed, 28 Sep 2016 15:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=O0heCnjhIawhZGBDqEXqFIdA1XiPFbhWfXSYjF4M7ww=; b=wL3ZmzCWK3RXgllifCcE1LrAsZaOF3qLL+spfln/1iuzJoJu3yxwq+W/cI3rLT9iqi Kl3/NE1cEqOuBGf3f+wVID2vINCHQF1m7P+2eq6bEntKg8vzMrFSyM8sH+yczJ1sMzZd 6YtFnrxMIU7OFE8L5blXaBSb+HYGTIf6/cXgAdmSvJMuXh9Js2aGHvVNdkpmD+VJQlrQ qXZVEFrXDLpCNRxwXIi6md8T34It2YTzdPK6f4DfYeKpwWAcTxWkV0matwS/pvKXa2Pr /AU7GPTubZzwdNwkmN48jFNDQsZa75Cp9uW/Q2hnZ2g2HyDHZJ/9vvwru/X/8DhRxVv3 /wJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=O0heCnjhIawhZGBDqEXqFIdA1XiPFbhWfXSYjF4M7ww=; b=OegkJGHQuna1v+Pf3bF2AlnmV5JV+XxVZN2Yftx59RKJXuL9OOJUjRo+QAckr7sx6k mlXPtjjK4LCNvwegFjGfLCKkguQhbPX3osKoZIV5jkv2tEGXCmA5/IJ+OiaOZDr0nb5s i9vez9t4SJ3dY1to1fits3yKryITgaiiCz0jkgHqa+yGYuEzbXbGXci1p8rKuM4Uu2D4 HOy/OFWN38a1d147TrWMCfqqyV9vFVrVJBwQqihtgK2fk5fCKNY0ga5towjvIcbfD2s/ XCT1LyMu3UB6Tt4edPXgj5bCLICWXm7IMtXJ6xehTtrAe6+WN+ctCfN37KAjPNnS++r4 XWiQ== X-Gm-Message-State: AA6/9RlNzA7Y6o72hBEcuzkKYVeTUuWKlSUhNNae9yoqlJ/fKjUeqkWoFq3nIXxSZM/NfQ== X-Received: by 10.55.108.6 with SMTP id h6mr33527832qkc.289.1475101281201; Wed, 28 Sep 2016 15:21:21 -0700 (PDT) Received: from [10.31.1.71] (ip-64-134-222-71.public.wayport.net. [64.134.222.71]) by smtp.gmail.com with ESMTPSA id z186sm4981727qkb.13.2016.09.28.15.21.20 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 28 Sep 2016 15:21:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: Date: Wed, 28 Sep 2016 15:21:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Richard Li X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "ideas@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] [Ideas] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 28 Sep 2016 22:21:23 -0000 > Since some efforts have been made, at least partially, in LISP, why do = we still want to work on it? Appreciated if you could explain it a = little bit. LISP is a solution. The draft is a requirements document. We need to = generate requirements to decide if the LISP solution meets them. It might sound backwards, but that is how it works out chronologically. Dino From nobody Wed Sep 28 16:51:39 2016 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 342AB12B1ED; Wed, 28 Sep 2016 16:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlD0CPhoNgXQ; Wed, 28 Sep 2016 16:51:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BFA012B03B; Wed, 28 Sep 2016 16:51:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CXC04435; Wed, 28 Sep 2016 23:51:34 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.218.25.35) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 29 Sep 2016 00:51:33 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.53]) by SJCEML702-CHM.china.huawei.com ([169.254.4.207]) with mapi id 14.03.0235.001; Wed, 28 Sep 2016 16:51:23 -0700 From: Padmadevi Pillay Esnault To: Dino Farinacci , Richard Li Thread-Topic: [Ideas] [lisp] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt Thread-Index: AdIZzOP8v2BaiL1kTEal3ROYmzzdQAARGsOAAAyKg6A= Date: Wed, 28 Sep 2016 23:51:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.111.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.57EC5786.0130, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.53, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 21593b2ea99517b86651e5381f2c8864 Archived-At: Cc: "ideas@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] [Ideas] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 28 Sep 2016 23:51:39 -0000 Hi Richard =20 Thank you for your comment. =20 The ideas problem statement is introducing a new Network Mapping Systems (N= MS) in order to have an efficient interoperable solution between ID based p= rotocols.=20 The LISP mapping system's main functionality is to provide the mapping of I= D/LOC in LISP. However, the NMS goal is to have a common control plane for multiple data-p= lanes rather than one mapping system or scheme per protocol. We also are building the NMS to cater for a wide variety of fixed and mobil= ity cases including IoT, IP mobility and mobility over heterogeneous access= networks. The Network mapping systems may also have different scopes (loca= l, regional or global) and be private or public as well. The expectations is that the NMS will be a powerful extensible infrastructu= re usable by all and not restricted to specific use cases. Padma =20 -----Original Message----- From: Ideas [mailto:ideas-bounces@ietf.org] On Behalf Of Dino Farinacci Sent: Wednesday, September 28, 2016 3:21 PM To: Richard Li Cc: ideas@ietf.org; lisp@ietf.org Subject: Re: [Ideas] [lisp] Mapping System Requirements and draft-padma-ide= as-problem-statement-00.txt > Since some efforts have been made, at least partially, in LISP, why do we= still want to work on it? Appreciated if you could explain it a little bit= . LISP is a solution. The draft is a requirements document. We need to genera= te requirements to decide if the LISP solution meets them. It might sound backwards, but that is how it works out chronologically. Dino _______________________________________________ Ideas mailing list Ideas@ietf.org https://www.ietf.org/mailman/listinfo/ideas From nobody Thu Sep 29 10:49:31 2016 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 A9C3312B123; Thu, 29 Sep 2016 10:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g39cZ5h0L_bM; Thu, 29 Sep 2016 10:49:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCBEB12B0FA; Thu, 29 Sep 2016 10:49:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CXD42789; Thu, 29 Sep 2016 17:49:21 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 29 Sep 2016 18:49:20 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Thu, 29 Sep 2016 10:49:10 -0700 From: Lin Han To: Padmadevi Pillay Esnault , Dino Farinacci , Richard Li Thread-Topic: [Ideas] [lisp] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt Thread-Index: AdIZzOP8v2BaiL1kTEal3ROYmzzdQAARGsOAAAyKg6AADWMFMA== Date: Thu, 29 Sep 2016 17:49:09 +0000 Message-ID: <1D30AF33624CDD4A99E8C395069A2A162AFA9F91@dfweml501-mbb> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.64.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.57ED5421.0345, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 21593b2ea99517b86651e5381f2c8864 Archived-At: Cc: "ideas@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] [Ideas] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 29 Sep 2016 17:49:27 -0000 Hi, Padma This sounds interesting, are you saying that the mapping system will finall= y support the interworking between different Loc/id protocols, such as LISP= and HIP and others? Also, could you elaborate the "common control plane". This impressed me it = will be a super-controller, isn't it? Thanks Lin -----Original Message----- From: Ideas [mailto:ideas-bounces@ietf.org] On Behalf Of Padmadevi Pillay E= snault Sent: Wednesday, September 28, 2016 4:51 PM To: Dino Farinacci; Richard Li Cc: ideas@ietf.org; lisp@ietf.org; Padmadevi Pillay Esnault Subject: Re: [Ideas] [lisp] Mapping System Requirements and draft-padma-ide= as-problem-statement-00.txt Hi Richard =20 Thank you for your comment. =20 The ideas problem statement is introducing a new Network Mapping Systems (N= MS) in order to have an efficient interoperable solution between ID based p= rotocols.=20 The LISP mapping system's main functionality is to provide the mapping of I= D/LOC in LISP. However, the NMS goal is to have a common control plane for multiple data-p= lanes rather than one mapping system or scheme per protocol. We also are building the NMS to cater for a wide variety of fixed and mobil= ity cases including IoT, IP mobility and mobility over heterogeneous access= networks. The Network mapping systems may also have different scopes (loca= l, regional or global) and be private or public as well. The expectations is that the NMS will be a powerful extensible infrastructu= re usable by all and not restricted to specific use cases. Padma =20 -----Original Message----- From: Ideas [mailto:ideas-bounces@ietf.org] On Behalf Of Dino Farinacci Sent: Wednesday, September 28, 2016 3:21 PM To: Richard Li Cc: ideas@ietf.org; lisp@ietf.org Subject: Re: [Ideas] [lisp] Mapping System Requirements and draft-padma-ide= as-problem-statement-00.txt > Since some efforts have been made, at least partially, in LISP, why do we= still want to work on it? Appreciated if you could explain it a little bit= . LISP is a solution. The draft is a requirements document. We need to genera= te requirements to decide if the LISP solution meets them. It might sound backwards, but that is how it works out chronologically. Dino _______________________________________________ Ideas mailing list Ideas@ietf.org https://www.ietf.org/mailman/listinfo/ideas _______________________________________________ Ideas mailing list Ideas@ietf.org https://www.ietf.org/mailman/listinfo/ideas From nobody Thu Sep 29 11:19:51 2016 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 C031C12B209; Thu, 29 Sep 2016 11:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRDtxeMa9G4o; Thu, 29 Sep 2016 11:19:47 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22B1C12B1BD; Thu, 29 Sep 2016 11:19:47 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id u78so6069005pfa.1; Thu, 29 Sep 2016 11:19:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fasOzddVEeyM3iY1w1q4xOEGaXRaOicg1MQBbFfQI6c=; b=pSl1lNn8HNWpZoCD5hHLxmNU3AdWLvQjZejzfq8bPzSv77pZLK/BSpFkBXv7apX94B AeFGWL3yD+62nYlW1qnLchdWXrkd0PpZSBXqCsxcP24G0cf8WO/Ow6niNCDvIDmW3xSW ChD76GkvnHt510gYcsYWFc+gOD+ON+zCCCmymBh+qdIo9O53QckfMLLZyqxIWXAvcuQB l9naofV16z4t303KUKue21Yt3giOA9D3OVTlPPhYDC1xki2BH9mF/iQx/zzSbAw3qd58 NtZp8guEnPO/gb5AVOLCz037kMkcoQzB0y6vSmXv3goYjF75O36XGPa4/B23wIMh39QC ki0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fasOzddVEeyM3iY1w1q4xOEGaXRaOicg1MQBbFfQI6c=; b=BbBowap9BYc8b0cNL+iIjg4lBrP7x73RdBOU4MUawTnSlq+dKBbIIlskZGInmv9IyA rtEMUoV3LrMDMs+Cbt9M8aKuGsfzRYJOazNkcNzF4Dw4EkfHrkMwqtXVsvc9tXGJ5sqd luij7oSRAtEAtSmgqM90rM3cVZ1oDflUdty7YCDs8zd5HEXi84B5scs1uJido9Isg52a nQQ2lOOBFX8LA4X4f8/drxvmru9fEo71u8RgeZPlfgmkvDcyCas4ww30o53i3A7RQ6ht 9xGZe0nHGrIRVSJWGID6gGI/jGFaZJ7wdaWYEsW2gBLqMqBcaf5Esd/ETMBv8pthRYua xBGg== X-Gm-Message-State: AA6/9RmEmoFUgbHZCw7K5A6pV9Iy+y10KLqN+Q3drjzScnEehnZQVhHIMjjwlOfoK7jQNQ== X-Received: by 10.98.217.199 with SMTP id b68mr4750710pfl.74.1475173186711; Thu, 29 Sep 2016 11:19:46 -0700 (PDT) Received: from ?IPv6:2600:1010:b044:4e28:25cd:6dc8:4893:9cf3? ([2600:1010:b044:4e28:25cd:6dc8:4893:9cf3]) by smtp.gmail.com with ESMTPSA id z66sm14006769pfd.11.2016.09.29.11.19.44 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 29 Sep 2016 11:19:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Sharon X-Mailer: iPhone Mail (14A456) In-Reply-To: Date: Thu, 29 Sep 2016 11:19:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <32C28142-350A-4242-A9C6-9E32D9966601@gmail.com> <1D30AF33624CDD4A99E8C395069A2A162A600B3E@SJCEML701-CHM.china.huawei.com> <8CA89FA5-D1AC-4D3B-8CB4-FD5E16DE8C4F@gmail.com> <57EB684E.1000601@uni-tuebingen.de> To: Dino Farinacci Archived-At: Cc: "beta@lispers.net" , "ideas@ietf.org" , LISP mailing list list , NVO3 , "lisp-alpha@external.cisco.com" , LISPmob , "5gangip@ietf.org" <5gangip@ietf.org>, "lisp-ops@external.cisco.com" , Lin Han Subject: Re: [lisp] [Ideas] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 29 Sep 2016 18:19:50 -0000 Can add that we don't want to scale a mapping service like dns or x500. rath= er take full advantage of no-sql tech that wasn't available at the time to c= reate a flat pub-nub like service for overlays, scaled based on underlay reg= ular IP. No bootstrap loop. The effect on mobile can be dramatic, any packet coming up from the base-sta= tion, no matter the address space or transience can be considered Gi. No nee= d for a whole different sets of framework for network functions pre Gi and p= ost Gi. There's the RAN and there's virtual IP (NVO3). Or rather (flat ) dir= ectory-assisted virtual IP. traffic going back and forth: =20 Mapping=20 | | RAN <> NVO3 <> IP <> NVO3 <> Internet=20 | | Functions Functions=20 (scheduling) (peering) --szb On Sep 28, 2016, at 1:30 PM, Dino Farinacci wrote: >> Am 28.09.2016 um 05:02 schrieb Dino Farinacci: >>>> When I spoke to some of the 5G folks this was clearly the direction and= in fact Dino's LISP was one of the strongest candidates there as control pl= ane.=20 >>> The IETF=E2=80=99s LISP-DDT borrows ideas from DNS but does not need to b= e structured like the DNS deployed today. There is hierarchy for scale with i= terative lookups, but we don=E2=80=99t have to allow it to get out of hand w= ith too many levels of hierarchy. >> What do you mean by that exactly? What's the problem with DNS and what's >> the advantage of LISP-DDT? >=20 > These were the main reasons we didn=E2=80=99t consider DNS as a mapping sy= stem back in the RRG days when we were designing the mapping system for LISP= : >=20 > (1) DNS didn=E2=80=99t work easily on bit boundaries. So delegation would h= ave to be on byte boundaries and that restricts the flexibility of how EID a= ddress allocation occurs on the LISP-DDT hierarchy. >=20 > (2) DNS doesn=E2=80=99t have a pub/sub model. LISP needed notification sup= port so old RLOCs new when an EID has moved to a new set of RLOCs. >=20 > (3) Architecturally, we didn=E2=80=99t want routing information to be in a= n applicaiton Directory. Since DNS depends on routing, we didn=E2=80=99t wan= t routing to depend on DNS and cause a circular dependency to be created. >=20 > (4) And we thought it would be too hard to get IETF to allow network layer= information to be stored in what is really a application level database. >=20 > So the architectural definition of a LISP EID would be in the DNS pointed t= o by names and the dynamic binding of EIDs to RLOCs would be in a new networ= k layer database, which we refer to as the LISP Mapping System. >=20 > Dino >=20 >>=20 >> Michael >>=20 >>>=20 >>> Dino >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Thu Sep 29 11:21:24 2016 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 D0B4C12B21C; Thu, 29 Sep 2016 11:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ot8WQTz6Fdz; Thu, 29 Sep 2016 11:21:20 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 853DE12B22B; Thu, 29 Sep 2016 11:21:16 -0700 (PDT) Received: by mail-pa0-x22a.google.com with SMTP id oz2so30090134pac.2; Thu, 29 Sep 2016 11:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=69uVCUkYxgw7mAuMRPRq8wjsLhrTMtfbGXDtVl28L1Q=; b=gREu4tm0eZC8Fkt/GRcQJYx24UJqsxndm7H/hqm3UIkueEHDJxgBYURlvAr/TKZHXi nu9HFadWMOLDP8P8u1msD59vGrCOiOdiRIO/zSzekcDiQfoeKuh6dtXkzfv9sol5R1Nc ipbJDk1qJI/go4SyXnTJYdMmt+KLF1Q1qogOnTyg9VoZRnAw2u9XAHoafeUcW8A+XxHd t+yKGEz/sotQ/1Ih84Al/XPstkLSSHl5IljKbxZXz5N2ofLBc0OukXjt6j0vSG+K7qcY OmtySg+utiGRfIODhe80EM/pycIpSzmifeewLQAMpVoIWz2TEWHr4Vaku5aJ+1JmI5dM 96vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=69uVCUkYxgw7mAuMRPRq8wjsLhrTMtfbGXDtVl28L1Q=; b=OKTYNOF5/ApW52nLQ5f7//L2Rdmfae6gbF51Lie9Gqja7BLWBmJavflU5CDDJp6Qoz UUmfFOyqUy1RSAjDTLtTC4AhVlx8iwBKovZmkZSNhVCyfB0yitKJv3h8oAAlPVBs/16l xTI7biwl0as55v3mXclHoB7ValWoNX+8zaDEHIXXYCGPQ2o+kIUps9dhT1i0tTD0cvns /j2bwlPY9cDmuGVwmDNjyoHsbWScwFcvy6buoeTFeDWZTF3AojZ3msL6Au89wRt6e+Eo XNmylQ7MUVq0WlFxukCvPR4dzZk2hVkL+3Nel7QJFXrSUq7xMgK1b5FbHectiw7hHCr9 LQXg== X-Gm-Message-State: AA6/9RnlXDENH7E1lcuMvPzas7w6lN9UXFGoTBq5edrFZkKxfSVHz9z1AWkoQp4cKkkPSQ== X-Received: by 10.66.197.197 with SMTP id iw5mr4636957pac.130.1475173276215; Thu, 29 Sep 2016 11:21:16 -0700 (PDT) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id c66sm21931250pfd.24.2016.09.29.11.21.15 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 29 Sep 2016 11:21:15 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: <1D30AF33624CDD4A99E8C395069A2A162AFA9F91@dfweml501-mbb> Date: Thu, 29 Sep 2016 11:21:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4AACB05E-43F5-4CF1-B433-C0100880B3FB@gmail.com> References: <1D30AF33624CDD4A99E8C395069A2A162AFA9F91@dfweml501-mbb> To: Lin Han X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "ideas@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] [Ideas] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 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, 29 Sep 2016 18:21:23 -0000 > This sounds interesting, are you saying that the mapping system will = finally support the interworking between different Loc/id protocols, = such as LISP and HIP and others? > Also, could you elaborate the "common control plane". This impressed = me it will be a super-controller, isn't it? I don=E2=80=99t see any reason why a HIP host cannot send LISP = Map-Requests and Map-Registers to a LISP mapping system. It could do it = for any EID type, even though a HIT is a perfectly fine EID key to use. Dino