Hi Patrick,
> If I use B2B server in the DMZ and my partner is behind a VPN > connection then having an "address based authentication" gives me some > level of protection - when returning packets goes out from my B2B > server they are routed by the firewall towards the VPN connection - > even though the source address would have been faked and arriving from > somewhere else than the VPN connection. So the bad guy can't get the > data from my B2B. In this case, is the firewall routing based on your source locator or on the destination locator? Presumably, if it's part of your VPN service, that return routing is purely based on the destination locator. What you'd really like is to block packets arriving at your server that don't come off of the VPN. It is not unreasonable to do this with source locator filters in this specific case, because you can (reasonably) guarantee that the return packets will be directed to the VPN. > If the "address-based authentication"gets replaced by identifier then > the firewall doesn't care about the locator anymore, the bad guy > steels the partner's identifier (public DNS record) and put his own > locator on the packets. My firewall would route the returning packets > according to the locator and data goes to the bad guy. Given that ILNP identifiers are not global, doing identification purely on identifier is not going to help. If your server is not willing to perform application level authentication, then you can have your firewall perform authentication against a static locator and identifier binding, or against a pre-shared DNS name. The latter has the advantage that it allows locator mobility for your correspondent. This security seems like it is equivalent to IPv4 and maybe a touch better given DNSSEC. > How can this be prevented by DNSSEC? It ensures that the resolver gets > to the correct record information but how can my B2B or firewall know > that the request comes from the partner - should the firewall or B2B > verify the source locator from DNSSEC before responding to the > request? Yes, verifying the source locator is the correct thing to do, or resorting to higher levels of authentication (e.g., IPsec). > RFC 3383 says: > - While some participants in the meeting were interested in > protecting against disclosure of DNS data to unauthorized parties, > the design team made an explicit decision that "DNS data is > `public'", and ruled all threats of data disclosure explicitly out > of scope for DNSSEC. > > - While some participants in the meeting were interested in > authentication of DNS clients and servers as a basis for access > control, this work was also ruled out of scope for DNSSEC per se. > > What do I miss? Why is this relevant? This is clearly in scope for an architecture. And clearly DNSSEC privacy is not required for this either. Regards, Tony _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
