Subject: [BEHAVE] Comment regarding draft-perkins-sourceipnat-00

From: Magnus Westerlund <[email-masked]>
Date: Wed, 25 Mar 2009 11:42:04 -0700

Hi,

As I raised this comment on the mike I like to follow it up here.

As this proposal has very similar properties to NAT-PT I think it is
important that the document do addresses the relevant critique raised in
 RFC 4966 for this proposal and how it can mitigate the issue.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 25 Mar 2009 11:46:53 -0700

the question I had on the mike today:
- given that the TTL of the name need to be low
- what happens if I write a 2 line loop script which queries the name as
fast and as many as I can? it would then create new mappings on the
translator for each request. Therefore, end up pretty fast to allocate
all ressources on the NAT. therefore, no more available until the
timeouts start to happen, which can't be too short...

How to mitigate that problem?

Marc.
-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca

---

From: <[email-masked]>
Date: Thu, 26 Mar 2009 14:29:14 +0100

If I've understood well, there is also a possibility to directly attack the IPv4 address pool.
Assuming an attacker knows this pool, he can generate packets (with different source addresses) towards this pool, and hence eat most of the pending mappings before the real packets arrive. It will be diffcult to filter because the NAT does not know what source addresses are legitimate.

Pierre

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Marc Blanchet
Envoyé : mercredi 25 mars 2009 19:47
À : Charles E. Perkins
Cc : [email-masked]
Objet : [BEHAVE] DOS regarding draft-perkins-sourceipnat-00

Marc.

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 26 Mar 2009 11:05:29 -0700

Hello Pierre,

There is the possibility to do this.  However, the payoff
is so small, that I wonder if anyone would bother.

Nevertheless, the impact should be assessed.  As it was
presented yesterday, the attack is a threat.  In order to
have long-term effects, it would have to be done
repeatedly.  That might increase the opportunity for
detection.

It might also be possible to blacklist incoming packets
from address ranges that are misbehaving.

Yesterday, Mark Andrews pointed out that there is a
very good reason to leave the port "accessible" to packets
with new source IP addresses.  This also has the effect of
mitigating the particular DOS attack mentioned in your
message.  I will be taking a detailed look at this.

Regards,
Charlie P.

---

From: Rémi Després <[email-masked]>
Date: Thu, 26 Mar 2009 13:30:48 -0700

> How to mitigate that problem?
To _mitigate_ it (not to solve it completely), it would be easy to limit 
the number of current mappings _per URL_.
(Thus DOS attacks on one URL, or on a number of them, would not impact 
others.)

Regards,

RD

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 26 Mar 2009 13:41:37 -0700

