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

Re: [RRG] Initial comments on the LISP proposal

Some initial comments on the LISP proposal:


Thanks for the comments.


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


The Reply goes from the ETR to the ITR.


   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?
Security is going to be addressed in the -01 draft. By using nonces and not accepting unsolicited replies solves most of this.
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
This depends on how you do the mapping. If the mapping is pushed and the ETR registers Locators, then you do know. When you don't know, the host sends packet a ICMP protocol unreachable message.
For TE tunnels, you do know because most likely shared-keys will be used so there will be a bilateral setup of the tunnel. That means, a technical contract between two ISPs. 


   the path. Some systems may refuse to accept encapsulated packets if
   they do not have at least a tunnel interface configured a priori,
This depends on the implementation. I plan to not support it this way. LISP does not require the implementation to configure static tunnel interfaces in the ITRs and ETRs but strongly recommends it for TE-ITRs and TE-ETRs. 


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.


Same issue when you don't inject your site based route into BGP.


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.
I will fix that, but intentionally left it out so I can get some implementation experience first before choosing a number. 


   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.
We will be using routable-IDs globally only for the first phase. We plan to have a LISP 3.0 solution soon so we never have routable IDs. That is the best direction to pursue.
The ultimate goal should be to address all sites with PI blocks and not have those blocks injected into BGP. We really need to get to this goal as soon as possible (for both IPv4 and IPv6). 


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.


Yep, a problem with any tunneling design.

Thanks again. I will get numbers in the spec in about a month or so.

Dino

--
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