IETF-75 Routing Area Open Meeting
=================================

http://rtg.ietf.org

ADs: Ross Callon, Adrian Farrel

Scribe: Deborah Brungard 

Administriva and Area Status
----------------------------
 
Ross opened. Ross gave some quick comments on Process. Reviewed the Note Well.

Reviewed reminder on IPR and need for contributors to disclose IPR. Reviewed
"Please, Polite & Effective Process" basic rules discussed by the IESG. Adrian
asked for WG Chairs to ensure the slides are uploaded prior to the meeting.
Especially important for non-native English speakers. And to start using jabber
as it also helps for people in the room.

Routing Area Working Group Reports
----------------------------------

BFD (Dave) - All the base documents in IESG review. Only one draft still with comments.
Then all move forward. One update needed for the base.

CCAMP (Deborah) – Two new RFCs. We have a new co-chair, Lou Berger. We will be meeting
tomorrow morning- one session this time. WSON (wavelength switched networks) is a key item
in progress. A new item, we are beginning to recharter.

FORCES (Ross) – Main documents in RFC editors queue. Waiting for one normative reference document
which is almost complete and will be submitted for publication before next meeting. Had
interop between different vendors. Very valuable experience.

IDR (Sue) - Yakov started almost 20 years ago, now has retired. Ross thanked him. New co-chair
will be John Scudder. We have new work items, meet on Thursday. I thank Yakov for all his support
these years.

ISIS (Dave) – One RFC pushed out from last meeting. Many in your queue to go forward. We'll
remind you.
 
L3VPN (Ross) - Most significant difficult task consuming energy is multicast. Two main protocol
specs- I got proto writeups this morning. Will put into publication request asap. Another draft
which discusses using the protocols still needing to progress. So there has been significant
progress in this difficult area.

MANET (Ross) - Co-chairs not here. Will meet with a substitute chair.

MPLS (Loa) – We had two RFCs since last time (LDP capability). 5 in publication review state.
Almost completed some of the multicast.
 
OSPF (Acee) – Made good progress on several documents existing the last several years. One going
from experimental to standards track. Finishing up manet experimental documents. Have several on
the AD queue for publication. Looking at items for recharter. May not meet next ietf unless have
some new items.

PCE (JP) – Good news and bad news - lost co-chair Adrian, and have new AD, Adrian. New co-chair,
Julien. And a new secretary, Dan King. A little late on interdomain, but should wrap up soon.
Now have ASON and MIBs.

PIM (Stig) – Very little news. 5 documents with IESG. 3 for this meeting. 4th, no new revisions
but not covered at this meeting. Making good progress.

ROLL (JP) - Formed wg about a year ago. Did a survey looking at existing protocols. Conclusion, no
existing protocols fully satisfy requirements. Rechartered to do new work. Have a design team to
look at. Moving forward quickly. Another new proposal also will be discussed tomorrow. Alot of
people other than roll also looking at us for our work.

RTGWG () - No one here.

SIDR (Sandy) - 3 drafts almost ready. My co-chair not able to attend. I'll chair. Hopefully will
reach some consensus this meeting.

VRRP (Adrian) - Chairs couldn't attend. Not meeting. The unified model is at v3 attempting to
address comments from IESG and others from mailing list. Should move soon. A mib version ready
almost. A need for sub-second timers which will be rolled into the draft.

MEAD (Loa) - This is a Design Team (not a WG). Chartered to manage the ITU relationship on MPLS-TP.
Also chartered to progress the MPLS-TP documents before they become WG documents. We needed to address
a process and had to have a document on this. It's a WG document at this time. If you want to
comment on this document, need to understand this is a delta from normal IETF process as need to
work with ITU-T. We probably won't have documents ready for the schedule date by Fall, but will
have some by Christmas. We have many more documents than originally planned.


