Subject: [RRG] Initial comments on the LISP proposal

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 20 Mar 2007 02:52:48 -0700

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
[email-masked]

--
to unsubscribe send a message to [email-masked] 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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 20 Mar 2007 11:05:13 +0100

>    to the ICMP reply so that off-path attacker risks can be mitigated?

maybe you want to check

http://www.rfc-editor.org/cgi-bin/iddoctype.pl?letsgo=draft-bagnulo- 
lisp-threat-00

regards, marcelo

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 20 Mar 2007 03:45:11 -0700

> Some initial comments on the LISP proposal:

Thanks for the comments.

>    ITR to the ETR do not seem to contain any information that could

The Reply goes from the ETR to the ITR.

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

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

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

>    recognize unencapsulated packets.

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

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

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

>    when the ITR is not careful about the size of the tunneled packets

Yep, a problem with any tunneling design.

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

Dino

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 20 Mar 2007 05:41:32 -0700

> -----Original Message-----
> From: Dino Farinacci [mailto:[email-masked]] 
> Sent: Tuesday, March 20, 2007 3:45 AM
> To: Templin, Fred L
> Cc: [email-masked]; rrg
> Subject: Re: [RRG] Initial comments on the LISP proposal
> 

Correct; I had a dyslexic moment.
 
> and not accepting unsolicited replies solves most of this.

I defer to the threat analysis document and the -01 draft.
 
> >    This means that it will send encapsulated packets 
> without having  
> > any

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

> technical contract between two ISPs.

No problem for configured tunnels, obviously.
 
> tunnel interfaces in the ITRs and ETRs but strongly 

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

> implementation experience first before choosing a number.

OK, I'll watch for it.

> That is the best direction to pursue.

I'll watch for that too.

> this goal as soon as possible (for both IPv4 and IPv6).

I'll agree with that.

> 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

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 20 Mar 2007 08:31:03 -0700

> believe you may be in for some backward-compatibility issues.

The legacy nodes don't are not LISP boxes and don't have to change.  
To them the packets between the ITR and ETR are just plain old IPv4  
or IPv6 packets.

> packets. The service will therefore be unreachable.

NAT breaks a lot of things. The ETR has to be upstream of the NAT or  
collocated in the NAT.

> Fixable with a suitable tunnel path MTU assurance mechanism.

Yes, you can do PMTU with encapsulated data packets from ITR to ETR.

Dino

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 20 Mar 2007 09:31:20 -0700

> Sent: Tuesday, March 20, 2007 8:31 AM
> To: Templin, Fred L
> Cc: [email-masked]; rrg

I'm concerned about legacy end systems; not legacy network middle boxes.
 
> NAT breaks a lot of things. The ETR has to be upstream of the NAT or  

The point is that LISP may interact in strange ways with the
legacy deployment. If a working serice is set up behind a NAT
today (with a hole punched through the NAT), then that same
service should still work tomorrow after LISP gets deployed.
 
> Yes, you can do PMTU with encapsulated data packets from ITR to ETR.

Need to be careful with this; the ITR can certainly receive an
ICMPv4 "fragmentation needed" from some middlebox within the
tunnel. But, it is only guaranteed to get back the first 8
octets of the encapsulated packet so translation for sending
an ICMP back to the original destination is infeasible. The
only safe way I know of for the tunnel to support an assured
MTU (while avoiding unecessary in-the-network fragmentation)
is for the ITR to be able to probe the path and get an
acknowledgement back from the ETR.

Fred