Hi Fred, Thanks for these references, and some other PMTUD discussion in the "Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP" thread, which I will respond to here:
>> I stand corrected about LISP's approach to PMTUD - the latest >> draft does include an outline of a workable solution. > > I don't know if you were fishing for a response, No. I meant it was at least going to work, if the PTBs contained the nonce. It may not work very well, but that is better than the stateless approach, which won't work at all. > but the > stateful solution outlined in the latest LISP draft still > has problems. It should also be mentioned that the approach > (drop first; return PTBs for subsequent) is not new and > has been proposed many times over the years. I hadn't heard of this approach before. I still think it has problems. > The approach in the current LISP draft still relies on ICMPs > coming from anonymous network middleboxes (which Dino himself > has said that we cannot depend on), Dino clarified this to say that he thinks we can rely on PTBs being sent - and generally rely on them being received: http://www.irtf.org/pipermail/rrg/2009-January/000899.html But ICMP TooBig and Time-Exceeded message are sent and are more dependable. That is, they can get lost when they are transmitted since they are single transmitted datagrams. But at least they are sent. I assume this is true - it makes sense. Anyone configuring a DFZ router or an internal router between any ITR and ETR would be badly mistaken not to allow generation of any PTBs. > and provides insufficient > means for authenticating any ICMPs that may come. For example, > even if the ICMPs were delivered, and even if they included > the LISP nonce, it would be impractical for the ITR to cache > enough nonces of enough recently-sent packets especially at > high data rates. I tend to agree, but it depends on how smart the ITR is about recognising "longer packets" and only caching details for that subset. There's no need for the ITR to cache a LISP nonce for the purposes of PMTUD if the packet is shorter than some constant below which it can be assumed there are no MTU problems. So VoIP packets and quite a few others will not need to have any nonce or other details cached. I wonder if there is a cryptographic approach to generating 32 bit nonces such that it is not necessary to cache each one in order to be able to verify that a nonce in a PTB matched a recently sent packet? For instance, for a period of a second or two, set a randomly selected set of 16 bits in the 32 bit nonce to some particular bit pattern, which is pseudo-random, which remains the same for the period and is cached. Then, change the other 16 bits for each generated nonce. Hmmm - this just makes it easier for an attacker to spoof a nonce. Maybe send the same nonce for all packets for 0.1 seconds . . . No - if an attacker can get a tunneled packet from this ITR to its own ETR then it use the nonce to spoof a PTB apparently from a tunnel to another ETR. Maybe there is some snappy crypto approach to this, but it needs to be lightweight when checking the nonce in a PTB - and knowledge of another recent nonce must not allow an attacker to improve their chances of spoofing a valid nonce of another packet tunneled to some other ETR. My plan in: http://www.firstpr.com.au/ip/ivip/pmtud-frag/ is that a very small subset of packets get the special PMTUD treatment. Every such packet will result in a reduction of the zone of uncertainty about the path MTU to the ETR. Data will either be delivered or the ETR and therefore the destination network or the ITR will send a valid PTB to the sending host. Pretty quickly, ordinary RFC 1191 sending host behaviour will result in the zone of uncertainty being reduced to zero. Then, except for occasional attempts to try longer packets than the current estimate allows, or to confirm that packets are getting through when they are close to, or at, the current MTU limit, there is no special treatment of packets and so nothing to cache. (In Ivip, ordinarily tunneled packets hitting an MTU limit will not generate a PTB to the ITR - the PTB will go to the sending host and not be recognised there.) > So, the only option is to ignore ICMPs (leads to black holes) > or honor ICMPs (leads to denial of large packet service). If the ITR doesn't attempt to recognise PTBs, then it needs some other way of determining PMTU to the ETR - which involves special protocols between the ITR and ETR. This is part of what I am proposing. My approach does recognise PTBs if they are sent with enough of the offending packet to contain the nonce in the "Packet B", which is the same length as the original traffic packet would become with ordinary Ivip encapsulation. This requires the intermediate router send back at least 8 bytes more than the bare minimum 8 bytes required by RFC 1911. I think it is reasonable to expect DFZ and internal routers to do this. I recall someone writing that many do it already. It would be a straightforward config change or firmware update to make sure they all did it in time for the introduction of Ivip or any similar system. So secure recognition of PTBs is used by my system, but the system will still work without PTBs. > I have said this before, but AFAICT DF=1 is busted. I don't understand why. My approach should support any RFC 1191 sending host creating DF=1 packets as long as it likes, including as more and more paths between ITRs and ETRs change from ~1500 to ~9000 or whatever in the future. It is the DF=0 packets I think are a problem. I intend to handle them up to a certain length - something a little below 1500 bytes. Longer than that and the ITR will drop them. I think it is unreasonable for a sending host to expect the network to fragment its excessively long packets ca. 2015 or whenever Ivip or the like is deployed. RFC 1191 is a perfectly good approach and has been available since 1990. - Robin _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
