From nobody Sun Nov 1 01:14:23 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6691B71B2 for ; Sun, 1 Nov 2015 01:14:22 -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 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 iaCxqQ-iNcQP for ; Sun, 1 Nov 2015 01:14:20 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::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 320DA1B71B0 for ; Sun, 1 Nov 2015 01:14:20 -0700 (PDT) Received: by pasz6 with SMTP id z6so115960321pas.2 for ; Sun, 01 Nov 2015 01:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=g4smq4H1Jmy2aatyT/CUsyex5qqiKRXsDoSPfquzXCA=; b=QI3RT/eGZ5HKHLb8WNpaWZIAS1BHA8sfguheY+C8UxtjWiaxpwPZDNk/7riMSjOkSP uoShPYoe2eWVztr6TTUJ41bXoK25WpZUuQIDdrkr3QLmXR/vszw1u71Gycg7Xe3Cfbwi kM4RLqC2kEO8JBK1IRNtYD3cSs4wiZMrQdnkED0iY7EeNZMzhTFCSZAK35X0Xs9PKTXt sbclYaj3u47k5UKl7WeuDmFWW56VXyedSID1E0qHVel7IiS+lY+jKLPHA5M95S+Ax5VB dFEg+eA+4shMCqY5GkaLYLXJ9gXLRV/yVSqKc4kfJafbRi90wUXm5OV9BLWQG7M1mDo0 HOiw== X-Received: by 10.68.254.170 with SMTP id aj10mr19212900pbd.97.1446365659799; Sun, 01 Nov 2015 01:14:19 -0700 (PDT) Received: from [10.71.1.66] ([101.110.53.38]) by smtp.gmail.com with ESMTPSA id bs3sm17341857pbd.89.2015.11.01.01.14.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Nov 2015 01:14:18 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Dino Farinacci In-Reply-To: <20151028141703.GA9632@LK-Perkele-V2.elisa-laajakaista.fi> Date: Sun, 1 Nov 2015 01:13:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1C855BE8-70D6-4604-AFED-4298AAD6186C@gmail.com> References: <20151028141703.GA9632@LK-Perkele-V2.elisa-laajakaista.fi> To: Ilari Liusvaara X-Mailer: Apple Mail (2.2104) Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] Let's review crypto in lisp-crypto X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 01 Nov 2015 08:14:22 -0000 > I did a review of crypto usage of lisp-crypto (-02), and found the > following issues (some I have noticed before, some were new to me): Thanks for doing that Ilari. See my responses inline. > - Ciphersuite 1 uses 1024-bit Diffie-Hellman, which is too weak > (after you have cracked one key (and it doesn't take that much, > especially if you can throw ASICs at the problem), you can crack > each subsequent one in a few CPU minutes. With 2048-bit DH, at > least the first key tends to be too hard, and with ECDH, tricks > like this don't work). Yes, both Brian and I replied that we were using this more for = experimentation on low-powered or CPU challenged devices. We will not = recommend its use. It=E2=80=99s just there for implementations to start = with something. But havind said that, I would like to recommend the = smaller keys that come along with chacha20/poly1305 so maybe the subject = is moot.=20 > - Instead of "homecooked" encryption, use AEAD modes. AES-GCM is a lot > faster than AES-CBC + HMAC-SHA1-96. I didn=E2=80=99t realize we were home cooking this. We can certainly go = with AES-GCM. Do you think we should add a new cipher suite for it or = just change the existing ones that refer to AES-CBC to AES-GCM? > - AEAD_CHACHA20_POLY1305 is not composition of CHACHA20 and POLY1305, > it is a single AEAD algorithm (as is AES128-GCM). Did we imply that? Can you point to the text? I for one, am not expert = enough to know the difference so if text implies that, please point that = out. > - How to encode Diffie-Hellman public keys? I presume big-endian > integer encoding. I will make that more clear in the spec. Thanks. > - Don't truncate Diffie-Hellman secret, just feed the entiere thing > to the KDF I want Brian to comment on this. I have no opinion about the matter. > - The NIST SP800-108 KDF handles the counter and length internally, > those are not part of the context input. You should point to text so we know where in the spec you are commenting = against. It is hard to get context from your comments. > - If you need identifier for association (e.g. for displaying to > admin for authentication purposes), you must hash in the (EC)DH > public keys used into the identifier. Otherwise MITM attacker can > defeat the authentication. We use the source RLOC and the Map-Request nonce to identify the = association. > - If the same system can be ITR and ETR at once, how one ensures that > if two such systems establish associations to each other, the keys > won't wind up being the same? This could be solved by requiring Because the key-pair is unidirectional. If router A is an ITR and sends = a Map-Request to router B, that key-pair is for data traffic = encapsulated from A to B. If B is an ITR encapsulating to A an ETR, a = differne key-pair is used. A new random number generator, nonce, and key = exchange is performed for each direction. > separate keys for ITR and ETR operation, or including the public > keys in the context in fixed order (e.g. first ITR, then ETR). > - AEAD_CHACHA20_POLY1305 IVs are 12 octets, right? That's too short > to randomly generate. Instead, the encryptor should just use its Yes, you are right. I padded to 16-bytes in my implementation. Do you = see harm in that. That way the packet length/format doesn=E2=80=99t have = to change for different cipher suites. If you are okay with padding, I can make that more clear in the spec. > preferred generation method that takes long time to cycle (counter, > 96-bit LFSR, etc...). > - Are the associations unidirectional (data is only ever sent one > way) or how is uniqueness of IVs between directions handled? Yes, unidirectional. IVs are per packet, any packet, in any direction. > - IV is incremented for every packet? If using CBC mode, predictable > IVs are bad (AEAD algorithms do deal with predictable IVs, but not > repeating IVs). The diagram in Section 6: 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|P|K|K| Nonce/Map-Version | \ I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S \ | Instance ID/Locator-Status-Bits | | P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Initialization Vector (IV) | I E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C n / | | V c | | | r | Packet Payload with EID Header ... | | y | | | p \ | | / t +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integrity Check Value (ICV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Is the same for any cipher suite. > - AEAD_CHACHA20_POLY1305 decryption both checks the ICV and if the > check passes, decrypts the data. So performing step 2 also performs > step 5. Hmm. So are you saying that if the cipher suite negotiated is chacha20, = we should not add a ICV? That would be great, beacuse we can make cipher = suite 4 go even faster. > - I don't see requirement that ITR nonces must be distinct for the > same ITR DH key (otherwise encryption keys will be the same if > the ETR DH key is the same)? Well in RFC 6830, we state that nonces are distinct for each = Map-Request. So we inherit that information for DH. > - The CHACHA-POLY reference should presumably point to RFC7539? > - Maybe use the CFRG-CURVES draft (in RFC-EDITOR queue) for > Curve25519/X25519. I will fix. Thanks for comments and please clarify some of my questions = above. Cheers, Dino >=20 >=20 > -Ilari >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Sun Nov 1 01:53:34 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CED91A8738 for ; Sun, 1 Nov 2015 01:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_52=1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 uX-8K9BXO4Q2 for ; Sun, 1 Nov 2015 01:53:30 -0800 (PST) Received: from filtteri2.pp.htv.fi (filtteri2.pp.htv.fi [213.243.153.185]) by ietfa.amsl.com (Postfix) with ESMTP id CD0F21A872E for ; Sun, 1 Nov 2015 01:53:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by filtteri2.pp.htv.fi (Postfix) with ESMTP id A274819C79D; Sun, 1 Nov 2015 11:53:28 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp5.welho.com ([213.243.153.39]) by localhost (filtteri2.pp.htv.fi [213.243.153.185]) (amavisd-new, port 10024) with ESMTP id 2m8zxFwXnNdz; Sun, 1 Nov 2015 11:53:28 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp5.welho.com (Postfix) with ESMTPSA id 661225BC002; Sun, 1 Nov 2015 11:53:28 +0200 (EET) Date: Sun, 1 Nov 2015 11:53:25 +0200 From: Ilari Liusvaara To: Dino Farinacci Message-ID: <20151101095325.GB13377@LK-Perkele-V2.elisa-laajakaista.fi> References: <20151028141703.GA9632@LK-Perkele-V2.elisa-laajakaista.fi> <1C855BE8-70D6-4604-AFED-4298AAD6186C@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1C855BE8-70D6-4604-AFED-4298AAD6186C@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] Let's review crypto in lisp-crypto X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 01 Nov 2015 09:53:32 -0000 On Sun, Nov 01, 2015 at 01:13:56AM -0700, Dino Farinacci wrote: > > > - Ciphersuite 1 uses 1024-bit Diffie-Hellman, which is too weak > > (after you have cracked one key (and it doesn't take that much, > > especially if you can throw ASICs at the problem), you can crack > > each subsequent one in a few CPU minutes. With 2048-bit DH, at > > least the first key tends to be too hard, and with ECDH, tricks > > like this don't work). > > Yes, both Brian and I replied that we were using this more for > experimentation on low-powered or CPU challenged devices. We will > not recommend its use. It’s just there for implementations to start > with something. But havind said that, I would like to recommend > the smaller keys that come along with chacha20/poly1305 so maybe > the subject is moot. I think that even having low-security options is a problem. > > - Instead of "homecooked" encryption, use AEAD modes. AES-GCM is a lot > > faster than AES-CBC + HMAC-SHA1-96. > > I didn’t realize we were home cooking this. We can certainly go with > AES-GCM. Do you think we should add a new cipher suite for it or > just change the existing ones that refer to AES-CBC to AES-GCM? I think just change them. > > - AEAD_CHACHA20_POLY1305 is not composition of CHACHA20 and POLY1305, > > it is a single AEAD algorithm (as is AES128-GCM). > > Did we imply that? Can you point to the text? I for one, am not > expert enough to know the difference so if text implies that, > please point that out. IIRC, the text says something like: Encryption: Chacha20 Integerity: Poly1305 (i.e. AEAD_CHACHA20_POLY1305) Which would imply some sort of composition (and the encryption and decryption procedures also seem to imply it is composition, as those handle encryption and authentication seperatedly). > > - The NIST SP800-108 KDF handles the counter and length internally, > > those are not part of the context input. > > You should point to text so we know where in the spec you are > commenting against. It is hard to get context from your comments. Section 5 in -02. The listing for "Context" (meaning the fields in context). > > - If you need identifier for association (e.g. for displaying to > > admin for authentication purposes), you must hash in the (EC)DH > > public keys used into the identifier. Otherwise MITM attacker can > > defeat the authentication. > > We use the source RLOC and the Map-Request nonce to identify the association. That's does not create identifier suitable for comparing between endpoints for authentication. > > - If the same system can be ITR and ETR at once, how one ensures that > > if two such systems establish associations to each other, the keys > > won't wind up being the same? This could be solved by requiring > > Because the key-pair is unidirectional. If router A is an ITR and sends > a Map-Request to router B, that key-pair is for data traffic encapsulated > from A to B. If B is an ITR encapsulating to A an ETR, a differne > key-pair is used. A new random number generator, nonce, and key > exchange is performed for each direction. You mean that A (and B) is supposed to use different DH keys for their roles as ITR and ETR (if reusing keys, like at least some implementations are going to do)? I didn't see that explicitly required anywhere (this is kind of thing one wants to document). The problem if routers share keys between roles is that if two such routers connect to each other and pick the same nonces (nonce looks to be only 24 bits!) the keys will collide, with bad results. > > - AEAD_CHACHA20_POLY1305 IVs are 12 octets, right? That's too short > > to randomly generate. Instead, the encryptor should just use its > > Yes, you are right. I padded to 16-bytes in my implementation. Do > you see harm in that. That way the packet length/format doesn’t have > to change for different cipher suites. Well, no harm to have padding bits (if those are authenticated!). It is just that such padding needs to be specified. (Assuming AD for AEAD algorithms is ICV\Encrypt, those are authenticated) If you have some AEAD algo with N_MIN > 16 (I don't think any are currently defined) you could even zero-pad the IV... > > - Are the associations unidirectional (data is only ever sent one > > way) or how is uniqueness of IVs between directions handled? > > Yes, unidirectional. IVs are per packet, any packet, in any direction. Okay. That reduces IV uniqueness to ensuring each side generates unique IVs and that the keying material is direction-dependent. > > - IV is incremented for every packet? If using CBC mode, predictable > > IVs are bad (AEAD algorithms do deal with predictable IVs, but not > > repeating IVs). I mean, the document seems to say both IVs are randomly generated and incremented for every packet (which seem to be mutually contradictionary). > > - AEAD_CHACHA20_POLY1305 decryption both checks the ICV and if the > > check passes, decrypts the data. So performing step 2 also performs > > step 5. > > Hmm. So are you saying that if the cipher suite negotiated is chacha20, > we should not add a ICV? That would be great, beacuse we can make cipher > suite 4 go even faster. The encryption with AEAD algorithm presumably goes as follows: 1) The encapsulator generates IV by some method that takes very long time to repeat (counters, LFSRs, etc...) and appends it to the LISP header. 2) Invoke the AEAD encryption with: - Key set to encryption-key - Nonce set to the IV (truncated to N_MAX octets if N_MAX<16, padded with zeroes in the end to N_MIN octets if N_MIN>16). - AD set to LISP header plus added IV field (the parts of packet marked as ICV but not encrypt). - Plaintext set to the packet payload. (Any possible tag output is appended to the ciphertext) 3) Prepend the LISP header, together with the IV field into ciphertext. 4) Lastly, prepend the UDP and IP headers into the encrypted packet and send to destination RLOC. And decryption: 1) Strip the outer IP and UDP headers. 2) Strip tag encryption concatenated from packet payload (if any). 3) Invoke the AEAD decryption with: - Key set to encryption-key (from local key-cache) - Nonce set to the IV field contents (truncated to N_MAX octets if N_MAX<16, padded with zeroes in the end to N_MIN octets if N_MIN>16). - AD set to LISP header plus added IV field (the parts of packet marked as ICV but not encrypt). - Ciphertext set to the packet payload. (If the algorithm has tag input, the tag is split off from the ciphertext). If the result is FAIL, drop the packet (it is tampered with) and optionally issue a log message. 3) Strip IV from the packet. 4) Forward the packet to destination EID. The nonce truncation/padding rules are to handle AEAD algorithms that don't accept 16 octet nonces but still keep the IV on wire at constant 16 octets. There is also AEAD_AES_128_GCM, which being AEAD algorithm, is used similarly to AEAD_CHACHA20_POLY1305. The above algorithms work with it too. -Ilari From nobody Sun Nov 1 16:47:57 2015 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 7BAD51B2CE9; Tue, 20 Oct 2015 19:14:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151021021458.7620.61602.idtracker@ietfa.amsl.com> Date: Tue, 20 Oct 2015 19:14:58 -0700 Archived-At: X-Mailman-Approved-At: Sun, 01 Nov 2015 16:47:56 -0800 Cc: draft-ietf-lisp-impact.all@ietf.org, lisp-chairs@ietf.org, draft-ietf-lisp-impact@ietf.org, lisp@ietf.org Subject: [lisp] Ben Campbell's No Objection on draft-ietf-lisp-impact-04: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 02:14:58 -0000 Ben Campbell has entered the following ballot position for draft-ietf-lisp-impact-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-impact/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- It seems odd to me that an "impacts" paper would leave security impacts out of scope. Even with the detailed security considerations in draft-ietf-lisp-threats, it seems like there might be some higher-level observations to make, along the lines of the rest of the draft. Along those lines, if you want to refer to draft-ietf-lisp-threats for security considerations, it needs to be a normative reference. From nobody Sun Nov 1 16:47:58 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACAFD1A8A5A; Thu, 22 Oct 2015 08:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 R74rk7ftmcOv; Thu, 22 Oct 2015 08:08:20 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97D961A8A8B; Thu, 22 Oct 2015 08:08:20 -0700 (PDT) Received: from [10.0.1.9] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t9MF8CY8052352 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 22 Oct 2015 10:08:12 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.9] From: "Ben Campbell" To: "Luigi Iannone" Date: Thu, 22 Oct 2015 10:08:12 -0500 Message-ID: <57BE6E2E-BF06-4F3C-94BE-E4EEE487D933@nostrum.com> In-Reply-To: <2DAE09CA-B090-404C-89D6-D1EB4DA85426@gigix.net> References: <20151021021458.7620.61602.idtracker@ietfa.amsl.com> <2DAE09CA-B090-404C-89D6-D1EB4DA85426@gigix.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5141) Archived-At: X-Mailman-Approved-At: Sun, 01 Nov 2015 16:47:56 -0800 Cc: lisp-chairs@ietf.org, lisp@ietf.org, draft-ietf-lisp-impact.all@ietf.org, The IESG , draft-ietf-lisp-impact@ietf.org Subject: Re: [lisp] Ben Campbell's No Objection on draft-ietf-lisp-impact-04: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 15:08:22 -0000 Thanks, those changes would address my comments. Ben. On 22 Oct 2015, at 4:08, Luigi Iannone wrote: > Hi Ben, > >> On 21 Oct 2015, at 04:14, Ben Campbell wrote: >> > > [snip] >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> It seems odd to me that an "impacts" paper would leave security >> impacts >> out of scope. Even with the detailed security considerations in >> draft-ietf-lisp-threats, it seems like there might be some >> higher-level >> observations to make, along the lines of the rest of the draft. >> > > Yes you are right. > We proposed an updated security section in the reply to Hillarie, who > did the secdir review. > The proposed text is: > > > A thorough security and threats analysis of the LISP protocol > is carried out in details in [I-D.ietf-lisp-threats]. > Like for other Internet technologies, also for LISP most of > threats can be mitigated using Best Current Practice, meaning > with careful deployment an configuration (e.g., filter) and also > by activating only features that are really necessary in the > deployment and verifying all the information obtained from third > parties. Unless gleaning features (actually deprecated in > RFC 6830 [RFC6830]) are used, the LISP data-plane shows the > same level of security as other IP-over-IP technologies. > From a security perspective, the control-plane remains the > critical part of the LISP architecture. > To mitigate the threats on the mapping system, authentication > should be used for all control plane messages. > The current specification ([RFC6833], [I-D.ietf-lisp-sec]) > defines security > mechanisms which can reduce threats in open network environments. > The LISP specification defines a generic authentication data field > for control plane messages [RFC6830] which could be used for a > general > authentication mechanisms for the LISP control-plane while staying > backward compatible. > > > >> Along those lines, if you want to refer to draft-ietf-lisp-threats >> for >> security considerations, it needs to be a normative reference. >> >> > > Absolutely. We will move the document as normative reference. > > thanks > > Luigi From nobody Sun Nov 1 18:23:19 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C651B4262 for ; Sun, 1 Nov 2015 18:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 kJoc8u-J_jmb for ; Sun, 1 Nov 2015 18:23:04 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F30C61B4271 for ; Sun, 1 Nov 2015 18:23:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9219; q=dns/txt; s=iport; t=1446430983; x=1447640583; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=2FNOekLWw/i1UdA+fg7/9JT9GjL2McGW/ooFNV8kTRc=; b=jBrNgxQVbTb3h6AkAlo2qAaEEq+tk3Cdn0WxePA09wtvtWgyOKjehHur qy9Vq+j0dgC7mYGsvlMqEduyO35YWr3Q7hTR2KYS6h2jxda9Coo76VILU ySy9O8/Q6gbxnKHy3wH1exGx/UKquS6ijzr3lqUIUa0fEPzhnX/QBfV8F w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D2AQBcyDZW/5ldJa1UCoM7U2+sJ5MPAQ2BWhcKhXgCgSQ4FAEBAQEBAQGBCoQ1AQEBAwEBAQEgDwEFNAIKAQULCQIOBAYCAgUDEwsCAgkDAgECARUiDgYNBgIBAReIDQgNkyidN5BUAQEBAQEBAQEBAQEBAQEBAQEBARYEgSKFVYN4gQaEMwUGAQGDO4FFBY4QiDONJYFZhD+DAY8vg3IfAQFCghYYgWUvNIQ1CBeBKgEBAQ X-IronPort-AV: E=Sophos;i="5.20,232,1444694400"; d="scan'208";a="203888433" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-5.cisco.com with ESMTP; 02 Nov 2015 02:23:02 +0000 Received: from [10.24.80.25] ([10.24.80.25]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tA22N03i008118; Mon, 2 Nov 2015 02:23:01 GMT To: Luigi Iannone References: <561D7D55.3090305@cisco.com> <3C8EF5A4-B81B-45DB-ACF4-20F9A4A9E625@gigix.net> <561E7448.7080209@cisco.com> From: Fabio Maino Message-ID: <5636C906.7010101@cisco.com> Date: Mon, 2 Nov 2015 11:23:02 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: lisp@ietf.org Subject: Re: [lisp] Draft of new Proposed Charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 02 Nov 2015 02:23:09 -0000 On 10/15/15 6:41 PM, Luigi Iannone wrote: > Hi Fabio, > >> On 14 Oct 2015, at 17:27, Fabio Maino wrote: >> >> On 10/14/15 1:23 AM, Luigi Iannone wrote: >>> Hi Fabio, >>> >>> thanks for the feedback. >>> Are you saying that the scope of the proposed chart is too large? >> No, I think the scope is very appropriate. I was just suggesting that we use those two use cases to drive the design decisions. >> >> There are clearly many more use cases that a LISP overlay can be used for, but in my opinion those two are well understood and will help focusing the group on the protocol work that you have identified. I selected those two, and articulated them in that way, exactly because they can cover the whole scope of the outlined work. >> >> If we include those two use cases in the charter, probably it should also mention that those are not the only ones, but are used to drive the design. >> > I kind of confused here. You agree that there is the right scope in the proposed charter but that is lacking use-cases. > > I would prefer having a charter that states what we are working on, not where our work can/will be applied. > > If people are interested in use-cases, it is possible to add a use-case document where we document where the work can be used. > > Would people be happy with such type of solution? Sorry for getting to this only now, Luigi. I am suggesting to use the two use cases as a way to drive/justify requirements. I think they are well understood, and can provide a guide for the WG to prioritize what to do first. I don't want to limit LISP use to those two use cases only. Rather than having a single document encompassing all use cases (that will never be complete), I think it might be useful to allow the WG to adopt use cases documents as guide to the extensions needed. > > > >>> From what I see in your mail I would say that the proposed charter covers all of your work items (with the exception of the programmatic northbound access to the mapping). >> Yes. I think the SDN angle is very important for an overlay, and may drive very relevant components of the architecture. The text you posted does refers to YANG modeling, that is one component of programmability, but I would like to see this requirement more explicit, particularly for the mapping system. >> >> I believe LISP, with the clean separation of the forwarding function provided by the mapping system, can play a key role in controller-based SDN applications. Again, it's not the only way to use LISP, but I think it's an opportunity that the WG should pick up. >> >> > I would prefer that in the charter we refer only to IETF work. This means avoiding acronyms like SDN. First because it is a I_R_TF work, second because SDN way too large. It means different things for different people, so I am unsure on whether it helps in defining a clear scope for our work. Luigi, I have not used "SDN" in the actual wording I suggested for the use cases. I referred to "programmatic northbound access to the mapping and to xTR configuration", exactly to avoid to be too generic. > YANG is different, because it is clearly an IETF effort and is something that we have anyway to consider. > > Yet, you can always propose some text to help in give a better scope to the proposed charter. The second part of the sentence above provides motivation for YANG data modeling of the xTR, the first part of the sentence helps understanding why we may need pub/sub and other extensions to the protocol as currently defined. Without specifying what we want to solve it's hard to explain why we want to make some extensions to the protocol. Thanks, Fabio > > ciao > > L. > > > >> Thanks, >> Fabio >> >> >> >>> Or I am misunderstanding your comment? >>> >>> ciao >>> >>> L. >>> >>> >>>> On 13 Oct 2015, at 23:53, Fabio Maino wrote: >>>> >>>> Joel, Luigi, >>>> thanks for taking a stab at this one. >>>> >>>> I think it covers the relevant aspects that I would like to see the WG to focus on. >>>> >>>> As discussed in the use case thread, I would suggest that the draft should mention a very small set of use cases that we can use to drive the design decisions. I think that we can possibly cover all of the protocol aspects you describe if we take the following two use cases: >>>> 1) LISP-based programmable L2/L3 VPNs with extensions to support the following services: >>>> - encryption >>>> - programmatic northbound access to the mapping and to xTR configuration >>>> - SFC/NFV >>>> - VPN termination on mobile nodes >>>> 2) LISP-based programmable L2/L3 VPNs for DC applications >>>> >>>> I think these two will give a good scope to the WG work and, without resorting to more exotic use cases, reinforce the focus on the use of LISP as an overlay technology. >>>> >>>> Thanks, >>>> Fabio >>>> >>>> >>>> >>>> On 10/13/15 1:30 PM, Luigi Iannone wrote: >>>>> Folks, >>>>> >>>>> in the past weeks (and months) there was a fruitful discussion that took place on the mailing list (and also in Prague) concerning >>>>> the new charter to be adopted by our WG. Thanks for this effort. >>>>> >>>>> Beside this discussion we had proposals from WG members as well as discussion with our AD about what is practical and reasonable. >>>>> Hereafter you can find the result: a draft of the new proposed charter. >>>>> >>>>> This does not mean that discussion is over, rather that we reached a first consistent milestone for further discussion. >>>>> Discussion ideally culminating in our meeting in Japan. >>>>> >>>>> So please have look and send your thoughts and feedback to the mailing list. >>>>> >>>>> Joel and Luigi >>>>> >>>>> %—————————————————————————————————————————————————% >>>>> The LISP WG has completed the first set of Experimental RFCs >>>>> describing the Locator/ID Separation Protocol (LISP). LISP supports >>>>> a routing architecture which decouples the routing locators and >>>>> identifiers, thus allowing for efficient aggregation of the routing locator >>>>> space and providing persistent identifiers in the identifier space. >>>>> LISP requires no changes to end-systems or to routers that do not >>>>> directly participate in the LISP deployment. LISP aims for an >>>>> incrementally deployable protocol. The scope of the LISP >>>>> technology is recognized to range from programmable overlays, >>>>> at Layer 2 as well as at Layer 3, including NAT traversal, and >>>>> supporting mobility as a general feature, independently of whether >>>>> it is a mobile user or a migrating VM, hence being applicable in both >>>>> Data Centers and public Internet environments. >>>>> >>>>> The LISP WG is chartered to continue work on the LISP base protocol >>>>> with the main objective to develop a standard solution based on the >>>>> completed Experimental RFCs and the experience gained from early >>>>> deployments. >>>>> This work will include reviewing the existing set of Experimental RFCs >>>>> and doing the necessary enhancements to support a base set of >>>>> standards track RFCs. The group will review the current set of Working >>>>> Group documents to identify potential standards-track documents and >>>>> do the necessary enhancements to support standards-track. It is >>>>> recognized that some of the work will continue on the experimental track, >>>>> though the group is encouraged to move the documents to standards >>>>> track in support of network use, whereas the work previously was >>>>> scoped to research studies. >>>>> >>>>> Beside this main focus, the LISP WG may work on the following items: >>>>> >>>>> • NAT-Traversal >>>>> • Mobility >>>>> • Data-Plane Encryption >>>>> • Multicast: Support for overlay multicast by means of replication >>>>> as well as interfacing with existing underlay multicast support. >>>>> • YANG Data models for management of LISP. >>>>> • Multi-protocol support: Specifying the required extensions to support >>>>> multi-protocol encapsulation (e.g., L2 or NSH – Network Service >>>>> Headers). Rather than developing new encapsulations, the work will >>>>> aim at using existing well-established encapsulations or emerging >>>>> from other Working Groups such as NVO3 and SFC. >>>>> • Alternative Mapping System Design: When extending LISP to support >>>>> new protocols,it may be also necessary to develop the related mapping >>>>> function extensions to operate LISP map-assisted networks (which >>>>> might include Hierarchical Pull, Publish/Subscribe, or Push models >>>>> and related security extensions). >>>>> >>>>> _______________________________________________ >>>>> 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 From nobody Sun Nov 1 18:29:09 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1ECB1ACECE for ; Sun, 1 Nov 2015 18:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 3t3VUGuIxhi7 for ; Sun, 1 Nov 2015 18:29:05 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E12A1ACEC2 for ; Sun, 1 Nov 2015 18:29:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8982; q=dns/txt; s=iport; t=1446431345; x=1447640945; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=K23Aa0WBCVeCF8eClhKYRaRAQ+01+eLntfQqcHsU5TU=; b=PD69fWNYBA9Sf+z6bMSowGCyBXxxMhcXeSwymiW/E8Ro6fKBRZJQrQrC z/+tDqL4e6ZBZsw0iZW+wn+1FgTxmbXHbswQK2dtmr8PZWtA0zq/6UyIZ jz2VN/lD1gZ4+raoqViIwofWmvuW7CP+/cQggjyCzaV4XsqAcgk1ocM+0 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D2AQC2yTZW/5pdJa1UCoM7U2+/NgENgVoXCoV4AoEkOBQBAQEBAQEBgQqENQEBAQMBAQEBIA8BBTQCCgEQCQIOBAYCAgUDEwsCAgkDAgECAQ8GIg4GAQwGAgEBF4gAAwoIDZMpnTeMBQ2EQgEBAQEBAQEBAQEBAQEBAQEBAQEBARQEgSKFVYR+glOBWgYKAgGDO4FFAQSOEIgziy+BdoFZhD+DAYtQg1+Dch8BAUKCFhiBZS80hX4BAQE X-IronPort-AV: E=Sophos;i="5.20,232,1444694400"; d="scan'208";a="204001891" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP; 02 Nov 2015 02:29:04 +0000 Received: from [10.24.80.25] ([10.24.80.25]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id tA22T2sK002752; Mon, 2 Nov 2015 02:29:03 GMT To: Luigi Iannone , Sharon References: <561D7D55.3090305@cisco.com> <3C8EF5A4-B81B-45DB-ACF4-20F9A4A9E625@gigix.net> <561E7448.7080209@cisco.com> From: Fabio Maino Message-ID: <5636CA70.5090308@cisco.com> Date: Mon, 2 Nov 2015 11:29:04 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: lisp@ietf.org Subject: Re: [lisp] Draft of new Proposed Charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 02 Nov 2015 02:29:08 -0000 On 10/15/15 6:52 PM, Luigi Iannone wrote: > Hi Sharon, > >> On 14 Oct 2015, at 20:28, Sharon wrote: >> >> We could say that as we completed a set of experimental lisp rfcs the importance of connectionless logical services networks overlaying and or anchoring topological IP networks grew significantly. >> >> To accommodate we continue to evolve the unique lisp map-assisted overlay architecture characteristics along the following lines: >> - traversal, schemas, chaining… > Thanks the above observation can be converted to text for the new charter. Let me think a bit the way to do it. >> etc >> >> We evolve these lisp aspects and examine their applicability by matching and testing them vis-a-vis key example use-cases: >> - VPN virtual logical private services networks >> - NFV virtualization of functions from junctions >> - DMM distributed (floating-anchors) mobility >> > References to VPN and DMM can be added, since this is IETF work. > > For NFV, is I have the same comment as for SDN. It looks to me that in this way we make scope more fuzzy rather than clear. Moreover, like for SDN, this is IRTF work. As I mentioned in the previous email I think that "programmatic northbound access to the mapping and to xTR configuration" should be addressed by LISP WG and not by IRTF. Maybe to address what Sharon suggests for NFV we need to articulate in a similar way the requirements that may enable NFV. SFC provides some of that context, I don't knwo if it is all what is needed though. Thanks, Fabio > > ciao > > L. > > > >> --szb >> >>> On Oct 14, 2015, at 8:27 AM, Fabio Maino wrote: >>> >>>> On 10/14/15 1:23 AM, Luigi Iannone wrote: >>>> Hi Fabio, >>>> >>>> thanks for the feedback. >>>> Are you saying that the scope of the proposed chart is too large? >>> No, I think the scope is very appropriate. I was just suggesting that we use those two use cases to drive the design decisions. >>> >>> There are clearly many more use cases that a LISP overlay can be used for, but in my opinion those two are well understood and will help focusing the group on the protocol work that you have identified. I selected those two, and articulated them in that way, exactly because they can cover the whole scope of the outlined work. >>> >>> If we include those two use cases in the charter, probably it should also mention that those are not the only ones, but are used to drive the design. >>> >>>> From what I see in your mail I would say that the proposed charter covers all of your work items (with the exception of the programmatic northbound access to the mapping). >>> Yes. I think the SDN angle is very important for an overlay, and may drive very relevant components of the architecture. The text you posted does refers to YANG modeling, that is one component of programmability, but I would like to see this requirement more explicit, particularly for the mapping system. >>> >>> I believe LISP, with the clean separation of the forwarding function provided by the mapping system, can play a key role in controller-based SDN applications. Again, it's not the only way to use LISP, but I think it's an opportunity that the WG should pick up. >>> >>> >>> >>> Thanks, >>> Fabio >>> >>> >>> >>>> Or I am misunderstanding your comment? >>>> >>>> ciao >>>> >>>> L. >>>> >>>> >>>>> On 13 Oct 2015, at 23:53, Fabio Maino wrote: >>>>> >>>>> Joel, Luigi, >>>>> thanks for taking a stab at this one. >>>>> >>>>> I think it covers the relevant aspects that I would like to see the WG to focus on. >>>>> >>>>> As discussed in the use case thread, I would suggest that the draft should mention a very small set of use cases that we can use to drive the design decisions. I think that we can possibly cover all of the protocol aspects you describe if we take the following two use cases: >>>>> 1) LISP-based programmable L2/L3 VPNs with extensions to support the following services: >>>>> - encryption >>>>> - programmatic northbound access to the mapping and to xTR configuration >>>>> - SFC/NFV >>>>> - VPN termination on mobile nodes >>>>> 2) LISP-based programmable L2/L3 VPNs for DC applications >>>>> >>>>> I think these two will give a good scope to the WG work and, without resorting to more exotic use cases, reinforce the focus on the use of LISP as an overlay technology. >>>>> >>>>> Thanks, >>>>> Fabio >>>>> >>>>> >>>>> >>>>>> On 10/13/15 1:30 PM, Luigi Iannone wrote: >>>>>> Folks, >>>>>> >>>>>> in the past weeks (and months) there was a fruitful discussion that took place on the mailing list (and also in Prague) concerning >>>>>> the new charter to be adopted by our WG. Thanks for this effort. >>>>>> >>>>>> Beside this discussion we had proposals from WG members as well as discussion with our AD about what is practical and reasonable. >>>>>> Hereafter you can find the result: a draft of the new proposed charter. >>>>>> >>>>>> This does not mean that discussion is over, rather that we reached a first consistent milestone for further discussion. >>>>>> Discussion ideally culminating in our meeting in Japan. >>>>>> >>>>>> So please have look and send your thoughts and feedback to the mailing list. >>>>>> >>>>>> Joel and Luigi >>>>>> >>>>>> %—————————————————————————————————————————————————% >>>>>> The LISP WG has completed the first set of Experimental RFCs >>>>>> describing the Locator/ID Separation Protocol (LISP). LISP supports >>>>>> a routing architecture which decouples the routing locators and >>>>>> identifiers, thus allowing for efficient aggregation of the routing locator >>>>>> space and providing persistent identifiers in the identifier space. >>>>>> LISP requires no changes to end-systems or to routers that do not >>>>>> directly participate in the LISP deployment. LISP aims for an >>>>>> incrementally deployable protocol. The scope of the LISP >>>>>> technology is recognized to range from programmable overlays, >>>>>> at Layer 2 as well as at Layer 3, including NAT traversal, and >>>>>> supporting mobility as a general feature, independently of whether >>>>>> it is a mobile user or a migrating VM, hence being applicable in both >>>>>> Data Centers and public Internet environments. >>>>>> >>>>>> The LISP WG is chartered to continue work on the LISP base protocol >>>>>> with the main objective to develop a standard solution based on the >>>>>> completed Experimental RFCs and the experience gained from early >>>>>> deployments. >>>>>> This work will include reviewing the existing set of Experimental RFCs >>>>>> and doing the necessary enhancements to support a base set of >>>>>> standards track RFCs. The group will review the current set of Working >>>>>> Group documents to identify potential standards-track documents and >>>>>> do the necessary enhancements to support standards-track. It is >>>>>> recognized that some of the work will continue on the experimental track, >>>>>> though the group is encouraged to move the documents to standards >>>>>> track in support of network use, whereas the work previously was >>>>>> scoped to research studies. >>>>>> >>>>>> Beside this main focus, the LISP WG may work on the following items: >>>>>> >>>>>> • NAT-Traversal >>>>>> • Mobility >>>>>> • Data-Plane Encryption >>>>>> • Multicast: Support for overlay multicast by means of replication >>>>>> as well as interfacing with existing underlay multicast support. >>>>>> • YANG Data models for management of LISP. >>>>>> • Multi-protocol support: Specifying the required extensions to support >>>>>> multi-protocol encapsulation (e.g., L2 or NSH – Network Service >>>>>> Headers). Rather than developing new encapsulations, the work will >>>>>> aim at using existing well-established encapsulations or emerging >>>>>> from other Working Groups such as NVO3 and SFC. >>>>>> • Alternative Mapping System Design: When extending LISP to support >>>>>> new protocols,it may be also necessary to develop the related mapping >>>>>> function extensions to operate LISP map-assisted networks (which >>>>>> might include Hierarchical Pull, Publish/Subscribe, or Push models >>>>>> and related security extensions). >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp From nobody Sun Nov 1 18:36:10 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95EFF1AD359 for ; Sun, 1 Nov 2015 18:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 k6azs2STe5I5 for ; Sun, 1 Nov 2015 18:36:07 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 299E61AD2D9 for ; Sun, 1 Nov 2015 18:36:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7718; q=dns/txt; s=iport; t=1446431767; x=1447641367; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=vajaQvjDHAr4cRaGCv+3QORRERdi9wCyK1bi/kdvm6c=; b=EO0MNDsyyVKtgX+/jwTl9KNdHYZzE8uOwZohUTT6Ntv0bLQYDHuPlpy/ DHUquE1Cdmg8IDuJcu+pQmfxLW8B1BVb5UHOY4NvixzpM/g49YqAENOqn EpdI2+G/e80Jmq/KLIrmPsziEeviwMyKcyKMTvr0CaRacrrnI/imr3ZnO M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D1AQCJyjZW/4MNJK1UCoM7U2+/NgENgVoXCoV4AoElOBQBAQEBAQEBgQqENQEBAQMBAQEBIA8BBTQCCgYLCQISBgICBQMTCwICCQMCAQIBFSIOEwYCAQEXiA0IDZMinTeQVAEBAQEGAQEBARsEgSKFVYR+hDODSIFFBY4QiDONJYFZhD+DAY8vg3IfAQFCghEFGIFlLzSFfgEBAQ X-IronPort-AV: E=Sophos;i="5.20,232,1444694400"; d="scan'208";a="204201115" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Nov 2015 02:36:06 +0000 Received: from [10.24.80.25] ([10.24.80.25]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id tA22a5E7020474 for ; Mon, 2 Nov 2015 02:36:05 GMT To: lisp@ietf.org References: <561D7D55.3090305@cisco.com> From: Fabio Maino Message-ID: <5636CC17.8080601@cisco.com> Date: Mon, 2 Nov 2015 11:36:07 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lisp] Draft of new Proposed Charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 02 Nov 2015 02:36:09 -0000 On 10/15/15 7:10 AM, Albert Cabellos wrote: > Hi Luigi > > Please see my comments inline: > > On Wed, Oct 14, 2015 at 1:31 AM, Luigi Iannone wrote: > > [snip] > >> Having design guidelines does not forcedly mean having a programmatic language approach. Right? >> >> In your opinion could well defined guidelines (not language) be added to the current LCAF document? > I am unsure if we can do this without ending up reproducing some sort > of language, we´ll start by defining scalar data-types, then complex > data-types (combinations of scalars), then data-structures, then > encoding mechanisms for each scalar and each data-structure and so on. > > This could be as simple as defining an encoding mechanisms for YANG > (XMLBIN with some sort of compression). I am not stating that we > should go this precise way, what I am stating is that LCAF is rigid > and, if a new use-case is not defined as an LCAF, it can´t be deployed > in a standard way. A language could solve this issue and make the LISP > control plane truly flexible. > >>> to define new ones. A flexible language with a clear >>> syntax would ease deployment of new use-cases both at the data and >>> control plane. >> How much relevant and with what priority is this for the WG? ( _NOTE_ this question is for the whole WG not just for Albert…) >> I think it might be interesting to explore the options the we might have here. While we expand the scope of LISP beyond mapping EID to RLOCs (see the LISP/NSH draft as an example), we'll indeed have to deal with a bunch of new LCAF types. A language might help to keep focus on the semantic, rather than on the syntax of allocating bits. I see no harm in including this work with the goal to write an experimental RFC. Fabio > me too :) > > Albert > >>> Maybe this could be done as experimental (not >>> standard). >> _if_ the WG decides to take on this work it would very reasonable to go for experimental. >> >> ciao >> >> L. >> >> >>> Albert >>> >>> >>> On Tue, Oct 13, 2015 at 2:53 PM, Fabio Maino wrote: >>>> Joel, Luigi, >>>> thanks for taking a stab at this one. >>>> >>>> I think it covers the relevant aspects that I would like to see the WG to focus on. >>>> >>>> As discussed in the use case thread, I would suggest that the draft should mention a very small set of use cases that we can use to drive the design decisions. I think that we can possibly cover all of the protocol aspects you describe if we take the following two use cases: >>>> 1) LISP-based programmable L2/L3 VPNs with extensions to support the following services: >>>> - encryption >>>> - programmatic northbound access to the mapping and to xTR configuration >>>> - SFC/NFV >>>> - VPN termination on mobile nodes >>>> 2) LISP-based programmable L2/L3 VPNs for DC applications >>>> >>>> I think these two will give a good scope to the WG work and, without resorting to more exotic use cases, reinforce the focus on the use of LISP as an overlay technology. >>>> >>>> Thanks, >>>> Fabio >>>> >>>> >>>> >>>> >>>> On 10/13/15 1:30 PM, Luigi Iannone wrote: >>>>> Folks, >>>>> >>>>> in the past weeks (and months) there was a fruitful discussion that took place on the mailing list (and also in Prague) concerning >>>>> the new charter to be adopted by our WG. Thanks for this effort. >>>>> >>>>> Beside this discussion we had proposals from WG members as well as discussion with our AD about what is practical and reasonable. >>>>> Hereafter you can find the result: a draft of the new proposed charter. >>>>> >>>>> This does not mean that discussion is over, rather that we reached a first consistent milestone for further discussion. >>>>> Discussion ideally culminating in our meeting in Japan. >>>>> >>>>> So please have look and send your thoughts and feedback to the mailing list. >>>>> >>>>> Joel and Luigi >>>>> >>>>> %—————————————————————————————————————————————————% >>>>> The LISP WG has completed the first set of Experimental RFCs >>>>> describing the Locator/ID Separation Protocol (LISP). LISP supports >>>>> a routing architecture which decouples the routing locators and >>>>> identifiers, thus allowing for efficient aggregation of the routing locator >>>>> space and providing persistent identifiers in the identifier space. >>>>> LISP requires no changes to end-systems or to routers that do not >>>>> directly participate in the LISP deployment. LISP aims for an >>>>> incrementally deployable protocol. The scope of the LISP >>>>> technology is recognized to range from programmable overlays, >>>>> at Layer 2 as well as at Layer 3, including NAT traversal, and >>>>> supporting mobility as a general feature, independently of whether >>>>> it is a mobile user or a migrating VM, hence being applicable in both >>>>> Data Centers and public Internet environments. >>>>> >>>>> The LISP WG is chartered to continue work on the LISP base protocol >>>>> with the main objective to develop a standard solution based on the >>>>> completed Experimental RFCs and the experience gained from early >>>>> deployments. >>>>> This work will include reviewing the existing set of Experimental RFCs >>>>> and doing the necessary enhancements to support a base set of >>>>> standards track RFCs. The group will review the current set of Working >>>>> Group documents to identify potential standards-track documents and >>>>> do the necessary enhancements to support standards-track. It is >>>>> recognized that some of the work will continue on the experimental track, >>>>> though the group is encouraged to move the documents to standards >>>>> track in support of network use, whereas the work previously was >>>>> scoped to research studies. >>>>> >>>>> Beside this main focus, the LISP WG may work on the following items: >>>>> >>>>> • NAT-Traversal >>>>> • Mobility >>>>> • Data-Plane Encryption >>>>> • Multicast: Support for overlay multicast by means of replication >>>>> as well as interfacing with existing underlay multicast support. >>>>> • YANG Data models for management of LISP. >>>>> • Multi-protocol support: Specifying the required extensions to support >>>>> multi-protocol encapsulation (e.g., L2 or NSH – Network Service >>>>> Headers). Rather than developing new encapsulations, the work will >>>>> aim at using existing well-established encapsulations or emerging >>>>> from other Working Groups such as NVO3 and SFC. >>>>> • Alternative Mapping System Design: When extending LISP to support >>>>> new protocols,it may be also necessary to develop the related mapping >>>>> function extensions to operate LISP map-assisted networks (which >>>>> might include Hierarchical Pull, Publish/Subscribe, or Push models >>>>> and related security extensions). >>>>> >>>>> _______________________________________________ >>>>> 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 >>> _______________________________________________ >>> 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 From nobody Sun Nov 1 20:42:53 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44711B29E7 for ; Sun, 1 Nov 2015 20:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, J_BACKHAIR_52=1, SPF_PASS=-0.001] autolearn=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 J2kBxIJMLlJy for ; Sun, 1 Nov 2015 20:42:49 -0800 (PST) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::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 E6DEF1B29D0 for ; Sun, 1 Nov 2015 20:42:48 -0800 (PST) Received: by pacfv9 with SMTP id fv9so141467341pac.3 for ; Sun, 01 Nov 2015 20:42:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+fXQ9Lh+Wq90/Mk+rhfvVWLSlsdgskGff2AHXfdM3TA=; b=T9/yRyI7nlbNH8h0bHlOhwPfJGxm1w3S1bO8CIFULRFl3TGUmKlwfUQM68a6YLFUfA 6J1iuHM0i3ggD3UDEBksRqinj8YSDXVEqJUBwuGSliUzpmW8LiyMtM2OlmDLEsvbO4iz AfwH0MyOzCZCmi2eFMqUlObqx97OKADV9a3orz0J67p28Kujb8GR4foVdFUD3O4vT0Oi HTqTHT5ngrcAmhoIHDizwFDJ3pVDZ9feWKmIZJv/RvrK+vDcgTcj0SyHGkmTPDzVvskp ed/pexYxUFbUgHZhiXo8oRmglzG8dMpuSxIQhfEuwMZrh2Dbgra4Y5GvpaVW8KDK+B+L oGJQ== X-Received: by 10.66.90.137 with SMTP id bw9mr24683366pab.112.1446439368569; Sun, 01 Nov 2015 20:42:48 -0800 (PST) Received: from t20010c4000003080a5075e44c098b11a.v6.meeting.ietf94.jp (t20010c4000003080a5075e44c098b11a.v6.meeting.ietf94.jp. [2001:c40:0:3080:a507:5e44:c098:b11a]) by smtp.gmail.com with ESMTPSA id mk5sm21210919pab.44.2015.11.01.20.42.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Nov 2015 20:42:47 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Dino Farinacci In-Reply-To: <20151101095325.GB13377@LK-Perkele-V2.elisa-laajakaista.fi> Date: Sun, 1 Nov 2015 20:42:44 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0A35A9D5-B44E-4A00-B680-8B3599575E2C@gmail.com> References: <20151028141703.GA9632@LK-Perkele-V2.elisa-laajakaista.fi> <1C855BE8-70D6-4604-AFED-4298AAD6186C@gmail.com> <20151101095325.GB13377@LK-Perkele-V2.elisa-laajakaista.fi> To: Ilari Liusvaara X-Mailer: Apple Mail (2.2104) Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] Let's review crypto in lisp-crypto X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 02 Nov 2015 04:42:51 -0000 > On Sun, Nov 01, 2015 at 01:13:56AM -0700, Dino Farinacci wrote: >>=20 >>> - Ciphersuite 1 uses 1024-bit Diffie-Hellman, which is too weak >>> (after you have cracked one key (and it doesn't take that much, >>> especially if you can throw ASICs at the problem), you can crack >>> each subsequent one in a few CPU minutes. With 2048-bit DH, at >>> least the first key tends to be too hard, and with ECDH, tricks >>> like this don't work). >>=20 >> Yes, both Brian and I replied that we were using this more for >> experimentation on low-powered or CPU challenged devices. We will >> not recommend its use. It=E2=80=99s just there for implementations to = start >> with something. But havind said that, I would like to recommend >> the smaller keys that come along with chacha20/poly1305 so maybe >> the subject is moot.=20 >=20 > I think that even having low-security options is a problem. How about we change the Cipher Suite definitions TO this (and address = multiple of your comments): Cipher Suite 0: Reserved Cipher Suite 1: Diffie-Hellman Group: 2048-bit MODP [RFC3526] Encryption: AES with 128-bit keys in GCM mode [AES-GCM] Integrity: HMAC-SHA1-96 [RFC2404] Cipher Suite 2: Diffie-Hellman Group: 3072-bit MODP [RFC3526] Encryption: AES with 128-bit keys in GCM mode [AES-GCM] Integrity: HMAC-SHA1-96 [RFC2404] Cipher Suite 3: Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519] Encryption: AES with 128-bit keys in GCM mode [AES-GCM] Integrity: HMAC-SHA1-96 [RFC2404] Cipher Suite 4: Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519] Encryption: Chacha20-Poly1305 [CHACHA-POLY] Integrity: Covered under Encryption Algorithm Please ack before we take action. And would like Brian (or anyone else = in the WG) to weigh in on this as well. >=20 >>> - The NIST SP800-108 KDF handles the counter and length internally, >>> those are not part of the context input. >>=20 >> You should point to text so we know where in the spec you are >> commenting against. It is hard to get context from your comments. >=20 > Section 5 in -02. The listing for "Context" (meaning the fields > in context). I think we are saying we are building a context similar to the NIST = standard but not using it. Brian needs to comment here. > - If you need identifier for association (e.g. for displaying to >>> admin for authentication purposes), you must hash in the (EC)DH >>> public keys used into the identifier. Otherwise MITM attacker can >>> defeat the authentication. >>=20 >> We use the source RLOC and the Map-Request nonce to identify the = association. >=20 > That's does not create identifier suitable for comparing between > endpoints for authentication. LISP-SEC is used as well. See the Security Considerations section. I = think we have this covered. >> - If the same system can be ITR and ETR at once, how one ensures that >>> if two such systems establish associations to each other, the keys >>> won't wind up being the same? This could be solved by requiring >>=20 >> Because the key-pair is unidirectional. If router A is an ITR and = sends >> a Map-Request to router B, that key-pair is for data traffic = encapsulated >> from A to B. If B is an ITR encapsulating to A an ETR, a differne >> key-pair is used. A new random number generator, nonce, and key >> exchange is performed for each direction. >=20 > You mean that A (and B) is supposed to use different DH keys for > their roles as ITR and ETR (if reusing keys, like at least some > implementations are going to do)? Yes, that is the way we described it by talking about encryption = unidirectionally from ITR to ETR. > I didn't see that explicitly required anywhere (this is kind of > thing one wants to document). It is implied and is rather clear I think. Wondering why you didn=E2=80=99= t see that. Maybe your unfamiliarity with LISP? > The problem if routers share keys between roles is that if two > such routers connect to each other and pick the same nonces (nonce > looks to be only 24 bits!) the keys will collide, with bad > results. They DO NOT do this. The DH keys and nonces are WITHIN the functionality = of ITR versus ETR. >=20 >>> - AEAD_CHACHA20_POLY1305 IVs are 12 octets, right? That's too short >>> to randomly generate. Instead, the encryptor should just use its >>=20 >> Yes, you are right. I padded to 16-bytes in my implementation. Do >> you see harm in that. That way the packet length/format doesn=E2=80=99t= have >> to change for different cipher suites. >=20 > Well, no harm to have padding bits (if those are authenticated!). It > is just that such padding needs to be specified. We will make that change to the spec. > (Assuming AD for AEAD algorithms is ICV\Encrypt, those are > authenticated) >=20 > If you have some AEAD algo with N_MIN > 16 (I don't think any are > currently defined) you could even zero-pad the IV=E2=80=A6 Right now we don=E2=80=99t. But the spec says the IV size is based on = the cipher suite negotiated. So we really don=E2=80=99t have to pad for = chacha, we can just have an IV of 12 bytes. So written, it is correct. = It is just my implementation that is padding. I can change the = implementation (much easier than changing specs LOL). >>> - Are the associations unidirectional (data is only ever sent one >>> way) or how is uniqueness of IVs between directions handled? >>=20 >> Yes, unidirectional. IVs are per packet, any packet, in any = direction. >=20 > Okay. That reduces IV uniqueness to ensuring each side generates > unique IVs and that the keying material is direction-dependent. Right. > - IV is incremented for every packet? If using CBC mode, predictable >>> IVs are bad (AEAD algorithms do deal with predictable IVs, but not >>> repeating IVs). >=20 > I mean, the document seems to say both IVs are randomly generated and > incremented for every packet (which seem to be mutually > contradictionary). I see. We can do one versus the other. That is, use random IVs. Is that = okay? >> - AEAD_CHACHA20_POLY1305 decryption both checks the ICV and if the >>> check passes, decrypts the data. So performing step 2 also performs >>> step 5. >>=20 >> Hmm. So are you saying that if the cipher suite negotiated is = chacha20, >> we should not add a ICV? That would be great, beacuse we can make = cipher >> suite 4 go even faster. >=20 > The encryption with AEAD algorithm presumably goes as follows: >=20 > 1) The encapsulator generates IV by some method that takes very long > time to repeat (counters, LFSRs, etc...) and appends it to the LISP > header. >=20 > 2) Invoke the AEAD encryption with: > - Key set to encryption-key > - Nonce set to the IV (truncated to N_MAX octets if N_MAX<16, padded > with zeroes in the end to N_MIN octets if N_MIN>16). > - AD set to LISP header plus added IV field (the parts of packet = marked > as ICV but not encrypt). > - Plaintext set to the packet payload. Yes, that is what we do. > (Any possible tag output is appended to the ciphertext) >=20 > 3) Prepend the LISP header, together with the IV field into = ciphertext. >=20 > 4) Lastly, prepend the UDP and IP headers into the encrypted packet > and send to destination RLOC. Yep, exactly what I think we stated. Thanks for clarification. > And decryption: >=20 > 1) Strip the outer IP and UDP headers. >=20 > 2) Strip tag encryption concatenated from packet payload (if any). >=20 > 3) Invoke the AEAD decryption with: > - Key set to encryption-key (from local key-cache) > - Nonce set to the IV field contents (truncated to N_MAX octets if > N_MAX<16, padded with zeroes in the end to N_MIN octets if N_MIN>16). > - AD set to LISP header plus added IV field (the parts of packet = marked > as ICV but not encrypt). > - Ciphertext set to the packet payload. But we don=E2=80=99t use the data-plane nonce for this. Because it may = be used for other LISP data-plane features. We use the control-plane = nonce which doesn=E2=80=99t show up on the network very often (only when = Map-Requests and returning Map-Replies are sent). So this is better for = security. > (If the algorithm has tag input, the tag is split off from the > ciphertext). >=20 > If the result is FAIL, drop the packet (it is tampered with) and > optionally issue a log message. We do that with the ICV check. > 3) Strip IV from the packet. >=20 > 4) Forward the packet to destination EID. I don=E2=80=99t think we are not doing what you say, but you are just = using different language. Please confirm. > The nonce truncation/padding rules are to handle AEAD algorithms > that don't accept 16 octet nonces but still keep the IV on > wire at constant 16 octets. >=20 > There is also AEAD_AES_128_GCM, which being AEAD algorithm, is used > similarly to AEAD_CHACHA20_POLY1305. The above algorithms work with > it too. Does that mean we don=E2=80=99t need an ICV if we used AES-GCM? Similar = to your chacha20-poloy1305 comment? Dino From nobody Mon Nov 2 02:39:56 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6C41A1BC8 for ; Mon, 2 Nov 2015 02:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_52=1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 GSMLhtnBZdss for ; Mon, 2 Nov 2015 02:39:51 -0800 (PST) Received: from filtteri2.pp.htv.fi (filtteri2.pp.htv.fi [213.243.153.185]) by ietfa.amsl.com (Postfix) with ESMTP id 229C61A1BB0 for ; Mon, 2 Nov 2015 02:39:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by filtteri2.pp.htv.fi (Postfix) with ESMTP id DA30D19C68A; Mon, 2 Nov 2015 12:39:49 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp5.welho.com ([213.243.153.39]) by localhost (filtteri2.pp.htv.fi [213.243.153.185]) (amavisd-new, port 10024) with ESMTP id EuX-uwNjezJ3; Mon, 2 Nov 2015 12:39:49 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp5.welho.com (Postfix) with ESMTPSA id A18415BC006; Mon, 2 Nov 2015 12:39:49 +0200 (EET) Date: Mon, 2 Nov 2015 12:39:46 +0200 From: Ilari Liusvaara To: Dino Farinacci Message-ID: <20151102103946.GA4014@LK-Perkele-V2.elisa-laajakaista.fi> References: <20151028141703.GA9632@LK-Perkele-V2.elisa-laajakaista.fi> <1C855BE8-70D6-4604-AFED-4298AAD6186C@gmail.com> <20151101095325.GB13377@LK-Perkele-V2.elisa-laajakaista.fi> <0A35A9D5-B44E-4A00-B680-8B3599575E2C@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0A35A9D5-B44E-4A00-B680-8B3599575E2C@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] Let's review crypto in lisp-crypto X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 02 Nov 2015 10:39:53 -0000 On Sun, Nov 01, 2015 at 08:42:44PM -0800, Dino Farinacci wrote: > > > On Sun, Nov 01, 2015 at 01:13:56AM -0700, Dino Farinacci wrote: > >> > >>> - Ciphersuite 1 uses 1024-bit Diffie-Hellman, which is too weak > >>> (after you have cracked one key (and it doesn't take that much, > >>> especially if you can throw ASICs at the problem), you can crack > >>> each subsequent one in a few CPU minutes. With 2048-bit DH, at > >>> least the first key tends to be too hard, and with ECDH, tricks > >>> like this don't work). > >> > >> Yes, both Brian and I replied that we were using this more for > >> experimentation on low-powered or CPU challenged devices. We will > >> not recommend its use. It’s just there for implementations to start > >> with something. But havind said that, I would like to recommend > >> the smaller keys that come along with chacha20/poly1305 so maybe > >> the subject is moot. > > > > I think that even having low-security options is a problem. > > How about we change the Cipher Suite definitions TO this (and address multiple of your comments): > > Cipher Suite 0: > Reserved > > Cipher Suite 1: > Diffie-Hellman Group: 2048-bit MODP [RFC3526] > Encryption: AES with 128-bit keys in GCM mode [AES-GCM] > Integrity: HMAC-SHA1-96 [RFC2404] > > Cipher Suite 2: > Diffie-Hellman Group: 3072-bit MODP [RFC3526] > Encryption: AES with 128-bit keys in GCM mode [AES-GCM] > Integrity: HMAC-SHA1-96 [RFC2404] > > Cipher Suite 3: > Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519] > Encryption: AES with 128-bit keys in GCM mode [AES-GCM] > Integrity: HMAC-SHA1-96 [RFC2404] AES-GCM is AEAD algorithm, so it also covers the integerity. > Cipher Suite 4: > Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519] > Encryption: Chacha20-Poly1305 [CHACHA-POLY] > Integrity: Covered under Encryption Algorithm > > Please ack before we take action. And would like Brian (or anyone else > in the WG) to weigh in on this as well. > > >>> - The NIST SP800-108 KDF handles the counter and length internally, > >>> those are not part of the context input. > >> > >> You should point to text so we know where in the spec you are > >> commenting against. It is hard to get context from your comments. > > > > Section 5 in -02. The listing for "Context" (meaning the fields > > in context). > > I think we are saying we are building a context similar to the NIST > standard but not using it. Brian needs to comment here. What I'm saying is that you seem to be duplicating steps NIST KDF does internally. > >> We use the source RLOC and the Map-Request nonce to identify the association. > > > > That's does not create identifier suitable for comparing between > > endpoints for authentication. > > LISP-SEC is used as well. See the Security Considerations section. > I think we have this covered. > > > You mean that A (and B) is supposed to use different DH keys for > > their roles as ITR and ETR (if reusing keys, like at least some > > implementations are going to do)? > > Yes, that is the way we described it by talking about encryption > unidirectionally from ITR to ETR. I haven't found the security consideration (that if the same router is ITR and ETR, it MUST NOT reuse DH keys for both purposes). And I'd rather not leave such things implicit. > > - IV is incremented for every packet? If using CBC mode, predictable > >>> IVs are bad (AEAD algorithms do deal with predictable IVs, but not > >>> repeating IVs). > > > > I mean, the document seems to say both IVs are randomly generated and > > incremented for every packet (which seem to be mutually > > contradictionary). > > I see. We can do one versus the other. That is, use random IVs. Is that okay? No the problem is: - CBC IVs MUST be random. - 12-octet-nonce AEAD IVs MUST NOT be random. The reason for latter is that 96 bit randoms repeat too soon, and AEAD algorithms usually break in catastrophic ways if the nonce ever repeats (basically all security lost in this case). > > 2) Invoke the AEAD encryption with: > > - Key set to encryption-key > > - Nonce set to the IV (truncated to N_MAX octets if N_MAX<16, padded > > with zeroes in the end to N_MIN octets if N_MIN>16). > > - AD set to LISP header plus added IV field (the parts of packet marked > > as ICV but not encrypt). > > - Plaintext set to the packet payload. > > Yes, that is what we do. If you have IV size be algorithm-dependent, just set the nonce to the IV (no padding, no truncation). > > > And decryption: > > > > 1) Strip the outer IP and UDP headers. > > > > 2) Strip tag encryption concatenated from packet payload (if any). > > > > 3) Invoke the AEAD decryption with: > > - Key set to encryption-key (from local key-cache) > > - Nonce set to the IV field contents (truncated to N_MAX octets if > > N_MAX<16, padded with zeroes in the end to N_MIN octets if N_MIN>16). > > - AD set to LISP header plus added IV field (the parts of packet marked > > as ICV but not encrypt). > > - Ciphertext set to the packet payload. > > But we don’t use the data-plane nonce for this. Because it may be > used for other LISP data-plane features. We use the control-plane > nonce which doesn’t show up on the network very often (only when > Map-Requests and returning Map-Replies are sent). So this is better > for security. No, this nonce is the nonce for crypto algorithm and is per-packet. The LISP packets transport it in "IV" field. > > There is also AEAD_AES_128_GCM, which being AEAD algorithm, is used > > similarly to AEAD_CHACHA20_POLY1305. The above algorithms work with > > it too. > > Does that mean we don’t need an ICV if we used AES-GCM? Similar to > your chacha20-poloy1305 comment? Yes, it means that. AES-GCM internally does the equivalent of the ICV (called "tag" there). -Ilari From nobody Mon Nov 2 18:18:23 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6C81ACDA5 for ; Mon, 2 Nov 2015 18:18:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, J_BACKHAIR_52=1, SPF_PASS=-0.001] autolearn=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 1QGHonXcTf3W for ; Mon, 2 Nov 2015 18:18:15 -0800 (PST) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::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 4C79D1ACD92 for ; Mon, 2 Nov 2015 18:18:15 -0800 (PST) Received: by pacfv9 with SMTP id fv9so3822009pac.3 for ; Mon, 02 Nov 2015 18:18:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dHeuuPgzEuJGHs/KYVEvq6eamjM7A1Df2OHd6d/+lUs=; b=zVmhp4KHlWKOsAdQ6AjUon0EsDsSkFUlzkLs7CRuM+TLed0YiYMwrlvMkp2RH+iXug B2gZ1280Iu1Sy687CPwvn61gPPWtm+XRWWdEUWnxc8ehlsia8AAwSFzDww5gTNEr/AU7 kuolXXJFDqXEM+vIfYS79XV2eprOeUJc3Uk0rRAzZrmHpfe/vURycE5qeP+S85JNQTk7 lgsjET9sWC8JWUBbEvzmyI2iDx8FHp9TmTBN+rX/pSM/JacJT1XF01A/3baZXRxw9kJ/ nD6I0/JkchpqNowzYzEc4BxzaJwvKGhynX6WpqW+rM7NFEkA5bNV8dW0gJnRKAIiTLwO AE4A== X-Received: by 10.66.62.198 with SMTP id a6mr31118038pas.68.1446517094943; Mon, 02 Nov 2015 18:18:14 -0800 (PST) Received: from t20010c400000303240265176242d4849.v6.meeting.ietf94.jp (t20010c400000303240265176242d4849.v6.meeting.ietf94.jp. [2001:c40:0:3032:4026:5176:242d:4849]) by smtp.gmail.com with ESMTPSA id zn9sm26523873pac.48.2015.11.02.18.18.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Nov 2015 18:18:13 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Dino Farinacci In-Reply-To: <20151102103946.GA4014@LK-Perkele-V2.elisa-laajakaista.fi> Date: Mon, 2 Nov 2015 18:18:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7E1DB803-830D-46EC-A49F-FDB2618D14EB@gmail.com> References: <20151028141703.GA9632@LK-Perkele-V2.elisa-laajakaista.fi> <1C855BE8-70D6-4604-AFED-4298AAD6186C@gmail.com> <20151101095325.GB13377@LK-Perkele-V2.elisa-laajakaista.fi> <0A35A9D5-B44E-4A00-B680-8B3599575E2C@gmail.com> <20151102103946.GA4014@LK-Perkele-V2.elisa-laajakaista.fi> To: Ilari Liusvaara X-Mailer: Apple Mail (2.2104) Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] Let's review crypto in lisp-crypto X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 03 Nov 2015 02:18:17 -0000 Understand your comemnts. I=E2=80=99ll create a -03 with changes that = reflect your comments and turn it around ASAP so you can make sure I = addressed your comments. Expect it in the next few days but not before today=E2=80=99s working = group meets. Dino > On Nov 2, 2015, at 2:39 AM, Ilari Liusvaara = wrote: >=20 > On Sun, Nov 01, 2015 at 08:42:44PM -0800, Dino Farinacci wrote: >>=20 >>> On Sun, Nov 01, 2015 at 01:13:56AM -0700, Dino Farinacci wrote: >>>>=20 >>>>> - Ciphersuite 1 uses 1024-bit Diffie-Hellman, which is too weak >>>>> (after you have cracked one key (and it doesn't take that much, >>>>> especially if you can throw ASICs at the problem), you can crack >>>>> each subsequent one in a few CPU minutes. With 2048-bit DH, at >>>>> least the first key tends to be too hard, and with ECDH, tricks >>>>> like this don't work). >>>>=20 >>>> Yes, both Brian and I replied that we were using this more for >>>> experimentation on low-powered or CPU challenged devices. We will >>>> not recommend its use. It=E2=80=99s just there for implementations = to start >>>> with something. But havind said that, I would like to recommend >>>> the smaller keys that come along with chacha20/poly1305 so maybe >>>> the subject is moot.=20 >>>=20 >>> I think that even having low-security options is a problem. >>=20 >> How about we change the Cipher Suite definitions TO this (and address = multiple of your comments): >>=20 >> Cipher Suite 0: >> Reserved >>=20 >> Cipher Suite 1: >> Diffie-Hellman Group: 2048-bit MODP [RFC3526] >> Encryption: AES with 128-bit keys in GCM mode [AES-GCM] >> Integrity: HMAC-SHA1-96 [RFC2404] >>=20 >> Cipher Suite 2: >> Diffie-Hellman Group: 3072-bit MODP [RFC3526] >> Encryption: AES with 128-bit keys in GCM mode [AES-GCM] >> Integrity: HMAC-SHA1-96 [RFC2404] >>=20 >> Cipher Suite 3: >> Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519] >> Encryption: AES with 128-bit keys in GCM mode [AES-GCM] >> Integrity: HMAC-SHA1-96 [RFC2404] >=20 > AES-GCM is AEAD algorithm, so it also covers the integerity. >=20 >> Cipher Suite 4: >> Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519] >> Encryption: Chacha20-Poly1305 [CHACHA-POLY] >> Integrity: Covered under Encryption Algorithm >>=20 >> Please ack before we take action. And would like Brian (or anyone = else >> in the WG) to weigh in on this as well. >>=20 >>>>> - The NIST SP800-108 KDF handles the counter and length = internally, >>>>> those are not part of the context input. >>>>=20 >>>> You should point to text so we know where in the spec you are >>>> commenting against. It is hard to get context from your comments. >>>=20 >>> Section 5 in -02. The listing for "Context" (meaning the fields >>> in context). >>=20 >> I think we are saying we are building a context similar to the NIST >> standard but not using it. Brian needs to comment here. >=20 > What I'm saying is that you seem to be duplicating steps NIST KDF does > internally. >=20 >>>> We use the source RLOC and the Map-Request nonce to identify the = association. >>>=20 >>> That's does not create identifier suitable for comparing between >>> endpoints for authentication. >>=20 >> LISP-SEC is used as well. See the Security Considerations section. >> I think we have this covered. >>=20 >>> You mean that A (and B) is supposed to use different DH keys for >>> their roles as ITR and ETR (if reusing keys, like at least some >>> implementations are going to do)? >>=20 >> Yes, that is the way we described it by talking about encryption >> unidirectionally from ITR to ETR. >=20 > I haven't found the security consideration (that if the same router > is ITR and ETR, it MUST NOT reuse DH keys for both purposes). >=20 > And I'd rather not leave such things implicit. >=20 >>> - IV is incremented for every packet? If using CBC mode, predictable >>>>> IVs are bad (AEAD algorithms do deal with predictable IVs, but not >>>>> repeating IVs). >>>=20 >>> I mean, the document seems to say both IVs are randomly generated = and >>> incremented for every packet (which seem to be mutually >>> contradictionary). >>=20 >> I see. We can do one versus the other. That is, use random IVs. Is = that okay? >=20 > No the problem is: > - CBC IVs MUST be random. > - 12-octet-nonce AEAD IVs MUST NOT be random. >=20 > The reason for latter is that 96 bit randoms repeat too soon, and > AEAD algorithms usually break in catastrophic ways if the nonce > ever repeats (basically all security lost in this case). >=20 >>> 2) Invoke the AEAD encryption with: >>> - Key set to encryption-key >>> - Nonce set to the IV (truncated to N_MAX octets if N_MAX<16, padded >>> with zeroes in the end to N_MIN octets if N_MIN>16). >>> - AD set to LISP header plus added IV field (the parts of packet = marked >>> as ICV but not encrypt). >>> - Plaintext set to the packet payload. >>=20 >> Yes, that is what we do. >=20 > If you have IV size be algorithm-dependent, just set the nonce to the > IV (no padding, no truncation). >=20 >>=20 >>> And decryption: >>>=20 >>> 1) Strip the outer IP and UDP headers. >>>=20 >>> 2) Strip tag encryption concatenated from packet payload (if any). >>>=20 >>> 3) Invoke the AEAD decryption with: >>> - Key set to encryption-key (from local key-cache) >>> - Nonce set to the IV field contents (truncated to N_MAX octets if >>> N_MAX<16, padded with zeroes in the end to N_MIN octets if = N_MIN>16). >>> - AD set to LISP header plus added IV field (the parts of packet = marked >>> as ICV but not encrypt). >>> - Ciphertext set to the packet payload. >>=20 >> But we don=E2=80=99t use the data-plane nonce for this. Because it = may be >> used for other LISP data-plane features. We use the control-plane >> nonce which doesn=E2=80=99t show up on the network very often (only = when >> Map-Requests and returning Map-Replies are sent). So this is better >> for security. >=20 > No, this nonce is the nonce for crypto algorithm and is per-packet. > The LISP packets transport it in "IV" field. >=20 >>> There is also AEAD_AES_128_GCM, which being AEAD algorithm, is used >>> similarly to AEAD_CHACHA20_POLY1305. The above algorithms work with >>> it too. >>=20 >> Does that mean we don=E2=80=99t need an ICV if we used AES-GCM? = Similar to >> your chacha20-poloy1305 comment? >=20 > Yes, it means that. AES-GCM internally does the equivalent of the ICV > (called "tag" there). >=20 >=20 > -Ilari From nobody Mon Nov 2 20:10:49 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB591B2CC1 for ; Mon, 2 Nov 2015 20:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 k3uDPLqM8jon for ; Mon, 2 Nov 2015 20:10:46 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9733A1B2CE7 for ; Mon, 2 Nov 2015 20:10:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 8D5901E59F6 for ; Mon, 2 Nov 2015 20:10:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWeRl6qRQcr7 for ; Mon, 2 Nov 2015 20:10:10 -0800 (PST) Received: from t20010c400000302418ef1e5e1effddeb.v6.meeting.ietf94.jp (t20010c400000302418ef1e5e1effddeb.v6.meeting.ietf94.jp [IPv6:2001:c40:0:3024:18ef:1e5e:1eff:ddeb]) by c8a.amsl.com (Postfix) with ESMTPA id 40EE81E59F2 for ; Mon, 2 Nov 2015 20:10:10 -0800 (PST) From: Alexa Morris Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Nov 2015 20:10:42 -0800 Message-Id: To: lisp@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Sendlaterdate: Mon, 2 Nov 2015 20:10:42 -0800 X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [lisp] Queue for LISP Remote Attendees X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 03 Nov 2015 04:10:47 -0000 If you are planning to participate in the LISP session here at IETF 94 = today =97 either locally in Yokohama or as a remote participant =97 we = want to make sure that you are aware that the IETF is providing a remote = participants with a fairly new way to ask questions or make comments. In = addition to using the Jabber room, for the LISP session there is also = the opportunity for remote participants to enter a virtual queue and ask = questions directly into the meeting room.=20 This experimental queue was used in several sessions at IETF 92 and IETF = 93, so you may have already seen it in action. There will be two queues = for the LISP session =97 a virtual queue and an actual (in-room) queue. = Remote attendees will log into the Meetecho platform and will have a = virtual mic line that they can enter if they have a question or comment. = In-room participants will continue to use normal mic lines.=20 Instructions for remote participants are at = http://ietf94.conf.meetecho.com/index.php/Remote_Participation.=20 Information on how to join the Meetecho session is at = http://ietf94.conf.meetecho.com/. Verify that you are WebRTC compliant (required to use the virtual queue) = by performing a self-test here: = http://ietf94.conf.meetecho.com/index.php/Self_Test.=20 Regards, Alexa ---------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com From nobody Mon Nov 2 23:04:00 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01451B2F01 for ; Mon, 2 Nov 2015 23:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ko3oaPPADXWh for ; Mon, 2 Nov 2015 23:03:56 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 234E41B2EDA for ; Mon, 2 Nov 2015 23:03:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4892; q=dns/txt; s=iport; t=1446534214; x=1447743814; h=from:to:subject:date:message-id:mime-version; bh=dmenljRTdVHI8Mdx9JtQ2uYsPZfdw2dJ9GRxnPW4Mwg=; b=Cr36+kv6Zlb2qU3j+U4dmbaGTa4wUOFwG50QgJcNTVPQEXHXPd7Cm+Lw 9Q922s0eTkkcjUf7Khgu5uo2+JELsNy8rg1Lo0a544kGW+n4PVyi6bpzA uyrlLxJAUiX5QJE0O1SzjsemiXRJK3mADpCYQHB09UPoXGWijPAfoNxqU I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D0AQD+WzhW/5RdJa1egm5NU3W7GoQhAQ2BWodLOBQBAQEBAQEBfwuEPC1eAYEAJgEEG4gooEageAEBAQEGAQEBAQEBHZU1BZZDAY0dnEEBHwEBQoQEhWmBBwEBAQ X-IronPort-AV: E=Sophos;i="5.20,238,1444694400"; d="scan'208,217";a="203155800" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-2.cisco.com with ESMTP; 03 Nov 2015 07:03:30 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id tA373UvY007506 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 3 Nov 2015 07:03:30 GMT Received: from xch-aln-006.cisco.com (173.36.7.16) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 Nov 2015 01:03:29 -0600 Received: from xch-aln-006.cisco.com ([173.36.7.16]) by XCH-ALN-006.cisco.com ([173.36.7.16]) with mapi id 15.00.1104.000; Tue, 3 Nov 2015 01:03:29 -0600 From: "Amjad Inamdar (amjads)" To: "lisp@ietf.org" Thread-Topic: LISP NAT Traversal Thread-Index: AdEWBbvY2lYwQkWuSL61SKNwqJz5Qw== Date: Tue, 3 Nov 2015 07:03:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.62.183] Content-Type: multipart/alternative; boundary="_000_f02960a2f1234e9cba653318dcf0be44XCHALN006ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [lisp] LISP NAT Traversal X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 03 Nov 2015 07:03:58 -0000 --_000_f02960a2f1234e9cba653318dcf0be44XCHALN006ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, It will be useful if LISP NAT traversal draft (draft-ermagan-lisp-nat-trave= rsal) can elaborate on the following 1) Why LISP NAT traversal cannot be accomplished without RTR (another netwo= rk entity) which has implications on deployability, complexity and latency.= There are other protocols (e.g IKE/IPsec) that achieve NAT-D and NAT-T wit= hout the need for additional network entity. 2) Some more details on RTR deployment - location of RTR in the LISP deployment like there are recommendations on = PITR/PETR deployments - is RTR shared across LISP sites behind NAT or each site needs a dedicated= RTR - what if RTR is behind another NAT (SP-NAT) 3) How is multiple-NAT handled (e.g. enterprise and SP NAT) Thanks, -Amjad Inamdar CISSP, CCNP R&S, CCNP Security, CCDP, CCSK Senior Technical Leader CSG PI Services Security - India --_000_f02960a2f1234e9cba653318dcf0be44XCHALN006ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

It will be useful if LISP NAT traversal draft (draft= -ermagan-lisp-nat-traversal) can elaborate on the following

 

1) Why LISP NAT traversal cannot be accomplished wit= hout RTR (another network entity) which has implications on deployability, = complexity and latency. There are other protocols (e.g IKE/IPsec) that achi= eve NAT-D and NAT-T without the need for additional network entity.

 

2) Some more details on RTR deployment

- location of RTR in the LISP deployment like there = are recommendations on PITR/PETR deployments

- is RTR shared across LISP sites behind NAT or each= site needs a dedicated RTR

- what if RTR is behind another NAT (SP-NAT)

 

3) How is multiple-NAT handled (e.g. enterprise and = SP NAT)

 

