martillo@ATHENA.MIT.EDU (10/30/87)
I seem to remember reading (perhaps in an article by Padlipsky) that if a process receives a packet with expected source and destination TCP ports, expected destination IP address but an unexpected IP source address, such an incident should be considered an error. I would think that for a multihomed host selecting a new interface would be a perfectly reasonable way to handle an interface error. Also moving to a new interface would be one way of handling load sharing. The recipient should be smart enough to start sending IP packets to the new interface. If IP and TCP are really separate layers, this analysis makes sense to me. Is this the way TCP/IP is implemented on multihomed hosts? Yaqim Martillo
CERF@A.ISI.EDU (10/30/87)
Yaqim, I would be surprised if multi-homed hosts were implemented in such a way as to make indistinguishable to the source which net was being used. Generally, in the scenario you describe, the arriving packet with the unexpected source IP address might be thought an intruder by the recipient. How could you tell the difference between a source which is attempting a spoof of a multi-homed host and a true multi-homed host? Logical addressing at the IP level seems a more solid way of proceeding - of course, this leaves unspoken how the various physical addresses are bound/validated to the logical IP level address - for some networks, this is done automatically as in the DDN and ARPANET. Vint Cerf
martillo@ATHENA.MIT.EDU (11/01/87)
If I were really worried about spoofing, I would hardly depend on IP address consistency to guard against spoofing. I would suggest that this chimerical protection against spoofing violates the logical distinction between the IP and TCP layers. I would suggest in fact that a host supporting several level 3s or IP like layers should permit the passage of data packets up to the TCP protocol handler or any other comparable level protocol handler and the TCP level protocol handlers should not care from which of the level 3s the packet originated. Such logical distinction seems to be lost if level 4 worries about the remote IP address and if level 3 worries about level 4 ports. At MIT we used subnet mask to provide some security for tftp transfers. I am not so sure this was such a good idea though it did work for our purposes. Yakim Martillo
jis@BITSY.MIT.EDU (Jeffrey I. Schiller) (11/02/87)
I should point out that at MIT we no longer use network addresses as a form of authenticity. We now use our encryption based "Kerberos" authentication service. The code you wrote to use the subnet as a means of determining authentication has long since been retired. -Jeff
minshall@OPAL.BERKELEY.EDU (11/04/87)
Well, I've never been great on understanding which level is which. However, a TCP address is the two-ple <IP address, TCP port number>. This is the TCP address. That is the way it is. The nice thing here is that the TCP address contains sufficient information to determine the IP address (and, the bad thing here is that...). Next, a TCP connection is defined by the two-ple <local TCP address, remote TCP address>. A TCP connection *cannot* be defined by the two-ple <local TCP port, remote TCP port> - port numbers only have significance when concatenated with an IP address (imagine telnet clients on two machines trying to connect to the telnet server, port 23 or whatever, on one server machine). If I understand the world of ISO correctly, *everything* has an address (or is it a name?) which is (maybe) globally unique. In that case what you are saying would make sense - ISO TCP shouldn't care about the ISO IP source address some packet of data came from. However, DARPA TCP/IP is not built that way. (It would, it is true, be nice if every host had exactly one "name"; then a TCP address could be <host "name", port number>.) Greg Minshall
martillo@ATHENA.MIT.EDU (11/05/87)
Yes, it sounds like my interpretation won't work. I really was not trying to get TCP/IP to fit into the ISO model which I consider malformed at best. I have some Basic Rate and Primary Rate Interface cards for various machines, and I want to run TCP/IP over them. But I want the option of establishing point to point serial links between machines or X.31 connections to PSPDNs rather than just packet calls to my PBX or local switch which seem to have either miserable or non-existent packet handlers. In this environment I want to dynamically assign IP addresses to channels or groups of channels and I want to tear down links over which there is no traffic because I want to avoid phone bills which could be large in the case of point-to-point rather than packet billing. In such an environment I could anticipate the physical link for an rlogin session going away and then suddenly when there was activity over the TCP VC a new physical link on perhaps a different interface might be established which might end up with a new IP address. Alternatively if possible I would probably like to move calls off the ISDN medium onto the ethernet medium if a dead network suddenly became alive. But given that IP and TCP are apparently really only one layer it can't be done. In any case the problem probably isn't too important since ISDN is too slow to be useful for real networking. Of course for multihomed hosts the reliability issue might be important, but I guess it just can't be done.
minshall@OPAL.BERKELEY.EDU (11/05/87)
>... > Alternatively if possible I would probably like to move calls off the > ISDN medium onto the ethernet medium if a dead network suddenly became > alive. > > But given that IP and TCP are apparently really only one layer it > can't be done. > > In any case the problem probably isn't too important since ISDN is too > slow to be useful for real networking. Of course for multihomed hosts > the reliability issue might be important, but I guess it just can't be > done. No, TCP and IP are not one layer. Back in the days of experimental ethernets, there were only 8 bits of addressing in the ethernet packets. The way of mapping an IP address to an ethernet address was to use the lower order 8 bits of the IP address as the ethernet address (though actually what really happened was that the ethernet address was assigned to the lower order 8 bits of the IP address). You wouldn't argue that the ethernet and IP were really one layer; however, the mapping between IP address and ethernet address was merely that of extracting - a projection. On current ethernet, a projection from the 32-bit IP address space won't work, since the map needs to be onto, and the ethernet address space is 48 bits. So, we have ARP. A TCP address is composed of two parts: a 32-bit IP address, and an 8-bit port identifier. To convert a TCP address into an IP address is, again, a projection. That this is so does not somehow merge the two layers into one. They are two layers. (By the way, a machine is certainly free to send a packet on an interface with address 128.32.13.4, and give it an IP source address of 10.0.3.4; this is even justified if that machine has an interface with "address" 10.0.3.4 and that interface is down and there is an already existing connection to a local port of 10.0.3.4. However, you are correct in assuming that in this situation, the connection partner will probably not survive the fact that the 10.0.3.4 interface has gone down - unless the sender uses IP source routing and the partner remembers the last source route received on the connection.)
schoff@NIC.NYSER.NET ("Marty Schoffstall") (11/07/87)
I should point out that at MIT we no longer use network
addresses as a form of authenticity. We now use our encryption based
"Kerberos" authentication service. The code you wrote to use the
subnet as a means of determining authentication has long since been
retired.
Is there going to be an RFC on the authentication service???
Marty