Subject: [Ipsec] new internet draftt - draft-touch-anonsec

From: Joe Touch <[email-masked]>
Date: Thu, 06 May 2004 08:51:52 -0700

Hi, all,

The following I-D is soon to appear in the drafts directory; until then, 
here is the title and abstract, and it is available now at:

	http://www.isi.edu/touch/pubs/draft-touch-anonsec-00.txt

At this time, I'm soliciting discussion and feedback on both TCPM and 
IPsec mailing lists, where discussion of the issues of IPsec have been 
ongoing. I track both lists; please do NOT cross-post. I'll 
cross-summarize periodically if it proves necessary.

I'd also like to solicit input on in which WG to proceed.

Joe

----

       ANONsec: Anonymous IPsec to Defend Against Spoofing Attacks
                           draft-touch-anonsec

    Recent attacks on core Internet infrastructure indicate an increased
    vulnerability of TCP connections to spurious resets (RSTs).  TCP has
    always been susceptible to such RST spoof attacks, which were
    indirectly protected by checking that the RST sequence number was
    inside the current receive window, as well as via the obfuscation of
    TCP endpoint and port numbers. For pairs of well-known endpoints
    often over predictable port pairs, such as BGP, increases in the path
    bandwidth-delay product of a connection have sufficiently increased
    the receive window space that off-path third parties can guess a
    viable RST sequence number. This document addresses this
    vulnerability, discussing proposed solutions at the transport level
    and their inherent challenges, as well as existing network level
    solutions and the feasibility of their deployment. Finally, it
    proposes an extension to IPsec configuration called ANONsec that
    intends to efficiently and scalably secure any transport protocol
    from such off-path third-party spoofing attacks.

----

---

From: "Bora Akyol" <[email-masked]>
Date: Fri, 7 May 2004 09:39:38 -0700

Joe

What is the difference between AnonIKE and having the same
pre-shared key (as in preshared_key ="anonIKE") in all of the points of
interest?

I think this would get you the same effect. I also fail to see what is 
so scary about adding the ACK response to RST to TCP as described in
tcpm draft that came out. Your argument in the draft does not 
actually show a fundamental problem with this approach.

Finally, as is widely discussed, IKEv1 is not the most robust protocol
as far as responsiveness to DOS attacks. By requiring these nodes to do
IKE, I think we would opening ourselves up for more problems.

Regards,

Bora

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: "Bora Akyol" <[email-masked]>
Date: Fri, 7 May 2004 09:39:38 -0700

Joe

Regards,

Bora

---

From: Joe Touch <[email-masked]>
Date: Fri, 07 May 2004 10:20:57 -0700

> pre-shared key (as in preshared_key ="anonIKE") in all of the points of

That's something we're looking into. Far as I can tell right now, using 
unauthenticated certificates (i.e., where the CA isn't checked) is 
equivalent to a longer nonce. There may be some value to using a longer 
nonce - I don't know enough about the diffie-hellman exchange to 
determine that. Otherwise, though, they should be equivalent.

> actually show a fundamental problem with this approach.

The draft is not intended to go into that level of detail, but to refer 
to discussions on the TCPM mailing list which will hopefully go into an 
update of the RST-modification draft.

One concern is a RST ACK storm. A RST is intended to be a unilateral 
connection abort; replying to that sort of thing, depending on the state 
of the source, can cause oscillation.

> IKE, I think we would opening ourselves up for more problems.

I don't appreciate enough of the details between IKEv1 and IKEv2 to 
understand whether that would solve the problem.

I would presume that IKE would be rate-limited, i.e., the same way SYN 
processing is for TCP, to protect new association requests from 
assaulting existing associations. Is that the issue with DOS for IKEv1, 
or is there something more specific?

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 07 May 2004 10:20:57 -0700

Joe

---

From: "Bora Akyol" <[email-masked]>
Date: Fri, 7 May 2004 10:50:45 -0700

Hi Joe

I will subscribe to the tcpm list for the details on the RST ACK storm,
I guess this could be used as an amplifier for an attack if I understand
you correctly.

See below for comments on IKE
> or is there something more specific?
IKEv1 creates state for each new connection on the first packet, so does
IKEv2
unless the cookie option is used which is left as a non-mandatory
feature
in the draft only to be activated when the system detects its under
attack.

Due to this, I think moving the security problem down to IKE does not
solve
it, it just shifts it.

Thanks for your comments,

Bora

---

From: "Bora Akyol" <[email-masked]>
Date: Fri, 7 May 2004 10:50:45 -0700

Hi Joe

Bora

---

From: Joe Touch <[email-masked]>
Date: Fri, 07 May 2004 11:06:16 -0700

Bora Akyol wrote:

...
> solve it, it just shifts it.
> 

Hi, Bora,

The revision to the draft will address this in further detail. Some 
initial thoughts:

	1) ANONike costs more in open SPIs and messages, but a lot
	less in certificate validation costs vs. using a known CA
	(though as before the difference - if any - between ANONike
	and preshared fixed keys should be examined further)

	2) I heartily agree that this shifts the problem, IMO to
	a place that ought to be optimized to handle it. I.e.,
	moving it to IKE means we solve it once, at least for
	attacks from off-path spoofers

	3) if you have an on-path attack, you really just have
	load - notably since I'm assuming you turned on ANONsec
	because you're running a publicly available service

	shedding load for public services is also a well-known
	issue, and certainly needs to be considered. ANONsec
	helps avoid the off-path attacks, not the on-path
	from parties willing to setup full associations,
	either at the IPsec or TCP layers

