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 protected]> 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 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
