RE: I-D on SAFENeT

Hi Scott,

Thank you very much for the detailed comparison between SAFENeT and SIMCO.
Please see some comments inline.

--On 7/13/2005 3:42 PM +0200 Stott, David (David) wrote:
>
> After reading draft-stiemerling-midcom-simco-07 and RFC 3898, SIMCO is
> considerably more similar to SAFENeT than I was previously aware of.
> I suspect that as things evolve, SIMCO can replace SCP (the communication
> protocol in SAFENeT).
>
> One critical difference between 3898/SIMCO and SAFENeT is the extended
> mode, which modifies SIP to make use of the base mode.
>
> There are a few important capabilities in SAFENeT that seem to be lacking in SIMCO:
>
> 1. SAFENeT supports rate-limiting as a middlebox option.  For example, a VoIP
> server could rate limit an RTP connection based on the CODECs being used.

It is correct that SIMCO does not do so.  When designing SIMCO, we were
building an enterprise solution for VoIP including QoS control.  Our analysis
and feedback from customers made us believe that per connection QoS is not
the right approach to control QoS in a scalable way.

But what about SAFENeT.  Is there any protocol specification available, yet?
The message exmaples you describe in draft-stott-behave-safenet-00.txt do
not cover any rate limiting.  Also the SAFENeT request field types in Table 1
of this draft do not support specifying a rate.  It looks like you came to
the same conclusion that per-connection QoS control is not the right approach.

> 2. SIMCO does not appear to be extensible.

The binary message structure for requests and replies is extensible.

The ASCII structure of SAFENeT that I can guess from the examples in
your draft seem to be very extensible, but it is hard to finally judge
this without a protocol specification.

> 3. SAFENeT assumes that some NAT middleboxes DO NOT support reservation.  For me,
> that is the nominal case for low-end NATs.  I consider reservation an optimization.
> SIMCO appears to require that the middleboxes support reservation.

The reservation request PRR is not necessary, if at least PER is supported.
This is not well documented in the SIMCO I-D.  SIMCO has the return code
  0x0340  :  negative reply: transaction not supported
This can be used by middleboxes that do not support PRR.
It looks like a good idea to add a section on compliancy to the SIMCO draft.

> 4. SAFENeT has an UPDATE operation that can update the parameters of a
> SAFENeT session.  It is essential for SAFENeT because it is used to
> activate a rule.  This part of the operation is handled in SIMCO with
> PRR and PEA messages.  SAFENeT also supports modifying parameters in
> an existing connection, which SIMCO does not appear to support
> (without creating a new policy).  I thought I had a complicated case
> with multiple NATs that required the UPDATE message or reservation)
> after opening (but not activating) bindings on each of the NATs.
> I can't find that case right now.

We decided against an update function (beyond updating the lifetime),
because it complicates the semantics and the server (middlebox)
implementation significantly.  There might be scenarios where you
could use it, but we considered them not worth the effort of supporting
an update.  Maybe you have one that is convincing.

> 5. [I'm just now understanding the SIMCO draft, so I am not
> positive I understand it correctly here].  With SAFENeT, the normal
> mode of operation will use 3-tuples on each rule, referred to as FROM,
> TO, and FOR.  FROM and TO are the original and mapped
> (NATed) address tuples for the "local" host.  FOR is address tuple
> (the port is often a wildcard) for the "remote" host (i.e., the source
> address in the inbound packets).  The purpose of the FOR address tuple
> is a security measure such that the middlebox "lock down" the binding
> so that only the intended destination (remote host) can get back in.

We are in full agreement.  Your terms map to concepts in RFC 3989, Figure 3:
  - FROM - A0
  - TO   - A2
  - FOR  - A3

> There are also a number of minor differences between the two approaches:
>
> - SAFENeT uses text-based protocols, SIMCO uses binary.  My
> implementation is in XML, I think we have an older text-based protocol
> in the draft.

You are right.  The examples in your draft are not using XML.

> Except that this affects extensibility, allows textual
> error message, and facilitates prototype development, this is not a
> major factor.

After starting as an ASCII protocol, as SAFENeT does now also show in
your draft, SIMCO moved to a binary protocol in order to have a small
footprint on small devices and in order to allow its support on high
performance middleboxes.

We found that such an ASCII encoding combines the worst of both worlds.
Plain ASCII cannot be checked easily for correctness and is also not
really low in resource consumption.  So consequently, either an XML
or a binary encoding should be preferred.  At this point we decided
for a binary encoding for the reasons stated above.

> - SAFENeT assumes "some" transport protocol is used to provide
> security (and presumes TLS w/mutual authentication will be most
> commonly used).  SIMCO specifies transport mode IPSec[1].  I see
> very little difference in the security of the two, but prefer not
> to require any particular one.

I am not very happy with the IPsec requirement for SIMCO.  Actually,
we do also have a TLS implementation.

> - I have issues with the authentication part.  Clearly, the
> transport protocol is providing authentication.  Without the
> security provided by the transport protocol, the authentication
> procedures is vulnerable to Man in the Middle attacks, not to
> mention simply changing packet contents after authenticating.
> What do you gain by including the authentication procedure?
> Why not remove it?

I hope Martin will comment on this.

> - I purposefully don't support operations for the manager
> (e.g., application server) to query the server capabilities
> or the existing rules.  My philosophy is that manager should
> maintain this information about the rules and be configured with
> knowledge of the capabilities as a requirement to be authorized
> to use it.  Maybe I'm going a little to far on this one.
> As long as the SIMCO server is allowed to give a "you're
> unauthorized" error reply to these requests (at its discretion)
> I'm okay with them.

It simplifies fail-over from one MIDCOM agent to another.

> I believe that the two solutions are different enough that we
> should continue with both in the short term.  I also believe
> that can merge to a single solution before long.

SIMCO has been submitted to the RFC Editor as individual submission.
We expect to receive some review and might be able to apply
minor changes, but I do not expect major modifications.
Also SIMCO was designed to be fully compliant to the protocol
semantics in RFC 3989 developed by the MIDCOM WG. Certainly,
SIMCO will stick to this semantics.

> Notes:
>
> [1] Top of page 6 in the draft, you reference security considerations as section 11, it is section 9.2.
>
> [x] In figure 12, should the first address type have length of 0x0004?  The "ip version number' fields are inconsistent with the text (text has 0x1 for IPv4, figure has 0x4, and similarly for v6)

Thank you very much for these helpful hints.  We will consider them
when updating the SIMCO draft.

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: 	Juergen Quittek [mailto:[email protected]]
> Sent:	Sunday, July 10, 2005 11:08 AM
> To:	Townsend, Richard L, JR (Rick);
> 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
>