Subject: [lisp] Tsvart last call review of draft-ietf-lisp-rfc6833bis-13

From: Colin Perkins <[email-masked]>
Date: Mon, 03 Sep 2018 05:54:57 -0700

Reviewer: Colin Perkins
Review result: On the Right Track

I've reviewed this document as part of the transport area review team's ongoing
effort to review key IETF documents. These comments were written primarily for
the transport area directors, but are copied to the document's authors for
their information and to allow them to address any issues raised. When done at
the time of IETF Last Call, the authors should consider this review together
with any other last-call comments they receive. Please always CC
[email-masked] if you reply to or forward this review.

I have several concerns with the transport aspects of this draft. Many of these
appear to be present in RFC 6833 also, but I note that while RFC 6833 is an
Experimental, this draft is targeted at the Standards Track. Some of these
issues may not be of practical concern, depending on the way LISP is used, and
might just need clarifications in the draft to make it clear they do not occur
in practice.

The draft defines the LISP control plane. It updates and greatly extends RFC
6833. The control plane runs over UDP, and this draft defines the format of
LISP control plane messages and rules for processing such messages. The packet
formats generally contain lists of records, the length of which is indicated by
an 8-bit Record Count field located in a common sub-header. The format allows
packets that are larger than the typical path MTUs seen in the Internet, but
the draft doesn’t mention Path MTU discovery to determine the largest packet
that can be sent, or how large packets are fragmented. Perhaps the messages are
small enough that this is not a practical issue? In which case the draft should
explain and justify this for each message type (and perhaps put limits on the
Record Count to ensure it). Alternatively, then the draft should specify how
path MTU discovery is to be performed, and how protocol messages should be
fragmented (or subdivided) to fit the path MTU. Section 3.2 of RFC 8085 has
some further discussion and suggestions for how to address this issue.

The draft does not mention congestion control, but many of the messages are
rate limited. If the intent of the rate limits is that no further congestion
control is needed, then it needs to be made explicit that this is the case, and
some justification needs to be added to explain why it is safe. This could,
perhaps, take the form of an appendix that analyses the expected control plane
traffic that will flow over a particular path when the protocol is in use, and
demonstrates that this will be low enough rate not to be problematic. In any
case, the draft needs some discussion of how congestion control is addressed.

It’s unclear what messages need to be retransmitted if they’re lost, and how to
determine if a message is lost (e.g., what is the timeout) and what is the
retransmission schedule. This may be clear to a reader with an in-depth
understanding of LISP, but it would be helpful to provide more explicit
statements about loss detection and retransmission.

Many of these issues could perhaps be addressed by running the control plane
over TCP rather than UDP, as is beginning to happen with the DNS. I understand
that this would be a significant late change to the protocol.

The control plane messages contain embedded IP addresses. Does this cause any
issues in the presence of NAT boxes, either by leaking information about
private addressing or by distributing addresses that are unreachable outside
their realm? I noticed there is a mention of an individual draft on LISP NAT
Traversal in Section 5.6, but the embedded addresses are included in more
places.

Regards,
Colin

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 4 Sep 2018 09:33:15 -0700

> [email-masked] if you reply to or forward this review.

Thanks a lot for the review Colin.

> might just need clarifications in the draft to make it clear they do not occur

Let me try helping with the clarification and if we need to add clarification text, by all means, we will do so.

> 6833. The control plane runs over UDP, and this draft defines the format of

I hope you understand why it greatly updates RFC6833. It was due to the working group’s decision to move the control-plane elements out of RFC 6830 into RFC 6833bis. So the procedures and protocols are not new just re-located.

> some further discussion and suggestions for how to address this issue.

The control-plane does’t try to send MTU size packets. It depends on IP fragmentation/reassembly. But an implementation should know it cannot build a LISP message larger than 65535 bytes.

> control is needed, then it needs to be made explicit that this is the case, and

Yes, that is the intent.

> case, the draft needs some discussion of how congestion control is addressed.

The flow-control is coupled with protecting caches as well as request and register load on map-resolvers and map-servers.

> statements about loss detection and retransmission.

Map-Registers are sent periodically but the text says that if Map-Notify messages are desired for acknowledgement, the Map-Registers can be transmitted more quickly in the case of loss.

Map-Notify messages are obviously acknowledgement by Map-Notify-Ack. That was an added message to RFC6833bis.

Map-Requests and Map-Replies are reliability sent for cache population. And the nonce is used for both security purproses and to associated a Map-Reply to a previous sent Map-Request, which is rate-limited.

That is pretty much it and I think is explained in pretty much detail. So if you have any specific comments, please provide them. Thanks.

> that this would be a significant late change to the protocol.

We have a draft that is considering running the LISP control-plane over TCP/QUIC with the addition of encryped security TLS/QUIC. But not as a replacement to UDP but so an LISP control-plane implementation cam be simplfied.

> Traversal in Section 5.6, but the embedded addresses are included in more

We want private addresses to be inside of LISP control-plane packet payload because there are cases where two xTRs want to determine if they are behind the same NAT, so they can encapsulate directly to each other with those private addresses. For xTRs that are not behind this common NAT, RLOC-probing will tell them they cannot reach the private address.

Yes, there is a NAT-traversal draft that has been a alive for quite a long time. Many of us are trying to simplify the operation of LISP NAT-traversal with implementation and deployment experience.

Thanks again,
Dino

---

From: Colin Perkins <[email-masked]>
Date: Wed, 12 Sep 2018 13:43:53 +0100

