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

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 <jmh@joelhalpern.com> 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
> > <albert.cabellos@gmail.com <mailto:albert.cabellos@gmail.com>> wrote:
> >
> >
> >     On Fri, Jul 3, 2020 at 9:07 PM Martin Duke via Datatracker
> >     <noreply@ietf.org <mailto:noreply@ietf.org>> 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
> > lisp@ietf.org
> > https://www.ietf.org/mailman/listinfo/lisp
> >
>