Subject: [OFF-PATH-BOF] SIP, naming, APIs and control

From: Teemu Koponen <[email-masked]>
Date: Thu, 13 Jul 2006 10:35:02 -0700

Thanks for a very interesting BoF, Paul, Mark and Saikat.  There's
definitely ongoing work in this area elsewhere too. :) Here's my
unstructured initial stake on the matter.

I have to say that I was more than slightly concerned about the
proposed content before hearing the presentations. It seemed that the
called approach would not be a "clean-slate" one but a more
engineering oriented effort. Especially,

o) The promotion of SIP was concerning. I tend to see the current SIP
as a rather complex beast indeed. While it does have certain
attractive primitives built-in (e.g., delegation to impose off-path
middleboxes), I would not like to remain fixed to SIP. In the end, I
believe something more simple can meet the requirements. Fortunately,
SIP was less emphasized in the presentions themselves than in the
call.

o) Mixing the needs to persistently identify an end-point for machines
and for users was distracting.  I do not think hierarchical names
should remain the sole option to consider. Flat names are rather
attractive option indeed to identify end-points for machines. In fact,
I think one should support both.

"Newsock" was mentioned, but I was somewhat confused when the focus
was in the API and when in the protocol.  I feel that explicitly
considering the API first would enforce us to think the requirements
before moving down to the protocol level issues. Moreover, I could
imagine an outcome where applications could use multiple "offpath
protocols" through the same API.

The fundamental aspect I still do not understand is that how the
decoupling of signaling and data paths helps at all. It strikes to be
problem roaming only for me. (I think Bob Briscoe asked this without
getting a decent answer.) I'm not sure whether I heard the word in
some comment, but I think the group name misses a single word:
control. This all is about getting the control back to the end-points
and not that much about decoupling the paths.

Teemu

--

_______________________________________________
OFF-PATH-BOF mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/off-path-bof

---

From: Melinda Shore <[email-masked]>
Date: Thu, 13 Jul 2006 14:12:36 -0400

> I think one should support both.

I think it's probably early to bog down in deployment issues, but
I do think it's worth mentioning deployment issues *un*related to
compatibility issues and I think this is one of them, for two
reasons:

1) flat namespaces are just plain hard to manage, and
2) I'm not sure where Paul or anybody else stands on this
   but I've been laboring in these particular fields for a
   few years now and from my perspective the really hard problems
   relate to topology and "findability."  It's much harder to
   find your way around a flat namespace.

> and not that much about decoupling the paths.

When I first brought the proposal for on-path middlebox communication
to the IETF I described it as "topology insensitive," and I think that's
still the desired outcome.  However, what we've found over the past
few years is that on-path middlebox signaling is nearly impossible to deploy
in all but the most constrained networks.  I agree that focusing on
the question of whether or not the signaling is on-path or off-path
is largely orthogonal to the work that needs to be done, but by
now we know an awful lot about how to do both on-path and off-path
control/request/communications but not how to solve the extremely
difficult problems introduced by even modest topological complexity.
My opinion is that ultimately it's the path-decoupled stuff (I
guess "off-path" is kind of misleading in this context) that's going
to be *actually* useful in real networks, but obviously there's
not yet any consensus about this and some further discussion is
undoubtedly necessary.

But it is my feeling that the "control" aspect has kind of been done
to death and is well beyond the research stage.

Melinda

---

From: Teemu Koponen <[email-masked]>
Date: Thu, 13 Jul 2006 11:59:38 -0700

On Jul 13, 2006, at 11:12, Melinda Shore wrote:

> in all but the most constrained networks.

I believe everyone agrees on this; requiring middleboxes to be on the  
path complicates deployment. However, when questioning the point of  
decoupling signaling and data paths, I all the time assumed this  
combined data and signaling path to be different from a path routers  
give you. Is this what you mean or do you opt for three different  
paths: a router given, signaling, and data path?

> difficult problems introduced by even modest topological complexity.

Could you elaborate these difficult problems?

Teemu

--

---

From: Melinda Shore <[email-masked]>
Date: Thu, 13 Jul 2006 15:38:46 -0400

On 7/13/06 2:59 PM, "Teemu Koponen" <[email-masked]> wrote:
> path complicates deployment.

Actually, it's my impression that some people agree with this at
this time, but not yet the preponderance of people.

> However, when questioning the point of

