On Mon, Jan 14, 2002 at 06:04:32PM -0300, Paulo Eduardo Ferreira de Castro wrote: > 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. :-) > The idea is to use the URLs as they are 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). > I didn't think about gateways, but about NAT. Think about an .org which has one connection over a translating ISP (that is an ISP, that gives his customers private IPs, that are translated via NAT to a few [possibly more than one] publicly accessible IPs). That .org would have its own NAT - so you have a triple, where multiple IPs are translated to one IP at each level. > > > 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? > See f). I think that policy (or the existence of one) must be defined in your proposal because if you don't, any implementor will want to leave it out so your protocol will be hacked and therefore not widely implemented. There was an idea to solve the same problem with essentially IP over HTTP, "because HTTP can travel all firewalls". Needless to say no one implemented it. Furthermore is the origin (as recorded in the source address) not a factor in a possible policy because it can be spoofed. The source address in an IP-Header is a misnomer. It should be called "Error destination". Then no one would even think about recording it to prove the origin of a packet. So there *must* be a cryptographic proof of responsibility to make a worthwile policy. > > > 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... > I shouldn't have asked "Is there ...", but "Do you think about ..." or "Will there be ...". > > > 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. IPsec has many modes. There are modifiable ones. You do not need IPIP in this case however, because IPsec contains the functionality of IPIP (that you use anyway). > (However, SSL or any other solution that don't care for IP headers should > work fine. :-) > That woud be to high a level. > 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