Thanks,

-Amjad= Inamdar CISSP, CCNP R&S, CCNP Security, CCDP, CCSK

Senior Te= chnical Leader

CSG PI Se= rvices Security - India  

 

--_000_f02960a2f1234e9cba653318dcf0be44XCHALN006ciscocom_-- From nobody Tue Nov 3 05:59:53 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202291A0062 for ; Tue, 3 Nov 2015 05:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 g2VniwOhMcpf for ; Tue, 3 Nov 2015 05:59:51 -0800 (PST) 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 7F4311A00B4 for ; Tue, 3 Nov 2015 05:59:51 -0800 (PST) Received: by padhx2 with SMTP id hx2so11623282pad.1 for ; Tue, 03 Nov 2015 05:59:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=etHtHkQRHj9fvExzIxhEGaxJUR2PF1HVWRZzHQ2zfD4=; b=c70lQHEwXXlrifEnD+CzzemmiEy8dWpYVJPg3fGY7Js931CkIybd+BnSGs1yi8JaU8 +pSCP7tR1uX3o8Qni8k/ESjUS9oGwocV0Sh5UPVPTUq4qpQN1m4drM94jTX5+2pUzx7C 19MrYlGgAiSKmeHj7tAnP7rZOfyVr0Npac69cOYL2+hPli/cxCwl98HRjKXWjweGxhE8 sdptNKGsghNzhWjO8WCBWVVC4MFXVj1F8dlxzSPzIdQRqPnF3vZd0l4NKoUVl/+TAU9m UYrZgTMF6sYkrIAH6m55xZcaH9q9zLTDQ8QAin1l2Y9GCDiYB/krx3PAPGd6sv9IJ3EG eQGA== X-Received: by 10.68.248.6 with SMTP id yi6mr34199293pbc.158.1446559191109; Tue, 03 Nov 2015 05:59:51 -0800 (PST) Received: from t20010c40000030807939b9355523c50e.v6.meeting.ietf94.jp (t20010c40000030807939b9355523c50e.v6.meeting.ietf94.jp. [2001:c40:0:3080:7939:b935:5523:c50e]) by smtp.gmail.com with ESMTPSA id bz1sm29869069pab.20.2015.11.03.05.59.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Nov 2015 05:59:50 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Dino Farinacci In-Reply-To: Date: Tue, 3 Nov 2015 05:59:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <754E7621-099C-4A75-95D8-EA41F4A512C0@gmail.com> References: To: "Amjad Inamdar (amjads)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "lisp@ietf.org" Subject: Re: [lisp] LISP NAT Traversal X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 03 Nov 2015 13:59:53 -0000 > Hi, > =20 > It will be useful if LISP NAT traversal draft = (draft-ermagan-lisp-nat-traversal) can elaborate on the following See comments inline. Thanks for having a look at the draft. > 1) Why LISP NAT traversal cannot be accomplished without RTR (another = network entity) which has implications on deployability, complexity and = latency. There are other protocols (e.g IKE/IPsec) that achieve NAT-D = and NAT-T without the need for additional network entity. There are 2 important scalability reasons: (1) You want to keep the number of cache entries in the NAT to a = minimum. By using an RTR to encapsulate packets to, there is only a = single NAT entry. (2) When the xTR moves, you want its new locator to be advertised to the = fewest number of places in the network. So if the RTR is the only one = encapsulating to the xTR then it only has to be updated. > 2) Some more details on RTR deployment > - location of RTR in the LISP deployment like there are = recommendations on PITR/PETR deployments The location of the RTR is desiraable to be close to the current = location of the xTR so we can minimize packet stretch. Hence when an xTR = moves, the Map-Server (which is fixed and doesn=E2=80=99t need to be = close to the moving xTR since it is a control-plane function), tells the = xTR of a new set of RTRs that is close to it, in the xTRs new location. This is mostly policy information in the mapping system. > - is RTR shared across LISP sites behind NAT or each site needs a = dedicated RTR Yes, we envision that millions of xTRs can use the same set of RTRs = (i.e. a pair of RTRs that are topologically close to each other and the = xTRs that are using them). > - what if RTR is behind another NAT (SP-NAT) By protocol specification, it should be in public space. But I have an = implementation where NAT-traversal works when both the xTR and RTR are = behind NATs (different NATs). > 3) How is multiple-NAT handled (e.g. enterprise and SP NAT) If you have an xTR that is multi-homed to 2 NATs, then Info-Requests are = sent each way to both the map-server and to RTRs that map-server has = advertised. In the registration, one can decide which RTR is used by = remote ITRs encapsulating toward the EIDs behind the xTR. And the xTR = can load-split traffic (outgoing traffic) across the RTRs in the list = the map-server provided. Thanks, Dino > =20 > Thanks, > -Amjad Inamdar CISSP, CCNP R&S, CCNP Security, CCDP, CCSK > Senior Technical Leader > CSG PI Services Security - India =20 > =20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Tue Nov 3 07:02:36 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 641E91A1BA2 for ; Tue, 3 Nov 2015 07:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 qeoW9XcZZY6C for ; Tue, 3 Nov 2015 07:02:27 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::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 1660A1A1BDC for ; Tue, 3 Nov 2015 07:02:21 -0800 (PST) Received: by pabfh17 with SMTP id fh17so20735348pab.0 for ; Tue, 03 Nov 2015 07:02:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EdSwXm/0V5uNrPPXFvuiK6eZ8VRSu1M7yxrNo207GJg=; b=WU1uCJaE4WJWNST4KBQqp5b7MXxEqzQNYaeXCGHWa7XSKDBThUoQZsMyCMj+mN24Xu kdIX9X1YtbqZDcFI0skXv8Vg+BLNptl8Q+gh6r2oSXVcOhkj4/iFhP2g6sPI/Po5iZ3d 6ciz9DL4cHq86Zp7MzdtaU98gYZI4AQltmy+JrKHkNhbarBJz5VETlPzkUCP+JNTeqjy D0v5I+sXi1M6Z8OWpHKh6pAR1RdZc62Nypuz2S/Pq0XuKLRpdHa0w5kGUMtZrmwSJhHN 2l9tWLemwKcPO1Y4G0yzcmN0lqGbI0L9E3Ugnx/qwvbxGWEAJqrEf1lwxPY/f53/ZYPJ TT3Q== X-Received: by 10.68.170.101 with SMTP id al5mr34596037pbc.38.1446562940504; Tue, 03 Nov 2015 07:02:20 -0800 (PST) Received: from [10.0.0.16] (c-98-248-50-149.hsd1.ca.comcast.net. [98.248.50.149]) by smtp.gmail.com with ESMTPSA id ce3sm30031604pbb.35.2015.11.03.07.02.18 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Nov 2015 07:02:18 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Sharon X-Mailer: iPhone Mail (13B143) In-Reply-To: <754E7621-099C-4A75-95D8-EA41F4A512C0@gmail.com> Date: Tue, 3 Nov 2015 07:02:17 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <711231F5-5A32-4382-8F5F-48FD088E5E25@gmail.com> References: <754E7621-099C-4A75-95D8-EA41F4A512C0@gmail.com> To: Dino Farinacci Archived-At: Cc: "lisp@ietf.org" Subject: Re: [lisp] LISP NAT Traversal X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 03 Nov 2015 15:02:33 -0000 Can also add a carrier use case - The RTRs are in POPs, racks of equipment or clusters of servers, stable unde= rlay, very responsive low latency mapping.=20 The XTRs are across the access, on or off the carrier footprint, (NAT wise) h= igh latency lookup, potentially shaky conditions. The RTRs anchor the XTRs. The XTR can reach any of the RTRs (any cast) move,= recover from a topology change, or access carrier change. The mapping Service & Resource Schema apropos yesterday discussion regarding= easy mapping abstraction (Albert) for orchestrating NSH (Vina, Fabio) is ma= de available to potentially millions of semi loose XTRs aggregating billions= of very loose EIDs, using traversal anchoring without creating a global dat= a consistency nightmare.=20 --szb On Nov 3, 2015, at 5:59 AM, Dino Farinacci wrote: >> Hi, >>=20 >> It will be useful if LISP NAT traversal draft (draft-ermagan-lisp-nat-tra= versal) can elaborate on the following >=20 > See comments inline. Thanks for having a look at the draft. >=20 >> 1) Why LISP NAT traversal cannot be accomplished without RTR (another net= work entity) which has implications on deployability, complexity and latency= . There are other protocols (e.g IKE/IPsec) that achieve NAT-D and NAT-T wit= hout the need for additional network entity. >=20 > There are 2 important scalability reasons: >=20 > (1) You want to keep the number of cache entries in the NAT to a minimum. B= y using an RTR to encapsulate packets to, there is only a single NAT entry. >=20 > (2) When the xTR moves, you want its new locator to be advertised to the f= ewest number of places in the network. So if the RTR is the only one encapsu= lating to the xTR then it only has to be updated. >=20 >> 2) Some more details on RTR deployment >> - location of RTR in the LISP deployment like there are recommendations o= n PITR/PETR deployments >=20 > The location of the RTR is desiraable to be close to the current location o= f the xTR so we can minimize packet stretch. Hence when an xTR moves, the Ma= p-Server (which is fixed and doesn=E2=80=99t need to be close to the moving x= TR since it is a control-plane function), tells the xTR of a new set of RTRs= that is close to it, in the xTRs new location. >=20 > This is mostly policy information in the mapping system. >=20 >> - is RTR shared across LISP sites behind NAT or each site needs a dedicat= ed RTR >=20 > Yes, we envision that millions of xTRs can use the same set of RTRs (i.e. a= pair of RTRs that are topologically close to each other and the xTRs that a= re using them). >=20 >> - what if RTR is behind another NAT (SP-NAT) >=20 > By protocol specification, it should be in public space. But I have an imp= lementation where NAT-traversal works when both the xTR and RTR are behind N= ATs (different NATs). >=20 >> 3) How is multiple-NAT handled (e.g. enterprise and SP NAT) >=20 > If you have an xTR that is multi-homed to 2 NATs, then Info-Requests are s= ent each way to both the map-server and to RTRs that map-server has advertis= ed. In the registration, one can decide which RTR is used by remote ITRs enc= apsulating toward the EIDs behind the xTR. And the xTR can load-split traffi= c (outgoing traffic) across the RTRs in the list the map-server provided. >=20 > Thanks, > Dino >=20 >>=20 >> Thanks, >> -Amjad Inamdar CISSP, CCNP R&S, CCNP Security, CCDP, CCSK >> Senior Technical Leader >> CSG PI Services Security - India =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 From nobody Tue Nov 3 08:37:48 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64D01A8823 for ; Tue, 3 Nov 2015 08:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ozAIMXpTnXnt for ; Tue, 3 Nov 2015 08:37:40 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E4431A8865 for ; Tue, 3 Nov 2015 08:37:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=442; q=dns/txt; s=iport; t=1446568660; x=1447778260; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OBTWFFsrGYH39sdGofuKeYWzdSFPXlH0UkYNgUpPPNw=; b=HiOg4F1vGckKI+Az1mF+2zNWOUNnXGn+f2DCGTKySuBDRvSqH8aaB91E 9ljdabuZleHI8BfC0fwMlsQ/w1Gg29jbM9q6F6JM2UOHNl/6BL2dxRWyZ Ly9YyJpK+8/EowKpVa5caeZbwbUyPhptq/XV3/OlQKWNH7SGIesld8h/2 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D8AQDS4ThW/4ENJK1egzuBQga7IIIqAQ2BXYYUAoE8OBQBAQEBAQEBgQqENgEBBDo/EAIBCDYQIRElAgQOBYgZAxK9TA2EJAEBAQEBAQEBAQEBAQEBAQEBAQEBARiGZIIQgm6CU4FhJYNOgRQBBJZGAYsugXSUbIdRAR8BAUKEBHKENEOBBwEBAQ X-IronPort-AV: E=Sophos;i="5.20,239,1444694400"; d="scan'208";a="43548313" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-5.cisco.com with ESMTP; 03 Nov 2015 16:37:39 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id tA3GbdVK003877 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 Nov 2015 16:37:39 GMT Received: from xch-rcd-018.cisco.com (173.37.102.28) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 Nov 2015 10:37:38 -0600 Received: from xch-rcd-018.cisco.com ([173.37.102.28]) by XCH-RCD-018.cisco.com ([173.37.102.28]) with mapi id 15.00.1104.000; Tue, 3 Nov 2015 10:37:39 -0600 From: "Darrel Lewis (darlewis)" To: Dino Farinacci Thread-Topic: [lisp] LISP NAT Traversal Thread-Index: AQHRFlXzL7ZOZElg1kyFz4C8M3JtGA== Date: Tue, 3 Nov 2015 16:37:39 +0000 Message-ID: References: <754E7621-099C-4A75-95D8-EA41F4A512C0@gmail.com> In-Reply-To: <754E7621-099C-4A75-95D8-EA41F4A512C0@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.253.180] Content-Type: text/plain; charset="us-ascii" Content-ID: <58B971C6B51FCF45AC3CF79D5A2B12E2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lisp@ietf.org" Subject: Re: [lisp] LISP NAT Traversal X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 03 Nov 2015 16:37:46 -0000 On Nov 3, 2015, at 5:59 AM, Dino Farinacci wrote: >>=20 >> - is RTR shared across LISP sites behind NAT or each site needs a dedica= ted RTR >=20 > Yes, we envision that millions of xTRs can use the same set of RTRs (i.e.= a pair of RTRs that are topologically close to each other and the xTRs tha= t are using them). Well, a given RTR is limited by the # of destination UDP ports available. -Darrel= From nobody Wed Nov 4 17:29:49 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482C41B3600 for ; Wed, 4 Nov 2015 17:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 62LS7WUcF9NC for ; Wed, 4 Nov 2015 17:29:46 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 495D91B35F6 for ; Wed, 4 Nov 2015 17:29:46 -0800 (PST) Received: by wmll128 with SMTP id l128so716160wml.0 for ; Wed, 04 Nov 2015 17:29:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YWB8AoCwamrcSrdNlfAwA9pqmJqOwuf+CSFmhtctXSc=; b=GoMBJqiWUIgNRDbEklIHcp05/fMnCc7Ar0upB2iILNkGNLMEwGKTvqoN6QP60A4MW1 NfaL9LMNVaP03sGwj700F3sktfeYnotpMr64ZapDRxqPFNDi5x64m4AevYq2PaaHIgOr OhReEhSZrrVr2IoNYoVCisAyCFoS+5QNbrlT8rBsvooM19Nryzw/+/1iacpFkHo17rtN mzO/OM3VFT1+pD+2T01fEDKzqXov32f45EcpQXE69c36UhbNatfzIIeJPr+0lxNc3tGA ny9uu+2Yldh1pzEh4M6hK9T1DkDo5nZd4zcYkS8aq257za5Mj94NpEBlVvQaed/ISPl+ Fs5Q== X-Received: by 10.28.12.11 with SMTP id 11mr143364wmm.99.1446686984613; Wed, 04 Nov 2015 17:29:44 -0800 (PST) Received: from dhcp-52-119.meeting.ietf94.jp (dhcp-52-119.meeting.ietf94.jp. [133.93.52.119]) by smtp.gmail.com with ESMTPSA id vr10sm4226155wjc.38.2015.11.04.17.29.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 17:29:44 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Damien Saucez In-Reply-To: <562E53EF.9070707@joelhalpern.com> Date: Thu, 5 Nov 2015 10:29:38 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <9181AA70-7967-4625-8F2A-981ED8C04724@gmail.com> References: <562E53EF.9070707@joelhalpern.com> To: Joel Halpern X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] Way forward on 6830bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2015 01:29:48 -0000 Hello, By seeing Alberts presentation on SFC today I was just thinking that we = could split 6830 in two documents. One document to present the data-plane (mostly Sec 5). One document to present the control-plane (mostly Sec 6). As Albert said the mapping system is generic (with LCAF). Therefore it = would make it more logical (to me at least) to have a document to strictly = talk about the mapping system and it would increase the appeal of the mapping = system by not requiring people to care about the LISP encapsulation if they only = need the mapping system function. Cheers, Damien Saucez=20 On 27 Oct 2015, at 01:25, Joel M. Halpern wrote: > It seemed to us that there was likely some confusiona bout how we = expect to handle the revision of RCC 6830. The following is what we = currently expect. >=20 > Once we have a new charter approved, the chairs will appoint an editor = for the revision of rfc6830. That may be one of the existing authors, = or a new person. We will ask for volunteers. >=20 > Once we have an author, they will submit a starting ID called = draft-ietf-lisp-rfc6830bis-00 which will be identical in content to the = existing RFC. That may require assistance from the RFC Editor to ensure = that we get all the changes they made during final edit. >=20 > At that point, we will use the trouble ticket system to record issues = that people bring up. We will also discuss on the list what changes we = wish to make according to the charter. Things will tehn proceed in the = usual fashion, using the trouble ticket system to help make sure we do = not drop any of the issues. >=20 > Yours, > Joel & Luigi >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Wed Nov 4 17:33:32 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A72681B35BA for ; Wed, 4 Nov 2015 17:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 Oj5dG-rB2phs for ; Wed, 4 Nov 2015 17:33:29 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::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 14FA31B35B1 for ; Wed, 4 Nov 2015 17:33:29 -0800 (PST) Received: by pabfh17 with SMTP id fh17so69836725pab.0 for ; Wed, 04 Nov 2015 17:33:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gqQIe1yb7B4kEa8p2wT35ptylnxU/D9Vt0IidzcOlCo=; b=GHGmIo8E7fNpEEmfajkshWJ7n8gJ9x1x+PP01WvmuclQcrJwk87sJQB20IGgIdI7UZ lPWTzoBEhXwE0Jq3e1QlpwdsCCT6bJscaH2k8VcmlJ1G9AvEYRvv9cnqwwFXQ/AnsUgh 7s5N7VytCAWWDWU1kWMt9jsIGCcVzMkByuYu79B/PkRNWWiF7n+FHYlJIwuHrpPbMCk4 fgA9ERZdGBJSuW0BLijajPN+TipODFop+JCBjdnNEIJ+keaSgbPnhc3875NAHy1fRe4U edSbBxzne5UP4IVjmxiKhMYm2iszif8q7aXKWmTTT038Z1qVBu/bTZnkQiBasjiY92cX dnRw== X-Received: by 10.68.179.228 with SMTP id dj4mr6084136pbc.112.1446687208580; Wed, 04 Nov 2015 17:33:28 -0800 (PST) Received: from t20010c400000303225371849ad79f5b9.v6.meeting.ietf94.jp (t20010c400000303225371849ad79f5b9.v6.meeting.ietf94.jp. [2001:c40:0:3032:2537:1849:ad79:f5b9]) by smtp.gmail.com with ESMTPSA id l16sm4409489pbq.22.2015.11.04.17.33.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 17:33:27 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Dino Farinacci In-Reply-To: <9181AA70-7967-4625-8F2A-981ED8C04724@gmail.com> Date: Wed, 4 Nov 2015 17:33:24 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <562E53EF.9070707@joelhalpern.com> <9181AA70-7967-4625-8F2A-981ED8C04724@gmail.com> To: Damien Saucez X-Mailer: Apple Mail (2.2104) Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] Way forward on 6830bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2015 01:33:30 -0000 > Hello, >=20 > By seeing Alberts presentation on SFC today I was just thinking that = we could > split 6830 in two documents. >=20 > One document to present the data-plane (mostly Sec 5). >=20 > One document to present the control-plane (mostly Sec 6). >=20 > As Albert said the mapping system is generic (with LCAF). Therefore = it would > make it more logical (to me at least) to have a document to strictly = talk about > the mapping system and it would increase the appeal of the mapping = system by > not requiring people to care about the LISP encapsulation if they only = need the > mapping system function. The mapping system is in a separate document and spread across alt, ddt, = and ms specs. The control-plane text in RFC6830 is defining an API to = the mapping system. And I think you want it all in one place for = completeness. Dino >=20 > Cheers, >=20 > Damien Saucez=20 >=20 > On 27 Oct 2015, at 01:25, Joel M. Halpern wrote: >=20 >> It seemed to us that there was likely some confusiona bout how we = expect to handle the revision of RCC 6830. The following is what we = currently expect. >>=20 >> Once we have a new charter approved, the chairs will appoint an = editor for the revision of rfc6830. That may be one of the existing = authors, or a new person. We will ask for volunteers. >>=20 >> Once we have an author, they will submit a starting ID called = draft-ietf-lisp-rfc6830bis-00 which will be identical in content to the = existing RFC. That may require assistance from the RFC Editor to ensure = that we get all the changes they made during final edit. >>=20 >> At that point, we will use the trouble ticket system to record issues = that people bring up. We will also discuss on the list what changes we = wish to make according to the charter. Things will tehn proceed in the = usual fashion, using the trouble ticket system to help make sure we do = not drop any of the issues. >>=20 >> Yours, >> Joel & Luigi >>=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 Wed Nov 4 17:40:00 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6141B35F6 for ; Wed, 4 Nov 2015 17:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 zxZtvZQ5au53 for ; Wed, 4 Nov 2015 17:39:56 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48D061A8788 for ; Wed, 4 Nov 2015 17:39:56 -0800 (PST) Received: by wmll128 with SMTP id l128so833590wml.0 for ; Wed, 04 Nov 2015 17:39:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bb6mf/b0B/VttzMuTXdc7lk6i2rqvOay3KGbJ+4BhOc=; b=pPc7/oLut3woXvJc5cU5sDHfDEHkvS/UHfGE8i+beQO20Z/ePBoHE/Dy/rcab4cc9b FektRSUxaSes0Mko1XLkFIuF374eFEuoYIMBPniI7yWoQhAgkxcsjabAS0YaRQjgNTx5 BTUCdzwVIMg03032JtNj2xpC8kg8mnLJQM9o9pcbcuJZS6AH80iDViIuxR6wohbU/MVr aDYs30nCkzKc+g+s9LSySu9QCcN4NvBcLGC7Q4+8GJsCcFBUYBzf8VkkdBwdwpF4XVNZ 9Z4WffM0cjSlxyHEIOuJy9ovee2bYdY+3czzgqt5vtQxdQT2GE2zxeqXSVYINLuCXQkr WG4A== X-Received: by 10.28.217.6 with SMTP id q6mr254152wmg.5.1446687594758; Wed, 04 Nov 2015 17:39:54 -0800 (PST) Received: from dhcp-52-119.meeting.ietf94.jp (dhcp-52-119.meeting.ietf94.jp. [133.93.52.119]) by smtp.gmail.com with ESMTPSA id h4sm4249606wjx.41.2015.11.04.17.39.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 17:39:54 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Damien Saucez In-Reply-To: Date: Thu, 5 Nov 2015 10:39:46 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <562E53EF.9070707@joelhalpern.com> <9181AA70-7967-4625-8F2A-981ED8C04724@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] Way forward on 6830bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2015 01:39:58 -0000 On 05 Nov 2015, at 10:33, Dino Farinacci wrote: >> Hello, >>=20 >> By seeing Alberts presentation on SFC today I was just thinking that = we could >> split 6830 in two documents. >>=20 >> One document to present the data-plane (mostly Sec 5). >>=20 >> One document to present the control-plane (mostly Sec 6). >>=20 >> As Albert said the mapping system is generic (with LCAF). Therefore = it would >> make it more logical (to me at least) to have a document to strictly = talk about >> the mapping system and it would increase the appeal of the mapping = system by >> not requiring people to care about the LISP encapsulation if they = only need the >> mapping system function. >=20 > The mapping system is in a separate document and spread across alt, = ddt, and ms specs. The control-plane text in RFC6830 is defining an API = to the mapping system. And I think you want it all in one place for = completeness. >=20 When I was talking about mapping system, I was talking about the =93API=94 (Map-Request, Map-Reply, Map-Register=85 ). I understand that it is not straightforward to make it in a nice way, = but the as LISP is about decoupling control-plane and data-plane it would make sense to also decouple control and data-plane definition. Imagine you want someone to only implement the control-plane, how does he know what to implement exactly to be fully compliant?=20 Damien Saucez=20 > Dino >=20 >>=20 >> Cheers, >>=20 >> Damien Saucez=20 >>=20 >> On 27 Oct 2015, at 01:25, Joel M. Halpern = wrote: >>=20 >>> It seemed to us that there was likely some confusiona bout how we = expect to handle the revision of RCC 6830. The following is what we = currently expect. >>>=20 >>> Once we have a new charter approved, the chairs will appoint an = editor for the revision of rfc6830. That may be one of the existing = authors, or a new person. We will ask for volunteers. >>>=20 >>> Once we have an author, they will submit a starting ID called = draft-ietf-lisp-rfc6830bis-00 which will be identical in content to the = existing RFC. That may require assistance from the RFC Editor to ensure = that we get all the changes they made during final edit. >>>=20 >>> At that point, we will use the trouble ticket system to record = issues that people bring up. We will also discuss on the list what = changes we wish to make according to the charter. Things will tehn = proceed in the usual fashion, using the trouble ticket system to help = make sure we do not drop any of the issues. >>>=20 >>> Yours, >>> Joel & Luigi >>>=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 >=20 From nobody Wed Nov 4 17:48:36 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9E21B3624 for ; Wed, 4 Nov 2015 17:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 At89jWVNI-al for ; Wed, 4 Nov 2015 17:48:24 -0800 (PST) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::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 385A71B3608 for ; Wed, 4 Nov 2015 17:48:22 -0800 (PST) Received: by pabfh17 with SMTP id fh17so70236143pab.0 for ; Wed, 04 Nov 2015 17:48:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zg5htHgQ3YJcigu4RK6C3Rrd4h9/ClMygbCZXZNFIi8=; b=OmzT45mx2u2QULy7F35Z5YZboVKT+ZozadEBY2y0SAC06t/445IAzHLvS5227ULuwr NA0IebpvNnMAyzV9ErSjZY1FTGUwpWlMgjyDIk5O3RNqR9o9hR07f/n40Z1RByGjS1fV eLpz8Rt4LsOuW8oOgES/wmpYuYSfLt2CZSLHnR2kpClBu5sOdZUIk9Mhhx58yjy/6AGX B59ppC4wWxaWsaM8hJU7JpJgR5yEACesNnS5CMJMyRLNbw5JP9kqv7JcYribEIDpGrvN dPUcOzxNVUiFkwCzXQq87Z/wGEWTcIIU2ffQZfYnqU4ivgQKxCcVziJNy8RxVx3erhn9 WqwA== X-Received: by 10.68.194.4 with SMTP id hs4mr6203670pbc.116.1446688101749; Wed, 04 Nov 2015 17:48:21 -0800 (PST) Received: from t20010c400000303225371849ad79f5b9.v6.meeting.ietf94.jp (t20010c400000303225371849ad79f5b9.v6.meeting.ietf94.jp. [2001:c40:0:3032:2537:1849:ad79:f5b9]) by smtp.gmail.com with ESMTPSA id sz9sm4453751pab.13.2015.11.04.17.48.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 17:48:21 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Dino Farinacci In-Reply-To: Date: Wed, 4 Nov 2015 17:48:18 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7F7F2396-CF00-4362-AA7A-A410B395C20A@gmail.com> References: <562E53EF.9070707@joelhalpern.com> <9181AA70-7967-4625-8F2A-981ED8C04724@gmail.com> To: Damien Saucez X-Mailer: Apple Mail (2.2104) Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] Way forward on 6830bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2015 01:48:29 -0000 On 05 Nov 2015, at 10:33, Dino Farinacci wrote: >=20 >>> Hello, >>>=20 >>> By seeing Alberts presentation on SFC today I was just thinking that = we could >>> split 6830 in two documents. >>>=20 >>> One document to present the data-plane (mostly Sec 5). >>>=20 >>> One document to present the control-plane (mostly Sec 6). >>>=20 >>> As Albert said the mapping system is generic (with LCAF). Therefore = it would >>> make it more logical (to me at least) to have a document to strictly = talk about >>> the mapping system and it would increase the appeal of the mapping = system by >>> not requiring people to care about the LISP encapsulation if they = only need the >>> mapping system function. >>=20 >> The mapping system is in a separate document and spread across alt, = ddt, and ms specs. The control-plane text in RFC6830 is defining an API = to the mapping system. And I think you want it all in one place for = completeness. >>=20 >=20 > When I was talking about mapping system, I was talking about the > =93API=94 (Map-Request, Map-Reply, Map-Register=85 ). >=20 > I understand that it is not straightforward to make it in a nice way, = but > the as LISP is about decoupling control-plane and data-plane it would > make sense to also decouple control and data-plane definition. >=20 > Imagine you want someone to only implement the control-plane, how > does he know what to implement exactly to be fully compliant?=20 This is clearly stated in RFC6830. That is, you can send a Map-Request = for any reason. It doesn=92t have to be invoked by arrival of a packet = on an ITR/RTR/PITR. Tools like lig and rig are examples of this. Dino >=20 > Damien Saucez=20 >=20 >> Dino >>=20 >>>=20 >>> Cheers, >>>=20 >>> Damien Saucez=20 >>>=20 >>> On 27 Oct 2015, at 01:25, Joel M. Halpern = wrote: >>>=20 >>>> It seemed to us that there was likely some confusiona bout how we = expect to handle the revision of RCC 6830. The following is what we = currently expect. >>>>=20 >>>> Once we have a new charter approved, the chairs will appoint an = editor for the revision of rfc6830. That may be one of the existing = authors, or a new person. We will ask for volunteers. >>>>=20 >>>> Once we have an author, they will submit a starting ID called = draft-ietf-lisp-rfc6830bis-00 which will be identical in content to the = existing RFC. That may require assistance from the RFC Editor to ensure = that we get all the changes they made during final edit. >>>>=20 >>>> At that point, we will use the trouble ticket system to record = issues that people bring up. We will also discuss on the list what = changes we wish to make according to the charter. Things will tehn = proceed in the usual fashion, using the trouble ticket system to help = make sure we do not drop any of the issues. >>>>=20 >>>> Yours, >>>> Joel & Luigi >>>>=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 >>=20 >=20 From nobody Wed Nov 4 18:06:56 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0AA51B36B0 for ; Wed, 4 Nov 2015 18:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 8FqqRnLhFXju for ; Wed, 4 Nov 2015 18:06:53 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B1AD1B38CE for ; Wed, 4 Nov 2015 18:06:53 -0800 (PST) Received: by wmll128 with SMTP id l128so1196357wml.0 for ; Wed, 04 Nov 2015 18:06:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PbMaqyymERVMWvZOW6bRBRUJzU9LQI9AROROcyU+hxM=; b=0GoLKzsLF+tS0BbvP4sDl1U8Hm65v+Xyoj9YYcqngBFmA6qYYDCC2/Spi2An/etQZG CaCP+H32M8tIbtqph8SknpYBhzw7HYakecVI0W30Dnl2uEDUFwy6FW8GNdDduw6lhWBC 0GAplh/aJtWueJ6Sl4uZWq/uwhrtdjhavRR5aZeEpXpqDIO0tnWbAcaFO8XTbQRu1Pn7 sv6NH/jZE+fAHVrAq1Fnxz96VQlEEykh9/9/CrZI8vKXSSpd2eOelzZD9qMRwq8J0JlG 1nPAqAlEpju833tLrx+tHbJ938jVK1EgaGofRBuSJclVjJxKnCIcoAJh0jtyV6/JuPbL EANA== X-Received: by 10.28.10.13 with SMTP id 13mr355302wmk.30.1446689211611; Wed, 04 Nov 2015 18:06:51 -0800 (PST) Received: from dhcp-52-119.meeting.ietf94.jp (dhcp-52-119.meeting.ietf94.jp. [133.93.52.119]) by smtp.gmail.com with ESMTPSA id l1sm5766768wmg.21.2015.11.04.18.06.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 18:06:50 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Damien Saucez In-Reply-To: <7F7F2396-CF00-4362-AA7A-A410B395C20A@gmail.com> Date: Thu, 5 Nov 2015 11:06:44 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <049DD8C5-0356-434A-A32C-EE8C4DF270FE@gmail.com> References: <562E53EF.9070707@joelhalpern.com> <9181AA70-7967-4625-8F2A-981ED8C04724@gmail.com> <7F7F2396-CF00-4362-AA7A-A410B395C20A@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] Way forward on 6830bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2015 02:06:55 -0000 On 05 Nov 2015, at 10:48, Dino Farinacci wrote: > On 05 Nov 2015, at 10:33, Dino Farinacci wrote: >>=20 >>>> Hello, >>>>=20 >>>> By seeing Alberts presentation on SFC today I was just thinking = that we could >>>> split 6830 in two documents. >>>>=20 >>>> One document to present the data-plane (mostly Sec 5). >>>>=20 >>>> One document to present the control-plane (mostly Sec 6). >>>>=20 >>>> As Albert said the mapping system is generic (with LCAF). = Therefore it would >>>> make it more logical (to me at least) to have a document to = strictly talk about >>>> the mapping system and it would increase the appeal of the mapping = system by >>>> not requiring people to care about the LISP encapsulation if they = only need the >>>> mapping system function. >>>=20 >>> The mapping system is in a separate document and spread across alt, = ddt, and ms specs. The control-plane text in RFC6830 is defining an API = to the mapping system. And I think you want it all in one place for = completeness. >>>=20 >>=20 >> When I was talking about mapping system, I was talking about the >> =93API=94 (Map-Request, Map-Reply, Map-Register=85 ). >>=20 >> I understand that it is not straightforward to make it in a nice way, = but >> the as LISP is about decoupling control-plane and data-plane it would >> make sense to also decouple control and data-plane definition. >>=20 >> Imagine you want someone to only implement the control-plane, how >> does he know what to implement exactly to be fully compliant?=20 >=20 > This is clearly stated in RFC6830. That is, you can send a Map-Request = for any reason. It doesn=92t have to be invoked by arrival of a packet = on an ITR/RTR/PITR. Tools like lig and rig are examples of this. >=20 Of course for someone who knows LISP it is trivial that it is separated. = The issue is how to move forward and ensure that LISP control plane is not = bound at all to a particular data-plane. Actually, since the beginning we say = LISP is map-and-encap so it means two components mapping and encapsulation, that = seems thus very logical to me to have to documents, one for "mapping", one for =93encapsulation". At a first glance it could look like just being marketing but actually = splitting would allow both planes to be developed (and updated) in parallel. Damien Saucez > Dino >=20 >>=20 >> Damien Saucez=20 >>=20 >>> Dino >>>=20 >>>>=20 >>>> Cheers, >>>>=20 >>>> Damien Saucez=20 >>>>=20 >>>> On 27 Oct 2015, at 01:25, Joel M. Halpern = wrote: >>>>=20 >>>>> It seemed to us that there was likely some confusiona bout how we = expect to handle the revision of RCC 6830. The following is what we = currently expect. >>>>>=20 >>>>> Once we have a new charter approved, the chairs will appoint an = editor for the revision of rfc6830. That may be one of the existing = authors, or a new person. We will ask for volunteers. >>>>>=20 >>>>> Once we have an author, they will submit a starting ID called = draft-ietf-lisp-rfc6830bis-00 which will be identical in content to the = existing RFC. That may require assistance from the RFC Editor to ensure = that we get all the changes they made during final edit. >>>>>=20 >>>>> At that point, we will use the trouble ticket system to record = issues that people bring up. We will also discuss on the list what = changes we wish to make according to the charter. Things will tehn = proceed in the usual fashion, using the trouble ticket system to help = make sure we do not drop any of the issues. >>>>>=20 >>>>> Yours, >>>>> Joel & Luigi >>>>>=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 >>>=20 >>=20 >=20 From nobody Wed Nov 4 18:14:16 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D1F1B36C6 for ; Wed, 4 Nov 2015 18:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 NzxSFxseqpRY for ; Wed, 4 Nov 2015 18:14:05 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E4671B38DA for ; Wed, 4 Nov 2015 18:13:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4682; q=dns/txt; s=iport; t=1446689637; x=1447899237; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=TIP2z8idWAsLQo8TVlagcI+hQTxfyIgiu+U7BhBVKqA=; b=M3rd+RtzKzThdWw9XZRUPsr3G2Q5t2Q6q96cuvcOa31dBVtTjnss+qU6 5ygxPMoFzOinTYzpQe9yG6tRpv2xXcvPxI7w4/eUWVq8VyRVT/liHu9Yk pzYGRIaX+Apjn/1RAfYJhMOZlEzSKHzzBlNNQzdt5bfxuPMmUMhQKy7WR c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AaAgCTujpW/4QNJK1egztTb713AQ2BXhcKhXECgUE4FAEBAQEBAQGBCoQ1AQEBAwEBAQEvAQU2AQkRCxgJFg8JAwIBAgEPBjATBgIBAYgVAwoIDb0yDYQ8AQEBAQYBAQEBARoEhlSEfoJTgXWEcAWOEIg4iy+BdIFah0EjizGHUh8BAUKCER2BZS80hTQBAQE X-IronPort-AV: E=Sophos;i="5.20,245,1444694400"; d="scan'208";a="41943958" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-9.cisco.com with ESMTP; 05 Nov 2015 02:13:56 +0000 Received: from [10.24.154.57] ([10.24.154.57]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id tA52DtKv006389 for ; Thu, 5 Nov 2015 02:13:55 GMT To: lisp@ietf.org References: <562E53EF.9070707@joelhalpern.com> <9181AA70-7967-4625-8F2A-981ED8C04724@gmail.com> <7F7F2396-CF00-4362-AA7A-A410B395C20A@gmail.com> <049DD8C5-0356-434A-A32C-EE8C4DF270FE@gmail.com> From: Fabio Maino Message-ID: <563ABB62.4070608@cisco.com> Date: Thu, 5 Nov 2015 11:13:54 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <049DD8C5-0356-434A-A32C-EE8C4DF270FE@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lisp] Way forward on 6830bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2015 02:14:08 -0000 On 11/5/15 11:06 AM, Damien Saucez wrote: > On 05 Nov 2015, at 10:48, Dino Farinacci wrote: > >> On 05 Nov 2015, at 10:33, Dino Farinacci wrote: >>>>> Hello, >>>>> >>>>> By seeing Alberts presentation on SFC today I was just thinking that we could >>>>> split 6830 in two documents. >>>>> >>>>> One document to present the data-plane (mostly Sec 5). >>>>> >>>>> One document to present the control-plane (mostly Sec 6). >>>>> >>>>> As Albert said the mapping system is generic (with LCAF). Therefore it would >>>>> make it more logical (to me at least) to have a document to strictly talk about >>>>> the mapping system and it would increase the appeal of the mapping system by >>>>> not requiring people to care about the LISP encapsulation if they only need the >>>>> mapping system function. >>>> The mapping system is in a separate document and spread across alt, ddt, and ms specs. The control-plane text in RFC6830 is defining an API to the mapping system. And I think you want it all in one place for completeness. >>>> >>> When I was talking about mapping system, I was talking about the >>> “API” (Map-Request, Map-Reply, Map-Register… ). >>> >>> I understand that it is not straightforward to make it in a nice way, but >>> the as LISP is about decoupling control-plane and data-plane it would >>> make sense to also decouple control and data-plane definition. >>> >>> Imagine you want someone to only implement the control-plane, how >>> does he know what to implement exactly to be fully compliant? >> This is clearly stated in RFC6830. That is, you can send a Map-Request for any reason. It doesn’t have to be invoked by arrival of a packet on an ITR/RTR/PITR. Tools like lig and rig are examples of this. >> > > Of course for someone who knows LISP it is trivial that it is separated. The > issue is how to move forward and ensure that LISP control plane is not bound at > all to a particular data-plane. Actually, since the beginning we say LISP is > map-and-encap so it means two components mapping and encapsulation, that seems > thus very logical to me to have to documents, one for "mapping", one for > “encapsulation". > > At a first glance it could look like just being marketing but actually splitting > would allow both planes to be developed (and updated) in parallel. Damien, I think this could be a good idea. Too many people still associate LISP mostly with the encap (and it looks like too many don't read past the title of the RFC... :-( We should also do a better work of explaining that LISP CP can be used as generic mapping service for overlays (not only for on-demand LISP tunnel provisioning). In retrospective we should have presented the LISP/NSH draft in SFC as well.There might be more SFC use cases that can be addressed by the LISP CP. It'd be helpful to have the people in SFC give a thought to the concept of map assisted overlays. Fabio > > Damien Saucez > >> Dino >> >>> Damien Saucez >>> >>>> Dino >>>> >>>>> Cheers, >>>>> >>>>> Damien Saucez >>>>> >>>>> On 27 Oct 2015, at 01:25, Joel M. Halpern wrote: >>>>> >>>>>> It seemed to us that there was likely some confusiona bout how we expect to handle the revision of RCC 6830. The following is what we currently expect. >>>>>> >>>>>> Once we have a new charter approved, the chairs will appoint an editor for the revision of rfc6830. That may be one of the existing authors, or a new person. We will ask for volunteers. >>>>>> >>>>>> Once we have an author, they will submit a starting ID called draft-ietf-lisp-rfc6830bis-00 which will be identical in content to the existing RFC. That may require assistance from the RFC Editor to ensure that we get all the changes they made during final edit. >>>>>> >>>>>> At that point, we will use the trouble ticket system to record issues that people bring up. We will also discuss on the list what changes we wish to make according to the charter. Things will tehn proceed in the usual fashion, using the trouble ticket system to help make sure we do not drop any of the issues. >>>>>> >>>>>> Yours, >>>>>> Joel & Luigi >>>>>> >>>>>> _______________________________________________ >>>>>> 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 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Wed Nov 4 18:29:05 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569ED1B390A for ; Wed, 4 Nov 2015 18:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 bddzfYP0Ppaz for ; Wed, 4 Nov 2015 18:28:53 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id A6DA41B3901 for ; Wed, 4 Nov 2015 18:28:52 -0800 (PST) Received: from gw-3.ac.upc.es (gw-3.ac.upc.es [147.83.30.9]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id tA50gXFN032535 for ; Thu, 5 Nov 2015 01:42:33 +0100 Received: from mail-lf0-f52.google.com (mail-lf0-f52.google.com [209.85.215.52]) by gw-3.ac.upc.es (Postfix) with ESMTPSA id F2D92207 for ; Thu, 5 Nov 2015 03:28:50 +0100 (CET) Received: by lfgh9 with SMTP id h9so51269093lfg.1 for ; Wed, 04 Nov 2015 18:28:50 -0800 (PST) X-Received: by 10.25.211.194 with SMTP id k185mr1223673lfg.119.1446690530293; Wed, 04 Nov 2015 18:28:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.124.202 with HTTP; Wed, 4 Nov 2015 18:28:30 -0800 (PST) In-Reply-To: <049DD8C5-0356-434A-A32C-EE8C4DF270FE@gmail.com> References: <562E53EF.9070707@joelhalpern.com> <9181AA70-7967-4625-8F2A-981ED8C04724@gmail.com> <7F7F2396-CF00-4362-AA7A-A410B395C20A@gmail.com> <049DD8C5-0356-434A-A32C-EE8C4DF270FE@gmail.com> From: Alberto Rodriguez-Natal Date: Thu, 5 Nov 2015 03:28:30 +0100 Message-ID: To: Damien Saucez Content-Type: multipart/alternative; boundary=001a1141805e2885a90523c1e3e3 Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] Way forward on 6830bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2015 02:29:01 -0000 --001a1141805e2885a90523c1e3e3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Adding to the discussion here, I have to said that Damien raised a very valid point. In my understanding RFC6830 is covering aspects both of control and data. I also agree that for me control-plane is something more than just RFC6833 and that there are aspects of it covered in RFC6830 and in other documents. I'm in favour of trying to avoid too much semantics discussion about what is what. Rather I think that be should think of it in a more pragmatic way. At the end of the day what we care is what we can do with the protocol, and what we want to do now is to be able to use the LISP control-plane standalone without being tied to the LISP data-plane. In that sense I think that we should ask ourselves the question, if I'm willing to use (for instance) VXLAN-GPE for encapsulation and LISP for the control-plane, which pieces of what is currently covered in RFC6830, RFC6833, etc, do I need to use? That is what for me should go into the "control-plane" document. The rest of the pieces of the LISP protocol that I didn't use since I had VXLAN-GPE, would be the "data-plane". Just my 2 cents here. Alberto On Thu, Nov 5, 2015 at 3:06 AM, Damien Saucez wrote: > > On 05 Nov 2015, at 10:48, Dino Farinacci wrote: > > > On 05 Nov 2015, at 10:33, Dino Farinacci wrote: > >> > >>>> Hello, > >>>> > >>>> By seeing Alberts presentation on SFC today I was just thinking that > we could > >>>> split 6830 in two documents. > >>>> > >>>> One document to present the data-plane (mostly Sec 5). > >>>> > >>>> One document to present the control-plane (mostly Sec 6). > >>>> > >>>> As Albert said the mapping system is generic (with LCAF). Therefore > it would > >>>> make it more logical (to me at least) to have a document to strictly > talk about > >>>> the mapping system and it would increase the appeal of the mapping > system by > >>>> not requiring people to care about the LISP encapsulation if they > only need the > >>>> mapping system function. > >>> > >>> The mapping system is in a separate document and spread across alt, > ddt, and ms specs. The control-plane text in RFC6830 is defining an API t= o > the mapping system. And I think you want it all in one place for > completeness. > >>> > >> > >> When I was talking about mapping system, I was talking about the > >> =E2=80=9CAPI=E2=80=9D (Map-Request, Map-Reply, Map-Register=E2=80=A6 )= . > >> > >> I understand that it is not straightforward to make it in a nice way, > but > >> the as LISP is about decoupling control-plane and data-plane it would > >> make sense to also decouple control and data-plane definition. > >> > >> Imagine you want someone to only implement the control-plane, how > >> does he know what to implement exactly to be fully compliant? > > > > This is clearly stated in RFC6830. That is, you can send a Map-Request > for any reason. It doesn=E2=80=99t have to be invoked by arrival of a pac= ket on an > ITR/RTR/PITR. Tools like lig and rig are examples of this. > > > > > Of course for someone who knows LISP it is trivial that it is separated. > The > issue is how to move forward and ensure that LISP control plane is not > bound at > all to a particular data-plane. Actually, since the beginning we say LIS= P > is > map-and-encap so it means two components mapping and encapsulation, that > seems > thus very logical to me to have to documents, one for "mapping", one for > =E2=80=9Cencapsulation". > > At a first glance it could look like just being marketing but actually > splitting > would allow both planes to be developed (and updated) in parallel. > > Damien Saucez > > > Dino > > > >> > >> Damien Saucez > >> > >>> Dino > >>> > >>>> > >>>> Cheers, > >>>> > >>>> Damien Saucez > >>>> > >>>> On 27 Oct 2015, at 01:25, Joel M. Halpern > wrote: > >>>> > >>>>> It seemed to us that there was likely some confusiona bout how we > expect to handle the revision of RCC 6830. The following is what we > currently expect. > >>>>> > >>>>> Once we have a new charter approved, the chairs will appoint an > editor for the revision of rfc6830. That may be one of the existing > authors, or a new person. We will ask for volunteers. > >>>>> > >>>>> Once we have an author, they will submit a starting ID called > draft-ietf-lisp-rfc6830bis-00 which will be identical in content to the > existing RFC. That may require assistance from the RFC Editor to ensure > that we get all the changes they made during final edit. > >>>>> > >>>>> At that point, we will use the trouble ticket system to record > issues that people bring up. We will also discuss on the list what chang= es > we wish to make according to the charter. Things will tehn proceed in th= e > usual fashion, using the trouble ticket system to help make sure we do no= t > drop any of the issues. > >>>>> > >>>>> Yours, > >>>>> Joel & Luigi > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>> > >> > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > --001a1141805e2885a90523c1e3e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Adding to the discussion here, I have to sa= id that Damien raised a very valid point. In my understanding RFC6830 is covering=20 aspects both of control and data. I also agree that for me control-plane is something more than just RFC6833 and that there are aspects of it=20 covered in RFC6830 and in other documents.

I'm in favour o= f trying to avoid too much semantics discussion about what is what.=20 Rather I think that be should think of it in a more pragmatic way. At=20 the end of the day what we care is what we can do with the protocol, and what we want to do now is to be able to use the LISP control-plane=20 standalone without being tied to the LISP data-plane.

In that=20 sense I think that we should ask ourselves the question, if I'm willing= =20 to use (for instance) VXLAN-GPE for encapsulation and LISP for the=20 control-plane, which pieces of what is currently covered in RFC6830,=20 RFC6833, etc, do I need to use? That is what for me should go into the=20 "control-plane" document. The rest of the pieces of the LISP prot= ocol=20 that I didn't use since I had VXLAN-GPE, would be the "data-plane&= quot;.

Just my 2 cents here.

Alberto

On Thu, Nov 5, 2015 at 3= :06 AM, Damien Saucez <damien.saucez@gmail.com> wrote:=

On 05 Nov 2015, at 10:48, Dino Farinacci <farinacci@gmail.com> wrote:

> On 05 Nov 2015, at 10:33, Dino Farinacci <farinacci@gmail.com> wrote:
>>
>>>> Hello,
>>>>
>>>> By seeing Alberts presentation on SFC today I was just thi= nking that we could
>>>> split 6830 in two documents.
>>>>
>>>> One document to present the data-plane (mostly Sec 5).
>>>>
>>>> One document to present the control-plane (mostly Sec 6).<= br> >>>>
>>>> As Albert said the mapping system is generic (with LCAF).= =C2=A0 Therefore it would
>>>> make it more logical (to me at least) to have a document t= o strictly talk about
>>>> the mapping system and it would increase the appeal of the= mapping system by
>>>> not requiring people to care about the LISP encapsulation = if they only need the
>>>> mapping system function.
>>>
>>> The mapping system is in a separate document and spread across= alt, ddt, and ms specs. The control-plane text in RFC6830 is defining an A= PI to the mapping system. And I think you want it all in one place for comp= leteness.
>>>
>>
>> When=C2=A0 I was talking about mapping system, I was talking about= the
>> =E2=80=9CAPI=E2=80=9D (Map-Request, Map-Reply, Map-Register=E2=80= =A6 ).
>>
>> I understand that it is not straightforward to make it in a nice w= ay, but
>> the as LISP is about decoupling control-plane and data-plane it wo= uld
>> make sense to also decouple control and data-plane definition.
>>
>> Imagine you want someone to only implement the control-plane, how<= br> >> does he know what to implement exactly to be fully compliant?
>
> This is clearly stated in RFC6830. That is, you can send a Map-Request= for any reason. It doesn=E2=80=99t have to be invoked by arrival of a pack= et on an ITR/RTR/PITR. Tools like lig and rig are examples of this.
>


Of course for someone who knows LISP it is trivial that it is separa= ted.=C2=A0 The
issue is how to move forward and ensure that LISP control plane is not boun= d at
all to a particular data-plane.=C2=A0 Actually, since the beginning we say = LISP is
map-and-encap so it means two components mapping and encapsulation, that se= ems
thus very logical to me to have to documents, one for "mapping", = one for
=E2=80=9Cencapsulation".

At a first glance it could look like just being marketing but actually spli= tting
would allow both planes to be developed (and updated) in parallel.

Damien Saucez

> Dino
>
>>
>> Damien Saucez
>>
>>> Dino
>>>
>>>>
>>>> Cheers,
>>>>
>>>> Damien Saucez
>>>>
>>>> On 27 Oct 2015, at 01:25, Joel M. Halpern <jmh@joelhalpern.com> wrote:
>>>>
>>>>> It seemed to us that there was likely some confusiona = bout how we expect to handle the revision of RCC 6830.=C2=A0 The following = is what we currently expect.
>>>>>
>>>>> Once we have a new charter approved, the chairs will a= ppoint an editor for the revision of rfc6830.=C2=A0 That may be one of the = existing authors, or a new person.=C2=A0 We will ask for volunteers.
>>>>>
>>>>> Once we have an author, they will submit a starting ID= called draft-ietf-lisp-rfc6830bis-00 which will be identical in content to= the existing RFC.=C2=A0 That may require assistance from the RFC Editor to= ensure that we get all the changes they made during final edit.
>>>>>
>>>>> At that point, we will use the trouble ticket system t= o record issues that people bring up.=C2=A0 We will also discuss on the lis= t what changes we wish to make according to the charter.=C2=A0 Things will = tehn proceed in the usual fashion, using the trouble ticket system to help = make sure we do not drop any of the issues.
>>>>>
>>>>> Yours,
>>>>> Joel & Luigi
>>>>>
>>>>> _______________________________________________
>>>>> 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/lis= p
>>>
>>
>

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

--001a1141805e2885a90523c1e3e3-- From nobody Wed Nov 4 18:42:04 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4961A0110 for ; Wed, 4 Nov 2015 18:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 6d0qdDAGWWjN for ; Wed, 4 Nov 2015 18:42:02 -0800 (PST) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::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 E74E71A016A for ; Wed, 4 Nov 2015 18:42:01 -0800 (PST) Received: by pasz6 with SMTP id z6so74091103pas.2 for ; Wed, 04 Nov 2015 18:42:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eQa7a2hdbVji13u32g20Sy4PSe/4Rzj33Ns7MRfd3jE=; b=j7wQ3Vxw9+90ZG+J9q6g1JTjZs5cx+RBgOCSWArm5uOiiWTPBq3ZuSRgkA/MAvIahq at+bj3lM4JPdt456NctQhoT8/FVjSSB2suliyuksHA3Y6xdRmDgnvhzYV1/1hbw5xbl6 TGGfYfCZxYMGBVpcqE9F7Ez+5pIGlOOqeVmenNRDy6TK+0wroExXD0ijJ6AxqJIqd4KU MYgfiLpxTQ+m7pvNIu2wa9jBnvCwZZJwnIDuDL0fqN1eayLjomJdAn/4p7C7URyJuMOd 5YVGy5+3w9e8KecUajHPz9aGN47L9mj25aho5VZUzDIn/JWMAnaIqzhDRGLDZf4HloK+ ig1g== X-Received: by 10.68.134.135 with SMTP id pk7mr6343714pbb.67.1446691321370; Wed, 04 Nov 2015 18:42:01 -0800 (PST) Received: from t20010c4000003080eca5c6c4a913ab7d.v6.meeting.ietf94.jp (t20010c4000003080eca5c6c4a913ab7d.v6.meeting.ietf94.jp. [2001:c40:0:3080:eca5:c6c4:a913:ab7d]) by smtp.gmail.com with ESMTPSA id ku1sm4574153pbc.47.2015.11.04.18.41.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 18:42:00 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Dino Farinacci In-Reply-To: <049DD8C5-0356-434A-A32C-EE8C4DF270FE@gmail.com> Date: Wed, 4 Nov 2015 18:41:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <562E53EF.9070707@joelhalpern.com> <9181AA70-7967-4625-8F2A-981ED8C04724@gmail.com> <7F7F2396-CF00-4362-AA7A-A410B395C20A@gmail.com> <049DD8C5-0356-434A-A32C-EE8C4DF270FE@gmail.com> To: Damien Saucez X-Mailer: Apple Mail (2.2104) Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] Way forward on 6830bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2015 02:42:03 -0000 > Of course for someone who knows LISP it is trivial that it is = separated. The > issue is how to move forward and ensure that LISP control plane is not = bound at > all to a particular data-plane. Actually, since the beginning we say = LISP is > map-and-encap so it means two components mapping and encapsulation, = that seems > thus very logical to me to have to documents, one for "mapping", one = for > =93encapsulation=94. If the new charter allows to incorporate additional data-planes, then = RFC6830bis could be structured to (1) indicate that multiple data-planes = can be used and (2) how more we can decouple the data-plane from the = control-plane. > At a first glance it could look like just being marketing but actually = splitting > would allow both planes to be developed (and updated) in parallel. There are pros and cons either way. Dino From nobody Wed Nov 4 18:43:04 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB611A03A3 for ; Wed, 4 Nov 2015 18:43:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 D623-qqTW0Bm for ; Wed, 4 Nov 2015 18:43:00 -0800 (PST) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::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 713BE1A016A for ; Wed, 4 Nov 2015 18:43:00 -0800 (PST) Received: by pacdm15 with SMTP id dm15so47466098pac.3 for ; Wed, 04 Nov 2015 18:43:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=g8wFgg2M1pDV3vgzt8ZH4yuCPSAxNvX0aZrrYHE8OFA=; b=z6fgENQkFbGgdP2EgpLA2ij5tnsDjnH8kdEAghKWOeQxeClXdDvU+c1H3VfVEUstcr ZXkJnRN5htENLoeGiU/C6Gw7jhYgQQYqrjo7XnEcOL7yz0DeJY6u2f0p9ginn7I6D81j JmvpbwpHVQ9bryasMcfDXvbcRU6eSVJXuMen4BskGDyURcNNQEewslrKwzA+VrYE00tH WSKq4hIQSM10CWp6trBOXDnmp4i0SaxuAlE64DhBjbsJOagHC0SiSwn81MGak7mqanle 0fz6QwCb+hMH036JDoTrMxwFzi7cMcmWFo1Po5hIvHIyo6t6KixOQCDX/wkxPgzvxrVA F0yw== X-Received: by 10.68.57.235 with SMTP id l11mr6547297pbq.26.1446691380189; Wed, 04 Nov 2015 18:43:00 -0800 (PST) Received: from t20010c4000003080eca5c6c4a913ab7d.v6.meeting.ietf94.jp (t20010c4000003080eca5c6c4a913ab7d.v6.meeting.ietf94.jp. [2001:c40:0:3080:eca5:c6c4:a913:ab7d]) by smtp.gmail.com with ESMTPSA id ku1sm4574153pbc.47.2015.11.04.18.42.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 18:42:59 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Dino Farinacci In-Reply-To: <563ABB62.4070608@cisco.com> Date: Wed, 4 Nov 2015 18:42:56 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <157D80EC-573F-4F11-9A58-D45B07F31A30@gmail.com> References: <562E53EF.9070707@joelhalpern.com> <9181AA70-7967-4625-8F2A-981ED8C04724@gmail.com> <7F7F2396-CF00-4362-AA7A-A410B395C20A@gmail.com> <049DD8C5-0356-434A-A32C-EE8C4DF270FE@gmail.com> <563ABB62.4070608@cisco.com> To: Fabio Maino X-Mailer: Apple Mail (2.2104) Archived-At: Cc: lisp@ietf.org Subject: Re: [lisp] Way forward on 6830bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2015 02:43:02 -0000 I certainly agree with your conclusions Fabio. Dino > On Nov 4, 2015, at 6:13 PM, Fabio Maino wrote: >=20 > On 11/5/15 11:06 AM, Damien Saucez wrote: >> On 05 Nov 2015, at 10:48, Dino Farinacci wrote: >>=20 >>> On 05 Nov 2015, at 10:33, Dino Farinacci = wrote: >>>>>> Hello, >>>>>>=20 >>>>>> By seeing Alberts presentation on SFC today I was just thinking = that we could >>>>>> split 6830 in two documents. >>>>>>=20 >>>>>> One document to present the data-plane (mostly Sec 5). >>>>>>=20 >>>>>> One document to present the control-plane (mostly Sec 6). >>>>>>=20 >>>>>> As Albert said the mapping system is generic (with LCAF). = Therefore it would >>>>>> make it more logical (to me at least) to have a document to = strictly talk about >>>>>> the mapping system and it would increase the appeal of the = mapping system by >>>>>> not requiring people to care about the LISP encapsulation if they = only need the >>>>>> mapping system function. >>>>> The mapping system is in a separate document and spread across = alt, ddt, and ms specs. The control-plane text in RFC6830 is defining an = API to the mapping system. And I think you want it all in one place for = completeness. >>>>>=20 >>>> When I was talking about mapping system, I was talking about the >>>> =93API=94 (Map-Request, Map-Reply, Map-Register=85 ). >>>>=20 >>>> I understand that it is not straightforward to make it in a nice = way, but >>>> the as LISP is about decoupling control-plane and data-plane it = would >>>> make sense to also decouple control and data-plane definition. >>>>=20 >>>> Imagine you want someone to only implement the control-plane, how >>>> does he know what to implement exactly to be fully compliant? >>> This is clearly stated in RFC6830. That is, you can send a = Map-Request for any reason. It doesn=92t have to be invoked by arrival = of a packet on an ITR/RTR/PITR. Tools like lig and rig are examples of = this. >>>=20 >>=20 >> Of course for someone who knows LISP it is trivial that it is = separated. The >> issue is how to move forward and ensure that LISP control plane is = not bound at >> all to a particular data-plane. Actually, since the beginning we say = LISP is >> map-and-encap so it means two components mapping and encapsulation, = that seems >> thus very logical to me to have to documents, one for "mapping", one = for >> =93encapsulation". >>=20 >> At a first glance it could look like just being marketing but = actually splitting >> would allow both planes to be developed (and updated) in parallel. >=20 >=20 > Damien, > I think this could be a good idea. Too many people still associate = LISP mostly with the encap (and it looks like too many don't read past = the title of the RFC... :-( >=20 > We should also do a better work of explaining that LISP CP can be used = as generic mapping service for overlays (not only for on-demand LISP = tunnel provisioning). >=20 > In retrospective we should have presented the LISP/NSH draft in SFC as = well.There might be more SFC use cases that can be addressed by the LISP = CP. It'd be helpful to have the people in SFC give a thought to the = concept of map assisted overlays. >=20 > Fabio >=20 >=20 >>=20 >> Damien Saucez >>=20 >>> Dino >>>=20 >>>> Damien Saucez >>>>=20 >>>>> Dino >>>>>=20 >>>>>> Cheers, >>>>>>=20 >>>>>> Damien Saucez >>>>>>=20 >>>>>> On 27 Oct 2015, at 01:25, Joel M. Halpern = wrote: >>>>>>=20 >>>>>>> It seemed to us that there was likely some confusiona bout how = we expect to handle the revision of RCC 6830. The following is what we = currently expect. >>>>>>>=20 >>>>>>> Once we have a new charter approved, the chairs will appoint an = editor for the revision of rfc6830. That may be one of the existing = authors, or a new person. We will ask for volunteers. >>>>>>>=20 >>>>>>> Once we have an author, they will submit a starting ID called = draft-ietf-lisp-rfc6830bis-00 which will be identical in content to the = existing RFC. That may require assistance from the RFC Editor to ensure = that we get all the changes they made during final edit. >>>>>>>=20 >>>>>>> At that point, we will use the trouble ticket system to record = issues that people bring up. We will also discuss on the list what = changes we wish to make according to the charter. Things will tehn = proceed in the usual fashion, using the trouble ticket system to help = make sure we do not drop any of the issues. >>>>>>>=20 >>>>>>> Yours, >>>>>>> Joel & Luigi >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> 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 >> _______________________________________________ >> 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 Wed Nov 4 18:43:56 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E86F1A1A7C for ; Wed, 4 Nov 2015 18:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 JlrtMTryurxc for ; Wed, 4 Nov 2015 18:43:54 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::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 C2E051A1A5B for ; Wed, 4 Nov 2015 18:43:54 -0800 (PST) Received: by pacdm15 with SMTP id dm15so47490241pac.3 for ; Wed, 04 Nov 2015 18:43:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ID94cPsOeIFOM85S7iWUY1iNiR8ijtWf0QUK7gaY5V8=; b=sSg7FI4WSXPJnm6MBWNUlDo+9D+sGBQFN8IcfSCYDx1VWKTX/734Hyp5Nl64gZC5zl lQFuAneA3wesGHpBQUvwySGS6S8BDx1VIvSv3c4lsPawnxTcXJk9il+p/OI9X0JBD6/R /xZJXQrvhhwC1XPhoZelylncsDwzt0EobaAz2p3DPqfO3zJYcVeKbnu0bW3t6EFtPnOW BLPeHSLVfQGdrhMcMLzCQrW1YXRRPInuG7ahl7Ob7BNqzjNlsas9dH/PF/wya4/rrZcF 34W6Stctr8mJ+9BRKVGgj83fxwTiBVFjbbzcFJgyTYEErRrj6rXHOfs5Q+jkBHylWXes acYg== X-Received: by 10.66.62.225 with SMTP id b1mr921956pas.66.1446691434405; Wed, 04 Nov 2015 18:43:54 -0800 (PST) Received: from t20010c4000003080eca5c6c4a913ab7d.v6.meeting.ietf94.jp (t20010c4000003080eca5c6c4a913ab7d.v6.meeting.ietf94.jp. [2001:c40:0:3080:eca5:c6c4:a913:ab7d]) by smtp.gmail.com with ESMTPSA id ku1sm4574153pbc.47.2015.11.04.18.43.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 18:43:53 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Dino Farinacci In-Reply-To: Date: Wed, 4 Nov 2015 18:43:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <37B7213D-0640-460F-8583-0A4F413283D4@gmail.com> References: <562E53EF.9070707@joelhalpern.com> <9181AA70-7967-4625-8F2A-981ED8C04724@gmail.com> <7F7F2396-CF00-4362-AA7A-A410B395C20A@gmail.com> <049DD8C5-0356-434A-A32C-EE8C4DF270FE@gmail.com> To: Alberto Rodriguez-Natal X-Mailer: Apple Mail (2.2104) Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] Way forward on 6830bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2015 02:43:56 -0000 > In that sense I think that we should ask ourselves the question, if = I'm willing to use (for instance) VXLAN-GPE for encapsulation and LISP = for the control-plane, which pieces of what is currently covered in = RFC6830, RFC6833, etc, do I need to use? That is what for me should go = into the "control-plane" document. The rest of the pieces of the LISP = protocol that I didn't use since I had VXLAN-GPE, would be the = "data-plane=E2=80=9D. Agree as well. Dino From nobody Thu Nov 5 06:12:37 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC201B2B79 for ; Thu, 5 Nov 2015 06:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 ZmSimGgIpsET for ; Thu, 5 Nov 2015 06:12:33 -0800 (PST) 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 A1F1D1B2CB4 for ; Thu, 5 Nov 2015 06:12:25 -0800 (PST) Received: by pacdm15 with SMTP id dm15so64646643pac.3 for ; Thu, 05 Nov 2015 06:12:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ug6qwcAmSWqsOFBeLBevN3p96V5tNNKg+rYfYPTB2Y0=; b=CEzJrgcOEg7Hu+gDly3xKpEHKo5x4YQS0XaR9Ri0B5rJD2NRHq7QJ78aRLIfjpNyBB VqWwUaO+WDICdNqByOd3oXGn+3i+L7tFNpoOU9xU7ZO1uT7GUvRI84JbRNIytt0xfol5 AszS+Jmh62HFfm6qyClSPbrgMB17MoZVeYsrz/JXuSmICCMntZxonraEKSJuTM0dE2F9 x2RCJKZg+unXmfcPvhZDIYGQAWbhZoLDMzZ8yQWcSjuTzz5EGrXEcP8o5thZNYCEharB 9EAoXeXDZTEEeI4T0zC0vSYOoUBVIoiiMuVweYUNMJQnckIuZej6KDryVvlNc3OiGu8q czcw== X-Received: by 10.66.188.49 with SMTP id fx17mr9638572pac.95.1446732745295; Thu, 05 Nov 2015 06:12:25 -0800 (PST) Received: from ?IPv6:2001:420:c0c8:1003::1f? ([2001:420:c0c8:1003::1f]) by smtp.gmail.com with ESMTPSA id ha3sm8283560pbb.28.2015.11.05.06.12.22 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 Nov 2015 06:12:24 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Content-Type: text/plain; charset=windows-1252 From: Florin Coras In-Reply-To: <157D80EC-573F-4F11-9A58-D45B07F31A30@gmail.com> Date: Thu, 5 Nov 2015 15:12:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9D4B8406-D05B-4DB5-AC3E-2F523F8E42A0@gmail.com> References: <562E53EF.9070707@joelhalpern.com> <9181AA70-7967-4625-8F2A-981ED8C04724@gmail.com> <7F7F2396-CF00-4362-AA7A-A410B395C20A@gmail.com> <049DD8C5-0356-434A-A32C-EE8C4DF270FE@gmail.com> <563ABB62.4070608@cisco.com> <157D80EC-573F-4F11-9A58-D45B07F31A30@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: lisp@ietf.org Subject: Re: [lisp] Way forward on 6830bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2015 14:12:35 -0000 Definitely agree with this as well. As Damien mentioned, RFC6830 convolutes control-plane API definition and = semantics with data-plane operation. While I believe there should be a = section treating tunnel router interaction with the mapping-system in = RFC6830, the control-plane API definition (i.e., syntax and semantic of = messages exchanged by tunnel routers with the mapping-system), should be = moved to a separate document.=20 Florin =20 > On Nov 5, 2015, at 3:42 AM, Dino Farinacci = wrote: >=20 > I certainly agree with your conclusions Fabio. >=20 > Dino >=20 >> On Nov 4, 2015, at 6:13 PM, Fabio Maino wrote: >>=20 >> On 11/5/15 11:06 AM, Damien Saucez wrote: >>> On 05 Nov 2015, at 10:48, Dino Farinacci = wrote: >>>=20 >>>> On 05 Nov 2015, at 10:33, Dino Farinacci = wrote: >>>>>>> Hello, >>>>>>>=20 >>>>>>> By seeing Alberts presentation on SFC today I was just thinking = that we could >>>>>>> split 6830 in two documents. >>>>>>>=20 >>>>>>> One document to present the data-plane (mostly Sec 5). >>>>>>>=20 >>>>>>> One document to present the control-plane (mostly Sec 6). >>>>>>>=20 >>>>>>> As Albert said the mapping system is generic (with LCAF). = Therefore it would >>>>>>> make it more logical (to me at least) to have a document to = strictly talk about >>>>>>> the mapping system and it would increase the appeal of the = mapping system by >>>>>>> not requiring people to care about the LISP encapsulation if = they only need the >>>>>>> mapping system function. >>>>>> The mapping system is in a separate document and spread across = alt, ddt, and ms specs. The control-plane text in RFC6830 is defining an = API to the mapping system. And I think you want it all in one place for = completeness. >>>>>>=20 >>>>> When I was talking about mapping system, I was talking about the >>>>> =93API=94 (Map-Request, Map-Reply, Map-Register=85 ). >>>>>=20 >>>>> I understand that it is not straightforward to make it in a nice = way, but >>>>> the as LISP is about decoupling control-plane and data-plane it = would >>>>> make sense to also decouple control and data-plane definition. >>>>>=20 >>>>> Imagine you want someone to only implement the control-plane, how >>>>> does he know what to implement exactly to be fully compliant? >>>> This is clearly stated in RFC6830. That is, you can send a = Map-Request for any reason. It doesn=92t have to be invoked by arrival = of a packet on an ITR/RTR/PITR. Tools like lig and rig are examples of = this. >>>>=20 >>>=20 >>> Of course for someone who knows LISP it is trivial that it is = separated. The >>> issue is how to move forward and ensure that LISP control plane is = not bound at >>> all to a particular data-plane. Actually, since the beginning we = say LISP is >>> map-and-encap so it means two components mapping and encapsulation, = that seems >>> thus very logical to me to have to documents, one for "mapping", one = for >>> =93encapsulation". >>>=20 >>> At a first glance it could look like just being marketing but = actually splitting >>> would allow both planes to be developed (and updated) in parallel. >>=20 >>=20 >> Damien, >> I think this could be a good idea. Too many people still associate = LISP mostly with the encap (and it looks like too many don't read past = the title of the RFC... :-( >>=20 >> We should also do a better work of explaining that LISP CP can be = used as generic mapping service for overlays (not only for on-demand = LISP tunnel provisioning). >>=20 >> In retrospective we should have presented the LISP/NSH draft in SFC = as well.There might be more SFC use cases that can be addressed by the = LISP CP. It'd be helpful to have the people in SFC give a thought to the = concept of map assisted overlays. >>=20 >> Fabio >>=20 >>=20 >>>=20 >>> Damien Saucez >>>=20 >>>> Dino >>>>=20 >>>>> Damien Saucez >>>>>=20 >>>>>> Dino >>>>>>=20 >>>>>>> Cheers, >>>>>>>=20 >>>>>>> Damien Saucez >>>>>>>=20 >>>>>>> On 27 Oct 2015, at 01:25, Joel M. Halpern = wrote: >>>>>>>=20 >>>>>>>> It seemed to us that there was likely some confusiona bout how = we expect to handle the revision of RCC 6830. The following is what we = currently expect. >>>>>>>>=20 >>>>>>>> Once we have a new charter approved, the chairs will appoint an = editor for the revision of rfc6830. That may be one of the existing = authors, or a new person. We will ask for volunteers. >>>>>>>>=20 >>>>>>>> Once we have an author, they will submit a starting ID called = draft-ietf-lisp-rfc6830bis-00 which will be identical in content to the = existing RFC. That may require assistance from the RFC Editor to ensure = that we get all the changes they made during final edit. >>>>>>>>=20 >>>>>>>> At that point, we will use the trouble ticket system to record = issues that people bring up. We will also discuss on the list what = changes we wish to make according to the charter. Things will tehn = proceed in the usual fashion, using the trouble ticket system to help = make sure we do not drop any of the issues. >>>>>>>>=20 >>>>>>>> Yours, >>>>>>>> Joel & Luigi >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> 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 >>> _______________________________________________ >>> 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 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Thu Nov 5 10:38:07 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2821A6F11 for ; Thu, 5 Nov 2015 10:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Fmq3H-wYs03T for ; Thu, 5 Nov 2015 10:38:04 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877F51A6F0B for ; Thu, 5 Nov 2015 10:38:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7007; q=dns/txt; s=iport; t=1446748685; x=1447958285; h=from:to:subject:date:message-id:mime-version; bh=kYT9/RsgG+oGi+NFgLP94RtKaTpysmIozd2gvTntvOg=; b=FmEGoLFffpJaNX3Vu+eh6d1byNNMl/vRYk6POyB+K7qNvFJQ74+qf33l 0j2k1rSauuIk4mJkFmV5T6/Nmx+DF5GrjdOftupKdCKOgi4uee1G8D1l0 TZxCrI+FUEcRtWvK8Wa1Y2iOSuEGD+/tQF0lL/u2pZ6WkHvAqNrcpS45/ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D1AQDdoTtW/5tdJa1egm5NU28Gu2iCGgENgV6HRjgUAQEBAQEBAX8LhDUBAQEELV4BGQQBAWEPDgkBBBMIiCahG6BvAQEBAQEBBAEBAQEBAQEBG5ULBZZIAY0bnEgBHwEBQoQEcoQYgQcBAQE X-IronPort-AV: E=Sophos;i="5.20,248,1444694400"; d="scan'208,217";a="204124947" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP; 05 Nov 2015 18:37:42 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tA5IbfHc032167 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 5 Nov 2015 18:37:41 GMT Received: from xch-aln-006.cisco.com (173.36.7.16) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 5 Nov 2015 12:37:41 -0600 Received: from xch-aln-006.cisco.com ([173.36.7.16]) by XCH-ALN-006.cisco.com ([173.36.7.16]) with mapi id 15.00.1104.000; Thu, 5 Nov 2015 12:37:40 -0600 From: "Amjad Inamdar (amjads)" To: "lisp@ietf.org" Thread-Topic: LISP crypto Thread-Index: AdEX+QgCejSjQFO0RFuQI9IxGCz84Q== Date: Thu, 5 Nov 2015 18:37:40 +0000 Message-ID: <0289fb1a84a84cff89fa92a4559c829c@XCH-ALN-006.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.79.253] Content-Type: multipart/alternative; boundary="_000_0289fb1a84a84cff89fa92a4559c829cXCHALN006ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [lisp] LISP crypto X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2015 18:38:06 -0000 --_000_0289fb1a84a84cff89fa92a4559c829cXCHALN006ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Brian/Dino, The key material derivation proposed in draft-ietf-lisp-crypto is based on = Diffie-Hellman which is not Quantum Computer resistant. There is some work = underway to make IKE that uses DH for key derivation Quantum Computer safe.= Might be a good idea to consider this for lisp-crypto as well. Thanks, -Amjad From: Amjad Inamdar (amjads) Sent: 03 November 2015 PM 12:33 To: 'lisp@ietf.org' Subject: LISP NAT Traversal Hi, It will be useful if LISP NAT traversal draft (draft-ermagan-lisp-nat-trave= rsal) can elaborate on the following 1) Why LISP NAT traversal cannot be accomplished without RTR (another netwo= rk entity) which has implications on deployability, complexity and latency.= There are other protocols (e.g IKE/IPsec) that achieve NAT-D and NAT-T wit= hout the need for additional network entity. 2) Some more details on RTR deployment - location of RTR in the LISP deployment like there are recommendations on = PITR/PETR deployments - is RTR shared across LISP sites behind NAT or each site needs a dedicated= RTR - what if RTR is behind another NAT (SP-NAT) 3) How is multiple-NAT handled (e.g. enterprise and SP NAT) Thanks, -Amjad Inamdar CISSP, CCNP R&S, CCNP Security, CCDP, CCSK Senior Technical Leader CSG PI Services Security - India --_000_0289fb1a84a84cff89fa92a4559c829cXCHALN006ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Brian/Dino,

 

