Subject: Tsvart last call review of draft-ietf-lisp-rfc6830bis-15

From: Brian Trammell <[email-masked]>
Date: Mon, 27 Aug 2018 07:35:48 -0700

Reviewer: Brian Trammell
Review result: Ready with Issues

>From a transport standpoint, this document is basically OK -- I suspect that
there are probably more transport-relevant issues to consider on 6833bis, but I
did not review it. Two issues with the dataplane:

(1) Common advice to all UDP-using encapsulation designers and implementors:
please read RFC8085, especially section 3.1.11. As LISP's dataplane is
basically an application of UDP, I was surprised to see no reference to RFC8085
here. I believe that in the most common case LISP falls into case 1 here, but
implementors of LISP ITRs should at least be made aware of the other cases.

(2) This is not transport-specific. Reading the document, it struck me that the
design of the protocol has a few inherently unsafe features related to the fact
that its wire image is neither confidentiality- nor integrity-protected. I
think that all of the potential DDoS and traffic focusing attacks I could come
up with in the hour I spent reviewing the document are indeed mentioned in the
security considerations section, but as the security considerations section
does not give any practical mitigation for dataplane overload attacks, it seems
to be saying that RLOC addresses shouldn't be Internet-accessible, which as I
understand it is not the point of LISP. I haven't seen a secdir review on this
document yet, but I'd encourage the authors to do everything it asks.

nit: Section 7.1. para 7 should note that the ICMPv6 message sent is called
Packet Too Big, not Unreachable/Frag Needed.

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 27 Aug 2018 10:36:42 -0700

> implementors of LISP ITRs should at least be made aware of the other cases.

I don’t see a section 3.1.11 in RFC 8085. Rather than make references, can you say what you think the issue is?

> document yet, but I'd encourage the authors to do everything it asks.

RFC 8061 goes along with RFC6830bis. It addresses data-plane confidentiality.

> Packet Too Big, not Unreachable/Frag Needed.

We used “Packet Too Big” for all ICMP messages including IPv4 and hence we received comments about it on how it should change it to Network Unreachable. I will fix this for IPv6.

Dino

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Mon, 27 Aug 2018 21:38:59 +0200

Hi Dino, all,

Sent from my iPhone

On 27 Aug 2018, at 19:36, Dino Farinacci <[email-masked]> wrote:

> I don’t see a section 3.1.11 in RFC 8085.

Page 16, “UDP tunnels”.

> Rather than make references, can you say what you think the issue is?

LISP’s data plane is a UDP tunnel, and as such there are congestion control issues that must be considered. LISP inplementors and deployers using LISP to carry a mix of traffic that is not predominantly 

> RFC 8061 goes along with RFC6830bis. It addresses data-plane confidentiality.

I haven’t read 8061 yet, but I probably should before continuing this thread.

I will say that I’m far less concerned about LISP header confidentiality than I am about LISP header integrity, given the opportunities for on-path meddling and off-path spoofing. If the common solution to both is something like sticking everything on the ITR-ETR path in IPSec then this is less of a concern.

> We used “Packet Too Big” for all ICMP messages including IPv4 and hence we received comments about it on how it should change it to Network Unreachable. I will fix this for IPv6.

Yeah, this is the one place where i noticed a rough edge on supporting v4 and v6. Thanks.

Cheers,

Brian

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

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 27 Aug 2018 13:39:34 -0700

> LISP’s data plane is a UDP tunnel, and as such there are congestion control issues that must be considered. LISP inplementors and deployers using LISP to carry a mix of traffic that is not predomin…

Could you finish your sentence. 

I am not sure what more we can say. There is an depth discussion about DSCP fields and how to use ECN. Basically copies the inner values to the outer header equiv values.

> I will say that I’m far less concerned about LISP header confidentiality than I am about LISP header integrity, given the opportunities for on-path meddling and off-path spoofing. If the common sol…

Well RFC8061 does AEAD on the payload. All data *after* the LISP header. The encryption is a more integrated model than IPsec, so we can be more efficient by not using extra IP headers and extra control/key exchange protocols.

> Yeah, this is the one place where i noticed a rough edge on supporting v4 and v6. Thanks.

Fixed. Submitted a new revision a few hours ago.

Dino

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Mon, 27 Aug 2018 23:14:19 +0200

hi Dino,

> On 27 Aug 2018, at 22:39, Dino Farinacci <[email-masked]> wrote:
> 
> 

