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

From: Albert Cabellos <[email-masked]>
Date: Wed, 9 Sep 2020 14:55:54 +0200

Hi Martin

Just posted -34 per your comments:

https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6830bis-34

1) Removed duplicate paragraph in section 7
2) Added the following sentence for clarification of what happens when N=0
and V=0: "*Finally, when both the N and V-bit are not set (N=0, V=0), then
both the Nonce and Map-Version fields are set to 0 and ignored on receipt*"
3) Removed the IPv4-only requirement in section 7.2. Please note that this
is in -35 since I missed it in the first place.
4) Added the following paragraph (yours, verbatim) at the end of section
7.2:

*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.*

Albert

On Fri, Aug 14, 2020 at 12:17 AM Martin Duke <[email-masked]>
wrote:

> 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:
>
>> 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.
>> >
>> > However the "IPv4 only" recommendation is just wrong and should be
>> reverted.
>> >
>> > On Thu, Aug 6, 2020 at 1:48 PM Joel M. Halpern <[email-masked]
>> > <mailto:[email-masked]>> wrote:
>> >
>> >     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:
>> >      >
>> >      > 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] <mailto:[email-masked]>
>> >     <mailto:[email-masked]
>> >     <mailto:[email-masked]>>> wrote:
>> >      >
>> >      >
>> >      >     On Fri, Jul 3, 2020 at 9:07 PM Martin Duke via Datatracker
>> >      >     <[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.
>> >      >
>> >      >
>> >      > 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
>> >      >
>> >      > _______________________________________________
>> >      > lisp mailing list
>> >      > [email-masked] <mailto:[email-masked]>
>> >      > https://www.ietf.org/mailman/listinfo/lisp
>> >      >
>> >
>>
>>

---

From: Martin Duke <[email-masked]>
Date: Wed, 9 Sep 2020 14:36:53 -0700

Thanks Albert!

This all looks great, except one last thing that dropped out of the thread:

>>
>> 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.

I don't see why this is the case. In Sec 7.2, option 3 implies that the ITR
is not immediately attached to some endpoints. Why couldn't an ETR receive
an ICMP message from one of its destinations?

On Wed, Sep 9, 2020 at 5:56 AM Albert Cabellos <[email-masked]>
wrote:

> and V=0: "*Finally, when both the N and V-bit are not set (N=0, V=0),
> then both the Nonce and Map-Version fields are set to 0 and ignored on
> receipt*"
>>> >      >      > fields in the outer IP and UDP headers are hard to
>>> guess, and
>>> >      >     that this
>>> >      > section, what does the ETR do when it receives a packet from
>>> the ITR

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 9 Sep 2020 17:50:38 -0400

Martin, just trying to clarify the question.
A packet arriving at the final destination as the destination EID as the 
destination IP address, and the source EID as the source IP address.  If 
something between the ETR and the destination EID generates an ICMP (of 
any kind) it will be addressed to the source EID, not to the ETR.  It 
will go back presumably through the ITR 9which might be the same device 
as the ETR).  But it will simply be processed as an IP packet, not as an 
ICMP for local consumption at the xTR.
If that is the case you meant, there is no ETR behavior for it.
If you meant some other case, can you please elaborate?

Thank you,
Joel

On 9/9/2020 5:36 PM, Martin Duke wrote:
>>> 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.
> 
> I don't see why this is the case. In Sec 7.2, option 3 implies that the 
> ITR is not immediately attached to some endpoints. Why couldn't an ETR 
> receive an ICMP message from one of its destinations?
> 
> On Wed, Sep 9, 2020 at 5:56 AM Albert Cabellos 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Martin
> 
>     2) Added the following sentence for clarification of what happens
>     when N=0 and V=0: "/Finally, when both the N and V-bit are not set
>     (N=0, V=0), then both the Nonce and Map-Version fields are set to 0
>     and ignored on receipt/"
>     3) Removed the IPv4-only requirement in section 7.2. Please note
>     that this is in -35 since I missed it in the first place.
>     4) Added the following paragraph (yours, verbatim) at the end of
>     section 7.2:
> 
>     /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./
> 
>     Albert
> 
> 
>     On Fri, Aug 14, 2020 at 12:17 AM Martin Duke
>     <[email-masked] <mailto:[email-masked]>> wrote:
> 
>         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."
> 
>         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] <mailto:[email-masked]>> wrote:
> 
>              > However the "IPv4 only" recommendation is just wrong and
>             should be reverted.
>              >
>              > On Thu, Aug 6, 2020 at 1:48 PM Joel M. Halpern
>             <[email-masked] <mailto:[email-masked]>
>              > <mailto:[email-masked]
>             <mailto:[email-masked]>>> wrote:
>              >
>              >     Martin, I want to check one aspect of your response
>             about MTU handling.
>              >
>              >     responses, is the ITR.  In most cases, the ITR is a
>             router.  I do not
>              >     the sources behind the ITR, I doubt that we can use
>             PLPMTUD, although I
>              >      > 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]
>             <mailto:[email-masked]>
>             <mailto:[email-masked]>>
>             <mailto:[email-masked]>
>             <mailto:[email-masked]>>>> wrote:
>              >      >
>              >      >
>              >      >     On Fri, Jul 3, 2020 at 9:07 PM Martin Duke via
>             Datatracker
>              >      >     <[email-masked] <mailto:[email-masked]>
>             <mailto:[email-masked] <mailto:[email-masked]>>
>              >     <mailto:[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.
>              >      >
>              >      >
>              >      > 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
>              >      >
>              >      > _______________________________________________
>              >      > lisp mailing list
>              >      > [email-masked] <mailto:[email-masked]>
>             <mailto:[email-masked] <mailto:[email-masked]>>
>              >      > https://www.ietf.org/mailman/listinfo/lisp
>              >      >
>              >
>

---

From: Martin Duke <[email-masked]>
Date: Wed, 9 Sep 2020 15:02:14 -0700

Thanks Joel,

Yes, that is the case I meant, and I see now that it will work just fine.
Thanks for thinking it through with me.

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 9 Sep 2020 15:11:46 -0700

> On Sep 9, 2020, at 3:02 PM, Martin Duke <[email-masked]> wrote:
> 
> Yes, that is the case I meant, and I see now that it will work just fine. Thanks for thinking it through with me.

And note the ICMP packet could exit a different ITR and get encap’ed to a different ETR at the LISP site where the original source EID resides. But that is normal LISP operation. 

Dino