Re: [lisp] Mirja Kühlewind's Discuss on draft-ietf-lisp-rfc6833bis-13: (with DISCUSS and COMMENT)

Dino Farinacci <farinacci@gmail.com> Tue, 11 September 2018 18:13 UTC

Return-Path: <farinacci@gmail.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B569C130EE7; Tue, 11 Sep 2018 11:13:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWVjZoC4lbis; Tue, 11 Sep 2018 11:13:53 -0700 (PDT)
Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A63DB1292F1; Tue, 11 Sep 2018 11:13:53 -0700 (PDT)
Received: by mail-pg1-x52b.google.com with SMTP id s7-v6so12677831pgc.0; Tue, 11 Sep 2018 11:13:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=U+5Q9dFq9A9CMe2Hinvh1wT0s40Nc4ikP9UNqEzDx+g=; b=sG1JdAxYqOOFOlc1viQubv6b7L84Cie0mCmHG2Tv77WD3sKAUIkxV/CVzCbbO28gut 2i4WTbJYJ2poUddobYww0jyZAUoqutdLXuwX/44jDfFHHgmROtnD+ZNzF2kT1qEMFR4C nVJEeQsP1pIGrNpSjqsnbF/mD7DeOti4+NLWC52MQYwu+Y9LgDi7UaKduYZNH5NhZ7gR Vre6MmU82WVWJeYI9vbIeUPwvp2I8IuA/hUjIpPzFVp+ETiFDMDcdw2wCPrNKxOpbdgs OkEvFbrQsVJRR6HPefCnI4ltkjX5TpZ2aBjmTaPqT44avb8mCT/qejpZ/jvzdHIYRh5Y pwkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=U+5Q9dFq9A9CMe2Hinvh1wT0s40Nc4ikP9UNqEzDx+g=; b=q2S0MC5YzNcSJ52rEb9sUhti5ok7J4FvGrTZ/XC7ybThTHtXDmKg7vjpCruAmDHk5w 0pDZDZbVfGTxbVMimSd3bMq2pQVrSAJCWgr6SC2faeIMZAFThVccy4MkmbJtR7EPPJ77 IRHJDlssvakSURkrthq4ZgmnidjVtxJgNmoMxy4Vkjwu8Xdk3/UKsrAejaSvK1YemtdJ soo8twSBqQ/rvETjJN2l5yu1oXZKbjcNRbbow1rgxdrUaNXNmT7Rd9PpkiIS8s6XFwGC m+XbELa1QZfP3mYW2zagIg/tMfTLJxUnsGlwG2z9jFxKBP/9LDucMWOLuzmbUamdFHj0 MO8Q==
X-Gm-Message-State: APzg51AJAcf1J6mDVWdKivS4NQ3etOj02aD9w6m4F5HBrv1qRp4B5BNa pTDb2y9Q1BY14U4VAD4ZnK4=
X-Google-Smtp-Source: ANB0VdZIVXDXcOJa4AVoBJ5ei0+QxbIFGz+LMwArba8++pJj5+UAdpZUofB9XNto79D9asLTV8ZgAA==
X-Received: by 2002:a62:9c17:: with SMTP id f23-v6mr30838228pfe.209.1536689633045; Tue, 11 Sep 2018 11:13:53 -0700 (PDT)
Received: from [10.31.79.252] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id d24-v6sm23538163pgv.23.2018.09.11.11.13.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 11:13:52 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <153667812809.16741.10796738054406466412.idtracker@ietfa.amsl.com>
Date: Tue, 11 Sep 2018 11:13:51 -0700
Cc: The IESG <iesg@ietf.org>, draft-ietf-lisp-rfc6833bis@ietf.org, Luigi Iannone <ggx@gigix.net>, lisp-chairs@ietf.org, Dino Farinacci <farinacci@gmail.com>, "lisp@ietf.org list" <lisp@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9D08CA59-8AC4-4866-944E-98553C37E547@gmail.com>
References: <153667812809.16741.10796738054406466412.idtracker@ietfa.amsl.com>
To: Mirja Kühlewind <ietf@kuehlewind.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/6h_sc0ImfpYFRBF7nKBT9ZXDS0k>
Subject: Re: [lisp] Mirja Kühlewind's Discuss on draft-ietf-lisp-rfc6833bis-13: (with DISCUSS and COMMENT)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Sep 2018 18:13:57 -0000

> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-lisp-rfc6833bis-13: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/

Thanks again for your comments Mirja.

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 1) Versioning and backward compatibility
> 
> Section 5.2 says: "Support for requesting multiple EIDs in a single Map-Request
>      message will be specified in a future version of the protocol."
> However, there is no versioning mechanism for this protocol specified. How is
> versioning supposed to work?

The multiple EID-record encoding is already spec’ed and is in the protocol. And since Map-Requests are triggered by packet arrival or network management tools, they tend to be sent for a single EID. What is for further study is if a ITR would want the entire map-cache, so would it request a set of aggregates and would a replier return all more specifics for the aggregates requested.

> Further given there is no new version, I wonder if the changes as outlined in
> section 10 are all backward-compatible? Especially for the introduction of the
> Message-Notify-Ack message, I guess there is no problem if a server sends it,
> however, as the sender of the Message-Notify message might not know if the
> other end supports sending of the Message-Notify-Ack it can't rely on it. This
> should be further discussed in the doc! Or is there another strategy to achieve
> backward compatibility?

The Map-Notify-Ack has been there since day-1 in implementations. This is just IETF catching up. And it took over 5 years. So we really don’t have a compatibility situation. And didn’t want to create one in the specifications. So consider it a day 1, version 1 message. It really wasn’t added later.

And big part of this push for standardization is to have the specs “catch up” with the implementations. The implementations are way further ahead than the specs.

> 2) Size and MTU
> 
> As outlined in the TSV-ART review (Thanks Colin!) this document does not
> discuss fragmentation or Path MTU discovery. RFC8085 recommends to either

> perform Path MTU discovery or limit the message to 576 bytes for IPv4 or 1280
> bytes for IPv6 (minus any static header). As this seems to be an appropriate
> size for LISP messages, I would recommend this approach. Relying on IP
> fragmentation (as indicated in the reply to the TSV-ART review) is not
> recommended by RFC8085 as this would lead to IP packet without a UDP header, in
> the case of LISP, which can cause problem and loss when NATs are involved. In
> any case the chosen approach needs to be further discussed in the doc.
> 

This is a data-plane feature so it is discussed in 6830bis and RFC6830.

> 3) Rate-limiting and congestion control
> 
> Sec 5.3: "Map-Requests MUST be rate-limited.  It is RECOMMENDED that a Map-
>   Request for the same EID-Prefix be sent no more than once per second."
> As already noted by the TSV-ART review (Thanks Colin!), RFC8085 actually
> recommends to not send more the one packet per 3 seconds, and that is a
> restriction for all traffic not on a per-receiver base, or implement congestion
> control. This limit is meant to not only protect the receiver but also the
> network from overloading. Why do you use a smaller interval here? Also if
> (appropriate) rate limiting is used, this should either be a MUST or more
> explanation when it is okay to use a smaller rate limit should be provided.
> However, after all, I don't think you those the right approach here for rate
> limiting. A Map-Request is always expected to be followed by some reply. For
> these kind of communication pattern, RFC8085 recommends to limit the number of
> outstanding requests to 1 (see sec 3.1.1 of RFC8085 recommending one packet per
> RTT), also for all traffic and not only per receiver. However, this would also
> require to implement some simple mechanism to detect a message as lost (see
> also further below in point 4).

We have referenced RFC8085 in the too be published -14 version of 6833bis.

> Similarly I'm not sure about the intent of this requirement in section 5.5:
> "Map-Replies SHOULD be sent for an EID-Prefix no more often than once
>   per second to the same requesting router. "
> My understanding is that Replies are only sent when a request is received. Why
> is this additional rate limit needed? Again if used it should be 3 seconds for
> all traffic to be inline with RFC8085. Also again, why is that not a MUST?
> Further recommendation are needed here.

