Subject: Re: [lisp] Martin Duke's Discuss on draft-ietf-lisp-rfc6830bis-32: (with DISCUSS and COMMENT)

From: Martin Duke <[email-masked]>
Date: Thu, 6 Aug 2020 13:35:58 -0700

Hi Albert,

thanks for the edits, and sorry for the delay! We're not quite there on a
few of the items:

Though first, there is now a duplicate paragraph in Section 7. Please
delete one.

On Fri, Jul 31, 2020 at 5:43 AM Albert Cabellos <[email-masked]>
wrote:

>
> On Fri, Jul 3, 2020 at 9:07 PM Martin Duke via Datatracker <
> [email-masked]> wrote:
>
> >
>
> > Sec 5.3 What is in the Nonce/Map-Version field if both the N and V bits
> are
> > zero?
> >
>
> There is no field then.
>

so the bits are set to zero, or is the LISP header actually shorter by 3
octets?

>
> >
> > Sec 7.2 The stateful MTU design does not incorporate any security
> measures
> > against ICMP spoofing. At the very least, the ITR needs to make sure
> that some
> > fields in the outer IP and UDP headers are hard to guess, and that this
> > information is stored to verify that the ICMP message came from on-path.
> If
> > this is not possible, the design is not safe to use over IPv4.  If
> > hard-to-guess information is not available to be stored deeper in the
> packet,
> > then it is not safe over IPv6 either.
> >
>
> The source UDP port is random. We have therefore added the following
> statement at the beginning of section 7.7:
>
>    An ITR stateful solution to handle MTU issues is described as follows,
> this solution can only be used with IPv4-encapsulated packets:
>
>
This is backwards, and anyway inadequate.

An off-path attacker can generate a fairly small number of ICMP messages to
reduce the MTU to ridiculously low levels (e.g. 68 bytes), which depending
on tunneling overhead could render the path unusable. The defense against
this is to either ignore ICMP messages (instead using PLPMTUD
<https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/> to
find the MTU) or to compare the echoed information the ICMP message against
the stored contents of the packet, where obviously there needs to be enough
entropy to make it hard to guess. Generally the port is not sufficient
entropy, since it takes fewer than 2^16 packets to take you down, but
admittedly there isn't much UDP-based protocols can do about this.

In IPv6, the router should include as much of the packet as possible in the
ICMP packet, so the chance of guessing is low. It's therefore it's simply a
matter of specifying that hosts should store the packet payload and do the
validation step.

In IPv4, the router is required to include the first 8 bytes of the IP
payload (eg the UDP header), so all you have are the IP and UDP headers.
Hosts should still do the validation.

The main thing is to tell them to do that validation.

>
> >
> > Sec 7.2 There is a fourth situation which can arise. If the ETR receives
> an
> > ICMP packet from an EID in its network. I have a couple of questions
> about what
> > should happen in this case:
> >
>
> In this case the EID is locally attached to the xTR. Therefore, the xTR
> has a locally configured MTU to reach the EID. So what is written in the
> section already covers this scenario.
>
> >
> > - How is this communicated to the sender of the flow that triggered the
> > message? Is there an "outer" ICMP to the ITR, and "inner" ICMP to the
> source
> > EID, both, or neither?
> >
> > - Is the ETR responsible for enforcing the MTU to that EID for
> subsequent flows?
> >
>

I read 7.2 again and I don't see that it does. According to this section,
what does the ETR do when it receives a packet from the ITR that exceeds
the locally configured MTU?

Martin

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 6 Aug 2020 16:48:02 -0400

Martin, I want to check one aspect of your response about MTU handling.

The entity which is originating the packets, and receiving the ICMP 
responses, is the ITR.  In most cases, the ITR is a router.  I do not 
know of any tunnel protocol for rotuers that expects the routers to 
store state about the packets it has sent in the tunnels.
As these are low-state tunnels, and as the packets are those provided by 
the sources behind the ITR, I doubt that we can use PLPMTUD, although I 
would be happy to be given enough information to find I am wrong about that.

I am somewhat confused as to what you would have us do.
Yours,
Joel