sorry, ate an interrupt, sorry about that.

... "congestion controlled itself (i.e., carried by any IETF transport) need to be aware that the ITR is ultimately responsible for not causing undue congestion, for example, using a circuit breaker."

> I am not sure what more we can say. There is an depth discussion about DSCP fields and how to use ECN. Basically copies the inner values to the outer header equiv values.

Concretely, I'd add a pointer to RFC 8085, especially section 3.1.11.

> Well RFC8061 does AEAD on the payload. All data *after* the LISP header.
> The encryption is a more integrated model than IPsec, so we can be more efficient by not using extra IP headers and extra control/key exchange protocols.

Okay, that's all well and good. The LISP header itself isn't integrity protected, though?

Thanks, cheers,

Brian

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 27 Aug 2018 14:29:03 -0700

>> LISP’s data plane is a UDP tunnel, and as such there are congestion control issues that must be considered. LISP inplementors and deployers using LISP to carry a mix of traffic that is not predominantly"
> ... "congestion controlled itself (i.e., carried by any IETF transport) need to be aware that the ITR is ultimately responsible for not causing undue congestion, for example, using a circuit breaker.”

Well I hear you, but you know there is a lot of technology developed that uses UDP tunneling. And in this case, it isn’t used like a traditional transport whereby a node is originating traffic. In this case, a LISP router is forwarding packets just like any other IP router forwarding IP packets.

> Concretely, I'd add a pointer to RFC 8085, especially section 3.1.11.

But I am not sure what supporting text we should put around the reference. Please advise.

> Okay, that's all well and good. The LISP header itself isn't integrity protected, though?

It is not, unless the outer UDP checksum is used. Which we suggest to be 0 and when NATs make it non-zero, ETRs ignore it.

Dino

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 28 Aug 2018 08:42:08 +0200

hi Dino, all,

> On 27 Aug 2018, at 23:29, Dino Farinacci <[email-masked]> wrote:
> 

Yep. 8085 is where the we put our best current practices for doing this sort of thing, so IMO it's important for implementors to be aware of the things it says relative to tunneling.

> But I am not sure what supporting text we should put around the reference. Please advise.

I'd suggest inserting a new paragraph after paragraph 2 of section 5, something like:

NEW:

As LISP uses UDP encapsulation to carry traffic between ITRs and ETRs across the Internet, implementors should be aware of the provisions of [RFC8085], especially those given in section 3.1.11 on congestion control for UDP tunneling.

> It is not, unless the outer UDP checksum is used. Which we suggest to be 0 and when NATs make it non-zero, ETRs ignore it.

Ah. Okay, so two things:

(1) By "integrity protection" I mean "cryptographic integrity protection", in the sense of "preventing on-path attackers or off-path spoofers from being able to influence ITR/ETR state through crafted LISP headers to the detriment of the traffic of others". Looking over 8061, it seems to only cover confidentiality of the data-plane payload, which is extremely useful but not sufficient to prevent these attacks.

The attacks seem to be well enumerated in 6830bis, but the lack of a stated mitigation beyond "be careful" seems to suggest that the mitigation is "don't use LISP", which is of course less than desirable. I'm trying to understand whether the deployment scenarios envisioned for LISP make these attacks less likely (for instance, because the ITR/ETR path itself is generally cryptographically protected with its own outer tunnel), or whether this is something that this document (or a future companion to 8061) needs to worry about.

(2) Checksums provide what I'd call "corruption protection". On "setting the outer UDP checksum to zero", please be aware that this may have undesirable interactions with IPv6 headers; see also section 3.4 (Checksum Guidelines) of 8085.

Thanks, cheers,

Brian

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 28 Aug 2018 09:49:15 -0700

> As LISP uses UDP encapsulation to carry traffic between ITRs and ETRs across the Internet, implementors should be aware of the provisions of [RFC8085], especially those given in section 3.1.11 on c…

Consider it added to Section 5 “LISP Encapsulation Details”, last paragraph.

> (1) By "integrity protection" I mean "cryptographic integrity protection", in the sense of "preventing on-path attackers or off-path spoofers from being able to influence ITR/ETR state through craf…

Well at this point in the generation of LISP, the only text I think to mitigate LISP header corruption is to indicate that a LISP ITR can use an outer IPsec header if protection of the UDP and LISP headers need protection. Or is that not a strong enough statement?

