Thanks Albert! This all looks great, except one last thing that dropped out of the thread:
>> >> 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. I don't see why this is the case. In Sec 7.2, option 3 implies that the ITR is not immediately attached to some endpoints. Why couldn't an ETR receive an ICMP message from one of its destinations? On Wed, Sep 9, 2020 at 5:56 AM Albert Cabellos <[email protected]> wrote: > 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
