On Tue, Jun 8, 2010 at 9:52 PM, Noel Chiappa <[email protected]> wrote:
> This is the exact same 'argument' that was raised against 8+8. It was
> incorrect then (Steve Bellovin, if memory serves, prepared a succint
> analysis of why that line of reasoning was incorrect), and it's still
> incorrect now.
>
> It's relatively easy to design a system which has at least as much
> security as the faux security that the 'address-based authentication' of
> the current system (even with DNSSec) has.
>
Please elaborate around this a little bit more, thanks.
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.
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.
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?
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?
-- patte
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
