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