KMART
------------------------------
(Greg)
Presented slides.
Explained different from SIDR which is authenticating the route origination details within a
message - message content validation. This is just authenticating message is from neighbor thinking
it is. Prevents attacks at the routing protocol level - at bits on the wire.
Acee - Asked if statistics from Arbor Networks report, answer is yes (slide on TCP MD5 use).
While significant increase in use of TCP MD5, the problem is no one changes the key (everyone said
only one key ever used, never changed). So this is a problem - problem if a harmful employee. Need
a way to automate key so will facilitate changing. Step 1 is to automate. But also need a way to do
without impacting sessions on-going. If bounce the adjacency this won't be used either
(mid-session key agility). We have a requirements document which address these items.
Acee - Has anyone considered a priori in-band distribution e.g. when start and end for dissemination
of keys?
Greg - Do you mean when ospf starts forming adjacencies? 
Acee - No, could we do outside of protocol. 
Greg - Yes, if could do also changing a key, could do without breaking the session. Most protocols can
not do.
Acee - Not my implementation:-)
Greg - But implementations are not the concern of IETF. We need to do what it takes for two different
vendors to work.
Ross - Could look at though. We could look at it if we had a wg which we don't right now. 
Dave Ward - On the two phase process - where at? 90% done on first step for key protocols?
Greg - Differing views for what's important.
Ross - I think may need step 3 so that a routing expert (non-security expert) can understand your work.
A generic document.
Dave - OSPF and ISIS are pretty much down the path for what have said.
Ross - Also have rsvp, ldp, bgp.
Adrian - Isn't another motivation of key management for auto discovery?
Greg - Discussion on automated key, it's in a later slide. Continued discussing slides.
Ross - Is the key stored on the same routing machine?
Greg - Operators say they always start with a few static routes to see connected. Then later do
automated discovery. So chicken and egg problem for getting the key into a router is not there as
never start up in automated mode.
Greg - We need to define a way so that can move between using a manual key and automated key so don't
bounce routing adjacencies.
Greg - Always need to start with a router identity. Then need a preshared key to use between two.
All operators are running ssh. And using preshared key. So we could use same mechanism as operators
are familiar with it. Just one possibility. Most important is structure so flexible how populate keys.
Adrian - You've nicely shown can use key management for already discovered peers. But my question, is
for automated. If don't know who is out there. Then need an automated way.
Greg - Not sure need to. If I use a group key, manually configured, then all can discover each other.
Adrian - I guess I should of said then with a level of security as group key is less secure than an
individual key.
Greg - Not necessarily. Depends how use. Doesn't have to be less secure.
Ross - Doesn't depend on number of boxes. If more people need to know the key, then more difficult.
Greg - Yes, true. but because of this, manual keys are always weaker for this reason.
Albert Jiang - Is it only the master key stored or also traffic keys?
Greg - It doesn't need to be that way. Could store master key in KeyStore and then generate the others.
Albert- is this similar to Mobile Networks?
Greg - Yes in that a provider needs to give you a code first in some way.
Albert - What is difference?
Greg - It's out of scope to discuss all the ways differed. Need a proof and way.
Ed Veroset - While it's said that MANET is outside scope, but my question is if ROLL should also
follow this.
Greg - I'll defer to the Routing ADs.
Ross - My first guess, it would need to for the same reasons, need to discuss more.
Ed - If an authorized user turns rogue, then quits, how do you restore?
Greg - The document says that this mechanism can not prevent, but the automated key will help
to recover more quicker as can change the key much more quicker.
Adrian - ROLL just picked up a new security advisor, Rene. So can pick up on this.
Albert - So where does authentication occur?
Greg - In TCP-AO - there's parameters which need, key id, shared key, and algorithm using. OSPF will
have different parameters. So will depend on routing protocol.
Albert - Is this API between KMP and Traffic keys for providing parameters?
Greg - Yes, you have understood correctly. 
Aleksi Suhonen - Have considered using one key management for all protocols or a different one for
each?
Greg - will be a design decision (after put together a wg for this). Framework document recognizes
will be different parameters for each protocol.
Ross - We don't need discussion today - will be for wg.
Aleksi Suhonen - How does work with existing protocols security mechanisms e.g. BGP?
Greg - Don't know - we haven't got that far yet.
Richard Graveman- When you say ospf mean v2 (v3 has a different security)?
Greg - Will look to routing experts to determine. Routing wg may decide if protocol
already has means to pass step 1.
Ross - answer - it has to be both ospf v2 and v3.
Richard - v2 is similar to isis. v3 has its own security mechanisms but a gap
for key authoritication.
Ross - Yes, there is work to be done here. It needs to be done in the wg. Should probably
list ospf v2 separately from v3. So do as two different groups on this slide. Can always decide
later if can be combined.
Greg - Slide lists only some items to be done.
Ross - Yes, more items will need to be done.
Greg - Proposing to form a wg in routing area with routing area expert and security area expert
advisor. We'd do work for each protocol in this new wg. Not sure to do work in each protocol wg
or in one new wg. Thought to do as one new wg so as to have all critical people together in one
group. And will not be so disruptive to all the wgs. Need a charter.
Ross - Want to add that the bullets on the slide (plan of record) are not in chronological order.
Plan to have BoF in Hiroshima so people will have time to input what is needed. So work is not
done yet - just a good start.
Greg - We'll need to do a charter for the BoF. And discuss better the split.
Andrew Lange - Wasn't RPsec suppose to do this?
Ross - Don't want to really get into.
Greg - RPsec tried to do everything. We are narrowly focused to bits on the wire.
Ross - RPsec got stuck on issues which this wg is not planning to look at.
Greg - There wasn't even consensus on what the work should look at. This is taking a look at one
part of the RPsec work.
Ross - Is there any issue with copyright on the kmart name?
Greg - We had a kmart BoF before and now looking at something a bit different. So this one
could be different. It doesn't matter to me.
Ed V. - May want to avoid NAMI (national alliance for mentally ill in US)
Greg - There's a kmart@ietf.org list if interested or send mail to me.
Richard Graveman - I'm 100% behind this. It's a good set of steps. When having the discussion
with the ADs on progress, could you cc the mailing list so everyone can know what's going
on?
Ross - Alot of these discussions also occurred over yesterday's breakfast.
Greg - There were emails but most were identifying if should be routing area or sec area. We
can copy going forward.
Richard - Most of what is being address is about a disgruntled employee. Not for example
wiretapping. In your threat model, if all we do, is make the fired person do one more step
to get access, it's enough?
Greg - If a person has the master key, can not help. Need to use automated, but if base protocol
can not do automated, can not do either.
Peter - One more scenario would like to see - a card in the router has failure. And when
sent back for repair, its configuration ends up on ebay.
Greg - Yes, and also how to get the standby card up to speed quickly.
Dave W - Don't think we need a wg, maybe need a design team with specific individuals that know
the protocols.
Greg - But a DT for each protocol? or one?
Dave W - Could have a general DT, and then specific ones.
Ross - May find for specific protocols, work already done. For others, the work is very specific
for the protocol. May need to be a short document progressed in the protocol wg.
Dave W - This top end stuff should be in a foobar BoF. Then follow thru to the protocol wgs.
Greg - May be some general items which need to be worked as a combination of security and protocol
experts.
Dave W - The API will be defined by the new wg?
Greg - The attributes (general) will be, the specific attributes need to be done by the protocol
specific.
Dave W - I see the need to discuss this more before the BoF so understand better.
Greg - There's a document by Russ and Tim on KeyStore which may want to look at.
Andrew - Where's this discussed?
Greg - On the KMART list.
Peter Lothberg - Also would like to see this expanded to more general operational security for a
router.
Dave W - This looks like should be a plugin.
Greg - Will depend on protocol specifics. 
Tony Li- Support this. Been discussing for awhile. Just do it.
Adrian - Encourage people to use the KMART list to discuss.