RE: I-D on SAFENeT

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

> Hi Juergen,
> Judging from your comments, I can believe that the existing work
> could cover the architecture and protocol proposed by SAFENeT.
> However, because those implementations cover the more comprehensive
> situations, i.e., more than the enterprise, they are likely to be
> more complicated than a SAFENeT implementation focusing on the
> enterprise.

Likely, yes.  But do you have any concrete evidence that they are
in fact more complicated?

And, if they are more complicated, does the simplification justify
an additional protocol?

> RFC 3303 is more limiting with respect to MIDCOM location than
> RFC 3989 (see comment in-line).
>
> SAFENeT is a different architecture, i.e., the call server is
> constrained to be within the enterprise network, that allows a
> simpler implementation

I assume that you can simplify the implementation of the existing
protocols if you restrict their application to enterprise networks.
Any doubts?

>                        and allows security measures to be
> incorporated in a more secure way.

Why would this not be possible for the existing solutions?

> As a separate pragmatic issue, deployment becomes easier because
> everything is under control of the enterprise.

Which is certainly true for all of the solutions.

> There may be  organizations that prefer the simpler, more secure,
> easier to deploy alternative.

Who would not?
Still I am looking for an evidence of the menitoned advantages
of SAFENeT.

> I did go back and check on my reference for the MIDCOM agent
> being in the external realm and found it in RFC 3303.  The
> alternative for putting the agent in a private environment
> is not mentioned.

Can you tell me where in RFC 3303 you found it?

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


> Please see specific comments in-line.
>
> 	Cheers,
> 	Rick
>
>
>  -----Original Message-----
> From: 	Juergen Quittek [mailto:[email protected]]
> Sent:	Tuesday, July 12, 2005 10:30 AM
> To:	Townsend, Richard L, JR (Rick); [email protected]
> Subject:	RE: [midcom] I-D on SAFENeT
>
> Hi Rick,
>
> --On 7/11/2005 8:39 PM +0200 Townsend, Richard L, JR (Rick) wrote:
>
>> 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.
>
> It is correct that RFC 3989 in general covers the case where the MIDCOM agent
> (call server) is located in the public Internet.  However, the typical
> (enterprise) network installations will have it within the private realm.
> And that is fully supported by RFC 3989.
> RFC 3303seems to restrict the agent to being in the external realm.
>
>> 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.
>
> This is all fully agreed.  It is definitely simpler concerning the security
> setup to install a MIDCOM agent (all server) within the private realm.  And
> I would also call this the more common case.  But what is different in
> SAFENeT that exploits the restriction that SAFENeT can only be deployment
> in the private realm?
> Bu that is SAFENeT's specific advantage.  Yes, it is restricted to enterprise-like networks.
>
>> 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.
>
> The PRR transaction in RFC 3989 reserves an external (public) address at
> the NAT that is returned to the MIDCOM agent and can be used for hash
> calculation and other issues.  why do you think this can only be obtained
> by a MIDCOM agent in the public realm?  Which information or functionality
> is missing if the MIDCOM agent is in the private realm?
> Could a MIDCOM agent residing in the public realm communicate back to the internal host?  Yes, but don't you have to communicate through the NAT and, in doing so, open a specific path through the NAT that is open to security breaches?  Our argument for
> SAFENeT is that this process is easier and more secure than otherwise.
>
>
>> 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 still do not see any concrete difference:
>   - MIDCOM agents according to RFC 3989 can be located in the internal realm
>     as well as in the external realm.
>   - Information about the external address that will be used when translating
>     a concrete internal address can be acquired in advance using the PRR
>     transaction defined in RFC 3989.
> RFC 3989 permits this but RFC 3303 does not.
>
>> 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.
>
> It is also good news having new people in the MIDCOM WG that help
> to better understand the issue and to improve the output.  You are very
> welcome.
> Good discussion is better than most alternatives.
>
>> We are taking another look at the SIMCO draft to see what responses we
>> might have relative to that document.
>
> Thanks,
>
>     Juergen
>
>> 	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
>>
>>
>> _______________________________________________
>> midcom mailing list
>> [email protected]
>> https://www1.ietf.org/mailman/listinfo/midcom
>
>
> _______________________________________________
> midcom mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/midcom