Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!agate!ucbvax!GATEWAY.MITRE.ORG!barns
From: barns@GATEWAY.MITRE.ORG (Bill Barns)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  IP over X.25 (request for info)
Message-ID: <8902081711.AA07245@gateway.mitre.org>
Date: 8 Feb 89 17:11:06 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 96

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 Barns