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

[Juergen Quittek <[e-mail]>]

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:

> 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

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

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

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?

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

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.

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

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