Re: [P2PSIP] P2PSIP and HIP Joint Meeting on the Boeing VOIPHIPImplementation

[Spencer Dawkins <[e-mail]>]

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 
([e-mail]), 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/p2psip