RE: I-D on SAFENeT

Hi Juergen,
Thank you for your comments.  

One of the fundamental differences between SAFENeT and the existing MIDCOM work is the explicit location of the call server.  From my reading of RFC 3989, RFC 3989 states the call server is externally located.  Having the call server located within the enterprise's control offers a simplification in the process of setting up or receiving a call.  Additionally it offers a more simplified environment in which to roll out an implementation and therefore offers a technique in which we may get a quicker deployment in the industry.  E.g., in many enterprises the IT department can roll out applications to the hosts within the enterprise as well as to the servers, at least putting deployment under a single control.  Another advantage of having the call server within the enterprise increases the security of the process since a enterprise owned server can bring proper focus to the security issue.

On a more technical basis, the SAFENeT architecture allows the originating host to make changes reflecting the binding addresses, e.g., recalculating the message hash, thereby allowing message measures.  The existing architecture requires a server in the public realm to make these changes, a situation some may find uncomfortable.

I did not mean to imply that the current protocol and standard neglected any issues, only that there may be a simpler way to address an industry problem albeit for enterprises and not necessarily for the more comprehensive problem for non-enterprise architectures, a much harder problem.  Indeed, what we are pointing out are not shortcomings of the existing work, but alternative that has the advantages I point out in this message.

I believe it is good news that SAFENeT does not violate the existing protocols.  Our intent is only to add to those existing solutions with an alternative of a call server within the enterprise to make the VoIP problem simpler and by adding security measures.

We are taking another look at the SIMCO draft to see what responses we might have relative to that document.

	Rick

 -----Original Message-----
From: 	Juergen Quittek [mailto:[email protected]] 
Sent:	Sunday, July 10, 2005 11:08 AM
To:	Townsend, Richard L, JR (Rick); [email protected]
Subject:	RE: [midcom] I-D on SAFENeT

Hi Rick,

--On 7/8/2005 5:29 PM +0200 Townsend, Richard L, JR (Rick) wrote:

> Hi Martin,
> I'm not sure how to answer your question directly so let me take a
> slightly different approach that I intend to be a helpful way to go.
>
> The main difference between SAFENeT and existing MIDCOM work is that SAFENeT
> provides a complete solution, whereas existing work defines mostly the
> architecture, but not implementation.

I do not get this point.  The MIDCOM MIB module is all you need for
implementing the MIDCOM standard.  And the SIMCO protocol is already
implemented and had a first interoperability testing event recently.

I do not see that existing work neglected implementation issues.

>                                         Another difference is that SAFENeT
> provides a close secure relationship between the manager and agent (e.g.,
> call server and middlebox)(they are both owned by the enterprise), whereas
> the other architectures provide for the case where there is no a priori
> relationship between the components (which may have security implications).

Yes, the other solutions are also suited for other cases than the one
SAFENeT focuses on.  Can you say which concrete disadvantages you see
compared to SAFENeT?

>  I believe the configuration where the server can reserve resources (e.g.,
> ports for NAT mappings) is new, and critical for high-performance.

It is not new.  Both, MIDCOM-MIB and SIMCO fully implement the MIDCOM
protocol semantics (RFC 3989) with the Policy reserve Rule that serves
for reserving resources at the middlebox.

I did not see any signaling flow chart in draft-stott-behave-safenet-00.txt
that is not covered by the MIDCOM-MIB and the SIMCO protocol.

> While SAFENeT may provide a somewhat limited scope, i.e., an enterprise
> solution, I believe it will provide useful insights in attacking the NAT/FW
> problem.
>
> My intention is to help the development of MIDCOM protocols, not to replace
> them.  And that we feel that it will be useful for MIDCOM to have a working
> implementation (in draft form) to learn from before finalizing future MIDCOM
> standards.

You are very welcome to do so.  In order to help us improving MIDCOM
protocols, a very good first step would be to identify shortcomings of the
MIDCOM protocol semantics (RFC 3989).

Also please indicate disadvantages of the MIDCOM MIB module
draft-ietf-midcom-mib-05.txt compared to SAFENet.  If you like, please also
have a look at the SIMCO protocol (draft-stiemerling-midcom-simco-07.txt).

> 	Rick

Thanks,

    Juergen
-- 
Juergen Quittek        [email protected]       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de


>  -----Original Message-----
> From: 	Martin Stiemerling [mailto:[email protected]]
> Sent:	Friday, July 08, 2005 8:02 AM
> To:	Townsend, Richard L, JR (Rick); '[email protected]'
> Subject:	Re: [midcom] I-D on SAFENeT
>
> Hi Richard,
>
> I have read the draft but still do not know what the difference to the usage
> of the MIDCOM MIB or SIMCO is?
>
> Thanks
>
>   Martin
>
> --On Mittwoch, 6. Juli 2005 15:46 Uhr -0400 "Townsend, Richard L, JR
> (Rick)" <[email protected]> wrote:
>
>| Hi all,
>| After several discussions with ADs and others, we have reached the view
>| that MIDCOM should be the group to discuss the I-D on SAFENeT, an
>| enterprise solution to the NAT/FW traversal problem.  Melinda has asked
>| me to advise you that the I-D is published as
>| <draft-stott-behave-safenet-00.txt>.
>|
>| To see how SAFENeT addresses the NAT/FW traversal problem differently,
>| let me refer you to sections of the I-D rather than rewrite them here.
>|
>| Section 1.5 describes what SAFENeT is trying to accomplish.
>| Section 2 describes existing views/solutions of the NAT/FW traversal.
>| Section 3.1 gives an overview of SAFENeT.
>|
>| We believe SAFENeT could be fit within other developing
>| architectures/protocols if that's what the group desires and it is
>| reasonable simple, in part, because it carves out a niche in that it
>| addresses enterprise networks and does not try to solve the general
>| problem.
>|
>| Comments are welcome.
>|
>| 	Rick
>|
>| _______________________________________________
>| midcom mailing list
>| [email protected]
>| https://www1.ietf.org/mailman/listinfo/midcom
>
>
> _______________________________________________
> midcom mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/midcom