Network Working Group P. Francis Internet-Draft S. Guha Intended status: Standards Track Cornell U. Expires: October 22, 2007 S. Brim M. Shore Cisco April 20, 2007 An EME Signaling Protocol Design draft-irtf-eme-francis-nutss-design-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 22, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Francis, et al. Expires October 22, 2007 [Page 1] Internet-Draft An EME Signaling Protocol Design April 2007 Abstract This document presents a high-level design for an End-Middle-End (EME) signaling protocol called NUTSS (which stands for NAT, URI, Tunnel, Signaling, STUN). While high-level, this document tries to be detailed enough that the EME RG can have a meaningful debate about its pros and cons and possible alternatives. The main attribute of NUTSS is that it couples together both path-coupled and path- decoupled signaling. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Relationship with existing signaling protocols . . . . . . 3 2. Dual Signaling Overview . . . . . . . . . . . . . . . . . . . 4 2.1. Terms and Components . . . . . . . . . . . . . . . . . . . 4 2.2. Name-routing between P-boxes . . . . . . . . . . . . . . . 5 2.3. Relationship between P-boxes and associated M-boxes . . . 6 2.4. High-level approach to dual signaling . . . . . . . . . . 7 3. Signaling Details . . . . . . . . . . . . . . . . . . . . . . 9 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Case A . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.1. Comments . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Case B . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2.1. Case B, Version a . . . . . . . . . . . . . . . . . . 16 4.2.2. Case B, Version b . . . . . . . . . . . . . . . . . . 18 4.2.3. Case B, Version c . . . . . . . . . . . . . . . . . . 19 4.2.4. Case B, Version d . . . . . . . . . . . . . . . . . . 20 4.2.5. Case B, Version e . . . . . . . . . . . . . . . . . . 23 5. Case C . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.1. Comments . . . . . . . . . . . . . . . . . . . . . . . . . 26 6. Case D . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.1. Case D, Version a . . . . . . . . . . . . . . . . . . . . 27 6.2. Case D, Version b . . . . . . . . . . . . . . . . . . . . 31 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 8. Normative References . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Intellectual Property and Copyright Statements . . . . . . . . . . 37 Francis, et al. Expires October 22, 2007 [Page 2] Internet-Draft An EME Signaling Protocol Design April 2007 1. Introduction This document presents a high-level design for an End-Middle-End (EME) signaling protocol that satisfies the requirements in [I-D.guha-emerg-requirements]. This document tries to be detailed enough that the EME RG can have a meaningful debate about its pros and cons and possible alternatives. Clearly, however, much detail is missing and still needs to be filled in. The intent is that this detail can be created once the EME RG builds consensus on a high- level approach. The core idea behind NUTSS is that it exploits both path-decoupled and path-coupled signaling, coordinating them in such a way that the limitations of either individual approach are overcome. Specifically, path-decoupled signaling is able to provide authorization tokens that are then handed to middleboxes through path-coupled signaling. Middleboxes, in turn, are able to refer endpoints to path-decoupled signaling devices so that they may obtain the appropriate tokens. Despite our best efforts to the contrary, this version (0) is likely to have numerous errors, especially in the examples. We appreciate comments on these so that we can put out a cleaner version soon. 1.1. Relationship with existing signaling protocols Obviously there is tons of existing work that relates to this, especially SIP, NSIS, and RSVP. This section needs to be filled in, but for now we'll let it suffice to say that the dual-signaling approach described in this paper could heavily borrow specific mechanisms from these "uni-signaling" approaches. This is for further study. Francis, et al. Expires October 22, 2007 [Page 3] Internet-Draft An EME Signaling Protocol Design April 2007 2. Dual Signaling Overview 2.1. Terms and Components This paper uses the terms "name-routed" and "address-routed" to refer to the two forms of signaling used by NUTSS. We define name-routed signaling as signaling that uses a name (URI) to route the signaling message. We define address-routed signaling as signaling that uses the IP address(es) that are ultimately used by data packets to route the signaling. Address-routed signaling can be out-of-band (i.e. message-based), or in-band (embedded in the data flow itself). Name-routed signaling is needed, at a minimum, to obtain one or more IP addresses that can be used to reach the destination host (or middleboxes along the way). There are other uses for name-routed signaling as well. Name-routed signaling allows protocols to be negotiated (network layer, transport layer, security), and allows flexible deployment of where policy decisions are made (i.e. replication of policy boxes). Clearly name-routed signaling is valuable, and SIP is a testament to this. Address-routed signaling is needed because ultimately it is boxes on the data path (i.e. firewalls) that enforce policy. Given that we require both name- and address-routed signaling (aka "dual signaling"), there must be some way to coordinate the two. Before describing this, we first define the components of NUTSS. There are two components in NUTSS, policy boxes (p-box), and middleboxes (m-box). P-boxes handle name-routed signaling messages. That is, a name-routed message travels between end-hosts from p-box to p-box. The end-point name (a URI) to which the signaling message is being delivered is used to determine what the next p-box on the path should be. P-boxes tend to make "policy" decisions, such as whether a flow is allowed, what data protocols will be used for the flow, and so on. M-boxes handle address-routed signaling messages as well as data packets (which, by definition are address-routed). Sometimes m-boxes receive address-routed messages that are not addressed to them, for instance a packet that is addressed to an end-point that traverses an m-box. We call these non-addressed m-boxes. Other times packets are addressed to the m-box itself, as with a packet being delivered to a NAT box, or with packets being steered to an m-box. Indeed, a key feature of NUTSS is that it allows p-boxes to insert addressed m-boxes into a data path. Note that we model end-hosts as having an internal p-box and m-box Francis, et al. Expires October 22, 2007 [Page 4] Internet-Draft An EME Signaling Protocol Design April 2007 that can initiate and receive signaling messages as well as filter packets. Any network (or host) that has policies (i.e. reasons to allow, disallow, or modify a flow), and that is in the datapath of a flow, must have one or more p-boxes and one or more m-boxes. Note that p-box functionality may be deployed in a box that is in the data- path, and may also be deployed in the end-hosts themselves. These p-boxes and m-boxes work in concert with each other as follows: 2.2. Name-routing between P-boxes Any given p-box may have one or more "parent" p-boxes. This would almost always be the case for the p-box embedded in the end-host. For non-end-host p-boxes, a typical reason for this would be because the p-box is behind a firewall controlled by another organization. When a message is routed from a p-box to one of its parents, we say the message is being routed "up". Likewise when a message is being routed from parent to child, it is being routed "down". When a p-box routes a message to another p-box that is neither its parent or child, we say it is being routed "across". (Note that when we say "parent", we mean immediate parent, not an ancestor (parent's parent, etc.) A p-box will typically discover its parent(s) through configuration: DHCP if the p-box is in an end-host, manually otherwise. Auto- discovery of p-boxes is also possible, as mentioned in Section 2.3. P-boxes must be able to directly exchange packets with their parent and children p-boxes, but not with non-parent ancestors or non-child descendents. When an end-host registers with its p-box, the registration is passed up, parent-to-parent, to all ancestor p-boxes. This way, p-boxes know which child to route messages to. When a p-box has a message to route, it forwards the message down if it has received a matching registration for the destination endpoint name (URI) from a child p-box. Otherwise, if it has one or more parents, it forwards the message up to one or more of them. Otherwise, if it has no parent, it does a DNS lookup to learn the IP address of the p-box associated with the DNS name in the destination URI, and forwards the message there. (This is obviously very much like how SIP messages are routed.) Besides this, p-boxes must know how to route, via zero or more intermediate p-boxes, to all ancestor p-boxes. This is because m-boxes can refer endhosts to ancestor p-boxes (Section 2.3). Since p-boxes (including those in the endhost) may have multiple parents, they need to know which of multiple parents to use to reach a given Francis, et al. Expires October 22, 2007 [Page 5] Internet-Draft An EME Signaling Protocol Design April 2007 ancestor p-box. This can be done by having p-boxes advertise all known ancestor p-boxes to their children. From the above description, it should be apparent that a name-routed message may take multiple up or down hops, but won't take more than one across hop. While strictly speaking we don't disallow more than one across hop, neither do we provide a mechanism for letting p-boxes know how to navigate more than one across hop. Future work, however, may uncover a reason for doing so. 2.3. Relationship between P-boxes and associated M-boxes When a p-box approves a flow (perhaps after participating in the negotiation of flow parameters), it provides security tokens that its corresponding m-box(es) use to allow the flow in both directions. The tokens might be cryptographic based on shared information between p-box and m-box (a self-authorizing token), or contain a simple directive for the m-box to contact the p-box to approve the flow (a contact token). The tokens are conveyed by name-routed signaling to the end-hosts, which then insert them address-routed. If an m-box receives a packet for an unauthorized flow, it can refer the end-host to the m-box'es associated p-box, thus allowing the end- host to obtain a token. It does this by giving both the name and IP address of the p-box. If the referred p-box is a parent, the end- host can do name-routed signaling directly with the parent. If the referred p-box is a non-parent ancestor, then the end-host can indicate that the signaling message must reach that p-box, and route the message accordingly. It is this combination of tokens (in the p-box to m-box direction) and referrals (in the m-box to p-box direction) that couples the two signaling paths together. This approach solves many if not all of the problems that result from the fact that name-routed signaling cannot always know what the path of a subsequent data flow will be. For instance, if a p-box PA authorizes a flow through m-box MA, and the flow actually goes through m-box MB, then MB can refer the end- host to its associated p-box PB, which can then provide the right token. Referrals can also be used for auto-discovery of p-boxes by end- hosts: the end-host can discover the p-box by trying to transmit a packet to a global address. The m-box receiving the packet can reject the flow and refer the end-host to the p-box. Indeed this same trick can be used to allow a p-box to discover another p-box. (Note however that more generally a configuration tool like DHCP will be used to tell end-hosts of their associated p-boxes.) Francis, et al. Expires October 22, 2007 [Page 6] Internet-Draft An EME Signaling Protocol Design April 2007 In cases where a p-box and associated m-box are not co-resident in the same device, the coupling between p-boxes and their associated m-boxes requires certain configuration at p-boxes and m-boxes, as follows: 1. The m-box and p-box must almost certainly share cryptographic keying information. This is needed for instance if self- authorizing tokens are used, and is desired even if contact tokens are used. 2. The m-box needs to know the name and IP address of the p-box. This is in order to be able to refer end-hosts with unauthorized flows to the appropriate p-box. But it is also needed to prevent end-hosts from spoofing contact tokens (i.e. inserting a bogus p-box address in the token). 3. If the p-box is positioned "outside" of the network protected by the m-box, then the m-box must have firewalls rules that allow hosts within the network to communicate with the p-box. 4. If the m-box is a NAT box, then the p-box must know the public address(es) of the NAT box. Even if the m-box is not a NAT, the p-box may need to know the public-side address of the m-box in order to steer incoming flows to the m-box. 5. If the p-box wants to steer outgoing flows to a given m-box (or for that matter any m-box), then the p-box needs to know the IP address of the appropriate interface (i.e. the private-side interface if the m-box both private and public interfaces). 2.4. High-level approach to dual signaling As a general rule, certain information can be established with name- routed signaling, and certain other information requires address- routed signaling. Furthermore, in some complex situations, address- routed and name-routed signaling may have to be interspersed. For instance, in cases where the name-routed signaling path doesn't match the address-routed path chosen by routing, additional name-routed signaling may be required. To the extent possible, signaling operates such that endpoints can tell what information is still missing, and so can trigger whatever kind of signaling is needed to establish that information. The broad approach to dual signaling is that the endpoints try, through a series of signaling messages that travel from endpoint to endpoint via p-boxes or m-boxes, to establish all the information needed to start the data flow. The same signaling message format is used for both name-routed and address-routed. The only difference is Francis, et al. Expires October 22, 2007 [Page 7] Internet-Draft An EME Signaling Protocol Design April 2007 that name-routed messages are routed by name (of the destination endpoint), and address-routed messages are routed by IP address (of the destination endpoint and middleboxes). Typically, signaling will start name-routed (because the endpoints don't have an IP address to use), and then simply continue address-routed at the point in time where name-routed left off. Indeed, where p-boxes and m-boxes are co-resident, there is no distinction between name-routed and address- routed. Broadly speaking, name-routed signaling is required when the end- points don't have an IP address to address-route signal with. Address-routed signaling commences when name-routed signaling provides the IP addresses needed for address-routed signaling, and indicates that no more information can be obtained through additional name-routed signaling. Address-routed signaling continues, possibly through multiple parallel m-boxes, until enough information has been established (for instance NAT state in m-boxes) to start data flows. If name-routed signaling provides all the information needed for the data flow, then address-routed signaling is unnecessary. Information gathered during signaling is cacheable. As a result, often endpoints will be able to establish a new flow using only address-routed signaling, or with no additional signaling at all. Finally, note that flow authorization using tokens at m-boxes may be in-band as well as out-of-band. Francis, et al. Expires October 22, 2007 [Page 8] Internet-Draft An EME Signaling Protocol Design April 2007 3. Signaling Details In general, name-routed signaling does the following: 1. Authorizes flows (named endpoints and application). 2. Authenticates endpoints (needed for authorization). 3. Negotiates the protocol stack for the flow. 4. Establishes (some of the) parameters needed for the data flow (addresses and ports). At a minimum, the addresses needed to send address-routed signaling messages is required. 5. Conveys tokens needed by m-boxes to authorize the data path. 6. Conveys application data where appropriate. Address-routed signaling does the following: 1. Presents tokens to m-boxes. 2. Refines the protocol stack negotiations. 3. Establishes any additional parameters needed for the flow. 4. Conveys additional application data where appropriate. Towards this end, signaling messages (both name- and address-routed) have two components, a "device", and "data". A device can represent either an end host or an m-box. Signaling messages must start with at least two devices, one for each end-host. Typically a signaling exchange will start with a message that contains the end-host devices, and additional devices are added by p-boxes. As the message progresses through p-boxes, additional devices are added as needed, for instance to represent NAT boxes, firewalls, or other middleboxes. As a general rule, information may only be added to a signaling message as it traverses p-boxes and m-boxes. For instance, an m-box device with its protocol stack and IP address may initially be created by a p-box (and signed by that p-box). Later, the m-box itself may decide to change the IP address and add a port number. Mechanistically, the additional information would be added in the form of a new device component, signed by the m-box. Both the old and new IP addresses would still be there, but it would be understood that the new IP address over-rides the old one. Francis, et al. Expires October 22, 2007 [Page 9] Internet-Draft An EME Signaling Protocol Design April 2007 If it is necessary to literally remove information (not override), this is done through a "backtrack", whereby the message is reverse routed to the box that added the offending information, which can then replace it based on the information passed back to it. For instance, an endhost p-box may include its IP address in the original signaling message, but a p-box may later wish not to include it until the remote end has been authenticated and authorized. The only way to do that is to backtrack the message to the endhost with an indication to remove the IP address. (Later, after the flow is approved, the IP address can be added back in.) After a signaling message passes once through the complete set of p-boxes from initiating endpoint to receiving endpoint, there should be a device component in the message for every m-box that is expected to be in the data path. A device component may contain the following information: 1. Names (including endpoint and application) 2. Data Stacks (and associated parameters) 3. Authorizing Tokens (or Token for short) 4. Authenticator (Cert or Challenge/Response) The Name (a URI) is mandatory for end-host devices, and describes both the endpoint and the application. The endpoint may be the machine, a user, a process, and so on. M-box devices may or may not have endpoint names or application names associated with them, but typically won't (an IP address will suffice). A name can be "anonymous". A Data Stack is literally a list of the stack(s) of protocols that can run on the device, and parameters associated with each of the protocols in the stack (i.e. IP address or port). When listed for an endpoint, it contains the protocols from the lowest network layer to just below the application. Stating the available stacks allows for negotiation of protocol, including security protocols, and makes it easier to introduce new protocols into the Internet. (For instance, two endpoints can negotiate the use of IPv6 or SCTP as soon as they, and any m-boxes that care, have it.) The data stack also serves to supply the protocol parameters needed for a data flow. A data stack for an m-box specifies what protocols are terminated or modified at the m-box. For instance, a NAT box might be described as terminating IP (because it changes the addresses), but only modifying TCP (because it does not send ACKs). The data stack would also Francis, et al. Expires October 22, 2007 [Page 10] Internet-Draft An EME Signaling Protocol Design April 2007 indicate the parameters needed at the NAT box for the flow (i.e. IP address, TCP port). Note that in this case, it might be a p-box that supplies the NAT boxes address (during name-routed signaling), but the m-box itself that later supplies the port (during address-routed signaling). An HTTP proxy, on the other hand, would be described as terminating HTTP (and by extension, everything below HTTP). M-box data stacks, then, serve to inform endpoints as to what is going on in the network, as well as conveys data parameters needed to traverse middleboxes. Tokens carry flow authorizations. When supplied by a p-box, they indicate that a flow is approved to traverse one or more m-boxes. When supplied by an m-box, they indicate that the flow is enabled at the m-box (pending establishment of flow parameters like NAT port mappings). Note that a device component with only a token (no name or data stack) suggests that there is an m-box that requires the token for traversal, but does not modify any data protocols. An authenticator may contain either a certificate or a challenge/ response. (This is not further discussed.) Data is information that normally would be carried in the initial part of the data flow, but is piggybacked onto signaling messages for better performance. For instance, for HTTP, the initial signaling message might carry the headers in the TCP SYN and the HTTP GET that would normally be carried in the first and third packets of the data flow. The responding signaling message might carry the headers the the resulting TCP SYN/ACK and the first part of the HTTP reply. After the first two signaling messages, the now established TCP connection could simply pick up where it left off. In contrast to the device components, which are required for NUTSS to work, the data component is an optimization meant to reduce the number of round trips needed to establish a flow. We need to carefully consider the pros and cons of this optimization before deciding whether we want it or not. As a signaling message flows through the p-boxes and m-boxes that process it, each box can do the following: 1. Add a device component. 2. Append an existing device component with additional elements. 3. Negate or over-ride an element from an already existing component (by adding an element that negates the previous element). 4. Backtrack a message in order to remove an element from an already existing component. Francis, et al. Expires October 22, 2007 [Page 11] Internet-Draft An EME Signaling Protocol Design April 2007 5. Redirect the previous hop in the signaling path to a different p-box or m-box. In other words, it tells the previous hop to send the same signaling message to another p-box or m-box. 6. Replicate a message (to explore multiple parallel paths through the network, as with multi-homed sites). (The issue of whether to replicate messages to multiple identically named endpoints, as with SIP forking, needs to be studied.) 7. Explicitly reject a signaling message. 8. Silently drop a signaling message. In addition to the above, an m-box, upon receiving a disallowed data flow, can refer the endpoint to a p-box that can authorize (or reject) the flow. Francis, et al. Expires October 22, 2007 [Page 12] Internet-Draft An EME Signaling Protocol Design April 2007 4. Examples Following are some examples to clarify and flesh out the above "design". These example focus on illustrating the coupling between name-routed and address-routed messages. As such, there are many examples that are, at least for the time being, left out. In addition, any separate messages resulting from authentication are also not shown (and the "Authenticator" elements of the device components are not shown). Note that we acknowledge that the syntax in these examples (such as it is) is somewhat high-level. We are trying to strike a balance between too much detail (which would obscure the operation), and not enough detail (which would prevent the reader from understanding what is happening). 4.1. Case A In this case, there are two single-homed sites, where both ends have p-box functionality in the (m-box) NAT boxes. This illustrates the conveyance of NAT mapping information. The topology is as follows, where H1 and H2 are the endhosts in sites 1 and 2, and M1 and M2 are the NAT boxes. +-------+ +-------+ +-------+ | | | | | | | H1 |--M1--| |--M2--| H2 | | | | | | | +-------+ +-------+ +-------+ Site 1 Internet Site 2 A.1 H1->M1 (name routed): H1-dev[Name(H1name, appName), Stack(IP-TCP, IPaddr, TCPport) ] H2-dev[Name(H2name, appName) ] H1-Data[TCP SYN, App data ] A.2. M1: DNS lookup on H2name, returns M2 IP address. A.3. M1->M2 (name routed): H1-dev[...same as before...] H2-dev[...] H1-Data[...] M1-dev[Stack(IP-TCP-IP, pubIPaddr, pubTCPport), Token("flow enabled at m-box") ] Francis, et al. Expires October 22, 2007 [Page 13] Internet-Draft An EME Signaling Protocol Design April 2007 A.4. M2->H2 (name routed): H1-dev[...] H2-dev[...] H1-Data[...] M1-dev[...] M2-dev[Stack(IP-TCP-IP, pubIPaddr, pubTCPport), Token("flow enabled at m-box") ] A.5. H2->M2 (reverse routed): H1-dev[...] H2-dev[...] M1-dev[...] M2-dev[...] H2-dev[Stack(IP-TCP, IPaddr, TCPport) ] H2-Data[TCP SYN/ACK, App data] A.6. M2->M1 (reverse routed): H1-dev[...] H2-dev[...] M1-dev[...] M2-dev[...] H2-dev[...] H2-Data[...] A.7. M1->H1 (reverse routed): H1-dev[...] H2-dev[...] M1-dev[...] M2-dev[...] H2-dev[...] H2-Data[...] A.8 data flow The total signaling path is: H1-M1-(DNS)-M2-H2-M2-M1-H1 4.1.1. Comments Note that there are two H2-dev components. One was put in by H1, and contains names. The next was put in by H2 (in step A.5), and contains stack info and data. By doing it this way, it is clear which system put what into the signaling message. Since H2 didn't negate anything that H1 put in, we can combine information in the two components. H2 can sign both H2-dev components. (In subsequent messages, only a single H2-dev component is shown, to represent the combination of both components.) M1 and M2 are able to insert tokens indicating that the data flow is enabled, since they are both p-box and m-box for the later flow. Internally, M1 and M2 simply keep track of the NAT mapping state conveyed in the signaling messages, and use this to later identify and (weakly) authenticate the flow. Because the tokens have already authorized the flow, there is no need for subsequent signaling: by the time each endpoint receives the message, all the information needed to start the flow exists. Note that, although M1 enabled the flow in message A.3, it is not yet able to fill in all of the NAT state, because it does not know what Francis, et al. Expires October 22, 2007 [Page 14] Internet-Draft An EME Signaling Protocol Design April 2007 address and port M2 will assign. It learns this when it receives the message in step A.6. Since messages contain a history of where they have been, it is possible by observing a message to know if m-boxes have adequate state (i.e. NAT state) for forwarding packets. Indeed this is how hosts know to stop sending messages. The notation "IP-TCP" in the stack of step A.1 is meant to indicate that host H1 plans to use IP and TCP for this application. The IPaddr and TCPport refer to these protocols. Though we don't show it, H1 could have listed several stacks (IP-TCP, IP-IPsec-TCP, IP- TCP-SSL, etc.) as a way of negotiating protocol, and given the relevant parameters for each. Subsequent boxes could have pruned the set, ultimately selecting one stack. The stack "IP-TCP-IP" for the m-boxes is meant to indicate that IP is terminated on each side of the m-box, and that TCP is modified but not terminated. Obviously we'll need a nice notation for this. When H2 receives the message in step A.4, it sees three devices, M2, M1, and H1. We are assuming that the message syntax allows H2 to know that 1) M2 is 'up', M1 is 'across', and H1 is 'down', that 2) H2 is therefore on the private side of M2 and the public side of M1, and that 3) it should therefore use the public address of M1 as the destination address of transmitted data packets. In this example (and subsequent examples), we assume that the boxes are sufficiently authenticated. Note however that if challenge/ response authentication is being used, then an extra signaling leg is needed for the responses and associated enabling of the flow. "Name routed" means that the name is used to route the message. So, H1->M1 is learned through configuration of H1 (DHCP or dynamic discovery), M1->M2 learned through DNS, and M2->H2 through a registration. "Reverse routed" means that the return message follows the reverse path of the initial message. Note that, strictly speaking, the return message could have been "address routed", which means that the IP address information needed to route a signaling message exists. But I think the design is cleaner if return messages follow the reverse path. (Perhaps H2 could have sent an addr-routed message in parallel.) We might want one more leg of the signaling message as an acknowledgement from H1 to H2. Francis, et al. Expires October 22, 2007 [Page 15] Internet-Draft An EME Signaling Protocol Design April 2007 4.2. Case B H1 is behind a single NAT as with example 1, but H2's site is multi- homed, and H2 is behind two NAT boxes, both of which act as p-box and m-box. +-------+ +-------+ +-------+ | | | |-M21--| | | H1 |--M1--| | | H2 | | | | |-M22--| | +-------+ +-------+ +-------+ Site 1 Internet Site 2 The interesting problem here is that the signaling path may involve one m-box, while the data path uses the other. There are a number of ways to handle this case (referral, parallel signaling, and m-box pinning), as follows: 4.2.1. Case B, Version a This version shows the use of referral. Assume that steps identical to steps A.1-A.7 occur, but with M21 instead of M2. Also, assume that DNS returned both M21 and M22 at step A.2, but that M1 only used the address for M21. Ba.8 Data flow H1-M1-M21-H2 works, but assume that packets from H2 are routed by IP to M22. This results in a referral message: M22->H2 (addr-routed): Referral message: token needed, obtain from p-box M22. Ba.9. H2->M22 (name-routed): H1-dev[...] H2-dev[...] M1-dev[...] M21-dev[...] H2-dev[Name(H2name, appName), Stack(IP-TCP, IPaddr, TCPport) ] H2-Data[TCP SYN/ACK, App data] Ba.10. M22->M1 (name-routed): H1-dev[...] H2-dev[...] M1-dev[...] M21-dev[...] H2-dev[...] H2-Data[...] M22-dev[Stack(IP-TCP-IP, pubIPaddr, pubTCPport), Token("flow enabled at m-box") ] Francis, et al. Expires October 22, 2007 [Page 16] Internet-Draft An EME Signaling Protocol Design April 2007 Ba.11. M1->H1 (name-routed): H1-dev[...] H2-dev[...] M1-dev[...] M21-dev[...] H2-dev[...] H2-Data[...] M22-dev[...] Ba.12. H1->M1 (reverse-routed): H1-dev[...] H2-dev[...] M1-dev[...] M21-dev[...] H2-dev[...] H1-Data[...] M22-dev[...] Ba.13. M1->M22 (reverse-routed): H1-dev[...] H2-dev[...] M1-dev[...] M21-dev[...] H2-dev[...] H1-Data[...] M22-dev[...] Ba.14. M22->H2 (reverse-routed): H1-dev[...] H2-dev[...] M1-dev[...] M21-dev[...] H2-dev[...] H1-Data[...] M22-dev[...] Ba.15 data flow (H1<->M1<->M22<->H2) The total signaling path is: H1 M1 M21 M22 H2 | | | | | A.1 - A.4 |====>o====>o=====|====>o | | | | | A.5 - A.7 o<====o<====o<====|=====| | | | | | A.8 data flow |>>>>>o>>>>>o>>>>>|>>>>>o | | | x<<<<<| | | | | | Ba.8 o | | |---->o | | | | | Ba.9 - Ba.11 o<====o<====|=====o<====| | | | | | Ba.12 - Ba.14 |====>o=====|====>o====>o | | | | | data flow |>>>>>o>>>>>|>>>>>o>>>>>o data flow |<<<<>>>>o Data flow, intercepted at "o" mark, error at "x" mark ====>o Name-routed or reverse-routed message, handled at ">o" mark ---->o Address-routed message, handled at ">o" mark Francis, et al. Expires October 22, 2007 [Page 17] Internet-Draft An EME Signaling Protocol Design April 2007 4.2.1.1. Comments Had IP routing chosen to send the H2->H1 data flow through M21, then steps Ba.8 through Ba.14 would have been unnecessary. At step Ba.11, H1 now has two valid data paths. H1 needs some guidance on which to use. If the policy at site 2 is that flows must traverse the m-box in both directions, then M22 could have negated the M21 information. If on the other hand, asymmetric flows are ok, the M22 could leave M21 un-negated, and this could inform H1 that it can use either path. Even in this case, however, H1 should probably use the last successfully signaled path. Note, we can't go on adding components to these messages forever (say if H2 were mobile and kept traversing new middleboxes). One approach would be to negate defunct m-boxes as they become defunct, and once negated, leave them out of future signaling message. Messages Ba.12 - Ba.14 is essentially an ACK going H1->M1->M22->H2. This ACK is necessary because any given signaling message must make a final "ACK" trip so that all involved boxes can see that all other boxes have seen it. (Note that the second leg of the signaling message, from H2 to H1, served the purpose of the ACK. This is clear to H1 because no changes were made in the message between H2 and H1.) 4.2.2. Case B, Version b This case shows a version of the use of m-box pinning. This version is identical to example 1, but substituting M21 for M1, and with step four being changed as follows: Bb.4. M21->H2 (name-routed): H1-dev[...] H2-dev[...] H1-Data[...] M1-dev[...] M21-dev[Stack(IP-TCP-IP, pubIPaddr, pubTCPport, privIPaddr, privTCPport), Token("flow enabled at m-box") ] The total signaling path is: H1-M1-(DNS)-M21-H2-M21-M1-H1 Francis, et al. Expires October 22, 2007 [Page 18] Internet-Draft An EME Signaling Protocol Design April 2007 4.2.2.1. Comments Specifically, m-box M21 has added a private IP address and TCP port to its stack. From this, H2 can see the path M21->M1->H1 for its packets. It sees that each has provided an address and port on H2's "side" of the network (private side for M21, public side for M1). Since there is no tunneling indicated in the stacks, H2 can deduce that it needs to address its packets to the private addr and port of M21, and can assume that M21 will re-address the packets appropriately. This will cause packets to be routed through M21, and so we avoid the referral message of step Ba.8 and subsequent re- signaling. Note that if both pinned and non-pinned flows were possible, then M21 would have included two stacks, one indicating pinning and the other indicating no pinning. In general, the intent is that during signaling, device components contain all possible means of communications, and endpoints select from whichever will work E2E. 4.2.3. Case B, Version c This case shows another version of the use of m-box pinning. This version is identical to case B, version c, but with steps four and five being changed as follows: Bc.4. M21->H2 (name-routed): H1-dev[...] H2-dev[...] H1-Data[...] M1-dev[...] M21-dev[Stack(IP-TCP-IP, pubIPaddr, pubTCPport, privIPaddr, privTCPport), Stack(IP-TCP-IP-IP, pubIPaddr, pubTCPport, outerIPaddr), Token("flow enabled at m-box") ] Bc.5. H2->M21 (reverse-routed): H1-dev[...] H2-dev[...] M1-dev[...] M21-dev[...] H2-dev[Name(H2name, appName), Stack(IP-IP-TCP, IPaddr, IPaddr, TCPport) ] H2-Data[TCP SYN/ACK, App data] The total signaling path is the same as example Bb: H1-M1-(DNS)-M21-H2-M21-M1-H1 Francis, et al. Expires October 22, 2007 [Page 19] Internet-Draft An EME Signaling Protocol Design April 2007 4.2.3.1. Comments We see in Bc.4 that M21 has added a stack to its device component (IP-TC-IP-IP). This stack indicates that M21 can terminate an IP-IP tunnel on the H2-side of the flow. M21 also provides an IP address associated with the tunnel. (Note that M21 could have provided yet another tunnel, IP-GRE-IP, in which case it would have also provided the GRE Key value.) In step Bc.5, H2 has indicated that it will use the tunneled stack, and provides addresses for both outer and inner tunnel. Note that the inner tunnel does get translated by the NAT box M21. If H2 does not have tunneling capability, then it will respond with the stack of example 1, thus effectively rejecting M21's offer of using a tunnel to pin the route. 4.2.4. Case B, Version d This shows one version of parallel signaling. In this version, the signaling from H1->M1->M21->H2 take place as with example Ba. After that, H2, knowing that it has two p-boxes (M21 and M22), replicates its signaling message as follows: Francis, et al. Expires October 22, 2007 [Page 20] Internet-Draft An EME Signaling Protocol Design April 2007 Bd.5. H2->M21 (reverse-routed): Leg: H2->M21->M1->M1 H1-dev[...] H2-dev[...] M1-dev[...] M21-dev[...] H2-dev[Name(H2name, appName), Stack(IP-TCP, IPaddr, TCPport) ] H2-Data[TCP SYN/ACK, App data] Bd.6. (addr-routed to M1, then to H1) Leg: H2->M22->M1->H1 Message: H1-dev[...] H2-dev[...] M1-dev[...] M21-dev[...] H2-dev[Name(H2name, appName), Stack(IP-TCP, IPaddr, TCPport) ] H2-Data[TCP SYN/ACK, App data] M22-dev[Stack(IP-TCP-IP, pubIPaddr, pubTCPport), Token("flow enabled at m-box") ] M1-dev[Stack(IP-TCP-IP, pubIPaddr, pubTCPport) ] Bd.7. (reverse routed) Leg: H1->M1->M22->H2 Message: H1-dev[...] H2-dev[...] M1-dev[...] M21-dev[...] M22-dev[...] The total signaling path is: H1 M1 M21 M22 H2 | | | | | A.1 - A.4 |====>o====>o=====|====>o | | | | | Bd.5 o<====o<====o<====|=====| Bd.6 o<----o<----|-----o<----| | | | | | Bd.7 |====>o=====|====>o====>o | | | | | data flow |>>>>>o>>>>>|>>>>>o>>>>>o data flow |<<<<o====>o=====|====>o | o=====|====>o====>o | | | | | o<====o<====o<====|=====| o<----o<----|-----o<----| o<====o<====|=====o<====| | | | | | data flow |>>>>>o>>>>>|>>>>>o>>>>>o data flow |<<<<P1 (name routed): H1-dev[Name(H1name, appName), Stack(IP-TCP, IPaddr, TCPport) ] H2-dev[Name(H2name, appName) ] C.2. P1: DNS lookup on H2name, returns P2 IP address. C.3. P1->P2 (name routed): H1-dev[...] H2-dev[...] M1-dev[Stack(IP-TCP-IP, pubIPaddr>), Token("flow approved for tuple") ] C.4. P2->H2 (name routed): H1-dev[...] H2-dev[...] M1-dev[...] M2-dev[Stack(IP-TCP-IP, pubIPaddr), Token("flow approved for tuple") ] C.5a. H2->P2 (reverse routed): H1-dev[...] H2-dev[...] M1-dev[...] M2-dev[...] H2-dev[Stack(IP-TCP, IPaddr, TCPport) ] Francis, et al. Expires October 22, 2007 [Page 24] Internet-Draft An EME Signaling Protocol Design April 2007 C.5b. H2->M2 (address routed): H1-dev[...] H2-dev[...] M1-dev[...] M2-dev[...] H2-dev[Stack(IP-TCP, IPaddr, TCPport) ] C.6a. P2->P1 (reverse routed): H1-dev[...] H2-dev[...] M1-dev[...] M2-dev[...] C.6b. M2->M1 (address routed): H1-dev[...] H2-dev[...] M1-dev[...] M2-dev[...] M2-dev[Stack(IP-TCP-IP, pubTCPport), Token("flow enabled at m-box") ] C.7a. P1->H1 (reverse routed): H1-dev[...] H2-dev[...] M1-dev[...] M2-dev[...] C.7b. M1->H1 (address routed): H1-dev[...] H2-dev[...] M1-dev[...] M2-dev[...] M1-dev[Stack(IP-TCP-IP, pubTCPport), Token("flow enabled at m-box") ] C.8. H1->M1 (address routed, in response to either message C.7a or b): H1-dev[...] H2-dev[...] M1-dev[...] M2-dev[...] ] C.9. M1->M2 (address routed): H1-dev[...] H2-dev[...] M1-dev[...] M2-dev[...] C.10. M2->H2 (address routed): H1-dev[...] H2-dev[...] M1-dev[...] M2-dev[...] M2-dev[Token("flow enabled (H1->H2 direction)")] ] C.11 data flow The total signaling path is: H1 P1 M1 P2 M2 H2 | | | | | | C.1 - C.4 |====>o=====|====>o=====|====>o | | | | | | C.5a - C.7a o<====o<====|=====o<====|=====| | | | | | | C.5b - C.7b o<----|-----o<----|-----o<----| | | | | | | Francis, et al. Expires October 22, 2007 [Page 25] Internet-Draft An EME Signaling Protocol Design April 2007 C.8 - C.10 |-----|---->o-----|---->o---->o | | | | | | data flow |>>>>>|>>>>>o>>>>>|>>>>>o>>>>>o data flow o<<<<<|<<<<H2 packets at this point, because it knows the IP addr and port H1 is using. It can also enable the flow, which we show happening. However, data packets cannot yet flow because M2 doesn't know the public port M1 has assigned. This doesn't happen until it receives the message from M1 at step C.9. In C.9 (C.10), M1 (M2) doesn't need to add a Stack, because all of the parameters have already been assigned in the previous leg and so are held in the pre-existing M1-dev (M2-dev) component. (Same for H1 on step C.8.) Note that in this example, address-routed messages flow in both directions. There is a kind-of race condition where, for instance, data packets sent subsequent to the address-routed signaling message may go faster than the message (cause of processing delays at the message) and therefore get dropped at m-boxes that have not seen the message. One way to deal with this is just to accept a few dropped packets (though when these trigger referral messages, the end-host would have to know to ignore them). Another way is of course to wait for an ACK of the address routed message (which we don't show in the example, but which certainly could exist). Such ACKs could be E2E, thus bypassing message processing delays. Strictly speaking, in this case the m-boxes could have eavesdropped on the original name- and reverse-routed messages, and in so doing enabling the flow and adding the appropriate parameters. But in the general case this may not be possible, so we go ahead and replicate the reply, address-routed. Francis, et al. Expires October 22, 2007 [Page 26] Internet-Draft An EME Signaling Protocol Design April 2007 6. Case D In this case, both sites are multi-homed with NATs to different ISPs (not shown), which serve as m-boxes. In the case of site 1, P11 is the p-box associated with M11, and P12 is the p-box associated with M12. In the case of site 2, P2 is associated with both M21 and M22. +-------+ +-------+ +-------+ | P11 |-M11--| P2 |-M21--| | | | | | | H2 | | H1 |-M12--| P12 |-M22--| | +-------+ +-------+ +-------+ Site 1 Internet Site 2 H1 initiates the signaling. Assume, however, that IP routing uses the following paths: H1->M21 via M11 H1->M22 via M12 H2->M11 via M22 H2->M12 via M21 In other words, there are no symmetric paths. For instance, if signaling selects M21 as the m-box at site 2, then packets from H1 will traverse M11. If H2 tries to send its packets to M11, however, its packets will traverse M22. Therefore, there is no way to create a symmetric path without m-box pinning. In these examples, we show message "legs" rather than individual messages. 6.1. Case D, Version a In this version, there is no replicated parallel signaling messages anywhere. Da.1: (name-routed) Leg: H1-P11-(DNS)-P2-H2 Message: H1-dev[Name(H1name, appName), Stack(IP-TCP, IPaddr, TCPport) ] H2-dev[Name(H2name, appName) Francis, et al. Expires October 22, 2007 [Page 27] Internet-Draft An EME Signaling Protocol Design April 2007 ] M11-dev[Stack(IP-TCP-IP, pubIPaddr>), Token("flow approved for tuple") ] M21-dev[Stack(IP-TCP-IP, pubIPaddr), Token("flow approved for tuple") ] M22-dev[Stack(IP-TCP-IP, pubIPaddr), Token("flow approved for tuple") ] Da.2: (addr-routed to M11 pubIPaddr, then to H1 IPaddr) Leg: H2-M22-M11-H1 Message: H1-dev[...] H2-dev[...] M11-dev[...] M21-dev[....] M22-dev[...] H2-dev[Stack(IP-TCP, IPaddr, TCPport) ] M22-dev[Stack(IP-TCP-IP, pubTCPport), Token("H2-M11 flow enabled") ] M11-dev[Stack(IP-TCP-IP, pubTCPport), Token("M22-H1 flow enabled"), ] Da.3: (addr-routed to M22, then to H2) Leg: H1-M12-(refer H1 to P12) Message: H1-dev[...] H2-dev[...] M11-dev[...] M21-dev[....] M22-dev[...] Da.4 (name-routed) Leg: H1-P12-P2-H2 Message: H1-dev[...] H2-dev[...] M11-dev[...] M21-dev[....] M22-dev[...] M12-dev[Stack(IP-TCP-IP, pubIPaddr>), Token("flow approved for tuple") ] Da.5 (addr-routed to M12, then to H1) Leg: H2-M21-M12-H1 Message: H1-dev[...] H2-dev[...] M11-dev[...] M21-dev[....] M22-dev[...] M12-dev[...] M21-dev[Stack(IP-TCP-IP, pubTCPport), Token("H2->M12 flow enabled") ] M12-dev[Stack(IP-TCP-IP, pubTCPport), Token("H1-M21 flow enabled") ] Francis, et al. Expires October 22, 2007 [Page 28] Internet-Draft An EME Signaling Protocol Design April 2007 Da.6 (addr-routed to M21, then to H2) Leg: H1-M11-M21-H2 Message: H1-dev[...] H2-dev[...] M11-dev[...] M21-dev[....] M22-dev[...] M12-dev[...] M11-dev[Stack(IP-TCP-IP, pubTCPport), Token("H1-M21 flow enabled") ] M21-dev[Stack(IP-TCP-IP, pubTCPport), Token("M11-H2 flow enabled"), ] Da.7 (addr-routed to M11, then to H1) Leg: H2-M22-M11-H1 Message: H1-dev[...] H2-dev[...] M11-dev[...] M21-dev[....] M22-dev[...] M12-dev[...] Da.8 Data Flow (asymmetric) H1 M11 P11 M12 P12 P2 M21 M22 H2 | | | | | | | | | Da.1 |=====|====>o=====|=====|====>o=====|=====|====>| | | | | | | | | | Da.2 |<----o<----|-----|-----|-----|-----|-----o<----| | | | | | | | | | Da.3 |-----|-----|---->o | | | | | |<----|-----|-----| | | | | | | | | | | | | | | Da.4 |=====|=====|=====|====>o====>o=====|=====|====>| | | | | | | | | | Da.5 |<----|-----|-----o<----|-----|-----o<----|-----| | | | | | | | | | Da.6 |---->o-----|-----|-----|-----|---->o-----|---->| | | | | | | | | | Da.7 |<----o<----|-----|-----|-----|-----|-----o<----| | | | | | | | | | Data |>>>>>o>>>>>|>>>>>|>>>>>|>>>>>|>>>>>o>>>>>|>>>>>o Flow o<<<<), Token("flow approved for tuple") ] M21-dev[Stack(IP-TCP-IP, pubIPaddr), Token("flow approved for tuple") ] M22-dev[Stack(IP-TCP-IP, pubIPaddr), Token("flow approved for tuple") ] Leg B: H1-P12-(DNS)-P2-H2 Message: H1-dev[...] H2-dev[...] (same as leg A) M12-dev[Stack(IP-TCP-IP, pubIPaddr>), Token("flow approved for tuple") ] M21-dev[...] M22-dev[...] (same as leg A) Db.2: (addr-routed) Leg A: H2-M22-M11-H1 Message: H1-dev[...] H2-dev[...] M11-dev[...] M12-dev[...] M21-dev[....] M22-dev[...] H2-dev[Stack(IP-TCP, IPaddr, TCPport) ] M22-dev[Stack(IP-TCP-IP, pubTCPport), Token("H2-M11 flow enabled") ] M11-dev[Stack(IP-TCP-IP, pubTCPport), Token("M22-H1 flow enabled"), ] Leg B: H2-M21-M12-H1 Message: Francis, et al. Expires October 22, 2007 [Page 31] Internet-Draft An EME Signaling Protocol Design April 2007 H1-dev[...] H2-dev[...] M11-dev[...] M12-dev[...] M21-dev[....] M22-dev[...] H2-dev[Stack(IP-TCP, IPaddr, TCPport) ] M21-dev[Stack(IP-TCP-IP, pubTCPport), Token("H2-M12 flow enabled") ] M12-dev[Stack(IP-TCP-IP, pubTCPport), Token("M21-H1 flow enabled"), ] Db.3: (addr-routed) Leg A: H1-M12-M22-H2 Message: H1-dev[...] H2-dev[...] M11-dev[...] M12-dev[...] M21-dev[....] M22-dev[...] M12-dev[Stack(IP-TCP-IP, pubTCPport), Token("H1-M22 flow enabled") ] M22-dev[Stack(IP-TCP-IP, pubTCPport), Token("M12-H2 flow enabled"), ] Leg B: H1-M11-M21-H2 Message: H1-dev[...] H2-dev[...] M11-dev[...] M12-dev[...] M21-dev[....] M22-dev[...] M11-dev[Stack(IP-TCP-IP, pubTCPport), Token("H1-M21 flow enabled") ] M21-dev[Stack(IP-TCP-IP, pubTCPport), Token("M11-H2 flow enabled"), ] Db.4 (addr-routed) Leg A: H2-M22-M11-H1 Message: H1-dev[...] H2-dev[...] M11-dev[...] M12-dev[...] M21-dev[....] M22-dev[...] Leg B: H2-M21-M12-H1 Message: H1-dev[...] H2-dev[...] M11-dev[...] M12-dev[...] M21-dev[....] M22-dev[...] Db.5 Data Flow (asymmetric): Francis, et al. Expires October 22, 2007 [Page 32] Internet-Draft An EME Signaling Protocol Design April 2007 H1 M11 P11 M12 P12 P2 M21 M22 H2 | | | | | | | | | Db.1 |=====|====>o=====|=====|====>o=====|=====|====>| |=====|=====|=====|====>o====>o=====|=====|====>| | | | | | | | | | Db.2 |<----o<----|-----|-----|-----|-----|-----o<----| |<----|-----|-----o<----|-----|-----o<----|-----| | | | | | | | | | Db.3 |-----|-----|---->o-----|-----|-----|---->o---->| |---->o-----|-----|-----|-----|---->o-----|---->| | | | | | | | | | Db.4 |<----o<----|-----|-----|-----|-----|-----o<----| |<----|-----|-----o<----|-----|-----o<----|-----| | | | | | | | | | Data |>>>>>o>>>>>|>>>>>|>>>>>|>>>>>|>>>>>o>>>>>|>>>>>o Flow o<<<<