Re: Some Observations on Entropy Re: Some observations on dns-0x20

[Mark Andrews]

>
> On Aug 26, 2008, at 9:19 AM, George Barwood wrote:
>
> >> There are also other heuristics (eg, has the MAC for the gateway
> >> changed) which could also be used.
> >
> > It all gets rather complex really, and complexity is enemy of
> > security.
> > I might be connected via a mobile phone that keeps changing networks.
> > Or an intermediate local computer that uses multiple NAT connections.
> > Or all sorts of stuff that I have no idea about, or might happen in
> > future.
> > [ Please understand I'm no expert in networking ]
>
> There are really two cases: Either you're NATed (between you and the
> remote resolver/authority) or you aren't.
>
> If you are NATed, port number offers NO entropy and NO protection,

If you are NAT'd the port number MAY offer you no protection.
There are NAT's which attempt to preserve port numbers and
actually do a pretty good job of doing that.

If you are NAT'd the NAT MAY provide protection for nameservers
that do not randomize their source ports by randomising the
source port as a side effect of the NAT process.

There are also NAT's which serialize the ports and NAT's
which only emit one port and potentially serialize the qid
as well.

The only thing you can say about NATs is because there is
no standard they can be doing ANYTHING to the queries. This
is one of the reasons NAT's are a abomination that people
should be working to remove as soon as possible.

Mark

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org

--
to unsubscribe send a message to namedroppe...@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

[Mark Andrews]

> > If you are NAT'd the port number MAY offer you no protection.
> > There are NAT's which attempt to preserve port numbers and
> > actually do a pretty good job of doing that.
> >
> > If you are NAT'd the NAT MAY provide protection for nameservers
> > that do not randomize their source ports by randomising the
> > source port as a side effect of the NAT process.
> >
> > There are also NAT's which serialize the ports and NAT's
> > which only emit one port and potentially serialize the qid
> > as well.
>

> Mark,
>
> Can we please make a distinction between plain NATs (which only affect
> TCP/UDP and IP headers) and proxies (or ALGs) which manipulate the
> protocol at higher levels?
>
> I've never seen a NAT which affects QIDs. I've seen plenty of ALGs that
> do, though, many of which did indeed pick serial QIDs :(
>
> Ray

I agree with you that there is a difference. The problem
of course is that you often don't know that a ALG is also
installed in the NAT box.

You generally buy a NAT (router in some markets) and have
no idea of what's inside as the vendors don't give you
enough details. You are also often not in a position to
see the traffic on both sides as the upstream may be a
cable/dsl modem and not ethernet.

[Mark Andrews]

>
> On Aug 28, 2008, at 5:04 PM, Mark Andrews wrote:
> >
> > I agree with you that there is a difference. The problem
> > of course is that you often don't know that a ALG is also
> > installed in the NAT box.
> >
> > You generally buy a NAT (router in some markets) and have
> > no idea of what's inside as the vendors don't give you
> > enough details. You are also often not in a position to
> > see the traffic on both sides as the upstream may be a
> > cable/dsl modem and not ethernet.
>

> However, for purposes of building a DNS resolver, you can probe for
> the detailed behavior, including port, ID, IP, etc, by querying a
> properly constructed authority, so you can be in a position to see
> both sides of the traffic: you just have to ask somebody who will tell
> you the other side.
>
> {port,txid,server}.{anything}.nettest.icir.org is one protoype example.
>
> This works in all cases where the NAT/proxy is not malicious
> (deliberately whitelisting the tests) and who's behavior doesn't
> change (you can always repoll to check for changed behaviors at a
> reasonable interval, however).
>
> For a malicious proxy in path, you are sunk however, but with a
> malicious proxy in path, you are sunk period.

And one really wants a solution where you don't need to care about
whether the port or txid are being changed or not. You also want
one where you can detect a malicious proxy / cache.