Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ulysses!smb
From: smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: IP over X.25 (request for info)
Message-ID: <11201@ulysses.homer.nj.att.com>
Date: 10 Feb 89 19:36:17 GMT
References: <8902081711.AA07245@gateway.mitre.org>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 26

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