Ah.  Maybe somebody should write up an informational document
defining some of these terms so that we're at least all using the
same language.  "Off-path" middlebox control assumes that you know
the address of the middlebox you'd like to control and that you
can establish a relationship with it directly (client/server, if
you like).  The actual route taken is irrelevant in terms of
the protocol design, although obviously there may be some operational
considerations.  "On-path" middlebox control typically (but not
always) assumes that you do not know the addresses of any
middlebox along the path or, for that matter, which path the
data will be taking.  It works much like RSVP, where the requests
are addressed to the application peer and intercepted by middleboxes
they happen to traverse.  nsis is actually somewhere in the middle.

> Could you elaborate these difficult problems?

Probably not exhaustively - every time you think you've got something
licked another one crops up.  But basically, if you're going to
address a middlebox directly you have to know where it is, and again,
aside from operational considerations (operators/network administrators
typically are loathe to reveal the locations of their firewalls, not
to mention configuration/provisioning of firewall locations) you have
to know which firewall is the correct one.  Throw in NATs, and you
start having to know who is where in relationship to each other, so
that you can request the correct firewall pinhole addresses, or QoS
reservations, or anything else that requires installing a network
address in the middle of the network.  For example, if your network
looks like:

    Host----NAT----firewall

you'll need to request an external (to the NAT) address, while if
it's

    Host----firewall----NAT

you'll need to request  the internal (to the NAT) address.

This problem in conjunction with figuring out how to handle multihoming
and route changes is what motivated the topology-insensitive work in the
first place, but the problem is that for the on-path stuff you need a
path, which is a route between two (or more, but we won't go there)
endpoints.  If the other guy doesn't have a network presence because he's
NATted or otherwise invisible, you don't have a path.  Now, it's
possible to start sticking proxies into the network to act on behalf
of unpresent hosts, but that reintroduces the topology problems that
we find in off-path signaling and then you end up, in my opinion, with
the worst of both approaches.

There are some unbelievably hacky workarounds for these problems, but
they introduce other issues around resource consumption and security
vulnerabilities.  In fact, one of the things that I really like
about Paul's proposal is the focus on authorization for middlebox
traversal.  

Melinda

---

From: Saikat Guha <[email-masked]>
Date: Fri, 14 Jul 2006 17:20:44 +0100

On Thu, 2006-07-13 at 15:38 -0400, Melinda Shore wrote:
> Maybe somebody should write up an informational document
> same language.

I'll draft up a proposal for the terms, but just so we are all on the
same page for mailing list discussion, my understanding of {on,off}path,
data{coupled,decoupled}, {in,out of}band, end-to-{end,middle}-signaling
are as follows.

   _----------S---------_
  /                      \
 /                        \
A --- N --Internet-- M --- B

If A and B are the two endpoints that want to communicate, the path that
data packets between the two will ultimately take is termed the
DATA-PATH. Data refers to some application data (not the signaling
packet).

OFF-PATH signaling, synonymous with DATA-DECOUPLED signaling, refers to
the case where signaling packets (at least the first signaling packet)
_necessarily_ take a path different than the DATA-PATH.

ON-PATH signaling, synonymous with DATA-COUPLED signaling, is when
signaling packets (even the first) do _not necessarily_ take a path
different from the DATA-PATH.

IN-BAND signaling is defined as a subset of ON-PATH signaling where the
signaling packets are piggy-backed on the data packets themselves i.e.
use the same 5-tuple as the data flow. OUT-OF-BAND signaling is a subset
of ON-PATH signaling where the signaling packets are not piggy-backed on
the data packets and use a different 5-tuple.

END-TO-END-SIG is where the signaling message sent by one end (A) MAY be
delivered to the other end (B).

END-TO-MIDDLE-SIG is where the signaling message sent by one end (A)
cannot be delivered to the other end.

Here is how I would classify some signaling protocols:
[Disclaimer: Some protocols can move between classification depending on
the mode they can be put in. Classification for other protocols may just
be entirely wrong. :-p]

OFF-PATH / DATA-DECOUPLED, END-TO-END-SIG
=====================================
SIP, XMPP (e.g. data is filetransfer), MPLS-LDP (END here is the LSR)

OFF-PATH / DATA-DECOUPLED, END-TO-MIDDLE-SIG
=====================================
DNS

ON-PATH / DATA-COUPLED, OUT-OF-BAND, END-TO-END-SIG
===================================
NSIS, RTCP, FTP control

ON-PATH / DATA-COUPLED, OUT-OF-BAND, END-TO-MIDDLE-SIG
===================================
UPnP, Midcom, SOCKS (for bind request), Remote-WinSock

ON-PATH / DATA-COUPLED, IN-BAND, END-TO-END-SIG
===================================
TCP SYN, TURN (note, TURN server may not be on the direct IP path, but
it is still on the DATA-PATH), BEEP

ON-PATH / DATA-COUPLED, IN-BAND, END-TO-MIDDLE-SIG
===================================
SOCKS (for connect request)

-- 
Saikat

---

From: Teemu Koponen <[email-masked]>
Date: Fri, 14 Jul 2006 09:43:52 -0700

> A --- N --Internet-- M --- B

Your classification assumes M and N are not explicitly addressed  
middleboxes, right?

Teemu

--

---

From: Saikat Guha <[email-masked]>
Date: Fri, 14 Jul 2006 18:34:56 +0100

> Your classification assumes M and N are not explicitly addressed  

The classification applies more to the signaling protocol than devices
themselves. However, the choice of the device may preclude one signaling
protocol or another. Here, N and M may or may not be explicitly
addressed depending on the nature of the device.

If N and M are UPnP/midcom/TURN/SOCKS servers etc., then they need to be
addressed explicitly, and for that, some off-path signaling needs to
happen first to discover their addresses. This off-path signaling can be
as simple as a DNS query, link-level broadcast, or a more complicated
SIP discovery/negotiation. -- Some lookup mechanism that _won't_ be used
for the actual data.

If N and M are firewall/NAT boxes, they need not be explicitly
addressed, therefore there is no such need for an off-path lookup to
discover N/M -- i.e. N and M can be discovered (invoked?) by the same
mechanism that'll be used to send data (unicast IP routing from A to B).
An off-path lookup, however, may still be needed to find B in the first
place.

Not sure if I answered your question,
-- 
Saikat
_______________________________________________
OFF-PATH-BOF mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/off-path-bof

---

From: Saikat Guha <[email-masked]>
Date: Fri, 14 Jul 2006 18:58:39 +0100

On Thu, 2006-07-13 at 10:35 -0700, Teemu Koponen wrote:
> decoupling of signaling and data paths helps at all.

I guess one way to put what we (Paul and I) were trying to say is that
there is a present need for "end-to-end off-path signaling" today.

Connection establishment in the original Internet involved an
end-to-middle off-path lookup (DNS) followed by an end-to-end on-path
signal (TCP SYN).

That is no longer sufficient today, especially when you have firewalls
that drop all inbound traffic to be on the safe side. One such firewall
at each end and your end-to-end on-path signal can no longer make it.

If instead of the end-to-middle off-path signaling (DNS) you first
perform end-to-end off-path signaling (SIP or something such), the ends
now can punch the holes to let your end-to-end on-path signal (TCP SYN)
through.

So the architecture can be viewed as either:

a) decoupling the existing end-to-end path (TCP SYN) into 
   end-to-end off-path and end-to-end on-path components.

  or alternatively as:

