Subject: [tcpm] Fwd: [Int-area] draft-williams-overlaypath-ip-tcp-rfc

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 21 Dec 2012 08:51:29 +0000

Since a TCP option is being designed, of interest to TCPM.

Lars

Begin forwarded message:

> From: Brandon Williams <[email-masked]>
> Subject: [Int-area] draft-williams-overlaypath-ip-tcp-rfc
> Date: December 20, 2012 18:20:01 GMT+01:00
> To: "[email-masked]" <[email-masked]>
> 
> Dear all,
> 
> A new version of this draft has been submitted that attempts to lay out a more clear argument for the use of both TCP and IP options, with references to other efforts in the same arena.
> 
> Comments are welcome.
> 
> Cheers,
> --Brandon
> 
> 
> -------- Original Message --------
> Subject: New Version Notification for draft-williams-overlaypath-ip-tcp-rfc-03.txt
> Date: Thu, 20 Dec 2012 11:55:33 -0500
> From: [email-masked] <[email-masked]>
> To: Williams, Brandon <[email-masked]>
> 
> 
> A new version of I-D, draft-williams-overlaypath-ip-tcp-rfc-03.txt
> has been successfully submitted by Brandon Williams and posted to the
> IETF repository.
> 
> Filename:	 draft-williams-overlaypath-ip-tcp-rfc
> Revision:	 03
> Title:		 Overlay Path Option for IP and TCP
> Creation date:	 2012-12-20
> WG ID:		 Individual Submission
> Number of pages: 15
> URL: http://www.ietf.org/internet-drafts/draft-williams-overlaypath-ip-tcp-rfc-03.txt
> Status: http://datatracker.ietf.org/doc/draft-williams-overlaypath-ip-tcp-rfc
> Htmlized: http://tools.ietf.org/html/draft-williams-overlaypath-ip-tcp-rfc-03
> Diff: http://www.ietf.org/rfcdiff?url2=draft-williams-overlaypath-ip-tcp-rfc-03
> 
> Abstract:
>   Data transport through overlay networks often uses either connection
>   termination or network address translation (NAT) in such a way that
>   the public IP addresses of the true endpoint machines involved in the
>   data transport are invisible to each other.  This document describes
>   IPv4, IPv6, and TCP options for communicating this information from
>   the overlay network to the endpoint machines.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Costin Raiciu <[email-masked]>
Date: Fri, 21 Dec 2012 11:05:37 +0200

I have been thinking about this same problem for a project we're doing. The project wants to give end-systems the ability to instantiate flow processing (e.g. layer 4 and up) in the network - and so it needs a way to get packets onto these boxes.

We found that one option is to use loose source routing (LSRR). The intermediary hop just injects loose source route options that record all the relevant IPs this packet will go through; the packet's source address does not need to change. LSRR makes sure that the return packet travels the same way, 
thus enabling TCP connectivity.

Brief wide-area tests showed that LSRR options do not get through the Internet (spoofing concerns lead to it being blocked a long time ago)  - so some sort of tunnel may be required to "hide" them from routers, (e.g. a UDP tunnel, IPsec). If the tunnel is MACed or encrypted then LSRR options are protected so on-path boxes can't modify them - thus alleviating the security issues relating to LSRR.

I admit that the need to tunnel isn't exactly clean either, but at least it supports all protocols and not just TCP.

If we want to target "just" TCP we may be able to do something more general than the current proposal - more about this when we have something fleshed out.

Best,
Costin

On 21 Dec 2012, at 10:51, Eggert, Lars wrote:

> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Brandon Williams <[email-masked]>
Date: Fri, 21 Dec 2012 11:32:51 -0500

Hi Costin,

Thanks for your comments.

The option described here is not intended to be the mechanism by which 
the overlay functions. Instead, it is intended to mitigate server-side 
issues associated with the use of NAT. This proposal is meant to meet 
some of the same requirements as other similar host identification 
drafts, as well as some other requirements that are specific to the 
overlay use case.

Is there something specific in the text of draft that appears to 
indicate that the option would be used to implement the overlay? Or is 
it perhaps simply that name that was chosen for the option?

Cheers,
--Brandon

-- 
Brandon Williams; Principal Software Engineer
Cloud Engineering; Akamai Technologies Inc.

-- 
Brandon Williams; Principal Software Engineer
Cloud Engineering; Akamai Technologies Inc.