RE: [midcom] Basic question about SAFENeT I-D

["Townsend, Richard L, JR (Rick)" <[e-mail]>]

Hi Juergen and Martin,

Sorry to take so long getting back to you but I've been working an issue with my boss in another standards body.
I took the opportunity over the past week to talk and develop a better understanding of where MIDCOM is in their decision process.  Back to that in a minute.

First let me address your questions.  I put together a couple of slides last week that I can share with you.

Slide 1:  Assumptions for SAFENeT
Optimized for enterprise environment with respect to security and performance
Call Server owned by enterprise
SIP-based, system supports S/MIME
TLS using mutually authenticated certification for secure message exchange
NAT vendors may implement their devices however they see fit, i.e., SAFENeT is not restricted in the type of NAT.



Slide 2:  Side by side comparison of SIMCO and SAFENeT

	SIMCO	SAFENeT
Target customer	General, comprehensive	Optimized for enterprise
Call server ownership	Call server could be owned by anybody	Call server owned by enterprise
Protocol	binary	ASCII
Message transmittal - server to NAT/FW	IPsec potentially across public realm	TLS within enterprise (maybe with a shared key)
Performance	One message/command	Assert better than current draft regarding traffic volume
Versatility	Could be extended to address	Offers opportunity to address issues such as QoS
Simplicity	Binary is better	ASCII addresses enterprise market so inexpensive is not an issue

Explaining the advantages of SAFENeT in the table:

Advantages of SAFENeT:

Addresses higher level of security for those enterprises requiring it.

Enterprise ownership of call server lowers risk of security attack, i.e., SIMCO uses messages to server to initiate NAT/FW actions     remember, server could be within enterprise

Protocol offers more functionality such as setting QoS parameters.

Easier to establish/coordinate rules between server and NAT/FW, i.e., administered by same enterprise IT group.

Protocol for reservation lowers traffic volume with more control given to the (enterprise owned) call server, i.e., can reserve in blocks.

**************************

Having stated that let me state what I believe (and I could be wrong) what the status in MIDCOM is.  

The group has done and published an RFC on protocol evaluation (RFC 4097) and in that analysis, SNMP came out the winner.  It may need some simple extensions but it is the best of the group.

The people I talked with believe SIMCO is on a track towards Experimental RFC.

The IESG rules allow more than one Experimental RFC from a group.

I now realize that with RFC 4097, my goal of SAFENeT becoming an RFC is either premature, unrealizable, or both.  So let me take a more realistic position and note that, given the advantages I see as noted above, SAFENeT should be offered as being on an Experimental RFC track too.  While others may not see or agree with the advantages I see, we do have a client who does, one who looks on security as uppermost.

Let me add that I see nothing wrong with SIMCO nor the decision by th egroup on SNMP.  I just see an advantage for a simpler, higher performance and more secure spec on which to build a product (and restricts some of its messaging in the provision process); and yes, it gives up something concerning the comprehensive nature of the others. 

I hope the above clarifies my position.

I'll be in BEHAVE and MSEC this afternoon although there isn't much time after either of those.  Would meeting after PKI4IPSEC be better?  I could stay in the room after to be easier to find.

	Rick



 -----Original Message-----
From: 	Juergen Quittek [mailto:[e-mail]] 
Sent:	Tuesday, August 02, 2005 6:07 AM
To:	Martin Stiemerling; Townsend, Richard L, JR (Rick); [e-mail]
Subject:	Re: [midcom] Basic question about SAFENeT I-D

--On 8/2/2005 11:52 AM +0200 Martin Stiemerling wrote:
> Hi Rick,
>
> I'm re-reading the SAFENeT I-D and have a basic question. It is about
> Section 2.4 "The MIDCOM and NSIS Solutions". You say this section is
> describes existing solutions on middlebox traversal and configuration.
> After reading it again, I still miss a reference to any already
> available/existing that refers to a MIDCOM-type solution. How about
> the FCP of Jiri Kuthan, MIDCOM MIB, or SIMCO?
>
> The solution described in Section 4.4 "Details of SAFENeT UA Communication
> Protocol (SUCP)" will fit to SIPPING working group and not MIDCOM. If not
> specified there, or in the SIP working group, already.
>
> I would like to see a clarification on this before we can meet
> face to face.

A meeting would be a great opportunity for clarifying this and other
issues.

Rick, when would you be available?

Thanks,

    Juergen


_______________________________________________
midcom mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/midcom