[09:27:14] --- tskj has joined
[09:27:23] --- tskj has left
[09:27:28] --- tskj has joined
[11:04:47] --- jtk has joined
[11:04:47] --- jlcjohn has joined
[11:06:16] --- jtk has left
[11:09:48] --- nm has joined
[11:11:14] --- jtk has joined
[11:11:52] --- jeffa has joined
[11:15:24] <jeffa> http://www.1-4-5.net/~dmm/IETF/IETF63/GROW/agenda/
[11:15:27] --- ggm has joined
[11:15:59] <ggm> Geoff and Dave in the chair(s)
[11:16:03] --- nm has left: Replaced by new connection
[11:16:03] --- nm has joined
[11:16:04] --- nm has left
[11:16:17] --- nm has joined
[11:16:23] <ggm> http://www.1-4-5.net/~dmm/IETF/IETF63/GROW/agenda
[11:16:52] <ggm> GIH: outta here by 7;45 if we can.
[11:17:20] <ggm> nobody cares about me
[11:17:30] <ggm> (jabber scribe that is)
[11:17:50] <ggm> slides (see agenda URL) being walked through
[11:17:57] <jlcjohn> (The audio is actually working for me...)
[11:18:25] <ggm> 2 new potential drafts, bgp-pm and operational security (geoff and dave)
[11:18:35] <ggm> <glad to know its working>
[11:18:44] <ggm> work items status reports
[11:18:55] <ggm> embedded address is published, in BCP
[11:19:08] <ggm> bgp wedgies and collection-communities in RFC-ED q
[11:19:24] <ggm> bgp-med-considerations and rfc1519bis in AD evaluation
[11:19:47] <ggm> active drast discussions.
[11:19:55] <ggm> kurtis talks to the anycast draft.
[11:20:29] <ggm> revised version out. major updates are removal of wierd anycast V6 limitations (v6 addrarch fixed this)
[11:20:43] <ggm> additional security section on anycast stuff
[11:20:52] <ggm> time to last call it again
[11:20:58] --- nm has left: Replaced by new connection
[11:20:59] --- nm has joined
[11:20:59] --- nm has left
[11:21:02] <ggm> chair: too small sample size
[11:21:11] --- nm has joined
[11:22:30] <ggm> refs to anycast coming in from other groups.
[11:23:46] <ggm> larry blunk on MRT status
[11:24:15] <ggm> reminds us its a simple binary format for recording routing info with timestamps
[11:25:07] --- nm has left: Replaced by new connection
[11:25:07] --- nm has joined
[11:25:07] --- nm has left
[11:25:20] --- nm has joined
[11:25:27] <ggm> bunch of updates done to cover ISIS, microsecond timestamps etc. quite a few implementations out there. toolkits
[11:25:37] <ggm> routeviews/RIS use it
[11:26:46] <ggm> little/no impl experience with OSPF, RIP/RIPng. need IANA typecodes
[11:26:51] <ggm> not the most efficient format. duplicated data. some caching could improve things
[11:27:33] <ggm> mechanisms for capture. sh ip bgp or syslog, could be better?
[11:27:44] <ggm> microsecond timestamps, only added for ISIS/BGP. needed for other protos?
[11:28:24] <ggm> kessins, AD
[11:28:28] <ggm> (ops/mgt)
[11:28:40] <ggm> let creep into GROW, normally don't do protos here. keep things simple.
[11:30:04] <ggm> dubois on requirements for maint on planned maintenance on BGP sessions
[11:30:27] <ggm> shut down bgp nicely
[11:30:57] <ggm> limit traffic loss. limit operational burden. (when impacting the forwarding plane, with backup paths available)
[11:33:00] <ggm> promoting a 'make before break' form of cutover to avoid packetloss when prime link is shut down
[11:34:05] <ggm> propose graceful redirect of packets for next-hop expected to become unreachable
[11:34:30] <ggm> some should/must language implied about this, concerns about loops
[11:35:07] <jlcjohn> The draft is rather tolerant of possible loops -- seems like a problem...
[11:35:22] <ggm> issues: interactions with other BGP mechanisms, including new ones. maybe exploit existing features to do this instead of re-inventing the wheel.
[11:35:39] <ggm> avoid protocol changes if possible
[11:35:57] <ggm> draft lists use-cases, situations to model.
[11:36:11] <ggm> asking for WG interest, adoption, take to ML
[11:36:38] <ggm> Dave. (chair) how many read (some hands) of them, how many for adopt (a few)
[11:36:50] <ggm> Dave thinks too small sample, not clear
[11:37:17] <jlcjohn> It's an interesting topic, but too vague to judge.
[11:37:20] <ggm> Geoff: clarification. what you're saying, looking for graceful mechanism for planned outages,
[11:37:36] <ggm> dubois, yes, but not full-on 'graceful restart as we have'
[11:37:58] --- nm has left: Replaced by new connection
[11:37:58] --- nm has joined
[11:37:59] --- nm has left
[11:38:02] <ggm> Geoff so is this mechanism inside BGP, saying, 'adjacent RIB not viable, re-compute then shut down adjacent rib'
[11:38:52] <ggm> dubois many ways to do, could be done with some existing capabilities. many possible solutions
[11:38:57] <ggm> Christian Huitema.
[11:39:11] <ggm> just listed reqts. haven't done any even intermediate conclusions yet.
[11:39:28] <ggm> Dubois yes. lots of potential ways of doing something. but not stated in draft
[11:39:33] <ggm> Christian and lots of problems
[11:40:02] <ggm> Dave/Geoff. thinking about what we can take on for securing BGP. Geoff has issues slides.
[11:40:11] <ggm> Geoff: operational perspective of BGP security
[11:40:25] <ggm> <dubois de-mikes>
[11:40:30] <jlcjohn> Are there slides online?
[11:40:54] <ggm> Geoff asks is profit 1/10/1000 dollars per year
[11:41:01] <ggm> much laughter
[11:41:08] <ggm> security is a cost. it doesn't earn, you spend.
[11:41:15] <ggm> so you do 'just enough'
[11:41:28] <ggm> <dunno. will try and find out>
[11:41:51] <ggm> risk management: its not about being absolute. its mitigation. trade-offs.
[11:42:06] <ggm> making informed/reasoned judgements.
[11:42:39] <ggm> need to understand the threat model. the mights, consequences etc.
[11:42:45] <ggm> what are we trying to do:
[11:43:07] <ggm> project the protocol and its operation. make routers harder to get to. hard to destroy. (need secrets etc) protect the infrastructure.
[11:43:12] <ggm> most do reasonable job.
[11:43:36] <ggm> but what about the payload? wrong address.. globally propagated. typos happen all the time. only difference from attack is motivation
[11:43:55] --- nm has joined
[11:44:03] <ggm> so need to protect corrutped info from getting in. the wrong prefix (eg yours) with my AS (because I want to see it) or leave alone, wrong reachability, so I pass it on.
[11:44:06] <ggm> thats the harder bit
[11:44:21] <ggm> threat is corrupting the forwarding tables.
[11:44:53] <ggm> subverting, dropping, adding false addrs, (compounded attacks, using untraceable addrs from darknet) or isolating a router to take it out.
[11:45:15] <ggm> so the standard response is 'I have good design' I manage my config. 'management'
[11:45:20] <ggm> but protecting the payload is hard bit.
[11:45:31] <ggm> how do you know the routes you get are right? how do peers know, you are not lying?
[11:45:47] <ggm> security
[11:46:13] <ggm> who injects, did they have the right credentials. not who they are, but are they entitled.
[11:46:19] <ggm> is the forwarding path credible.
[11:46:58] <ggm> forwarding path may do strange things. may not be straightforward, but it needs to be plausible.
[11:47:12] <ggm> what we have is insecure. we've been lucky.
[11:47:31] <ggm> we can't answer the critical questions reliably. can spend $$ trying to, but how much to spend inside operational env, to look at payload?
[11:47:40] <ggm> what I (Geoff) want to see
[11:48:06] <ggm> ue of authenticatable attestations to allow automated validation. random data mining in crap whois is not good enough.
[11:48:23] <ggm> the data published is neither current nor sufficiently accurate. if you trust people, you're back where you started.
[11:48:27] <ggm> what we currently do doesn't work.
[11:48:35] <ggm> this is frustrating.
[11:48:41] <ggm> what would be better: inject trust into the system.
[11:48:52] <ggm> authenticatable attestations, would be very cool. help everyone.
[11:49:28] <ggm> I can ask 'is this valid' -is that route object authentic. is the origin AS real, has the person in control given permission to the AS to originate? would like to be able to do this automatically. how I can do it inside the cost constraints.
[11:49:34] <ggm> doesn't have to be inside BGP.
[11:49:36] --- torus has joined
[11:49:46] <ggm> basic issue 'customer says please route' -I can check if this is sensible.
[11:50:04] <ggm> good, if its in BGP. better.
[11:50:51] <ggm> nice if its a black box. want BGP to behave as it does today. lot of business models based around BGP behaviours. hasn't been deployed by accident, acceptance because it matches how we operate the network. we don't publish many policies. we accept routes, apply business logic, I emit routes. I don't neccessarily publish.
[11:51:02] --- geir_egeland has joined
[11:51:08] <ggm> near real time proto. session reset is not calamoutous. doesn't take 3 days to converge. if make it much slower, there is a problem
[11:51:22] <ggm> if we can do that, that would be really cool. even some of it would be a bit cool.
[11:51:29] <ggm> good to start today, even without the protocol
[11:51:47] <ggm> good if certification of number resources. signed, can go to trust point and check.
[11:51:52] <ggm> good to have repositary
[11:51:56] <ggm> good to have auth of adverts
[11:52:16] <ggm> good to have origination coming through., then data is reliable, verifyable into routing system independently of into BGP. when can do into BGP can leverage
[11:52:21] <ggm> next steps:
[11:52:27] <ggm> pki infrastructure for IP addr/ASN.
[11:52:32] <ggm> cert repositary structure
[11:52:53] <ggm> operational tools for near-realtime validation of signed routing reqs/filters/entries in route registries.
[11:53:06] <ggm> carry sig info as part of BGP update
[11:53:20] <ggm> question for GROW
[11:53:37] <ggm> is there interest in working on spec/description of tools that use resource PKI for near-realtime validation of routing reqs?
[11:53:49] <ggm> like RR, but tighter models of the certification
[11:54:05] <ggm> if interest, will work with folk, if not, going to drop it
[11:54:30] <ggm> Definately interesting to one person whose name I missed.
[11:54:44] <ggm> Darrin redside, simple way to think about it, PGP for BGP?
[11:55:52] <ggm> Geoff. if you break down PGP into two parts, one PKI, then yes. but beyond that, PGP trust model, rings, mutual trust, what I'm saying here is, that we don't know where the bad folk are, the rings of trust are difficult. real PKI. hierarchical , IANA -> RIR down follow the chain. allocation of resource., find cert infrastructure.
[11:56:12] <ggm> Darrin so the trust hierarchy is a hierarchy, not a web of trust. more centralized.
[11:56:31] <ggm> Geoff, I'm being a big bank today. I feel like using their address. the PKI says, you cant inject if you can follow the path.
[11:56:41] <ggm> Huitema
[11:57:01] <ggm> something to improve mess is needed. proposals which help with not inly with how to do, but provide tools are much more welcome.
[11:57:38] <ggm> not completely sure about details, need to be worked out. I am somewhat in position, want to have things earlier than this, in some parts of the world, wants to mention having routing registies
[11:57:50] <ggm> sorry not Huitema. Im tired. this is rudiger volker isn't it?
[11:58:27] <ggm> not all the RR for all parts of the world are completely junk. not all clean, some very clean
[11:58:42] <jlcjohn> Question: Is there sufficient value in veifying the last AS in the path, when it's so easy to intercept at each AS the packets pass through?
[11:58:50] <ggm> Paul who is going to run the PKI, and pay for it?
[11:59:26] <ggm> Geoff: its IANA-RIR-ISPs-down. if you look at it as a hierarchy, the folk who do the allocs, pay for their part. distributed mechanism.
[11:59:40] <ggm> Paul but SBGP is in the works
[12:00:07] --- geir_egeland has left
[12:00:09] <ggm> Geoff relies on this infrastructrure. don't wait for SBGP to do everything, seed a bit off, big bit of work operationally, lets not say SBGP lets say 'secure form of IDR' use without waiting for protocol
[12:00:11] <ggm> Kurtis
[12:00:27] <ggm> think we're in such a sad state, any idea welcome. can't make it worse.
[12:00:30] <ggm> <laughs>
[12:00:59] <ggm> interesting thjings in this. issues. need thought, the PKI part. worried want to ties this to auth of who owns this, in RIR, avoiding too many CAs.
[12:01:33] <ggm> Michael. 2nd comment, PKI, thats hierarchical, CA is organization nightmare. web of trust. sign pubkeys, has some congruence with present schedule
[12:02:39] <ggm> Geoff. have thought about this idea, rings or hierarchies. in some origin work on sobgp mention of web of trust. problem iwth rings of trust in global env, never sure if the ring is truly trustable. do actually hve in alloc system existing hierarchy. every prefix is uniquely located. hierarchical PKI fits the resource alloc structure. why not use what we hav ein place?
[12:02:45] <ggm> Russ Mundy
[12:02:55] <ggm> spent a lot of time thinking about this, i
[12:03:55] <ggm> one of the things we've seen over time, more difficult problem is the politics, getting agreements by the parties, from space 'holders' to the allocators, getting agreement that its ok IANA is in charge, or ICANN in charge at the top level of the PKI. having strong statements from the op community is the most important first step, will help buold momentum. to solve non-tech problems.
[12:04:39] <ggm> suggestion of thinking with web of trust, with idea of moving towards this hierarchy, PKI, is something to be considered, one thing we've seen. RIRs cooperate, but they tend to be independent and want to remain that way. politicatl policy thing.
[12:04:49] <ggm> vince ex Op person.
[12:05:03] <ggm> problem may be worse. we've seen this before. RPSSEC, RPSDIST/RPSAUTH.
[12:05:20] <ggm> how is the community changed, the env changed, that people will buy into this. couldn't get the big players to buy in.
[12:06:02] <ggm> Geoff. this is an endless movie. the level of concerns in the op community, the liability side, give more impetus to take small step. once you get that, the rest becomes easy
[12:06:22] <ggm> 10 years ago, security wasn't as interesting.
[12:06:28] <ggm> Vince think this is overdue.
[12:06:51] <ggm> need advocacy. get critical mass.
[12:06:57] <ggm> Geoff this is one step down that path
[12:07:47] <ggm> Paul can use PGP in PKI form.
[12:07:58] <ggm> Pedro
[12:08:40] <ggm> these problems common for all proposals on the table. how to delegate, how to find correct info. work needs to be done. stuffing bits into BGP, is trivial compared. knowing what to carry in BGP is bigger job. doing this work will get right info.
[12:08:59] <ggm> Geoff some info doesn't need to be in BGP.
[12:09:12] <ggm> Dave. visit on list.
[12:09:16] <ggm> Kurtis is next
[12:10:14] <ggm> SHIM6 update
[12:10:32] <ggm> meets tomorrow for first time, and on wednesday. Kurtis/Geoff share it
[12:10:39] <ggm> re-charter, continuation of multi6
[12:11:02] <ggm> in INT area
[12:11:17] <ggm> targetting site multihoming in V6
[12:11:57] <ggm> lots of drafts.
[12:12:38] <ggm> inherited work from multi6 re-submitted into shim6
[12:13:25] <ggm> goals and milestones through to Jun 06
[12:14:10] <ggm> ID/Locator separation model
[12:14:31] <ggm> lots of questions on state mgt, id characteristics, locater pair detection
[12:15:16] <ggm> come to the WG. its not that early, only 9am
[12:15:42] <ggm> lixia on router convergeance work
[12:17:19] <ggm> continuing work reported before, on behaviours of bGP. where the disconnects happen, who sees the flaps. this time its about convergeance times.
[12:18:09] <ggm> beacons , artificially generated events. don't know real events, what the numbers are with slow convergeance
[12:18:20] <ggm> how does it affect the operational internet?
[12:18:45] <ggm> preliminary result, picked 3 weeks from 2005, one from Mar, one from Feb, one from May. more or less the same. data is all from may shown here.
[12:19:10] <ggm> representative. took bgp updates from 28 oregon route views. (want to add RIPE data and other route collectors)
[12:19:21] <ggm> measured all changes to all prefixes to find slow convergeance
[12:19:33] <ggm> grouped updates into events. based on heuristics.
[12:19:37] <ggm> took before/after AS paths
[12:19:43] <ggm> calc update counte, and duration of events
[12:20:03] <ggm> then classify.
[12:20:40] --- torus has left
[12:20:43] <ggm> do you see as much if a tier-1 as a tier-5?
[12:20:54] <ggm> event classification: same path, path disturbance, path change
[12:21:38] <ggm> same AS across event, change during event but not afterward, different AS before and after
[12:23:39] <ggm> further devided into 5 path change events. Tup new route, Tdown, route withdrawn, Tshort, 'better' path Tlong 'longer' path, Tequal, cannot tell if better or worse
[12:24:31] <ggm> ranked paths. followed trends
[12:25:28] <ggm> used beacons to verify classification scheme
[12:25:42] <ggm> seems to work pretty well. 96% accuracy
[12:26:36] <ggm> then did same method for all update in the sample period. 18% carry same AS path across event. 37% were disturbance. 44% were path change
[12:27:13] <ggm> 5 stage model shows Tup gets less events than Tdown.
[12:27:27] <ggm> event duration graph shows slow convergeance can take 15min. doesn't mean always, but can
[12:28:14] <ggm> 90% of events finish in under 2.5 minutes, so most routing events short lived, but long tail
[12:28:24] <ggm> about the locations. where you live is important
[12:29:17] <ggm> path complexity changes how much path choices you are faced with if a link dies.
[12:30:41] <ggm>
[12:31:42] <ggm> shows examples of Tlong path event, duration.
[12:32:19] <ggm> tier1 converges very fast. tier-5 slow
[12:32:36] <ggm> summary: how bad is it? prelim results in paper
[12:35:13] <ggm> Geoff, Routing table status report
[12:35:31] <ggm> growth accellerating. same as early internet boom nowadays.
[12:36:09] <ggm> less fragmentation than before.
[12:36:15] <ggm> its more addresses being added
[12:36:55] <ggm> this is real growth, the boom was fragmentation
[12:36:59] <ggm> still flapping /8
[12:37:37] <ggm> slightly more care in routing
[12:39:03] <ggm> almost linear AS, but not quite. 2bytes run out around 2010. first 4byte AS soon! BGP needed. approach vendors, implementation timeline.
[12:39:45] <ggm> avg AS path length is converging. its going to get worse
[12:40:18] <ggm> V6 show contnual decline of 6bone.
[12:40:22] <ggm> slowly
[12:40:33] <ggm> now 750 entries. slower year for growth
[12:41:26] <ggm> larger V6 allocs showing up, /20s and the like being announced.
[12:41:30] <ggm> 10 v6 only ASNs.
[12:41:45] <ggm> 140 6bones, rest is 550
[12:42:04] <ggm> increase rate in V6 is around 150, even if routing table not growing as much
[12:42:20] <ggm> there is aggregation potential. can get rid of 60
[12:43:01] <ggm> no 2002 in the diagram.
[12:43:06] <ggm> is 4byte AS doc stable?
[12:43:12] <ggm> Geoff yes. for last 3 releases. just changing date.
[12:43:36] <ggm> Bill Fenner
[12:43:45] <ggm> completely agree need 4byte stuff now. need impls.
[12:43:58] <ggm> Geoff. now we're stuck. no impls until customers demand it
[12:44:37] <ggm> Susan Hares. IDR cochair. have 1 impl. wanna interop.
[12:44:41] --- nm has left: Replaced by new connection
[12:44:43] --- nm has joined
[12:44:43] --- nm has left
[12:44:49] <ggm> redback is 4byte enabled
[12:44:52] --- nm has joined
[12:45:09] --- tskj has left
[12:45:24] --- arifumi@jabber.org has joined
[12:46:30] --- nm has left: Replaced by new connection
[12:46:30] --- nm has joined
[12:46:30] --- nm has left
[12:46:31] <ggm> bill & geoff discuss how to get things moving on
[12:46:34] --- nm has joined
[12:47:03] --- arifumi@jabber.org has left
[12:47:04] <ggm> done
[12:47:06] --- ggm has left
[12:47:13] --- nm has left
[12:47:34] --- jeffa has left
[12:50:51] --- jtk has left