RE: I-D on SAFENeT

Hi Rick,

--On Donnerstag, 14. Juli 2005 8:41 Uhr -0400 "Townsend, Richard L, JR 
(Rick)" <[email protected]> wrote:

| 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

Right, the text in RFC 3303 says:

   This document describes a framework in which application intelligence
   can be moved from middleboxes into external MIDCOM agents.  The
   premise of the framework is to devise a MIDCOM protocol that is
   application independent, so the middleboxes can stay focused on
   services such as firewall and NAT.  The framework document includes
   some explicit and implied requirements for the MIDCOM protocol.
   However, it must be noted that these requirements are only a subset.
   A separate requirements document lists the requirements in detail.

Probably, there is a misunderstanding about what "external agent" is about.
It is not an agent external to a network but the agent is separated from
the middlebox. That is the basic idea of MIDCOM. The actual location
of the agent is independent of the protocol itself, but rather a
network design question.


| 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

If you are worried about the agent being external of the middlebox: The
MIDCOM MIB and SIMCO both are able to have both, agent and "server", on the
same box.

  Martin

| 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
|
|
| _______________________________________________
| midcom mailing list
| [email protected]
| https://www1.ietf.org/mailman/listinfo/midcom