Hi Tony, sorry for the delay, wish I could cope up with the discussion better...
On Wed, Jun 9, 2010 at 5:03 AM, Tony Li <[email protected]> wrote: > > > 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. > Right, use uRFP on the locator value > >> 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. > It seems that the firewalls should move towards DNS based filtering solutions >> 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). > But then we are back in the renumbering challenge, if the partner changes his locator value I have to change my rule base simultaneously - and we are not really improving mobility here (either worsening it from current solution). It would be nice if the identifier could be used to limit access to my server farm, the final authentication is then done by e.g. IPsec by the server > >> 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. > I'm exploring the capabilities and limitations of the ILNP identifier, also renumbering - if renumbering could be made easier we would have a business case at the enterprises. We can't use the identifier at the firewalls to limit access at a security zone, if we use locators we loose mobility - both site and host mobility. Throwing a shim header on the problem won't help either - in site mobility scenario the edge locator remain unchanged and the core locator changes, so here you could use edge locator value to create fw rules. But then we have host mobility, a cellco is not keen to let the end user to roam over to another network that they can't charge for - thus the core locator do not change but the edge locator will change when the device is moving at the cellco's RAN (if you take the identifier mechanism to the future mobile network architecture). Filtering on IP addresses is not a good security solution, I agree on that - but it is used everywhere and it is not the final authentication method, instead you are limiting access from part of the Internet to particular zones, then you have some additional authentication methods on the server to have final access to the applications. If the locator is flexible we need something else to be able to set the scope of zones. -- patte > Regards, > Tony > > > _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
