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
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.
rank as org country s-c p-c
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
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
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
10 3786 DACOM Corporation KR 4,649,565 160,775
11 2828 XO Communications US 4,649,129 160,414
12 702 MCI EMEA NL 4,640,429 160,222 17,229
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
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
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
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
24 3320 Deutsche Telekom AG DE 4,606,335 158,963
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
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
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:touch@xxxxxxx]
> Sent: Tuesday, June 13, 2006 5:11 PM
> To: Barry Greene (bgreene)
> Cc: Andrew Lange; tcpm@xxxxxxxx; mallman@xxxxxxxx
> Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple
> 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
> > 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.
tcpm mailing list