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