Because the source is a bad-actor and sending new Map-Requests (with a new nonce).

> Further section 6.1 say "Both the SMR sender and the Map-Request responder MUST
> rate-limit
>   these messages.  Rate-limiting can be implemented as a global rate-
>   limiter or one rate-limiter per SMR destination."
> This seems to be the same rate limit as mention above, or not...? It would
> probably make sense to rate limit the SMR even further. Please clarify and
> provide more guidance, e.g. what should the value of a potential additional
> rate limit for SMR be?

Some of this machinery is left to the implementor. But we have published some map-cache management guidelines in the lisp-threat RFC.

> Respectively the following sentence in section 6.1 is also unclear:
> "The remote ITR MUST rate-limit the Map-Request until it gets a Map-Reply"
> Why is the rate-limit as currently proposed depend on the fact if a Map-Reply
> is received? Is the ITR supposed to retransmit the Map-Request…?

If you are not getting answers to your Map-Requests because of packet loss or MITM, sending them faster is not going to get you a Map-Reply.

> And finally the Map-Register, Map-Notify and Map-Notify-Ack messages does not
> seem to have any rate-limits. Recommendations inline with RFC8085 should be
> provided for the total traffic and not only for a few message types. Again,
> Map-Notify and Map-Notify-Ack messages should be send only once per RTT as
> there is a feedback mechanism.

We have added that in -14.

> For Map-Register sec 8.2 say: "Map-Register messages are sent periodically from
> an ETR to a Map-
>   Server with a suggested interval between messages of one minute."
> However, this a rather a low bound than an upper bound. A required (MUST) rate
> limit is still needed.

That is not rate-limiting to avoid message reduction. It is a soft-state way of keeping registration state alive in the map-server(s).

> 4) Loss detection and retransmission
> 
> As also mention by the TSV-ART review (Once more thanks to Colin!), this spec
> has an ACK mechanism for Map-Requests and now also for Map-Notify, however, it

And Map-Notify are acks to Map-Registers when requested.

> does not specify what to do if the ACK is not received (loss detection and
> retransmission scheduling). This makes the spec incomplete and needs to be
> further specified in the doc (and also has a relation to the point 3 above of
> course).

We focus on why a Map-Request is being generated (to populate the map-cache) and a Map-Reply not only provides information to be put in the map-cache, but acts as an ackl now. If the Map-Request nonce is being replied with a Map-Reply with the same nonce, Map-Requests no longer need to be sent and the requestor is happy with the result (and hence it was reliable).

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Further comments:
> 
> 1) The example given in 5.5 should probably used IPv6 addresses and use the IP
> address space that is reserved for documentation purposes.

I disagree. I think its simpler with IPv4 addresses and shouldn’t matter. We want this complex concept to come across as clear as possible. And I believe IPv6 doesn’t do that. This is not a v4 versus v6 response. It is a notation preference.

> 2) I find the security requirements in this doc very unsatisfying. Most
> important the doc requires the support of authentication mechanism but not the
> use of it. I would like to see more clear MUST requirements here. Further,
> today and at this stage of the protocol (moving from exp to PS) I find it not
> acceptable anymore to have certain security feature as optional and outsourced
> into a different work-in-process draft. However, I leave further discussion to
> the SEC ADs.

Can you cite where this is a problem. Are you saying we are not supplying enough MUST text?

> 3) Given the following statement:
> "Note that while this document assumes a LISP-ALT database mapping
>   infrastructure to illustrate certain aspects of Map-Server and Map-
>   Resolver operation..."
> it seems that RFC6836 should be a normative reference, as it might not be
> possible to understand all details explained in this doc with knowing ALT.

I would like the lisp-chairs and/or Deborah to comment on this.

> 4) Further I would also think that I-D.ietf-lisp-mn and I-D.ietf-lisp-pubsub
> should be normative references as the meaning of the respective bits it not
> further specified in this doc. Or can these bits just be ignored if
> I-D.ietf-lisp-mn and I-D.ietf-lisp-pubsub are not implemented? If so that
> should be stated.

