ther than switching
them to TCP (which happens without cookies).
Once Alice has a server cookie then the the server skips all the
rate limiting on future transactions from Alice (but not the attacker)
until the server cookie times out / is forgotten.
Mark
> Best,
> Hosnieh
>
&g
From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Mark Andrews
> Sent: Tuesday, July 21, 2015 7:19 AM
> Cc: DNSOP@ietf.org; Hosnieh Rafiee
> Subject: Re: [DNSOP] Review of draft: draft-ietf-dnsop-cookies
>
>
> Hosnieh, below is a real life use of cookies showing how they
Hi Hosnieh,
On Mon, Jul 20, 2015 at 10:55 AM, Hosnieh Rafiee wrote:
>> > This is not highlighted in the draft which makes it confusing for the
>> > reader which causes to raise such question regarding NAT.
>>
>> Because it is irrelevent has to how the attacker chooses the address to
>> attack.
>
Hosnieh, below is a real life use of cookies showing how they are used.
Establish a cookie pair. Dig chooses a random value for the client
cookie. The server returns the client cookie along with the server
cookie. The client cookie is checked and as it matched "good" is
displayed.
; <<>> DiG
In message <024401d0c2fc$2cc85ce0$865916a0$@rozanak.com>, "Hosnieh Rafiee" writ
es:
> > > This is not highlighted in the draft which makes it confusing for the
> > > reader which causes to raise such question regarding NAT.
> >
> > Because it is irrelevent has to how the attacker chooses the addr
> -Original Message-
> From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Donald Eastlake
>
> Hi Ralf,
>
> On Mon, Jul 20, 2015 at 7:19 AM, Ralf Weber wrote:
> > Moin!
> >
>
> While the protocol is designed so that no state needs to be maintained at
the
> server, I don't think th
Hi Ralf,
On Mon, Jul 20, 2015 at 7:19 AM, Ralf Weber wrote:
> Moin!
>
> On 20 Jul 2015, at 4:39, Mark Andrews wrote:
>> No. The server takes the fake_client_cookie + IP client (victim) +
>> server secret + maybe parts of server cookie itself. Computes a
>> server cookie and compares that with wh
Hi Donald,
I think all the things you mentioned already addressed in other messages.
So, I would only go to the part that is not already answered
>
> It seems to me that presenting the defenses before the attacks means that
> while you are reading the defenses they are un-motivated. I think the
> > This is not highlighted in the draft which makes it confusing for the
> > reader which causes to raise such question regarding NAT.
>
> Because it is irrelevent has to how the attacker chooses the address to
attack.
> What is relevent is the impact the attack is happening and how a server
can
In message <3c8b970b-4588-4f31-ab35-436b7cbb5...@fl1ger.de>, "Ralf Weber" write
s:
> Moin!
>
> On 20 Jul 2015, at 4:39, Mark Andrews wrote:
> > No. The server takes the fake_client_cookie + IP client (victim) +
> > server secret + maybe parts of server cookie itself. Computes a
> > server cookie
Moin!
On 20 Jul 2015, at 4:39, Mark Andrews wrote:
> No. The server takes the fake_client_cookie + IP client (victim) +
> server secret + maybe parts of server cookie itself. Computes a
> server cookie and compares that with what was received. If and
> only if that matches (1 in 2^64) does the f
Hi,
I think Mark has done a good job in responding, so I don't really have
much to add.
If you can conveniently do configuration at the client and server,
then you can get strong authentication with TSIG. If you can't, the
weak authentication provided by Cookies is about the best you can do.
See
In message <001201d0c288$317fe330$947fa990$@rozanak.com>, "Hosnieh Rafiee"
writes:
> > > When the clients are not seen, I just wonder how the attacker can
> > > target them??
> >
> > Clients talks to things other than DNS servers. The attacker gets the
> address of
> > the address of the client
> > When the clients are not seen, I just wonder how the attacker can
> > target them??
>
> Clients talks to things other than DNS servers. The attacker gets the
address of
> the address of the client from those transactions.
This is not highlighted in the draft which makes it confusing for the
In message <01d0c225$8c4d0260$a4e70720$@rozanak.com>, "Hosnieh Rafiee"
writes:
> > > So, you want such mechanism is implemented in NAT devices to protect
> > > all clients in that network, right? If not, the implementation of that
> > > in a single client behind the NAT, doesn't help all the
> > So, you want such mechanism is implemented in NAT devices to protect
> > all clients in that network, right? If not, the implementation of that
> > in a single client behind the NAT, doesn't help all the clients inside
> > that NAT network because the target is a public address of this device
>
In message <001501d0c1ec$52898050$f79c80f0$@rozanak.com>, "Hosnieh Rafiee"
writes:
> Mark,
>
> Thanks for your explanation. My comments are inline...
>
> > -Original Message-
> > From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Mark Andrews
>
>
> > > If the victim node is behi
Mark,
Thanks for your explanation. My comments are inline...
> -Original Message-
> From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Mark Andrews
> > If the victim node is behind NAT (servers are not behind NAT), and
> > attacker is not in the same network, IMO, it cannot perfor
In message <000301d0c17f$6ac5f530$4051df90$@rozanak.com>, "Hosnieh Rafiee"
writes:
>
> Hello,
>
> I have reviewed this draft. My comments are as followings:
>
> - Section 3.2 TKEY can solve the problem ..
> IMO TKEY also needs some manual preconfiguration on the server side. So, it
> does no
Hello,
I have reviewed this draft. My comments are as followings:
- Section 3.2 TKEY can solve the problem ..
IMO TKEY also needs some manual preconfiguration on the server side. So, it
does not completely solve the TKEY distribution problem.
furthermore This is only applicable to recursive re
20 matches
Mail list logo
