Hi Robin, See few comments inline
Robin Whittle wrote: > Short version: Stateless approach is a really bad idea in the future > when ~9000 byte MTU ITR to ETR paths become common. > > Stateful approach somewhat resembles Ivip's approach > - which is documented in greater detail and limits > the number of traffic packets for which state must > be stored in case a PTB is received. > > Here my thoughts on the two techniques (Stateless and Stateful) for > LISP Path MTU Discovery management in the latest (19 December) draft. > > My understanding of the whole problem (for Ivip's map-encap modes or > for any other map-encap scheme, such as LISP or APT), together with > my solution for Ivip, is here: > > http://www.firstpr.com.au/ip/ivip/pmtud-frag/ > > > Here is my critique of the Stateless approach, assuming L = 1500, as > is recommended at the end of: > > http://tools.ietf.org/html/draft-farinacci-lisp-11#section-5.4.1 > > The stateless approach was rejected by the OpenLISP team: > 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. What we proposed is just an alternative approach that takes advantage of ICMP messages (if they are present). > http://tools.ietf.org/html/draft-iannone-openlisp-implementation-01#section-6.8.1 > > > [snip] > 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. > 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? Our goal was not to introduce new mechanisms in the core, but rather to take advantage of what exists. > 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? > 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 sen a fake ICMP message to shrink the MTU toward that specific ETR? > 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. 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. So, you need to 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. Cheers Luigi _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