b) extending the existing end-to-middle off-path lookup (DNS) to an
   end-to-end off-path signaling

still not sure if I am caffinated enough,
-- 
Saikat
_______________________________________________
OFF-PATH-BOF mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/off-path-bof

---

From: "Paul Francis" <[email-masked]>
Date: Tue, 25 Jul 2006 11:49:11 -0400

There are about 50 folks on this mailing list now.

I know y'all are all feverishly awaiting a draft agenda to discuss, but I'm
going on holiday for the next week and a half, so don't want to start
anything until after that.

PF

---

From: Scott W Brim <[email-masked]>
Date: Fri, 28 Jul 2006 14:52:01 +0200

Catching up after being on the road for three weeks ...

On 07/14/2006 18:20 PM, Saikat Guha allegedly wrote:
> If A and B are the two endpoints that want to communicate, the path
> that data packets between the two will ultimately take is termed the
> OFF-PATH signaling, synonymous with DATA-DECOUPLED signaling, refers
> to the case where signaling packets (at least the first signaling
> packet) _necessarily_ take a path different than the DATA-PATH.

First I want to push for a few terminology nits ...

Technically they are not synonymous, at least in some circles.  Path-
(or data-) decoupled means it NEED not take the same path as the data,
but MIGHT.  That's what we usually mean with SIP.  On the other hand
some network operators want true off-path, which means signaling and
data MUST take separate paths.