The key material deriv= ation proposed in draft-ietf-lisp-crypto is based on Diffie-Hellman which i= s not Quantum Computer resistant. There is some work underway to make IKE t= hat uses DH for key derivation Quantum Computer safe. Might be a good idea to consider this for lisp-crypto as we= ll.

 

Thanks,

-Amjad

 

From:= Amjad Inamdar (amjads)
Sent: 03 November 2015 PM 12:33
To: 'lisp@ietf.org'
Subject: LISP NAT Traversal

 

Hi,

 

It will be useful if LISP NAT traversal draft (draft= -ermagan-lisp-nat-traversal) can elaborate on the following

 

1) Why LISP NAT traversal cannot be accomplished wit= hout RTR (another network entity) which has implications on deployability, = complexity and latency. There are other protocols (e.g IKE/IPsec) that achi= eve NAT-D and NAT-T without the need for additional network entity.

 

2) Some more details on RTR deployment

- location of RTR in the LISP deployment like there = are recommendations on PITR/PETR deployments

- is RTR shared across LISP sites behind NAT or each= site needs a dedicated RTR

- what if RTR is behind another NAT (SP-NAT)

 

3) How is multiple-NAT handled (e.g. enterprise and = SP NAT)

 

Thanks,

-Amjad= Inamdar CISSP, CCNP R&S, CCNP Security, CCDP, CCSK

