Robin, FWIW, the LISP stateful/stateless approaches follow those specified in RFC4213. Check there for caveats about the stateful approach, and see also RFC2003 and its predecessors.
Fred [email protected] > -----Original Message----- > From: Robin Whittle [mailto:[email protected]] > Sent: Tuesday, January 27, 2009 5:25 AM > To: RRG > Cc: [email protected] > Subject: Re: [rrg] LISP PMTU - 2 methods in draft-farinacci-lisp-11 > > Short version: Luigi suggests a method by which the ITR > can perform PMTUD to an ETR without having > to cache the original packet. This requires > three things to be done to achieve the goals > without the most obvious DoS vulnerabilities: > > 1 - The intermediate router sends back at least > 16 bytes of original packet in the PTB - > 8 bytes more than RFC 1191 requires. > > 2 - It is acceptable for the system not to > deliver the first "too long" packet. > > 3 - The sending host sends a second "too long" > packet after the ITR has received and > processed the PTB from the intermediate > router. > > If the system is supposed to work without the > PTB check requiring the LISP nonce in the PTB's > original packet fragment, then I think the ITR > still needs to store some details of recently > sent packets, to force the attacker to set some > other parts of the PTB's original packet fragment > to hard-to-guess actual values of packets sent. > > I modify my critique of LISP accordingly - this > looks like a reasonable way to do PMTUD without > the ITR maintaining a lot of state. However the > smallest amount of state would be the LISP > nonce of recently sent packets and this requires > all intermediate routers which might have an > MTU problem to send back more than the RFC 1191 > minimum of 8 bytes. > > The process of checking PTBs in a busy ITR could > become so expensive (due to the large number of > LISP nonces or other details to be checked, of > recently sent packets) that it could become a DoS > vulnerability in itself. > > How I think an off-path attacker could find the > addresses of some, many or most ITRs which are > tunneling packets to some ETR the attacker wants > to DoS. > > An ITR occasionally needs to allow longer packets > to the ETR than its current MTU setting allows - > otherwise it has no way of adapting to an > increased actual path MTU. > > > Hi Luigi, > > Thanks for your reply, in which you wrote: > > > As a member of the OpenLISP team, let me say that we do not > > *accept* or *reject* anything. AFAICT, that is left to the > > community and to the (future) LISP WG. > > OK - "rejected" was my way of stating that you didn't find the > stateless approach suitable for OpenLISP: > > http://tools.ietf.org/html/draft-iannone-openlisp-implementati > on-01#section-6.8.1 > > 6.8.1. OpenLISP local MTU Management > > During preliminary tests, we observed that the MTU issue is at the > origin of many problems. OpenLISP does not (and will not) > implement the fragmentation mechanism proposed in Sec. 5.4 of > [I-D.farinacci-lisp]. The reason is because the proposed method > sounds very primitive and does not appear to be efficient. The > original LISP specification is based on an architectural constant > used by the xTR to limit the MTU of LISP encapsulated packets. > OpenLISP uses a more advanced solution, based on the real MTU of > the local RLOCs present on the xTR, as described below. > > > > What we proposed is just an alternative approach that takes > advantage of > > ICMP messages (if they are present). > > OK - your approach makes sense. I am reading it now. > > > >> Stateful approach for all packets > >> --------------------------------- > >> > >> I am reading the LISP version - I have not looked in detail at the > >> OpenLISP source of this approach. > >> > >> This makes no reference to IPv4 DF=0 packets. So this approach of > >> the ITR sending a PTB packet to the sending host when a DF=0 packet > >> exceeds some length is not going to result in any action > on the part > >> of the sending host. Such a DF=0 packet will be dropped > by the ITR. > >> That may be OK - Ivip will do much the same - but it needs to be > >> specified clearly. > > > > The text that we provided is just a first cut. I agree that > there are > > several points to clarify. > > OK. > > >> This approach of determining the MTU to each ITR by receiving ICMP > >> messages from an intermediate router needs to be done securely. > > > > Am I wrong if I say that this means to change the ICMP protocol? > > I meant securely enough to prevent spoofing by an off-path attacker > intent on DoS. (Full description below.) > > The LISP nonce should do the trick - but that requires the > intermediate router to send back to the ITR, in the PTB message, the > 8 byte LISP header after the UDP header. RFC 1191 only requires it > to send back the outer IP header and the next 8 bytes - which in a > LISP packet is the UDP header. > > This was a pretty short-sighted requirement, I think. I don't know > how DFZ routers behave, but I recall someone (Bill Herrin?) stating > some months ago that it was common to send back more bytes than the > bare minimum of 8. If LISP or something similar was implemented in 5 > years time, I guess it wouldn't be too much to ask the router > manufacturers to create firmware updates if their routers don't > already send back a decent number of bytes such as 32 or whatever. > > Without this, the ITR can't "securely" respond to ICMP PTB messages. > > > Our goal was not to introduce new mechanisms in the core, > but rather to > > take advantage of what exists. > > OK. > > >> It requires the ITR to cache significant amounts of information for > >> every packet it sends which might trigger such a PTB. > > > > Why should the ITR cache information? > > Skip the following if you like: > > My understanding of what ITRs would have to do, before I read the > rest of your message: > > For every encapsulated packet the ITR sends which might generate > a PTB message in some router en-route to the ETR, the ITR needs > to cache - I mean store for a few seconds - the start of the > original packet and the nonce it put in the LISP header of the > encapsulating header. I guess the ITR needs to store it for a > few seconds, since it might take that long for the PTB to come > back. Technically, maybe it should hold it for longer, but my > guess is that 2 seconds should do the trick. > > Then, when a PTB arrives, the ITR needs to compare the LISP nonce > in the PTB's fragment of the initial packet (see discussion above > about how this requires more bytes than RFC 1191 requires) with > its cached information about recently sent packets. It should > also check other things such as the destination address in the > packet fragment, to ensure it is the same as the ETR to which it > tunnelled the packet. This will enable the ITR to uniquely > identify one of the packets it recently sent. Then it can adjust > for that ETR its record of path MTU, and generate a PTB packet to > be sent to the sending host, from its cached fragment of the > start of the original packet. > > After that, the ITR can use the stored value of MTU for that ETR > and use it to decide whether to accept or reject with a PTB any > packet to be tunneled to that ETR. > > I don't think your I-D doesn't mention this, but the ITR also needs > to occasionally let a longer packet be encapsulated to this ETR - a > packet long enough that once encapsulated it would exceed the ITR's > current notion of path MTU to this ETR. This will only occur if and > when one of the following occur: > > 1 - The original sending host, in the same communication session > tries its luck with a longer packet for the same reason. RFC > 1191 specifies the one sending host should not try a longer > packet to a given destination address for 10 minutes after > receiving a PTB. > > 2 - Some other sending host sending a longer packet through this > ITR to an EID address which is mapped to the same ETR. > > 3 - The same sending host, in the same or another application, > sending a long packet to a different destination address, > which may or may not be in the same EID as the first > destination address, which is mapped to the same ETR. > > Then, if the longer packet does not result in a PTB, the ITR should > probably raise its notion of the MTU to that ETR accordingly. > > However, packet loss here (loss of the too long packet before the > intermediate router with the limiting MTU, or loss of the PTB message > from that router) could result in a too-long MTU setting in the ITR. > This is not such a problem, since it would probably soon be corrected > if subsequent packets passed through the ITR due to this too-high > value and did result in a PTB being received by the ITR. > > The Ivip approach can use PTBs from intermediate routers, but does > not rely on them absolutely. It uses positive and negative > acknowledgement from the ETR for a small subset of packets which, > once encapsulated, are of a length which falls within the ITR's "zone > of uncertainty" for the path MTU to this ETR. This zone is reduced > by every such packet and would, in general, quickly diminish to zero > - after which the technique is only needed occasionally to test > whether the MTU limit has risen. > > I think would be best to store the path MTU value in a separate body > of data from however you store the mapping information. The mapping > information is indexed on EID, I assume. You might have in the > mapping cache thousands of entries which all use the same ETR. It > makes no sense to store the ETR's path MTU in every one of those > entries. I think the encapsulation process needs to check the path > MTU to the ETR after it has determined which ETR address to tunnel > each packet to. > > > >> The intermediate router would need to send back sufficient of the > >> original packet to ITR to include the LISP nonce. Otherwise, PTBs > >> spoofed by off-path attackers would be accepted and the > whole system > >> could easily be DoSed. > > > > Probably there is a DoS risk, but IMO is from on-path > attackers. How can > > an off-path attacker know that a specific ITR is sending > packets to a > > specific ETR and send a fake ICMP message to shrink the MTU > toward that > > specific ETR? > > It is easy to find out where the ITRs of a particular ISP or end-user > network are. Attackers could discover this by various means, but > here is one: They get their own EID space, which is mapped to an > RLOC address of one of their own machines - which pretends to be, or > is, an ETR. Then, the attacker sends to some host in the ISP or > end-user network a ping packet or any other packet which will elicit > a response. That packet has a source address in the attacker's EID > range, so the targeted host will send back a response to that > address. The ITR in the targeted site will look up the mapping for > the attacker's EID address and so tunnel the response packet to the > attacker's "ETR". With LISP, APT and TRRP, the encapsulation outer > header's source address is that of the ITR, so the attacker's "ETR" > learns the address of the ITR. (With Ivip, the source address is > that of the sending host.) > > So attackers can easily find the address of an ITR in some network of > its choice where there are sending hosts. It could do this en-masse > and so discover the addresses of ITRs in many such networks. > > The attacker presumably has some idea of where the sending hosts are > for the destination network it wants to DoS. > > The attacker could find the addresses of Proxy Tunnel Routers which > handle the attacker's EID. The attacker simply send packets from one > of its own EID addresses to random IP addresses to get responses from > a bunch of hosts, many of which will use a PTR (all those which don't > have an ITR in their own network). If there were a single set of > PTRs which handled every EID, then this would suffice to locate all > PTRs in the world. > > However, at least in the Ivip model, there probably won't be OITRDs > (the Ivip version of LISP's PTR) which handle every micronet. There > seems to be no business plan for LISP PTRs, so I can't say how they > would be organised. Assuming that there is one set of PTRs for one > subset of the EID address space, and another set for another subset, > then the above method will only allow the attacker to discover the > PTRs which handle its subset. > > I can't easily think of a way an off-path attacker could find the > addresses of the PTRs which handle the EID space of some network > which the attacker wants to DoS. Nonetheless, attackers in general > could figure out the addresses of PTRs in various PTR networks and > share this information between themselves. > > So an attacker could find the addresses of some, many or most ITRs > which might be tunneling packets to the site they want to DoS. > > The attacker presumably has a motivation to DoS a particular ETR. If > the attacker wants to DoS the ETR(s) of a particular organisation, it > can easily look up the mapping for that organisation's EID prefix to > obtain the ETR addresses. > > With the ETR address and a list of ITR addresses, the attacker can > inexpensively generate a sequence of spoofed PTB packets. (But see > discussion below on how much information the ITR needs to store about > recently sent packets, to force the attacker to correctly set length, > checksum and (IPv4 only) Identification bits to match a packet > actually sent, which the attacker, being off-path, can't see. > > Each such spoofed PTB, if recognised by the ITR, can be used to > clobber the MTU the ITR perceives for the targeted ETR, so causing > significant and reasonably persistent DoS for a potentially large > number of sending hosts which rely on that ITR - and a potentially > large number of destination hosts in potentially multiple destination > networks which rely on this ETR. > > If the ITR requires the LISP nonce to be in the PTB fragment, then > the system is secure against such spoofing, but then this PMTUD > system will only work if all the intermediate routers which might > cause an MTU problem send back at least 16 bytes rather than the RFC > 1191 minimum of 8 bytes after the IP header. > > > >> The ITR needs to store an initial fragment of each incoming traffic > >> packet for some time, so it can generate a PTB message for the > >> sending host. It can't rely on enough of the original > packet coming > >> back in the PTB from the intermediate router. The ITR > needs to cache > >> this for a second or two at least - while it waits for a possible > >> PTB. This is an onerous requirement in a high-volume ITR. > > > > No. This is not the case. > > Assume the following topology: > > > > H1-----------ITR1-----<DFZ>----------ETR2-----------H2 > > > > where host H1 send packets to host H2. If a first packets > triggers a > > ICMP PTB in the DFZ, this is sent back to ITR1, which sjust > stores the > > fact that to reach ETR2 a smaller MTU must be used. Nothing > is sent back > > to H1. > > But that involves data loss. The Ivip approach is intended to avoid > this. > > > H1 sends a second packet. On the ITR1 there will be a check > on the MTU > > triggering a second ICMP PTB to be sent back to H1. > > Ahh . . . OK, you can make it work this way if you accept data loss > on the first large packet, expecting the sending host to generate > another similarly large packet, which seems reasonable. > > I don't think this technique can be used with Ivip, but I will > consider it when I write the PMTUD I-D. > > I withdraw my critique of LISP's stateful approach to PMTUD requiring > storage of the initial part of longer packets for a few seconds. > However, I think the text of draft-farinacci-lisp and your own > OpenLISP I-D should be revised to make this process clearer. > > Still, if you are to check the nonce, you do need to store each nonce > of recently sent packets. > > To do a proper check of the PTB, you need to store some packet > details - to force the attacker to generate the correct > Identification (IPv4 only) and Length bits from the IP header. > > Likewise, if you store the UDP checksum of recently sent packets, > then you can force the attacker to get that right, which would be > generally impossible except by lots of attempts for data packets. It > would be easier to spoof the checksum and length of TCP SYN packets > or some other commonly used short packets. To protect against that, > your ITR would need to store the length of such (generally short) > packets and make sure the potentially spoofed PTB message's MTU limit > was not longer than the actual packet. This, combined with some > general limit on how low you would accept the MTU to be according to > any PTB, would probably make the system immune to this kind of attack. > > > Also, I think you need to either check the LISP nonce (and accept the > system will fail if the PTB original packet fragment doesn't contain > it) or not expect it and so recognise that the system is open to a > powerful DoS attack if you don't store a bunch of details of recent > packets, and use them to carefully check all PTBs. > > This PTB checking process itself could represent a DoS vulnerability > for a busy ITR. If it has a lot of details of packets recently sent > - potentially hundreds of thousands or millions, I guess, and you are > not requiring LISP nonces, then you still have to search through some > long and constantly changing lists of packet details such as length, > UDP checksum (IPv4 only) Identification etc. for every PTB received. > > This could easily get way out of hand - those cached lists of recent > packet details are expensive enough to add to and clean out, and I > guess they can't inexpensively be optimised for inexpensive searching > to see which one matches a PTB. > > PTB messages are pretty short (inexpensive for the attacker to send) > and could chew up a lot of ITR CPU power to process. Checking only a > fraction of these PTBs (in order to limit the CPU time spent chewing > through a flood of spoofed PTBs) would slow down the ITR's ability to > adapt properly to actual MTU problems. > > > > So, you need two big packets in order to make the feedback reach the > > original sender, but the ITR does not need to store packets. > > > > Hope this clearer now. > > Yes - thanks. > > - Robin > _______________________________________________ > rrg mailing list > [email protected] > http://www.irtf.org/mailman/listinfo/rrg > _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