Joe

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 May 2004 13:53:10 -0400

>>>>> "Bora" == Bora Akyol <[email-masked]> writes:
    Bora> Finally, as is widely discussed, IKEv1 is not the most robust protocol
    Bora> as far as responsiveness to DOS attacks. By requiring these nodes to do
    Bora> IKE, I think we would opening ourselves up for more problems.

  IKE in aggressive mode has that property.
  That's why smart people don't use that.

--
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Joe Touch <[email-masked]>
Date: Fri, 07 May 2004 11:06:16 -0700

Bora Akyol wrote:

...

Hi, Bora,

Joe

---

From: "Bora Akyol" <[email-masked]>
Date: Fri, 7 May 2004 11:29:42 -0700

1) MM has its own issues coupled with the fact that it takes 6 messages
to get anything done. What's next, a MM exchange for each DNS request.
2) If the DOS attacks are coming from machines that are "owned" MM
has very similar properties to aggressive mode.
3) IKE for the purpose of off-path transport layer attacks is 
like using a jack hammer to drive a thin nail on a picture frame.
4) The proposed approach which is really equivalent to a pre-shared key
that is hard coded into every IKE implementation opens us up for even
more issues.

I think the basic idea has merit, i.e. for certain 
applications the receiver must be in control of who it talks to.
I am not sure IKE is the way to go for this.

Bora

> -----Original Message-----
> From: Michael Richardson [mailto:[email-masked]] 
> Sent: Friday, May 07, 2004 10:53 AM
> To: Bora Akyol
> Cc: 'Joe Touch'; 'ipsec mailingList'
> Subject: Re: [Ipsec] new internet draftt - draft-touch-anonsec 
> 
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 May 2004 13:53:10 -0400

---

From: "Bora Akyol" <[email-masked]>
Date: Fri, 7 May 2004 11:29:42 -0700

Bora

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 May 2004 14:43:36 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Bora" == Bora Akyol <[email-masked]> writes:
    Bora> 1) MM has its own issues coupled with the fact that it takes 6 messages
    Bora> to get anything done. What's next, a MM exchange for each DNS
    Bora> request.

  a) we've done that, and it isn't as bad as you might think.
     There is a bootstrap issue if you are getting keys from DNS.

  b) MM for each new TCP connection that a router does isn't really that
     much of a deal. Routers do not talk TCP to many systems.

    Bora> 2) If the DOS attacks are coming from machines that are "owned" MM
    Bora> has very similar properties to aggressive mode.

  That's true.
  But, that's why IKE implementations needs to manage themselves very
carefully.  The point is to take all of our knowledge about how to
defend against DDoS attacks and put it into one place so that we don't
have to keep putting this into every protocol.

    Bora> 3) IKE for the purpose of off-path transport layer attacks is 
    Bora> like using a jack hammer to drive a thin nail on a picture
    Bora> frame.

  Defending against such attacks will become more and more important.

    Bora> 4) The proposed approach which is really equivalent to a pre-shared key
    Bora> that is hard coded into every IKE implementation opens us up for even
    Bora> more issues.

  Yes, I agree. I'm not crazy about Joe's approach either.
  I know we can do better, because we have already done better.

- --

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 May 2004 14:43:36 -0400

-----BEGIN PGP SIGNED MESSAGE-----

  That's true.

- --

---

From: Joe Touch <[email-masked]>
Date: Fri, 07 May 2004 13:10:35 -0700

Michael Richardson wrote:

...
>   I know we can do better, because we have already done better.

Can you be a little more specific about such alternatives?

If there are alternatives that suffice for anonymous exchanges, please 
indicate what they are in addition to asserting their benefit (if it's 
equivalent, then it's not better ;-) - I'd prefer to use an existing 
approach, especially one I can cite.

Thanks,

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 07 May 2004 13:10:35 -0700

...

Thanks,

Joe