> (Thus DOS attacks on one URL, or on a number of them, would not impact

don't understand it. here is my understanding:
- user request a name
- dns resolution path goes to the sourceip-nat DNS server
- DNS server returns IP address and opens the NAT mapping

in this list, I don't see where URL are. does not seem relevant to me. I
guess I'm missing something.

Marc.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 26 Mar 2009 13:47:30 -0700

> (Thus DOS attacks on one URL, or on a number of them, would not impact

I'm not sure I understand this. Suppose you have N names and M addresses
in the pool. If M >= N, then you have no need for this draft. If M < N
and you impose the lowest possible limit (i.e. 1), you haven't solved
anything. Just allocate all M addresses to names you don't care about
while the others are being DOSed.

Blocking the addresses of clients sending DNS requests with the evil bit
set is out of question since you probably don't want to block resolving
DNS servers that are sending requests on behalf of the attacker.

I find this security issue so overwhelming that I doubt I understand the
method correctly.

Simon
-- 
STUN/TURN server    --> http://numb.viagenie.ca
Interplanetary news --> http://reeves.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: Rémi Després <[email-masked]>
Date: Thu, 26 Mar 2009 14:37:51 -0700

Marc Blanchet  -  le (m/j/a) 3/26/09 1:41 PM:

Rémi Després a écrit :

I guess I should have said "name" instead of URL.

This being done, assume a DNS that manages temporary mappings as
Charlie proposes has a bound on the number of mappings it accepts for
each name. Then the attack on name aa will not be sufficient to take
all resources of the NAT. The attacker will have to attack many names
mapped to the same NAT (names ab, ac, etc... which must be real names
in the DNS to do some harm).

RD

---

From: Simon Perreault <[email-masked]>
Date: Thu, 26 Mar 2009 14:50:22 -0700

Rémi Després wrote:
> This idea is not to block those who send too many requests, but only to
> avoid that an attack on a given name would be sufficient to consume all
> mapping resources of the DNS and the NAT.

I do not understand this.

Suppose you have a.com, b.com, and c.com, along with two IP addresses.

An attacker keeps a.com and b.com mapped to IP addresses by sending DNS
requests for these domains.

c.com is DOSed.

Concretely, how can this attack be mitigated?

Thanks,
Simon

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 26 Mar 2009 15:15:23 -0700

Hello Simon,

Do you mean that the attacker continuously sends
DNS requests for a.com and b.com?

If so, doesn't this increase the opportunity for
detection?

Regards,
Charlie P.

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 26 Mar 2009 15:39:06 -0700

> If so, doesn't this increase the opportunity for

not really, because the key is that the attacker source address is not
seen by the sourceip-nat DNS server. The DNS request packet received by
sourceip-nat DNS server is from some other DNS servers. These might be
broadband provider DNS server that you would not block.

therefore, it looks difficult to detect and to filter.

Marc.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 26 Mar 2009 17:41:23 -0700

> DNS requests for a.com and b.com?

Yes, every 1-2 seconds (according to the TTL).

> If so, doesn't this increase the opportunity for

The authoritative DNS server will detect evil requests, yes. The
solution would be to ban the requester. However, it is very possible
that the requests will come from a legitimate recursive DNS server being
abused by the real attacker. You cannot block requests coming from this
server because legitimate users may be trying to reach you using this
same recursive DNS server.

I have more and more the feeling that I got something wrong. I am
looking forward to enlightenment.

Thanks,
Simon

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 26 Mar 2009 18:10:55 -0700

Hello Simon,

> same recursive DNS server.

Right.  But we could do something to enforce fairness, by making sure that
requests are served in order.  I mentioned buffering the DNS Requests.  
I think
there are other implementation techniques also that could be useful.
> looking forward to enlightenment.

No, I don't think you have got it wrong.

How do you think this compares against existing DOS mechanisms?
The mechanisms for mitigating attacks on sourceIP_NAT remain to
be investigated for the most part, but it seems at least doable to make
the attacks "less interesting" to the attackers than other easier attacks.

Regards,
Charlie P.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 26 Mar 2009 18:33:31 -0700

> How do you think this compares against existing DOS mechanisms?

- A preliminary step is to discover a set of names mapped to the same
address pool as the name that is the target of the attack. A number of
name at least equal to the number of addresses in the pool is needed.

Publication of NSEC RRs by the subject of the attack may make this step
trivial.

- Performing the attack only requires from the attacker to be able to
send a number of DNS requests per second equal to the number of names
identified in the preliminary step (assuming a TTL equal to one second).
This represents a very low necessary upstream bandwidth.

- The identity of the attacker is not revealed when it is using a
legitimate recursive DNS server. Any broadband ISP provides such a server.

Simon

---

From: Keith Moore <[email-masked]>
Date: Thu, 26 Mar 2009 19:08:27 -0700

At this point I'm having a hard time believing that this proposal has
much applicability.

- it only works for protocols/implementations where a DNS query is made
fairly soon (separately from each peer making use of the address of the
host behind the NAT) before a connection is established

- there appear to be constraints on applicability based on:
  - how much each of the services behind it is used,
  - how many IPv4 addresses are available to be NATted to the servers'
addresses,
  - how many services are behind the DNS server/NAT

- it's vulnerable to DoS attacks and it's easy to mount those attacks.

So what is the space for which this proposal is a good solution,
something that we could recommend?  Can we describe it with any lucidity?

Keith

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 26 Mar 2009 19:49:40 -0700

Hello Keith,

I think that the applicability is as I described it in my presentation.
I expect that if a network operator serves a population of some thousands
or more of small-to-medium businesses and websites, then the proposal
should be applicable.  It "works" on the datasets I have, given the right
parameter choices.

> host behind the NAT) before a connection is established

Right.  I thought this was most of them, except for peer-to-peer.  For these
purposes, of course we could enable some explicit signaling for static 
or dynamic
assignment of the IPv4 address to the IPv6-only peer.  My proposal is never
going to be the only tool for transition.

>   - how many services are behind the DNS server/NAT

You are right.  These are the considerations/constraints.

> - it's vulnerable to DoS attacks and it's easy to mount those attacks.

Perhaps there could be some help for these problems.

> something that we could recommend?  Can we describe it with any lucidity?

I hope my comments above are lucid.  I gather you would not want to
see statistics for applicability based on the number of DNS requests per
second.

I really want to know if you disagree with my observation that, unless
businesses can serve their customers from a v6-based platform, they
will strongly oppose any suggestion to move to IPv6.  They will heat up
the demand for IPv4 addresses and delay transition.  Some might
prefer a balkanized Internet instead of doing the "right thing".

None of this is black and white.  I understand my proposal is not perfect;
in fact, it is imperfect in several ways.  However, compared to what we have
now to encourage adoption of IPv6, it seems very useful.  And, I really
have to emphasize that somehow NAT managed to proliferate because
it served certain needs -- I'm not claiming NAT is great, either!  In fact
just the opposite.

Another point about the number of NATv4 addresses...  First, temporarily
grant my hypothesis that this could be a useful tool for transition, and
grant my observation that the system works best with at least a few hundred
IPv4 addresses for the NAT.  Then it might be important to reserve some
of the existing IPv4 address space for the purpose of enabling this
way of accelerating IPv6 transition (or, at least, eliminating an important
inhibition against IPv6 transition).

I'll submit another draft in a few weeks taking recent suggestions into
account.

Regards,
Charlie P.

---

From: Keith Moore <[email-masked]>
Date: Fri, 27 Mar 2009 01:33:02 -0700

Charles E. Perkins wrote:

> will strongly oppose any suggestion to move to IPv6. 

Heavens, no.  I agree with that entirely.  I just think we need to try
to be clear about the applicability of all of our proposals, and I also
think that the potential for DoS attacks (in particular) limits the
applicability of this one.

I also think that even if the DoS potential can be dealt with (and I
don't see a way to do that offhand) that it's hard to describe the
applicability of this proposal because it's something like a
three-dimensional space with number of IPv4 addresses on the x axis,
number of servers on the y axis, and frequency of access per server
on the z axis.    Perhaps you could model that given your test data, but
could you describe the results in terms that a potential user could
understand and which would still be accurate?

> inhibition against IPv6 transition).

One thing I'll note is that this proposal doesn't have to be
standardized to be used.  That is, it doesn't require any changes to the
appliciations that use this mechanism on either the client or server
end.   All it requires is a NAT and a DNS server that cooperate with one
another, and someone who is willing to try to make a business out of
selling IPv4 access using this mechanism.

Keith