> On 4 Sep 2018, at 17:33, Dino Farinacci <[email-masked]> wrote:
>> Reviewer: Colin Perkins

Apologies for the slow follow-up.

> The control-plane does’t try to send MTU size packets. It depends on IP fragmentation/reassembly. But an implementation should know it cannot build a LISP message larger than 65535 bytes.

I’m not convinced relying on IP fragmentation is a good idea. In the best case, loss of a fragment results in loss of the entire packet, multiplying the effective loss rate. There can also be middleboxes that drop fragments. It would be better if the control place could fragment to MTU size packets (either the actual MTU, or a typical MTU – 1280 octets perhaps).

> The flow-control is coupled with protecting caches as well as request and register load on map-resolvers and map-servers.

Sure, but as I mentioned, the draft needs some justification for why this is safe from a congestion control viewpoint.

> That is pretty much it and I think is explained in pretty much detail. So if you have any specific comments, please provide them. Thanks.

I perhaps missed it, but didn’t see any discussion of timeouts to detect loss, retransmission frequency, how often retransmissions should be retried before giving up, and what might happen if the retransmissions fail. It’s not sufficient to just say a response is retransmitted, without saying how loss is detected and how retransmissions work.

> We have a draft that is considering running the LISP control-plane over TCP/QUIC with the addition of encryped security TLS/QUIC. But not as a replacement to UDP but so an LISP control-plane implem…

I’d encourage this work, with the goal of eventually replacing the UDP-based transport.

> We want private addresses to be inside of LISP control-plane packet payload because there are cases where two xTRs want to determine if they are behind the same NAT, so they can encapsulate directl…

That’s fine, there should be some discussion of the privacy implications of exposing those addresses. The WebRTC community has run into considerable issues due to leaking IP addressing information – perhaps this is not a concern for LISP, but the issue should be considered, if only to add a note explaining why it’s not a concern.

Is there a need to protect the addresses? STUN uses XOR-mapping of embedded IP addresses, because NATs were found that tried to translate embedded IP addresses, outside of the IP header, and broke the protocol. Does LISP need something similar?

-- 
Colin Perkins
https://csperkins.org/

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 12 Sep 2018 11:58:13 -0700

Thanks for the response, no worries on the slow follow-up. I have cut out some email text.

> I’m not convinced relying on IP fragmentation is a good idea. In the best case, loss of a fragment results in loss of the entire packet, multiplying the effective loss rate. There can also be middl…

Well an implementation can certainly build messages of effective MTU length which in most cases is 1280/1500 as well.

> Sure, but as I mentioned, the draft needs some justification for why this is safe from a congestion control viewpoint.

Can you suggest some simple text that would be sufficient. We have done the analysis in other drafts. Would simply pointing a reference to them be sufficient you think?

> I’d encourage this work, with the goal of eventually replacing the UDP-based transport.

Fabio and Marc have been working on it. A draft expired, so I don’t know their status. I agree with you.

> That’s fine, there should be some discussion of the privacy implications of exposing those addresses. The WebRTC community has run into considerable issues due to leaking IP addressing information…

This only happens in the NAT-traversal cases. I think it should go in the Security Consideration section of that draft. Not this draft. The standardization effort at this point in time is not including NAT-traversal mechanisms because that draft has not been accepted as a working group draft yet.

> Is there a need to protect the addresses? STUN uses XOR-mapping of embedded IP addresses, because NATs were found that tried to translate embedded IP addresses, outside of the IP header, and broke…

No it doesn’t but as we evolved the NAT-traversal draft, we will consider this. Thanks for the heads-up.

Thanks again,
Dino

---

From: Colin Perkins <[email-masked]>
Date: Wed, 19 Sep 2018 13:41:29 +0100

Some follow-up comments inline.
Colin

> On 12 Sep 2018, at 19:58, Dino Farinacci <[email-masked]> wrote:
> 

I’d suggest that the document provide guidance on doing this, since relying on IP fragmentation is going to be problematic.

> Can you suggest some simple text that would be sufficient. We have done the analysis in other drafts. Would simply pointing a reference to them be sufficient you think?

If the analysis exists elsewhere, then referencing it is likely sufficient. If not, this needs analysis by someone who understands LISP to explain why it won’t cause congestion. I’m not a LISP expert, so cannot do that analysis.

> This only happens in the NAT-traversal cases. I think it should go in the Security Consideration section of that draft. Not this draft. The standardization effort at this point in time is not inclu…

Putting the details into the NAT traversal draft likely makes sense, but I do think a brief addition to highlight that there may be an issue, and to point to the discussion elsewhere, would be worthwhile.

> _______________________________________________
> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art

-- 
Colin Perkins
https://csperkins.org/

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 19 Sep 2018 08:50:42 -0700

> I’d suggest that the document provide guidance on doing this, since relying on IP fragmentation is going to be problematic.

Did you see the text we added to the posted draft-ietf-lisp-rfc6833bis-15?

> If the analysis exists elsewhere, then referencing it is likely sufficient. If not, this needs analysis by someone who understands LISP to explain why it won’t cause congestion. I’m not a LISP expe…

Okay.

> Putting the details into the NAT traversal draft likely makes sense, but I do think a brief addition to highlight that there may be an issue, and to point to the discussion elsewhere, would be wort…

There is no issue. The private address RLOCs are probed by ITRs and found unreachable. So they are not used to encapsulate packets to.

Dino