I would like the lisp-chairs and/or Deborah to comment on this.

> Clarification questions:
> 1) Sec 5.3.:
> "For the initial case, the destination IP
>   address used for the Map-Request is the data packet's destination
>   address (i.e., the destination EID) that had a mapping cache lookup
>   failure."
> Does that mean that the Map-Request needs to use the IPv4 or IPv6 depending on
> the IP version used by the initial message from the EID. Is that always the
> case or just for this initial message? I would assume that for all other cases
> this is actually independent...? Because otherwise there would be a constraint
> on what needs to be requested. I would like t see further clarification about
> this in the doc.

No it doesn’t. It depends on the address-family of the map-resolver. And that is configured.

> 2) In section 5.3: "The ITR MAY include all locally
>   configured Locators in this list or just provide one locator address
>   from each address family it supports."
> Would it make sense to include a SHOULD requirement to at least the address
> family that is used to send the Request is included (to increase chance to
> enable a communication/get a reply)…?

But all address-families are used all the time. And in some ITRs, usually there is no IPv6 at the edge. 

> 3) Sec 5.4: "If all Weights for a Locator-Set are equal,
>      the receiver of the Map-Reply will decide how to load-split the
>      traffic. "
> Shouldn't the receiver in this case split the traffic equally? Otherwise how
> would you signal that the traffic should be split equally? Maybe use all zero
> instead to let the receiver decide…?

It means the ITR will load-split according to hashing. Versus if the priorities are not equal, it is the ETR deciding how packets ingress the LISP site.

> 4) sec 6.1: "When an ITR receives an SMR-based Map-Request for which it does not
>   have a cached mapping for the EID in the SMR message, it may not send
>   an SMR-invoked Map-Request."
> I guess this should be normative and probably also a MUST NOT or at least
> SHOULD NOT.

Yes, I changed to SHOULD NOT. Good catch. Don’t want to make it a MUST NOT because both sides could be mobile and the remote side may need to populate its map-cache. That would allow less packet loss if we keep it SHOULD NOT versus MUST NOT.

> 5) Section 7 seems to imply that if it is detected that no route is available,
> the ITR should basically do nothing and just drop any incoming packets for that
> ETR. Would it make sense for incremental deployability, to just forward the
> packet to the IP address of the EID instead...? This way the source host would

Well no. Because the EID most likely doesn’t have a route in the underlying routing system. If there are PITRs out in the core, then the ITR will be configured to know that, a negative map-reply causes those PITRs to be used or PITRs are registering for coarse EID-prefixes.

> not benefit in mobility cases but still gets connectivity otherwise. Or is that
> anyway not the implication? If that is the case, that should be further
> clarified in the doc.

The point you are bringing up is discussed in the LISP interworking document (RFC 6832), FYI.

> 6) Section 8.2 says: "Note that the Map-Notify message
>   is sent to UDP destination port 4342, not to the source port
>   specified in the original Map-Register message."
> Actually why is that?

cisco interperability.

> Some minor editorial comments:
> 
> 1) First sentence in intro: the pointer to ietf-lisp-introduction as currently
> introduced, makes this reference look very normative: "The Locator/ID
> Separation Protocol [I-D.ietf-lisp-introduction] and [I-D.ietf-lisp-rfc6830bis]
> specifies..." I would recommend the following wording: "The Locator/ID
> Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see also
> [I-D.ietf-lisp-introduction]) specifies…"

Good recommendation. Thanks. Changed.

> 2) Also in intro: Given that 6830bis is a normative reference "LISP RFC
> 6830bis" should be replaced with the new RFC number in the text. This should be
> noted to the RFC editor; probably this is more obvious if RFCXXX is used
> instead.

What are you suggesting. A bracketed comment inline?

> 3) Sec 5.4: "...for another way the R-bit MAY be used."
> This looks like a lower case may would be more appropriate.

We fixed a bunch of incorrect capitalized MAYs and SHOULDs.

Thanks again,
Dino