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

[Albert Cabellos <[e-mail]>]

Hi Mirja

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

Please let me know if you agree with them, once this is finished I´ll send
a similar reply for your COMMENTS. Once all the comments are done I´ll send
a diff for your review.

On Tue, Sep 11, 2018 at 5:02 PM Mirja Kühlewind <[e-mail]> wrote:
>
> 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/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> 1) Versioning and backward compatibility
>
> Section 5.2 says: "Support for requesting multiple EIDs in a single
Map-Request
>       message will be specified in a future version of the protocol."
> However, there is no versioning mechanism for this protocol specified.
How is
> versioning supposed to work?
>
> Further given there is no new version, I wonder if the changes as
outlined in
> section 10 are all backward-compatible? Especially for the introduction
of the
> Message-Notify-Ack message, I guess there is no problem if a server sends
it,
> however, as the sender of the Message-Notify message might not know if 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?
>

There is no support for requesting multiple EID and none of the use-cases
have this requirement. I suggest to remove the text.

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

RFC8085 states that:

Although most UDP applications are expected to follow these guidelines,
there do exist valid reasons why a specific application may decide not to
follow a given guideline.  In such cases, it is RECOMMENDED that
application designers cite the respective section(s) of this document in
the technical specification of their application or protocol and explain
their rationale for their design choice.


Our rationale is the following one, I suggest to include it on the spec:

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


> 3) Rate-limiting and congestion control
>

I suggest to state the following rate-limiters, as specified by RFC8085:

Map-Requests MUST be rate-limited, it is RECOMMENDED that a Map-Request for
the same EID-Prefix be sent no more than one packets per 3 seconds.

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

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


Additional clarifications below:

>
> Sec 5.3: "Map-Requests MUST be rate-limited.  It is RECOMMENDED that a
Map-
>    Request for the same EID-Prefix be sent no more than once per second."
> As already noted by the TSV-ART review (Thanks Colin!), RFC8085 actually
> recommends to not send more the one packet per 3 seconds, and that is a
> restriction for all traffic not on a per-receiver base, or implement
congestion
> control. This limit is meant to not only protect the receiver but also 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).
>
> Similarly I'm not sure about the intent of this requirement in section
5.5:
> "Map-Replies SHOULD be sent for an EID-Prefix no more often than once
>    per second to the same requesting router. "
> My understanding is that Replies are only sent when a request is
received. Why
> is this additional rate limit needed? Again if used it should be 3
seconds for
> all traffic to be inline with RFC8085. Also again, why is that not a MUST?
> Further recommendation are needed here.
>
> Further section 6.1 say "Both the SMR sender and the Map-Request
responder MUST
> rate-limit
>    these messages.  Rate-limiting can be implemented as a global rate-
>    limiter or one rate-limiter per SMR destination."
> This seems to be the same rate limit as mention above, or not...? It 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?
>
> Respectively the following sentence in section 6.1 is also unclear:
> "The remote ITR MUST rate-limit the Map-Request until it gets a Map-Reply"
> Why is the rate-limit as currently proposed depend on the fact if a
Map-Reply
> is received? Is the ITR supposed to retransmit the Map-Request...?
>

The reason is that an attacker can forge Map-Requests.

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

The RTT between the xTR and Map-Server and Map-Resolver can be very small
since they are typically deployed within the same network.

>
> For Map-Register sec 8.2 say: "Map-Register messages are sent
periodically from
> an ETR to a Map-
>    Server with a suggested interval between messages of one minute."
> However, this a rather a low bound than an upper bound. A required (MUST)
rate
> limit is still needed.
>
> 4) Loss detection and retransmission
>
> As also mention by the TSV-ART review (Once more thanks to Colin!), this
spec
> has an ACK mechanism for Map-Requests and now also for Map-Notify,
however, it
> does not specify what to do if the ACK is not received (loss detection 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).
>

I suggest to add the following sentence:

After sending a Map-Register, if a Map-Notify-Ack is not received after 1
second the transmitter MUST re-transmit the original Map-Register with an
exponential backoff, the maximum backoff is 1 minute.



