[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[RRG] Initial comments on the LISP proposal



Dino/Vince/Dave,

Some initial comments on the LISP proposal:

1) The ICMP reply that is triggered by the first packet(s) from the
   ITR to the ETR do not seem to contain any information that could
   help the ITR know that the reply is in fact coming from a
   legitimate on-path ETR. Perhaps add a message digest (MD5 or other)
   to the ICMP reply so that off-path attacker risks can be mitigated?

2) The mechanism is really an open-ended automatic tunneling mechanism.
   This means that it will send encapsulated packets without having any
   way of knowing whether a suitably-configured decapsulator exists on
   the path. Some systems may refuse to accept encapsulated packets if
   they do not have at least a tunnel interface configured a priori,
   and some systems may not configure a tunnel interface by default. I
   *think* we found this to be the case on Linux FC5 (system wouldn't
   accept the packets w/o a tunnel interface configured) but I need
   to go back and verify.

3) Sending encapsulated packets when there is no way of knowing
   whether there is a suitably-configured decapsulator on the path
   could fail to reach some services, e.g., services that reside
   behind NAT boxes and have "holes" punched in the NAT that only
   recognize unencapsulated packets.

4) The spec doesn't say for how long the ITR will continue to send
   encapsulated packets when it gets no replies back from an ETR.
   Will it continue to send the encapsulated packets for the entire
   duration of the flow? If so, this may not work in some cases (see
   above) and will add unnecessary encapsulation overhead in other
   cases. Either way, it seems that legacy systems may suffer before
   the scheme becomes widely deployed.

5) There is also the issue of unnessary IP fragmentation on the path
   when the ITR is not careful about the size of the tunneled packets
   it sends.

Fred
fred.l.templin@boeing.com

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg