Subject: RE: [tcpm] new internet draft - drafft-touch-anonsec

From: [email-masked]
Date: Thu, 6 May 2004 15:51:18 -0500

>  
> > i.e., Trudy sends a packet with her SPI (SPI2) to Alice, but in the
> inner
> > packet she sends a packet which has IP address of Alice and Bob and
> TCP
> > ports of Alice and Bob. Please also note that Trudy can use just one
> SPI2
> > to attack hundreds of TCP connection that might originate 
> from Alice.
> 
> What you are saying is that one cannot really protect TCP with
> tunnel-mode IPSEC. Duh. Use transport mode.
> 

BTW, does transport mode allows IP in IP? If it does, then we are back to the same attack. Of course one can have policies to stop IP in IP, but this might not be acceptable for a general TCP security solution.

Yogesh

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 06 May 2004 14:05:05 -0700

[email-masked] wrote:

> BTW, does transport mode allows IP in IP? If it does, then we are
> back
> to the same attack. Of course one can have policies to stop IP in IP,
> but this might not be acceptable for a general TCP security solution.
> 
> Yogesh

I was perhaps not specific enough.

It doesn't matter whether you use transport mode or tunnel mode IPsec. 
In either case, there is the possibility of spoofing IN THE ABSENCE OF 
ANY OTHER POLICIES.

I.e., there is nothing to stop a server, running IPsec in either mode, 
of being attacked by packets:
	- in transport mode where protocol=ANY
		(and ports are thus undefined)
	- in tunnel mode where src=ANY in the encapsulated packet

ANONsec weakens IPsec so that any third party can spoof when the 
policies are this open. However, current IPsec allows spoofing among the 
set of truly authenticated sources (e.g., with valid certs signed by 
known CAs). I.e., Alice and Trudy can spoof each other, regardless of 
whether they are signed, in the absence of realistic policies.

It's worth mentioning this in the next version of the draft, certainly. 
This is not otherwise significant IMO since it constitutes running a 
"wide open" IPsec, which is like locking an open door.

Joe

---

From: Mitesh Dalal <[email-masked]>
Date: Thu, 6 May 2004 16:57:53 -0700 (PDT)

> "wide open" IPsec, which is like locking an open door.

Although the solution sound reasonable, I have couple of issues that
I believe should be addressed.

1. Interop issues. In the proposed solutions, both ends need to
support crypto, if they dont, what do you do ?

2. UDP and the relevant ports have to be allowed in the middleboxes.
Any plan to address this problem.

3. Scalability. Are the current crypto solutions designed to handle
thousands of connections ?

4. Configuration and cost issues.

5. The way I see the solution is only a recommendation to the end
user to use the bear minimum of the crypto feature(if they have)
to alleviate this attack. I would assume, that if an end-user
did have crypto, he would be using it anyways depending on his
requirement(AH or ESP, PKI or shared or whatever)

6. I disagree that this has less inertia than the changes that
we are proposing in TCP :)

Thanks
Mitesh

---

From: Joe Touch <[email-masked]>
Date: Thu, 06 May 2004 17:11:41 -0700

> support crypto, if they dont, what do you do ?

IMO, if you want to authenticate the source of packets, both ends need 
to support crypto. All other devices are basically some variant of 
crypto embedded in the (IMO) wrong place.

> Any plan to address this problem.

Middleboxes that end up looking like spoofers are correctly identified 
and defeated. Middleboxes that are proxies would work fine.

> thousands of connections ?

Yes.

> 4. Configuration and cost issues.

I'm trying to reduce configuration and computation overheads. Besides 
that, can you be more specific about costs?

> requirement(AH or ESP, PKI or shared or whatever)

The IPsec community discussed this as I summarized; current IPsec tends 
to require CA agreement, which is considered prohibitive overhead. The 
whole point of ANONsec is to reduce that overhead, so the crypto that 
already exists actually gets used ;-)

> we are proposing in TCP :)

I would be glad to have you back this up with some analysis. Right now, 
TCP represents a ubiquitous installed base that largely defines the 
"Internet". Modifications to the state machines of TCP can - and have - 
tripped legacy implementations in the past, even given substantial 
pre-deployment analysis. The modifications proposed to IPsec do not 
modify the state machine of IKE (I would be equally hesitant to do 
that), which is at least one reason I think this has less inertia.

Joe

---

From: Anantha Ramaiah <[email-masked]>
Date: Thu, 06 May 2004 19:34:46 -0700

<snip>

> "Internet". Modifications to the state machines of TCP can - and have -

Hmm.. Not sure I agree with this for ...

- I guess we need quantify here. How much modifications are we talking
  about to TCP? Are they safe/unsafe? What is the worst case scenario?
  I think these arguments/thoughts has been going on from the time we 
  thought about the TCP secure proposal.

- The changes which is proposed (TCP secure draft) is to make TCP more 
  robust. Agreed we need to address the corner cases and document some
  of those. [Esp the middlebox scenarios, which have been by far the most
  part of concern]

