GROW WG - IETF63
Global Routing Operations WG (grow)
Minutes of GROW WG Meeting at IETF63
Monday, August 1 at 1815-1945
Chairs:
Geoff Huston <gih (a) apnic.net>
David Meyer <dmm (a) 1-4-5.net>
Notes:
Spencer Dawkins <spencer (a) csr-labs.org>
NOTES
1. Administrivia
- Mailing list: majordomo@lists.uoregon.edu "subscribe grow"
2. Agenda Bashing
3. Review and status of work items
4. Potential New Work
draft-dubois-bgp-pm-reqs-01.txt - Dubois
- Would like to have "make before break" BGP4 behavior. Currently BGP4
loses packets while peers look for alternate paths during shutdowns,
etc.
- What are the interactions with other new BGP4 capabilities?
David Meyer - Not enough people in this room expressing opinions
to get a sense of the room on bringing this into the working
group.
Geoff - is this a proposal for an internal mechanism for a router,
and not a protocol activity?
5. BGP Operational Security
Geoff Huston
- Need to understand the goals - protect router protocols and
infrastructure? Protecting the protocol payload?
- How do you know the routes you are getting are authentic and accurate?
The system we have today is relatively insecure, vulnerable to
corruption and to subversion.
- Rough trust and datamining through WHOIS records isn't nearly sufficient
for security. Basic data isn't good data, so you can't go anywhere based
on it.
- BGP4 should still be a "black box" protocol, and should still be "near
real time".
- Start doing the work now, don't wait for the protocol to catch up.
Signing routing requests would be good. Authorization of advertisements
would be good.
- Next steps? PKI for IP addresses and AS numbers, certificate repository
infrastructure, operational tools, signature information of BGP Update
attribute.
- Is there interest in GROW in working on specifications and descriptions
of tools?
WG Commments:
- can't help with the specification, but this is interesting.
- is this PGP for BGP? depends on where the trust anchors are... rings
of trust would be hard!
- something to improve this mess is different. Details still need to be
worked out. A routing registry that runs an authentication /
authorization scheme gets you partially there, and not all the
routing registries are totally devoid of data quality.
- who would pay for the PKI? Who would pay for it? IANA, RIRs, ISPs,
further allocations... people at each level pay for their part?
- why not S-BGP? You need the certificate infrastructure no matter
what, maybe we don't need to wait for the protocol.
- We are at such a sad state that it doesn't matter what we do - we
couldn't make things worse!
- There are existing groups with some congruence here - SO-BGP looked
at rings of trust, but you're never sure if the ring is really
trustable!
- The problem is political, not technical (not JUST technical). That's
the obstacle. If operators say "we need this", that would help a lot.
Although RIRs cooperate, they tend to be independent and want to
remain that way. A ring of trust might be easier to start with.
- Problem is worse than you think - anyone who was involved with RPS
has seen this movie. What has changed in five/ten years? Big players
wouldn't buy in then, and if they don't, it's not worth doing. Maybe
doing the least that is still useful is a good part.
- If all parties don't have keys on day 1, we still have to handle
this...
- These problems seem to be solved in all of the BGP proposals. Once
you know what you want to carry in BGP, carrying it is trivial.
- Will follow up on the mailing list and get more views.
- Lots of interest in the topic expressed in the room...
6. SHIM6 update
Kurtis Lindqvist
-
Meeting at this IETF for the first time (this is a continuation of
MULTI6, producing protocol specifications). Eight documents resubmitted
as SHIM6 drafts.
- A lot of questions remain - state management, identifier
characteristics, locator pair detection, etc.
7. Routing Convergence: An Update
Lixia Zhang
- Reporting measurements on BGP slow convergence... controlled experiments
and simulations say this can be really bad, but we need real data.
- Measured the routing changes of ALL prefixes visible from one of 28
routeview collectors in Oregon - will add more later, plus RIPE data.
- Methodology - group events, classify based on before/after AS paths,
calculate update count and duration of different types of events.
- Categories - same path, path disturbed during the event (but not after),
and path changed after event.
- Sometimes "slow convergence" is no convergence - policies point to one
path, unless you have multiple providers.
- The further you are down in the hierarchy, the more paths you see over
time.
- Tier-1 to Tier-1 convergence is pretty quick. Tier-5 to Tier-5 is NOT!
- 90-95% converge in 2.5 minutes, but there's a long tail (15 minutes,
even longer in extreme cases).
- False flap dampening also more likely to happen at lower tiers.
8. BGP Status Report
Geoff Huston
- Back to 160,000 entries, back to accelerating growth just like the 1999
- 2001 period. But this isn't just fragmenting prefixes this time, it's
announcing new address spaces. Number of more-specifics isn't
accelerating - this isn't the source of the problem.
- Linear growth in AS numbers - we'll run out of two-byte numbers in 2010,
ask your vendors when they are implementing four-byte numbers.
- IPv6 addresses is slowing leaving the 6Bone, RIR allocations have
significant step functions in announced address spaces.
- 10 ASes that originate ONLY IPv6 prefixes.
Geoff Huston - Is 4-byte draft stable? It's only getting new dates on
the last three revisions.
Bill Fenner - we need implementations to move this forward
Geoff Huston - but I am lead to understand that there will be no
implementations from vendors until customers demand it, customers
don't demand it until it's obviously a current problem and there's an
RFC to quote, so no code is released before the time when we have
already run out - a looming problem for 2010!
Sue Hares - we can help with numbers for implementors...
Bill Fenner - we may change the RFC publication rules so we don't hang
indefinitely waiting for implementations.
|