> IN-BAND signaling is defined as a subset of ON-PATH signaling where
> the signaling packets are piggy-backed on the data packets
> themselves i.e.  use the same 5-tuple as the data flow.

Well, they are piggy-backed on the same FLOW but could be in different
packets.

> cannot be delivered to the other end.

Hm, you say "cannot be delivered".  Is that required?  Do you mean
that interaction with the intermediary is required to reach the other
end?  E2M signaling would seem to be where the source end explicitly
knows of and speaks to a middlebox ... whether it could (also) speak
to the other endpoint or not.  Why not just say that e2m is where the
"signaling" is addressed to something that is known to be an
intermediary and not the ultimately desired endpoint?

On 07/13/2006 19:35 PM, Teemu Koponen allegedly wrote:
> decoupling of signaling and data paths helps at all. It strikes to
> be problem roaming only for me. (I think Bob Briscoe asked this
> without getting a decent answer.) I'm not sure whether I heard the
> word in some comment, but I think the group name misses a single
> word: control. This all is about getting the control back to the
> end-points and not that much about decoupling the paths.

It enables indirection, which doesn't necessarily mean being at the
mercy of a third party.  An intermediary could be under your control.
You are right that the signaling doesn't have to be off-path, but you
don't want to assume that it's on-path.  This is where Melinda's work
comes in.

swb

---

From: Saikat Guha <[email-masked]>
Date: Fri, 28 Jul 2006 21:02:50 +0100

On Fri, 2006-07-28 at 14:52 +0200, Scott W Brim wrote:
> Technically they are not synonymous, at least in some circles.  

Agreed. I should have used different terms; what I was trying to get at
was a slightly broader picture of a communication session between two
endpoints.

Take an FTP transfer for instance between client C and server S.
Consider how it would be accomplished in various architectures today.

Arch #1: Internet before DNS
----------------------------
1. Assumption: C must know S's IP address.
   - How? Business card, phone call, ... somehow
2. C sends a TCP SYN to S's IP address
   - This 'signal' follows the same path that data will eventually
     follow. 
3. Over the signaling channel in #2, C sends a request. S opens a 
   data connection by sending another SYN signal. Data can now flow.

#1 = assumption: knows IP address
#2 = end-to-end signal
#3 = end-to-end data

Arch #2: Internet with DNS
--------------------------
1. Assumption: C must know S's hostname
2. C does a DNS request to it's local resolver
   - This 'signal' is along a different path than the e2e path that
     the data will eventually take
3. Same as #2 above
4. Same as #3 above.

#1 = assumption: knows hostname
#2 = end-to-middle signal
#3 = end-to-end signal
#4 = end-to-end data

Arch #3: With SIP/ICE/NAT-Traversal
-----------------------------------
1. Assumption: C must know S's URI
2. C sends 'INVITE' to S over SIP
   - This path _may_ be different from the ultimate e2e data path
3. S responds with a transient IP address/port pair over SIP
4. Same as #3 above
5. Same as #4 above

#1 = assumption: knows URI 
#2 = end-to-middle-to-end signal (possible disjoint from data-path)
#3 = end-to-middle-to-end signal (possible disjoint from data-path)
#4 = end-to-end signal
#5 = end-to-end data

Arch #4: With TURN relay in addition with SIP/ICE/...
-----------------------------------------------------
1. Assumption: C must know S's URI
2. Same as #2 above
3. Same as #3 above, except returns a TURN server's address
4. C sends a SYN to the TURN server, TURN server connects to S
5. For data conection, S connects to TURN server, which connects to C

#1 = assumption: knows URI
#2 = end-to-middle-to-end signal (possible disjoint from data-path)
#3 = end-to-middle-to-end signal (possible disjoint from data-path)
#4 = end-to-middle-to-end signal (along data-path)
#5 = end-to-middle-to-end data

So basically, I was shooting for terms to differentiate the various
components of these architectures.

a) end-to-middle signal                  (DNS, UPnP, ....)
b) end-to-middle-to-end signal           (SIP, i3, TURN, NSIS, ...)
   b1) not necessarily along data path     (SIP, i3, ...)
   b2) along the data path                 (TURN, NSIS, ...)
       b21) same "flow"                      (TURN, ...)
       b22) different "flow"                 (NSIS, ...)
c) end-to-end signal                     (TCP SYN, ...)
d) end-to-end data                       (TCP Data, ...) 
e) end-to-middle-to-end data             (TURN Data)