RE: [RRG] Initial comments on the LISP proposal

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

> -----Original Message-----
> From: Dino Farinacci [mailto:dino@cisco.com] 
> Sent: Tuesday, March 20, 2007 3:45 AM
> To: Templin, Fred L
> Cc: ram@iab.org; rrg
> Subject: 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.

Correct; I had a dyslexic moment.
 
> >    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.

I defer to the threat analysis document and the -01 draft.
 
> > 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.

But if you don't get the ICMPs, it appears as a black hole.

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

No problem for configured tunnels, obviously.
 
> >    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.

I'm not concerned about the LISP-enlightened nodes; I'm concerned
for the legacy nodes that don't yet implement the scheme and I
believe you may be in for some backward-compatibility issues.
 
> > 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.

I don't understand your response; I was saying that the encapsulated
packets are delivered to the NAT box in front of the server, but the
NAT has a hole punched through it that only recognizes unencapsulated
packets. The service will therefore be unreachable.

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

OK, I'll watch for it.

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

I'll watch for that too.

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

I'll agree with that.

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

Fixable with a suitable tunnel path MTU assurance mechanism.
 
> Thanks again. I will get numbers in the spec in about a month or so.

OK - Fred
fred.l.templin@boeing.com

> 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