RE: I-D on SAFENeT

Hi Juergen,
I'm juggling being at another meeting an dtrying to respond to your questions so pardon for the shortness of this response. 
Regarding the reference in 3303, it's on page 2, next to last paragraph, first sentence - "moved from middleboxes into external MIDCOM agents".
Without investigating, I'm sure the protocol could likely handle the SAFENeT case and may even be simpler in doing so.  My larger concern is the seeming  constraint the agent be external.  Is that a situation the group should re-visit?
	Rick


 -----Original Message-----
From: 	Juergen Quittek [mailto:[email protected]] 
Sent:	Wednesday, July 13, 2005 6:44 PM
To:	Townsend, Richard L, JR (Rick); [email protected]
Subject:	RE: [midcom] 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