chm@nbires.nbi.com (Paul Chmielewski) (02/03/89)
We're in the process of putting together an IP-over-X.25 package for our 4.3 derivative UNIX systems. We currently have an intelligent communications card (VME bus) on which we run X.25. The UNIX kernel and networking subsystem are pretty much straight from BSD4.3. We plan to write a network interface driver to interface with the X.25 code. I'm interested in hearing from people who have already done this or something similiar. I'd like to hear about problems you ran into, what type of performance to expect, or what documentation you found useful. I've read RFC 877, but it doesn't seem to address all of the issues. I do have one specific question concerning the internet address to virtual circuit pairings. Is there a standard mechanism for telling the called end of a virtual circuit what the internet address of the calling host is? I'm thinking that each X.25 VC or PVC will be configured as a point-to-point link. The machine initiating the call can fairly easily map the pt-to-pt IP addresses to the virtual circuit. But I'm not sure how the machine accepting the call would do this. One possibility would be to include the initiating machines IP address in the Call User Data Field after the protocol demultiplexing octet. Any comments?? Paul Chmielewski NBI Inc., Boulder, CO chm@nbires.UUCP or chm@nbires.NBI.COM (303) 938-2926
barns@GATEWAY.MITRE.ORG (Bill Barns) (02/04/89)
Paul, If you have not made the acquaintance of the Defense Data Network (DDN) X.25 Standard Service, it would probably be a good idea to do so. It will NOT answer your immediate question, but considering the type of product you are developing, it seems to me that it would be rather silly not to support the DDN Standard Service as a configuration option. That may be the largest single market for IP over X.25. I will not describe it in detail as there are documents for that, but very briefly, it uses an algorithmic transformation between IP addresses and X.121 addresses. This transformation has some limitations which make it undesirable or unusable in many other situations, but it seems like it would be worth implementing, or at least leaving hooks for. DDN Standard X.25 has a couple of other twists which involve network-specific X.25 facilities at SVC initiation, as well as the CUD which is essentially as described in the RFC. Also, it imposes some implicit restrictions on the assignment of IP datagrams to X.25 VCs, so that Precedence will work. If you code it right to start with, the extra work is minimal; retrofitting may or may not be easy, "depending." The common method of address handling (that I know of) involves keeping static address mapping tables in all the X.25 endpoints involved. These tables associate IP addresses with X.121 DTE addresses. This method has the advantage of providing the basis for some security checking. Since the static configuration table lists all the DTE's that are expected to call and talk IP with you, you can clear calls from impostors. You would also have the IP layer do its routing based on this information, which prevents a legitimate DTE address from acquiring packets destined to an IP address properly belonging to some other DTE. The utility of this depends on the validity of the DTE address, but there is some validation of this in most public data networks, I believe. I would certainly want such a feature to be available in any box that I used on a public data network in this way. Send mail if you would like to chat about this further... this seems like enough for the public wire. Bill Barns / MITRE-Washington / barns@gateway.mitre.org
CERF@A.ISI.EDU (02/04/89)
Paul, After the VC is established, the first packet over the link is an IP packet containing source/destination IP addresses and, probably, a TCP SYN packet or a UDP packet. Won't the Source/Dest address in the first IP packet be sufficient or have I missed some initialization problem on the receiving end? Vint Cerf
art@SAGE.ACC.COM (02/05/89)
>Paul, >After the VC is established, the first packet over the link is an IP >packet containing source/destination IP addresses and, probably, a TCP >SYN packet or a UDP packet. Won't the Source/Dest address in the >first IP packet be sufficient or have I missed some initialization >problem on the receiving end? > >Vint Cerf Vint, Unfortunately, the Source address in the IP packet may have little relation to the X.121 address at the other end of the VC. If there is at least one gateway between the local machine and the remote machine, the virtual circuit really exists as a logical level 2 connection between the local machine and gateway. It's probably better to translate from the X.121 calling address to an associated IP address. The IETF Performance Working Group has been working on a paper that covers, amoung other things, issues around SVC management for IP over X.25. +-----------------------------------------------------------------------+ | Art Berggreen Advanced Computer Communications | | <art@sage.acc.com> Santa Barbara Street | | (805)963-9431 Santa Barbara, CA 93101 | +-----------------------------------------------------------------------+
kre@cs.mu.oz.au (Robert Elz) (02/06/89)
In article <220@cutter.nbi.com>, chm@nbires.nbi.com (Paul Chmielewski) writes: > Is there a standard mechanism for telling the called end > of a virtual circuit what the internet address of the calling host is? I doubt that looking at the address on the first datagram is the right way, that may have come from anywhere, and just happens to be being routed through this X.25 connection (the calling site may have restrictions on for whom it will forward datagrams over x.25, but then again, it also might not). A useful question might be "Do you care?" I think not, datagrams arrive over the link, they carry source addresses, the address of the particular site at the other end of the link shouldn't matter much. When you come to sending out a datagram, you need (somehow) to translate the IP address to a DTE address - you have to be able to do this to cope with the case where your end initiates the connection anyway. Its likely that this translation will produce the same DTE address as was in the "calling address" x.25 field in the initial call packet. In that case, you can send your datagram(s) back out over this same call (if its still active). kre
keith@SPIDER.CO.UK (Keith Mitchell) (02/07/89)
I am nearing completion of a Unix V.3 STREAMS-based implementation of IP over X.25, which is part of our SpiderTCP and SpiderX.25 protocol software products. We call it IXE (IP/X.25 Encapsulation). It fits into the STREAMS protocol stack as a multiplexing driver underneath IP and above our X.25 stack. It conforms fully to the rather skimpy RFC 877 spec, and although at present it will only work with CCITT-flavour X.25 PDNs, DDN support is on the way. (CCITT is a lot more in demand in Europe than DDN, obviously). On the other hand, it *does* work with both the 1980 and 1984 flavours of X.25. Clearing down of idle X.25 calls and pre-emption of these when resources are scarce are implemented. Address mapping for this stuff is something of an issue. At present we use a lookup table, which is the only way of really doing the job, but if you have a lot of WAN destinations to talk to then there is a danger of guzzling up lots of kernel memory. Some kind of address resolution protocol would be nice, but another way to look at it is from a security point of view. If you are connected to a public network, then anyone could call you up and claim to be some host with a remote IP address that higher- level software trusts. This leaves you wide open to spoofing by Public Data Network hackers. On the other hand, PDNs are usually set up so you can trust the X.25 calling address, so we use this to look back into the table and check that the remote IP host is who it claims to be. Using the CUDF field for address resolution does not seem like a good idea to me. I would prefer the use of X.25 facilities for this, most specifically the extended addressing one of X.25(1984). When used for the ISO CONS, this carries an NSAP. It is interesting to note that a scheme for encoding IP addresses into NSAPs already exists (RFC 986), at least for the connection-less world. Some scheme along these lines would thus bypass the need for table lookup, and I think is probably the right approach. (Again you have to trust the address you get from the PDN). It strikes me that generally RFC 877 leaves a lot of issues unanswered, and the introduction of the 1984 (and now 1988) standards for X.25 have aggravated this. Is is perhaps time for a new standard in this area ? Any such work probably ought to take into account using ISO IP (or CLNP) over X.25 circuits as well. Does anyone have any thoughts on this ? Keith Mitchell Spider Systems Ltd. Spider Systems Inc. 65 Bonnington Road 12 New England Executive Park Edinburgh, Scotland Burlington, MA 01803 +44 31-554 9424 +1 (617) 270-3510 keith@spider.co.uk keith%spider.co.uk@uunet.uu.net keith@uk.co.spider ...!uunet!ukc!spider!keith
smb@ulysses.homer.nj.att.com (Steven M. Bellovin) (02/08/89)
In article <8902071459.AA22881@redrump.spider.co.uk>, keith@SPIDER.CO.UK (Keith Mitchell) writes: > Address mapping for this stuff is something of an issue. At present > we use a lookup table, which is the only way of really doing the > job, but if you have a lot of WAN destinations to talk to then there > is a danger of guzzling up lots of kernel memory. I have an implementation of IP over Datakit(r) VCS circuits that I did for 4.3bsd; I had the same problems. One thing I did was to do call setup from user-level. If a circuit to a destination is needed, but none is available, the IP address is passed to a daemon process; this process looks up the dialstring, makes the call, and hands the circuit back to the dkip driver. Because I'm using a user-level process, the mappings can reside in a file. The problem, though, is that *lots* of IP drivers need this sort of lookup, especially for wide-area non-broadcast nets. Dkip has one version, assorted X.25 implementations have their own, dial-up SLIP needs analogous data, etc. Perhaps we can find some way to store the information via the Domain Name System. What we'd need, more or less, is a new record type PHYSADDR in class IN; its data field would contain a type code (Datakit VCS, X.25, etc., and a type-dependent set of dialing instructions. The inverse mapping, or -- more likely -- the equivalent to the INADDR.ARPA records would be useful as well, for validation of incoming calls. I'm not entirely happy with this idea, though; the format of the dialing instructions is rather too variable for a single record type. But the PHYSADDR record needs to be tied to the IN class, since IP is the primary client for the information. Suggestions, anyone? --Steve Bellovin smb@ulysses.att.com
dyer@spdcc.COM (Steve Dyer) (02/08/89)
In article <11194@ulysses.homer.nj.att.com> smb@ulysses.homer.nj.att.com (Steven M. Bellovin) writes: >Perhaps we can find some way to store the information via the >Domain Name System. What we'd need, more or less, is a new record type >PHYSADDR in class IN; its data field would contain a type code (Datakit VCS, >X.25, etc., and a type-dependent set of dialing instructions. The inverse >mapping, or -- more likely -- the equivalent to the INADDR.ARPA records would >be useful as well, for validation of incoming calls. > >I'm not entirely happy with this idea, though; the format of the dialing >instructions is rather too variable for a single record type. But the >PHYSADDR record needs to be tied to the IN class, since IP is the primary >client for the information. Suggestions, anyone? If you can live without the IN class, the Hesiod nameserver mods to BIND we made at MIT would seem to be just what you want. It essentially uses class HS, type TXT for its resource records. The TXT type is just free-form ASCII text, and further qualification ("typing") is done with a second string, the HesiodNameType, which when concatenated with the name of the object to be resolved, is passed by the Hesiod calls to the DNS. Since there was no way to predict what data Hesiod would be carrying in the future, we decided against defining new RR types, preferring to encode this in the domain names of the RRs. char **cp; e.g., cp = hes_resolve(hostname-or-ip-addr-as-octet-string, "physaddr"); /* Now cp == NULL */ /* or cp[0], cp[1], cp[N-1] contain strings and cp[N] == NULL */ cp[0] == "x25 some-long-ISO-addr", etc. You get the idea. In our use of Hesiod within Athena, we quite commonly return strings of the form TYPE strings-meaningful-for-said-TYPE and application which use Hesiod know about the structure of the strings for a particular HesiodNameType. If you want to examine Hesiod, it can be retrieved as pub/hesiod.tar.Z from athena-dist.mit.edu. -- Steve Dyer dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer dyer@arktouros.mit.edu
barns@GATEWAY.MITRE.ORG (Bill Barns) (02/09/89)
From offline sources I gather that some people were confused about what
the X.121/IP address mapping discussion really meant. Here is an
attempt at an explanation. After that, I have some remarks on the NSAP
vs. IP issue.
The point of an X.121/IP address mapping table is to enable mapping in
the IP -> X.121 direction, not the other way around. This is needed to
identify or create an appropriate X.25 virtual circuit to carry an IP
datagram through an X.25 subnet to its destination or an appropriate
gateway. The reverse mapping turns out not to be a very useful thing,
and thus is not really an issue.
It also happens that the list of X.121 addresses appearing in the
mapping table can be used for a rough validation of the legitimacy of
an incoming X.25 call. In general, however, it is not possible to use
the reverse mapping X.121 -> IP to validate the IP addresses contained
in datagrams arriving over an X.25 VC whose other end is an X.121
address in the table. Although the entity on the other end of the X.25
VC has an IP address, it does not necessarily follow that datagrams
received from the other end will have that particular IP address as the
IP source address.
There are three main reasons why the address might be different.
(1) The other end of the X.25 VC is an IP gateway (router). In
this situation there will be many IP source addresses appearing in the
datagrams arriving on that VC, and the IP address of the gateway itself
will not usually appear in those datagrams.
(2) Source routing is being used. In this case, the IP source
address might be anything, and the address of the gateway at the far
end of the VC will generally appear in the option, but this is not
assured.
(3) The device at the other end is claiming an inappropriate IP
address.
The idea of checking each datagram's IP source address and the X.121
address of the other end of the X.25 VC on which it arrived against the
static table to detect spoofing is meant to deal with (3) above, but it
causes legitimate actions (1) and (2) to fail. The functions (1) and
(2) are part of the normal IP definition and one ought not to break
these things unless there are particularly strong reasons to do so in a
specific limited usage environment.
One might try to cope with (1) by maintaining some knowledge of
legitimate backside network numbers for such gateways, but this
requires a more elaborate static table and tends to be impractical if
the backside has backdoors into other parts of the Internet.
If you distinguish between non-gateways and gateways in the static
table, it would be possible to use logic to cope with case (2) for
the non-gateways. This would require checking for source routing
options. This can work because the non-gateway is either the source
or has to have been named explicitly in the source route, in order
for a properly functioning gateway to have sent it the packet in the
first place. (This logic doesn't hold for gateways because gateways
may have been routed to because of extrinsically derived information at
the prior hop.)
For the gateway case, security protection against unauthorized use of a
network (remember that the X.25 VC is a network/subnet in the IP sense)
can be implemented separately from VC management and X.121 address
mapping, and this is a nice feature to have. It does not make sense to
shut down an X.25 VC to a gateway because an unauthorized party (or
someone impersonating one) has sent a datagram through it. If you do
this, you make it easy for troublemakers to induce denial of service to
legitimate users. Instead, filtering should be done at appropriate
gateways, and the undesirable datagrams should be dropped, with
appropriate ICMP messages to their source if feasible. This feature
exists in several commercial gateway boxes. The same thing can be done
in end systems, but the utility there is less clear.
Now then, about IP and ISO and so on. The RFC that discusses IP-flavored
NSAPs is not 100% up with the latest thinking there. As far as I know,
the current thought is IDEA003. This scheme talks explicitly about the
case of isolated end systems on PDNs but the NSAP treatment essentially
ignores the question of IP address association. The object of these
documents was to support ISO stacks, not IP. The reason for the hybrid
NSAP format was to provide hooks for using IP routing mechanisms to
support NSAP interpretation, rather than the other way around.
There is official ISO work on the usage of CLNP over X.25, and this is
the mode of operation envisioned (most of the time) by US GOSIP. But
it is not clear that all of the questions one might ask have really been
answered - or they may have been answered in ways you won't like. The
first octet of CUD is now officially supposed to contain the protocol
identifier when you plan to use OSI protocols. There is a designated
value, hex 81, identifying CLNP. Distinct values are assigned (I don't
recall them) for ES-IS and IS-IS, which apparently means that it is
necessary to have two X.25 VC's to support one user's traffic between
two network entities. I'm surprised that we aren't hearing howls from
gateway vendors already. ES-IS should handle the problem of converting
the NSAP to an X.121 address, but of course you need a preconfigured
X.121 address for the IS so you can talk to it to ask the question, and
the IS (or another IS) still needs to be told what the mapping and
topology are. These matters are outside the scope of the ISO specs.
Bill Barnssmb@ulysses.homer.nj.att.com (Steven M. Bellovin) (02/11/89)
The point of doing a X.121->IP address map is to economize on virtual circuits. That is, routes are often symmetric; if a packet from A to B goes through gateways G1 and G2, replies from B to A will often go through G2 and G1. If G1 and G2 communicate via X.25, G1 will call G2 to send the first packet; if the reply is going to traverse the same path, it makes sense to reuse the X.25 VC. If G2 has to open its own circuit back to G1, it will incur a delay, and -- probably more important -- it will waste a channel. Some boards only support a limited number of channels; requiring two circuits for each call will, more or less, halve the number of connections a gateway can handle. (I'm assuming we don't want it thrashing on connection setup/teardown.) The flip side is the security issue: can one trust the calling X.25 address supplied? That depends on how much trust one has in the underlying network, or, more precisely, in the underlying X.25 *internetwork*. If the network provider is corrupt, making a new outgoing call won't help, as it will be diverted as well. But if the X.25 network relays calls from other X.25 data networks, and doesn't check the source address properly, it is possible that some spoofing will occur. I note that the two X.25 drivers lying around my 4.3bsd system here (for the ACC 5256/6250 and the 625 board) both behave as I describe: they attempt to determine the IP address to associate with incoming calls. --Steve Bellovin
karn@jupiter..bellcore.com (Phil R. Karn) (02/11/89)
>The point of doing a X.121->IP address map is to economize on virtual >circuits. That is, routes are often symmetric; if a packet from A to B >goes through gateways G1 and G2, replies from B to A will often go through >G2 and G1.... On the other hand, CSNET's experience with real commercial X.25 networks like Telenet has shown that multiple parallel virtual circuits are often necessary anyway to even approach acceptable performance. The problem is the small X.25 packet size limit and the tiny packet-layer flow control window. In the absence of a mechanism for increasing this window you are forced to open up additional circuits and distribute your traffic among them. Face it, X.25 was designed for remote slow-speed terminal networking, not serious computer networking. I can also say from experience that such a path is an excellent stress test for your TCP segment reordering code... Phil
rajaei@ttds.UUCP (Hassan Rajaei) (02/14/89)
In article <13962@bellcore.bellcore.com> karn@jupiter.bellcore.com (Phil R. Karn) writes: >On the other hand, CSNET's experience with real commercial X.25 networks >like Telenet has shown that multiple parallel virtual circuits are often >necessary anyway to even approach acceptable performance. The problem is the >small X.25 packet size limit and the tiny packet-layer flow control window. >In the absence of a mechanism for increasing this window you are forced to >open up additional circuits and distribute your traffic among them. Face it, >X.25 was designed for remote slow-speed terminal networking, not serious >computer networking. I quite agree with Phil. X.25 can not satisfy the high performance needed for high-speed communication and certainly not for internetworking. Isn't it really funny to have VC over a large network while it is not necessary? I believe the PTTs have done some mistake and now it is hard for them to admit and backup. The investment is so enormous that nobody dare to backup just like FORTRAN. I don't care which protocol the commercial world want to use, but I do care what scientists and researchers use or will use. These people have already started the alternative solutions. If other people listen enough we can hope for a newer and better standard than X.25. Hassan Rajaei
haas@wasatch.UUCP (Walt Haas) (02/16/89)
In article <13962@bellcore.bellcore.com>, karn@jupiter..bellcore.com (Phil R. Karn) writes: > On the other hand, CSNET's experience with real commercial X.25 networks > like Telenet has shown that multiple parallel virtual circuits are often > necessary anyway to even approach acceptable performance. The problem is the > small X.25 packet size limit and the tiny packet-layer flow control window. I was waiting for somebody else to point out the obvious, but it didn't happen... the small packet size limit and flow control window are *NOT X.25* problems, they are problems with the Telenet implementation! Please read the literature before you post... Walt Haas haas@cs.utah.edu utah-cs!haas
karn@jupiter..bellcore.com (Phil R. Karn) (02/16/89)
>I was waiting for somebody else to point out the obvious, but it didn't >happen... the small packet size limit and flow control window are *NOT X.25* >problems, they are problems with the Telenet implementation! > >Please read the literature before you post... I did. Unfortunately nobody seemed particularly interested in implementing all those wonderful features like modulo-128 packet numbering and packet window negotiation. Nor did Telenet seem interested in fixing their switches to not act as though the D bit were always set. Paper specs by themselves don't do much for me. The more gratuitously complicated a protocol is, the greater the opportunity for the vender to screw it up. Phil
Denis.Russell@newcastle.ac.uk (10/04/90)
I have an interest in routing IP datagrams over an X.25 network,
and would like some information on the characteristics actual
products (routers) that do this. The kind of completely
hypothetical (!) setup that interests me is a set of say 50 to
100 mainly Ethernet LANs connected by a wide-area X.25 network
with X.25 speeds in the 9.6kbps-64kbps-2Mbps range.
In the worst case one might imagine a permanent 2 * N^2
network of X.25 calls, and clearly some intermediate plan using
an hierarchy of routers would be preferable.
However, I am primarily interested in an intermediate
scenario where the X.25 calls are established and cleared down
as required. Clearly the practicality of this this would depend
on the traffic pattern - but that is not the primary focus of
this query. The primary focus is to find out whether routers
that support X.25 as an IP bearer have the right sort of
characteristic for such an application. For example, one would
require support for a substantial number of such calls (10, 20,
30?), and the automatic clearing down of calls after some
inactivity timeout. What speed X.25 is supported (preferably
well beyond 64kbps)? Does a router exploit already existing
inbound X.25 calls to send outbound datagrams or does traffic
always result in two calls, one used in each direction? What
other questions are important?
As some examples of the clarifications we would value are
that we understand that Sunlink supports only 4 X.25 calls by
default, but can be configured for any larger number. On the
other hand, the calls are never cleared due to inactivity. We
don't know whether any routers exploit X.25 in a duplex manner
or whether two calls are always/sometimes/never set up.
I'll summarise to the list if there is interest in the
results.
Denis Russell JANET: Denis.Russell@uk.ac.newcastle
Computing Laboratory Internet: Denis.Russell@newcastle.ac.uk
The University
Claremont Road Tel: (+44) 91 222 8243
Newcastle upon Tyne Fax: (+44) 91 222 8232
NE1 7RU Telex: 53 65 4 UNINEW G
ENGLANDa20@nikhefh.nikhef.nl (Marten Terpstra) (10/05/90)
In article <emu-ul20.1990.1004.143548.cl04@uk.ac.ncl.mts> Denis.Russell@newcastle.ac.uk writes: [stuf deleted] >this query. The primary focus is to find out whether routers >that support X.25 as an IP bearer have the right sort of >characteristic for such an application. For example, one would >require support for a substantial number of such calls (10, 20, >30?), and the automatic clearing down of calls after some >inactivity timeout. What speed X.25 is supported (preferably >well beyond 64kbps)? Does a router exploit already existing >inbound X.25 calls to send outbound datagrams or does traffic >always result in two calls, one used in each direction? What >other questions are important? CISCO IP routers can provide you with everything you want. The max speed for normal serial interfaces in these boxes is T1 (or 1.544 Mbit/s). You can of course get higher speed interfaces. The set-up and clearing of calls can simply be done by specifying an idle timer. Only one call is needed for two way traffic. It will set up a call if it has traffic to route. CISCO even provides x25 switching if you want this. Ask CISCO for some info or drop a line at customer-support@cisco.com. Marten -- Marten Terpstra National Institute for Nuclear Internet : terpstra@nikhef.nl and High Energy Physics Oldie-net: {....}mcsun!nikhefh!terpstra (NIKHEF-H), PO Box 41882, 1009 DB Phone : +31 20 592 5102 Amsterdam, The Netherlands