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

From: "Townsend, Richard L, JR (Rick)" <[email-masked]>
Date: Tue, 2 Aug 2005 10:51:07 -0400

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:[email-masked]] 
Sent:	Tuesday, August 02, 2005 6:07 AM
To:	Martin Stiemerling; Townsend, Richard L, JR (Rick); [email-masked]
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 02 Aug 2005 17:31:00 +0200

Rick,

Thanks for the information you sent.
Please find comments inline.

--On 8/2/2005 10:51 AM -0400 Townsend, Richard L, JR (Rick) wrote:

> 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.
>

I am still curious to see what your optimization you achieved
that is not achieved by MIDCOM.

> is not restricted in the type of NAT.

Do you also support NAT-PT?
I could not find it in your draft, because your protocol
is not specified in there.  The draft just gives examples
of SAFENeT messages.

> Slide 2:  Side by side comparison of SIMCO and SAFENeT

Sorry, this is hard to read.
Do you have a PPT of PDF version of your slide?

> Addresses higher level of security for those enterprises requiring it.

Which what technical feature.  I do not see it yet.
You say you disallow running SAFENeT over public Internet.
This implies that you have less need for security.  Right?

> 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

MIDCOM MIB, SIMCO and any other protocol complying with
the MIDCOM semantics work very well when owned by an enterprise
that operates its own network.  What is technically different
for SAFENeT except that you say it cannot operate in the
public Internet?

> Protocol offers more functionality such as setting QoS parameters.

Yes, this is a technical difference.
MIDCOM is not dealing with QoS configuration.

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

Which is true for all MIDCOM protocols.

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

Reserving of blocks is also supported by the MIDCOM semantics.

> 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.
>

I think Martin and I submitted it individually as an Informational RFC.
It complies with the MIDCOM semantics, it has been discussed by the MIDCOM WG,
but it is not an output of the MIDCOM WG.

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

Yes, certainly.

> 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
> the group 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.

Please substantiate your claims that SAFENeT is
  - simpler
  - providing higher performance
  - more secure
than existing solutions.

Thanks,

    Juergen

> 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
>
>
>