keith@SPIDER.CO.UK (Keith Mitchell) (02/11/89)
It appears I may have contributed to the confusion on this topic myself, for which I can only apologise, and attempt to clarify what I meant when I mentioned using checking X.25 calling addresses for security purposes. Following on from Bill Barns <barns@GATEWAY.MITRE.ORG>: >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. When I advocated using the calling X.121 address as a validity check, I had *not* meant that it should be used to check the source IP addresses in the incoming datagrams, rather merely that the X.121 address belongs to someone with whom you are prepared to exchange IP datagrams with. The check is not to see that there is a valid relationship between a caller's X.121 address and a datagram's source IP address, but simply to see that the X.121 address is itself one of a known set of possible such addresses. >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. I accept that the IP address of the caller need not be the same as a datagram's IP source address. Nor do I believe that trying to deduce what the source IP address should be from the X.25 calling address is worth attempting. However, I think it *is* worth checking to determine whether this call is coming from someone who is part of the Internet. It is not a very rigourous check, but the assumption is that the Internet is a safer place than the PDN. My software works on the basis that if they're not in your IP <-> X.121 mapping table, then you don't know who they are and hence don't want datagrams from them. Once you have verified that someone is a legitimate source of datagrams, you can then perform higher-level scrutiny of these, filtering on network number as desired, which I agree is a nice facility. On to OSI and NSAPs. I must admit I do not have IDEA-0003 and so am not fully up to date with current thinking on this. Certainly we want to carry OSI services over both existing IP and X.25(80) networks, this is a sensible approach for transition to OSI. The question is, do we regard existing IP as a dead end, or is it still worth developing subnetwork services for it which can exploit the extra features being added to existing networks to make them OSI compatible ? I guess what I mean is, are the PTTs going to upgrade their PDNs to the 1984 CONS flavour of X.25 before the Internet starts using ISO CLNP, or will it be the other way round ? If it's the former, then we need some new standards. It would be nice if I could take the (NSAP + X.121) <-> IP address mapping table out of SpiderX.25 IXE, and just replace it with an algorithmic mapping. Too bad you can't use ES-IS for this sort of thing. This of course is why OSI will be the long-term solution to all this, and I appreciate that the CLNP over X.25 stuff is being addressed in GOSIP, even if I'm not terribly familiar with it. Of course, even in an OSI world, a lot of this stuff would be less of an issue if PTTs did not insist on providing Connection-Oriented service only. Roll-on public datagram networks. 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