DNS over TCP - a fix for Kaminsky's hack - TCP-IP

This is a discussion on DNS over TCP - a fix for Kaminsky's hack - TCP-IP ; In article , vjs@calcite.rhyolite.com (Vernon Schryver) wrote: > In article , > Barry Margolin wrote: > >In article , > > Rick Jones wrote: > > > >> How does carrying queries over TCP connections interact with anycast > >> ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 28 of 28

Thread: DNS over TCP - a fix for Kaminsky's hack

  1. Re: DNS over TCP - a fix for Kaminsky's hack

    In article ,
    vjs@calcite.rhyolite.com (Vernon Schryver) wrote:

    > In article ,
    > Barry Margolin wrote:
    > >In article ,
    > > Rick Jones wrote:
    > >
    > >> How does carrying queries over TCP connections interact with anycast
    > >> addressing?

    > >
    > >Since DNS doesn't generally need to keep connections around for long
    > >periods, it probably wouldn't be a problem. I think there have been
    > >some experiments with anycast to HTTP servers and they worked OK.
    > >Internet routes don't usually flap enough to cause problems for
    > >short-lived connections.

    >
    > Some comments in the mailing lists say much the same thing. Other
    > comments seem to be saying that the anycast route flaps happen far more
    > often than one might expect. I think that we're not talking about route
    > flaps in the usual sense, which are damped and clamped and very rare
    > at time scales of DNS/TCP/IP connections.


    Maybe they're talking about packets traversing redundant connections
    within the network. While it's possible that these can cause different
    segments of a connection to go to different anycast instances, I think
    this is usually considered a bug in the network and it should be fixed.
    Many routers do flow caching, so all the segments of a connection
    automatically take the same path (unless the cache overflows).

    >
    > Besides, anycast is not the only kind of load balancing in front of
    > big DNS servers. Consider a load balancer that even distributes
    > incoming packets to a bag of MAC addresses. You'd hope that a load
    > balancer would not do that to TCP segments, but doing the right thing
    > would require the load balancer to keep state for bazillions of
    > DNS/TCP/IP connections.


    Since one of the most common use of load balancers is in front of
    clusters of HTTP servers, I sure hope they'd be able to keep state for
    bazillions of TCP connections.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  2. Re: DNS over TCP - a fix for Kaminsky's hack

    The dns request/response seems to have a reserved flag called Z which is not
    used yet ?

    This flag could be used to indicate a dns transaction id extension.

    This extension could be added anywhere in the packet.

    Be it as a new field... or as a extra fake query/answer.

    Over time software needs to be updated anyway... so implement this extension
    as soon as possible into new software and devices and all will be well soon
    enough... at least for all those people that think it's important enough to
    warrant an update

    Bye,
    Skybuck.



  3. Re: DNS over TCP - a fix for Kaminsky's hack

    On Aug 11, 4:17*pm, Didi wrote:

    >*There is no state to save between requests if you use TCP
    > other than what there is if you use UDP. Both transports
    > are defined in RFC1034/1035, the only difference being a length word
    > at the beginning of the data.


    Umm, what? There is *NO* state to save between requests for UDP. The
    server can completely forget that the client exists and can treat each
    new request packet as its own universe.

    With TCP, there are two choices:

    1) You could use a new TCP request with each connection. In that case,
    instead of one packet for a UDP request and one packet for a UDP
    reply, you have a three-way TCP handshake, then the request/reply,
    then the FIN/ACK packets of a TCP shutdown. This increases the network
    traffic to the DNS server by a factor of 3 or so.

    2) You could keep each TCP connection up between requests. This
    requires the server to store the full TCP connection state for every
    client connected to it. At minimum, this is the client IP, client
    port, window positions in both direction, current state. If it doesn't
    use a timer of some kind, it will be vulnerable to various DOS
    attacks, so it will need to keep a timeout or a 'last heard' time.

    TCP requires significantly greater state on the server than UDP, or it
    requires about three times the network bandwidth. Most likely,
    somewhere in-between these two, depending upon the ratio of requests
    to connection setup/teardowns.

    DS

  4. Re: DNS over TCP - a fix for Kaminsky's hack

    In article ,
    vjs@calcite.rhyolite.com (Vernon Schryver) writes:
    > Someone in the mailing lists suggested hacking a special code for
    > very busy DNS servers that would
    > - answer all SYNs to port 53 with SYN-ACK without creating a TSP or saving
    > any other state,
    > - acknowledge everything that seems to want an acknowledgement,
    > - assume that the DNS/TCP/IP request would fit in the first and
    > only non-trivial segment after the SYN,
    > - and generally act as if DNS/TCP/IP were the same as DNS/UDP/IP.
    >
    > It would do no retransmitting, which might be hard on DNS clients beyond
    > lossy paths.


    Retransmissions should not be a problem, provided that you replace
    "acknowledge everything that seems to want an acknowledgement", with
    something just a little bit more sophisticated.
    The client's sequence numbers are used to verify that it is really
    talking to the server, but the server can use its sequence numbers as a
    cookie. For the sake of the explanation I will assume that the server's
    ISS is 0.

    There are 3 things that may want an acknowledgement:

    - SYN.
    Always acknowledge.

    - Request, with or without FIN.
    Always respond with reply+FIN+ACK

    If the client is on a lossy path then it will retry its request,
    which triggers another reply+FIN+ACK. In other words, the client
    handles retransmissions.

    - FIN in a segment by itself.
    Be careful. If you acknowledge this just because it seems to
    want an acknowledgement then the client will assume that you've
    seen its request and no longer retransmit.
    We therefore only acknowledge the FIN if this segment acknowledges
    our response. This is where the cookie comes in. If segment.ack <= 1
    then it only acknowledges our SYN. Otherwise chances are that it
    acknowledges our response.

    At first sight it may seem that this causes an extra packet to be sent,
    but unless the client is really broken it can combine the retransmission
    of its FIN with the acknowledgement of our FIN, which needs to be sent
    anyway.

  5. Re: DNS over TCP - a fix for Kaminsky's hack

    Vernon Schryver wrote:
    > ....
    > > There is no state to save between requests if you use TCP
    > >other than what there is if you use UDP.

    >
    > That is wrong if you define "request" as broadly as required by the
    > situation. The socket and FD for a DNS/TCP request is created when DNS
    > server does a select() and accept() soon after the SYN from the client
    > arrives. That FD, the underlying TSP, and the client's IP address,
    > sequence number, TCP options,...


    I know how TCP works. Like I already said, I happen to have
    implemented
    it, along with DNS and many other things.
    All you mention has nothing to do with states to save related to DNS
    as
    you claimed. This is the overhead TCP adds to which we both referred
    separately.

    > >other than what there is if you use UDP. Both transports
    > >are defined in RFC1034/1035, the only difference being a length word
    > >at the beginning of the data.

    >
    > that's irrelevant.


    Given that now you know there are no states to save between
    DNS transactions it is irrelevant indeed.

    >
    > > You may want to take note that this comes from someone who has
    > >implemented a TCP, DNS with caches etc.

    >
    > Google is your friend.


    I tried that - spent the 2-3 minutes I was inclined to - and all I
    found
    was similar to what I see here. If you have authored some real stuff
    it must be harder than that to locate, please indicate what.

    > While in theory and special implementations, Van Jacobson's number of
    > ~100 cycles per TCP segment exclusive of byte copies and checksums is
    > right, in typical practice it is orders of magnitude small. On the
    > other hand, searching a DNS cache needs few cycles if you're a rabid
    > coder comfortable writing your own tree and hash searching code.


    So you want to search the database of the root servers in a few cycles
    per request. How many entries per cycle do you actually want to go
    through? Sorry but this sounds like you don't have a clue of what
    you are talking about.

    Didi

    ------------------------------------------------------
    Dimiter Popoff Transgalactic Instruments

    http://www.tgi-sci.com
    ------------------------------------------------------
    http://www.flickr.com/photos/didi_tg...7600228621276/

    Original message: http://groups.google.com/group/comp....d?dmode=source


  6. Re: DNS over TCP - a fix for Kaminsky's hack

    Vernon Schryver wrote:
    > Besides, anycast is not the only kind of load balancing in front of
    > big DNS servers. Consider a load balancer that even distributes
    > incoming packets to a bag of MAC addresses. You'd hope that a load
    > balancer would not do that to TCP segments, but doing the right
    > thing would require the load balancer to keep state for bazillions
    > of DNS/TCP/IP connections.


    Or simply do its balancing decisions based on the four-tuple. If we
    are talking about bazillions of DNS/TCP/IP connections one probably
    gets good distribution from a hash on the four-tuple.

    > Someone in the mailing lists suggested hacking a special code for
    > very busy DNS servers that would
    > - answer all SYNs to port 53 with SYN-ACK without creating a TSP
    > or saving any other state,
    > - acknowledge everything that seems to want an acknowledgement,
    > - assume that the DNS/TCP/IP request would fit in the first and
    > only non-trivial segment after the SYN,
    > - and generally act as if DNS/TCP/IP were the same as DNS/UDP/IP.


    > It would do no retransmitting, which might be hard on DNS clients
    > beyond lossy paths.


    So long as the ACK of the request was only piggybacked on the segment
    carrying the reponse you would be OK. Then in the event of loss of
    ACK you would get a retransmit from the client.

    > It would naturally defend against the current excitement by the DNS
    > client using the additional entropy in its TCP initial sequence
    > number. It is such a completely nasty ugly kludge that I love it,
    > if it really works.


    Is it really sufficient to protect against the spoofing if only the
    clients to be keeping state? I guess the 32 bit ISN of TCP is a nice
    boost. It would be a nasty ugly kludge. How many more nasty ugly
    kludges can dance on the Internet pin-head?

    rick jones
    --
    firebug n, the idiot who tosses a lit cigarette out his car window
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  7. Re: DNS over TCP - a fix for Kaminsky's hack

    In article ,
    Rick Jones wrote:

    >> It would do no retransmitting, which might be hard on DNS clients
    >> beyond lossy paths.

    >
    >So long as the ACK of the request was only piggybacked on the segment
    >carrying the reponse you would be OK. Then in the event of loss of
    >ACK you would get a retransmit from the client.


    good point

    >Is it really sufficient to protect against the spoofing if only the
    >clients to be keeping state? I guess the 32 bit ISN of TCP is a nice
    >boost.


    The current kludges of less than partial fixes of varying the client's
    UDP port number or toggling 0x20 bits is all about state on the client.
    The real DNSSEC fix is also about client state if you squint at it from
    the right angle.
    The server's state is useless, expensive overhead except when the server
    recurses. Real DNS/TCP/IP protects against the current cache poisoning
    attack only because predicting the client's DNS/TCP initial sequence
    numbers to spoof the server's answers is hard in the modern era. For
    example, if the client always used an initial sequence number of 1, the
    bad guy could spew DNS/TCP segments with bogus answers much like the
    bogus DNS/UDP bogus answers. The main difference is that the DNS/TCP
    bogus answers would need to be preceded by bogus SYN-ACKs.


    > It would be a nasty ugly kludge. How many more nasty ugly
    >kludges can dance on the Internet pin-head?


    time-wait delays, MSS options, Nagle, congestion control, congestion
    avoidance, header prediction, page flipping/zero-copy, timestamps,
    extended windows, IPv6 and the rest of the list implies some job security.

    oh what a tangled web we weave when first we practice to be compabible.


    Vernon Schryver vjs@rhyolite.com

  8. Re: DNS over TCP - a fix for Kaminsky's hack

    On Tue, 12 Aug 2008 01:20:45 -0700, Didi wrote:

    > Vernon Schryver wrote:
    >> ....
    >> > There is no state to save between requests if you use TCP
    >> >other than what there is if you use UDP.

    >>
    >> That is wrong if you define "request" as broadly as required by the
    >> situation. The socket and FD for a DNS/TCP request is created when DNS
    >> server does a select() and accept() soon after the SYN from the client
    >> arrives. That FD, the underlying TSP, and the client's IP address,
    >> sequence number, TCP options,...

    >
    > I know how TCP works. Like I already said, I happen to have implemented
    > it, along with DNS and many other things.
    > All you mention has nothing to do with states to save related to DNS
    > as
    > you claimed. This is the overhead TCP adds to which we both referred
    > separately.


    I don't see how you can implement DNS over TCP without saving the socket,
    thus saving extra state. Which is what Vernon said btw.

    M4

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2