Re: [tcpm] [OPSEC] draft-gont-tcp-security

["Smith, Donald" <[e-mail]>]

(coffee != sleep) & (!coffee == sleep)
[e-mail] gcia   

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of Joe Touch
> Sent: Monday, April 13, 2009 3:02 PM
> To: Fernando Gont
> Cc: [e-mail]; [e-mail]; Joe Abley; [e-mail]; 
> Lars Eggert; Eddy,Wesley M. (GRC-RCN0)[Verizon]
> Subject: Re: [OPSEC] [tcpm] draft-gont-tcp-security
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Fernando Gont wrote:
> > Joe Touch wrote:
> > 
> >>> So we had tcp-secure in 2004, icmp-attacks in 2005, a claim for a
> >>> trivial attack in 2008 (Outpost24/CERT-FI), and we'll 
> probably continue
> >>> in this line, because we do nothing about it.
> >> Whether we have this document or not, we will continue to 
> have people
> >> who incorrectly assume that TCP is secure.
> > 
> > That's correct. But we also have people that do know it is 
> not mean to
> > be secure, but that it should be resilient enough so that it's still
> > usable. One way or another, most stacks implement 
> counter-measures for
> > SYN-floods (on which tcpm did publish something), timers on the
> > FIN-WAIT-2 state, port randomization (on which tsvwg is 
> working), ICP
> > ISN randomization, etc.
> > 
> > The reason for which they did that was to improve TCP's 
> security/resiliency.
> > 
> > Would you argue in favour of predictable ISNs, predictable ports,
> > time-less FIN-WAIT-2 state, etc.? -- I hope you wouldn't.
> 
> These measures can be used to reduce the impact of attacks when TCP is
> not secured. However, they DO NOT make TCP secure. They DO 
> make TCP more
> brittle - they limit the way in which two legitimate endpoints can do
> legitimate things.
> 
> >>>> It summarizes issues already raised by the WG, 
> >>> I believe this statement is unfair with respect to our 
> document. e.g.,
> >>> has the issues described in Section 4.3, Section 9.2, or 
> Section 10 been
> >>> brought to tcpm before???
> >> I didn't say that's all it does ;-) Agreed that it raises 
> other issues,
> >> many of which are operational.
> > 
> > Many of which arise if you expect to use TCP in some other 
> scenario that
> > just two computers in a LAN. If that makes those issues 
> "operational", I
> > agree.
> 
> Many of those don't arise for computers in a wide area, or 
> with millions
> of other computers on the network either. They arise only 
> when there are
> active attacks, and only for some kinds of attackers 
> (on-path, off-path,
> high-speed access, etc.)
> 
> IMO, any decision which would be enabled or disabled depending on
> whether security was a concern or performance was needed is 
> operational.
> E.g., port randomization helps only when attackers are 
> off-path and when
> port use is a fraction of the active port space. That's operational.
> Ditto for ISN randomization.
Given that this is opsec and that my major concern is the network elements 
I am much more concerned about "off-path" or "blind attacks" then direct attacks.
Customers generally don't attack the router they are connected to.
Peers generally don't attack the router they are connected to.

> 
> I.e., if the protection is not needed in the absence of 
> attacks, it may
> be operational.
> 
> >>>> TCP itself is not a secure protocol, nor is it intended to be.
> >>> Yeah. But that does not mean that we should not do our 
> best to improve
> >>> it.
> >> It means we should not try to give the incorrect impression that it
> >> *can* be secured. 
> > 
> > It's security/resiliency can be improved. After all, if 
> that were not
> > the case, I guess you're wasting your time with TCP-AO. Or 
> is it that
> > you believe the only way to improve a protocol is to throw 
> crypto at it?
> 
> I *know* that the only way to secure a protocol is to throw 
> crypto at it.
Now I think I understand what you mean by secure.
I don't agree with your opinion. For example SSL is a form of encryption but has done little to
secure http as sites have trained customers to ignore cert errors.
Banks put lock bitmaps on their pages to show how "safe" they are.
Phishers depend on this user confusion!

> 
> I also *know* that unexpected packets are *not* indications 
> of attacks.
In the router world packets destined towards my routers that are "unexpected" are often
an indication of attack or a misconfigured system either can cause problems for the network and blocking it TOWARDS the router is a BCP.

> 
> These two things are not evident in this document, and should be.
> Further, this document should make a case as to whether the 
> improvements
> are operational or not. AFAICT, most are operational.
> 
> >> Interpreting every unexpected event as an attack makes
> >> a protocol robust but also brittle; TCP is intended to 
> trade flexibility
> >> for security, AFAICT, because it is agnostic about intent, 
> and gives the
> >> benefit of doubt at all times. 
> > 
> > I would prefer that instead of making this type of broad 
> statement, you
> > would argue against a particular recommendation in
> > draft-gont-tcp-security, and explain how it makes TCP more brittle.
> 
> Randomizing ports and ISNs assumes there is a window over which some
> values are NOT used; that window precludes legitimate exchanges from
> occurring. That is what I mean by "brittle."
> 
> >> Consider packet drops. That can happen due to loss, non-malicious
> >> corruption, or jamming, e.g. In the last case, it makes 
> sense to blast
> >> copies of packets in the hopes of getting something 
> through, but that's
> >> NOT what we assume.
> > 
> > Wasn't this very behavior what lead to the Internet 
> congestion collapse
> > in the 80's, or am I missing something?
> 
> Loss of a segment can mean:
> 	a) congestion (correlated drops)
> 	b) non-correlated drops (not related to increasing traffic)
> 	c) active removal (attack)
> 
> If (a), then you backoff. That's how congestion collapse was 
> addressed.
> 
> If you believe that packet drops are caused by either non-correlated
> drops or active removal, you send MORE - you send copies of 
> each packet,
> e.g. That is NOT what we assume, but what I presume you ought to
> recommend in a document that assumes that every event that COULD have
> been an attack probably is an attack.
> 
> >>> Please talk to vendors. I don't want to reproduce here 
> what seems to
> >>> be the consensus among vendors with respect to the 
> current state of
> >>> affairs in terms of how up-to-date our specs are.
> >> Vendors misapply our protocols then complain that they 
> don't work. Yes,
> >> there are operational issues, but one severe operational 
> issue is not
> >> using security for some policy, financial, or operation 
> expense and then
> >> complaining that nonsecure TCP is being attacked.
> > 
> > Joe, we're talkng about a simple web server being taken 
> down because of
> > a SYN flood, a FIN-WAIT-2 flood, or the like. Even the most 
> stupid web
> > server should survive these types of attacks.
> 
> If you're talking about implementation advice (don't put all your
> resources in pending connections), I agree that a good implementation
> should be implemented well. But that's operational / implementation
> advice, not protocol advice.
> 
> I do not agree that all web servers should implement SYN cookies, e.g.
> 
> Joe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAknjqFYACgkQE5f5cImnZrtBNwCgiJPsTDBt34Im+s/TFkBm90DE
> Xn4AoNlUvCAucvZoVVMTpex4sMXAaXb2
> =1ijT
> -----END PGP SIGNATURE-----
> _______________________________________________
> OPSEC mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsec
>