> The attacks seem to be well enumerated in 6830bis, but the lack of a stated mitigation beyond "be careful" seems to suggest that the mitigation is "don't use LISP", which is of course less than des…

I think so because of 8061.

> (2) Checksums provide what I'd call "corruption protection". On "setting the outer UDP checksum to zero", please be aware that this may have undesirable interactions with IPv6 headers; see also sec…

If we don’t go IPsec route, we go with the checksum route. What do you think? Meaning, that if LISP header protection is desiriable, use UDP checksums. 

> Brian

Thanks for the commentary and discussion,
Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 28 Aug 2018 09:53:29 -0700

Here is the latest diff for -17.

Dino

> On Aug 28, 2018, at 9:49 AM, Dino Farinacci <[email-masked]> wrote:
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 28 Aug 2018 14:36:17 -0500

Hi, Dino,

On Tue, Aug 28, 2018 at 11:49 AM Dino Farinacci <[email-masked]> wrote:

> > As LISP uses UDP encapsulation to carry traffic between ITRs and ETRs
> across the Internet, implementors should be aware of the provisions of
> [RFC8085], especially those given in section 3.1.11 on congestion control
> for UDP tunneling.
>

Thanks for that. It's the right thing to do (at least in my ballot
position) :-)

Spencer

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 28 Aug 2018 12:56:54 -0700

> Thanks for that. It's the right thing to do (at least in my ballot position) :-)

Ack Spencer. Thanks.

Dino

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 29 Aug 2018 11:36:33 +0200

hi Dino,

> On 28 Aug 2018, at 18:49, Dino Farinacci <[email-masked]> wrote:
> 

Looks good, thanks!

> Well at this point in the generation of LISP, the only text I think to mitigate LISP header corruption is to indicate that a LISP ITR can use an outer IPsec header if protection of the UDP and LISP…

We're talking past each other here, I think.

There are, as I see it, two completely separate problems here:

(1) The document permits/recommends zero UDP checksum on IPv6 outer packets. This leaves the IPv6 header unprotected against inadvertent corruption. To prevent this, LISP should follow the guidelines in section 3.4.1 of 8085, specifically:

      Use of the UDP checksum with IPv6 MUST be the default
      configuration for all implementations [RFC6935].  The receiving
      endpoint MUST only allow the use of UDP zero-checksum mode for
      IPv6 on a UDP destination port that is specifically enabled.

and

      A UDP application MUST check that the source and destination IPv6
      addresses are valid for any packets with a UDP zero-checksum and
      MUST discard any packet for which this check fails.  To protect
      from misdelivery, new encapsulation designs SHOULD include an
      integrity check at the transport layer that includes at least the
      IPv6 header, the UDP header and the shim header for the
      encapsulation, if any [RFC6936].

See also Magnus' tsvart review on lisp-gpe; his issue A is basically the same problem.

None of this, however, defends against the second problem:

(2) Any on-path attacker, or any off-path attacker who knows the addresses of the xTRs, can guess the current state of mappings, and can spoof packets from one of them, can send packets with valid LISP headers (and, indeed, valid checksums if they so choose) which will change xTR state in ways which can lead to denial of service conditions. A cryptographic integrity check over the LISP header would prevent the on-path attacks. I *think* the nonce echo functionality can be used to prevent off path attacks, or at least allows an endpoint that suspects it is under attack to challenge

Indeed, the security considerations section (and 7835 on which it is based) acknowledges most of this, and it seems that work is ongoing to fix this (draft-ietf-lisp-sec-15), so I guess you can simply take my comment on the second problem as encouragement to get lisp-sec done (subject, of course, to the warnings in draft-trammell-optional-security-not).

Cheers,

Brian

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 29 Aug 2018 10:17:01 -0700

> See also Magnus' tsvart review on lisp-gpe; his issue A is basically the same problem.

This issue has come up at least once or twice every 2 years. We suggest a zero checksum no matter what the  outer header is because we wanted to be practical with respect to what implementations do. No matter what the IETF says, the industry has moved forward and not only do not check checksums for UDP based tunnels but if they wanted to they can’t because many hardware does not have the entire packet buffer in the forwarding engine that does header processing.

So I would not want to change our text at this point. We are very aware this is controversial but it is emotionally packed as well. UDP packets in all probability will not be missed forward because layer-2 chips do a very good job at CRC. So if its bit errors one worries about, that is very rare. If it is packet corruption due to MITM, that is another story.

