Richard,
These are the notes I took during the telechat - I hope you find them
helpful.
It would be really good for people to see how badly they were misquoted -
please send corrections to me privately, and I can provide a bulk update to
Richard. I'm almost sure I attributed several Dan York statements randomly
to other people...
Thanks again for setting up this call - very helpful.
Spencer
We started with a review of "Note Well" (we're under IETF IPR rules for this
meeting).
- Agenda bashing...
Planned agenda is to review the VoWLAN paper and then do Q&A. No bashing to
this agenda.
- Paper review...
This paper was distributed to P2PSIP mailing list on December 21 (also
downloadable from http://www.opengroup.org/bookstore/catalog/e041.htm).
Using Open Group's Secure Mobile Architecture for both wireless and wireline
secure communication, including voice, for factory operations.
Mechanism described is currently in production on the Boeing 777 assembly
line robots, but is much more broadly applicable.
Overlay network, using HIP ("SCADANET Plane" in the paper). Tunnel looks
like IPsec, with a cryptographic identifier.
Wireless devices are Nokia 770s with Linux and LinPhone. SIP provides call
management services, while HIP provides security associations.
Some infrastructure is involved - "virtual directory" (identity, IP address,
location of a device), DNS proxy for directory, certificate
download-to-device management, location service.
Need to know who someone is, and where they are, to do security well.
Using HIP UPDATE packets for subnet mobility.
Provide crytographic security for every packet (also protects
infrastructure).
Does rely on enterprise PKI in this demonstration.
- Questions and answers ...
Did this require mods to Linux IP stack? Used HIP from Helsinki, did have
some kernel patches that added a new transform.
Does this use Orchid? Tom said all HIP implementations use Orchids (Orchids
are a particular form of IPv6 addresses, allocated experimentally).
Would this also require changes to a Windows TCP/IP stack? Tom said that
Boeing uses an OpenVPN "shim" with all modifications in user space, so no
kernel mods are required.
There's no way for an application to know that it's talking to an overlay -
how does the application know it's using a secure overlay? This is security
by configuration - the application "just knows" the interface is magically
secure.
Do we want applications to know about these security characteristics? Big
design question (using ORCHIDs with legacy APIs tells you nothing about
these characteristics).
What about a secure SIP security indicator? Applications don't get any
indication of security from IPsec, this is no different from any other IPsec
operation.
Dean said that there are mechanisms to make applications aware of HIP-IP
mapping, if you build an application to be aware - this demo is using
opportunistic mode, which does not, but there are 5 other modes.
Lots of discussions about HIP security on VOIP-SEC/VOIP-SA mailing list
([EMAIL PROTECTED]), but not in about a year.
The question here is whether we can use modified applications with
unmodified stacks. Ted thinks the real question is whether you get something
easy for the application writer to use without awareness of an underlying
overlay or not. Anything - OpenVPN, kernel mod, etc. are just creating
another interface that is exposed to anything that uses normal mechanisms
for discovery - applications would not know the difference between IDs and
LOCs. Ted thinks we need to know this difference - need to have a design
discussion about this.
This is a tradeoff between easy deployment and application awareness of
unique characteristics - we need to talk.
Spencer- There are a lot of other reasons to dork with an API - multihoming,
route selection. Is API enhancement bounded?
Dean - we went with TLS 10 years ago because we could do it without dorking
with stacks. We might make a different decision now, if we were
reconsidering.
Henry - the IPsec mechanism secures all applications, not just SIP.
Ted - but applications that don't know IPsec is there will run TLS over
IPsec happily if they care about security. Maybe we could know that we're
using an ORCHID that must be HIP-ergo-IPsec. There are questions about the
layering model we need to talk about.
Steve - not sure what approach we want - transparency for legacy
applications or application awareness.
Ted - we're using P2P anyway, HIP or not. If applications understand
characteristics, you want to have the same answer for P2P and HIP awareness.
Steve - both mechanisms available? and application writer chooses?
Dave Bryan - transparency isn't going to make SIP phones P2P, right?
built-in free resource location, etc. doesn't happen by magic. Still work to
do on both SIP and P2P to make this work.
Question (sorry, missed name) - if HIP is providing overlay routing, there
is also a coupling with resource location, etc.
Dave Bryan - but think about service, voice mail, etc. We still have work to
do before we can remove all the servers.
Spencer - seeing people talking about HIP over P2P and P2P over HIP - need
to nail down an architecture early in this discussion.
Tom - HIP is doing security for media streams, and there is separate work
about extending the architecture to do routing. Could be different ways to
go here (media streams only, or entire overlay on architecture).
Gonzalo - WithHIP proposal started discussion using HIP in naive way, but
this was too simple an approach to use. We would modify the architecture,
use ORCHIDs (or derivation) as identifiers, etc.
Sherry - has anyone done competitive analysis about performance, operational
scenarios, etc.
Richard - not an alternative that met our requirements (in the broader
context). We did what we did to meet our requirements. We're going through a
competitive analysis now, for another reason (and it's not obvious we would
release that analysis externally).
- Next Steps? ...
Ted would like to resolve design decision about application awareness -
write this up early in the process. If HIP is only transport-mode security,
it's low-handing but not very valuable fruit. P2PSIP needs to be clear about
API expectations about underlying overlay. If we don't get that right, we'll
be headed in the wrong direction.
David Bryan - consensus on that issue would help a lot. A lot of people in
P2PSIP don't understand how this would work and would benefit from one clear
statement.
Henry - a lot of confusion about protocol stack, what's on top. Could Boeing
team identify architectural choices in a separate paper, perhaps working
with Gonzalo? It would help the P2PSIP folks a lot. Should come from
authoritative source, right now that looks like Boeing and Finland.
Gonzalo - three proposals, but thought HIP-HOP was abandoned and no one is
working on WithHIP, we're working on HIP-BONE. We need to communicate better
with P2PSIP working group. We've been having conversations within HIP, with
P2PSIP guys, clearer than before IETF 70.
Tom - still needs to be discussion. Eric Cooper is still interested in
HIP-HOP, Philip is interested in IP-LOC. Thought we agreed to talk on HIP-RG
mailing list and then HIP-BONE came out and things got quiet.
Gonzalo - don't see HIP-HOP and HIP-BONE as different proposals - saying
similar things. Published new draft because I didn't think there was
interest in revising HIP-HOP.
Henry - new draft with tutorial and framework?
Gonzalo - has some tutorial but did draft in a few hours. Need to add
historical statements, etc.
Henry - how to represent Boeing contribution to IETF? don't have to decide
now, but would like to see Boeing work better understood in IETF. Extremely
interesting for entire HIP community.
Gonzalo - choices have to be explained further.
Richard - Sherry was talking about "competitive analysis" beyond
architecture - MEXT, MIP, etc?
Sherry - think more practical to decide architecture and educate people.
Start with this. Eventually have to give analysis answer - P2PSIP and
conventional SIP.
Dave Bryan - need to focus on HIP and non-HIP discussion.
Is there an interest in HIP within industry? This is what Richard hopes to
finish by February.
Henry - believe working working group is not proper place for economic
analysis, but need to think about wquestions like balkanized security for
different applications, etc.
Dan York - if we're going to do a comparison, I'd like to understand how
widely HIP might be endorsed.
Spencer - need to ask about interest in architecture, not interest in
specific protocols.
Henry - dialup IP is a good model - a way to get started, and then
applications that manage connectivity can move into OS code.
ANOTHER TELECHAT?
Gonzalo - yes, but everyone prepare. Don't discuss on abstract level because
we won't make progress.
Richard - have to deliver comparison between technologies in February. If I
can get that approved for release, it could be a basis for top-down
discussion, then talk about protocol stack, architecture, etc. If Gonzalo
adds tutorial material that would also help.
Gonzalo - sure, what tutorial do people need? Trying to do tutorial in three
pages so people will it read it.
Henry - had to read 10 references anyway...
Having read through HIP-BONE, Gonzalo and team did this well and unfortunate
we truncated discussion during the holidays. Let's not keep starting out
"what would this architecture look like" - keep going from where we are.
Richard - want me to set up another joint meeting?
(No objections!)
Stopping at 1:35 minutes... will go from there.
Much gratitude to Boeing for throwing these ideas out for thought!
_______________________________________________
P2PSIP mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/p2psip
