Just back from vacation and see an amazing 87 messages in this thread on
NTAs. As the primary NTA I-D author and NTA proponent I will slowly make
my way through.
Regards
Jason
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://li
Hi all,
for all those who haven't been on saag WG at IETF 88...
Amir Herzbert and Haya Shulman has presented a quite interesting attack on UDP
fragmentation that allows Kaminsky-style attacks to be real again.
The saag presentation is here:
http://www.ietf.org/proceedings/87/slides/slides-87-s
On 8/23/13 12:52 PM, "Daniel Kalchev" wrote:
>Most ISP's DNS "operations" are just as clueless/careless as those
>breaking their DNS setups. NTAs are not solutions for these, because
>they won't bother with it either.
It's fun to poke at operators I guess, and that's certainly one reason why
mor
On 8/26/13 2:16 AM, "Randy Bush" mailto:ra...@psg.com>> wrote:
fix the software and the ops processes. do not patch over the problems or they
will increase. the problem is weak software and processes that need to be
fixed, and patching and denial will not fix them.
Fair enough, and I agree tha
Hello,
I believe that it is another serious attack against DNS protocol,
or it may be against UDP/IP (especially IPv4).
So, we might set max-udp-size to 1220 for preventing UDP fragmentation.
And I know anouther "IPv6 Fragment Header Deprecated" I-D at IETF 6man WG.
BTW, sometimes I unofficial
On Wed, Sep 04, 2013 at 03:08:55PM +0200,
Ondřej Surý wrote
a message of 81 lines which said:
> So what are the views of other people on this list?
[Total noob just going back from holidays and therefore even less
competent as usual.]
Isn't is a good idea to limit the maximum size of the res
On 4 Sep 2013, at 15:04, Ondřej Surý wrote:
>> A possible solution is simply to deploy IPv6 faster :-)
> Yeah :), but what should we do in the eternity meanwhile?
Don't fragment at all, set TC=1 on responses which would cause UDP or lower
layer fragmantation and assume only genuine queries wi
Hello,
> > So, we might set max-udp-size to 1220 for preventing UDP
> > fragmentation.
>
> But, in IPv4, the attacker can send spoofed ICMP "packet too big"
> messages to decrease the size of the path MTU, as seen by the DNS
> server.
RELNOTES of NSD 3.2.9 describes the following,
we may separ
On 4. 9. 2013, at 16:11, Jim Reid wrote:
>
> On 4 Sep 2013, at 15:04, Ondřej Surý wrote:
>
>>> A possible solution is simply to deploy IPv6 faster :-)
>
>> Yeah :), but what should we do in the eternity meanwhile?
>
> Don't fragment at all, set TC=1 on responses which would cause UDP or low
On 4. 9. 2013, at 15:47, Stephane Bortzmeyer wrote:
> On Wed, Sep 04, 2013 at 03:08:55PM +0200,
> Ondřej Surý wrote
> a message of 81 lines which said:
>
>> So what are the views of other people on this list?
>
> [Total noob just going back from holidays and therefore even less
> competent a
Ondřej Surý wrote on 09/04/2013 10:37:57 AM:
> On 22. 8. 2013, at 21:59, wbr...@e1b.org wrote:
> > Our browsers give us the option to trust invalid TLS certificates,
some
> > even storing it indefinitely. Is an NTA much different?
>
>
> And in certain circles it's considered by one of the bi
Folks,
A few years ago, I had an informal conversation with Dr. Vixie, and he
mentioned he could work a little bit more on DNS level fragmentation
(protocol modification required, however).
At a glance, we may use EDNS0 variable part to represent DNS level
fragmentation information as well as add
Ondrej,
On 9/4/13 9:08 AM, "Ondřej Surý" wrote:
>We gave it some thoughts here at CZ.NIC Labs and we think that the threat
>is real and we are now trying to write a PoC code to prove the
>theoretical concept.
>
>So what are the views of other people on this list?
I attended the SAAG session, li
On 22. 8. 2013, at 21:59, wbr...@e1b.org wrote:
> Our browsers give us the option to trust invalid TLS certificates, some
> even storing it indefinitely. Is an NTA much different?
And in certain circles it's considered by one of the biggest mistakes that
could have happened, and the reason why
BTW just to complete my question in first email - is there a agreement that
this is serious and needs to be addressed?
I am still wondering why this have slipped under the radar for so long (the
original paper was published last year).
Ondřej Surý
> On 4. 9. 2013, at 15:47, Stephane Bortzmeyer
On 4 Sep 2013, at 15:34, Stephane Bortzmeyer wrote:
>> Don't fragment at all, set TC=1 on responses which would cause UDP
>> or lower layer fragmantation
>
> Not obvious to implement, the application (the name server) typically
> does not know the path MTU before sending an UDP packet to a
> de
On 4 Sep 2013, at 15:40, Ondřej Surý wrote:
>> Check also ICMP "packet too big" coming in with ridiculous sizes, they
>> might be the sign that someone is trying the Shulman attack.
>
> True, but again, that might work for us, but not for average DNS operator.
Indeed. But who is more likely to
Last but not least, I observed some conflicting feedback in this thread on
NTAs. So I am wondering whether there is comparatively more consensus on these
two issues:
1 – Responsibility for authoritative DNSSEC mistakes rests with authoritative
operators
(written up quickly in
http://tools.ietf
> Check also ICMP "packet too big" coming in with ridiculous sizes, they
> might be the sign that someone is trying the Shulman attack.
JFTR It's one ICMP packet per the fragmentation cache timeout and the unique
destination IP.
I wish we had found out some way to enforce BCP38 before spoofing
On 09/04/2013 04:50 PM, Ondřej Surý wrote:
> BTW just to complete my question in first email - is there a agreement that
> this is serious and needs to be addressed?
>
Just had a quick read and here are some random thoughts (staying out of
solution space for now):
Fragmentation has long been k
> On 4. 9. 2013, at 16:50, Jim Reid wrote:
>
> On 4 Sep 2013, at 15:40, Ondřej Surý wrote:
>
>>> Check also ICMP "packet too big" coming in with ridiculous sizes, they
>>> might be the sign that someone is trying the Shulman attack.
>>
>> True, but again, that might work for us, but not for a
I don't think there's any requirement to fragment exactly at the MTU/MSS
boundary. It's ok to fragment at a lower point, so there's an opportunity
for additional entropy by randomising the point of fragmentation on a
datagram by datagram basis. If the spoofer doesn't know the point of
fragmentation
On Wed, Sep 04, 2013 at 04:04:13PM +0200,
Ondřej Surý wrote
a message of 93 lines which said:
> > Isn't is a good idea to limit the maximum size of the response,
> > like .com/.net (and may be other TLD: examples welcome) do? This
> > will make the attack more difficult.
>
> That could work,
On Wed, Sep 04, 2013 at 11:01:43PM +0900,
Yasuhiro Orange Morishita / 森下泰宏 wrote
a message of 40 lines which said:
> RELNOTES of NSD 3.2.9 describes the following,
> we may separate max-udp-size value for IPv4 and for IPv6.
This controls the size of the IP datagrame sent by the application
(t
On Wed, Sep 04, 2013 at 03:11:17PM +0100,
Jim Reid wrote
a message of 11 lines which said:
> Don't fragment at all, set TC=1 on responses which would cause UDP
> or lower layer fragmantation
Not obvious to implement, the application (the name server) typically
does not know the path MTU befo
-Original Message-
From: Dan York
Date: Wednesday, September 4, 2013 11:03 AM
To: Ondřej Surý , DNS Operations
Subject: Re: [dns-operations] DNS Attack over UDP fragmentation
>Ondrej,
>
>On 9/4/13 9:08 AM, "Ondřej Surý" wrote:
>
>>We gave it some thoughts here at CZ.NIC Labs and we thi
On Wed, Sep 04, 2013 at 10:45:42PM +0900,
Yasuhiro Orange Morishita / 森下泰宏 wrote
a message of 38 lines which said:
> So, we might set max-udp-size to 1220 for preventing UDP
> fragmentation.
But, in IPv4, the attacker can send spoofed ICMP "packet too big"
messages to decrease the size of t
On 4. 9. 2013, at 16:33, Stephane Bortzmeyer wrote:
> On Wed, Sep 04, 2013 at 04:04:13PM +0200,
> Ondřej Surý wrote
> a message of 93 lines which said:
>
>>> Isn't is a good idea to limit the maximum size of the response,
>>> like .com/.net (and may be other TLD: examples welcome) do? This
>>
On 2013-09-04 17:25, Colm MacCárthaigh wrote:
I don't think there's any requirement to fragment exactly at the
MTU/MSS boundary. It's ok to fragment at a lower point, so there's an
opportunity for additional entropy by randomising the point of
fragmentation on a datagram by datagram basis. If the
On 2013-09-04 17:38, Mike Hoskins (michoski) wrote:
-Original Message-
From: Dan York
Date: Wednesday, September 4, 2013 11:03 AM
To: Ondřej Surý , DNS Operations
Subject: Re: [dns-operations] DNS Attack over UDP fragmentation
Ondrej,
On 9/4/13 9:08 AM, "Ondřej Surý" wrote:
We gav
-Original Message-
From: Ondřej Surý
Date: Wednesday, September 4, 2013 10:37 AM
To: "wbr...@e1b.org"
Cc: "dns-operati...@dns-oarc.net"
Subject: Re: [dns-operations] Implementation of negative trust anchors?
>On 22. 8. 2013, at 21:59, wbr...@e1b.org wrote:
>> Our browsers give us the o
On 09/04/2013 05:48 PM, Francis Dupont wrote:
> In your previous mail you wrote:
>
>> When these are defined, implemented, and deployed, all DNS messages
>> can be sent with DF=1 or IPv6 fragmentation option can be
>> deprecated.
>
> => if I remember well the attack is for IPv4 (it exchanges
how much more money, brains, and time are we going to collectively waste
on dns (so, a WOMBAT) to solve the problems dnssec solves, rather than
just deploying dnssec? i understood why, during the 2008 summer of fear,
we had to focus our efforts on source port randomization. but it's 2013
now. unles
In your previous mail you wrote:
> When these are defined, implemented, and deployed, all DNS messages
> can be sent with DF=1 or IPv6 fragmentation option can be
> deprecated.
=> if I remember well the attack is for IPv4 (it exchanges the random
DNS ID and port against the random IP ID which
On Wed, Sep 4, 2013 at 8:40 AM, wrote:
>
>> It'd be interesting to work out what the total entropy is by
>> using that along with truly random IP IDs.
>>
>
> It's only 16-bit and it's not much since you can preload the second
> fragments even before the query is sent.
I think with variable poin
On 2013-09-04 17:55, Mike Hoskins (michoski) wrote:
-Original Message-
From: Ondřej Surý
Date: Wednesday, September 4, 2013 10:37 AM
To: "wbr...@e1b.org"
Cc: "dns-operati...@dns-oarc.net"
Subject: Re: [dns-operations] Implementation of negative trust anchors?
On 22. 8. 2013, at 21:5
-Original Message-
From: "ondrej.s...@nic.cz"
Date: Wednesday, September 4, 2013 12:37 PM
To: "dns-operations@lists.dns-oarc.net"
Subject: Re: [dns-operations] Implementation of negative trust anchors?
>>When the two seem to conflict, better education is the answer not
>> removing one's
On 2013-09-04 18:12, Paul Vixie wrote:
how much more money, brains, and time are we going to collectively
waste
on dns (so, a WOMBAT) to solve the problems dnssec solves, rather than
just deploying dnssec? i understood why, during the 2008 summer of
fear,
we had to focus our efforts on source
Paul,
On 9/4/13 12:12 PM, "Paul Vixie" wrote:
>how much more money, brains, and time are we going to collectively waste
>on dns (so, a WOMBAT) to solve the problems dnssec solves, rather than
>just deploying dnssec?
My interest in understanding this attack is to understand how severe it
may be
ondrej.s...@nic.cz wrote:
> On 2013-09-04 18:12, Paul Vixie wrote:
>> ..., then i think we can safely tell anyone who is worried that their
>> authority data or recursive server is vulnerable to fragmentation-based
>> attacks, that they ought to just deploy dnssec.
>
> Paul,
>
> the problem is th
From: "Livingood, Jason"
> 1 ? Responsibility for authoritative DNSSEC mistakes rests with
> authoritative operators
> (written up quickly in http://tools.ietf.org/html/draft-livingood-
> auth-dnssec-mistakes-00)
The ultimate responsibility for domain issues really rests with the domain
owner,
> I don't think this is about a free choice, but adhering to the protocol.
At this point, I'm not sure who is saying what and what is inferred in the
quips, but if you adhere to the protocol, you place free choice first.
This is not just from my dimming memory of the 1990's when we developed t
In your previous mail you wrote:
> Read the paper, the authors mention that the recommendation for IP-ID on
> IPv6 is a sequential value, so its entropy is meager at best. Also some
> implementations on IPv4 use sequential value or per destination counters.
=> my comment was about correct IPv
> if you want to spend time on solutions for A/Z where A cares about
> security and Z does not, that's your decision.
but A is a vulnerable player
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listin
44 matches
Mail list logo