We can make a reference to 8085 with respect to checksums but we have to craft the text carefully because I really don’t want to release a spec that doesn’t reflect reality. So if you can help us craft a couple sentences, we can consider putting it in.

> (2) Any on-path attacker, or any off-path attacker who knows the addresses of the xTRs, can guess the current state of mappings, and can spoof packets from one of them, can send packets with valid LISP 

They cannot if the inner header is encrypted. The EIDs will be obfuscated. All that is known is that one location is sending to another location and not who is sending to who.

> headers (and, indeed, valid checksums if they so choose) which will change xTR state in ways which can lead to denial of service conditions. A cryptographic integrity check over the LISP header would prevent the on-path attacks. I *think* the nonce echo functionality can be used to prevent off path attacks, or at least allows an endpoint that suspects it is under attack to challenge

For this context, the key-id field in the LISP header is the only precious entity. All other bits could be  MITM attacked and the ETR could verify if the settings are real or not (at some expense). If the key-id field is changed, then the ETR will get decryption or ICV errors and drop packets. Yes, I know that is a DoS.

To resolve this, I’d be willing to refer to 8085 and use checksum when users believe they need to protect the UDP and LISP headers.

What do you think?

> Indeed, the security considerations section (and 7835 on which it is based) acknowledges most of this, and it seems that work is ongoing to fix this (draft-ietf-lisp-sec-15), so I guess you can sim…

What do you think of my suggestion?

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 29 Aug 2018 11:18:19 -0700

Brian, see the second reference to RFC 8085 in the diff file below. Let me know if this could satisfy your comment. Thanks.

Dino

> On Aug 29, 2018, at 10:17 AM, Dino Farinacci <[email-masked]> wrote:
>

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Thu, 30 Aug 2018 11:57:28 +0200

hi Dino,

Almost. How about:

OLD:

When the UDP and LISP headers require integrity protection, the
methods of using UDP checksums in [RFC8085] can be considered.

NEW:

Implementors are encouraged to consider UDP checksum usage guidelines in section 3.4 of [RFC8085]. Specifically, when the UDP, LISP, and outer IPv6 headers require protection against corruption, the use of non-zero UDP checksums is RECOMMENDED.

Thanks, cheers,

Brian

> On 29 Aug 2018, at 20:18, Dino Farinacci <[email-masked]> wrote:
> 
> <rfcdiff.html>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 30 Aug 2018 07:55:16 -0700

> On Aug 30, 2018, at 2:57 AM, Brian Trammell (IETF) <[email-masked]> wrote:
> 
> hi Dino,
> 
> Almost. How about:
> 
> 
> OLD:
> 

Well if we recommend it and when describing the UDP header in the packet format section we don’t that woudl be a contracdiction. And note the IPv6 outer header cannot be protected with a UDP checksum. The link-layer CRC will do that.

NEWNEW:

Implementors are encouraged to consider UDP checksum usage guidelines in section 3.4 of [RFC8085] when
it is desirable to protect UDP and LISP headers against corruption.

What do you think?

Dino

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Thu, 30 Aug 2018 17:46:08 +0200

> On 30 Aug 2018, at 16:55, Dino Farinacci <[email-masked]> wrote:
> 
> Well if we recommend it and when describing the UDP header in the packet format section we don’t that woudl be a contracdiction.

I think my point here is that the packet format section probably shouldn't do that. :) Yes, I understand the disconnect between the reality of the situation and the

> And note the IPv6 outer header cannot be protected with a UDP checksum. The link-layer CRC will do that.

Eh, this makes assumptions about the underlying link layer's corruption characteristics that may not hold. But yeah, for most packets in most realistic situations this is the case, and I guess we've learned to live with the underlying phy error rate * 1e-10 in any case.

> it is desirable to protect UDP and LISP headers against corruption.

This seems like a fine compromise to me.

Thanks, cheers,

Brian

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 30 Aug 2018 09:09:54 -0700

Thanks for the great discussion Brian. I think we’re all in sync now?

Dino

> On Aug 30, 2018, at 8:46 AM, Brian Trammell (IETF) <[email-masked]> wrote:
> 
> 
>

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Thu, 30 Aug 2018 18:15:40 +0200

From my side, yes. Thanks a lot for your quick responses on this!

Cheers,

Brian

> On 30 Aug 2018, at 18:09, Dino Farinacci <[email-masked]> wrote:
>