Senior Te= chnical Leader

CSG PI Se= rvices Security - India  

 

--_000_0289fb1a84a84cff89fa92a4559c829cXCHALN006ciscocom_-- From nobody Thu Nov 5 16:04:05 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD741A0405 for ; Thu, 5 Nov 2015 16:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 3jdySYUG0DQz for ; Thu, 5 Nov 2015 16:04:03 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::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 CD5161A03C7 for ; Thu, 5 Nov 2015 16:04:02 -0800 (PST) Received: by pasz6 with SMTP id z6so106202891pas.2 for ; Thu, 05 Nov 2015 16:04:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vHR6L+EMu/CU2geQTdj7tRpxm9yB5HQ/CSIo8Z2dmRw=; b=vXp9dYcgKzQjkqITXe3hr9Qv/M5etKj0ZoxArphTVaFG6zYzIK8F4UOAe68+JpuN1G 35efmw9YQjBcxiEqSmxJ+eqqllCSiZKEgTUlqQGsOT4DTfDKOr2vWk+4VRxIlv7T8maY fXVcnXPIY6+Jcql2R1lOWrOdO1J6rguaDtHnpZ6fE7TB419DvLDQV1NaZ0bl0CqDIadk I5rz9FtHqrWVw0kAhYTRQyxsb5pPQLeDJStOmI7gR2jAiKqjcIMWjHTx8Ra47somoHi/ F6UAYBFoOgInt6rbrOIxkHwZbtzaWOBOmhhgLAf1JCk0GUw4A4wrR3aw5pnCCYCZexiX iajQ== X-Received: by 10.66.181.234 with SMTP id dz10mr13086835pac.51.1446768242311; Thu, 05 Nov 2015 16:04:02 -0800 (PST) Received: from t20010c400000308028a91aeec12dfbcc.v6.meeting.ietf94.jp (t20010c400000308028a91aeec12dfbcc.v6.meeting.ietf94.jp. [2001:c40:0:3080:28a9:1aee:c12d:fbcc]) by smtp.gmail.com with ESMTPSA id sz7sm9958293pbc.57.2015.11.05.16.04.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Nov 2015 16:04:01 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Dino Farinacci In-Reply-To: <0289fb1a84a84cff89fa92a4559c829c@XCH-ALN-006.cisco.com> Date: Thu, 5 Nov 2015 16:03:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0289fb1a84a84cff89fa92a4559c829c@XCH-ALN-006.cisco.com> To: "Amjad Inamdar (amjads)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "lisp@ietf.org" Subject: Re: [lisp] LISP crypto X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 06 Nov 2015 00:04:04 -0000 Amjad, we are aware of the QC-safe work going on in CFRG. We are = following it but it is very researchy at this point. We can add some = text indicating that we=E2=80=99ll follow any CFRG/SAAG recommendations = (or any security area working group=E2=80=99s recommendation) on using = QC-safe technology. If there is anything specific you want us to look at with IKE, please = send some pointers. Thanks. Dino > On Nov 5, 2015, at 10:37 AM, Amjad Inamdar (amjads) = wrote: >=20 > Hi Brian/Dino, > =20 > The key material derivation proposed in draft-ietf-lisp-crypto is = based on Diffie-Hellman which is not Quantum Computer resistant. There = is some work underway to make IKE that uses DH for key derivation = Quantum Computer safe. Might be a good idea to consider this for = lisp-crypto as well. > =20 > Thanks, > -Amjad > =20 > From: Amjad Inamdar (amjads)=20 > Sent: 03 November 2015 PM 12:33 > To: 'lisp@ietf.org' > Subject: LISP NAT Traversal > =20 > Hi, > =20 > It will be useful if LISP NAT traversal draft = (draft-ermagan-lisp-nat-traversal) can elaborate on the following > =20 > 1) Why LISP NAT traversal cannot be accomplished without RTR (another = network entity) which has implications on deployability, complexity and = latency. There are other protocols (e.g IKE/IPsec) that achieve NAT-D = and NAT-T without the need for additional network entity. > =20 > 2) Some more details on RTR deployment > - location of RTR in the LISP deployment like there are = recommendations on PITR/PETR deployments > - is RTR shared across LISP sites behind NAT or each site needs a = dedicated RTR > - what if RTR is behind another NAT (SP-NAT) > =20 > 3) How is multiple-NAT handled (e.g. enterprise and SP NAT) > =20 > Thanks, > -Amjad Inamdar CISSP, CCNP R&S, CCNP Security, CCDP, CCSK > Senior Technical Leader > CSG PI Services Security - India =20 > =20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Thu Nov 5 16:23:49 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189FE1A6FAC for ; Thu, 5 Nov 2015 16:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 gyGZhkqdYG1W for ; Thu, 5 Nov 2015 16:23:45 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B65931A6F9B for ; Thu, 5 Nov 2015 16:23:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CBABBBE25; Fri, 6 Nov 2015 00:23:43 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9cU0a0CAkc8; Fri, 6 Nov 2015 00:23:42 +0000 (GMT) Received: from [133.93.44.14] (dhcp-44-14.meeting.ietf94.jp [133.93.44.14]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B5C02BDF9; Fri, 6 Nov 2015 00:23:40 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1446769422; bh=xQJEwfWbbVmZJYHAd7HkCstv0QtKgTZt3YMzNFjxWP4=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=JEAxkBZaKGC9+2idtJdw2CBI6Fq6f36cTCiVKOEeM+Cboom+TNuKoLlnj1rSid7aS dzln5q5pgRJTRW64aFi7j9z9VrbzT30+NvQZ7LI7kCoqL6wzxUQvspC8+zZ2Sj5ig7 KFnkoVzTFSdyHbsHXeebxkQjUqYV9ni31QaB17fk= To: Dino Farinacci , "Amjad Inamdar (amjads)" References: <0289fb1a84a84cff89fa92a4559c829c@XCH-ALN-006.cisco.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <563BF308.3010407@cs.tcd.ie> Date: Fri, 6 Nov 2015 00:23:36 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "lisp@ietf.org" Subject: Re: [lisp] LISP crypto X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 06 Nov 2015 00:23:48 -0000 On 06/11/15 00:03, Dino Farinacci wrote: > Amjad, we are aware of the QC-safe work going on in CFRG. We are > following it but it is very researchy at this point. Correct. It would be premature IMO to try to incorporate any functionality that aims to mitigate QC attacks against asymmetric crypto since we're not at a point where we know how to do that effectively and efficiently. > We can add some > text indicating that we’ll follow any CFRG/SAAG recommendations (or > any security area working group’s recommendation) on using QC-safe > technology. I don't think that's needed myself. S. > > If there is anything specific you want us to look at with IKE, please > send some pointers. Thanks. > > Dino > >> On Nov 5, 2015, at 10:37 AM, Amjad Inamdar (amjads) >> wrote: >> >> Hi Brian/Dino, >> >> The key material derivation proposed in draft-ietf-lisp-crypto is >> based on Diffie-Hellman which is not Quantum Computer resistant. >> There is some work underway to make IKE that uses DH for key >> derivation Quantum Computer safe. Might be a good idea to consider >> this for lisp-crypto as well. >> >> Thanks, -Amjad >> >> From: Amjad Inamdar (amjads) Sent: 03 November 2015 PM 12:33 To: >> 'lisp@ietf.org' Subject: LISP NAT Traversal >> >> Hi, >> >> It will be useful if LISP NAT traversal draft >> (draft-ermagan-lisp-nat-traversal) can elaborate on the following >> >> 1) Why LISP NAT traversal cannot be accomplished without RTR >> (another network entity) which has implications on deployability, >> complexity and latency. There are other protocols (e.g IKE/IPsec) >> that achieve NAT-D and NAT-T without the need for additional >> network entity. >> >> 2) Some more details on RTR deployment - location of RTR in the >> LISP deployment like there are recommendations on PITR/PETR >> deployments - is RTR shared across LISP sites behind NAT or each >> site needs a dedicated RTR - what if RTR is behind another NAT >> (SP-NAT) >> >> 3) How is multiple-NAT handled (e.g. enterprise and SP NAT) >> >> Thanks, -Amjad Inamdar CISSP, CCNP R&S, CCNP Security, CCDP, CCSK >> Senior Technical Leader CSG PI Services Security - India >> >> _______________________________________________ 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 > From nobody Thu Nov 5 16:36:28 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6AC61A6FFE for ; Thu, 5 Nov 2015 16:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 fQAQt4imfvIq for ; Thu, 5 Nov 2015 16:36:26 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::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 4023B1A6FF1 for ; Thu, 5 Nov 2015 16:36:26 -0800 (PST) Received: by pasz6 with SMTP id z6so107049389pas.2 for ; Thu, 05 Nov 2015 16:36:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uU3RK9MhcjarH0Pw2XhSFSFU+LVwoQRB9rKz6+ZWZjk=; b=z8VRv5EU6Hftc/P3/jRts9DfwIaKb6v5UJUQoKsSXsC3jco48vk+0cfBYe5SSSOKIa AUtI0AGJBynHRp/zA5v1uIzA/tZNBTACiC0rAxJBedaQN3jdqCxXnPQfsBkcypUro7Vh jx/c11lXYliUw9oAVtA3xQWlbkn/uV1WaZiyyE7Gk5ncZR6ezGnqhyjwdc3HstgVCzYX TVxikQBvkRDa3vJVpY1pRTmuPiDU6nJYoxSCykcHTq9i8hI4DA38NqakRxYRVXstZp0a FrViK5e+WEuoNZffS6zdKc3hr0iFgzCRa0HKwjjfwNx8WMK0YjQR/CKDqc/aA0dXB581 T+3Q== X-Received: by 10.68.227.69 with SMTP id ry5mr13575344pbc.148.1446770185941; Thu, 05 Nov 2015 16:36:25 -0800 (PST) Received: from t20010c400000308028a91aeec12dfbcc.v6.meeting.ietf94.jp (t20010c400000308028a91aeec12dfbcc.v6.meeting.ietf94.jp. [2001:c40:0:3080:28a9:1aee:c12d:fbcc]) by smtp.gmail.com with ESMTPSA id ho3sm10080452pbb.18.2015.11.05.16.36.24 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Nov 2015 16:36:25 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Dino Farinacci In-Reply-To: <563BF308.3010407@cs.tcd.ie> Date: Thu, 5 Nov 2015 16:36:22 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4651FF16-9710-47D5-B1CA-0CC72C0B69E9@gmail.com> References: <0289fb1a84a84cff89fa92a4559c829c@XCH-ALN-006.cisco.com> <563BF308.3010407@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "lisp@ietf.org" Subject: Re: [lisp] LISP crypto X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 06 Nov 2015 00:36:28 -0000 Okay, thanks for input Stephen, appreciated. Dino > On Nov 5, 2015, at 4:23 PM, Stephen Farrell = wrote: >=20 >=20 >=20 > On 06/11/15 00:03, Dino Farinacci wrote: >> Amjad, we are aware of the QC-safe work going on in CFRG. We are >> following it but it is very researchy at this point.=20 >=20 > Correct. It would be premature IMO to try to incorporate any > functionality that aims to mitigate QC attacks against > asymmetric crypto since we're not at a point where we know how > to do that effectively and efficiently. >=20 >> We can add some >> text indicating that we=E2=80=99ll follow any CFRG/SAAG = recommendations (or >> any security area working group=E2=80=99s recommendation) on using = QC-safe >> technology. >=20 > I don't think that's needed myself. >=20 > S. >=20 >>=20 >> If there is anything specific you want us to look at with IKE, please >> send some pointers. Thanks. >>=20 >> Dino >>=20 >>> On Nov 5, 2015, at 10:37 AM, Amjad Inamdar (amjads) >>> wrote: >>>=20 >>> Hi Brian/Dino, >>>=20 >>> The key material derivation proposed in draft-ietf-lisp-crypto is >>> based on Diffie-Hellman which is not Quantum Computer resistant. >>> There is some work underway to make IKE that uses DH for key >>> derivation Quantum Computer safe. Might be a good idea to consider >>> this for lisp-crypto as well. >>>=20 >>> Thanks, -Amjad >>>=20 >>> From: Amjad Inamdar (amjads) Sent: 03 November 2015 PM 12:33 To: >>> 'lisp@ietf.org' Subject: LISP NAT Traversal >>>=20 >>> Hi, >>>=20 >>> It will be useful if LISP NAT traversal draft >>> (draft-ermagan-lisp-nat-traversal) can elaborate on the following >>>=20 >>> 1) Why LISP NAT traversal cannot be accomplished without RTR >>> (another network entity) which has implications on deployability, >>> complexity and latency. There are other protocols (e.g IKE/IPsec) >>> that achieve NAT-D and NAT-T without the need for additional >>> network entity. >>>=20 >>> 2) Some more details on RTR deployment - location of RTR in the >>> LISP deployment like there are recommendations on PITR/PETR >>> deployments - is RTR shared across LISP sites behind NAT or each >>> site needs a dedicated RTR - what if RTR is behind another NAT >>> (SP-NAT) >>>=20 >>> 3) How is multiple-NAT handled (e.g. enterprise and SP NAT) >>>=20 >>> Thanks, -Amjad Inamdar CISSP, CCNP R&S, CCNP Security, CCDP, CCSK=20 >>> Senior Technical Leader CSG PI Services Security - India >>>=20 >>> _______________________________________________ lisp mailing list=20 >>> lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp >>=20 >> _______________________________________________ lisp mailing list=20 >> lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp >>=20 From nobody Thu Nov 5 16:40:51 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B4A1A7000 for ; Thu, 5 Nov 2015 16:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 NiVXciG6lh7J for ; Thu, 5 Nov 2015 16:40:48 -0800 (PST) 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 006581A6FF9 for ; Thu, 5 Nov 2015 16:40:47 -0800 (PST) Received: by oiww189 with SMTP id w189so33682813oiw.3 for ; Thu, 05 Nov 2015 16:40:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=cpQQT1XO3SH7cJ4Qj3TP3kbrGJQ8CRl3b2CkpL2sf9Y=; b=mIWnT1Y0JGGQefJIdp6REiLosmmRlVVo4CWIfLYlmne6f+SC39rOoTLhSzdNvBxEeh S79sOhPyiEak7rgHETiXd0l8WY6a4dQlU5EGZT5onACaSJa4xHc/fY4FkrPM6s9tXAQF zgSUEBUHWwcGh6TjSbco4CBKrGrj4BB9XRhENioPFEqLNl1WGYxW9OlDTMmtXrb/RnJO GIBGo+oFJhTdld2gBDImGNGgxed5Gtx4WwCdVoLr1DH9IgXdIgahF5Mzul7EnQ2z/ZhG QFBDPppCNebXv1N+ikq7YDm6VKM/B3VURKAgTsDRFnmY74enDBn+YjRZ8iYEvU0KC78Q 773A== MIME-Version: 1.0 X-Received: by 10.202.229.141 with SMTP id c135mr6379352oih.109.1446770447487; Thu, 05 Nov 2015 16:40:47 -0800 (PST) Received: by 10.182.120.73 with HTTP; Thu, 5 Nov 2015 16:40:47 -0800 (PST) In-Reply-To: <9D4B8406-D05B-4DB5-AC3E-2F523F8E42A0@gmail.com> References: <562E53EF.9070707@joelhalpern.com> <9181AA70-7967-4625-8F2A-981ED8C04724@gmail.com> <7F7F2396-CF00-4362-AA7A-A410B395C20A@gmail.com> <049DD8C5-0356-434A-A32C-EE8C4DF270FE@gmail.com> <563ABB62.4070608@cisco.com> <157D80EC-573F-4F11-9A58-D45B07F31A30@gmail.com> <9D4B8406-D05B-4DB5-AC3E-2F523F8E42A0@gmail.com> Date: Fri, 6 Nov 2015 09:40:47 +0900 Message-ID: From: Albert Cabellos To: Florin Coras Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "lisp@ietf.org" Subject: Re: [lisp] Way forward on 6830bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 06 Nov 2015 00:40:50 -0000 +1 to this Albert On Thu, Nov 5, 2015 at 11:12 PM, Florin Coras wrot= e: > Definitely agree with this as well. > > As Damien mentioned, RFC6830 convolutes control-plane API definition and = semantics with data-plane operation. While I believe there should be a sect= ion treating tunnel router interaction with the mapping-system in RFC6830, = the control-plane API definition (i.e., syntax and semantic of messages exc= hanged by tunnel routers with the mapping-system), should be moved to a sep= arate document. > > Florin > >> On Nov 5, 2015, at 3:42 AM, Dino Farinacci wrote: >> >> I certainly agree with your conclusions Fabio. >> >> Dino >> >>> On Nov 4, 2015, at 6:13 PM, Fabio Maino wrote: >>> >>> On 11/5/15 11:06 AM, Damien Saucez wrote: >>>> On 05 Nov 2015, at 10:48, Dino Farinacci wrote: >>>> >>>>> On 05 Nov 2015, at 10:33, Dino Farinacci wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> By seeing Alberts presentation on SFC today I was just thinking th= at we could >>>>>>>> split 6830 in two documents. >>>>>>>> >>>>>>>> One document to present the data-plane (mostly Sec 5). >>>>>>>> >>>>>>>> One document to present the control-plane (mostly Sec 6). >>>>>>>> >>>>>>>> As Albert said the mapping system is generic (with LCAF). Therefo= re it would >>>>>>>> make it more logical (to me at least) to have a document to strict= ly talk about >>>>>>>> the mapping system and it would increase the appeal of the mapping= system by >>>>>>>> not requiring people to care about the LISP encapsulation if they = only need the >>>>>>>> mapping system function. >>>>>>> The mapping system is in a separate document and spread across alt,= ddt, and ms specs. The control-plane text in RFC6830 is defining an API to= the mapping system. And I think you want it all in one place for completen= ess. >>>>>>> >>>>>> When I was talking about mapping system, I was talking about the >>>>>> =E2=80=9CAPI=E2=80=9D (Map-Request, Map-Reply, Map-Register=E2=80=A6= ). >>>>>> >>>>>> I understand that it is not straightforward to make it in a nice way= , but >>>>>> the as LISP is about decoupling control-plane and data-plane it woul= d >>>>>> make sense to also decouple control and data-plane definition. >>>>>> >>>>>> Imagine you want someone to only implement the control-plane, how >>>>>> does he know what to implement exactly to be fully compliant? >>>>> This is clearly stated in RFC6830. That is, you can send a Map-Reques= t for any reason. It doesn=E2=80=99t have to be invoked by arrival of a pac= ket on an ITR/RTR/PITR. Tools like lig and rig are examples of this. >>>>> >>>> >>>> Of course for someone who knows LISP it is trivial that it is separate= d. The >>>> issue is how to move forward and ensure that LISP control plane is not= bound at >>>> all to a particular data-plane. Actually, since the beginning we say = LISP is >>>> map-and-encap so it means two components mapping and encapsulation, th= at seems >>>> thus very logical to me to have to documents, one for "mapping", one f= or >>>> =E2=80=9Cencapsulation". >>>> >>>> At a first glance it could look like just being marketing but actually= splitting >>>> would allow both planes to be developed (and updated) in parallel. >>> >>> >>> Damien, >>> I think this could be a good idea. Too many people still associate LISP= mostly with the encap (and it looks like too many don't read past the titl= e of the RFC... :-( >>> >>> We should also do a better work of explaining that LISP CP can be used = as generic mapping service for overlays (not only for on-demand LISP tunnel= provisioning). >>> >>> In retrospective we should have presented the LISP/NSH draft in SFC as = well.There might be more SFC use cases that can be addressed by the LISP CP= . It'd be helpful to have the people in SFC give a thought to the concept o= f map assisted overlays. >>> >>> Fabio >>> >>> >>>> >>>> Damien Saucez >>>> >>>>> Dino >>>>> >>>>>> Damien Saucez >>>>>> >>>>>>> Dino >>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Damien Saucez >>>>>>>> >>>>>>>> On 27 Oct 2015, at 01:25, Joel M. Halpern wr= ote: >>>>>>>> >>>>>>>>> It seemed to us that there was likely some confusiona bout how we= expect to handle the revision of RCC 6830. The following is what we curre= ntly expect. >>>>>>>>> >>>>>>>>> Once we have a new charter approved, the chairs will appoint an e= ditor for the revision of rfc6830. That may be one of the existing authors= , or a new person. We will ask for volunteers. >>>>>>>>> >>>>>>>>> Once we have an author, they will submit a starting ID called dra= ft-ietf-lisp-rfc6830bis-00 which will be identical in content to the existi= ng RFC. That may require assistance from the RFC Editor to ensure that we = get all the changes they made during final edit. >>>>>>>>> >>>>>>>>> At that point, we will use the trouble ticket system to record is= sues that people bring up. We will also discuss on the list what changes w= e wish to make according to the charter. Things will tehn proceed in the u= sual fashion, using the trouble ticket system to help make sure we do not d= rop any of the issues. >>>>>>>>> >>>>>>>>> Yours, >>>>>>>>> Joel & Luigi >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 From nobody Thu Nov 5 20:47:56 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D111B354F for ; Thu, 5 Nov 2015 20:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 1Put4ZC4MVvW for ; Thu, 5 Nov 2015 20:47:53 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F5551B354E for ; Thu, 5 Nov 2015 20:47:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3388; q=dns/txt; s=iport; t=1446785273; x=1447994873; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wETIDx5SnKJf/dqHKY7E/0rfGBnhWkGu9LzGzf8zc7E=; b=VY13Qfl45u6V67Im7/csRE4Zx2L7fKHNUBD/iRop+GfUBKkccJRPA1x0 phTuZ5kgBvJvIFJQl23wfQtsA6DA31FGiQsrudpnLqtZ6QGJCkLZZWOq8 /IcbiR9gRhboVZgKigSKVeWpymwnfW6K/+/lx+Z5/P4tGyddbHxvDnpvF I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ARAgC0LzxW/4cNJK1egztTbwa+BwENgWAXCoVvAhyBJDgUAQEBAQEBAYEKhDUBAQEDAQEBASAROgsFBwQCAQgRBAEBAQICIwMCAgIfBgsUAQgIAQEEDgUIiBEDCggNsBSMLQ2EPgEBAQEBAQEBAQEBAQEBAQEBAQEBARQEgQGKUYJThSKBRAWWSAGLLoFtgWGEP45Xh1EBHwEBQoQEcoQNgQcBAQE X-IronPort-AV: E=Sophos;i="5.20,250,1444694400"; d="scan'208";a="204919490" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-4.cisco.com with ESMTP; 06 Nov 2015 04:47:52 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tA64lqNt007588 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Nov 2015 04:47:52 GMT Received: from xch-aln-006.cisco.com (173.36.7.16) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 5 Nov 2015 22:47:52 -0600 Received: from xch-aln-006.cisco.com ([173.36.7.16]) by XCH-ALN-006.cisco.com ([173.36.7.16]) with mapi id 15.00.1104.000; Thu, 5 Nov 2015 22:47:51 -0600 From: "Amjad Inamdar (amjads)" To: Dino Farinacci Thread-Topic: [lisp] LISP crypto Thread-Index: AdEX+QgCejSjQFO0RFuQI9IxGCz84QAX+TQAAALXINA= Date: Fri, 6 Nov 2015 04:47:51 +0000 Message-ID: <46848e1566054f18828428d721391388@XCH-ALN-006.cisco.com> References: <0289fb1a84a84cff89fa92a4559c829c@XCH-ALN-006.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.56.246] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "lisp@ietf.org" Subject: Re: [lisp] LISP crypto X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 06 Nov 2015 04:47:55 -0000 SGkgRGlubywNCg0KVGhlIHRoaW5nIGJlaW5nIHByb3Bvc2VkIHdpdGggSUtFdjIgaXMgdG8gaW5j bHVkZSBhIHByZS1zaGFyZWQga2V5IGluIHRoZSBrZXkgZGVyaXZhdGlvbiBhbmQgd2l0aCBzdWZm aWNpZW50IGVudHJvcHkgaW4gdGhlIHByZS1zaGFyZWQga2V5LCB0aGlzIHdvdWxkIG9mZmVyIGZh aXIgYW1vdW50IG9mIHByb3RlY3Rpb24uIFlvdSBjYW4gcGxlYXNlIHJlZmVyIGRyYWZ0LWZsdWhy ZXItcXItaWtldjIgZm9yIGZ1cnRoZXIgZGV0YWlscy4NCg0KVGhhbmtzLA0KLUFtamFkDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEaW5vIEZhcmluYWNjaSBbbWFpbHRvOmZh cmluYWNjaUBnbWFpbC5jb21dIA0KU2VudDogMDYgTm92ZW1iZXIgMjAxNSBBTSAwNTozNA0KVG86 IEFtamFkIEluYW1kYXIgKGFtamFkcykNCkNjOiBsaXNwQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W2xpc3BdIExJU1AgY3J5cHRvDQoNCkFtamFkLCB3ZSBhcmUgYXdhcmUgb2YgdGhlIFFDLXNhZmUg d29yayBnb2luZyBvbiBpbiBDRlJHLiBXZSBhcmUgZm9sbG93aW5nIGl0IGJ1dCBpdCBpcyB2ZXJ5 IHJlc2VhcmNoeSBhdCB0aGlzIHBvaW50LiBXZSBjYW4gYWRkIHNvbWUgdGV4dCBpbmRpY2F0aW5n IHRoYXQgd2XigJlsbCBmb2xsb3cgYW55IENGUkcvU0FBRyByZWNvbW1lbmRhdGlvbnMgKG9yIGFu eSBzZWN1cml0eSBhcmVhIHdvcmtpbmcgZ3JvdXDigJlzIHJlY29tbWVuZGF0aW9uKSBvbiB1c2lu ZyBRQy1zYWZlIHRlY2hub2xvZ3kuDQoNCklmIHRoZXJlIGlzIGFueXRoaW5nIHNwZWNpZmljIHlv dSB3YW50IHVzIHRvIGxvb2sgYXQgd2l0aCBJS0UsIHBsZWFzZSBzZW5kIHNvbWUgcG9pbnRlcnMu IFRoYW5rcy4NCg0KRGlubw0KDQo+IE9uIE5vdiA1LCAyMDE1LCBhdCAxMDozNyBBTSwgQW1qYWQg SW5hbWRhciAoYW1qYWRzKSA8YW1qYWRzQGNpc2NvLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBCcmlh bi9EaW5vLA0KPiAgDQo+IFRoZSBrZXkgbWF0ZXJpYWwgZGVyaXZhdGlvbiBwcm9wb3NlZCBpbiBk cmFmdC1pZXRmLWxpc3AtY3J5cHRvIGlzIGJhc2VkIG9uIERpZmZpZS1IZWxsbWFuIHdoaWNoIGlz IG5vdCBRdWFudHVtIENvbXB1dGVyIHJlc2lzdGFudC4gVGhlcmUgaXMgc29tZSB3b3JrIHVuZGVy d2F5IHRvIG1ha2UgSUtFIHRoYXQgdXNlcyBESCBmb3Iga2V5IGRlcml2YXRpb24gUXVhbnR1bSBD b21wdXRlciBzYWZlLiBNaWdodCBiZSBhIGdvb2QgaWRlYSB0byBjb25zaWRlciB0aGlzIGZvciBs aXNwLWNyeXB0byBhcyB3ZWxsLg0KPiAgDQo+IFRoYW5rcywNCj4gLUFtamFkDQo+ICANCj4gRnJv bTogQW1qYWQgSW5hbWRhciAoYW1qYWRzKQ0KPiBTZW50OiAwMyBOb3ZlbWJlciAyMDE1IFBNIDEy OjMzDQo+IFRvOiAnbGlzcEBpZXRmLm9yZycNCj4gU3ViamVjdDogTElTUCBOQVQgVHJhdmVyc2Fs DQo+ICANCj4gSGksDQo+ICANCj4gSXQgd2lsbCBiZSB1c2VmdWwgaWYgTElTUCBOQVQgdHJhdmVy c2FsIGRyYWZ0IA0KPiAoZHJhZnQtZXJtYWdhbi1saXNwLW5hdC10cmF2ZXJzYWwpIGNhbiBlbGFi b3JhdGUgb24gdGhlIGZvbGxvd2luZw0KPiAgDQo+IDEpIFdoeSBMSVNQIE5BVCB0cmF2ZXJzYWwg Y2Fubm90IGJlIGFjY29tcGxpc2hlZCB3aXRob3V0IFJUUiAoYW5vdGhlciBuZXR3b3JrIGVudGl0 eSkgd2hpY2ggaGFzIGltcGxpY2F0aW9ucyBvbiBkZXBsb3lhYmlsaXR5LCBjb21wbGV4aXR5IGFu ZCBsYXRlbmN5LiBUaGVyZSBhcmUgb3RoZXIgcHJvdG9jb2xzIChlLmcgSUtFL0lQc2VjKSB0aGF0 IGFjaGlldmUgTkFULUQgYW5kIE5BVC1UIHdpdGhvdXQgdGhlIG5lZWQgZm9yIGFkZGl0aW9uYWwg bmV0d29yayBlbnRpdHkuDQo+ICANCj4gMikgU29tZSBtb3JlIGRldGFpbHMgb24gUlRSIGRlcGxv eW1lbnQNCj4gLSBsb2NhdGlvbiBvZiBSVFIgaW4gdGhlIExJU1AgZGVwbG95bWVudCBsaWtlIHRo ZXJlIGFyZSANCj4gcmVjb21tZW5kYXRpb25zIG9uIFBJVFIvUEVUUiBkZXBsb3ltZW50cw0KPiAt IGlzIFJUUiBzaGFyZWQgYWNyb3NzIExJU1Agc2l0ZXMgYmVoaW5kIE5BVCBvciBlYWNoIHNpdGUg bmVlZHMgYSANCj4gZGVkaWNhdGVkIFJUUg0KPiAtIHdoYXQgaWYgUlRSIGlzIGJlaGluZCBhbm90 aGVyIE5BVCAoU1AtTkFUKQ0KPiAgDQo+IDMpIEhvdyBpcyBtdWx0aXBsZS1OQVQgaGFuZGxlZCAo ZS5nLiBlbnRlcnByaXNlIGFuZCBTUCBOQVQpDQo+ICANCj4gVGhhbmtzLA0KPiAtQW1qYWQgSW5h bWRhciBDSVNTUCwgQ0NOUCBSJlMsIENDTlAgU2VjdXJpdHksIENDRFAsIENDU0sgU2VuaW9yIA0K PiBUZWNobmljYWwgTGVhZGVyIENTRyBQSSBTZXJ2aWNlcyBTZWN1cml0eSAtIEluZGlhDQo+ICAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbGlz cCBtYWlsaW5nIGxpc3QNCj4gbGlzcEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2xpc3ANCg0K From nobody Thu Nov 5 22:44:44 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163821A9087 for ; Thu, 5 Nov 2015 22:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 teN0Xm2EQpoL for ; Thu, 5 Nov 2015 22:44:42 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002: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 2098F1A9068 for ; Thu, 5 Nov 2015 22:44:42 -0800 (PST) Received: by ykba4 with SMTP id a4so173667169ykb.3 for ; Thu, 05 Nov 2015 22:44:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3BNd+4oSP0GdjN+In1mgv+zqxOiTjf3xZ3Bi7zeXsVw=; b=AgpF/Bb62aBKytt/lr0KfYmAfA9zBTCQH5+lhHYgGCbq9NItOQt58jOKhm2fYiERpx KVNuOFHjlsWD8pkESAwmfhsK+vcuSIxUHYHHKkQM5s2aAeh82PJS2oEjU3ik6Pn3rRbZ kQHTF5tY41XwPehyWwZMrUfdD/p1OXdM+7/Dm0lNT4KYcVdl18JQluv3NDacgJhdJVcq DXIfZE4tmLwOQNgWcTT8/xYIxQWxxGautbMaAZgSZ3GjaEbfUtgDDYBvJIqPfa50H4mu 0aSFcyMC7R+UQYED3XtmylsyvUmDKLRFiGCI4ZDkGifXgIlViV6FV4tccz6hyzWr23rx ingQ== X-Received: by 10.13.242.4 with SMTP id b4mr9673113ywf.255.1446792281271; Thu, 05 Nov 2015 22:44:41 -0800 (PST) Received: from [10.87.111.186] ([166.170.52.46]) by smtp.gmail.com with ESMTPSA id 205sm7284671ywi.55.2015.11.05.22.44.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Nov 2015 22:44:40 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (13B143) In-Reply-To: <46848e1566054f18828428d721391388@XCH-ALN-006.cisco.com> Date: Fri, 6 Nov 2015 15:44:35 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <326CA60F-2952-408E-B78D-2FD1540C6CEB@gmail.com> References: <0289fb1a84a84cff89fa92a4559c829c@XCH-ALN-006.cisco.com> <46848e1566054f18828428d721391388@XCH-ALN-006.cisco.com> To: "Amjad Inamdar (amjads)" Archived-At: Cc: "lisp@ietf.org" Subject: Re: [lisp] LISP crypto X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 06 Nov 2015 06:44:44 -0000 In the lisp-crypto design, the ECDH shared secret is input to the KDF that p= roduces the encryption key and integrity-check key.=20 Sounds like we may already be doing what you suggest.=20 And not clear to me how much more QC-safe this actually is.=20 Dino > On Nov 6, 2015, at 1:47 PM, Amjad Inamdar (amjads) wrot= e: >=20 > Hi Dino, >=20 > The thing being proposed with IKEv2 is to include a pre-shared key in the k= ey derivation and with sufficient entropy in the pre-shared key, this would o= ffer fair amount of protection. You can please refer draft-fluhrer-qr-ikev2 f= or further details. >=20 > Thanks, > -Amjad >=20 > -----Original Message----- > From: Dino Farinacci [mailto:farinacci@gmail.com]=20 > Sent: 06 November 2015 AM 05:34 > To: Amjad Inamdar (amjads) > Cc: lisp@ietf.org > Subject: Re: [lisp] LISP crypto >=20 > Amjad, we are aware of the QC-safe work going on in CFRG. We are following= it but it is very researchy at this point. We can add some text indicating t= hat we=E2=80=99ll follow any CFRG/SAAG recommendations (or any security area= working group=E2=80=99s recommendation) on using QC-safe technology. >=20 > If there is anything specific you want us to look at with IKE, please send= some pointers. Thanks. >=20 > Dino >=20 >> On Nov 5, 2015, at 10:37 AM, Amjad Inamdar (amjads) wr= ote: >>=20 >> Hi Brian/Dino, >>=20 >> The key material derivation proposed in draft-ietf-lisp-crypto is based o= n Diffie-Hellman which is not Quantum Computer resistant. There is some work= underway to make IKE that uses DH for key derivation Quantum Computer safe.= Might be a good idea to consider this for lisp-crypto as well. >>=20 >> Thanks, >> -Amjad >>=20 >> From: Amjad Inamdar (amjads) >> Sent: 03 November 2015 PM 12:33 >> To: 'lisp@ietf.org' >> Subject: LISP NAT Traversal >>=20 >> Hi, >>=20 >> It will be useful if LISP NAT traversal draft=20 >> (draft-ermagan-lisp-nat-traversal) can elaborate on the following >>=20 >> 1) Why LISP NAT traversal cannot be accomplished without RTR (another net= work entity) which has implications on deployability, complexity and latency= . There are other protocols (e.g IKE/IPsec) that achieve NAT-D and NAT-T wit= hout the need for additional network entity. >>=20 >> 2) Some more details on RTR deployment >> - location of RTR in the LISP deployment like there are=20 >> recommendations on PITR/PETR deployments >> - is RTR shared across LISP sites behind NAT or each site needs a=20 >> dedicated RTR >> - what if RTR is behind another NAT (SP-NAT) >>=20 >> 3) How is multiple-NAT handled (e.g. enterprise and SP NAT) >>=20 >> Thanks, >> -Amjad Inamdar CISSP, CCNP R&S, CCNP Security, CCDP, CCSK Senior=20 >> Technical Leader CSG PI Services Security - India >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 From nobody Fri Nov 6 01:37:04 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89D71B37EC for ; Fri, 6 Nov 2015 01:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 sHswJqOsr_38 for ; Fri, 6 Nov 2015 01:37:01 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F5771B37EA for ; Fri, 6 Nov 2015 01:37:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4512; q=dns/txt; s=iport; t=1446802621; x=1448012221; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=EF+ojf2f3BIU0lbdlPsCqVa0+dX6sFOaLTX4sfAmRVY=; b=huxZ8UCPt9xEwdISwJm+TJvKepdn4TCR/A3Ki8AbbM4ieY+JFZbbDXtb dN3qg1/n2scBsP7TybDpG0Fz090QL5yWSYRK506VasG6j4oFYZGoEWIRn oLqFRtUwgTE1Ct0FuV1WRuV1nu8TMOAEurNFXVREsrQOcmvJ7m1XVLjzS Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AfAgBUdDxW/5pdJa1egztTbwa+FgENgWAXCoVvAhyBGjgUAQEBAQEBAYEKhDUBAQEDAQEBASAROgsFBwQCAQgRBAEBAQICIwMCAgIfBgsUAQgIAQEEDgUIiBEDCggNsBqMLg2EPgEBAQEBAQEBAQEBAQEBAQEBAQEBARQEgQGKUYJThSKBRAWHRo8CAYsvgW2BYoRAjleHUQEfAQFChARyhA0BgQYBAQE X-IronPort-AV: E=Sophos;i="5.20,251,1444694400"; d="scan'208";a="205529306" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP; 06 Nov 2015 09:37:00 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id tA69b0hX014438 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Nov 2015 09:37:00 GMT Received: from xch-aln-006.cisco.com (173.36.7.16) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 6 Nov 2015 03:36:59 -0600 Received: from xch-aln-006.cisco.com ([173.36.7.16]) by XCH-ALN-006.cisco.com ([173.36.7.16]) with mapi id 15.00.1104.000; Fri, 6 Nov 2015 03:36:59 -0600 From: "Amjad Inamdar (amjads)" To: Dino Farinacci Thread-Topic: [lisp] LISP crypto Thread-Index: AdEX+QgCejSjQFO0RFuQI9IxGCz84QAX+TQAAALXINAACyargAAGq7Gg Date: Fri, 6 Nov 2015 09:36:59 +0000 Message-ID: <5508eb83eb0c4d7abfd28c71c1d46c7e@XCH-ALN-006.cisco.com> References: <0289fb1a84a84cff89fa92a4559c829c@XCH-ALN-006.cisco.com> <46848e1566054f18828428d721391388@XCH-ALN-006.cisco.com> <326CA60F-2952-408E-B78D-2FD1540C6CEB@gmail.com> In-Reply-To: <326CA60F-2952-408E-B78D-2FD1540C6CEB@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [173.39.66.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "lisp@ietf.org" Subject: Re: [lisp] LISP crypto X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 06 Nov 2015 09:37:03 -0000 SGkgRGlubywNCg0KVGhlIHByZS1zaGFyZWQga2V5IEkgbWVudGlvbmVkIGFib3V0IHdvdWxkIG5l ZWQgdG8gYmUgcHJlLWNvbmZpZ3VyZWQgb24gdGhlIHBlZXJzL3hUUnMuIERIIHNoYXJlZCBzZWNy ZXQgaXMgYmFzZWQgb24gREggcHVibGljIHZhbHVlcyBleGNoYW5nZWQgb24gdGhlIHdpcmUgd2hp Y2ggUUMgY2FuIGJyZWFrLg0KDQpUaGFua3MsDQotQW1qYWQNCg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogRGlubyBGYXJpbmFjY2kgW21haWx0bzpmYXJpbmFjY2lAZ21haWwu Y29tXSANClNlbnQ6IDA2IE5vdmVtYmVyIDIwMTUgUE0gMTI6MTUNClRvOiBBbWphZCBJbmFtZGFy IChhbWphZHMpDQpDYzogbGlzcEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtsaXNwXSBMSVNQIGNy eXB0bw0KDQpJbiB0aGUgbGlzcC1jcnlwdG8gZGVzaWduLCB0aGUgRUNESCBzaGFyZWQgc2VjcmV0 IGlzIGlucHV0IHRvIHRoZSBLREYgdGhhdCBwcm9kdWNlcyB0aGUgZW5jcnlwdGlvbiBrZXkgYW5k IGludGVncml0eS1jaGVjayBrZXkuIA0KDQpTb3VuZHMgbGlrZSB3ZSBtYXkgYWxyZWFkeSBiZSBk b2luZyB3aGF0IHlvdSBzdWdnZXN0LiANCg0KQW5kIG5vdCBjbGVhciB0byBtZSBob3cgbXVjaCBt b3JlIFFDLXNhZmUgdGhpcyBhY3R1YWxseSBpcy4gDQoNCkRpbm8NCg0KPiBPbiBOb3YgNiwgMjAx NSwgYXQgMTo0NyBQTSwgQW1qYWQgSW5hbWRhciAoYW1qYWRzKSA8YW1qYWRzQGNpc2NvLmNvbT4g d3JvdGU6DQo+IA0KPiBIaSBEaW5vLA0KPiANCj4gVGhlIHRoaW5nIGJlaW5nIHByb3Bvc2VkIHdp dGggSUtFdjIgaXMgdG8gaW5jbHVkZSBhIHByZS1zaGFyZWQga2V5IGluIHRoZSBrZXkgZGVyaXZh dGlvbiBhbmQgd2l0aCBzdWZmaWNpZW50IGVudHJvcHkgaW4gdGhlIHByZS1zaGFyZWQga2V5LCB0 aGlzIHdvdWxkIG9mZmVyIGZhaXIgYW1vdW50IG9mIHByb3RlY3Rpb24uIFlvdSBjYW4gcGxlYXNl IHJlZmVyIGRyYWZ0LWZsdWhyZXItcXItaWtldjIgZm9yIGZ1cnRoZXIgZGV0YWlscy4NCj4gDQo+ IFRoYW5rcywNCj4gLUFtamFkDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBEaW5vIEZhcmluYWNjaSBbbWFpbHRvOmZhcmluYWNjaUBnbWFpbC5jb21dDQo+IFNlbnQ6 IDA2IE5vdmVtYmVyIDIwMTUgQU0gMDU6MzQNCj4gVG86IEFtamFkIEluYW1kYXIgKGFtamFkcykN Cj4gQ2M6IGxpc3BAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtsaXNwXSBMSVNQIGNyeXB0bw0K PiANCj4gQW1qYWQsIHdlIGFyZSBhd2FyZSBvZiB0aGUgUUMtc2FmZSB3b3JrIGdvaW5nIG9uIGlu IENGUkcuIFdlIGFyZSBmb2xsb3dpbmcgaXQgYnV0IGl0IGlzIHZlcnkgcmVzZWFyY2h5IGF0IHRo aXMgcG9pbnQuIFdlIGNhbiBhZGQgc29tZSB0ZXh0IGluZGljYXRpbmcgdGhhdCB3ZeKAmWxsIGZv bGxvdyBhbnkgQ0ZSRy9TQUFHIHJlY29tbWVuZGF0aW9ucyAob3IgYW55IHNlY3VyaXR5IGFyZWEg d29ya2luZyBncm91cOKAmXMgcmVjb21tZW5kYXRpb24pIG9uIHVzaW5nIFFDLXNhZmUgdGVjaG5v bG9neS4NCj4gDQo+IElmIHRoZXJlIGlzIGFueXRoaW5nIHNwZWNpZmljIHlvdSB3YW50IHVzIHRv IGxvb2sgYXQgd2l0aCBJS0UsIHBsZWFzZSBzZW5kIHNvbWUgcG9pbnRlcnMuIFRoYW5rcy4NCj4g DQo+IERpbm8NCj4gDQo+PiBPbiBOb3YgNSwgMjAxNSwgYXQgMTA6MzcgQU0sIEFtamFkIEluYW1k YXIgKGFtamFkcykgPGFtamFkc0BjaXNjby5jb20+IHdyb3RlOg0KPj4gDQo+PiBIaSBCcmlhbi9E aW5vLA0KPj4gDQo+PiBUaGUga2V5IG1hdGVyaWFsIGRlcml2YXRpb24gcHJvcG9zZWQgaW4gZHJh ZnQtaWV0Zi1saXNwLWNyeXB0byBpcyBiYXNlZCBvbiBEaWZmaWUtSGVsbG1hbiB3aGljaCBpcyBu b3QgUXVhbnR1bSBDb21wdXRlciByZXNpc3RhbnQuIFRoZXJlIGlzIHNvbWUgd29yayB1bmRlcndh eSB0byBtYWtlIElLRSB0aGF0IHVzZXMgREggZm9yIGtleSBkZXJpdmF0aW9uIFF1YW50dW0gQ29t cHV0ZXIgc2FmZS4gTWlnaHQgYmUgYSBnb29kIGlkZWEgdG8gY29uc2lkZXIgdGhpcyBmb3IgbGlz cC1jcnlwdG8gYXMgd2VsbC4NCj4+IA0KPj4gVGhhbmtzLA0KPj4gLUFtamFkDQo+PiANCj4+IEZy b206IEFtamFkIEluYW1kYXIgKGFtamFkcykNCj4+IFNlbnQ6IDAzIE5vdmVtYmVyIDIwMTUgUE0g MTI6MzMNCj4+IFRvOiAnbGlzcEBpZXRmLm9yZycNCj4+IFN1YmplY3Q6IExJU1AgTkFUIFRyYXZl cnNhbA0KPj4gDQo+PiBIaSwNCj4+IA0KPj4gSXQgd2lsbCBiZSB1c2VmdWwgaWYgTElTUCBOQVQg dHJhdmVyc2FsIGRyYWZ0DQo+PiAoZHJhZnQtZXJtYWdhbi1saXNwLW5hdC10cmF2ZXJzYWwpIGNh biBlbGFib3JhdGUgb24gdGhlIGZvbGxvd2luZw0KPj4gDQo+PiAxKSBXaHkgTElTUCBOQVQgdHJh dmVyc2FsIGNhbm5vdCBiZSBhY2NvbXBsaXNoZWQgd2l0aG91dCBSVFIgKGFub3RoZXIgbmV0d29y ayBlbnRpdHkpIHdoaWNoIGhhcyBpbXBsaWNhdGlvbnMgb24gZGVwbG95YWJpbGl0eSwgY29tcGxl eGl0eSBhbmQgbGF0ZW5jeS4gVGhlcmUgYXJlIG90aGVyIHByb3RvY29scyAoZS5nIElLRS9JUHNl YykgdGhhdCBhY2hpZXZlIE5BVC1EIGFuZCBOQVQtVCB3aXRob3V0IHRoZSBuZWVkIGZvciBhZGRp dGlvbmFsIG5ldHdvcmsgZW50aXR5Lg0KPj4gDQo+PiAyKSBTb21lIG1vcmUgZGV0YWlscyBvbiBS VFIgZGVwbG95bWVudA0KPj4gLSBsb2NhdGlvbiBvZiBSVFIgaW4gdGhlIExJU1AgZGVwbG95bWVu dCBsaWtlIHRoZXJlIGFyZSANCj4+IHJlY29tbWVuZGF0aW9ucyBvbiBQSVRSL1BFVFIgZGVwbG95 bWVudHMNCj4+IC0gaXMgUlRSIHNoYXJlZCBhY3Jvc3MgTElTUCBzaXRlcyBiZWhpbmQgTkFUIG9y IGVhY2ggc2l0ZSBuZWVkcyBhIA0KPj4gZGVkaWNhdGVkIFJUUg0KPj4gLSB3aGF0IGlmIFJUUiBp cyBiZWhpbmQgYW5vdGhlciBOQVQgKFNQLU5BVCkNCj4+IA0KPj4gMykgSG93IGlzIG11bHRpcGxl LU5BVCBoYW5kbGVkIChlLmcuIGVudGVycHJpc2UgYW5kIFNQIE5BVCkNCj4+IA0KPj4gVGhhbmtz LA0KPj4gLUFtamFkIEluYW1kYXIgQ0lTU1AsIENDTlAgUiZTLCBDQ05QIFNlY3VyaXR5LCBDQ0RQ LCBDQ1NLIFNlbmlvciANCj4+IFRlY2huaWNhbCBMZWFkZXIgQ1NHIFBJIFNlcnZpY2VzIFNlY3Vy aXR5IC0gSW5kaWENCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+IGxpc3AgbWFpbGluZyBsaXN0DQo+PiBsaXNwQGlldGYub3JnDQo+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpc3ANCj4gDQo= From nobody Fri Nov 6 04:29:24 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68671A007C for ; Fri, 6 Nov 2015 04:29:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 Ex_Mew0p4BlD for ; Fri, 6 Nov 2015 04:29:20 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE6FE1A0074 for ; Fri, 6 Nov 2015 04:29:20 -0800 (PST) Received: by pacdm15 with SMTP id dm15so97855506pac.3 for ; Fri, 06 Nov 2015 04:29:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4ZmUwprlSFAH60qZsZtt4fwbGgSo6o3EvZKKqpUi79o=; b=GxGOJsAnmGsObS6PNhSuZao8vouLov4nrhMRo4gLWgFSZqgZ7acbvaXZJqG5KdaG/l /3ByuP6df0QkdpH3q7RJqqxDefno8kHIxLo8dK+4458Ylv9CMPf9BxZCpvtT0jN6dnIA Mzyo0GlYrlw6IMnCq+xnhGWEwvyGEaFBfH98mGdAvruW7fqBXfjUVo5KDfoMK1E6bj8h d7pxIQCYtt68H7g6v7oqkal3I26Z4Rt9tNrh4HDk2u2bbRWJz8VoPU8+A1wl2rIF/dc4 lMqPxkKmGYiWifATkEYMHvlTBPsHEZFyfDTT9NkTcUgYd6vmqAXe4FMMa3v31qa+c4Bq +dDA== X-Received: by 10.68.196.131 with SMTP id im3mr17267389pbc.59.1446812960401; Fri, 06 Nov 2015 04:29:20 -0800 (PST) Received: from [10.71.7.211] ([101.110.53.38]) by smtp.gmail.com with ESMTPSA id ro3sm13889546pbc.69.2015.11.06.04.29.19 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Nov 2015 04:29:19 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (13B143) In-Reply-To: <5508eb83eb0c4d7abfd28c71c1d46c7e@XCH-ALN-006.cisco.com> Date: Fri, 6 Nov 2015 21:29:18 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0289fb1a84a84cff89fa92a4559c829c@XCH-ALN-006.cisco.com> <46848e1566054f18828428d721391388@XCH-ALN-006.cisco.com> <326CA60F-2952-408E-B78D-2FD1540C6CEB@gmail.com> <5508eb83eb0c4d7abfd28c71c1d46c7e@XCH-ALN-006.cisco.com> To: "Amjad Inamdar (amjads)" Archived-At: Cc: "lisp@ietf.org" Subject: Re: [lisp] LISP crypto X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 06 Nov 2015 12:29:22 -0000 Configured shared-keys is a non- starter for LISP.=20 Imagine and ITR, just with 10K map-cache entries that point to dual-homed LI= SP sites. That is 20K keys that not only need to be configured but colocated= with those 20K RLOCs. RLOCs that can change due to EID-prefix mobility.=20 Dino > On Nov 6, 2015, at 6:36 PM, Amjad Inamdar (amjads) wrot= e: >=20 > Hi Dino, >=20 > The pre-shared key I mentioned about would need to be pre-configured on th= e peers/xTRs. DH shared secret is based on DH public values exchanged on the= wire which QC can break. >=20 > Thanks, > -Amjad >=20 >=20 > -----Original Message----- > From: Dino Farinacci [mailto:farinacci@gmail.com]=20 > Sent: 06 November 2015 PM 12:15 > To: Amjad Inamdar (amjads) > Cc: lisp@ietf.org > Subject: Re: [lisp] LISP crypto >=20 > In the lisp-crypto design, the ECDH shared secret is input to the KDF that= produces the encryption key and integrity-check key.=20 >=20 > Sounds like we may already be doing what you suggest.=20 >=20 > And not clear to me how much more QC-safe this actually is.=20 >=20 > Dino >=20 >> On Nov 6, 2015, at 1:47 PM, Amjad Inamdar (amjads) wro= te: >>=20 >> Hi Dino, >>=20 >> The thing being proposed with IKEv2 is to include a pre-shared key in the= key derivation and with sufficient entropy in the pre-shared key, this woul= d offer fair amount of protection. You can please refer draft-fluhrer-qr-ike= v2 for further details. >>=20 >> Thanks, >> -Amjad >>=20 >> -----Original Message----- >> From: Dino Farinacci [mailto:farinacci@gmail.com] >> Sent: 06 November 2015 AM 05:34 >> To: Amjad Inamdar (amjads) >> Cc: lisp@ietf.org >> Subject: Re: [lisp] LISP crypto >>=20 >> Amjad, we are aware of the QC-safe work going on in CFRG. We are followin= g it but it is very researchy at this point. We can add some text indicating= that we=E2=80=99ll follow any CFRG/SAAG recommendations (or any security ar= ea working group=E2=80=99s recommendation) on using QC-safe technology. >>=20 >> If there is anything specific you want us to look at with IKE, please sen= d some pointers. Thanks. >>=20 >> Dino >>=20 >>> On Nov 5, 2015, at 10:37 AM, Amjad Inamdar (amjads) w= rote: >>>=20 >>> Hi Brian/Dino, >>>=20 >>> The key material derivation proposed in draft-ietf-lisp-crypto is based o= n Diffie-Hellman which is not Quantum Computer resistant. There is some work= underway to make IKE that uses DH for key derivation Quantum Computer safe.= Might be a good idea to consider this for lisp-crypto as well. >>>=20 >>> Thanks, >>> -Amjad >>>=20 >>> From: Amjad Inamdar (amjads) >>> Sent: 03 November 2015 PM 12:33 >>> To: 'lisp@ietf.org' >>> Subject: LISP NAT Traversal >>>=20 >>> Hi, >>>=20 >>> It will be useful if LISP NAT traversal draft >>> (draft-ermagan-lisp-nat-traversal) can elaborate on the following >>>=20 >>> 1) Why LISP NAT traversal cannot be accomplished without RTR (another ne= twork entity) which has implications on deployability, complexity and latenc= y. There are other protocols (e.g IKE/IPsec) that achieve NAT-D and NAT-T wi= thout the need for additional network entity. >>>=20 >>> 2) Some more details on RTR deployment >>> - location of RTR in the LISP deployment like there are=20 >>> recommendations on PITR/PETR deployments >>> - is RTR shared across LISP sites behind NAT or each site needs a=20 >>> dedicated RTR >>> - what if RTR is behind another NAT (SP-NAT) >>>=20 >>> 3) How is multiple-NAT handled (e.g. enterprise and SP NAT) >>>=20 >>> Thanks, >>> -Amjad Inamdar CISSP, CCNP R&S, CCNP Security, CCDP, CCSK Senior=20 >>> Technical Leader CSG PI Services Security - India >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>=20 From nobody Fri Nov 20 07:46:44 2015 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 AF8A51B2AF3; Fri, 20 Nov 2015 07:46:41 -0800 (PST) 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.10.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151120154641.3601.83333.idtracker@ietfa.amsl.com> Date: Fri, 20 Nov 2015 07:46:41 -0800 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-impact-05.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 20 Nov 2015 15:46: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 Working Group of the IETF. Title : LISP Impact Authors : Damien Saucez Luigi Iannone Albert Cabellos Florin Coras Filename : draft-ietf-lisp-impact-05.txt Pages : 18 Date : 2015-11-20 Abstract: The Locator/Identifier Separation Protocol (LISP) aims at improving the Internet routing scalability properties by leveraging on three principles: address role separation, encapsulation, and mapping. In this document, based on implementation work, deployment experiences, and theoretical studies, we discuss the impact that the deployment of LISP can have on both the routing infrastructure and the end-user. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-impact/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lisp-impact-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-impact-05 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 Fri Nov 20 07:51:40 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D469D1B2B51 for ; Fri, 20 Nov 2015 07:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 5qrHoy__YUZX for ; Fri, 20 Nov 2015 07:51:30 -0800 (PST) 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 791291B2B54 for ; Fri, 20 Nov 2015 07:51:30 -0800 (PST) Received: by wmec201 with SMTP id c201so77954111wme.0 for ; Fri, 20 Nov 2015 07:51:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:content-type:message-id:mime-version:subject:date:references :cc:to; bh=/9r7AjuE5aOZ29COWC+shlUEezMZl8HNLiPcQWdzvEI=; b=DyTIstHT84wrt+c3Yubc6KKspjrsClGVkdhpoxLmRfR/pCiolzXBx+UdSVIMyo08wH QNEyToouCIJD3WLwQjCuPhkG7rY6iwapgoVix9FgpbQKmnj49UtDmf2JJ9YsHMP4llP9 EwNKprGaver+wUs+M/d7hs3i/6zawjX7I2PQV2BTSgm9I7zlnLSsyDnOlGAwd3WkR6p/ ORh+iWnI6KZpsL9qTxj5pqjJlLjezcZ/ycpCr9EpXwR5Sl+XOxgfkaBf6bzu5H5z69dv htNLnhE3w/dpoM7KNpEK7k7d9FePvHzfX6+ggTNkf5DZ6iZo7G58tGr/A3nSQRTUq2g6 Cj6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:cc:to; bh=/9r7AjuE5aOZ29COWC+shlUEezMZl8HNLiPcQWdzvEI=; b=FxV0UvNt9lrFWZ94DWIXQeI7Gv3X4wrY0pYT5Ak7B+aJj9EVuUWbvFdjaYibayrFkQ rhOsm9EUsfQlo9pwzIkJzOijCPJuElPYoEKHgUHqyoqo1IQtR9T533AFNdeahmP898kJ RNAputsJBkuATTozQUgd9gqasAuk4QPfAZ2DZs6vCZsBavBt1b/uNxLqTT2mFPg4S6Op 8B2/MkVXrl9o6xYE0L75j0n676hi/48bEUNG6pfIcdhmWvsb2TQLeCifvbcFeebxQjhH LyPa2mUMmJg9zkSlF4lB/+gxRxCuR9JpqeIznbX99rj1sOvOnKqZNdfJMbfrmZmm0Vsa YEUw== X-Gm-Message-State: ALoCoQnpieXG2qTfK61Z93cHGOV17T/wC6Q32sTgVyQ3gVIbgolFvY2iacTNNV5KQOrZ4b+sK7y+ X-Received: by 10.28.26.78 with SMTP id a75mr3163472wma.13.1448034688900; Fri, 20 Nov 2015 07:51:28 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:a159:f8d4:cc46:b638? ([2001:660:330f:a4:a159:f8d4:cc46:b638]) by smtp.gmail.com with ESMTPSA id 143sm116202wmv.18.2015.11.20.07.51.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 20 Nov 2015 07:51:27 -0800 (PST) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_7A095662-345D-4F1D-92A3-96E11652F90F" Message-Id: <702CF6D9-26CF-4AD3-BBD8-7259BD12C954@gigix.net> Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Date: Fri, 20 Nov 2015 16:51:25 +0100 References: <20151120154641.3601.83333.idtracker@ietfa.amsl.com> To: LISP mailing list list X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: lisp-chairs@ietf.org, The IESG Subject: [lisp] Fwd: I-D Action: draft-ietf-lisp-impact-05.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 20 Nov 2015 15:51:33 -0000 --Apple-Mail=_7A095662-345D-4F1D-92A3-96E11652F90F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, We just submitted an updated LISP Impact document that includes all the = reviews received during IESG evaluation. We actually had great reviews (thanks you all), which helped in = improving the readability of the document in several parts. ciao Luigi > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Date: 20 November 2015 at 16:46:41 GMT+1 > To: > Cc: lisp@ietf.org > Subject: I-D Action: draft-ietf-lisp-impact-05.txt >=20 >=20 > 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 = Working Group of the IETF. >=20 > Title : LISP Impact > Authors : Damien Saucez > Luigi Iannone > Albert Cabellos > Florin Coras > Filename : draft-ietf-lisp-impact-05.txt > Pages : 18 > Date : 2015-11-20 >=20 > Abstract: > The Locator/Identifier Separation Protocol (LISP) aims at improving > the Internet routing scalability properties by leveraging on three > principles: address role separation, encapsulation, and mapping. In > this document, based on implementation work, deployment experiences, > and theoretical studies, we discuss the impact that the deployment = of > LISP can have on both the routing infrastructure and the end-user. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lisp-impact/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-lisp-impact-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-impact-05 >=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 --Apple-Mail=_7A095662-345D-4F1D-92A3-96E11652F90F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi All,