- It appears that if we follow this logic of "no changes (not even minor) 
  to TCP state machine, then I don't think we can ever make changes to TCP 
  because almost any change for a mature protocol like TCP may interfere 
  with the TCP state machine ( may be even marginally) and I think there is 
  no need for any workgroup (TCP maintenance and minor extensions) as such 
  :)

My thinking on this is :

- making TCP robust to benefit the "raw" users of the protocol. By 
"raw user" I mean any client who does not wish to use other "costly" 
methods like ipsec etc., due to deployment constraints. Irrespective 
of whether or not which solutions are going to be pursued I think efforts
need to be made to enhance the robustness of the protocol.

-Anantha

>   ------------------------------------------------------------------------------
>                        Name: signature.asc
>    signature.asc       Type: application/pgp
>                 Description: OpenPGP digital signature

---

From: Mitesh Dalal <[email-masked]>
Date: Thu, 6 May 2004 19:42:09 -0700 (PDT)

> crypto embedded in the (IMO) wrong place.

that what you and I would like it to be, but that is not how it is
out there.

> and defeated. Middleboxes that are proxies would work fine.

I am not sure what you are talking about. What I was referring to is many
organizations have strict UDP blocking in order to prevent udp attacks
like snmp. In order to let ISAKMP through, they would have to allow yet
another protocol and ports for the "handshake" to happen and without
proper configuration, this may lead to more avenues for mischief.
Morever IPSec and NAT are 2 well-known interop beasts in themself.

> > thousands of connections ?

Not the last time I checked. I used to work in the crypto group earlier
and I am well aware of the issues that end users have seen in the past.
This maybe implementation and h/w related, but the technology is not
perfected yet.

> that, can you be more specific about costs?

crypto s/w, h/w and the people who can maintain them cost more than
their vanilla counterparts.

> that), which is at least one reason I think this has less inertia.

If TCP is such a thou-shall-touch-not technology, then it would seem
so much ironical that we should have a WG called tcpm whose charter
is to suggest changes :)

Thanks
Mitesh

---

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

> Morever IPSec and NAT are 2 well-known interop beasts in themself.

Agreed. But then any mod to TCP may not interoperate with middleboxes 
anyway. Middleboxes work in one of two modes:

	a) 'transparent' (NATs fall into this group)
		these ARE spoofers. some users may like them
		(I use them on occasion), but as far as 'defeating
		spoofing attacks' goes, any real spoofing solution
		will almost ensure failure to play nice with this kind

	b) proxies (explicit web proxies fall into this group)
		these should work fine

i.e., some transparent proxies shoot RSTs to 'help' a connection
by cleaning it up; as has been discussed on this list, such behavior can
cause interoperation problems with any mods to RST processing.

basically, such boxes represent legacy components that do worse than use 
a fixed protocol implementation - they usually make assumptions about 
protocol behavior based on current implementations, rather than protocol 
rules per se. any mods to existing behavior can - and usually will - 
trip at least some of them up.

> This maybe implementation and h/w related, but the technology is not

Handling thousands of connections is easy. Handling them fast is not. 
But fast demuxing based on SPI indexing is not substantially different 
from fast demuxing based on TCP port number - anything that has that 
many connections has to handle them fast anyway.

> their vanilla counterparts.

IPsec crypto comes with most modern routers and OS's. Again, the focus 
of the draft is to encourage cheaper use of existing crypto anyway.

> so much ironical that we should have a WG called tcpm whose charter

Having the TCPM WG is not - IMO - carte blanche to change TCP. The cost 
of the mod should be outweighed by the benefit, and take into 
consideration the overall effect.

I.e., modifying TCP's initial windows didn't require mods to the state 
machine. There are other mods that can be negotiated at startup and 
don't operate unless both ends agree. The current proposal is a mod that 
is intended to be deployed unilaterally, makes changes to TCPs state 
machine (adds an arc or more), causes RSTs
to generate responses, and causes valid RSTs from legacy sources to NOT 
reset a connection. These are different beasts.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 06 May 2004 21:07:42 -0700

>   of those. [Esp the middlebox scenarios, which have been by far the most

The change makes TCP try to provide source identity authentication. In 
the process, TCP is less robust in the following way:
	- a valid RST from a legitimate legacy source received at
	an upgraded destination can be ignored (in the sense that
	the connection is NOT reset), and can generate response
	traffic (sending an ACK)

That is not, IMO, robusness per se. That is a change in behavior that 
we've all been analyzing the effects of.

>   no need for any workgroup (TCP maintenance and minor extensions) as such 

TCPM is not carte blanche to modify TCP, IMO. The state machine is a 
place I'm particularly concerned about tinkering. There are lots of 
other places in TCP to 'play' - e.g., large initial windows, the 
windowing operation overall, timeouts, etc.

> need to be made to enhance the robustness of the protocol.

The good news is that TCP mods may help everyone.

The bad news is that we'll all be taking that risk if we're wrong, in a 
sense.

Joe

---

From: Mark Allman <[email-masked]>
Date: Mon, 10 May 2004 10:23:37 -0400

> Having the TCPM WG is not - IMO - carte blanche to change TCP. 

Absolutely agree, FWIW.

allman

--
Mark Allman -- ICIR -- http://www.icir.org/mallman/