Minutes for KARP at IETF-89
minutes-89-karp-1

KARP (Joel and Brian)
---------------------
(scribe: This is a summary of the discussion, for detailed comments, refer to audio
for session)

Adrian - if you care about routing - don't leave the room now.

Joel - We have alot of work in the working group but the work is not getting done as
folks are just pointing fingers at who
should do the work.
Brian reviwed the slides. We have some small documents which give some guidance.
Several gap analysis documents
have been published,in progress, or just starting. Operations model for router
keying is in the RFC editor queue. Also
database is in the editor's queue.
What have we achieved? Security and interoperability have been improved for
manual configured keys. Now, looking at manual
keys vs. AKM. Manual keys is operationally more a burden and also sometimes the
keys are not as good. SIDR is also doing a
lot of work on distributing keys for BGP. There are tradeoffs for AKM vs. manual,
maybe the cost of AKM not worth it.
And the complexity of AKM brings its reliability into question. Newer AKM has
better DoS protections. Been reviewing
AD questions on whether KARP should continue with AKM work. There doesn't
seem to be sufficient support to adopt some of
the drafts that have been discussed. Would like to ask the question in this broader
audience. Should the work be abandoned?
Should it be moved to the security area?

Ren - a couple of clarification comments. For an IGP, all the routers are in a single AS
domain. So many use provisioning as
they control all their routers. That solution not so obvious when discuss
interdomain,as then have two different provisioning
systems provisioning the two domains so not so straight forward to coordinate. Also
these are using multicast for BGP, not
so good. It might be productive when you ask the questions, to scope the questions
for the two distinct problems (inter/intra).
Brian - yes, two distinct efforts. Been doing EBGP. Some multicast. But for multicast
protocols, do have problems, nasty
problems. TCP based pretty far along, for automated keying. So would be good to
separate the efforts.
Curtis - not sure what proposing for IGP. For SIDR can use PKI. But for IGP can not
use PKI. It's a chicken and egg problem.
Two separate issues, picking a key and distributing a key. From what I know, service
providers don't pick keys by hand.
Because these are used by routers, so machines can pick. So it's distributing that is
needed for the keys. Would hope by
now ISPs know how to do that by now. So not sure configuration is a problem to
solve except maybe for new players on the block.
Joel- Now we come to the problem we have, we need people to do the work, the
expertise.
Ross - I'm not saying I have the expertise. I'm commenting on the last bullet, should
it be moved to the security area? I think
there is so much specific to the routing protocol, that if we just gave a list to the
securtiy area, something would go wrong.
Yes, we do need security experts to participate here with us on this in the routing
area. I don't know if there is a concept
of a working group in two areas. But we sort of need it to be half done in the routing
area and some in the security area.
Brian - that's why we have been doing it in the routing area. We've had security
experts participating, but not enough
non-authors participating so far that are interested.
Ruediger - I'm not able to do the automated key management. I can provide hints
and some requirements. People are sitting,
waiting for solutions, but not effectively producing text. For me, I viewed as it was
experts, not me, doing the work.
Not sure how to tackle that problem. On what would like to see, I can remark
on interdomain. My focus, the actual problem is authenticating between ASs. For
that we are building on how we are doing.
As for intradomain, I'm not so comfortable with relying on my provisioning systems.
Having a roll over once in a while may
be the way. My take on the question, are current operators satisfied, yes, we know
ways to operate but we probably are not
so happy on it. But there is so much elso to do, why bother on this one. If security
becomes a problem, then will be interest.
Acee - my comments on the intradomain, unless people want it and want to spend
money, I don't want to spend time on it.
Delegating it to the security area, I'd be concerned it could be developed with the
premise that security is the main premise
vs. routing.
Sam - I found we have alot of expertise. I've gotten good answers e.g. from Acee.
We've gotten it pretty close. I hope
whatever we do, we do it as needed from both sides. Maybe we can get more
security experts over there (security) if we do it
there. I want to speak on trust and respect and in the IETF community. we did do
some security requirements on automated
key management and we discussed in the community. Alot of people built up trust
and wanted to support the routing community.
We had to make hard choices to give priority to supporting the routing community
and made compromises. If now give up, it
will damage the community's trust. I'd hate to see that happen. I ask, if we think the
work is valuable, then let's do the work.
If automated is not the answer, then we can revisit and do provisioning. If want to
do provisioning, should do so as
interoperable vs. using one vendor's provisioning system. Let's not go against
agreements we have made. Let's have a broader
discussion and rework our agreements and writeup why. But if don't want to do
now as don't have enough people, then don't
stop people from those that want to do it in the future.
Wes George- On Acee, the cost of implementing. That's true of most security things,
we've been lucky it hasn't bitten us. Yes,
operators have been using the same MD5 values for many years. We have been very
lucky, but not a reason not to do it. As we
have not been bitten, money is not going to be the primary driver. It will be because
it's the right thing to do.
Jeff - the problem with security in IETF is that the older stuff is "good enough".
Things do evolve. And when figure out will
need it, it will be too late. We need to start now. That's what this working group is
trying to do. Where's the money for it?
Because it hasn't been a problem, the money is not there. Can either proceed ahead
and document so when it is needed it's
ready. Or say that effort is too much. Then stop the work for now, free up the people
working on it, and when need it, can
pick up.
Curtis - Two problems, the one Jeff brought up. Never changing a key. So one
problem is - changing a key, key generation. Do
you ever do it? Second problem goes with what Sam was saying. There is now a
standard mechanism how can do - NETCONF. So now
the CLI that NETCONF represents differs by vendor. So maybe can built a yang
module for that. I think that's about all that
can be added now to current practice.
Doug Otis - there is another protocol used for cell towers. That technology is very
fast, very reliable. If do over tcp, may not
be as robust. So do have technology, if want to apply it.
Joel - some use it, some do not.
Doug - that's not it - I can not say what it is.
Tim Polk- We put this in the routing area as we thought security folks would come
and help. I don't think we can punt it to
security area and expect it to get done. While I would prefer automated key
management in-band in the security protocols for
the future, you could use like yang for outband. So not manual. I would like to see
even that incremental effort. Let's
think though what is it that we really need. My view, the security tool kit in the
routing area is very thin, so if we need it
in the future, we should be progressing now as we are a long way from deploying
code.
Acee - I was refering to interdomain before. I think this work on tcp, for not only
service providers but also content providers
will need a RPKI solution. And it doesn't have the chicken and egg problem. Need to
do right as there will be consequences if
don't. I think KARP has done good work, especially for IGPs, now need
implementations and deployment. On the yang model, we
have the key table draft could be mapped to the yang model. And implementations
could map to their internal.
Sam - clarification, the intradomain, it doesn't have a chicken and egg problem,
unless you create it. All our proposals
could be said to cover that.
Curtis - there's a third community should have been involved - the operational
community, ops as they will give input if
anyone wants to deploy this.
Brian - we have had a few ops folks involved.
curtis - these are all operational practices that people know the proper pratice here
in IETF - if people use them that's
the question.
John S. - I can say this is great, but unless you give me a business case for it, I can't
say it's worth it. Some of the other
comments have convinced me it is good to go forward with the work now and not
when our hair is on fire.
Curtis - is this encryption?
Joel - no, we're not doing encryption, this is authentication. Would like to see if
interest, will confirm later on the list.
Joel - how many people here would like to see work go forward on auto managed
keys for interdomain? Good show of hands.
On intra domain? Less hands.
How many would do work on interdomain? - only 6 hands. Intradomain? - only 6
hands. So this is the problem. Lots of people
want the work, but not do work. So again, how many would help do the work with
interdomain - this time a few more hands.
For intra domain? only again about 7.
Thank you - we will try and figure out what to do with this.
Curtis - this discussion would have benefited if we had a heads up on this before.
Ren - one suggestion, may be worthwhile to do a yang module, can you ask?
Steven - interdomain seems some interest maybe ask.
Sam - I'm hesitant to do that - I'm hesitant to change direction now. Let's ask both
the interest question and the willing to do.
Ruediger - I think we should look at the question - do we want explicit description of
the model, or not to do that as it
would be percieved as changing direction.
Sam - It's not about changing direction that concerns me, let me rephrase - I want
something deployable and interoperable.
Joel - how many would work on the model for an interface for key management?
About seven people. Thanks, we'll talk more on
the list on what to do.