Subject: [lisp] We need LISP over HTTP!

From: Damien Saucez <[email-masked]>
Date: Wed, 30 Sep 2015 15:48:10 +0200

Dear all,

Today again I was in the situation where I was not able to run my LISP setup in the place I visited.
All was supposed to work well using the NAT traversal. But reality was different: UDP traffic was
filtered in the place.

So my question to the working group: who would be ready to start working on a technique to cary
LISP over TCP and, even more horrible, over HTTP?

Thanks,

Damien Saucez

---

From: Richard Li <[email-masked]>
Date: Wed, 30 Sep 2015 16:54:21 +0000

It might solve your NAT problem, but I am afraid it is not a good idea to have something like LISP carried by TCP since you have to hold up the connection and transporting states between xTRs for each flow or each packet, which will bring you a huge scale problem. You could do experiments with it, but it is unlikely to get accepted in production networks.

Can you re-try it by re-configuring your NAT?

Renwei

-----Original Message-----
From: lisp [mailto:[email-masked]] On Behalf Of Damien Saucez
Sent: Wednesday, September 30, 2015 6:48 AM
To: LISP mailing list list
Subject: [lisp] We need LISP over HTTP!

Dear all,

Today again I was in the situation where I was not able to run my LISP setup in the place I visited.
All was supposed to work well using the NAT traversal. But reality was different: UDP traffic was filtered in the place.

So my question to the working group: who would be ready to start working on a technique to cary LISP over TCP and, even more horrible, over HTTP?

Thanks,

Damien Saucez
_______________________________________________
lisp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lisp

---

From: Damien Saucez <[email-masked]>
Date: Wed, 30 Sep 2015 19:02:40 +0200

> It might solve your NAT problem, but I am afraid it is not a good idea to have something like LISP carried by TCP since you have to hold up the connection and transporting states between xTRs for e…

I agree, the point is just to have an escape mode in case of filtering. I was more thinking of an evolution of NAT-traversal so just between the node and the RTR, and only if it is strictly necessary. Obviously, it is not necessary to integrate it in LISP and we can fix it making VPNs but then you have a VPN to escape and the RTR so you jump from your place to the VPN endpoint then only RTR, which is not very efficient.

> Can you re-try it by re-configuring your NAT?

No. In practice you don’t control the CGN or the ACLs of the network you roam in when you are in LISP-MN.

Damien Saucez

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 30 Sep 2015 10:18:04 -0700

How about doing it via the DNS port on UDP?

Dino

> On Sep 30, 2015, at 10:02 AM, Damien Saucez <[email-masked]> wrote:
> 
>

---

From: Damien Saucez <[email-masked]>
Date: Wed, 30 Sep 2015 19:31:07 +0200

> How about doing it via the DNS port on UDP?

That’s one solution but for example at my office location, they filter DNS traffic (we must use our DNS).

Just using another port is not a big deal if we use LCAF to have ip:port instead of just ip :)

And even if we are over the same port if the traffic is not UDP it might be filtered. With HTTPs it is fine, the payload of the HTTP is the packet and the LISP header is HTTP header :) or just put the packets as-is in the payload.

Damien Saucez

---

From: Sam Hartman <[email-masked]>
Date: Wed, 30 Sep 2015 13:47:52 -0400

>>>>> "Dino" == Dino Farinacci <[email-masked]> writes:

    Dino> How about doing it via the DNS port on UDP?  Dino

Sadly, there's a lot of stuff that will break DNS especially to things
not the default DNS server you get from DHCP.
There is  an implementation of IP tunneled over DNS--not just the port,
but actually in a DNS protocol that will work even if there are
recursive resolvers in the way.
It's performance is not ideal:-)

I've certainly seen a lot of protocols look at the HTTP encapsulation
route.  These days you could potentially use web sockets.

---

From: Michael Menth <[email-masked]>
Date: Wed, 30 Sep 2015 20:15:29 +0200

Hi Renwei, hi Damien,

when using NAT traversal there is state anyway between the NAT traversal
router and the mobile node. What about just using HTTP instead of LISP
in the outer header between the mobile node and the NAT traversal router
for tunneling purposes? I don't see this causes more state than normal
NAT traversal.

If the NAT traversal functionality itself is not needed, one might still
use it to use an http tunnel to just one other node in the Internet
instead to many others which avoids the general state problem.

Regards,

Michael

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:[email-masked]
http://kn.inf.uni-tuebingen.de