Re: interception proxies
Dick, Quoted from RFC791, the IP specification, in the section on loose source routing, page 19 [emphasis added]: If the address in destination address field has been reached and the pointer is not greater than the length, the next address in the source route replaces the address in the destination address field, and the recorded route address REPLACES THE SOURCE ADDRESS just used, and pointer is increased by four. You have misread the specification. That "source" is not (IP Header) "Source Address" that you imply, but the "source" mentioned earlier in the sentence, i.e., "address in the source route" (option). The IP Header Source Address is not changed by the source routing options. (Nor in the case of IPv6 style source routing.) [If you think about it, the interpretation you emphasized above will not result in a capability for bi-directional communication.] Charlie
Re: interception proxies
Dick St.Peters says: Quoted from RFC791, the IP specification, in the section on loose source routing, page 19 [emphasis added]: If the address in destination address field has been reached and the pointer is not greater than the length, the next address in the source route replaces the address in the destination address field, and the recorded route address REPLACES THE SOURCE ADDRESS just used, and pointer is increased by four. ... An end-to-end-inviolate source address is not a required part of the IP spec. If you look upward two paragraphs from the part you quoted, you'll see that "source address" does not mean the first address in the fixed part of the IP header, but the address in the "route data" provided by the source. __ Matt Crawford[EMAIL PROTECTED] Fermilab "A5.1.5.2.7.1. Remove all classified and CCI boards from the COMSEC equipment, thoroughly smash them with a hammer or an ax, and scatter the pieces."
Re: interception proxies
On Wed, 12 Apr 2000, Dick St.Peters wrote: Quoted from RFC791, the IP specification, in the section on loose source routing, page 19 [emphasis added]: If the address in destination address field has been reached and the pointer is not greater than the length, the next address in the source route replaces the address in the destination address field, and the recorded route address REPLACES THE SOURCE ADDRESS just used, and pointer is increased by four. The recorded route address is the internet module's own internet address as known in the environment into which this datagram is being forwarded. An end-to-end-inviolate source address is not a required part of the IP spec. The authors of the standard had the vision to foresee that rewriting the source address might be desireable under some circumstances. They were off target about when this might be used, but they designed a protocol flexible enough to encompass things they could not foresee. I think you have misunderstood what the RFC intended to say. The "source address" being replaced is the entry in the LSRR option that is being written into the destination field, not the source address in the IP header, which is supposed to remain constant throughout its journey. Anyway, a source route option was intended to be something that the originating host puts into the datagram, and so the destination address rewriting that does happen is being done by explicit request of the originating host. That's quite different from what an interception proxy does, isn't it? C. M. Heard [EMAIL PROTECTED]
Cable as Firewall?!
I'm at the end of all my knowledge and I can't find any explaination for the following issue. So I hope anyone of you Network Guru's can give me an idea why this would happen. I have this scenario in a Network: A couple of PC's are connected to a 3300 Switch made by 3COM which are connected using 3 metres long TP (normal CAT5) cables. The stations have diffrent OS'es like Linux and Novell Netware. However the problem seems to be the cable not the operating systems. I use diffrent protocols over this network to establish a communication, like IPX and of course TCP/IP. Now the weird thing is if I use one cable, IPX data comes through, but no TCP/IP traffic. If I exchange the cables again, both TCP/IP and IPX work. I tried with tcpdump (filtering UDP and diffrent ethernet protocols), but I only get IPX through with this cable! I used diffrent stuff to test this cable, like fluke 2000 dsp pro and fluke 1000 dsp and a lot of diffrent volt/ohm testers. The cable seems to function ok. I tried other switches such as 3COM 3300, HP pro curve 4000, DLink 10/100, but I only get IPX through with that cable. This cable doesn't have a chip and ethernet is ethernet, no? I would really like to know what makes this cable diffrent. Its not the operating systems since I tried some Windows and other Netware 4.x server too. Both only get IPX through it. How can a cable filter specific ethernet protocols? Best Regards, Thomas Kuiper Thomas Kuiper| [EMAIL PROTECTED] | www.tobit.com __ Core Development | TK3680-RIPE | /__/\ Tobit Software | ICQ #8345483| ask your server. \__\/
Re: interception proxies
From: "Dick St.Peters" [EMAIL PROTECTED] The authors of the standard had the vision to foresee ... they designed a protocol flexible enough to encompass things they could not foresee. Pardon me if I emit a "balderdash". There's this tendency to act like IPv4 was handed down on stone tablets by Athena, the Goddess of Wisdom, herself - and I want to stamp it out. *I was there*, and trust me, it wasn't a much (any?) different case of sausage production than the average standard today. (Trivia question: what's the connection between 32-bit IP addresses and the number of registers available at interrupt time in Tenex?) They had great foresight, huh? The foresight to see the need for more address bits (funnily enough, IP2.5 *had* this, and they *ripped it out* - great vision there), traffic flows, etc (I could go on but what's the point). Yes, IPv4 had some good ideas, ideas that have turned out well. It also has some woeful deficiencies. (In some cases these are deficiencies that not even Einstein could have forseen, so don't get me wrong, I'm not trying to throw rocks about them.) However, let's not mythologize anything, OK? It gets in the way of objective analysis. Noel
Re: breaking the IP model (or not)
At 04:12 PM 4/10/00 -0400, Keith Moore wrote: it's completely natural that people will try such approaches - they are trying to address real problems and they want quick solutions to those problems. but if the quick fix solutions get entrenched then they cause their own set of problems which are worse then the original problems. this is not progress. IMHO we need to see these things for what they are: - quick fixes with limited applicability and future - indicators that there is an important problem that needs to be solved in a technically sound fashion Agreed completely ... but this still doesn't lead to your conclusion. Suppose we had suppressed every kludge that's come up since we started working on a new Internet design as a group? Let me see, ROAD gave their report, where they recommended CLNP, in Santa Fe, right? That was (let me look at the back of my shirt a second ...) in 1991. OK, OK, I'm being a bit extreme but the point is that just because something is architecturally bad doesn't mean you shouldn't do it, since these days it takes us years to make any architectural enhancements. Peter Deutsch is right: let the work go forward and *in addition* be sure you document very well what its limitations are. Stick that documentation in the same RFCs whenever possible. ...Scott __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
Re: breaking the IP model (or not)
I'm being a bit extreme but the point is that just because something is architecturally bad doesn't mean you shouldn't do it, since these days it takes us years to make any architectural enhancements. perhaps architectural impurity alone shouldn't keep you from doing something, but the fact that something violates fundamental design assumptions should cause you to do some analysis and hard thinking about the likely consequences of using them. and if you are in the business of selling boxes that violate the design assumptions you shouldn't misrepresent these to your customers. most of these hacks can be employed in ways that are mostly harmless, but knowing when they are harmless and when they will cause harm can be quite difficult. NATs seemed mostly harmless when they were first deployed; now they're a huge problem. Keith
Re: interception proxies
Charles Lynn writes: You have misread the specification. That "source" is not (IP Header) "Source Address" that you imply, but the "source" mentioned earlier in the sentence, i.e., "address in the source route" (option). Apparently so - though given that the part I emphasized immediately follows mention of rewriting the destination address, this isn't obvious. [If you think about it, the interpretation you emphasized above will not result in a capability for bi-directional communication.] Actually, I've always thought that the first recorded-route address was the original source address so the route would indeed be reversible, but I'll admit to never having actually seen a recorded route. J. Noel Chiappa writes: Pardon me if I emit a "balderdash". ... They had great foresight, huh? The foresight to see the need for more address bits (funnily enough, IP2.5 *had* this, and they *ripped it out* - great vision there), traffic flows, etc (I could go on but what's the point). Yes, just what was your point? However, let's not mythologize anything, OK? It gets in the way of objective analysis. Actually, the view that everything about IP was cast in stone forever in the IP spec is exactly the view that is being argued about. Would you settle for "The IP spec authors didn't have enough foresight to foresee a need to rewrite source addresses" ? :) Whatever anyone thinks of it, people are doing it. On the right are people saying it is immoral, evil, and dangerous, not to mention prohibited by the gods, and they refuse to talk about it. On the left are people doing it, each their own way because there is no standard and not even any public discussion. Only a few months after I first used the net, IP replaced NCP, giving me an instant impression that network protocols are ephemeral things, replaceable if they don't measure up. Presumably if they can be replaced, they can be adapted when necessary. -- Dick St.Peters, [EMAIL PROTECTED]
Re: interception proxies
where did the wrec folks get the idea that the IP specification was obsolete? (speaking not for the entire WREC, but my impression of the meetings) I did get the impression (mistakenly or not) that addressing the whole of the IP spec was not particularly in scope (e.g., from our area director, who discussed scope at nearly every meeting). I would agree on that point ... but as long as wrec recognizes (correctly) that revising IP is not within its purview then it also seems reasonable for wrec to assume that things that violate IP are of dubious value. Keith
Re: breaking the IP model (or not)
--- Keith Moore [EMAIL PROTECTED] wrote: I'm being a bit extreme but the point is that just because something is architecturally bad doesn't mean you shouldn't do it, since these days it takes us years to make any architectural enhancements. perhaps architectural impurity alone shouldn't keep you from doing something, but the fact that something violates fundamental design assumptions should cause you to do some analysis and hard thinking about the likely consequences of using them. and if you are in the business of selling boxes that violate the design assumptions you shouldn't misrepresent these to your customers. most of these hacks can be employed in ways that are mostly harmless, but knowing when they are harmless and when they will cause harm can be quite difficult. NATs seemed mostly harmless when they were first deployed; now they're a huge problem. Hmm... Depends on one's perspective. Do not underestimate the timeliness of a solution. Timeliness is operational reality. It could have been catastrphic had we not had a timely solution with no addresses to issue. NAT is the reason we have had this much time to work on IPng. Keith regards, suresh = __ Do You Yahoo!? Send online invitations with Yahoo! Invites. http://invites.yahoo.com
Mail to ervjb Returned
The following message is being returned unread. The message is addressed properly but the addressee has not accessed their mailbox for at least 4 days ** ** Message To: [EMAIL PROTECTED] (Joakim Bergstrom) ** ** Unread Message Follows: ** From: [EMAIL PROTECTED] Subject: Re: recommendation against publication of draft-cerpa-necp-02.txt Date: Sat, 9 Apr 2000 12:10:53 -0700 Reply-To: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED] Peter Deutsch in Mountain View wrote: [in part you said] I still object to your notion that it's not censorship since people can always go elsewhere. Where does this lead? I see the day when people can't publish a new directory service protocol because "The IETF has endorsed LDAP for directory services", or would ban the publication of an extension to DNS because "it must prevent the misuse of the protocol in creating inappropriate services". One by one, you'd be chasing innovation to other foums. "Danger, Will Robinson! Danger!" The above information is nonsense. You seem to be objecting to Keith's right to object to the draft as it is written. So using your logic (As I understand what you are saying above) - you are also guilty of censorship by not wanting Keith to object. I understand you frustration as many of us in the IETF have been frustrated from time to time. If you want to convince me and others then please ignore anything you feel is a non-technical issue. And address the technical issues. Many in the IETF *are* swayed by technical content. I am undecided on this issue and I am personally glad to see this debate. I do find it an important discussion when it remains technical. Questions I have: Does this solve a problem that is not already solved by another method? Not that it has to be unique as you point out above, but if you could compare it against other known solutions (if any) then perhaps its advantages (that I have not seen yet) could help you cause? TRUNCATED BY ERV_IMS.
Re: breaking the IP model (or not)
Hmm... Depends on one's perspective. Do not underestimate the timeliness of a solution. Timeliness is operational reality. I'm very much aware of this. timelinesss is what gives you (or denies you) the opportunity to deploy a new technology. but just because something is timely (in the sense that there is an opportunity to deploy it) does not mean that deploying it leaves the world in a better place. It could have been catastrphic had we not had a timely solution with no addresses to issue. NAT is the reason we have had this much time to work on IPng. it's not at all clear whether NAT provided additional time for IPng development or whether such time was really needed. IPv6 was largely developed before NAT enjoyed significant deployment, and arguably NAT has delayed adoption of IPv6. and because of the NAT deployment it is now somewhat "untimely" to deploy applications like IP telephony. whereas if IPv6 had been adopted a bit earlier (because NAT had not filled the vacuum, so to speak) IP telephony would work just fine with it. of course, IPv6 might have moved along slowly even without NAT. but it would probably have moved faster had NATs not existed. best thing I can say about NAT is that it motivated me to work on 6to4. Keith
Re: breaking the IP model (or not)
At 01:27 PM 4/12/00 -0400, Keith Moore wrote: I'm being a bit extreme but the point is that just because something is architecturally bad doesn't mean you shouldn't do it, since these days it takes us years to make any architectural enhancements. perhaps architectural impurity alone shouldn't keep you from doing something, but the fact that something violates fundamental design assumptions should cause you to do some analysis and hard thinking about the likely consequences of using them. Yes. So why don't we have a new design which decouples all the meanings for an IP "address"? and if you are in the business of selling boxes that violate the design assumptions you shouldn't misrepresent these to your customers. Sounds like we have some agreement on the list. most of these hacks can be employed in ways that are mostly harmless, but knowing when they are harmless and when they will cause harm can be quite difficult. There is precedent for the IESG getting draft authors to include caveats and limitations. NATs seemed mostly harmless when they were first deployed; now they're a huge problem. Just wait until mobile IP-based "phones" take off! ...Scott __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
eating our own dogfood
rip.psg.com:/usr/home/randy/mp3/neil_young nslookup ietf.org. Server: cache.psg.com Address: 147.28.0.3 *** No address (A) records available for ietf.org. rip.psg.com:/usr/home/randy/mp3/neil_young ns ietf.org. Default Server: cache.psg.com Address: 147.28.0.3 Server: cache.psg.com Address: 147.28.0.3 Non-authoritative answer: ietf.orgnameserver = ns.ietf.org ietf.orgnameserver = ns.CNRI.Reston.VA.US Authoritative answers can be found from: ns.ietf.org internet address = 132.151.1.19 ns.CNRI.Reston.VA.USinternet address = 132.151.1.1 rfc2182 ignored, both servers on same backbone, probably in same site. dns hosed, ietf.org was an A RR just a few hours ago. randy
Re: interception proxies
] From: "Dick St.Peters" [EMAIL PROTECTED] ] ... ] Actually, I've always thought that the first recorded-route address ] was the original source address so the route would indeed be ] reversible, but I'll admit to never having actually seen a recorded ] route. ... Try `ping -R` between reasonable UNIX boxes on a private network, and either use something like dbx or gdb to look at the bits that `ping` gets or use tcpdump or similar to see the bits on the wire. From: Salvador Vidal [EMAIL PROTECTED] ... There are also good uses for interception, I think that ONGs, churchs, and other organizations and people will want to become Internet trusters soon, ... I'm not talking about the computers inside a organization, but people computers anywhere that trust in these organizations or persons to do censor, ranking to do their purchases decisions or whatever they want!, and probabily some people want to have more than one truster and balance them. ... So please, which will be the right tool for a truster service? Please read the two WREC drafts to discover the technical meaning of "interception proxy." Interception proxies are useless in the circumstances you care about. An interception proxy can affect only traffic directed to it by a router in the path between IP peers (e.g. HTTP client and server). Your "computers anywhere" won't be using the very few routers that would intercept traffic for your trustors and send it to your trustees. I'm reminded of statements during the wiretapping dicussions that imagined the Internet as a big phone system using a single CO in a room somewhere in the The Netherlands. That seems to be like the problem here. An explicit proxy is the right tool for part of your goal. Simply build proxies that filters according to your taste, and then configure the HTTP browsers of trusting people to use your proxies. That solution has a characteristic that is either a fatal flaw or an enormous virtue, depending on your philosphy. It is that using or ignoring your proxy would be the choice of the people in charge of the client computers instead of those in charge of the proxies. For the rest of your goal, the parts that involve balancing evaluations and choosing whom to trust, interception proxies are tools for the opposite notions. They are tools for authoritarian censoring, and that is intrinsically opposed to people making their choices in trust, ranking, balancing and so forth. I also think you need to give up the idea of having computers make value judgements, but maybe that's just my lack of imagination. Vernon Schryver[EMAIL PROTECTED]
Re: breaking the IP model (or not)
On Wed, 12 Apr 2000 17:02:28 PDT, Pyda Srisuresh said: --- Keith Moore [EMAIL PROTECTED] wrote: can be quite difficult. NATs seemed mostly harmless when they were first deployed; now they're a huge problem. Hmm... Depends on one's perspective. Do not underestimate the timeliness of a solution. Timeliness is operational reality. I think Keith meant "huge problem" in the same sense that a kidney dialysis machine is a huge problem. They keep the patient alive, but never in the greatest of health or comfort. Valdis Kletnieks Operating Systems Analyst Virginia Tech
Re: Source address (offtopic)
On Wed, 12 Apr 2000 23:21:18 +0200, Harald Tveit Alvestrand said: The source address of a datagram was an architectural mistake, and should never have been in the mandatory packet format. OK, I'll bite - either I'm missing something, or it's 11 days past the traditional time for such statements. If the source address wasn't in the mandatory packet, what would we use for the 4-tuple identifying a connection? On Wed, 12 Apr 2000 17:07:50 CDT, Matt Crawford said: Nahh, the mistake was ignoring the source address when routing forwarding. I may be dense, but I don't remember seeing an absolute prohibition against checking the source address. Otherwise, RFC2267 on Network Ingress Filtering would be in violation all over the place Valdis Kletnieks Operating Systems Analyst Virginia Tech
Re: interception proxies
On Wed, 12 Apr 2000 21:48:28 MDT, Vernon Schryver [EMAIL PROTECTED] said: circumstances you care about. An interception proxy can affect only traffic directed to it by a router in the path between IP peers (e.g. HTTP client and server). Your "computers anywhere" won't be using the very few routers that would intercept traffic for your trustors and send it to your trustees. Well.. as long as you are very careful to define "computers anywhere" to specifically not be co-located at MAE-East or other similar peering location where they'd be on a whoe LOT of paths between IP peers. Valdis Kletnieks Operating Systems Analyst Virginia Tech