On 8/6/2020 4:35 PM, Martin Duke wrote:
> Hi Albert,
> 
> thanks for the edits, and sorry for the delay! We're not quite there on 
> a few of the items:
> 
> On Fri, Jul 31, 2020 at 5:43 AM Albert Cabellos 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>     On Fri, Jul 3, 2020 at 9:07 PM Martin Duke via Datatracker
>     <[email-masked] <mailto:[email-masked]>> wrote:
> 
>          >
> 
>      > Sec 5.3 What is in the Nonce/Map-Version field if both the N and
>     V bits are
>      > zero?
>      >
> 
>     There is no field then.
> 
> 
>      > against ICMP spoofing. At the very least, the ITR needs to make
>     sure that some
>      > information is stored to verify that the ICMP message came from
>     on-path. If
>      > hard-to-guess information is not available to be stored deeper in
>     the packet,
>             An ITR stateful solution to handle MTU issues is described
>         as follows, this solution can only be used with
>         IPv4-encapsulated packets:
> 
> 
> An off-path attacker can generate a fairly small number of ICMP messages 
> to reduce the MTU to ridiculously low levels (e.g. 68 bytes), which 
> depending on tunneling overhead could render the path unusable. The 
> defense against this is to either ignore ICMP messages (instead using 
> PLPMTUD 
> find the MTU) or to compare the echoed information the ICMP message 
> against the stored contents of the packet, where obviously there needs 
> to be enough entropy to make it hard to guess. Generally the port is not 
> sufficient entropy, since it takes fewer than 2^16 packets to take you 
> down, but admittedly there isn't much UDP-based protocols can do about this.
> 
> In IPv6, the router should include as much of the packet as possible in 
> the ICMP packet, so the chance of guessing is low. It's therefore it's 
> simply a matter of specifying that hosts should store the packet payload 
> and do the validation step.
> 
>      > Sec 7.2 There is a fourth situation which can arise. If the ETR
>     receives an
>      > ICMP packet from an EID in its network. I have a couple of
>     questions about what
>     In this case the EID is locally attached to the xTR. Therefore, the
>     xTR has a locally configured MTU to reach the EID. So what is
>     written in the section already covers this scenario.
> 
>      >
>      > message? Is there an "outer" ICMP to the ITR, and "inner" ICMP to
>     the source
>      > EID, both, or neither?
>      >
> I read 7.2 again and I don't see that it does. According to this 
> section, what does the ETR do when it receives a packet from the ITR 
> that exceeds the locally configured MTU?
> 
> Martin
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Martin Duke <[email-masked]>
Date: Thu, 6 Aug 2020 15:24:46 -0700

Hi Joel,

I'm realizing that we may not have a consensus document that provides good
guidance on how to proceed. I'm going to consult with a couple of SMEs and
come up with a reasonable recommendation. This shouldn't take any more than
a couple of days.

However the "IPv4 only" recommendation is just wrong and should be reverted.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 6 Aug 2020 21:28:34 -0400

Exploring Martin's second comment, I looked at section 7.2 of the draft. 
  I do not see any obvious reason why this section is restricted to 
IPv4.  If there is a reason, we need to state it.  If there is no 
reason, we should allow it for the v6 case as well.

Yours,
Joel

On 8/6/2020 6:24 PM, Martin Duke wrote:
> Hi Joel,
> 
> I'm realizing that we may not have a consensus document that provides 
> good guidance on how to proceed. I'm going to consult with a couple of 
> SMEs and come up with a reasonable recommendation. This shouldn't take 
> any more than a couple of days.
> 
> On Thu, Aug 6, 2020 at 1:48 PM Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      > <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >
>      >
>      >     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >          >
>      >
>      >      > Sec 5.3 What is in the Nonce/Map-Version field if both the
>     N and
>      >     V bits are
>      >      > zero?
>      >      >
>      >
>      >     There is no field then.
>      >
>      >
>      >      >
>      >      > Sec 7.2 The stateful MTU design does not incorporate any
>     security
>      >     measures
>      >      > against ICMP spoofing. At the very least, the ITR needs to
>     make
>      >     sure that some
>      >      > fields in the outer IP and UDP headers are hard to guess, and
>      >     that this
>      >      > information is stored to verify that the ICMP message came
>     from
>      >     on-path. If
>      >      > this is not possible, the design is not safe to use over
>     IPv4.  If
>      >      > hard-to-guess information is not available to be stored
>     deeper in
>      >     the packet,
>      >      > then it is not safe over IPv6 either.
>      >      >
>      >
>      >      >
>      >      > Sec 7.2 There is a fourth situation which can arise. If
>     the ETR
>      >     receives an
>      >      > ICMP packet from an EID in its network. I have a couple of
>      >     questions about what
>      >      > should happen in this case:
>      >      >
>      >
>      >      >
>      >      > - How is this communicated to the sender of the flow that
>      >     triggered the
>      >      > message? Is there an "outer" ICMP to the ITR, and "inner"
>     ICMP to
>      >     the source
>      >      > EID, both, or neither?
>      >      >
>      >      > - Is the ETR responsible for enforcing the MTU to that EID for
>      >     subsequent flows?
>      >      >
>      >
>      >
>      > [email-masked] <mailto:[email-masked]>

---

From: Martin Duke <[email-masked]>
Date: Thu, 13 Aug 2020 15:17:17 -0700

As promised, here are my reconsidered thoughts about Section 7.2:

1) as agreed before, delete the restriction to IPv4 and restore the other
references to ICMPv6 in draft-31.

2) There is not an IETF consensus document that describes what I feel to be
the most secure way to do tunnel PMTU management. So the current design is
acceptable; however, there should be some warning about the robustness
issues here. Example text:

"Please note that [RFC1191] and [RFC1981], which describe the use of ICMP
packets for PMTU discovery, can behave suboptimally in the presence of ICMP
black holes or off-path attackers that spoof ICMP. Possible mitigations
include ITRs and ETRs cooperating on MTU probe packets ([RFC4821],
[I-D.draft-ietf-tsvwg-datagram]), or ITRs storing the beginning of large
packets to verify that they match the echoed packet in ICMP Frag
Needed/PTB."

Feel free to re-word, of course.

This can either be in the section or mentioned in security considerations
with a pointer in 7.2.

Martin

On Thu, Aug 6, 2020 at 6:28 PM Joel M. Halpern <[email-masked]> wrote:

> >      >      > fields in the outer IP and UDP headers are hard to guess,
> and
> >      >     that this
> >     <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/
> > to
> >