We = just submitted an updated LISP Impact document that includes all the = reviews received during IESG evaluation.
We = actually had great reviews (thanks you all), which helped in improving = the readability of the document in several parts.
ciao

Luigi

Begin = forwarded message:

From: = internet-drafts@ietf.org
Date: = 20 November 2015 at 16:46:41 = GMT+1
To: = <i-d-announce@ietf.org>
Cc: lisp@ietf.org
Subject: = I-D Action: = draft-ietf-lisp-impact-05.txt


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 Working Group of the IETF.

       Title =           : LISP = Impact
       Authors =         : Damien Saucez
=             &n= bsp;           &nbs= p;Luigi Iannone
=             &n= bsp;           &nbs= p;Albert Cabellos
=             &n= bsp;           &nbs= p;Florin Coras
Filename =        : = draft-ietf-lisp-impact-05.txt
Pages =           : 18
= Date =            : = 2015-11-20

Abstract:
=   The Locator/Identifier Separation Protocol (LISP) aims at = improving
  the Internet routing scalability = properties by leveraging on three
  principles: = address role separation, encapsulation, and mapping.  In
  this document, based on implementation work, = deployment experiences,
  and theoretical = studies, we discuss the impact that the deployment of
=   LISP can have on both the routing infrastructure and the = end-user.


