Re: runumbering (was: Re: IPv6: Past mistakes repeated?)
Ok, I will stop being a lurker and chime in since our draft was mentioned :- Stephen Sprunk wrote: draft-xie-stewart-sigtran-ddp-00 addresses redundancy and failover of sessions within a server pool, where uncoordinated failover of sessions from one endpoint to another is a requirement. There is signifcant overheard and indirection added to the session to achieve this. Yes, I think you sum up what DDP attempts to do but I strongly disagree with your "signifcant overhead" argument. Qiaobing and I have been playing with DDP now for quite a number of years. It has some overhead on the wire (not much) since the overhead is mainly upfront i.e. when you want to go hold a talk to someone you may need to do a query to find out where it is and where all its redundant pools are. This drops in to a cache in any sensible implementation and then within some period will need to expire or be updated. Even when the cache is updated it does NOT interfere with the ongoing communication (its done in parrallel). So basically the delay overhead to talk to a peer is possibly one round trip to the local ENRP server (of course local is not necessarrily on the machine you are on but it could be :-0). In some cases there may be no delay. In particular, the ability to send to a address (pre-known) and then do a parrallel query to the ENRP deamon. We did not get this one in the draft but I am sure future updates will have this ... The point is I can't see what your "signifcant overhead" is. Yes it will take a query to get some redundancy but after 5 years of work I think we have the overhead as slim as we can... of course perhaps the working group will show us a way to reduce it further but we will see We seem to be discussing a simpler requirement: coordinated movement of a session from one ip:port pair on a single endpoint to a different ip:port pair on the same endpoint. Windows, buffer states, sequence numbers, etc. could all remain the same. In its basic state this is what DDP does do.. i.e. if you don't have multiple peers. But of course if the route fails between you and your peer, the conversations over.. until the path is back up. I would think the latter requirement could be implemented as a simple TCP "forward me" option. For ESP/AH-protected sessions, no TCP-level anti-hijacking protection seems necessary. This could even be performed if the original IP is suddenly not available and the other endpoint hasn't given up on the connection yet; you send a "forward me" packet sourced from the first IP, then listen for an ACK on the new IP. I can think of no simple way (ie. without recreating IKEAH inside TCP) to do this for unprotected sessions; I'm not sure it's worth the effort to solve either. I'm sure there's something I'm missing here, or else this would have been implemented 15 years ago... Thoughts? Yes, having worked at solving this problem for 5 years you are missing some of the subtle nature of where the different state is. You really must have a seperate state around, unless the "new IP" is attached to the same machine. In that case you end up with something that looks like SCTP to provide the redundancy, i.e. use the "new IP" address. R S | | Stephen Sprunk, K5SSS, CCIE #3723 :|::|:Network Consulting Engineer, NSA :|||: :|||: 14875 Landmark Blvd #400; Dallas, TX .:|||:..:|||:.Email: [EMAIL PROTECTED] - Original Message - From: [EMAIL PROTECTED] To: Karl Auerbach Cc: IETF Sent: Wednesday, April 26, 2000 16:48 Subject: RE: runumbering (was: Re: IPv6: Past mistakes repeated?) Turn it any way you want, TCP sessions can only survive renumbering through end to end mechanisms... Which raises the interesting (to me anyway) question: Is there value in considering a new protocol, layered on top of TCP, but beneath new applications, that provides an "association" the life of which transcends the TCP transports upon which it is constructed? I believe that if we had such a protocol that it would be a useful tool to solve many of the juggling acts that transpire under the heading of "mobile networking" as well as providing a way to continue (or "resume") connectivity after IP address changes. (I will, of course, be suitably embarrassed if someone points out that work is already going on to do this.) draft-xie-stewart-sigtran-ddp-00.txt ned -- Randall R. Stewart Member Technical Staff Network Architecture and Technology (NAT) 847-632-7438 fax:847-632-6733
Re: runumbering (was: Re: IPv6: Past mistakes repeated?)
It seems to me that the decision to just use NATv6 rather than do a site-wide runumber will be a very easy decision to make. Actually, if your assumption is that NATv6 is better than IPv6 with renumbering, then IPv4 and NATv4 was good enough to start with and there was need to move to IPv6 in the first place. However, many people fear that NATs just won't cut it as a long-term solution, with a number of different reasons why this is so (impact on security and applications, operational and administrative costs, etc.). But if NATv4 doesn't cut it, I don't see how NATv6 between IPv6 sites cuts it either. Thomas
Re: runumbering (was: Re: IPv6: Past mistakes repeated?)
So what I am suggesting is that it seems that there is evidence that one can do an "association" protocol that is relatively lightweight in terms of machinery, packets, packet headers, and end-node state if one leaves the heavy lifting of reliability to the underlying TCP protocol. the on-the-wire protocol overhead is not that great. the computational overhead to the host and application, and the resulting loss in maximum bandwidth, are fairly expensive. basically it's a lot more efficient to do some variant of mobile IP. Keith
Re: runumbering (was: Re: IPv6: Past mistakes repeated?)
Thomas Narten writes: | Actually, if your assumption is that NATv6 is better than IPv6 with | renumbering, then IPv4 and NATv4 was good enough to start with and | there was need to move to IPv6 in the first place. ^ no (right? maybe this is where the previous "not" came from -:) ) Did you see Noel's excellent observation that the problem with NAT is architectural and not mechanical? The architectural problem: more things to address on one side of the NAT than there are addresses on the other side of the NAT. IPv6 does bring *ONE* thing significantly different from IPv4: lots of address space. So much, that we do not obviously need to have situations where there is an addressability mismatch on any side of a NAT. NATv6 therefore does not suffer the architectural flaw that causes him to have real problems with NAT, although it can suffer many of the mechanical problems, particularly if IPv6 deliberately seeks to worsen the mechanical difficulties of NATv6. This allows for the architectural features of NAT to be less awkwared to exploit. | But if NATv4 doesn't cut it, I don't see how NATv6 between IPv6 | sites cuts it either. I hope this makes it clearer for you. Sean.
RE: runumbering (was: Re: IPv6: Past mistakes repeated?)
I agree completely with what you say about needing to push the multi-address complexity to the host. As you kindly pointed out (and I self-servingly expand on here), this is an architecture I put forth about a decade ago in a sigcomm paper (in Zurich, I don't remember the year). The paper "Efficient and robust policy routing using multiple hierarchical addresses " was published at the 1991 SIGCOMM, in Zurich. ACM papers used to be available on line, but it seems that the ACM now wants to enforce pay per view. (http://www.acm.org/pubs/citations/proceedings/comm/115992/p53-tsuchiya/) There is related work on an "Extended Transmission Control Protocol" available at http://www.chem.ucla.edu/~beichuan/etcp/ But that architecture (hosts having multiple addresses representing a site's multiple aggregation prefixes and selecting among them) requires some method of identifying hosts when they switch from one address to another mid-connection. I would assume that what people have in mind for this are the mobility mechanisms? (The alternative is 8+8 or some variant, which I understand to be contentious enough that it is a defacto non-starter.) The rubbing point is that identifying is not quite enough -- you need "secure identifying" in order to avoid connection hijacking, probably through some variation of IPSEC. Which brings us back to NATs not being terribly helpful...
RE: runumbering (was: Re: IPv6: Past mistakes repeated?)
mid-connection. I would assume that what people have in mind for this are the mobility mechanisms? (The alternative is 8+8 or some variant, which I understand to be contentious enough that it is a defacto non-starter.) The rubbing point is that identifying is not quite enough -- you need "secure identifying" in order to avoid connection hijacking, probably through some variation of IPSEC. Which brings us back to NATs not being terribly helpful... But if the mechanisms used are the mobility mechanisms, then the security mechanisms for mobility will apply... PF
RE: runumbering (was: Re: IPv6: Past mistakes repeated?)
Turn it any way you want, TCP sessions can only survive renumbering through end to end mechanisms... Which raises the interesting (to me anyway) question: Is there value in considering a new protocol, layered on top of TCP, but beneath new applications, that provides an "association" the life of which transcends the TCP transports upon which it is constructed? I believe that if we had such a protocol that it would be a useful tool to solve many of the juggling acts that transpire under the heading of "mobile networking" as well as providing a way to continue (or "resume") connectivity after IP address changes. (I will, of course, be suitably embarrassed if someone points out that work is already going on to do this.) draft-xie-stewart-sigtran-ddp-00.txt ned
Re: runumbering (was: Re: IPv6: Past mistakes repeated?)
draft-xie-stewart-sigtran-ddp-00 addresses redundancy and failover of sessions within a server pool, where uncoordinated failover of sessions from one endpoint to another is a requirement. There is signifcant overheard and indirection added to the session to achieve this. We seem to be discussing a simpler requirement: coordinated movement of a session from one ip:port pair on a single endpoint to a different ip:port pair on the same endpoint. Windows, buffer states, sequence numbers, etc. could all remain the same. I would think the latter requirement could be implemented as a simple TCP "forward me" option. For ESP/AH-protected sessions, no TCP-level anti-hijacking protection seems necessary. This could even be performed if the original IP is suddenly not available and the other endpoint hasn't given up on the connection yet; you send a "forward me" packet sourced from the first IP, then listen for an ACK on the new IP. I can think of no simple way (ie. without recreating IKEAH inside TCP) to do this for unprotected sessions; I'm not sure it's worth the effort to solve either. I'm sure there's something I'm missing here, or else this would have been implemented 15 years ago... Thoughts? S | | Stephen Sprunk, K5SSS, CCIE #3723 :|::|:Network Consulting Engineer, NSA :|||: :|||: 14875 Landmark Blvd #400; Dallas, TX .:|||:..:|||:.Email: [EMAIL PROTECTED] - Original Message - From: [EMAIL PROTECTED] To: Karl Auerbach Cc: IETF Sent: Wednesday, April 26, 2000 16:48 Subject: RE: runumbering (was: Re: IPv6: Past mistakes repeated?) Turn it any way you want, TCP sessions can only survive renumbering through end to end mechanisms... Which raises the interesting (to me anyway) question: Is there value in considering a new protocol, layered on top of TCP, but beneath new applications, that provides an "association" the life of which transcends the TCP transports upon which it is constructed? I believe that if we had such a protocol that it would be a useful tool to solve many of the juggling acts that transpire under the heading of "mobile networking" as well as providing a way to continue (or "resume") connectivity after IP address changes. (I will, of course, be suitably embarrassed if someone points out that work is already going on to do this.) draft-xie-stewart-sigtran-ddp-00.txt ned
Re: runumbering (was: Re: IPv6: Past mistakes repeated?)
Christian; But that architecture (hosts having multiple addresses representing a site's multiple aggregation prefixes and selecting among them) requires some method of identifying hosts when they switch from one address to another mid-connection. I would assume that what people have in mind for this are the mobility mechanisms? (The alternative is 8+8 or some variant, which I understand to be contentious enough that it is a defacto non-starter.) 8+8 is not strictly necessary here unless you use locally scoped addresses. As you can see, DNS reverse and, then, forward look up is working fine for IPv4 hosts to know all the addresses of other hosts with weak security. Mobility, which does not work when home is unreachable, is no rubust and, as is often the case with a psuedo multihoming proposal, does not satisfy people needing multihoming. To make mobility rubust, it is, instead, necessary to make mobile hosts multihomed. The rubbing point is that identifying is not quite enough -- you need "secure identifying" in order to avoid connection hijacking, probably through some variation of IPSEC. Which brings us back to NATs not being terribly helpful... Wrong. Use of complex and time consuming mechanisms such as IPSEC makes the system insecure vulnerable to DoS attacks. To avoid connection hijacking, cookies, such as TCP port and sequence numbers, is enough, if they are long enough. You may use optional IPSEC over it for extra security (it is more secure primarily because IPSEC keys are long cookies), but you don't need it. Masataka Ohta
Re: runumbering (was: Re: IPv6: Past mistakes repeated?)
Steve Bellovin; To avoid connection hijacking, cookies, such as TCP port and sequence numbers, is enough, if they are long enough. That's preposterous. Long-enough numbers are good *if* and only if there are no eavesdroppers present. "good *if* and only if"? With cookies, a network is as secure as a telephone or fax network, which is *GOOD* enough for credit card companies. On the other hand, complex key handling mechanism introduces a lot of chances for key eavesdropping. You may use optional IPSEC over it for extra security (it is more secure primarily because IPSEC keys are long cookies), but you don't need it. Nonsense. Agreed, because TCP port and sequence numbers are long enough. Masataka Ohta
RE: runumbering (was: Re: IPv6: Past mistakes repeated?)
Hi all, I guess this is somewhat unrelated to the thread's maing topic but the paper that Christian mentioned is available to everyone (as well as all papers from SIGCOMM since 91) through SIGCOMM's web site. The exact pointer for the paper mentioned below is http://www.acm.org/pubs/articles/proceedings/comm/115992/p53-tsuchiya/p53-tsuchiya.pdf regards, -andreas =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Andreas A. Terzis, | UCLA Computer Science Department http://irl.cs.ucla.edu/~terzis | Internet Research Lab On Wed, 26 Apr 2000, Christian Huitema wrote: I agree completely with what you say about needing to push the multi-address complexity to the host. As you kindly pointed out (and I self-servingly expand on here), this is an architecture I put forth about a decade ago in a sigcomm paper (in Zurich, I don't remember the year). The paper "Efficient and robust policy routing using multiple hierarchical addresses " was published at the 1991 SIGCOMM, in Zurich. ACM papers used to be available on line, but it seems that the ACM now wants to enforce pay per view. (http://www.acm.org/pubs/citations/proceedings/comm/115992/p53-tsuchiya/) There is related work on an "Extended Transmission Control Protocol" available at http://www.chem.ucla.edu/~beichuan/etcp/ But that architecture (hosts having multiple addresses representing a site's multiple aggregation prefixes and selecting among them) requires some method of identifying hosts when they switch from one address to another mid-connection. I would assume that what people have in mind for this are the mobility mechanisms? (The alternative is 8+8 or some variant, which I understand to be contentious enough that it is a defacto non-starter.) The rubbing point is that identifying is not quite enough -- you need "secure identifying" in order to avoid connection hijacking, probably through some variation of IPSEC. Which brings us back to NATs not being terribly helpful...
Re: runumbering (was: Re: IPv6: Past mistakes repeated?)
So what I am suggesting is that it seems that there is evidence that one can do an "association" protocol that is relatively lightweight in terms of machinery, packets, packet headers, and end-node state if one leaves the heavy lifting of reliability to the underlying TCP protocol. the on-the-wire protocol overhead is not that great. the computational overhead to the host and application, and the resulting loss in maximum bandwidth, are fairly expensive. I tend to disagree. An association protocol only really does its work on connect/reconnect - hopefully a rear event -- and when the application says "let's establish a work-mark here". no, that's not the bulk of the work. the bulk of the work is just in managing the extra copies of data (applications don't want to deal with this explicitly, they want it handled by lower layers), in detecting failures, distinguishing one kind of failure from another, and in recovery. for instance, to make the handoff efficient you want to have the ability to say to your peer "please contact me on this new address" and have it do so. but that message may be delayed and meanwhile some new data might have been sent your way. so the host that is moving might also arrange to have data which was sent to its old location forwarded to the new location for a time - this saves the burden of getting the peer to retransmit everything. but the "I'm moving" message might get dropped - this is actually likely because hosts don't usually know that they're moving and you have to assume that hosts that are mobile will be disconnected from time to time. so you still need a fallback way to find your peer's connections again - and this generally means some sort of resolution service for connection endpoints. and the resolution service probably also needs some redundancy. now realize that it's quite possible for two peers to be moving on the network at the same time, with their redirect messages crossing each other and/or being dropped. etc. there are a lot of states that have to be dealt with if you want the system to be both reliable and efficient. And given that many of our applications are bursty/transactional vehicles we're not talking about supercomputers transfering bulk files of simulation data. if you're talking about a general purpose facility then it probably does need to span a wide range of applications' needs. perhaps not supercomputers exchanging large matrices, but those are hardly the only applications that care about performance and bandwidth. even lowly web servers care about performance and bandwidth. basically it's a lot more efficient to do some variant of mobile IP. Mobility is not the issue. Rather, there is use, distinct from mobilty, for an association that can persever longer than the underlying transport(s), including changes of IP addresses. if you build a level of indirection to handle this then it had better handle mobility also. and we don't need the kind of facility you're talking about just to do renumbering. nor would such a facility be sufficient, because IP addresses are kept in other places besides just TCP connection state. In my eyes, an application that uses an association protocol to deal with changes and faults in underlying connectivity is a lot more in accord with end-to-end principles than if it relied on ad hoc transport/network address juggling. either approach is end-to-end. it's just that by putting this functionality above the transport layer you end up duplicating the functionality that was already implemented at lower layers, and you have to make the resulting system fairly complex before you gain much for your trouble. OTOH, by putting the mobility at the IP layer, you can let TCP take care of the sequencing etc. and you don't have to implement it again in a higher layer. Keith
Re: runumbering (was: Re: IPv6: Past mistakes repeated?)
draft-xie-stewart-sigtran-ddp-00 addresses redundancy and failover of sessions within a server pool, where uncoordinated failover of sessions from one endpoint to another is a requirement. There is signifcant overheard and indirection added to the session to achieve this. We seem to be discussing a simpler requirement: coordinated movement of a session from one ip:port pair on a single endpoint to a different ip:port pair on the same endpoint. Windows, buffer states, sequence numbers, etc. could all remain the same. The stated requirement was "an association that will outlast the TCP connections it is based on". I saw (and see) nothing that limited this to coordinated moves set up in advance. You're right that it's a simpler problem, but the general problem is what's on the table IMO. And if ISO session layer is seen as comparable, we're *definitely* in the more general problem space. (Although whether or not ISO session layer actually solved such problems is another matter -- it sorta did on paper if you read the specifications optimistically, but it never solved any of these problems in practice. And I have the misfortunate of having had to deal with ISO session layer stuff a *lot*.) Ned
RE: runumbering (was: Re: IPv6: Past mistakes repeated?)
Now consider the NATv6 alternative. The average net admin is already comfortable with NAT at the ISP boundary (hell, some even like it). She will already be running NAT, if for no other reason than to deal with IPv4-IPv6 transition. NATv6 is much less onerous than NATv4, because the address mapping is one to one (and in fact is probably a simple prefix rewriting, not a large table lookup), not many to one like with IPv4. What's more, NATv6 will give you some rudimentary form of multihoming (can advertise different prefixes at different ISPs)! I think your description is somewhat biased, Paul. Suppose that you execute the strategy you describe, and that the address 10.3.2.1, that was mapped to 129.87.64.32, gets transparently remapped to 130.123.45.67. It seems to me that you are going to loose all existing TCP connections, just like with any other form of renumbering. Suppose then that the external prefix of your site, 129.87.64.0/25, was used in the firewall access control lists of your business partners. Well, unless these partners somehow reprogram their firewall, the packets sourced from 130.123.45.67 are not going to get through. What? Numeric addresses in ACL is bad? Come on -- if none were used, if we only used DNS names, then renumbering would not be the problem that it is known to be! Besides, do you believe that using a NAT rather than plain renumbering would make your external DNS records to upgrade any sooner? Suppose now that you want to use NAT for multihoming. Suppose then that I really care that my TCP connection survives when I loose contact with ISP-A, the one that provided me with the prefix 129.87.64.0/25. Can I just go on routing the packets through ISP-B, that provides me with the address 130.123.45.0/25? Well, you can source them, but not receiving them, unless you convince ISP-B to announce your other /25 prefix in its BGP tables -- just like the old fashion no-NAT multihoming. And then, how exactly do you tell your customers that, among the two IP addresses of your web site, they should really use 130.123.45.3, not 129.87.64.5? Turn it any way you want, TCP sessions can only survive renumbering through end to end mechanisms, in effect some form of TCP-NG, and effective multihoming requires either a single address prefix supported by multiple ISPs, or end to end smartness to pick the best of N addresses (hey, we could use *your* work for that!) As Steve pointed out, trying to convince your ISP to announce random non topological prefixes will get you laughed out of court. There is, in fact, no alternative to end-to-end smartness -- the smarter your end systems, the more likely they are to use the network correctly. Now, if your systems are smart and now how to choose one of many available addresses, then we have a solution with v6 multi-homing -- the support of multiple prefixes per site, multiple addresses per interface.
Re: runumbering (was: Re: IPv6: Past mistakes repeated?)
% Turn it any way you want, TCP sessions can only survive renumbering through % end to end mechanisms... % % Which raises the interesting (to me anyway) question: Is there value in % considering a new protocol, layered on top of TCP, but beneath new % applications, that provides an "association" the life of which transcends % the TCP transports upon which it is constructed? % % I believe that if we had such a protocol that it would be a useful tool to % solve many of the juggling acts that transpire under the heading of % "mobile networking" as well as providing a way to continue (or % "resume") connectivity after IP address changes. % % (I will, of course, be suitably embarrassed if someone points out that % work is already going on to do this.) % % --karl-- The most visable one was implemented at UCLA in 1996. Built using a per-session 32bit sequence. My idea was to use the DNS lable instead of a fixed 32bit number. A bit harder... :) --bill
Re: runumbering (was: Re: IPv6: Past mistakes repeated?)
Which raises the interesting (to me anyway) question: Is there value in considering a new protocol, layered on top of TCP, but beneath new applications, that provides an "association" the life of which transcends the TCP transports upon which it is constructed? been there, done that. yes, it is valuable. but it is expensive in terms of the amount of protocol overhead and support that you need to make it work reliably in the face of various failures. and it can be slow to recover from such failures. for instance, you have to build your own data acks on top of TCP, because if the other end of a connection changes IP addresses you cannot assume that any data already acknowledged at the TCP level was actually received by the application at the other end...and you therefore have to keep track of data that is unacknowleged by the other end in case you have to resynchronize. and you need above-TCP keepalives and redirects. and you need a separate mechanism to keep track of the current IP address and port number for each of your connection endpoints... and which gets updated independently (in case your connection with a peer drops before it has a chance to tell you where it's moving to) this separate mechanism has its own failure modes, and parts of that mechanism might also be mobile. if you had to build mobility entirely at the above-tcp level this might be a useful approach. but there are better ways to implement mobile networking. Keith
Re: runumbering (was: Re: IPv6: Past mistakes repeated?)
Which raises the interesting (to me anyway) question: Is there value in considering a new protocol, layered on top of TCP, but beneath new applications, that provides an "association" the life of which transcends the TCP transports upon which it is constructed? been there, done that. yes, it is valuable. but it is expensive in terms of the amount of protocol overhead and support that you need to make it work reliably in the face of various failures. and it can be slow to recover from such failures. for instance, you have to build your own data acks on top of TCP, There is a protocol design that did this, but we tend to shield our eyes when we look that way - OSI Session layer. It was a hideous thing indeed to read on paper and way overburdened with options. But when one got down to the wire, the actual protocol traffic was small. It didn't try to do any kind of reliability or sequencing or even sensing that a transport had died. Rather it maintained a sequence of restart points - and it was only at those points (which were triggered by the application saying "mark this point") that there were things that could be called "acks". So what I am suggesting is that it seems that there is evidence that one can do an "association" protocol that is relatively lightweight in terms of machinery, packets, packet headers, and end-node state if one leaves the heavy lifting of reliability to the underlying TCP protocol. I bet Marshall Rose has some good comments on this as he actually went and did some of this. (By-the-way, I'm not in any way suggesting OSI Session, I'm only trying to learn from the past.) --karl--
