Subject: RE: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple AuthenticationOption

From: "Barry Greene \(bgreene\)" <[email-masked]>
Date: Tue, 13 Jun 2006 19:26:56 -0700

Q. Why does BGP use TCP vs the link status? Cause of the ships in the
night layering of the protocols. You want your IGP to have the ability
to fail over links quickly with the BGP session staying up during the
fail over. That is why you have iBGP meshed using the router's loopback
address. 

Is this broken? People who run the Internet seem to like it since it is
the way we're gluing the whole Internet together.

Q. Why isn't IPSEC used? Several reason. The re-keying and hitless
issues I'll leave to Ron and the authors. My core reason is that IPSEC
for a control plane protocol (OSPF, BGP, etc.) makes the router
EXTREMELY vulnerable to a DOS attack. We're not talking about Mpps or
Kpps attacks. We're talking about Hpps attacks that will have to bypass
all the layered protection mechanisms built into a router to give it
protection against this sort of abuse.  draft-bonica-tcp-auth-04.txt
allows the layered protection (combinations of classifications,
policing, and hard queuing) to remain - doing the security checks as
close to the conversion of photonic/electrical to packets as is feasible
possible in hardware. 

Q. Why do you need a timer in the solution? Telco meets. "Telco meets"
are when to operators have to schedule a exact time to meet and
configure equipment which touches each other. They are a pain to
schedule and a huge OPEX cost to both parties. What the operators want
to do is re-key and notify the other side that their new key is in
place. At some time period later, the other side configures their new
key. This could be days later. 

The expense of the telco meets are one of the key reasons why you have
MD5 keys on networks that are TEN YEARS OLD! 

Q. Why do you need a hitless re-keying?  Today many SPs have to report
customer perceivable outage to their network to their telecoms
regulator. Tomorrow with the continued convergence of services on top of
IP, even the minor "non-perceivable - but measurable outages" will be
required to be reported. So the seconds it takes to rebuilt, packets
dropped, and recovery time it takes for OC192 connection's BGP session
to be "re-key" is just too costly. 

Do they want to re-key? Yes. Can they afford to re-key? Not today and
definitely not tomorrow.

Q. Why can't BGP Graceful Restart be used? When you look at the top SPs
in the world (see below), you find that few to no SPs are planning on
BGP Graceful Restart deployments. Some considered when looking at it as
a security tool (after the April 2004 TCP vulnerability advisory). Most
see no big operational savings on their networks - making it really
tough to justify planning time, testing, pre-deployment, and maintenance
windows to get it deployed. 

So a basic requirement is no BGP Graceful Restart. 

Next questions?

Barry