The IETF = datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lisp-impact/
There's also a htmlized version available = at:
https://tools.ietf.org/html/draft-ietf-lisp-impact-05
A diff from the previous version is available = at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-impact-05

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/

_______________________________________________
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

= --Apple-Mail=_7A095662-345D-4F1D-92A3-96E11652F90F-- From nobody Mon Nov 30 10:04:48 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCDD41ACD69 for ; Mon, 30 Nov 2015 10:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 qdKW9X1l-c1t for ; Mon, 30 Nov 2015 10:04:46 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::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 C17BE1ACD65 for ; Mon, 30 Nov 2015 10:04:46 -0800 (PST) Received: by pacdm15 with SMTP id dm15so191837256pac.3 for ; Mon, 30 Nov 2015 10:04:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version; bh=l42O8KBOw5KLnmygtjwiIc8LqNDUhRGBQFZydORHtrE=; b=0KFJQw5wPEocD+sWCe7PMDuD0v0PJShkGMJbVMHD6AkTVnH6rkGVPW1KwOmC99rHRL sLtTpBOS1F76dBT9ezahop62oxmWFHwnhkHBW3DHJzttkI5qkaesUS3sBSMFPW1mfRJv JPNZfSyvKDSqM4j7Nj9aKPZtdPy9sPbw1UU4KTH3g6+rgIyvmUee5SZAp80HysaO0fWS 9o2fNP5FMH2twxTARQbYf+UeFsJY2sVN7/ibr3Igmv1q5XvixxCH1l52rSfpjxmIAHzC GifLjVJasD+g1TNgP/VRr6cwQv1AiuhIZMVdQPbZDTMOPgPOorWC7FjVRo5YOAumMwHL iTxQ== X-Received: by 10.98.42.9 with SMTP id q9mr72208154pfq.142.1448906686476; Mon, 30 Nov 2015 10:04:46 -0800 (PST) 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 rz10sm53282611pac.29.2015.11.30.10.04.44 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 30 Nov 2015 10:04:45 -0800 (PST) From: Dino Farinacci Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Nov 2015 10:04:40 -0800 References: <20151130124204.32281.43652.idtracker@ietfa.amsl.com> To: LISP mailing list list Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: [lisp] Fwd: Expiration impending: X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 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, 30 Nov 2015 18:04:48 -0000 Folks, I presented this at many WG meetings and felt it is ready for = working group document. I asked this in Yokohama and want to follow-up = now on the list. Since the individual submission is about to expire, I am wonder if I can = resubmit it as draft-ietf-lisp-signal-free-multicast-00? Chairs? Dino > Begin forwarded message: >=20 > From: IETF Secretariat > Date: November 30, 2015 at 4:42:04 AM PST > To: > Subject: Expiration impending: = >=20 > The following draft will expire soon: >=20 > Name: draft-farinacci-lisp-signal-free-multicast > Title: Signal-Free LISP Multicast > State: I-D Exists > Expires: 2015-12-10 (in 1 week, 2 days) >=20