KARP minutes
Thursday morning 2010-07-29
Minutes taken by Paul Hoffman
Things from the slides not copied here
You must read the slides to get more details
People tend to speak really quickly and I made a lot
of guesses about what they meant
Chairs: Joel Halpern and Brian Weis
Meeting Materials
https://datatracker.ietf.org/meeting/78/materials.html
http://www.ietf.org/proceedings/78/
Meeting audio track
http://www.ietf.org/audio/ietf78/ietf78-ch7-thur-am.mp3
beginning at 09:35
Why we are here
Claims at Black Hat for breaking many layer 3
protocols including many routing protocols
Status
We have three WG documents but not enough review
NANOG report
Joel Halpern
Told folks that we really care what the operators
think
Mixed bag of comments
Stability - great if you can avoid breaking running
code
No, they don't change the keys
Yes, they know that they should
Don't really know the other
threats
Trying to stay in touch with the operators community
If the operators aren't interested in our work, we
are wasting our time
Status of Design Guide, Framework, and Threat Analysis I-Ds
Gregory Lebovitz
draft-ietf-karp-design-guide-00
Work order for the per-protocol
teams
draft-ietf-karp-framework-00
Overview of what we are doing
draft-ietf-karp-threats-reqs-00
Lists the reasons we need this
Three documents replace karp-roadmap that will
expire soon
Operators: make it easy, and reduce my costs, not
increase them
Can keys and ciphers be changed
without bouncing the links
Main use case: when one staff who
had access to key material
Ekr: Doesn't think that changing a cipher without a
bounce is needed
Chris Morrow: Need to have the
new software everywhere before changing to a new algorithm
Can do
individually
Ekr: Could do capabilities
announcement to help rolling
Threats documents
So far, no reviews
Four people said they would
Design guide
Question of whether RSVP or -TE
Sam Hartman: Question to Joel:
Have you backed down from saying RSVP is out of scope
RSVP-TE might
not be as easy we think
Need more review
This is a
contract between the WG and the design teams
Joel H: We
will also listen to the first design teams to help revise this
Twoish people said they would
review this
Ekr: Concerned about procedure
Got some
review, but there were no updates since the last IETF
Gregory: There
were no significant comments and very few reviews
Overstating the problem dramatically
Joel H: Chairs
thought about putting them back together now, but thought separate are
better
There was a technical issue that didn't get discussed on the list
Ekr: I did
bring it to the list
Gregory: When
the documents are content-complete, we will consider re-combining
Sam: Remembers
Ekr's review to the list
Gregory:
Bhatia didn't get the new draft out
Things that were brought up in Anaheim will be in the rev
Lou Berger: We
should wait for a new rev before doing the review
When will it be complete?
Gregory: Can't commit to get it out soon
Joel: Please look at the current
reviews and get a new draft out if any are significant
Framework
Router vendors say they don't
want to know a whole lot about the kinds of keys and protocols
Ekr: Wants to see the discussion
with routing vendors online
Gregory: Will
do
Sam: Just sent mail to the list
about the out-of-band comparison
Question of protocol or protocols
One-to-one communication can be a
special case of the group keying model
Discussed in
other SDOs as well
Will have a
discussion with Sam, Ryan to discuss this general idea
Questions on if keystore is needed
Wants to be
able to move between one part of the evolution to another without
bouncing links
Brian: Will you produce a new
document first:
Gregory: Wants
to wait for the coupled/decoupled debate to settle before doing a new
document
Heated process and personality
discussion ensued
Cryptographic Authentication Algorithm Implementation Best Practices
for Routing Protocols
Joel Jaeggli
draft-ietf-opsec-igp-crypto-requirements-00.txt
ADs want reviews from KARP in specific and security
area in general
Database of Long-Lived Cryptographic Keys
Tim Polk
draft-polk-saag-rtg-auth-keytable-03
Read this first
draft-housley-saag-crypto-key-table-02
About incremental improvement
If your protocol adopts this model, you don't have
to implement everything
Is not really an API
Generating short-lived keys from automated protocol
(in the routing protocol) is not done here
Could co-exist in theory
Question of whether it is a good
idea
Dan Harkins: Are you going to do this for every
packet?
Tim: No, only when you see a key
change
Tero Kivenen: Are you only looking on the key-id?
Tim: No, also look at other data
Ekr: What are the session keys being derived from?
Tim: KDF, set of inputs, other
Ekr: In AO, there is no material
to start with
Tim: When you reach the point in
the protocol, you need the ISNs
Ekr: That's not soft state
This design
implies that a crypto setup has passed
This uses
session identiers
You are
assuming that there is a handshake
Tim: Correct
Sam: If you want to publish a document for the
keystore for AO, that is fine
If you want to discuss are
routing protocols need to store long-term and short term-keys, fine
This document is premature
Not sure that we can solve the
replay attacks on multisession keys
Tim: We don't know what multicast
solutions we are going to end up with, probably not perfect
Is there value
in this group for us to have this discussion?
Sam: Using
this as a thought process for that case is too restrictive as a
starting point
Min ?: The key length can be 8, 16, or 32 length:
how can those be used?
Tim: There are many ways to do
translation
Ekr: Start with TCP-MD5, in your view, add a
handshake, use a protocol like IKE to do a derivation
Tim: Yes
Ekr: But most of those protocols
don't have a derivation function, we should specify one
Tim: This is transparent for the
protocol
Ekr: So every routing protocol
will need a handshake
Tim: Yes, there is left to do for
all the protocols
Ekr: TCP-AO hijacks fields in the
TCP header to do the standard nonce exchange handshake
Gregory: There is information in
the header that we can use for inter- and intra-session protection
Brian: We are only talking about (missed this
because people spoke over him)
Gregory: If there are elements that we can use to
make an implicit handshake
Tim: This is trying to facilitate the improvements
that we tried to facilitate when going from TCP to TCP-AO
Sam: There is a massive amount of talking past each
other
Come up with a version that is
not TCP-AO, hopefully a multicast one, so that the screaming can start
Tim: Only thinking about
non-multicast
Sam: Needs to see a specific
example in order to see what the handshake might be
Jeff Haas: I don't want all the details exposed to
my routing protocol
Handle them in the transport
protocol
Lou: What is the intended publication status?
Tim: Informational or
experimental, maybe not even published as RFC
Lou: Update the document: it says
standards track
Chris: Idea of a keystore is fine
Most protocols have no idea of
what key they are using
They don't understand an ID for a
key
They can't rotate keys in the
protocol, but the implementations can
Jeff: If the transport can take care of that for
you, we're happy
Analysis of OSPF Security According to KARP Design Guide
Sam Hartman
Some other documents are needed to read before you
start designing
Trying to decide what level of detail is needed for
the security requirements
Wants many people to analyze this to see if the only
problem is dropped connections
Are these the kinds of things that we want design
teams to cover in their documents
Gregory: Yes, going through the exchanges and
finding the gaps is the right thing
Sam: Are there more things that an analysis should
cover?
Ekr: Scares the pants off of him.
Response is to burn it to the
ground and start with something we already understand
Sam: If you could get better
sequence numbers, you can map it onto a protocol that you understand
Doesn't
understand OSPF extensibility enough to do this analysis yet
Jeff: Wasn't an analysis of OSPF-2 the reason to do
OSPF-3 with manually-keyed IPsec?
Sam: But the OSPF-3 way of doing
it was worse
Gregory: You choose a fixed SPI
and that gets in the way
Sam: You can't set the IV
Ekr: All the anti-replay fixes rely on the
adjacencies
Operations Model for Router Keying
Sam Hartman
draft-hartman-karp-ops-model-00.txt
Wanted to start writing down the model so they know
what the design teams should use
Now mostly questions, but when there are answers, it
will be much more useful
Wants an operator as co-author
Analysis of Security Association for Current Routing Protocol
Yinxing Wei
Different routers handle SAs differently (if at all)
Lou: Didn't cover the full scope of protocols in the
charter, such as RSVP-TE
Yinxing: Yes, will add more
Lou: Wants to see this in the WG
after it has all the protocols
Ekr: Not sure if the SA is the right model
This is not the way AO works
Chris: Appreciates the survey, likes the idea of the
document
Gregory: +1 to Chris
Maybe make the SA a very long
string of bits that the protocol knows how to take things from
Each protocol can interpret
differently
End-of-meeting questions from Joel
We keep focusing on BGP
What protocols should we be focusing on first?
The charter has an order, maybe we will use it
Ekr: Do we want a harmonized approach? If so, the
next one needs to be a multicast one and see what happens
The security are understands
point-to-point much better than multicast
Not much deployment in multicast
Gregory: See if we can pick a multicast, then derive
point-to-point from that
Will we have a disaggregated key
management protocol
Lou: Worried if you use a particular protocol, the
result could be protocol-specific
ISIS uses a different model from
RSVP
Do an analysis of all the
protocols before picking
Jeff: One size is not going to fit all
BFD is usually bootstrapped by
other protocols