Hello, Zybell. Thank you for your reply. (It's the only reply up to now... :-) I'll answer your questions bellow. For people who don't remember what this thread is all about, please read the page: http://www.geocities.com/peddubr/re.html Uwe Zybell wrote: > I have read your proposal and have a few questions: > a) Do you propose a DNS-Extension to use *one* name for an address pair? I even thought about it, but I didn't formalize anything. I supposed this would not be essential right now. First, I'd like to see it all working with IP addresses... Even before DNS extensions, I guess it would be more important to formalize URL extensions to allow the use of several IP addresses or names, probably through another update for RFC 1738 (Uniform Resource Locators). Nevertheless, it would be perfectly possible to extend DNS anyway. I just didn't dare doing that right now. :-) > b) What about address triples, quadruples and so on? There could be more than > one Firewall, especially in the peer-to-peer scenario. Even when clients or servers are behind several gateways or firewalls, an address pair should be enough. I believe there would be no need for address triples or quadruples. This is because of an assumption I make: addresses in private networks are unique inside their environment, and packets can be properly routed. Suppose the following scenario: +--------+ | server | +--------+ | 192.168.0.10 192.168.0.50 +---------+ +--------------------------------------| gateway | +---------+ 172.16.0.10 172.16.0.50 | +------------------------------------------+ | +---------+ 10.0.0.10 10.0.0.50 +---------+ | gateway |--------------------------------| gateway | +---------+ +---------+ 133.27.228.205 | | INTERNET | 18.29.1.34 | +---------+ 10.0.0.20 +---------+ | gateway |--------------------------------| gateway | +---------+ 10.0.0.70 +---------+ | 192.168.0.1 | | 192.168.0.2 +--------+ | client | +--------+ In the network configuration above, the server (or client peer) is behind three gateways, and the client is behind two gateways. Even in this situation, the server could be identified by the address pair (133.27.228.205, 192.168.0.10). This is because the first gateway (133.27.228.205) could be configured to route packets for network 192.168/16 through gateway 10.0.0.10, which in turn could be configured to route through gateway 172.16.0.50, which in turn could be configured to send to its interface 192.168.0.50, reaching destination. These routing configurations can just be done in the conventional way, with the `route' command. Notice that in the scenario above, gateway 133.27.228.205 would do the conversion between IPIP encapsulated packets and LSRR packets, so that the intermediate gateways in the private networks should be configured to accept forwarding of source routed packets. If the scenario above was not what you had in mind, then please explain me better. It would probably be possible to use address triples or quadruples encapsulating several IP packets (a "nesting encapsulation"), but I don't see a real need for that (yet). > c) I would want to propose an option in the IPIP-Packet to reduce the > possibility of fakes. Your scheme would be no good, if it would be > possible to penetrate firewalls with it and flood internal computers, > which are possibly not prepared to deal with it, because they are *not* > servers, with traffic per guessed addresses. Then no sane router would > route IPIP. Well, I believe this is a matter of policy and firewall filters configuration. The kernel driver that would implement the conversion between IPIP encapsulated packets and LSRR packets could use a filter to decide if packets with a certain origin, destination and intermediate route should be allowed or denied. Those filters would be much of the same currently implemented in Linux; the main difference would be that not only source and destination addresses should be considered, but also intermediate addresses that appear in IPIP and LSRR. Internet applications running in machines exposed to LSRR packets could also consider logging the LSRR option instead of only the IP source address, since it would be much more meaningful. What kind of "option in the IPIP-Packet" were you exactly thinking about? > d) Is there a protocol to make a server known to the firewall (leasing a port)? > e) Is there a protocol to question a firewall for valid servers (if not > per DNS as per question a)? I don't know the answers for questions d and e... > f) Is it a good idea to introduce cryptographic options into IPIP or is it > better to use IPsec instead? (with regard to c) I don't deeply understand IPsec and do not even know if it would work if its packets were encapsulated within other IP packets, as in IPIP. I'm afraid IPsec does not allow IP headers to be modified, which in my scheme would be needed as when inserting a LSRR option to a header. (However, SSL or any other solution that don't care for IP headers should work fine. :-) Best regards, Paulo E. F. Castro Institute of Computing State University of Campinas, SP, Brazil - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