>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Further comments:
>
> 1) The example given in 5.5 should probably used IPv6 addresses and use
the IP
> address space that is reserved for documentation purposes.
>
> 2) I find the security requirements in this doc very unsatisfying. Most
> important the doc requires the support of authentication mechanism but
not the
> use of it. I would like to see more clear MUST requirements here. Further,
> today and at this stage of the protocol (moving from exp to PS) I find it
not
> acceptable anymore to have certain security feature as optional and
outsourced
> into a different work-in-process draft. However, I leave further
discussion to
> the SEC ADs.
>
> 3) Given the following statement:
> "Note that while this document assumes a LISP-ALT database mapping
>    infrastructure to illustrate certain aspects of Map-Server and Map-
>    Resolver operation..."
> it seems that RFC6836 should be a normative reference, as it might not be
> possible to understand all details explained in this doc with knowing ALT.
>
> 4) Further I would also think that I-D.ietf-lisp-mn and
I-D.ietf-lisp-pubsub
> should be normative references as the meaning of the respective bits it
not
> further specified in this doc. Or can these bits just be ignored if
> I-D.ietf-lisp-mn and I-D.ietf-lisp-pubsub are not implemented? If so that
> should be stated.
>
> Clarification questions:
> 1) Sec 5.3.:
> "For the initial case, the destination IP
>    address used for the Map-Request is the data packet's destination
>    address (i.e., the destination EID) that had a mapping cache lookup
>    failure."
> Does that mean that the Map-Request needs to use the IPv4 or IPv6
depending on
> the IP version used by the initial message from the EID. Is that always
the
> case or just for this initial message? I would assume that for all other
cases
> this is actually independent...? Because otherwise there would be a
constraint
> on what needs to be requested. I would like t see further clarification
about
> this in the doc.
>
> 2) In section 5.3: "The ITR MAY include all locally
>    configured Locators in this list or just provide one locator address
>    from each address family it supports."
> Would it make sense to include a SHOULD requirement to at least the
address
> family that is used to send the Request is included (to increase chance to
> enable a communication/get a reply)...?
>
> 3) Sec 5.4: "If all Weights for a Locator-Set are equal,
>       the receiver of the Map-Reply will decide how to load-split the
>       traffic. "
> Shouldn't the receiver in this case split the traffic equally? Otherwise
how
> would you signal that the traffic should be split equally? Maybe use all
zero
> instead to let the receiver decide...?
>
> 4) sec 6.1: "When an ITR receives an SMR-based Map-Request for which it
does not
>    have a cached mapping for the EID in the SMR message, it may not send
>    an SMR-invoked Map-Request."
> I guess this should be normative and probably also a MUST NOT or at least
> SHOULD NOT.
>
> 5) Section 7 seems to imply that if it is detected that no route is
available,
> the ITR should basically do nothing and just drop any incoming packets
for that
> ETR. Would it make sense for incremental deployability, to just forward
the
> packet to the IP address of the EID instead...? This way the source host
would
> not benefit in mobility cases but still gets connectivity otherwise. Or
is that
> anyway not the implication? If that is the case, that should be further
> clarified in the doc.
>
> 6) Section 8.2 says: "Note that the Map-Notify message
>    is sent to UDP destination port 4342, not to the source port
>    specified in the original Map-Register message."
> Actually why is that?
>
> Some minor editorial comments:
>
> 1) First sentence in intro: the pointer to ietf-lisp-introduction as
currently
> introduced, makes this reference look very normative: "The Locator/ID
> Separation Protocol [I-D.ietf-lisp-introduction] and
[I-D.ietf-lisp-rfc6830bis]
> specifies..." I would recommend the following wording: "The Locator/ID
> Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see also
> [I-D.ietf-lisp-introduction]) specifies..."
>
> 2) Also in intro: Given that 6830bis is a normative reference "LISP RFC
> 6830bis" should be replaced with the new RFC number in the text. This
should be
> noted to the RFC editor; probably this is more obvious if RFCXXX is used
> instead.
>
> 3) Sec 5.4: "...for another way the R-bit MAY be used."
> This looks like a lower case may would be more appropriate.
>
>
> _______________________________________________
> lisp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp