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

[Martin Duke <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]
> > <mailto:[e-mail]>> 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
> >      > <[e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail]
> >     <mailto:[e-mail]>>> wrote:
> >      >
> >      >
> >      >     On Fri, Jul 3, 2020 at 9:07 PM Martin Duke via Datatracker
> >      >     <[e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]>>> 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
> >      > [e-mail] <mailto:[e-mail]>
> >      > https://www.ietf.org/mailman/listinfo/lisp
> >      >
> >
>
>