rank	as	org	                        country	s-c	p-c
a-c	n
1	701	UUNET Technologies, Inc. 	US	6,940,288
177,765	19,386	2,371
2	174	Cogent Communications 	      US	5,164,137
173,111	19,433	1,335
3	7018	AT&T WorldNet Services 	US	5,085,014	173,438
19,142	2,003
4	1239	Sprint 	US	5,058,048	173,686	19,240	1,697
5	2914	Verio, Inc. 	US	4,955,427	169,478	18,694
457
6	3561	Savvis 	US	4,794,705	164,726	18,030	540
7	209	Qwest 	US	4,790,916	164,036	17,920	1,161
8	703	UUNET Technologies, Inc. 	US	4,681,719
159,585	17,165	183
9	3549	Global Crossing 	US	4,659,580	162,217
17,711	741
10	3786	DACOM Corporation	KR	4,649,565	160,775
17,347	270
11	2828	XO Communications 	US	4,649,129	160,414
17,420	472
12	702	MCI EMEA 	NL	4,640,429	160,222	17,229
542
13	4436	nLayer Communications, Inc. 	US	4,606,467
158,980	17,127	62
14	3356	Level 3 Communications, LLC 	US	4,606,335
158,963	17,120	1,290
15	4323	Time Warner Telecom 	US	4,606,335	158,963
17,120	605
16	3303	Swisscom Enterprise Solutions Ltd	CH
4,606,335	158,963	17,120	582
17	6939	Hurricane Electric 	US	4,606,335	158,963
17,120	518
18	6461	Abovenet Communications, Inc 	US	4,606,335
158,963	17,120	495
19	13237	European Backbone of LambdaNet	DE	4,606,335
158,963	17,120	436
20	8220	COLT Telecommunications - www.colt.net	NL
4,606,335	158,963	17,120	408
21	1299	TeliaNet Global Network	SE	4,606,335	158,963
17,120	379
22	6395	Broadwing Communications Services, Inc. 	US
4,606,335	158,963	17,120	369
23	6453	Teleglobe Inc 	CA	4,606,335	158,963	17,120
341
24	3320	Deutsche Telekom AG	DE	4,606,335	158,963
17,120	338
25	7911	Williams Communications Group 	US	4,606,335
158,963	17,120	333
26	3491	Beyond The Network America, Inc. 	US
4,606,335	158,963	17,120	330
27	19151	WV FIBER LLC		4,606,335	158,963	17,120
296
28	286	KPN Internet Backbone AS	NL	4,606,335
158,963	17,120	291
29	16150	Port80 AB, Sweden	NL	4,606,335	158,963
17,120	281
30	2516	KDDI	JP	4,606,335	158,963	17,120	280
30	6539	GT Group Telecom Services Corp. 	CA
4,606,335	158,963	17,120	280  

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]] 
> Sent: Tuesday, June 13, 2006 5:11 PM
> To: Barry Greene (bgreene)
> Cc: Andrew Lange; [email-masked]; [email-masked]
> Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple 
> AuthenticationOption
> 
> 
> 
> Barry Greene (bgreene) wrote:
> >  
> > 
> >> Those modifications are already underway or implemented in the 
> >> primary protocol of interest (BGP). These modifications 
> reflect (IMO) 
> >> an error in protocol design: TCP connectivity was never 
> intended to 
> >> reflect path viability for routing.
> >> Interpreting TCP disconnects as a path failure - which is the only 
> >> reason to flush the associated routes - is thus an error 
> which it is 
> >> appropriate to correct.
> > 
> > But why is it your job to correct your perception of a design error 
> > that the operators have no desire to change?
> 
> We're the standards community; if there's an error in one 
> standard (BGP) that creates a problem for another (TCP/MD5 
> needing to rekey
> mid-session) then it is we who resolve that contradiction.
> 
> > Operators submitted their design and expectation 
> requirements to three 
> > vendors. Those vendors went off, explored a variety of options, and 
> > came up with a proposal (draft-bonica-tcp-auth-04.txt). The 
> Operators 
> > then said "good, make it happen."
> 
> That's between vendors and operators; if you want the IETF 
> involved, you need to expose that loop to the community as per below.
> 
> > Now all I'm seeing from all parts of the IETF is "this is the wrong 
> > way to do it cause it does not fit how we perceive the 
> Internet to be 
> > operated." I'm puzzled.
> 
> We're equally puzzled as to why IPsec isn't sufficient as an 
> alternative, since this is precisely what it was designed to 
> do. Perhaps that's because we haven't been presented with the 
> operator's requirements - which, BTW, need to be in the form 
> of _WHAT_ they need, not _HOW_ to accomplish it. We haven't 
> been presented with that yet; to the extent that we have seen 
> glimpses of their requirements, we still don't understand why 
> a TCP solution is required, or if so why rekeying inband is required.
> 
> Further, I'm personally puzzled at the use of time-based keys 
> - which add a notion of time that TCP doesn't have (TCP has 
> timeouts, not time), and are not how other rekeying systems 
> work (e.g., IKE).
> 
> Answers to those would be a start.
> 
> Joe
> 
> 

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

---

From: Joe Touch <[email-masked]>
Date: Wed, 14 Jun 2006 07:16:12 -0700

> fail over. That is why you have iBGP meshed using the router's loopback

Whether IGP fails over with BGP staying up depends on the protocols
either uses to determine failure. There's no reason that link status
alone would be used for BGP; indeed, layering suggests that a separate,
tunable protocol would be appropriate to determine whether the other
party is path-reachable rather than just link reachable.

However, TCP isn't that protocol. As I noted before, that's a known
error in design; there's nothing in TCP that is designed to ensure that
a connection stays up if the other end is intermittently reachable.

> Is this broken?

Because it is based on an incorrect assumption, as noted above.

> People who run the Internet seem to like it since it is

That's not how we in the IETF define correctness.

> close to the conversion of photonic/electrical to packets as is feasible

IPsec hardware is available. Turning on any security leaves a device
vulnerable to CPU load attacks; how is this different from TCP-Auth?
Packets in TCP-Auth are filtered based on IP addresses and port pairs
before being (expensively) authenticated. IPsec packets are filtered
based on IP addresses and the SPI; the SPI is 32 bits that are
arbitrary, wheras TCP's ports have only 16 arbitrary bits (source port).

Is there some other technical reason that TCP-Auth is easier to filter
thank IPsec?

> key. This could be days later. 

Why are operators involved in rekeying at all?

> MD5 keys on networks that are TEN YEARS OLD! 

That's indicative of a number of things, including ignorance as to why
rekeying is needed and apathy given the lack of ongoing attacks.

> to be "re-key" is just too costly. 

I agree with all this, but that is just why graceful restart BGP is the
assumption.

> So a basic requirement is no BGP Graceful Restart. 

This is the most telling. So basically you're telling us that SPs are
not willing to accept (existing) BGP graceful restart due to deployment
costs and lack of operational savings.

Exactly what is the basis for believing that they would accept TCP-Auth?
It is extraordinarily more complex (than graceful restart +
TCP-simple-auth).

> Next questions?

All stated above. So far, all you've done is confuse us as to why you
want a solution at all (your last point), and why one of BGP/GR +
TCP-simple-auth or BGP + IPsec/IKE is less acceptable than TCP-Auth.

Joe