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