From daemon@optimus.ietf.org Tue Apr 2 03:33:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09852 for ; Tue, 2 Apr 2002 03:33:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA26672 for midcom-archive@odin.ietf.org; Tue, 2 Apr 2002 03:33:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26253; Tue, 2 Apr 2002 03:30:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26194 for ; Tue, 2 Apr 2002 03:30:18 -0500 (EST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09791 for ; Tue, 2 Apr 2002 03:30:15 -0500 (EST) Received: from hzsgp68.nl.lucent.com (h135-85-117-188.lucent.com [135.85.117.188]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g328TjA15605; Tue, 2 Apr 2002 03:29:45 -0500 (EST) Received: from lucent.com (hzsgp04.nl.lucent.com [135.85.117.104]) by hzsgp68.nl.lucent.com (8.11.0/8.11.0) with ESMTP id g329Sq032642; Tue, 2 Apr 2002 11:28:52 +0200 Message-ID: <3CA96C27.7BB91420@lucent.com> Date: Tue, 02 Apr 2002 10:30:31 +0200 From: Paul Sijben Organization: Lucent technologies, The Netherlands X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Melinda Shore CC: Jonathan Rosenberg , Mary Barnes , "'midcom@ietf.org'" Subject: Re: [midcom] Protocol Evaluation document template References: <1B54FA3A2709D51195C800508BF9386A03DE3906@zrc2c000.us.nortel.com> <5.1.0.14.0.20020328181716.00a849e0@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Melinda, are you implying that we may get a protocol selected that does not come out as "best" from the evaluation? I agree with those who spoke earlier that it may be a good idea to find out first what the protocol is supposed to do before starting to evaluate. Paul Melinda Shore wrote: > > At 06:09 PM 3/28/02 -0500, Jonathan Rosenberg wrote: > >The requirements documents are at a high enough level that I do not see > >how they would be used to rule out or support protocols. Just about any > >sensible protocol that supports a session oriented communication between > >two things, with messages in both directions, will meet the > >requirements. > > Right. I think there may be some confusion at work, though - > the protocol "evaluation" document is not a protocol recommendation > document - the decision about which protocol will ultimately be > used will take place after the evaluation document is complete. > By then the semantics document should be done or nearly done, > although I'm somewhat disappointed that there hasn't been one response > to the proposal that Tom has put out and there haven't been any other > proposals put forward. And, frankly, I don't think that the semantics > we settle on are going to have that much discriminatory power. > > I understand your concern but I think we're okay. If you're familiar > with "Indiana Jones and the Last Crusade" you may recall the scene in > which he steps into the abyss only to find that there's actually an > invisible bridge there. It's possible that there's no bridge here, > but I'm willing to try it anyway. I really don't want to delay starting > the protocol evaluation until the semantics are put together - it would > end up taking us over a year to finish. > > Melinda > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom -- Paul Sijben Tel:+31 356874774 Bell Labs - Advanced Technologies Fax:+31 356875954 Lucent Technologies (internal) http://voip.nl.lucent.com/~sijben Huizen, The Netherlands _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 2 03:37:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09942 for ; Tue, 2 Apr 2002 03:37:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA26841 for midcom-archive@odin.ietf.org; Tue, 2 Apr 2002 03:37:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA25770; Tue, 2 Apr 2002 03:22:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA25743 for ; Tue, 2 Apr 2002 03:22:06 -0500 (EST) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09695 for ; Tue, 2 Apr 2002 03:22:03 -0500 (EST) Received: from hzsgp68.nl.lucent.com (h135-85-117-188.lucent.com [135.85.117.188]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g328M3Y12587; Tue, 2 Apr 2002 03:22:04 -0500 (EST) Received: from lucent.com (hzsgp04.nl.lucent.com [135.85.117.104]) by hzsgp68.nl.lucent.com (8.11.0/8.11.0) with ESMTP id g329LA032617; Tue, 2 Apr 2002 11:21:10 +0200 Message-ID: <3CA96A59.361ACB91@lucent.com> Date: Tue, 02 Apr 2002 10:22:49 +0200 From: Paul Sijben Organization: Lucent technologies, The Netherlands X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom-PT Taylor CC: midcom@ietf.org Subject: Re: [midcom] MIDCOM Semantics References: <4D79C746863DD51197690002A52CDA0001E8A1B8@zcard0kc.ca.nortel.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit Tom, sorry for not responding to this sooner but your mail must have gotten lost in the noise. In fact this looks fairly good. I would consider this to be a good start to the semantics work. Paul > Tom-PT Taylor wrote: > > Cedric Aoun and I are working on an I-D describing MIDCOM semantics. > What follows is the part that deals with message contents. The > remainder of the draft deals with the detailed structure of Policy Rules > and shows application of the messages and detailed structure to the > scenarios documented in draft-ietf-midcom-scenarios-02.txt. > > 3 Message semantics > > 3.1 General assumptions > > 1. The exchanges are all structured as request/response, to accord with > requirement 2.1.5 (known and stable state). There are other ways to > meet this requirement, if someone wants to document them. > > 2. No explicit association startup sequence. Instead, each party > supplies its credentials in every message it sends. The Agent's > authority is based on those credentials and the policy available to the > Middlebox. > > 3. There is an ambiguity in the requirements regarding the ability to > group "rulesets", as well as inconsistency in terminologies where > rulesets are used instead of policy rule. It is assumed that a Policy > Rule provides all of the grouping required. > > 4. It is assumed in this note that the protocol supports both "all or > nothing" and partial intallation of Policy Rules (see discussion in the > next section), where the choice is made by the Agent. The partial > installation option may be considered too complex to support, in which > case the semantics will simplify accordingly. > > 3.2 Summary of Exchanges: > > 1) Policy Rule Request/Response > > Request from the Agent to install a specific Policy Rule, associating it > with a specific identifier and assigning it a specific lifetime. The > request also indicates whether partial installation is allowed. This > request has replacement semantics: if the identified rule was previously > installed, it is replaced completely by the content of the request > assuming that the Agent has the authority to make this request. This > assumption is made to simplify the semantic presentation: the WG may > wish as an optimization to define an additional message to incrementally > modify a rule already in place. > > An empty Policy Rule implies that the rule has been deactivated and the > associated identifier is available for reuse. > > The Policy Rule Response indicates the Policy Rule actually installed > and the lifetime assigned to it by the Middlebox. > > 2) Middlebox Action Notification/Acknowledgement > > Asynchronous notification from the Middlebox, indicating what Policy > Rule was affected, if any, what action or event has occurred, and a > reason for the action or event. Acknowledgement has no additional > content. > > 3) Deactivation Request/Acknowledgement > > Request from either peer to deactivate all Policy Rules associated with > the given Agent. Acknowledgement indicates compliance and has no > additional content. > > Open issue: does the Middlebox deactivate all Policy Rules the Agent has > ever installed, or only those for which it is the most recent installer? > > 4) Policy Rule Audit Request/Response > > Request from the Agent to audit the content of a given Policy Rule or > all rules associated with that Agent, as viewed by the Middlebox. The > response provides the desired information, possibly in multiple > messages. > > Open issue: when "ALL" is requested, does the Middlebox return all > Policy Rules the Agent has ever installed, or only those for which it is > the most recent installer? > > 5) Capability Request/Response > > Assuming the possibility that the Middlebox may support differing > options, the request is made by the Agent and the response indicates the > supported Middlebox options. > > Open issue: besides the Policy Rule audit, there is also the possibility > of a flow audit, asking about the specifications for active flows which > have been bound to Policy Rules. > > > 3.3 Detailed Message Description > > General parameters > ------------------ > > Every message carries the following parameters: > > - Version: the version of the MIDCOM protocol used to encode the > message. > - Source Identifier: the Agent or Middlebox identifier associated with > the accompanying credentials. > - Credentials: authenticating content. > - Transaction Identifier: used to correlate requests with their > responses. > > These are omitted from the following message descriptions for brevity. > > 1 (a): Policy Rule Request (Agent to Middlebox) > -------------------------- > > Specific Parameters: Policy Rule Identifier, Policy Rule, Lifetime, > Integrity > > Policy Rule Identifier: > An identifier which can be used to correlate further requests involving > this rule. At a minimum, the tuple {Agent Identifier, Middlebox > Identifier, Policy Rule Identifier) must be unique. It is probably > necessary that the Policy Rule Identifier be globally unique so that one > Agent can (if given the authority) manipulate rules belonging to other > Agents. > > Policy Rule: > The specific Policy Rule which the Agent is asking to take effect, > specified as a set of {Filter, Action} pairs. This replaces any Policy > rule previously associated with the same Policy rule Identifier. An > empty Policy Rule implies that the rule has been deactivated and the > associated identifier is available for reuse. > > Lifetime: > The desired lifetime of the rule, e.g. in number of seconds from the > time of installation. The Middlebox deactivates the rule and notifies > the Agent if the lifetime expires. The Middlebox may autonomously > extend the lifetime when it detects packet activity coming within the > scope of the Policy Rule. Note that such autonomous extension could be > undesirable under certain failure conditions. If the Policy Rule is > empty, Lifetime is set to 0. > > Integrity: > This has two values: > (a) The Policy Rule must apply completely or not at all. > (b) Partial installation of the Policy rule is allowed. > Integrity has effect throughout the lifetime of the rule: > > · at the time of processing of the Policy Rule request, it affects > the outcome if conflicting Policy Rules are found > > · subsequently, if any Agent issues a Policy Rule request with a > different Policy Rule Identifier which is found to conflict with this > one and policy finds that this one is of lower priority, Integrity > determines whether it is deactivated or modified. > > If a Policy Rule Request causes another Policy Rule to be modified or > deactivated, the Middlebox sends a Middlebox Action Notification message > to the Agent which requested the installation of that rule, as well as > sending a Policy Rule Response to the source of the Policy Rule Request. > > 1(b) Policy Rule Response (Middlebox to Agent) > ------------------------- > > Specific parameters: Policy Rule Identifier, Policy Rule, Lifetime, > Reason > > Policy Rule Identifier: > Policy Rule Identifier as it appeared in the Policy Rule Request. > > Policy Rule: > The Policy Rule actually installed. If partial installation is allowed > this may differ from the Policy Rule in the original request. If the > request was denied completely this must be empty. > > Lifetime: > The rule lifetime actually assigned by the Middlebox. This may differ > from the lifetime requested, regardless of the value of Integrity in the > request. Changes in lifetime are not reflected in Reason (e.g. a > request could be "accepted", yet lifetime has been modified). If the > Policy Rule is empty, Lifetime is set to 0. > > Reason: > Indicates the reason for the outcome. Possible values are: > - accepted > - Policy Rule modified due to conflict > - denied due to conflict (returned Policy Rule must be empty) > - Policy Rule modified due to lack of resources > - denied due to lack of resources (returned Policy Rule must be empty) > - denied due to lack of authority (returned Policy Rule must be empty) > > 2(a) Middlebox Action Notification (Middlebox to Agent) > ---------------------------------- > > Specific parameters: Reason, Policy Rule Identifier (optional), Policy > Rule (optional) > > Reason: > Indicates why the notification was issued. Possible values are: > - Policy Rule modified due to conflict (Policy Rule Identifier and > Policy Rule must be present) > - Policy Rule deactivated due to conflict (Policy Rule Identifier must > be present) > - Policy Rule deactivated due to lifetime expiry (Policy Rule > Identifier must be present) > - ??? > > Policy Rule Identifier: > If present, identifies the Policy Rule affected by the event. > > Policy Rule: > If present, indicates the present content of the given Policy Rule. > > 2(b) Middlebox Action Acknowledgement (Agent to Middlebox) > ------------------------------------- > > No specific parameters. > > 3(a) Deactivation Request (either Agent or Middlebox to peer) > ------------------------- > > No specific parameters. > > 3(b) Deactivation Acknowledgement (responding peer to requesting Agent > or Middlebox) > --------------------------------- > > No specific parameters. > > 4(a) Policy Rule Audit Request (Agent to Middlebox) > ------------------------------ > > Specific parameter: Policy Rule Identifier > > Policy Rule Identifier: > The identifier of the specific policy to be audited, or else the special > identifier ALL. If ALL is specified the request is for an audit of all > Policy Rules installed by the requesting Agent. > > 4(b) Policy Rule Audit Response (Middlebox to Agent) > ------------------------------- > > Specific parameters: Sequence Number, Total Count, Policy Rule > Identifier, Policy Rule, Lifetime, Integrity > > Each Policy Rule Audit Response message reports the content of one > Policy Rule associated with the Agent. > > Sequence Number: > The order of the message in the set of responses, beginning with 1 and > incrementing by 1 for each additional message. > > Total Count: > The total number of Policy Rules associated with the Agent. This may be > 0 if no Policy Rules are currently associated with the Agent. > > Policy Rule Identifier (optional): > Present unless no Policy Rules are currently associated with the Agent. > Identifies the Policy Rule specified in this message. > > Policy Rule (optional): > Present unless no Policy Rules are currently associated with the Agent. > Specifies the Policy Rule as it is known to the Middlebox. > > Lifetime (optional): > Present unless no Policy Rules are currently associated with the Agent. > Indicates the remaining lifetime of the Policy Rule at the time of the > response. > > Integrity (optional): > Present unless no Policy Rules are currently associated with the Agent. > Indicates whether the Middlebox deactivate or modify the Policy Rule if > a conflicting rule takes precedence. > > 5(a) Capability Request (Agent to Middlebox) > ----------------------- > > Specific parameters: Option List > > Option List (optional): > if present, indicates options the Agent proposes to use. Possible > options are for further study. > > 5(b) Capability Response (Middlebox to Agent) > ----------------------- > > Specific parameters: Option List > > Option List): > indicates options supported by the Middlebox. Possible options are for > further study. > > Tom Taylor > taylor@nortelnetworks.com > Ph. +1 613 736 0961 (ESN 396 1490) > -- Paul Sijben Tel:+31 356874774 Bell Labs - Advanced Technologies Fax:+31 356875954 Lucent Technologies (internal) http://voip.nl.lucent.com/~sijben Huizen, The Netherlands _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 2 03:37:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09961 for ; Tue, 2 Apr 2002 03:37:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA26869 for midcom-archive@odin.ietf.org; Tue, 2 Apr 2002 03:38:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA25956; Tue, 2 Apr 2002 03:26:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA25923 for ; Tue, 2 Apr 2002 03:26:16 -0500 (EST) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09741 for ; Tue, 2 Apr 2002 03:26:13 -0500 (EST) Received: from hzsgp68.nl.lucent.com (h135-85-117-188.lucent.com [135.85.117.188]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g328Pg816902; Tue, 2 Apr 2002 03:25:42 -0500 (EST) Received: from lucent.com (hzsgp04.nl.lucent.com [135.85.117.104]) by hzsgp68.nl.lucent.com (8.11.0/8.11.0) with ESMTP id g329On032630; Tue, 2 Apr 2002 11:24:49 +0200 Message-ID: <3CA96B33.58D7E4B3@lucent.com> Date: Tue, 02 Apr 2002 10:26:27 +0200 From: Paul Sijben Organization: Lucent technologies, The Netherlands X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Louis-Nicolas Hamer , "'James_Renkel@3com.com'" , Melinda Shore , Mary Barnes , "'midcom@ietf.org'" Subject: Re: [midcom] Protocol Evaluation document template References: <9FBD322B7824D511B36900508BF93C9C01D0E612@zcard031.ca.nortel.com> <3CA7CED3.1D8C6C8B@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Jonathan, don't give in so quickly. I actually agreed with your earlier statement and I would assume others would do so as well if they just have to to catch up with the mailing list. Paul Jonathan Rosenberg wrote: > > Louis-Nicolas Hamer wrote: > > > > I tend to agree with Jonathan but I also feel that we should move > > forward > > with the protocol evaluation as soon as possible...what I am scared of > > is what > > some call "analysis-paralysis"... > > Since I appear to be in the minority, I'll cease and desist on this > point. However, I do want to be clear that I was not proposing analysis > of any sort; the "abstract protocol" is design work - to specify the > protocol itself in all details but the syntax. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom -- Paul Sijben Tel:+31 356874774 Bell Labs - Advanced Technologies Fax:+31 356875954 Lucent Technologies (internal) http://voip.nl.lucent.com/~sijben Huizen, The Netherlands _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 2 07:26:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12883 for ; Tue, 2 Apr 2002 07:26:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA07663 for midcom-archive@odin.ietf.org; Tue, 2 Apr 2002 07:26:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA07498; Tue, 2 Apr 2002 07:24:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28739 for ; Tue, 2 Apr 2002 04:20:26 -0500 (EST) Received: from cvis21.Marconicomms.com (cvis21.marconicomms.com [195.99.244.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10441 for ; Tue, 2 Apr 2002 04:20:21 -0500 (EST) Received: from cvis05.marconicomms.com (unverified) by cvis21.Marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Tue, 2 Apr 2002 10:19:48 +0100 Received: from cvdgwy01.uk.marconicomms.com by cvis05.marconicomms.com with ESMTP (8.10.2+Sun/cvms-35) id g329Jou06993; Tue, 2 Apr 2002 10:19:50 +0100 (BST) Subject: Re: [midcom] Protocol Evaluation document template To: "Melinda Shore Cc: "Jonathan Rosenberg , "Mary Barnes , ""'midcom" "@marconi.com X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: "Philip Mart" Date: Tue, 2 Apr 2002 10:17:38 +0100 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(Release 5.0.8 |June 18, 2001) at 02/04/2002 10:19:49 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Melinda, You seem to suggest, >I don't think that the semantics >we settle on are going to have that much discriminatory power ,that the choice of protocol is predominantly about the container protocol itself and the semantics are not important. Whilst the choice of container protocol is probably paramount it must also result in a fit for purpose protocol and correct compveyance of the semantics is an important engineering requirement. I hope that there will be no choice made until the semantics are well understood since they form a refinement of the requirements. Ideally the semantics should be mapped into candidate "concrete" protocols so that an informed choice can be made. I suspect this means that semantics and concrete protocol mappings should proceed in parallel to the decision point. The decision should be made only when the semantics are complete leaving only minor changes to the mappings. Phil _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 2 07:28:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12936 for ; Tue, 2 Apr 2002 07:28:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA07787 for midcom-archive@odin.ietf.org; Tue, 2 Apr 2002 07:28:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA07523; Tue, 2 Apr 2002 07:24:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20568 for ; Mon, 1 Apr 2002 18:51:43 -0500 (EST) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19319 for ; Mon, 1 Apr 2002 18:51:40 -0500 (EST) Received: from jku2.iptel.org (dhcp218.fokus.gmd.de [195.37.78.218]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g31Nq6Z06308; Tue, 2 Apr 2002 01:52:06 +0200 Message-Id: <5.1.0.14.0.20020402012023.00b415f0@mailhost.fokus.gmd.de> X-Sender: jiri@iptel.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Apr 2002 01:49:53 +0200 To: Jonathan Rosenberg , Louis-Nicolas Hamer From: Jiri Kuthan Subject: Re: [midcom] Protocol Evaluation document template Cc: "'James_Renkel@3com.com'" , Melinda Shore , Mary Barnes , "'midcom@ietf.org'" In-Reply-To: <3CA7CED3.1D8C6C8B@dynamicsoft.com> References: <9FBD322B7824D511B36900508BF93C9C01D0E612@zcard031.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I'm personaly not very convinced about efficiency of an iterative "evaluate-x-pet-protocols" --> "refine requirements" --+ ^ | +---------------------------------------------------+ process either. I guess it would result in a bunch of documents well demonstrating that each author's pet protocol makes the requirements happy, if tweaked enough. Nice to have, but I would prefer having a simple, interoperable protocol with running code soon. I personaly do not see how we can approach such an objective using this process. Starting from the minimum the MidCom protocol must accomplish rather than from maximum which someone's favorite protocol is capable of seems to me a much more feasible strategy. -Jiri At 05:06 AM 4/1/2002, Jonathan Rosenberg wrote: >Louis-Nicolas Hamer wrote: >> >> I tend to agree with Jonathan but I also feel that we should move >> forward >> with the protocol evaluation as soon as possible...what I am scared of >> is what >> some call "analysis-paralysis"... > >Since I appear to be in the minority, I'll cease and desist on this >point. However, I do want to be clear that I was not proposing analysis >of any sort; the "abstract protocol" is design work - to specify the >protocol itself in all details but the syntax. > >-Jonathan R. -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 2 07:45:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13435 for ; Tue, 2 Apr 2002 07:45:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA09089 for midcom-archive@odin.ietf.org; Tue, 2 Apr 2002 07:45:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08990; Tue, 2 Apr 2002 07:43:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08959 for ; Tue, 2 Apr 2002 07:43:53 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13397 for ; Tue, 2 Apr 2002 07:43:51 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g32ChLJ8006946; Tue, 2 Apr 2002 04:43:21 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADJ98715; Tue, 2 Apr 2002 04:40:58 -0800 (PST) Message-Id: <5.1.0.14.0.20020402073643.00a81810@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Apr 2002 07:47:05 -0500 To: "Philip Mart" From: Melinda Shore Subject: Re: [midcom] Protocol Evaluation document template Cc: midcom@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 10:17 AM 4/2/02 +0100, Philip Mart wrote: >You seem to suggest, >>I don't think that the semantics >>we settle on are going to have that much discriminatory power >,that the choice of protocol is predominantly about the container protocol >itself and the semantics are not important. To the contrary - I think the semantics are important and the container protocol less so. What I was trying to say is that I'm not convinced that the semantics of what we're trying to do will be critical to distinguishing from among various proposed protocols. I suspect that the biggest problem we're facing, in terms of getting the work completed, is that there are several protocols that could do a very good job, and although I could be convinced otherwise it right now seems to me that our high-level requirements (does the protocol support asynchronous messages?, etc.) are likely to be more valuable in teasing out the difference levels of suitability. I say this having midcom-ified several IETF protocols. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 2 07:55:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13559 for ; Tue, 2 Apr 2002 07:55:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA09516 for midcom-archive@odin.ietf.org; Tue, 2 Apr 2002 07:55:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09411; Tue, 2 Apr 2002 07:53:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09343 for ; Tue, 2 Apr 2002 07:52:29 -0500 (EST) Received: from Mitel.COM ([216.191.234.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13537 for ; Tue, 2 Apr 2002 07:52:27 -0500 (EST) From: Tom_Gray@Mitel.COM Received: from kanmta01.mitel.com (kanmta01.kanata.mitel.com [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id HAA03532 for ; Tue, 2 Apr 2002 07:51:53 -0500 (EST) Importance: Normal X-Priority: 1 (High) Subject: Re: [midcom] Protocol Evaluation document template To: "'midcom@ietf.org'" Date: Tue, 2 Apr 2002 07:51:51 -0500 Message-ID: X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.7 |March 21, 2001) at 04/02/2002 07:51:53 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Someone wrote: >I agree with those who spoke earlier that it may be a good idea to find >out first what the protocol is supposed to do before starting to evaluate. How relevant is a requirements document and exercise, if they do not determine what the protocol is supposed to do? If requirements cannot be used to discriminate between proposed solutions then what use are they? What was the point of that lengthy execise? _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 2 08:24:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12881 for ; Tue, 2 Apr 2002 07:26:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA07667 for midcom-archive@odin.ietf.org; Tue, 2 Apr 2002 07:26:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA07555; Tue, 2 Apr 2002 07:24:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29997 for ; Tue, 2 Apr 2002 04:43:17 -0500 (EST) Received: from mailer.wtmea.com ([62.140.66.211]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10775 for ; Tue, 2 Apr 2002 04:43:14 -0500 (EST) Received: (qmail 16286 invoked from network); 2 Apr 2002 09:52:15 -0000 Received: from dolphin.wtmea.com (HELO ieee.org) (1.0.0.8) by wthome.wtmea.com with SMTP; 2 Apr 2002 09:52:15 -0000 Message-ID: <3CA97D70.2A98ED58@ieee.org> Date: Tue, 02 Apr 2002 11:44:16 +0200 From: Khaled Elsayed X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: te-wg@ops.ietf.org, tccc@comsoc.org, itc@comsoc.org, idwg-public@zurich.ibm.com, ipsec@lists.tislabs.com, midcom@ietf.org, pilc@grc.nasa.gov Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] 2nd CFP IEEE Communications Magazine -- Internet Technology Series Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Apologies if you receive multiple copies. If you are interested in participating in the review process, please see the end of the message. HTML version of this CFP can be found at http://inetseries.tripod.com/cfp.html ---------------------------------------------------------- Call for Papers IEEE Communications Magazine Internet Technology Series Series Editors Michah Lerner (AT&T) and Khaled Elsayed (Cairo University) The Internet Technology series of the IEEE Communications Magazine is calling for original tutorial papers that discuss the following specific topics: - Traffic Engineering for Large Scale IP-based Networks - BGP Scalability Issues and Route optimization Methods in a Multihoming Environment - Performance Enhancement Services and Proxies: Scalable and Practical Methods for Data and Media Services - Verifiable and Affordable Security: Specification and Assurance of Security The IEEE Communications Magazine is read by tens of thousands of Communications Society members. The magazine has also been ranked as the number 1 telecommunications journal according to the ISI citation database for year 2000. The papers will be available on the Internet through Communications Magazine Interactive, the WWW edition of the magazine. Details about IEEE Communications Magazine can be found at http://www.comsoc.org/ci/. Sample publications published within the Internet Technology Series can be found in the January 2001 and July 2001 issues of the IEEE Communications Magazine. Tentative Schedule ================== Manuscripts due: May 1, 2002 Notification of acceptance: July 1, 2002 Final copy due: One month before final publication date Prospective Magazine issue: Oct. 2002 How to Submit Manuscripts ========================= Article Style Information ========================= Articles should be tutorial in nature and should be written in a style comprehensible to readers outside the specialty of the article. Articles may be edited for content, and will be copyedited for compliance with the magazine's style guidelines. Page proofs will be sent to the contact author for final review prior to publication. Mathematical equations should not be used unless they are vital to the presentation. Even then, they should be kept to a minimum. If the article has numerous equations, please contact the editor handling the manuscript. References should be included only to guide readers to more information on the topic; the reference list should not include every available source (a limit of ten references is recommended). Use footnotes only where necessary. Articles should not exceed 4500 words. Figures and tables should be limited to a combined total of six. If the article exceeds these recommended limits, please contact the editor handling the manuscript. Submission ========================= Electronic submission of manuscripts as either PDF (preferred) or Postscript is required. Please send your submission to both of the series editors: Khaled Elsayed: khaled@ieee.org Michah Lerner: michah@ieee.org ---------------------------------------------------------- For those interested in participating in the review process, please fill in the following form and send it to the editors. Name: Institution/Affiliation: Position (optional): E-mail address: Research Interests: _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 2 09:11:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15885 for ; Tue, 2 Apr 2002 09:11:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA13915 for midcom-archive@odin.ietf.org; Tue, 2 Apr 2002 09:11:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13828; Tue, 2 Apr 2002 09:09:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13741 for ; Tue, 2 Apr 2002 09:09:29 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15793 for ; Tue, 2 Apr 2002 09:09:28 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g32E8xa02178 for ; Tue, 2 Apr 2002 06:08:59 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADJ99546; Tue, 2 Apr 2002 06:06:35 -0800 (PST) Message-Id: <5.1.0.14.0.20020402091103.00a800e0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Apr 2002 09:13:00 -0500 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Fwd: Draft MIDCOM Minutes Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Here are the draft minutes from the recent IETF meeting. As always, let us know about errors, omissions, etc. Thanks, Melinda The MIDCOM (Middlebox Communications) Working Group met Thursday, March 21 at 1530-1730. Melinda Shore chaired the meeting. Notes were taken by Tom Taylor (taylor@nortelnetworks.com) Agenda Bashing ============== The agenda was accepted as proposed. Status ========= The MIDCOM Framework and Requirements documents have both been approved for publication. The new charter has been approved and posted. STUN is due April 2002. Our unnamed pre-MIDCOM deliverable is due in May. Process Going Forward ===================== Mary Barnes is to be the editor for the protocol evaluation document. The Working Group is doing the semantic work in parallel. -- process to be announced next week (last week of March) -- Tom Taylor is doing work on the semantic model. Jonathan Rosenberg commented that he was not sure if the work should go in parallel, given that the semantic description can be disposed of quickly. Melinda responded that the protocol evaluation will be messy and political, hence is best started as soon as possible. Mary Barnes presented charts describing the process going forward. Chart 1: Methodology Overview - Part 1 -------------------------------------- - Process open to entire WG. - Contributors need to specify their intention to contribute an objective evaluation of a specific protocol (by April 3rd). -- If there are multiple volunteers for the same protocol, priority is given to whomever puts in the first claim with a suggestion that the interested parties work together. -- Objective is to NOT have multiple individual contributions for the same protocol. - Specific protocol evaluation to be completed by April 19th. - Open WG feedback on the specific proposals on the mailing list, allowing authors to incorporate WG feedback into their contribution to improve its positioning and completeness (April 19th- May 3rd). - Final version of specific protocol evaluations due on May 10th. - Final versions of specific protocol evaluationss due May 10 -- template will be provided Some discussion of IPR followed the presentation. IPR claims must be revealed by April 3 to help people decide which protocols they want to work with. Chart 2: Methodology Overview - Part 2 -------------------------------------- - MIDCOM WG protocol evaluation document to be comprised from the information from the specific protocol drafts (May 10th-May 24th) -- Information is synthesized by the editor into a consistent format, with an objective comparison of the various proposals based upon the drafts (thus the responsibility is on the draft writers to ensure they completely evaluate their protocol against the requirements and framework and incorporate constructive input from mailing list). -- first version of protocol evaluation draft available on May 24th. - Open WG feedback on the draft (May 24th - June 7th) : -- Discussion of amalgamated pros/cons of the various proposals -- Any other issues with the draft. - Second version of draft available on June 14th: -- One Week mailing list discussion. -- Updated draft posted for WGLC: June 28th -- WGLC: June 28th-July 19th. -- Time allowed for a second iteration of WGLC Chart 3: Basis for evaluation ----------------------------- - Fundamental basis for evaluation is: -- MIDCOM Requirements: draft-ietf-midcom-requirements-05.txt -- MIDCOM Framework: draft-ietf-midcom-framework-07.txt - Format for individual protocol evaluations is not prescriptive but for an objective analysis should include the following sections/content: -- Applicability to the MIDCOM Framework. -- Identification of the MIDCOM Requirements that are satisfied -- Identification of the MIDCOM Requirements that are "partially" satisfied -- Identification of the MIDCOM Requirements that are NOT satisfied - Template for WG protocol evaluation draft will be made available early in the process to provide some guidance and to solicit WG feedback. Discussion of this chart revealed a concern to have detailed criteria beyond those shown. The WG will generate these more detailed requirements over next couple of weeks on the list. Mary's next few charts summarized the timeline for the process, based on the dates given in the preceding charts. Her final chart was as follows: Chart 8: Other Considerations - Conference calls can be scheduled to discuss issues that have not been resolved on the list or have deadlocked, but the goal is to work primarily via email. - Specific dates are subject to change, however, to meet the August deadline, we need to stick with these at a high level. Any changes to these proposed dates will be posted to the list. - IF progress isn't being achieved with the open nature of the proposed process, a design team MAY be formed to get the work back on track to meet the August delivery to IESG per the WG charter. Melinda called for feedback on the process and on the criteria. Pre-MIDCOM Design Team ====================== Melinda named the members: Jonathan Rosenberg, Ram Dantu , Mahadev Somasundaram , Sanjoy Sen , and Steve Davies (being replaced by Pete Cordell ). STUN Open Issues (Jonathan Rosenberg) ===================================== Changes in -00: - Answered UNSAF considerations - still awaiting response from IAB - Alignment of parameters on word boundaries -- not compatible with original draft - Added missing parameter code - Clarified meaning of changed-address - Added security Security issue: theft attack ---------------------------- - attacker snoops request - injects fake response - MAPPED-ADDRESS points to attacker - client thinks this is its own address, hands it out - media signalling applications go to attacker Bad because it gives the attacker access to a variety of applications. Rohan Mahy noted limitations to the attack. If the NAT is not full cone, the attacker has to fake its source IP address to be that of STUN server. Attacker has to be on the path or local to the client. Solution Requirements --------------------- Server authenticates itself to the client - same domain as the in which the client launched the request. Client can validate the integrity of the entire response. Server to client authentication typically based on PK - web model - want to work with servers you don't share a secret with. Christian Huitema warned that there are NATs that will remap what they perceive to be IP addresses in the content. Hence applications have to obfuscate vulnerable portions of the content. -- take off-line. Solution approach: ----------------- Cryptographic Message Syntax (CMS) RFC 2630 - heart of S/MIME - syntax for signatures, certificates, etc. Problem: don't want to sign responses for just any request -- would set up a potential distributed denial of service attack. Hence the proposed procedure has a two-stage handshake, with a cookie in the initial response. Issue: CMS implementation is probably 10-20 times bigger than STUN itself - other approaches? Christian Huitema suggested that we may not need security for every mapping. If the first response looks OK, it should be optional to require the full signature. Note to authors: add the is remark to the document. Cullen Jennings asked why the exchange could not use a shared secret. Jonathan responded: this would be a brake on deployment. A single STUN server may have many clients. Cullen asked why the SMTP model would not work. Melinda answered this: the trust model different -- it is necessary to narrow access to prevent spoofing. Kerberos may be applicable in a year. Cullen remarked that SIP phones don't do that. Jonathan explained further that he wanted to preserve the nature of the server as a stand-alone resource. The code readily available. Cullen indicated that code size is his precise concern. The mitigating circumstance is that TLS and MIME share technology. Ruling from the Chair: put it in the document, since the latter is a team output rather than a WG output. Jonathan continued his review of STUN status in general. Beyond what had already been described, there is little else to do. Lots of implementations are underway, and products will soon be available. draft-ietf-midcom-stun-00 will be revised and reissued after the blackout. Then it will be ready for Working Group Last Call. Comment: we could make the operation of the protocol more efficient by not having a timeout in the NAT so probes are not needed. Suggestion: put time value in the STUN packet from the server. Jonathan declared himself in favour. Melinda said it was in her draft last year. She will reissue that draft, ask for BOF in Yokohama (but this is a separate problem). Pre-MIDCOM Update (Steve Davies) ================= 'Thing' Now a chartered item Design team set up to propose a solution to the Working Group. - Draft submission date May 2. Allow inbound connections through midcom-unaware symmetric NATs using communications with server elements on the public side. Mechanism: enable a client to obtain an address at a public relay. PPP is in scope. Issues: - avoid implicit subversion of security policy e.g. running unauthorized servers - out-of-band vs. in-band control of relay - are symmetric paths required? Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 2 09:13:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15974 for ; Tue, 2 Apr 2002 09:13:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA14062 for midcom-archive@odin.ietf.org; Tue, 2 Apr 2002 09:13:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13990; Tue, 2 Apr 2002 09:12:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13961 for ; Tue, 2 Apr 2002 09:12:07 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15921 for ; Tue, 2 Apr 2002 09:12:05 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g32EBba03669 for ; Tue, 2 Apr 2002 06:11:37 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADJ99577; Tue, 2 Apr 2002 06:09:15 -0800 (PST) Message-Id: <5.1.0.14.0.20020402091337.00a838a0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Apr 2002 09:15:41 -0500 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Protocol evaluation contribution reminder Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Reminder: if you're planning on contributing an evaluation of an existing IETF protocol to the evaluation deliverable, please let Mary Barnes (mbarnes@nortelnetworks.com) know by *tomorrow*, 3 April. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 2 09:24:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16441 for ; Tue, 2 Apr 2002 09:24:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA14567 for midcom-archive@odin.ietf.org; Tue, 2 Apr 2002 09:24:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14508; Tue, 2 Apr 2002 09:22:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14479 for ; Tue, 2 Apr 2002 09:22:49 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16360 for ; Tue, 2 Apr 2002 09:22:48 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id AEB8FD8401B6; Tue, 02 Apr 2002 09:22:48 -0500 Message-ID: <002d01c1da51$983809a0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Tom-PT Taylor" , References: <4D79C746863DD51197690002A52CDA0001E8A1B8@zcard0kc.ca.nortel.com> Subject: Re: [midcom] MIDCOM Semantics Date: Tue, 2 Apr 2002 09:20:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit see embedded comments below ----- Original Message ----- From: "Tom-PT Taylor" > 3.2 Summary of Exchanges: > > 1) Policy Rule Request/Response > > Request from the Agent to install a specific Policy Rule, associating it > with a specific identifier and assigning it a specific lifetime. The > request also indicates whether partial installation is allowed. This > request has replacement semantics: if the identified rule was previously > installed, it is replaced completely by the content of the request assuming > that the Agent has the authority to make this request. This assumption is > made to simplify the semantic presentation: the WG may wish as an > optimization to define an additional message to incrementally modify a rule > already in place. Providing for incremental modification of the rule (i.e. specifying only the fields that have changed) would reduce the amount of bandwidth used by the protocol. > > An empty Policy Rule implies that the rule has been deactivated and the > associated identifier is available for reuse. As an alternative, the semantics could be explict create, modify, and delete commands within the request. > > The Policy Rule Response indicates the Policy Rule actually installed and > the lifetime assigned to it by the Middlebox. I assume this would have the full content of the rule. > 3) Deactivation Request/Acknowledgement > Open issue: does the Middlebox deactivate all Policy Rules the Agent has > ever installed, or only those for which it is the most recent installer? > 4) Policy Rule Audit Request/Response > Open issue: when "ALL" is requested, does the Middlebox return all Policy > Rules the Agent has ever installed, or only those for which it is the most > recent installer? A sort of related issue: Does the middlebox remember all the agents that have operated on this rule? Can one agent indicate that additional agents are allowed to modify/audit the rule and/or receive notification? > > 1 (a): Policy Rule Request (Agent to Middlebox) > -------------------------- > > Specific Parameters: Policy Rule Identifier, Policy Rule, Lifetime, > Integrity > > Policy Rule Identifier: > An identifier which can be used to correlate further requests involving this > rule. At a minimum, the tuple {Agent Identifier, Middlebox Identifier, > Policy Rule Identifier) must be unique. It is probably necessary that the > Policy Rule Identifier be globally unique so that one Agent can (if given > the authority) manipulate rules belonging to other Agents. Alternatively, the Middlebox Identifier could be globally unique, and the Policy Rule Identifier unique within a given middlebox. Question: Is the Policy Rule identifier determined by the agent or the middlebox? > > Policy Rule: > The specific Policy Rule which the Agent is asking to take effect, specified > as a set of {Filter, Action} pairs. This replaces any Policy rule > previously associated with the same Policy rule Identifier. An empty Policy > Rule implies that the rule has been deactivated and the associated > identifier is available for reuse. Again, would explicit create, modify, and delete commands be better? If creation is implicit, the agent has no way to tell that the rule previously existed. However, if the policy rule identifier was assigned by the middlebox, creation would be indicated by some sort of "pick one" wildcard. Based on the requirements, the filter may contain: source address source transport port destination address destination transport port transport protocol For firewall pinholes, the action has at least "allow/deny" For NAT, the action may have new source address new source transport port new destination address new destination transport port > 2(a) Middlebox Action Notification (Middlebox to Agent) > ---------------------------------- > > Specific parameters: Reason, Policy Rule Identifier (optional), Policy Rul e > (optional) > > Reason: > Indicates why the notification was issued. Possible values are: > - Policy Rule modified due to conflict (Policy Rule Identifier and Policy > Rule must be present) > - Policy Rule deactivated due to conflict (Policy Rule Identifier must be > present) > - Policy Rule deactivated due to lifetime expiry (Policy Rule Identifier > must be present) > - ??? In cases where multiple agents are responsible for a rule, would we need/want to notify the other agents when a rule is changed? If so, we whould have a "Policy Rule modified by another agent" reason. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 2 09:28:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16638 for ; Tue, 2 Apr 2002 09:28:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA14866 for midcom-archive@odin.ietf.org; Tue, 2 Apr 2002 09:28:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14722; Tue, 2 Apr 2002 09:27:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14691 for ; Tue, 2 Apr 2002 09:27:15 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16574 for ; Tue, 2 Apr 2002 09:27:14 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id AFC1BAE9004A; Tue, 02 Apr 2002 09:27:13 -0500 Message-ID: <005901c1da52$35b7dca0$2300000a@acmepacket.com> From: "Bob Penfield" To: , "Melinda Shore" References: <5.1.0.14.0.20020402091337.00a838a0@localhost> Subject: Re: [midcom] Protocol evaluation contribution reminder Date: Tue, 2 Apr 2002 09:25:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Is there a list of which protocols folks have signed up for so far? I am only aware of Megaco and RSIP from the list. Are there any suggestions for protocols that we ought to look at, but nobody has signed up for yet? cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Melinda Shore" To: Sent: Tuesday, April 02, 2002 9:15 AM Subject: [midcom] Protocol evaluation contribution reminder > Reminder: if you're planning on contributing an evaluation > of an existing IETF protocol to the evaluation deliverable, > please let Mary Barnes (mbarnes@nortelnetworks.com) know by > *tomorrow*, 3 April. > > Thanks, > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 2 09:41:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17225 for ; Tue, 2 Apr 2002 09:41:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA15879 for midcom-archive@odin.ietf.org; Tue, 2 Apr 2002 09:41:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15806; Tue, 2 Apr 2002 09:39:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15779 for ; Tue, 2 Apr 2002 09:39:51 -0500 (EST) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17184 for ; Tue, 2 Apr 2002 09:39:49 -0500 (EST) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g32Edhd03706; Tue, 2 Apr 2002 08:39:43 -0600 (CST) From: "Ben Campbell" To: "Bob Penfield" , "Tom-PT Taylor" , Subject: RE: [midcom] MIDCOM Semantics Date: Tue, 2 Apr 2002 08:39:30 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <002d01c1da51$983809a0$2300000a@acmepacket.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit see below > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Bob Penfield [snip] > > Policy Rule Identifier: > > An identifier which can be used to correlate further requests involving > this > > rule. At a minimum, the tuple {Agent Identifier, Middlebox Identifier, > > Policy Rule Identifier) must be unique. It is probably > necessary that the > > Policy Rule Identifier be globally unique so that one Agent can > (if given > > the authority) manipulate rules belonging to other Agents. > > Alternatively, the Middlebox Identifier could be globally unique, and the > Policy Rule Identifier unique within a given middlebox. > > Question: Is the Policy Rule identifier determined by the agent or the > middlebox? Hopefully by the agent. This would allow the agent to determine the identifier through some repeatable algorithm, which would be very useful for reducing agent state, allowing other agent to refer to the same rule without sharing information, etc. [snip] > > Reason: > > Indicates why the notification was issued. Possible values are: > > - Policy Rule modified due to conflict (Policy Rule Identifier > and Policy > > Rule must be present) > > - Policy Rule deactivated due to conflict (Policy Rule > Identifier must be > > present) > > - Policy Rule deactivated due to lifetime expiry (Policy Rule > Identifier > > must be present) > > - ??? > > In cases where multiple agents are responsible for a rule, would we > need/want to notify the other agents when a rule is changed? If so, we > whould have a "Policy Rule modified by another agent" reason. It depends on whether the additional agents know in advance that they are responsible for the rule. > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 2 09:45:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17374 for ; Tue, 2 Apr 2002 09:45:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA16185 for midcom-archive@odin.ietf.org; Tue, 2 Apr 2002 09:45:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16065; Tue, 2 Apr 2002 09:43:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16034 for ; Tue, 2 Apr 2002 09:43:36 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17297 for ; Tue, 2 Apr 2002 09:43:35 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g32Eh2V08878; Tue, 2 Apr 2002 08:43:02 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 08:43:07 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A03DE391A@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Bob Penfield'" , midcom@ietf.org, Melinda Shore Subject: RE: [midcom] Protocol evaluation contribution reminder Date: Tue, 2 Apr 2002 08:43:05 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DA54.B2ABDC00" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DA54.B2ABDC00 Content-Type: text/plain; charset="iso-8859-1" Hi all, The following are the protocols for which people have signed up, with the "prime" listed (several have indicated that there will be multiple authors): MEGACO - Sanjoy Sen [sanjoy@nortelnetworks.com] COPS - Louis-Nicolas Hamer [nhamer@nortelnetworks.com] RSIP - James Renkel [James_Renkel@3com.com] SNMP/SMI - Juergen Quittek [quittek@ccrle.nec.de] Regards, Mary. Editor, Protocol evaluation document -----Original Message----- From: Bob Penfield [mailto:bpenfield@acmepacket.com] Sent: Tuesday, April 02, 2002 8:25 AM To: midcom@ietf.org; Melinda Shore Subject: Re: [midcom] Protocol evaluation contribution reminder Is there a list of which protocols folks have signed up for so far? I am only aware of Megaco and RSIP from the list. Are there any suggestions for protocols that we ought to look at, but nobody has signed up for yet? cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Melinda Shore" To: Sent: Tuesday, April 02, 2002 9:15 AM Subject: [midcom] Protocol evaluation contribution reminder > Reminder: if you're planning on contributing an evaluation > of an existing IETF protocol to the evaluation deliverable, > please let Mary Barnes (mbarnes@nortelnetworks.com) know by > *tomorrow*, 3 April. > > Thanks, > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C1DA54.B2ABDC00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Protocol evaluation contribution reminder

Hi all,

The following are the protocols for which people have = signed up, with the "prime" listed (several have indicated = that there will be multiple authors):

MEGACO - Sanjoy Sen = [sanjoy@nortelnetworks.com]
COPS - Louis-Nicolas Hamer = [nhamer@nortelnetworks.com]
RSIP - James Renkel [James_Renkel@3com.com]
SNMP/SMI - Juergen Quittek = [quittek@ccrle.nec.de]

Regards,
Mary.
Editor, Protocol evaluation document

-----Original Message-----
From: Bob Penfield [mailto:bpenfield@acmepacket.com= ]
Sent: Tuesday, April 02, 2002 8:25 AM
To: midcom@ietf.org; Melinda Shore
Subject: Re: [midcom] Protocol evaluation = contribution reminder


Is there a list of which protocols folks have signed = up for so far? I am
only aware of Megaco and RSIP from the list.

Are there any suggestions for protocols that we ought = to look at, but nobody
has signed up for yet?

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
bpenfield@acmepacket.com

----- Original Message -----
From: "Melinda Shore" = <mshore@cisco.com>
To: <midcom@ietf.org>
Sent: Tuesday, April 02, 2002 9:15 AM
Subject: [midcom] Protocol evaluation contribution = reminder


> Reminder: if you're planning on contributing an = evaluation
> of an existing IETF protocol to the evaluation = deliverable,
> please let Mary Barnes = (mbarnes@nortelnetworks.com) know by
> *tomorrow*, 3 April.
>
> Thanks,
>
> Melinda
>
>
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
>


_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C1DA54.B2ABDC00-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 2 10:07:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18269 for ; Tue, 2 Apr 2002 10:07:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA17686 for midcom-archive@odin.ietf.org; Tue, 2 Apr 2002 10:07:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17595; Tue, 2 Apr 2002 10:04:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17567 for ; Tue, 2 Apr 2002 10:04:45 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18210 for ; Tue, 2 Apr 2002 10:04:43 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g32F48U26923 for ; Tue, 2 Apr 2002 10:04:08 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g32F47Z29797 for ; Tue, 2 Apr 2002 10:04:07 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 10:04:08 -0500 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A227@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Bob Penfield'" , midcom@ietf.org Subject: RE: [midcom] MIDCOM Semantics Date: Tue, 2 Apr 2002 10:04:06 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org My responses follow your comments, marked with [PTT]. -----Original Message----- From: Bob Penfield [mailto:bpenfield@acmepacket.com] Sent: Tuesday, April 02, 2002 9:21 AM To: Taylor, Tom-PT [CAR:B800:EXCH]; midcom@ietf.org Subject: Re: [midcom] MIDCOM Semantics see embedded comments below ----- Original Message ----- From: "Tom-PT Taylor" > 3.2 Summary of Exchanges: > > 1) Policy Rule Request/Response > > Request from the Agent to install a specific Policy Rule, associating it > with a specific identifier and assigning it a specific lifetime. The > request also indicates whether partial installation is allowed. This > request has replacement semantics: if the identified rule was previously > installed, it is replaced completely by the content of the request assuming > that the Agent has the authority to make this request. This assumption is > made to simplify the semantic presentation: the WG may wish as an > optimization to define an additional message to incrementally modify a rule > already in place. Providing for incremental modification of the rule (i.e. specifying only the fields that have changed) would reduce the amount of bandwidth used by the protocol. [PTT] Agreed. My intent was to state the semantics at the most abstract level, with the idea that a practical realization would break them up, but in different ways for different protocols. > > An empty Policy Rule implies that the rule has been deactivated and the > associated identifier is available for reuse. As an alternative, the semantics could be explict create, modify, and delete commands within the request. [PTT] Agreed. > > The Policy Rule Response indicates the Policy Rule actually installed and > the lifetime assigned to it by the Middlebox. I assume this would have the full content of the rule. [PTT] Yes. > 3) Deactivation Request/Acknowledgement > Open issue: does the Middlebox deactivate all Policy Rules the Agent has > ever installed, or only those for which it is the most recent installer? > 4) Policy Rule Audit Request/Response > Open issue: when "ALL" is requested, does the Middlebox return all Policy > Rules the Agent has ever installed, or only those for which it is the most > recent installer? A sort of related issue: Does the middlebox remember all the agents that have operated on this rule? Can one agent indicate that additional agents are allowed to modify/audit the rule and/or receive notification? [PTT] I had assumed that communication of Policy Rule Identifiers between agents was achieved by means out of scope of the Midcom protocol, and that the authority to modify and audit rules was assigned by the policy mechanism (based on the specific source and destination addresses involved) rather than agent communication with the Middlebox. If people are of the view that the Midcom protocol should support delegation of authority, I'll add the necessary exchanges. > > 1 (a): Policy Rule Request (Agent to Middlebox) > -------------------------- > > Specific Parameters: Policy Rule Identifier, Policy Rule, Lifetime, > Integrity > > Policy Rule Identifier: > An identifier which can be used to correlate further requests involving this > rule. At a minimum, the tuple {Agent Identifier, Middlebox Identifier, > Policy Rule Identifier) must be unique. It is probably necessary that the > Policy Rule Identifier be globally unique so that one Agent can (if given > the authority) manipulate rules belonging to other Agents. Alternatively, the Middlebox Identifier could be globally unique, and the Policy Rule Identifier unique within a given middlebox. [PTT] I think you're right on the scope of the Policy Rule Identifier. Question: Is the Policy Rule identifier determined by the agent or the middlebox? [PTT] It is determined by the agent. See the detailed parameter descriptions in the latter part of my original note. > > Policy Rule: > The specific Policy Rule which the Agent is asking to take effect, specified > as a set of {Filter, Action} pairs. This replaces any Policy rule > previously associated with the same Policy rule Identifier. An empty Policy > Rule implies that the rule has been deactivated and the associated > identifier is available for reuse. Again, would explicit create, modify, and delete commands be better? If creation is implicit, the agent has no way to tell that the rule previously existed. However, if the policy rule identifier was assigned by the middlebox, creation would be indicated by some sort of "pick one" wildcard. [PTT] I can see the potential problems introduced by inadvertent reuse of a Policy Rule Identifier already activated by another agent. Actual rule collision is sorted out by policy, but reuse of an identifier for a totally unrelated rule would be undesirable. Your suggestion that the Middlebox assign the identifier is probably the easier way to solve the problem. The other way is to require the Policy Rule Identifier to include the AgentId as one of its components. (I'm assuming an Agent can keep track of the Policy Rules it has created.) Based on the requirements, the filter may contain: source address source transport port destination address destination transport port transport protocol For firewall pinholes, the action has at least "allow/deny" For NAT, the action may have new source address new source transport port new destination address new destination transport port [PTT] I'm going to publish our proposed abstract representation of a Policy Rule in another note. Cedric and I are still working through the various scenarios to validate it. > 2(a) Middlebox Action Notification (Middlebox to Agent) > ---------------------------------- > > Specific parameters: Reason, Policy Rule Identifier (optional), Policy Rul e > (optional) > > Reason: > Indicates why the notification was issued. Possible values are: > - Policy Rule modified due to conflict (Policy Rule Identifier and Policy > Rule must be present) > - Policy Rule deactivated due to conflict (Policy Rule Identifier must be > present) > - Policy Rule deactivated due to lifetime expiry (Policy Rule Identifier > must be present) > - ??? In cases where multiple agents are responsible for a rule, would we need/want to notify the other agents when a rule is changed? If so, we whould have a "Policy Rule modified by another agent" reason. [PTT] "Policy Rule modified by another agent" is implicit in the first two reasons when generating a Middlebox Action Notification. Guess I should have made that clearer in the wording of the reasons. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 2 10:28:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19018 for ; Tue, 2 Apr 2002 10:28:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA18433 for midcom-archive@odin.ietf.org; Tue, 2 Apr 2002 10:28:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18308; Tue, 2 Apr 2002 10:26:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18283 for ; Tue, 2 Apr 2002 10:26:03 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18934 for ; Tue, 2 Apr 2002 10:26:01 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g32FPVU00184 for ; Tue, 2 Apr 2002 10:25:31 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g32FPUZ01685 for ; Tue, 2 Apr 2002 10:25:30 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 10:25:30 -0500 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A229@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: midcom@ietf.org Cc: "Cedric Aoun" Date: Tue, 2 Apr 2002 10:25:24 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] MIDCOM SEmantics: Policy Rule Content Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This is the theoretical section of the I-D Cedric and I are working on. We are still validating it against the various scenarios. 4 Structure And Comparison Of Policy Rules In this note, a Policy Rule is defined to be a set of terms of the form {Filter, Action}, the union of which defines the desired policy. Any such set can be refined into a canonical form in which the Filter part of each {Filter,Action} term represents a rectangular prism (i.e. a box) in N-space, where N is the number of components of the filter. If two such filters are compared for overlap, the zone of overlap, if any, will be another box. See the diagram below, where the area of overlap is marked with X's. +-------------------------+ | Filter 1 | | | | | | +-------------------------+ | |XXXXXXXXXXXX Filter 2 | | |XXXXXXXXXXXX | | |XXXXXXXXXXXX | | +-------------------------+ | | +-------------------------+ Suppose now that these two filters are associated with actions which contradict each other. Then the decision rules used by the Middlebox will decide which action will apply in the region of overlap. By assumption, these decision rules will be based on the combination of order of specification and policy at the Middlebox. There are two possible cases: (1) The Policy Rule associated with each of the two {Filter, Action} pairs must be installed completely or not at all. In this case, if there is a conflict between the two rules in the zone of overlap, the lower-priority Policy Rule will be disallowed (if it was the later arrival) or deactivated (if it was already installed). (2) The Policy Rule which has lower priority in the zone of conflict allows for partial implementation. Thus the desired {Filter, Action} pair is modified to exclude the zone of overlap. There are two sub-cases: (a) In the simpler case, the exclusion of the zone of overlap still leaves a box in N-space. This is true of Filter 2 in the diagram. In this case, the original {Filter, Action} pair is replaced by another {Filter', Action} pair where Filter' defines the region outside the zone of overlap. (b) In the more complex case, the exclusion of the zone of overlap leaves a complex region rather than a simple box. This is true of Filter 1 in the above diagram. In this case, the region can be partitioned into a set of up to 2N simple boxes in N-space. Thus the canonical outcome of the conflict with respect to the original {Filter, Action} pair is a set of {Filter, Action} pairs where Action is the same as in the original pair. Policy rules are evaluated for conflict through a pairwise comparison of their individual {Filter, Action} components. Let us turn now to the detailed semantic content of the {Filter, Action} pairs. As the examples of section 4 illustrate, it is possible to represent NAT and firewall policies using sets of uni-directional filters of the form {, , , Protocol} with suitable wildcarding. Each Address-Port term has the detailed form {Address, Port, Realm}. Two wildcards are needed: - ANY is a placeholder for a value to be bound when a flow instance is matched against the Policy Rule. - CHOOSE is a value to be assigned by the Middlebox at Policy Rule installation time. That is, each CHOOSE in a Policy Rule Request must be replaced by a specific value in a Policy Rule Response. CHOOSE must only be used for components of . Our requirements indicate the need for two additional items. It must be possible on occasion for the filter to specify a range of ports rather than a single port. Moreover, it must be possible to constrain the parity of the Map port assignment(s). These requirements are satisfied by adding three modifiers to the port components of the filter: - the Count modifier is an integer from 1 upwards. If it is included in a port component, it indicates that a range of ports is requested. If the filter provides a specific value rather than a wildcard for the port in question, the port assignments begin with that value. If Count is absent, only one port is indicated. - the Step modifier must not be present unless the Count modifier is also present. It is an integer from 1 upwards indicating the increment to be applied in determining port numbers for a port number range. One example of when Step would be needed is when allocating RTP or RTCP ports for layered encoding. In this example, Step would have value 2. The default if Step is absent is an increment of 1. - the Parity modifier has values Odd or Even. If it is included in a port component, it indicates that the port (or the first port of a range) must have the given parity. If Parity is not specified, port assignment is unconstrained. Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 2 11:53:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22684 for ; Tue, 2 Apr 2002 11:53:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA24345 for midcom-archive@odin.ietf.org; Tue, 2 Apr 2002 11:53:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24243; Tue, 2 Apr 2002 11:50:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24160 for ; Tue, 2 Apr 2002 11:50:43 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22572 for ; Tue, 2 Apr 2002 11:50:40 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g32Go7Z23076 for ; Tue, 2 Apr 2002 11:50:07 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 11:50:08 -0500 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A22D@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: midcom@ietf.org Cc: "Cedric Aoun" Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Tue, 2 Apr 2002 11:50:08 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org My previous posting was probably too abstract without an example of how it works, so here is an extract showing application to the first scenario. 5.1 Simple server behind NAT/Firewall Since the intent is to cover semantics (i.e. what should be included in the MIDCOM messages), informal Midcom messages are shown. The syntax in describing the required information in the messages will be dependent on the selected protocol. Middlebox Beta Midcom Agent Alpha <-------------------- PolicyRuleRequest (Version, TransactionId=x, AgentId=Alpha, Credentials, RuleID=r, Policy Rule=[see below], Lifetime=eternal, Integrity=all-or-nothing) --------------------> PolicyRuleResponse [success case] (Version, TransactionId=x, MiddleboxId=Beta, Credentials, RuleID=r, Policy Rule=[see below], Lifetime=eternal, Reason=accepted) --------------------> PolicyRuleResponse [failure case] (Version, TransactionId=x, MiddleboxId=Beta, Credentials, RuleID=r, Policy Rule={}, Lifetime=0, Reason=no authority) The Policy Rule in the Request consists of a single {Filter, Action} pair as follows: Filter = Source addr = ANY Source port= ANY Source realm=Outside Map addr = CHOOSE Map port= CHOOSE Map realm= Outside Dest addr= InternalHostaddr ; address of the internal host Dest port=80 Dest realm= Inside Protocol=TCP Action= Allow This {Filter, Action} pair is used to ask the Middlebox for a mapped address/port pair to allow an incoming TCP connection to be established. The success case Response shown above indicates that the Middlebox has granted the request. The Policy Rule returned in this example is: Filter = Source addr = ANY Source port= ANY Source realm=Outside Map addr = 193.252.187.186 Map port= 25000 Map realm= Outside Dest addr= InternalHostaddr Dest port=80 Dest realm= Inside Protocol=TCP Action= Allow Scenario 1 does not mention enabling of outward flows. That may be because default policies already allow such flows. On the other hand, the required flow could be installed either as an increment to the Policy Rule just installed or when the SYN is received. In the example shown here, the Midcom Agent requests another filter to be added within the existing policy rule installed on the Middlebox, to allow packets to flow from the server to the external network. Middlebox Beta Midcom Agent Alpha <-------------------- PolicyRuleRequest (Version, TransactionId=y, AgentId=Alpha, Credentials, RuleID=r, Policy Rule=[see below], Lifetime=eternal, Integrity=all-or-nothing) --------------------> PolicyRuleResponse (Version, TransactionId=y, MiddleboxId=Beta, Credentials, RuleID=r, Policy Rule=[see below], Lifetime=eternal, Reason=accepted) For the Request and Response both, the Policy Rule now consists of two {Filter, Action} pairs. The first pair is the one returned in the first Response. The second is for the outgoing flow: Filter = Source addr = InternalHostaddr Source port= 80 Source realm=Inside Map addr = 193.252.187.186 Map port= 25000 Map realm= Outside Dest addr= ANY Dest port= ANY Dest realm= Outside Protocol=TCP Action= Allow The server can now start receiving start receiving incoming connections, and replying back to the external client. The same message sequence is applicable to other transport protocols (UDP, SCTP, ...), and to third-party control of the Middlebox. 5.2 Peer-to-peer communication with ad-hoc rendezvous The message sequence for the Internal Server in this case looks the same as in the previous case, except that the "Outside" address and port may be specific values rather than ANY. In the case where the "external" host is behind a firewall and wants to predict its mapped source address, the outgoing {Filter, Action} pair it sends in its Policy Rule Request looks like this: Filter = Source addr = External Host's addr Source port= External Host's port Source realm=External Host's realm Map addr = CHOOSE Map port = CHOOSE Map realm= Outside Dest addr= ANY Dest port= ANY Dest realm= Outside Protocol=TCP Action= Allow The response provides a specific Map Address-Port which the external host can send to the internal host by way of the IM server. To close the holes opened by Policy Rule y when the session is done, the internal host deactivates it by modifying it to be empty: Middlebox Beta Midcom Agent Alpha <-------------------- PolicyRuleRequest (Version, TransactionId=z, AgentId=Alpha, Credentials, RuleID=r, Policy Rule={}, Lifetime=0, Integrity=all-or-nothing) --------------------> PolicyRuleResponse (Version, TransactionId=z, MiddleboxId=Beta, Credentials, RuleID=r, Policy Rule={}, Lifetime=0, Reason=accepted) Policy Rule Identifier r is now available for reuse. -----Original Message----- From: Taylor, Tom-PT [CAR:B800:EXCH] Sent: Tuesday, April 02, 2002 10:25 AM To: midcom@ietf.org Cc: Aoun, Cedric [QPD:MA01:EXCH] Subject: [midcom] MIDCOM SEmantics: Policy Rule Content This is the theoretical section of the I-D Cedric and I are working on. We are still validating it against the various scenarios. 4 Structure And Comparison Of Policy Rules In this note, a Policy Rule is defined to be a set of terms of the form {Filter, Action}, the union of which defines the desired policy. Any such set can be refined into a canonical form in which the Filter part of each {Filter,Action} term represents a rectangular prism (i.e. a box) in N-space, where N is the number of components of the filter. If two such filters are compared for overlap, the zone of overlap, if any, will be another box. See the diagram below, where the area of overlap is marked with X's. +-------------------------+ | Filter 1 | | | | | | +-------------------------+ | |XXXXXXXXXXXX Filter 2 | | |XXXXXXXXXXXX | | |XXXXXXXXXXXX | | +-------------------------+ | | +-------------------------+ Suppose now that these two filters are associated with actions which contradict each other. Then the decision rules used by the Middlebox will decide which action will apply in the region of overlap. By assumption, these decision rules will be based on the combination of order of specification and policy at the Middlebox. There are two possible cases: (1) The Policy Rule associated with each of the two {Filter, Action} pairs must be installed completely or not at all. In this case, if there is a conflict between the two rules in the zone of overlap, the lower-priority Policy Rule will be disallowed (if it was the later arrival) or deactivated (if it was already installed). (2) The Policy Rule which has lower priority in the zone of conflict allows for partial implementation. Thus the desired {Filter, Action} pair is modified to exclude the zone of overlap. There are two sub-cases: (a) In the simpler case, the exclusion of the zone of overlap still leaves a box in N-space. This is true of Filter 2 in the diagram. In this case, the original {Filter, Action} pair is replaced by another {Filter', Action} pair where Filter' defines the region outside the zone of overlap. (b) In the more complex case, the exclusion of the zone of overlap leaves a complex region rather than a simple box. This is true of Filter 1 in the above diagram. In this case, the region can be partitioned into a set of up to 2N simple boxes in N-space. Thus the canonical outcome of the conflict with respect to the original {Filter, Action} pair is a set of {Filter, Action} pairs where Action is the same as in the original pair. Policy rules are evaluated for conflict through a pairwise comparison of their individual {Filter, Action} components. Let us turn now to the detailed semantic content of the {Filter, Action} pairs. As the examples of section 4 illustrate, it is possible to represent NAT and firewall policies using sets of uni-directional filters of the form {, , , Protocol} with suitable wildcarding. Each Address-Port term has the detailed form {Address, Port, Realm}. Two wildcards are needed: - ANY is a placeholder for a value to be bound when a flow instance is matched against the Policy Rule. - CHOOSE is a value to be assigned by the Middlebox at Policy Rule installation time. That is, each CHOOSE in a Policy Rule Request must be replaced by a specific value in a Policy Rule Response. CHOOSE must only be used for components of . Our requirements indicate the need for two additional items. It must be possible on occasion for the filter to specify a range of ports rather than a single port. Moreover, it must be possible to constrain the parity of the Map port assignment(s). These requirements are satisfied by adding three modifiers to the port components of the filter: - the Count modifier is an integer from 1 upwards. If it is included in a port component, it indicates that a range of ports is requested. If the filter provides a specific value rather than a wildcard for the port in question, the port assignments begin with that value. If Count is absent, only one port is indicated. - the Step modifier must not be present unless the Count modifier is also present. It is an integer from 1 upwards indicating the increment to be applied in determining port numbers for a port number range. One example of when Step would be needed is when allocating RTP or RTCP ports for layered encoding. In this example, Step would have value 2. The default if Step is absent is an increment of 1. - the Parity modifier has values Odd or Even. If it is included in a port component, it indicates that the port (or the first port of a range) must have the given parity. If Parity is not specified, port assignment is unconstrained. Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 2 12:24:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24460 for ; Tue, 2 Apr 2002 12:24:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA29043 for midcom-archive@odin.ietf.org; Tue, 2 Apr 2002 12:24:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28860; Tue, 2 Apr 2002 12:22:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28829 for ; Tue, 2 Apr 2002 12:22:55 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24400 for ; Tue, 2 Apr 2002 12:22:51 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g32HMBl09880; Tue, 2 Apr 2002 09:22:11 -0800 (PST) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ACM16210; Tue, 2 Apr 2002 09:22:33 -0800 (PST) From: "Cullen Jennings" To: "Bob Penfield" , , "Melinda Shore" Subject: RE: [midcom] Protocol evaluation contribution reminder Date: Tue, 2 Apr 2002 09:25:04 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: <005901c1da52$35b7dca0$2300000a@acmepacket.com> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit I'm sort of surprised not to see RSVP HTTP ( perhaps a SOAP or UPNP style thing ) WEBDAV to modify an XML document that describes the current filter specs? If you consider the midbox to be a IP to IP gateway, this could be a Session Initiation Problem telnet of IOS style ACLs Many of these protocol evaluations are going to amount to - yes, the protocol could function as a transport for the data and perhaps deal with the security and authentication issues and No, the protocol has no idea of the semantics of what we want to do on a midbox but we can invent that on top of the current protocol. Cullen _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 2 12:59:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26179 for ; Tue, 2 Apr 2002 12:59:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA02367 for midcom-archive@odin.ietf.org; Tue, 2 Apr 2002 12:59:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02223; Tue, 2 Apr 2002 12:57:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02192 for ; Tue, 2 Apr 2002 12:57:06 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26102 for ; Tue, 2 Apr 2002 12:57:05 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g32HuZb25339; Tue, 2 Apr 2002 09:56:35 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADK05068; Tue, 2 Apr 2002 09:54:05 -0800 (PST) Message-Id: <5.1.0.14.0.20020402125340.00a8dc50@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Apr 2002 13:00:34 -0500 To: "Cullen Jennings" , From: Melinda Shore Subject: RE: [midcom] Protocol evaluation contribution reminder In-Reply-To: References: <005901c1da52$35b7dca0$2300000a@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 09:25 AM 4/2/02 -0800, Cullen Jennings wrote: >RSVP >HTTP ( perhaps a SOAP or UPNP style thing ) >WEBDAV to modify an XML document that describes the current filter specs? >If you consider the midbox to be a IP to IP gateway, this could be a Session >Initiation Problem >telnet of IOS style ACLs RSVP is actually one of the few IETF protocols that really diverges from the midcom framework and requirements, and I think we disposed of the notion of using its model, in the context of the midcom working group, last December. Other candidates could include Diameter and even GSMP. I'd like to see us be thorough, but at the same time I don't think we need to go overboard. That is to say, it's probably best if people limit themselves to evaluation of protocols that they really believe are good fits to the framework and requirements. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 2 13:53:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27965 for ; Tue, 2 Apr 2002 13:53:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA05470 for midcom-archive@odin.ietf.org; Tue, 2 Apr 2002 13:53:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05248; Tue, 2 Apr 2002 13:49:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05218 for ; Tue, 2 Apr 2002 13:49:48 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27767 for ; Tue, 2 Apr 2002 13:49:46 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g32IW5l09238; Tue, 2 Apr 2002 10:32:05 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADK06662; Tue, 2 Apr 2002 10:29:54 -0800 (PST) Message-Id: <5.1.0.14.0.20020402092839.00a7ca00@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Apr 2002 13:36:22 -0500 To: Tom_Gray@Mitel.COM, "'midcom@ietf.org'" From: Melinda Shore Subject: Re: [midcom] Protocol Evaluation document template In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 07:51 AM 4/2/02 -0500, Tom_Gray@Mitel.COM wrote: >How relevant is a requirements document and exercise, if they do not >determine what the protocol is supposed to do? If requirements cannot be >used to discriminate between proposed solutions then what use are they? >What was the point of that lengthy execise? The point of that document was to produce what we produced and use it as the basis for a protocol evaluation and eventual midcom protocol. The requirements document survived IESG scrutiny and is currently in the RFC Editor's queue. Our next midcom (as opposed to pre-midcom) deliverable is the protocol evaluation document. As I said earlier, in terms of choosing useful tools for the basis for the protocol evaluation, I believe that the requirements document will have more discriminatory power than will detailed protocol semantics. I have no expectation that the requirements document will be revised during this process. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Wed Apr 3 05:42:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28811 for ; Wed, 3 Apr 2002 05:42:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA11077 for midcom-archive@odin.ietf.org; Wed, 3 Apr 2002 05:42:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10894; Wed, 3 Apr 2002 05:38:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10866 for ; Wed, 3 Apr 2002 05:38:13 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28640 for ; Wed, 3 Apr 2002 05:38:09 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g33AbXo58765; Wed, 3 Apr 2002 12:37:33 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA21297; Wed, 3 Apr 2002 12:37:21 +0200 Date: Wed, 03 Apr 2002 12:40:32 +0200 From: Juergen Quittek To: Cullen Jennings , Bob Penfield , midcom@ietf.org, Melinda Shore Subject: RE: [midcom] Protocol evaluation contribution reminder Message-ID: <10016402.1017837632@[192.168.102.164]> In-Reply-To: References: X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Cullen, I am much more surprised not to find Diameter in the list of evaluated protocols. Although being heavy-weight it certainly has the potential to serve as a midcom protocol. Isn't there anyone who wants to volunteer for evaluating Diameter? Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de --On 02 April 2002 09:25 -0800 Cullen Jennings wrote: > > I'm sort of surprised not to see > > RSVP > HTTP ( perhaps a SOAP or UPNP style thing ) > WEBDAV to modify an XML document that describes the current filter specs? > If you consider the midbox to be a IP to IP gateway, this could be a Session > Initiation Problem > telnet of IOS style ACLs > > Many of these protocol evaluations are going to amount to - yes, the > protocol could function as a transport for the data and perhaps deal with > the security and authentication issues and No, the protocol has no idea of > the semantics of what we want to do on a midbox but we can invent that on > top of the current protocol. > > Cullen > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Wed Apr 3 06:27:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29619 for ; Wed, 3 Apr 2002 06:27:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA14392 for midcom-archive@odin.ietf.org; Wed, 3 Apr 2002 06:27:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14163; Wed, 3 Apr 2002 06:21:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14134 for ; Wed, 3 Apr 2002 06:21:10 -0500 (EST) Received: from protactinium (protactinium.btinternet.com [194.73.73.176]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29509 for ; Wed, 3 Apr 2002 06:21:02 -0500 (EST) Received: from host213-122-38-80.in-addr.btopenworld.com ([213.122.38.80] helo=tkw) by protactinium with smtp (Exim 3.22 #8) id 16siot-0003KA-00; Wed, 03 Apr 2002 12:20:55 +0100 Message-ID: <001a01c1db01$bb407b20$0200000a@tkw> From: "Pete Cordell" To: "Jonathan Rosenberg" Cc: Date: Wed, 3 Apr 2002 11:42:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Subject: [midcom] Truncated STUN test Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Jonathan, My understanding is that only NATs that exhibit cone NAT functionality (which presumably includes 1-to-1 NAT) are useful for things like SIP. For clients that are only interested in whether they can run VoIP (or something similar) knowing the various types of NAT is not really required. All they want is a go/no go decision on whether they can communicate through the NAT. If that's the case it would be worth specifying a truncated STUN test sequence that yields only this go/no go decision. That would seem to involve doing Test I on the set of SRV derived STUN servers until one is found that works. You would then do a Test II. Once you have the result of that test, you can stop. Either this could be mentioned as a separate test sequence, or the current text could be amended to say something like: "If the client requires cone NAT functionality to operate (such as for SIP RTP/RTCP) and is not interested in discovering the particular restrictions of a NAT that is not useable, it can stop the testing at this point. If it wishes to know the restricted type of NAT, the following tests can be performed...." Thanks, Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Wed Apr 3 07:02:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00174 for ; Wed, 3 Apr 2002 07:02:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA16802 for midcom-archive@odin.ietf.org; Wed, 3 Apr 2002 07:02:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16511; Wed, 3 Apr 2002 07:01:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16472 for ; Wed, 3 Apr 2002 07:01:06 -0500 (EST) Received: from protactinium (protactinium.btinternet.com [194.73.73.176]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00148 for ; Wed, 3 Apr 2002 07:01:03 -0500 (EST) Received: from host213-122-38-80.in-addr.btopenworld.com ([213.122.38.80] helo=tkw) by protactinium with smtp (Exim 3.22 #8) id 16sjRl-0007ZX-00; Wed, 03 Apr 2002 13:01:02 +0100 Message-ID: <008601c1db07$55a33d60$0200000a@tkw> From: "Pete Cordell" To: "Cullen Jennings" , References: Subject: Re: [midcom] Protocol evaluation contribution reminder Date: Wed, 3 Apr 2002 13:01:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit SOCKS would seem to be a candidate also. Or do people already know that it is not useful? Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: Cullen Jennings To: Bob Penfield ; ; Melinda Shore Sent: 02 April 2002 18:25 Subject: RE: [midcom] Protocol evaluation contribution reminder > > I'm sort of surprised not to see > > RSVP > HTTP ( perhaps a SOAP or UPNP style thing ) > WEBDAV to modify an XML document that describes the current filter specs? > If you consider the midbox to be a IP to IP gateway, this could be a Session > Initiation Problem > telnet of IOS style ACLs > > Many of these protocol evaluations are going to amount to - yes, the > protocol could function as a transport for the data and perhaps deal with > the security and authentication issues and No, the protocol has no idea of > the semantics of what we want to do on a midbox but we can invent that on > top of the current protocol. > > Cullen > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Wed Apr 3 09:41:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04543 for ; Wed, 3 Apr 2002 09:41:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA28138 for midcom-archive@odin.ietf.org; Wed, 3 Apr 2002 09:41:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27904; Wed, 3 Apr 2002 09:37:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27871 for ; Wed, 3 Apr 2002 09:37:33 -0500 (EST) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04425 for ; Wed, 3 Apr 2002 09:37:30 -0500 (EST) Received: from jku2.fokus.gmd.de (dhcp218.fokus.gmd.de [195.37.78.218]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g33EcGZ02098; Wed, 3 Apr 2002 16:38:16 +0200 Message-Id: <5.1.0.14.0.20020403110130.02d0feb8@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 03 Apr 2002 11:05:42 +0200 To: Melinda Shore , midcom@ietf.org From: Jiri Kuthan Subject: Re: [midcom] Fwd: Draft MIDCOM Minutes In-Reply-To: <5.1.0.14.0.20020402091103.00a800e0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 04:13 PM 4/2/2002, Melinda Shore wrote: >Process Going Forward >===================== Melinda, My notes tell me I had questions on the process which did not make it to the minutes. Jiri: "How will the protocol selection useful in getting to a simple, interoperable protocol? I suspect that will just take time and result in taking a complex protocol which does unnecessarily more than needed?" Melinda: "thats how IESG wants it". Jiri: "What will we do if all protocols qualify?" Melinda: "we will shop for more features, such as low complexity." -Jiri _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Wed Apr 3 09:41:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04566 for ; Wed, 3 Apr 2002 09:41:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA28166 for midcom-archive@odin.ietf.org; Wed, 3 Apr 2002 09:41:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27999; Wed, 3 Apr 2002 09:38:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27970 for ; Wed, 3 Apr 2002 09:38:10 -0500 (EST) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04436 for ; Wed, 3 Apr 2002 09:38:07 -0500 (EST) Received: from jku2.fokus.gmd.de (dhcp218.fokus.gmd.de [195.37.78.218]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g33EcKZ02119; Wed, 3 Apr 2002 16:38:20 +0200 Message-Id: <5.1.0.14.0.20020403134226.0222ca30@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 03 Apr 2002 13:56:41 +0200 To: "Tom-PT Taylor", midcom@ietf.org From: Jiri Kuthan Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Cc: "Cedric Aoun" In-Reply-To: <4D79C746863DD51197690002A52CDA0001E8A22D@zcard0kc.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Tom-PT, I'm glad midcom has gained momentum to focus on real things. As for the overlapping rules: I'm very much in favor of the approach #1, i.e., disallowing overlapping rules. I think MidCom's primary purpose is to get apps over NATs/FWs for which this is good enough. It is not good enough for a FW/NAT mgmt protocol, but that is not what we are concerned with. Allowing overlapping rules would result in unnecessarily higher complexity of midcom servers. Simple is good. Rather then priorities, I would prefer to use first-come, first-served conflict resolution then. -Jiri >There are two possible cases: > >(1) The Policy Rule associated with each of the two {Filter, Action} pairs >must be installed completely or not at all. In this case, if there is a >conflict between the two rules in the zone of overlap, the lower-priority >Policy Rule will be disallowed (if it was the later arrival) or deactivated >(if it was already installed). > >(2) The Policy Rule which has lower priority in the zone of conflict allows >for partial implementation. Thus the desired {Filter, Action} pair is >modified to exclude the zone of overlap. There are two sub-cases: > >(a) In the simpler case, the exclusion of the zone of overlap still leaves a >box in N-space. This is true of Filter 2 in the diagram. In this case, the >original {Filter, Action} pair is replaced by another {Filter', Action} pair >where Filter' defines the region outside the zone of overlap. > >(b) In the more complex case, the exclusion of the zone of overlap leaves a >complex region rather than a simple box. This is true of Filter 1 in the >above diagram. In this case, the region can be partitioned into a set of up >to 2N simple boxes in N-space. Thus the canonical outcome of the conflict >with respect to the original {Filter, Action} pair is a set of {Filter, >Action} pairs where Action is the same as in the original pair. > >Policy rules are evaluated for conflict through a pairwise comparison of >their individual {Filter, Action} components. > >Let us turn now to the detailed semantic content of the {Filter, Action} >pairs. As the examples of section 4 illustrate, it is possible to represent >NAT and firewall policies using sets of uni-directional filters of the form > >{, , , >Protocol} > >with suitable wildcarding. Each Address-Port term has the detailed form >{Address, Port, Realm}. Two wildcards are needed: > > - ANY is a placeholder for a value to be bound when a flow instance is >matched against the Policy Rule. > > - CHOOSE is a value to be assigned by the Middlebox at Policy Rule >installation time. That is, each CHOOSE in a Policy Rule Request must be >replaced by a specific value in a Policy Rule Response. CHOOSE must only be >used for components of . > >Our requirements indicate the need for two additional items. It must be >possible on occasion for the filter to specify a range of ports rather than >a single port. Moreover, it must be possible to constrain the parity of the >Map port assignment(s). These requirements are satisfied by adding three >modifiers to the port components of the filter: > > - the Count modifier is an integer from 1 upwards. If it is included in a >port component, it indicates that a range of ports is requested. If the >filter provides a specific value rather than a wildcard for the port in >question, the port assignments begin with that value. If Count is absent, >only one port is indicated. > > - the Step modifier must not be present unless the Count modifier is also >present. It is an integer from 1 upwards indicating the increment to be >applied in determining port numbers for a port number range. One example of >when Step would be needed is when allocating RTP or RTCP ports for layered >encoding. In this example, Step would have value 2. The default if Step is >absent is an increment of 1. > > - the Parity modifier has values Odd or Even. If it is included in a port >component, it indicates that the port (or the first port of a range) must >have the given parity. If Parity is not specified, port assignment is >unconstrained. > >Tom Taylor >taylor@nortelnetworks.com >Ph. +1 613 736 0961 (ESN 396 1490) > > >_______________________________________________ >midcom mailing list >midcom@ietf.org >https://www1.ietf.org/mailman/listinfo/midcom > >_______________________________________________ >midcom mailing list >midcom@ietf.org >https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Wed Apr 3 09:41:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04582 for ; Wed, 3 Apr 2002 09:41:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA28180 for midcom-archive@odin.ietf.org; Wed, 3 Apr 2002 09:41:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27860; Wed, 3 Apr 2002 09:37:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27829 for ; Wed, 3 Apr 2002 09:37:19 -0500 (EST) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04423 for ; Wed, 3 Apr 2002 09:37:16 -0500 (EST) Received: from jku2.iptel.org (dhcp218.fokus.gmd.de [195.37.78.218]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g33EcGZ02097 for ; Wed, 3 Apr 2002 16:38:16 +0200 Message-Id: <5.1.0.14.0.20020403111102.02fd1b20@iptel.org> X-Sender: jiri@iptel.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 03 Apr 2002 11:13:11 +0200 To: midcom@ietf.org From: Jiri Kuthan Subject: Re: [midcom] Protocol Evaluation document template Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org [resent, as the mailing list filtering logic apparently recognized this email to be spam] I'm personaly not very convinced about efficiency of an iterative "evaluate-x-pet-protocols" --> "refine requirements" --+ ^ | +---------------------------------------------------+ process either. I guess it would result in a bunch of documents well demonstrating that each author's pet protocol makes the requirements happy, if tweaked enough. Nice to have, but I would prefer having a simple, interoperable protocol with running code soon. I personaly do not see how we can approach such an objective using this process. Starting from the minimum the MidCom protocol must accomplish rather than from maximum which someone's favorite protocol is capable of seems to me a much more feasible strategy. -Jiri At 05:06 AM 4/1/2002, Jonathan Rosenberg wrote: >Louis-Nicolas Hamer wrote: >> >> I tend to agree with Jonathan but I also feel that we should move >> forward >> with the protocol evaluation as soon as possible...what I am scared of >> is what >> some call "analysis-paralysis"... > >Since I appear to be in the minority, I'll cease and desist on this >point. However, I do want to be clear that I was not proposing analysis >of any sort; the "abstract protocol" is design work - to specify the >protocol itself in all details but the syntax. > >-Jonathan R. -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Wed Apr 3 10:02:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04985 for ; Wed, 3 Apr 2002 10:02:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA29570 for midcom-archive@odin.ietf.org; Wed, 3 Apr 2002 10:02:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29254; Wed, 3 Apr 2002 10:00:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29222 for ; Wed, 3 Apr 2002 10:00:34 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04926 for ; Wed, 3 Apr 2002 10:00:31 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g33F04J8009112; Wed, 3 Apr 2002 07:00:04 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADK33624; Wed, 3 Apr 2002 06:57:40 -0800 (PST) Message-Id: <5.1.0.14.0.20020403100102.00a8c7f0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 03 Apr 2002 10:04:09 -0500 To: Jiri Kuthan , midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] Protocol Evaluation document template In-Reply-To: <5.1.0.14.0.20020403111102.02fd1b20@iptel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 11:13 AM 4/3/02 +0200, Jiri Kuthan wrote: >I'm personaly not very convinced about efficiency of an iterative >"evaluate-x-pet-protocols" --> "refine requirements" --+ > ^ | > +---------------------------------------------------+ >process either. Good, because that's not what we're doing. >Nice to have, but I would prefer having a simple, interoperable >protocol with running code soon. I personaly do not see how we can >approach such an objective using this process. Starting from the >minimum the MidCom protocol must accomplish rather than from maximum >which someone's favorite protocol is capable of seems to me >a much more feasible strategy. It's been absolutely clear since well before the working group was chartered that we were going to be expected to base a midcom protocol on an existing IETF protocol. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Wed Apr 3 10:10:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05396 for ; Wed, 3 Apr 2002 10:10:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA00212 for midcom-archive@odin.ietf.org; Wed, 3 Apr 2002 10:10:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29991; Wed, 3 Apr 2002 10:06:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29962 for ; Wed, 3 Apr 2002 10:06:08 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05209 for ; Wed, 3 Apr 2002 10:06:05 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g33F5ca16233 for ; Wed, 3 Apr 2002 07:05:38 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADK33741; Wed, 3 Apr 2002 07:03:15 -0800 (PST) Message-Id: <5.1.0.14.0.20020403100612.00abf990@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 03 Apr 2002 10:09:43 -0500 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Fwd: Impending publication: draft-iab-unsaf-considerations-01.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Read and pay heed. All of our pre-midcom work is going to be expected to directly address the questions raised in section 4. Comments on the document should be sent by 15 April to Leslie or to the IETF discussion mailing list. Melinda >To: IETF-Announce: ; >From: "Leslie Daigle" >Subject: Impending publication: draft-iab-unsaf-considerations-01.txt >Date: Wed, 03 Apr 2002 09:49:29 -0500 >Sender: dinaras@cnri.reston.va.us > >The IAB is ready to ask the IESG to publish > > IAB Considerations for UNilateral Self-Address Fixing (UNSAF) > draft-iab-unsaf-considerations-01.txt > >as an Informational RFC. This document is part survey of issues, >and part advice for IETF protocol development. The IAB would >like to ensure that the IETF community has had an opportunity to >read it and comment before its publication. > >The IAB solicits comments by April 15, 2002. Please send >comments to the IAB, care of the document editor >(leslie@thinkingcat.com), or to ietf@ietf.org. The document can be >found at > >http://www.ietf.org/internet-drafts/draft-iab-unsaf-considerations-01.txt > >Leslie Daigle >For the IAB > >ABSTRACT > > With current NA[P]T middleboxes, individual networks using different > address realms are bridged. However, as a side effect of address > translation, communicating endpoints on either side of the middlebox > do not know how to refer to themselves using addresses that are > applicable in the other realm -- the address translation is locked > within the middlebox. Various proposals have been made for > "UNilateral Self-Address Fixing (UNSAF)" processes. These are > processes whereby some originating process attempts to determine or > fix the address (and port) by which it is known to another process -- > e.g., to be able to use address data in the protocol exchange, or to > advertise a public address from which it will receive connections. > > This document outlines the reasons for which these proposals can be > considered at best as short term fixes to specific problems, and the > specific issues to be carefully evaluated before creating an UNSAF > proposal. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Wed Apr 3 10:11:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05414 for ; Wed, 3 Apr 2002 10:11:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA00262 for midcom-archive@odin.ietf.org; Wed, 3 Apr 2002 10:11:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00199; Wed, 3 Apr 2002 10:09:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00160 for ; Wed, 3 Apr 2002 10:09:35 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05337 for ; Wed, 3 Apr 2002 10:09:19 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g33F8dl28200; Wed, 3 Apr 2002 07:08:39 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADK33798; Wed, 3 Apr 2002 07:06:30 -0800 (PST) Message-Id: <5.1.0.14.0.20020403101002.00ac2830@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 03 Apr 2002 10:12:58 -0500 To: "Pete Cordell" , From: Melinda Shore Subject: Re: [midcom] Protocol evaluation contribution reminder In-Reply-To: <008601c1db07$55a33d60$0200000a@tkw> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 01:01 PM 4/3/02 +0100, Pete Cordell wrote: >SOCKS would seem to be a candidate also. Or do people already know that it >is not useful? SOCKS would require significant extension, and I think that its basic model is actually covered in a more general way by RSIP. It's a reasonable protocol to investigate, though. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Wed Apr 3 11:34:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08367 for ; Wed, 3 Apr 2002 11:34:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07607 for midcom-archive@odin.ietf.org; Wed, 3 Apr 2002 11:34:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07319; Wed, 3 Apr 2002 11:32:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07287 for ; Wed, 3 Apr 2002 11:32:38 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08282 for ; Wed, 3 Apr 2002 11:32:34 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g33GW7880105; Wed, 3 Apr 2002 18:32:07 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA25238; Wed, 3 Apr 2002 18:31:50 +0200 Date: Wed, 03 Apr 2002 18:35:01 +0200 From: Juergen Quittek To: Pete Cordell , Cullen Jennings , midcom@ietf.org Subject: Re: [midcom] Protocol evaluation contribution reminder Message-ID: <31285125.1017858901@[192.168.102.164]> In-Reply-To: <008601c1db07$55a33d60$0200000a@tkw> References: <008601c1db07$55a33d60$0200000a@tkw> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Pete, Our lab runs very well behind a SOCKS firewall. So, I consider it quite useful. However, I think it is too simple to match the midcom requirements. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de --On 03 April 2002 13:01 +0100 Pete Cordell wrote: > SOCKS would seem to be a candidate also. Or do people already know that it > is not useful? > > Pete. > > ============================================= > Pete Cordell > Tech-Know-Ware > pete@tech-know-ware.com > +44 1473 635863 > ============================================= > > ----- Original Message ----- > From: Cullen Jennings > To: Bob Penfield ; ; Melinda > Shore > Sent: 02 April 2002 18:25 > Subject: RE: [midcom] Protocol evaluation contribution reminder > > >> >> I'm sort of surprised not to see >> >> RSVP >> HTTP ( perhaps a SOAP or UPNP style thing ) >> WEBDAV to modify an XML document that describes the current filter specs? >> If you consider the midbox to be a IP to IP gateway, this could be a > Session >> Initiation Problem >> telnet of IOS style ACLs >> >> Many of these protocol evaluations are going to amount to - yes, the >> protocol could function as a transport for the data and perhaps deal with >> the security and authentication issues and No, the protocol has no idea of >> the semantics of what we want to do on a midbox but we can invent that on >> top of the current protocol. >> >> Cullen >> >> >> _______________________________________________ >> midcom mailing list >> midcom@ietf.org >> https://www1.ietf.org/mailman/listinfo/midcom > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Wed Apr 3 11:34:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08387 for ; Wed, 3 Apr 2002 11:34:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07635 for midcom-archive@odin.ietf.org; Wed, 3 Apr 2002 11:34:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07505; Wed, 3 Apr 2002 11:33:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07396 for ; Wed, 3 Apr 2002 11:33:03 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08310 for ; Wed, 3 Apr 2002 11:33:00 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g33GVhe04522; Wed, 3 Apr 2002 10:31:43 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 10:31:44 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A03DE393E@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Melinda Shore'" , Pete Cordell , midcom@ietf.org Subject: RE: [midcom] Protocol evaluation contribution reminder Date: Wed, 3 Apr 2002 10:31:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB2D.09192A60" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DB2D.09192A60 Content-Type: text/plain; charset="iso-8859-1" With my editor's hat on... There seems to be general WG interest in visiting a larger number of protocols. At this point, I've not taken any of these queries as "volunteering" to do these evaluations of these other protocols. With my editor's hat off... I think it's a really good idea to do a minimal evaluation of several of the protocols that have been put forth over the past couple days (DIAMETER, SOCKS, RSVP, etc.). I do realize that some of these have already been previously considered and already discarded, but from a completeness perspective, it would be really useful to capture why they were discarded or considered inappropriate. I have a feeling that the reason why people that have suggested these haven't volunteered has more to do with that limitation of only 24 hours in a given day versus lack of interest. With my editor's hat back on... I would suggest we add an additional section to the Protocol Evaluation document template to cover these other protocols. What this would require from the WG would be some discussion on the list to compile this information or "volunteers" (that word again) to provide minimal content for the protocol evaluation document for these other protocols (i.e. just a brief overview and summary of Pros/cons (per the requirements) and perhaps a recommendation as to why this wouldn't be appropriate as the MIDCOM protocol). Now, I can see problems with doing this as it's possible one of these others might actually be better and we've not necessarily evaluated these as thoroughly as the others (although, Melinda seems to be indicating that a certain level of analysis had been previously done in an informal manner on some of these others). So, what do people think about this proposal? Mary. -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Wednesday, April 03, 2002 9:13 AM To: Pete Cordell; midcom@ietf.org Subject: Re: [midcom] Protocol evaluation contribution reminder At 01:01 PM 4/3/02 +0100, Pete Cordell wrote: >SOCKS would seem to be a candidate also. Or do people already know that it >is not useful? SOCKS would require significant extension, and I think that its basic model is actually covered in a more general way by RSIP. It's a reasonable protocol to investigate, though. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C1DB2D.09192A60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Protocol evaluation contribution reminder

With my editor's hat on...

There seems to be general WG interest in visiting a = larger number of protocols.  At this point, I've not taken any of = these queries as "volunteering" to do these evaluations of = these other protocols.

With my editor's hat off...

I think it's a really good idea to do a minimal = evaluation of several of the protocols that have been put forth over = the past couple days (DIAMETER, SOCKS, RSVP, etc.).  I do realize = that some of these have already been previously considered and already = discarded, but from a completeness perspective, it would be really = useful to capture why they were discarded or considered = inappropriate.  I have a feeling that the reason why people that = have suggested these haven't volunteered has more to do with that = limitation of only 24 hours in a given day versus lack of = interest. 

With my editor's hat back on...

I would suggest we add an additional section to the = Protocol Evaluation document template to cover these other = protocols.  What this would require from the WG would be some = discussion on the list to compile this information or = "volunteers" (that word again) to provide minimal content for = the protocol evaluation document for these other protocols (i.e. just a = brief overview and summary of Pros/cons (per the requirements) and = perhaps a recommendation as to why this wouldn't be appropriate as the = MIDCOM protocol).  Now, I can see problems with doing this as it's = possible one of these others might actually be better and we've not = necessarily evaluated these as thoroughly as the others (although, = Melinda seems to be indicating that a certain level of analysis had = been previously done in an informal manner on some of these others). =

So, what do people think about this proposal?

Mary. 

-----Original Message-----
From: Melinda Shore [mailto:mshore@cisco.com]
Sent: Wednesday, April 03, 2002 9:13 AM
To: Pete Cordell; midcom@ietf.org
Subject: Re: [midcom] Protocol evaluation = contribution reminder


At 01:01 PM 4/3/02 +0100, Pete Cordell wrote:
>SOCKS would seem to be a candidate also.  = Or do people already know that it
>is not useful?

SOCKS would require significant extension, and I = think that
its basic model is actually covered in a more = general way by
RSIP.  It's a reasonable protocol to = investigate, though.

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C1DB2D.09192A60-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Wed Apr 3 11:42:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08675 for ; Wed, 3 Apr 2002 11:42:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA08276 for midcom-archive@odin.ietf.org; Wed, 3 Apr 2002 11:42:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08165; Wed, 3 Apr 2002 11:41:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08123 for ; Wed, 3 Apr 2002 11:41:10 -0500 (EST) Received: from linux.aravox.com (linux.aravox.com [209.46.41.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08657 for ; Wed, 3 Apr 2002 11:41:06 -0500 (EST) Received: from MPIETRAS (IDENT:root@linux.aravox.com [209.46.41.66] (may be forged)) by linux.aravox.com (8.9.3/8.9.3) with ESMTP id KAA08204; Wed, 3 Apr 2002 10:39:54 -0600 From: "Mark Pietras" To: "'Melinda Shore'" , "'Cullen Jennings'" , Subject: RE: [midcom] Protocol evaluation contribution reminder Date: Wed, 3 Apr 2002 10:39:22 -0600 Message-ID: <002c01c1db2e$1c085050$4c01a8c0@MPIETRAS> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <5.1.0.14.0.20020402125340.00a8dc50@localhost> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit I'm in general agreement with other posts in that having a more abstract definition makes sense first, but not strongly enough to make a stink about it. Given where we are though, I'm surprised nobody has brought up in this thread SIP as a candidate for evaluation. I recall someone suggesting this before jokingly, but I'm surprised to not see it come up again recently. Anyway, it sounds silly (overboard?), and I'm not saying I necessarily believe it's the best fit, but it's as good a construct as some of the others. Master-Slave'ness versus Peer-to-Peer'ness issues could be worked out in usage, we could have a ruleset description protocol (RDP) closely mirroring but in place of SDP (we'll need something like this with any protocol choice)... and it has the advantage in that there's likely to be a parser and other logic right there with the MIDCOM agent ready to use!! If I had some time on my hands I'd do a real evaluation... Remind me again why this is stupid? Mark. -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Melinda Shore Sent: Tuesday, April 02, 2002 12:01 PM To: Cullen Jennings; midcom@ietf.org Subject: RE: [midcom] Protocol evaluation contribution reminder At 09:25 AM 4/2/02 -0800, Cullen Jennings wrote: >RSVP >HTTP ( perhaps a SOAP or UPNP style thing ) >WEBDAV to modify an XML document that describes the current filter specs? >If you consider the midbox to be a IP to IP gateway, this could be a Session >Initiation Problem >telnet of IOS style ACLs RSVP is actually one of the few IETF protocols that really diverges from the midcom framework and requirements, and I think we disposed of the notion of using its model, in the context of the midcom working group, last December. Other candidates could include Diameter and even GSMP. I'd like to see us be thorough, but at the same time I don't think we need to go overboard. That is to say, it's probably best if people limit themselves to evaluation of protocols that they really believe are good fits to the framework and requirements. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Wed Apr 3 12:00:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09122 for ; Wed, 3 Apr 2002 12:00:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA10334 for midcom-archive@odin.ietf.org; Wed, 3 Apr 2002 12:00:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09320; Wed, 3 Apr 2002 11:59:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09282 for ; Wed, 3 Apr 2002 11:59:03 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09055 for ; Wed, 3 Apr 2002 11:58:57 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g33GwVa16212; Wed, 3 Apr 2002 08:58:31 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADK36380; Wed, 3 Apr 2002 08:56:08 -0800 (PST) Message-Id: <5.1.0.14.0.20020403115613.00a9b520@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 03 Apr 2002 12:02:29 -0500 To: "Mark Pietras" , From: Melinda Shore Subject: RE: [midcom] Protocol evaluation contribution reminder In-Reply-To: <002c01c1db2e$1c085050$4c01a8c0@MPIETRAS> References: <5.1.0.14.0.20020402125340.00a8dc50@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 10:39 AM 4/3/02 -0600, Mark Pietras wrote: >Given where we are though, I'm surprised nobody has brought up in this >thread SIP as a candidate for evaluation. I recall someone suggesting >this before jokingly, but I'm surprised to not see it come up again >recently. I think it's not unreasonable, myself. I've been generally surprised by the taste and restraint being shown by volunteers, for which I'm endlessly grateful. If there are people who would like to help out with a protocol evaluation but either haven't identified one they'd like to describe or they have but there's already someone covering it, perhaps they could get in touch with Mary (mbarnes@nortelnetworks.com) and we can get more of the obvious candidates covered. Many thanks to everybody who's volunteering. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Wed Apr 3 12:09:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09371 for ; Wed, 3 Apr 2002 12:09:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA11456 for midcom-archive@odin.ietf.org; Wed, 3 Apr 2002 12:09:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11373; Wed, 3 Apr 2002 12:07:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11342 for ; Wed, 3 Apr 2002 12:07:19 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09332 for ; Wed, 3 Apr 2002 12:07:15 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g33H6al18298; Wed, 3 Apr 2002 09:06:36 -0800 (PST) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ACM42577; Wed, 3 Apr 2002 09:06:59 -0800 (PST) From: "Cullen Jennings" To: "Pete Cordell" , "Cullen Jennings" , Subject: RE: [midcom] Protocol evaluation contribution reminder Date: Wed, 3 Apr 2002 09:09:30 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <008601c1db07$55a33d60$0200000a@tkw> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit I had not considered SOCKS - interesting idea. I did completely miss Diameter on my list which seems like a better candidate than anything I mentioned. > -----Original Message----- > From: Pete Cordell [mailto:pete@tech-know-ware.com] > Sent: Wednesday, April 03, 2002 4:02 AM > To: Cullen Jennings; midcom@ietf.org > Subject: Re: [midcom] Protocol evaluation contribution reminder > > > SOCKS would seem to be a candidate also. Or do people already > know that it > is not useful? > > Pete. > > ============================================= > Pete Cordell > Tech-Know-Ware > pete@tech-know-ware.com > +44 1473 635863 > ============================================= > > ----- Original Message ----- > From: Cullen Jennings > To: Bob Penfield ; ; Melinda > Shore > Sent: 02 April 2002 18:25 > Subject: RE: [midcom] Protocol evaluation contribution reminder > > > > > > I'm sort of surprised not to see > > > > RSVP > > HTTP ( perhaps a SOAP or UPNP style thing ) > > WEBDAV to modify an XML document that describes the current > filter specs? > > If you consider the midbox to be a IP to IP gateway, this could be a > Session > > Initiation Problem > > telnet of IOS style ACLs > > > > Many of these protocol evaluations are going to amount to - yes, the > > protocol could function as a transport for the data and > perhaps deal with > > the security and authentication issues and No, the protocol has > no idea of > > the semantics of what we want to do on a midbox but we can > invent that on > > top of the current protocol. > > > > Cullen > > > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Wed Apr 3 12:19:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09632 for ; Wed, 3 Apr 2002 12:19:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12081 for midcom-archive@odin.ietf.org; Wed, 3 Apr 2002 12:19:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11921; Wed, 3 Apr 2002 12:16:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11892 for ; Wed, 3 Apr 2002 12:16:25 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09552 for ; Wed, 3 Apr 2002 12:16:21 -0500 (EST) Received: from airborne.cisco.com (IDENT:mirapoint@airborne.cisco.com [171.71.154.32]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g33HFtJ8013932 for ; Wed, 3 Apr 2002 09:15:55 -0800 (PST) Received: from SBRIM-W2K (rtp-vpn1-422.cisco.com [10.82.225.166]) by airborne.cisco.com (Mirapoint) with SMTP id AAX06346; Wed, 3 Apr 2002 09:15:43 -0800 (PST) Received: by SBRIM-W2K (sSMTP sendmail emulation); Wed, 3 Apr 2002 12:15:53 -0500 Date: Wed, 3 Apr 2002 12:15:53 -0500 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Protocol evaluation contribution reminder Message-ID: <20020403121552.D1948@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <008601c1db07$55a33d60$0200000a@tkw> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from fluffy@cisco.com on Wed, Apr 03, 2002 at 09:09:30AM -0800 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Wed, Apr 03, 2002 09:09:30AM -0800, Cullen Jennings wrote: > I had not considered SOCKS - interesting idea. I did completely miss > Diameter on my list which seems like a better candidate than anything I > mentioned. Doesn't help unless someone takes responsibility for writing each one up. I suppose someone could write up more than one. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Wed Apr 3 13:17:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11340 for ; Wed, 3 Apr 2002 13:17:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA16447 for midcom-archive@odin.ietf.org; Wed, 3 Apr 2002 13:17:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16290; Wed, 3 Apr 2002 13:13:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16261 for ; Wed, 3 Apr 2002 13:13:02 -0500 (EST) Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11250 for ; Wed, 3 Apr 2002 13:12:59 -0500 (EST) Received: from host213-122-52-207.in-addr.btopenworld.com ([213.122.52.207] helo=tkw) by tungsten.btinternet.com with smtp (Exim 3.22 #8) id 16spFb-0002XV-00; Wed, 03 Apr 2002 19:12:51 +0100 Message-ID: <004301c1db3b$41191200$0200000a@tkw> From: "Pete Cordell" To: "Mary Barnes" , "'Melinda Shore'" , References: <1B54FA3A2709D51195C800508BF9386A03DE393E@zrc2c000.us.nortel.com> Subject: Re: [midcom] Protocol evaluation contribution reminder Date: Wed, 3 Apr 2002 19:12:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit RE: [midcom] Protocol evaluation contribution reminderMary, I think it's a good idea to list the protocols that we 'know' won't work also. But maybe it should be sufficient to just list the fatal reason (or set of reasons) why it is not suitable, rather than matching the full template. Indeed, I think it would be better to say something like: SOCKS (or whatever) - Gut feeling was that it was not appropriate and so it wasn't considered further. rather than ignore these protocols completely. Mind you, it would be good if we could also list what is useful about the discarded protocol as that information may come in handy when polishing off various parts of the selected candidate protocol. A few arguments on the list ought to be sufficient to provide the information. Maybe I can start the ball rolling by saying: ------------- SOCKS does not allow for persistent TCP listeners for receiving incoming calls (although it does allow for one-shot listeners that automatically close on reception of the first incoming TCP connection). Control and authentication is on a per-connection basis, potentially placing significant computational load on the server and so may limit scalability. Each UDP connection requires a separate authenticated TCP control connection thus requiring TCP state in addition to UDP state which further limits scaling. The BIND operation does have sufficient information to be used with a NAT function. However, the UDP ASSOCIATE semantics do not readily allow for the inclusion of NAT functionality (BND.ADDR/PORT indicate where the local client must send data to in order to send it from the allocated port rather than where the remote client should send data to to be relayed to the local client). The BIND and CONNECT operations involve essentially in-band configuration. Hence it is not clear how these mechanisms would be used if the firewall and the NAT were separate devices. In its favour, SOCKS does pass around the sorts of data fields that a midcom protocol would require, although the actual addressing tuples that are used are probably insufficient for the midcom case. It also includes a simple authentication mechanism scheme that may be worth looking at if the selected midcom protocol is lacking in this respect, although there are likely to be many of these to choose from, and the mechanism used is definitely on the simpler side of things. --------------- Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: Mary Barnes To: 'Melinda Shore' ; Pete Cordell ; midcom@ietf.org Sent: 03 April 2002 17:31 Subject: RE: [midcom] Protocol evaluation contribution reminder With my editor's hat on... There seems to be general WG interest in visiting a larger number of protocols. At this point, I've not taken any of these queries as "volunteering" to do these evaluations of these other protocols. With my editor's hat off... I think it's a really good idea to do a minimal evaluation of several of the protocols that have been put forth over the past couple days (DIAMETER, SOCKS, RSVP, etc.). I do realize that some of these have already been previously considered and already discarded, but from a completeness perspective, it would be really useful to capture why they were discarded or considered inappropriate. I have a feeling that the reason why people that have suggested these haven't volunteered has more to do with that limitation of only 24 hours in a given day versus lack of interest. With my editor's hat back on... I would suggest we add an additional section to the Protocol Evaluation document template to cover these other protocols. What this would require from the WG would be some discussion on the list to compile this information or "volunteers" (that word again) to provide minimal content for the protocol evaluation document for these other protocols (i.e. just a brief overview and summary of Pros/cons (per the requirements) and perhaps a recommendation as to why this wouldn't be appropriate as the MIDCOM protocol). Now, I can see problems with doing this as it's possible one of these others might actually be better and we've not necessarily evaluated these as thoroughly as the others (although, Melinda seems to be indicating that a certain level of analysis had been previously done in an informal manner on some of these others). So, what do people think about this proposal? Mary. -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Wednesday, April 03, 2002 9:13 AM To: Pete Cordell; midcom@ietf.org Subject: Re: [midcom] Protocol evaluation contribution reminder At 01:01 PM 4/3/02 +0100, Pete Cordell wrote: >SOCKS would seem to be a candidate also. Or do people already know that it >is not useful? SOCKS would require significant extension, and I think that its basic model is actually covered in a more general way by RSIP. It's a reasonable protocol to investigate, though. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Apr 3 16:41:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16575 for ; Wed, 3 Apr 2002 16:41:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA29265 for midcom-archive@odin.ietf.org; Wed, 3 Apr 2002 16:42:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28713; Wed, 3 Apr 2002 16:35:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28684 for ; Wed, 3 Apr 2002 16:35:47 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16453 for ; Wed, 3 Apr 2002 16:35:42 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.80]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g33LaRTE027526 for ; Wed, 3 Apr 2002 16:36:27 -0500 (EST) Message-ID: <3CAB7593.ABE3249E@dynamicsoft.com> Date: Wed, 03 Apr 2002 16:35:16 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: midcom@ietf.org Content-Type: multipart/mixed; boundary="------------CA51BB9CB8E089C91240C7F3" Subject: [midcom] [Fwd: Application for port-number (3478)] Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This is a multi-part message in MIME format. --------------CA51BB9CB8E089C91240C7F3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit FYI, we now have a port number for stun. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com --------------CA51BB9CB8E089C91240C7F3 Content-Type: message/rfc822 Content-Disposition: inline Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2HCQXVWG; Wed, 3 Apr 2002 16:21:31 -0500 Received: from mailhub.icann.org (mailhub.icann.org [192.0.34.33]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g33LJ5e8025671 for ; Wed, 3 Apr 2002 16:19:06 -0500 (EST) Received: from tarim ([192.0.35.80]) by mailhub.icann.org (8.9.3/8.9.3) with SMTP id NAA01838 for ; Wed, 3 Apr 2002 13:20:40 -0800 Message-ID: From: IANA To: jdrosen@dynamicsoft.com Subject: RE: Application for port-number (3478) Date: Wed, 3 Apr 2002 16:18:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mozilla-Status2: 00000000 Dear Jonathan, We have assigned the following user port number with you as the point of contact: nat-stun-port 3478/tcp Simple Traversal of UDP Through NAT (STUN) port nat-stun-port 3478/udp Simple Traversal of UDP Through NAT (STUN) port # Jonathan Rosenberg April 2002 Please notify the IANA if there is a change in contact information. Thank you, Michelle S. Cotton IANA Administrator *************************************************************** Internet Assigned Numbers Authority (IANA) 4676 Admiralty Way, Suite 330 Marina del Rey, California 90292 Voice: (310) 823-9358 FAX: (310) 823-8649 email: iana@iana.org *************************************************************** --------------CA51BB9CB8E089C91240C7F3-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 4 05:26:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09026 for ; Thu, 4 Apr 2002 05:26:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA19147 for midcom-archive@odin.ietf.org; Thu, 4 Apr 2002 05:26:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18965; Thu, 4 Apr 2002 05:20:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18933 for ; Thu, 4 Apr 2002 05:20:10 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08945 for ; Thu, 4 Apr 2002 05:20:06 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g34AJ1805161; Thu, 4 Apr 2002 12:19:01 +0200 (CEST) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA02095; Thu, 4 Apr 2002 12:18:41 +0200 Received: from ccrle.nec.de (elgar.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 6C92E119E2; Thu, 4 Apr 2002 12:18:40 +0200 (CEST) Message-ID: <3CAC2891.5080508@ccrle.nec.de> Date: Thu, 04 Apr 2002 12:18:57 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20020305 X-Accept-Language: en-us MIME-Version: 1.0 To: Pete Cordell Cc: Cullen Jennings , midcom@ietf.org Subject: Re: [midcom] Protocol evaluation contribution reminder References: <008601c1db07$55a33d60$0200000a@tkw> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit An old email (midcom list 02/07/02) regarding SOCKS and MIDCOM and SOCKS is not suitable for MIDCOM: > In the MIDCOM case the SOCKS server is the firewall/NAT and the client > is located at the MIDCOM agent. After establishing a pinhole/binding > in the NAT by the MIDCOM agent, the data flow from the client, e.g. a > SIP phone with UDP traffic, has to take the follwing way: > SIP-Phone -> MIDCOM agent/SOCKS client -> SOCKS/Server. This is certainly not the way it should work. Martin Pete Cordell wrote: > SOCKS would seem to be a candidate also. Or do people already know that it > is not useful? > > Pete. > > ============================================= > Pete Cordell > Tech-Know-Ware > pete@tech-know-ware.com > +44 1473 635863 > ============================================= -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 4 09:01:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14645 for ; Thu, 4 Apr 2002 09:01:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA01919 for midcom-archive@odin.ietf.org; Thu, 4 Apr 2002 09:01:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01539; Thu, 4 Apr 2002 08:59:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01508 for ; Thu, 4 Apr 2002 08:59:14 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14473 for ; Thu, 4 Apr 2002 08:59:08 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g34Dvr819440; Thu, 4 Apr 2002 15:57:53 +0200 (CEST) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA04805; Thu, 4 Apr 2002 15:57:36 +0200 Received: from ccrle.nec.de (elgar.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 6E7CA1488B; Thu, 4 Apr 2002 15:57:36 +0200 (CEST) Message-ID: <3CAC5BDF.7040700@ccrle.nec.de> Date: Thu, 04 Apr 2002 15:57:51 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20020305 X-Accept-Language: en-us MIME-Version: 1.0 To: Tom-PT Taylor Cc: midcom@ietf.org, Cedric Aoun Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content References: <4D79C746863DD51197690002A52CDA0001E8A229@zcard0kc.ca.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Hi, please find my comments embedded in the text. Regards Martin Tom-PT Taylor wrote: > This is the theoretical section of the I-D Cedric and I are working on. We > are still validating it against the various scenarios. > Yes, it is very theoretical. We should aviod such text for internet drafts, because a lot of people won't even continue reading the entire document. > 4 Structure And Comparison Of Policy Rules > > In this note, a Policy Rule is defined to be a set of terms of the form [...] > decide which action will apply in the region of overlap. By assumption, > these decision rules will be based on the combination of order of > specification and policy at the Middlebox. > > There are two possible cases: > > (1) The Policy Rule associated with each of the two {Filter, Action} pairs > must be installed completely or not at all. In this case, if there is a > conflict between the two rules in the zone of overlap, the lower-priority > Policy Rule will be disallowed (if it was the later arrival) or deactivated > (if it was already installed). This sounds very complicated and with a lot of administrative overhead. I prefer Jiri's idea of disallowing overlapping rules at all and using a first come, first served scheme, instead of priorities. Should there be any conflict, reject the latest policy rule request. > > (2) The Policy Rule which has lower priority in the zone of conflict allows > for partial implementation. Thus the desired {Filter, Action} pair is > modified to exclude the zone of overlap. There are two sub-cases: Hmm, how to tell the agent, that his rule request has been fulfilled only partial? My opinion is, that the agent wants exactly this policy rule and if he can't get this, tell him! _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 4 13:48:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03907 for ; Thu, 4 Apr 2002 13:48:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA23849 for midcom-archive@odin.ietf.org; Thu, 4 Apr 2002 13:48:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23688; Thu, 4 Apr 2002 13:45:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23661 for ; Thu, 4 Apr 2002 13:45:18 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03763 for ; Thu, 4 Apr 2002 13:45:15 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.198]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g34IjqTE028569; Thu, 4 Apr 2002 13:45:53 -0500 (EST) Message-ID: <3CAC9F18.B082DA04@dynamicsoft.com> Date: Thu, 04 Apr 2002 13:44:40 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pete Cordell CC: midcom@ietf.org References: <001a01c1db01$bb407b20$0200000a@tkw> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Re: Truncated STUN test Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Pete Cordell wrote: > > Jonathan, > > My understanding is that only NATs that exhibit cone NAT functionality > (which presumably includes 1-to-1 NAT) are useful for things like SIP. Thats not the case. Cone NATs are ideal, but it is possible to use SIP along with stun and get voip working when you have an restricted cone nat too. You'll need to prime the nat with "suicide" packets to open holes for the media from the peer. This is documented in draft-rosenberg-sipping-nat-scenarios-00.txt, page 13. > For > clients that are only interested in whether they can run VoIP (or > something > similar) knowing the various types of NAT is not really required. All > they > want is a go/no go decision on whether they can communicate through the > NAT. Fair enough. > > If that's the case it would be worth specifying a truncated STUN test > sequence that yields only this go/no go decision. > > That would seem to involve doing Test I on the set of SRV derived STUN > servers until one is found that works. You would then do a Test II. > Once > you have the result of that test, you can stop. Since it does work behind a restricted cone nat, you actually need to run the full sequence in any case, as far as I can tell. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 4 13:59:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04242 for ; Thu, 4 Apr 2002 13:59:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24542 for midcom-archive@odin.ietf.org; Thu, 4 Apr 2002 13:59:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24401; Thu, 4 Apr 2002 13:57:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24370 for ; Thu, 4 Apr 2002 13:57:11 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04167 for ; Thu, 4 Apr 2002 13:57:08 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g34IuWv27443; Thu, 4 Apr 2002 13:56:32 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Apr 2002 13:56:34 -0500 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A261@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Martin Stiemerling'" Cc: midcom@ietf.org, "Cedric Aoun" Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Thu, 4 Apr 2002 13:56:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DC0A.6C56891E" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DC0A.6C56891E Content-Type: text/plain; charset="iso-8859-1" That's two people so far who have said requests should be satisfied completely or not at all. Shall we take this as the working assumption? First-come-first-serve vs. policy hides another issue: how to allow multiple authorized agents to work on the same ruleset (requirement 2.2.7). Our proposals so far assumed this was handled through a policy mechanism. There is a distinction, of course, between two agents operating on the same Policy Rule Identifier (which is perhaps what 2.2.7 permits) and two agents defining identical rulesets with different Policy Rule Identifiers. So I have a couple of questions for the WG: 1) Does the protocol address the possibility of two agents defining overlapping rulesets and if so, are conflicts handled on a first-come-first-served basis? 2) Does the protocol need a formal delegation capability, so that Agent A can tell the Middlebox that Agent B can make requests affecting Policy Rule Identifier x? Here we would distinguish between sharing of authority (both Agent A and Agent B can manipulate the Policy Rule) vs. handoff (Agent A gives up its authority to Agent B). Which one might we want, if we want either? I visualize a message exchange of the form: Agent A Middlebox Agent B Grant(Policy Rule Id x, Agent B) -------------------------------> Notify (Grant, Policy Rule Id x) Grant Acknowledge ---------------------------> <------------------------------- Notify Acknowledge <--------------------------- Sorry about the really theoretical stuff -- it was something I had to think through clearly for myself, but I can see it wouldn't be generally helpful, so we can omit it or put it into an appendix. -----Original Message----- From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] Sent: Thursday, April 04, 2002 8:58 AM To: Taylor, Tom-PT [CAR:B800:EXCH] Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content Hi, please find my comments embedded in the text. Regards Martin Tom-PT Taylor wrote: > This is the theoretical section of the I-D Cedric and I are working on. We > are still validating it against the various scenarios. > Yes, it is very theoretical. We should aviod such text for internet drafts, because a lot of people won't even continue reading the entire document. > 4 Structure And Comparison Of Policy Rules > > In this note, a Policy Rule is defined to be a set of terms of the form [...] > decide which action will apply in the region of overlap. By assumption, > these decision rules will be based on the combination of order of > specification and policy at the Middlebox. > > There are two possible cases: > > (1) The Policy Rule associated with each of the two {Filter, Action} pairs > must be installed completely or not at all. In this case, if there is a > conflict between the two rules in the zone of overlap, the lower-priority > Policy Rule will be disallowed (if it was the later arrival) or deactivated > (if it was already installed). This sounds very complicated and with a lot of administrative overhead. I prefer Jiri's idea of disallowing overlapping rules at all and using a first come, first served scheme, instead of priorities. Should there be any conflict, reject the latest policy rule request. > > (2) The Policy Rule which has lower priority in the zone of conflict allows > for partial implementation. Thus the desired {Filter, Action} pair is > modified to exclude the zone of overlap. There are two sub-cases: Hmm, how to tell the agent, that his rule request has been fulfilled only partial? My opinion is, that the agent wants exactly this policy rule and if he can't get this, tell him! ------_=_NextPart_001_01C1DC0A.6C56891E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] MIDCOM SEmantics: Policy Rule Content

That's two people so far who have said requests = should be satisfied completely or not at all.  Shall we take this = as the working assumption?

First-come-first-serve vs. policy hides another = issue: how to allow multiple authorized agents to work on the same = ruleset (requirement 2.2.7).  Our proposals so far assumed this = was handled through a policy mechanism.  There is a distinction, = of course, between two agents operating on the same Policy Rule = Identifier (which is perhaps what 2.2.7 permits) and two agents = defining identical rulesets with different Policy Rule = Identifiers.  So I have a couple of questions for the = WG:

 1) Does the protocol address the possibility of = two agents defining overlapping rulesets and if so, are conflicts = handled on a first-come-first-served basis?

 2) Does the protocol need a formal delegation = capability, so that Agent A can tell the Middlebox that Agent B can = make requests affecting Policy Rule Identifier x?  Here we would = distinguish between sharing of authority (both Agent A and Agent B can = manipulate the Policy Rule) vs. handoff (Agent A gives up its authority = to Agent B).  Which one might we want, if we want either?  I = visualize a message exchange of the form:

    Agent = A            = ;         = Middlebox          &nb= sp;       Agent B

    Grant(Policy Rule Id x, Agent = B)
    = ------------------------------->
          &nb= sp;           &nb= sp;           &nb= sp;     Notify (Grant, Policy Rule Id x)
    Grant = Acknowledge          &= nbsp;    --------------------------->
    = <-------------------------------
          &nb= sp;           &nb= sp;           &nb= sp;     Notify Acknowledge
          &nb= sp;           &nb= sp;           &nb= sp; <---------------------------

Sorry about the really theoretical stuff -- it was = something I had to think through clearly for myself, but I can see it = wouldn't be generally helpful, so we can omit it or put it into an = appendix.

-----Original Message-----
From: Martin Stiemerling [mailto:Martin.Stiemerlin= g@ccrle.nec.de]
Sent: Thursday, April 04, 2002 8:58 AM
To: Taylor, Tom-PT [CAR:B800:EXCH]
Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH]
Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule = Content


Hi,

please find my comments embedded in the text.

Regards
Martin

Tom-PT Taylor wrote:

> This is the theoretical section of the I-D = Cedric and I are working on.  We
> are still validating it against the various = scenarios.
>


Yes, it is very theoretical. We should aviod such = text for internet
drafts, because a lot of people won't even continue = reading the entire
document.


> 4     Structure And = Comparison Of Policy Rules
>
> In this note, a Policy Rule is defined to be a = set of terms of the form


[...]


> decide which action will apply in the region of = overlap.  By assumption,
> these decision rules will be based on the = combination of order of
> specification and policy at the = Middlebox.
>
> There are two possible cases:
>
> (1) The Policy Rule associated with each of the = two {Filter, Action} pairs
> must be installed completely or not at = all.  In this case, if there is a
> conflict between the two rules in the zone of = overlap, the lower-priority
> Policy Rule will be disallowed (if it was the = later arrival) or deactivated
> (if it was already installed).


This sounds very complicated and with a lot of = administrative overhead.
I prefer Jiri's idea of disallowing overlapping = rules at all and using a
first come, first served scheme, instead of = priorities. Should there be
any conflict, reject the latest policy rule = request.


>
> (2) The Policy Rule which has lower priority in = the zone of conflict allows
> for partial implementation.  Thus the = desired {Filter, Action} pair is
> modified to exclude the zone of overlap.  = There are two sub-cases:


Hmm, how to tell the agent, that his rule request has = been fulfilled
only partial? My opinion is, that the agent wants = exactly this policy
rule and if he can't get this, tell him!


------_=_NextPart_001_01C1DC0A.6C56891E-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 4 14:21:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05047 for ; Thu, 4 Apr 2002 14:21:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA25962 for midcom-archive@odin.ietf.org; Thu, 4 Apr 2002 14:21:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25852; Thu, 4 Apr 2002 14:19:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25824 for ; Thu, 4 Apr 2002 14:19:16 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04961 for ; Thu, 4 Apr 2002 14:19:13 -0500 (EST) Received: from asimu-u5.cisco.com (asimu-u5.cisco.com [128.107.162.97]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g34JIcON014045; Thu, 4 Apr 2002 11:18:38 -0800 (PST) Received: from cisco.com (localhost [127.0.0.1]) by asimu-u5.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id LAA11246; Thu, 4 Apr 2002 11:18:38 -0800 (PST) Message-ID: <3CACA70E.1F52BFD3@cisco.com> Date: Thu, 04 Apr 2002 11:18:38 -0800 From: Adina Simu X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Tom-PT Taylor CC: "'Martin Stiemerling'" , midcom@ietf.org, Cedric Aoun Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content References: <4D79C746863DD51197690002A52CDA0001E8A261@zcard0kc.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Tom, > Tom-PT Taylor wrote: > > That's two people so far who have said requests should be satisfied > completely or not at all. Shall we take this as the working > assumption? I vote "yes". If an agent receives a negative answer to its request, it can try again, this time requesting a narrower ruleset. One idea would be to include some error codes in the response, to let the agent know if a narrower ruleset might be accepted. -Adina > > First-come-first-serve vs. policy hides another issue: how to allow > multiple authorized agents to work on the same ruleset (requirement > 2.2.7). Our proposals so far assumed this was handled through a > policy mechanism. There is a distinction, of course, between two > agents operating on the same Policy Rule Identifier (which is perhaps > what 2.2.7 permits) and two agents defining identical rulesets with > different Policy Rule Identifiers. So I have a couple of questions > for the WG: > > 1) Does the protocol address the possibility of two agents defining > overlapping rulesets and if so, are conflicts handled on a > first-come-first-served basis? > > 2) Does the protocol need a formal delegation capability, so that > Agent A can tell the Middlebox that Agent B can make requests > affecting Policy Rule Identifier x? Here we would distinguish between > sharing of authority (both Agent A and Agent B can manipulate the > Policy Rule) vs. handoff (Agent A gives up its authority to Agent B). > Which one might we want, if we want either? I visualize a message > exchange of the form: > > Agent A Middlebox Agent B > > Grant(Policy Rule Id x, Agent B) > -------------------------------> > Notify (Grant, Policy Rule Id > x) > Grant Acknowledge ---------------------------> > <------------------------------- > Notify Acknowledge > <--------------------------- > > Sorry about the really theoretical stuff -- it was something I had to > think through clearly for myself, but I can see it wouldn't be > generally helpful, so we can omit it or put it into an appendix. > > -----Original Message----- > From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] > Sent: Thursday, April 04, 2002 8:58 AM > To: Taylor, Tom-PT [CAR:B800:EXCH] > Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] > Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content > > Hi, > > please find my comments embedded in the text. > > Regards > Martin > > Tom-PT Taylor wrote: > > > This is the theoretical section of the I-D Cedric and I are working > on. We > > are still validating it against the various scenarios. > > > > Yes, it is very theoretical. We should aviod such text for internet > drafts, because a lot of people won't even continue reading the entire > > document. > > > 4 Structure And Comparison Of Policy Rules > > > > In this note, a Policy Rule is defined to be a set of terms of the > form > > [...] > > > decide which action will apply in the region of overlap. By > assumption, > > these decision rules will be based on the combination of order of > > specification and policy at the Middlebox. > > > > There are two possible cases: > > > > (1) The Policy Rule associated with each of the two {Filter, Action} > pairs > > must be installed completely or not at all. In this case, if there > is a > > conflict between the two rules in the zone of overlap, the > lower-priority > > Policy Rule will be disallowed (if it was the later arrival) or > deactivated > > (if it was already installed). > > This sounds very complicated and with a lot of administrative > overhead. > I prefer Jiri's idea of disallowing overlapping rules at all and using > a > first come, first served scheme, instead of priorities. Should there > be > any conflict, reject the latest policy rule request. > > > > > (2) The Policy Rule which has lower priority in the zone of conflict > allows > > for partial implementation. Thus the desired {Filter, Action} pair > is > > modified to exclude the zone of overlap. There are two sub-cases: > > Hmm, how to tell the agent, that his rule request has been fulfilled > only partial? My opinion is, that the agent wants exactly this policy > rule and if he can't get this, tell him! _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 4 17:22:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10976 for ; Thu, 4 Apr 2002 17:22:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA07016 for midcom-archive@odin.ietf.org; Thu, 4 Apr 2002 17:22:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06898; Thu, 4 Apr 2002 17:19:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06870 for ; Thu, 4 Apr 2002 17:19:14 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10942 for ; Thu, 4 Apr 2002 17:19:04 -0500 (EST) Received: from airborne.cisco.com (IDENT:mirapoint@airborne.cisco.com [171.71.154.32]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g34MIOCl000361 for ; Thu, 4 Apr 2002 14:18:24 -0800 (PST) Received: from SBRIM-W2K (rtp-vpn2-246.cisco.com [10.82.240.246]) by airborne.cisco.com (Mirapoint) with SMTP id AAY02207; Thu, 4 Apr 2002 14:18:24 -0800 (PST) Received: by SBRIM-W2K (sSMTP sendmail emulation); Thu, 4 Apr 2002 17:18:35 -0500 Date: Thu, 4 Apr 2002 17:18:35 -0500 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content Message-ID: <20020404171835.U1948@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <4D79C746863DD51197690002A52CDA0001E8A261@zcard0kc.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4D79C746863DD51197690002A52CDA0001E8A261@zcard0kc.ca.nortel.com>; from taylor@nortelnetworks.com on Thu, Apr 04, 2002 at 01:56:30PM -0500 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Thu, Apr 04, 2002 01:56:30PM -0500, Tom-PT Taylor wrote: > That's two people so far who have said requests should be satisfied > completely or not at all. Shall we take this as the working assumption? I think so too. You could have a flag saying partial fulfillment is allowed. However, it would be very good to keep the midcom protocol lean and mean. If a request is not atomic and can be partially fulfilled, then it can be broken up into independent requests as well. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 4 17:37:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11473 for ; Thu, 4 Apr 2002 17:37:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA08109 for midcom-archive@odin.ietf.org; Thu, 4 Apr 2002 17:37:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07906; Thu, 4 Apr 2002 17:33:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07821 for ; Thu, 4 Apr 2002 17:32:55 -0500 (EST) Received: from zsc3s004.us.nortel.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11270 for ; Thu, 4 Apr 2002 17:32:42 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g34MW9623047; Thu, 4 Apr 2002 14:32:10 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2JTCTKCC>; Thu, 4 Apr 2002 16:27:44 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E01187A34@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Jiri Kuthan'" , "Tom-PT Taylor", midcom@ietf.org Cc: "Cedric Aoun" Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Thu, 4 Apr 2002 16:27:47 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DC27.F2A8AB60" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DC27.F2A8AB60 Content-Type: text/plain; charset="iso-8859-1" How will then the following requirement from Midcom requirements draft be satisfied? ***** 2.2.11. It should be possible to define rulesets that contain a more spe- cific filter spec than an overlapping ruleset. This should allow agents to request actions for the subset that contradict those of the overlapping set. ***** Whether you want it or not, there would be overlapping rulesets because the filterspec may overlap for different rulesets installed by independent agents. The question - who wins when there're contradictory actions is moot because the requirement above seems to suggest that we need to allow contradictory behavior. Any comments? Sanjoy > -----Original Message----- > From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de] > Sent: Wednesday, April 03, 2002 5:57 AM > To: Taylor, Tom-PT [CAR:B800:EXCH]; midcom@ietf.org > Cc: Aoun, Cedric [QPD:MA01:EXCH] > Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content > > > Tom-PT, > > I'm glad midcom has gained momentum to focus on real things. > > As for the overlapping rules: I'm very much in favor of the approach > #1, i.e., disallowing overlapping rules. I think MidCom's primary > purpose is to get apps over NATs/FWs for which this is good enough. > It is not good enough for a FW/NAT mgmt protocol, but that is not > what we are concerned with. Allowing overlapping rules would result > in unnecessarily higher complexity of midcom servers. Simple is good. > > Rather then priorities, I would prefer to use first-come, > first-served > conflict resolution then. > > -Jiri > > >There are two possible cases: > > > >(1) The Policy Rule associated with each of the two {Filter, > Action} pairs > >must be installed completely or not at all. In this case, > if there is a > >conflict between the two rules in the zone of overlap, the > lower-priority > >Policy Rule will be disallowed (if it was the later arrival) > or deactivated > >(if it was already installed). > > > >(2) The Policy Rule which has lower priority in the zone of > conflict allows > >for partial implementation. Thus the desired {Filter, > Action} pair is > >modified to exclude the zone of overlap. There are two sub-cases: > > > >(a) In the simpler case, the exclusion of the zone of > overlap still leaves a > >box in N-space. This is true of Filter 2 in the diagram. > In this case, the > >original {Filter, Action} pair is replaced by another > {Filter', Action} pair > >where Filter' defines the region outside the zone of overlap. > > > >(b) In the more complex case, the exclusion of the zone of > overlap leaves a > >complex region rather than a simple box. This is true of > Filter 1 in the > >above diagram. In this case, the region can be partitioned > into a set of up > >to 2N simple boxes in N-space. Thus the canonical outcome > of the conflict > >with respect to the original {Filter, Action} pair is a set > of {Filter, > >Action} pairs where Action is the same as in the original pair. > > > >Policy rules are evaluated for conflict through a pairwise > comparison of > >their individual {Filter, Action} components. > > > >Let us turn now to the detailed semantic content of the > {Filter, Action} > >pairs. As the examples of section 4 illustrate, it is > possible to represent > >NAT and firewall policies using sets of uni-directional > filters of the form > > > >{, , Address-Port>, > >Protocol} > > > >with suitable wildcarding. Each Address-Port term has the > detailed form > >{Address, Port, Realm}. Two wildcards are needed: > > > > - ANY is a placeholder for a value to be bound when a flow > instance is > >matched against the Policy Rule. > > > > - CHOOSE is a value to be assigned by the Middlebox at Policy Rule > >installation time. That is, each CHOOSE in a Policy Rule > Request must be > >replaced by a specific value in a Policy Rule Response. > CHOOSE must only be > >used for components of . > > > >Our requirements indicate the need for two additional items. > It must be > >possible on occasion for the filter to specify a range of > ports rather than > >a single port. Moreover, it must be possible to constrain > the parity of the > >Map port assignment(s). These requirements are satisfied by > adding three > >modifiers to the port components of the filter: > > > > - the Count modifier is an integer from 1 upwards. If it > is included in a > >port component, it indicates that a range of ports is > requested. If the > >filter provides a specific value rather than a wildcard for > the port in > >question, the port assignments begin with that value. If > Count is absent, > >only one port is indicated. > > > > - the Step modifier must not be present unless the Count > modifier is also > >present. It is an integer from 1 upwards indicating the > increment to be > >applied in determining port numbers for a port number range. > One example of > >when Step would be needed is when allocating RTP or RTCP > ports for layered > >encoding. In this example, Step would have value 2. The > default if Step is > >absent is an increment of 1. > > > > - the Parity modifier has values Odd or Even. If it is > included in a port > >component, it indicates that the port (or the first port of > a range) must > >have the given parity. If Parity is not specified, port > assignment is > >unconstrained. > > > >Tom Taylor > >taylor@nortelnetworks.com > >Ph. +1 613 736 0961 (ESN 396 1490) > > > > > >_______________________________________________ > >midcom mailing list > >midcom@ietf.org > >https://www1.ietf.org/mailman/listinfo/midcom > > > >_______________________________________________ > >midcom mailing list > >midcom@ietf.org > >https://www1.ietf.org/mailman/listinfo/midcom > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C1DC27.F2A8AB60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] MIDCOM SEmantics: Policy Rule Content

How will then the following requirement from Midcom = requirements draft be satisfied?
*****
2.2.11.

     It should be possible to = define rulesets that contain a more spe-
     cific filter spec than an = overlapping ruleset.  This should allow
     agents to request actions = for the subset that contradict those of
     the overlapping set.
*****

Whether you want it or not, there would be = overlapping rulesets because the filterspec may overlap for different = rulesets installed by independent agents. The question - who wins when = there're contradictory actions is moot because the requirement above = seems to suggest that we need to allow contradictory = behavior.

Any comments?

Sanjoy



> -----Original Message-----
> From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de]
> Sent: Wednesday, April 03, 2002 5:57 AM
> To: Taylor, Tom-PT [CAR:B800:EXCH]; = midcom@ietf.org
> Cc: Aoun, Cedric [QPD:MA01:EXCH]
> Subject: RE: [midcom] MIDCOM SEmantics: Policy = Rule Content
>
>
> Tom-PT,
>
> I'm glad midcom has gained momentum to focus on = real things.
>
> As for the overlapping rules: I'm very much in = favor of the approach
> #1, i.e., disallowing overlapping rules. I = think MidCom's primary
> purpose is to get apps over NATs/FWs for which = this is good enough.
> It is not good enough for a FW/NAT mgmt = protocol, but that is not
> what we are concerned with. Allowing = overlapping rules would result
> in unnecessarily higher complexity of midcom = servers. Simple is good.
>
> Rather then priorities, I would prefer to use = first-come,
> first-served
> conflict resolution then.
>
> -Jiri
>
> >There are two possible cases:
> >
> >(1) The Policy Rule associated with each of = the two {Filter,
> Action} pairs
> >must be installed completely or not at = all.  In this case,
> if there is a
> >conflict between the two rules in the zone = of overlap, the
> lower-priority
> >Policy Rule will be disallowed (if it was = the later arrival)
> or deactivated
> >(if it was already installed).
> >
> >(2) The Policy Rule which has lower = priority in the zone of
> conflict allows
> >for partial implementation.  Thus the = desired {Filter,
> Action} pair is
> >modified to exclude the zone of = overlap.  There are two sub-cases:
> >
> >(a) In the simpler case, the exclusion of = the zone of
> overlap still leaves a
> >box in N-space.  This is true of = Filter 2 in the diagram. 
> In this case, the
> >original {Filter, Action} pair is replaced = by another
> {Filter', Action} pair
> >where Filter' defines the region outside = the zone of overlap.
> >
> >(b) In the more complex case, the exclusion = of the zone of
> overlap leaves a
> >complex region rather than a simple = box.  This is true of
> Filter 1 in the
> >above diagram.  In this case, the = region can be partitioned
> into a set of up
> >to 2N simple boxes in N-space.  Thus = the canonical outcome
> of the conflict
> >with respect to the original {Filter, = Action} pair is a set
> of {Filter,
> >Action} pairs where Action is the same as = in the original pair.
> >
> >Policy rules are evaluated for conflict = through a pairwise
> comparison of
> >their individual {Filter, Action} = components.
> >
> >Let us turn now to the detailed semantic = content of the
> {Filter, Action}
> >pairs.  As the examples of section 4 = illustrate, it is
> possible to represent
> >NAT and firewall policies using sets of = uni-directional
> filters of the form
> >
> >{<Source Address-Port>, <Map = Address-Port>, <Destination
> Address-Port>,
> >Protocol}
> >
> >with suitable wildcarding.  Each = Address-Port term has the
> detailed form
> >{Address, Port, Realm}.  Two wildcards = are needed:
> >
> > - ANY is a placeholder for a value to be = bound when a flow
> instance is
> >matched against the Policy Rule.
> >
> > - CHOOSE is a value to be assigned by the = Middlebox at Policy Rule
> >installation time.  That is, each = CHOOSE in a Policy Rule
> Request must be
> >replaced by a specific value in a Policy = Rule Response. 
> CHOOSE must only be
> >used for components of <Map = Address-Port>.
> >
> >Our requirements indicate the need for two = additional items.
>  It must be
> >possible on occasion for the filter to = specify a range of
> ports rather than
> >a single port.  Moreover, it must be = possible to constrain
> the parity of the
> >Map port assignment(s).  These = requirements are satisfied by
> adding three
> >modifiers to the port components of the = filter:
> >
> > - the Count modifier is an integer from 1 = upwards.  If it
> is included in a
> >port component, it indicates that a range = of ports is
> requested.  If the
> >filter provides a specific value rather = than a wildcard for
> the port in
> >question, the port assignments begin with = that value.  If
> Count is absent,
> >only one port is indicated.
> >
> > - the Step modifier must not be present = unless the Count
> modifier is also
> >present.  It is an integer from 1 = upwards indicating the
> increment to be
> >applied in determining port numbers for a = port number range.
>  One example of
> >when Step would be needed is when = allocating RTP or RTCP
> ports for layered
> >encoding.  In this example, Step would = have value 2.  The
> default if Step is
> >absent is an increment of 1.
> >
> > - the Parity modifier has values Odd or = Even.  If it is
> included in a port
> >component, it indicates that the port (or = the first port of
> a range) must
> >have the given parity.  If Parity is = not specified, port
> assignment is
> >unconstrained.
> >
> >Tom Taylor
> >taylor@nortelnetworks.com
> >Ph. +1 613 736 0961 (ESN 396 1490)
> >
> >
> = >_______________________________________________
> >midcom mailing list
> >midcom@ietf.org
> >https://www1.ietf.org/mailman/listinfo/midcom
> >
> = >_______________________________________________
> >midcom mailing list
> >midcom@ietf.org
> >https://www1.ietf.org/mailman/listinfo/midcom =
>
>
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C1DC27.F2A8AB60-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 4 17:57:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11931 for ; Thu, 4 Apr 2002 17:57:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA08796 for midcom-archive@odin.ietf.org; Thu, 4 Apr 2002 17:57:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08721; Thu, 4 Apr 2002 17:55:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08692 for ; Thu, 4 Apr 2002 17:55:43 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11907 for ; Thu, 4 Apr 2002 17:55:38 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g34Mt2P14288; Thu, 4 Apr 2002 17:55:02 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Apr 2002 17:55:05 -0500 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A264@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "Sanjoy Sen", "'Jiri Kuthan'" , "'midcom@ietf.org'" Cc: "Cedric Aoun" Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Thu, 4 Apr 2002 17:55:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DC2B.655305AE" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DC2B.655305AE Content-Type: text/plain; charset="iso-8859-1" First, does the requirement have to be supported across different agents, or does it just apply to one agent? Secondly, could we consider the requirement fulfilled if both the broader and the narrower filter had to belong to the same Policy Rule? -----Original Message----- From: Sen, Sanjoy [NGC:B692:EXCH] Sent: Thursday, April 04, 2002 5:28 PM To: 'Jiri Kuthan'; Taylor, Tom-PT [CAR:B800:EXCH]; midcom@ietf.org Cc: Aoun, Cedric [QPD:MA01:EXCH] Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content How will then the following requirement from Midcom requirements draft be satisfied? ***** 2.2.11. It should be possible to define rulesets that contain a more spe- cific filter spec than an overlapping ruleset. This should allow agents to request actions for the subset that contradict those of the overlapping set. ***** Whether you want it or not, there would be overlapping rulesets because the filterspec may overlap for different rulesets installed by independent agents. The question - who wins when there're contradictory actions is moot because the requirement above seems to suggest that we need to allow contradictory behavior. Any comments? Sanjoy > -----Original Message----- > From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de] > Sent: Wednesday, April 03, 2002 5:57 AM > To: Taylor, Tom-PT [CAR:B800:EXCH]; midcom@ietf.org > Cc: Aoun, Cedric [QPD:MA01:EXCH] > Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content > > > Tom-PT, > > I'm glad midcom has gained momentum to focus on real things. > > As for the overlapping rules: I'm very much in favor of the approach > #1, i.e., disallowing overlapping rules. I think MidCom's primary > purpose is to get apps over NATs/FWs for which this is good enough. > It is not good enough for a FW/NAT mgmt protocol, but that is not > what we are concerned with. Allowing overlapping rules would result > in unnecessarily higher complexity of midcom servers. Simple is good. > > Rather then priorities, I would prefer to use first-come, > first-served > conflict resolution then. > > -Jiri > > >There are two possible cases: > > > >(1) The Policy Rule associated with each of the two {Filter, > Action} pairs > >must be installed completely or not at all. In this case, > if there is a > >conflict between the two rules in the zone of overlap, the > lower-priority > >Policy Rule will be disallowed (if it was the later arrival) > or deactivated > >(if it was already installed). > > > >(2) The Policy Rule which has lower priority in the zone of > conflict allows > >for partial implementation. Thus the desired {Filter, > Action} pair is > >modified to exclude the zone of overlap. There are two sub-cases: > > > >(a) In the simpler case, the exclusion of the zone of > overlap still leaves a > >box in N-space. This is true of Filter 2 in the diagram. > In this case, the > >original {Filter, Action} pair is replaced by another > {Filter', Action} pair > >where Filter' defines the region outside the zone of overlap. > > > >(b) In the more complex case, the exclusion of the zone of > overlap leaves a > >complex region rather than a simple box. This is true of > Filter 1 in the > >above diagram. In this case, the region can be partitioned > into a set of up > >to 2N simple boxes in N-space. Thus the canonical outcome > of the conflict > >with respect to the original {Filter, Action} pair is a set > of {Filter, > >Action} pairs where Action is the same as in the original pair. > > > >Policy rules are evaluated for conflict through a pairwise > comparison of > >their individual {Filter, Action} components. > > > >Let us turn now to the detailed semantic content of the > {Filter, Action} > >pairs. As the examples of section 4 illustrate, it is > possible to represent > >NAT and firewall policies using sets of uni-directional > filters of the form > > > >{, , Address-Port>, > >Protocol} > > > >with suitable wildcarding. Each Address-Port term has the > detailed form > >{Address, Port, Realm}. Two wildcards are needed: > > > > - ANY is a placeholder for a value to be bound when a flow > instance is > >matched against the Policy Rule. > > > > - CHOOSE is a value to be assigned by the Middlebox at Policy Rule > >installation time. That is, each CHOOSE in a Policy Rule > Request must be > >replaced by a specific value in a Policy Rule Response. > CHOOSE must only be > >used for components of . > > > >Our requirements indicate the need for two additional items. > It must be > >possible on occasion for the filter to specify a range of > ports rather than > >a single port. Moreover, it must be possible to constrain > the parity of the > >Map port assignment(s). These requirements are satisfied by > adding three > >modifiers to the port components of the filter: > > > > - the Count modifier is an integer from 1 upwards. If it > is included in a > >port component, it indicates that a range of ports is > requested. If the > >filter provides a specific value rather than a wildcard for > the port in > >question, the port assignments begin with that value. If > Count is absent, > >only one port is indicated. > > > > - the Step modifier must not be present unless the Count > modifier is also > >present. It is an integer from 1 upwards indicating the > increment to be > >applied in determining port numbers for a port number range. > One example of > >when Step would be needed is when allocating RTP or RTCP > ports for layered > >encoding. In this example, Step would have value 2. The > default if Step is > >absent is an increment of 1. > > > > - the Parity modifier has values Odd or Even. If it is > included in a port > >component, it indicates that the port (or the first port of > a range) must > >have the given parity. If Parity is not specified, port > assignment is > >unconstrained. > > > >Tom Taylor > >taylor@nortelnetworks.com > >Ph. +1 613 736 0961 (ESN 396 1490) > > > > > >_______________________________________________ > >midcom mailing list > >midcom@ietf.org > >https://www1.ietf.org/mailman/listinfo/midcom > > > >_______________________________________________ > >midcom mailing list > >midcom@ietf.org > >https://www1.ietf.org/mailman/listinfo/midcom > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C1DC2B.655305AE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] MIDCOM SEmantics: Policy Rule Content

First, does the requirement have to be supported = across different agents, or does it just apply to one agent?  = Secondly, could we consider the requirement fulfilled if both the = broader and the narrower filter had to belong to the same Policy = Rule?

-----Original Message-----
From: Sen, Sanjoy [NGC:B692:EXCH]
Sent: Thursday, April 04, 2002 5:28 PM
To: 'Jiri Kuthan'; Taylor, Tom-PT [CAR:B800:EXCH]; = midcom@ietf.org
Cc: Aoun, Cedric [QPD:MA01:EXCH]
Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule = Content


How will then the following requirement from Midcom = requirements draft be satisfied?
*****
2.2.11.

     It should be possible to = define rulesets that contain a more spe-
     cific filter spec than an = overlapping ruleset.  This should allow
     agents to request actions = for the subset that contradict those of
     the overlapping set.
*****

Whether you want it or not, there would be = overlapping rulesets because the filterspec may overlap for different = rulesets installed by independent agents. The question - who wins when = there're contradictory actions is moot because the requirement above = seems to suggest that we need to allow contradictory = behavior.

Any comments?

Sanjoy



> -----Original Message-----
> From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de]
> Sent: Wednesday, April 03, 2002 5:57 AM
> To: Taylor, Tom-PT [CAR:B800:EXCH]; = midcom@ietf.org
> Cc: Aoun, Cedric [QPD:MA01:EXCH]
> Subject: RE: [midcom] MIDCOM SEmantics: Policy = Rule Content
>
>
> Tom-PT,
>
> I'm glad midcom has gained momentum to focus on = real things.
>
> As for the overlapping rules: I'm very much in = favor of the approach
> #1, i.e., disallowing overlapping rules. I = think MidCom's primary
> purpose is to get apps over NATs/FWs for which = this is good enough.
> It is not good enough for a FW/NAT mgmt = protocol, but that is not
> what we are concerned with. Allowing = overlapping rules would result
> in unnecessarily higher complexity of midcom = servers. Simple is good.
>
> Rather then priorities, I would prefer to use = first-come,
> first-served
> conflict resolution then.
>
> -Jiri
>
> >There are two possible cases:
> >
> >(1) The Policy Rule associated with each of = the two {Filter,
> Action} pairs
> >must be installed completely or not at = all.  In this case,
> if there is a
> >conflict between the two rules in the zone = of overlap, the
> lower-priority
> >Policy Rule will be disallowed (if it was = the later arrival)
> or deactivated
> >(if it was already installed).
> >
> >(2) The Policy Rule which has lower = priority in the zone of
> conflict allows
> >for partial implementation.  Thus the = desired {Filter,
> Action} pair is
> >modified to exclude the zone of = overlap.  There are two sub-cases:
> >
> >(a) In the simpler case, the exclusion of = the zone of
> overlap still leaves a
> >box in N-space.  This is true of = Filter 2 in the diagram. 
> In this case, the
> >original {Filter, Action} pair is replaced = by another
> {Filter', Action} pair
> >where Filter' defines the region outside = the zone of overlap.
> >
> >(b) In the more complex case, the exclusion = of the zone of
> overlap leaves a
> >complex region rather than a simple = box.  This is true of
> Filter 1 in the
> >above diagram.  In this case, the = region can be partitioned
> into a set of up
> >to 2N simple boxes in N-space.  Thus = the canonical outcome
> of the conflict
> >with respect to the original {Filter, = Action} pair is a set
> of {Filter,
> >Action} pairs where Action is the same as = in the original pair.
> >
> >Policy rules are evaluated for conflict = through a pairwise
> comparison of
> >their individual {Filter, Action} = components.
> >
> >Let us turn now to the detailed semantic = content of the
> {Filter, Action}
> >pairs.  As the examples of section 4 = illustrate, it is
> possible to represent
> >NAT and firewall policies using sets of = uni-directional
> filters of the form
> >
> >{<Source Address-Port>, <Map = Address-Port>, <Destination
> Address-Port>,
> >Protocol}
> >
> >with suitable wildcarding.  Each = Address-Port term has the
> detailed form
> >{Address, Port, Realm}.  Two wildcards = are needed:
> >
> > - ANY is a placeholder for a value to be = bound when a flow
> instance is
> >matched against the Policy Rule.
> >
> > - CHOOSE is a value to be assigned by the = Middlebox at Policy Rule
> >installation time.  That is, each CHOOS= E in a Policy Rule
> Request must be
> >replaced by a specific value in a Policy = Rule Response. 
> CHOOSE must only be
> >used for components of <Map = Address-Port>.
> >
> >Our requirements indicate the need for two = additional items.
>  It must be
> >possible on occasion for the filter to = specify a range of
> ports rather than
> >a single port.  Moreover, it must be = possible to constrain
> the parity of the
> >Map port assignment(s).  These = requirements are satisfied by
> adding three
> >modifiers to the port components of the = filter:
> >
> > - the Count modifier is an integer from 1 = upwards.  If it
> is included in a
> >port component, it indicates that a range = of ports is
> requested.  If the
> >filter provides a specific value rather = than a wildcard for
> the port in
> >question, the port assignments begin with = that value.  If
> Count is absent,
> >only one port is indicated.
> >
> > - the Step modifier must not be present = unless the Count
> modifier is also
> >present.  It is an integer from 1 = upwards indicating the
> increment to be
> >applied in determining port numbers for a = port number range.
>  One example of
> >when Step would be needed is when = allocating RTP or RTCP
> ports for layered
> >encoding.  In this example, Step would = have value 2.  The
> default if Step is
> >absent is an increment of 1.
> >
> > - the Parity modifier has values Odd or = Even.  If it is
> included in a port
> >component, it indicates that the port (or = the first port of
> a range) must
> >have the given parity.  If Parity is = not specified, port
> assignment is
> >unconstrained.
> >
> >Tom Taylor
> >taylor@nortelnetworks.com
> >Ph. +1 613 736 0961 (ESN 396 1490)
> >
> >
> = >_______________________________________________
> >midcom mailing list
> >midcom@ietf.org
> >https://www1.ietf.org/mailman/listinfo/midcom
> >
> = >_______________________________________________
> >midcom mailing list
> >midcom@ietf.org
> >https://www1.ietf.org/mailman/listinfo/midcom =
>
>
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C1DC2B.655305AE-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 4 18:06:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12164 for ; Thu, 4 Apr 2002 18:06:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA09590 for midcom-archive@odin.ietf.org; Thu, 4 Apr 2002 18:06:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09479; Thu, 4 Apr 2002 18:05:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09448 for ; Thu, 4 Apr 2002 18:05:05 -0500 (EST) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12132 for ; Thu, 4 Apr 2002 18:05:00 -0500 (EST) Received: from jku2.fokus.gmd.de (dhcp218.fokus.gmd.de [195.37.78.218]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g34N5bZ19938; Fri, 5 Apr 2002 01:05:38 +0200 Message-Id: <5.1.0.14.0.20020405005329.02163328@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 05 Apr 2002 01:04:10 +0200 To: "Sanjoy Sen", "Tom-PT Taylor", midcom@ietf.org From: Jiri Kuthan Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Cc: "Cedric Aoun" In-Reply-To: <933FADF5E673D411B8A30002A5608A0E01187A34@zrc2c012.us.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 12:27 AM 4/5/2002, Sanjoy Sen wrote: >How will then the following requirement from Midcom requirements draft be satisfied? Perhaps by reading "should" as "there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." (RFC2119). >***** >2.2.11. > > It should be possible to define rulesets that contain a more spe- > cific filter spec than an overlapping ruleset. This should allow > agents to request actions for the subset that contradict those of > the overlapping set. >***** > >Whether you want it or not, there would be overlapping rulesets because the filterspec may overlap for different rulesets installed by independent agents. Why? Again, thats a matter of protocol scope. If we define MidCom to be firewall/NAT opener, then overlaps are errors and can be as such denied. If we define it as a management protocol, things are different -- but MidCom is not a management protocol. Whereas some people may like extending its scope, I am in favor of keeping things very simple. -Jiri _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 4 18:07:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12180 for ; Thu, 4 Apr 2002 18:07:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA09608 for midcom-archive@odin.ietf.org; Thu, 4 Apr 2002 18:07:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09572; Thu, 4 Apr 2002 18:05:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09488 for ; Thu, 4 Apr 2002 18:05:30 -0500 (EST) Received: from zsc3s004.us.nortel.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12142 for ; Thu, 4 Apr 2002 18:05:25 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g34N4j626172; Thu, 4 Apr 2002 15:04:49 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2JTCTK6P>; Thu, 4 Apr 2002 17:04:43 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E01187A37@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "Tom-PT Taylor", "'Martin Stiemerling'" Cc: midcom@ietf.org, "Cedric Aoun" Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Thu, 4 Apr 2002 17:04:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DC2D.1BA80600" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DC2D.1BA80600 Content-Type: text/plain; charset="iso-8859-1" Inline. -----Original Message----- From: Taylor, Tom-PT [CAR:B800:EXCH] Sent: Thursday, April 04, 2002 12:57 PM To: 'Martin Stiemerling' Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content That's two people so far who have said requests should be satisfied completely or not at all. Shall we take this as the working assumption? First-come-first-serve vs. policy hides another issue: how to allow multiple authorized agents to work on the same ruleset (requirement 2.2.7). Our proposals so far assumed this was handled through a policy mechanism. There is a distinction, of course, between two agents operating on the same Policy Rule Identifier (which is perhaps what 2.2.7 permits) and two agents defining identical rulesets with different Policy Rule Identifiers. So I have a couple of questions for the WG: 1) Does the protocol address the possibility of two agents defining overlapping rulesets and if so, are conflicts handled on a first-come-first-served basis? [SS] The protocol has to allow overlapping rulesets because multiple agents are installing rulesets independently and there're bound to be overlaps in, say, the filter spec. Question is, what happens when there is a contradiction. Requirement 2.2.11 seems to suggest that we need to allow the later agent to win, at least, under special circumstances. For example, a Midcom agent installs a ruleset allowing packets from the address range 100.10.*.* to pass through, but at a later time, the firewall administrator wants to create a ruleset disallowing packets from 100.10.50.10. I would like to think that the firewall administrator would have the last say. An administrator Agent has the highest priority. IMO, an Agent priority list makes sense, with an agent higher up in the priority list can modify/revoke rulesets created by lower priority agents. For agents of same priority, a first-come-first-serve approach may be more suitable. 2) Does the protocol need a formal delegation capability, so that Agent A can tell the Middlebox that Agent B can make requests affecting Policy Rule Identifier x? Here we would distinguish between sharing of authority (both Agent A and Agent B can manipulate the Policy Rule) vs. handoff (Agent A gives up its authority to Agent B). Which one might we want, if we want either? I visualize a message exchange of the form: [SS] Since we're requiring the Middlebox to report unsolicitated messages to the Agent, we can do this in another way. When there is an attempt by Agent B to install a ruleset which overlaps with and has contradictory action(s) to one that has been installed by Agent A, then the Middlebox can send a notification message reporting this event to A with Agent B's id. Agent A may or may not allow this. If disallowed, the Middlebox may either reject B's request to install or suggests an alternative/modified ruleset by sending B an error message. Agent A Middlebox Agent B Grant(Policy Rule Id x, Agent B) -------------------------------> Notify (Grant, Policy Rule Id x) Grant Acknowledge ---------------------------> <------------------------------- Notify Acknowledge <--------------------------- Sorry about the really theoretical stuff -- it was something I had to think through clearly for myself, but I can see it wouldn't be generally helpful, so we can omit it or put it into an appendix. -----Original Message----- From: Martin Stiemerling [ mailto:Martin.Stiemerling@ccrle.nec.de ] Sent: Thursday, April 04, 2002 8:58 AM To: Taylor, Tom-PT [CAR:B800:EXCH] Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content Hi, please find my comments embedded in the text. Regards Martin Tom-PT Taylor wrote: > This is the theoretical section of the I-D Cedric and I are working on. We > are still validating it against the various scenarios. > Yes, it is very theoretical. We should aviod such text for internet drafts, because a lot of people won't even continue reading the entire document. > 4 Structure And Comparison Of Policy Rules > > In this note, a Policy Rule is defined to be a set of terms of the form [...] > decide which action will apply in the region of overlap. By assumption, > these decision rules will be based on the combination of order of > specification and policy at the Middlebox. > > There are two possible cases: > > (1) The Policy Rule associated with each of the two {Filter, Action} pairs > must be installed completely or not at all. In this case, if there is a > conflict between the two rules in the zone of overlap, the lower-priority > Policy Rule will be disallowed (if it was the later arrival) or deactivated > (if it was already installed). This sounds very complicated and with a lot of administrative overhead. I prefer Jiri's idea of disallowing overlapping rules at all and using a first come, first served scheme, instead of priorities. Should there be any conflict, reject the latest policy rule request. > > (2) The Policy Rule which has lower priority in the zone of conflict allows > for partial implementation. Thus the desired {Filter, Action} pair is > modified to exclude the zone of overlap. There are two sub-cases: Hmm, how to tell the agent, that his rule request has been fulfilled only partial? My opinion is, that the agent wants exactly this policy rule and if he can't get this, tell him! ------_=_NextPart_001_01C1DC2D.1BA80600 Content-Type: text/html; charset="iso-8859-1" RE: [midcom] MIDCOM SEmantics: Policy Rule Content
Inline.
-----Original Message-----
From: Taylor, Tom-PT [CAR:B800:EXCH]
Sent: Thursday, April 04, 2002 12:57 PM
To: 'Martin Stiemerling'
Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH]
Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content

That's two people so far who have said requests should be satisfied completely or not at all.  Shall we take this as the working assumption?

First-come-first-serve vs. policy hides another issue: how to allow multiple authorized agents to work on the same ruleset (requirement 2.2.7).  Our proposals so far assumed this was handled through a policy mechanism.  There is a distinction, of course, between two agents operating on the same Policy Rule Identifier (which is perhaps what 2.2.7 permits) and two agents defining identical rulesets with different Policy Rule Identifiers.  So I have a couple of questions for the WG:

 1) Does the protocol address the possibility of two agents defining overlapping rulesets and if so, are conflicts handled on a first-come-first-served basis? 

[SS] The protocol has to allow overlapping rulesets because multiple agents are installing rulesets independently and there're bound to be overlaps in, say, the filter spec.  Question is, what happens when there is a contradiction. Requirement 2.2.11 seems to suggest that we need to allow the later agent to win, at least, under special circumstances. For example, a Midcom agent installs a ruleset allowing packets from the address range 100.10.*.* to pass through, but at a later time, the firewall administrator wants to create a ruleset disallowing packets from 100.10.50.10. I would like to think that the firewall administrator would have the last say. An administrator Agent has the highest priority.

IMO, an Agent priority list makes sense, with an agent higher up in the priority list can modify/revoke rulesets created by lower priority agents. For agents of same priority, a first-come-first-serve approach may be more suitable.

 2) Does the protocol need a formal delegation capability, so that Agent A can tell the Middlebox that Agent B can make requests affecting Policy Rule Identifier x?  Here we would distinguish between sharing of authority (both Agent A and Agent B can manipulate the Policy Rule) vs. handoff (Agent A gives up its authority to Agent B).  Which one might we want, if we want either?  I visualize a message exchange of the form: 

[SS] Since we're requiring the Middlebox to report unsolicitated messages to the Agent, we can do this in another way. When there is an attempt by Agent B to install a ruleset which overlaps with and has contradictory action(s) to one that has been installed by Agent A, then the Middlebox can send a notification message reporting this event to A with Agent B's id. Agent A may or may not allow this. If disallowed, the Middlebox may either reject B's request to install or suggests an alternative/modified ruleset by sending B an error message.

    Agent A                     Middlebox                  Agent B

    Grant(Policy Rule Id x, Agent B)
    ------------------------------->
                                        Notify (Grant, Policy Rule Id x)
    Grant Acknowledge               --------------------------->
    <-------------------------------
                                        Notify Acknowledge
                                    <---------------------------

Sorry about the really theoretical stuff -- it was something I had to think through clearly for myself, but I can see it wouldn't be generally helpful, so we can omit it or put it into an appendix.

-----Original Message-----
From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de]
Sent: Thursday, April 04, 2002 8:58 AM
To: Taylor, Tom-PT [CAR:B800:EXCH]
Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH]
Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content


Hi,

please find my comments embedded in the text.

Regards
Martin

Tom-PT Taylor wrote:

> This is the theoretical section of the I-D Cedric and I are working on.  We
> are still validating it against the various scenarios.
>


Yes, it is very theoretical. We should aviod such text for internet
drafts, because a lot of people won't even continue reading the entire
document.


> 4     Structure And Comparison Of Policy Rules
>
> In this note, a Policy Rule is defined to be a set of terms of the form


[...]


> decide which action will apply in the region of overlap.  By assumption,
> these decision rules will be based on the combination of order of
> specification and policy at the Middlebox.
>
> There are two possible cases:
>
> (1) The Policy Rule associated with each of the two {Filter, Action} pairs
> must be installed completely or not at all.  In this case, if there is a
> conflict between the two rules in the zone of overlap, the lower-priority
> Policy Rule will be disallowed (if it was the later arrival) or deactivated
> (if it was already installed).


This sounds very complicated and with a lot of administrative overhead.
I prefer Jiri's idea of disallowing overlapping rules at all and using a
first come, first served scheme, instead of priorities. Should there be
any conflict, reject the latest policy rule request.


>
> (2) The Policy Rule which has lower priority in the zone of conflict allows
> for partial implementation.  Thus the desired {Filter, Action} pair is
> modified to exclude the zone of overlap.  There are two sub-cases:


Hmm, how to tell the agent, that his rule request has been fulfilled
only partial? My opinion is, that the agent wants exactly this policy
rule and if he can't get this, tell him!


------_=_NextPart_001_01C1DC2D.1BA80600-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 4 18:49:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12996 for ; Thu, 4 Apr 2002 18:49:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA11808 for midcom-archive@odin.ietf.org; Thu, 4 Apr 2002 18:49:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11638; Thu, 4 Apr 2002 18:47:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11611 for ; Thu, 4 Apr 2002 18:47:00 -0500 (EST) Received: from zsc3s004.us.nortel.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12951 for ; Thu, 4 Apr 2002 18:46:54 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g34NkN628366; Thu, 4 Apr 2002 15:46:23 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2JTCTLN5>; Thu, 4 Apr 2002 17:46:21 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E01187A38@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Jiri Kuthan'" , "Tom-PT Taylor", midcom@ietf.org Cc: "Cedric Aoun" Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Thu, 4 Apr 2002 17:46:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DC32.EC7C9E30" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DC32.EC7C9E30 Content-Type: text/plain; charset="iso-8859-1" Jiri, Why wouldn't a network/firewall administration application be able to use the same Midcom protocol for opening/closing firewall pinholes? Nothing in the charter says that this out of scope. Also, what you're suggesting may be too retrictive. I can't possibly assume that all NAT's & firewalls will be Midcom-enabled at the same time. So there might be a situation where a Midcom agent would like to open pinhole in a firewall which is sandwitched between two NAT's which are not Midcom-aware. The Agent doesn't have any idea about the exact NAT binds that will be used on both sides of the FW but knows about the range of possible binds. There'll be overlap in this case between rulesets of agents controlling the firewall. Sanjoy > -----Original Message----- > From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de] > Sent: Thursday, April 04, 2002 5:04 PM > To: Sen, Sanjoy [NGC:B692:EXCH]; Taylor, Tom-PT [CAR:B800:EXCH]; > midcom@ietf.org > Cc: Aoun, Cedric [QPD:MA01:EXCH] > Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content > > > At 12:27 AM 4/5/2002, Sanjoy Sen wrote: > >How will then the following requirement from Midcom > requirements draft be satisfied? > > Perhaps by reading "should" as "there may exist valid reasons > in particular > circumstances to ignore a particular item, but the full > implications must > be understood and carefully weighed before choosing a > different course." > (RFC2119). > > >***** > >2.2.11. > > > > It should be possible to define rulesets that contain a > more spe- > > cific filter spec than an overlapping ruleset. This > should allow > > agents to request actions for the subset that > contradict those of > > the overlapping set. > >***** > > > >Whether you want it or not, there would be overlapping > rulesets because the filterspec may overlap for different > rulesets installed by independent agents. > > Why? Again, thats a matter of protocol scope. If we define > MidCom to be > firewall/NAT opener, then overlaps are errors and can be as > such denied. > If we define it as a management protocol, things are different -- but > MidCom is not a management protocol. Whereas some people may like > extending its scope, I am in favor of keeping things very simple. > > -Jiri > > ------_=_NextPart_001_01C1DC32.EC7C9E30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] MIDCOM SEmantics: Policy Rule Content

Jiri,
  Why wouldn't a network/firewall = administration application be able to use the same Midcom protocol for = opening/closing firewall pinholes? Nothing in the charter says that = this out of scope.

Also, what you're suggesting may be too retrictive. I = can't possibly assume that all NAT's & firewalls will be = Midcom-enabled at the same time. So there might be a situation where a = Midcom agent would like to open pinhole in a firewall which is = sandwitched between two NAT's which are not Midcom-aware. The Agent = doesn't have any idea about the exact NAT binds that will be used on = both sides of the FW but knows about the range of possible binds. = There'll be overlap in this case between rulesets of agents controlling = the firewall.

Sanjoy


> -----Original Message-----
> From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de]
> Sent: Thursday, April 04, 2002 5:04 PM
> To: Sen, Sanjoy [NGC:B692:EXCH]; Taylor, Tom-PT = [CAR:B800:EXCH];
> midcom@ietf.org
> Cc: Aoun, Cedric [QPD:MA01:EXCH]
> Subject: RE: [midcom] MIDCOM SEmantics: Policy = Rule Content
>
>
> At 12:27 AM 4/5/2002, Sanjoy Sen wrote:
> >How will then the following requirement = from Midcom
> requirements draft be satisfied?
>
> Perhaps by reading "should" as = "there may exist valid reasons
> in particular
> circumstances to ignore a particular item, but = the full
> implications must
> be understood and carefully weighed before = choosing a
> different course."
> (RFC2119).
>
> >*****
> >2.2.11.
> >
> >     It should be = possible to define rulesets that contain a
> more spe-
> >     cific filter spec = than an overlapping ruleset.  This
> should allow
> >     agents to request = actions for the subset that
> contradict those of
> >     the overlapping = set.
> >*****
> >
> >Whether you want it or not, there would be = overlapping
> rulesets because the filterspec may overlap for = different
> rulesets installed by independent agents. =
>
> Why? Again, thats a matter of protocol scope. = If we define
> MidCom to be
> firewall/NAT opener, then overlaps are errors = and can be as
> such denied.
> If we define it as a management protocol, = things are different -- but
> MidCom is not a management protocol. Whereas = some people may like
> extending its scope, I am in favor of keeping = things very simple.
>
> -Jiri
>
>

------_=_NextPart_001_01C1DC32.EC7C9E30-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 4 20:05:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14417 for ; Thu, 4 Apr 2002 20:05:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA15958 for midcom-archive@odin.ietf.org; Thu, 4 Apr 2002 20:05:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA15880; Thu, 4 Apr 2002 20:02:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA15839 for ; Thu, 4 Apr 2002 20:02:05 -0500 (EST) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14378 for ; Thu, 4 Apr 2002 20:02:01 -0500 (EST) Received: from jku2.fokus.gmd.de (port-213-20-128-224.reverse.qdsl-home.de [213.20.128.224]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g3512rZ21593; Fri, 5 Apr 2002 03:02:54 +0200 Message-Id: <5.1.0.14.0.20020405024838.00b41468@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 05 Apr 2002 03:01:20 +0200 To: "Sanjoy Sen", "Tom-PT Taylor", midcom@ietf.org From: Jiri Kuthan Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Cc: "Cedric Aoun" In-Reply-To: <933FADF5E673D411B8A30002A5608A0E01187A38@zrc2c012.us.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 01:46 AM 4/5/2002, Sanjoy Sen wrote: >Jiri, > Why wouldn't a network/firewall administration application be able to use the same Midcom protocol for opening/closing firewall pinholes? Nothing in the charter says that this out of scope. Sanjoy, I think simplicity is good. If we focus on the issues which are indeed compelling we will have good chances to come out with a usable protocol. Building a management protocol is not precluded in charter, but it is neither stated there. That makes me think that management protocols are better discussed in a BOF in the management area. >Also, what you're suggesting may be too retrictive. I can't possibly assume that all NAT's & firewalls will be Midcom-enabled at the same time. So there might be a situation where a Midcom agent would like to open pinhole in a firewall which is sandwitched between two NAT's which are not Midcom-aware. The Agent doesn't have any idea about the exact NAT binds that will be used on both sides of the FW but knows about the range of possible binds. There'll be overlap in this case between rulesets of agents controlling the firewall. Well, I'm not sure whether we want to align midcom protocol design to such cumbersome scenarios. If so, it should be probably documented in the Midcom Scenarios I-D. -Jiri _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 4 21:04:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15018 for ; Thu, 4 Apr 2002 21:04:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA18696 for midcom-archive@odin.ietf.org; Thu, 4 Apr 2002 21:04:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA18326; Thu, 4 Apr 2002 21:00:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA18275 for ; Thu, 4 Apr 2002 21:00:36 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14978 for ; Thu, 4 Apr 2002 21:00:34 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g351xsQ25085; Thu, 4 Apr 2002 19:59:54 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2JXV2W4H>; Thu, 4 Apr 2002 19:59:58 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E01187A3A@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Jiri Kuthan'" , "Tom-PT Taylor", midcom@ietf.org Cc: "Cedric Aoun" Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Thu, 4 Apr 2002 20:00:01 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DC45.98898CD0" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DC45.98898CD0 Content-Type: text/plain; charset="iso-8859-1" I was just trying to point out that there may be situations where the Midcom Agent may not have complete knowledge of application endpoint addresses and would be forced to open a range of pinholes. > -----Original Message----- > From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de] > Sent: Thursday, April 04, 2002 7:01 PM > To: Sen, Sanjoy [NGC:B692:EXCH]; Taylor, Tom-PT [CAR:B800:EXCH]; > midcom@ietf.org > Cc: Aoun, Cedric [QPD:MA01:EXCH] > Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content > > > At 01:46 AM 4/5/2002, Sanjoy Sen wrote: > > >Jiri, > > Why wouldn't a network/firewall administration application > be able to use the same Midcom protocol for opening/closing > firewall pinholes? Nothing in the charter says that this out > of scope. > > Sanjoy, > > I think simplicity is good. If we focus on the issues which are indeed > compelling we will have good chances to come out with a > usable protocol. > Building a management protocol is not precluded in charter, but it is > neither stated there. That makes me think that management > protocols are > better discussed in a BOF in the management area. > > >Also, what you're suggesting may be too retrictive. I can't > possibly assume that all NAT's & firewalls will be > Midcom-enabled at the same time. So there might be a > situation where a Midcom agent would like to open pinhole in > a firewall which is sandwitched between two NAT's which are > not Midcom-aware. The Agent doesn't have any idea about the > exact NAT binds that will be used on both sides of the FW but > knows about the range of possible binds. There'll be overlap > in this case between rulesets of agents controlling the firewall. > > Well, I'm not sure whether we want to align midcom protocol > design to such > cumbersome scenarios. If so, it should be probably documented in the > Midcom Scenarios I-D. > > -Jiri > ------_=_NextPart_001_01C1DC45.98898CD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] MIDCOM SEmantics: Policy Rule Content

I was just trying to point out that there may be = situations where the Midcom Agent may not have complete knowledge of = application endpoint addresses and would be forced to open a range of = pinholes.

> -----Original Message-----
> From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de]
> Sent: Thursday, April 04, 2002 7:01 PM
> To: Sen, Sanjoy [NGC:B692:EXCH]; Taylor, Tom-PT = [CAR:B800:EXCH];
> midcom@ietf.org
> Cc: Aoun, Cedric [QPD:MA01:EXCH]
> Subject: RE: [midcom] MIDCOM SEmantics: Policy = Rule Content
>
>
> At 01:46 AM 4/5/2002, Sanjoy Sen wrote:
>
> >Jiri,
> >  Why wouldn't a network/firewall = administration application
> be able to use the same Midcom protocol for = opening/closing
> firewall pinholes? Nothing in the charter says = that this out
> of scope.
>
> Sanjoy,
>
> I think simplicity is good. If we focus on the = issues which are indeed
> compelling we will have good chances to come = out with a
> usable protocol.
> Building a management protocol is not precluded = in charter, but it is
> neither stated there. That makes me think that = management
> protocols are
> better discussed in a BOF in the management = area.
>
> >Also, what you're suggesting may be too = retrictive. I can't
> possibly assume that all NAT's & firewalls = will be
> Midcom-enabled at the same time. So there might = be a
> situation where a Midcom agent would like to = open pinhole in
> a firewall which is sandwitched between two = NAT's which are
> not Midcom-aware. The Agent doesn't have any = idea about the
> exact NAT binds that will be used on both sides = of the FW but
> knows about the range of possible binds. = There'll be overlap
> in this case between rulesets of agents = controlling the firewall.
>
> Well, I'm not sure whether we want to align = midcom protocol
> design to such
> cumbersome scenarios. If so, it should be = probably documented in the
> Midcom Scenarios I-D.
>
> -Jiri
>

------_=_NextPart_001_01C1DC45.98898CD0-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 4 22:24:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16762 for ; Thu, 4 Apr 2002 22:24:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA21772 for midcom-archive@odin.ietf.org; Thu, 4 Apr 2002 22:24:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA21719; Thu, 4 Apr 2002 22:22:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA21692 for ; Thu, 4 Apr 2002 22:22:55 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16755 for ; Thu, 4 Apr 2002 22:22:52 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g353M1Cl017020; Thu, 4 Apr 2002 19:22:01 -0800 (PST) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ACM88460; Thu, 4 Apr 2002 19:22:23 -0800 (PST) From: "Cullen Jennings" To: , "Pete Cordell" Cc: "Jonathan Rosenberg" Subject: RE: [midcom] Re: Truncated STUN test Date: Thu, 4 Apr 2002 19:24:59 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <3CAC9F18.B082DA04@dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit The open source implementation of STUN at http://www.polyphase.ca/software/stun/overview.html runs all the tests in parallel with the exception of the 4th test that happens once a result to the 1st test is done. You can look at the code to see the details but the point is that it finds out what type of NAT it is in similar time to what it takes to find out if you are behind a NAT at all. I think this approach illustrates that go/no go probably has a similar burden to compute as finding all the stuff described in the STUN draft. The parallel approach may eliminate the need to optimize something else. A related thing I have seen come up has to do with getting consecutive ports with the right even odd combination for RTP/RTCP. Some antidotal experiments suggested there were no problems with an approach of doing several simultaneous parallel request then looking at the results and using the mapped ports that have the right properties. Cullen PS. I just noticed that Jonathan seems to have a track record of protocols with interesting names when spelled in reverse. > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Jonathan Rosenberg > Sent: Thursday, April 04, 2002 10:45 AM > To: Pete Cordell > Cc: midcom@ietf.org > Subject: [midcom] Re: Truncated STUN test > > > > > Pete Cordell wrote: > > > > Jonathan, > > > > My understanding is that only NATs that exhibit cone NAT functionality > > (which presumably includes 1-to-1 NAT) are useful for things like SIP. > > Thats not the case. Cone NATs are ideal, but it is possible to use SIP > along with stun and get voip working when you have an restricted cone > nat too. You'll need to prime the nat with "suicide" packets to open > holes for the media from the peer. This is documented in > draft-rosenberg-sipping-nat-scenarios-00.txt, page 13. > > > For > > clients that are only interested in whether they can run VoIP (or > > something > > similar) knowing the various types of NAT is not really required. All > > they > > want is a go/no go decision on whether they can communicate through the > > NAT. > > Fair enough. > > > > > If that's the case it would be worth specifying a truncated STUN test > > sequence that yields only this go/no go decision. > > > > That would seem to involve doing Test I on the set of SRV derived STUN > > servers until one is found that works. You would then do a Test II. > > Once > > you have the result of that test, you can stop. > > Since it does work behind a restricted cone nat, you actually need to > run the full sequence in any case, as far as I can tell. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 4 22:38:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17859 for ; Thu, 4 Apr 2002 22:38:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA22603 for midcom-archive@odin.ietf.org; Thu, 4 Apr 2002 22:37:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA22551; Thu, 4 Apr 2002 22:35:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA22521 for ; Thu, 4 Apr 2002 22:35:01 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17828 for ; Thu, 4 Apr 2002 22:34:58 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g353YVON001883 for ; Thu, 4 Apr 2002 19:34:31 -0800 (PST) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ACM88635; Thu, 4 Apr 2002 19:34:40 -0800 (PST) From: "Cullen Jennings" To: Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Thu, 4 Apr 2002 19:37:16 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <933FADF5E673D411B8A30002A5608A0E01187A3A@zrc2c012.us.nortel.com> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit When setting up existing firewalls, people often use a list of rules that either allow or disallow a packet or do nothing and just go to the next rule on the list. This would lean towards a priority list of rules approach. When setting up NAT style holes - the idea that a hole that is allocated to one person could just be appropriated and given to someone else seems very disturbing. This leans to a first come first severed approach. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 4 23:22:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18461 for ; Thu, 4 Apr 2002 23:22:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA24411 for midcom-archive@odin.ietf.org; Thu, 4 Apr 2002 23:22:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24348; Thu, 4 Apr 2002 23:19:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24315 for ; Thu, 4 Apr 2002 23:19:54 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18439 for ; Thu, 4 Apr 2002 23:19:50 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.11]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g354KXTE029036; Thu, 4 Apr 2002 23:20:33 -0500 (EST) Message-ID: <3CAD25C8.67CA0F95@dynamicsoft.com> Date: Thu, 04 Apr 2002 23:19:20 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Cullen Jennings CC: midcom@ietf.org, Pete Cordell Subject: Re: [midcom] Re: Truncated STUN test References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > The open source implementation of STUN at > http://www.polyphase.ca/software/stun/overview.html > runs all the tests in parallel with the exception of the 4th test that > happens once a result to the 1st test is done. > > You can look at the code to see the details but the point is that it > finds > out what type of NAT it is in similar time to what it takes to find out > if > you are behind a NAT at all. I think this approach illustrates that > go/no go > probably has a similar burden to compute as finding all the stuff > described > in the STUN draft. The parallel approach may eliminate the need to > optimize > something else. More importantly, we don't need to specify that you should or shouldn't do it in parallel, and we don't need to specify whether you do fewer tests or more tests. The protocol itself is a simple request/response exchage with a dumb server. The ways in which a client can use the protocol to learn different things need not be standardized, and don't require the server to know what you want the client wants to do. > > A related thing I have seen come up has to do with getting consecutive > ports > with the right even odd combination for RTP/RTCP. Some antidotal > experiments > suggested there were no problems with an approach of doing several > simultaneous parallel request then looking at the results and using the > mapped ports that have the right properties. Really? It would only work for nats that are allocating ports sequentially. I wonder how often that is the case. > > Cullen > > PS. I just noticed that Jonathan seems to have a track record of > protocols > with interesting names when spelled in reverse. I never even noticed that - honest! Its like those records, where, if you manually played them backwards, you could supposedly hear hidden messages, from, well, you know... I don't know what this says about me. Hmm. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 5 00:03:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19562 for ; Fri, 5 Apr 2002 00:03:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA26574 for midcom-archive@odin.ietf.org; Fri, 5 Apr 2002 00:04:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA26293; Fri, 5 Apr 2002 00:00:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA26259 for ; Fri, 5 Apr 2002 00:00:54 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19519 for ; Fri, 5 Apr 2002 00:00:52 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.11]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g3551TTE029048; Fri, 5 Apr 2002 00:01:30 -0500 (EST) Message-ID: <3CAD2F60.15C470C8@dynamicsoft.com> Date: Fri, 05 Apr 2002 00:00:16 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Cedric Aoun CC: midcom@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Re: some comments on stun 01 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Cedric Aoun wrote: > > Hi, > I have some comments on stun-01 Thanks for your comments. Responses inline. > > Page 7, > "STUN servers are discovered through DNS SRV records [2], and is > generally > assumed that the client is configured with the domain to use to find > the STUN server. " > I prefer saying STUN servers could/might be discovered, I think we > should clearly decouple STUN > from the ability to send DNS SRV record queries to find the STUN server. OK. I'll change to "can be discovered". > > Section 9.2 page 17 > "It then starts a timer with a > value of T seconds. When this timer fires, the client sends a request > > to server A, with the "change IP" and "change port" flags set. If the > > binding is still active, this response should be received through all > > nat types." > > This bind expiry timer discovery method works only for NATs that are not > full cone NAT. When the NAT is full cone, > it won't work since we have refreshed the bind by sending out the > message to the original server Excellent point. > I suggest adding a > timer in the STUN query when the NAT is found full cone. This counter > will be used to say after how many secs > the server should reply back. I'd rather not do that, since it introduces state into the servers. How about this: 1. the client sends a request to the server, from socket X. It is sent to address/port C,D. The response is sent from C,D. From the response, the client learns the public IP/port for this request, say thats A,B. 2. after T seconds, the client sends a second request, from a different socket (Y), to the server at C,D. This one has a RESPONSE-ADDRESS of A,B. The server sends a response from C,D to A,B. If the old binding still exists, it is matched for all nat types, and the response goes to socket X. If the binding had timed out, the response will either be discarded, or it is possible that it might get sent to socket Y. In either case, the client knows that the binding has expired. I believe that will work. > > Section 12, page 23; Cullen mentioned this issue already where a > specific protocol name will need to be assigned > when used in DNS SRV records, Jonathan provided already the name.The > next version of the draft will need to incoeporate the "nat-stun-port" Actually, no. The port has been registered and obtained outside of the spec. No IANA considerations section is needed to obtain it. I can merely include the actual port number in the document. > > page 24, section 13.2 > "STUN can also help facilitate the introduction of midcom. As midcom- > capable NATs are deployed, applications will, instead of using STUN > (which also resides at the application layer), first allocate an > address binding using midcom. However, it is a well-known limitation > of midcom that it only works when the agent knows the middleboxes > through which its traffic will flow. Once bindings have been > allocated from those middleboxes, a STUN detection procedure can > validate that there are no additional middleboxes on the path from > the public Internet to the client. If this is the case, the > application can continue operation using the address bindings > allocated from midcom. If it is not the case, STUN provides a > mechanism for self-address fixing through the remaining midcom- > unaware middlboxes. Thus, STUN provides a way to help transition to > full midcom-aware networks." > > This is only valid only if a peer to peer STUN messaging is launched to > discover if there are no > other NATs traversed by the Media flow, Right. > this is actually one of the > issues of STUN, in case a realm > has several NATs on its boundaries the STUN stream (between the client > and the STUN server) > could be sent to a different NAT than the media stream. This particular validation scenario would require the stun server to be embedded within the end system, so that this would not happen. > I think that we should have this stated in a STUN applicability > statement. I've added an applicability statement, in fact, giving some of the caveats up front. However, it doesn't talk about this e2e usage. The usage e2e is mentioned as a possibility in a few places now. I think that sufficient. > > page 27, section 13.6 > "The result of this lack of standardization has been a > proliferation of devices whose behavior is highly predictable, > extremely variable, and uncontrollable" > Did you originally mean highly unpredictable? Yes, thanks. Thanks for your comments! -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 5 01:08:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20230 for ; Fri, 5 Apr 2002 01:08:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA02093 for midcom-archive@odin.ietf.org; Fri, 5 Apr 2002 01:08:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA00782; Fri, 5 Apr 2002 01:06:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA00723 for ; Fri, 5 Apr 2002 01:06:46 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20223 for ; Fri, 5 Apr 2002 01:06:43 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.11]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g3567PTE029142 for ; Fri, 5 Apr 2002 01:07:25 -0500 (EST) Message-ID: <3CAD3ED4.2D61774C@dynamicsoft.com> Date: Fri, 05 Apr 2002 01:06:12 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: midcom@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] new stun draft Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Folks, I just submitted an update to stun. Until it appears in the I-D archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-midcom-stun-00.txt The changes are listed in the changes section towards the bottom of the document. Comments and questions welcome, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 5 06:17:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01721 for ; Fri, 5 Apr 2002 06:16:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA23636 for midcom-archive@odin.ietf.org; Fri, 5 Apr 2002 06:17:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23567; Fri, 5 Apr 2002 06:14:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23483 for ; Fri, 5 Apr 2002 06:14:38 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01699 for ; Fri, 5 Apr 2002 06:14:32 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g35BDu855553; Fri, 5 Apr 2002 13:13:56 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA15581; Fri, 5 Apr 2002 13:13:37 +0200 Date: Fri, 05 Apr 2002 13:16:56 +0200 From: Juergen Quittek To: Sanjoy Sen , Tom-PT Taylor , "'Martin Stiemerling'" cc: midcom@ietf.org, Cedric Aoun Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Message-ID: <19040969.1018012616@[192.168.102.164]> In-Reply-To: <933FADF5E673D411B8A30002A5608A0E01187A37@zrc2c012.us.nortel.com> References: <933FADF5E673D411B8A30002A5608A0E01187A37@zrc2c012.us.nortel.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Sanjoy, --On 04 April 2002 17:04 -0600 Sanjoy Sen wrote: > > Inline. > > > -----Original Message----- > From: Taylor, Tom-PT [CAR:B800:EXCH] > Sent: Thursday, April 04, 2002 12:57 PM > To: 'Martin Stiemerling' > Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] > Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content > > > > That's two people so far who have said requests should be satisfied completely > or not at all. Shall we take this as the working assumption? > > First-come-first-serve vs. policy hides another issue: how to allow multiple > authorized agents to work on the same ruleset (requirement 2.2.7). > Our proposals so far assumed this was handled through a policy mechanism. > There is a distinction, of course, between two agents operating on the same > Policy Rule Identifier (which is perhaps what 2.2.7 permits) and two agents > defining identical rulesets with different Policy Rule Identifiers. > So I have a couple of questions for the WG: > > 1) Does the protocol address the possibility of two agents defining > overlapping rulesets and if so, are conflicts handled on a > first-come-first-served basis? > > [SS] The protocol has to allow overlapping rulesets because multiple agents > are installing rulesets independently and there're bound to be overlaps in, > say, the filter spec. Question is, what happens when there is a contradiction. > Requirement 2.2.11 seems to suggest that we need to allow the later agent to win, > at least, under special circumstances. For example, a Midcom agent installs a > ruleset allowing packets from the address range 100.10.*.* to pass through, > but at a later time, the firewall administrator wants to create a ruleset > disallowing packets from 100.10.50.10. I would like to think that the firewall > administrator would have the last say. An administrator Agent has the highest > priority. I did not yet consider the midcom protocol as the interface for a system administrator to consider the firewall. I think this taks includes restricting the the midcom interface's access to firewall control. So if the administrator wants to disallow packets from 100.10.50.10, he should do it by configuring the access rights of the midcom server running at the firewall, for example by modifying the midcom serve configuration files. But maybe I'm wrong here. I considered midcom to be used for temporary configurations by users or applications but not as a mean for permanent configuration of the firewall as it is done by the administrator. So, I clearly vote for not having priorities in order to KISS. However, if the WG decides to support also administrator configuration running over a midcom protocol, then it should be enough to have exactly two priorities: administrator and user (and first-come-first-serve per priority). > > IMO, an Agent priority list makes sense, with an agent higher up in the > priority list can modify/revoke rulesets created by lower priority agents. > For agents of same priority, a first-come-first-serve approach may be more > suitable. > > 2) Does the protocol need a formal delegation capability, so that Agent A > can tell the Middlebox that Agent B can make requests affecting Policy Rule > Identifier x? I think we do not need this at all. First, the scenario would be rather a rare one to happen. Second this increases complexity significantly on server side and on client side. More state need to be kept an more message types are required. We should not overdesign the protocol and avoid all complexity that is not required by a strong usage scenario. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > Here we would distinguish between sharing of authority (both Agent A and > Agent B can manipulate the Policy Rule) vs. handoff (Agent A gives up its > authority to Agent B). Which one might we want, if we want either? > I visualize a message exchange of the form: > > [SS] Since we're requiring the Middlebox to report unsolicitated messages > to the Agent, we can do this in another way. When there is an attempt by > Agent B to install a ruleset which overlaps with and has contradictory > action(s) to one that has been installed by Agent A, then the Middlebox can > send a notification message reporting this event to A with Agent B's id. > Agent A may or may not allow this. If disallowed, the Middlebox may either > reject B's request to install or suggests an alternative/modified ruleset > by sending B an error message. > > Agent A Middlebox Agent B > > Grant(Policy Rule Id x, Agent B) > -------------------------------> > Notify (Grant, Policy Rule Id x) > Grant Acknowledge ---------------------------> > <------------------------------- > Notify Acknowledge > <--------------------------- > > Sorry about the really theoretical stuff -- it was something I had to think > through clearly for myself, but I can see it wouldn't be generally helpful, > so we can omit it or put it into an appendix. > > -----Original Message----- > From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] > Sent: Thursday, April 04, 2002 8:58 AM > To: Taylor, Tom-PT [CAR:B800:EXCH] > Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] > Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content > > Hi, > > please find my comments embedded in the text. > > Regards > Martin > > Tom-PT Taylor wrote: > >> This is the theoretical section of the I-D Cedric and I are working on. We >> are still validating it against the various scenarios. >> > > Yes, it is very theoretical. We should aviod such text for internet > drafts, because a lot of people won't even continue reading the entire > document. > >> 4 Structure And Comparison Of Policy Rules >> >> In this note, a Policy Rule is defined to be a set of terms of the form > > [...] > >> decide which action will apply in the region of overlap. By assumption, >> these decision rules will be based on the combination of order of >> specification and policy at the Middlebox. >> >> There are two possible cases: >> >> (1) The Policy Rule associated with each of the two {Filter, Action} pairs >> must be installed completely or not at all. In this case, if there is a >> conflict between the two rules in the zone of overlap, the lower-priority >> Policy Rule will be disallowed (if it was the later arrival) or deactivated >> (if it was already installed). > > This sounds very complicated and with a lot of administrative overhead. > I prefer Jiri's idea of disallowing overlapping rules at all and using a > first come, first served scheme, instead of priorities. Should there be > any conflict, reject the latest policy rule request. > >> >> (2) The Policy Rule which has lower priority in the zone of conflict allows >> for partial implementation. Thus the desired {Filter, Action} pair is >> modified to exclude the zone of overlap. There are two sub-cases: > > Hmm, how to tell the agent, that his rule request has been fulfilled > only partial? My opinion is, that the agent wants exactly this policy > rule and if he can't get this, tell him! > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 5 06:28:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01846 for ; Fri, 5 Apr 2002 06:28:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA24022 for midcom-archive@odin.ietf.org; Fri, 5 Apr 2002 06:28:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23969; Fri, 5 Apr 2002 06:26:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23938 for ; Fri, 5 Apr 2002 06:26:34 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01839 for ; Fri, 5 Apr 2002 06:26:31 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g35BPO856482; Fri, 5 Apr 2002 13:25:24 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA15746; Fri, 5 Apr 2002 13:25:05 +0200 Date: Fri, 05 Apr 2002 13:28:24 +0200 From: Juergen Quittek To: Sanjoy Sen , "'Jiri Kuthan'" , Tom-PT Taylor , midcom@ietf.org cc: Cedric Aoun Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Message-ID: <19729139.1018013304@[192.168.102.164]> In-Reply-To: <933FADF5E673D411B8A30002A5608A0E01187A38@zrc2c012.us.nortel.com> References: <933FADF5E673D411B8A30002A5608A0E01187A38@zrc2c012.us.nortel.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Sanjoy, --On 04 April 2002 17:46 -0600 Sanjoy Sen wrote: > > Jiri, > Why wouldn't a network/firewall administration application be > able to use the same Midcom protocol for opening/closing firewall > pinholes? Nothing in the charter says that this out of scope. Yes, we can do a lot more. But how much is enough? We also should care about size and complexity and priorities of problems to be solved. In my view the high priority is giving applications/users the ability to control a part of the firewall/NAT in order to enable applications, such as NetMeeting, SIP/H323 telephony, ... to work when middleboxes are in between. The charter allows us to build a remote management protocol for FWs/NATs, but I would prefer to leave this tasks to the operations and management area. > > Also, what you're suggesting may be too retrictive. I can't > possibly assume that all NAT's & firewalls will be Midcom-enabled > at the same time. So there might be a situation where a Midcom > agent would like to open pinhole in a firewall which is > sandwitched between two NAT's which are not Midcom-aware. The > Agent doesn't have any idea about the exact NAT binds that > will be used on both sides of the FW but knows about the range > of possible binds. There'll be overlap in this case between > rulesets of agents controlling the firewall. The scenario is well constructed to show that there there is a need AT ALL to care about this. But shoudn't we just say that the midcom protocol does not helpin this situation? Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > Sanjoy > >> -----Original Message----- >> From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de] >> Sent: Thursday, April 04, 2002 5:04 PM >> To: Sen, Sanjoy [NGC:B692:EXCH]; Taylor, Tom-PT [CAR:B800:EXCH]; >> midcom@ietf.org >> Cc: Aoun, Cedric [QPD:MA01:EXCH] >> Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content >> >> >> At 12:27 AM 4/5/2002, Sanjoy Sen wrote: >> > How will then the following requirement from Midcom >> requirements draft be satisfied? >> >> Perhaps by reading "should" as "there may exist valid reasons >> in particular >> circumstances to ignore a particular item, but the full >> implications must >> be understood and carefully weighed before choosing a >> different course." >> (RFC2119). >> >> > ***** >> > 2.2.11. >> > >> > It should be possible to define rulesets that contain a >> more spe- >> > cific filter spec than an overlapping ruleset. This >> should allow >> > agents to request actions for the subset that >> contradict those of >> > the overlapping set. >> > ***** >> > >> > Whether you want it or not, there would be overlapping >> rulesets because the filterspec may overlap for different >> rulesets installed by independent agents. >> >> Why? Again, thats a matter of protocol scope. If we define >> MidCom to be >> firewall/NAT opener, then overlaps are errors and can be as >> such denied. >> If we define it as a management protocol, things are different -- but >> MidCom is not a management protocol. Whereas some people may like >> extending its scope, I am in favor of keeping things very simple. >> >> -Jiri >> _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 5 09:41:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05983 for ; Fri, 5 Apr 2002 09:41:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA03759 for midcom-archive@odin.ietf.org; Fri, 5 Apr 2002 09:41:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03511; Fri, 5 Apr 2002 09:35:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03479 for ; Fri, 5 Apr 2002 09:35:15 -0500 (EST) Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05896 for ; Fri, 5 Apr 2002 09:35:09 -0500 (EST) Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 2896964 for midcom@ietf.org; Fri, 05 Apr 2002 09:35:12 -0500 Message-Id: <5.1.0.14.0.20020405093110.0204afb8@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 05 Apr 2002 09:34:27 -0500 To: midcom@ietf.org From: "Joel M. Halpern" Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content In-Reply-To: <19040969.1018012616@[192.168.102.164]> References: <933FADF5E673D411B8A30002A5608A0E01187A37@zrc2c012.us.nortel.com> <933FADF5E673D411B8A30002A5608A0E01187A37@zrc2c012.us.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I believe that the problem turns on how large a range of "rules" we want to allow. My understanding of the goal is to allow a controlling entity to: 1) create some holes that will allow traffic to pass through the middle box 2) find out certain things about these holes (for NAT) 3) provide auxiliary processing for some packets. Note that for cases 1 and 2, there is not much trouble. Overlapping holes merely means that that hole remains open as long as either requestor needs it. As far as I can tell, it is only the "auxilliary processing" case that makes life complicated. It would seem that we could again say "both" for that. We are not providing arbitrary policy management. At the same time, declaring that two servers can not open overlapping holes in the same firewall / NAT would seem counter-factual. Yours, Joel M. Halpern At 01:16 PM 4/5/2002 +0200, Juergen Quittek wrote: >Sanjoy, > >--On 04 April 2002 17:04 -0600 Sanjoy Sen wrote: >> >>Inline. >> >> >>-----Original Message----- >>From: Taylor, Tom-PT [CAR:B800:EXCH] >>Sent: Thursday, April 04, 2002 12:57 PM >>To: 'Martin Stiemerling' >>Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] >>Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content >> >> >> >>That's two people so far who have said requests should be satisfied >>completely >>or not at all. Shall we take this as the working assumption? >> >>First-come-first-serve vs. policy hides another issue: how to allow multiple >>authorized agents to work on the same ruleset (requirement 2.2.7). >>Our proposals so far assumed this was handled through a policy mechanism. >>There is a distinction, of course, between two agents operating on the same >>Policy Rule Identifier (which is perhaps what 2.2.7 permits) and two agents >>defining identical rulesets with different Policy Rule Identifiers. >>So I have a couple of questions for the WG: >> >> 1) Does the protocol address the possibility of two agents defining >> overlapping rulesets and if so, are conflicts handled on a >> first-come-first-served basis? >> >>[SS] The protocol has to allow overlapping rulesets because multiple agents >>are installing rulesets independently and there're bound to be overlaps in, >>say, the filter spec. Question is, what happens when there is a >>contradiction. >>Requirement 2.2.11 seems to suggest that we need to allow the later agent >>to win, >>at least, under special circumstances. For example, a Midcom agent installs a >>ruleset allowing packets from the address range 100.10.*.* to pass through, >>but at a later time, the firewall administrator wants to create a ruleset >>disallowing packets from 100.10.50.10. I would like to think that the >>firewall >>administrator would have the last say. An administrator Agent has the highest >>priority. > >I did not yet consider the midcom protocol as the interface for a system >administrator to consider the firewall. I think this taks includes restricting >the the midcom interface's access to firewall control. So if the administrator >wants to disallow packets from 100.10.50.10, he should do it by configuring >the access rights of the midcom server running at the firewall, for example by >modifying the midcom serve configuration files. > >But maybe I'm wrong here. I considered midcom to be used for temporary >configurations by users or applications but not as a mean for permanent >configuration of the firewall as it is done by the administrator. > >So, I clearly vote for not having priorities in order to KISS. However, if >the WG decides to support also administrator configuration running over >a midcom protocol, then it should be enough to have exactly two priorities: >administrator and user (and first-come-first-serve per priority). > >> >>IMO, an Agent priority list makes sense, with an agent higher up in the >>priority list can modify/revoke rulesets created by lower priority agents. >>For agents of same priority, a first-come-first-serve approach may be more >>suitable. >> >> 2) Does the protocol need a formal delegation capability, so that Agent A >>can tell the Middlebox that Agent B can make requests affecting Policy Rule >>Identifier x? > >I think we do not need this at all. First, the scenario would be rather >a rare one to happen. Second this increases complexity significantly on >server side and on client side. More state need to be kept an more message >types are required. We should not overdesign the protocol and avoid all >complexity that is not required by a strong usage scenario. > > Juergen >-- >Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 >NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 >Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > >>Here we would distinguish between sharing of authority (both Agent A and >>Agent B can manipulate the Policy Rule) vs. handoff (Agent A gives up its >>authority to Agent B). Which one might we want, if we want either? >>I visualize a message exchange of the form: >> >>[SS] Since we're requiring the Middlebox to report unsolicitated messages >>to the Agent, we can do this in another way. When there is an attempt by >>Agent B to install a ruleset which overlaps with and has contradictory >>action(s) to one that has been installed by Agent A, then the Middlebox can >>send a notification message reporting this event to A with Agent B's id. >>Agent A may or may not allow this. If disallowed, the Middlebox may either >>reject B's request to install or suggests an alternative/modified ruleset >>by sending B an error message. >> >> Agent A Middlebox Agent B >> >> Grant(Policy Rule Id x, Agent B) >> -------------------------------> >> Notify (Grant, Policy Rule Id x) >> Grant Acknowledge ---------------------------> >> <------------------------------- >> Notify Acknowledge >> <--------------------------- >> >>Sorry about the really theoretical stuff -- it was something I had to think >>through clearly for myself, but I can see it wouldn't be generally helpful, >>so we can omit it or put it into an appendix. >> >>-----Original Message----- >>From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] >>Sent: Thursday, April 04, 2002 8:58 AM >>To: Taylor, Tom-PT [CAR:B800:EXCH] >>Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] >>Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content >> >>Hi, >> >>please find my comments embedded in the text. >> >>Regards >>Martin >> >>Tom-PT Taylor wrote: >> >>>This is the theoretical section of the I-D Cedric and I are working on. We >>>are still validating it against the various scenarios. >> >>Yes, it is very theoretical. We should aviod such text for internet >>drafts, because a lot of people won't even continue reading the entire >>document. >> >>>4 Structure And Comparison Of Policy Rules >>> >>>In this note, a Policy Rule is defined to be a set of terms of the form >> >>[...] >> >>>decide which action will apply in the region of overlap. By assumption, >>>these decision rules will be based on the combination of order of >>>specification and policy at the Middlebox. >>> >>>There are two possible cases: >>> >>>(1) The Policy Rule associated with each of the two {Filter, Action} pairs >>>must be installed completely or not at all. In this case, if there is a >>>conflict between the two rules in the zone of overlap, the lower-priority >>>Policy Rule will be disallowed (if it was the later arrival) or deactivated >>>(if it was already installed). >> >>This sounds very complicated and with a lot of administrative overhead. >>I prefer Jiri's idea of disallowing overlapping rules at all and using a >>first come, first served scheme, instead of priorities. Should there be >>any conflict, reject the latest policy rule request. >> >>> >>>(2) The Policy Rule which has lower priority in the zone of conflict allows >>>for partial implementation. Thus the desired {Filter, Action} pair is >>>modified to exclude the zone of overlap. There are two sub-cases: >> >>Hmm, how to tell the agent, that his rule request has been fulfilled >>only partial? My opinion is, that the agent wants exactly this policy >>rule and if he can't get this, tell him! > > > >_______________________________________________ >midcom mailing list >midcom@ietf.org >https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 5 09:54:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06344 for ; Fri, 5 Apr 2002 09:54:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA04317 for midcom-archive@odin.ietf.org; Fri, 5 Apr 2002 09:54:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04053; Fri, 5 Apr 2002 09:49:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04025 for ; Fri, 5 Apr 2002 09:49:48 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06229 for ; Fri, 5 Apr 2002 09:49:43 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g35Em2869771; Fri, 5 Apr 2002 16:48:02 +0200 (CEST) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA18214; Fri, 5 Apr 2002 16:47:42 +0200 Received: from ccrle.nec.de (elgar.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 4A2D93B64D; Fri, 5 Apr 2002 16:47:42 +0200 (CEST) Message-ID: <3CADB923.6070203@ccrle.nec.de> Date: Fri, 05 Apr 2002 16:48:03 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20020305 X-Accept-Language: en-us MIME-Version: 1.0 To: Sanjoy Sen Cc: Tom-PT Taylor , midcom@ietf.org, Cedric Aoun Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content References: <933FADF5E673D411B8A30002A5608A0E01187A37@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Sanjoy Sen wrote: > Inline. > > -----Original Message----- [... ] > > 1) Does the protocol address the possibility of two agents defining > overlapping rulesets and if so, are conflicts handled on a > first-come-first-served basis? > > [SS] The protocol has to allow overlapping rulesets because multiple > agents are installing rulesets independently and there're bound to > be overlaps in, say, the filter spec. Question is, what happens > when there is a contradiction. Requirement 2.2.11 seems to suggest > that we need to allow the later agent to win, at least, under > special circumstances. For example, a Midcom agent installs a > ruleset allowing packets from the address range 100.10.*.* to pass > through, but at a later time, the firewall administrator wants to > create a ruleset disallowing packets from 100.10.50.10. I would like > to think that the firewall administrator would have the last say. An > administrator Agent has the highest priority. > > IMO, an Agent priority list makes sense, with an agent higher up in > the priority list can modify/revoke rulesets created by lower > priority agents. For agents of same priority, a > first-come-first-serve approach may be more suitable. Midcom is not intended to be a complete firewall management tool, but rather a tool for configuring pin-holes for applications. And by the way, the best way to disallow packets permanently, you better use the command line interface. > > 2) Does the protocol need a formal delegation capability, so that > Agent A can tell the Middlebox that Agent B can make requests > affecting Policy Rule Identifier x? Here we would distinguish > between sharing of authority (both Agent A and Agent B can > manipulate the Policy Rule) vs. handoff (Agent A gives up its > authority to Agent B). Which one might we want, if we want either? > I visualize a message exchange of the form: > > [SS] Since we're requiring the Middlebox to report unsolicitated > messages to the Agent, we can do this in another way. When there is > an attempt by Agent B to install a ruleset which overlaps with and > has contradictory action(s) to one that has been installed by Agent > A, then the Middlebox can send a notification message reporting this > event to A with Agent B's id. Agent A may or may not allow this. If > disallowed, the Middlebox may either reject B's request to install > or suggests an alternative/modified ruleset by sending B an error > message. Delegating rules to other agents blows the whole protocol up and it is from my view questionable, if this function is ever needed. We can put a lot of functions into this protocl, but we should consider that somebody has to implement this stuff sometimes. Martin _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 5 09:59:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06494 for ; Fri, 5 Apr 2002 09:59:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA04575 for midcom-archive@odin.ietf.org; Fri, 5 Apr 2002 09:59:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04355; Fri, 5 Apr 2002 09:54:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00536 for ; Fri, 5 Apr 2002 08:47:21 -0500 (EST) Received: from ws3-3.us4.outblaze.com (205-158-62-93.outblaze.com [205.158.62.93]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04553 for ; Fri, 5 Apr 2002 08:47:16 -0500 (EST) Received: (qmail 28618 invoked by uid 1001); 5 Apr 2002 13:46:49 -0000 Message-ID: <20020405134649.28617.qmail@email.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [202.134.192.190] by ws3-3.us4.outblaze.com with http for harry_suede@email.com; Fri, 05 Apr 2002 21:46:49 +0800 From: "Harry Suede" To: midcom@ietf.org, , "Mary Barnes" Date: Fri, 05 Apr 2002 21:46:49 +0800 Subject: Re: [midcom] Protocol evaluation contribution reminder X-Originating-Ip: 202.134.192.190 X-Originating-Server: ws3-3.us4.outblaze.com Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Hi I am new to this list, and so I just wanted to know what is currently going on. The Working Group Description says that group is going to pick an existing protocol which meets the MIDCOM requirements. I guess that the protocols listed in this thread are for the same purpose. But the Description also talks about an 'interim' solution. Has the group decided on one ? Regards Harry ======================== Hi all, The following are the protocols for which people have signed up, with the "prime" listed (several have indicated that there will be multiple authors): MEGACO - Sanjoy Sen [sanjoy@nortelnetworks.com] COPS - Louis-Nicolas Hamer [nhamer@nortelnetworks.com] RSIP - James Renkel [James_Renkel@3com.com] SNMP/SMI - Juergen Quittek [quittek@ccrle.nec.de] Regards, Mary. Editor, Protocol evaluation document -- _______________________________________________ Sign-up for your own FREE Personalized E-mail at Email.com http://www.email.com/?sr=signup _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 5 10:03:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06667 for ; Fri, 5 Apr 2002 10:03:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA05153 for midcom-archive@odin.ietf.org; Fri, 5 Apr 2002 10:03:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04530; Fri, 5 Apr 2002 09:58:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04502 for ; Fri, 5 Apr 2002 09:58:19 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06475 for ; Fri, 5 Apr 2002 09:58:13 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g35EuW870232; Fri, 5 Apr 2002 16:56:32 +0200 (CEST) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA18293; Fri, 5 Apr 2002 16:56:12 +0200 Received: from ccrle.nec.de (elgar.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id CEF863A266; Fri, 5 Apr 2002 16:56:11 +0200 (CEST) Message-ID: <3CADBB21.90405@ccrle.nec.de> Date: Fri, 05 Apr 2002 16:56:33 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20020305 X-Accept-Language: en-us MIME-Version: 1.0 To: Sanjoy Sen Cc: "'Jiri Kuthan'" , Tom-PT Taylor , midcom@ietf.org, Cedric Aoun Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content References: <933FADF5E673D411B8A30002A5608A0E01187A34@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Sanjoy Sen wrote: > How will then the following requirement from Midcom requirements draft > be satisfied? > ***** > 2.2.11. > > It should be possible to define rulesets that contain a more spe- > cific filter spec than an overlapping ruleset. This should allow > agents to request actions for the subset that contradict those of > the overlapping set. > ***** > > Whether you want it or not, there would be overlapping rulesets because > the filterspec may overlap for different rulesets installed by > independent agents. The question - who wins when there're contradictory > actions is moot because the requirement above seems to suggest that we > need to allow contradictory behavior. The questions is, who will decide how to behave in such a case? There are so many combinations of firewall/NAT configurations which will make it difficult to define a stable behaviour, i.e. how to react with this overlapping set. Furthermore, the requirement starts with "should"... Martin -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 5 10:12:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06916 for ; Fri, 5 Apr 2002 10:12:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA05616 for midcom-archive@odin.ietf.org; Fri, 5 Apr 2002 10:12:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05319; Fri, 5 Apr 2002 10:07:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05288 for ; Fri, 5 Apr 2002 10:07:30 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06780 for ; Fri, 5 Apr 2002 10:07:24 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g35F4c870571; Fri, 5 Apr 2002 17:04:38 +0200 (CEST) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA18377; Fri, 5 Apr 2002 17:04:18 +0200 Received: from ccrle.nec.de (elgar.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 12CFD35E0E; Fri, 5 Apr 2002 17:04:17 +0200 (CEST) Message-ID: <3CADBD06.6090801@ccrle.nec.de> Date: Fri, 05 Apr 2002 17:04:38 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20020305 X-Accept-Language: en-us MIME-Version: 1.0 To: Sanjoy Sen Cc: "'Jiri Kuthan'" , Tom-PT Taylor , midcom@ietf.org, Cedric Aoun Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content References: <933FADF5E673D411B8A30002A5608A0E01187A38@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Sanjoy Sen wrote: > Jiri, > Why wouldn't a network/firewall administration application be able to > use the same Midcom protocol for opening/closing firewall pinholes? > Nothing in the charter says that this out of scope. Hmm, I'm thinking about all the different firewalls/NATs from different vendors, with different capabilities. We can spend years of defining such a management protocol, but we need a simple protocol for configuring holes/bindings for a defined period of time. > > Also, what you're suggesting may be too retrictive. I can't possibly > assume that all NAT's & firewalls will be Midcom-enabled at the same > time. So there might be a situation where a Midcom agent would like to > open pinhole in a firewall which is sandwitched between two NAT's which > are not Midcom-aware. The Agent doesn't have any idea about the exact > NAT binds that will be used on both sides of the FW but knows about the > range of possible binds. There'll be overlap in this case between > rulesets of agents controlling the firewall. How does the agent know about the NATs? I thought middle box discovery is out of scope? > > Sanjoy > > > > -----Original Message----- > > From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de] > > Sent: Thursday, April 04, 2002 5:04 PM > > To: Sen, Sanjoy [NGC:B692:EXCH]; Taylor, Tom-PT [CAR:B800:EXCH]; > > midcom@ietf.org > > Cc: Aoun, Cedric [QPD:MA01:EXCH] > > Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content > > > > > > At 12:27 AM 4/5/2002, Sanjoy Sen wrote: > > >How will then the following requirement from Midcom > > requirements draft be satisfied? > > > > Perhaps by reading "should" as "there may exist valid reasons > > in particular > > circumstances to ignore a particular item, but the full > > implications must > > be understood and carefully weighed before choosing a > > different course." > > (RFC2119). > > > > >***** > > >2.2.11. > > > > > > It should be possible to define rulesets that contain a > > more spe- > > > cific filter spec than an overlapping ruleset. This > > should allow > > > agents to request actions for the subset that > > contradict those of > > > the overlapping set. > > >***** > > > > > >Whether you want it or not, there would be overlapping > > rulesets because the filterspec may overlap for different > > rulesets installed by independent agents. > > > > Why? Again, thats a matter of protocol scope. If we define > > MidCom to be > > firewall/NAT opener, then overlaps are errors and can be as > > such denied. > > If we define it as a management protocol, things are different -- but > > MidCom is not a management protocol. Whereas some people may like > > extending its scope, I am in favor of keeping things very simple. > > > > -Jiri > > > > > -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 5 10:18:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07101 for ; Fri, 5 Apr 2002 10:18:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA06064 for midcom-archive@odin.ietf.org; Fri, 5 Apr 2002 10:18:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05555; Fri, 5 Apr 2002 10:11:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05522 for ; Fri, 5 Apr 2002 10:11:25 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06885 for ; Fri, 5 Apr 2002 10:11:18 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g35FAj870881; Fri, 5 Apr 2002 17:10:45 +0200 (CEST) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA18489; Fri, 5 Apr 2002 17:10:25 +0200 Received: from ccrle.nec.de (elgar.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id E344A36E84; Fri, 5 Apr 2002 17:10:23 +0200 (CEST) Message-ID: <3CADBE75.4050603@ccrle.nec.de> Date: Fri, 05 Apr 2002 17:10:45 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20020305 X-Accept-Language: en-us MIME-Version: 1.0 To: "Joel M. Halpern" Cc: midcom@ietf.org Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content References: <933FADF5E673D411B8A30002A5608A0E01187A37@zrc2c012.us.nortel.com> <933FADF5E673D411B8A30002A5608A0E01187A37@zrc2c012.us.nortel.com> <5.1.0.14.0.20020405093110.0204afb8@mail.stevecrocker.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Joel M. Halpern wrote: > I believe that the problem turns on how large a range of "rules" we want > to allow. > My understanding of the goal is to allow a controlling entity to: > 1) create some holes that will allow traffic to pass through the middle box > 2) find out certain things about these holes (for NAT) > 3) provide auxiliary processing for some packets. What is your definition of "auxiliary processing"? > > Note that for cases 1 and 2, there is not much trouble. Overlapping > holes merely means that that hole remains open as long as either > requestor needs it. You assume that the holes are already configured, but the problem appears earlier: How to configure the rules at all? Martin > > As far as I can tell, it is only the "auxilliary processing" case that > makes life complicated. It would seem that we could again say "both" > for that. > > We are not providing arbitrary policy management. > At the same time, declaring that two servers can not open overlapping > holes in the same firewall / NAT would seem counter-factual. > > Yours, > Joel M. Halpern > -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 5 10:19:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07134 for ; Fri, 5 Apr 2002 10:19:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA06204 for midcom-archive@odin.ietf.org; Fri, 5 Apr 2002 10:19:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05747; Fri, 5 Apr 2002 10:13:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05661 for ; Fri, 5 Apr 2002 10:13:19 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06953 for ; Fri, 5 Apr 2002 10:13:13 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g35FCcT05091; Fri, 5 Apr 2002 09:12:38 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2JXV20N4>; Fri, 5 Apr 2002 09:12:40 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A03DE395A@zrc2c000.us.nortel.com> From: "Mary Barnes" To: midcom@ietf.org Cc: "'Melinda Shore'" , Pete Cordell Date: Fri, 5 Apr 2002 09:12:32 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCB4.4F387A90" Subject: [midcom] Summary of Volunteers for Protocol Evaluation Documents & one las t plea for additional volunteers Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DCB4.4F387A90 Content-Type: text/plain; charset="iso-8859-1" Well, the volunteers for protocols remain as follows: MEGACO - Sanjoy Sen [sanjoy@nortelnetworks.com] COPS - Louis-Nicolas Hamer [nhamer@nortelnetworks.com] RSIP - James Renkel [James_Renkel@3com.com] SNMP/SMI - Juergen Quittek [quittek@ccrle.nec.de] There was a single response to my proposal to include some of the others. Pete provided a brief description of why SOCKS wouldn't be suitable. Unfortunately, without more support or "volunteers" the task of including this sort of information in the document isn't practical. Subsequent list discussion does show that there is a level of interest in these others, particularly DIAMETER. So, I'd like to do one last plea for volunteers for some of these others. The deadline for the intial submission is April 19th, thus I think it's still reasonable for folks to step forward and still take these on. These don't have to be extremely long documents but MUST cover the items highlighted in section 4.1 of the template at: http://www.obsidian97.com/draft-midcom-protocol-eval-template.txt . As a reminder, the timeline for these contributions is: April 19th Final cutoff for specific protocol drafts. * Drafts must be as objective as possible, identify the applicability to the framework and clearly identify the requirements that are satisfied, those that are "partially" satisfied, and those that are NOT satisfied. April 19th- May 3rd Mailing list discussion of specific protocol drafts, allowing authors to incorporate WG feedback into their contribution to improve comparison and add completeness. May 10th Deadline for any updates to protocol drafts. So, are there any additional volunteers? If I don't hear anything by 5PM EST today, we'll go forward with the 4 above listed protocols for the content of the document. Mary. Editor, MIDCOM Protocol Evalation Document -----Original Message----- From: Barnes, Mary [NGC:B601:EXCH] Sent: Wednesday, April 03, 2002 10:32 AM To: 'Melinda Shore'; Pete Cordell; midcom@ietf.org Subject: RE: [midcom] Protocol evaluation contribution reminder With my editor's hat on... There seems to be general WG interest in visiting a larger number of protocols. At this point, I've not taken any of these queries as "volunteering" to do these evaluations of these other protocols. With my editor's hat off... I think it's a really good idea to do a minimal evaluation of several of the protocols that have been put forth over the past couple days (DIAMETER, SOCKS, RSVP, etc.). I do realize that some of these have already been previously considered and already discarded, but from a completeness perspective, it would be really useful to capture why they were discarded or considered inappropriate. I have a feeling that the reason why people that have suggested these haven't volunteered has more to do with that limitation of only 24 hours in a given day versus lack of interest. With my editor's hat back on... I would suggest we add an additional section to the Protocol Evaluation document template to cover these other protocols. What this would require from the WG would be some discussion on the list to compile this information or "volunteers" (that word again) to provide minimal content for the protocol evaluation document for these other protocols (i.e. just a brief overview and summary of Pros/cons (per the requirements) and perhaps a recommendation as to why this wouldn't be appropriate as the MIDCOM protocol). Now, I can see problems with doing this as it's possible one of these others might actually be better and we've not necessarily evaluated these as thoroughly as the others (although, Melinda seems to be indicating that a certain level of analysis had been previously done in an informal manner on some of these others). So, what do people think about this proposal? Mary. -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Wednesday, April 03, 2002 9:13 AM To: Pete Cordell; midcom@ietf.org Subject: Re: [midcom] Protocol evaluation contribution reminder At 01:01 PM 4/3/02 +0100, Pete Cordell wrote: >SOCKS would seem to be a candidate also. Or do people already know that it >is not useful? SOCKS would require significant extension, and I think that its basic model is actually covered in a more general way by RSIP. It's a reasonable protocol to investigate, though. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C1DCB4.4F387A90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Summary of Volunteers for Protocol Evaluation Documents & = one last plea for additional volunteers

Well, the volunteers for protocols remain as = follows:

MEGACO - Sanjoy Sen = [sanjoy@nortelnetworks.com]
COPS - Louis-Nicolas Hamer = [nhamer@nortelnetworks.com]
RSIP - James Renkel [James_Renkel@3com.com]
SNMP/SMI - Juergen Quittek = [quittek@ccrle.nec.de]

There was a single response to my proposal to include = some of the others. Pete provided a brief description of why SOCKS = wouldn't be suitable.  Unfortunately, without more support or = "volunteers" the task of including this sort of information = in the document isn't practical.

Subsequent list discussion does show that there is a = level of interest in these others, particularly DIAMETER.  So, I'd = like to do one last plea for volunteers for some of these others. The = deadline for the intial submission is April 19th, thus I think it's = still reasonable for folks to step forward and still take these on. = These don't have to be extremely long documents but MUST cover the = items highlighted in section 4.1 of the template at: http://www.obsidian97.com/draft-midcom-protocol-eval-t= emplate.txt .

As a reminder, the timeline for these contributions = is:

April 19th      Final cutoff = for specific protocol drafts.
          &nb= sp; *  Drafts must be as objective as possible, identify = the
          &nb= sp;    applicability to the framework and clearly = identify the
          &nb= sp;    requirements that are satisfied, those = that
          &nb= sp;    are "partially" satisfied, and those = that are NOT satisfied.

April 19th- May 3rd     Mailing = list discussion of specific protocol
          &nb= sp;           &nb= sp; drafts, allowing authors to incorporate WG feedback
          &nb= sp;           &nb= sp; into their contribution to improve comparison and
          &nb= sp;           &nb= sp; add completeness.

May 10th        = Deadline for any updates to protocol drafts.


So, are there any additional volunteers?  If I = don't hear anything by 5PM EST today, we'll go forward with the 4 above = listed protocols for the content of the document.

Mary.
Editor, MIDCOM Protocol Evalation Document

-----Original Message-----
From: Barnes, Mary [NGC:B601:EXCH]
Sent: Wednesday, April 03, 2002 10:32 AM
To: 'Melinda Shore'; Pete Cordell; = midcom@ietf.org
Subject: RE: [midcom] Protocol evaluation = contribution reminder


With my editor's hat on...
There seems to be general WG interest in visiting a = larger number of protocols.  At this point, I've not taken any of = these queries as "volunteering" to do these evaluations of = these other protocols.

With my editor's hat off...
I think it's a really good idea to do a minimal = evaluation of several of the protocols that have been put forth over = the past couple days (DIAMETER, SOCKS, RSVP, etc.).  I do realize = that some of these have already been previously considered and already = discarded, but from a completeness perspective, it would be really = useful to capture why they were discarded or considered = inappropriate.  I have a feeling that the reason why people that = have suggested these haven't volunteered has more to do with that = limitation of only 24 hours in a given day versus lack of = interest. 

With my editor's hat back on...
I would suggest we add an additional section to the = Protocol Evaluation document template to cover these other = protocols.  What this would require from the WG would be some = discussion on the list to compile this information or = "volunteers" (that word again) to provide minimal content for = the protocol evaluation document for these other protocols (i.e. just a = brief overview and summary of Pros/cons (per the requirements) and = perhaps a recommendation as to why this wouldn't be appropriate as the = MIDCOM protocol).  Now, I can see problems with doing this as it's = possible one of these others might actually be better and we've not = necessarily evaluated these as thoroughly as the others (although, = Melinda seems to be indicating that a certain level of analysis had = been previously done in an informal manner on some of these others). =

So, what do people think about this proposal?

Mary. 
-----Original Message-----
From: Melinda Shore [mailto:mshore@cisco.com]
Sent: Wednesday, April 03, 2002 9:13 AM
To: Pete Cordell; midcom@ietf.org
Subject: Re: [midcom] Protocol evaluation = contribution reminder


At 01:01 PM 4/3/02 +0100, Pete Cordell wrote:
>SOCKS would seem to be a candidate also.  = Or do people already know that it
>is not useful?
SOCKS would require significant extension, and I = think that
its basic model is actually covered in a more = general way by
RSIP.  It's a reasonable protocol to = investigate, though.
Melinda


_______________________________________________ =
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom =

------_=_NextPart_001_01C1DCB4.4F387A90-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 5 10:38:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07683 for ; Fri, 5 Apr 2002 10:38:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA08393 for midcom-archive@odin.ietf.org; Fri, 5 Apr 2002 10:38:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06763; Fri, 5 Apr 2002 10:25:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06729 for ; Fri, 5 Apr 2002 10:25:49 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07335 for ; Fri, 5 Apr 2002 10:25:43 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g35FPFw19732 for ; Fri, 5 Apr 2002 10:25:15 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 10:25:15 -0500 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A275@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "Mary Barnes", midcom@ietf.org Cc: "'Melinda Shore'" , Pete Cordell Subject: RE: [midcom] Summary of Volunteers for Protocol Evaluation Docume nts & one las t plea for additional volunteers Date: Fri, 5 Apr 2002 10:25:13 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I used to know DIAMETER well, though I haven't looked at it for several years. I suppose I could have a go. -----Original Message----- From: Barnes, Mary [NGC:B601:EXCH] Sent: Friday, April 05, 2002 10:13 AM To: midcom@ietf.org Cc: 'Melinda Shore'; Pete Cordell Subject: [midcom] Summary of Volunteers for Protocol Evaluation Documents & one las t plea for additional volunteers Well, the volunteers for protocols remain as follows: MEGACO - Sanjoy Sen [sanjoy@nortelnetworks.com] COPS - Louis-Nicolas Hamer [nhamer@nortelnetworks.com] RSIP - James Renkel [James_Renkel@3com.com] SNMP/SMI - Juergen Quittek [quittek@ccrle.nec.de] There was a single response to my proposal to include some of the others. Pete provided a brief description of why SOCKS wouldn't be suitable. Unfortunately, without more support or "volunteers" the task of including this sort of information in the document isn't practical. Subsequent list discussion does show that there is a level of interest in these others, particularly DIAMETER. So, I'd like to do one last plea for volunteers for some of these others. The deadline for the intial submission is April 19th, thus I think it's still reasonable for folks to step forward and still take these on. These don't have to be extremely long documents but MUST cover the items highlighted in section 4.1 of the template at: http://www.obsidian97.com/draft-midcom-protocol-eval-template.txt . As a reminder, the timeline for these contributions is: April 19th Final cutoff for specific protocol drafts. * Drafts must be as objective as possible, identify the applicability to the framework and clearly identify the requirements that are satisfied, those that are "partially" satisfied, and those that are NOT satisfied. April 19th- May 3rd Mailing list discussion of specific protocol drafts, allowing authors to incorporate WG feedback into their contribution to improve comparison and add completeness. May 10th Deadline for any updates to protocol drafts. So, are there any additional volunteers? If I don't hear anything by 5PM EST today, we'll go forward with the 4 above listed protocols for the content of the document. Mary. Editor, MIDCOM Protocol Evalation Document -----Original Message----- From: Barnes, Mary [NGC:B601:EXCH] Sent: Wednesday, April 03, 2002 10:32 AM To: 'Melinda Shore'; Pete Cordell; midcom@ietf.org Subject: RE: [midcom] Protocol evaluation contribution reminder With my editor's hat on... There seems to be general WG interest in visiting a larger number of protocols. At this point, I've not taken any of these queries as "volunteering" to do these evaluations of these other protocols. With my editor's hat off... I think it's a really good idea to do a minimal evaluation of several of the protocols that have been put forth over the past couple days (DIAMETER, SOCKS, RSVP, etc.). I do realize that some of these have already been previously considered and already discarded, but from a completeness perspective, it would be really useful to capture why they were discarded or considered inappropriate. I have a feeling that the reason why people that have suggested these haven't volunteered has more to do with that limitation of only 24 hours in a given day versus lack of interest. With my editor's hat back on... I would suggest we add an additional section to the Protocol Evaluation document template to cover these other protocols. What this would require from the WG would be some discussion on the list to compile this information or "volunteers" (that word again) to provide minimal content for the protocol evaluation document for these other protocols (i.e. just a brief overview and summary of Pros/cons (per the requirements) and perhaps a recommendation as to why this wouldn't be appropriate as the MIDCOM protocol). Now, I can see problems with doing this as it's possible one of these others might actually be better and we've not necessarily evaluated these as thoroughly as the others (although, Melinda seems to be indicating that a certain level of analysis had been previously done in an informal manner on some of these others). So, what do people think about this proposal? Mary. -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Wednesday, April 03, 2002 9:13 AM To: Pete Cordell; midcom@ietf.org Subject: Re: [midcom] Protocol evaluation contribution reminder At 01:01 PM 4/3/02 +0100, Pete Cordell wrote: >SOCKS would seem to be a candidate also. Or do people already know that it >is not useful? SOCKS would require significant extension, and I think that its basic model is actually covered in a more general way by RSIP. It's a reasonable protocol to investigate, though. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 5 10:58:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08157 for ; Fri, 5 Apr 2002 10:58:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA09876 for midcom-archive@odin.ietf.org; Fri, 5 Apr 2002 10:58:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09127; Fri, 5 Apr 2002 10:45:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09076 for ; Fri, 5 Apr 2002 10:45:53 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07877 for ; Fri, 5 Apr 2002 10:45:42 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g35FjEw20927 for ; Fri, 5 Apr 2002 10:45:14 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 10:45:14 -0500 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A276@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Joel M. Halpern'" , midcom@ietf.org Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Fri, 5 Apr 2002 10:45:13 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org If the purpose of the Midcom protocol is just to open holes, life is very easy -- you can't ever get contradictions. Can I confirm that the Action is always "allow", and never "deny"? (That's assuming that one closes holes or at least reverts to default policy by deactivating the Policy Rule). -----Original Message----- From: Joel M. Halpern [mailto:joel@stevecrocker.com] Sent: Friday, April 05, 2002 9:34 AM To: midcom@ietf.org Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content I believe that the problem turns on how large a range of "rules" we want to allow. My understanding of the goal is to allow a controlling entity to: 1) create some holes that will allow traffic to pass through the middle box 2) find out certain things about these holes (for NAT) 3) provide auxiliary processing for some packets. Note that for cases 1 and 2, there is not much trouble. Overlapping holes merely means that that hole remains open as long as either requestor needs it. As far as I can tell, it is only the "auxilliary processing" case that makes life complicated. It would seem that we could again say "both" for that. We are not providing arbitrary policy management. At the same time, declaring that two servers can not open overlapping holes in the same firewall / NAT would seem counter-factual. Yours, Joel M. Halpern At 01:16 PM 4/5/2002 +0200, Juergen Quittek wrote: >Sanjoy, > >--On 04 April 2002 17:04 -0600 Sanjoy Sen wrote: >> >>Inline. >> >> >>-----Original Message----- >>From: Taylor, Tom-PT [CAR:B800:EXCH] >>Sent: Thursday, April 04, 2002 12:57 PM >>To: 'Martin Stiemerling' >>Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] >>Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content >> >> >> >>That's two people so far who have said requests should be satisfied >>completely >>or not at all. Shall we take this as the working assumption? >> >>First-come-first-serve vs. policy hides another issue: how to allow multiple >>authorized agents to work on the same ruleset (requirement 2.2.7). >>Our proposals so far assumed this was handled through a policy mechanism. >>There is a distinction, of course, between two agents operating on the same >>Policy Rule Identifier (which is perhaps what 2.2.7 permits) and two agents >>defining identical rulesets with different Policy Rule Identifiers. >>So I have a couple of questions for the WG: >> >> 1) Does the protocol address the possibility of two agents defining >> overlapping rulesets and if so, are conflicts handled on a >> first-come-first-served basis? >> >>[SS] The protocol has to allow overlapping rulesets because multiple agents >>are installing rulesets independently and there're bound to be overlaps in, >>say, the filter spec. Question is, what happens when there is a >>contradiction. >>Requirement 2.2.11 seems to suggest that we need to allow the later agent >>to win, >>at least, under special circumstances. For example, a Midcom agent installs a >>ruleset allowing packets from the address range 100.10.*.* to pass through, >>but at a later time, the firewall administrator wants to create a ruleset >>disallowing packets from 100.10.50.10. I would like to think that the >>firewall >>administrator would have the last say. An administrator Agent has the highest >>priority. > >I did not yet consider the midcom protocol as the interface for a system >administrator to consider the firewall. I think this taks includes restricting >the the midcom interface's access to firewall control. So if the administrator >wants to disallow packets from 100.10.50.10, he should do it by configuring >the access rights of the midcom server running at the firewall, for example by >modifying the midcom serve configuration files. > >But maybe I'm wrong here. I considered midcom to be used for temporary >configurations by users or applications but not as a mean for permanent >configuration of the firewall as it is done by the administrator. > >So, I clearly vote for not having priorities in order to KISS. However, if >the WG decides to support also administrator configuration running over >a midcom protocol, then it should be enough to have exactly two priorities: >administrator and user (and first-come-first-serve per priority). > >> >>IMO, an Agent priority list makes sense, with an agent higher up in the >>priority list can modify/revoke rulesets created by lower priority agents. >>For agents of same priority, a first-come-first-serve approach may be more >>suitable. >> >> 2) Does the protocol need a formal delegation capability, so that Agent A >>can tell the Middlebox that Agent B can make requests affecting Policy Rule >>Identifier x? > >I think we do not need this at all. First, the scenario would be rather >a rare one to happen. Second this increases complexity significantly on >server side and on client side. More state need to be kept an more message >types are required. We should not overdesign the protocol and avoid all >complexity that is not required by a strong usage scenario. > > Juergen >-- >Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 >NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 >Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > >>Here we would distinguish between sharing of authority (both Agent A and >>Agent B can manipulate the Policy Rule) vs. handoff (Agent A gives up its >>authority to Agent B). Which one might we want, if we want either? >>I visualize a message exchange of the form: >> >>[SS] Since we're requiring the Middlebox to report unsolicitated messages >>to the Agent, we can do this in another way. When there is an attempt by >>Agent B to install a ruleset which overlaps with and has contradictory >>action(s) to one that has been installed by Agent A, then the Middlebox can >>send a notification message reporting this event to A with Agent B's id. >>Agent A may or may not allow this. If disallowed, the Middlebox may either >>reject B's request to install or suggests an alternative/modified ruleset >>by sending B an error message. >> >> Agent A Middlebox Agent B >> >> Grant(Policy Rule Id x, Agent B) >> -------------------------------> >> Notify (Grant, Policy Rule Id x) >> Grant Acknowledge ---------------------------> >> <------------------------------- >> Notify Acknowledge >> <--------------------------- >> >>Sorry about the really theoretical stuff -- it was something I had to think >>through clearly for myself, but I can see it wouldn't be generally helpful, >>so we can omit it or put it into an appendix. >> >>-----Original Message----- >>From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] >>Sent: Thursday, April 04, 2002 8:58 AM >>To: Taylor, Tom-PT [CAR:B800:EXCH] >>Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] >>Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content >> >>Hi, >> >>please find my comments embedded in the text. >> >>Regards >>Martin >> >>Tom-PT Taylor wrote: >> >>>This is the theoretical section of the I-D Cedric and I are working on. We >>>are still validating it against the various scenarios. >> >>Yes, it is very theoretical. We should aviod such text for internet >>drafts, because a lot of people won't even continue reading the entire >>document. >> >>>4 Structure And Comparison Of Policy Rules >>> >>>In this note, a Policy Rule is defined to be a set of terms of the form >> >>[...] >> >>>decide which action will apply in the region of overlap. By assumption, >>>these decision rules will be based on the combination of order of >>>specification and policy at the Middlebox. >>> >>>There are two possible cases: >>> >>>(1) The Policy Rule associated with each of the two {Filter, Action} pairs >>>must be installed completely or not at all. In this case, if there is a >>>conflict between the two rules in the zone of overlap, the lower-priority >>>Policy Rule will be disallowed (if it was the later arrival) or deactivated >>>(if it was already installed). >> >>This sounds very complicated and with a lot of administrative overhead. >>I prefer Jiri's idea of disallowing overlapping rules at all and using a >>first come, first served scheme, instead of priorities. Should there be >>any conflict, reject the latest policy rule request. >> >>> >>>(2) The Policy Rule which has lower priority in the zone of conflict allows >>>for partial implementation. Thus the desired {Filter, Action} pair is >>>modified to exclude the zone of overlap. There are two sub-cases: >> >>Hmm, how to tell the agent, that his rule request has been fulfilled >>only partial? My opinion is, that the agent wants exactly this policy >>rule and if he can't get this, tell him! > > > >_______________________________________________ >midcom mailing list >midcom@ietf.org >https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 5 11:56:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09690 for ; Fri, 5 Apr 2002 11:55:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA12919 for midcom-archive@odin.ietf.org; Fri, 5 Apr 2002 11:55:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12615; Fri, 5 Apr 2002 11:44:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12587 for ; Fri, 5 Apr 2002 11:44:30 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09426 for ; Fri, 5 Apr 2002 11:44:23 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g35Ghtw28193 for ; Fri, 5 Apr 2002 11:43:55 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 11:43:56 -0500 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A277@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Martin Stiemerling'" , "Sanjoy Sen" Cc: "'Jiri Kuthan'" , midcom@ietf.org, "Cedric Aoun" Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Fri, 5 Apr 2002 11:43:54 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Assuming that contradictions are possible (see my previous message), we should distinguish two cases: - a specific Agent contradicts a Policy Rule installed previously by that same Agent - a specific Agent contradicts a Policy Rule installed by another Agent. An underlying premise of our proposed semantics is that each Policy Rule (defined as a set of {Filter, Action} pairs with a specific Policy Rule Identifier) has one or more owners. That is, the Middlebox remembers the Agent(s) who installed those rules. Whether more than one Agent should be able to work with the same Policy Rule is a matter for discussion, though I sense an inclination not to allow this. (But it seems to me that an Administrator should be able to audit all installed Policy Rules and deactivate any of them if need be.) On the other hand, I think it is accepted that different Policy Rules could overlap in their scope. So I'll concentrate my discussion on the case where a new Policy Rule is in conflict with a previously installed Policy Rule. I would suggest a general approach to conflicts of this form: - If an Agent contradicts itself, the Middlebox denies the new Policy Rule Request. It returns an appropriate reason code and the Policy Rule Identifier of the rule which is in conflict. The Agent then has the information it needs to choose between modifying the already-existing rule to accommodate the new conditions or giving up on the new Policy Rule. - If an Agent contradicts another Agent, Agent priorities come into play. I'm happy enough to allow only two priorities: Administrator and others, but I'm not sure we need to specify this, only that there exists a hierarchy of Agent priorities. The general rule is then that the Policy Rule installed by the higher priority agent prevails and the other one is rejected or deactivated as the case may be. Between equal-priority Agents, existing Policy Rules take priority over new ones. One open question is what diagnostic information should be supplied when a Policy Rule is rejected or deactivated. I see the following possibilities: (1) The Middlebox computes and returns a modified Policy Rule that would be consistent with the over-riding Policy Rule. (2) The Middlebox returns the complete contents of the over-riding Policy Rule. (3) The Middlebox returns the (sub)set of {Filter, Action} pairs within the over-riding Policy Rule which are in conflict with the disallowed Policy Rule. (4) The Middlebox returns a set of filters which describe the precise area of conflict with the over-riding Policy Rule. I have a bit of a concern with privacy which inclines me to alternative (4). -----Original Message----- From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] Sent: Friday, April 05, 2002 9:57 AM To: Sen, Sanjoy [NGC:B692:EXCH] Cc: 'Jiri Kuthan'; Taylor, Tom-PT [CAR:B800:EXCH]; midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content Sanjoy Sen wrote: > How will then the following requirement from Midcom requirements draft > be satisfied? > ***** > 2.2.11. > > It should be possible to define rulesets that contain a more spe- > cific filter spec than an overlapping ruleset. This should allow > agents to request actions for the subset that contradict those of > the overlapping set. > ***** > > Whether you want it or not, there would be overlapping rulesets because > the filterspec may overlap for different rulesets installed by > independent agents. The question - who wins when there're contradictory > actions is moot because the requirement above seems to suggest that we > need to allow contradictory behavior. The questions is, who will decide how to behave in such a case? There are so many combinations of firewall/NAT configurations which will make it difficult to define a stable behaviour, i.e. how to react with this overlapping set. Furthermore, the requirement starts with "should"... Martin -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 5 12:37:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11126 for ; Fri, 5 Apr 2002 12:37:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16778 for midcom-archive@odin.ietf.org; Fri, 5 Apr 2002 12:37:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16580; Fri, 5 Apr 2002 12:32:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16555 for ; Fri, 5 Apr 2002 12:32:14 -0500 (EST) Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10989 for ; Fri, 5 Apr 2002 12:32:09 -0500 (EST) From: James_Renkel@3com.com Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g35HVpA23548; Fri, 5 Apr 2002 09:31:51 -0800 (PST) Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79]) by opal.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g35HW7g22263; Fri, 5 Apr 2002 09:32:07 -0800 (PST) Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content To: "Tom-PT Taylor" Cc: "'Joel M. Halpern'" , midcom@ietf.org Date: Fri, 5 Apr 2002 11:32:02 -0600 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I think what Tom is suggesting here would lead to the following general operational scenario: 1) a middle-box "straight from the factory" by default allows all pin-holes and/or translations to be established, though none are yet actually established; 2) the network administrator, using a network management protocol, i.e., *NOT* the midcom protocol, defines what is permitted operationally, i.e., an operating policy, probably by defining a whole bunch of deny rules that define what is not permitted; the policy may be defined directly in the middlebox or separately in a policy server that is referenced by the middlebox. 3) the middlebox dynamically establishes pin-holes and/or translations, either: 3.1) implicitly (i.e., a packet shows up that does not match an existing ruleset); or 3.2) explicitly (i.e., an application (agent) uses the midcom protocol to request one), SO LONG AS the dynamically created pin-holes and translations are permitted or not denied by the policy set by the administrator AND don't conflict with previous pin-holes and translations; 4) the middlebox dynamically removes pin-holes and/or translations either: 3.1) implicitly, when they time-out; 3.2) explicitly, upon request from the application (agent) that established the pin-hole and/or translation, again using the midcom protocol; or 3.3) explicitly, by the middlebox administrator, again using a network management protocol, *NOT* the midcom protocol. I like this operational scenario because it nicely scopes what the midcom protocol MUST do, i.e., just permit the establishment and removal of pin-holes and translations by application (agents). Anything beyond that is gravy, should be looked at with great skepticism, and if adopted into the midcom protocol should be optional in middlebox implementations. And, of course, ya have to deal with all aspects of security. Jim "Tom-PT Taylor"@ietf.org on 04/05/2002 09:45:13 AM Sent by: midcom-admin@ietf.org To: "'Joel M. Halpern'" , midcom@ietf.org cc: Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content If the purpose of the Midcom protocol is just to open holes, life is very easy -- you can't ever get contradictions. Can I confirm that the Action is always "allow", and never "deny"? (That's assuming that one closes holes or at least reverts to default policy by deactivating the Policy Rule). -----Original Message----- From: Joel M. Halpern [mailto:joel@stevecrocker.com] Sent: Friday, April 05, 2002 9:34 AM To: midcom@ietf.org Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content I believe that the problem turns on how large a range of "rules" we want to allow. My understanding of the goal is to allow a controlling entity to: 1) create some holes that will allow traffic to pass through the middle box 2) find out certain things about these holes (for NAT) 3) provide auxiliary processing for some packets. Note that for cases 1 and 2, there is not much trouble. Overlapping holes merely means that that hole remains open as long as either requestor needs it. As far as I can tell, it is only the "auxilliary processing" case that makes life complicated. It would seem that we could again say "both" for that. We are not providing arbitrary policy management. At the same time, declaring that two servers can not open overlapping holes in the same firewall / NAT would seem counter-factual. Yours, Joel M. Halpern At 01:16 PM 4/5/2002 +0200, Juergen Quittek wrote: >Sanjoy, > >--On 04 April 2002 17:04 -0600 Sanjoy Sen wrote: >> >>Inline. >> >> >>-----Original Message----- >>From: Taylor, Tom-PT [CAR:B800:EXCH] >>Sent: Thursday, April 04, 2002 12:57 PM >>To: 'Martin Stiemerling' >>Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] >>Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content >> >> >> >>That's two people so far who have said requests should be satisfied >>completely >>or not at all. Shall we take this as the working assumption? >> >>First-come-first-serve vs. policy hides another issue: how to allow multiple >>authorized agents to work on the same ruleset (requirement 2.2.7). >>Our proposals so far assumed this was handled through a policy mechanism. >>There is a distinction, of course, between two agents operating on the same >>Policy Rule Identifier (which is perhaps what 2.2.7 permits) and two agents >>defining identical rulesets with different Policy Rule Identifiers. >>So I have a couple of questions for the WG: >> >> 1) Does the protocol address the possibility of two agents defining >> overlapping rulesets and if so, are conflicts handled on a >> first-come-first-served basis? >> >>[SS] The protocol has to allow overlapping rulesets because multiple agents >>are installing rulesets independently and there're bound to be overlaps in, >>say, the filter spec. Question is, what happens when there is a >>contradiction. >>Requirement 2.2.11 seems to suggest that we need to allow the later agent >>to win, >>at least, under special circumstances. For example, a Midcom agent installs a >>ruleset allowing packets from the address range 100.10.*.* to pass through, >>but at a later time, the firewall administrator wants to create a ruleset >>disallowing packets from 100.10.50.10. I would like to think that the >>firewall >>administrator would have the last say. An administrator Agent has the highest >>priority. > >I did not yet consider the midcom protocol as the interface for a system >administrator to consider the firewall. I think this taks includes restricting >the the midcom interface's access to firewall control. So if the administrator >wants to disallow packets from 100.10.50.10, he should do it by configuring >the access rights of the midcom server running at the firewall, for example by >modifying the midcom serve configuration files. > >But maybe I'm wrong here. I considered midcom to be used for temporary >configurations by users or applications but not as a mean for permanent >configuration of the firewall as it is done by the administrator. > >So, I clearly vote for not having priorities in order to KISS. However, if >the WG decides to support also administrator configuration running over >a midcom protocol, then it should be enough to have exactly two priorities: >administrator and user (and first-come-first-serve per priority). > >> >>IMO, an Agent priority list makes sense, with an agent higher up in the >>priority list can modify/revoke rulesets created by lower priority agents. >>For agents of same priority, a first-come-first-serve approach may be more >>suitable. >> >> 2) Does the protocol need a formal delegation capability, so that Agent A >>can tell the Middlebox that Agent B can make requests affecting Policy Rule >>Identifier x? > >I think we do not need this at all. First, the scenario would be rather >a rare one to happen. Second this increases complexity significantly on >server side and on client side. More state need to be kept an more message >types are required. We should not overdesign the protocol and avoid all >complexity that is not required by a strong usage scenario. > > Juergen >-- >Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 >NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 >Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > >>Here we would distinguish between sharing of authority (both Agent A and >>Agent B can manipulate the Policy Rule) vs. handoff (Agent A gives up its >>authority to Agent B). Which one might we want, if we want either? >>I visualize a message exchange of the form: >> >>[SS] Since we're requiring the Middlebox to report unsolicitated messages >>to the Agent, we can do this in another way. When there is an attempt by >>Agent B to install a ruleset which overlaps with and has contradictory >>action(s) to one that has been installed by Agent A, then the Middlebox can >>send a notification message reporting this event to A with Agent B's id. >>Agent A may or may not allow this. If disallowed, the Middlebox may either >>reject B's request to install or suggests an alternative/modified ruleset >>by sending B an error message. >> >> Agent A Middlebox Agent B >> >> Grant(Policy Rule Id x, Agent B) >> -------------------------------> >> Notify (Grant, Policy Rule Id x) >> Grant Acknowledge ---------------------------> >> <------------------------------- >> Notify Acknowledge >> <--------------------------- >> >>Sorry about the really theoretical stuff -- it was something I had to think >>through clearly for myself, but I can see it wouldn't be generally helpful, >>so we can omit it or put it into an appendix. >> >>-----Original Message----- >>From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] >>Sent: Thursday, April 04, 2002 8:58 AM >>To: Taylor, Tom-PT [CAR:B800:EXCH] >>Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] >>Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content >> >>Hi, >> >>please find my comments embedded in the text. >> >>Regards >>Martin >> >>Tom-PT Taylor wrote: >> >>>This is the theoretical section of the I-D Cedric and I are working on. We >>>are still validating it against the various scenarios. >> >>Yes, it is very theoretical. We should aviod such text for internet >>drafts, because a lot of people won't even continue reading the entire >>document. >> >>>4 Structure And Comparison Of Policy Rules >>> >>>In this note, a Policy Rule is defined to be a set of terms of the form >> >>[...] >> >>>decide which action will apply in the region of overlap. By assumption, >>>these decision rules will be based on the combination of order of >>>specification and policy at the Middlebox. >>> >>>There are two possible cases: >>> >>>(1) The Policy Rule associated with each of the two {Filter, Action} pairs >>>must be installed completely or not at all. In this case, if there is a >>>conflict between the two rules in the zone of overlap, the lower-priority >>>Policy Rule will be disallowed (if it was the later arrival) or deactivated >>>(if it was already installed). >> >>This sounds very complicated and with a lot of administrative overhead. >>I prefer Jiri's idea of disallowing overlapping rules at all and using a >>first come, first served scheme, instead of priorities. Should there be >>any conflict, reject the latest policy rule request. >> >>> >>>(2) The Policy Rule which has lower priority in the zone of conflict allows >>>for partial implementation. Thus the desired {Filter, Action} pair is >>>modified to exclude the zone of overlap. There are two sub-cases: >> >>Hmm, how to tell the agent, that his rule request has been fulfilled >>only partial? My opinion is, that the agent wants exactly this policy >>rule and if he can't get this, tell him! > > > >_______________________________________________ >midcom mailing list >midcom@ietf.org >https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 5 13:37:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12586 for ; Fri, 5 Apr 2002 13:37:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA20732 for midcom-archive@odin.ietf.org; Fri, 5 Apr 2002 13:37:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20334; Fri, 5 Apr 2002 13:31:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20289 for ; Fri, 5 Apr 2002 13:31:30 -0500 (EST) Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12413 for ; Fri, 5 Apr 2002 13:31:26 -0500 (EST) From: James_Renkel@3com.com Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g35IV3A04981; Fri, 5 Apr 2002 10:31:03 -0800 (PST) Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79]) by opal.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g35IVIg03340; Fri, 5 Apr 2002 10:31:19 -0800 (PST) Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content To: "Tom-PT Taylor" Cc: "'Martin Stiemerling'" , "Sanjoy Sen", "'Jiri Kuthan'" , midcom@ietf.org, "Cedric Aoun" Date: Fri, 5 Apr 2002 12:25:11 -0600 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org It seems to me that we're getting into an area here that might be described as "conflict resolution between requests from different applications / agents". IMHO, this can get real hairy, real quick, and might best be declared to be out of scope for the midcom protocol, at least for now. That said, I have no problem with the middlebox, when presented with a conflicting request, reporting to the "conflictor" and the "conflictee" the identities of the other party in the conflict, IF THEY HAVE AUTHORIZED THE MIDDLEBOX TO DO SO. Anything beyond that, I believe, should be left to the applications / agents to work out for themselves in some way not specified in the midcom protocol, using some other protocol, not the midcom protocol. Then one or the other or both would adjust their established or requested filters with the middlebox accordingly, so they hopefully no longer conflicted. Once we have some more experience with this, maybe we will want to add something to version 2 of the midcom protocol (Remember, it is required to be compatibly extensible, perhaps just for reasons like this.). If we are going to deal with this now, I think we need to have some very, very, very specific use cases to justify this capability, not just "navel scratchings". Also, as as I hinted in a separate e-mail, if a "big" capabiltiy in this area were included in the midcom protocol, I would want it to be optional in implementation so that, e.g., SOHO cable/DSL/ISDN middleboxes would not have to implement it to be RFC compliant. I think trying to deal with this now may be premature, but I could be wrong. Jim "Tom-PT Taylor"@ietf.org on 04/05/2002 10:43:54 AM Sent by: midcom-admin@ietf.org To: "'Martin Stiemerling'" , "Sanjoy Sen" cc: "'Jiri Kuthan'" , midcom@ietf.org, "Cedric Aoun" Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Assuming that contradictions are possible (see my previous message), we should distinguish two cases: - a specific Agent contradicts a Policy Rule installed previously by that same Agent - a specific Agent contradicts a Policy Rule installed by another Agent. An underlying premise of our proposed semantics is that each Policy Rule (defined as a set of {Filter, Action} pairs with a specific Policy Rule Identifier) has one or more owners. That is, the Middlebox remembers the Agent(s) who installed those rules. Whether more than one Agent should be able to work with the same Policy Rule is a matter for discussion, though I sense an inclination not to allow this. (But it seems to me that an Administrator should be able to audit all installed Policy Rules and deactivate any of them if need be.) On the other hand, I think it is accepted that different Policy Rules could overlap in their scope. So I'll concentrate my discussion on the case where a new Policy Rule is in conflict with a previously installed Policy Rule. I would suggest a general approach to conflicts of this form: - If an Agent contradicts itself, the Middlebox denies the new Policy Rule Request. It returns an appropriate reason code and the Policy Rule Identifier of the rule which is in conflict. The Agent then has the information it needs to choose between modifying the already-existing rule to accommodate the new conditions or giving up on the new Policy Rule. - If an Agent contradicts another Agent, Agent priorities come into play. I'm happy enough to allow only two priorities: Administrator and others, but I'm not sure we need to specify this, only that there exists a hierarchy of Agent priorities. The general rule is then that the Policy Rule installed by the higher priority agent prevails and the other one is rejected or deactivated as the case may be. Between equal-priority Agents, existing Policy Rules take priority over new ones. One open question is what diagnostic information should be supplied when a Policy Rule is rejected or deactivated. I see the following possibilities: (1) The Middlebox computes and returns a modified Policy Rule that would be consistent with the over-riding Policy Rule. (2) The Middlebox returns the complete contents of the over-riding Policy Rule. (3) The Middlebox returns the (sub)set of {Filter, Action} pairs within the over-riding Policy Rule which are in conflict with the disallowed Policy Rule. (4) The Middlebox returns a set of filters which describe the precise area of conflict with the over-riding Policy Rule. I have a bit of a concern with privacy which inclines me to alternative (4). -----Original Message----- From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] Sent: Friday, April 05, 2002 9:57 AM To: Sen, Sanjoy [NGC:B692:EXCH] Cc: 'Jiri Kuthan'; Taylor, Tom-PT [CAR:B800:EXCH]; midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content Sanjoy Sen wrote: > How will then the following requirement from Midcom requirements draft > be satisfied? > ***** > 2.2.11. > > It should be possible to define rulesets that contain a more spe- > cific filter spec than an overlapping ruleset. This should allow > agents to request actions for the subset that contradict those of > the overlapping set. > ***** > > Whether you want it or not, there would be overlapping rulesets because > the filterspec may overlap for different rulesets installed by > independent agents. The question - who wins when there're contradictory > actions is moot because the requirement above seems to suggest that we > need to allow contradictory behavior. The questions is, who will decide how to behave in such a case? There are so many combinations of firewall/NAT configurations which will make it difficult to define a stable behaviour, i.e. how to react with this overlapping set. Furthermore, the requirement starts with "should"... Martin -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 5 13:45:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12891 for ; Fri, 5 Apr 2002 13:45:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA21328 for midcom-archive@odin.ietf.org; Fri, 5 Apr 2002 13:45:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20900; Fri, 5 Apr 2002 13:39:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20815 for ; Fri, 5 Apr 2002 13:39:10 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12665 for ; Fri, 5 Apr 2002 13:39:06 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g35Icae06873; Fri, 5 Apr 2002 13:38:36 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 13:38:36 -0500 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A279@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'James_Renkel@3com.com'" Cc: midcom@ietf.org Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Fri, 5 Apr 2002 13:38:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCD0.E837AA38" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DCD0.E837AA38 Content-Type: text/plain; charset="iso-8859-1" Well, if the conflict-free model you postulated in your previous note is accepted by everyone as valid, we don't need to worry about this anyway. -----Original Message----- From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] Sent: Friday, April 05, 2002 1:25 PM To: Taylor, Tom-PT [CAR:B800:EXCH] Cc: 'Martin Stiemerling'; Sen, Sanjoy [NGC:B692:EXCH]; 'Jiri Kuthan'; midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content It seems to me that we're getting into an area here that might be described as "conflict resolution between requests from different applications / agents". IMHO, this can get real hairy, real quick, and might best be declared to be out of scope for the midcom protocol, at least for now. That said, I have no problem with the middlebox, when presented with a conflicting request, reporting to the "conflictor" and the "conflictee" the identities of the other party in the conflict, IF THEY HAVE AUTHORIZED THE MIDDLEBOX TO DO SO. Anything beyond that, I believe, should be left to the applications / agents to work out for themselves in some way not specified in the midcom protocol, using some other protocol, not the midcom protocol. Then one or the other or both would adjust their established or requested filters with the middlebox accordingly, so they hopefully no longer conflicted. Once we have some more experience with this, maybe we will want to add something to version 2 of the midcom protocol (Remember, it is required to be compatibly extensible, perhaps just for reasons like this.). If we are going to deal with this now, I think we need to have some very, very, very specific use cases to justify this capability, not just "navel scratchings". Also, as as I hinted in a separate e-mail, if a "big" capabiltiy in this area were included in the midcom protocol, I would want it to be optional in implementation so that, e.g., SOHO cable/DSL/ISDN middleboxes would not have to implement it to be RFC compliant. I think trying to deal with this now may be premature, but I could be wrong. Jim "Tom-PT Taylor"@ietf.org on 04/05/2002 10:43:54 AM Sent by: midcom-admin@ietf.org To: "'Martin Stiemerling'" , "Sanjoy Sen" cc: "'Jiri Kuthan'" , midcom@ietf.org, "Cedric Aoun" Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Assuming that contradictions are possible (see my previous message), we should distinguish two cases: - a specific Agent contradicts a Policy Rule installed previously by that same Agent - a specific Agent contradicts a Policy Rule installed by another Agent. An underlying premise of our proposed semantics is that each Policy Rule (defined as a set of {Filter, Action} pairs with a specific Policy Rule Identifier) has one or more owners. That is, the Middlebox remembers the Agent(s) who installed those rules. Whether more than one Agent should be able to work with the same Policy Rule is a matter for discussion, though I sense an inclination not to allow this. (But it seems to me that an Administrator should be able to audit all installed Policy Rules and deactivate any of them if need be.) On the other hand, I think it is accepted that different Policy Rules could overlap in their scope. So I'll concentrate my discussion on the case where a new Policy Rule is in conflict with a previously installed Policy Rule. I would suggest a general approach to conflicts of this form: - If an Agent contradicts itself, the Middlebox denies the new Policy Rule Request. It returns an appropriate reason code and the Policy Rule Identifier of the rule which is in conflict. The Agent then has the information it needs to choose between modifying the already-existing rule to accommodate the new conditions or giving up on the new Policy Rule. - If an Agent contradicts another Agent, Agent priorities come into play. I'm happy enough to allow only two priorities: Administrator and others, but I'm not sure we need to specify this, only that there exists a hierarchy of Agent priorities. The general rule is then that the Policy Rule installed by the higher priority agent prevails and the other one is rejected or deactivated as the case may be. Between equal-priority Agents, existing Policy Rules take priority over new ones. One open question is what diagnostic information should be supplied when a Policy Rule is rejected or deactivated. I see the following possibilities: (1) The Middlebox computes and returns a modified Policy Rule that would be consistent with the over-riding Policy Rule. (2) The Middlebox returns the complete contents of the over-riding Policy Rule. (3) The Middlebox returns the (sub)set of {Filter, Action} pairs within the over-riding Policy Rule which are in conflict with the disallowed Policy Rule. (4) The Middlebox returns a set of filters which describe the precise area of conflict with the over-riding Policy Rule. I have a bit of a concern with privacy which inclines me to alternative (4). -----Original Message----- From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] Sent: Friday, April 05, 2002 9:57 AM To: Sen, Sanjoy [NGC:B692:EXCH] Cc: 'Jiri Kuthan'; Taylor, Tom-PT [CAR:B800:EXCH]; midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content Sanjoy Sen wrote: > How will then the following requirement from Midcom requirements draft > be satisfied? > ***** > 2.2.11. > > It should be possible to define rulesets that contain a more spe- > cific filter spec than an overlapping ruleset. This should allow > agents to request actions for the subset that contradict those of > the overlapping set. > ***** > > Whether you want it or not, there would be overlapping rulesets because > the filterspec may overlap for different rulesets installed by > independent agents. The question - who wins when there're contradictory > actions is moot because the requirement above seems to suggest that we > need to allow contradictory behavior. The questions is, who will decide how to behave in such a case? There are so many combinations of firewall/NAT configurations which will make it difficult to define a stable behaviour, i.e. how to react with this overlapping set. Furthermore, the requirement starts with "should"... Martin -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C1DCD0.E837AA38 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] MIDCOM SEmantics: Policy Rule Content

Well, if the conflict-free model you postulated in = your previous note is accepted by everyone as valid, we don't need to = worry about this anyway.

-----Original Message-----
From: James_Renkel@3com.com [mailto:James_Renkel@3com.com]<= /FONT>
Sent: Friday, April 05, 2002 1:25 PM
To: Taylor, Tom-PT [CAR:B800:EXCH]
Cc: 'Martin Stiemerling'; Sen, Sanjoy = [NGC:B692:EXCH]; 'Jiri Kuthan';
midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH]
Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule = Content



It seems to me that we're getting into an area here = that might be
described as "conflict resolution between = requests from different
applications / agents". IMHO, this can get real = hairy, real quick,
and might best be declared to be out of scope for = the midcom protocol,
at least for now.

That said, I have no problem with the middlebox, when = presented with a
conflicting request, reporting to the = "conflictor" and the "conflictee"
the identities of the other party in the conflict, = IF THEY HAVE AUTHORIZED
THE MIDDLEBOX TO DO SO.

Anything beyond that, I believe, should be left to = the applications /
agents to work out for themselves in some way not = specified in the midcom
protocol, using some other protocol, not the midcom = protocol. Then one
or the other or both would adjust their established = or requested filters
with the middlebox accordingly, so they hopefully no = longer conflicted.

Once we have some more experience with this, maybe we = will want to add
something to version 2 of the midcom protocol = (Remember, it is required
to be compatibly extensible, perhaps just for = reasons like this.). If we
are going to deal with this now, I think we need to = have some very, very,
very specific use cases to justify this capability, = not just "navel
scratchings".

Also, as as I hinted in a separate e-mail, if a = "big" capabiltiy in this
area were included in the midcom protocol, I would = want it to be optional
in implementation so that, e.g., SOHO cable/DSL/ISDN = middleboxes would not
have to implement it to be RFC compliant.

I think trying to deal with this now may be = premature, but I could be
wrong.

Jim





"Tom-PT = Taylor"<taylor@nortelnetworks.com>@ietf.org on 04/05/2002 = 10:43:54
AM

Sent by:  midcom-admin@ietf.org


To:   "'Martin Stiemerling'" = <Martin.Stiemerling@ccrle.nec.de>, "Sanjoy
      = Sen"<sanjoy@nortelnetworks.com>
cc:   "'Jiri Kuthan'" = <kuthan@fokus.gmd.de>, midcom@ietf.org, "Cedric
      = Aoun"<cedric.aoun@nortelnetworks.com>
Subject:  RE: [midcom] MIDCOM SEmantics: Policy = Rule Content


Assuming that contradictions are possible (see my = previous message), we
should distinguish two cases:
 - a specific Agent contradicts a Policy Rule = installed previously by that
same Agent
 - a specific Agent contradicts a Policy Rule = installed by another Agent.

An underlying premise of our proposed semantics is = that each Policy Rule
(defined as a set of {Filter, Action} pairs with a = specific Policy Rule
Identifier) has one or more owners.  That is, = the Middlebox remembers the
Agent(s) who installed those rules.

Whether more than one Agent should be able to work = with the same Policy
Rule
is a matter for discussion, though I sense an = inclination not to allow
this.
(But it seems to me that an Administrator should be = able to audit all
installed Policy Rules and deactivate any of them if = need be.)  On the
other
hand, I think it is accepted that different Policy = Rules could overlap in
their scope.  So I'll concentrate my discussion = on the case where a new
Policy Rule is in conflict with a previously = installed Policy Rule.

I would suggest a general approach to conflicts of = this form:

 - If an Agent contradicts itself, the Middlebox = denies the new Policy Rule
Request.  It returns an appropriate reason code = and the Policy Rule
Identifier of the rule which is in conflict.  = The Agent then has the
information it needs to choose between modifying the = already-existing rule
to accommodate the new conditions or giving up on = the new Policy Rule.

 - If an Agent contradicts another Agent, Agent = priorities come into play.
I'm happy enough to allow only two priorities: = Administrator and others,
but
I'm not sure we need to specify this, only that = there exists a hierarchy of
Agent priorities.  The general rule is then = that the Policy Rule installed
by the higher priority agent prevails and the other = one is rejected or
deactivated as the case may be.  Between = equal-priority Agents, existing
Policy Rules take priority over new ones.

One open question is what diagnostic information = should be supplied when a
Policy Rule is rejected or deactivated.  I see = the following possibilities:
(1) The Middlebox computes and returns a modified = Policy Rule that would be
consistent with the over-riding Policy Rule.
(2) The Middlebox returns the complete contents of = the over-riding Policy
Rule.
(3) The Middlebox returns the (sub)set of {Filter, = Action} pairs within the
over-riding Policy Rule which are in conflict with = the disallowed Policy
Rule.
(4) The Middlebox returns a set of filters which = describe the precise area
of conflict with the over-riding Policy Rule.

I have a bit of a concern with privacy which inclines = me to alternative
(4).

-----Original Message-----
From: Martin Stiemerling [mailto:Martin.Stiemerlin= g@ccrle.nec.de]
Sent: Friday, April 05, 2002 9:57 AM
To: Sen, Sanjoy [NGC:B692:EXCH]
Cc: 'Jiri Kuthan'; Taylor, Tom-PT [CAR:B800:EXCH]; = midcom@ietf.org;
Aoun, Cedric [QPD:MA01:EXCH]
Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule = Content


Sanjoy Sen wrote:

> How will then the following requirement from = Midcom requirements draft
> be satisfied?
> *****
> 2.2.11.
>
>      It should be = possible to define rulesets that contain a more spe-
>      cific filter spec = than an overlapping ruleset.  This should allow
>      agents to request = actions for the subset that contradict those of
>      the overlapping = set.
> *****

 >

> Whether you want it or not, there would be = overlapping rulesets because
> the filterspec may overlap for different = rulesets installed by
> independent agents. The question - who wins = when there're contradictory

> actions is moot because the requirement above = seems to suggest that we
> need to allow contradictory behavior.


The questions is, who will decide how to behave in = such a case? There
are so many combinations of firewall/NAT = configurations which will make
it difficult to define a stable behaviour, i.e. how = to react with this
overlapping set. Furthermore, the requirement starts = with "should"...

Martin
--
Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories  = Stiemerling@ccrle.nec.de
IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom




------_=_NextPart_001_01C1DCD0.E837AA38-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 5 14:04:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13521 for ; Fri, 5 Apr 2002 14:04:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA22505 for midcom-archive@odin.ietf.org; Fri, 5 Apr 2002 14:04:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21742; Fri, 5 Apr 2002 13:59:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21711 for ; Fri, 5 Apr 2002 13:59:12 -0500 (EST) Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13308 for ; Fri, 5 Apr 2002 13:59:07 -0500 (EST) From: James_Renkel@3com.com Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g35IwrA09825; Fri, 5 Apr 2002 10:58:53 -0800 (PST) Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79]) by opal.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g35Ix9g07619; Fri, 5 Apr 2002 10:59:09 -0800 (PST) Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content To: "Tom-PT Taylor" Cc: midcom@ietf.org Date: Fri, 5 Apr 2002 12:56:34 -0600 Message-ID: MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=86256B9200680EBC8f9e8a93df938690918c86256B9200680EBC" Content-Disposition: inline Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --0__=86256B9200680EBC8f9e8a93df938690918c86256B9200680EBC Content-type: text/plain; charset=us-ascii Tom, The model I proposed in my previous note is not conflict free. Having granted one filter request, a middlebox could very well be presented with another conflicting request from the same or a different application (agent). I suppose we could define filter capabilities to be so restrictive that no conflicts were ever possible, but I'm skeptical that such a definition is possible or useful. I think we can agree that the middlebox cannot simply grant the second request (unless it "undoes" the conflicting part of the first, already granted, request; but I, for one, don't want to go there.). And I wouldn't want it to reject the second request without some at least minimal explanation of why it did so. All I'm saying is that, sans compelling use cases to open the door of conflict resolution, we should limit ourselves to what might be described as "conflict identification", a necessary first step in the midcom protocol if the application (agent)s are to resolve the conflict with mechanisms outside of the midcom protocol. Jim "Tom-PT Taylor" on 04/05/2002 12:38:35 PM Sent by: "Tom-PT Taylor" To: James Renkel/MW/US/3Com cc: midcom@ietf.org Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Well, if the conflict-free model you postulated in your previous note is accepted by everyone as valid, we don't need to worry about this anyway. -----Original Message----- From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] Sent: Friday, April 05, 2002 1:25 PM To: Taylor, Tom-PT [CAR:B800:EXCH] Cc: 'Martin Stiemerling'; Sen, Sanjoy [NGC:B692:EXCH]; 'Jiri Kuthan'; midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content It seems to me that we're getting into an area here that might be described as "conflict resolution between requests from different applications / agents". IMHO, this can get real hairy, real quick, and might best be declared to be out of scope for the midcom protocol, at least for now. That said, I have no problem with the middlebox, when presented with a conflicting request, reporting to the "conflictor" and the "conflictee" the identities of the other party in the conflict, IF THEY HAVE AUTHORIZED THE MIDDLEBOX TO DO SO. Anything beyond that, I believe, should be left to the applications / agents to work out for themselves in some way not specified in the midcom protocol, using some other protocol, not the midcom protocol. Then one or the other or both would adjust their established or requested filters with the middlebox accordingly, so they hopefully no longer conflicted. Once we have some more experience with this, maybe we will want to add something to version 2 of the midcom protocol (Remember, it is required to be compatibly extensible, perhaps just for reasons like this.). If we are going to deal with this now, I think we need to have some very, very, very specific use cases to justify this capability, not just "navel scratchings". Also, as as I hinted in a separate e-mail, if a "big" capabiltiy in this area were included in the midcom protocol, I would want it to be optional in implementation so that, e.g., SOHO cable/DSL/ISDN middleboxes would not have to implement it to be RFC compliant. I think trying to deal with this now may be premature, but I could be wrong. Jim "Tom-PT Taylor"@ietf.org on 04/05/2002 10:43:54 AM Sent by: midcom-admin@ietf.org To: "'Martin Stiemerling'" , "Sanjoy Sen" cc: "'Jiri Kuthan'" , midcom@ietf.org, "Cedric Aoun" Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Assuming that contradictions are possible (see my previous message), we should distinguish two cases: - a specific Agent contradicts a Policy Rule installed previously by that same Agent - a specific Agent contradicts a Policy Rule installed by another Agent. An underlying premise of our proposed semantics is that each Policy Rule (defined as a set of {Filter, Action} pairs with a specific Policy Rule Identifier) has one or more owners. That is, the Middlebox remembers the Agent(s) who installed those rules. Whether more than one Agent should be able to work with the same Policy Rule is a matter for discussion, though I sense an inclination not to allow this. (But it seems to me that an Administrator should be able to audit all installed Policy Rules and deactivate any of them if need be.) On the other hand, I think it is accepted that different Policy Rules could overlap in their scope. So I'll concentrate my discussion on the case where a new Policy Rule is in conflict with a previously installed Policy Rule. I would suggest a general approach to conflicts of this form: - If an Agent contradicts itself, the Middlebox denies the new Policy Rule Request. It returns an appropriate reason code and the Policy Rule Identifier of the rule which is in conflict. The Agent then has the information it needs to choose between modifying the already-existing rule to accommodate the new conditions or giving up on the new Policy Rule. - If an Agent contradicts another Agent, Agent priorities come into play. I'm happy enough to allow only two priorities: Administrator and others, but I'm not sure we need to specify this, only that there exists a hierarchy of Agent priorities. The general rule is then that the Policy Rule installed by the higher priority agent prevails and the other one is rejected or deactivated as the case may be. Between equal-priority Agents, existing Policy Rules take priority over new ones. One open question is what diagnostic information should be supplied when a Policy Rule is rejected or deactivated. I see the following possibilities: (1) The Middlebox computes and returns a modified Policy Rule that would be consistent with the over-riding Policy Rule. (2) The Middlebox returns the complete contents of the over-riding Policy Rule. (3) The Middlebox returns the (sub)set of {Filter, Action} pairs within the over-riding Policy Rule which are in conflict with the disallowed Policy Rule. (4) The Middlebox returns a set of filters which describe the precise area of conflict with the over-riding Policy Rule. I have a bit of a concern with privacy which inclines me to alternative (4). -----Original Message----- From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] Sent: Friday, April 05, 2002 9:57 AM To: Sen, Sanjoy [NGC:B692:EXCH] Cc: 'Jiri Kuthan'; Taylor, Tom-PT [CAR:B800:EXCH]; midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content Sanjoy Sen wrote: > How will then the following requirement from Midcom requirements draft > be satisfied? > ***** > 2.2.11. > > It should be possible to define rulesets that contain a more spe- > cific filter spec than an overlapping ruleset. This should allow > agents to request actions for the subset that contradict those of > the overlapping set. > ***** > > Whether you want it or not, there would be overlapping rulesets because > the filterspec may overlap for different rulesets installed by > independent agents. The question - who wins when there're contradictory > actions is moot because the requirement above seems to suggest that we > need to allow contradictory behavior. The questions is, who will decide how to behave in such a case? There are so many combinations of firewall/NAT configurations which will make it difficult to define a stable behaviour, i.e. how to react with this overlapping set. Furthermore, the requirement starts with "should"... Martin -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom (See attached file: C.htm) --0__=86256B9200680EBC8f9e8a93df938690918c86256B9200680EBC Content-type: text/html; name="C.htm" Content-Disposition: attachment; filename="C.htm" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1NS4zNSI+DQo8VElUTEU+UkU6IFtt aWRjb21dIE1JRENPTSBTRW1hbnRpY3M6IFBvbGljeSBSdWxlIENvbnRlbnQ8L1RJVExFPg0KPC9I RUFEPg0KPEJPRFk+DQoNCjxQPjxGT05UIFNJWkU9Mj5XZWxsLCBpZiB0aGUgY29uZmxpY3QtZnJl ZSBtb2RlbCB5b3UgcG9zdHVsYXRlZCBpbiB5b3VyIHByZXZpb3VzIG5vdGUgaXMgYWNjZXB0ZWQg YnkgZXZlcnlvbmUgYXMgdmFsaWQsIHdlIGRvbid0IG5lZWQgdG8gd29ycnkgYWJvdXQgdGhpcyBh bnl3YXkuPC9GT05UPjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5Gcm9tOiBKYW1lc19SZW5rZWxAM2NvbS5j b20gWzxBIEhSRUY9Im1haWx0bzpKYW1lc19SZW5rZWxAM2NvbS5jb20iPm1haWx0bzpKYW1lc19S ZW5rZWxAM2NvbS5jb208L0E+XTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+U2VudDogRnJpZGF5 LCBBcHJpbCAwNSwgMjAwMiAxOjI1IFBNPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5UbzogVGF5 bG9yLCBUb20tUFQgW0NBUjpCODAwOkVYQ0hdPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5DYzog J01hcnRpbiBTdGllbWVybGluZyc7IFNlbiwgU2Fuam95IFtOR0M6QjY5MjpFWENIXTsgJ0ppcmkg S3V0aGFuJzs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPm1pZGNvbUBpZXRmLm9yZzsgQW91biwg Q2VkcmljIFtRUEQ6TUEwMTpFWENIXTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+U3ViamVjdDog UkU6IFttaWRjb21dIE1JRENPTSBTRW1hbnRpY3M6IFBvbGljeSBSdWxlIENvbnRlbnQ8L0ZPTlQ+ DQo8L1A+DQo8QlI+DQo8QlI+DQoNCjxQPjxGT05UIFNJWkU9Mj5JdCBzZWVtcyB0byBtZSB0aGF0 IHdlJ3JlIGdldHRpbmcgaW50byBhbiBhcmVhIGhlcmUgdGhhdCBtaWdodCBiZTwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+ZGVzY3JpYmVkIGFzICZxdW90O2NvbmZsaWN0IHJlc29sdXRpb24gYmV0 d2VlbiByZXF1ZXN0cyBmcm9tIGRpZmZlcmVudDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+YXBw bGljYXRpb25zIC8gYWdlbnRzJnF1b3Q7LiBJTUhPLCB0aGlzIGNhbiBnZXQgcmVhbCBoYWlyeSwg cmVhbCBxdWljayw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPmFuZCBtaWdodCBiZXN0IGJlIGRl Y2xhcmVkIHRvIGJlIG91dCBvZiBzY29wZSBmb3IgdGhlIG1pZGNvbSBwcm90b2NvbCw8L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yPmF0IGxlYXN0IGZvciBub3cuPC9GT05UPg0KPC9QPg0KDQo8UD48 Rk9OVCBTSVpFPTI+VGhhdCBzYWlkLCBJIGhhdmUgbm8gcHJvYmxlbSB3aXRoIHRoZSBtaWRkbGVi b3gsIHdoZW4gcHJlc2VudGVkIHdpdGggYTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Y29uZmxp Y3RpbmcgcmVxdWVzdCwgcmVwb3J0aW5nIHRvIHRoZSAmcXVvdDtjb25mbGljdG9yJnF1b3Q7IGFu ZCB0aGUgJnF1b3Q7Y29uZmxpY3RlZSZxdW90OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dGhl IGlkZW50aXRpZXMgb2YgdGhlIG90aGVyIHBhcnR5IGluIHRoZSBjb25mbGljdCwgSUYgVEhFWSBI QVZFIEFVVEhPUklaRUQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlRIRSBNSURETEVCT1ggVE8g RE8gU08uPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+QW55dGhpbmcgYmV5b25kIHRo YXQsIEkgYmVsaWV2ZSwgc2hvdWxkIGJlIGxlZnQgdG8gdGhlIGFwcGxpY2F0aW9ucyAvPC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj5hZ2VudHMgdG8gd29yayBvdXQgZm9yIHRoZW1zZWx2ZXMgaW4g c29tZSB3YXkgbm90IHNwZWNpZmllZCBpbiB0aGUgbWlkY29tPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj5wcm90b2NvbCwgdXNpbmcgc29tZSBvdGhlciBwcm90b2NvbCwgbm90IHRoZSBtaWRjb20g cHJvdG9jb2wuIFRoZW4gb25lPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5vciB0aGUgb3RoZXIg b3IgYm90aCB3b3VsZCBhZGp1c3QgdGhlaXIgZXN0YWJsaXNoZWQgb3IgcmVxdWVzdGVkIGZpbHRl cnM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPndpdGggdGhlIG1pZGRsZWJveCBhY2NvcmRpbmds eSwgc28gdGhleSBob3BlZnVsbHkgbm8gbG9uZ2VyIGNvbmZsaWN0ZWQuPC9GT05UPg0KPC9QPg0K DQo8UD48Rk9OVCBTSVpFPTI+T25jZSB3ZSBoYXZlIHNvbWUgbW9yZSBleHBlcmllbmNlIHdpdGgg dGhpcywgbWF5YmUgd2Ugd2lsbCB3YW50IHRvIGFkZDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ c29tZXRoaW5nIHRvIHZlcnNpb24gMiBvZiB0aGUgbWlkY29tIHByb3RvY29sIChSZW1lbWJlciwg aXQgaXMgcmVxdWlyZWQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnRvIGJlIGNvbXBhdGlibHkg ZXh0ZW5zaWJsZSwgcGVyaGFwcyBqdXN0IGZvciByZWFzb25zIGxpa2UgdGhpcy4pLiBJZiB3ZTwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+YXJlIGdvaW5nIHRvIGRlYWwgd2l0aCB0aGlzIG5vdywg SSB0aGluayB3ZSBuZWVkIHRvIGhhdmUgc29tZSB2ZXJ5LCB2ZXJ5LDwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+dmVyeSBzcGVjaWZpYyB1c2UgY2FzZXMgdG8ganVzdGlmeSB0aGlzIGNhcGFiaWxp dHksIG5vdCBqdXN0ICZxdW90O25hdmVsPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5zY3JhdGNo aW5ncyZxdW90Oy48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5BbHNvLCBhcyBhcyBJ IGhpbnRlZCBpbiBhIHNlcGFyYXRlIGUtbWFpbCwgaWYgYSAmcXVvdDtiaWcmcXVvdDsgY2FwYWJp bHRpeSBpbiB0aGlzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5hcmVhIHdlcmUgaW5jbHVkZWQg aW4gdGhlIG1pZGNvbSBwcm90b2NvbCwgSSB3b3VsZCB3YW50IGl0IHRvIGJlIG9wdGlvbmFsPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj5pbiBpbXBsZW1lbnRhdGlvbiBzbyB0aGF0LCBlLmcuLCBT T0hPIGNhYmxlL0RTTC9JU0ROIG1pZGRsZWJveGVzIHdvdWxkIG5vdDwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+aGF2ZSB0byBpbXBsZW1lbnQgaXQgdG8gYmUgUkZDIGNvbXBsaWFudC48L0ZPTlQ+ DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5JIHRoaW5rIHRyeWluZyB0byBkZWFsIHdpdGggdGhp cyBub3cgbWF5IGJlIHByZW1hdHVyZSwgYnV0IEkgY291bGQgYmU8L0ZPTlQ+DQo8QlI+PEZPTlQg U0laRT0yPndyb25nLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPkppbTwvRk9OVD4N CjwvUD4NCjxCUj4NCjxCUj4NCjxCUj4NCjxCUj4NCg0KPFA+PEZPTlQgU0laRT0yPiZxdW90O1Rv bS1QVCBUYXlsb3ImcXVvdDsmbHQ7dGF5bG9yQG5vcnRlbG5ldHdvcmtzLmNvbSZndDtAaWV0Zi5v cmcgb24gMDQvMDUvMjAwMiAxMDo0Mzo1NDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+QU08L0ZP TlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5TZW50IGJ5OiZuYnNwOyBtaWRjb20tYWRtaW5A aWV0Zi5vcmc8L0ZPTlQ+DQo8L1A+DQo8QlI+DQoNCjxQPjxGT05UIFNJWkU9Mj5UbzombmJzcDsm bmJzcDsgJnF1b3Q7J01hcnRpbiBTdGllbWVybGluZycmcXVvdDsgJmx0O01hcnRpbi5TdGllbWVy bGluZ0BjY3JsZS5uZWMuZGUmZ3Q7LCAmcXVvdDtTYW5qb3k8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTZW4mcXVvdDsmbHQ7c2Fuam95QG5v cnRlbG5ldHdvcmtzLmNvbSZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPmNjOiZuYnNwOyZu YnNwOyAmcXVvdDsnSmlyaSBLdXRoYW4nJnF1b3Q7ICZsdDtrdXRoYW5AZm9rdXMuZ21kLmRlJmd0 OywgbWlkY29tQGlldGYub3JnLCAmcXVvdDtDZWRyaWM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBb3VuJnF1b3Q7Jmx0O2NlZHJpYy5hb3Vu QG5vcnRlbG5ldHdvcmtzLmNvbSZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlN1YmplY3Q6 Jm5ic3A7IFJFOiBbbWlkY29tXSBNSURDT00gU0VtYW50aWNzOiBQb2xpY3kgUnVsZSBDb250ZW50 PC9GT05UPg0KPC9QPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpFPTI+QXNzdW1pbmcgdGhhdCBjb250 cmFkaWN0aW9ucyBhcmUgcG9zc2libGUgKHNlZSBteSBwcmV2aW91cyBtZXNzYWdlKSwgd2U8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPnNob3VsZCBkaXN0aW5ndWlzaCB0d28gY2FzZXM6PC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJzcDstIGEgc3BlY2lmaWMgQWdlbnQgY29udHJhZGljdHMg YSBQb2xpY3kgUnVsZSBpbnN0YWxsZWQgcHJldmlvdXNseSBieSB0aGF0PC9GT05UPg0KPEJSPjxG T05UIFNJWkU9Mj5zYW1lIEFnZW50PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJzcDstIGEg c3BlY2lmaWMgQWdlbnQgY29udHJhZGljdHMgYSBQb2xpY3kgUnVsZSBpbnN0YWxsZWQgYnkgYW5v dGhlciBBZ2VudC48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5BbiB1bmRlcmx5aW5n IHByZW1pc2Ugb2Ygb3VyIHByb3Bvc2VkIHNlbWFudGljcyBpcyB0aGF0IGVhY2ggUG9saWN5IFJ1 bGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPihkZWZpbmVkIGFzIGEgc2V0IG9mIHtGaWx0ZXIs IEFjdGlvbn0gcGFpcnMgd2l0aCBhIHNwZWNpZmljIFBvbGljeSBSdWxlPC9GT05UPg0KPEJSPjxG T05UIFNJWkU9Mj5JZGVudGlmaWVyKSBoYXMgb25lIG9yIG1vcmUgb3duZXJzLiZuYnNwOyBUaGF0 IGlzLCB0aGUgTWlkZGxlYm94IHJlbWVtYmVycyB0aGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PkFnZW50KHMpIHdobyBpbnN0YWxsZWQgdGhvc2UgcnVsZXMuPC9GT05UPg0KPC9QPg0KDQo8UD48 Rk9OVCBTSVpFPTI+V2hldGhlciBtb3JlIHRoYW4gb25lIEFnZW50IHNob3VsZCBiZSBhYmxlIHRv IHdvcmsgd2l0aCB0aGUgc2FtZSBQb2xpY3k8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlJ1bGU8 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPmlzIGEgbWF0dGVyIGZvciBkaXNjdXNzaW9uLCB0aG91 Z2ggSSBzZW5zZSBhbiBpbmNsaW5hdGlvbiBub3QgdG8gYWxsb3c8L0ZPTlQ+DQo8QlI+PEZPTlQg U0laRT0yPnRoaXMuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4oQnV0IGl0IHNlZW1zIHRvIG1l IHRoYXQgYW4gQWRtaW5pc3RyYXRvciBzaG91bGQgYmUgYWJsZSB0byBhdWRpdCBhbGw8L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yPmluc3RhbGxlZCBQb2xpY3kgUnVsZXMgYW5kIGRlYWN0aXZhdGUg YW55IG9mIHRoZW0gaWYgbmVlZCBiZS4pJm5ic3A7IE9uIHRoZTwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+b3RoZXI8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPmhhbmQsIEkgdGhpbmsgaXQgaXMg YWNjZXB0ZWQgdGhhdCBkaWZmZXJlbnQgUG9saWN5IFJ1bGVzIGNvdWxkIG92ZXJsYXAgaW48L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPnRoZWlyIHNjb3BlLiZuYnNwOyBTbyBJJ2xsIGNvbmNlbnRy YXRlIG15IGRpc2N1c3Npb24gb24gdGhlIGNhc2Ugd2hlcmUgYSBuZXc8L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPlBvbGljeSBSdWxlIGlzIGluIGNvbmZsaWN0IHdpdGggYSBwcmV2aW91c2x5IGlu c3RhbGxlZCBQb2xpY3kgUnVsZS48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5JIHdv dWxkIHN1Z2dlc3QgYSBnZW5lcmFsIGFwcHJvYWNoIHRvIGNvbmZsaWN0cyBvZiB0aGlzIGZvcm06 PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+Jm5ic3A7LSBJZiBhbiBBZ2VudCBjb250 cmFkaWN0cyBpdHNlbGYsIHRoZSBNaWRkbGVib3ggZGVuaWVzIHRoZSBuZXcgUG9saWN5IFJ1bGU8 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlJlcXVlc3QuJm5ic3A7IEl0IHJldHVybnMgYW4gYXBw cm9wcmlhdGUgcmVhc29uIGNvZGUgYW5kIHRoZSBQb2xpY3kgUnVsZTwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+SWRlbnRpZmllciBvZiB0aGUgcnVsZSB3aGljaCBpcyBpbiBjb25mbGljdC4mbmJz cDsgVGhlIEFnZW50IHRoZW4gaGFzIHRoZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+aW5mb3Jt YXRpb24gaXQgbmVlZHMgdG8gY2hvb3NlIGJldHdlZW4gbW9kaWZ5aW5nIHRoZSBhbHJlYWR5LWV4 aXN0aW5nIHJ1bGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnRvIGFjY29tbW9kYXRlIHRoZSBu ZXcgY29uZGl0aW9ucyBvciBnaXZpbmcgdXAgb24gdGhlIG5ldyBQb2xpY3kgUnVsZS48L0ZPTlQ+ DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4mbmJzcDstIElmIGFuIEFnZW50IGNvbnRyYWRpY3Rz IGFub3RoZXIgQWdlbnQsIEFnZW50IHByaW9yaXRpZXMgY29tZSBpbnRvIHBsYXkuPC9GT05UPg0K PEJSPjxGT05UIFNJWkU9Mj5JJ20gaGFwcHkgZW5vdWdoIHRvIGFsbG93IG9ubHkgdHdvIHByaW9y aXRpZXM6IEFkbWluaXN0cmF0b3IgYW5kIG90aGVycyw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PmJ1dDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+SSdtIG5vdCBzdXJlIHdlIG5lZWQgdG8gc3Bl Y2lmeSB0aGlzLCBvbmx5IHRoYXQgdGhlcmUgZXhpc3RzIGEgaGllcmFyY2h5IG9mPC9GT05UPg0K PEJSPjxGT05UIFNJWkU9Mj5BZ2VudCBwcmlvcml0aWVzLiZuYnNwOyBUaGUgZ2VuZXJhbCBydWxl IGlzIHRoZW4gdGhhdCB0aGUgUG9saWN5IFJ1bGUgaW5zdGFsbGVkPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj5ieSB0aGUgaGlnaGVyIHByaW9yaXR5IGFnZW50IHByZXZhaWxzIGFuZCB0aGUgb3Ro ZXIgb25lIGlzIHJlamVjdGVkIG9yPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5kZWFjdGl2YXRl ZCBhcyB0aGUgY2FzZSBtYXkgYmUuJm5ic3A7IEJldHdlZW4gZXF1YWwtcHJpb3JpdHkgQWdlbnRz LCBleGlzdGluZzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+UG9saWN5IFJ1bGVzIHRha2UgcHJp b3JpdHkgb3ZlciBuZXcgb25lcy48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5PbmUg b3BlbiBxdWVzdGlvbiBpcyB3aGF0IGRpYWdub3N0aWMgaW5mb3JtYXRpb24gc2hvdWxkIGJlIHN1 cHBsaWVkIHdoZW4gYTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+UG9saWN5IFJ1bGUgaXMgcmVq ZWN0ZWQgb3IgZGVhY3RpdmF0ZWQuJm5ic3A7IEkgc2VlIHRoZSBmb2xsb3dpbmcgcG9zc2liaWxp dGllczo8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPigxKSBUaGUgTWlkZGxlYm94IGNvbXB1dGVz IGFuZCByZXR1cm5zIGEgbW9kaWZpZWQgUG9saWN5IFJ1bGUgdGhhdCB3b3VsZCBiZTwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+Y29uc2lzdGVudCB3aXRoIHRoZSBvdmVyLXJpZGluZyBQb2xpY3kg UnVsZS48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPigyKSBUaGUgTWlkZGxlYm94IHJldHVybnMg dGhlIGNvbXBsZXRlIGNvbnRlbnRzIG9mIHRoZSBvdmVyLXJpZGluZyBQb2xpY3k8L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPlJ1bGUuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4oMykgVGhlIE1p ZGRsZWJveCByZXR1cm5zIHRoZSAoc3ViKXNldCBvZiB7RmlsdGVyLCBBY3Rpb259IHBhaXJzIHdp dGhpbiB0aGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPm92ZXItcmlkaW5nIFBvbGljeSBSdWxl IHdoaWNoIGFyZSBpbiBjb25mbGljdCB3aXRoIHRoZSBkaXNhbGxvd2VkIFBvbGljeTwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+UnVsZS48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPig0KSBUaGUg TWlkZGxlYm94IHJldHVybnMgYSBzZXQgb2YgZmlsdGVycyB3aGljaCBkZXNjcmliZSB0aGUgcHJl Y2lzZSBhcmVhPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5vZiBjb25mbGljdCB3aXRoIHRoZSBv dmVyLXJpZGluZyBQb2xpY3kgUnVsZS48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5J IGhhdmUgYSBiaXQgb2YgYSBjb25jZXJuIHdpdGggcHJpdmFjeSB3aGljaCBpbmNsaW5lcyBtZSB0 byBhbHRlcm5hdGl2ZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+KDQpLjwvRk9OVD4NCjwvUD4N Cg0KPFA+PEZPTlQgU0laRT0yPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj5Gcm9tOiBNYXJ0aW4gU3RpZW1lcmxpbmcgWzxBIEhSRUY9Im1haWx0bzpN YXJ0aW4uU3RpZW1lcmxpbmdAY2NybGUubmVjLmRlIj5tYWlsdG86TWFydGluLlN0aWVtZXJsaW5n QGNjcmxlLm5lYy5kZTwvQT5dPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5TZW50OiBGcmlkYXks IEFwcmlsIDA1LCAyMDAyIDk6NTcgQU08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlRvOiBTZW4s IFNhbmpveSBbTkdDOkI2OTI6RVhDSF08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPkNjOiAnSmly aSBLdXRoYW4nOyBUYXlsb3IsIFRvbS1QVCBbQ0FSOkI4MDA6RVhDSF07IG1pZGNvbUBpZXRmLm9y Zzs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPkFvdW4sIENlZHJpYyBbUVBEOk1BMDE6RVhDSF08 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlN1YmplY3Q6IFJlOiBbbWlkY29tXSBNSURDT00gU0Vt YW50aWNzOiBQb2xpY3kgUnVsZSBDb250ZW50PC9GT05UPg0KPC9QPg0KPEJSPg0KDQo8UD48Rk9O VCBTSVpFPTI+U2Fuam95IFNlbiB3cm90ZTo8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9 Mj4mZ3Q7IEhvdyB3aWxsIHRoZW4gdGhlIGZvbGxvd2luZyByZXF1aXJlbWVudCBmcm9tIE1pZGNv bSByZXF1aXJlbWVudHMgZHJhZnQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgYmUgc2F0 aXNmaWVkPzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAqKioqKjwvRk9OVD4NCjxCUj48 Rk9OVCBTSVpFPTI+Jmd0OyAyLjIuMTEuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7PC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IEl0IHNob3VsZCBiZSBwb3NzaWJsZSB0byBkZWZpbmUgcnVsZXNldHMgdGhhdCBjb250YWluIGEg bW9yZSBzcGUtPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGNpZmljIGZpbHRlciBzcGVjIHRoYW4gYW4gb3ZlcmxhcHBpbmcgcnVsZXNl dC4mbmJzcDsgVGhpcyBzaG91bGQgYWxsb3c8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYWdlbnRzIHRvIHJlcXVlc3QgYWN0aW9ucyBm b3IgdGhlIHN1YnNldCB0aGF0IGNvbnRyYWRpY3QgdGhvc2Ugb2Y8L0ZPTlQ+DQo8QlI+PEZPTlQg U0laRT0yPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIG92ZXJsYXBwaW5n IHNldC48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgKioqKio8L0ZPTlQ+DQo8L1A+DQoN CjxQPjxGT05UIFNJWkU9Mj4mbmJzcDsmZ3Q7PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpF PTI+Jmd0OyBXaGV0aGVyIHlvdSB3YW50IGl0IG9yIG5vdCwgdGhlcmUgd291bGQgYmUgb3Zlcmxh cHBpbmcgcnVsZXNldHMgYmVjYXVzZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyB0aGUg ZmlsdGVyc3BlYyBtYXkgb3ZlcmxhcCBmb3IgZGlmZmVyZW50IHJ1bGVzZXRzIGluc3RhbGxlZCBi eTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBpbmRlcGVuZGVudCBhZ2VudHMuIFRoZSBx dWVzdGlvbiAtIHdobyB3aW5zIHdoZW4gdGhlcmUncmUgY29udHJhZGljdG9yeTwvRk9OVD4NCjwv UD4NCg0KPFA+PEZPTlQgU0laRT0yPiZndDsgYWN0aW9ucyBpcyBtb290IGJlY2F1c2UgdGhlIHJl cXVpcmVtZW50IGFib3ZlIHNlZW1zIHRvIHN1Z2dlc3QgdGhhdCB3ZTwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+Jmd0OyBuZWVkIHRvIGFsbG93IGNvbnRyYWRpY3RvcnkgYmVoYXZpb3IuPC9GT05U Pg0KPC9QPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpFPTI+VGhlIHF1ZXN0aW9ucyBpcywgd2hvIHdp bGwgZGVjaWRlIGhvdyB0byBiZWhhdmUgaW4gc3VjaCBhIGNhc2U/IFRoZXJlPC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj5hcmUgc28gbWFueSBjb21iaW5hdGlvbnMgb2YgZmlyZXdhbGwvTkFUIGNv bmZpZ3VyYXRpb25zIHdoaWNoIHdpbGwgbWFrZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+aXQg ZGlmZmljdWx0IHRvIGRlZmluZSBhIHN0YWJsZSBiZWhhdmlvdXIsIGkuZS4gaG93IHRvIHJlYWN0 IHdpdGggdGhpczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+b3ZlcmxhcHBpbmcgc2V0LiBGdXJ0 aGVybW9yZSwgdGhlIHJlcXVpcmVtZW50IHN0YXJ0cyB3aXRoICZxdW90O3Nob3VsZCZxdW90Oy4u LjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPk1hcnRpbjwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+LS08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPk1hcnRpbiBTdGllbWVybGluZzwv Rk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPk5FQyBFdXJvcGUgTHRkLiAtLSBOZXR3b3Jr IExhYm9yYXRvcmllcyZuYnNwOyBTdGllbWVybGluZ0BjY3JsZS5uZWMuZGU8L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPklQdjQ6IDxBIEhSRUY9Imh0dHA6Ly93d3cuY2NybGUubmVjLmRlIiBUQVJH RVQ9Il9ibGFuayI+aHR0cDovL3d3dy5jY3JsZS5uZWMuZGU8L0E+Jm5ic3A7IElQdjY6IDxBIEhS RUY9Imh0dHA6Ly93d3cuaXB2Ni5jY3JsZS5uZWMuZGUiIFRBUkdFVD0iX2JsYW5rIj5odHRwOi8v d3d3LmlwdjYuY2NybGUubmVjLmRlPC9BPjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0y Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9GT05UPg0K PEJSPjxGT05UIFNJWkU9Mj5taWRjb20gbWFpbGluZyBsaXN0PC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj5taWRjb21AaWV0Zi5vcmc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPjxBIEhSRUY9Imh0 dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZGNvbSIgVEFSR0VUPSJfYmxh bmsiPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZGNvbTwvQT48L0ZP TlQ+DQo8L1A+DQo8QlI+DQo8QlI+DQo8QlI+DQoNCjwvQk9EWT4NCjwvSFRNTD4= --0__=86256B9200680EBC8f9e8a93df938690918c86256B9200680EBC-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 5 14:13:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13855 for ; Fri, 5 Apr 2002 14:13:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA23133 for midcom-archive@odin.ietf.org; Fri, 5 Apr 2002 14:13:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22853; Fri, 5 Apr 2002 14:09:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22769 for ; Fri, 5 Apr 2002 14:09:05 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13698 for ; Fri, 5 Apr 2002 14:09:02 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g35J8Ww14681 for ; Fri, 5 Apr 2002 14:08:33 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 14:08:33 -0500 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A27B@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'James_Renkel@3com.com'" Cc: midcom@ietf.org Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Fri, 5 Apr 2002 14:08:28 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org OK, so you're saying in effect that in case of a conflict the newest rule is ALWAYS rejected. Am I right? You're also saying that the diagnostic information, where authorized, consists of the identity of the conflicting agent. I'm not sure this will be very helpful, given that agents could be servers somewhere in the middle of the network. Why not identify the scope of the conflict instead? -----Original Message----- From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] Sent: Friday, April 05, 2002 1:57 PM To: Taylor, Tom-PT [CAR:B800:EXCH] Cc: midcom@ietf.org Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Tom, The model I proposed in my previous note is not conflict free. Having granted one filter request, a middlebox could very well be presented with another conflicting request from the same or a different application (agent). I suppose we could define filter capabilities to be so restrictive that no conflicts were ever possible, but I'm skeptical that such a definition is possible or useful. I think we can agree that the middlebox cannot simply grant the second request (unless it "undoes" the conflicting part of the first, already granted, request; but I, for one, don't want to go there.). And I wouldn't want it to reject the second request without some at least minimal explanation of why it did so. All I'm saying is that, sans compelling use cases to open the door of conflict resolution, we should limit ourselves to what might be described as "conflict identification", a necessary first step in the midcom protocol if the application (agent)s are to resolve the conflict with mechanisms outside of the midcom protocol. Jim "Tom-PT Taylor" on 04/05/2002 12:38:35 PM Sent by: "Tom-PT Taylor" To: James Renkel/MW/US/3Com cc: midcom@ietf.org Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Well, if the conflict-free model you postulated in your previous note is accepted by everyone as valid, we don't need to worry about this anyway. -----Original Message----- From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] Sent: Friday, April 05, 2002 1:25 PM To: Taylor, Tom-PT [CAR:B800:EXCH] Cc: 'Martin Stiemerling'; Sen, Sanjoy [NGC:B692:EXCH]; 'Jiri Kuthan'; midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content It seems to me that we're getting into an area here that might be described as "conflict resolution between requests from different applications / agents". IMHO, this can get real hairy, real quick, and might best be declared to be out of scope for the midcom protocol, at least for now. That said, I have no problem with the middlebox, when presented with a conflicting request, reporting to the "conflictor" and the "conflictee" the identities of the other party in the conflict, IF THEY HAVE AUTHORIZED THE MIDDLEBOX TO DO SO. Anything beyond that, I believe, should be left to the applications / agents to work out for themselves in some way not specified in the midcom protocol, using some other protocol, not the midcom protocol. Then one or the other or both would adjust their established or requested filters with the middlebox accordingly, so they hopefully no longer conflicted. Once we have some more experience with this, maybe we will want to add something to version 2 of the midcom protocol (Remember, it is required to be compatibly extensible, perhaps just for reasons like this.). If we are going to deal with this now, I think we need to have some very, very, very specific use cases to justify this capability, not just "navel scratchings". Also, as as I hinted in a separate e-mail, if a "big" capabiltiy in this area were included in the midcom protocol, I would want it to be optional in implementation so that, e.g., SOHO cable/DSL/ISDN middleboxes would not have to implement it to be RFC compliant. I think trying to deal with this now may be premature, but I could be wrong. Jim "Tom-PT Taylor"@ietf.org on 04/05/2002 10:43:54 AM Sent by: midcom-admin@ietf.org To: "'Martin Stiemerling'" , "Sanjoy Sen" cc: "'Jiri Kuthan'" , midcom@ietf.org, "Cedric Aoun" Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Assuming that contradictions are possible (see my previous message), we should distinguish two cases: - a specific Agent contradicts a Policy Rule installed previously by that same Agent - a specific Agent contradicts a Policy Rule installed by another Agent. An underlying premise of our proposed semantics is that each Policy Rule (defined as a set of {Filter, Action} pairs with a specific Policy Rule Identifier) has one or more owners. That is, the Middlebox remembers the Agent(s) who installed those rules. Whether more than one Agent should be able to work with the same Policy Rule is a matter for discussion, though I sense an inclination not to allow this. (But it seems to me that an Administrator should be able to audit all installed Policy Rules and deactivate any of them if need be.) On the other hand, I think it is accepted that different Policy Rules could overlap in their scope. So I'll concentrate my discussion on the case where a new Policy Rule is in conflict with a previously installed Policy Rule. I would suggest a general approach to conflicts of this form: - If an Agent contradicts itself, the Middlebox denies the new Policy Rule Request. It returns an appropriate reason code and the Policy Rule Identifier of the rule which is in conflict. The Agent then has the information it needs to choose between modifying the already-existing rule to accommodate the new conditions or giving up on the new Policy Rule. - If an Agent contradicts another Agent, Agent priorities come into play. I'm happy enough to allow only two priorities: Administrator and others, but I'm not sure we need to specify this, only that there exists a hierarchy of Agent priorities. The general rule is then that the Policy Rule installed by the higher priority agent prevails and the other one is rejected or deactivated as the case may be. Between equal-priority Agents, existing Policy Rules take priority over new ones. One open question is what diagnostic information should be supplied when a Policy Rule is rejected or deactivated. I see the following possibilities: (1) The Middlebox computes and returns a modified Policy Rule that would be consistent with the over-riding Policy Rule. (2) The Middlebox returns the complete contents of the over-riding Policy Rule. (3) The Middlebox returns the (sub)set of {Filter, Action} pairs within the over-riding Policy Rule which are in conflict with the disallowed Policy Rule. (4) The Middlebox returns a set of filters which describe the precise area of conflict with the over-riding Policy Rule. I have a bit of a concern with privacy which inclines me to alternative (4). -----Original Message----- From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] Sent: Friday, April 05, 2002 9:57 AM To: Sen, Sanjoy [NGC:B692:EXCH] Cc: 'Jiri Kuthan'; Taylor, Tom-PT [CAR:B800:EXCH]; midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content Sanjoy Sen wrote: > How will then the following requirement from Midcom requirements draft > be satisfied? > ***** > 2.2.11. > > It should be possible to define rulesets that contain a more spe- > cific filter spec than an overlapping ruleset. This should allow > agents to request actions for the subset that contradict those of > the overlapping set. > ***** > > Whether you want it or not, there would be overlapping rulesets because > the filterspec may overlap for different rulesets installed by > independent agents. The question - who wins when there're contradictory > actions is moot because the requirement above seems to suggest that we > need to allow contradictory behavior. The questions is, who will decide how to behave in such a case? There are so many combinations of firewall/NAT configurations which will make it difficult to define a stable behaviour, i.e. how to react with this overlapping set. Furthermore, the requirement starts with "should"... Martin -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom (See attached file: C.htm) _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 5 15:17:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17313 for ; Fri, 5 Apr 2002 15:17:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA26751 for midcom-archive@odin.ietf.org; Fri, 5 Apr 2002 15:17:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26223; Fri, 5 Apr 2002 15:09:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26193 for ; Fri, 5 Apr 2002 15:09:13 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17073 for ; Fri, 5 Apr 2002 15:09:09 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id A39C140B004C; Fri, 05 Apr 2002 15:05:48 -0500 Message-ID: <003c01c1dcdc$ffeb2180$2300000a@acmepacket.com> From: "Bob Penfield" To: "Tom-PT Taylor" , "'Martin Stiemerling'" Cc: , "Cedric Aoun" References: <4D79C746863DD51197690002A52CDA0001E8A261@zcard0kc.ca.nortel.com> Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Fri, 5 Apr 2002 15:03:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit There have been a lot of comments on this thread, but I want to go back to the original questions and make a few points which may also apply to later comments. ----- Original Message ----- From: "Tom-PT Taylor" > That's two people so far who have said requests should be satisfied > completely or not at all. Shall we take this as the working assumption? First, I think that each request from the agent should be atomic. Partial rule installation just makes everything too complex. > > First-come-first-serve vs. policy hides another issue: how to allow multiple > authorized agents to work on the same ruleset (requirement 2.2.7). Our > proposals so far assumed this was handled through a policy mechanism. There > is a distinction, of course, between two agents operating on the same Policy > Rule Identifier (which is perhaps what 2.2.7 permits) That is exactly what 2.2.7 is talking about. The motivation for allowing multiple agents to work on the same rule came from the need for redundancy and reliability in the application layer (i.e. the agents). I don't think the case would be that both agents would create/install the rule, but rather one would create it and the other might modify or remove if the second agent became responsible for the rule because the first agent died. > and two agents > defining identical rulesets with different Policy Rule Identifiers. So I > have a couple of questions for the WG: > > 1) Does the protocol address the possibility of two agents defining > overlapping rulesets and if so, are conflicts handled on a > first-come-first-served basis? I think first-come-first-served is the right approach. However, I would see a conflict only when the filter was identical. We had talked about having overlapping rules, but one would have a "more specific" filter. For example, a rule might allow a whole range of addresses and ports thru, but there might be rules to deny more specific or narrower ranges of addresses and ports. The more specific filter would take precedence when deciding what to do with a specific packet which matched multiple rules (i.e. their filters). > > 2) Does the protocol need a formal delegation capability, so that Agent A > can tell the Middlebox that Agent B can make requests affecting Policy Rule > Identifier x? I don't think this is what we want. For the case of a failure of one agent in a redundant pair, the crashed agent would not be able to "delegate" the rule to the other agent. This relationship has to be established either by policy in the middlebox, or in rule creation/modification with the semantics of "BTW, allow agent X to also mess with this rule, and send it notifications about this rule too". cheers, (-:bob _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 5 16:21:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19105 for ; Fri, 5 Apr 2002 16:21:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA29536 for midcom-archive@odin.ietf.org; Fri, 5 Apr 2002 16:21:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29358; Fri, 5 Apr 2002 16:14:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29329 for ; Fri, 5 Apr 2002 16:14:13 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18957 for ; Fri, 5 Apr 2002 16:14:08 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g35LDa878817; Fri, 5 Apr 2002 23:13:36 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.31] ([192.168.102.31]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA21015; Fri, 5 Apr 2002 23:13:12 +0200 Date: Fri, 05 Apr 2002 23:16:30 +0200 From: Juergen Quittek To: Tom-PT Taylor , "'Martin Stiemerling'" , Sanjoy Sen cc: "'Jiri Kuthan'" , midcom@ietf.org, Cedric Aoun Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Message-ID: <7031811.1018048590@[192.168.102.31]> In-Reply-To: <4D79C746863DD51197690002A52CDA0001E8A277@zcard0kc.ca.nortel.com> References: <4D79C746863DD51197690002A52CDA0001E8A277@zcard0kc.ca.nortel.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Tom, --On 05 April 2002 11:43 -0500 Tom-PT Taylor wrote: > Assuming that contradictions are possible (see my previous message), we > should distinguish two cases: > - a specific Agent contradicts a Policy Rule installed previously by that > same Agent > - a specific Agent contradicts a Policy Rule installed by another Agent. > > An underlying premise of our proposed semantics is that each Policy Rule > (defined as a set of {Filter, Action} pairs with a specific Policy Rule > Identifier) has one or more owners. That is, the Middlebox remembers the > Agent(s) who installed those rules. Alternatively, you could 1. disallow contradictions 2. have a single owner per rule and have both of them active at the same time. Both alternatives avoid multiple ownership. > Whether more than one Agent should be able to work with the same Policy Rule > is a matter for discussion, though I sense an inclination not to allow this. > (But it seems to me that an Administrator should be able to audit all > installed Policy Rules and deactivate any of them if need be.) On the other > hand, I think it is accepted that different Policy Rules could overlap in > their scope. So I'll concentrate my discussion on the case where a new > Policy Rule is in conflict with a previously installed Policy Rule. > > I would suggest a general approach to conflicts of this form: > > - If an Agent contradicts itself, the Middlebox denies the new Policy Rule > Request. It returns an appropriate reason code and the Policy Rule > Identifier of the rule which is in conflict. The Agent then has the > information it needs to choose between modifying the already-existing rule > to accommodate the new conditions or giving up on the new Policy Rule. > > - If an Agent contradicts another Agent, Agent priorities come into play. > I'm happy enough to allow only two priorities: Administrator and others, but > I'm not sure we need to specify this, only that there exists a hierarchy of > Agent priorities. The general rule is then that the Policy Rule installed > by the higher priority agent prevails and the other one is rejected or > deactivated as the case may be. Between equal-priority Agents, existing > Policy Rules take priority over new ones. > > One open question is what diagnostic information should be supplied when a > Policy Rule is rejected or deactivated. I see the following possibilities: > (1) The Middlebox computes and returns a modified Policy Rule that would be > consistent with the over-riding Policy Rule. > (2) The Middlebox returns the complete contents of the over-riding Policy > Rule. > (3) The Middlebox returns the (sub)set of {Filter, Action} pairs within the > over-riding Policy Rule which are in conflict with the disallowed Policy > Rule. > (4) The Middlebox returns a set of filters which describe the precise area > of conflict with the over-riding Policy Rule. You omitted the most obvious choice: (5) The middlebox does not return any diagnostic information. A simple error code, such as "denied" or "denied because of conflict" might be enough. I think that most clients will be rather simple and therefore not able to analyse complex diagnostic info and react accordingly. Diagnostic information would be interesting for manual operators, but this is not what our charter is about. > I have a bit of a concern with privacy which inclines me to alternative (4). Alternative (5) should be close to the optimum concerning privacy. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > -----Original Message----- > From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] > Sent: Friday, April 05, 2002 9:57 AM > To: Sen, Sanjoy [NGC:B692:EXCH] > Cc: 'Jiri Kuthan'; Taylor, Tom-PT [CAR:B800:EXCH]; midcom@ietf.org; > Aoun, Cedric [QPD:MA01:EXCH] > Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content > > > Sanjoy Sen wrote: > >> How will then the following requirement from Midcom requirements draft >> be satisfied? >> ***** >> 2.2.11. >> >> It should be possible to define rulesets that contain a more spe- >> cific filter spec than an overlapping ruleset. This should allow >> agents to request actions for the subset that contradict those of >> the overlapping set. >> ***** > > > > >> Whether you want it or not, there would be overlapping rulesets because >> the filterspec may overlap for different rulesets installed by >> independent agents. The question - who wins when there're contradictory > >> actions is moot because the requirement above seems to suggest that we >> need to allow contradictory behavior. > > > The questions is, who will decide how to behave in such a case? There > are so many combinations of firewall/NAT configurations which will make > it difficult to define a stable behaviour, i.e. how to react with this > overlapping set. Furthermore, the requirement starts with "should"... > > Martin > -- > Martin Stiemerling > > NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de > IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Apr 8 10:04:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24032 for ; Mon, 8 Apr 2002 10:04:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA07161 for midcom-archive@odin.ietf.org; Mon, 8 Apr 2002 10:04:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06032; Mon, 8 Apr 2002 09:54:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05830 for ; Mon, 8 Apr 2002 09:51:04 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23551; Mon, 8 Apr 2002 09:51:01 -0400 (EDT) Message-Id: <200204081351.JAA23551@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 08 Apr 2002 09:51:01 -0400 Subject: [midcom] I-D ACTION:draft-ietf-midcom-stun-00.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Middlebox Communication Working Group of the IETF. Title : STUN - Simple Traversal of UDP Through NATs Author(s) : J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy Filename : draft-ietf-midcom-stun-00.txt Pages : 32 Date : 05-Apr-02 Simple Traversal of UDP Through NATs (STUN) is a lightweight protocol that allows applications to discover the presence and types of Network Address Translators (NATs) and firewalls between them and the public Internet. It also provides the ability for applications to determine the public IP addresses allocated to them by the NAT. STUN works with many existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure. The STUN protocol is simple, being almost identical to echo. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-midcom-stun-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-midcom-stun-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020405102026.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-stun-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-stun-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020405102026.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Apr 8 10:17:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24524 for ; Mon, 8 Apr 2002 10:17:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA08389 for midcom-archive@odin.ietf.org; Mon, 8 Apr 2002 10:17:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07518; Mon, 8 Apr 2002 10:07:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07484 for ; Mon, 8 Apr 2002 10:07:28 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24198 for ; Mon, 8 Apr 2002 10:07:25 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g38E6tt07150 for ; Mon, 8 Apr 2002 10:06:55 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 10:06:56 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A290@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Bob Penfield'" , "'Martin Stiemerling'" Cc: midcom@ietf.org, "Cedric Aoun" Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Mon, 8 Apr 2002 10:06:52 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org A couple of comments here: 1) You talk of more specific rules taking precedence ove less specific ones. But what about cases of overlap, as illustrated in my theoretical note? Would the zone of overlap be considered to be "more specific"? 2) I think your requirement for one agent (B) to act on behalf of another (A) can be met if agent (B) takes on the identity of agent (A). This wouldn't have a direct impact on the protocol -- sharing of identities and credentials would happen behind the scenes -- but must have implications for our security analysis. Bob, would this meet requirement 2.2.7 in your view, or do you prefer a formal "B can work on this too" in the original Policy Rule Request? -----Original Message----- From: Bob Penfield [mailto:bpenfield@acmepacket.com] Sent: Friday, April 05, 2002 3:04 PM To: Taylor, Tom-PT [CAR:B800:EXCH]; 'Martin Stiemerling' Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content There have been a lot of comments on this thread, but I want to go back to the original questions and make a few points which may also apply to later comments. ----- Original Message ----- From: "Tom-PT Taylor" > That's two people so far who have said requests should be satisfied > completely or not at all. Shall we take this as the working assumption? First, I think that each request from the agent should be atomic. Partial rule installation just makes everything too complex. > > First-come-first-serve vs. policy hides another issue: how to allow multiple > authorized agents to work on the same ruleset (requirement 2.2.7). Our > proposals so far assumed this was handled through a policy mechanism. There > is a distinction, of course, between two agents operating on the same Policy > Rule Identifier (which is perhaps what 2.2.7 permits) That is exactly what 2.2.7 is talking about. The motivation for allowing multiple agents to work on the same rule came from the need for redundancy and reliability in the application layer (i.e. the agents). I don't think the case would be that both agents would create/install the rule, but rather one would create it and the other might modify or remove if the second agent became responsible for the rule because the first agent died. > and two agents > defining identical rulesets with different Policy Rule Identifiers. So I > have a couple of questions for the WG: > > 1) Does the protocol address the possibility of two agents defining > overlapping rulesets and if so, are conflicts handled on a > first-come-first-served basis? I think first-come-first-served is the right approach. However, I would see a conflict only when the filter was identical. We had talked about having overlapping rules, but one would have a "more specific" filter. For example, a rule might allow a whole range of addresses and ports thru, but there might be rules to deny more specific or narrower ranges of addresses and ports. The more specific filter would take precedence when deciding what to do with a specific packet which matched multiple rules (i.e. their filters). > > 2) Does the protocol need a formal delegation capability, so that Agent A > can tell the Middlebox that Agent B can make requests affecting Policy Rule > Identifier x? I don't think this is what we want. For the case of a failure of one agent in a redundant pair, the crashed agent would not be able to "delegate" the rule to the other agent. This relationship has to be established either by policy in the middlebox, or in rule creation/modification with the semantics of "BTW, allow agent X to also mess with this rule, and send it notifications about this rule too". cheers, (-:bob _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Apr 8 10:37:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25321 for ; Mon, 8 Apr 2002 10:37:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA10352 for midcom-archive@odin.ietf.org; Mon, 8 Apr 2002 10:37:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10169; Mon, 8 Apr 2002 10:34:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10127 for ; Mon, 8 Apr 2002 10:34:50 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25247 for ; Mon, 8 Apr 2002 10:34:47 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g38EXSON003720 for ; Mon, 8 Apr 2002 07:33:28 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADM28249; Mon, 8 Apr 2002 07:30:48 -0700 (PDT) Message-Id: <5.1.0.14.0.20020408103432.00a6cd50@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 08 Apr 2002 10:37:37 -0400 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Working group last call - STUN Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org We are starting working group last call on the STUN document. The last call period closes on Tuesday, 23 April at 5pm EDT. Please post any comments, etc. to the mailing list, and please point out whether you feel your comment is editorial or a show- stopper. Thanks, Melinda >To: IETF-Announce: ; >Cc: midcom@ietf.org >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Date: Mon, 08 Apr 2002 09:51:01 -0400 >Subject: [midcom] I-D ACTION:draft-ietf-midcom-stun-00.txt >Sender: midcom-admin@ietf.org >X-Mailman-Version: 1.0 >List-Id: >X-BeenThere: midcom@ietf.org > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Middlebox Communication Working Group of the IETF. > > Title : STUN - Simple Traversal of UDP Through NATs > Author(s) : J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy > Filename : draft-ietf-midcom-stun-00.txt > Pages : 32 > Date : 05-Apr-02 > >Simple Traversal of UDP Through NATs (STUN) is a lightweight protocol >that allows applications to discover the presence and types of >Network Address Translators (NATs) and firewalls between them and the >public Internet. It also provides the ability for applications to >determine the public IP addresses allocated to them by the NAT. STUN >works with many existing NATs, and does not require any special >behavior from them. As a result, it allows a wide variety of >applications to work through existing NAT infrastructure. The STUN >protocol is simple, being almost identical to echo. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-midcom-stun-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-midcom-stun-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20020405102026.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-midcom-stun-00.txt > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Apr 8 10:38:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25427 for ; Mon, 8 Apr 2002 10:38:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA10539 for midcom-archive@odin.ietf.org; Mon, 8 Apr 2002 10:38:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10215; Mon, 8 Apr 2002 10:35:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10177 for ; Mon, 8 Apr 2002 10:34:55 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25252 for ; Mon, 8 Apr 2002 10:34:52 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g38EXYD18846; Mon, 8 Apr 2002 09:33:34 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2JXVKNRA>; Mon, 8 Apr 2002 09:33:35 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A03DE396D@zrc2c000.us.nortel.com> From: "Mary Barnes" To: midcom@ietf.org Cc: "'Melinda Shore'" Date: Mon, 8 Apr 2002 09:33:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF0A.5CB81740" Subject: [midcom] FINAL Summary of Volunteers for Protocol Evaluation Documents Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DF0A.5CB81740 Content-Type: text/plain; charset="iso-8859-1" Hi all, We added one additional protocol/volunteer to the list on Friday, thus the FINAL list of protocols to be evaluated (with the prime listed) is: MEGACO - Sanjoy Sen [sanjoy@nortelnetworks.com] COPS - Louis-Nicolas Hamer [nhamer@nortelnetworks.com] RSIP - James Renkel [James_Renkel@3com.com] SNMP/SMI - Juergen Quittek [quittek@ccrle.nec.de] DIAMETER - Tom Taylor [taylor@nortelnetworks.com] As a reminder, the timeline for these contributions is: April 19th Final cutoff for specific protocol drafts. * The mandatory sections for this document are outlined in section 4.1 of the template at: http://www.obsidian97.com/draft-midcom-protocol-eval-template.txt April 19th- May 3rd Mailing list discussion of specific protocol drafts, allowing authors to incorporate WG feedback into their contribution to improve comparison and add completeness. May 10th Deadline for any updates to protocol drafts. Thanks to all the volunteers for committing their time and efforts to this activity. Mary. Editor, MIDCOM Protocol Evalation Document ------_=_NextPart_001_01C1DF0A.5CB81740 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FINAL Summary of Volunteers for Protocol Evaluation = Documents

Hi all,

We added one additional protocol/volunteer to the = list on Friday, thus the FINAL list of protocols to be evaluated (with = the prime listed) is:

MEGACO - Sanjoy Sen [sanjoy@nortelnetworks.com] =
COPS - Louis-Nicolas Hamer = [nhamer@nortelnetworks.com]
RSIP - James Renkel [James_Renkel@3com.com]
SNMP/SMI - Juergen Quittek [quittek@ccrle.nec.de] =
DIAMETER - Tom Taylor = [taylor@nortelnetworks.com]

As a reminder, the timeline for these contributions = is:
April 19th      Final = cutoff for specific protocol drafts.
          &nb= sp;    *  The mandatory sections for this document = are
          &nb= sp;       outlined in section 4.1 of = the     
          &nb= sp;       template at:
http://www.obsidian97.com/draft-midcom-protocol-eval-t= emplate.txt

April 19th- May 3rd     Mailing = list discussion of specific
          &nb= sp;           &nb= sp; protocol drafts, allowing authors to
          &nb= sp;           &nb= sp; incorporate WG feedback into their 
          &nb= sp;           &nb= sp; contribution to improve comparison and
          &nb= sp;           &nb= sp; add completeness.

May 10th        = Deadline for any updates to protocol drafts.

Thanks to all the volunteers for committing their = time and efforts to this activity.

Mary.
Editor, MIDCOM Protocol Evalation Document

------_=_NextPart_001_01C1DF0A.5CB81740-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Apr 8 11:40:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27364 for ; Mon, 8 Apr 2002 11:40:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA15702 for midcom-archive@odin.ietf.org; Mon, 8 Apr 2002 11:40:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15064; Mon, 8 Apr 2002 11:35:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15038 for ; Mon, 8 Apr 2002 11:35:42 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27207 for ; Mon, 8 Apr 2002 11:35:38 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.80]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g38FWDo6001072; Mon, 8 Apr 2002 11:32:14 -0400 (EDT) Message-ID: <3CB1B7B3.4C9DA93@dynamicsoft.com> Date: Mon, 08 Apr 2002 11:30:59 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Cedric Aoun CC: midcom@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Re: some comments on stun 01 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Cedric Aoun wrote: > > Jonathan, > > I'm refering to the bind timeout calculation algorithm > > "How about this: > > 1. the client sends a request to the server, from socket X. It is sent > to address/port C,D. The response is sent from C,D. From the response, > the client learns the public IP/port for this request, say thats A,B. > > 2. after T seconds, the client sends a second request, from a different > socket (Y), to the server at C,D. This one has a RESPONSE-ADDRESS of > A,B. The server sends a response from C,D to A,B. If the old binding > still exists, it is matched for all nat types, and the response goes to > socket X. If the binding had timed out, the response will either be > discarded, or it is possible that it might get sent to socket Y. In > either case, the client knows that the binding has expired. > > I believe that will work." > > > I agree with the approach, this is the right way to do it. I have a > small comment on > "or it is possible that it might get sent to socket Y", it won't since > the datagram sent from Y > created a new bind that didn't allocate A/B (that's how most NATs will > normally behave). I didn't want to make any assumptions on how they might behave. I was worried that it may very well get reallocated. The text in the document does clarify that this is teh reason it might go to Y. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Apr 8 11:54:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27842 for ; Mon, 8 Apr 2002 11:54:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA16746 for midcom-archive@odin.ietf.org; Mon, 8 Apr 2002 11:54:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16596; Mon, 8 Apr 2002 11:52:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12839 for ; Mon, 8 Apr 2002 11:08:50 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26405 for ; Mon, 8 Apr 2002 11:08:46 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g38F7x323694; Mon, 8 Apr 2002 17:08:00 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g38F7N704299; Mon, 8 Apr 2002 16:07:23 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 16:07:57 +0100 Message-ID: From: "Cedric Aoun" To: "'Jonathan Rosenberg'" Cc: midcom@ietf.org Date: Mon, 8 Apr 2002 16:07:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF0F.18E1E348" Subject: [midcom] RE: some comments on stun 01 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DF0F.18E1E348 Content-Type: text/plain Jonathan, I'm refering to the bind timeout calculation algorithm "How about this: 1. the client sends a request to the server, from socket X. It is sent to address/port C,D. The response is sent from C,D. From the response, the client learns the public IP/port for this request, say thats A,B. 2. after T seconds, the client sends a second request, from a different socket (Y), to the server at C,D. This one has a RESPONSE-ADDRESS of A,B. The server sends a response from C,D to A,B. If the old binding still exists, it is matched for all nat types, and the response goes to socket X. If the binding had timed out, the response will either be discarded, or it is possible that it might get sent to socket Y. In either case, the client knows that the binding has expired. I believe that will work." I agree with the approach, this is the right way to do it. I have a small comment on "or it is possible that it might get sent to socket Y", it won't since the datagram sent from Y created a new bind that didn't allocate A/B (that's how most NATs will normally behave). Thanks Cedric ------_=_NextPart_001_01C1DF0F.18E1E348 Content-Type: text/html RE: some comments on stun 01

Jonathan,

I'm refering to the bind timeout calculation algorithm

<JR> "How about this:

1. the client sends a request to the server, from socket X. It is sent
to address/port C,D. The response is sent from C,D. From the response,
the client learns the public IP/port for this request, say thats A,B.

2. after T seconds, the client sends a second request, from a different
socket (Y), to the server at C,D. This one has a RESPONSE-ADDRESS of
A,B. The server sends a response from C,D to A,B. If the old binding
still exists, it is matched for all nat types, and the response goes to
socket X. If the binding had timed out, the response will either be
discarded, or it is possible that it might get sent to socket Y. In
either case, the client knows that the binding has expired.

I believe that will work."
</JR>

I agree with the approach, this is the right way to do it. I have a small comment on
"or it is possible that it might get sent to socket Y", it won't since the datagram sent from Y
created a new bind that didn't allocate A/B (that's how most NATs will normally behave).

Thanks
Cedric


------_=_NextPart_001_01C1DF0F.18E1E348-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Apr 8 12:48:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29569 for ; Mon, 8 Apr 2002 12:48:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA21192 for midcom-archive@odin.ietf.org; Mon, 8 Apr 2002 12:48:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21038; Mon, 8 Apr 2002 12:43:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21008 for ; Mon, 8 Apr 2002 12:43:42 -0400 (EDT) Received: from rhenium.btinternet.com (rhenium.btinternet.com [194.73.73.93]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29501 for ; Mon, 8 Apr 2002 12:43:40 -0400 (EDT) Received: from host213-1-185-93.btinternet.com ([213.1.185.93] helo=tkw) by rhenium.btinternet.com with smtp (Exim 3.22 #8) id 16ucF1-0003x7-00 for midcom@ietf.org; Mon, 08 Apr 2002 17:43:39 +0100 Message-ID: <007701c1df1c$af1127e0$0200000a@tkw> From: "Pete Cordell" To: References: <5.1.0.14.0.20020408103432.00a6cd50@localhost> Subject: Re: [midcom] Working group last call - STUN Date: Mon, 8 Apr 2002 17:40:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Here are my comments as part of WGLC... - The biggest technical issues I have is that in 11.2.3 on CHANGED-ADDRESS, the following change should be made: s|and/or|and| - To be pedantic, I also think in section 9.1 an additional paragraph should be added after the third paragraph to the effect of: "Requests are sent to successive SRV listed servers according to the above procedure until a response is successfully received. Once a successful response is received an operational STUN server is considered to have been located and the client should not move the test to the next SRV listed server if subsequent requests do not solicit a response after 30 seconds." The above is pretty obvious, but I feel ought to be stated for completeness. - Section 9.2 last paragraph - The response will also include the CHANGED-ADDRESS attributes (although the section does not claim to be an exhaustive list so its omission is no big deal.) - In 11.2.6 CMS-SIGNED-DATA - When you say detached signatures, do you mean external signatures? I can see no mention of detached signatures in RFC2630 (but I might have missed them). - I'm still getting to grips with RFC2630, but it seems to say "If the eContent value within EncapsulatedContentInfo is absent, then the signatureValue is calculated and the eContentType is assigned as though the eContent value was present." That implies to me that an object identifier is needed for STUN, which is a bit of a hassle. Maybe some words should be added to 11.2.6 to address this. - 11.1 Message Header: s/64 bit header/160 bit header/ in the first and third paragraphs. - Personally I would find it clearer if CHANGED-ADDRESS was actually called CHANGE-ADDRESS. The reason for this is I got CHANGED-ADDRESS confused with MAPPED-ADDRESS. i.e. I was thinking CHANGED-ADDRESS was the address changed by the NAT. I also think it's confusing because in a number of cases the address is not actually changed, at least not in its entirity. Calling it CHANGE-ADDRESS also ties it in more with the 'change-ip' and 'change-port' flags with which it is associated. - In section 10 (Use cases) there could be more emphasis that the way STUN is used is at the discretion of the client by breaking it into a number of paragraphs, e.g.: "The rules of Sections 8 and 9 describe exactly how a client and server interact to send requests and get responses. "How these requests and responses are used to obtain useful information is at the discretion of the client. "Here, we provide some useful scenarios for applying STUN." Definitely no show-stoppers. The latter two are primarily intended to help people avoid missing the points that I missed. (Jonathan - sorry for submitting a few more comments than I initially I said would.) Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: Melinda Shore To: Sent: 08 April 2002 15:37 Subject: [midcom] Working group last call - STUN > We are starting working group last call on the STUN document. > The last call period closes on Tuesday, 23 April at 5pm EDT. > Please post any comments, etc. to the mailing list, and please > point out whether you feel your comment is editorial or a show- > stopper. > > Thanks, > > Melinda > > > >To: IETF-Announce: ; > >Cc: midcom@ietf.org > >From: Internet-Drafts@ietf.org > >Reply-to: Internet-Drafts@ietf.org > >Date: Mon, 08 Apr 2002 09:51:01 -0400 > >Subject: [midcom] I-D ACTION:draft-ietf-midcom-stun-00.txt > >Sender: midcom-admin@ietf.org > >X-Mailman-Version: 1.0 > >List-Id: > >X-BeenThere: midcom@ietf.org > > > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > >This draft is a work item of the Middlebox Communication Working Group of the IETF. > > > > Title : STUN - Simple Traversal of UDP Through NATs > > Author(s) : J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy > > Filename : draft-ietf-midcom-stun-00.txt > > Pages : 32 > > Date : 05-Apr-02 > > > >Simple Traversal of UDP Through NATs (STUN) is a lightweight protocol > >that allows applications to discover the presence and types of > >Network Address Translators (NATs) and firewalls between them and the > >public Internet. It also provides the ability for applications to > >determine the public IP addresses allocated to them by the NAT. STUN > >works with many existing NATs, and does not require any special > >behavior from them. As a result, it allows a wide variety of > >applications to work through existing NAT infrastructure. The STUN > >protocol is simple, being almost identical to echo. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-00.txt > > > >To remove yourself from the IETF Announcement list, send a message to > >ietf-announce-request with the word unsubscribe in the body of the message. > > > >Internet-Drafts are also available by anonymous FTP. Login with the username > >"anonymous" and a password of your e-mail address. After logging in, > >type "cd internet-drafts" and then > > "get draft-ietf-midcom-stun-00.txt". > > > >A list of Internet-Drafts directories can be found in > >http://www.ietf.org/shadow.html > >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > >Internet-Drafts can also be obtained by e-mail. > > > >Send a message to: > > mailserv@ietf.org. > >In the body type: > > "FILE /internet-drafts/draft-ietf-midcom-stun-00.txt". > > > >NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > >Below is the data which will enable a MIME compliant mail reader > >implementation to automatically retrieve the ASCII version of the > >Internet-Draft. > >Content-Type: text/plain > >Content-ID: <20020405102026.I-D@ietf.org> > > > >ENCODING mime > >FILE /internet-drafts/draft-ietf-midcom-stun-00.txt > > > > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Apr 8 13:38:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00699 for ; Mon, 8 Apr 2002 13:38:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24252 for midcom-archive@odin.ietf.org; Mon, 8 Apr 2002 13:38:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24086; Mon, 8 Apr 2002 13:34:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24055 for ; Mon, 8 Apr 2002 13:34:19 -0400 (EDT) Received: from carbon (carbon.btinternet.com [194.73.73.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00635 for ; Mon, 8 Apr 2002 13:34:16 -0400 (EDT) Received: from host213-122-113-3.in-addr.btopenworld.com ([213.122.113.3] helo=tkw) by carbon with smtp (Exim 3.22 #8) id 16ud1z-0007N6-00; Mon, 08 Apr 2002 18:34:16 +0100 Message-ID: <000201c1df23$c0ab8480$0200000a@tkw> From: "Pete Cordell" To: , "Melinda Shore" , "Tom Taylor" References: <5.1.0.14.0.20020402091103.00a800e0@localhost> Subject: Re: [midcom] Fwd: Draft MIDCOM Minutes Date: Mon, 8 Apr 2002 18:27:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Melinda/Tom, Towards the end where TOM has said 'PPP is in scope', I think it should read 'TCP is in scope'. Also, THING is due May 02 as in May 2002 rather than 2 May. That means 32nd May to a delivery chap like me! The date is from the charter. (I thought when Steve said it that it sounded confusing.) Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: Melinda Shore To: Sent: 02 April 2002 15:13 Subject: [midcom] Fwd: Draft MIDCOM Minutes > Here are the draft minutes from the recent IETF meeting. As always, > let us know about errors, omissions, etc. > > Thanks, > > Melinda > > > The MIDCOM (Middlebox Communications) Working Group met Thursday, March 21 at 1530-1730. Melinda Shore chaired the meeting. Notes were taken by Tom Taylor (taylor@nortelnetworks.com) > > Agenda Bashing > ============== > > The agenda was accepted as proposed. > > Status > ========= > > The MIDCOM Framework and Requirements documents have both been approved for publication. > > The new charter has been approved and posted. > > STUN is due April 2002. > > Our unnamed pre-MIDCOM deliverable is due in May. > > Process Going Forward > ===================== > > Mary Barnes is to be the editor for the protocol evaluation document. > > The Working Group is doing the semantic work in parallel. > -- process to be announced next week (last week of March) > -- Tom Taylor is doing work on the semantic model. > > Jonathan Rosenberg commented that he was not sure if the work should go in parallel, given that the semantic description can be disposed of quickly. Melinda responded that the protocol evaluation will be messy and political, hence is best started as soon as possible. > > Mary Barnes presented charts describing the process going forward. > > Chart 1: Methodology Overview - Part 1 > -------------------------------------- > > - Process open to entire WG. > > - Contributors need to specify their intention to contribute > an objective evaluation of a specific protocol (by April 3rd). > -- If there are multiple volunteers for the same protocol, > priority is given to whomever puts in the first claim > with a suggestion that the interested parties work together. > -- Objective is to NOT have multiple individual contributions > for the same protocol. > > - Specific protocol evaluation to be completed by April 19th. > > - Open WG feedback on the specific proposals on the mailing list, > allowing authors to incorporate WG feedback into their contribution > to improve its positioning and completeness (April 19th- May 3rd). > > - Final version of specific protocol evaluations due on May 10th. > > - Final versions of specific protocol evaluationss due May 10 > -- template will be provided > > Some discussion of IPR followed the presentation. IPR claims must be revealed by April 3 to help people decide which protocols they want to work with. > > Chart 2: Methodology Overview - Part 2 > -------------------------------------- > > - MIDCOM WG protocol evaluation document to be comprised > from the information from the specific protocol drafts > (May 10th-May 24th) > -- Information is synthesized by the editor into a consistent > format, with an objective comparison of the various proposals > based upon the drafts (thus the responsibility is on the draft > writers to ensure they completely evaluate their protocol > against the requirements and framework and incorporate > constructive input from mailing list). > -- first version of protocol evaluation draft available on May 24th. > > - Open WG feedback on the draft (May 24th - June 7th) : > -- Discussion of amalgamated pros/cons of the various proposals > -- Any other issues with the draft. > > - Second version of draft available on June 14th: > -- One Week mailing list discussion. > -- Updated draft posted for WGLC: June 28th > -- WGLC: June 28th-July 19th. > -- Time allowed for a second iteration of WGLC > > Chart 3: Basis for evaluation > ----------------------------- > > - Fundamental basis for evaluation is: > -- MIDCOM Requirements: draft-ietf-midcom-requirements-05.txt > -- MIDCOM Framework: draft-ietf-midcom-framework-07.txt > > - Format for individual protocol evaluations is not > prescriptive but for an objective analysis should include > the following sections/content: > -- Applicability to the MIDCOM Framework. > -- Identification of the MIDCOM Requirements that are satisfied > -- Identification of the MIDCOM Requirements that are > "partially" satisfied > -- Identification of the MIDCOM Requirements that are NOT > satisfied > > - Template for WG protocol evaluation draft will be made available > early in the process to provide some guidance and to solicit > WG feedback. > > Discussion of this chart revealed a concern to have detailed criteria beyond those shown. The WG will generate these more detailed requirements over next couple of weeks on the list. > > Mary's next few charts summarized the timeline for the process, based on the dates given in the preceding charts. Her final chart was as follows: > > Chart 8: Other Considerations > > - Conference calls can be scheduled to discuss issues that > have not been resolved on the list or have deadlocked, > but the goal is to work primarily via email. > > - Specific dates are subject to change, however, to meet > the August deadline, we need to stick with these at a high > level. Any changes to these proposed dates will be posted > to the list. > > - IF progress isn't being achieved with the open nature of the > proposed process, a design team MAY be formed to get the work > back on track to meet the August delivery to IESG per the WG charter. > > Melinda called for feedback on the process and on the criteria. > > Pre-MIDCOM Design Team > ====================== > > Melinda named the members: Jonathan Rosenberg, Ram Dantu , Mahadev Somasundaram , Sanjoy Sen , and Steve Davies (being replaced by Pete Cordell ). > > STUN Open Issues (Jonathan Rosenberg) > ===================================== > Changes in -00: > > - Answered UNSAF considerations - still awaiting response from IAB > > - Alignment of parameters on word boundaries > -- not compatible with original draft > > - Added missing parameter code > > - Clarified meaning of changed-address > > - Added security > > Security issue: theft attack > ---------------------------- > > - attacker snoops request > - injects fake response > - MAPPED-ADDRESS points to attacker > - client thinks this is its own address, hands it out > - media signalling applications go to attacker > Bad because it gives the attacker access to a variety of applications. > > Rohan Mahy noted limitations to the attack. If the NAT is not full cone, the attacker has to fake its source IP address to be that of STUN server. Attacker has to be on the path or local to the client. > > Solution Requirements > --------------------- > > Server authenticates itself to the client > - same domain as the in which the client launched the request. > > Client can validate the integrity of the entire response. > > Server to client authentication typically based on PK > - web model > - want to work with servers you don't share a secret with. > > Christian Huitema warned that there are NATs that will remap what they perceive to be IP addresses in the content. Hence applications have to obfuscate vulnerable portions of the content. > > -- take off-line. > > Solution approach: > ----------------- > > Cryptographic Message Syntax (CMS) RFC 2630 > > - heart of S/MIME > - syntax for signatures, certificates, etc. > > Problem: don't want to sign responses for just any request > -- would set up a potential distributed denial of service attack. > > Hence the proposed procedure has a two-stage handshake, with a cookie in the initial response. > > Issue: CMS implementation is probably 10-20 times bigger than STUN itself > - other approaches? > > Christian Huitema suggested that we may not need security for every mapping. If the first response looks OK, it should be optional to require the full signature. > > Note to authors: add the is remark to the document. > > Cullen Jennings asked why the exchange could not use a shared secret. > Jonathan responded: this would be a brake on deployment. A single STUN server may have many clients. Cullen asked why the SMTP model would not work. Melinda answered this: the trust model different -- it is necessary to narrow access to prevent spoofing. Kerberos may be applicable in a year. Cullen remarked that SIP phones don't do that. Jonathan explained further that he wanted to preserve the nature of the server as a stand-alone resource. The code readily available. Cullen indicated that code size is his precise concern. The mitigating circumstance is that TLS and MIME share technology. > > Ruling from the Chair: put it in the document, since the latter is a team output rather than a WG output. > > Jonathan continued his review of STUN status in general. Beyond what had already been described, there is little else to do. Lots of implementations are underway, and products will soon be available. draft-ietf-midcom-stun-00 will be revised and reissued after the blackout. Then it will be ready for Working Group Last Call. > > Comment: we could make the operation of the protocol more efficient by not having a timeout in the NAT so probes are not needed. Suggestion: put time value in the STUN packet from the server. Jonathan declared himself in favour. Melinda said it was in her draft last year. She will reissue that draft, ask for BOF in Yokohama (but this is a separate problem). > > Pre-MIDCOM Update (Steve Davies) > ================= > > 'Thing' > > Now a chartered item > > Design team set up to propose a solution to the Working Group. > - Draft submission date May 2. > > Allow inbound connections through midcom-unaware symmetric NATs using communications with server elements on the public side. > > Mechanism: enable a client to obtain an address at a public relay. > > PPP is in scope. > > Issues: > - avoid implicit subversion of security policy e.g. running unauthorized servers > - out-of-band vs. in-band control of relay > - are symmetric paths required? > > Tom Taylor > taylor@nortelnetworks.com > Ph. +1 613 736 0961 (ESN 396 1490) > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 9 09:30:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04590 for ; Tue, 9 Apr 2002 09:30:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA18417 for midcom-archive@odin.ietf.org; Tue, 9 Apr 2002 09:30:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17994; Tue, 9 Apr 2002 09:24:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19487 for ; Mon, 8 Apr 2002 18:52:53 -0400 (EDT) Received: from pop.mainstreet.net (smtp.mainstreet.net [207.5.0.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09131 for ; Mon, 8 Apr 2002 18:52:49 -0400 (EDT) Received: from e1a0e6 (rtr1-150.mainstreet.net [207.5.1.150] (may be forged)) by pop.mainstreet.net (8.12.1/8.12.1) with SMTP id g38MqLbp038553; Mon, 8 Apr 2002 15:52:39 -0700 (PDT) Reply-To: From: "Saqib Jang" To: "Pete Cordell" , , "Melinda Shore" , "Tom Taylor" Subject: RE: [midcom] Fwd: Draft MIDCOM Minutes Date: Mon, 8 Apr 2002 16:01:30 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-reply-to: <000201c1df23$c0ab8480$0200000a@tkw> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit What does "TCP is in scope" mean? Also, how do the goals behind the "other thing" differ from STUN? Saqib -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Pete Cordell Sent: Monday, April 08, 2002 10:27 AM To: midcom@ietf.org; Melinda Shore; Tom Taylor Subject: Re: [midcom] Fwd: Draft MIDCOM Minutes Melinda/Tom, Towards the end where TOM has said 'PPP is in scope', I think it should read 'TCP is in scope'. Also, THING is due May 02 as in May 2002 rather than 2 May. That means 32nd May to a delivery chap like me! The date is from the charter. (I thought when Steve said it that it sounded confusing.) Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: Melinda Shore To: Sent: 02 April 2002 15:13 Subject: [midcom] Fwd: Draft MIDCOM Minutes > Here are the draft minutes from the recent IETF meeting. As always, > let us know about errors, omissions, etc. > > Thanks, > > Melinda > > > The MIDCOM (Middlebox Communications) Working Group met Thursday, March 21 at 1530-1730. Melinda Shore chaired the meeting. Notes were taken by Tom Taylor (taylor@nortelnetworks.com) > > Agenda Bashing > ============== > > The agenda was accepted as proposed. > > Status > ========= > > The MIDCOM Framework and Requirements documents have both been approved for publication. > > The new charter has been approved and posted. > > STUN is due April 2002. > > Our unnamed pre-MIDCOM deliverable is due in May. > > Process Going Forward > ===================== > > Mary Barnes is to be the editor for the protocol evaluation document. > > The Working Group is doing the semantic work in parallel. > -- process to be announced next week (last week of March) > -- Tom Taylor is doing work on the semantic model. > > Jonathan Rosenberg commented that he was not sure if the work should go in parallel, given that the semantic description can be disposed of quickly. Melinda responded that the protocol evaluation will be messy and political, hence is best started as soon as possible. > > Mary Barnes presented charts describing the process going forward. > > Chart 1: Methodology Overview - Part 1 > -------------------------------------- > > - Process open to entire WG. > > - Contributors need to specify their intention to contribute > an objective evaluation of a specific protocol (by April 3rd). > -- If there are multiple volunteers for the same protocol, > priority is given to whomever puts in the first claim > with a suggestion that the interested parties work together. > -- Objective is to NOT have multiple individual contributions > for the same protocol. > > - Specific protocol evaluation to be completed by April 19th. > > - Open WG feedback on the specific proposals on the mailing list, > allowing authors to incorporate WG feedback into their contribution > to improve its positioning and completeness (April 19th- May 3rd). > > - Final version of specific protocol evaluations due on May 10th. > > - Final versions of specific protocol evaluationss due May 10 > -- template will be provided > > Some discussion of IPR followed the presentation. IPR claims must be revealed by April 3 to help people decide which protocols they want to work with. > > Chart 2: Methodology Overview - Part 2 > -------------------------------------- > > - MIDCOM WG protocol evaluation document to be comprised > from the information from the specific protocol drafts > (May 10th-May 24th) > -- Information is synthesized by the editor into a consistent > format, with an objective comparison of the various proposals > based upon the drafts (thus the responsibility is on the draft > writers to ensure they completely evaluate their protocol > against the requirements and framework and incorporate > constructive input from mailing list). > -- first version of protocol evaluation draft available on May 24th. > > - Open WG feedback on the draft (May 24th - June 7th) : > -- Discussion of amalgamated pros/cons of the various proposals > -- Any other issues with the draft. > > - Second version of draft available on June 14th: > -- One Week mailing list discussion. > -- Updated draft posted for WGLC: June 28th > -- WGLC: June 28th-July 19th. > -- Time allowed for a second iteration of WGLC > > Chart 3: Basis for evaluation > ----------------------------- > > - Fundamental basis for evaluation is: > -- MIDCOM Requirements: draft-ietf-midcom-requirements-05.txt > -- MIDCOM Framework: draft-ietf-midcom-framework-07.txt > > - Format for individual protocol evaluations is not > prescriptive but for an objective analysis should include > the following sections/content: > -- Applicability to the MIDCOM Framework. > -- Identification of the MIDCOM Requirements that are satisfied > -- Identification of the MIDCOM Requirements that are > "partially" satisfied > -- Identification of the MIDCOM Requirements that are NOT > satisfied > > - Template for WG protocol evaluation draft will be made available > early in the process to provide some guidance and to solicit > WG feedback. > > Discussion of this chart revealed a concern to have detailed criteria beyond those shown. The WG will generate these more detailed requirements over next couple of weeks on the list. > > Mary's next few charts summarized the timeline for the process, based on the dates given in the preceding charts. Her final chart was as follows: > > Chart 8: Other Considerations > > - Conference calls can be scheduled to discuss issues that > have not been resolved on the list or have deadlocked, > but the goal is to work primarily via email. > > - Specific dates are subject to change, however, to meet > the August deadline, we need to stick with these at a high > level. Any changes to these proposed dates will be posted > to the list. > > - IF progress isn't being achieved with the open nature of the > proposed process, a design team MAY be formed to get the work > back on track to meet the August delivery to IESG per the WG charter. > > Melinda called for feedback on the process and on the criteria. > > Pre-MIDCOM Design Team > ====================== > > Melinda named the members: Jonathan Rosenberg, Ram Dantu , Mahadev Somasundaram , Sanjoy Sen , and Steve Davies (being replaced by Pete Cordell ). > > STUN Open Issues (Jonathan Rosenberg) > ===================================== > Changes in -00: > > - Answered UNSAF considerations - still awaiting response from IAB > > - Alignment of parameters on word boundaries > -- not compatible with original draft > > - Added missing parameter code > > - Clarified meaning of changed-address > > - Added security > > Security issue: theft attack > ---------------------------- > > - attacker snoops request > - injects fake response > - MAPPED-ADDRESS points to attacker > - client thinks this is its own address, hands it out > - media signalling applications go to attacker > Bad because it gives the attacker access to a variety of applications. > > Rohan Mahy noted limitations to the attack. If the NAT is not full cone, the attacker has to fake its source IP address to be that of STUN server. Attacker has to be on the path or local to the client. > > Solution Requirements > --------------------- > > Server authenticates itself to the client > - same domain as the in which the client launched the request. > > Client can validate the integrity of the entire response. > > Server to client authentication typically based on PK > - web model > - want to work with servers you don't share a secret with. > > Christian Huitema warned that there are NATs that will remap what they perceive to be IP addresses in the content. Hence applications have to obfuscate vulnerable portions of the content. > > -- take off-line. > > Solution approach: > ----------------- > > Cryptographic Message Syntax (CMS) RFC 2630 > > - heart of S/MIME > - syntax for signatures, certificates, etc. > > Problem: don't want to sign responses for just any request > -- would set up a potential distributed denial of service attack. > > Hence the proposed procedure has a two-stage handshake, with a cookie in the initial response. > > Issue: CMS implementation is probably 10-20 times bigger than STUN itself > - other approaches? > > Christian Huitema suggested that we may not need security for every mapping. If the first response looks OK, it should be optional to require the full signature. > > Note to authors: add the is remark to the document. > > Cullen Jennings asked why the exchange could not use a shared secret. > Jonathan responded: this would be a brake on deployment. A single STUN server may have many clients. Cullen asked why the SMTP model would not work. Melinda answered this: the trust model different -- it is necessary to narrow access to prevent spoofing. Kerberos may be applicable in a year. Cullen remarked that SIP phones don't do that. Jonathan explained further that he wanted to preserve the nature of the server as a stand-alone resource. The code readily available. Cullen indicated that code size is his precise concern. The mitigating circumstance is that TLS and MIME share technology. > > Ruling from the Chair: put it in the document, since the latter is a team output rather than a WG output. > > Jonathan continued his review of STUN status in general. Beyond what had already been described, there is little else to do. Lots of implementations are underway, and products will soon be available. draft-ietf-midcom-stun-00 will be revised and reissued after the blackout. Then it will be ready for Working Group Last Call. > > Comment: we could make the operation of the protocol more efficient by not having a timeout in the NAT so probes are not needed. Suggestion: put time value in the STUN packet from the server. Jonathan declared himself in favour. Melinda said it was in her draft last year. She will reissue that draft, ask for BOF in Yokohama (but this is a separate problem). > > Pre-MIDCOM Update (Steve Davies) > ================= > > 'Thing' > > Now a chartered item > > Design team set up to propose a solution to the Working Group. > - Draft submission date May 2. > > Allow inbound connections through midcom-unaware symmetric NATs using communications with server elements on the public side. > > Mechanism: enable a client to obtain an address at a public relay. > > PPP is in scope. > > Issues: > - avoid implicit subversion of security policy e.g. running unauthorized servers > - out-of-band vs. in-band control of relay > - are symmetric paths required? > > Tom Taylor > taylor@nortelnetworks.com > Ph. +1 613 736 0961 (ESN 396 1490) > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 12 06:16:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01479 for ; Fri, 12 Apr 2002 06:16:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA05972 for midcom-archive@odin.ietf.org; Fri, 12 Apr 2002 06:16:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA04898; Fri, 12 Apr 2002 05:57:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA04875 for ; Fri, 12 Apr 2002 05:57:58 -0400 (EDT) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29700 for ; Fri, 12 Apr 2002 05:57:54 -0400 (EDT) Received: from jku2.fokus.gmd.de (dial43.cesnet.cz [195.113.150.43]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g3C9wvZ26716; Fri, 12 Apr 2002 11:58:58 +0200 Message-Id: <5.1.0.14.0.20020412111442.0240c408@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 12 Apr 2002 11:29:48 +0200 To: "Tom-PT Taylor", "'Martin Stiemerling'" , "Sanjoy Sen" From: Jiri Kuthan Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Cc: midcom@ietf.org, "Cedric Aoun" In-Reply-To: <4D79C746863DD51197690002A52CDA0001E8A277@zcard0kc.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I think people mix up two issues: rule overlapping and access control. I argumented against rule overlapping -- I want to disallow rules with different packet matching expressions with packets matching both of them. Doing anything else is a ticket for unneeded complexity and I see reluctance to enter such business on mailing list. The other, security-policy issue is how access to rules with identical packet matching expressions is governed. Which is a different discussion. -Jiri At 06:43 PM 4/5/2002, Tom-PT Taylor wrote: >Assuming that contradictions are possible (see my previous message), Please NO. > we should distinguish two cases: > - a specific Agent contradicts a Policy Rule installed previously by that same Agent > - a specific Agent contradicts a Policy Rule installed by another Agent. > >An underlying premise of our proposed semantics is that each Policy Rule (defined as a set of {Filter, Action} pairs with a specific Policy Rule Identifier) has one or more owners. That is, the Middlebox remembers the Agent(s) who installed those rules. > >Whether more than one Agent should be able to work with the same Policy Rule is a matter for discussion, though I sense an inclination not to allow this. (But it seems to me that an Administrator should be able to audit all installed Policy Rules and deactivate any of them if need be.) On the other hand, I think it is accepted that different Policy Rules could overlap in their scope. So I'll concentrate my discussion on the case where a new Policy Rule is in conflict with a previously installed Policy Rule. > >I would suggest a general approach to conflicts of this form: > > - If an Agent contradicts itself, the Middlebox denies the new Policy Rule Request. It returns an appropriate reason code and the Policy Rule Identifier of the rule which is in conflict. The Agent then has the information it needs to choose between modifying the already-existing rule to accommodate the new conditions or giving up on the new Policy Rule. > > - If an Agent contradicts another Agent, Agent priorities come into play. I'm happy enough to allow only two priorities: Administrator and others, but I'm not sure we need to specify this, only that there exists a hierarchy of Agent priorities. The general rule is then that the Policy Rule installed by the higher priority agent prevails and the other one is rejected or deactivated as the case may be. Between equal-priority Agents, existing Policy Rules take priority over new ones. > >One open question is what diagnostic information should be supplied when a Policy Rule is rejected or deactivated. I see the following possibilities: > >(1) The Middlebox computes and returns a modified Policy Rule that would be consistent with the over-riding Policy Rule. > >(2) The Middlebox returns the complete contents of the over-riding Policy Rule. >(3) The Middlebox returns the (sub)set of {Filter, Action} pairs within the over-riding Policy Rule which are in conflict with the disallowed Policy Rule. > >(4) The Middlebox returns a set of filters which describe the precise area of conflict with the over-riding Policy Rule. > >I have a bit of a concern with privacy which inclines me to alternative (4). > >-----Original Message----- >From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] >Sent: Friday, April 05, 2002 9:57 AM >To: Sen, Sanjoy [NGC:B692:EXCH] >Cc: 'Jiri Kuthan'; Taylor, Tom-PT [CAR:B800:EXCH]; midcom@ietf.org; >Aoun, Cedric [QPD:MA01:EXCH] >Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content > >Sanjoy Sen wrote: > >> How will then the following requirement from Midcom requirements draft >> be satisfied? >> ***** >> 2.2.11. >> >> It should be possible to define rulesets that contain a more spe- >> cific filter spec than an overlapping ruleset. This should allow >> agents to request actions for the subset that contradict those of >> the overlapping set. >> ***** > > > > >> Whether you want it or not, there would be overlapping rulesets because >> the filterspec may overlap for different rulesets installed by >> independent agents. The question - who wins when there're contradictory > >> actions is moot because the requirement above seems to suggest that we >> need to allow contradictory behavior. > >The questions is, who will decide how to behave in such a case? There >are so many combinations of firewall/NAT configurations which will make >it difficult to define a stable behaviour, i.e. how to react with this >overlapping set. Furthermore, the requirement starts with "should"... > >Martin >-- >Martin Stiemerling > >NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de >IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 12 08:48:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17125 for ; Fri, 12 Apr 2002 08:48:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA13390 for midcom-archive@odin.ietf.org; Fri, 12 Apr 2002 08:48:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12879; Fri, 12 Apr 2002 08:36:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12848 for ; Fri, 12 Apr 2002 08:36:07 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15862 for ; Fri, 12 Apr 2002 08:36:04 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id A4B5E7780116; Fri, 12 Apr 2002 08:36:05 -0400 Message-ID: <001901c1e21e$3f7f7b20$2300000a@acmepacket.com> From: "Bob Penfield" To: References: <5.1.0.14.0.20020412111442.0240c408@mailhost.fokus.gmd.de> Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Fri, 12 Apr 2002 08:33:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Jiri Kuthan" > I think people mix up two issues: rule overlapping and access control. > > I argumented against rule overlapping -- I want to disallow rules > with different packet matching expressions with packets matching > both of them. Doing anything else is a ticket for unneeded complexity > and I see reluctance to enter such business on mailing list. > I think there is value to have a rule whose filter is a subset of another rule. In pictures, this: +-------------------------+ |Filter 1 | | +-------------+ | | | Filter 2 | | | | | | | +-------------+ | | | +-------------------------+ Instead of this: +-------------------------+ |Filter 1 | | +-------------------------+ | |XXXXXXXXXXXX Filter 2 | | |XXXXXXXXXXXX | | |XXXXXXXXXXXX | | +-------------------------+ | | +-------------------------+ A common example given is a where Filter 1 is broad and allows packets thru, and Filter 2 defines a narrower set to be disallowed. > The other, security-policy issue is how access to rules > with identical packet matching expressions is governed. Which is > a different discussion. > > -Jiri _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 12 09:02:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18606 for ; Fri, 12 Apr 2002 09:02:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA14283 for midcom-archive@odin.ietf.org; Fri, 12 Apr 2002 09:02:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13578; Fri, 12 Apr 2002 08:52:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13552 for ; Fri, 12 Apr 2002 08:52:46 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17479 for ; Fri, 12 Apr 2002 08:52:43 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3CCptD27979; Fri, 12 Apr 2002 08:51:55 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <2WJAN1RB>; Fri, 12 Apr 2002 08:51:56 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A2E3@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Jiri Kuthan'" , "'Martin Stiemerling'" , "Sanjoy Sen" Cc: midcom@ietf.org, "Cedric Aoun" Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Fri, 12 Apr 2002 08:51:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E220.D3617F1C" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E220.D3617F1C Content-Type: text/plain; charset="iso-8859-1" I agree with your distinction between the issues of rule overlapping and access control. I do wonder if you are being too dogmatic on the matter of rule overlapping, and would beg for exceptions in two cases: -- the rules do not involve contradictory actions (e.g. both rules allow flows) -- the rules both come from the same Agent. Here is an example scenario in which I could see the possibility of rule overlapping: a rule is set up allowing any node inside to connect to a specific address outside. Then an Agent sets up a rule allowing connection from a specific inside address to that outside address. In the process, the Agent receives an address binding to the mapped address at the Middlebox. Using the notation I have proposed earlier, the first rule is: Filter= { Source address: ANY, Source port: ANY, Source realm: , Map address: ANY, Map port: ANY, Map realm: , Destination address: , Destination port: , Destination realm: , Protocol }, Action = Allow The second, more specific rule is: Filter= { Source address: , Source port: , Source realm: , Map address: CHOOSE, Map port: CHOOSE, Map realm: , Destination address: , Destination port: , Destination realm: }, Action = Allow In response to this second rule the Middlebox reports the bindings it has assigned for the CHOOSE entries. I can think of one or two arguments you may have against this sort of situation, but I don't know which particular arguments you would choose. So I'll see what you have to say. As for allowing an Agent to amend or contradict itself, I see this as a matter of convenience. It makes it easier to associate specific Policy Rules with specific application sessions, regardless of how they interact. If you disallow it, the workaround is for the agent to combine everything into a single Policy Rule. This is OK provided that the Agent knows that it itself is the source of the overlap. -----Original Message----- From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de] Sent: Friday, April 12, 2002 5:30 AM To: Taylor, Tom-PT [CAR:B800:EXCH]; 'Martin Stiemerling'; Sen, Sanjoy [NGC:B692:EXCH] Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content I think people mix up two issues: rule overlapping and access control. I argumented against rule overlapping -- I want to disallow rules with different packet matching expressions with packets matching both of them. Doing anything else is a ticket for unneeded complexity and I see reluctance to enter such business on mailing list. The other, security-policy issue is how access to rules with identical packet matching expressions is governed. Which is a different discussion. -Jiri At 06:43 PM 4/5/2002, Tom-PT Taylor wrote: >Assuming that contradictions are possible (see my previous message), Please NO. > we should distinguish two cases: > - a specific Agent contradicts a Policy Rule installed previously by that same Agent > - a specific Agent contradicts a Policy Rule installed by another Agent. > >An underlying premise of our proposed semantics is that each Policy Rule (defined as a set of {Filter, Action} pairs with a specific Policy Rule Identifier) has one or more owners. That is, the Middlebox remembers the Agent(s) who installed those rules. > >Whether more than one Agent should be able to work with the same Policy Rule is a matter for discussion, though I sense an inclination not to allow this. (But it seems to me that an Administrator should be able to audit all installed Policy Rules and deactivate any of them if need be.) On the other hand, I think it is accepted that different Policy Rules could overlap in their scope. So I'll concentrate my discussion on the case where a new Policy Rule is in conflict with a previously installed Policy Rule. > >I would suggest a general approach to conflicts of this form: > > - If an Agent contradicts itself, the Middlebox denies the new Policy Rule Request. It returns an appropriate reason code and the Policy Rule Identifier of the rule which is in conflict. The Agent then has the information it needs to choose between modifying the already-existing rule to accommodate the new conditions or giving up on the new Policy Rule. > > - If an Agent contradicts another Agent, Agent priorities come into play. I'm happy enough to allow only two priorities: Administrator and others, but I'm not sure we need to specify this, only that there exists a hierarchy of Agent priorities. The general rule is then that the Policy Rule installed by the higher priority agent prevails and the other one is rejected or deactivated as the case may be. Between equal-priority Agents, existing Policy Rules take priority over new ones. > >One open question is what diagnostic information should be supplied when a Policy Rule is rejected or deactivated. I see the following possibilities: > >(1) The Middlebox computes and returns a modified Policy Rule that would be consistent with the over-riding Policy Rule. > >(2) The Middlebox returns the complete contents of the over-riding Policy Rule. >(3) The Middlebox returns the (sub)set of {Filter, Action} pairs within the over-riding Policy Rule which are in conflict with the disallowed Policy Rule. > >(4) The Middlebox returns a set of filters which describe the precise area of conflict with the over-riding Policy Rule. > >I have a bit of a concern with privacy which inclines me to alternative (4). > >-----Original Message----- >From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec .de] >Sent: Friday, April 05, 2002 9:57 AM >To: Sen, Sanjoy [NGC:B692:EXCH] >Cc: 'Jiri Kuthan'; Taylor, Tom-PT [CAR:B800:EXCH]; midcom@ietf.org; >Aoun, Cedric [QPD:MA01:EXCH] >Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content > >Sanjoy Sen wrote: > >> How will then the following requirement from Midcom requirements draft >> be satisfied? >> ***** >> 2.2.11. >> >> It should be possible to define rulesets that contain a more spe- >> cific filter spec than an overlapping ruleset. This should allow >> agents to request actions for the subset that contradict those of >> the overlapping set. >> ***** > > > > >> Whether you want it or not, there would be overlapping rulesets because >> the filterspec may overlap for different rulesets installed by >> independent agents. The question - who wins when there're contradictory > >> actions is moot because the requirement above seems to suggest that we >> need to allow contradictory behavior. > >The questions is, who will decide how to behave in such a case? There >are so many combinations of firewall/NAT configurations which will make >it difficult to define a stable behaviour, i.e. how to react with this >overlapping set. Furthermore, the requirement starts with "should"... > >Martin >-- >Martin Stiemerling > >NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de >IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de ------_=_NextPart_001_01C1E220.D3617F1C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] MIDCOM SEmantics: Policy Rule Content

I agree with your distinction between the issues of = rule overlapping and access control.  I do wonder if you are being = too dogmatic on the matter of rule overlapping, and would beg for = exceptions in two cases:

  -- the rules do not involve contradictory = actions (e.g. both rules allow flows)

  -- the rules both come from the same = Agent.

Here is an example scenario in which I could see the = possibility of rule overlapping: a rule is set up allowing any node = inside to connect to a specific address outside.  Then an Agent = sets up a rule allowing connection from a specific inside address to = that outside address.  In the process, the Agent receives an = address binding to the mapped address at the Middlebox.  Using the = notation I have proposed earlier, the first rule is:

Filter=3D { Source = address:      ANY,
          Source = port:         ANY,
          Source = realm:        <the internal = realm>,
          Map = address:         ANY,
          Map = port:            = ANY,
          Map = realm:           = <the external realm>,
          = Destination address: <specific external address>,
          = Destination port:    <specific external = port>,
          = Destination realm:   <the external realm>,
          = Protocol          &nbs= p;  <a specific protocol> },

Action =3D Allow

The second, more specific rule is:

Filter=3D { Source = address:      <specific internal = address>,
          Source = port:         <specific = internal port>,
          Source = realm:        <the internal = realm>,
          Map = address:         CHOOSE,
          Map = port:            = CHOOSE,
          Map = realm:           = <the external realm>,
          = Destination address: <specific external address>,
          = Destination port:    <specific external = port>,
          = Destination realm:   <the external realm> },

Action =3D Allow

In response to this second rule the Middlebox reports = the bindings it has assigned for the CHOOSE entries.

I can think of one or two arguments you may have = against this sort of situation, but I don't know which particular = arguments you would choose.  So I'll see what you have to = say.

As for allowing an Agent to amend or contradict = itself, I see this as a matter of convenience.  It makes it easier = to associate specific Policy Rules with specific application sessions, = regardless of how they interact.  If you disallow it, the = workaround is for the agent to combine everything into a single Policy = Rule.  This is OK provided that the Agent knows that it itself is = the source of the overlap.


-----Original Message-----
From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de]
Sent: Friday, April 12, 2002 5:30 AM
To: Taylor, Tom-PT [CAR:B800:EXCH]; 'Martin = Stiemerling'; Sen, Sanjoy
[NGC:B692:EXCH]
Cc: midcom@ietf.org; Aoun, Cedric = [QPD:MA01:EXCH]
Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule = Content


I think people mix up two issues: rule overlapping = and access control.

I argumented against rule overlapping -- I want to = disallow rules
with different packet matching expressions with = packets matching
both of them. Doing anything else is a ticket for = unneeded complexity
and I see reluctance to enter such business on = mailing list.

The other, security-policy issue is how access to = rules
with identical packet matching expressions is = governed. Which is
a different discussion.

-Jiri

At 06:43 PM 4/5/2002, Tom-PT Taylor wrote:

>Assuming that contradictions are possible (see my = previous message),

Please NO.

> we should distinguish two cases:
> - a specific Agent contradicts a Policy Rule = installed previously by that same Agent
> - a specific Agent contradicts a Policy Rule = installed by another Agent.
>
>An underlying premise of our proposed semantics = is that each Policy Rule (defined as a set of {Filter, Action} pairs = with a specific Policy Rule Identifier) has one or more owners.  = That is, the Middlebox remembers the Agent(s) who installed those = rules.

>
>Whether more than one Agent should be able to = work with the same Policy Rule is a matter for discussion, though I = sense an inclination not to allow this.  (But it seems to me that = an Administrator should be able to audit all installed Policy Rules and = deactivate any of them if need be.)  On the other hand, I think it = is accepted that different Policy Rules could overlap in their = scope.  So I'll concentrate my discussion on the case where a new = Policy Rule is in conflict with a previously installed Policy = Rule.

>
>I would suggest a general approach to conflicts = of this form:
>
> - If an Agent contradicts itself, the Middlebox = denies the new Policy Rule Request.  It returns an appropriate = reason code and the Policy Rule Identifier of the rule which is in = conflict.  The Agent then has the information it needs to choose = between modifying the already-existing rule to accommodate the new = conditions or giving up on the new Policy Rule.

>
> - If an Agent contradicts another Agent, Agent = priorities come into play.  I'm happy enough to allow only two = priorities: Administrator and others, but I'm not sure we need to = specify this, only that there exists a hierarchy of Agent = priorities.  The general rule is then that the Policy Rule = installed by the higher priority agent prevails and the other one is = rejected or deactivated as the case may be.  Between = equal-priority Agents, existing Policy Rules take priority over new = ones.

>
>One open question is what diagnostic information = should be supplied when a Policy Rule is rejected or deactivated.  = I see the following possibilities:

>
>(1) The Middlebox computes and returns a = modified Policy Rule that would be consistent with the over-riding = Policy Rule.

>
>(2) The Middlebox returns the complete contents = of the over-riding Policy Rule.
>(3) The Middlebox returns the (sub)set of = {Filter, Action} pairs within the over-riding Policy Rule which are in = conflict with the disallowed Policy Rule.

>
>(4) The Middlebox returns a set of filters which = describe the precise area of conflict with the over-riding Policy = Rule.

>
>I have a bit of a concern with privacy which = inclines me to alternative (4).
>
>-----Original Message-----
>From: Martin Stiemerling [<mailto:Martin.Stiemerlin= g@ccrle.nec.de>mailto:Martin.Stiemerlin= g@ccrle.nec.de]
>Sent: Friday, April 05, 2002 9:57 AM
>To: Sen, Sanjoy [NGC:B692:EXCH]
>Cc: 'Jiri Kuthan'; Taylor, Tom-PT = [CAR:B800:EXCH]; midcom@ietf.org;
>Aoun, Cedric [QPD:MA01:EXCH]
>Subject: Re: [midcom] MIDCOM SEmantics: Policy = Rule Content
>
>Sanjoy Sen wrote:
>
>> How will then the following requirement = from Midcom requirements draft
>> be satisfied?
>> *****
>> 2.2.11.
>>
>>      It should be = possible to define rulesets that contain a more spe-
>>      cific filter = spec than an overlapping ruleset.  This should allow
>>      agents to = request actions for the subset that contradict those of
>>      the = overlapping set.
>> *****
>
> >
>
>> Whether you want it or not, there would be = overlapping rulesets because
>> the filterspec may overlap for different = rulesets installed by
>> independent agents. The question - who wins = when there're contradictory
>
>> actions is moot because the requirement = above seems to suggest that we
>> need to allow contradictory behavior. =
>
>The questions is, who will decide how to behave = in such a case? There
>are so many combinations of firewall/NAT = configurations which will make
>it difficult to define a stable behaviour, i.e. = how to react with this
>overlapping set. Furthermore, the requirement = starts with "should"...
>
>Martin
>--
>Martin Stiemerling
>
>NEC Europe Ltd. -- Network Laboratories  = Stiemerling@ccrle.nec.de
>IPv4: <http://www.ccrle.nec.de>http://www.ccrle.nec.de  IPv6: <http://www.ipv6.ccrle.nec.de>http://www.ipv6.ccrle.nec.de

------_=_NextPart_001_01C1E220.D3617F1C-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 12 10:24:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28839 for ; Fri, 12 Apr 2002 10:24:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA18420 for midcom-archive@odin.ietf.org; Fri, 12 Apr 2002 10:24:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18104; Fri, 12 Apr 2002 10:14:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18017 for ; Fri, 12 Apr 2002 10:14:39 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27574 for ; Fri, 12 Apr 2002 10:14:35 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id ABCBC6EF0052; Fri, 12 Apr 2002 10:14:35 -0400 Message-ID: <007601c1e22b$ff23ec60$2300000a@acmepacket.com> From: "Bob Penfield" To: "Tom-PT Taylor" , References: <4D79C746863DD51197690002A52CDA0001E8A229@zcard0kc.ca.nortel.com> Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Fri, 12 Apr 2002 10:11:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Tom-PT Taylor" > Let us turn now to the detailed semantic content of the {Filter, Action} > pairs. As the examples of section 4 illustrate, it is possible to represent > NAT and firewall policies using sets of uni-directional filters of the form > > {, , , > Protocol} I would think that the filter would contain only the data used to match packets. The Map Address-Port would part of the action. Also, I don't think a single Map Address-Port is sufficient. I see the parameters in the Filter as follows: Source Address-Port Destination Address-Port Transport Protocol (UDP, TCP, etc) The actions would include: New Source Address-Port New Destination Address-Port Allow/Disallow _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Apr 12 12:36:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16312 for ; Fri, 12 Apr 2002 12:36:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27329 for midcom-archive@odin.ietf.org; Fri, 12 Apr 2002 12:36:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26330; Fri, 12 Apr 2002 12:17:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26302 for ; Fri, 12 Apr 2002 12:17:22 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13253 for ; Fri, 12 Apr 2002 12:17:18 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3CGGiq12963 for ; Fri, 12 Apr 2002 11:16:44 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2Y3TTR4X>; Fri, 12 Apr 2002 11:16:44 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A03DE39AB@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'midcom@ietf.org'" Date: Fri, 12 Apr 2002 11:16:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E23D.6B05F700" Subject: [midcom] MIDCOM Protocol Evaluation: Clarification of "Partial Compliance" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E23D.6B05F700 Content-Type: text/plain; charset="iso-8859-1" Hi all, I've had a couple queries and discussions as to the meaning of "Partial Compliance" in section 3 and 4.1.3 of the protocol evaluation template. My view is that if the protocol can be extended (within the extensibility guidelines for that protocol, doesn't break anything and it's still within the "spririt" of the protocol), then it would be Partially compliant to that requirement (and not a Failed requirement). BEWARE: that this is contrary to what the text in the template implies in section 4.1.4, so I need to update the template! Also, it's quite likely there may be disagreements on specific classifications, so it is imperative that there be some text describing the context for each of the Compliancy claims in sections 4.1.2, 4.1.3 and 4.1.4." There may be other examples that I've not thought of as far as "Partial Compliance", so it would be useful if those authoring the documents post those to the list for discussion as well. As a reminder the deadline for the initial submission is one week away: April 19th Final cutoff for specific protocol drafts. * The mandatory sections for this document are outlined in section 4.1 of the template at: http://www.obsidian97.com/draft-midcom-protocol-eval-template.txt April 19th- May 3rd Mailing list discussion of specific protocol drafts, allowing authors to incorporate WG feedback into their contribution to improve comparison and add completeness. May 10th Deadline for any updates to protocol drafts. Regards, Mary. ------_=_NextPart_001_01C1E23D.6B05F700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIDCOM Protocol Evaluation: Clarification of "Partial = Compliance"

Hi all,

I've had a couple queries and discussions as to the = meaning of "Partial Compliance" in section 3 and 4.1.3 of the = protocol evaluation template. My view is that if the protocol can be = extended (within the extensibility guidelines for that protocol, = doesn't break anything and it's still within the "spririt" of = the protocol), then it would be Partially compliant to that requirement = (and not a Failed requirement).  BEWARE: that this is contrary to = what the text in the template implies in section 4.1.4, so I need to = update the template!

Also, it's quite likely there may be disagreements on = specific classifications, so it is imperative that there be some text = describing the context for each of the Compliancy claims in sections = 4.1.2, 4.1.3 and 4.1.4."

There may be other examples that I've not thought of = as far as "Partial Compliance", so it would be useful if = those authoring the documents post those to the list for discussion as = well. 

As a reminder the deadline for the initial submission = is one week away:

April 19th      Final cutoff = for specific protocol drafts.
          &nb= sp;    *  The mandatory sections for this document = are
          &nb= sp;       outlined in section 4.1 of = the     
          &nb= sp;       template at:
http://www.obsidian97.com/draft-midcom-protocol-eval-t= emplate.txt

April 19th- May 3rd     Mailing = list discussion of specific
          &nb= sp;           &nb= sp; protocol drafts, allowing authors to
          &nb= sp;           &nb= sp; incorporate WG feedback into their 
          &nb= sp;           &nb= sp; contribution to improve comparison and
          &nb= sp;           &nb= sp; add completeness.

May 10th        = Deadline for any updates to protocol drafts.


Regards,
Mary.
 
 

------_=_NextPart_001_01C1E23D.6B05F700-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Apr 12 13:47:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25152 for ; Fri, 12 Apr 2002 13:47:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA00798 for midcom-archive@odin.ietf.org; Fri, 12 Apr 2002 13:47:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00322; Fri, 12 Apr 2002 13:35:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00288 for ; Fri, 12 Apr 2002 13:35:16 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23869 for ; Fri, 12 Apr 2002 13:34:58 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3CHYRD03887 for ; Fri, 12 Apr 2002 13:34:28 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <2WJANPDB>; Fri, 12 Apr 2002 13:34:28 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A2EC@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Bob Penfield'" , midcom@ietf.org Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Fri, 12 Apr 2002 13:34:27 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I partly agree with you. When the Agent is asking for a mapping to be granted, the Map Address-Port is a return value, not really part of the filter. Since we are talking semantics rather than protocol notation, the distinction should be made clear. On the other hand, when a mapping has been granted previously and the Agent is now enabling a specific flow, the Map-Address-Port is legitimately part of the flow specification. To show what I mean, suppose we are talking about a rule allowing inbound flows to a service. To set this up, the Agent issues a request like this: Source Address: Any Source Port: Any Destination Address: Destination Port: Protocol: TCP Action: new destination address-port The response provides a specific Map-Address-Port as requested. Now consider a rule allowing inbound flows through that mapped address-port, from a specific external address. (To avoid extraneous issues, assume it is replacing the previous rule.) The rule should have the form: Source Address: Source Port: Destination Address: Destination Port: Protocol: TCP Action: allow One other point: do your actions "new source address" and "new destination address" mean what I think they mean: - new source address: please assign an address which will appear as the external source of flows originated from inside - new destination address: please assign an address which will appear as the external destination of flows being forwarded to the inside? -----Original Message----- From: Bob Penfield [mailto:bpenfield@acmepacket.com] Sent: Friday, April 12, 2002 10:12 AM To: Taylor, Tom-PT [CAR:B800:EXCH]; midcom@ietf.org Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content ----- Original Message ----- From: "Tom-PT Taylor" > Let us turn now to the detailed semantic content of the {Filter, Action} > pairs. As the examples of section 4 illustrate, it is possible to represent > NAT and firewall policies using sets of uni-directional filters of the form > > {, , , > Protocol} I would think that the filter would contain only the data used to match packets. The Map Address-Port would part of the action. Also, I don't think a single Map Address-Port is sufficient. I see the parameters in the Filter as follows: Source Address-Port Destination Address-Port Transport Protocol (UDP, TCP, etc) The actions would include: New Source Address-Port New Destination Address-Port Allow/Disallow _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Apr 12 13:58:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26516 for ; Fri, 12 Apr 2002 13:58:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA01152 for midcom-archive@odin.ietf.org; Fri, 12 Apr 2002 13:58:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29371; Fri, 12 Apr 2002 13:21:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29289 for ; Fri, 12 Apr 2002 13:21:33 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22167 for ; Fri, 12 Apr 2002 13:21:30 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3CHKeq02647; Fri, 12 Apr 2002 12:20:40 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2Y3TTTJV>; Fri, 12 Apr 2002 12:20:41 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E01187A76@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "Tom-PT Taylor", "'Jiri Kuthan'" , "'Martin Stiemerling'" Cc: "'midcom@ietf.org'" , "Cedric Aoun" Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Fri, 12 Apr 2002 12:20:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E246.5D9C5880" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E246.5D9C5880 Content-Type: text/plain; charset="iso-8859-1" I support this as a good compromise. We should disallow contradictions in overlapping rulesets (and resolve on a FCFS basis). But, we should allow overlapping rulesets if there's no contradiction. > -----Original Message----- > From: Taylor, Tom-PT [CAR:B800:EXCH] > Sent: Friday, April 12, 2002 7:52 AM > To: 'Jiri Kuthan'; 'Martin Stiemerling'; Sen, Sanjoy [NGC:B692:EXCH] > Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] > Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content > > > I agree with your distinction between the issues of rule > overlapping and access control. I do wonder if you are being > too dogmatic on the matter of rule overlapping, and would beg > for exceptions in two cases: > > -- the rules do not involve contradictory actions (e.g. > both rules allow flows) > > -- the rules both come from the same Agent. > > Here is an example scenario in which I could see the > possibility of rule overlapping: a rule is set up allowing > any node inside to connect to a specific address outside. > Then an Agent sets up a rule allowing connection from a > specific inside address to that outside address. In the > process, the Agent receives an address binding to the mapped > address at the Middlebox. Using the notation I have proposed > earlier, the first rule is: > > Filter= { Source address: ANY, > Source port: ANY, > Source realm: , > Map address: ANY, > Map port: ANY, > Map realm: , > Destination address: , > Destination port: , > Destination realm: , > Protocol }, > > Action = Allow > > The second, more specific rule is: > > Filter= { Source address: , > Source port: , > Source realm: , > Map address: CHOOSE, > Map port: CHOOSE, > Map realm: , > Destination address: , > Destination port: , > Destination realm: }, > > Action = Allow > > In response to this second rule the Middlebox reports the > bindings it has assigned for the CHOOSE entries. > > I can think of one or two arguments you may have against this > sort of situation, but I don't know which particular > arguments you would choose. So I'll see what you have to say. > > As for allowing an Agent to amend or contradict itself, I see > this as a matter of convenience. It makes it easier to > associate specific Policy Rules with specific application > sessions, regardless of how they interact. If you disallow > it, the workaround is for the agent to combine everything > into a single Policy Rule. This is OK provided that the > Agent knows that it itself is the source of the overlap. > > > -----Original Message----- > From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de] > Sent: Friday, April 12, 2002 5:30 AM > To: Taylor, Tom-PT [CAR:B800:EXCH]; 'Martin Stiemerling'; Sen, Sanjoy > [NGC:B692:EXCH] > Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] > Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content > > > I think people mix up two issues: rule overlapping and access control. > > I argumented against rule overlapping -- I want to disallow rules > with different packet matching expressions with packets matching > both of them. Doing anything else is a ticket for unneeded complexity > and I see reluctance to enter such business on mailing list. > > The other, security-policy issue is how access to rules > with identical packet matching expressions is governed. Which is > a different discussion. > > -Jiri > > At 06:43 PM 4/5/2002, Tom-PT Taylor wrote: > > >Assuming that contradictions are possible (see my previous message), > > Please NO. > > > we should distinguish two cases: > > - a specific Agent contradicts a Policy Rule installed > previously by that same Agent > > - a specific Agent contradicts a Policy Rule installed by > another Agent. > > > >An underlying premise of our proposed semantics is that each > Policy Rule (defined as a set of {Filter, Action} pairs with > a specific Policy Rule Identifier) has one or more owners. > That is, the Middlebox remembers the Agent(s) who installed > those rules. > > > >Whether more than one Agent should be able to work with the > same Policy Rule is a matter for discussion, though I sense > an inclination not to allow this. (But it seems to me that > an Administrator should be able to audit all installed Policy > Rules and deactivate any of them if need be.) On the other > hand, I think it is accepted that different Policy Rules > could overlap in their scope. So I'll concentrate my > discussion on the case where a new Policy Rule is in conflict > with a previously installed Policy Rule. > > > >I would suggest a general approach to conflicts of this form: > > > > - If an Agent contradicts itself, the Middlebox denies the > new Policy Rule Request. It returns an appropriate reason > code and the Policy Rule Identifier of the rule which is in > conflict. The Agent then has the information it needs to > choose between modifying the already-existing rule to > accommodate the new conditions or giving up on the new Policy Rule. > > > > - If an Agent contradicts another Agent, Agent priorities > come into play. I'm happy enough to allow only two > priorities: Administrator and others, but I'm not sure we > need to specify this, only that there exists a hierarchy of > Agent priorities. The general rule is then that the Policy > Rule installed by the higher priority agent prevails and the > other one is rejected or deactivated as the case may be. > Between equal-priority Agents, existing Policy Rules take > priority over new ones. > > > >One open question is what diagnostic information should be > supplied when a Policy Rule is rejected or deactivated. I > see the following possibilities: > > > >(1) The Middlebox computes and returns a modified Policy > Rule that would be consistent with the over-riding Policy Rule. > > > >(2) The Middlebox returns the complete contents of the > over-riding Policy Rule. > >(3) The Middlebox returns the (sub)set of {Filter, Action} > pairs within the over-riding Policy Rule which are in > conflict with the disallowed Policy Rule. > > > >(4) The Middlebox returns a set of filters which describe > the precise area of conflict with the over-riding Policy Rule. > > > >I have a bit of a concern with privacy which inclines me to > alternative (4). > > > >-----Original Message----- > >From: Martin Stiemerling > [mailto:Martin.Stiemer ling@ccrle.nec.de] >Sent: Friday, April 05, 2002 9:57 AM >To: Sen, Sanjoy [NGC:B692:EXCH] >Cc: 'Jiri Kuthan'; Taylor, Tom-PT [CAR:B800:EXCH]; midcom@ietf.org; >Aoun, Cedric [QPD:MA01:EXCH] >Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content > >Sanjoy Sen wrote: > >> How will then the following requirement from Midcom requirements draft >> be satisfied? >> ***** >> 2.2.11. >> >> It should be possible to define rulesets that contain a more spe- >> cific filter spec than an overlapping ruleset. This should allow >> agents to request actions for the subset that contradict those of >> the overlapping set. >> ***** > > > > >> Whether you want it or not, there would be overlapping rulesets because >> the filterspec may overlap for different rulesets installed by >> independent agents. The question - who wins when there're contradictory > >> actions is moot because the requirement above seems to suggest that we >> need to allow contradictory behavior. > >The questions is, who will decide how to behave in such a case? There >are so many combinations of firewall/NAT configurations which will make >it difficult to define a stable behaviour, i.e. how to react with this >overlapping set. Furthermore, the requirement starts with "should"... > >Martin >-- >Martin Stiemerling > >NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de >IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de ------_=_NextPart_001_01C1E246.5D9C5880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] MIDCOM SEmantics: Policy Rule Content

I support this as a good compromise. We should = disallow contradictions in overlapping rulesets (and resolve on a FCFS = basis). But, we should allow overlapping rulesets if there's no = contradiction. 

> -----Original Message-----
> From: Taylor, Tom-PT [CAR:B800:EXCH]
> Sent: Friday, April 12, 2002 7:52 AM
> To: 'Jiri Kuthan'; 'Martin Stiemerling'; Sen, = Sanjoy [NGC:B692:EXCH]
> Cc: midcom@ietf.org; Aoun, Cedric = [QPD:MA01:EXCH]
> Subject: RE: [midcom] MIDCOM SEmantics: Policy = Rule Content
>
>
> I agree with your distinction between the = issues of rule
> overlapping and access control.  I do = wonder if you are being
> too dogmatic on the matter of rule overlapping, = and would beg
> for exceptions in two cases:
>
>   -- the rules do not involve = contradictory actions (e.g.
> both rules allow flows)
>
>   -- the rules both come from the = same Agent.
>
> Here is an example scenario in which I could = see the
> possibility of rule overlapping: a rule is set = up allowing
> any node inside to connect to a specific = address outside. 
> Then an Agent sets up a rule allowing = connection from a
> specific inside address to that outside = address.  In the
> process, the Agent receives an address binding = to the mapped
> address at the Middlebox.  Using the = notation I have proposed
> earlier, the first rule is:
>
> Filter=3D { Source = address:      ANY,
>          = ; Source port:         = ANY,
>          = ; Source realm:        <the = internal realm>,
>          = ; Map address:         = ANY,
>          = ; Map = port:            = ANY,
>          = ; Map = realm:           = <the external realm>,
>          = ; Destination address: <specific external address>,
>          = ; Destination port:    <specific external = port>,
>          = ; Destination realm:   <the external realm>,
>          = ; = Protocol          &nbs= p;  <a specific protocol> },
>
> Action =3D Allow
>
> The second, more specific rule is:
>
> Filter=3D { Source = address:      <specific internal = address>,
>          = ; Source port:         = <specific internal port>,
>          = ; Source realm:        <the = internal realm>,
>          = ; Map address:         = CHOOSE,
>          = ; Map = port:            = CHOOSE,
>          = ; Map = realm:           = <the external realm>,
>          = ; Destination address: <specific external address>,
>          = ; Destination port:    <specific external = port>,
>          = ; Destination realm:   <the external realm> },
>
> Action =3D Allow
>
> In response to this second rule the Middlebox = reports the
> bindings it has assigned for the CHOOSE = entries.
>
> I can think of one or two arguments you may = have against this
> sort of situation, but I don't know which = particular
> arguments you would choose.  So I'll see = what you have to say.
>
> As for allowing an Agent to amend or contradict = itself, I see
> this as a matter of convenience.  It makes = it easier to
> associate specific Policy Rules with specific = application
> sessions, regardless of how they = interact.  If you disallow
> it, the workaround is for the agent to combine = everything
> into a single Policy Rule.  This is OK = provided that the
> Agent knows that it itself is the source of the = overlap.
>
>
> -----Original Message-----
> From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de]
> Sent: Friday, April 12, 2002 5:30 AM
> To: Taylor, Tom-PT [CAR:B800:EXCH]; 'Martin = Stiemerling'; Sen, Sanjoy
> [NGC:B692:EXCH]
> Cc: midcom@ietf.org; Aoun, Cedric = [QPD:MA01:EXCH]
> Subject: RE: [midcom] MIDCOM SEmantics: Policy = Rule Content
>
>
> I think people mix up two issues: rule = overlapping and access control.
>
> I argumented against rule overlapping -- I want = to disallow rules
> with different packet matching expressions with = packets matching
> both of them. Doing anything else is a ticket = for unneeded complexity
> and I see reluctance to enter such business on = mailing list.
>
> The other, security-policy issue is how access = to rules
> with identical packet matching expressions is = governed. Which is
> a different discussion.
>
> -Jiri
>
> At 06:43 PM 4/5/2002, Tom-PT Taylor = wrote:
>
> >Assuming that contradictions are possible = (see my previous message),
>
> Please NO.
>
> > we should distinguish two cases:
> > - a specific Agent contradicts a Policy = Rule installed
> previously by that same Agent
> > - a specific Agent contradicts a Policy = Rule installed by
> another Agent.
> >
> >An underlying premise of our proposed = semantics is that each
> Policy Rule (defined as a set of {Filter, = Action} pairs with
> a specific Policy Rule Identifier) has one or = more owners. 
> That is, the Middlebox remembers the Agent(s) = who installed
> those rules.
> >
> >Whether more than one Agent should be able = to work with the
> same Policy Rule is a matter for discussion, = though I sense
> an inclination not to allow this.  (But it = seems to me that
> an Administrator should be able to audit all = installed Policy
> Rules and deactivate any of them if need = be.)  On the other
> hand, I think it is accepted that different = Policy Rules
> could overlap in their scope.  So I'll = concentrate my
> discussion on the case where a new Policy Rule = is in conflict
> with a previously installed Policy Rule.
> >
> >I would suggest a general approach to = conflicts of this form:
> >
> > - If an Agent contradicts itself, the = Middlebox denies the
> new Policy Rule Request.  It returns an = appropriate reason
> code and the Policy Rule Identifier of the rule = which is in
> conflict.  The Agent then has the = information it needs to
> choose between modifying the already-existing = rule to
> accommodate the new conditions or giving up on = the new Policy Rule.
> >
> > - If an Agent contradicts another Agent, = Agent priorities
> come into play.  I'm happy enough to allow = only two
> priorities: Administrator and others, but I'm = not sure we
> need to specify this, only that there exists a = hierarchy of
> Agent priorities.  The general rule is = then that the Policy
> Rule installed by the higher priority agent = prevails and the
> other one is rejected or deactivated as the = case may be. 
> Between equal-priority Agents, existing Policy = Rules take
> priority over new ones.
> >
> >One open question is what diagnostic = information should be
> supplied when a Policy Rule is rejected or = deactivated.  I
> see the following possibilities:
> >
> >(1) The Middlebox computes and returns a = modified Policy
> Rule that would be consistent with the = over-riding Policy Rule.
> >
> >(2) The Middlebox returns the complete = contents of the
> over-riding Policy Rule.
> >(3) The Middlebox returns the (sub)set of = {Filter, Action}
> pairs within the over-riding Policy Rule which = are in
> conflict with the disallowed Policy = Rule.
> >
> >(4) The Middlebox returns a set of filters = which describe
> the precise area of conflict with the = over-riding Policy Rule.
> >
> >I have a bit of a concern with privacy = which inclines me to
> alternative (4).
> >
> >-----Original Message-----
> >From: Martin Stiemerling
> [<mailto:Martin.Stiemerlin= g@ccrle.nec.de>mailto:Martin.Stiemer
ling@ccrle.nec.de]
>Sent: Friday, April 05, 2002 9:57 AM
>To: Sen, Sanjoy [NGC:B692:EXCH]
>Cc: 'Jiri Kuthan'; Taylor, Tom-PT = [CAR:B800:EXCH]; midcom@ietf.org;
>Aoun, Cedric [QPD:MA01:EXCH]
>Subject: Re: [midcom] MIDCOM SEmantics: Policy = Rule Content
>
>Sanjoy Sen wrote:
>
>> How will then the following requirement = from Midcom requirements draft
>> be satisfied?
>> *****
>> 2.2.11.
>>
>>      It should be = possible to define rulesets that contain a more spe-
>>      cific filter = spec than an overlapping ruleset.  This should allow
>>      agents to = request actions for the subset that contradict those of
>>      the = overlapping set.
>> *****
>
> >
>
>> Whether you want it or not, there would be = overlapping rulesets because
>> the filterspec may overlap for different = rulesets installed by
>> independent agents. The question - who wins = when there're contradictory
>
>> actions is moot because the requirement = above seems to suggest that we
>> need to allow contradictory behavior. =
>
>The questions is, who will decide how to behave = in such a case? There
>are so many combinations of firewall/NAT = configurations which will make
>it difficult to define a stable behaviour, i.e. = how to react with this
>overlapping set. Furthermore, the requirement = starts with "should"...
>
>Martin
>--
>Martin Stiemerling
>
>NEC Europe Ltd. -- Network Laboratories  = Stiemerling@ccrle.nec.de
>IPv4: <http://www.ccrle.nec.de>http://www.ccrle.nec.de  IPv6: <http://www.ipv6.ccrle.nec.de>http://www.ipv6.ccrle.nec.de

------_=_NextPart_001_01C1E246.5D9C5880-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Apr 12 14:01:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26997 for ; Fri, 12 Apr 2002 14:01:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA01579 for midcom-archive@odin.ietf.org; Fri, 12 Apr 2002 14:01:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00757; Fri, 12 Apr 2002 13:46:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00724 for ; Fri, 12 Apr 2002 13:46:23 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25115 for ; Fri, 12 Apr 2002 13:46:20 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3CHjoD04529 for ; Fri, 12 Apr 2002 13:45:50 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <2WJANPM9>; Fri, 12 Apr 2002 13:45:50 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A2ED@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "Tom-PT Taylor", "'Bob Penfield'" , midcom@ietf.org Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Fri, 12 Apr 2002 13:45:45 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Oops, had a two-hour interruption in the middle of answering this and forgot what I had to put into the final filter spec to make my point. The second filter spec should look like this: Source Address: Source Port: Map address: Map port: Destination Address: Destination Port: Protocol: TCP Action: allow -----Original Message----- From: Taylor, Tom-PT [CAR:B800:EXCH] Sent: Friday, April 12, 2002 1:34 PM To: 'Bob Penfield'; midcom@ietf.org Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content I partly agree with you. When the Agent is asking for a mapping to be granted, the Map Address-Port is a return value, not really part of the filter. Since we are talking semantics rather than protocol notation, the distinction should be made clear. On the other hand, when a mapping has been granted previously and the Agent is now enabling a specific flow, the Map-Address-Port is legitimately part of the flow specification. To show what I mean, suppose we are talking about a rule allowing inbound flows to a service. To set this up, the Agent issues a request like this: Source Address: Any Source Port: Any Destination Address: Destination Port: Protocol: TCP Action: new destination address-port The response provides a specific Map-Address-Port as requested. Now consider a rule allowing inbound flows through that mapped address-port, from a specific external address. (To avoid extraneous issues, assume it is replacing the previous rule.) The rule should have the form: Source Address: Source Port: Destination Address: Destination Port: Protocol: TCP Action: allow One other point: do your actions "new source address" and "new destination address" mean what I think they mean: - new source address: please assign an address which will appear as the external source of flows originated from inside - new destination address: please assign an address which will appear as the external destination of flows being forwarded to the inside? -----Original Message----- From: Bob Penfield [mailto:bpenfield@acmepacket.com] Sent: Friday, April 12, 2002 10:12 AM To: Taylor, Tom-PT [CAR:B800:EXCH]; midcom@ietf.org Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content ----- Original Message ----- From: "Tom-PT Taylor" > Let us turn now to the detailed semantic content of the {Filter, Action} > pairs. As the examples of section 4 illustrate, it is possible to represent > NAT and firewall policies using sets of uni-directional filters of the form > > {, , , > Protocol} I would think that the filter would contain only the data used to match packets. The Map Address-Port would part of the action. Also, I don't think a single Map Address-Port is sufficient. I see the parameters in the Filter as follows: Source Address-Port Destination Address-Port Transport Protocol (UDP, TCP, etc) The actions would include: New Source Address-Port New Destination Address-Port Allow/Disallow _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Apr 12 15:03:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00672 for ; Fri, 12 Apr 2002 15:03:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA05799 for midcom-archive@odin.ietf.org; Fri, 12 Apr 2002 15:03:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04775; Fri, 12 Apr 2002 14:51:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04747 for ; Fri, 12 Apr 2002 14:51:21 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00336 for ; Fri, 12 Apr 2002 14:51:19 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3CIoin23318 for ; Fri, 12 Apr 2002 14:50:44 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <2WJANRJ0>; Fri, 12 Apr 2002 14:50:44 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A2EE@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Christian Huitema'" , "Sanjoy Sen", Jiri Kuthan , Martin Stiemerling Cc: midcom@ietf.org, "Cedric Aoun" Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Fri, 12 Apr 2002 14:50:39 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Would the same Agent install both rules? -----Original Message----- From: Christian Huitema [mailto:huitema@windows.microsoft.com] Sent: Friday, April 12, 2002 2:24 PM To: Sen, Sanjoy [NGC:B692:EXCH]; Taylor, Tom-PT [CAR:B800:EXCH]; Jiri Kuthan; Martin Stiemerling Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content I am sorry, but the requirement was there for a very strong operational reason. For example, it should be possible to say something like: 1) disallow UDP on port 3456 in general 2) allow UDP on port 3456 if the source is X and the destination Y. -- Christian Huitema -----Original Message----- From: Sanjoy Sen [mailto:sanjoy@nortelnetworks.com] Sent: Friday, April 12, 2002 10:21 AM To: Tom-PT Taylor; 'Jiri Kuthan'; 'Martin Stiemerling' Cc: 'midcom@ietf.org'; Cedric Aoun Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content I support this as a good compromise. We should disallow contradictions in overlapping rulesets (and resolve on a FCFS basis). But, we should allow overlapping rulesets if there's no contradiction.  > -----Original Message----- > From: Taylor, Tom-PT [CAR:B800:EXCH] > Sent: Friday, April 12, 2002 7:52 AM > To: 'Jiri Kuthan'; 'Martin Stiemerling'; Sen, Sanjoy [NGC:B692:EXCH] > Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] > Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content > > > I agree with your distinction between the issues of rule > overlapping and access control.  I do wonder if you are being > too dogmatic on the matter of rule overlapping, and would beg > for exceptions in two cases: > >   -- the rules do not involve contradictory actions (e.g. > both rules allow flows) > >   -- the rules both come from the same Agent. > > Here is an example scenario in which I could see the > possibility of rule overlapping: a rule is set up allowing > any node inside to connect to a specific address outside.  > Then an Agent sets up a rule allowing connection from a > specific inside address to that outside address.  In the > process, the Agent receives an address binding to the mapped > address at the Middlebox.  Using the notation I have proposed > earlier, the first rule is: > > Filter= { Source address:      ANY, >           Source port:         ANY, >           Source realm:        , >           Map address:         ANY, >           Map port:            ANY, >           Map realm:           , >           Destination address: , >           Destination port:    , >           Destination realm:   , >           Protocol             }, > > Action = Allow > > The second, more specific rule is: > > Filter= { Source address:      , >           Source port:         , >           Source realm:        , >           Map address:         CHOOSE, >           Map port:            CHOOSE, >           Map realm:           , >           Destination address: , >           Destination port:    , >           Destination realm:   }, > > Action = Allow > > In response to this second rule the Middlebox reports the > bindings it has assigned for the CHOOSE entries. > > I can think of one or two arguments you may have against this > sort of situation, but I don't know which particular > arguments you would choose.  So I'll see what you have to say. > > As for allowing an Agent to amend or contradict itself, I see > this as a matter of convenience.  It makes it easier to > associate specific Policy Rules with specific application > sessions, regardless of how they interact.  If you disallow > it, the workaround is for the agent to combine everything > into a single Policy Rule.  This is OK provided that the > Agent knows that it itself is the source of the overlap. > > > -----Original Message----- > From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de] > Sent: Friday, April 12, 2002 5:30 AM > To: Taylor, Tom-PT [CAR:B800:EXCH]; 'Martin Stiemerling'; Sen, Sanjoy > [NGC:B692:EXCH] > Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] > Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content > > > I think people mix up two issues: rule overlapping and access control. > > I argumented against rule overlapping -- I want to disallow rules > with different packet matching expressions with packets matching > both of them. Doing anything else is a ticket for unneeded complexity > and I see reluctance to enter such business on mailing list. > > The other, security-policy issue is how access to rules > with identical packet matching expressions is governed. Which is > a different discussion. > > -Jiri > > At 06:43 PM 4/5/2002, Tom-PT Taylor wrote: > > >Assuming that contradictions are possible (see my previous message), > > Please NO. > > > we should distinguish two cases: > > - a specific Agent contradicts a Policy Rule installed > previously by that same Agent > > - a specific Agent contradicts a Policy Rule installed by > another Agent. > > > >An underlying premise of our proposed semantics is that each > Policy Rule (defined as a set of {Filter, Action} pairs with > a specific Policy Rule Identifier) has one or more owners.  > That is, the Middlebox remembers the Agent(s) who installed > those rules. > > > >Whether more than one Agent should be able to work with the > same Policy Rule is a matter for discussion, though I sense > an inclination not to allow this.  (But it seems to me that > an Administrator should be able to audit all installed Policy > Rules and deactivate any of them if need be.)  On the other > hand, I think it is accepted that different Policy Rules > could overlap in their scope.  So I'll concentrate my > discussion on the case where a new Policy Rule is in conflict > with a previously installed Policy Rule. > > > >I would suggest a general approach to conflicts of this form: > > > > - If an Agent contradicts itself, the Middlebox denies the > new Policy Rule Request.  It returns an appropriate reason > code and the Policy Rule Identifier of the rule which is in > conflict.  The Agent then has the information it needs to > choose between modifying the already-existing rule to > accommodate the new conditions or giving up on the new Policy Rule. > > > > - If an Agent contradicts another Agent, Agent priorities > come into play.  I'm happy enough to allow only two > priorities: Administrator and others, but I'm not sure we > need to specify this, only that there exists a hierarchy of > Agent priorities.  The general rule is then that the Policy > Rule installed by the higher priority agent prevails and the > other one is rejected or deactivated as the case may be.  > Between equal-priority Agents, existing Policy Rules take > priority over new ones. > > > >One open question is what diagnostic information should be > supplied when a Policy Rule is rejected or deactivated.  I > see the following possibilities: > > > >(1) The Middlebox computes and returns a modified Policy > Rule that would be consistent with the over-riding Policy Rule. > > > >(2) The Middlebox returns the complete contents of the > over-riding Policy Rule. > >(3) The Middlebox returns the (sub)set of {Filter, Action} > pairs within the over-riding Policy Rule which are in > conflict with the disallowed Policy Rule. > > > >(4) The Middlebox returns a set of filters which describe > the precise area of conflict with the over-riding Policy Rule. > > > >I have a bit of a concern with privacy which inclines me to > alternative (4). > > > >-----Original Message----- > >From: Martin Stiemerling > [mailto:Martin.Stiemer ling@ccrle.nec.de] >Sent: Friday, April 05, 2002 9:57 AM >To: Sen, Sanjoy [NGC:B692:EXCH] >Cc: 'Jiri Kuthan'; Taylor, Tom-PT [CAR:B800:EXCH]; midcom@ietf.org; >Aoun, Cedric [QPD:MA01:EXCH] >Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content > >Sanjoy Sen wrote: > >> How will then the following requirement from Midcom requirements draft >> be satisfied? >> ***** >> 2.2.11. >> >>      It should be possible to define rulesets that contain a more spe- >>      cific filter spec than an overlapping ruleset.  This should allow >>      agents to request actions for the subset that contradict those of >>      the overlapping set. >> ***** > > > > >> Whether you want it or not, there would be overlapping rulesets because >> the filterspec may overlap for different rulesets installed by >> independent agents. The question - who wins when there're contradictory > >> actions is moot because the requirement above seems to suggest that we >> need to allow contradictory behavior. > >The questions is, who will decide how to behave in such a case? There >are so many combinations of firewall/NAT configurations which will make >it difficult to define a stable behaviour, i.e. how to react with this >overlapping set. Furthermore, the requirement starts with "should"... > >Martin >-- >Martin Stiemerling > >NEC Europe Ltd. -- Network Laboratories  Stiemerling@ccrle.nec.de >IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Apr 12 15:09:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00885 for ; Fri, 12 Apr 2002 15:09:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA06065 for midcom-archive@odin.ietf.org; Fri, 12 Apr 2002 15:09:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04908; Fri, 12 Apr 2002 14:52:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04628 for ; Fri, 12 Apr 2002 14:49:12 -0400 (EDT) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00230 for ; Fri, 12 Apr 2002 14:49:08 -0400 (EDT) Received: by shell.nominum.com (Postfix, from userid 11089) id 5FBE83190E; Fri, 12 Apr 2002 11:48:40 -0700 (PDT) Date: Fri, 12 Apr 2002 11:48:40 -0700 From: Ted Hardie To: Sanjoy Sen Cc: Tom-PT Taylor , "'Jiri Kuthan'" , "'Martin Stiemerling'" , "'midcom@ietf.org'" , Cedric Aoun Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content Message-ID: <20020412114840.B90127@shell.nominum.com> Reply-To: Ted.Hardie@nominum.com References: <933FADF5E673D411B8A30002A5608A0E01187A76@zrc2c012.us.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <933FADF5E673D411B8A30002A5608A0E01187A76@zrc2c012.us.nortel.com>; from sanjoy@nortelnetworks.com on Fri, Apr 12, 2002 at 12:20:38PM -0500 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Sanjoy, Possibly my memory is faulty here, but I thought we had previously agreed that an override was a possibility for a standard rule. If memory serves, that discussion did not really touch on overlapping rules, but the case where a rule introduced by an agent over-rode a previously installed rule (whether installed by that agent or a different agent). The logic in that discussion seemed to be that a test-for-rule, delete-rule, over-ride rule mechanism would be too heavyweight. If we go for FCFS basis for overlapping rulesets, the mechanism for non-overlapping rule and overlapping rules seems to be a bit at odds. I have not found that discussion in the archives after a quick scan, so it is possible I am mis-remembering the conculsion. If that was the conclusion, I think we have a slightly more complex problem, as there is no way for an agent to know in advance that the rule is overlapping. regards, Ted Hardie On Fri, Apr 12, 2002 at 12:20:38PM -0500, Sanjoy Sen wrote: > I support this as a good compromise. We should disallow contradictions in > overlapping rulesets (and resolve on a FCFS basis). But, we should allow > overlapping rulesets if there's no contradiction. > > > -----Original Message----- > > From: Taylor, Tom-PT [CAR:B800:EXCH] > > Sent: Friday, April 12, 2002 7:52 AM > > To: 'Jiri Kuthan'; 'Martin Stiemerling'; Sen, Sanjoy [NGC:B692:EXCH] > > Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] > > Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content > > > > > > I agree with your distinction between the issues of rule > > overlapping and access control. I do wonder if you are being > > too dogmatic on the matter of rule overlapping, and would beg > > for exceptions in two cases: > > > > -- the rules do not involve contradictory actions (e.g. > > both rules allow flows) > > > > -- the rules both come from the same Agent. > > > > Here is an example scenario in which I could see the > > possibility of rule overlapping: a rule is set up allowing > > any node inside to connect to a specific address outside. > > Then an Agent sets up a rule allowing connection from a > > specific inside address to that outside address. In the > > process, the Agent receives an address binding to the mapped > > address at the Middlebox. Using the notation I have proposed > > earlier, the first rule is: > > > > Filter= { Source address: ANY, > > Source port: ANY, > > Source realm: , > > Map address: ANY, > > Map port: ANY, > > Map realm: , > > Destination address: , > > Destination port: , > > Destination realm: , > > Protocol }, > > > > Action = Allow > > > > The second, more specific rule is: > > > > Filter= { Source address: , > > Source port: , > > Source realm: , > > Map address: CHOOSE, > > Map port: CHOOSE, > > Map realm: , > > Destination address: , > > Destination port: , > > Destination realm: }, > > > > Action = Allow > > > > In response to this second rule the Middlebox reports the > > bindings it has assigned for the CHOOSE entries. > > > > I can think of one or two arguments you may have against this > > sort of situation, but I don't know which particular > > arguments you would choose. So I'll see what you have to say. > > > > As for allowing an Agent to amend or contradict itself, I see > > this as a matter of convenience. It makes it easier to > > associate specific Policy Rules with specific application > > sessions, regardless of how they interact. If you disallow > > it, the workaround is for the agent to combine everything > > into a single Policy Rule. This is OK provided that the > > Agent knows that it itself is the source of the overlap. > > > > > > -----Original Message----- > > From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de] > > Sent: Friday, April 12, 2002 5:30 AM > > To: Taylor, Tom-PT [CAR:B800:EXCH]; 'Martin Stiemerling'; Sen, Sanjoy > > [NGC:B692:EXCH] > > Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] > > Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content > > > > > > I think people mix up two issues: rule overlapping and access control. > > > > I argumented against rule overlapping -- I want to disallow rules > > with different packet matching expressions with packets matching > > both of them. Doing anything else is a ticket for unneeded complexity > > and I see reluctance to enter such business on mailing list. > > > > The other, security-policy issue is how access to rules > > with identical packet matching expressions is governed. Which is > > a different discussion. > > > > -Jiri > > > > At 06:43 PM 4/5/2002, Tom-PT Taylor wrote: > > > > >Assuming that contradictions are possible (see my previous message), > > > > Please NO. > > > > > we should distinguish two cases: > > > - a specific Agent contradicts a Policy Rule installed > > previously by that same Agent > > > - a specific Agent contradicts a Policy Rule installed by > > another Agent. > > > > > >An underlying premise of our proposed semantics is that each > > Policy Rule (defined as a set of {Filter, Action} pairs with > > a specific Policy Rule Identifier) has one or more owners. > > That is, the Middlebox remembers the Agent(s) who installed > > those rules. > > > > > >Whether more than one Agent should be able to work with the > > same Policy Rule is a matter for discussion, though I sense > > an inclination not to allow this. (But it seems to me that > > an Administrator should be able to audit all installed Policy > > Rules and deactivate any of them if need be.) On the other > > hand, I think it is accepted that different Policy Rules > > could overlap in their scope. So I'll concentrate my > > discussion on the case where a new Policy Rule is in conflict > > with a previously installed Policy Rule. > > > > > >I would suggest a general approach to conflicts of this form: > > > > > > - If an Agent contradicts itself, the Middlebox denies the > > new Policy Rule Request. It returns an appropriate reason > > code and the Policy Rule Identifier of the rule which is in > > conflict. The Agent then has the information it needs to > > choose between modifying the already-existing rule to > > accommodate the new conditions or giving up on the new Policy Rule. > > > > > > - If an Agent contradicts another Agent, Agent priorities > > come into play. I'm happy enough to allow only two > > priorities: Administrator and others, but I'm not sure we > > need to specify this, only that there exists a hierarchy of > > Agent priorities. The general rule is then that the Policy > > Rule installed by the higher priority agent prevails and the > > other one is rejected or deactivated as the case may be. > > Between equal-priority Agents, existing Policy Rules take > > priority over new ones. > > > > > >One open question is what diagnostic information should be > > supplied when a Policy Rule is rejected or deactivated. I > > see the following possibilities: > > > > > >(1) The Middlebox computes and returns a modified Policy > > Rule that would be consistent with the over-riding Policy Rule. > > > > > >(2) The Middlebox returns the complete contents of the > > over-riding Policy Rule. > > >(3) The Middlebox returns the (sub)set of {Filter, Action} > > pairs within the over-riding Policy Rule which are in > > conflict with the disallowed Policy Rule. > > > > > >(4) The Middlebox returns a set of filters which describe > > the precise area of conflict with the over-riding Policy Rule. > > > > > >I have a bit of a concern with privacy which inclines me to > > alternative (4). > > > > > >-----Original Message----- > > >From: Martin Stiemerling > > [mailto:Martin.Stiemer > ling@ccrle.nec.de] > >Sent: Friday, April 05, 2002 9:57 AM > >To: Sen, Sanjoy [NGC:B692:EXCH] > >Cc: 'Jiri Kuthan'; Taylor, Tom-PT [CAR:B800:EXCH]; midcom@ietf.org; > >Aoun, Cedric [QPD:MA01:EXCH] > >Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content > > > >Sanjoy Sen wrote: > > > >> How will then the following requirement from Midcom requirements draft > >> be satisfied? > >> ***** > >> 2.2.11. > >> > >> It should be possible to define rulesets that contain a more spe- > >> cific filter spec than an overlapping ruleset. This should allow > >> agents to request actions for the subset that contradict those of > >> the overlapping set. > >> ***** > > > > > > > > >> Whether you want it or not, there would be overlapping rulesets because > >> the filterspec may overlap for different rulesets installed by > >> independent agents. The question - who wins when there're contradictory > > > >> actions is moot because the requirement above seems to suggest that we > >> need to allow contradictory behavior. > > > >The questions is, who will decide how to behave in such a case? There > >are so many combinations of firewall/NAT configurations which will make > >it difficult to define a stable behaviour, i.e. how to react with this > >overlapping set. Furthermore, the requirement starts with "should"... > > > >Martin > >-- > >Martin Stiemerling > > > >NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de > >IPv4: http://www.ccrle.nec.de IPv6: > http://www.ipv6.ccrle.nec.de > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Apr 12 15:17:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01141 for ; Fri, 12 Apr 2002 15:17:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA06561 for midcom-archive@odin.ietf.org; Fri, 12 Apr 2002 15:17:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04924; Fri, 12 Apr 2002 14:52:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03247 for ; Fri, 12 Apr 2002 14:27:50 -0400 (EDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29749 for ; Fri, 12 Apr 2002 14:27:47 -0400 (EDT) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 12 Apr 2002 11:27:01 -0700 Received: from 157.54.6.150 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 12 Apr 2002 11:27:15 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 12 Apr 2002 11:27:15 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 12 Apr 2002 11:27:05 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Fri, 12 Apr 2002 11:23:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Fri, 12 Apr 2002 11:23:39 -0700 Message-ID: Thread-Topic: [midcom] MIDCOM SEmantics: Policy Rule Content Thread-Index: AcHiSX6/dm8ywAB6QcimuqGRN1m18gABeLgQ From: "Christian Huitema" To: "Sanjoy Sen" , "Tom-PT Taylor" , "Jiri Kuthan" , "Martin Stiemerling" Cc: , "Cedric Aoun" X-OriginalArrivalTime: 12 Apr 2002 18:23:39.0626 (UTC) FILETIME=[2B164CA0:01C1E24F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA03250 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit I am sorry, but the requirement was there for a very strong operational reason. For example, it should be possible to say something like: 1) disallow UDP on port 3456 in general 2) allow UDP on port 3456 if the source is X and the destination Y. -- Christian Huitema -----Original Message----- From: Sanjoy Sen [mailto:sanjoy@nortelnetworks.com] Sent: Friday, April 12, 2002 10:21 AM To: Tom-PT Taylor; 'Jiri Kuthan'; 'Martin Stiemerling' Cc: 'midcom@ietf.org'; Cedric Aoun Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content I support this as a good compromise. We should disallow contradictions in overlapping rulesets (and resolve on a FCFS basis). But, we should allow overlapping rulesets if there's no contradiction.  > -----Original Message----- > From: Taylor, Tom-PT [CAR:B800:EXCH] > Sent: Friday, April 12, 2002 7:52 AM > To: 'Jiri Kuthan'; 'Martin Stiemerling'; Sen, Sanjoy [NGC:B692:EXCH] > Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] > Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content > > > I agree with your distinction between the issues of rule > overlapping and access control.  I do wonder if you are being > too dogmatic on the matter of rule overlapping, and would beg > for exceptions in two cases: > >   -- the rules do not involve contradictory actions (e.g. > both rules allow flows) > >   -- the rules both come from the same Agent. > > Here is an example scenario in which I could see the > possibility of rule overlapping: a rule is set up allowing > any node inside to connect to a specific address outside.  > Then an Agent sets up a rule allowing connection from a > specific inside address to that outside address.  In the > process, the Agent receives an address binding to the mapped > address at the Middlebox.  Using the notation I have proposed > earlier, the first rule is: > > Filter= { Source address:      ANY, >           Source port:         ANY, >           Source realm:        , >           Map address:         ANY, >           Map port:            ANY, >           Map realm:           , >           Destination address: , >           Destination port:    , >           Destination realm:   , >           Protocol             }, > > Action = Allow > > The second, more specific rule is: > > Filter= { Source address:      , >           Source port:         , >           Source realm:        , >           Map address:         CHOOSE, >           Map port:            CHOOSE, >           Map realm:           , >           Destination address: , >           Destination port:    , >           Destination realm:   }, > > Action = Allow > > In response to this second rule the Middlebox reports the > bindings it has assigned for the CHOOSE entries. > > I can think of one or two arguments you may have against this > sort of situation, but I don't know which particular > arguments you would choose.  So I'll see what you have to say. > > As for allowing an Agent to amend or contradict itself, I see > this as a matter of convenience.  It makes it easier to > associate specific Policy Rules with specific application > sessions, regardless of how they interact.  If you disallow > it, the workaround is for the agent to combine everything > into a single Policy Rule.  This is OK provided that the > Agent knows that it itself is the source of the overlap. > > > -----Original Message----- > From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de] > Sent: Friday, April 12, 2002 5:30 AM > To: Taylor, Tom-PT [CAR:B800:EXCH]; 'Martin Stiemerling'; Sen, Sanjoy > [NGC:B692:EXCH] > Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] > Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content > > > I think people mix up two issues: rule overlapping and access control. > > I argumented against rule overlapping -- I want to disallow rules > with different packet matching expressions with packets matching > both of them. Doing anything else is a ticket for unneeded complexity > and I see reluctance to enter such business on mailing list. > > The other, security-policy issue is how access to rules > with identical packet matching expressions is governed. Which is > a different discussion. > > -Jiri > > At 06:43 PM 4/5/2002, Tom-PT Taylor wrote: > > >Assuming that contradictions are possible (see my previous message), > > Please NO. > > > we should distinguish two cases: > > - a specific Agent contradicts a Policy Rule installed > previously by that same Agent > > - a specific Agent contradicts a Policy Rule installed by > another Agent. > > > >An underlying premise of our proposed semantics is that each > Policy Rule (defined as a set of {Filter, Action} pairs with > a specific Policy Rule Identifier) has one or more owners.  > That is, the Middlebox remembers the Agent(s) who installed > those rules. > > > >Whether more than one Agent should be able to work with the > same Policy Rule is a matter for discussion, though I sense > an inclination not to allow this.  (But it seems to me that > an Administrator should be able to audit all installed Policy > Rules and deactivate any of them if need be.)  On the other > hand, I think it is accepted that different Policy Rules > could overlap in their scope.  So I'll concentrate my > discussion on the case where a new Policy Rule is in conflict > with a previously installed Policy Rule. > > > >I would suggest a general approach to conflicts of this form: > > > > - If an Agent contradicts itself, the Middlebox denies the > new Policy Rule Request.  It returns an appropriate reason > code and the Policy Rule Identifier of the rule which is in > conflict.  The Agent then has the information it needs to > choose between modifying the already-existing rule to > accommodate the new conditions or giving up on the new Policy Rule. > > > > - If an Agent contradicts another Agent, Agent priorities > come into play.  I'm happy enough to allow only two > priorities: Administrator and others, but I'm not sure we > need to specify this, only that there exists a hierarchy of > Agent priorities.  The general rule is then that the Policy > Rule installed by the higher priority agent prevails and the > other one is rejected or deactivated as the case may be.  > Between equal-priority Agents, existing Policy Rules take > priority over new ones. > > > >One open question is what diagnostic information should be > supplied when a Policy Rule is rejected or deactivated.  I > see the following possibilities: > > > >(1) The Middlebox computes and returns a modified Policy > Rule that would be consistent with the over-riding Policy Rule. > > > >(2) The Middlebox returns the complete contents of the > over-riding Policy Rule. > >(3) The Middlebox returns the (sub)set of {Filter, Action} > pairs within the over-riding Policy Rule which are in > conflict with the disallowed Policy Rule. > > > >(4) The Middlebox returns a set of filters which describe > the precise area of conflict with the over-riding Policy Rule. > > > >I have a bit of a concern with privacy which inclines me to > alternative (4). > > > >-----Original Message----- > >From: Martin Stiemerling > [mailto:Martin.Stiemer ling@ccrle.nec.de] >Sent: Friday, April 05, 2002 9:57 AM >To: Sen, Sanjoy [NGC:B692:EXCH] >Cc: 'Jiri Kuthan'; Taylor, Tom-PT [CAR:B800:EXCH]; midcom@ietf.org; >Aoun, Cedric [QPD:MA01:EXCH] >Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content > >Sanjoy Sen wrote: > >> How will then the following requirement from Midcom requirements draft >> be satisfied? >> ***** >> 2.2.11. >> >>      It should be possible to define rulesets that contain a more spe- >>      cific filter spec than an overlapping ruleset.  This should allow >>      agents to request actions for the subset that contradict those of >>      the overlapping set. >> ***** > > > > >> Whether you want it or not, there would be overlapping rulesets because >> the filterspec may overlap for different rulesets installed by >> independent agents. The question - who wins when there're contradictory > >> actions is moot because the requirement above seems to suggest that we >> need to allow contradictory behavior. > >The questions is, who will decide how to behave in such a case? There >are so many combinations of firewall/NAT configurations which will make >it difficult to define a stable behaviour, i.e. how to react with this >overlapping set. Furthermore, the requirement starts with "should"... > >Martin >-- >Martin Stiemerling > >NEC Europe Ltd. -- Network Laboratories  Stiemerling@ccrle.nec.de >IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Apr 12 15:17:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01157 for ; Fri, 12 Apr 2002 15:17:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA06596 for midcom-archive@odin.ietf.org; Fri, 12 Apr 2002 15:17:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06018; Fri, 12 Apr 2002 15:08:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05987 for ; Fri, 12 Apr 2002 15:08:39 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00835 for ; Fri, 12 Apr 2002 15:08:36 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3CJ86D15328 for ; Fri, 12 Apr 2002 15:08:06 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <2WJANRY4>; Fri, 12 Apr 2002 15:08:07 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A2EF@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Christian Huitema'" , "Sanjoy Sen", Jiri Kuthan , Martin Stiemerling Cc: midcom@ietf.org, "Cedric Aoun" Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Fri, 12 Apr 2002 15:08:06 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Then perhaps we do have to debate decision rules, and can't just live with first-come, first-served. However, let me make one last try: could the broader rule be provisioned, and the narrower one installed by the Midcom protocol? -----Original Message----- From: Christian Huitema [mailto:huitema@windows.microsoft.com] Sent: Friday, April 12, 2002 3:01 PM To: Taylor, Tom-PT [CAR:B800:EXCH]; Sen, Sanjoy [NGC:B692:EXCH]; Jiri Kuthan; Martin Stiemerling Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Not necessarily. From an operational point of view, it is important to not tie a rule to an agent -- we debated that at length last year. -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Friday, April 12, 2002 11:51 AM To: Christian Huitema; Sanjoy Sen; Jiri Kuthan; Martin Stiemerling Cc: midcom@ietf.org; Cedric Aoun Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Would the same Agent install both rules? -----Original Message----- From: Christian Huitema [mailto:huitema@windows.microsoft.com] Sent: Friday, April 12, 2002 2:24 PM To: Sen, Sanjoy [NGC:B692:EXCH]; Taylor, Tom-PT [CAR:B800:EXCH]; Jiri Kuthan; Martin Stiemerling Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content I am sorry, but the requirement was there for a very strong operational reason. For example, it should be possible to say something like: 1) disallow UDP on port 3456 in general 2) allow UDP on port 3456 if the source is X and the destination Y. -- Christian Huitema -----Original Message----- From: Sanjoy Sen [mailto:sanjoy@nortelnetworks.com] Sent: Friday, April 12, 2002 10:21 AM To: Tom-PT Taylor; 'Jiri Kuthan'; 'Martin Stiemerling' Cc: 'midcom@ietf.org'; Cedric Aoun Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content I support this as a good compromise. We should disallow contradictions in overlapping rulesets (and resolve on a FCFS basis). But, we should allow overlapping rulesets if there's no contradiction.  > -----Original Message----- > From: Taylor, Tom-PT [CAR:B800:EXCH] > Sent: Friday, April 12, 2002 7:52 AM > To: 'Jiri Kuthan'; 'Martin Stiemerling'; Sen, Sanjoy [NGC:B692:EXCH] > Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] > Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content > > > I agree with your distinction between the issues of rule > overlapping and access control.  I do wonder if you are being > too dogmatic on the matter of rule overlapping, and would beg > for exceptions in two cases: > >   -- the rules do not involve contradictory actions (e.g. > both rules allow flows) > >   -- the rules both come from the same Agent. > > Here is an example scenario in which I could see the > possibility of rule overlapping: a rule is set up allowing > any node inside to connect to a specific address outside.  > Then an Agent sets up a rule allowing connection from a > specific inside address to that outside address.  In the > process, the Agent receives an address binding to the mapped > address at the Middlebox.  Using the notation I have proposed > earlier, the first rule is: > > Filter= { Source address:      ANY, >           Source port:         ANY, >           Source realm:        , >           Map address:         ANY, >           Map port:            ANY, >           Map realm:           , >           Destination address: , >           Destination port:    , >           Destination realm:   , >           Protocol             }, > > Action = Allow > > The second, more specific rule is: > > Filter= { Source address:      , >           Source port:         , >           Source realm:        , >           Map address:         CHOOSE, >           Map port:            CHOOSE, >           Map realm:           , >           Destination address: , >           Destination port:    , >           Destination realm:   }, > > Action = Allow > > In response to this second rule the Middlebox reports the > bindings it has assigned for the CHOOSE entries. > > I can think of one or two arguments you may have against this > sort of situation, but I don't know which particular > arguments you would choose.  So I'll see what you have to say. > > As for allowing an Agent to amend or contradict itself, I see > this as a matter of convenience.  It makes it easier to > associate specific Policy Rules with specific application > sessions, regardless of how they interact.  If you disallow > it, the workaround is for the agent to combine everything > into a single Policy Rule.  This is OK provided that the > Agent knows that it itself is the source of the overlap. > > > -----Original Message----- > From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de] > Sent: Friday, April 12, 2002 5:30 AM > To: Taylor, Tom-PT [CAR:B800:EXCH]; 'Martin Stiemerling'; Sen, Sanjoy > [NGC:B692:EXCH] > Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] > Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content > > > I think people mix up two issues: rule overlapping and access control. > > I argumented against rule overlapping -- I want to disallow rules > with different packet matching expressions with packets matching > both of them. Doing anything else is a ticket for unneeded complexity > and I see reluctance to enter such business on mailing list. > > The other, security-policy issue is how access to rules > with identical packet matching expressions is governed. Which is > a different discussion. > > -Jiri > > At 06:43 PM 4/5/2002, Tom-PT Taylor wrote: > > >Assuming that contradictions are possible (see my previous message), > > Please NO. > > > we should distinguish two cases: > > - a specific Agent contradicts a Policy Rule installed > previously by that same Agent > > - a specific Agent contradicts a Policy Rule installed by > another Agent. > > > >An underlying premise of our proposed semantics is that each > Policy Rule (defined as a set of {Filter, Action} pairs with > a specific Policy Rule Identifier) has one or more owners.  > That is, the Middlebox remembers the Agent(s) who installed > those rules. > > > >Whether more than one Agent should be able to work with the > same Policy Rule is a matter for discussion, though I sense > an inclination not to allow this.  (But it seems to me that > an Administrator should be able to audit all installed Policy > Rules and deactivate any of them if need be.)  On the other > hand, I think it is accepted that different Policy Rules > could overlap in their scope.  So I'll concentrate my > discussion on the case where a new Policy Rule is in conflict > with a previously installed Policy Rule. > > > >I would suggest a general approach to conflicts of this form: > > > > - If an Agent contradicts itself, the Middlebox denies the > new Policy Rule Request.  It returns an appropriate reason > code and the Policy Rule Identifier of the rule which is in > conflict.  The Agent then has the information it needs to > choose between modifying the already-existing rule to > accommodate the new conditions or giving up on the new Policy Rule. > > > > - If an Agent contradicts another Agent, Agent priorities > come into play.  I'm happy enough to allow only two > priorities: Administrator and others, but I'm not sure we > need to specify this, only that there exists a hierarchy of > Agent priorities.  The general rule is then that the Policy > Rule installed by the higher priority agent prevails and the > other one is rejected or deactivated as the case may be.  > Between equal-priority Agents, existing Policy Rules take > priority over new ones. > > > >One open question is what diagnostic information should be > supplied when a Policy Rule is rejected or deactivated.  I > see the following possibilities: > > > >(1) The Middlebox computes and returns a modified Policy > Rule that would be consistent with the over-riding Policy Rule. > > > >(2) The Middlebox returns the complete contents of the > over-riding Policy Rule. > >(3) The Middlebox returns the (sub)set of {Filter, Action} > pairs within the over-riding Policy Rule which are in > conflict with the disallowed Policy Rule. > > > >(4) The Middlebox returns a set of filters which describe > the precise area of conflict with the over-riding Policy Rule. > > > >I have a bit of a concern with privacy which inclines me to > alternative (4). > > > >-----Original Message----- > >From: Martin Stiemerling > [mailto:Martin.Stiemer ling@ccrle.nec.de] >Sent: Friday, April 05, 2002 9:57 AM >To: Sen, Sanjoy [NGC:B692:EXCH] >Cc: 'Jiri Kuthan'; Taylor, Tom-PT [CAR:B800:EXCH]; midcom@ietf.org; >Aoun, Cedric [QPD:MA01:EXCH] >Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content > >Sanjoy Sen wrote: > >> How will then the following requirement from Midcom requirements draft >> be satisfied? >> ***** >> 2.2.11. >> >>      It should be possible to define rulesets that contain a more spe- >>      cific filter spec than an overlapping ruleset.  This should allow >>      agents to request actions for the subset that contradict those of >>      the overlapping set. >> ***** > > > > >> Whether you want it or not, there would be overlapping rulesets because >> the filterspec may overlap for different rulesets installed by >> independent agents. The question - who wins when there're contradictory > >> actions is moot because the requirement above seems to suggest that we >> need to allow contradictory behavior. > >The questions is, who will decide how to behave in such a case? There >are so many combinations of firewall/NAT configurations which will make >it difficult to define a stable behaviour, i.e. how to react with this >overlapping set. Furthermore, the requirement starts with "should"... > >Martin >-- >Martin Stiemerling > >NEC Europe Ltd. -- Network Laboratories  Stiemerling@ccrle.nec.de >IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Apr 12 15:25:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01411 for ; Fri, 12 Apr 2002 15:25:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA07183 for midcom-archive@odin.ietf.org; Fri, 12 Apr 2002 15:25:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06754; Fri, 12 Apr 2002 15:19:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06727 for ; Fri, 12 Apr 2002 15:19:15 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01239 for ; Fri, 12 Apr 2002 15:19:12 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id A331C992014A; Fri, 12 Apr 2002 15:19:13 -0400 Message-ID: <006901c1e256$7f4e7e80$2300000a@acmepacket.com> From: "Bob Penfield" To: "Tom-PT Taylor" , References: <4D79C746863DD51197690002A52CDA0001E8A2EC@zcard0kc.ca.nortel.com> Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Fri, 12 Apr 2002 15:16:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Hi Tom, I think we have different interpretations of "filter" and "action". I see the "action" as the set of operations the middlebox performs for the packets matching the filter, rather than the "action" the protocol does for the policy rule. When a policy rule is created, both the filter and action parts of the rule might be selected using the CHOOSE wildcard. For example, say I want to enable an inbound UDP flow from "the-other-end" to "my-endpoint" in a NAT box. I would specify: Filter: Source: Destination: CHOOSE Protocol: UDP Action: Allow Change-Destination-To: The corresponding outbound rule might look like this: Filter: Source: Destination: Protocol: UDP Action: Allow Change-Source-To: CHOOSE There may be scenarios where I want to change both the source and destination addresses (twice-NAT), thus I would need to specify both in the action. For example, I might have specified the outbound rule as: Filter: Source: Destination: CHOOSE Protocol: UDP Action: Allow Change-Source-To: CHOOSE Change-Destination-To: I might need to do this to guarantee that the outbound packets traverse this particular middlebox it there are multiple ways out of the network. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Tom-PT Taylor" To: "'Bob Penfield'" ; Sent: Friday, April 12, 2002 1:34 PM Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content > I partly agree with you. When the Agent is asking for a mapping to be > granted, the Map Address-Port is a return value, not really part of the > filter. Since we are talking semantics rather than protocol notation, the > distinction should be made clear. > > On the other hand, when a mapping has been granted previously and the Agent > is now enabling a specific flow, the Map-Address-Port is legitimately part > of the flow specification. > > To show what I mean, suppose we are talking about a rule allowing inbound > flows to a service. To set this up, the Agent issues a request like this: > > Source Address: Any > Source Port: Any > Destination Address: > Destination Port: > Protocol: TCP > Action: new destination address-port > > The response provides a specific Map-Address-Port as requested. > > Now consider a rule allowing inbound flows through that mapped address-port, > from a specific external address. (To avoid extraneous issues, assume it is > replacing the previous rule.) The rule should have the form: > > Source Address: > Source Port: > Destination Address: > Destination Port: > Protocol: TCP > Action: allow > > One other point: do your actions "new source address" and "new destination > address" mean what I think they mean: > - new source address: please assign an address which will appear as the > external source of flows originated from inside > - new destination address: please assign an address which will appear as > the external destination of flows being forwarded to the inside? > > > -----Original Message----- > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > Sent: Friday, April 12, 2002 10:12 AM > To: Taylor, Tom-PT [CAR:B800:EXCH]; midcom@ietf.org > Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content > > > ----- Original Message ----- > From: "Tom-PT Taylor" > > > Let us turn now to the detailed semantic content of the {Filter, Action} > > pairs. As the examples of section 4 illustrate, it is possible to > represent > > NAT and firewall policies using sets of uni-directional filters of the > form > > > > {, , , > > Protocol} > > I would think that the filter would contain only the data used to match > packets. The Map Address-Port would part of the action. Also, I don't think > a single Map Address-Port is sufficient. > > I see the parameters in the Filter as follows: > > Source Address-Port > Destination Address-Port > Transport Protocol (UDP, TCP, etc) > > The actions would include: > > New Source Address-Port > New Destination Address-Port > Allow/Disallow > > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Apr 12 15:27:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01491 for ; Fri, 12 Apr 2002 15:27:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA07298 for midcom-archive@odin.ietf.org; Fri, 12 Apr 2002 15:27:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06965; Fri, 12 Apr 2002 15:22:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06780 for ; Fri, 12 Apr 2002 15:20:17 -0400 (EDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01254 for ; Fri, 12 Apr 2002 15:20:14 -0400 (EDT) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.154]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 12 Apr 2002 12:19:45 -0700 Received: from 157.54.8.155 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 12 Apr 2002 12:19:45 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 12 Apr 2002 12:19:33 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 12 Apr 2002 12:19:44 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Fri, 12 Apr 2002 12:16:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Fri, 12 Apr 2002 12:16:13 -0700 Message-ID: Thread-Topic: [midcom] MIDCOM SEmantics: Policy Rule Content Thread-Index: AcHiVO9mSx6Jv4gsRfS5k3GJ8tE4BQAAbY8w From: "Christian Huitema" To: "Tom-PT Taylor" , "Sanjoy Sen" , "Jiri Kuthan" , "Martin Stiemerling" Cc: , "Cedric Aoun" X-OriginalArrivalTime: 12 Apr 2002 19:16:14.0307 (UTC) FILETIME=[836C6B30:01C1E256] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA06784 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit The broader rule will often be a provisioned rule, but that is not necessary true. The narrower rule will most likely be dynamic, but that is also not necessarily true -- we could for example have a provisioned rule that excludes a specific address from interacting with the outside. -- Christian Huitema -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Friday, April 12, 2002 12:08 PM To: Christian Huitema; Sanjoy Sen; Jiri Kuthan; Martin Stiemerling Cc: midcom@ietf.org; Cedric Aoun Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Then perhaps we do have to debate decision rules, and can't just live with first-come, first-served.  However, let me make one last try: could the broader rule be provisioned, and the narrower one installed by the Midcom protocol? -----Original Message----- From: Christian Huitema [mailto:huitema@windows.microsoft.com] Sent: Friday, April 12, 2002 3:01 PM To: Taylor, Tom-PT [CAR:B800:EXCH]; Sen, Sanjoy [NGC:B692:EXCH]; Jiri Kuthan; Martin Stiemerling Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Not necessarily. From an operational point of view, it is important to not tie a rule to an agent -- we debated that at length last year. -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Friday, April 12, 2002 11:51 AM To: Christian Huitema; Sanjoy Sen; Jiri Kuthan; Martin Stiemerling Cc: midcom@ietf.org; Cedric Aoun Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Would the same Agent install both rules? -----Original Message----- From: Christian Huitema [mailto:huitema@windows.microsoft.com] Sent: Friday, April 12, 2002 2:24 PM To: Sen, Sanjoy [NGC:B692:EXCH]; Taylor, Tom-PT [CAR:B800:EXCH]; Jiri Kuthan; Martin Stiemerling Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content I am sorry, but the requirement was there for a very strong operational reason. For example, it should be possible to say something like: 1) disallow UDP on port 3456 in general 2) allow UDP on port 3456 if the source is X and the destination Y. -- Christian Huitema -----Original Message----- From: Sanjoy Sen [mailto:sanjoy@nortelnetworks.com] Sent: Friday, April 12, 2002 10:21 AM To: Tom-PT Taylor; 'Jiri Kuthan'; 'Martin Stiemerling' Cc: 'midcom@ietf.org'; Cedric Aoun Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content I support this as a good compromise. We should disallow contradictions in overlapping rulesets (and resolve on a FCFS basis). But, we should allow overlapping rulesets if there's no contradiction.  > -----Original Message----- > From: Taylor, Tom-PT [CAR:B800:EXCH] > Sent: Friday, April 12, 2002 7:52 AM > To: 'Jiri Kuthan'; 'Martin Stiemerling'; Sen, Sanjoy [NGC:B692:EXCH] > Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] > Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content > > > I agree with your distinction between the issues of rule > overlapping and access control.  I do wonder if you are being > too dogmatic on the matter of rule overlapping, and would beg > for exceptions in two cases: > >   -- the rules do not involve contradictory actions (e.g. > both rules allow flows) > >   -- the rules both come from the same Agent. > > Here is an example scenario in which I could see the > possibility of rule overlapping: a rule is set up allowing > any node inside to connect to a specific address outside.  > Then an Agent sets up a rule allowing connection from a > specific inside address to that outside address.  In the > process, the Agent receives an address binding to the mapped > address at the Middlebox.  Using the notation I have proposed > earlier, the first rule is: > > Filter= { Source address:      ANY, >           Source port:         ANY, >           Source realm:        , >           Map address:         ANY, >           Map port:            ANY, >           Map realm:           , >           Destination address: , >           Destination port:    , >           Destination realm:   , >           Protocol             }, > > Action = Allow > > The second, more specific rule is: > > Filter= { Source address:      , >           Source port:         , >           Source realm:        , >           Map address:         CHOOSE, >           Map port:            CHOOSE, >           Map realm:           , >           Destination address: , >           Destination port:    , >           Destination realm:   }, > > Action = Allow > > In response to this second rule the Middlebox reports the > bindings it has assigned for the CHOOSE entries. > > I can think of one or two arguments you may have against this > sort of situation, but I don't know which particular > arguments you would choose.  So I'll see what you have to say. > > As for allowing an Agent to amend or contradict itself, I see > this as a matter of convenience.  It makes it easier to > associate specific Policy Rules with specific application > sessions, regardless of how they interact.  If you disallow > it, the workaround is for the agent to combine everything > into a single Policy Rule.  This is OK provided that the > Agent knows that it itself is the source of the overlap. > > > -----Original Message----- > From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de] > Sent: Friday, April 12, 2002 5:30 AM > To: Taylor, Tom-PT [CAR:B800:EXCH]; 'Martin Stiemerling'; Sen, Sanjoy > [NGC:B692:EXCH] > Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] > Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content > > > I think people mix up two issues: rule overlapping and access control. > > I argumented against rule overlapping -- I want to disallow rules > with different packet matching expressions with packets matching > both of them. Doing anything else is a ticket for unneeded complexity > and I see reluctance to enter such business on mailing list. > > The other, security-policy issue is how access to rules > with identical packet matching expressions is governed. Which is > a different discussion. > > -Jiri > > At 06:43 PM 4/5/2002, Tom-PT Taylor wrote: > > >Assuming that contradictions are possible (see my previous message), > > Please NO. > > > we should distinguish two cases: > > - a specific Agent contradicts a Policy Rule installed > previously by that same Agent > > - a specific Agent contradicts a Policy Rule installed by > another Agent. > > > >An underlying premise of our proposed semantics is that each > Policy Rule (defined as a set of {Filter, Action} pairs with > a specific Policy Rule Identifier) has one or more owners.  > That is, the Middlebox remembers the Agent(s) who installed > those rules. > > > >Whether more than one Agent should be able to work with the > same Policy Rule is a matter for discussion, though I sense > an inclination not to allow this.  (But it seems to me that > an Administrator should be able to audit all installed Policy > Rules and deactivate any of them if need be.)  On the other > hand, I think it is accepted that different Policy Rules > could overlap in their scope.  So I'll concentrate my > discussion on the case where a new Policy Rule is in conflict > with a previously installed Policy Rule. > > > >I would suggest a general approach to conflicts of this form: > > > > - If an Agent contradicts itself, the Middlebox denies the > new Policy Rule Request.  It returns an appropriate reason > code and the Policy Rule Identifier of the rule which is in > conflict.  The Agent then has the information it needs to > choose between modifying the already-existing rule to > accommodate the new conditions or giving up on the new Policy Rule. > > > > - If an Agent contradicts another Agent, Agent priorities > come into play.  I'm happy enough to allow only two > priorities: Administrator and others, but I'm not sure we > need to specify this, only that there exists a hierarchy of > Agent priorities.  The general rule is then that the Policy > Rule installed by the higher priority agent prevails and the > other one is rejected or deactivated as the case may be.  > Between equal-priority Agents, existing Policy Rules take > priority over new ones. > > > >One open question is what diagnostic information should be > supplied when a Policy Rule is rejected or deactivated.  I > see the following possibilities: > > > >(1) The Middlebox computes and returns a modified Policy > Rule that would be consistent with the over-riding Policy Rule. > > > >(2) The Middlebox returns the complete contents of the > over-riding Policy Rule. > >(3) The Middlebox returns the (sub)set of {Filter, Action} > pairs within the over-riding Policy Rule which are in > conflict with the disallowed Policy Rule. > > > >(4) The Middlebox returns a set of filters which describe > the precise area of conflict with the over-riding Policy Rule. > > > >I have a bit of a concern with privacy which inclines me to > alternative (4). > > > >-----Original Message----- > >From: Martin Stiemerling > [mailto:Martin.Stiemer ling@ccrle.nec.de] >Sent: Friday, April 05, 2002 9:57 AM >To: Sen, Sanjoy [NGC:B692:EXCH] >Cc: 'Jiri Kuthan'; Taylor, Tom-PT [CAR:B800:EXCH]; midcom@ietf.org; >Aoun, Cedric [QPD:MA01:EXCH] >Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content > >Sanjoy Sen wrote: > >> How will then the following requirement from Midcom requirements draft >> be satisfied? >> ***** >> 2.2.11. >> >>      It should be possible to define rulesets that contain a more spe- >>      cific filter spec than an overlapping ruleset.  This should allow >>      agents to request actions for the subset that contradict those of >>      the overlapping set. >> ***** > > > > >> Whether you want it or not, there would be overlapping rulesets because >> the filterspec may overlap for different rulesets installed by >> independent agents. The question - who wins when there're contradictory > >> actions is moot because the requirement above seems to suggest that we >> need to allow contradictory behavior. > >The questions is, who will decide how to behave in such a case? There >are so many combinations of firewall/NAT configurations which will make >it difficult to define a stable behaviour, i.e. how to react with this >overlapping set. Furthermore, the requirement starts with "should"... > >Martin >-- >Martin Stiemerling > >NEC Europe Ltd. -- Network Laboratories  Stiemerling@ccrle.nec.de >IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Apr 12 15:27:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01505 for ; Fri, 12 Apr 2002 15:27:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA07312 for midcom-archive@odin.ietf.org; Fri, 12 Apr 2002 15:27:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAB06936; Fri, 12 Apr 2002 15:21:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05814 for ; Fri, 12 Apr 2002 15:04:39 -0400 (EDT) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00718 for ; Fri, 12 Apr 2002 15:04:36 -0400 (EDT) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 12 Apr 2002 12:04:07 -0700 Received: from 157.54.5.25 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 12 Apr 2002 12:04:07 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 12 Apr 2002 12:04:06 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 12 Apr 2002 12:04:06 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Fri, 12 Apr 2002 12:00:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Fri, 12 Apr 2002 12:00:35 -0700 Message-ID: Thread-Topic: [midcom] MIDCOM SEmantics: Policy Rule Content Thread-Index: AcHiUnsdO7tGsTscQ7aVUrxmpG8fwQAAiMhQ From: "Christian Huitema" To: "Tom-PT Taylor" , "Sanjoy Sen" , "Jiri Kuthan" , "Martin Stiemerling" Cc: , "Cedric Aoun" X-OriginalArrivalTime: 12 Apr 2002 19:00:35.0616 (UTC) FILETIME=[53EB8A00:01C1E254] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA05815 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit Not necessarily. From an operational point of view, it is important to not tie a rule to an agent -- we debated that at length last year. -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Friday, April 12, 2002 11:51 AM To: Christian Huitema; Sanjoy Sen; Jiri Kuthan; Martin Stiemerling Cc: midcom@ietf.org; Cedric Aoun Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Would the same Agent install both rules? -----Original Message----- From: Christian Huitema [mailto:huitema@windows.microsoft.com] Sent: Friday, April 12, 2002 2:24 PM To: Sen, Sanjoy [NGC:B692:EXCH]; Taylor, Tom-PT [CAR:B800:EXCH]; Jiri Kuthan; Martin Stiemerling Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content I am sorry, but the requirement was there for a very strong operational reason. For example, it should be possible to say something like: 1) disallow UDP on port 3456 in general 2) allow UDP on port 3456 if the source is X and the destination Y. -- Christian Huitema -----Original Message----- From: Sanjoy Sen [mailto:sanjoy@nortelnetworks.com] Sent: Friday, April 12, 2002 10:21 AM To: Tom-PT Taylor; 'Jiri Kuthan'; 'Martin Stiemerling' Cc: 'midcom@ietf.org'; Cedric Aoun Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content I support this as a good compromise. We should disallow contradictions in overlapping rulesets (and resolve on a FCFS basis). But, we should allow overlapping rulesets if there's no contradiction.  > -----Original Message----- > From: Taylor, Tom-PT [CAR:B800:EXCH] > Sent: Friday, April 12, 2002 7:52 AM > To: 'Jiri Kuthan'; 'Martin Stiemerling'; Sen, Sanjoy [NGC:B692:EXCH] > Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] > Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content > > > I agree with your distinction between the issues of rule > overlapping and access control.  I do wonder if you are being > too dogmatic on the matter of rule overlapping, and would beg > for exceptions in two cases: > >   -- the rules do not involve contradictory actions (e.g. > both rules allow flows) > >   -- the rules both come from the same Agent. > > Here is an example scenario in which I could see the > possibility of rule overlapping: a rule is set up allowing > any node inside to connect to a specific address outside.  > Then an Agent sets up a rule allowing connection from a > specific inside address to that outside address.  In the > process, the Agent receives an address binding to the mapped > address at the Middlebox.  Using the notation I have proposed > earlier, the first rule is: > > Filter= { Source address:      ANY, >           Source port:         ANY, >           Source realm:        , >           Map address:         ANY, >           Map port:            ANY, >           Map realm:           , >           Destination address: , >           Destination port:    , >           Destination realm:   , >           Protocol             }, > > Action = Allow > > The second, more specific rule is: > > Filter= { Source address:      , >           Source port:         , >           Source realm:        , >           Map address:         CHOOSE, >           Map port:            CHOOSE, >           Map realm:           , >           Destination address: , >           Destination port:    , >           Destination realm:   }, > > Action = Allow > > In response to this second rule the Middlebox reports the > bindings it has assigned for the CHOOSE entries. > > I can think of one or two arguments you may have against this > sort of situation, but I don't know which particular > arguments you would choose.  So I'll see what you have to say. > > As for allowing an Agent to amend or contradict itself, I see > this as a matter of convenience.  It makes it easier to > associate specific Policy Rules with specific application > sessions, regardless of how they interact.  If you disallow > it, the workaround is for the agent to combine everything > into a single Policy Rule.  This is OK provided that the > Agent knows that it itself is the source of the overlap. > > > -----Original Message----- > From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de] > Sent: Friday, April 12, 2002 5:30 AM > To: Taylor, Tom-PT [CAR:B800:EXCH]; 'Martin Stiemerling'; Sen, Sanjoy > [NGC:B692:EXCH] > Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] > Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content > > > I think people mix up two issues: rule overlapping and access control. > > I argumented against rule overlapping -- I want to disallow rules > with different packet matching expressions with packets matching > both of them. Doing anything else is a ticket for unneeded complexity > and I see reluctance to enter such business on mailing list. > > The other, security-policy issue is how access to rules > with identical packet matching expressions is governed. Which is > a different discussion. > > -Jiri > > At 06:43 PM 4/5/2002, Tom-PT Taylor wrote: > > >Assuming that contradictions are possible (see my previous message), > > Please NO. > > > we should distinguish two cases: > > - a specific Agent contradicts a Policy Rule installed > previously by that same Agent > > - a specific Agent contradicts a Policy Rule installed by > another Agent. > > > >An underlying premise of our proposed semantics is that each > Policy Rule (defined as a set of {Filter, Action} pairs with > a specific Policy Rule Identifier) has one or more owners.  > That is, the Middlebox remembers the Agent(s) who installed > those rules. > > > >Whether more than one Agent should be able to work with the > same Policy Rule is a matter for discussion, though I sense > an inclination not to allow this.  (But it seems to me that > an Administrator should be able to audit all installed Policy > Rules and deactivate any of them if need be.)  On the other > hand, I think it is accepted that different Policy Rules > could overlap in their scope.  So I'll concentrate my > discussion on the case where a new Policy Rule is in conflict > with a previously installed Policy Rule. > > > >I would suggest a general approach to conflicts of this form: > > > > - If an Agent contradicts itself, the Middlebox denies the > new Policy Rule Request.  It returns an appropriate reason > code and the Policy Rule Identifier of the rule which is in > conflict.  The Agent then has the information it needs to > choose between modifying the already-existing rule to > accommodate the new conditions or giving up on the new Policy Rule. > > > > - If an Agent contradicts another Agent, Agent priorities > come into play.  I'm happy enough to allow only two > priorities: Administrator and others, but I'm not sure we > need to specify this, only that there exists a hierarchy of > Agent priorities.  The general rule is then that the Policy > Rule installed by the higher priority agent prevails and the > other one is rejected or deactivated as the case may be.  > Between equal-priority Agents, existing Policy Rules take > priority over new ones. > > > >One open question is what diagnostic information should be > supplied when a Policy Rule is rejected or deactivated.  I > see the following possibilities: > > > >(1) The Middlebox computes and returns a modified Policy > Rule that would be consistent with the over-riding Policy Rule. > > > >(2) The Middlebox returns the complete contents of the > over-riding Policy Rule. > >(3) The Middlebox returns the (sub)set of {Filter, Action} > pairs within the over-riding Policy Rule which are in > conflict with the disallowed Policy Rule. > > > >(4) The Middlebox returns a set of filters which describe > the precise area of conflict with the over-riding Policy Rule. > > > >I have a bit of a concern with privacy which inclines me to > alternative (4). > > > >-----Original Message----- > >From: Martin Stiemerling > [mailto:Martin.Stiemer ling@ccrle.nec.de] >Sent: Friday, April 05, 2002 9:57 AM >To: Sen, Sanjoy [NGC:B692:EXCH] >Cc: 'Jiri Kuthan'; Taylor, Tom-PT [CAR:B800:EXCH]; midcom@ietf.org; >Aoun, Cedric [QPD:MA01:EXCH] >Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content > >Sanjoy Sen wrote: > >> How will then the following requirement from Midcom requirements draft >> be satisfied? >> ***** >> 2.2.11. >> >>      It should be possible to define rulesets that contain a more spe- >>      cific filter spec than an overlapping ruleset.  This should allow >>      agents to request actions for the subset that contradict those of >>      the overlapping set. >> ***** > > > > >> Whether you want it or not, there would be overlapping rulesets because >> the filterspec may overlap for different rulesets installed by >> independent agents. The question - who wins when there're contradictory > >> actions is moot because the requirement above seems to suggest that we >> need to allow contradictory behavior. > >The questions is, who will decide how to behave in such a case? There >are so many combinations of firewall/NAT configurations which will make >it difficult to define a stable behaviour, i.e. how to react with this >overlapping set. Furthermore, the requirement starts with "should"... > >Martin >-- >Martin Stiemerling > >NEC Europe Ltd. -- Network Laboratories  Stiemerling@ccrle.nec.de >IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Apr 12 15:31:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01677 for ; Fri, 12 Apr 2002 15:31:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA07854 for midcom-archive@odin.ietf.org; Fri, 12 Apr 2002 15:31:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07068; Fri, 12 Apr 2002 15:23:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07035 for ; Fri, 12 Apr 2002 15:23:12 -0400 (EDT) Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01320 for ; Fri, 12 Apr 2002 15:23:09 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 3E12581DA for ; Fri, 12 Apr 2002 14:23:07 -0500 (CDT) Received: by isis.visi.com (Postfix, from userid 2286) id C3D5376C27; Fri, 12 Apr 2002 14:23:06 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by isis.visi.com (Postfix) with ESMTP id C160376C26 for ; Fri, 12 Apr 2002 14:23:06 -0500 (CDT) Date: Fri, 12 Apr 2002 14:23:06 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content In-Reply-To: <4D79C746863DD51197690002A52CDA0001E8A2EF@zcard0kc.ca.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This discussion, while fascinating, appears to be operating in a vacuum. Please name ONE existing middlebox device that disallows -- or can even detect -- conflicting rules. While a few probably exist, most will use a stacking model of some sort. Logic of the form: the most recently applied rule relevant to the packet applies or all relevant rules are applied in the order they were created until either a rule discards the packet or all are done. or whatever. There are numerous ways to resolve this. Disallowing conflicting rules simply isn't one of the good ways. It is NORMAL to build policy by layering rules according to whatever the conflictin-rule logic of your box is. It is NORMAL to define general policy, and overlay/underlay/whatever special cases. Andrew _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Apr 12 15:33:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01739 for ; Fri, 12 Apr 2002 15:33:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA08058 for midcom-archive@odin.ietf.org; Fri, 12 Apr 2002 15:33:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05892; Fri, 12 Apr 2002 15:06:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05865 for ; Fri, 12 Apr 2002 15:05:58 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00770 for ; Fri, 12 Apr 2002 15:05:55 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g3CJ5R3e008300; Fri, 12 Apr 2002 12:05:27 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADN69794; Fri, 12 Apr 2002 12:02:45 -0700 (PDT) Message-Id: <5.1.0.14.0.20020412150329.00a963d0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 12 Apr 2002 15:09:21 -0400 To: Ted.Hardie@nominum.com From: Melinda Shore Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content Cc: "'midcom@ietf.org'" In-Reply-To: <20020412114840.B90127@shell.nominum.com> References: <933FADF5E673D411B8A30002A5608A0E01187A76@zrc2c012.us.nortel.com> <933FADF5E673D411B8A30002A5608A0E01187A76@zrc2c012.us.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 11:48 AM 4/12/02 -0700, Ted Hardie wrote: > Possibly my memory is faulty here, but I thought we had >previously agreed that an override was a possibility for a standard >rule. We did discuss it, and there was substantial agreement that that should be the case. > I have not found that discussion in the archives after >a quick scan, so it is possible I am mis-remembering the conculsion. >If that was the conclusion, I think we have a slightly more >complex problem, as there is no way for an agent to know in >advance that the rule is overlapping. That touches on a question I've been having about this discussion, actually. I tend to think that whether or not a middlebox can honor overlapping requests is out-of-scope. We do need for the middlebox to be able to provide a meaningful response to a request, but we need to avoid overspecifying the behavior of the middlebox itself. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Apr 12 15:47:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02066 for ; Fri, 12 Apr 2002 15:47:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA08210 for midcom-archive@odin.ietf.org; Fri, 12 Apr 2002 15:38:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07461; Fri, 12 Apr 2002 15:28:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07430 for ; Fri, 12 Apr 2002 15:28:52 -0400 (EDT) Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01558 for ; Fri, 12 Apr 2002 15:28:49 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 6E1FD81D3 for ; Fri, 12 Apr 2002 14:28:51 -0500 (CDT) Received: by isis.visi.com (Postfix, from userid 2286) id 1966D76C27; Fri, 12 Apr 2002 14:28:51 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by isis.visi.com (Postfix) with ESMTP id 0371D76C26 for ; Fri, 12 Apr 2002 14:28:50 -0500 (CDT) Date: Fri, 12 Apr 2002 14:28:50 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Fri, 12 Apr 2002, Christian Huitema wrote: > I am sorry, but the requirement was there for a very strong operational reason. For example, it should be possible to say something like: > > 1) disallow UDP on port 3456 in general > 2) allow UDP on port 3456 if the source is X and the destination Y. Exactly. If a strictly-more-specific rule can't conflict with a more general rule, what's the point of the more specific rule? A) allow all UDP B) allow UDP to port 1234 is null. I suppose it might be convenient to allow overlap that extends, you COULD do: A) allow ports 0 through 10,000 B) allow ports 9,000 through 20,000 but this is pretty rare. You're almost always layering more specific atop less specific. Splitting hairs by allowing "dynamic" rules to conflict only with "provisioned" rules just makes life harder for everyone. It simplifies nothing that I can see, and certainly makes several things -- starting with the protocol semantics definition -- more complicated. If you allow conflicts (and you must) just allow them. Andrew _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Apr 12 15:59:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02315 for ; Fri, 12 Apr 2002 15:59:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA09096 for midcom-archive@odin.ietf.org; Fri, 12 Apr 2002 15:59:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08898; Fri, 12 Apr 2002 15:51:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08867 for ; Fri, 12 Apr 2002 15:51:45 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02186 for ; Fri, 12 Apr 2002 15:51:41 -0400 (EDT) Received: from airborne.cisco.com (IDENT:mirapoint@airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g3CJpD83023867 for ; Fri, 12 Apr 2002 12:51:13 -0700 (PDT) Received: from SBRIM-W2K (rtp-vpn2-120.cisco.com [10.82.240.120]) by airborne.cisco.com (Mirapoint) with SMTP id AAZ76366; Fri, 12 Apr 2002 12:51:00 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Fri, 12 Apr 2002 15:51:11 -0400 Date: Fri, 12 Apr 2002 15:51:11 -0400 From: Scott Brim To: "'midcom@ietf.org'" Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content Message-ID: <20020412155111.J2312@SBRIM-W2K> Mail-Followup-To: Scott Brim , "'midcom@ietf.org'" References: <933FADF5E673D411B8A30002A5608A0E01187A76@zrc2c012.us.nortel.com> <933FADF5E673D411B8A30002A5608A0E01187A76@zrc2c012.us.nortel.com> <20020412114840.B90127@shell.nominum.com> <5.1.0.14.0.20020412150329.00a963d0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.0.20020412150329.00a963d0@localhost>; from mshore@cisco.com on Fri, Apr 12, 2002 at 03:09:21PM -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Fri, Apr 12, 2002 03:09:21PM -0400, Melinda Shore wrote: > That touches on a question I've been having about this discussion, > actually. I tend to think that whether or not a middlebox can > honor overlapping requests is out-of-scope. We do need for > the middlebox to be able to provide a meaningful response to a > request, but we need to avoid overspecifying the behavior of > the middlebox itself. But we do need the behavior of the box to be deterministic. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Apr 12 16:21:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02920 for ; Fri, 12 Apr 2002 16:21:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA10656 for midcom-archive@odin.ietf.org; Fri, 12 Apr 2002 16:21:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09738; Fri, 12 Apr 2002 16:05:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08961 for ; Fri, 12 Apr 2002 15:55:15 -0400 (EDT) Received: from mail.netscreen.com (mail.netscreen.com [63.126.135.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02229 for ; Fri, 12 Apr 2002 15:55:12 -0400 (EDT) Received: from ns-ca.netscreen.com (ns-ca.netscreen.com [63.126.135.21] (may be forged)) by mail.netscreen.com (8.10.0/8.10.0) with ESMTP id g3CIiVM19761 for ; Fri, 12 Apr 2002 11:44:31 -0700 Received: by NS-CA with Internet Mail Service (5.5.2653.19) id <2RWRSGM7>; Fri, 12 Apr 2002 12:53:53 -0700 Message-ID: From: John LaCour To: midcom@ietf.org Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Fri, 12 Apr 2002 12:54:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org How a middlebox resolves potential rule conflicts and rule precedence should be left up to middlebox implementors and is not something that the protocol needs to be capable of expressing. The middlebox will need to have it's own authorization and precedence model which resolves these issues not just between competing midcom agents but also for things like: - application layer gateways - automated responses due to some event detected by the middlebox - scheduled policies - competing management entities Solving the problem for competing midcom-agents, if you can do that, doesn't solve the whole problem anyway. The protocol need only to be able to express the request and the result. -John _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Apr 12 16:24:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01738 for ; Fri, 12 Apr 2002 15:33:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA08063 for midcom-archive@odin.ietf.org; Fri, 12 Apr 2002 15:33:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06570; Fri, 12 Apr 2002 15:17:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06529 for ; Fri, 12 Apr 2002 15:17:25 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01132 for ; Fri, 12 Apr 2002 15:17:22 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3CJGqD15807 for ; Fri, 12 Apr 2002 15:16:53 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <2WJANR09>; Fri, 12 Apr 2002 15:16:53 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A2F0@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Melinda Shore'" , Ted.Hardie@nominum.com Cc: "'midcom@ietf.org'" Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Fri, 12 Apr 2002 15:16:46 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I'm happy enough with that as a general direction, though it seems to me we're back almost where I started. The original concern expressed was that I expected too much provisioning on the Middlebox. Maybe by not specifying how the Middlebox makes its decisions we get around that and satisfy everyone. -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Friday, April 12, 2002 3:09 PM To: Ted.Hardie@nominum.com Cc: 'midcom@ietf.org' Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content At 11:48 AM 4/12/02 -0700, Ted Hardie wrote: > Possibly my memory is faulty here, but I thought we had >previously agreed that an override was a possibility for a standard >rule. We did discuss it, and there was substantial agreement that that should be the case. > I have not found that discussion in the archives after >a quick scan, so it is possible I am mis-remembering the conculsion. >If that was the conclusion, I think we have a slightly more >complex problem, as there is no way for an agent to know in >advance that the rule is overlapping. That touches on a question I've been having about this discussion, actually. I tend to think that whether or not a middlebox can honor overlapping requests is out-of-scope. We do need for the middlebox to be able to provide a meaningful response to a request, but we need to avoid overspecifying the behavior of the middlebox itself. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Apr 12 16:35:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03374 for ; Fri, 12 Apr 2002 16:35:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA11875 for midcom-archive@odin.ietf.org; Fri, 12 Apr 2002 16:35:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10915; Fri, 12 Apr 2002 16:25:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10831 for ; Fri, 12 Apr 2002 16:25:44 -0400 (EDT) Received: from zsc3s004.us.nortel.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03126 for ; Fri, 12 Apr 2002 16:25:40 -0400 (EDT) Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zsc3s004.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3CJGwm25326; Fri, 12 Apr 2002 12:16:58 -0700 (PDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2JXM9JQS>; Fri, 12 Apr 2002 12:16:52 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C01E6B324@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: "Tom-PT Taylor", "'Christian Huitema'" , "Sanjoy Sen", Jiri Kuthan , Martin Stiemerling Cc: midcom@ietf.org, "Cedric Aoun" Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Fri, 12 Apr 2002 12:17:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E256.9E9328D6" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E256.9E9328D6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorry if this questions was already hashed on this big thread, but who will check and decide when rules overlap or are a complete = subset of one another? Or is it just out-of-scope? For simple rules (5-tuples = type) it might be easy, but if we have more complex rules it might be = impossible.=20 Even for 5-tuple there might be some border cases when you start = installing rules for protocols that can use both TCP and UDP like SIP, or use domainnames instead of addresses. thanks, Reinaldo >-----Original Message----- >From: Taylor, Tom-PT [CAR:B800:EXCH]=20 >Sent: Friday, April 12, 2002 11:51 AM >To: 'Christian Huitema'; Sen, Sanjoy [NGC:B692:EXCH]; Jiri Kuthan; >Martin Stiemerling >Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] >Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content > > >Would the same Agent install both rules? > >-----Original Message----- >From: Christian Huitema [mailto:huitema@windows.microsoft.com] >Sent: Friday, April 12, 2002 2:24 PM >To: Sen, Sanjoy [NGC:B692:EXCH]; Taylor, Tom-PT [CAR:B800:EXCH]; Jiri >Kuthan; Martin Stiemerling >Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] >Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content > > >I am sorry, but the requirement was there for a very strong = operational >reason. For example, it should be possible to say something like: > >1) disallow UDP on port 3456 in general >2) allow UDP on port 3456 if the source is X and the destination Y. > >-- Christian Huitema > >-----Original Message----- >From: Sanjoy Sen [mailto:sanjoy@nortelnetworks.com]=20 >Sent: Friday, April 12, 2002 10:21 AM >To: Tom-PT Taylor; 'Jiri Kuthan'; 'Martin Stiemerling' >Cc: 'midcom@ietf.org'; Cedric Aoun >Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content > >I support this as a good compromise. We should disallow=20 >contradictions in >overlapping rulesets (and resolve on a FCFS basis). But, we=20 >should allow >overlapping rulesets if there's no contradiction.=A0=20 >> -----Original Message-----=20 >> From: Taylor, Tom-PT [CAR:B800:EXCH]=20 >> Sent: Friday, April 12, 2002 7:52 AM=20 >> To: 'Jiri Kuthan'; 'Martin Stiemerling'; Sen, Sanjoy [NGC:B692:EXCH] = >> Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH]=20 >> Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content=20 >>=20 >>=20 >> I agree with your distinction between the issues of rule=20 >> overlapping and access control.=A0 I do wonder if you are being=20 >> too dogmatic on the matter of rule overlapping, and would beg=20 >> for exceptions in two cases:=20 >>=20 >>=A0=A0 -- the rules do not involve contradictory actions (e.g.=20 >> both rules allow flows)=20 >>=20 >>=A0=A0 -- the rules both come from the same Agent.=20 >>=20 >> Here is an example scenario in which I could see the=20 >> possibility of rule overlapping: a rule is set up allowing=20 >> any node inside to connect to a specific address outside.=A0=20 >> Then an Agent sets up a rule allowing connection from a=20 >> specific inside address to that outside address.=A0 In the=20 >> process, the Agent receives an address binding to the mapped=20 >> address at the Middlebox.=A0 Using the notation I have proposed=20 >> earlier, the first rule is:=20 >>=20 >> Filter=3D { Source address:=A0=A0=A0=A0=A0 ANY,=20 >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Source port:=A0=A0=A0=A0=A0=A0=A0=A0 = ANY,=20 >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Source realm:=A0=A0=A0=A0=A0=A0=A0 = ,=20 >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Map address:=A0=A0=A0=A0=A0=A0=A0=A0 = ANY,=20 >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Map = port:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ANY,=20 >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Map = realm:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ,=20 >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Destination address: ,=20 >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Destination port:=A0=A0=A0 ,=20 >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Destination realm:=A0=A0 ,=20 >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Protocol=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 },=20 >>=20 >> Action =3D Allow=20 >>=20 >> The second, more specific rule is:=20 >>=20 >> Filter=3D { Source address:=A0=A0=A0=A0=A0 ,=20 >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Source port:=A0=A0=A0=A0=A0=A0=A0=A0 = ,=20 >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Source realm:=A0=A0=A0=A0=A0=A0=A0 = ,=20 >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Map address:=A0=A0=A0=A0=A0=A0=A0=A0 = CHOOSE,=20 >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Map = port:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 CHOOSE,=20 >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Map = realm:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ,=20 >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Destination address: ,=20 >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Destination port:=A0=A0=A0 ,=20 >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Destination realm:=A0=A0 },=20 >>=20 >> Action =3D Allow=20 >>=20 >> In response to this second rule the Middlebox reports the=20 >> bindings it has assigned for the CHOOSE entries.=20 >>=20 >> I can think of one or two arguments you may have against this=20 >> sort of situation, but I don't know which particular=20 >> arguments you would choose.=A0 So I'll see what you have to say.=20 >>=20 >> As for allowing an Agent to amend or contradict itself, I see=20 >> this as a matter of convenience.=A0 It makes it easier to=20 >> associate specific Policy Rules with specific application=20 >> sessions, regardless of how they interact.=A0 If you disallow=20 >> it, the workaround is for the agent to combine everything=20 >> into a single Policy Rule.=A0 This is OK provided that the=20 >> Agent knows that it itself is the source of the overlap.=20 >>=20 >>=20 >> -----Original Message-----=20 >> From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de]=20 >> Sent: Friday, April 12, 2002 5:30 AM=20 >> To: Taylor, Tom-PT [CAR:B800:EXCH]; 'Martin Stiemerling';=20 >Sen, Sanjoy=20 >> [NGC:B692:EXCH]=20 >> Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH]=20 >> Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content=20 >>=20 >>=20 >> I think people mix up two issues: rule overlapping and=20 >access control.=20 >>=20 >> I argumented against rule overlapping -- I want to disallow rules=20 >> with different packet matching expressions with packets matching=20 >> both of them. Doing anything else is a ticket for unneeded=20 >complexity=20 >> and I see reluctance to enter such business on mailing list.=20 >>=20 >> The other, security-policy issue is how access to rules=20 >> with identical packet matching expressions is governed. Which is=20 >> a different discussion.=20 >>=20 >> -Jiri=20 >>=20 >> At 06:43 PM 4/5/2002, Tom-PT Taylor wrote:=20 >>=20 >> >Assuming that contradictions are possible (see my previous=20 >message),=20 >>=20 >> Please NO.=20 >>=20 >> > we should distinguish two cases:=20 >> > - a specific Agent contradicts a Policy Rule installed=20 >> previously by that same Agent=20 >> > - a specific Agent contradicts a Policy Rule installed by=20 >> another Agent.=20 >> >=20 >> >An underlying premise of our proposed semantics is that each=20 >> Policy Rule (defined as a set of {Filter, Action} pairs with=20 >> a specific Policy Rule Identifier) has one or more owners.=A0=20 >> That is, the Middlebox remembers the Agent(s) who installed=20 >> those rules.=20 >> >=20 >> >Whether more than one Agent should be able to work with the=20 >> same Policy Rule is a matter for discussion, though I sense=20 >> an inclination not to allow this.=A0 (But it seems to me that=20 >> an Administrator should be able to audit all installed Policy=20 >> Rules and deactivate any of them if need be.)=A0 On the other=20 >> hand, I think it is accepted that different Policy Rules=20 >> could overlap in their scope.=A0 So I'll concentrate my=20 >> discussion on the case where a new Policy Rule is in conflict=20 >> with a previously installed Policy Rule.=20 >> >=20 >> >I would suggest a general approach to conflicts of this form:=20 >> >=20 >> > - If an Agent contradicts itself, the Middlebox denies the=20 >> new Policy Rule Request.=A0 It returns an appropriate reason=20 >> code and the Policy Rule Identifier of the rule which is in=20 >> conflict.=A0 The Agent then has the information it needs to=20 >> choose between modifying the already-existing rule to=20 >> accommodate the new conditions or giving up on the new Policy Rule.=20 >> >=20 >> > - If an Agent contradicts another Agent, Agent priorities=20 >> come into play.=A0 I'm happy enough to allow only two=20 >> priorities: Administrator and others, but I'm not sure we=20 >> need to specify this, only that there exists a hierarchy of=20 >> Agent priorities.=A0 The general rule is then that the Policy=20 >> Rule installed by the higher priority agent prevails and the=20 >> other one is rejected or deactivated as the case may be.=A0=20 >> Between equal-priority Agents, existing Policy Rules take=20 >> priority over new ones.=20 >> >=20 >> >One open question is what diagnostic information should be=20 >> supplied when a Policy Rule is rejected or deactivated.=A0 I=20 >> see the following possibilities:=20 >> >=20 >> >(1) The Middlebox computes and returns a modified Policy=20 >> Rule that would be consistent with the over-riding Policy Rule.=20 >> >=20 >> >(2) The Middlebox returns the complete contents of the=20 >> over-riding Policy Rule.=20 >> >(3) The Middlebox returns the (sub)set of {Filter, Action}=20 >> pairs within the over-riding Policy Rule which are in=20 >> conflict with the disallowed Policy Rule.=20 >> >=20 >> >(4) The Middlebox returns a set of filters which describe=20 >> the precise area of conflict with the over-riding Policy Rule.=20 >> >=20 >> >I have a bit of a concern with privacy which inclines me to=20 >> alternative (4).=20 >> >=20 >> >-----Original Message-----=20 >> >From: Martin Stiemerling=20 >> [mailto:Martin.Stiemer=20 >ling@ccrle.nec.de]=20 >>Sent: Friday, April 05, 2002 9:57 AM=20 >>To: Sen, Sanjoy [NGC:B692:EXCH]=20 >>Cc: 'Jiri Kuthan'; Taylor, Tom-PT [CAR:B800:EXCH]; midcom@ietf.org;=20 >>Aoun, Cedric [QPD:MA01:EXCH]=20 >>Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content=20 >>=20 >>Sanjoy Sen wrote:=20 >>=20 >>> How will then the following requirement from Midcom=20 >requirements draft=20 >>> be satisfied?=20 >>> *****=20 >>> 2.2.11.=20 >>>=20 >>>=A0=A0=A0=A0=A0 It should be possible to define rulesets that = contain=20 >a more spe-=20 >>>=A0=A0=A0=A0=A0 cific filter spec than an overlapping ruleset.=A0 = This=20 >should allow=20 >>>=A0=A0=A0=A0=A0 agents to request actions for the subset that=20 >contradict those of=20 >>>=A0=A0=A0=A0=A0 the overlapping set.=20 >>> *****=20 >>=20 >> >=20 >>=20 >>> Whether you want it or not, there would be overlapping=20 >rulesets because=20 >>> the filterspec may overlap for different rulesets installed by=20 >>> independent agents. The question - who wins when there're=20 >contradictory=20 >>=20 >>> actions is moot because the requirement above seems to=20 >suggest that we=20 >>> need to allow contradictory behavior.=20 >>=20 >>The questions is, who will decide how to behave in such a case? There = >>are so many combinations of firewall/NAT configurations which=20 >will make=20 >>it difficult to define a stable behaviour, i.e. how to react=20 >with this=20 >>overlapping set. Furthermore, the requirement starts with "should"... = >>=20 >>Martin=20 >>--=20 >>Martin Stiemerling=20 >>=20 >>NEC Europe Ltd. -- Network Laboratories=A0 Stiemerling@ccrle.nec.de=20 >>IPv4: http://www.ccrle.nec.de=A0 IPv6: >http://www.ipv6.ccrle.nec.de=20 > >_______________________________________________ >midcom mailing list >midcom@ietf.org >https://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C1E256.9E9328D6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] MIDCOM SEmantics: Policy Rule Content

Sorry if this questions was already hashed on this = big thread,

but who will check and decide when rules overlap or = are a complete subset of one another? Or is it just out-of-scope? For = simple rules (5-tuples type) it might be easy, but if we have more = complex rules it might be impossible.

Even for 5-tuple there might be some border cases = when you start installing rules for protocols that can use both TCP and = UDP like SIP, or use domainnames instead of addresses.

thanks,

Reinaldo


>-----Original Message-----
>From: Taylor, Tom-PT [CAR:B800:EXCH]
>Sent: Friday, April 12, 2002 11:51 AM
>To: 'Christian Huitema'; Sen, Sanjoy = [NGC:B692:EXCH]; Jiri Kuthan;
>Martin Stiemerling
>Cc: midcom@ietf.org; Aoun, Cedric = [QPD:MA01:EXCH]
>Subject: RE: [midcom] MIDCOM SEmantics: Policy = Rule Content
>
>
>Would the same Agent install both rules?
>
>-----Original Message-----
>From: Christian Huitema [mailto:huitema@windows.mic= rosoft.com]
>Sent: Friday, April 12, 2002 2:24 PM
>To: Sen, Sanjoy [NGC:B692:EXCH]; Taylor, Tom-PT = [CAR:B800:EXCH]; Jiri
>Kuthan; Martin Stiemerling
>Cc: midcom@ietf.org; Aoun, Cedric = [QPD:MA01:EXCH]
>Subject: RE: [midcom] MIDCOM SEmantics: Policy = Rule Content
>
>
>I am sorry, but the requirement was there for a = very strong operational
>reason. For example, it should be possible to = say something like:
>
>1) disallow UDP on port 3456 in general
>2) allow UDP on port 3456 if the source is X and = the destination Y.
>
>-- Christian Huitema
>
>-----Original Message-----
>From: Sanjoy Sen [mailto:sanjoy@nortelnetworks.c= om]
>Sent: Friday, April 12, 2002 10:21 AM
>To: Tom-PT Taylor; 'Jiri Kuthan'; 'Martin = Stiemerling'
>Cc: 'midcom@ietf.org'; Cedric Aoun
>Subject: RE: [midcom] MIDCOM SEmantics: Policy = Rule Content
>
>I support this as a good compromise. We should = disallow
>contradictions in
>overlapping rulesets (and resolve on a FCFS = basis). But, we
>should allow
>overlapping rulesets if there's no = contradiction.=A0
>> -----Original Message-----
>> From: Taylor, Tom-PT [CAR:B800:EXCH] =
>> Sent: Friday, April 12, 2002 7:52 AM =
>> To: 'Jiri Kuthan'; 'Martin Stiemerling'; = Sen, Sanjoy [NGC:B692:EXCH]
>> Cc: midcom@ietf.org; Aoun, Cedric = [QPD:MA01:EXCH]
>> Subject: RE: [midcom] MIDCOM SEmantics: = Policy Rule Content
>>
>>
>> I agree with your distinction between the = issues of rule
>> overlapping and access control.=A0 I do = wonder if you are being
>> too dogmatic on the matter of rule = overlapping, and would beg
>> for exceptions in two cases:
>>
>>=A0=A0 -- the rules do not involve = contradictory actions (e.g.
>> both rules allow flows)
>>
>>=A0=A0 -- the rules both come from the same = Agent.
>>
>> Here is an example scenario in which I = could see the
>> possibility of rule overlapping: a rule is = set up allowing
>> any node inside to connect to a specific = address outside.=A0
>> Then an Agent sets up a rule allowing = connection from a
>> specific inside address to that outside = address.=A0 In the
>> process, the Agent receives an address = binding to the mapped
>> address at the Middlebox.=A0 Using the = notation I have proposed
>> earlier, the first rule is:
>>
>> Filter=3D { Source address:=A0=A0=A0=A0=A0 = ANY,
>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Source = port:=A0=A0=A0=A0=A0=A0=A0=A0 ANY,
>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Source = realm:=A0=A0=A0=A0=A0=A0=A0 <the internal realm>,
>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Map = address:=A0=A0=A0=A0=A0=A0=A0=A0 ANY,
>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Map = port:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ANY,
>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Map = realm:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <the external realm>, =
>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Destination = address: <specific external address>,
>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Destination = port:=A0=A0=A0 <specific external port>,
>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Destination = realm:=A0=A0 <the external realm>,
>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Protocol=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <a specific = protocol> },
>>
>> Action =3D Allow
>>
>> The second, more specific rule is:
>>
>> Filter=3D { Source address:=A0=A0=A0=A0=A0 = <specific internal address>,
>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Source = port:=A0=A0=A0=A0=A0=A0=A0=A0 <specific internal port>,
>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Source = realm:=A0=A0=A0=A0=A0=A0=A0 <the internal realm>,
>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Map = address:=A0=A0=A0=A0=A0=A0=A0=A0 CHOOSE,
>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Map = port:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 CHOOSE,
>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Map = realm:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <the external realm>, =
>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Destination = address: <specific external address>,
>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Destination = port:=A0=A0=A0 <specific external port>,
>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Destination = realm:=A0=A0 <the external realm> },
>>
>> Action =3D Allow
>>
>> In response to this second rule the = Middlebox reports the
>> bindings it has assigned for the CHOOSE = entries.
>>
>> I can think of one or two arguments you may = have against this
>> sort of situation, but I don't know which = particular
>> arguments you would choose.=A0 So I'll see = what you have to say.
>>
>> As for allowing an Agent to amend or = contradict itself, I see
>> this as a matter of convenience.=A0 It = makes it easier to
>> associate specific Policy Rules with = specific application
>> sessions, regardless of how they = interact.=A0 If you disallow
>> it, the workaround is for the agent to = combine everything
>> into a single Policy Rule.=A0 This is OK = provided that the
>> Agent knows that it itself is the source of = the overlap.
>>
>>
>> -----Original Message-----
>> From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de] =
>> Sent: Friday, April 12, 2002 5:30 AM =
>> To: Taylor, Tom-PT [CAR:B800:EXCH]; 'Martin = Stiemerling';
>Sen, Sanjoy
>> [NGC:B692:EXCH]
>> Cc: midcom@ietf.org; Aoun, Cedric = [QPD:MA01:EXCH]
>> Subject: RE: [midcom] MIDCOM SEmantics: = Policy Rule Content
>>
>>
>> I think people mix up two issues: rule = overlapping and
>access control.
>>
>> I argumented against rule overlapping -- I = want to disallow rules
>> with different packet matching expressions = with packets matching
>> both of them. Doing anything else is a = ticket for unneeded
>complexity
>> and I see reluctance to enter such business = on mailing list.
>>
>> The other, security-policy issue is how = access to rules
>> with identical packet matching expressions = is governed. Which is
>> a different discussion.
>>
>> -Jiri
>>
>> At 06:43 PM 4/5/2002, Tom-PT Taylor wrote: =
>>
>> >Assuming that contradictions are = possible (see my previous
>message),
>>
>> Please NO.
>>
>> > we should distinguish two cases: =
>> > - a specific Agent contradicts a = Policy Rule installed
>> previously by that same Agent
>> > - a specific Agent contradicts a = Policy Rule installed by
>> another Agent.
>> >
>> >An underlying premise of our proposed = semantics is that each
>> Policy Rule (defined as a set of {Filter, = Action} pairs with
>> a specific Policy Rule Identifier) has one = or more owners.=A0
>> That is, the Middlebox remembers the = Agent(s) who installed
>> those rules.
>> >
>> >Whether more than one Agent should be = able to work with the
>> same Policy Rule is a matter for = discussion, though I sense
>> an inclination not to allow this.=A0 (But = it seems to me that
>> an Administrator should be able to audit = all installed Policy
>> Rules and deactivate any of them if need = be.)=A0 On the other
>> hand, I think it is accepted that different = Policy Rules
>> could overlap in their scope.=A0 So I'll = concentrate my
>> discussion on the case where a new Policy = Rule is in conflict
>> with a previously installed Policy Rule. =
>> >
>> >I would suggest a general approach to = conflicts of this form:
>> >
>> > - If an Agent contradicts itself, the = Middlebox denies the
>> new Policy Rule Request.=A0 It returns an = appropriate reason
>> code and the Policy Rule Identifier of the = rule which is in
>> conflict.=A0 The Agent then has the = information it needs to
>> choose between modifying the = already-existing rule to
>> accommodate the new conditions or giving up = on the new Policy Rule.
>> >
>> > - If an Agent contradicts another = Agent, Agent priorities
>> come into play.=A0 I'm happy enough to = allow only two
>> priorities: Administrator and others, but = I'm not sure we
>> need to specify this, only that there = exists a hierarchy of
>> Agent priorities.=A0 The general rule is = then that the Policy
>> Rule installed by the higher priority agent = prevails and the
>> other one is rejected or deactivated as the = case may be.=A0
>> Between equal-priority Agents, existing = Policy Rules take
>> priority over new ones.
>> >
>> >One open question is what diagnostic = information should be
>> supplied when a Policy Rule is rejected or = deactivated.=A0 I
>> see the following possibilities:
>> >
>> >(1) The Middlebox computes and returns = a modified Policy
>> Rule that would be consistent with the = over-riding Policy Rule.
>> >
>> >(2) The Middlebox returns the complete = contents of the
>> over-riding Policy Rule.
>> >(3) The Middlebox returns the (sub)set = of {Filter, Action}
>> pairs within the over-riding Policy Rule = which are in
>> conflict with the disallowed Policy Rule. =
>> >
>> >(4) The Middlebox returns a set of = filters which describe
>> the precise area of conflict with the = over-riding Policy Rule.
>> >
>> >I have a bit of a concern with privacy = which inclines me to
>> alternative (4).
>> >
>> >-----Original Message-----
>> >From: Martin Stiemerling
>> [<mailto:Martin.Stiemerlin= g@ccrle.nec.de>mailto:Martin.Stiemer
>ling@ccrle.nec.de]
>>Sent: Friday, April 05, 2002 9:57 AM
>>To: Sen, Sanjoy [NGC:B692:EXCH]
>>Cc: 'Jiri Kuthan'; Taylor, Tom-PT = [CAR:B800:EXCH]; midcom@ietf.org;
>>Aoun, Cedric [QPD:MA01:EXCH]
>>Subject: Re: [midcom] MIDCOM SEmantics: = Policy Rule Content
>>
>>Sanjoy Sen wrote:
>>
>>> How will then the following requirement = from Midcom
>requirements draft
>>> be satisfied?
>>> *****
>>> 2.2.11.
>>>
>>>=A0=A0=A0=A0=A0 It should be possible to = define rulesets that contain
>a more spe-
>>>=A0=A0=A0=A0=A0 cific filter spec than = an overlapping ruleset.=A0 This
>should allow
>>>=A0=A0=A0=A0=A0 agents to request = actions for the subset that
>contradict those of
>>>=A0=A0=A0=A0=A0 the overlapping set. =
>>> *****
>>
>> >
>>
>>> Whether you want it or not, there would = be overlapping
>rulesets because
>>> the filterspec may overlap for = different rulesets installed by
>>> independent agents. The question - who = wins when there're
>contradictory
>>
>>> actions is moot because the requirement = above seems to
>suggest that we
>>> need to allow contradictory behavior. =
>>
>>The questions is, who will decide how to = behave in such a case? There
>>are so many combinations of firewall/NAT = configurations which
>will make
>>it difficult to define a stable behaviour, = i.e. how to react
>with this
>>overlapping set. Furthermore, the = requirement starts with "should"...
>>
>>Martin
>>--
>>Martin Stiemerling
>>
>>NEC Europe Ltd. -- Network Laboratories=A0 = Stiemerling@ccrle.nec.de
>>IPv4: <http://www.ccrle.nec.de>http://www.ccrle.nec.de=A0 IPv6:
><http://www.ipv6.ccrle.nec.de>http://www.ipv6.ccrle.nec.de
>
>_______________________________________________
>midcom mailing list
>midcom@ietf.org
>https://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C1E256.9E9328D6-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Apr 12 17:33:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04723 for ; Fri, 12 Apr 2002 17:33:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA15597 for midcom-archive@odin.ietf.org; Fri, 12 Apr 2002 17:33:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14857; Fri, 12 Apr 2002 17:28:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14763 for ; Fri, 12 Apr 2002 17:26:57 -0400 (EDT) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04592 for ; Fri, 12 Apr 2002 17:26:53 -0400 (EDT) Received: by shell.nominum.com (Postfix, from userid 11089) id 9F7CB31914; Fri, 12 Apr 2002 14:26:25 -0700 (PDT) Date: Fri, 12 Apr 2002 14:26:25 -0700 From: Ted Hardie To: John LaCour Cc: midcom@ietf.org Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content Message-ID: <20020412142625.C90127@shell.nominum.com> Reply-To: Ted.Hardie@nominum.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jlacour@netscreen.com on Fri, Apr 12, 2002 at 12:54:17PM -0700 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Fri, Apr 12, 2002 at 12:54:17PM -0700, John LaCour wrote: > How a middlebox resolves potential rule conflicts > and rule precedence should be left up to middlebox > implementors and is not something that the protocol > needs to be capable of expressing. > The protocol need only to be able to express the request > and the result. > > -John What "the result" means here seems to me critical to determining whether or not John's prefered approach (implementation-specific rule conflict resolution) can meet Scott's test of deterministic behavior. The automated teller message of "your envelope has been accepted" is a classic case of the result code crafted not to promise much (especially not that the money will show up in your account.) A result like "rule accepted into set" without an evaluation of whether or not it is in force results in the same unsatisfactory result (can I use the pinhole? can I spend the money?). regards, Ted Hardie _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Apr 12 17:49:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04891 for ; Fri, 12 Apr 2002 17:49:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA16024 for midcom-archive@odin.ietf.org; Fri, 12 Apr 2002 17:49:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15946; Fri, 12 Apr 2002 17:46:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15916 for ; Fri, 12 Apr 2002 17:46:42 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04865 for ; Fri, 12 Apr 2002 17:46:38 -0400 (EDT) Received: from asimu-u5.cisco.com (asimu-u5.cisco.com [128.107.162.97]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3CLkA87002737 for ; Fri, 12 Apr 2002 14:46:10 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by asimu-u5.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA20369 for ; Fri, 12 Apr 2002 14:46:10 -0700 (PDT) Message-ID: <3CB755A2.D8737F62@cisco.com> Date: Fri, 12 Apr 2002 14:46:10 -0700 From: Adina Simu X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: midcom@ietf.org Subject: [midcom] new draft submission (stun aware nat) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Hi, A new draft has been submitted: http://www.ietf.org/internet-drafts/draft-simu-midcom-stun-aware-nat-00.txt and the abstract reads: STUN provides an easy way to traverse some types of NATs and it will work satisfactorily in many NAT deployments. To overcome STUN's limitations, one solution is to accept the idea that NATs can change too (and they've been proven to change, an example being the proliferation of IPsec pass-thru NAT devices) and to colocate STUN server functionality on the NAT box itself. Upon receipt of a STUN request, the server colocated within the NAT device allocates addresses and ports, and installs bindings. This allows hosts running the STUN client software to transparently achieve symmetric NAT traversal and to make themselves addressable from the Global Internet. Comments and criticism welcome. thanks -Adina _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Sun Apr 14 10:58:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18618 for ; Sun, 14 Apr 2002 10:58:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA01721 for midcom-archive@odin.ietf.org; Sun, 14 Apr 2002 10:58:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01671; Sun, 14 Apr 2002 10:54:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01642 for ; Sun, 14 Apr 2002 10:54:05 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18472 for ; Sun, 14 Apr 2002 10:54:02 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3EErXg29576 for ; Sun, 14 Apr 2002 10:53:33 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <2WJAN77B>; Sun, 14 Apr 2002 10:53:35 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A2F8@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Ted.Hardie@nominum.com'" , John LaCour Cc: midcom@ietf.org Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Sun, 14 Apr 2002 10:53:41 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Let me propose this to ensure determinsitic behaviour: (1) The Middlebox must support a queue model of rules. (2) New entries can be added either at the head of the queue (processed first when looking for a match) or at the tail of a queue (processed last when looking for a match). (3) Existing entries can be deleted from anywhere in the queue. -----Original Message----- From: Ted Hardie [mailto:Ted.Hardie@nominum.com] Sent: Friday, April 12, 2002 5:26 PM To: John LaCour Cc: midcom@ietf.org Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content On Fri, Apr 12, 2002 at 12:54:17PM -0700, John LaCour wrote: > How a middlebox resolves potential rule conflicts > and rule precedence should be left up to middlebox > implementors and is not something that the protocol > needs to be capable of expressing. > The protocol need only to be able to express the request > and the result. > > -John What "the result" means here seems to me critical to determining whether or not John's prefered approach (implementation-specific rule conflict resolution) can meet Scott's test of deterministic behavior. The automated teller message of "your envelope has been accepted" is a classic case of the result code crafted not to promise much (especially not that the money will show up in your account.) A result like "rule accepted into set" without an evaluation of whether or not it is in force results in the same unsatisfactory result (can I use the pinhole? can I spend the money?). regards, Ted Hardie _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Apr 15 05:11:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10592 for ; Mon, 15 Apr 2002 05:11:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA29947 for midcom-archive@odin.ietf.org; Mon, 15 Apr 2002 05:11:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA29823; Mon, 15 Apr 2002 05:09:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA29792 for ; Mon, 15 Apr 2002 05:09:19 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10553 for ; Mon, 15 Apr 2002 05:09:15 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g3F98m834991 for ; Mon, 15 Apr 2002 11:08:48 +0200 (CEST) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA02338 for ; Mon, 15 Apr 2002 11:07:54 +0200 Received: from ccrle.nec.de (elgar.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 85D421E875 for ; Mon, 15 Apr 2002 11:07:54 +0200 (CEST) Message-ID: <3CBA987A.50803@ccrle.nec.de> Date: Mon, 15 Apr 2002 11:08:10 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20020305 X-Accept-Language: en-us MIME-Version: 1.0 To: midcom@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Some thoughts on Policy Rule Contents Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Hi folks, I have seen a lot of emails concerning the policy rule conflict resolution and for me the discussion looks like a sponge, i.e. there are so many topics which are mixing everything and you actually can't grip it anymore. The mix is of: - mixing NAT binding allocation with packet filter rule allocation or what behaviour do the people assume at all in their examples - mixing policy rule conflict resolution and allowance of installing policy rules A proposal for solving the policy rule conflict: - the midcom server processes incoming request from agents on a first come first server base - the detection of conflicts (if any) is up to the middle box, out of our scope. - the midcom server simply reports any failure in installing the rule to the agent with an appropriate reason (e.g. too many wildcarding, rule conflicts, rule rejected) Otherwise the discussion can continue the discussion to infinity. Because packet filters and NATs can be configured in multiple ways and you can't think about all possible configurations and combination of them at all (I'm eager to present nasty rule combinations to everyone who is interested). Regards Martin -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Apr 15 09:46:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17279 for ; Mon, 15 Apr 2002 09:46:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA12955 for midcom-archive@odin.ietf.org; Mon, 15 Apr 2002 09:46:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12801; Mon, 15 Apr 2002 09:42:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12772 for ; Mon, 15 Apr 2002 09:42:54 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17101 for ; Mon, 15 Apr 2002 09:42:49 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g3FDgL856349; Mon, 15 Apr 2002 15:42:21 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA05897; Mon, 15 Apr 2002 15:41:27 +0200 Date: Mon, 15 Apr 2002 15:45:33 +0200 From: Juergen Quittek To: Bob Penfield , midcom@ietf.org Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content Message-ID: <31019063.1018885533@[192.168.102.164]> In-Reply-To: <001901c1e21e$3f7f7b20$2300000a@acmepacket.com> References: <001901c1e21e$3f7f7b20$2300000a@acmepacket.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Hi Bob, --On 12 April 2002 08:33 -0400 Bob Penfield wrote: > > ----- Original Message ----- > From: "Jiri Kuthan" > > >> I think people mix up two issues: rule overlapping and access control. >> >> I argumented against rule overlapping -- I want to disallow rules >> with different packet matching expressions with packets matching >> both of them. Doing anything else is a ticket for unneeded complexity >> and I see reluctance to enter such business on mailing list. >> > I think there is value to have a rule whose filter is a subset of another > rule. In pictures, this: > > +-------------------------+ > |Filter 1 | > | +-------------+ | > | | Filter 2 | | > | | | | > | +-------------+ | > | | > +-------------------------+ > > Instead of this: > > +-------------------------+ > |Filter 1 | > | +-------------------------+ > | |XXXXXXXXXXXX Filter 2 | > | |XXXXXXXXXXXX | > | |XXXXXXXXXXXX | > | +-------------------------+ > | | > +-------------------------+ > > > A common example given is a where Filter 1 is broad and allows packets thru, > and Filter 2 defines a narrower set to be disallowed. Our charter says that our primary focus we should be on requests between applications and firewalls/NATs. Could you give an example of a concrete (non-management) application sending this kind of requests to a middlebox? Thank you, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de >> The other, security-policy issue is how access to rules >> with identical packet matching expressions is governed. Which is >> a different discussion. >> >> -Jiri > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Apr 15 09:50:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17455 for ; Mon, 15 Apr 2002 09:50:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA13175 for midcom-archive@odin.ietf.org; Mon, 15 Apr 2002 09:50:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13024; Mon, 15 Apr 2002 09:48:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12995 for ; Mon, 15 Apr 2002 09:48:00 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17320 for ; Mon, 15 Apr 2002 09:47:55 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g3FDkh856688; Mon, 15 Apr 2002 15:46:43 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA05985; Mon, 15 Apr 2002 15:45:48 +0200 Date: Mon, 15 Apr 2002 15:49:54 +0200 From: Juergen Quittek To: Tom-PT Taylor , "'Jiri Kuthan'" , "'Martin Stiemerling'" , Sanjoy Sen cc: midcom@ietf.org, Cedric Aoun Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Message-ID: <31280248.1018885794@[192.168.102.164]> In-Reply-To: <4D79C746863DD51197690002A52CDA0001E8A2E3@zcard0kc.ca.nortel.com> References: <4D79C746863DD51197690002A52CDA0001E8A2E3@zcard0kc.ca.nortel.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Hi Tom, --On 12 April 2002 08:51 -0400 Tom-PT Taylor wrote: > > I agree with your distinction between the issues of rule overlapping and access control. I do wonder if you are being too dogmatic on the matter of rule overlapping, and would beg for exceptions in two cases: > > -- the rules do not involve contradictory actions (e.g. both rules allow flows) > > -- the rules both come from the same Agent. > > Here is an example scenario in which I could see the possibility of rule overlapping: a rule is set up allowing any node inside to connect to a specific address outside. Then an Agent sets up a rule allowing connection from a specific inside address > to that outside address. In the process, the Agent receives an address binding to the mapped address at the Middlebox. Using the notation I have proposed earlier, the first rule is: > > Filter= { Source address: ANY, > Source port: ANY, > Source realm: , > Map address: ANY, > Map port: ANY, > Map realm: , > Destination address: , > Destination port: , > Destination realm: , > Protocol }, > > Action = Allow Maybe I'm wrong, but I consider this kind of rule to be out of scope of midcom. This colesction of wildcards looks like an administrative NAT configuration but not like something that an application requires. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > The second, more specific rule is: > > Filter= { Source address: , > Source port: , > Source realm: , > Map address: CHOOSE, > Map port: CHOOSE, > Map realm: , > Destination address: , > Destination port: , > Destination realm: }, > > Action = Allow > > In response to this second rule the Middlebox reports the bindings it has assigned for the CHOOSE entries. > > I can think of one or two arguments you may have against this sort of situation, but I don't know which particular arguments you would choose. So I'll see what you have to say. > > As for allowing an Agent to amend or contradict itself, I see this as a matter of convenience. It makes it easier to associate specific Policy Rules with specific application sessions, regardless of how they interact. If you disallow it, the > workaround is for the agent to combine everything into a single Policy Rule. This is OK provided that the Agent knows that it itself is the source of the overlap. > > -----Original Message----- > From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de] > Sent: Friday, April 12, 2002 5:30 AM > To: Taylor, Tom-PT [CAR:B800:EXCH]; 'Martin Stiemerling'; Sen, Sanjoy > [NGC:B692:EXCH] > Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] > Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content > > I think people mix up two issues: rule overlapping and access control. > > I argumented against rule overlapping -- I want to disallow rules > with different packet matching expressions with packets matching > both of them. Doing anything else is a ticket for unneeded complexity > and I see reluctance to enter such business on mailing list. > > The other, security-policy issue is how access to rules > with identical packet matching expressions is governed. Which is > a different discussion. > > -Jiri > > At 06:43 PM 4/5/2002, Tom-PT Taylor wrote: > >> Assuming that contradictions are possible (see my previous message), > > Please NO. > >> we should distinguish two cases: >> - a specific Agent contradicts a Policy Rule installed previously by that same Agent >> - a specific Agent contradicts a Policy Rule installed by another Agent. >> >> An underlying premise of our proposed semantics is that each Policy Rule (defined as a set of {Filter, Action} pairs with a specific Policy Rule Identifier) has one or more owners. That is, the Middlebox remembers the Agent(s) who installed those >> rules. > >> >> Whether more than one Agent should be able to work with the same Policy Rule is a matter for discussion, though I sense an inclination not to allow this. (But it seems to me that an Administrator should be able to audit all installed Policy Rules and >> deactivate any of them if need be.) On the other hand, I think it is accepted that different Policy Rules could overlap in their scope. So I'll concentrate my discussion on the case where a new Policy Rule is in conflict with a previously installed >> Policy Rule. > >> >> I would suggest a general approach to conflicts of this form: >> >> - If an Agent contradicts itself, the Middlebox denies the new Policy Rule Request. It returns an appropriate reason code and the Policy Rule Identifier of the rule which is in conflict. The Agent then has the information it needs to choose between >> modifying the already-existing rule to accommodate the new conditions or giving up on the new Policy Rule. > >> >> - If an Agent contradicts another Agent, Agent priorities come into play. I'm happy enough to allow only two priorities: Administrator and others, but I'm not sure we need to specify this, only that there exists a hierarchy of Agent priorities. The >> general rule is then that the Policy Rule installed by the higher priority agent prevails and the other one is rejected or deactivated as the case may be. Between equal-priority Agents, existing Policy Rules take priority over new ones. > >> >> One open question is what diagnostic information should be supplied when a Policy Rule is rejected or deactivated. I see the following possibilities: > >> >> (1) The Middlebox computes and returns a modified Policy Rule that would be consistent with the over-riding Policy Rule. > >> >> (2) The Middlebox returns the complete contents of the over-riding Policy Rule. >> (3) The Middlebox returns the (sub)set of {Filter, Action} pairs within the over-riding Policy Rule which are in conflict with the disallowed Policy Rule. > >> >> (4) The Middlebox returns a set of filters which describe the precise area of conflict with the over-riding Policy Rule. > >> >> I have a bit of a concern with privacy which inclines me to alternative (4). >> >> -----Original Message----- >> From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] >> Sent: Friday, April 05, 2002 9:57 AM >> To: Sen, Sanjoy [NGC:B692:EXCH] >> Cc: 'Jiri Kuthan'; Taylor, Tom-PT [CAR:B800:EXCH]; midcom@ietf.org; >> Aoun, Cedric [QPD:MA01:EXCH] >> Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content >> >> Sanjoy Sen wrote: >> >>> How will then the following requirement from Midcom requirements draft >>> be satisfied? >>> ***** >>> 2.2.11. >>> >>> It should be possible to define rulesets that contain a more spe- >>> cific filter spec than an overlapping ruleset. This should allow >>> agents to request actions for the subset that contradict those of >>> the overlapping set. >>> ***** >> >> > >> >>> Whether you want it or not, there would be overlapping rulesets because >>> the filterspec may overlap for different rulesets installed by >>> independent agents. The question - who wins when there're contradictory >> >>> actions is moot because the requirement above seems to suggest that we >>> need to allow contradictory behavior. >> >> The questions is, who will decide how to behave in such a case? There >> are so many combinations of firewall/NAT configurations which will make >> it difficult to define a stable behaviour, i.e. how to react with this >> overlapping set. Furthermore, the requirement starts with "should"... >> >> Martin >> -- >> Martin Stiemerling >> >> NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de >> IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Apr 15 09:59:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17863 for ; Mon, 15 Apr 2002 09:59:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA13794 for midcom-archive@odin.ietf.org; Mon, 15 Apr 2002 09:59:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13654; Mon, 15 Apr 2002 09:57:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13622 for ; Mon, 15 Apr 2002 09:57:47 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17761 for ; Mon, 15 Apr 2002 09:57:42 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g3FDtZ858054; Mon, 15 Apr 2002 15:55:35 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA06081; Mon, 15 Apr 2002 15:54:40 +0200 Date: Mon, 15 Apr 2002 15:58:47 +0200 From: Juergen Quittek To: Sanjoy Sen , Tom-PT Taylor , "'Jiri Kuthan'" , "'Martin Stiemerling'" cc: "'midcom@ietf.org'" , Cedric Aoun Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Message-ID: <31812784.1018886327@[192.168.102.164]> In-Reply-To: <933FADF5E673D411B8A30002A5608A0E01187A76@zrc2c012.us.nortel.com> References: <933FADF5E673D411B8A30002A5608A0E01187A76@zrc2c012.us.nortel.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Hi Sanjoy, --On 12 April 2002 12:20 -0500 Sanjoy Sen wrote: > > I support this as a good compromise. We should disallow contradictions > in overlapping rulesets (and resolve on a FCFS basis). But, we should > allow overlapping rulesets if there's no contradiction. Nice idea! But what for? Please give me an example application, which requires this and which is worth the effort. Handling overlapping rules properly increases the complexity of a midcom server implementation and I would like to know what for I would spend additional time on implementing this feature. Cheers, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de >> -----Original Message----- >> From: Taylor, Tom-PT [CAR:B800:EXCH] >> Sent: Friday, April 12, 2002 7:52 AM >> To: 'Jiri Kuthan'; 'Martin Stiemerling'; Sen, Sanjoy [NGC:B692:EXCH] >> Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] >> Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content >> >> >> I agree with your distinction between the issues of rule >> overlapping and access control. I do wonder if you are being >> too dogmatic on the matter of rule overlapping, and would beg >> for exceptions in two cases: >> >> -- the rules do not involve contradictory actions (e.g. >> both rules allow flows) >> >> -- the rules both come from the same Agent. >> >> Here is an example scenario in which I could see the >> possibility of rule overlapping: a rule is set up allowing >> any node inside to connect to a specific address outside. >> Then an Agent sets up a rule allowing connection from a >> specific inside address to that outside address. In the >> process, the Agent receives an address binding to the mapped >> address at the Middlebox. Using the notation I have proposed >> earlier, the first rule is: >> >> Filter= { Source address: ANY, >> Source port: ANY, >> Source realm: , >> Map address: ANY, >> Map port: ANY, >> Map realm: , >> Destination address: , >> Destination port: , >> Destination realm: , >> Protocol }, >> >> Action = Allow >> >> The second, more specific rule is: >> >> Filter= { Source address: , >> Source port: , >> Source realm: , >> Map address: CHOOSE, >> Map port: CHOOSE, >> Map realm: , >> Destination address: , >> Destination port: , >> Destination realm: }, >> >> Action = Allow >> >> In response to this second rule the Middlebox reports the >> bindings it has assigned for the CHOOSE entries. >> >> I can think of one or two arguments you may have against this >> sort of situation, but I don't know which particular >> arguments you would choose. So I'll see what you have to say. >> >> As for allowing an Agent to amend or contradict itself, I see >> this as a matter of convenience. It makes it easier to >> associate specific Policy Rules with specific application >> sessions, regardless of how they interact. If you disallow >> it, the workaround is for the agent to combine everything >> into a single Policy Rule. This is OK provided that the >> Agent knows that it itself is the source of the overlap. >> >> >> -----Original Message----- >> From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de] >> Sent: Friday, April 12, 2002 5:30 AM >> To: Taylor, Tom-PT [CAR:B800:EXCH]; 'Martin Stiemerling'; Sen, Sanjoy >> [NGC:B692:EXCH] >> Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] >> Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content >> >> >> I think people mix up two issues: rule overlapping and access control. >> >> I argumented against rule overlapping -- I want to disallow rules >> with different packet matching expressions with packets matching >> both of them. Doing anything else is a ticket for unneeded complexity >> and I see reluctance to enter such business on mailing list. >> >> The other, security-policy issue is how access to rules >> with identical packet matching expressions is governed. Which is >> a different discussion. >> >> -Jiri >> >> At 06:43 PM 4/5/2002, Tom-PT Taylor wrote: >> >> > Assuming that contradictions are possible (see my previous message), >> >> Please NO. >> >> > we should distinguish two cases: >> > - a specific Agent contradicts a Policy Rule installed >> previously by that same Agent >> > - a specific Agent contradicts a Policy Rule installed by >> another Agent. >> > >> > An underlying premise of our proposed semantics is that each >> Policy Rule (defined as a set of {Filter, Action} pairs with >> a specific Policy Rule Identifier) has one or more owners. >> That is, the Middlebox remembers the Agent(s) who installed >> those rules. >> > >> > Whether more than one Agent should be able to work with the >> same Policy Rule is a matter for discussion, though I sense >> an inclination not to allow this. (But it seems to me that >> an Administrator should be able to audit all installed Policy >> Rules and deactivate any of them if need be.) On the other >> hand, I think it is accepted that different Policy Rules >> could overlap in their scope. So I'll concentrate my >> discussion on the case where a new Policy Rule is in conflict >> with a previously installed Policy Rule. >> > >> > I would suggest a general approach to conflicts of this form: >> > >> > - If an Agent contradicts itself, the Middlebox denies the >> new Policy Rule Request. It returns an appropriate reason >> code and the Policy Rule Identifier of the rule which is in >> conflict. The Agent then has the information it needs to >> choose between modifying the already-existing rule to >> accommodate the new conditions or giving up on the new Policy Rule. >> > >> > - If an Agent contradicts another Agent, Agent priorities >> come into play. I'm happy enough to allow only two >> priorities: Administrator and others, but I'm not sure we >> need to specify this, only that there exists a hierarchy of >> Agent priorities. The general rule is then that the Policy >> Rule installed by the higher priority agent prevails and the >> other one is rejected or deactivated as the case may be. >> Between equal-priority Agents, existing Policy Rules take >> priority over new ones. >> > >> > One open question is what diagnostic information should be >> supplied when a Policy Rule is rejected or deactivated. I >> see the following possibilities: >> > >> > (1) The Middlebox computes and returns a modified Policy >> Rule that would be consistent with the over-riding Policy Rule. >> > >> > (2) The Middlebox returns the complete contents of the >> over-riding Policy Rule. >> > (3) The Middlebox returns the (sub)set of {Filter, Action} >> pairs within the over-riding Policy Rule which are in >> conflict with the disallowed Policy Rule. >> > >> > (4) The Middlebox returns a set of filters which describe >> the precise area of conflict with the over-riding Policy Rule. >> > >> > I have a bit of a concern with privacy which inclines me to >> alternative (4). >> > >> > -----Original Message----- >> > From: Martin Stiemerling >> [mailto:Martin.Stiemer > ling@ccrle.nec.de] >> Sent: Friday, April 05, 2002 9:57 AM >> To: Sen, Sanjoy [NGC:B692:EXCH] >> Cc: 'Jiri Kuthan'; Taylor, Tom-PT [CAR:B800:EXCH]; midcom@ietf.org; >> Aoun, Cedric [QPD:MA01:EXCH] >> Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content >> >> Sanjoy Sen wrote: >> >>> How will then the following requirement from Midcom requirements draft >>> be satisfied? >>> ***** >>> 2.2.11. >>> >>> It should be possible to define rulesets that contain a more spe- >>> cific filter spec than an overlapping ruleset. This should allow >>> agents to request actions for the subset that contradict those of >>> the overlapping set. >>> ***** >> >> > >> >>> Whether you want it or not, there would be overlapping rulesets because >>> the filterspec may overlap for different rulesets installed by >>> independent agents. The question - who wins when there're contradictory >> >>> actions is moot because the requirement above seems to suggest that we >>> need to allow contradictory behavior. >> >> The questions is, who will decide how to behave in such a case? There >> are so many combinations of firewall/NAT configurations which will make >> it difficult to define a stable behaviour, i.e. how to react with this >> overlapping set. Furthermore, the requirement starts with "should"... >> >> Martin >> -- >> Martin Stiemerling >> >> NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de >> IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Apr 15 10:02:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17927 for ; Mon, 15 Apr 2002 10:02:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA14339 for midcom-archive@odin.ietf.org; Mon, 15 Apr 2002 10:02:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13956; Mon, 15 Apr 2002 10:00:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13915 for ; Mon, 15 Apr 2002 10:00:17 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17885 for ; Mon, 15 Apr 2002 10:00:12 -0400 (EDT) Received: from airborne.cisco.com (IDENT:mirapoint@airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3FDxi87024172 for ; Mon, 15 Apr 2002 06:59:44 -0700 (PDT) Received: from SBRIM-W2K (rtp-vpn2-302.cisco.com [10.82.241.46]) by airborne.cisco.com (Mirapoint) with SMTP id AAZ88329; Mon, 15 Apr 2002 06:59:31 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Mon, 15 Apr 2002 09:59:42 -0400 Date: Mon, 15 Apr 2002 09:59:42 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content Message-ID: <20020415095942.D1968@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <4D79C746863DD51197690002A52CDA0001E8A2F8@zcard0kc.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4D79C746863DD51197690002A52CDA0001E8A2F8@zcard0kc.ca.nortel.com>; from taylor@nortelnetworks.com on Sun, Apr 14, 2002 at 10:53:41AM -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Sun, Apr 14, 2002 10:53:41AM -0400, Tom-PT Taylor wrote: > Let me propose this to ensure determinsitic behaviour: > > (1) The Middlebox must support a queue model of rules. > > (2) New entries can be added either at the head of the queue (processed > first when looking for a match) or at the tail of a queue (processed last > when looking for a match). > > (3) Existing entries can be deleted from anywhere in the queue. What is the engineering reason for this ordering? I mean, yes, this would make behavior deterministic, but does it make the middlebox do what you want? _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Apr 15 15:28:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03889 for ; Mon, 15 Apr 2002 15:28:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA07793 for midcom-archive@odin.ietf.org; Mon, 15 Apr 2002 15:28:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07656; Mon, 15 Apr 2002 15:25:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07625 for ; Mon, 15 Apr 2002 15:25:19 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03774 for ; Mon, 15 Apr 2002 15:25:15 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FJOkO15191 for ; Mon, 15 Apr 2002 15:24:46 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <2WJA3RAL>; Mon, 15 Apr 2002 15:24:46 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A305@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Scott Brim'" , midcom@ietf.org Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Mon, 15 Apr 2002 15:24:46 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I agree -- it doesn't guarantee you anything unless you know what else is in the queue. On the other hand, giving that information to every agent that asks for it means privacy of individual communications is lost. I'm just trying to salvage something from the description of operation Andrew Molitor gave us. -----Original Message----- From: Scott Brim [mailto:swb@employees.org] Sent: Monday, April 15, 2002 10:00 AM To: midcom@ietf.org Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content On Sun, Apr 14, 2002 10:53:41AM -0400, Tom-PT Taylor wrote: > Let me propose this to ensure determinsitic behaviour: > > (1) The Middlebox must support a queue model of rules. > > (2) New entries can be added either at the head of the queue (processed > first when looking for a match) or at the tail of a queue (processed last > when looking for a match). > > (3) Existing entries can be deleted from anywhere in the queue. What is the engineering reason for this ordering? I mean, yes, this would make behavior deterministic, but does it make the middlebox do what you want? _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Apr 17 10:00:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18053 for ; Wed, 17 Apr 2002 10:00:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA11005 for midcom-archive@odin.ietf.org; Wed, 17 Apr 2002 10:00:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10929; Wed, 17 Apr 2002 09:57:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10896 for ; Wed, 17 Apr 2002 09:57:09 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17970 for ; Wed, 17 Apr 2002 09:57:05 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3HDuah01547 for ; Wed, 17 Apr 2002 09:56:36 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Apr 2002 09:56:37 -0400 Message-ID: <4D79C746863DD51197690002A52CDA00023C6A8C@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: Juergen Quittek Cc: midcom@ietf.org, "Cedric Aoun" Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Wed, 17 Apr 2002 09:56:37 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I agree that the double wildcarding goes a bit far, but most of the scenarios in Christian's document require wildcarding at one end or the other. -----Original Message----- From: Juergen Quittek [mailto:quittek@ccrle.nec.de] Sent: Monday, April 15, 2002 9:50 AM To: Taylor, Tom-PT [CAR:B800:EXCH]; 'Jiri Kuthan'; 'Martin Stiemerling'; Sen, Sanjoy [NGC:B692:EXCH] Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Hi Tom, --On 12 April 2002 08:51 -0400 Tom-PT Taylor wrote: > > I agree with your distinction between the issues of rule overlapping and access control. I do wonder if you are being too dogmatic on the matter of rule overlapping, and would beg for exceptions in two cases: > > -- the rules do not involve contradictory actions (e.g. both rules allow flows) > > -- the rules both come from the same Agent. > > Here is an example scenario in which I could see the possibility of rule overlapping: a rule is set up allowing any node inside to connect to a specific address outside. Then an Agent sets up a rule allowing connection from a specific inside address > to that outside address. In the process, the Agent receives an address binding to the mapped address at the Middlebox. Using the notation I have proposed earlier, the first rule is: > > Filter= { Source address: ANY, > Source port: ANY, > Source realm: , > Map address: ANY, > Map port: ANY, > Map realm: , > Destination address: , > Destination port: , > Destination realm: , > Protocol }, > > Action = Allow Maybe I'm wrong, but I consider this kind of rule to be out of scope of midcom. This colesction of wildcards looks like an administrative NAT configuration but not like something that an application requires. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > The second, more specific rule is: > > Filter= { Source address: , > Source port: , > Source realm: , > Map address: CHOOSE, > Map port: CHOOSE, > Map realm: , > Destination address: , > Destination port: , > Destination realm: }, > > Action = Allow > > In response to this second rule the Middlebox reports the bindings it has assigned for the CHOOSE entries. > > I can think of one or two arguments you may have against this sort of situation, but I don't know which particular arguments you would choose. So I'll see what you have to say. > > As for allowing an Agent to amend or contradict itself, I see this as a matter of convenience. It makes it easier to associate specific Policy Rules with specific application sessions, regardless of how they interact. If you disallow it, the > workaround is for the agent to combine everything into a single Policy Rule. This is OK provided that the Agent knows that it itself is the source of the overlap. > > -----Original Message----- > From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de] > Sent: Friday, April 12, 2002 5:30 AM > To: Taylor, Tom-PT [CAR:B800:EXCH]; 'Martin Stiemerling'; Sen, Sanjoy > [NGC:B692:EXCH] > Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] > Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content > > I think people mix up two issues: rule overlapping and access control. > > I argumented against rule overlapping -- I want to disallow rules > with different packet matching expressions with packets matching > both of them. Doing anything else is a ticket for unneeded complexity > and I see reluctance to enter such business on mailing list. > > The other, security-policy issue is how access to rules > with identical packet matching expressions is governed. Which is > a different discussion. > > -Jiri > > At 06:43 PM 4/5/2002, Tom-PT Taylor wrote: > >> Assuming that contradictions are possible (see my previous message), > > Please NO. > >> we should distinguish two cases: >> - a specific Agent contradicts a Policy Rule installed previously by that same Agent >> - a specific Agent contradicts a Policy Rule installed by another Agent. >> >> An underlying premise of our proposed semantics is that each Policy Rule (defined as a set of {Filter, Action} pairs with a specific Policy Rule Identifier) has one or more owners. That is, the Middlebox remembers the Agent(s) who installed those >> rules. > >> >> Whether more than one Agent should be able to work with the same Policy Rule is a matter for discussion, though I sense an inclination not to allow this. (But it seems to me that an Administrator should be able to audit all installed Policy Rules and >> deactivate any of them if need be.) On the other hand, I think it is accepted that different Policy Rules could overlap in their scope. So I'll concentrate my discussion on the case where a new Policy Rule is in conflict with a previously installed >> Policy Rule. > >> >> I would suggest a general approach to conflicts of this form: >> >> - If an Agent contradicts itself, the Middlebox denies the new Policy Rule Request. It returns an appropriate reason code and the Policy Rule Identifier of the rule which is in conflict. The Agent then has the information it needs to choose between >> modifying the already-existing rule to accommodate the new conditions or giving up on the new Policy Rule. > >> >> - If an Agent contradicts another Agent, Agent priorities come into play. I'm happy enough to allow only two priorities: Administrator and others, but I'm not sure we need to specify this, only that there exists a hierarchy of Agent priorities. The >> general rule is then that the Policy Rule installed by the higher priority agent prevails and the other one is rejected or deactivated as the case may be. Between equal-priority Agents, existing Policy Rules take priority over new ones. > >> >> One open question is what diagnostic information should be supplied when a Policy Rule is rejected or deactivated. I see the following possibilities: > >> >> (1) The Middlebox computes and returns a modified Policy Rule that would be consistent with the over-riding Policy Rule. > >> >> (2) The Middlebox returns the complete contents of the over-riding Policy Rule. >> (3) The Middlebox returns the (sub)set of {Filter, Action} pairs within the over-riding Policy Rule which are in conflict with the disallowed Policy Rule. > >> >> (4) The Middlebox returns a set of filters which describe the precise area of conflict with the over-riding Policy Rule. > >> >> I have a bit of a concern with privacy which inclines me to alternative (4). >> >> -----Original Message----- >> From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec .de] >> Sent: Friday, April 05, 2002 9:57 AM >> To: Sen, Sanjoy [NGC:B692:EXCH] >> Cc: 'Jiri Kuthan'; Taylor, Tom-PT [CAR:B800:EXCH]; midcom@ietf.org; >> Aoun, Cedric [QPD:MA01:EXCH] >> Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content >> >> Sanjoy Sen wrote: >> >>> How will then the following requirement from Midcom requirements draft >>> be satisfied? >>> ***** >>> 2.2.11. >>> >>> It should be possible to define rulesets that contain a more spe- >>> cific filter spec than an overlapping ruleset. This should allow >>> agents to request actions for the subset that contradict those of >>> the overlapping set. >>> ***** >> >> > >> >>> Whether you want it or not, there would be overlapping rulesets because >>> the filterspec may overlap for different rulesets installed by >>> independent agents. The question - who wins when there're contradictory >> >>> actions is moot because the requirement above seems to suggest that we >>> need to allow contradictory behavior. >> >> The questions is, who will decide how to behave in such a case? There >> are so many combinations of firewall/NAT configurations which will make >> it difficult to define a stable behaviour, i.e. how to react with this >> overlapping set. Furthermore, the requirement starts with "should"... >> >> Martin >> -- >> Martin Stiemerling >> >> NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de >> IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Apr 17 11:23:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22828 for ; Wed, 17 Apr 2002 11:23:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA27660 for midcom-archive@odin.ietf.org; Wed, 17 Apr 2002 11:23:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27366; Wed, 17 Apr 2002 11:21:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27334 for ; Wed, 17 Apr 2002 11:21:03 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22745 for ; Wed, 17 Apr 2002 11:20:57 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g3HFKL875013; Wed, 17 Apr 2002 17:20:21 +0200 (CEST) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA02965; Wed, 17 Apr 2002 17:19:20 +0200 Received: from ccrle.nec.de (elgar.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id F0CCF1B06F; Wed, 17 Apr 2002 17:19:18 +0200 (CEST) Message-ID: <3CBD927A.8050607@ccrle.nec.de> Date: Wed, 17 Apr 2002 17:19:22 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20020305 X-Accept-Language: en-us MIME-Version: 1.0 To: Tom-PT Taylor Cc: midcom@ietf.org Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content References: <4D79C746863DD51197690002A52CDA00023C6A8C@zcard0kc.ca.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Tom-PT Taylor wrote: > I agree that the double wildcarding goes a bit far, but most of the > scenarios in Christian's document require wildcarding at one end or the > other. Some wildcarding will be required for sure, but setting the IP address and the port number to wildcard is too much wildcarding, i.e. especially the sys admins won't like this. A good wildcarding situation would be that the IP address is known, but not the specific port number. Martin > > -----Original Message----- > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > Sent: Monday, April 15, 2002 9:50 AM > To: Taylor, Tom-PT [CAR:B800:EXCH]; 'Jiri Kuthan'; 'Martin Stiemerling'; > Sen, Sanjoy [NGC:B692:EXCH] > Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] > Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content > > > Hi Tom, > > --On 12 April 2002 08:51 -0400 Tom-PT Taylor > wrote: > > >>I agree with your distinction between the issues of rule overlapping and >> > access control. I do wonder if you are being too dogmatic on the matter of > rule overlapping, and would beg for exceptions in two cases: > >> -- the rules do not involve contradictory actions (e.g. both rules allow >> > flows) > >> -- the rules both come from the same Agent. >> >>Here is an example scenario in which I could see the possibility of rule >> > overlapping: a rule is set up allowing any node inside to connect to a > specific address outside. Then an Agent sets up a rule allowing connection > from a specific inside address > >>to that outside address. In the process, the Agent receives an address >> > binding to the mapped address at the Middlebox. Using the notation I have > proposed earlier, the first rule is: > >>Filter= { Source address: ANY, >> Source port: ANY, >> Source realm: , >> Map address: ANY, >> Map port: ANY, >> Map realm: , >> Destination address: , >> Destination port: , >> Destination realm: , >> Protocol }, >> >>Action = Allow >> > > Maybe I'm wrong, but I consider this kind of rule to be out of scope of > midcom. This colesction of wildcards looks like an administrative NAT > configuration but not like something that an application requires. > > Juergen > -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Apr 17 12:33:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25822 for ; Wed, 17 Apr 2002 12:33:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27953 for midcom-archive@odin.ietf.org; Wed, 17 Apr 2002 12:33:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27011; Wed, 17 Apr 2002 12:28:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26980 for ; Wed, 17 Apr 2002 12:28:02 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25637 for ; Wed, 17 Apr 2002 12:27:54 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3HGRQK04137 for ; Wed, 17 Apr 2002 12:27:26 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Apr 2002 12:27:28 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A313@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Martin Stiemerling'" Cc: midcom@ietf.org Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Wed, 17 Apr 2002 12:27:24 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Unfortunately the IP address is NOT known in many of those scenarios. -----Original Message----- From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] Sent: Wednesday, April 17, 2002 11:19 AM To: Taylor, Tom-PT [CAR:B800:EXCH] Cc: midcom@ietf.org Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content Tom-PT Taylor wrote: > I agree that the double wildcarding goes a bit far, but most of the > scenarios in Christian's document require wildcarding at one end or the > other. Some wildcarding will be required for sure, but setting the IP address and the port number to wildcard is too much wildcarding, i.e. especially the sys admins won't like this. A good wildcarding situation would be that the IP address is known, but not the specific port number. Martin > > -----Original Message----- > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > Sent: Monday, April 15, 2002 9:50 AM > To: Taylor, Tom-PT [CAR:B800:EXCH]; 'Jiri Kuthan'; 'Martin Stiemerling'; > Sen, Sanjoy [NGC:B692:EXCH] > Cc: midcom@ietf.org; Aoun, Cedric [QPD:MA01:EXCH] > Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content > > > Hi Tom, > > --On 12 April 2002 08:51 -0400 Tom-PT Taylor > wrote: > > >>I agree with your distinction between the issues of rule overlapping and >> > access control. I do wonder if you are being too dogmatic on the matter of > rule overlapping, and would beg for exceptions in two cases: > >> -- the rules do not involve contradictory actions (e.g. both rules allow >> > flows) > >> -- the rules both come from the same Agent. >> >>Here is an example scenario in which I could see the possibility of rule >> > overlapping: a rule is set up allowing any node inside to connect to a > specific address outside. Then an Agent sets up a rule allowing connection > from a specific inside address > >>to that outside address. In the process, the Agent receives an address >> > binding to the mapped address at the Middlebox. Using the notation I have > proposed earlier, the first rule is: > >>Filter= { Source address: ANY, >> Source port: ANY, >> Source realm: , >> Map address: ANY, >> Map port: ANY, >> Map realm: , >> Destination address: , >> Destination port: , >> Destination realm: , >> Protocol }, >> >>Action = Allow >> > > Maybe I'm wrong, but I consider this kind of rule to be out of scope of > midcom. This colesction of wildcards looks like an administrative NAT > configuration but not like something that an application requires. > > Juergen > -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Wed Apr 17 14:49:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01414 for ; Wed, 17 Apr 2002 14:49:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA08053 for midcom-archive@odin.ietf.org; Wed, 17 Apr 2002 14:49:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07791; Wed, 17 Apr 2002 14:45:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07762 for ; Wed, 17 Apr 2002 14:45:13 -0400 (EDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01268 for ; Wed, 17 Apr 2002 14:45:09 -0400 (EDT) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.148]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 17 Apr 2002 11:44:40 -0700 Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 17 Apr 2002 11:44:40 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 17 Apr 2002 11:44:41 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 17 Apr 2002 11:44:40 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Wed, 17 Apr 2002 11:41:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content Date: Wed, 17 Apr 2002 11:41:03 -0700 Message-ID: Thread-Topic: [midcom] MIDCOM SEmantics: Policy Rule Content Thread-Index: AcHmNoHx6c7SASfFS/C8LFeXEmOCsgACRCVQ From: "Christian Huitema" To: "Martin Stiemerling" , "Tom-PT Taylor" Cc: X-OriginalArrivalTime: 17 Apr 2002 18:41:04.0532 (UTC) FILETIME=[6DF70D40:01C1E63F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA07763 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit > > I agree that the double wildcarding goes a bit far, but most of the > > scenarios in Christian's document require wildcarding at one end or the > > other. > > Some wildcarding will be required for sure, but setting the IP address > and the port number to wildcard is too much wildcarding, i.e. especially > the sys admins won't like this. > A good wildcarding situation would be that the IP address is known, but > not the specific port number. Uh, why are we debating that now? We spent a year writing a requirements document, and debating such fines points as wildcarding. This is it, and this is the standard against which various proposals should be metered. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 18 04:22:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28773 for ; Thu, 18 Apr 2002 04:22:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA06264 for midcom-archive@odin.ietf.org; Thu, 18 Apr 2002 04:23:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06072; Thu, 18 Apr 2002 04:19:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06018 for ; Thu, 18 Apr 2002 04:19:50 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28728 for ; Thu, 18 Apr 2002 04:19:46 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g3I8J1803580; Thu, 18 Apr 2002 10:19:01 +0200 (CEST) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA11190; Thu, 18 Apr 2002 10:17:57 +0200 Received: from ccrle.nec.de (elgar.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id E9DCDE123; Thu, 18 Apr 2002 10:17:56 +0200 (CEST) Message-ID: <3CBE813B.4050003@ccrle.nec.de> Date: Thu, 18 Apr 2002 10:18:03 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20020305 X-Accept-Language: en-us MIME-Version: 1.0 To: Christian Huitema Cc: Tom-PT Taylor , midcom@ietf.org Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit > > > Uh, why are we debating that now? We spent a year writing a requirements > document, and debating such fines points as wildcarding. This is it, and > this is the standard against which various proposals should be metered. What's the point? I've just mentioned that too much wildcarding won't be used in real life and not wether wildcarding is useful at all or not. Martin > > -- Christian Huitema > -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 18 04:28:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28883 for ; Thu, 18 Apr 2002 04:28:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA06855 for midcom-archive@odin.ietf.org; Thu, 18 Apr 2002 04:28:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06630; Thu, 18 Apr 2002 04:26:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06603 for ; Thu, 18 Apr 2002 04:26:04 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28841 for ; Thu, 18 Apr 2002 04:25:59 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g3I8PS803979; Thu, 18 Apr 2002 10:25:28 +0200 (CEST) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA11244; Thu, 18 Apr 2002 10:24:24 +0200 Received: from ccrle.nec.de (elgar.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 2612041738; Thu, 18 Apr 2002 10:24:24 +0200 (CEST) Message-ID: <3CBE82BE.4010205@ccrle.nec.de> Date: Thu, 18 Apr 2002 10:24:30 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20020305 X-Accept-Language: en-us MIME-Version: 1.0 To: Tom-PT Taylor Cc: midcom@ietf.org Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content References: <4D79C746863DD51197690002A52CDA0001E8A313@zcard0kc.ca.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Tom-PT Taylor wrote: > Unfortunately the IP address is NOT known in many of those scenarios. > Yes and no. The scenarios in section 2.1 won't be considered anymore, as far as I know. Because they belong more to the middle box management and not to open dynamically pin holes. In some applications the IP address isn't really know, e.g. SIP. You know only the listing part (address + port number) of each participant, the sending IP address + port number is free too choose. But in 99.999 % of the IP telephony cases I would assume that the IP address of the sending part has the same IP address as the receiving part. With this information you know the IP address. Martin _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Apr 19 07:44:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16553 for ; Fri, 19 Apr 2002 07:44:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA03998 for midcom-archive@odin.ietf.org; Fri, 19 Apr 2002 07:44:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03891; Fri, 19 Apr 2002 07:41:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03859 for ; Fri, 19 Apr 2002 07:41:27 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16524 for ; Fri, 19 Apr 2002 07:41:25 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3JBeui20825 for ; Fri, 19 Apr 2002 06:40:56 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2Y3TXK5Y>; Fri, 19 Apr 2002 06:40:58 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A03DE39FA@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'midcom@ietf.org'" Date: Fri, 19 Apr 2002 06:40:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E797.12C828B0" Subject: [midcom] Reminder: Deadline for initial Protocol Evaluation Documents is T ODAY - April 19th Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E797.12C828B0 Content-Type: text/plain; charset="iso-8859-1" Hi, Just a reminder that the deadline for the individual protocol evaluation documents is today. Allowing time for the drafts to get through the queue, open WG discussion of the drafts should begin by Monday, April 22nd. ---------------------------------------------------------------------------- -------------- As a reminder, the timeline for these contributions is: April 19th Final cutoff for specific protocol drafts. * The mandatory sections for this document are outlined in section 4.1 of the template at: http://www.obsidian97.com/draft-midcom-protocol-eval-template.txt April 19th- May 3rd Mailing list discussion of specific protocol drafts, allowing authors to incorporate WG feedback into their contribution to improve comparison and add completeness. May 10th Deadline for any updates to protocol drafts. Regards, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 ------_=_NextPart_001_01C1E797.12C828B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Reminder: Deadline for initial Protocol Evaluation Documents is = TODAY - April 19th

Hi,

Just a  reminder that the deadline for the = individual protocol evaluation documents is today.
Allowing time for the drafts to get through the = queue, open WG discussion of the drafts should begin by Monday, April = 22nd.

---------------------------------------------------------------= ---------------------------

As a reminder, the timeline for these contributions = is:
 
April 19th      Final = cutoff for specific protocol drafts.
          &nb= sp;    *  The mandatory sections for this document = are
          &nb= sp;       outlined in section 4.1 of = the     
          &nb= sp;       template at:
http://www.obsidian97.com/draft-midcom-protocol-eval-t= emplate.txt

April 19th- May 3rd     Mailing = list discussion of specific
          &nb= sp;           &nb= sp; protocol drafts, allowing authors to
          &nb= sp;           &nb= sp; incorporate WG feedback into their 
          &nb= sp;           &nb= sp; contribution to improve comparison and
          &nb= sp;           &nb= sp; add completeness.

May 10th        = Deadline for any updates to protocol drafts.


Regards,
Mary H. Barnes
mbarnes@nortelnetworks.com
972-684-5432
Wireless 817-703-4806

------_=_NextPart_001_01C1E797.12C828B0-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 23 08:28:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14283 for ; Tue, 23 Apr 2002 08:28:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA25497 for midcom-archive@odin.ietf.org; Tue, 23 Apr 2002 08:28:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA25351; Tue, 23 Apr 2002 08:26:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18734 for ; Tue, 23 Apr 2002 07:13:41 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11788; Tue, 23 Apr 2002 07:13:36 -0400 (EDT) Message-Id: <200204231113.HAA11788@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 23 Apr 2002 07:13:35 -0400 Subject: [midcom] I-D ACTION:draft-aoun-midcom-cops-01.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : COPS applicability as the MIDCOM protocol Author(s) : C. Aoun et al. Filename : draft-aoun-midcom-cops-01.txt Pages : 12 Date : 22-Apr-02 This draft discusses the applicability of the COPS protocol as the MIDCOM protocol, in the context of the current protocol evaluations within the MIDCOM working group. It discusses the architectural similarities between COPS and Midcom and how COPS meets most of the MIDCOM protocol requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-aoun-midcom-cops-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-aoun-midcom-cops-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-aoun-midcom-cops-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020422135209.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-aoun-midcom-cops-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-aoun-midcom-cops-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020422135209.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 23 08:28:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14292 for ; Tue, 23 Apr 2002 08:28:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA25508 for midcom-archive@odin.ietf.org; Tue, 23 Apr 2002 08:28:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA25306; Tue, 23 Apr 2002 08:26:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18799 for ; Tue, 23 Apr 2002 07:14:01 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11848; Tue, 23 Apr 2002 07:13:53 -0400 (EDT) Message-Id: <200204231113.HAA11848@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 23 Apr 2002 07:13:52 -0400 Subject: [midcom] I-D ACTION:draft-renkel-rsip-midcom-eval-00.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Evaluation of RSIP against MIDCOM requirements Author(s) : J. Renkel Filename : draft-renkel-rsip-midcom-eval-00.txt Pages : 12 Date : 22-Apr-02 This document provides an evaluation of the RSIP (Realm Specific IP) framework and protocol against the evaluation criteria provided by the MIDCOM working group for the evaluation of middle box control protocols. RSIP is defined in experimental RFCs 3102 (Realm Specific IP: Framework) [3] and 3103 (Realm Specific IP: Protocol Specification) [4]; see also RFCs 3104 (RSIP Support for End-to-end IPsec) [5] and 3105 (Finding an RSIP Server with SLP) [6] for more information on RSIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-renkel-rsip-midcom-eval-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-renkel-rsip-midcom-eval-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-renkel-rsip-midcom-eval-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020422135241.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-renkel-rsip-midcom-eval-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-renkel-rsip-midcom-eval-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020422135241.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 23 08:28:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14317 for ; Tue, 23 Apr 2002 08:28:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA25522 for midcom-archive@odin.ietf.org; Tue, 23 Apr 2002 08:28:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA25336; Tue, 23 Apr 2002 08:26:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18761 for ; Tue, 23 Apr 2002 07:13:52 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11827; Tue, 23 Apr 2002 07:13:47 -0400 (EDT) Message-Id: <200204231113.HAA11827@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 23 Apr 2002 07:13:47 -0400 Subject: [midcom] I-D ACTION:draft-taylor-midcom-diameter-eval-00.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Evaluation Of DIAMETER Against MIDCOM Requirements Author(s) : T. Taylor Filename : draft-taylor-midcom-diameter-eval-00.txt Pages : 7 Date : 22-Apr-02 This document is submitted as part of the Midcom protocol selection process. It evaluates the suitability of the Diameter protocol as a transport for Midcom. The general conclusions are: . the Diameter architecture may be too heavy for the Midcom application, although this is a matter for discussion. It is clear in any event that much of the Diameter base is not needed; . a new application extension to Diameter would have to be defined to meet Midcom's requirements; . with these reservations, the protocol is a good fit to Midcom requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-taylor-midcom-diameter-eval-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-taylor-midcom-diameter-eval-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-taylor-midcom-diameter-eval-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020422135231.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-taylor-midcom-diameter-eval-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-taylor-midcom-diameter-eval-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020422135231.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 23 08:28:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14279 for ; Tue, 23 Apr 2002 08:28:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA25483 for midcom-archive@odin.ietf.org; Tue, 23 Apr 2002 08:28:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA25379; Tue, 23 Apr 2002 08:26:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA01225 for ; Tue, 23 Apr 2002 02:08:39 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07248 for ; Tue, 23 Apr 2002 02:08:36 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g3N688H23789 for ; Tue, 23 Apr 2002 02:08:08 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Apr 2002 01:08:03 -0500 Message-ID: <70565611B164D511957A001083FCDD5601870249@va02.va.neustar.com> From: "Peterson, Jon" To: "'midcom@ietf.org'" Subject: RE: [midcom] Working group last call - STUN (security) Date: Tue, 23 Apr 2002 01:07:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I have a long (and belated) comment on STUN's security - I apologize in advance for raising it only now, and for the fact that this particular point was hashed out way back during the pre-midcom design team. Specifically, I am concerned that CMS is a relatively heavyweight security system to implement. For the most part, these concerns relate to the use of an asymmetric key messaging system (including certificates) with a such a low-level protocol. The general ASN.1 protocol overhead, X.509 certificate verification (including maintaining root certs on the client, etc), and the extra TCP RTT required to download certificate chains from a server are a relatively high cost to pay. In Minneapolis, Jonathan suggested that implementing CMS would require 10-20 times the amount of code/effort that STUN itself would necessitate. CMS might not be prohibitive for some applications, such as SIP, which have an incentive to implement CMS already for S/MIME. However, I'd like to believe that STUN has broader applicability than SIP, and that the comparative complexity of the security implementation is therefore a cause for concern. I fear mandating CMS might either limit the deployment of STUN or limit the number of implementations that include STUN's security mechanism - both of which are bad. Some of the things that make me think CMS might not be the best fit are: 1) Certificate usage doesn't jibe well with the rest of the mechanism today; so much so that switching to TCP for the certificate transport RTT is recommended - it certainly wouldn't be ideal to require STUN entities to implement TCP. One might recommend using CMS without certificates (just public keys), but then its authentication story wouldn't be much more powerful than using shared secrets. As far as I can tell from the draft, and my conversations with some of the authors, I suspect that each of the various ways in which a client might discover a STUN server could also provide a means for a secret symmetric key to be shared with the client. So for example, if the client is pre-configured with the domain of a STUN server, it could also be pre-configured with a shared secret at that time. Or if the STUN server were discovered dynamically (say, on some kind of public matching service that tracked STUN servers), a shared secret could be passed to the client by such a matching service at the same time as the STUN server's address - this assumes that transmitting the secret would require about the same amount of security as transmitting the domain of the STUN server, which doesn't immediately sound unreasonable. For example, protocols like SIP might pass back a STUN server domain and accompanying secret in the application layer (relying on their own security mechanisms to shield this information from eavesdroppers). I would suggest that abandonning the complexities of CMS more than compensates for any trouble associated with learning shared secrets. 2) CMS really is pretty heavyweight, and it contains a lot of material that is superfluous to STUN. Here follows the ASN.1 (yes, and having to do ASN.1 seems a little more annoying if you aren't already doing X.509) of the CMS SignedData message (to which the CMS-SIGNED-DATA attribute in midcom-stun-00 is "exactly equal"): SignedData ::= SEQUENCE { version CMSVersion, digestAlgorithms DigestAlgorithmIdentifiers, encapContentInfo EncapsulatedContentInfo, certificates [0] IMPLICIT CertificateSet OPTIONAL, crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, signerInfos SignerInfos } Although half of these are optional (including, for STUN, the EncapsulatedContentInfo, which should be omitted in favor of an external signature), there is still a lot of unnecessary and redundant material here in compound objects. For example, SignerInfo above breaks down to: SignerInfo ::= SEQUENCE { version CMSVersion, sid SignerIdentifier, digestAlgorithm DigestAlgorithmIdentifier, signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, signatureAlgorithm SignatureAlgorithmIdentifier, signature SignatureValue, unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } Personally, I don't think STUN needs to identify the Digest algorithm at all in the message - I think we could safely assume just one (MD5) and save ourselves a few bytes. Similarly, all of the optional certificate-based material above is unnecessary if you believe the shared secret based approach described above is sufficient. We also don't need support for multiple signers of the data (since only one STUN server is involved with the generation and securing of a response). Filler material like versioning on the SignedData is also probably unnecessary for STUN (though STUN should probably have its own version field - but that's a separate issue). I think STUN should use a much leaner, more stripped-down mechanism that delivers only the security properties it needs. 3) Confidentiality doesn't seem useful for STUN, and one of the primary reasons to use CMS is that it can provide confidentiality. That suggests that a lot of the baseline CMS functionality (all of the EnvelopedData message, for starters) is unnecessary. On the one hand, this could merely suggest that a scaled-down profile of CMS should be built for STUN that uses minimal SignedData only, but on the other hand it further shows that CMS has a lot of versatility that STUN doesn't need, and that we might be able to get away with an underlying framework that is more lightweight. Given my suspicion that there will always be a way for a client to learn of a shared secret for a STUN server, and given that the core security properties required for STUN appear to be server-to-client authentication, replay protection and integrity (no confidentality, no PKI-style authentication), then it sounds to me like there are already security systems that satisfy this set of requirements. A good example would be HTTP Digest authentication (RFC2617). In broad strokes, applying HTTP Digest-style security to STUN would probably entail the creation of a STUN attribute corresponding to RFC2617 'nonce' (in a twist on HTTP, this attribute would probably be sent by the client in the request for STUN, since the request is essentially the 'challenge'), as well as the replacement of SMS-SIGNED-DATA with a much more lightweight STUN attribute corresponding to the RFC2617 'response', for which the entity-body would be the remainder of the STUN response. I don't immediately think we'd need to change anything about the syntax or usage of COOKIE (although it corresponds to the 'opaque' string in Digest, it would still be provided by the STUN server). Of course, Digest values would no longer need to be displayed as printable ASCII characters, which would create some savings over the HTTP version. If it turns out that STUN could also use mutual authentication, a STUN version of Digest could provide that as well with the addition of a 'cnonce'-ish STUN attribute (which, again twisting HTTP, might be sent by the server). Some behaviorial support for stale nonces would be required as well - clients would have to resend requests with a fresh nonce if they receive a server response with a stale nonce. Some language about how shared secrets are created and managed server-side would also be in order. In summary, a STUN version of Digest looks like a more promising path to me than CMS. I don't think it would be terribly difficult to specify these new parameters even in the short term, drawing liberally on RFC2617. For a protocol like STUN, I really think CMS is quite a burden. With a lighterweight mechanism, maybe the STUN draft could even make the usage of the security mechanism mandatory. Jon Peterson NeuStar, Inc. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 23 08:45:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15102 for ; Tue, 23 Apr 2002 08:45:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA26964 for midcom-archive@odin.ietf.org; Tue, 23 Apr 2002 08:45:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26778; Tue, 23 Apr 2002 08:43:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26751 for ; Tue, 23 Apr 2002 08:43:54 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15030 for ; Tue, 23 Apr 2002 08:43:50 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g3NChHjR009452; Tue, 23 Apr 2002 05:43:17 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADQ05557; Tue, 23 Apr 2002 05:40:39 -0700 (PDT) Message-Id: <5.1.0.14.0.20020423083802.00a8f050@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 23 Apr 2002 08:47:38 -0400 To: "Peterson, Jon" , "'midcom@ietf.org'" From: Melinda Shore Subject: RE: [midcom] Working group last call - STUN (security) In-Reply-To: <70565611B164D511957A001083FCDD5601870249@va02.va.neustar.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 01:07 AM 4/23/02 -0500, Peterson, Jon wrote: >As far as I can tell from the draft, and my conversations with some of the >authors, I suspect that each of the various ways in which a client might >discover a STUN server could also provide a means for a secret symmetric key >to be shared with the client. We talked about the use of self-signed certs, and it's probably not a good idea in this instance. If you want to make sure that you're talking to who you think you're talking to without taking their word for it, you can't trust their signature, either. With the use of DNS, even if you're capable of transporting the keys, you need a secure mechanism to push them to the STUN server along with the identity/credentials of the STUN client. You also would need to trust your DNS server. It would add a great deal of complexity, unfortunately. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue Apr 23 10:55:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20890 for ; Tue, 23 Apr 2002 10:55:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA05690 for midcom-archive@odin.ietf.org; Tue, 23 Apr 2002 10:55:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05589; Tue, 23 Apr 2002 10:53:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05552 for ; Tue, 23 Apr 2002 10:53:26 -0400 (EDT) Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20735 for ; Tue, 23 Apr 2002 10:53:20 -0400 (EDT) Received: from [63.113.114.131] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 2928546 for midcom@ietf.org; Tue, 23 Apr 2002 10:53:22 -0400 Message-Id: <5.1.0.14.0.20020423104007.01b1d528@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 23 Apr 2002 10:53:05 -0400 To: midcom@ietf.org From: "Joel M. Halpern" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [midcom] Re: draft-aoun-midcom-cops-01.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org A few comments on this draft: The first thing that struck me is that the draft was not clear as to whether it was discussing COPS or COPS-PR. While these are closely related, fom a practical point of view they are different, and it would help the reader if the assumption in the comparison was a specific one of the two or both. Given that operations are driven by the midcom agent which is a COPS PDP, I conclude that you primarily intended COPS-PR. The second thing that struck me is that in several places the document suggests that one could instantiate multiple PEPs to address the interaction with multiple managers (PDPs). The document states that requirement 2.1.3 is fully met by this mechanism. The best way I can say this is that such a statement assumes facts not in evidence. The rules for COPs PEPs specifically require non-overlapping domains of responsibility. In fact, this partitioning of manager responsibility is one of the biggest differences between COPS-PR and SNMP. If you see a way to bend things to make it work for this, significantly more clarity on how to do so is needed for tose a little more removed to evaluate the comparisons. Some might feel that my comment above is asking for too much from a comparison document. I feel it is reasonable to ask that ways in which the protocol can be bent to meet the requirements be spelled out in more detail in the evaluation than those ways which are a natural fit for the protocol, such as the representation of actions and properties of requests. Additionally, the description of the handling of aggregation seems weak. I actually think COPS can address the midcom requirement (2.2.3), but the use of hierarchy is unlikely to be the way to do so. Hierarchical structure is done a priori when the PIBs are defined. Aggregations are likely t be needed by specific applications making use of the common midcom services. We should not need to define new PIBs in order for agents to make new collections of requests if the elements they need are present. Yours, Joel M. Halpern _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue Apr 23 11:06:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21541 for ; Tue, 23 Apr 2002 11:06:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA06790 for midcom-archive@odin.ietf.org; Tue, 23 Apr 2002 11:06:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06329; Tue, 23 Apr 2002 11:02:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06296 for ; Tue, 23 Apr 2002 11:02:05 -0400 (EDT) Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21318 for ; Tue, 23 Apr 2002 11:02:00 -0400 (EDT) Received: from [63.113.114.131] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 2928562 for midcom@ietf.org; Tue, 23 Apr 2002 11:02:02 -0400 Message-Id: <5.1.0.14.0.20020423105307.01af2578@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 23 Apr 2002 11:01:43 -0400 To: midcom@ietf.org From: "Joel M. Halpern" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [midcom] Re: draft-taylor-midcom-diameter-eval-00.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I found this evaluation to be very sketchy. I will try to ask some specific questions: It is not at all clear to me whether the midcom agents is intended to be a diameter client, or server. My understanding (and please feel free to correct me if I am wrong in this regard) is that Diameter, like Radius, is a client / server where the client sends requests to the server and receives responses. Even if there are some additional reverse direction messages for special cases, this seems to be the predominant mode. The midcom protocol predominant mode is an invocation be a midcom agent requesting a behavior of a middlebox. This would lead one to the odd situation of expecting the midcom agent to be a diameter client, and a middlebox to be a diameter server. There is a reference to AVP grouping to address the aggregation requirement. As I am not particularly familiar with the Diameter details, it would be helpful if you mentioned whether this grouping is ad hoc (in which case it address the requirement thoroughly) or is defined via a schema / RFC / ... On a number of the requirements, somewhat more elaboration of the Diameter behavior would be helpful. Even once I know which side is the client and which the server, I suspect that issues of state maintenance, overlapping control, and related items which you feel are addressed easily could be described a little better. Yours, Joel M. Halpern _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue Apr 23 11:08:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21686 for ; Tue, 23 Apr 2002 11:08:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA06877 for midcom-archive@odin.ietf.org; Tue, 23 Apr 2002 11:08:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06693; Tue, 23 Apr 2002 11:05:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06664 for ; Tue, 23 Apr 2002 11:05:11 -0400 (EDT) Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21485 for ; Tue, 23 Apr 2002 11:05:06 -0400 (EDT) Received: from [63.113.114.131] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 2928569 for midcom@ietf.org; Tue, 23 Apr 2002 11:05:09 -0400 Message-Id: <5.1.0.14.0.20020423110144.01b2b738@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 23 Apr 2002 11:04:50 -0400 To: midcom@ietf.org From: "Joel M. Halpern" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [midcom] Re: draft-renkel-rsip-midcom-eval-00.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org My primary observation reading this document is that it would be helpful if you clearly and early in the document indicated that your proposal is to change the data handling behavior of te middlebox. If this is not your intent, then significant attention is needed to how RSIP would work without the currently required tunneling (you merely say "null tunnel", but there is a lot more to it than that. The other issue is that as I understand it RSIP as currently designed assumes that the requestor and the communicating party are one and the same. If this is so, and is a behavior you intend to retain, please say so. If it is a behavior you believe can be changed, then some description of the complications and degree of change to RSIP would be helpful. Yours, Joel M. Halpern _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue Apr 23 11:22:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22634 for ; Tue, 23 Apr 2002 11:22:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07821 for midcom-archive@odin.ietf.org; Tue, 23 Apr 2002 11:22:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07626; Tue, 23 Apr 2002 11:18:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07537 for ; Tue, 23 Apr 2002 11:18:43 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22442 for ; Tue, 23 Apr 2002 11:18:38 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3NFI7X29042; Tue, 23 Apr 2002 10:18:08 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2Y3TYS4Q>; Tue, 23 Apr 2002 10:18:04 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E01187AAC@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Peterson, Jon'" , "'midcom@ietf.org'" Subject: RE: [midcom] Working group last call - STUN (security) Date: Tue, 23 Apr 2002 10:17:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EADA.0C7EA100" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1EADA.0C7EA100 Content-Type: text/plain; charset="iso-8859-1" Jon, As perhaps the only member of the pre-Midcom design team supporting the option of a shared secret mechanism for STUN, I concur with you fully. In fact, my proposal to my team memebers had been exactly the same as yours - use a Digest-ish mechanism with two new STUN attributes, one for carrying the 'challenge' (nonce) and the other for the 'response'. It was turned down on the argument that anything less than public certs would hamper STUN adoption, although I tend to think that its the opposite. What we would likely see are many non-compliant implementations without any authentication. I think that its feasible to have both the options in the draft with the shared secret mechanism as the default. Sanjoy > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Tuesday, April 23, 2002 1:08 AM > To: 'midcom@ietf.org' > Subject: RE: [midcom] Working group last call - STUN (security) > > > > I have a long (and belated) comment on STUN's security - I > apologize in > advance for raising it only now, and for the fact that this > particular point > was hashed out way back during the pre-midcom design team. > Specifically, I > am concerned that CMS is a relatively heavyweight security system to > implement. For the most part, these concerns relate to the use of an > asymmetric key messaging system (including certificates) with a such a > low-level protocol. The general ASN.1 protocol overhead, > X.509 certificate > verification (including maintaining root certs on the client, > etc), and the > extra TCP RTT required to download certificate chains from a > server are a > relatively high cost to pay. > > In Minneapolis, Jonathan suggested that implementing CMS > would require 10-20 > times the amount of code/effort that STUN itself would > necessitate. CMS > might not be prohibitive for some applications, such as SIP, > which have an > incentive to implement CMS already for S/MIME. However, I'd > like to believe > that STUN has broader applicability than SIP, and that the comparative > complexity of the security implementation is therefore a > cause for concern. > I fear mandating CMS might either limit the deployment of > STUN or limit the > number of implementations that include STUN's security > mechanism - both of > which are bad. > > Some of the things that make me think CMS might not be the > best fit are: > > 1) Certificate usage doesn't jibe well with the rest of the > mechanism today; > so much so that switching to TCP for the certificate transport RTT is > recommended - it certainly wouldn't be ideal to require STUN > entities to > implement TCP. One might recommend using CMS without > certificates (just > public keys), but then its authentication story wouldn't be much more > powerful than using shared secrets. > > As far as I can tell from the draft, and my conversations > with some of the > authors, I suspect that each of the various ways in which a > client might > discover a STUN server could also provide a means for a > secret symmetric key > to be shared with the client. So for example, if the client is > pre-configured with the domain of a STUN server, it could also be > pre-configured with a shared secret at that time. Or if the > STUN server were > discovered dynamically (say, on some kind of public matching > service that > tracked STUN servers), a shared secret could be passed to the > client by such > a matching service at the same time as the STUN server's > address - this > assumes that transmitting the secret would require about the > same amount of > security as transmitting the domain of the STUN server, which doesn't > immediately sound unreasonable. For example, protocols like > SIP might pass > back a STUN server domain and accompanying secret in the > application layer > (relying on their own security mechanisms to shield this > information from > eavesdroppers). I would suggest that abandonning the > complexities of CMS > more than compensates for any trouble associated with learning shared > secrets. > > 2) CMS really is pretty heavyweight, and it contains a lot of > material that > is superfluous to STUN. Here follows the ASN.1 (yes, and > having to do ASN.1 > seems a little more annoying if you aren't already doing > X.509) of the CMS > SignedData message (to which the CMS-SIGNED-DATA attribute in > midcom-stun-00 > is "exactly equal"): > > SignedData ::= SEQUENCE { > version CMSVersion, > digestAlgorithms DigestAlgorithmIdentifiers, > encapContentInfo EncapsulatedContentInfo, > certificates [0] IMPLICIT CertificateSet OPTIONAL, > crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, > signerInfos SignerInfos } > > Although half of these are optional (including, for STUN, the > EncapsulatedContentInfo, which should be omitted in favor of > an external > signature), there is still a lot of unnecessary and redundant > material here > in compound objects. For example, SignerInfo above breaks down to: > > SignerInfo ::= SEQUENCE { > version CMSVersion, > sid SignerIdentifier, > digestAlgorithm DigestAlgorithmIdentifier, > signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, > signatureAlgorithm SignatureAlgorithmIdentifier, > signature SignatureValue, > unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } > > Personally, I don't think STUN needs to identify the Digest > algorithm at all > in the message - I think we could safely assume just one > (MD5) and save > ourselves a few bytes. Similarly, all of the optional > certificate-based > material above is unnecessary if you believe the shared secret based > approach described above is sufficient. We also don't need support for > multiple signers of the data (since only one STUN server is > involved with > the generation and securing of a response). Filler material > like versioning > on the SignedData is also probably unnecessary for STUN > (though STUN should > probably have its own version field - but that's a separate > issue). I think > STUN should use a much leaner, more stripped-down mechanism > that delivers > only the security properties it needs. > > 3) Confidentiality doesn't seem useful for STUN, and one of > the primary > reasons to use CMS is that it can provide confidentiality. > That suggests > that a lot of the baseline CMS functionality (all of the EnvelopedData > message, for starters) is unnecessary. On the one hand, this > could merely > suggest that a scaled-down profile of CMS should be built for > STUN that uses > minimal SignedData only, but on the other hand it further > shows that CMS has > a lot of versatility that STUN doesn't need, and that we > might be able to > get away with an underlying framework that is more lightweight. > > Given my suspicion that there will always be a way for a > client to learn of > a shared secret for a STUN server, and given that the core security > properties required for STUN appear to be server-to-client > authentication, > replay protection and integrity (no confidentality, no PKI-style > authentication), then it sounds to me like there are already security > systems that satisfy this set of requirements. A good example > would be HTTP > Digest authentication (RFC2617). > > In broad strokes, applying HTTP Digest-style security to STUN > would probably > entail the creation of a STUN attribute corresponding to > RFC2617 'nonce' (in > a twist on HTTP, this attribute would probably be sent by the > client in the > request for STUN, since the request is essentially the > 'challenge'), as well > as the replacement of SMS-SIGNED-DATA with a much more > lightweight STUN > attribute corresponding to the RFC2617 'response', for which > the entity-body > would be the remainder of the STUN response. I don't > immediately think we'd > need to change anything about the syntax or usage of COOKIE > (although it > corresponds to the 'opaque' string in Digest, it would still > be provided by > the STUN server). Of course, Digest values would no longer need to be > displayed as printable ASCII characters, which would create > some savings > over the HTTP version. If it turns out that STUN could also use mutual > authentication, a STUN version of Digest could provide that > as well with the > addition of a 'cnonce'-ish STUN attribute (which, again > twisting HTTP, might > be sent by the server). Some behaviorial support for stale > nonces would be > required as well - clients would have to resend requests with > a fresh nonce > if they receive a server response with a stale nonce. Some > language about > how shared secrets are created and managed server-side would > also be in > order. > > In summary, a STUN version of Digest looks like a more > promising path to me > than CMS. I don't think it would be terribly difficult to > specify these new > parameters even in the short term, drawing liberally on RFC2617. For a > protocol like STUN, I really think CMS is quite a burden. With a > lighterweight mechanism, maybe the STUN draft could even make > the usage of > the security mechanism mandatory. > > Jon Peterson > NeuStar, Inc. > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C1EADA.0C7EA100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Working group last call - STUN (security)

Jon,

  As perhaps the only member of the pre-Midcom = design team supporting the option of a shared secret mechanism for = STUN, I concur with you fully. In fact, my proposal to my team memebers = had been exactly the same as yours - use a Digest-ish mechanism with = two new STUN attributes, one for carrying the 'challenge' (nonce) and = the other for the 'response'. It was turned down on the argument that = anything less than public certs would hamper STUN adoption, although I = tend to think that its the opposite. What we would likely see are many = non-compliant implementations without any authentication. I think that = its feasible to have both the options in the draft with the shared = secret mechanism as the default.

Sanjoy

> -----Original Message-----
> From: Peterson, Jon [mailto:jon.peterson@neustar.biz= ]
> Sent: Tuesday, April 23, 2002 1:08 AM
> To: 'midcom@ietf.org'
> Subject: RE: [midcom] Working group last call - = STUN (security)
>
>
>
> I have a long (and belated) comment on STUN's = security - I
> apologize in
> advance for raising it only now, and for the = fact that this
> particular point
> was hashed out way back during the pre-midcom = design team.
> Specifically, I
> am concerned that CMS is a relatively = heavyweight security system to
> implement. For the most part, these concerns = relate to the use of an
> asymmetric key messaging system (including = certificates) with a such a
> low-level protocol. The general ASN.1 protocol = overhead, 
> X.509 certificate
> verification (including maintaining root certs = on the client,
> etc), and the
> extra TCP RTT required to download certificate = chains from a
> server are a
> relatively high cost to pay.
>
> In Minneapolis, Jonathan suggested that = implementing CMS
> would require 10-20
> times the amount of code/effort that STUN = itself would
> necessitate. CMS
> might not be prohibitive for some applications, = such as SIP,
> which have an
> incentive to implement CMS already for S/MIME. = However, I'd
> like to believe
> that STUN has broader applicability than SIP, = and that the comparative
> complexity of the security implementation is = therefore a
> cause for concern.
> I fear mandating CMS might either limit the = deployment of
> STUN or limit the
> number of implementations that include STUN's = security
> mechanism - both of
> which are bad.
>
> Some of the things that make me think CMS might = not be the
> best fit are:
>
> 1) Certificate usage doesn't jibe well with the = rest of the
> mechanism today;
> so much so that switching to TCP for the = certificate transport RTT is
> recommended - it certainly wouldn't be ideal to = require STUN
> entities to
> implement TCP. One might recommend using CMS = without
> certificates (just
> public keys), but then its authentication story = wouldn't be much more
> powerful than using shared secrets.
>
> As far as I can tell from the draft, and my = conversations
> with some of the
> authors, I suspect that each of the various = ways in which a
> client might
> discover a STUN server could also provide a = means for a
> secret symmetric key
> to be shared with the client. So for example, = if the client is
> pre-configured with the domain of a STUN = server, it could also be
> pre-configured with a shared secret at that = time. Or if the
> STUN server were
> discovered dynamically (say, on some kind of = public matching
> service that
> tracked STUN servers), a shared secret could be = passed to the
> client by such
> a matching service at the same time as the STUN = server's
> address - this
> assumes that transmitting the secret would = require about the
> same amount of
> security as transmitting the domain of the STUN = server, which doesn't
> immediately sound unreasonable. For example, = protocols like
> SIP might pass
> back a STUN server domain and accompanying = secret in the
> application layer
> (relying on their own security mechanisms to = shield this
> information from
> eavesdroppers). I would suggest that = abandonning the
> complexities of CMS
> more than compensates for any trouble = associated with learning shared
> secrets.
>
> 2) CMS really is pretty heavyweight, and it = contains a lot of
> material that
> is superfluous to STUN. Here follows the ASN.1 = (yes, and
> having to do ASN.1
> seems a little more annoying if you aren't = already doing
> X.509) of the CMS
> SignedData message (to which the = CMS-SIGNED-DATA attribute in
> midcom-stun-00
> is "exactly equal"):
>
> SignedData ::=3D SEQUENCE {
>   version CMSVersion,
>   digestAlgorithms = DigestAlgorithmIdentifiers,
>   encapContentInfo = EncapsulatedContentInfo,
>   certificates [0] IMPLICIT = CertificateSet OPTIONAL,
>   crls [1] IMPLICIT = CertificateRevocationLists OPTIONAL,
>   signerInfos SignerInfos }
>
> Although half of these are optional (including, = for STUN, the
> EncapsulatedContentInfo, which should be = omitted in favor of
> an external
> signature), there is still a lot of unnecessary = and redundant
> material here
> in compound objects. For example, SignerInfo = above breaks down to:
>
> SignerInfo ::=3D SEQUENCE {
>   version CMSVersion,
>   sid SignerIdentifier,
>   digestAlgorithm = DigestAlgorithmIdentifier,
>   signedAttrs [0] IMPLICIT = SignedAttributes OPTIONAL,
>   signatureAlgorithm = SignatureAlgorithmIdentifier,
>   signature SignatureValue,
>   unsignedAttrs [1] IMPLICIT = UnsignedAttributes OPTIONAL }
>
> Personally, I don't think STUN needs to = identify the Digest
> algorithm at all
> in the message - I think we could safely assume = just one
> (MD5) and save
> ourselves a few bytes. Similarly, all of the = optional
> certificate-based
> material above is unnecessary if you believe = the shared secret based
> approach described above is sufficient. We also = don't need support for
> multiple signers of the data (since only one = STUN server is
> involved with
> the generation and securing of a response). = Filler material
> like versioning
> on the SignedData is also probably unnecessary = for STUN
> (though STUN should
> probably have its own version field - but = that's a separate
> issue). I think
> STUN should use a much leaner, more = stripped-down mechanism
> that delivers
> only the security properties it needs.
>
> 3) Confidentiality doesn't seem useful for = STUN, and one of
> the primary
> reasons to use CMS is that it can provide = confidentiality.
> That suggests
> that a lot of the baseline CMS functionality = (all of the EnvelopedData
> message, for starters) is unnecessary. On the = one hand, this
> could merely
> suggest that a scaled-down profile of CMS = should be built for
> STUN that uses
> minimal SignedData only, but on the other hand = it further
> shows that CMS has
> a lot of versatility that STUN doesn't need, = and that we
> might be able to
> get away with an underlying framework that is = more lightweight.
>
> Given my suspicion that there will always be a = way for a
> client to learn of
> a shared secret for a STUN server, and given = that the core security
> properties required for STUN appear to be = server-to-client
> authentication,
> replay protection and integrity (no = confidentality, no PKI-style
> authentication), then it sounds to me like = there are already security
> systems that satisfy this set of requirements. = A good example
> would be HTTP
> Digest authentication (RFC2617).
>
> In broad strokes, applying HTTP Digest-style = security to STUN
> would probably
> entail the creation of a STUN attribute = corresponding to
> RFC2617 'nonce' (in
> a twist on HTTP, this attribute would probably = be sent by the
> client in the
> request for STUN, since the request is = essentially the
> 'challenge'), as well
> as the replacement of SMS-SIGNED-DATA with a = much more
> lightweight STUN
> attribute corresponding to the RFC2617 = 'response', for which
> the entity-body
> would be the remainder of the STUN response. I = don't
> immediately think we'd
> need to change anything about the syntax or = usage of COOKIE
> (although it
> corresponds to the 'opaque' string in Digest, = it would still
> be provided by
> the STUN server). Of course, Digest values = would no longer need to be
> displayed as printable ASCII characters, which = would create
> some savings
> over the HTTP version. If it turns out that = STUN could also use mutual
> authentication, a STUN version of Digest could = provide that
> as well with the
> addition of a 'cnonce'-ish STUN attribute = (which, again
> twisting HTTP, might
> be sent by the server). Some behaviorial = support for stale
> nonces would be
> required as well - clients would have to resend = requests with
> a fresh nonce
> if they receive a server response with a stale = nonce. Some
> language about
> how shared secrets are created and managed = server-side would
> also be in
> order.
>
> In summary, a STUN version of Digest looks like = a more
> promising path to me
> than CMS. I don't think it would be terribly = difficult to
> specify these new
> parameters even in the short term, drawing = liberally on RFC2617. For a
> protocol like STUN, I really think CMS is quite = a burden. With a
> lighterweight mechanism, maybe the STUN draft = could even make
> the usage of
> the security mechanism mandatory.
>
> Jon Peterson
> NeuStar, Inc.
>
>
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C1EADA.0C7EA100-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue Apr 23 11:34:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23403 for ; Tue, 23 Apr 2002 11:34:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA08807 for midcom-archive@odin.ietf.org; Tue, 23 Apr 2002 11:34:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08353; Tue, 23 Apr 2002 11:31:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08321 for ; Tue, 23 Apr 2002 11:31:11 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23267 for ; Tue, 23 Apr 2002 11:31:06 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3NFR1U03137; Tue, 23 Apr 2002 11:27:01 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Apr 2002 11:27:03 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A356@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Joel M. Halpern'" , midcom@ietf.org Subject: RE: [midcom] Re: draft-taylor-midcom-diameter-eval-00.txt Date: Tue, 23 Apr 2002 11:27:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EADA.D09A6DDA" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1EADA.D09A6DDA Content-Type: text/plain; charset="ISO-8859-1" I'll be happy to elaborate on all aspects. I was under the impression that I had to keep things brief so the evaluation would lend itself easily to incorporation in Mary's summary. But I assure you, I did my homework before checking off the requirements, and I'll prove it in a recycle of the document. On a fundamental point: Diameter calls itself a peer-to-peer protocol. -----Original Message----- From: Joel M. Halpern [mailto:joel@stevecrocker.com] Sent: Tuesday, April 23, 2002 11:02 AM To: midcom@ietf.org Subject: [midcom] Re: draft-taylor-midcom-diameter-eval-00.txt I found this evaluation to be very sketchy. I will try to ask some specific questions: It is not at all clear to me whether the midcom agents is intended to be a diameter client, or server. My understanding (and please feel free to correct me if I am wrong in this regard) is that Diameter, like Radius, is a client / server where the client sends requests to the server and receives responses. Even if there are some additional reverse direction messages for special cases, this seems to be the predominant mode. The midcom protocol predominant mode is an invocation be a midcom agent requesting a behavior of a middlebox. This would lead one to the odd situation of expecting the midcom agent to be a diameter client, and a middlebox to be a diameter server. There is a reference to AVP grouping to address the aggregation requirement. As I am not particularly familiar with the Diameter details, it would be helpful if you mentioned whether this grouping is ad hoc (in which case it address the requirement thoroughly) or is defined via a schema / RFC / ... On a number of the requirements, somewhat more elaboration of the Diameter behavior would be helpful. Even once I know which side is the client and which the server, I suspect that issues of state maintenance, overlapping control, and related items which you feel are addressed easily could be described a little better. Yours, Joel M. Halpern _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C1EADA.D09A6DDA Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Re: = draft-taylor-midcom-diameter-eval-00.txt

I'll be happy to elaborate on all aspects.  I = was under the impression that I had to keep things brief so the = evaluation would lend itself easily to incorporation in Mary's = summary.  But I assure you, I did my homework before checking off = the requirements, and I'll prove it in a recycle of the = document.

On a fundamental point: Diameter calls itself a = peer-to-peer protocol.

-----Original Message-----
From: Joel M. Halpern [mailto:joel@stevecrocker.com]<= /FONT>
Sent: Tuesday, April 23, 2002 11:02 AM
To: midcom@ietf.org
Subject: [midcom] Re: = draft-taylor-midcom-diameter-eval-00.txt


I found this evaluation to be very sketchy.  I = will try to ask some
specific questions:

It is not at all clear to me whether the midcom = agents is intended to be a
diameter client, or server.  My understanding = (and please feel free to
correct me if I am wrong in this regard) is that = Diameter, like Radius, is
a client / server where the client sends requests to = the server and
receives responses.  Even if there are some = additional reverse direction
messages for special cases, this seems to be the = predominant mode.  The
midcom protocol predominant mode is an invocation be = a midcom agent
requesting a behavior of a middlebox.  This = would lead one to the odd
situation of expecting the midcom agent to be a = diameter client, and a
middlebox to be a diameter server.

There is a reference to AVP grouping to address the = aggregation
requirement.  As I am not particularly familiar = with the Diameter details,
it would be helpful if you mentioned whether this = grouping is ad hoc (in
which case it address the requirement thoroughly) or = is defined via a
schema / RFC / ...

On a number of the requirements, somewhat more = elaboration of the Diameter
behavior would be helpful.  Even once I know = which side is the client and
which the server, I suspect that issues of state = maintenance, overlapping
control, and related items which you feel are = addressed easily could be
described a little better.

Yours,
Joel M. Halpern


_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C1EADA.D09A6DDA-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue Apr 23 11:52:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24430 for ; Tue, 23 Apr 2002 11:52:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA09915 for midcom-archive@odin.ietf.org; Tue, 23 Apr 2002 11:52:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09831; Tue, 23 Apr 2002 11:49:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09802 for ; Tue, 23 Apr 2002 11:49:47 -0400 (EDT) Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24316 for ; Tue, 23 Apr 2002 11:49:41 -0400 (EDT) Received: from [63.113.114.131] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 2928665; Tue, 23 Apr 2002 11:49:42 -0400 Message-Id: <5.1.0.14.0.20020423114544.01b49eb0@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 23 Apr 2002 11:49:08 -0400 To: "Tom-PT Taylor", midcom@ietf.org From: "Joel M. Halpern" Subject: RE: [midcom] Re: draft-taylor-midcom-diameter-eval-00.txt In-Reply-To: <4D79C746863DD51197690002A52CDA0001E8A356@zcard0kc.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Thank you. I did not intend to imply that you had not done your homework. A small explanation of peer-to-peer approach taken by Diameter would go a long way to addressing my concerns. If that included some coverage of the way Diameter views control (which might be absent completely due to the lack of coverage of state persistence that you mentioned) that would probably be helpful. There is an awkward balance to be achieved between avoiding saying too much on the one hand, as otherwise we have a multiple volume tome, while still saying enough that those who are not experts in the individual protocols have enough information to form reasoned judgements. Yours, Joel At 11:27 AM 4/23/2002 -0400, Tom-PT Taylor wrote: >I'll be happy to elaborate on all aspects. I was under the impression >that I had to keep things brief so the evaluation would lend itself easily >to incorporation in Mary's summary. But I assure you, I did my homework >before checking off the requirements, and I'll prove it in a recycle of >the document. > >On a fundamental point: Diameter calls itself a peer-to-peer protocol. > >-----Original Message----- >From: Joel M. Halpern >[mailto:joel@stevecrocker.com] >Sent: Tuesday, April 23, 2002 11:02 AM >To: midcom@ietf.org >Subject: [midcom] Re: draft-taylor-midcom-diameter-eval-00.txt > >I found this evaluation to be very sketchy. I will try to ask some >specific questions: > >It is not at all clear to me whether the midcom agents is intended to be a >diameter client, or server. My understanding (and please feel free to >correct me if I am wrong in this regard) is that Diameter, like Radius, is >a client / server where the client sends requests to the server and >receives responses. Even if there are some additional reverse direction >messages for special cases, this seems to be the predominant mode. The >midcom protocol predominant mode is an invocation be a midcom agent >requesting a behavior of a middlebox. This would lead one to the odd >situation of expecting the midcom agent to be a diameter client, and a >middlebox to be a diameter server. > >There is a reference to AVP grouping to address the aggregation >requirement. As I am not particularly familiar with the Diameter details, >it would be helpful if you mentioned whether this grouping is ad hoc (in >which case it address the requirement thoroughly) or is defined via a >schema / RFC / ... > >On a number of the requirements, somewhat more elaboration of the Diameter >behavior would be helpful. Even once I know which side is the client and >which the server, I suspect that issues of state maintenance, overlapping >control, and related items which you feel are addressed easily could be >described a little better. > >Yours, >Joel M. Halpern > >_______________________________________________ >midcom mailing list >midcom@ietf.org >https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue Apr 23 11:56:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24613 for ; Tue, 23 Apr 2002 11:56:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA10336 for midcom-archive@odin.ietf.org; Tue, 23 Apr 2002 11:56:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10004; Tue, 23 Apr 2002 11:53:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09979 for ; Tue, 23 Apr 2002 11:53:47 -0400 (EDT) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24469 for ; Tue, 23 Apr 2002 11:53:41 -0400 (EDT) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g3NFr4729713; Tue, 23 Apr 2002 10:53:04 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Apr 2002 10:52:59 -0500 Message-ID: <70565611B164D511957A001083FCDD5601870253@va02.va.neustar.com> From: "Peterson, Jon" To: "'Melinda Shore'" , "'midcom@ietf.org'" Subject: RE: [midcom] Working group last call - STUN (security) Date: Tue, 23 Apr 2002 10:52:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org To be clear, I'm not speaking to self-signed certificates (which would still require asymmetric keys, X.509 verification, TCP, the extra RTT, and incur all of the other penalties described in my note). I'm speaking to Digest-like password strings that would be shared by the STUN client and server, assuming that there is some way for such a shared secret to be communicated to the client - probably the same means by which the client learns the domain of the STUN server. I agree that self-signed certificates would not be a promising direction for this work to take. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Tuesday, April 23, 2002 5:48 AM > To: Peterson, Jon; 'midcom@ietf.org' > Subject: RE: [midcom] Working group last call - STUN (security) > > > At 01:07 AM 4/23/02 -0500, Peterson, Jon wrote: > >As far as I can tell from the draft, and my conversations with some of the > >authors, I suspect that each of the various ways in which a client might > >discover a STUN server could also provide a means for a secret symmetric key > >to be shared with the client. > > We talked about the use of self-signed certs, and it's > probably not a good idea in this instance. If you want to > make sure that you're talking to who you think you're > talking to without taking their word for it, you can't > trust their signature, either. With the use of DNS, even > if you're capable of transporting the keys, you need a > secure mechanism to push them to the STUN server along > with the identity/credentials of the STUN client. You > also would need to trust your DNS server. It would add > a great deal of complexity, unfortunately. > > Melinda > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue Apr 23 12:05:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25184 for ; Tue, 23 Apr 2002 12:05:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12639 for midcom-archive@odin.ietf.org; Tue, 23 Apr 2002 12:05:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12312; Tue, 23 Apr 2002 12:03:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12265 for ; Tue, 23 Apr 2002 12:03:22 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25052 for ; Tue, 23 Apr 2002 12:03:16 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g3NG2lkL014718; Tue, 23 Apr 2002 09:02:47 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADQ09591; Tue, 23 Apr 2002 09:00:08 -0700 (PDT) Message-Id: <5.1.0.14.0.20020423115951.00a95850@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 23 Apr 2002 12:07:05 -0400 To: "Peterson, Jon" , "'midcom@ietf.org'" From: Melinda Shore Subject: RE: [midcom] Working group last call - STUN (security) In-Reply-To: <70565611B164D511957A001083FCDD5601870253@va02.va.neustar.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 10:52 AM 4/23/02 -0500, Peterson, Jon wrote: >To be clear, I'm not speaking to self-signed certificates (which would still >require asymmetric keys, X.509 verification, TCP, the extra RTT, and incur >all of the other penalties described in my note). I'm speaking to >Digest-like password strings that would be shared by the STUN client and >server, assuming that there is some way for such a shared secret to be >communicated to the client - probably the same means by which the client >learns the domain of the STUN server. How would you move keys between the discovery mechanism and the STUN server? What I'm concerned about here is that we'd be creating another path which would require protection. The problem here, as always, is how to get the keys to everybody securely. You can either front-load the processing using something like STS (which still requires public key operations) or you can send down the whole package using something like CMS. I'm not married to CMS, heaven knows, but we do need a solution that doesn't assume that keys are shared in advance. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue Apr 23 13:03:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27708 for ; Tue, 23 Apr 2002 13:03:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA15919 for midcom-archive@odin.ietf.org; Tue, 23 Apr 2002 13:03:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15528; Tue, 23 Apr 2002 13:00:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15488 for ; Tue, 23 Apr 2002 13:00:27 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27577 for ; Tue, 23 Apr 2002 13:00:24 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g3NGxcH04125; Tue, 23 Apr 2002 12:59:38 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Apr 2002 11:59:33 -0500 Message-ID: <70565611B164D511957A001083FCDD5601870256@va02.va.neustar.com> From: "Peterson, Jon" To: "'Melinda Shore'" , "'midcom@ietf.org'" Subject: RE: [midcom] Working group last call - STUN (security) Date: Tue, 23 Apr 2002 11:59:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Well, as I suggested in my original note, a STUN server discovery mechanism already requires security. If the domain of your STUN server is pre-configured statically (you have a STUN server for your enterprise, say - not a totally unlikely scenario), then of course a shared secret could be provisioned at that time - presumably no security worries here. If the domain is discovered dynamically through some protocol other than STUN, then if that discovery protocol lacked security, attackers could (for example) spoof a discovery in order to send a fake STUN domain to the client - a serious problem, comparable to the threat that motivates STUN security. So I say that if you assume a dynamical discovery mechanism at all, then it already requires security. Having a dynamic STUN server discovery mechanism also communicate the shared secret doesn't seem especially problematic to me. In SIP, for example, it wouldn't be too arduous to communicate a STUN domain and secret in a response header, and use SIP protocol security to protect them. So in short, while transmitting the secret requires security, so does transmitting the domain of the STUN server. I also argued in my previous that any amount of inconvenience we suffer on account of discovering secrets is likely to pale in comparison with the implementation and operation of CMS. I have a hard time not looking at CMS as a STUN killer. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Tuesday, April 23, 2002 9:07 AM > To: Peterson, Jon; 'midcom@ietf.org' > Subject: RE: [midcom] Working group last call - STUN (security) > > [snip] > > How would you move keys between the discovery mechanism and the > STUN server? What I'm concerned about here is that we'd be > creating another path which would require protection. > > The problem here, as always, is how to get the keys to everybody > securely. You can either front-load the processing using something > like STS (which still requires public key operations) or you can > send down the whole package using something like CMS. I'm not married > to CMS, heaven knows, but we do need a solution that doesn't assume > that keys are shared in advance. > > Melinda > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue Apr 23 13:34:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28648 for ; Tue, 23 Apr 2002 13:34:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA18085 for midcom-archive@odin.ietf.org; Tue, 23 Apr 2002 13:34:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17840; Tue, 23 Apr 2002 13:31:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17802 for ; Tue, 23 Apr 2002 13:31:31 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28589 for ; Tue, 23 Apr 2002 13:31:27 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g3NHUe2q027055; Tue, 23 Apr 2002 10:30:40 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADQ12819; Tue, 23 Apr 2002 10:28:15 -0700 (PDT) Message-Id: <5.1.0.14.0.20020423131456.00ab6260@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 23 Apr 2002 13:35:09 -0400 To: "Peterson, Jon" , "'midcom@ietf.org'" From: Melinda Shore Subject: RE: [midcom] Working group last call - STUN (security) In-Reply-To: <70565611B164D511957A001083FCDD5601870256@va02.va.neustar.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 11:59 AM 4/23/02 -0500, Peterson, Jon wrote: >If the >domain is discovered dynamically through some protocol other than STUN, then >if that discovery protocol lacked security, attackers could (for example) >spoof a discovery in order to send a fake STUN domain to the client - a >serious problem, comparable to the threat that motivates STUN security. So I >say that if you assume a dynamical discovery mechanism at all, then it >already requires security. STUN uses DNS SRV records for discovery. We can do several things: 1) rely on DNSSEC, which unfortunately is not widely deployed, or 2) authenticate the entity whose address is given to us by the DNS (which we'll have to do anyway). Asking the DNS to also distribute keys means 1) adding a new record type to DNS (I believe), 2) having DNS servers generate keys, and 3) finding some way for DNS servers to propagate keys and identity information to the STUN server as well as the STUN client. I don't think that's workable. We have to be serious about securing STUN and make sure that the security provides protection in typical deployment scenarios. The problem we have to solve is this: we need for the server responses to be authenticatable by the client and we absolutely cannot assume the pre-existence of a relationship between the client and the server. Jonathan proposed CMS, which I don't think is a terrible solution to that problem. There may be other, better mechanisms but I don't see how we can avoid requiring a PKI. We absolutely cannot get around strongly authenticated server responses. Is it the size and structure of CMS messages that concerns you, or do you object to requiring the involvement of a CA, or both, or something else entirely? What if we were to do an authenticated Diffie-Helman and then run a MAC over the packet? We'd still need a PKI and to execute public key operations, as well as more round trips, but we wouldn't face the same packet bloat problem that we would with CMS. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue Apr 23 13:57:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29508 for ; Tue, 23 Apr 2002 13:57:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA18989 for midcom-archive@odin.ietf.org; Tue, 23 Apr 2002 13:57:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18870; Tue, 23 Apr 2002 13:52:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18835 for ; Tue, 23 Apr 2002 13:52:44 -0400 (EDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29360 for ; Tue, 23 Apr 2002 13:52:40 -0400 (EDT) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.148]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Apr 2002 10:52:12 -0700 Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 23 Apr 2002 10:52:11 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Apr 2002 10:52:11 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Apr 2002 10:52:11 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Tue, 23 Apr 2002 10:48:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] Working group last call - STUN (security) Date: Tue, 23 Apr 2002 10:48:29 -0700 Message-ID: Thread-Topic: [midcom] Working group last call - STUN (security) thread-index: AcHq6BTJvX5Fs9whTbaeN/Nt+Y3/hgABPsnA From: "Christian Huitema" To: "Peterson, Jon" , "Melinda Shore" , X-OriginalArrivalTime: 23 Apr 2002 17:48:30.0649 (UTC) FILETIME=[14953290:01C1EAEF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA18836 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit Jon, The problem with shared secrets is that you really don't want to share them too many times, which implies that any secret would have to be specific to a server-client pair. This in turn implies that STUN servers need to actually identify their clients, which today they don't. I am not sure that the cost of writing a provisioning system is less than the cost of implementing CMS. In fact, we have to distinguish between the client side and the server side. On the server side, most server platforms that I can think off have support for cryptographic operations, including certificate operations. The development cost is not very high, since the ASN.1 stuff that you object to is already there. There is an operation cost in actually signing the responses, which may require some hardware support. On the client side, there are really two cases. Some clients are using platforms that already have cryptographic capabilities, and thus can implement CMS without a problem. There may be a CPU cost in the verification of the signature, but this cost is typically much less than the actual production of the signature. The clients that do not have CMS capability can also decide to just live dangerously, and not perform the signature algorithm... -- Christian Huitema > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Tuesday, April 23, 2002 10:00 AM > To: 'Melinda Shore'; 'midcom@ietf.org' > Subject: RE: [midcom] Working group last call - STUN (security) > > > Well, as I suggested in my original note, a STUN server discovery > mechanism > already requires security. If the domain of your STUN server is > pre-configured statically (you have a STUN server for your enterprise, say > - > not a totally unlikely scenario), then of course a shared secret could be > provisioned at that time - presumably no security worries here. If the > domain is discovered dynamically through some protocol other than STUN, > then > if that discovery protocol lacked security, attackers could (for example) > spoof a discovery in order to send a fake STUN domain to the client - a > serious problem, comparable to the threat that motivates STUN security. So > I > say that if you assume a dynamical discovery mechanism at all, then it > already requires security. Having a dynamic STUN server discovery > mechanism > also communicate the shared secret doesn't seem especially problematic to > me. In SIP, for example, it wouldn't be too arduous to communicate a STUN > domain and secret in a response header, and use SIP protocol security to > protect them. > > So in short, while transmitting the secret requires security, so does > transmitting the domain of the STUN server. I also argued in my previous > that any amount of inconvenience we suffer on account of discovering > secrets > is likely to pale in comparison with the implementation and operation of > CMS. I have a hard time not looking at CMS as a STUN killer. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Melinda Shore [mailto:mshore@cisco.com] > > Sent: Tuesday, April 23, 2002 9:07 AM > > To: Peterson, Jon; 'midcom@ietf.org' > > Subject: RE: [midcom] Working group last call - STUN (security) > > > > > [snip] > > > > How would you move keys between the discovery mechanism and the > > STUN server? What I'm concerned about here is that we'd be > > creating another path which would require protection. > > > > The problem here, as always, is how to get the keys to everybody > > securely. You can either front-load the processing using something > > like STS (which still requires public key operations) or you can > > send down the whole package using something like CMS. I'm not married > > to CMS, heaven knows, but we do need a solution that doesn't assume > > that keys are shared in advance. > > > > Melinda > > > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue Apr 23 14:12:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29897 for ; Tue, 23 Apr 2002 14:12:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA20122 for midcom-archive@odin.ietf.org; Tue, 23 Apr 2002 14:12:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19938; Tue, 23 Apr 2002 14:07:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19907 for ; Tue, 23 Apr 2002 14:07:22 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29704 for ; Tue, 23 Apr 2002 14:07:19 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g3NI6dH06053; Tue, 23 Apr 2002 14:06:39 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Apr 2002 13:06:34 -0500 Message-ID: <70565611B164D511957A001083FCDD5601870258@va02.va.neustar.com> From: "Peterson, Jon" To: "'Melinda Shore'" Cc: "'midcom@ietf.org'" Subject: RE: [midcom] Working group last call - STUN (security) Date: Tue, 23 Apr 2002 13:06:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Some notes below. I think we may be speaking to slightly different points here. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Tuesday, April 23, 2002 10:35 AM > To: Peterson, Jon; 'midcom@ietf.org' > Subject: RE: [midcom] Working group last call - STUN (security) > > [snip] > > STUN uses DNS SRV records for discovery. We can do several > things: 1) rely on DNSSEC, which unfortunately is not widely > deployed, or 2) authenticate the entity whose address is > given to us by the DNS (which we'll have to do anyway). Asking > the DNS to also distribute keys means 1) adding a new record type > to DNS (I believe), 2) having DNS servers generate keys, and 3) > finding some way for DNS servers to propagate keys and identity > information to the STUN server as well as the STUN client. I > don't think that's workable. > I'm not talking about that kind of 'discovery'. I'm talking about the way that you discover the STUN domain, not the way that once you have a STUN domain, you resolve that domain to the IP address of a STUN server. I agree that none of the DNS-based security systems above are likely to be material in solving STUN's problems. I would hope STUN will not be encouraged to make the self-limiting decision that the domain of the a STUN server must be identical to the target domain of the service (like SIP) for which STUN support is required. At least, I haven't read any such limitation into the current draft. In fact, section 9.1 of midcom-stun-00 reads: Generally, the client will be configured with a domain name of the provider of the STUN servers. Again, it seems perfectly reasonable to me that when the client is configured with a domain name, it could also be configured with a shared secret - no security issues here. If, on the other hand, we assume there is some dynamic means through which the client comes to learn the domain name of a STUN service provider, then (as I have argued) we must acknowledge that this dynamic means requires security of its own, regardless of whether it needs to communicate shared secrets. DNS should not be a candidate for such a dynamic discovery mechanism, anyway. > We have to be serious about securing STUN and make sure that > the security provides protection in typical deployment scenarios. > The problem we have to solve is this: we need for the server > responses to be authenticatable by the client and we absolutely > cannot assume the pre-existence of a relationship between the > client and the server. Then I presume you disagree with the statement in 9.1 of midcom-stun-00 above? And the alterantive is...? > Jonathan proposed CMS, which I don't > think is a terrible solution to that problem. There may be > other, better mechanisms but I don't see how we can avoid > requiring a PKI. Actually, I believe that systems that use STUN might require PKI in only a subset of its useful deployments. Again, in an environment in which the domain of a STUN server can be meaningfully pre-configured (like an enterprise for which there is a resident STUN server), I see no requirement for PKI in support of STUN. Dynamic STUN server discovery mechanisms might require PKI - but then again they might not. That's a different problem; I don't see why the PKI should be inflicted on STUN. > We absolutely cannot get around strongly > authenticated server responses. Is it the size and structure of > CMS messages that concerns you, or do you object to requiring > the involvement of a CA, or both, or something else entirely? I enumerated and expressed my concerns with CMS at some length in my original message. In summary, the most material concerns are: - TCP: There is no reason why STUN should entail support for TCP. It does now for certificate transport (due to NAT fragmentation of large messages). - Extra RTT: The current mechanism requires an extra exchange of messages between the client and server for certificate download (over TCP). That's three RTTs to get started - that should be a warning sign. - Cumbersome SignedData construction: The SignedData message format has support for a lot of concepts (like multiple signators of a single block of data) that STUN does not need, but for which STUN will pay the cost in message size and complexity. It uses a lot of bytes for redundant data like versioning and hash algorithm identification that we really don't need for STUN. - Confidentiality: STUN doesn't need it. CMS supplies it. This just further illustrates that CMS is oriented towards a different set of requirements than STUN. - CA support: Maintaining one or more root certificates could be burdensome for small clients. Verifying certificates with long chains could be complicated for devices with little memory to work with. I would hope STUN has applicability beyond expansive application-layer protocols like SIP. - Certificates overall (self-signed or CA-based): ASN.1 parsing for X.509 (and SignedData too) as well as asymmetric key operations are intensive. If they are unnecessary we should avoid them. Most of all, echoing Sanjoy, I think CMS means that STUN security will simply not be implemented, or worse yet that STUN overall will be passed over. You can provide for the security requirements of STUN with a much less elaborate system. We need CMS and PKI to secure a protocol that is basically 'echo'? Something's out of whack there. I also think you need a security mechanism for STUN that can be made mandatory. I doubt consensus could be achieved for requiring CMS. > What if we were to do an authenticated Diffie-Helman and then > run a MAC over the packet? We'd still need a PKI and to > execute public key operations, as well as more round trips, but > we wouldn't face the same packet bloat problem that we would > with CMS. > > Melinda > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue Apr 23 14:25:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00524 for ; Tue, 23 Apr 2002 14:25:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA20669 for midcom-archive@odin.ietf.org; Tue, 23 Apr 2002 14:26:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20424; Tue, 23 Apr 2002 14:19:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20394 for ; Tue, 23 Apr 2002 14:19:25 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00261 for ; Tue, 23 Apr 2002 14:19:21 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g3NIIjjR018139; Tue, 23 Apr 2002 11:18:45 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADQ14992; Tue, 23 Apr 2002 11:16:05 -0700 (PDT) Message-Id: <5.1.0.14.0.20020423141816.00ab7980@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 23 Apr 2002 14:23:01 -0400 To: "Peterson, Jon" From: Melinda Shore Subject: RE: [midcom] Working group last call - STUN (security) Cc: "'midcom@ietf.org'" In-Reply-To: <70565611B164D511957A001083FCDD5601870258@va02.va.neustar.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 01:06 PM 4/23/02 -0500, Peterson, Jon wrote: >Some notes below. I think we may be speaking to slightly different points >here. I think we may be, as well. I agree that CMS is big and hairy. I don't agree that we can change the question that it answers. We need to be able to authenticate server responses when there's no pre-existing relationship between the server and the client. I'd be very happy to talk about other mechanisms for solving that problem, but we can't opt out of addressing it. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue Apr 23 14:49:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01809 for ; Tue, 23 Apr 2002 14:49:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA22285 for midcom-archive@odin.ietf.org; Tue, 23 Apr 2002 14:49:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22121; Tue, 23 Apr 2002 14:45:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22094 for ; Tue, 23 Apr 2002 14:45:10 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01639 for ; Tue, 23 Apr 2002 14:45:05 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g3NIibH07103; Tue, 23 Apr 2002 14:44:37 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Apr 2002 13:44:32 -0500 Message-ID: <70565611B164D511957A001083FCDD5601870259@va02.va.neustar.com> From: "Peterson, Jon" To: "'Christian Huitema'" , midcom@ietf.org Subject: RE: [midcom] Working group last call - STUN (security) Date: Tue, 23 Apr 2002 13:44:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I agree that the real trick to this approach is coming up with a good recommendation for the creation of the shared secrets. I'm not sure that in practice, the creation of client-server pairs really means that STUN servers need to identify their clients, but I understand what motivates your concern there. However, I do think it's unfair to suggest that the complexity of provisioning clients with shared secrets is comparable to the complexity of CMS. Frankly, I imagine that provisioning non-PC clients with root certificates for various CAs alone entails quite a bit more trouble than provisioning shared secrets. And remember that according to midcom-stun-00, you'll be provisioning each client with the domain of a STUN server anyway - surely adding a shared secret at that time wouldn't result in any additional complexity. There might also be ways to cut down on 'personal' relationships between the server and clients. Since I sent my initial note on this, I've been kicking around a way to import the Digest concept of realms into STUN - all STUN clients in a given realm might share the same secret with a STUN server. For enterprise-style deployments (where a STUN service provider provides STUN to several enterprises that are considered independent realms) this could be meaningful. Interestingly, the threat against STUN described in the security considerations of midcom-stun-00 has a limitation - the attack has to come from outside the NAT when the NAT is full cone, and so perhaps users within your own enterprise and realm, who use the same secret as you and are behind the same NAT, might not have the opportunity to stage the attack. Needs more thought, but it's one path we might explore. On the client/server implementation issues, while I don't materially disagree with your analysis below, I'm sure we both acknowledge that there are undesirable costs, at a hardware level and a protocol level, that are incurred for CMS support. I've been the first one to champion the use of CMS when it is appropriate; for this application, though, it's a bit of an albatross. CMS just isn't necessary. Incidentally, recommending that smaller clients 'live dangerously' and not verify CMS signatures is tantamount to saying 'don't implement security'. This is exactly where I'm afraid CMS puts us. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Tuesday, April 23, 2002 10:48 AM > To: Peterson, Jon; Melinda Shore; midcom@ietf.org > Subject: RE: [midcom] Working group last call - STUN (security) > > > Jon, > > The problem with shared secrets is that you really don't want to share > them too many times, which implies that any secret would have to be > specific to a server-client pair. This in turn implies that STUN servers > need to actually identify their clients, which today they don't. I am > not sure that the cost of writing a provisioning system is less than the > cost of implementing CMS. In fact, we have to distinguish between the > client side and the server side. > > On the server side, most server platforms that I can think off have > support for cryptographic operations, including certificate operations. > The development cost is not very high, since the ASN.1 stuff that you > object to is already there. There is an operation cost in actually > signing the responses, which may require some hardware support. > > On the client side, there are really two cases. Some clients are using > platforms that already have cryptographic capabilities, and thus can > implement CMS without a problem. There may be a CPU cost in the > verification of the signature, but this cost is typically much less than > the actual production of the signature. The clients that do not have CMS > capability can also decide to just live dangerously, and not perform the > signature algorithm... > > -- Christian Huitema > > > -----Original Message----- > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > > Sent: Tuesday, April 23, 2002 10:00 AM > > To: 'Melinda Shore'; 'midcom@ietf.org' > > Subject: RE: [midcom] Working group last call - STUN (security) > > > > > > Well, as I suggested in my original note, a STUN server discovery > > mechanism > > already requires security. If the domain of your STUN server is > > pre-configured statically (you have a STUN server for your > enterprise, > say > > - > > not a totally unlikely scenario), then of course a shared > secret could > be > > provisioned at that time - presumably no security worries > here. If the > > domain is discovered dynamically through some protocol other than > STUN, > > then > > if that discovery protocol lacked security, attackers could (for > example) > > spoof a discovery in order to send a fake STUN domain to > the client - > a > > serious problem, comparable to the threat that motivates STUN > security. So > > I > > say that if you assume a dynamical discovery mechanism at > all, then it > > already requires security. Having a dynamic STUN server discovery > > mechanism > > also communicate the shared secret doesn't seem especially > problematic > to > > me. In SIP, for example, it wouldn't be too arduous to communicate a > STUN > > domain and secret in a response header, and use SIP > protocol security > to > > protect them. > > > > So in short, while transmitting the secret requires > security, so does > > transmitting the domain of the STUN server. I also argued in my > previous > > that any amount of inconvenience we suffer on account of discovering > > secrets > > is likely to pale in comparison with the implementation and > operation > of > > CMS. I have a hard time not looking at CMS as a STUN killer. > > > > Jon Peterson > > NeuStar, Inc. > > > > > -----Original Message----- > > > From: Melinda Shore [mailto:mshore@cisco.com] > > > Sent: Tuesday, April 23, 2002 9:07 AM > > > To: Peterson, Jon; 'midcom@ietf.org' > > > Subject: RE: [midcom] Working group last call - STUN (security) > > > > > > > > [snip] > > > > > > How would you move keys between the discovery mechanism and the > > > STUN server? What I'm concerned about here is that we'd be > > > creating another path which would require protection. > > > > > > The problem here, as always, is how to get the keys to everybody > > > securely. You can either front-load the processing using > something > > > like STS (which still requires public key operations) or you can > > > send down the whole package using something like CMS. I'm not > married > > > to CMS, heaven knows, but we do need a solution that > doesn't assume > > > that keys are shared in advance. > > > > > > Melinda > > > > > > > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue Apr 23 14:56:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02194 for ; Tue, 23 Apr 2002 14:56:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA22541 for midcom-archive@odin.ietf.org; Tue, 23 Apr 2002 14:56:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22397; Tue, 23 Apr 2002 14:51:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22369 for ; Tue, 23 Apr 2002 14:51:22 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01932 for ; Tue, 23 Apr 2002 14:51:06 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g3NIoSH07303; Tue, 23 Apr 2002 14:50:28 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Apr 2002 13:50:23 -0500 Message-ID: <70565611B164D511957A001083FCDD560187025A@va02.va.neustar.com> From: "Peterson, Jon" To: "'Melinda Shore'" Cc: "'midcom@ietf.org'" Subject: RE: [midcom] Working group last call - STUN (security) Date: Tue, 23 Apr 2002 13:50:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org And I must reiterate that midcom-stun-00 already assumes enough of a pre-existing relationship that a client is provisioned with the domain of a server - and if that's the case, that's all the relationship we need for the client to also be provisioned with a shared secret. Why is the client provisioned with some specific STUN server domain (the STUN service at 'atlanta.com'), rather than some other domain (the STUN service at 'biloxi.com')? Because the person provisioning the client has some relationship with that particular domain. In whatever way that relationship was forged, a secret could also have been communicated. There's no slight of hand here, and I don't think this introduces any relationships amongst the participants in STUN that did not already exist. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Tuesday, April 23, 2002 11:23 AM > To: Peterson, Jon > Cc: 'midcom@ietf.org' > Subject: RE: [midcom] Working group last call - STUN (security) > > > At 01:06 PM 4/23/02 -0500, Peterson, Jon wrote: > >Some notes below. I think we may be speaking to slightly > different points > >here. > > I think we may be, as well. I agree that CMS is big and > hairy. I don't agree that we can change the question that > it answers. We need to be able to authenticate server > responses when there's no pre-existing relationship between > the server and the client. I'd be very happy to talk about > other mechanisms for solving that problem, but we can't opt > out of addressing it. > > Melinda > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue Apr 23 16:02:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05015 for ; Tue, 23 Apr 2002 16:02:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA26568 for midcom-archive@odin.ietf.org; Tue, 23 Apr 2002 16:02:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25697; Tue, 23 Apr 2002 15:57:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25665 for ; Tue, 23 Apr 2002 15:57:49 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04723 for ; Tue, 23 Apr 2002 15:57:43 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3NJvGpG016149; Tue, 23 Apr 2002 12:57:16 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADQ18666; Tue, 23 Apr 2002 12:54:16 -0700 (PDT) Message-Id: <5.1.0.14.0.20020423152122.00abd200@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 23 Apr 2002 16:01:10 -0400 To: "Peterson, Jon" From: Melinda Shore Subject: RE: [midcom] Working group last call - STUN (security) Cc: "'midcom@ietf.org'" In-Reply-To: <70565611B164D511957A001083FCDD560187025A@va02.va.neustar.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 01:50 PM 4/23/02 -0500, Peterson, Jon wrote: >And I must reiterate that midcom-stun-00 already assumes enough of a >pre-existing relationship that a client is provisioned with the domain of a >server - and if that's the case, that's all the relationship we need for the >client to also be provisioned with a shared secret. I'm not sure I agree with your basic premise (pre-existing relationships), and leaving aside, for the moment, scaling issues, key freshness is a serious issue with manually provisioned shared secrets and one that can't be addressed in the scenario you describe. I think that we can probably agree that we can cut the overhead on the packet down to adding an HMAC or digest, but the keying problem remains and I'd really like to focus on that. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue Apr 23 16:17:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05497 for ; Tue, 23 Apr 2002 16:17:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA27196 for midcom-archive@odin.ietf.org; Tue, 23 Apr 2002 16:17:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27075; Tue, 23 Apr 2002 16:11:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27044 for ; Tue, 23 Apr 2002 16:11:38 -0400 (EDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05359 for ; Tue, 23 Apr 2002 16:11:33 -0400 (EDT) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.148]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Apr 2002 13:11:06 -0700 Received: from 157.54.6.150 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 23 Apr 2002 13:11:05 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Apr 2002 13:10:37 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Apr 2002 13:10:38 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Tue, 23 Apr 2002 13:07:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] Working group last call - STUN (security) Date: Tue, 23 Apr 2002 13:07:24 -0700 Message-ID: Thread-Topic: [midcom] Working group last call - STUN (security) thread-index: AcHq93ksZAlViX+KSDatnzbFt/s8mAACzdgw From: "Christian Huitema" To: "Peterson, Jon" , "Melinda Shore" Cc: X-OriginalArrivalTime: 23 Apr 2002 20:07:24.0762 (UTC) FILETIME=[7C19EBA0:01C1EB02] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA27045 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit > > And I must reiterate that midcom-stun-00 already assumes enough of a > pre-existing relationship that a client is provisioned with the domain of > a > server - and if that's the case, that's all the relationship we need for > the > client to also be provisioned with a shared secret. Not true. I can provision the client by copying the same string in each of them, e.g. "stun.example.com." The string can be copied from a user manual. Do you suggest to copy the shared secret from that same manual? -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue Apr 23 17:19:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07040 for ; Tue, 23 Apr 2002 17:19:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA00678 for midcom-archive@odin.ietf.org; Tue, 23 Apr 2002 17:19:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00578; Tue, 23 Apr 2002 17:17:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00491 for ; Tue, 23 Apr 2002 17:17:00 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06953 for ; Tue, 23 Apr 2002 17:16:54 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g3NLGSkL002591 for ; Tue, 23 Apr 2002 14:16:28 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADQ21590; Tue, 23 Apr 2002 14:13:47 -0700 (PDT) Message-Id: <5.1.0.14.0.20020423171854.00ac3500@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 23 Apr 2002 17:20:39 -0400 To: "'midcom@ietf.org'" From: Melinda Shore Subject: RE: [midcom] Working group last call - STUN (security) In-Reply-To: <70565611B164D511957A001083FCDD560187025A@va02.va.neustar.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Let me ask this: if we have to move to TCP anyway, why not use TLS? It's more chatty than the CMS proposal, but it's got lower code overhead, less on-the-wire data expansion, and it's something that people can implement immediately. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue Apr 23 18:18:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08132 for ; Tue, 23 Apr 2002 18:18:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA04186 for midcom-archive@odin.ietf.org; Tue, 23 Apr 2002 18:18:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04116; Tue, 23 Apr 2002 18:16:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04077 for ; Tue, 23 Apr 2002 18:16:38 -0400 (EDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08080 for ; Tue, 23 Apr 2002 18:16:31 -0400 (EDT) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.148]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Apr 2002 15:15:27 -0700 Received: from 157.54.6.150 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 23 Apr 2002 15:15:28 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Apr 2002 15:15:27 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Apr 2002 15:15:27 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Tue, 23 Apr 2002 15:12:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] Working group last call - STUN (security) Date: Tue, 23 Apr 2002 15:12:22 -0700 Message-ID: Thread-Topic: [midcom] Working group last call - STUN (security) thread-index: AcHrC9ed4ODSZOdRRo+1EmFtrNKDGgACHXTw From: "Christian Huitema" To: "Melinda Shore" , X-OriginalArrivalTime: 23 Apr 2002 22:12:23.0330 (UTC) FILETIME=[F1989820:01C1EB13] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA04080 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit > Let me ask this: if we have to move to TCP anyway, why > not use TLS? It's more chatty than the CMS proposal, but > it's got lower code overhead, less on-the-wire data > expansion, and it's something that people can implement > immediately. You don't use TCP to request the mapping -- you can't, since you must use the same UDP socket you will use for the application. You only use TCP to fetch the oversized certificate list. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue Apr 23 18:18:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08150 for ; Tue, 23 Apr 2002 18:18:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA04200 for midcom-archive@odin.ietf.org; Tue, 23 Apr 2002 18:18:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04068; Tue, 23 Apr 2002 18:16:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04028 for ; Tue, 23 Apr 2002 18:16:32 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08075 for ; Tue, 23 Apr 2002 18:16:26 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g3NMFrH14207; Tue, 23 Apr 2002 18:15:53 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Apr 2002 17:15:48 -0500 Message-ID: <70565611B164D511957A001083FCDD560187025B@va02.va.neustar.com> From: "Peterson, Jon" To: "'Melinda Shore'" Cc: "'midcom@ietf.org'" Subject: RE: [midcom] Working group last call - STUN (security) Date: Tue, 23 Apr 2002 17:15:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org As for whether or not there's a pre-existing relationship between STUN clients and servers - well, I'm just citing midcom-stun-00, and I'm certainly not trying to take a hostile reading. Is there another way the draft should be understood? I think managing key freshness is not that scary when compared with using CMS, considering that: - You might also have to change your STUN domain periodically (for a while there, the average lifespan of a web service provider seems to be about two months) by reconfiguring your client. In some environments, it sounds like people might even want to configure STUN on a per-service basis. In short, I think you will already have to reconfigure STUN clients sometimes. - My various passwords for Internet services change with some regularity without radically inconveniencing me. Whether or not updating a secret is inconvenient is an interface question. STUN servers could probably even push fresh secrets to clients at intervals in a new STUN attribute, if we really felt that we needed some STUN-specific way of keeping keys fresh. - Additionally, certificates also have durations, get revoked, and so on. I assume STUN clients will have support for certificate revocation mechanisms? Using PKI doesn't make these problems go away - it just moves around the pieces a bit. I know this must be getting tiresome, but I feel compelled to place the difficulty of confronting these problems in the perspective of implementing CMS (and at the heart of it, PKI). If even Christian, one of the authors of STUN, is recommending that clients forgo the STUN security mechanism, then I hope you can see why I lean toward an alternative to CMS. I do understand that I seem to be in a minority on this point, though. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Tuesday, April 23, 2002 1:01 PM > To: Peterson, Jon > Cc: 'midcom@ietf.org' > Subject: RE: [midcom] Working group last call - STUN (security) > > > At 01:50 PM 4/23/02 -0500, Peterson, Jon wrote: > >And I must reiterate that midcom-stun-00 already assumes enough of a > >pre-existing relationship that a client is provisioned with the domain of a > >server - and if that's the case, that's all the relationship we need for the > >client to also be provisioned with a shared secret. > > I'm not sure I agree with your basic premise (pre-existing relationships), > and leaving aside, for the moment, scaling issues, key freshness is a serious > issue with manually provisioned shared secrets and one that can't be > addressed in the scenario you describe. > > I think that we can probably agree that we can cut the overhead on the > packet down to adding an HMAC or digest, but the keying problem remains > and I'd really like to focus on that. > > Melinda > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue Apr 23 18:20:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08183 for ; Tue, 23 Apr 2002 18:20:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA04355 for midcom-archive@odin.ietf.org; Tue, 23 Apr 2002 18:20:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04274; Tue, 23 Apr 2002 18:19:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04246 for ; Tue, 23 Apr 2002 18:19:16 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08173 for ; Tue, 23 Apr 2002 18:19:10 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g3NMIhH14258; Tue, 23 Apr 2002 18:18:44 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Apr 2002 17:18:38 -0500 Message-ID: <70565611B164D511957A001083FCDD560187025C@va02.va.neustar.com> From: "Peterson, Jon" To: "'Christian Huitema'" Cc: midcom@ietf.org Subject: RE: [midcom] Working group last call - STUN (security) Date: Tue, 23 Apr 2002 17:18:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org As I suggested in a separate mail, there's no reason to think that a shared secret system necessitates that each STUN client has a unique password; some sort of realm-based system influenced by HTTP Digest could be used, in which instance you would copy the same string into each client in an enterprise, for example. I suspect that in some environments, a configuration manual for an enterprise IT group that names a stun service provider (as you do below) could just as easily name a secret. This once again comes down to the question of why you provision one STUN service provider as opposed to another. The fact that there is a particular STUN service provider that you provision speaks, I believe, to some sort of relationship. Probably you (or the entity you get services from) has a business relationship with the STUN service provider. Or are we assuming that there is, after all, such a thing as a free lunch? If money changes hands, so can secrets. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Tuesday, April 23, 2002 1:07 PM > To: Peterson, Jon; Melinda Shore > Cc: midcom@ietf.org > Subject: RE: [midcom] Working group last call - STUN (security) > > [snip] > > Not true. I can provision the client by copying the same string in each > of them, e.g. "stun.example.com." The string can be copied from a user > manual. Do you suggest to copy the shared secret from that > same manual? > > -- Christian Huitema > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue Apr 23 18:32:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08428 for ; Tue, 23 Apr 2002 18:32:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA05320 for midcom-archive@odin.ietf.org; Tue, 23 Apr 2002 18:32:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA05075; Tue, 23 Apr 2002 18:31:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA05039 for ; Tue, 23 Apr 2002 18:31:09 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08376 for ; Tue, 23 Apr 2002 18:30:58 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3NMUKx10712; Tue, 23 Apr 2002 17:30:21 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2Y3TY8Z0>; Tue, 23 Apr 2002 17:30:19 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E01187AB3@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Melinda Shore'" , "Peterson, Jon" Cc: "'midcom@ietf.org'" Subject: RE: [midcom] Working group last call - STUN (security) Date: Tue, 23 Apr 2002 17:30:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EB16.71DD7030" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1EB16.71DD7030 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Tuesday, April 23, 2002 3:01 PM > > I think that we can probably agree that we can cut the overhead on the > packet down to adding an HMAC or digest, but the keying > problem remains > and I'd really like to focus on that. > Don't our passwords change periodically and doesn't that make it pretty safe if the passwords are properly generated? There's a trade-off between complexity and the amount of goodies you would get in return. ------_=_NextPart_001_01C1EB16.71DD7030 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Working group last call - STUN (security)

> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Tuesday, April 23, 2002 3:01 PM
 
>
> I think that we can probably agree that we can = cut the overhead on the
> packet down to adding an HMAC or digest, but = the keying
> problem remains
> and I'd really like to focus on that.  =
>

Don't our passwords change periodically and doesn't = that make it pretty safe if the passwords are properly generated? = There's a trade-off between complexity and the amount of goodies you = would get in return.

------_=_NextPart_001_01C1EB16.71DD7030-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue Apr 23 18:37:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08555 for ; Tue, 23 Apr 2002 18:37:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA05481 for midcom-archive@odin.ietf.org; Tue, 23 Apr 2002 18:37:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA05412; Tue, 23 Apr 2002 18:35:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA05378 for ; Tue, 23 Apr 2002 18:35:37 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08510 for ; Tue, 23 Apr 2002 18:35:31 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3NMYrx11026; Tue, 23 Apr 2002 17:34:54 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2Y3TY86X>; Tue, 23 Apr 2002 17:34:52 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E01187AB4@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Christian Huitema'" , "Peterson, Jon" , Melinda Shore Cc: midcom@ietf.org Subject: RE: [midcom] Working group last call - STUN (security) Date: Tue, 23 Apr 2002 17:34:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EB17.12C04450" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1EB17.12C04450 Content-Type: text/plain; charset="iso-8859-1" Actually the STUN service provider in many many deployment scenarios will already have a pre-shared secret (password) that it uses to authorize the user for other services. This can re-used by the service provider as a symmetric shared secret for authenticating itself through a Digest-ish mechanism. > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Tuesday, April 23, 2002 3:07 PM > To: Peterson, Jon; Melinda Shore > Cc: midcom@ietf.org > Subject: RE: [midcom] Working group last call - STUN (security) > > > > > > And I must reiterate that midcom-stun-00 already assumes enough of a > > pre-existing relationship that a client is provisioned with > the domain > of > > a > > server - and if that's the case, that's all the relationship we need > for > > the > > client to also be provisioned with a shared secret. > > Not true. I can provision the client by copying the same > string in each > of them, e.g. "stun.example.com." The string can be copied from a user > manual. Do you suggest to copy the shared secret from that > same manual? > > -- Christian Huitema > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C1EB17.12C04450 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Working group last call - STUN (security)

Actually the STUN service provider in many many = deployment scenarios will already have a pre-shared secret (password) = that it uses to authorize the user for other services. This can re-used = by the service provider as a symmetric shared secret for authenticating = itself through a Digest-ish mechanism.

> -----Original Message-----
> From: Christian Huitema [mailto:huitema@windows.mic= rosoft.com]
> Sent: Tuesday, April 23, 2002 3:07 PM
> To: Peterson, Jon; Melinda Shore
> Cc: midcom@ietf.org
> Subject: RE: [midcom] Working group last call - = STUN (security)
>
>
> >
> > And I must reiterate that midcom-stun-00 = already assumes enough of a
> > pre-existing relationship that a client is = provisioned with
> the domain
> of
> > a
> > server - and if that's the case, that's = all the relationship we need
> for
> > the
> > client to also be provisioned with a = shared secret.
>
> Not true. I can provision the client by copying = the same
> string in each
> of them, e.g. "stun.example.com." The = string can be copied from a user
> manual. Do you suggest to copy the shared = secret from that
> same manual?
>
> -- Christian Huitema
>
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C1EB17.12C04450-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue Apr 23 19:16:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09533 for ; Tue, 23 Apr 2002 19:16:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA07432 for midcom-archive@odin.ietf.org; Tue, 23 Apr 2002 19:16:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA07390; Tue, 23 Apr 2002 19:14:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA07361 for ; Tue, 23 Apr 2002 19:14:42 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09495 for ; Tue, 23 Apr 2002 19:14:38 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g3NNE7kL012857; Tue, 23 Apr 2002 16:14:07 -0700 (PDT) Received: from fluffyw2k (dhcp-171-71-249-48.cisco.com [171.71.249.48]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ACS14519; Tue, 23 Apr 2002 16:14:17 -0700 (PDT) From: "Cullen Jennings" To: "Sanjoy Sen" , "'Christian Huitema'" , "Peterson, Jon" , "Melinda Shore" Cc: Date: Tue, 23 Apr 2002 16:14:06 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <933FADF5E673D411B8A30002A5608A0E01187AB4@zrc2c012.us.nortel.com> Content-Transfer-Encoding: 7bit Subject: [midcom] Stun Security using TLS? Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Would someone be willing to propose an strawman email on how we could do this using TLS? _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Apr 24 11:51:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19927 for ; Wed, 24 Apr 2002 11:51:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA10126 for midcom-archive@odin.ietf.org; Wed, 24 Apr 2002 11:51:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09962; Wed, 24 Apr 2002 11:48:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09935 for ; Wed, 24 Apr 2002 11:48:08 -0400 (EDT) Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19866 for ; Wed, 24 Apr 2002 11:48:03 -0400 (EDT) From: James_Renkel@3com.com Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3OFm5322278 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 24 Apr 2002 08:48:05 -0700 (PDT) Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79]) by opal.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3OFm4O18630; Wed, 24 Apr 2002 08:48:05 -0700 (PDT) Subject: RE: [midcom] Working group last call - STUN (security) To: "Peterson, Jon" Cc: "'Melinda Shore'" , "'midcom@ietf.org'" Date: Wed, 24 Apr 2002 10:47:55 -0500 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Jon, Whether we are a minority or not, I stand with you, at least on the issue of the CMS for STUN being overkill. Aside from pure STUN issues, I am also concerned about possibly setting a precedent for MIDCOM. I may disagree with you on other things, but this one I'm with ya. I had not chimed in until now because you so eloquently and accurately expressed my thoughts. :-) Jim "Peterson, Jon" @ietf.org on 04/23/2002 05:15:46 PM Sent by: midcom-admin@ietf.org To: "'Melinda Shore'" cc: "'midcom @ietf.org'" Subject: RE: [midcom] Working group last call - STUN (security) As for whether or not there's a pre-existing relationship between STUN clients and servers - well, I'm just citing midcom-stun-00, and I'm certainly not trying to take a hostile reading. Is there another way the draft should be understood? I think managing key freshness is not that scary when compared with using CMS, considering that: - You might also have to change your STUN domain periodically (for a while there, the average lifespan of a web service provider seems to be about two months) by reconfiguring your client. In some environments, it sounds like people might even want to configure STUN on a per-service basis. In short, I think you will already have to reconfigure STUN clients sometimes. - My various passwords for Internet services change with some regularity without radically inconveniencing me. Whether or not updating a secret is inconvenient is an interface question. STUN servers could probably even push fresh secrets to clients at intervals in a new STUN attribute, if we really felt that we needed some STUN-specific way of keeping keys fresh. - Additionally, certificates also have durations, get revoked, and so on. I assume STUN clients will have support for certificate revocation mechanisms? Using PKI doesn't make these problems go away - it just moves around the pieces a bit. I know this must be getting tiresome, but I feel compelled to place the difficulty of confronting these problems in the perspective of implementing CMS (and at the heart of it, PKI). If even Christian, one of the authors of STUN, is recommending that clients forgo the STUN security mechanism, then I hope you can see why I lean toward an alternative to CMS. I do understand that I seem to be in a minority on this point, though. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Tuesday, April 23, 2002 1:01 PM > To: Peterson, Jon > Cc: 'midcom@ietf.org' > Subject: RE: [midcom] Working group last call - STUN (security) > > > At 01:50 PM 4/23/02 -0500, Peterson, Jon wrote: > >And I must reiterate that midcom-stun-00 already assumes enough of a > >pre-existing relationship that a client is provisioned with the domain of a > >server - and if that's the case, that's all the relationship we need for the > >client to also be provisioned with a shared secret. > > I'm not sure I agree with your basic premise (pre-existing relationships), > and leaving aside, for the moment, scaling issues, key freshness is a serious > issue with manually provisioned shared secrets and one that can't be > addressed in the scenario you describe. > > I think that we can probably agree that we can cut the overhead on the > packet down to adding an HMAC or digest, but the keying problem remains > and I'd really like to focus on that. > > Melinda > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Apr 24 11:57:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20048 for ; Wed, 24 Apr 2002 11:57:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA10473 for midcom-archive@odin.ietf.org; Wed, 24 Apr 2002 11:57:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10287; Wed, 24 Apr 2002 11:55:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10258 for ; Wed, 24 Apr 2002 11:55:20 -0400 (EDT) Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19962 for ; Wed, 24 Apr 2002 11:55:16 -0400 (EDT) From: James_Renkel@3com.com Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3OFtI323329 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 24 Apr 2002 08:55:19 -0700 (PDT) Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79]) by opal.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3OFtHO20224; Wed, 24 Apr 2002 08:55:18 -0700 (PDT) Subject: RE: [midcom] Working group last call - STUN (security) To: "Christian Huitema" Cc: "Peterson, Jon" , "Melinda Shore" , Date: Wed, 24 Apr 2002 10:55:07 -0500 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Depends on the manual. A free, public STUN service (I do hope there will be such things!) might still require a password for some reason, but publish it for all the world to know. Similarly, company internal "setup" information on services that the company has contracted for often includes, e.g., access passwords. Do we need some explicitly stated requriements here so that we can evaluate alternatives and otherwise guide our thoughts and discussions? Jim "Christian Huitema" @ietf.org on 04/23/2002 03:07:24 PM Sent by: midcom-admin@ietf.org To: "Peterson, Jon" , "Melinda Shore" cc: Subject: RE: [midcom] Working group last call - STUN (security) > > And I must reiterate that midcom-stun-00 already assumes enough of a > pre-existing relationship that a client is provisioned with the domain of > a > server - and if that's the case, that's all the relationship we need for > the > client to also be provisioned with a shared secret. Not true. I can provision the client by copying the same string in each of them, e.g. "stun.example.com." The string can be copied from a user manual. Do you suggest to copy the shared secret from that same manual? -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Apr 24 12:06:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20445 for ; Wed, 24 Apr 2002 12:06:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12565 for midcom-archive@odin.ietf.org; Wed, 24 Apr 2002 12:06:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12443; Wed, 24 Apr 2002 12:05:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12414 for ; Wed, 24 Apr 2002 12:04:58 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20379 for ; Wed, 24 Apr 2002 12:04:54 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g3OG4Mp6014274; Wed, 24 Apr 2002 09:04:22 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADQ41809; Wed, 24 Apr 2002 09:01:43 -0700 (PDT) Message-Id: <5.1.0.14.0.20020424120237.00abd2e0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 24 Apr 2002 12:08:35 -0400 To: From: Melinda Shore Subject: RE: [midcom] Working group last call - STUN (security) Cc: "'midcom@ietf.org'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 10:47 AM 4/24/02 -0500, James_Renkel@3com.com wrote: >Whether we are a minority or not, I stand with you, at least on the >issue of the CMS for STUN being overkill. Aside from pure STUN issues, >I am also concerned about possibly setting a precedent for MIDCOM. I'm more concerned about following an unfortunate precedent, namely that because security is inconvenient we punt and let the users deal with the consequences. At this point it would be helpful to hear alternative proposals that do not assume a pre-existing relationship between a server and a client. We can do it without CMS, but the nature of the problem is such that we can't do it without involving some sort of trust broker. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Wed Apr 24 13:49:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00907 for ; Wed, 24 Apr 2002 13:49:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA19758 for midcom-archive@odin.ietf.org; Wed, 24 Apr 2002 13:49:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19193; Wed, 24 Apr 2002 13:41:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19159 for ; Wed, 24 Apr 2002 13:41:23 -0400 (EDT) Received: from carbon.btinternet.com (carbon.btinternet.com [194.73.73.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00507 for ; Wed, 24 Apr 2002 13:41:15 -0400 (EDT) Received: from host213-122-126-70.in-addr.btopenworld.com ([213.122.126.70] helo=tkw) by carbon.btinternet.com with smtp (Exim 3.22 #8) id 170QlB-0000bq-00; Wed, 24 Apr 2002 18:40:53 +0100 Message-ID: <000901c1ebb7$5c072840$0200000a@tkw> From: "Pete Cordell" To: "Cullen Jennings" , "Sanjoy Sen" , "'Christian Huitema'" , "Peterson, Jon" , "Melinda Shore" Cc: References: Subject: Re: [midcom] Stun Security using TLS? Date: Wed, 24 Apr 2002 18:41:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Thinking aloud (i.e. without thinking it through!) another alternative would be to devise a scheme that allowed a client to test a mapping. For example, it might be able to open another socket, and send a packet to the mapped address. In theory this ought exit the NAT and loop back in on the NATted address and be sent back to the client. If the client gets it back, it knows the mapping is genuine. I recall that someone (possible Christian) said that NATs don't generally support this type of loop back. Is there another way of doing it? I considered echo, but that doesn't seem to be widely deployed. Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: "Cullen Jennings" To: "Sanjoy Sen" ; "'Christian Huitema'" ; "Peterson, Jon" ; "Melinda Shore" Cc: Sent: 24 April 2002 00:14 Subject: [midcom] Stun Security using TLS? > > Would someone be willing to propose an strawman email on how we could do > this using TLS? > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Wed Apr 24 15:55:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05560 for ; Wed, 24 Apr 2002 15:55:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA27203 for midcom-archive@odin.ietf.org; Wed, 24 Apr 2002 15:55:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27119; Wed, 24 Apr 2002 15:52:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27088 for ; Wed, 24 Apr 2002 15:52:56 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05511 for ; Wed, 24 Apr 2002 15:52:52 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g3OJqOpY021112; Wed, 24 Apr 2002 12:52:24 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADQ50895; Wed, 24 Apr 2002 12:49:45 -0700 (PDT) Message-Id: <5.1.0.14.0.20020424155001.00a96bf0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 24 Apr 2002 15:56:45 -0400 To: James_Renkel@3com.com From: Melinda Shore Subject: RE: [midcom] Working group last call - STUN (security) Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 10:55 AM 4/24/02 -0500, James_Renkel@3com.com wrote: >A free, public STUN service (I do hope there >will be such things!) might still require a password for some reason, >but publish it for all the world to know. A free, public STUN service is the one we need to be most concerned about authenticating. When you talk about publishing it for all the world to know you're necessarily talking about asymmetric crypto which brings us back to where we are. ssh- style host keys may be one approach but it's too easy to get people who should know better to blindly accept new keys. I am not ordinarily much of a fan of PGP, but this may be an appropriate application (depending on its current status and on the availability of trustworthy key servers). Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 25 03:08:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28031 for ; Thu, 25 Apr 2002 03:08:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA12230 for midcom-archive@odin.ietf.org; Thu, 25 Apr 2002 03:08:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12114; Thu, 25 Apr 2002 03:06:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12082 for ; Thu, 25 Apr 2002 03:05:52 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28023 for ; Thu, 25 Apr 2002 03:05:49 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g3P75LpY003036; Thu, 25 Apr 2002 00:05:21 -0700 (PDT) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ACS49279; Thu, 25 Apr 2002 00:05:32 -0700 (PDT) From: "Cullen Jennings" To: "Peterson, Jon" , "'Melinda Shore'" , Subject: RE: [midcom] Working group last call - STUN (security) Date: Thu, 25 Apr 2002 00:05:51 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <70565611B164D511957A001083FCDD5601870253@va02.va.neustar.com> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit I am greatly in favor of finding a simpler scheme to solve this stuff. I went and tried to implement the CMS stuff before the last IETF and I gave up. It's not simple even if you have an S/MINE library. I predict many people will choose to live dangerously with the current scheme. I hope I am wrong. One point I wanted to mention is that general security would suggest we figure out what we are protecting against. There has not been much discussion on this. If the string to provision a STUN client was in the form user:password@host.domain would it make anyone feel any better? Is this much different than, say, imap or pop. Is there any merit to something like using TLS to get a one time or short lived password from the stun server for an anonymous user then use this as the shared secret for a digest based STUN? I understand that in theory this may not be too much different to implement than CMS but given the stuff already in place, it might be different in practice. Cullen _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 25 07:17:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01100 for ; Thu, 25 Apr 2002 07:17:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA25757 for midcom-archive@odin.ietf.org; Thu, 25 Apr 2002 07:17:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25615; Thu, 25 Apr 2002 07:15:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25583 for ; Thu, 25 Apr 2002 07:15:31 -0400 (EDT) Received: from carbon.btinternet.com (carbon.btinternet.com [194.73.73.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01057 for ; Thu, 25 Apr 2002 07:15:23 -0400 (EDT) Received: from host213-122-154-114.in-addr.btopenworld.com ([213.122.154.114] helo=tkw) by carbon.btinternet.com with smtp (Exim 3.22 #8) id 170hDL-0003iB-00; Thu, 25 Apr 2002 12:15:04 +0100 Message-ID: <002a01c1ec4a$a0080620$0200000a@tkw> From: "Pete Cordell" To: "Pete Cordell" , "Cullen Jennings" , "Sanjoy Sen" , "'Christian Huitema'" , "Peterson, Jon" , "Melinda Shore" Cc: References: <000901c1ebb7$5c072840$0200000a@tkw> Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN Date: Thu, 25 Apr 2002 12:00:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit In addition to my suggestion of enabling the client to be able to test the address that it has been given, it has been pointed out to me that the client could simply check that the address that it has been given seems reasonable (i.e. it corresponds to one of the public addresses of the organisation.) This would work well for fixed devices as the valid set of addresses can be configured at installation time along with the domain. For mobile users using hotel and airport NATs, there seems scope for getting the information from DHCP and DNS at the same time as trying to find out the location of the STUN server, but there might need to be a little more work here. These methods are orders of magnitude simpler than using CMS, and much more in tune with the scale of STUN. While they don't offer quite the same protection, in some aspects they offer less, and others they offer more. Therefore, I believe it's worth considering these options. (Sometimes if you find a big obstacle its best to try and find a way round it, rather than trying to smash your way through it!) Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: "Pete Cordell" To: "Cullen Jennings" ; "Sanjoy Sen" ; "'Christian Huitema'" ; "Peterson, Jon" ; "Melinda Shore" Cc: Sent: 24 April 2002 18:41 Subject: Re: [midcom] Stun Security using TLS? > Thinking aloud (i.e. without thinking it through!) another alternative would > be to devise a scheme that allowed a client to test a mapping. > > For example, it might be able to open another socket, and send a packet to > the mapped address. In theory this ought exit the NAT and loop back in on > the NATted address and be sent back to the client. If the client gets it > back, it knows the mapping is genuine. > > I recall that someone (possible Christian) said that NATs don't generally > support this type of loop back. Is there another way of doing it? I > considered echo, but that doesn't seem to be widely deployed. > > Pete. > > ============================================= > Pete Cordell > Tech-Know-Ware > pete@tech-know-ware.com > +44 1473 635863 > ============================================= > > ----- Original Message ----- > From: "Cullen Jennings" > To: "Sanjoy Sen" ; "'Christian Huitema'" > ; "Peterson, Jon" ; > "Melinda Shore" > Cc: > Sent: 24 April 2002 00:14 > Subject: [midcom] Stun Security using TLS? > > > > > > Would someone be willing to propose an strawman email on how we could do > > this using TLS? > > > > > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 25 08:28:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03267 for ; Thu, 25 Apr 2002 08:28:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA02328 for midcom-archive@odin.ietf.org; Thu, 25 Apr 2002 08:29:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01985; Thu, 25 Apr 2002 08:24:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01936 for ; Thu, 25 Apr 2002 08:24:01 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02976; Thu, 25 Apr 2002 08:23:57 -0400 (EDT) Message-Id: <200204251223.IAA02976@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 25 Apr 2002 08:23:57 -0400 Subject: [midcom] I-D ACTION:draft-quittek-midcom-snmp-eval-00.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using SNMP as Midcom Protocol Author(s) : J. Quittek Filename : draft-quittek-midcom-snmp-eval-00.txt Pages : 9 Date : 24-Apr-02 This memo evaluates the Simple Network Management Protocol (SNMP) as a candidate for realizing a Midcom protocol. The properties and capabilities of the SNMP management framework are compared to the Midcom requirements [MDC-REQ] and to the Midcom framework and architecture [MDC-FRM]. It is shown that SNMP matches almost all Midcom requirements and that with the already existing support for NATs [NAT-MIB] only little additional effort is required for creating a Midcom protocol solution based on the SNMP management framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-quittek-midcom-snmp-eval-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-quittek-midcom-snmp-eval-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-quittek-midcom-snmp-eval-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020424105241.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-quittek-midcom-snmp-eval-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-quittek-midcom-snmp-eval-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020424105241.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 25 09:28:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05163 for ; Thu, 25 Apr 2002 09:28:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA06233 for midcom-archive@odin.ietf.org; Thu, 25 Apr 2002 09:27:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05705; Thu, 25 Apr 2002 09:16:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05661 for ; Thu, 25 Apr 2002 09:16:35 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04869 for ; Thu, 25 Apr 2002 09:16:32 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g3PDG4p6023378; Thu, 25 Apr 2002 06:16:04 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADQ70068; Thu, 25 Apr 2002 06:13:24 -0700 (PDT) Message-Id: <5.1.0.14.0.20020425091616.00a9ce20@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 25 Apr 2002 09:20:25 -0400 To: "Cullen Jennings" From: Melinda Shore Subject: RE: [midcom] Working group last call - STUN (security) Cc: midcom@ietf.org In-Reply-To: References: <70565611B164D511957A001083FCDD5601870253@va02.va.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 12:05 AM 4/25/02 -0700, Cullen Jennings wrote: >Is there any merit to something like using TLS to get a one time or short >lived password from the stun server for an anonymous user then use this as >the shared secret for a digest based STUN? I think something like this may be the best approach, which is why I suggested using an authenticated Diffie-Helman the other day. TLS may be overkill for this application, but there's a tradeoff here between time-to-implement and on-the-wire performance. Given that STUN is intended to be a short-lived, stopgap protocol we may choose to come down more on the side of time-to-implement. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 25 10:45:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07827 for ; Thu, 25 Apr 2002 10:45:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA11834 for midcom-archive@odin.ietf.org; Thu, 25 Apr 2002 10:45:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11409; Thu, 25 Apr 2002 10:35:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11373 for ; Thu, 25 Apr 2002 10:35:24 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07411 for ; Thu, 25 Apr 2002 10:35:18 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g3PEYOpY012735; Thu, 25 Apr 2002 07:34:24 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADQ71359; Thu, 25 Apr 2002 07:31:47 -0700 (PDT) Message-Id: <5.1.0.14.0.20020425103552.00a955f0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 25 Apr 2002 10:38:47 -0400 To: From: Melinda Shore Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 10:11 AM 4/25/02 -0400, Tom_Gray@Mitel.COM wrote: >Is there any reason that this 'address-reasonableness' test could not >defined at least as an option. I can see its utility especially in >enterprise sites that will be implementing their own STUN servers It doesn't require protocol changes. I have to note that, to a large extent, enterprise sites implementing their own servers somewhat defeats the purpose of the protocol. Otherwise it's just a somewhat gooby, kludgy midcom. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 25 10:56:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08246 for ; Thu, 25 Apr 2002 10:56:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA12408 for midcom-archive@odin.ietf.org; Thu, 25 Apr 2002 10:56:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11923; Thu, 25 Apr 2002 10:48:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11895 for ; Thu, 25 Apr 2002 10:48:08 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07928 for ; Thu, 25 Apr 2002 10:48:04 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3PElZG17374 for ; Thu, 25 Apr 2002 09:47:35 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2Y3TZV8Y>; Thu, 25 Apr 2002 09:47:11 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A03DE3A3C@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'midcom@ietf.org'" Date: Thu, 25 Apr 2002 09:46:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EC67.ECEB8850" Subject: [midcom] Please Review: Protocol Evaluation Documents available Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1EC67.ECEB8850 Content-Type: text/plain; charset="iso-8859-1" Hi, Just a reminder that we are in the middle of our review process for the individual protocol evaluation documents. This is your opportunity to influence the protocol evaluations such that we have as objective of an analysis as possible going into the amalgamated WG Protocol Evaluation document. There's been one round of comments on 3 of the drafts (Thanks!), however, to ensure that everyone sees them all, I've summarized the links below: SNMP Prime: Juergen Quittek [quittek@ccrle.nec.de]: http://www.ietf.org/internet-drafts/draft-quittek-midcom-snmp-eval-00.txt DIAMETER Prime: Tom Taylor [taylor@nortelnetworks.com] http://www.ietf.org/internet-drafts/draft-taylor-midcom-diameter-eval-00.txt RSIP Prime: James Renkel [James_Renkel@3com.com] http://www.ietf.org/internet-drafts/draft-renkel-rsip-midcom-eval-00.txt MEGACO Prime: Sanjoy Sen [sanjoy@nortelnetworks.com] http://www.ietf.org/internet-drafts/draft-sct-midcom-megaco-01.txt COPS Prime: Kwok Ho Chan [khchan@NortelNetworks.com] http://www.ietf.org/internet-drafts/draft-aoun-midcom-cops-01.txt Just a note that rather than fill the list with editorial nits, I will be doing an editorial review and will be sending that feedback directly to the authors. For this phase of the protocol evaluation process, the following are the deadlines: ---------------------------------------------------------------------------- ----- Now-May 3rd Mailing list discussion of specific protocol drafts, allowing authors to incorporate WG feedback into their contribution to improve comparison and add completeness. May 10th Deadline for any updates to protocol drafts. Regards, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 ------_=_NextPart_001_01C1EC67.ECEB8850 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please Review: Protocol Evaluation Documents available

Hi,

Just a reminder that we are in the middle of our = review process for the individual protocol evaluation documents. This = is your opportunity to influence the protocol evaluations such that we = have as objective of an analysis as possible going into the amalgamated = WG Protocol Evaluation document.

There's been one round of comments on 3 of the drafts = (Thanks!), however, to ensure that everyone sees them all, I've = summarized the links below:

SNMP Prime: Juergen Quittek = [quittek@ccrle.nec.de]:
http://www.ietf.org/internet-drafts/draft-quittek-midc= om-snmp-eval-00.txt

DIAMETER Prime: Tom Taylor = [taylor@nortelnetworks.com]
http://www.ietf.org/internet-drafts/draft-taylor-midco= m-diameter-eval-00.txt

RSIP Prime: James Renkel = [James_Renkel@3com.com]
http://www.ietf.org/internet-drafts/draft-renkel-rsip-= midcom-eval-00.txt

MEGACO Prime: Sanjoy Sen [sanjoy@nortelnetworks.com] =
http://www.ietf.org/internet-drafts/draft-sct-midcom-m= egaco-01.txt

COPS Prime: Kwok Ho Chan = [khchan@NortelNetworks.com]
http://www.ietf.org/internet-drafts/draft-aoun-midcom-= cops-01.txt


Just a note that rather than fill the list with = editorial nits, I will be doing an editorial review and will be sending = that feedback directly to the authors.

For this phase of the protocol evaluation process, = the following are the deadlines:

---------------------------------------------------------------= ------------------

Now-May 3rd     Mailing list = discussion of specific
          &nb= sp;     protocol drafts, allowing authors to
          &nb= sp;     incorporate WG feedback into their  =
          &nb= sp;     contribution to improve comparison and =
          &nb= sp;     add completeness.

May 10th        = Deadline for any updates to protocol drafts.


Regards,
Mary H. Barnes
mbarnes@nortelnetworks.com
972-684-5432
Wireless 817-703-4806

------_=_NextPart_001_01C1EC67.ECEB8850-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 25 11:00:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08389 for ; Thu, 25 Apr 2002 11:00:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA12568 for midcom-archive@odin.ietf.org; Thu, 25 Apr 2002 11:00:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12129; Thu, 25 Apr 2002 10:51:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12100 for ; Thu, 25 Apr 2002 10:51:14 -0400 (EDT) Received: from Mitel.COM ([216.191.234.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08081 for ; Thu, 25 Apr 2002 10:51:10 -0400 (EDT) From: Tom_Gray@Mitel.COM Received: from kanmta01.mitel.com (kanmta01.kanata.mitel.com [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id KAA07672; Thu, 25 Apr 2002 10:23:47 -0400 (EDT) Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN To: "Pete Cordell" Cc: "Pete Cordell" , "Cullen Jennings" , "Sanjoy Sen" , "'Christian Huitema'" , "Peterson, Jon" , "Melinda Shore" , Date: Thu, 25 Apr 2002 10:11:39 -0400 Message-ID: X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.7 |March 21, 2001) at 04/25/2002 10:23:47 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Is there any reason that this 'address-reasonableness' test could not defined at least as an option. I can see its utility especially in enterprise sites that will be implementing their own STUN servers "Pete Cordell" @ietf.org on 04/25/2002 07:00:01 AM Sent by: midcom-admin@ietf.org To: "Pete Cordell" , "Cullen Jennings" , "Sanjoy Sen" , "'Christian Huitema'" , "Peterson, Jon" , "Melinda Shore" cc: Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN In addition to my suggestion of enabling the client to be able to test the address that it has been given, it has been pointed out to me that the client could simply check that the address that it has been given seems reasonable (i.e. it corresponds to one of the public addresses of the organisation.) This would work well for fixed devices as the valid set of addresses can be configured at installation time along with the domain. For mobile users using hotel and airport NATs, there seems scope for getting the information from DHCP and DNS at the same time as trying to find out the location of the STUN server, but there might need to be a little more work here. These methods are orders of magnitude simpler than using CMS, and much more in tune with the scale of STUN. While they don't offer quite the same protection, in some aspects they offer less, and others they offer more. Therefore, I believe it's worth considering these options. (Sometimes if you find a big obstacle its best to try and find a way round it, rather than trying to smash your way through it!) Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: "Pete Cordell" To: "Cullen Jennings" ; "Sanjoy Sen" ; "'Christian Huitema'" ; "Peterson, Jon" ; "Melinda Shore" Cc: Sent: 24 April 2002 18:41 Subject: Re: [midcom] Stun Security using TLS? > Thinking aloud (i.e. without thinking it through!) another alternative would > be to devise a scheme that allowed a client to test a mapping. > > For example, it might be able to open another socket, and send a packet to > the mapped address. In theory this ought exit the NAT and loop back in on > the NATted address and be sent back to the client. If the client gets it > back, it knows the mapping is genuine. > > I recall that someone (possible Christian) said that NATs don't generally > support this type of loop back. Is there another way of doing it? I > considered echo, but that doesn't seem to be widely deployed. > > Pete. > > ============================================= > Pete Cordell > Tech-Know-Ware > pete@tech-know-ware.com > +44 1473 635863 > ============================================= > > ----- Original Message ----- > From: "Cullen Jennings" > To: "Sanjoy Sen" ; "'Christian Huitema'" > ; "Peterson, Jon" ; > "Melinda Shore" > Cc: > Sent: 24 April 2002 00:14 > Subject: [midcom] Stun Security using TLS? > > > > > > Would someone be willing to propose an strawman email on how we could do > > this using TLS? > > > > > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 25 11:11:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08848 for ; Thu, 25 Apr 2002 11:11:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA13401 for midcom-archive@odin.ietf.org; Thu, 25 Apr 2002 11:11:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13073; Thu, 25 Apr 2002 11:02:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13042 for ; Thu, 25 Apr 2002 11:02:51 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08530 for ; Thu, 25 Apr 2002 11:02:47 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g3PF2Jp6015400 for ; Thu, 25 Apr 2002 08:02:20 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADQ71937; Thu, 25 Apr 2002 07:59:38 -0700 (PDT) Message-Id: <5.1.0.14.0.20020425110415.00a940a0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 25 Apr 2002 11:06:38 -0400 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] STUN last call stopped Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At this point it's pretty clear that there are enough serious objections to the use of CMS for it to be impossible to send the document on to the IESG. However, objection is not enough - we need alternate proposals in sufficient detail to be closely evaluated and ultimately included in the STUN draft. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 25 12:19:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26071 for ; Thu, 25 Apr 2002 12:19:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA19367 for midcom-archive@odin.ietf.org; Thu, 25 Apr 2002 12:19:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17025; Thu, 25 Apr 2002 12:00:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16846 for ; Thu, 25 Apr 2002 12:00:18 -0400 (EDT) Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24732 for ; Thu, 25 Apr 2002 12:00:13 -0400 (EDT) Received: from host213-122-105-200.in-addr.btopenworld.com ([213.122.105.200] helo=tkw) by tungsten.btinternet.com with smtp (Exim 3.22 #8) id 170lfG-00022Z-00; Thu, 25 Apr 2002 17:00:11 +0100 Message-ID: <004601c1ec72$73c67f60$0200000a@tkw> From: "Pete Cordell" To: , "Melinda Shore" Cc: References: <5.1.0.14.0.20020425103552.00a955f0@localhost> Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN Date: Thu, 25 Apr 2002 16:57:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Melinda Shore" > At 10:11 AM 4/25/02 -0400, Tom_Gray@Mitel.COM wrote: > >Is there any reason that this 'address-reasonableness' test could not > >defined at least as an option. I can see its utility especially in > >enterprise sites that will be implementing their own STUN servers > > It doesn't require protocol changes. That surely doesn't prevent it from being included in a security considerations section. In many respects running protocols over TLS doesn't change the protocols themselves, but the issue is still discussed. > > I have to note that, to a large extent, enterprise sites implementing > their own servers somewhat defeats the purpose of the protocol. > Otherwise it's just a somewhat gooby, kludgy midcom. It's simple and effective, and will probably achieve 90% of what can be achieved with a CMS or TLS solution. For something that is so much simpler than the other candidates, it needs slightly more consideration than simply saying that it's gooby. Rome wasn't built in a day. Who knows, Rome might have been gooby in the beginning also. > > Melinda > Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 25 12:24:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26209 for ; Thu, 25 Apr 2002 12:24:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA19719 for midcom-archive@odin.ietf.org; Thu, 25 Apr 2002 12:24:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19343; Thu, 25 Apr 2002 12:18:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19315 for ; Thu, 25 Apr 2002 12:18:33 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25984 for ; Thu, 25 Apr 2002 12:18:29 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g3PGI1p6009365; Thu, 25 Apr 2002 09:18:01 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADQ73981; Thu, 25 Apr 2002 09:15:23 -0700 (PDT) Message-Id: <5.1.0.14.0.20020425122039.00aa18f0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 25 Apr 2002 12:22:22 -0400 To: "Pete Cordell" From: Melinda Shore Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN Cc: In-Reply-To: <004601c1ec72$73c67f60$0200000a@tkw> References: <5.1.0.14.0.20020425103552.00a955f0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 04:57 PM 4/25/02 +0100, Pete Cordell wrote: >For something that is so much simpler than the other candidates, it needs >slightly more consideration than simply saying that it's gooby. Rome wasn't >built in a day. Who knows, Rome might have been gooby in the beginning >also. I was referring to enterprises running their own STUN servers. At any rate, while what you're proposing is a good idea in certain deployments it's not a substitute for securing the STUN protocol, which we *must* do. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 25 12:32:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26541 for ; Thu, 25 Apr 2002 12:32:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA20737 for midcom-archive@odin.ietf.org; Thu, 25 Apr 2002 12:32:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19878; Thu, 25 Apr 2002 12:27:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19409 for ; Thu, 25 Apr 2002 12:20:09 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26090 for ; Thu, 25 Apr 2002 12:20:05 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g3PGJaTG017531; Thu, 25 Apr 2002 09:19:37 -0700 (PDT) Received: from localhost (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACX76689; Thu, 25 Apr 2002 09:19:35 -0700 (PDT) Date: Thu, 25 Apr 2002 09:16:32 -0700 (Pacific Daylight Time) From: Rohan Mahy To: midcom@ietf.org cc: mbarnes@nortelnetworks.com Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [midcom] Protocol Eval Documents Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Hi, Are we going to also compare the "existing protocol" approaches with just rolling our own on top of a reliable transport (TCP or TLS). I think there are/were two or three concrete proposals. Just browsing through the archives, I found these: http://www.ietf.org/internet-drafts/draft-stiemerling-midcom-simco-00.txt http://www.ietf.org/internet-drafts/draft-bryan-midcom-simple-strawman-00.txt plus I know of Jiri Kuthan's FCP, which I don't think was ever submitted as an ID. thanks, -rohan To: "'midcom@ietf.org'" Subject: [midcom] Please Review: Protocol Evaluation Documents available From: "Mary Barnes" Date: Thu, 25 Apr 2002 09:46:04 -0500 List-Id: Sender: midcom-admin@ietf.org -------------------------------------------------------------------------------- Title: Please Review: Protocol Evaluation Documents available Hi, Just a reminder that we are in the middle of our review process for the individual protocol evaluation documents. This is your opportunity to influence the protocol evaluations such that we have as objective of an analysis as possible going into the amalgamated WG Protocol Evaluation document. There's been one round of comments on 3 of the drafts (Thanks!), however, to ensure that everyone sees them all, I've summarized the links below: SNMP Prime: Juergen Quittek [quittek@ccrle.nec.de]: http://www.ietf.org/internet-drafts/draft-quittek-midcom-snmp-eval-00.txt DIAMETER Prime: Tom Taylor [taylor@nortelnetworks.com] http://www.ietf.org/internet-drafts/draft-taylor-midcom-diameter-eval-00.txt RSIP Prime: James Renkel [James_Renkel@3com.com] http://www.ietf.org/internet-drafts/draft-renkel-rsip-midcom-eval-00.txt MEGACO Prime: Sanjoy Sen [sanjoy@nortelnetworks.com] http://www.ietf.org/internet-drafts/draft-sct-midcom-megaco-01.txt COPS Prime: Kwok Ho Chan [khchan@NortelNetworks.com] http://www.ietf.org/internet-drafts/draft-aoun-midcom-cops-01.txt Just a note that rather than fill the list with editorial nits, I will be doing an editorial review and will be sending that feedback directly to the authors. For this phase of the protocol evaluation process, the following are the deadlines: --------------------------------------------------------------------------------- Now-May 3rd Mailing list discussion of specific protocol drafts, allowing authors to incorporate WG feedback into their contribution to improve comparison and add completeness. May 10th Deadline for any updates to protocol drafts. Regards, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 25 12:40:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26749 for ; Thu, 25 Apr 2002 12:40:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA21251 for midcom-archive@odin.ietf.org; Thu, 25 Apr 2002 12:40:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20908; Thu, 25 Apr 2002 12:35:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20868 for ; Thu, 25 Apr 2002 12:35:33 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26630 for ; Thu, 25 Apr 2002 12:35:30 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3PGYTTZ029204; Thu, 25 Apr 2002 09:34:29 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADQ74609; Thu, 25 Apr 2002 09:31:49 -0700 (PDT) Message-Id: <5.1.0.14.0.20020425123425.00aa44b0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 25 Apr 2002 12:38:48 -0400 To: Rohan Mahy , midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] Protocol Eval Documents In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 09:16 AM 4/25/02 -0700, Rohan Mahy wrote: >Are we going to also compare the "existing protocol" approaches with just >rolling our own on top of a reliable transport (TCP or TLS). The charter sez: The working group will evaluate existing IETF protocols for their applicability to this problem, using the framework and requirements documents developed during the working group's first phase as criteria for the evaluation. If a protocol is found to be suitable it will be used as the basis for the development of a middlebox communication protocol. In the unlikely case that one is not found to be suitable, the working group will undertake development of a new protocol. Also, whether we find an existing protocol or end up having to roll our own, I hope that we won't restrict ourselves to TCP for transport. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 25 13:16:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28101 for ; Thu, 25 Apr 2002 13:16:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24262 for midcom-archive@odin.ietf.org; Thu, 25 Apr 2002 13:16:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23962; Thu, 25 Apr 2002 13:11:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23931 for ; Thu, 25 Apr 2002 13:11:48 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27925 for ; Thu, 25 Apr 2002 13:11:45 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g3PHAaH01532; Thu, 25 Apr 2002 13:10:36 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Apr 2002 12:10:31 -0500 Message-ID: <70565611B164D511957A001083FCDD560187027F@va02.va.neustar.com> From: "Peterson, Jon" To: "'Melinda Shore'" , Cullen Jennings Cc: midcom@ietf.org Subject: RE: [midcom] Working group last call - STUN (security) Date: Thu, 25 Apr 2002 12:10:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This is closer to what I'd personally like to see, in so far as it takes the burden of PKI off of STUN itself. But I would probably stop short of making such a TLS password-download mechanism mandatory. There are at least two cases I can think of that are meaningful STUN architectures which wouldn't require any password download: - Simple pre-configuration of secret - meaningful for enterprise STUN servers - Secret is passed by the application-layer protocol (for example, in a SIP response header) for whose sake STUN is invoked, which presumably has its own security, probably PKI-based - meaningful for STUN servers that are operated by the provider of the application-layer service So, I wouldn't object to allowing TLS (or something similar) as a way of downloading a secret from a STUN server, as long as it is a MAY to implement, it is separate from the remainder of the STUN protocol. STUN itself has no need to become a secret-discovery protocol. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Thursday, April 25, 2002 6:20 AM > To: Cullen Jennings > Cc: midcom@ietf.org > Subject: RE: [midcom] Working group last call - STUN (security) > > > At 12:05 AM 4/25/02 -0700, Cullen Jennings wrote: > >Is there any merit to something like using TLS to get a one time or short > >lived password from the stun server for an anonymous user then use this as > >the shared secret for a digest based STUN? > > I think something like this may be the best approach, which is > why I suggested using an authenticated Diffie-Helman the other > day. TLS may be overkill for this application, but there's > a tradeoff here between time-to-implement and on-the-wire performance. > Given that STUN is intended to be a short-lived, stopgap protocol > we may choose to come down more on the side of time-to-implement. > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 25 13:18:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28126 for ; Thu, 25 Apr 2002 13:18:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24338 for midcom-archive@odin.ietf.org; Thu, 25 Apr 2002 13:18:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24094; Thu, 25 Apr 2002 13:13:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24067 for ; Thu, 25 Apr 2002 13:13:19 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27988 for ; Thu, 25 Apr 2002 13:13:16 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g3PHCmH01608 for ; Thu, 25 Apr 2002 13:12:48 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Apr 2002 12:12:43 -0500 Message-ID: <70565611B164D511957A001083FCDD5601870281@va02.va.neustar.com> From: "Peterson, Jon" To: "'midcom@ietf.org'" Subject: FW: [midcom] STUN last call stopped Date: Thu, 25 Apr 2002 12:12:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I would be happy to flesh out (in spec language) some of the Digest-based ideas I described in my earlier mails, if the working group is interested in entertaining them. Perhaps it would be appropriate to set a (short) schedule in which such new proposals should be formulated? Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Thursday, April 25, 2002 8:07 AM > To: midcom@ietf.org > Subject: [midcom] STUN last call stopped > > > At this point it's pretty clear that there are enough > serious objections to the use of CMS for it to be > impossible to send the document on to the IESG. However, > objection is not enough - we need alternate proposals > in sufficient detail to be closely evaluated and ultimately > included in the STUN draft. > > Thanks, > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 25 13:36:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28754 for ; Thu, 25 Apr 2002 13:36:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA25616 for midcom-archive@odin.ietf.org; Thu, 25 Apr 2002 13:36:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24849; Thu, 25 Apr 2002 13:29:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24821 for ; Thu, 25 Apr 2002 13:29:39 -0400 (EDT) Received: from Mitel.COM ([216.191.234.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28507 for ; Thu, 25 Apr 2002 13:29:36 -0400 (EDT) From: Tom_Gray@Mitel.COM Received: from kanmta01.mitel.com (kanmta01.kanata.mitel.com [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id NAA12894; Thu, 25 Apr 2002 13:28:56 -0400 (EDT) Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN To: Melinda Shore , , "Pete Cordell" , Tom_Gray@Mitel.COM Date: Thu, 25 Apr 2002 13:28:54 -0400 Message-ID: X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.7 |March 21, 2001) at 04/25/2002 01:28:56 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org The range of addresses which are reasonable might even be the 'shared secret' that is spoken of in other messages to this list. These can either be pre-configured or delivered by a protocol. Why not, it would make STUN completely indifferent to cryptography? Melinda Shore @ietf.org on 04/25/2002 12:22:22 PM Sent by: midcom-admin@ietf.org To: "Pete Cordell" cc: Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN At 04:57 PM 4/25/02 +0100, Pete Cordell wrote: >For something that is so much simpler than the other candidates, it needs >slightly more consideration than simply saying that it's gooby. Rome wasn't >built in a day. Who knows, Rome might have been gooby in the beginning >also. I was referring to enterprises running their own STUN servers. At any rate, while what you're proposing is a good idea in certain deployments it's not a substitute for securing the STUN protocol, which we *must* do. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 25 13:39:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28854 for ; Thu, 25 Apr 2002 13:39:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA25858 for midcom-archive@odin.ietf.org; Thu, 25 Apr 2002 13:39:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25713; Thu, 25 Apr 2002 13:37:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25683 for ; Thu, 25 Apr 2002 13:37:29 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28786 for ; Thu, 25 Apr 2002 13:37:23 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3PHalTZ015635; Thu, 25 Apr 2002 10:36:47 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADQ77304; Thu, 25 Apr 2002 10:34:02 -0700 (PDT) Message-Id: <5.1.0.14.0.20020425133000.00aa08f0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 25 Apr 2002 13:40:45 -0400 To: "Peterson, Jon" From: Melinda Shore Subject: RE: [midcom] Working group last call - STUN (security) Cc: midcom@ietf.org In-Reply-To: <70565611B164D511957A001083FCDD560187027F@va02.va.neustar.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 12:10 PM 4/25/02 -0500, Peterson, Jon wrote: >This is closer to what I'd personally like to see, in so far as it takes the >burden of PKI off of STUN itself. I don't see PKI as a huge issue here, frankly. We're not requiring users to have certs, and the people who are likely to be providing STUN services are already likely to have certificates. >But I would probably stop short of making >such a TLS password-download mechanism mandatory. There are at least two >cases I can think of that are meaningful STUN architectures which wouldn't >require any password download: Mandatory-to-implement shouldn't imply mandatory-to-deploy. If someone wants to run without authentication that's their choice, but the protocol MUST provide protection against the kind of active attack that's been identified. >- Simple pre-configuration of secret - meaningful for enterprise STUN >servers I really think enterprise STUN servers are a terrible idea. Again, it's basically got all of the disadvantages of midcom with none of the advantages. To the extent that an enterprise might choose to run a STUN server it might be helpful if it anticipates that NATted hosts may wish to talk to it and it wants to provide reliable address information, which brings us pretty much back to where we are. >So, I wouldn't object to allowing TLS (or something similar) as a way of >downloading a secret from a STUN server, as long as it is a MAY to >implement, it is separate from the remainder of the STUN protocol. STUN >itself has no need to become a secret-discovery protocol. I do not believe that this would pass IESG review. I'm rather concerned that people are being casual about a clear vulnerability with a simple attack against it. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 25 13:46:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29018 for ; Thu, 25 Apr 2002 13:46:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA26330 for midcom-archive@odin.ietf.org; Thu, 25 Apr 2002 13:46:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25823; Thu, 25 Apr 2002 13:39:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25792 for ; Thu, 25 Apr 2002 13:39:17 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28843 for ; Thu, 25 Apr 2002 13:39:11 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3PHcgTZ016917; Thu, 25 Apr 2002 10:38:43 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADQ77409; Thu, 25 Apr 2002 10:36:04 -0700 (PDT) Message-Id: <5.1.0.14.0.20020425134210.00aadd00@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 25 Apr 2002 13:43:02 -0400 To: From: Melinda Shore Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN Cc: midcom@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 01:26 PM 4/25/02 -0400, Tom_Gray@Mitel.COM wrote: >The range of addresses which are reasonable might even be the 'shared >secret' that is spoken of in other messages to this list. These can either >be pre-configured or delivered by a protocol. Why not, it would make STUN >completely indifferent to cryptography? It would be a nearly no-entropy secret. That's not a secret. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 25 14:18:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00636 for ; Thu, 25 Apr 2002 14:18:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA29440 for midcom-archive@odin.ietf.org; Thu, 25 Apr 2002 14:18:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28849; Thu, 25 Apr 2002 14:10:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28782 for ; Thu, 25 Apr 2002 14:10:29 -0400 (EDT) Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00224 for ; Thu, 25 Apr 2002 14:10:26 -0400 (EDT) Received: from [63.113.114.131] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 2932355 for midcom@ietf.org; Thu, 25 Apr 2002 14:10:22 -0400 Message-Id: <5.1.0.14.0.20020425135734.01a7dc60@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 25 Apr 2002 14:06:36 -0400 To: "'midcom@ietf.org'" From: "Joel M. Halpern" In-Reply-To: <1B54FA3A2709D51195C800508BF9386A03DE3A3C@zrc2c000.us.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA28799 Subject: [midcom] Re: draft-sct-midcom-megaco-01.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit As with some of the other analysis, this analysis treats partitioning as a solution to the multiple manager problem. This does not meet the requirements as stated. (It may be a compromise we are willing to accept, but should be described as partially met or not met, not claimed to be completely met.) With apologies for appearing to be hammering on this particular author (as they are not the only ones to have made this leap), I will quote from their document: ô2.2.7. The Midcom protocol must not preclude multiple authorized agents from working on the same policy rule.ö In case the Megaco state machine on the Middle Box is decoupled from the Middle Box policy rule management, this requirement is met with local policies on the Middle Box. ô2.1.3. The Midcom protocol must allow a middlebox to communicate with more than one Midcom agent simultaneously. There may be multiple instances of a single application or multiple applications desiring service from a single middlebox, and differ- ent agents may represent them. The protocol design must not pre- clude the ability to do so.ö Megaco has the concept of Virtual Media Gateways (VMG) within a single physical MG that allows multiple MGCs communicate simultaneously with the same MG, sharing resources in a conflict- free manner. 3. Virtual Media Gateways: A physical MG can be partitioned into multiple virtual MG's allowing multiple Controllers to interact with disjoint sets of Contexts/Terminations within a single physical device. So we see on the one hand that working with multiple agents is a local matter, and on the other that it is to be dealt with by VMGs. However, if it were actually practical to deal with it purely as a local matter, we would not have included it as a protocol requirement. And the description of the VMG requires complete partition of scope, while it is clear to me at least that the intent of the requirement is to allow overlapping scopes. Yours, Joel M. Halpern PS: There is a reasonable claim that the determinism requirement and the overlapping control requirement can not both be met as written. If that is your view, then describe the protocol as partially meeting each requirement and we as a working group may decide to accept such. Noone is being asked to claim to do the impossible. Accurate descriptions are much more helpful. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 25 14:20:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00787 for ; Thu, 25 Apr 2002 14:20:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA29635 for midcom-archive@odin.ietf.org; Thu, 25 Apr 2002 14:20:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29441; Thu, 25 Apr 2002 14:18:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28986 for ; Thu, 25 Apr 2002 14:12:03 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00397 for ; Thu, 25 Apr 2002 14:12:00 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g3PIBte10015; Thu, 25 Apr 2002 14:11:55 -0400 (EDT) Message-Id: <200204251811.g3PIBte10015@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Tom_Gray@mitel.com cc: Melinda Shore , midcom@ietf.org, "Pete Cordell" Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN In-reply-to: (Your message of "Thu, 25 Apr 2002 13:28:54 EDT.") Date: Thu, 25 Apr 2002 14:11:54 -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > The range of addresses which are reasonable might even be the 'shared > secret' that is spoken of in other messages to this list. These can either > be pre-configured or delivered by a protocol. Why not, it would make STUN > completely indifferent to cryptography? because it would also make STUN indifferent to security? _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 25 14:20:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00805 for ; Thu, 25 Apr 2002 14:20:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA29649 for midcom-archive@odin.ietf.org; Thu, 25 Apr 2002 14:20:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29302; Thu, 25 Apr 2002 14:17:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29275 for ; Thu, 25 Apr 2002 14:17:30 -0400 (EDT) Received: from Mitel.COM ([216.191.234.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00585 for ; Thu, 25 Apr 2002 14:17:22 -0400 (EDT) From: Tom_Gray@Mitel.COM Received: from kanmta01.mitel.com (kanmta01.kanata.mitel.com [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id OAA21504; Thu, 25 Apr 2002 14:16:46 -0400 (EDT) Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN To: Melinda Shore Cc: , midcom@ietf.org Date: Thu, 25 Apr 2002 14:16:45 -0400 Message-ID: X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.7 |March 21, 2001) at 04/25/2002 02:16:46 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I was using a figure of speech. If the purpose of the securing of STUN is to prevent a rogue STUN server from hijacking a connection, wouldn't this solve the problem. Are there other purposes that are being served by the securing of STUN? Melinda Shore on 04/25/2002 01:43:02 PM To: cc: midcom@ietf.org Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN At 01:26 PM 4/25/02 -0400, Tom_Gray@Mitel.COM wrote: >The range of addresses which are reasonable might even be the 'shared >secret' that is spoken of in other messages to this list. These can either >be pre-configured or delivered by a protocol. Why not, it would make STUN >completely indifferent to cryptography? It would be a nearly no-entropy secret. That's not a secret. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 25 14:28:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01096 for ; Thu, 25 Apr 2002 14:28:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA00248 for midcom-archive@odin.ietf.org; Thu, 25 Apr 2002 14:28:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00066; Thu, 25 Apr 2002 14:24:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00035 for ; Thu, 25 Apr 2002 14:24:19 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00999 for ; Thu, 25 Apr 2002 14:24:16 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g3PINlpY019739; Thu, 25 Apr 2002 11:23:47 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADQ79519; Thu, 25 Apr 2002 11:21:09 -0700 (PDT) Message-Id: <5.1.0.14.0.20020425142555.00aa4030@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 25 Apr 2002 14:28:05 -0400 To: From: Melinda Shore Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN Cc: midcom@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 02:16 PM 4/25/02 -0400, Tom_Gray@Mitel.COM wrote: >If the purpose of the securing of STUN is to prevent a rogue STUN server >from hijacking a connection, wouldn't this solve the problem. No, because keying material needs to be as random as possible. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Apr 25 15:54:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04020 for ; Thu, 25 Apr 2002 15:54:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA05863 for midcom-archive@odin.ietf.org; Thu, 25 Apr 2002 15:54:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05665; Thu, 25 Apr 2002 15:48:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05634 for ; Thu, 25 Apr 2002 15:48:15 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03892 for ; Thu, 25 Apr 2002 15:48:11 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3PJlhTZ020172; Thu, 25 Apr 2002 12:47:43 -0700 (PDT) Received: from localhost (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACX79965; Thu, 25 Apr 2002 12:47:41 -0700 (PDT) Date: Thu, 25 Apr 2002 12:44:37 -0700 (Pacific Daylight Time) From: Rohan Mahy To: Melinda Shore cc: midcom@ietf.org Subject: Re: [midcom] Protocol Eval Documents In-Reply-To: <5.1.0.14.0.20020425123425.00aa44b0@localhost> Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Thu, 25 Apr 2002, Melinda Shore wrote: > At 09:16 AM 4/25/02 -0700, Rohan Mahy wrote: > >Are we going to also compare the "existing protocol" approaches with just > >rolling our own on top of a reliable transport (TCP or TLS). > > The charter sez: > The working group will evaluate existing IETF protocols > for their applicability to this problem, using the framework > and requirements documents developed during the working group's > first phase as criteria for the evaluation. If a protocol is > found to be suitable it will be used as the basis for the > development of a middlebox communication protocol. In the > unlikely case that one is not found to be suitable, the working > group will undertake development of a new protocol. My interpretation of this is that to be suitable, an existing protocol has to be better in some way than writing our own, as opposed to merely working. Some of the applicability documents seem to take this approach. > Also, whether we find an existing protocol or end up having to > roll our own, I hope that we won't restrict ourselves to TCP > for transport. agreed, i mentioned TCP and TLS as examples only. thanks, -rohan > Melinda > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Thu Apr 25 16:12:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04581 for ; Thu, 25 Apr 2002 16:12:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA07332 for midcom-archive@odin.ietf.org; Thu, 25 Apr 2002 16:12:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06410; Thu, 25 Apr 2002 16:00:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06371 for ; Thu, 25 Apr 2002 16:00:15 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04130 for ; Thu, 25 Apr 2002 16:00:11 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g3PJxep6000582; Thu, 25 Apr 2002 12:59:41 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADQ83293; Thu, 25 Apr 2002 12:57:01 -0700 (PDT) Message-Id: <5.1.0.14.0.20020425160121.00aa7060@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 25 Apr 2002 16:03:53 -0400 To: Rohan Mahy From: Melinda Shore Subject: Re: [midcom] Protocol Eval Documents Cc: midcom@ietf.org In-Reply-To: References: <5.1.0.14.0.20020425123425.00aa44b0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 12:44 PM 4/25/02 -0700, Rohan Mahy wrote: >My interpretation of this is that to be suitable, an existing protocol >has to be better in some way than writing our own, as opposed to merely >working. That wasn't the intent. The only circumstance under which we'd be allowed to go off and develop something from scratch would be if every existing protocol proposed were shown to be completely unsuitable. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Thu Apr 25 17:13:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06328 for ; Thu, 25 Apr 2002 17:13:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA11651 for midcom-archive@odin.ietf.org; Thu, 25 Apr 2002 17:13:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11384; Thu, 25 Apr 2002 17:08:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11354 for ; Thu, 25 Apr 2002 17:08:10 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06117 for ; Thu, 25 Apr 2002 17:08:06 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g3PL7cpY017195; Thu, 25 Apr 2002 14:07:38 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADQ85865; Thu, 25 Apr 2002 14:04:59 -0700 (PDT) Message-Id: <5.1.0.14.0.20020425170423.00a7b170@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 25 Apr 2002 17:11:47 -0400 To: From: Melinda Shore Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN Cc: midcom@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 04:28 PM 4/25/02 -0400, Tom_Gray@Mitel.COM wrote: >If a client knows the range of reasonable addresses, it should receive then >it can determine autonomously that a rogue server has sent it a fraudulent >address with no specific cryptographic capability in the client. It can guess but it can't know for certain. Certainly, in the case where the NAT is being provided by the service provider and is not on the customer premises, as with cable, there's no way for the client to know what a reasonable public address might look like. And then there's the continuing problem of multihomed networks or nested NATs ... This might be a reasonable thing for a manufacturer to add to the client but it's not a substitute for properly securing the protocol when we know there's an easy-to-perform attack against it in anticipated deployed configurations. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Thu Apr 25 21:35:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10919 for ; Thu, 25 Apr 2002 21:35:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA24905 for midcom-archive@odin.ietf.org; Thu, 25 Apr 2002 21:35:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24804; Thu, 25 Apr 2002 21:33:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24778 for ; Thu, 25 Apr 2002 21:33:44 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10812 for ; Thu, 25 Apr 2002 21:33:39 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g3Q1XCp6027124; Thu, 25 Apr 2002 18:33:12 -0700 (PDT) Received: from fluffyw2k (dhcp-128-107-209-74.cisco.com [128.107.209.74]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ACS72076; Thu, 25 Apr 2002 18:33:22 -0700 (PDT) From: "Cullen Jennings" To: "Melinda Shore" , Cc: Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Date: Thu, 25 Apr 2002 18:33:12 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <5.1.0.14.0.20020425170423.00a7b170@localhost> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit In the case of my particular home cable modem with a residential NAT behind it, I do know the DNS name of my public address. It looks like my cable modems MAC address followed by service providers domain. I also run dynamic DNS from my NAT so I even have a reasonable human readable DNS address for the public side of my NAT. I agree that this does not sound like a very good solution - I'm not sure how an average user would configure it - but it is interesting to note that there seem to be a fair number of cases where it is feasible to make a fairly intelligent guess at what the IP range of valid DNS address might be. > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Melinda Shore > Sent: Thursday, April 25, 2002 2:12 PM > To: Tom_Gray@Mitel.COM > Cc: midcom@ietf.org > Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN > > > At 04:28 PM 4/25/02 -0400, Tom_Gray@Mitel.COM wrote: > >If a client knows the range of reasonable addresses, it should > receive then > >it can determine autonomously that a rogue server has sent it a > fraudulent > >address with no specific cryptographic capability in the client. > > It can guess but it can't know for certain. Certainly, in > the case where the NAT is being provided by the service > provider and is not on the customer premises, as with cable, > there's no way for the client to know what a reasonable > public address might look like. And then there's the continuing > problem of multihomed networks or nested NATs ... > > This might be a reasonable thing for a manufacturer to add to > the client but it's not a substitute for properly securing the > protocol when we know there's an easy-to-perform attack against > it in anticipated deployed configurations. > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Thu Apr 25 23:26:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14570 for ; Thu, 25 Apr 2002 23:26:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA00576 for midcom-archive@odin.ietf.org; Thu, 25 Apr 2002 23:26:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA00487; Thu, 25 Apr 2002 23:23:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA00400 for ; Thu, 25 Apr 2002 23:23:48 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14541 for ; Thu, 25 Apr 2002 23:23:43 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g3Q3N9H14466; Thu, 25 Apr 2002 23:23:09 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Apr 2002 22:23:04 -0500 Message-ID: <70565611B164D511957A001083FCDD5601870289@va02.va.neustar.com> From: "Peterson, Jon" To: "'Melinda Shore'" Cc: midcom@ietf.org Subject: RE: [midcom] Working group last call - STUN (security) Date: Thu, 25 Apr 2002 22:23:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Some notes below. It would seem that you and I are once again ships passing in the night here... Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Thursday, April 25, 2002 10:41 AM > To: Peterson, Jon > Cc: midcom@ietf.org > Subject: RE: [midcom] Working group last call - STUN (security) > > > At 12:10 PM 4/25/02 -0500, Peterson, Jon wrote: [snip] > > I don't see PKI as a huge issue here, frankly. We're not > requiring users to have certs, and the people who are likely > to be providing STUN services are already likely to have > certificates. > The verification of a cert by the STUN client and the operations that entails are the concern with this. Particularly the extra RTT to download the cert, and the fact that TCP is needed for the extra RTT. And the other things I mentioned in my previous mails. I see no reason why STUN, a protocol that is comparable to echo, a protocol that tests NAT configurations, needs to have some sort of certificate download and verification apparatus. This would clearly be a lot of work. > >But I would probably stop short of making > >such a TLS password-download mechanism mandatory. There are at least two > >cases I can think of that are meaningful STUN architectures which wouldn't > >require any password download: > > Mandatory-to-implement shouldn't imply mandatory-to-deploy. > If someone wants to run without authentication that's their > choice, but the protocol MUST provide protection against > the kind of active attack that's been identified. > Yes, but preventing the active attack against STUN has little to do with this matter of how you learn of shared secrets. There have been a couple of ideas related to TLS on the list in the last day - one, to use TLS overall for STUN authentication, and another, to use TLS to download a shared secret from a STUN server that would subsequently be used for authentication. I was speaking just to this latter point. I'm not suggesting running without authentication - I was suggesting that sometimes, STUN clients may have other ways of knowing passwords that they can use to authenticate STUN servers without needing to use TLS to download them. Thus I think support for the (proposed) TLS-based password download method should not be mandatory. > >- Simple pre-configuration of secret - meaningful for enterprise STUN > >servers > > I really think enterprise STUN servers are a terrible idea. Again, > it's basically got all of the disadvantages of midcom with none of > the advantages. To the extent that an enterprise might choose to > run a STUN server it might be helpful if it anticipates that NATted > hosts may wish to talk to it and it wants to provide reliable address > information, which brings us pretty much back to where we are. > An enterpise might also contract with a STUN server provider. This would still allow for the pre-configuration of a secret. Whether or not the enterprise actually operates the STUN server isn't really material to this. > >So, I wouldn't object to allowing TLS (or something similar) as a way of > >downloading a secret from a STUN server, as long as it is a MAY to > >implement, it is separate from the remainder of the STUN protocol. STUN > >itself has no need to become a secret-discovery protocol. > > I do not believe that this would pass IESG review. > > I'm rather concerned that people are being casual about a clear > vulnerability with a simple attack against it. > Again, declaring the TLS-based method of downloading the password as optional does not mean that authentication of the STUN server would in turn be optional. I was saying only that I thought there were useful STUN architectures in which a TLS-based password download would not be necessary, because the shared secret used for authentication could be learned in some other secure fashion. I agree that the attack against STUN itself is material - if I didn't, I wouldn't need to suggest any approach to STUN security whatsoever. > Melinda > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 26 07:25:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29702 for ; Fri, 26 Apr 2002 07:25:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA03882 for midcom-archive@odin.ietf.org; Fri, 26 Apr 2002 07:25:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03508; Fri, 26 Apr 2002 07:19:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03477 for ; Fri, 26 Apr 2002 07:19:28 -0400 (EDT) Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29635 for ; Fri, 26 Apr 2002 07:19:25 -0400 (EDT) Received: from host213-1-180-225.btinternet.com ([213.1.180.225] helo=tkw) by tungsten.btinternet.com with smtp (Exim 3.22 #8) id 1713l4-0003uc-00; Fri, 26 Apr 2002 12:19:22 +0100 Message-ID: <008001c1ed14$60d0a5a0$0200000a@tkw> From: "Pete Cordell" To: "Melinda Shore" Cc: References: <5.1.0.14.0.20020425170423.00a7b170@localhost> Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN Date: Fri, 26 Apr 2002 12:19:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Can I go back to basics then and just check my understanding... As I understand it the problem is that you might get an impostor (Mallory or whatever his name is) supplying you with an invalid MAPPED-ADDRESS. (stun-00 also says "...the attack is only possible for attackers outside of the NAT when the NAT is full cone." I'm not sure this is true. If Mallory does source address spoofing it should slip back through the NAT nicely. But it's convenient to assume this is true for the time being so I'll stick with it!) There seem to be two ways Mallory can operate - 1) Mallory is sitting on the path of the STUN request and on seeing it go past, generates a spoof response. 2) Mallory compromises the STUN server. In the first case, I assume that the client will get both the genuine and faked response (especially if they do retries). Is that reasonable? If that's the case the client can surmise that something is up. In the second case, if it is only a vulnerability in the case of full cone, perhaps the client can run the STUN test off of a number of STUN servers (maybe 3 or 4) and cross check results on the theory that not all of them are likely to be compromised at the same time by the same person. Even if they were all compromised by the same person, it is unlikely they would all give the same results if the tests were done at the same time (they wouldn't have enough time to agree on their story). Running the test multiple times is probably not as bad as it at first sounds. You wouldn't need the cookie exchange, so you get two tests for the price for one there. All the crypto stuff has got to be a burden on the servers as well (hence the need for the cookie) so removing that ought mean you can cope with many more tests. The client could also log addresses that it thought were genuine so that it wouldn't have to double check those every time. (Excuse me for banging on about this, but I feel that sometimes it's important to explore other possibilities before going with something that is going to be quite hard to implement - even if the chance of finding something is relatively small.) Pete. ----- Original Message ----- From: "Melinda Shore" To: Cc: Sent: 25 April 2002 22:11 Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN > At 04:28 PM 4/25/02 -0400, Tom_Gray@Mitel.COM wrote: > >If a client knows the range of reasonable addresses, it should receive then > >it can determine autonomously that a rogue server has sent it a fraudulent > >address with no specific cryptographic capability in the client. > > It can guess but it can't know for certain. Certainly, in > the case where the NAT is being provided by the service > provider and is not on the customer premises, as with cable, > there's no way for the client to know what a reasonable > public address might look like. And then there's the continuing > problem of multihomed networks or nested NATs ... > > This might be a reasonable thing for a manufacturer to add to > the client but it's not a substitute for properly securing the > protocol when we know there's an easy-to-perform attack against > it in anticipated deployed configurations. > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 26 07:25:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29721 for ; Fri, 26 Apr 2002 07:25:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA03915 for midcom-archive@odin.ietf.org; Fri, 26 Apr 2002 07:25:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03554; Fri, 26 Apr 2002 07:19:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03517 for ; Fri, 26 Apr 2002 07:19:33 -0400 (EDT) Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29632 for ; Fri, 26 Apr 2002 07:19:24 -0400 (EDT) Received: from host213-1-180-225.btinternet.com ([213.1.180.225] helo=tkw) by tungsten.btinternet.com with smtp (Exim 3.22 #8) id 1713l3-0003uc-00; Fri, 26 Apr 2002 12:19:21 +0100 Message-ID: <007f01c1ed14$60073b20$0200000a@tkw> From: "Pete Cordell" To: , "Melinda Shore" Cc: References: <5.1.0.14.0.20020425142555.00aa4030@localhost> Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN Date: Fri, 26 Apr 2002 12:09:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit I think what Tom is saying is, if you can deliver a secret, you can probably also deliver a list of valid answers. While this will not be used in the same way as a secret, it can get you to the same result... knowing that the MAPPED-ADDRESS is an appropriate value. One difference is who supplies the information. In the secret case, it is the STUN server doing the job, in the valid addresses case it is some local device / service provider. This difference may imply different mechanisms. Possibly the big difference is that maybe we assume that the local authorities are not playing the game, and so we can't rely on them providing information. Pete. ----- Original Message ----- From: "Melinda Shore" To: Cc: Sent: 25 April 2002 19:28 Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN > At 02:16 PM 4/25/02 -0400, Tom_Gray@Mitel.COM wrote: > >If the purpose of the securing of STUN is to prevent a rogue STUN server > >from hijacking a connection, wouldn't this solve the problem. > > No, because keying material needs to be as random as possible. > > Melinda > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 26 07:25:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29723 for ; Fri, 26 Apr 2002 07:25:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA03914 for midcom-archive@odin.ietf.org; Fri, 26 Apr 2002 07:25:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03579; Fri, 26 Apr 2002 07:19:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03502 for ; Fri, 26 Apr 2002 07:19:32 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29634 for ; Fri, 26 Apr 2002 07:19:25 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g3QBIup6000686; Fri, 26 Apr 2002 04:18:56 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADR02043; Fri, 26 Apr 2002 04:16:18 -0700 (PDT) Message-Id: <5.1.0.14.0.20020426071016.00a86980@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 26 Apr 2002 07:23:19 -0400 To: "Peterson, Jon" From: Melinda Shore Subject: RE: [midcom] Working group last call - STUN (security) Cc: midcom@ietf.org In-Reply-To: <70565611B164D511957A001083FCDD5601870289@va02.va.neustar.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 10:23 PM 4/25/02 -0500, Peterson, Jon wrote: >The verification of a cert by the STUN client and the operations that >entails are the concern with this. Particularly the extra RTT to download >the cert, and the fact that TCP is needed for the extra RTT. And the other >things I mentioned in my previous mails. I see no reason why STUN, a >protocol that is comparable to echo, a protocol that tests NAT >configurations, needs to have some sort of certificate download and >verification apparatus. This would clearly be a lot of work. Here's the problem at hand: we need a mandatory-to-implement, optional-to-deploy mechanism that protects *this protocol* against the hijacking attack when there's no pre-existing relationship between the STUN client and the STUN server. If we're going to authenticate the response from the server we need a good answer to the keying question. If we're not going to authenticate the response from the server we need 1) something that provides a similar level of assurance, and 2) a really good explanation describing *why* we think that what we're doing is very secure. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 26 07:40:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00005 for ; Fri, 26 Apr 2002 07:40:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA04822 for midcom-archive@odin.ietf.org; Fri, 26 Apr 2002 07:40:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04745; Fri, 26 Apr 2002 07:38:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04717 for ; Fri, 26 Apr 2002 07:38:47 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29963 for ; Fri, 26 Apr 2002 07:38:44 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g3QBcFpY007531; Fri, 26 Apr 2002 04:38:15 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADR02186; Fri, 26 Apr 2002 04:35:37 -0700 (PDT) Message-Id: <5.1.0.14.0.20020426073948.00a829f0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 26 Apr 2002 07:42:38 -0400 To: "Pete Cordell" From: Melinda Shore Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN Cc: In-Reply-To: <008001c1ed14$60d0a5a0$0200000a@tkw> References: <5.1.0.14.0.20020425170423.00a7b170@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 12:19 PM 4/26/02 +0100, Pete Cordell wrote: >In the first case, I assume that the client will get both the genuine and >faked response (especially if they do retries). Is that reasonable? If >that's the case the client can surmise that something is up. It's not a reliable test because: 1) it's not possible to detect UDP packet loss (if the legitimate response is lost), and 2) how long would we have to wait before deciding that we're only getting one answer? In terms of the server having been compromised, all bets are off in that case, anyway. Even if the protocol were highly secure, losing the private key would be enough to give the whole thing away. While there are things that can be done to mitigate the effects of a system compromise there's no real protect against it for our purposes. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 26 09:06:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02353 for ; Fri, 26 Apr 2002 09:06:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA10161 for midcom-archive@odin.ietf.org; Fri, 26 Apr 2002 09:06:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09973; Fri, 26 Apr 2002 09:02:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09928 for ; Fri, 26 Apr 2002 09:02:46 -0400 (EDT) Received: from Mitel.COM ([216.191.234.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02194 for ; Fri, 26 Apr 2002 09:02:43 -0400 (EDT) From: Tom_Gray@Mitel.COM Received: from kanmta01.mitel.com (kanmta01.kanata.mitel.com [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id JAA11750; Fri, 26 Apr 2002 09:01:27 -0400 (EDT) Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN To: Melinda Shore Cc: "Pete Cordell" , Date: Fri, 26 Apr 2002 09:01:26 -0400 Message-ID: X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.7 |March 21, 2001) at 04/26/2002 09:01:27 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Waiting is not a significant problem if he concern is that the connection is going to be hijacked. The connection can go ahead on the reception of the first message and if a later illicit response is received the connection can be broken. The connection can be made using an alternative server. Missing responses, it could be argued are not a problem since there will undoubtedly be many interactions between the client and a server a a real situation. One occurrence of an attempt at theft would be enough to disqualify the server. I too apologise if I am belabouring the point. The issue is not to secure the protocol but to have means to protect the user from a specific type of attack. If this can be done by a simple method that does not require an elaborate cryptographic implementation then I don't see why it would be a bad thing to toss a few simple ideas around. Indeed, the idea of using a certificate system to identify the server seems to me only an indirect and possibly uncertain means of security against a theft attack. The client could securely authenticate the server that steals its connections. Melinda Shore @ietf.org on 04/26/2002 07:42:38 AM Sent by: midcom-admin@ietf.org To: "Pete Cordell" cc: Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN At 12:19 PM 4/26/02 +0100, Pete Cordell wrote: >In the first case, I assume that the client will get both the genuine and >faked response (especially if they do retries). Is that reasonable? If >that's the case the client can surmise that something is up. It's not a reliable test because: 1) it's not possible to detect UDP packet loss (if the legitimate response is lost), and 2) how long would we have to wait before deciding that we're only getting one answer? In terms of the server having been compromised, all bets are off in that case, anyway. Even if the protocol were highly secure, losing the private key would be enough to give the whole thing away. While there are things that can be done to mitigate the effects of a system compromise there's no real protect against it for our purposes. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 26 09:21:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03220 for ; Fri, 26 Apr 2002 09:21:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA10863 for midcom-archive@odin.ietf.org; Fri, 26 Apr 2002 09:21:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10710; Fri, 26 Apr 2002 09:19:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10681 for ; Fri, 26 Apr 2002 09:19:02 -0400 (EDT) Received: from rhenium.btinternet.com (rhenium.btinternet.com [194.73.73.93]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03092 for ; Fri, 26 Apr 2002 09:18:58 -0400 (EDT) Received: from host213-122-150-145.in-addr.btopenworld.com ([213.122.150.145] helo=tkw) by rhenium.btinternet.com with smtp (Exim 3.22 #8) id 1715cn-0003Xg-00; Fri, 26 Apr 2002 14:18:57 +0100 Message-ID: <004101c1ed25$14e7e840$0200000a@tkw> From: "Pete Cordell" To: "Melinda Shore" Cc: References: <5.1.0.14.0.20020425170423.00a7b170@localhost> <5.1.0.14.0.20020426073948.00a829f0@localhost> Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN Date: Fri, 26 Apr 2002 14:18:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Melinda Shore" > At 12:19 PM 4/26/02 +0100, Pete Cordell wrote: > >In the first case, I assume that the client will get both the genuine and > >faked response (especially if they do retries). Is that reasonable? If > >that's the case the client can surmise that something is up. > > It's not a reliable test because: 1) it's not possible to detect > UDP packet loss (if the legitimate response is lost), Retries or trying a different server would resolve that. Trying different servers would be a better option. > and 2) how > long would we have to wait before deciding that we're only getting > one answer? About as long as I wait to decide I'm not going to get a reply from any other STUN test. I could actually assume that the first response was genuine and carry on with that. If I subsequently found that another response came in, I would only then start thinking about what to do with it (maybe tearing down the call). > In terms of the server having been compromised, all bets are off > in that case, anyway. Even if the protocol were highly secure, > losing the private key would be enough to give the whole thing > away. While there are things that can be done to mitigate the > effects of a system compromise there's no real protect against > it for our purposes. > > Melinda > Pete. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Apr 26 10:11:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05068 for ; Fri, 26 Apr 2002 10:11:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA14595 for midcom-archive@odin.ietf.org; Fri, 26 Apr 2002 10:11:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14158; Fri, 26 Apr 2002 10:07:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14106 for ; Fri, 26 Apr 2002 10:07:22 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04869 for ; Fri, 26 Apr 2002 10:07:18 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3QE6oTZ026060; Fri, 26 Apr 2002 07:06:50 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADR03970; Fri, 26 Apr 2002 07:04:10 -0700 (PDT) Message-Id: <5.1.0.14.0.20020426100019.00a919c0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 26 Apr 2002 10:11:12 -0400 To: "Pete Cordell" From: Melinda Shore Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN Cc: In-Reply-To: <004101c1ed25$14e7e840$0200000a@tkw> References: <5.1.0.14.0.20020425170423.00a7b170@localhost> <5.1.0.14.0.20020426073948.00a829f0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 02:18 PM 4/26/02 +0100, Pete Cordell wrote: >Retries or trying a different server would resolve that. Trying different >servers would be a better option. No, because you don't know if you've lost a packet. That is to say, the attacker's packet gets through and the legitimate packet does not. If you think that too unlikely to be of concern, consider typical internet packet loss statistics and the situation where the attacker is on the local network. >I could actually assume that the first response was genuine and carry on >with that. If I subsequently found that another response came in, I would >only then start thinking about what to do with it (maybe tearing down the >call). In the typical telephone call you have one outbound media channel. You would not discover the problem until subsequent telephone calls were placed, and then only if 1) the client was retaining state between calls, and 2) the call wasn't followed by a subsequent successful attack. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Apr 26 12:36:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10053 for ; Fri, 26 Apr 2002 12:36:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA24847 for midcom-archive@odin.ietf.org; Fri, 26 Apr 2002 12:36:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24741; Fri, 26 Apr 2002 12:32:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24715 for ; Fri, 26 Apr 2002 12:31:56 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09953 for ; Fri, 26 Apr 2002 12:31:51 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3QGTpB15467; Fri, 26 Apr 2002 11:29:56 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Apr 2002 11:29:47 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E01187ACA@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Joel M. Halpern'" , "'midcom@ietf.org'" Subject: RE: [midcom] Re: draft-sct-midcom-megaco-01.txt Date: Fri, 26 Apr 2002 11:29:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1ED3F.93328A10" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1ED3F.93328A10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think requirements 2.2.7 and 2.1.3, as stated, are quite different. = 2.1.3 does not say anything about overlapping resources or policy rules. It = just says that the protocol must allow multiple agent access a Middlebox. = Megaco allows that through the Virtual MG mechanism. The other requirement (2.2.7) talks about the protocol not precluding overlapping rulesets (subset or superset). Well, Megaco does not, as = long as we keep the ruleset separate from Terminations or other like Megaco = entities (and somehow link them back through their attributes). This is the = essence of our model shown in Appendix. This new layer of abstraction allows us = to manipulate the rulesets without any modification of the behavior of the = base protocol. Again, Megaco does not preclude this from happening in any = ways. Thanks for your comments, Sanjoy=20 > -----Original Message----- > From: Joel M. Halpern [mailto:joel@stevecrocker.com] > Sent: Thursday, April 25, 2002 1:07 PM > To: 'midcom@ietf.org' > Subject: [midcom] Re: draft-sct-midcom-megaco-01.txt >=20 >=20 > As with some of the other analysis, this analysis treats=20 > partitioning as a=20 > solution to the multiple manager problem. This does not meet the=20 > requirements as stated. (It may be a compromise we are=20 > willing to accept,=20 > but should be described as partially met or not met, not=20 > claimed to be=20 > completely met.) > With apologies for appearing to be hammering on this=20 > particular author (as=20 > they are not the only ones to have made this leap), I will=20 > quote from their=20 > document: >=20 > =F42.2.7. >=20 > The Midcom protocol must not preclude multiple authorized agents > from working on the same policy rule.=F6 >=20 > In case the Megaco state machine on the Middle Box is decoupled > from the Middle Box policy rule management, this requirement is > met with local policies on the Middle Box. >=20 > =F42.1.3. >=20 > The Midcom protocol must allow a middlebox to communicate=20 > with more > than one Midcom agent simultaneously. >=20 > There may be multiple instances of a single application=20 > or multiple > applications desiring service from a single middlebox, and = differ- > ent agents may represent them. The protocol design must not pre- > clude the ability to do so.=F6 >=20 > Megaco has the concept of Virtual Media Gateways (VMG) within a > single physical MG that allows multiple MGCs communicate > simultaneously with the same MG, sharing resources in a=20 > conflict- > free manner. >=20 > 3. Virtual Media Gateways: A physical MG can be partitioned into > multiple virtual MG's allowing multiple Controllers to=20 > interact with > disjoint sets of Contexts/Terminations within a single physical > device. >=20 > So we see on the one hand that working with multiple agents=20 > is a local=20 > matter, and on the other that it is to be dealt with by VMGs.=20 > However, if=20 > it were actually practical to deal with it purely as a local=20 > matter, we=20 > would not have included it as a protocol requirement. And=20 > the description=20 > of the VMG requires complete partition of scope, while it is=20 > clear to me at=20 > least that the intent of the requirement is to allow=20 > overlapping scopes. >=20 > Yours, > Joel M. Halpern >=20 > PS: There is a reasonable claim that the determinism=20 > requirement and the=20 > overlapping control requirement can not both be met as=20 > written. If that is=20 > your view, then describe the protocol as partially meeting=20 > each requirement=20 > and we as a working group may decide to accept such. Noone=20 > is being asked=20 > to claim to do the impossible. Accurate descriptions are=20 > much more helpful. >=20 > =20 >=20 >=20 > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom >=20 ------_=_NextPart_001_01C1ED3F.93328A10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Re: draft-sct-midcom-megaco-01.txt

I think requirements 2.2.7 and 2.1.3, as stated, are = quite different. 2.1.3 does not say anything about overlapping = resources or policy rules. It just says that the protocol must allow = multiple agent access a Middlebox. Megaco allows that through the = Virtual MG mechanism.

The other requirement (2.2.7) talks about the = protocol not precluding overlapping rulesets (subset or superset). = Well, Megaco does not, as long as we keep the ruleset separate from = Terminations or other like Megaco entities (and somehow link them back = through their attributes). This is the essence of our model shown in = Appendix. This new layer of abstraction allows us to manipulate the = rulesets without any modification of the behavior of the base protocol. = Again, Megaco does not preclude this from happening in any = ways.

Thanks for your comments,
Sanjoy

> -----Original Message-----
> From: Joel M. Halpern [mailto:joel@stevecrocker.com]<= /FONT>
> Sent: Thursday, April 25, 2002 1:07 PM
> To: 'midcom@ietf.org'
> Subject: [midcom] Re: = draft-sct-midcom-megaco-01.txt
>
>
> As with some of the other analysis, this = analysis treats
> partitioning as a
> solution to the multiple manager problem.  = This does not meet the
> requirements as stated.  (It may be a = compromise we are
> willing to accept,
> but should be described as partially met or not = met, not
> claimed to be
> completely met.)
> With apologies for appearing to be hammering on = this
> particular author (as
> they are not the only ones to have made this = leap), I will
> quote from their
> document:
>
>   =F42.2.7.
>
>     The Midcom protocol = must not preclude multiple authorized agents
>     from working on the = same policy rule.=F6
>
>       In case the = Megaco state machine on the Middle Box is decoupled
>       from the = Middle Box policy rule management, this requirement is
>       met with = local policies on the Middle Box.
>
>   =F42.1.3.
>
>     The Midcom protocol = must allow a middlebox to communicate
> with more
>     than one Midcom agent = simultaneously.
>
>     There may be multiple = instances of a single application
> or multiple
>     applications desiring = service from a single middlebox, and differ-
>     ent agents may = represent them.  The protocol design must not pre-
>     clude the ability to do = so.=F6
>
>       Megaco has = the concept of Virtual Media Gateways (VMG) within a
>       single = physical MG that allows multiple MGCs communicate
>       = simultaneously with the same MG, sharing resources in a
> conflict-
>       free = manner.
>
>   3. Virtual Media Gateways: A = physical MG can be partitioned into
>     multiple virtual MG's = allowing multiple Controllers to
> interact with
>     disjoint sets of = Contexts/Terminations within a single physical
>     device.
>
> So we see on the one hand that working with = multiple agents
> is a local
> matter, and on the other that it is to be dealt = with by VMGs.
>  However, if
> it were actually practical to deal with it = purely as a local
> matter, we
> would not have included it as a protocol = requirement.  And
> the description
> of the VMG requires complete partition of = scope, while it is
> clear to me at
> least that the intent of the requirement is to = allow
> overlapping scopes.
>
> Yours,
> Joel M. Halpern
>
> PS: There is a reasonable claim that the = determinism
> requirement and the
> overlapping control requirement can not both be = met as
> written.  If that is
> your view, then describe the protocol as = partially meeting
> each requirement
> and we as a working group may decide to accept = such.  Noone
> is being asked
> to claim to do the impossible.  Accurate = descriptions are
> much more helpful.
>
>     
>
>
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C1ED3F.93328A10-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Apr 26 12:43:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10280 for ; Fri, 26 Apr 2002 12:43:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA25151 for midcom-archive@odin.ietf.org; Fri, 26 Apr 2002 12:43:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25025; Fri, 26 Apr 2002 12:40:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24996 for ; Fri, 26 Apr 2002 12:40:12 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10142 for ; Fri, 26 Apr 2002 12:40:09 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3QGddq19427 for ; Fri, 26 Apr 2002 12:39:39 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Apr 2002 12:39:40 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A38E@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "Sanjoy Sen", "'Joel M. Halpern'" , "'midcom@ietf.org'" Subject: RE: [midcom] Re: draft-sct-midcom-megaco-01.txt Date: Fri, 26 Apr 2002 12:39:34 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I'll add to this that the message I took from our somewhat inconclusive semantics discussion was to disallow overlapping rule sets unless the overlap was created by the same party that created the original rule. This would mean that the use of Virtual MGs would be restricted to enforcing handoff/failover semantics. -----Original Message----- From: Sen, Sanjoy [NGC:B692:EXCH] Sent: Friday, April 26, 2002 12:30 PM To: 'Joel M. Halpern'; 'midcom@ietf.org' Subject: RE: [midcom] Re: draft-sct-midcom-megaco-01.txt I think requirements 2.2.7 and 2.1.3, as stated, are quite different. 2.1.3 does not say anything about overlapping resources or policy rules. It just says that the protocol must allow multiple agent access a Middlebox. Megaco allows that through the Virtual MG mechanism. The other requirement (2.2.7) talks about the protocol not precluding overlapping rulesets (subset or superset). Well, Megaco does not, as long as we keep the ruleset separate from Terminations or other like Megaco entities (and somehow link them back through their attributes). This is the essence of our model shown in Appendix. This new layer of abstraction allows us to manipulate the rulesets without any modification of the behavior of the base protocol. Again, Megaco does not preclude this from happening in any ways. Thanks for your comments, Sanjoy > -----Original Message----- > From: Joel M. Halpern [mailto:joel@stevecrocker.com] > Sent: Thursday, April 25, 2002 1:07 PM > To: 'midcom@ietf.org' > Subject: [midcom] Re: draft-sct-midcom-megaco-01.txt > > > As with some of the other analysis, this analysis treats > partitioning as a > solution to the multiple manager problem. This does not meet the > requirements as stated. (It may be a compromise we are > willing to accept, > but should be described as partially met or not met, not > claimed to be > completely met.) > With apologies for appearing to be hammering on this > particular author (as > they are not the only ones to have made this leap), I will > quote from their > document: > > ô2.2.7. > > The Midcom protocol must not preclude multiple authorized agents > from working on the same policy rule.ö > > In case the Megaco state machine on the Middle Box is decoupled > from the Middle Box policy rule management, this requirement is > met with local policies on the Middle Box. > > ô2.1.3. > > The Midcom protocol must allow a middlebox to communicate > with more > than one Midcom agent simultaneously. > > There may be multiple instances of a single application > or multiple > applications desiring service from a single middlebox, and differ- > ent agents may represent them. The protocol design must not pre- > clude the ability to do so.ö > > Megaco has the concept of Virtual Media Gateways (VMG) within a > single physical MG that allows multiple MGCs communicate > simultaneously with the same MG, sharing resources in a > conflict- > free manner. > > 3. Virtual Media Gateways: A physical MG can be partitioned into > multiple virtual MG's allowing multiple Controllers to > interact with > disjoint sets of Contexts/Terminations within a single physical > device. > > So we see on the one hand that working with multiple agents > is a local > matter, and on the other that it is to be dealt with by VMGs. > However, if > it were actually practical to deal with it purely as a local > matter, we > would not have included it as a protocol requirement. And > the description > of the VMG requires complete partition of scope, while it is > clear to me at > least that the intent of the requirement is to allow > overlapping scopes. > > Yours, > Joel M. Halpern > > PS: There is a reasonable claim that the determinism > requirement and the > overlapping control requirement can not both be met as > written. If that is > your view, then describe the protocol as partially meeting > each requirement > and we as a working group may decide to accept such. Noone > is being asked > to claim to do the impossible. Accurate descriptions are > much more helpful. > > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Apr 29 05:16:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15004 for ; Mon, 29 Apr 2002 05:16:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA07177 for midcom-archive@odin.ietf.org; Mon, 29 Apr 2002 05:17:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA07108; Mon, 29 Apr 2002 05:14:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA07079 for ; Mon, 29 Apr 2002 05:14:15 -0400 (EDT) Received: from gadolinium.btinternet.com (gadolinium.btinternet.com [194.73.73.111]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14860 for ; Mon, 29 Apr 2002 05:14:06 -0400 (EDT) Received: from host213-122-155-27.in-addr.btopenworld.com ([213.122.155.27] helo=tkw) by gadolinium.btinternet.com with smtp (Exim 3.22 #8) id 1727ES-0007Ta-00; Mon, 29 Apr 2002 10:14:05 +0100 Message-ID: <004b01c1ef5e$60654b60$0200000a@tkw> From: "Pete Cordell" To: "Melinda Shore" Cc: References: <5.1.0.14.0.20020425170423.00a7b170@localhost> <5.1.0.14.0.20020426073948.00a829f0@localhost> <5.1.0.14.0.20020426100019.00a919c0@localhost> Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN Date: Mon, 29 Apr 2002 10:13:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit I see the problem a bit like this... If I have a message written in Chinese on a bit of paper and I want to know what it says I have two options: 1) I can take it to the Chinese Embassy (in my case in London) and ask them to give me an official translation, and sign it to say its authentic. 2) I can ask a number of Chinese people locally to translate it. If I get consistent results then I can be fairly sure that that's what the message says. (2) is what I'm suggesting here (simultaneously send 3 or 4 packets to 3 or 4 different servers and compare their results). In my case it saves me from going all the way to London. (2) may also be even more reliable than (1) if the message happens to be in something like Iraqi and I go to the Iraqi embassy for a translation! Given that this is a light-weight protocol and a short term solution, I feel that it is more likely that such a scheme will be implemented than if it requires heavy-weight encryption. I think a cryptographic solution will hinder STUNs adoption for the following reasons: - On the client side the cryptography is something you probably wouldn't do on the first iteration. After you got unsecure STUN going you'd probably move on to other things. Once you'd moved on it would always be on that list of things to do, but always below many other things that seem necessary. - It will make it harder for people to deploy STUN servers. Server providers will be unlikely to provide servers if they are not fully functional (it reflects bad on them). They would rather NOT provide a server than provide a half baked server. That would limit the proliferation of servers. - Bear in mind also that good cryptography is not just about factoring large numbers etc, it's about securely storing keys etc. This is hard to do and server providers may not be willing to hand their private keys over to a bit of free-ware. - If something is difficult to implement, individuals will be less inclined to implement it and companies will be less inclined to make copies publicly available. This will limit the proliferation of STUN servers. Overall, something to worry about. I also feel we are making the association between 'secure ==> cryptographic' as a knee jerk reaction. While this relationship is often the case, I don't believe it always is. For example, hiding one message within a second innocent looking message has been a secure way of conveying messages for years, but it's not what we would recognise as cryptographic here. Still, if you think adopting a cryptographic solution is the only way we'll convince the IESG that it's secure, then I guess cryptographic is the only way to go! Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: "Melinda Shore" To: "Pete Cordell" Cc: Sent: 26 April 2002 15:11 Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN > At 02:18 PM 4/26/02 +0100, Pete Cordell wrote: > >Retries or trying a different server would resolve that. Trying different > >servers would be a better option. > > No, because you don't know if you've lost a packet. That > is to say, the attacker's packet gets through and the > legitimate packet does not. If you think that too unlikely > to be of concern, consider typical internet packet loss > statistics and the situation where the attacker is on the > local network. > > >I could actually assume that the first response was genuine and carry on > >with that. If I subsequently found that another response came in, I would > >only then start thinking about what to do with it (maybe tearing down the > >call). > > In the typical telephone call you have one outbound media > channel. You would not discover the problem until subsequent > telephone calls were placed, and then only if 1) the client > was retaining state between calls, and 2) the call wasn't > followed by a subsequent successful attack. > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Apr 29 18:03:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21290 for ; Mon, 29 Apr 2002 18:03:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA25090 for midcom-archive@odin.ietf.org; Mon, 29 Apr 2002 18:03:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24430; Mon, 29 Apr 2002 17:52:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24402 for ; Mon, 29 Apr 2002 17:51:53 -0400 (EDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21117 for ; Mon, 29 Apr 2002 17:51:49 -0400 (EDT) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.148]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 29 Apr 2002 14:51:19 -0700 Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 29 Apr 2002 14:51:18 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 29 Apr 2002 14:51:18 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 29 Apr 2002 14:51:18 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Mon, 29 Apr 2002 14:47:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Date: Mon, 29 Apr 2002 14:47:23 -0700 Message-ID: Thread-Topic: [midcom] WGLC - Alternatives for 'securing' STUN thread-index: AcHvXgu/OiSB7817Ql2/qOzD8gUuhAAZiIVg From: "Christian Huitema" To: "Pete Cordell" , "Melinda Shore" Cc: X-OriginalArrivalTime: 29 Apr 2002 21:47:24.0652 (UTC) FILETIME=[72CAFAC0:01C1EFC7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA24404 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit The threat that we want to mitigate is the faking of the STUN response by a third party. This is in practice a relatively low level threat, since this faking is only easy to engineer if the third party has access to the same shared link as the user -- e.g. a public access wireless link. But then, third parties with access to the shared link can do all kind of other bad stuff, e.g. fake a DHCP server or play games with ARP. If we use a heavy weight method to fight a low-level risk, there is a great chance that nodes will just use the insecure behavior! So, I agree that we need something simple. When Melinda first mentioned "using STUN over TLS", I was very dubitative: we need to send a UDP packet to the server in order to get the mapping, so at first sight sending something over TLS does not help us. However, after the recent discussion, I believe that we may be onto something with the suggestion to use TLS. The behavior would be the following: 1) Set a TLS connection to the STUN server. 2) Send request over the TLS connection, asking for mapping and id + password pair, as well as a life-time indication. 3) Receive mapping, id and password from the server. Close the TLS connection. At this point, the client knows whether it is behind a NAT. It also has an idea of the mapped address. 4) Send a UDP request to the server, mentioning the id. 5) Receive a UDP response from the server, signed using MD5 or SHA and the password. 6) Check that the signature is correct; if not, ignore. This simple TLS proposal has many advantages over the current certificate based procedure. It does implicitly use certificates, since they are needed to perform the TLS, but it does so through a widely used procedure: implementation is simple. The signature of the UDP messages is through a simple key hash, which requires less computation than a public key operation, and is thus easier to sustain. The id and password are chosen by the server, which means that some classic tricks can be used, e.g.: - embed a form of validity check in the id, which enables some protections against denial of service attacks, - algorithmically derive the passport from the id, which reduces the state in the server to a simple master key -- whose validity can be tied to the life-time of the id-password pair, - make sure that the passwords are actually randomized, which thwarts dictionary attacks against the keyed-hash algorithm. By allocating a life-time to the password, the server can ensure that there will be only one TLS exchange for many mapping requests, thus limiting the overall cost of the system. Overall, this looks like a plausible alternative to the currently specified scheme. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Apr 29 19:03:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22299 for ; Mon, 29 Apr 2002 19:02:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA28829 for midcom-archive@odin.ietf.org; Mon, 29 Apr 2002 19:03:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28409; Mon, 29 Apr 2002 19:00:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28366 for ; Mon, 29 Apr 2002 19:00:32 -0400 (EDT) Received: from exchange_04.2wire.com (exchange_03 [63.203.253.74] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22249 for ; Mon, 29 Apr 2002 19:00:29 -0400 (EDT) Received: by exchange_04.2wire.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Apr 2002 15:58:21 -0700 Message-ID: From: Randy Turner To: "'Christian Huitema '" , "'Pete Cordell '" , "'Melinda Shore '" Cc: "'midcom@ietf.org '" Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Date: Mon, 29 Apr 2002 15:57:16 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org In the STUN server SSL connection procedure, the STUN server is going to provide a certificate to the client, correct? How much certificate validation would be required by the client to properly "trust" the certificate? How would the client be provisioned with "trusted root certs"? This seems like a fair amount of code, on top of the TLS/SSL wrapper. But I agree that it is probably less than the previously mentioned certificate method(s). Randy -----Original Message----- From: Christian Huitema To: Pete Cordell; Melinda Shore Cc: midcom@ietf.org Sent: 4/29/02 2:47 PM Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN The threat that we want to mitigate is the faking of the STUN response by a third party. This is in practice a relatively low level threat, since this faking is only easy to engineer if the third party has access to the same shared link as the user -- e.g. a public access wireless link. But then, third parties with access to the shared link can do all kind of other bad stuff, e.g. fake a DHCP server or play games with ARP. If we use a heavy weight method to fight a low-level risk, there is a great chance that nodes will just use the insecure behavior! So, I agree that we need something simple. When Melinda first mentioned "using STUN over TLS", I was very dubitative: we need to send a UDP packet to the server in order to get the mapping, so at first sight sending something over TLS does not help us. However, after the recent discussion, I believe that we may be onto something with the suggestion to use TLS. The behavior would be the following: 1) Set a TLS connection to the STUN server. 2) Send request over the TLS connection, asking for mapping and id + password pair, as well as a life-time indication. 3) Receive mapping, id and password from the server. Close the TLS connection. At this point, the client knows whether it is behind a NAT. It also has an idea of the mapped address. 4) Send a UDP request to the server, mentioning the id. 5) Receive a UDP response from the server, signed using MD5 or SHA and the password. 6) Check that the signature is correct; if not, ignore. This simple TLS proposal has many advantages over the current certificate based procedure. It does implicitly use certificates, since they are needed to perform the TLS, but it does so through a widely used procedure: implementation is simple. The signature of the UDP messages is through a simple key hash, which requires less computation than a public key operation, and is thus easier to sustain. The id and password are chosen by the server, which means that some classic tricks can be used, e.g.: - embed a form of validity check in the id, which enables some protections against denial of service attacks, - algorithmically derive the passport from the id, which reduces the state in the server to a simple master key -- whose validity can be tied to the life-time of the id-password pair, - make sure that the passwords are actually randomized, which thwarts dictionary attacks against the keyed-hash algorithm. By allocating a life-time to the password, the server can ensure that there will be only one TLS exchange for many mapping requests, thus limiting the overall cost of the system. Overall, this looks like a plausible alternative to the currently specified scheme. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Apr 29 20:21:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24175 for ; Mon, 29 Apr 2002 20:21:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA05564 for midcom-archive@odin.ietf.org; Mon, 29 Apr 2002 20:21:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05485; Mon, 29 Apr 2002 20:19:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05460 for ; Mon, 29 Apr 2002 20:18:59 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24133 for ; Mon, 29 Apr 2002 20:18:56 -0400 (EDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 29 Apr 2002 17:18:27 -0700 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 29 Apr 2002 17:18:27 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 29 Apr 2002 17:18:27 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 29 Apr 2002 17:18:27 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Mon, 29 Apr 2002 17:14:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Date: Mon, 29 Apr 2002 17:14:40 -0700 Message-ID: Thread-Topic: [midcom] WGLC - Alternatives for 'securing' STUN thread-index: AcHv0RUuSZQMUNWsRMK6xZTMS9s+agACvCLA From: "Christian Huitema" To: "Randy Turner" , "Pete Cordell " , "Melinda Shore " Cc: X-OriginalArrivalTime: 30 Apr 2002 00:14:40.0269 (UTC) FILETIME=[053B23D0:01C1EFDC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA05461 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit Validating the certificate of TLS servers is pretty standard stuff -- you check that the name on the certificate is the one you expect, and that it has been issued by an authority you trust. A default list of trusted authorities + keys can be programmed in the device -- for example, there is one shipped with every copy of Windows. We could rat-hole for a long time about the actual trust one should give to these authorities, but remember what is at stake: the mapping of an IP address, not the transfer of billions of dollars... -- Christian Huitema > -----Original Message----- > From: Randy Turner [mailto:rturner@2wire.com] > Sent: Monday, April 29, 2002 3:57 PM > To: Christian Huitema; 'Pete Cordell '; 'Melinda Shore ' > Cc: 'midcom@ietf.org ' > Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN > > > In the STUN server SSL connection procedure, the STUN server is going to > provide a certificate to the client, correct? How much certificate > validation would be required by the client to properly "trust" the > certificate? How would the client be provisioned with "trusted root > certs"? > This seems like a fair amount of code, on top of the TLS/SSL wrapper. But > I > agree that it is probably less than the previously mentioned certificate > method(s). > > Randy > > -----Original Message----- > From: Christian Huitema > To: Pete Cordell; Melinda Shore > Cc: midcom@ietf.org > Sent: 4/29/02 2:47 PM > Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN > > The threat that we want to mitigate is the faking of the STUN response > by a third party. This is in practice a relatively low level threat, > since this faking is only easy to engineer if the third party has access > to the same shared link as the user -- e.g. a public access wireless > link. But then, third parties with access to the shared link can do all > kind of other bad stuff, e.g. fake a DHCP server or play games with ARP. > If we use a heavy weight method to fight a low-level risk, there is a > great chance that nodes will just use the insecure behavior! So, I agree > that we need something simple. > > When Melinda first mentioned "using STUN over TLS", I was very > dubitative: we need to send a UDP packet to the server in order to get > the mapping, so at first sight sending something over TLS does not help > us. However, after the recent discussion, I believe that we may be onto > something with the suggestion to use TLS. The behavior would be the > following: > > 1) Set a TLS connection to the STUN server. > 2) Send request over the TLS connection, asking for mapping and id + > password pair, as well as a life-time indication. > 3) Receive mapping, id and password from the server. Close the TLS > connection. > > At this point, the client knows whether it is behind a NAT. It also has > an idea of the mapped address. > > 4) Send a UDP request to the server, mentioning the id. > 5) Receive a UDP response from the server, signed using MD5 or SHA and > the password. > 6) Check that the signature is correct; if not, ignore. > > This simple TLS proposal has many advantages over the current > certificate based procedure. It does implicitly use certificates, since > they are needed to perform the TLS, but it does so through a widely used > procedure: implementation is simple. The signature of the UDP messages > is through a simple key hash, which requires less computation than a > public key operation, and is thus easier to sustain. The id and password > are chosen by the server, which means that some classic tricks can be > used, e.g.: > > - embed a form of validity check in the id, which enables some > protections against denial of service attacks, > > - algorithmically derive the passport from the id, which reduces the > state in the server to a simple master key -- whose validity can be tied > to the life-time of the id-password pair, > > - make sure that the passwords are actually randomized, which thwarts > dictionary attacks against the keyed-hash algorithm. > > By allocating a life-time to the password, the server can ensure that > there will be only one TLS exchange for many mapping requests, thus > limiting the overall cost of the system. > > Overall, this looks like a plausible alternative to the currently > specified scheme. > > -- Christian Huitema > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Apr 29 20:31:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24289 for ; Mon, 29 Apr 2002 20:31:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA06162 for midcom-archive@odin.ietf.org; Mon, 29 Apr 2002 20:31:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05763; Mon, 29 Apr 2002 20:29:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05728 for ; Mon, 29 Apr 2002 20:29:08 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24233 for ; Mon, 29 Apr 2002 20:29:05 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g3U0RgH14961; Mon, 29 Apr 2002 20:27:43 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Apr 2002 19:27:37 -0500 Message-ID: <70565611B164D511957A001083FCDD56018702AA@va02.va.neustar.com> From: "Peterson, Jon" To: "'Christian Huitema'" , Pete Cordell , Melinda Shore Cc: midcom@ietf.org Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Date: Mon, 29 Apr 2002 19:27:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Well, requiring TLS support would require that STUN clients implement TCP. And certificate processing. And do some complicated asymmetric key operations. TLS adds significantly more RTTs (ClientHello, etc - TLS set-up) to the total count than the previous CMS-based mechanism, although admittedly the TLS Record Layer is probably bless intensive than CMS on a per-message basis. Overall, I would still consider this to be a relatively heavyweight system. Of course, a heavyweight, PKI-based mechanism to deliver a shared secret to a STUN client might be useful in some architectures. I think we should acknowledge, though, that there are other reasonable ways that a shared secret might be communicated to a STUN client. STUN's job as a protocol should be to use that shared secret in the STUN authentication process, regardless of how clients happen to learn the secret. I believe that such a TLS-based mechanism to acquire shared secrets, if we were to design it, should be optional for STUN clients, and indeed it doesn't even need to be part of the STUN protocol at all. I'd be surprised if there wasn't some pre-existing mechanism in the IETF portfolio of standards for the secure downloading of shared secrets in this sort of fashion - and if not, I'd suggest this work should be undertaken as a separable mechanism tooled to this purpose rather than some sort of extension grafted onto STUN. Either way, there would be some independent STUN protocol work to be done to show how such a shared secret could be used in the STUN authentication process. I think that is work that should be undertaken regardless of whether or not TLS will be used to communicate these shared secrets. Is the midcom WG going to develop a timetable for examining work along these lines? Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Monday, April 29, 2002 2:47 PM > To: Pete Cordell; Melinda Shore > Cc: midcom@ietf.org > Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN > > > The threat that we want to mitigate is the faking of the STUN response > by a third party. This is in practice a relatively low level threat, > since this faking is only easy to engineer if the third party has access > to the same shared link as the user -- e.g. a public access wireless > link. But then, third parties with access to the shared link can do all > kind of other bad stuff, e.g. fake a DHCP server or play games with ARP. > If we use a heavy weight method to fight a low-level risk, there is a > great chance that nodes will just use the insecure behavior! So, I agree > that we need something simple. > > When Melinda first mentioned "using STUN over TLS", I was very > dubitative: we need to send a UDP packet to the server in order to get > the mapping, so at first sight sending something over TLS does not help > us. However, after the recent discussion, I believe that we may be onto > something with the suggestion to use TLS. The behavior would be the > following: > > 1) Set a TLS connection to the STUN server. > 2) Send request over the TLS connection, asking for mapping and id + > password pair, as well as a life-time indication. > 3) Receive mapping, id and password from the server. Close the TLS > connection. > > At this point, the client knows whether it is behind a NAT. It also has > an idea of the mapped address. > > 4) Send a UDP request to the server, mentioning the id. > 5) Receive a UDP response from the server, signed using MD5 or SHA and > the password. > 6) Check that the signature is correct; if not, ignore. > > This simple TLS proposal has many advantages over the current > certificate based procedure. It does implicitly use certificates, since > they are needed to perform the TLS, but it does so through a widely used > procedure: implementation is simple. The signature of the UDP messages > is through a simple key hash, which requires less computation than a > public key operation, and is thus easier to sustain. The id and password > are chosen by the server, which means that some classic tricks can be > used, e.g.: > > - embed a form of validity check in the id, which enables some > protections against denial of service attacks, > > - algorithmically derive the passport from the id, which reduces the > state in the server to a simple master key -- whose validity can be tied > to the life-time of the id-password pair, > > - make sure that the passwords are actually randomized, which thwarts > dictionary attacks against the keyed-hash algorithm. > > By allocating a life-time to the password, the server can ensure that > there will be only one TLS exchange for many mapping requests, thus > limiting the overall cost of the system. > > Overall, this looks like a plausible alternative to the currently > specified scheme. > > -- Christian Huitema > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 30 09:00:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18435 for ; Tue, 30 Apr 2002 09:00:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA21735 for midcom-archive@odin.ietf.org; Tue, 30 Apr 2002 09:00:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21523; Tue, 30 Apr 2002 08:54:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21483 for ; Tue, 30 Apr 2002 08:54:04 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18051 for ; Tue, 30 Apr 2002 08:54:01 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3UCrXTZ011037; Tue, 30 Apr 2002 05:53:33 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADS45614; Tue, 30 Apr 2002 05:50:36 -0700 (PDT) Message-Id: <5.1.0.14.0.20020430085138.00a7c3f0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 30 Apr 2002 08:57:59 -0400 To: "Peterson, Jon" From: Melinda Shore Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Cc: midcom@ietf.org In-Reply-To: <70565611B164D511957A001083FCDD56018702AA@va02.va.neustar.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 07:27 PM 4/29/02 -0500, Peterson, Jon wrote: >STUN's job as a protocol >should be to use that shared secret in the STUN authentication process, >regardless of how clients happen to learn the secret. It's probably more common than not that public keys are used to protect sessions that are created to either reach key agreement or simply send keys (public key cryptography being more expensive computationally than symmetric key cryptography), and Christian's proposal is very much in keeping with how keying is done in IETF and other protocols. Are there other opinions on this proposal? Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 30 13:16:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29352 for ; Tue, 30 Apr 2002 13:16:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA09609 for midcom-archive@odin.ietf.org; Tue, 30 Apr 2002 13:16:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09424; Tue, 30 Apr 2002 13:12:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09396 for ; Tue, 30 Apr 2002 13:12:36 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29243 for ; Tue, 30 Apr 2002 13:12:33 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3UHBEN01106; Tue, 30 Apr 2002 12:11:15 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Apr 2002 12:11:09 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E01187ADC@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Christian Huitema'" , Randy Turner , Pete Cordell , Melinda Shore Cc: midcom@ietf.org Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Date: Tue, 30 Apr 2002 12:11:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F06A.04C4A3C0" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F06A.04C4A3C0 Content-Type: text/plain; charset="iso-8859-1" IMO, we should have support for both the options - (1) an (out-of-band) pre-shared secret based mechanism, and (2) a TLS based shared-secret/mapping download mechanism (Huitema's proposal), with (1) being mandatory to implement and with (2) supported by servers who would accept STUN requests from unknown clients. The client would first attempt (1) by setting a flag in the STUN request (indicating its preference for shared secret mechanism) and sending a challenge in the same request. If the server has a shared secret matching the challenge, then it would respond with the MAC in the STUN response. If the server doesn't have a shared secret with the client and it accepts requests from unknown clients, then it would set the flag in the STUN response to a value indicating that it doesn't have a shared secret with the client but it accepts STUN requests from clients with whom it doesn't have a pre-shared agreement. Its upto the client to decide whether it would accept the mapping (in this STUN response) or set-up a TLS session with the server to download the shared secret, lifetime and the mapping. The reason I'm arguing for having both options (and many times in the past I've heard that multiple security options are bad), is that there would be many many scenarios where a pre-shared secret would exist (and be adequately maintained) between the client and the service provider that can simply be reused for STUN authentication. On the other hand, I do acknowldge that as many situations without an apriori association would also exist. So we probably need both. Sanjoy > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Monday, April 29, 2002 7:15 PM > To: Randy Turner; Pete Cordell ; Melinda Shore > Cc: midcom@ietf.org > Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN > > > Validating the certificate of TLS servers is pretty standard stuff -- > you check that the name on the certificate is the one you expect, and > that it has been issued by an authority you trust. A default list of > trusted authorities + keys can be programmed in the device -- for > example, there is one shipped with every copy of Windows. We could > rat-hole for a long time about the actual trust one should > give to these > authorities, but remember what is at stake: the mapping of an IP > address, not the transfer of billions of dollars... > > -- Christian Huitema > > > -----Original Message----- > > From: Randy Turner [mailto:rturner@2wire.com] > > Sent: Monday, April 29, 2002 3:57 PM > > To: Christian Huitema; 'Pete Cordell '; 'Melinda Shore ' > > Cc: 'midcom@ietf.org ' > > Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN > > > > > > In the STUN server SSL connection procedure, the STUN > server is going > to > > provide a certificate to the client, correct? How much certificate > > validation would be required by the client to properly "trust" the > > certificate? How would the client be provisioned with "trusted root > > certs"? > > This seems like a fair amount of code, on top of the > TLS/SSL wrapper. > But > > I > > agree that it is probably less than the previously mentioned > certificate > > method(s). > > > > Randy > > > > -----Original Message----- > > From: Christian Huitema > > To: Pete Cordell; Melinda Shore > > Cc: midcom@ietf.org > > Sent: 4/29/02 2:47 PM > > Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN > > > > The threat that we want to mitigate is the faking of the > STUN response > > by a third party. This is in practice a relatively low level threat, > > since this faking is only easy to engineer if the third party has > access > > to the same shared link as the user -- e.g. a public access wireless > > link. But then, third parties with access to the shared link can do > all > > kind of other bad stuff, e.g. fake a DHCP server or play games with > ARP. > > If we use a heavy weight method to fight a low-level risk, > there is a > > great chance that nodes will just use the insecure behavior! So, I > agree > > that we need something simple. > > > > When Melinda first mentioned "using STUN over TLS", I was very > > dubitative: we need to send a UDP packet to the server in > order to get > > the mapping, so at first sight sending something over TLS does not > help > > us. However, after the recent discussion, I believe that we may be > onto > > something with the suggestion to use TLS. The behavior would be the > > following: > > > > 1) Set a TLS connection to the STUN server. > > 2) Send request over the TLS connection, asking for mapping and id + > > password pair, as well as a life-time indication. > > 3) Receive mapping, id and password from the server. Close the TLS > > connection. > > > > At this point, the client knows whether it is behind a NAT. It also > has > > an idea of the mapped address. > > > > 4) Send a UDP request to the server, mentioning the id. > > 5) Receive a UDP response from the server, signed using MD5 > or SHA and > > the password. > > 6) Check that the signature is correct; if not, ignore. > > > > This simple TLS proposal has many advantages over the current > > certificate based procedure. It does implicitly use certificates, > since > > they are needed to perform the TLS, but it does so through a widely > used > > procedure: implementation is simple. The signature of the > UDP messages > > is through a simple key hash, which requires less computation than a > > public key operation, and is thus easier to sustain. The id and > password > > are chosen by the server, which means that some classic > tricks can be > > used, e.g.: > > > > - embed a form of validity check in the id, which enables some > > protections against denial of service attacks, > > > > - algorithmically derive the passport from the id, which reduces the > > state in the server to a simple master key -- whose validity can be > tied > > to the life-time of the id-password pair, > > > > - make sure that the passwords are actually randomized, > which thwarts > > dictionary attacks against the keyed-hash algorithm. > > > > By allocating a life-time to the password, the server can > ensure that > > there will be only one TLS exchange for many mapping requests, thus > > limiting the overall cost of the system. > > > > Overall, this looks like a plausible alternative to the currently > > specified scheme. > > > > -- Christian Huitema > > > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C1F06A.04C4A3C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] WGLC - Alternatives for 'securing' STUN

IMO, we should have support for both the options - = (1) an (out-of-band) pre-shared secret based mechanism, and (2) a TLS = based shared-secret/mapping download mechanism (Huitema's proposal), = with (1) being mandatory to implement and with (2) supported by servers = who would accept STUN requests from unknown clients.

The client would first attempt (1) by setting a flag = in the STUN request (indicating its preference for shared secret = mechanism) and sending a challenge in the same request. If the server = has a shared secret matching the challenge, then it would respond with = the MAC in the STUN response. If the server doesn't have a shared = secret with the client and it accepts requests from unknown clients, = then it would set the flag in the STUN response to a value indicating = that it doesn't have a shared secret with the client but it accepts = STUN requests from clients with whom it doesn't have a pre-shared = agreement. Its upto the client to decide whether it would accept the = mapping (in this STUN response) or set-up a TLS session with the server = to download the shared secret, lifetime and the mapping.

The reason I'm arguing for having both options (and = many times in the past I've heard that multiple security options are = bad), is that there would be many many scenarios where a pre-shared = secret would exist (and be adequately maintained) between the client = and the service provider that can simply be reused for STUN = authentication. On the other hand, I do acknowldge that as many = situations without an apriori association would also exist. So we = probably need both.

Sanjoy


> -----Original Message-----
> From: Christian Huitema [mailto:huitema@windows.mic= rosoft.com]
> Sent: Monday, April 29, 2002 7:15 PM
> To: Randy Turner; Pete Cordell ; Melinda Shore =
> Cc: midcom@ietf.org
> Subject: RE: [midcom] WGLC - Alternatives for = 'securing' STUN
>
>
> Validating the certificate of TLS servers is = pretty standard stuff --
> you check that the name on the certificate is = the one you expect, and
> that it has been issued by an authority you = trust. A default list of
> trusted authorities + keys can be programmed in = the device -- for
> example, there is one shipped with every copy = of Windows. We could
> rat-hole for a long time about the actual trust = one should
> give to these
> authorities, but remember what is at stake: the = mapping of an IP
> address, not the transfer of billions of = dollars...
>
> -- Christian Huitema
>
> > -----Original Message-----
> > From: Randy Turner [mailto:rturner@2wire.com]
> > Sent: Monday, April 29, 2002 3:57 = PM
> > To: Christian Huitema; 'Pete Cordell '; = 'Melinda Shore '
> > Cc: 'midcom@ietf.org '
> > Subject: RE: [midcom] WGLC - Alternatives = for 'securing' STUN
> >
> >
> > In the STUN server SSL connection = procedure, the STUN
> server is going
> to
> > provide a certificate to the client, = correct?  How much certificate
> > validation would be required by the client = to properly "trust" the
> > certificate? How would the client be = provisioned with "trusted root
> > certs"?
> > This seems like a fair amount of code, on = top of the
> TLS/SSL wrapper.
> But
> > I
> > agree that it is probably less than the = previously mentioned
> certificate
> > method(s).
> >
> > Randy
> >
> > -----Original Message-----
> > From: Christian Huitema
> > To: Pete Cordell; Melinda Shore
> > Cc: midcom@ietf.org
> > Sent: 4/29/02 2:47 PM
> > Subject: RE: [midcom] WGLC - Alternatives = for 'securing' STUN
> >
> > The threat that we want to mitigate is the = faking of the
> STUN response
> > by a third party. This is in practice a = relatively low level threat,
> > since this faking is only easy to engineer = if the third party has
> access
> > to the same shared link as the user -- = e.g. a public access wireless
> > link. But then, third parties with access = to the shared link can do
> all
> > kind of other bad stuff, e.g. fake a DHCP = server or play games with
> ARP.
> > If we use a heavy weight method to fight a = low-level risk,
> there is a
> > great chance that nodes will just use the = insecure behavior! So, I
> agree
> > that we need something simple.
> >
> > When Melinda first mentioned "using = STUN over TLS", I was very
> > dubitative: we need to send a UDP packet = to the server in
> order to get
> > the mapping, so at first sight sending = something over TLS does not
> help
> > us. However, after the recent discussion, = I believe that we may be
> onto
> > something with the suggestion to use TLS. = The behavior would be the
> > following:
> >
> > 1) Set a TLS connection to the STUN = server.
> > 2) Send request over the TLS connection, = asking for mapping and id +
> > password pair, as well as a life-time = indication.
> > 3) Receive mapping, id and password from = the server. Close the TLS
> > connection.
> >
> > At this point, the client knows whether it = is behind a NAT. It also
> has
> > an idea of the mapped address.
> >
> > 4) Send a UDP request to the server, = mentioning the id.
> > 5) Receive a UDP response from the server, = signed using MD5
> or SHA and
> > the password.
> > 6) Check that the signature is correct; if = not, ignore.
> >
> > This simple TLS proposal has many = advantages over the current
> > certificate based procedure. It does = implicitly use certificates,
> since
> > they are needed to perform the TLS, but it = does so through a widely
> used
> > procedure: implementation is simple. The = signature of the
> UDP messages
> > is through a simple key hash, which = requires less computation than a
> > public key operation, and is thus easier = to sustain. The id and
> password
> > are chosen by the server, which means that = some classic
> tricks can be
> > used, e.g.:
> >
> > - embed a form of validity check in the = id, which enables some
> > protections against denial of service = attacks,
> >
> > - algorithmically derive the passport from = the id, which reduces the
> > state in the server to a simple master key = -- whose validity can be
> tied
> > to the life-time of the id-password = pair,
> >
> > - make sure that the passwords are = actually randomized,
> which thwarts
> > dictionary attacks against the keyed-hash = algorithm.
> >
> > By allocating a life-time to the password, = the server can
> ensure that
> > there will be only one TLS exchange for = many mapping requests, thus
> > limiting the overall cost of the = system.
> >
> > Overall, this looks like a plausible = alternative to the currently
> > specified scheme.
> >
> > -- Christian Huitema
> >
> >
> > = _______________________________________________
> > midcom mailing list
> > midcom@ietf.org
> > https://www1.ietf.org/mailman/listinfo/midcom
>
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C1F06A.04C4A3C0-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 30 13:39:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00291 for ; Tue, 30 Apr 2002 13:39:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA11432 for midcom-archive@odin.ietf.org; Tue, 30 Apr 2002 13:39:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11238; Tue, 30 Apr 2002 13:35:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11205 for ; Tue, 30 Apr 2002 13:35:42 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00181 for ; Tue, 30 Apr 2002 13:35:39 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g3UHZ9pY014821; Tue, 30 Apr 2002 10:35:09 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADS52873; Tue, 30 Apr 2002 10:32:13 -0700 (PDT) Message-Id: <5.1.0.14.0.20020430132817.00a6e7f0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 30 Apr 2002 13:39:30 -0400 To: "Sanjoy Sen" From: Melinda Shore Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Cc: midcom@ietf.org In-Reply-To: <933FADF5E673D411B8A30002A5608A0E01187ADC@zrc2c012.us.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 12:11 PM 4/30/02 -0500, Sanjoy Sen wrote: >IMO, we should have support for both the options - (1) an (out-of-band) pre-shared secret based mechanism, and (2) a TLS based shared-secret/mapping download mechanism (Huitema's proposal), with (1) being mandatory to implement and with (2) supported by servers who would accept STUN requests from unknown clients. Options are a generally a bad thing, and in security they can be a very, very bad thing (_pace_ IKE). They can lead to interoperability problems, negotiation-down attacks, and increased complexity in implementation and testing. In this case we don't need to worry about a negotiation-down attack, but we should be aware that given what this protocol does it's highly vulnerable to a known-plaintext attack. That would be mitigated by, at a minimum, not reusing keys. Is that important? It may or may not be, depending on the circumstance. I would hope that in any deployment where security is a high priority they're doing more at the application layer than just passing stuff through a VPN, even though that's typically the extent of protection in today's networks. The level of protection I expect us to provide is at least sufficient protection to be able to hold off the vandals that typically go after Microsoft products, and some of those people are quite sophisticated. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 30 13:50:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00967 for ; Tue, 30 Apr 2002 13:50:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA12342 for midcom-archive@odin.ietf.org; Tue, 30 Apr 2002 13:50:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11900; Tue, 30 Apr 2002 13:44:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11867 for ; Tue, 30 Apr 2002 13:44:00 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00540 for ; Tue, 30 Apr 2002 13:43:56 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.14]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g3UHiPLC010103; Tue, 30 Apr 2002 13:44:29 -0400 (EDT) Message-ID: <3CCED7A4.634E6006@dynamicsoft.com> Date: Tue, 30 Apr 2002 13:43:00 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pete Cordell CC: Melinda Shore , midcom@ietf.org Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN References: <004b01c1ef5e$60654b60$0200000a@tkw> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Sorry for my absence on this thread.... my email back log is enormous at the moment... Pete Cordell wrote: > > I see the problem a bit like this... > > If I have a message written in Chinese on a bit of paper and I want to > know > what it says I have two options: > > 1) I can take it to the Chinese Embassy (in my case in London) and ask > them > to give me an official translation, and sign it to say its authentic. > > 2) I can ask a number of Chinese people locally to translate it. If I > get > consistent results then I can be fairly sure that that's what the > message > says. > > (2) is what I'm suggesting here (simultaneously send 3 or 4 packets to 3 > or > 4 different servers and compare their results). In my case it saves me > from > going all the way to London. It is most certainly NOT the same thing. Each stun request will have a different source port in many cases (symmetric NAT) because you are going to a different destination. Depending on the nat, it might even have a different source IP address. This approach is no substitute for real security, and in fact, is much worse, since it will lull people into a false sense that it provides it, when it doesnt. > > (2) may also be even more reliable than (1) if the message happens to be > in > something like Iraqi and I go to the Iraqi embassy for a translation! With an authenticated server, you know who you are talking to. I suggest you don't send STUN requests to the iraqi stun servers. That solves the problem. With your approach, since you don't know who you are talking to, you might talk to an iraqi server, which happily reports false mapped addresses. Indeed, your approach introduces a dos attack. I can run a server that always hands out incorrect mapped addresses. A client sends a a real server, and then to me, trying to validate the answer. I report a false answer. The client can't tell which is right, so it ends up dropping the call. Nice DOS attack. > > Given that this is a light-weight protocol and a short term solution, I > feel > that it is more likely that such a scheme will be implemented than if it > requires heavy-weight encryption. I think a cryptographic solution will > hinder STUNs adoption for the following reasons: > > - On the client side the cryptography is something you probably wouldn't > do > on the first iteration. After you got unsecure STUN going you'd > probably > move on to other things. Once you'd moved on it would always be on that > list of things to do, but always below many other things that seem > necessary. The point of a security considerations section is to make people aware of the problems that might happen if you don't use security. If they still don't care, then they are asking for trouble. > - Bear in mind also that good cryptography is not just about factoring > large > numbers etc, it's about securely storing keys etc. This is hard to do > and > server providers may not be willing to hand their private keys over to a > bit > of free-ware. I have no idea what this means. > > - If something is difficult to implement, individuals will be less > inclined > to implement it and companies will be less inclined to make copies > publicly > available. This will limit the proliferation of STUN servers. By this argument we shoud do away with cryptographic based security in all protocols. I don't think so. > > Overall, something to worry about. > > I also feel we are making the association between 'secure ==> > cryptographic' > as a knee jerk reaction. While this relationship is often the case, I > don't > believe it always is. For example, hiding one message within a second > innocent looking message has been a secure way of conveying messages for > years, but it's not what we would recognise as cryptographic here. Whether this technique counts as cryptography, I don't know. But, I see little value in arguing about the definition of the term. The best way to provide security is to map your problem to other known problems, and then apply known secure solutions. This is a known problem, with multiple known solutions (each with known limitations and issues). I suggest we use one rather than try to cook up some heuristic which will only sometimes work. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 30 14:03:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01694 for ; Tue, 30 Apr 2002 14:03:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA13894 for midcom-archive@odin.ietf.org; Tue, 30 Apr 2002 14:03:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13188; Tue, 30 Apr 2002 13:59:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13159 for ; Tue, 30 Apr 2002 13:59:48 -0400 (EDT) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01483 for ; Tue, 30 Apr 2002 13:59:44 -0400 (EDT) Received: by shell.nominum.com (Postfix, from userid 11089) id A6C933190C; Tue, 30 Apr 2002 10:59:13 -0700 (PDT) Date: Tue, 30 Apr 2002 10:59:13 -0700 From: Ted Hardie To: Melinda Shore Cc: Sanjoy Sen , midcom@ietf.org Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN Message-ID: <20020430105913.C6345@shell.nominum.com> Reply-To: Ted.Hardie@nominum.com References: <933FADF5E673D411B8A30002A5608A0E01187ADC@zrc2c012.us.norte l.com> <5.1.0.14.0.20020430132817.00a6e7f0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.0.20020430132817.00a6e7f0@localhost>; from mshore@cisco.com on Tue, Apr 30, 2002 at 01:39:30PM -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Tue, Apr 30, 2002 at 01:39:30PM -0400, Melinda Shore wrote: > we should be aware that given what this protocol does it's highly > vulnerable to a known-plaintext attack. That would be mitigated by, > at a minimum, not reusing keys. I suspect that the key will have to be reused at least through the a set of exchanges (so that test of each of the four address/port pairs use the same key). If we don't allow that, the number of TLS set ups and tear downs might be high enough (and take long enough)that there is some risk of mappings changing. If that is the case, is there any replay or hijack threat during the middle of the set of exchanges? regards, Ted Hardie _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 30 14:12:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02140 for ; Tue, 30 Apr 2002 14:12:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA14659 for midcom-archive@odin.ietf.org; Tue, 30 Apr 2002 14:12:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14242; Tue, 30 Apr 2002 14:08:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14213 for ; Tue, 30 Apr 2002 14:08:35 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02014 for ; Tue, 30 Apr 2002 14:08:32 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g3UI848M019719; Tue, 30 Apr 2002 11:08:04 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADS54365; Tue, 30 Apr 2002 11:05:03 -0700 (PDT) Message-Id: <5.1.0.14.0.20020430140858.00aa2710@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 30 Apr 2002 14:12:18 -0400 To: Ted.Hardie@nominum.com From: Melinda Shore Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN Cc: midcom@ietf.org In-Reply-To: <20020430105913.C6345@shell.nominum.com> References: <5.1.0.14.0.20020430132817.00a6e7f0@localhost> <933FADF5E673D411B8A30002A5608A0E01187ADC@zrc2c012.us.norte l.com> <5.1.0.14.0.20020430132817.00a6e7f0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 10:59 AM 4/30/02 -0700, Ted Hardie wrote: >I suspect that the key will have to be reused at least through the a >set of exchanges (so that test of each of the four address/port pairs >use the same key). Right, and I don't see a a problem with that. The problem I'm envisioning is that of an attacker watching several-to-many call setups. I don't think that it's necessary or even desirable to rekey during a single phone call. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 30 14:45:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03879 for ; Tue, 30 Apr 2002 14:45:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA17221 for midcom-archive@odin.ietf.org; Tue, 30 Apr 2002 14:45:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16882; Tue, 30 Apr 2002 14:38:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16798 for ; Tue, 30 Apr 2002 14:38:26 -0400 (EDT) Received: from Mitel.COM ([216.191.234.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03465 for ; Tue, 30 Apr 2002 14:38:23 -0400 (EDT) From: Tom_Gray@Mitel.COM Received: from kanmta01.mitel.com (kanmta01.kanata.mitel.com [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id OAA05680; Tue, 30 Apr 2002 14:32:09 -0400 (EDT) Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN To: "Christian Huitema" Cc: "Pete Cordell" , "Melinda Shore" , Date: Tue, 30 Apr 2002 14:10:15 -0400 Message-ID: X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.7 |March 21, 2001) at 04/30/2002 02:32:09 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Is there a sensitivity to replay attacks here? An attacker sees one valid exchange and then replay that for any further exchanges it sees. The client would receive multiple messages with valid signatures. "Christian Huitema" @ietf.org on 04/29/2002 05:47:23 PM Sent by: midcom-admin@ietf.org To: "Pete Cordell" , "Melinda Shore" cc: Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN The threat that we want to mitigate is the faking of the STUN response by a third party. This is in practice a relatively low level threat, since this faking is only easy to engineer if the third party has access to the same shared link as the user -- e.g. a public access wireless link. But then, third parties with access to the shared link can do all kind of other bad stuff, e.g. fake a DHCP server or play games with ARP. If we use a heavy weight method to fight a low-level risk, there is a great chance that nodes will just use the insecure behavior! So, I agree that we need something simple. When Melinda first mentioned "using STUN over TLS", I was very dubitative: we need to send a UDP packet to the server in order to get the mapping, so at first sight sending something over TLS does not help us. However, after the recent discussion, I believe that we may be onto something with the suggestion to use TLS. The behavior would be the following: 1) Set a TLS connection to the STUN server. 2) Send request over the TLS connection, asking for mapping and id + password pair, as well as a life-time indication. 3) Receive mapping, id and password from the server. Close the TLS connection. At this point, the client knows whether it is behind a NAT. It also has an idea of the mapped address. 4) Send a UDP request to the server, mentioning the id. 5) Receive a UDP response from the server, signed using MD5 or SHA and the password. 6) Check that the signature is correct; if not, ignore. This simple TLS proposal has many advantages over the current certificate based procedure. It does implicitly use certificates, since they are needed to perform the TLS, but it does so through a widely used procedure: implementation is simple. The signature of the UDP messages is through a simple key hash, which requires less computation than a public key operation, and is thus easier to sustain. The id and password are chosen by the server, which means that some classic tricks can be used, e.g.: - embed a form of validity check in the id, which enables some protections against denial of service attacks, - algorithmically derive the passport from the id, which reduces the state in the server to a simple master key -- whose validity can be tied to the life-time of the id-password pair, - make sure that the passwords are actually randomized, which thwarts dictionary attacks against the keyed-hash algorithm. By allocating a life-time to the password, the server can ensure that there will be only one TLS exchange for many mapping requests, thus limiting the overall cost of the system. Overall, this looks like a plausible alternative to the currently specified scheme. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 30 15:17:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05378 for ; Tue, 30 Apr 2002 15:17:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA18968 for midcom-archive@odin.ietf.org; Tue, 30 Apr 2002 15:17:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18737; Tue, 30 Apr 2002 15:12:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18708 for ; Tue, 30 Apr 2002 15:12:39 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04939 for ; Tue, 30 Apr 2002 15:12:36 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.172]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g3UJDOLC010337; Tue, 30 Apr 2002 15:13:27 -0400 (EDT) Message-ID: <3CCEEC7C.EF21B5BD@dynamicsoft.com> Date: Tue, 30 Apr 2002 15:11:56 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Melinda Shore CC: "Peterson, Jon" , midcom@ietf.org Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN References: <5.1.0.14.0.20020430085138.00a7c3f0@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Melinda Shore wrote: > > At 07:27 PM 4/29/02 -0500, Peterson, Jon wrote: > >STUN's job as a protocol > >should be to use that shared secret in the STUN authentication process, > >regardless of how clients happen to learn the secret. > > It's probably more common than not that public keys are > used to protect sessions that are created to either reach > key agreement or simply send keys (public key cryptography > being more expensive computationally than symmetric key > cryptography), and Christian's proposal is very much in > keeping with how keying is done in IETF and other protocols. > > Are there other opinions on this proposal? I'm not sure I fully understand the difference between Jon's proposal and Christians, but I like the idea of using TLS to obtain some kind of keying material to use on the actual stun response. I think it would be worth fleshing out the details. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 30 15:24:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05636 for ; Tue, 30 Apr 2002 15:24:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA19344 for midcom-archive@odin.ietf.org; Tue, 30 Apr 2002 15:24:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19262; Tue, 30 Apr 2002 15:22:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19231 for ; Tue, 30 Apr 2002 15:22:46 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05614 for ; Tue, 30 Apr 2002 15:22:42 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.172]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g3UJN6LC010358; Tue, 30 Apr 2002 15:23:08 -0400 (EDT) Message-ID: <3CCEEEC4.1A232D38@dynamicsoft.com> Date: Tue, 30 Apr 2002 15:21:40 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom_Gray@Mitel.COM CC: Christian Huitema , Pete Cordell , Melinda Shore , midcom@ietf.org Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Tom_Gray@Mitel.COM wrote: > > Is there a sensitivity to replay attacks here? An attacker sees one > valid > exchange and then replay that for any further exchanges it sees. The > client > would receive multiple messages with valid signatures. Thats what nonces are for. They limit the window of opportunity for replay attacks. In our case, since the nonce is client generated, you can use one-time nonces and totally eliminate the possibility of replay attacks. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 30 15:25:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05676 for ; Tue, 30 Apr 2002 15:25:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA19409 for midcom-archive@odin.ietf.org; Tue, 30 Apr 2002 15:25:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19311; Tue, 30 Apr 2002 15:23:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19282 for ; Tue, 30 Apr 2002 15:23:33 -0400 (EDT) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05622 for ; Tue, 30 Apr 2002 15:23:30 -0400 (EDT) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 30 Apr 2002 12:23:02 -0700 Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 30 Apr 2002 12:23:02 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 30 Apr 2002 12:23:01 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 30 Apr 2002 12:23:01 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Tue, 30 Apr 2002 12:19:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Date: Tue, 30 Apr 2002 12:19:13 -0700 Message-ID: Thread-Topic: [midcom] WGLC - Alternatives for 'securing' STUN thread-index: AcHwdNL47d4zEaddQZ66xLkep/ScxAAB2trA From: "Christian Huitema" To: Cc: "Pete Cordell" , "Melinda Shore" , X-OriginalArrivalTime: 30 Apr 2002 19:19:14.0143 (UTC) FILETIME=[EA0CB6F0:01C1F07B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA19283 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit > Is there a sensitivity to replay attacks here? An attacker sees one valid > exchange and then replay that for any further exchanges it sees. The > client > would receive multiple messages with valid signatures. The STUN protocol already incorporates a 128 bit transaction ID, which is a random number selected by the client and copied in the response. The signature covers that number, which provides a very efficient protection against replay attacks. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 30 15:26:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05726 for ; Tue, 30 Apr 2002 15:26:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA19451 for midcom-archive@odin.ietf.org; Tue, 30 Apr 2002 15:26:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19390; Tue, 30 Apr 2002 15:24:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19358 for ; Tue, 30 Apr 2002 15:24:21 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05651 for ; Tue, 30 Apr 2002 15:24:18 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3UJNoTZ025827; Tue, 30 Apr 2002 12:23:50 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADS57596; Tue, 30 Apr 2002 12:20:52 -0700 (PDT) Message-Id: <5.1.0.14.0.20020430152637.00a85d70@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 30 Apr 2002 15:28:07 -0400 To: "Christian Huitema" From: Melinda Shore Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 12:17 PM 4/30/02 -0700, Christian Huitema wrote: >It is true that in any key-hash signature algorithm, the attacker sees >the plain text and the hash. Using a user generated password as key >material in this context would be very weak, since user generated >passwords can fall to dictionary attacks. This is the reason why I >proposed that the server provides the user with a password, which could >well be a 128 binary string of appropriate randomness -- it does not >have to be user friendly. It would be extremely hard to reverse this >kind of key, even if you know the plaintext. I don't think we have to >worry about that. I don't think we need to worry about it with your proposal (while acknowledging that there are some really, really terrible random number generators out there). We do need to worry about it with long-lived pre-shared keys. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 30 15:27:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05762 for ; Tue, 30 Apr 2002 15:27:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA19482 for midcom-archive@odin.ietf.org; Tue, 30 Apr 2002 15:27:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19202; Tue, 30 Apr 2002 15:22:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19171 for ; Tue, 30 Apr 2002 15:22:10 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05580 for ; Tue, 30 Apr 2002 15:22:06 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g3UJLTp6017250; Tue, 30 Apr 2002 12:21:29 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADS57511; Tue, 30 Apr 2002 12:18:30 -0700 (PDT) Message-Id: <5.1.0.14.0.20020430152344.00a804e0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 30 Apr 2002 15:25:44 -0400 To: Jonathan Rosenberg From: Melinda Shore Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN Cc: midcom@ietf.org In-Reply-To: <3CCEEC7C.EF21B5BD@dynamicsoft.com> References: <5.1.0.14.0.20020430085138.00a7c3f0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 03:11 PM 4/30/02 -0400, Jonathan Rosenberg wrote: >I'm not sure I fully understand the difference between Jon's proposal >and Christians, but I like the idea of using TLS to obtain some kind of >keying material to use on the actual stun response. I think it would be >worth fleshing out the details. It would be great if someone could volunteer to turn the proposal into draft text, but I would like to get a handle on the level of either support or objection. I'd rather not find ourselves in last call again facing strong objections to something we'd already discussed and, I thought, resolved. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 30 15:32:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05943 for ; Tue, 30 Apr 2002 15:32:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA20148 for midcom-archive@odin.ietf.org; Tue, 30 Apr 2002 15:32:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19160; Tue, 30 Apr 2002 15:22:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19129 for ; Tue, 30 Apr 2002 15:22:00 -0400 (EDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05558 for ; Tue, 30 Apr 2002 15:21:57 -0400 (EDT) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 30 Apr 2002 12:21:29 -0700 Received: from 157.54.6.150 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 30 Apr 2002 12:21:29 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 30 Apr 2002 12:21:29 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 30 Apr 2002 12:21:27 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Tue, 30 Apr 2002 12:17:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Date: Tue, 30 Apr 2002 12:17:41 -0700 Message-ID: Thread-Topic: [midcom] WGLC - Alternatives for 'securing' STUN thread-index: AcHwbRhE2WMnP26SQwKxsSIAsKMIeQADnoFA From: "Christian Huitema" To: "Melinda Shore" , "Sanjoy Sen" Cc: X-OriginalArrivalTime: 30 Apr 2002 19:17:41.0388 (UTC) FILETIME=[B2C36CC0:01C1F07B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA19130 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit > Options are a generally a bad thing, and in security they can > be a very, very bad thing (_pace_ IKE). They can lead to > interoperability problems, negotiation-down attacks, and > increased complexity in implementation and testing. In this > case we don't need to worry about a negotiation-down attack, but > we should be aware that given what this protocol does it's highly > vulnerable to a known-plaintext attack. That would be mitigated by, > at a minimum, not reusing keys. It is true that in any key-hash signature algorithm, the attacker sees the plain text and the hash. Using a user generated password as key material in this context would be very weak, since user generated passwords can fall to dictionary attacks. This is the reason why I proposed that the server provides the user with a password, which could well be a 128 binary string of appropriate randomness -- it does not have to be user friendly. It would be extremely hard to reverse this kind of key, even if you know the plaintext. I don't think we have to worry about that. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 30 15:38:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06096 for ; Tue, 30 Apr 2002 15:38:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA20365 for midcom-archive@odin.ietf.org; Tue, 30 Apr 2002 15:38:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20229; Tue, 30 Apr 2002 15:33:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20204 for ; Tue, 30 Apr 2002 15:33:41 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05989 for ; Tue, 30 Apr 2002 15:33:38 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.172]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g3UJYVLC010362; Tue, 30 Apr 2002 15:34:32 -0400 (EDT) Message-ID: <3CCEF173.E68E0427@dynamicsoft.com> Date: Tue, 30 Apr 2002 15:33:07 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Melinda Shore CC: Christian Huitema , midcom@ietf.org Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN References: <5.1.0.14.0.20020430152637.00a85d70@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Melinda Shore wrote: > > At 12:17 PM 4/30/02 -0700, Christian Huitema wrote: > >It is true that in any key-hash signature algorithm, the attacker sees > >the plain text and the hash. Using a user generated password as key > >material in this context would be very weak, since user generated > >passwords can fall to dictionary attacks. This is the reason why I > >proposed that the server provides the user with a password, which could > >well be a 128 binary string of appropriate randomness -- it does not > >have to be user friendly. It would be extremely hard to reverse this > >kind of key, even if you know the plaintext. I don't think we have to > >worry about that. > > I don't think we need to worry about it with your proposal > (while acknowledging that there are some really, really terrible > random number generators out there). We do need to worry about > it with long-lived pre-shared keys. Agreed its a problem with long-lived pre-shared keys. That problem can be mitigated using a four-way handshake: request C --------------> S response w/ server nonce C<-----------------S request w/ hash over (secret,server-nonce), client nonce C----------------> S response w/ hash over (secret,client-nonce) C<---------------- S of course, the hashes also include the content of the message as well as the nonce and secret. This is full mutual-auth, and is the same flow as used by http digest for that purpose. However, I am still confused about whether this proposal (TLS to obtain shared secrets) solves the problems Jon raised. It does not eliminate the need for TCP, certs, or any of the other "heavy" stuff. If you allow for provisioned shared secrets rather than using TLS to obtain a short-lived one, it does solve his objection of the need for PKI under all conditions, although all servers would need to implement it for sure... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 30 15:43:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06229 for ; Tue, 30 Apr 2002 15:43:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA20538 for midcom-archive@odin.ietf.org; Tue, 30 Apr 2002 15:43:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20478; Tue, 30 Apr 2002 15:41:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20450 for ; Tue, 30 Apr 2002 15:41:25 -0400 (EDT) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06169 for ; Tue, 30 Apr 2002 15:41:21 -0400 (EDT) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g3UJeQ719587; Tue, 30 Apr 2002 14:40:26 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Apr 2002 14:40:21 -0500 Message-ID: <70565611B164D511957A001083FCDD56018702AF@va02.va.neustar.com> From: "Peterson, Jon" To: "'Melinda Shore'" , "Peterson, Jon" Cc: midcom@ietf.org Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Date: Tue, 30 Apr 2002 14:40:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org TLS does use a public key system (probably RSA) to protect the generation of session keys (using something like AES). But just to be clear from an overhead perspective, that AES session key will actually secure the payload (i.e. the STUN protocol running over TLS) in Christian's example, including the STUN-specific shared secret. So in other words, TLS for STUN-shared secret acquisition would use a public key to negotiate a session key in order to secure another session key. My argument against CMS was never that it was insecure, just intensive, both on the wire and to implement. This TLS proposal has the necessary security properties, but it is also probably overkill. I still think it could be presented as an option (in some environments you'll get TLS for free, and your STUN server's economy won't be upset by the additional overhead of processing TLS set-up) - but again, surely that won't be true in all environments. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Tuesday, April 30, 2002 5:58 AM > To: Peterson, Jon > Cc: midcom@ietf.org > Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN > > > At 07:27 PM 4/29/02 -0500, Peterson, Jon wrote: > >STUN's job as a protocol > >should be to use that shared secret in the STUN > authentication process, > >regardless of how clients happen to learn the secret. > > It's probably more common than not that public keys are > used to protect sessions that are created to either reach > key agreement or simply send keys (public key cryptography > being more expensive computationally than symmetric key > cryptography), and Christian's proposal is very much in > keeping with how keying is done in IETF and other protocols. > > Are there other opinions on this proposal? > > Melinda > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 30 15:49:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06438 for ; Tue, 30 Apr 2002 15:49:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA21131 for midcom-archive@odin.ietf.org; Tue, 30 Apr 2002 15:49:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20618; Tue, 30 Apr 2002 15:44:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20582 for ; Tue, 30 Apr 2002 15:43:59 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06246 for ; Tue, 30 Apr 2002 15:43:50 -0400 (EDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 30 Apr 2002 12:43:22 -0700 Received: from 157.54.8.155 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 30 Apr 2002 12:43:22 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 30 Apr 2002 12:43:22 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 30 Apr 2002 12:43:22 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Tue, 30 Apr 2002 12:39:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Date: Tue, 30 Apr 2002 12:39:34 -0700 Message-ID: Thread-Topic: [midcom] WGLC - Alternatives for 'securing' STUN thread-index: AcHwfVYu9aYKxwUKS+qMMIWPpzLAIAAATjTg From: "Christian Huitema" To: "Jonathan Rosenberg" , "Melinda Shore" Cc: X-OriginalArrivalTime: 30 Apr 2002 19:39:34.0611 (UTC) FILETIME=[C1815A30:01C1F07E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA20583 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit > However, I am still confused about whether this proposal (TLS to obtain > shared secrets) solves the problems Jon raised. It does not eliminate > the need for TCP, certs, or any of the other "heavy" stuff. If you allow > for provisioned shared secrets rather than using TLS to obtain a > short-lived one, it does solve his objection of the need for PKI under > all conditions, although all servers would need to implement it for > sure... The main advantage of the TLS proposal is that you can reuse well known software components, and also that you perform a lesser number of public key operations. In a SIP context, TLS is pretty much a "must implement" anyhow, so I don't think it creates a particular burden to the endpoint. I don't know whether Jon really believes that he can go away with a UDP only implementation of SIP, but if that is the case the security of STUN should be the least of his concerns. SIP over UDP can be attacked in dozen of creative ways, without even having to resort to fake STUN messages. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 30 15:57:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06681 for ; Tue, 30 Apr 2002 15:57:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA21492 for midcom-archive@odin.ietf.org; Tue, 30 Apr 2002 15:57:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21426; Tue, 30 Apr 2002 15:55:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21396 for ; Tue, 30 Apr 2002 15:55:35 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06563 for ; Tue, 30 Apr 2002 15:55:26 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g3UJsupY025025; Tue, 30 Apr 2002 12:54:56 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADS58723; Tue, 30 Apr 2002 12:52:02 -0700 (PDT) Message-Id: <5.1.0.14.0.20020430154953.00a77080@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 30 Apr 2002 15:59:16 -0400 To: "Peterson, Jon" From: Melinda Shore Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Cc: midcom@ietf.org In-Reply-To: <70565611B164D511957A001083FCDD56018702AF@va02.va.neustar.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 02:40 PM 4/30/02 -0500, Peterson, Jon wrote: >TLS does use a public key system (probably RSA) to protect the generation of >session keys (using something like AES). But just to be clear from an >overhead perspective, that AES session key will actually secure the payload >(i.e. the STUN protocol running over TLS) in Christian's example, including >the STUN-specific shared secret. Not exactly - a TLS channel would be established for key agreement, and the key would then be used to calculate an HMAC for the UDP-transported STUN answer packets. >My argument against CMS was never that it was insecure, just intensive, both >on the wire and to implement. This TLS proposal has the necessary security >properties, but it is also probably overkill. Yes and no. Keying is generally the hardest thing to get right when using crypto technologies, so we shouldn't be surprised that it's an issue in this case. We know there's an easy-to-implement security exposure here and we really do have to protect against it. Visualize your reaction if there were a report in the trade press that company released a product that had an obvious security flaw that it knew about in advance and chose not to correct. I don't want to give away the moral authority to snark at other people's security goofs. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 30 16:17:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07548 for ; Tue, 30 Apr 2002 16:17:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA22980 for midcom-archive@odin.ietf.org; Tue, 30 Apr 2002 16:17:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22607; Tue, 30 Apr 2002 16:12:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22580 for ; Tue, 30 Apr 2002 16:12:15 -0400 (EDT) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07247 for ; Tue, 30 Apr 2002 16:12:11 -0400 (EDT) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g3UKB9721002; Tue, 30 Apr 2002 15:11:09 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Apr 2002 15:11:04 -0500 Message-ID: <70565611B164D511957A001083FCDD56018702B1@va02.va.neustar.com> From: "Peterson, Jon" To: "'Christian Huitema'" , Jonathan Rosenberg , Melinda Shore Cc: midcom@ietf.org Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Date: Tue, 30 Apr 2002 15:11:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Actually, I think STUN has applicability beyond SIP - if STUN were SIP-specific, I wouldn't have raised any concerns about CMS (since personally I would like to encourage all SIP entities to support S/MIME). But STUN is really targeted at a whole class of UDP applications - that suggests to me right off the bat that mandating TCP for STUN might limit the potential applicability of the protocol. I hope, Christian, that your ambitions for this protocol are also larger than just SIP. As far as I can tell (since this question was raised), the main difference between Christian's proposal and mine is that Christian wants to mandate a particular way of acquiring the shared secret, a way that I find a little too expensive (still comparable to the original CMS mechanism, really). I have a hard time seeing why the acquisition of the shared secret is not a separable issue - though I agree there is a requirement that the acquisition itself be appropriately secure. I see no immediate incentive to mandate any single way of acquiring a secret. But aside from that, I haven't detected any opposition to the actual use of the shared secret in STUN. I think agreement on how exactly this shared secret will be used (i.e. one-way or mutual auth, etc) should be our first important work item in exploring this proposal. I think this question of how you learn of keys should be a subsequent work item. In fact, I suspect a proposal along Christian's lines would best be designed as a separate protocol unrelated to STUN. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Tuesday, April 30, 2002 12:40 PM > To: Jonathan Rosenberg; Melinda Shore > Cc: midcom@ietf.org > Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN > > > > However, I am still confused about whether this proposal (TLS to obtain > > shared secrets) solves the problems Jon raised. It does not eliminate > > the need for TCP, certs, or any of the other "heavy" stuff. If you allow > > for provisioned shared secrets rather than using TLS to obtain a > > short-lived one, it does solve his objection of the need for PKI under > > all conditions, although all servers would need to implement it for > > sure... > > The main advantage of the TLS proposal is that you can reuse well known > software components, and also that you perform a lesser number of public > key operations. In a SIP context, TLS is pretty much a "must implement" > anyhow, so I don't think it creates a particular burden to > the endpoint. > > > I don't know whether Jon really believes that he can go away with a UDP > only implementation of SIP, but if that is the case the security of STUN > should be the least of his concerns. SIP over UDP can be attacked in > dozen of creative ways, without even having to resort to fake STUN > messages. > > > -- Christian Huitema > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 30 16:45:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08411 for ; Tue, 30 Apr 2002 16:45:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA24531 for midcom-archive@odin.ietf.org; Tue, 30 Apr 2002 16:45:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24402; Tue, 30 Apr 2002 16:39:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24321 for ; Tue, 30 Apr 2002 16:39:42 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08273 for ; Tue, 30 Apr 2002 16:39:37 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3UKZmN15282; Tue, 30 Apr 2002 15:35:48 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Apr 2002 15:35:42 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E01187ADE@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Jonathan Rosenberg'" , Melinda Shore Cc: Christian Huitema , midcom@ietf.org Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Date: Tue, 30 Apr 2002 15:35:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F086.97D04FE0" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F086.97D04FE0 Content-Type: text/plain; charset="iso-8859-1" I support Jonathan's call flow below for using the Digest-like approach. HTTP Digest provides adequate protection against chosen plain-text attack (which is deemed worse kind of attack than known plain-text) by using 'cnonce' or client nonce as shown in the call flow below. These nonces are sufficiently randomly generated for every transaction to make-up for the inadequecy of long-lived secrets. For TLS you still have to perform the RSA or Diffe-Hellman key exchange, which is processing intensive. The minimum number of messages exchanged is, I think, eight. The server will download certs unless anonymous DH is used. In short, TLS brings a lot of excess baggage, which should be avoided if not required. So my proposal would be to- 1) Make Digest (with both client and server nonce) mandatory 2) Support TLS when its needed (i.e., when there's no shared secret) and the server is willing to build an security association on the fly. Thanks, Sanjoy > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, April 30, 2002 2:33 PM > To: Melinda Shore > Cc: Christian Huitema; midcom@ietf.org > Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN > > > > > Melinda Shore wrote: > > > > At 12:17 PM 4/30/02 -0700, Christian Huitema wrote: > > >It is true that in any key-hash signature algorithm, the > attacker sees > > >the plain text and the hash. Using a user generated password as key > > >material in this context would be very weak, since user generated > > >passwords can fall to dictionary attacks. This is the reason why I > > >proposed that the server provides the user with a > password, which could > > >well be a 128 binary string of appropriate randomness -- > it does not > > >have to be user friendly. It would be extremely hard to > reverse this > > >kind of key, even if you know the plaintext. I don't think > we have to > > >worry about that. > > > > I don't think we need to worry about it with your proposal > > (while acknowledging that there are some really, really terrible > > random number generators out there). We do need to worry about > > it with long-lived pre-shared keys. > > Agreed its a problem with long-lived pre-shared keys. That problem can > be mitigated using a four-way handshake: > > request > C --------------> S > response w/ server nonce > C<-----------------S > > request w/ hash over (secret,server-nonce), client nonce > C----------------> S > > response w/ hash over (secret,client-nonce) > C<---------------- S > > of course, the hashes also include the content of the message > as well as > the nonce and secret. This is full mutual-auth, and is the > same flow as > used by http digest for that purpose. > > > However, I am still confused about whether this proposal (TLS > to obtain > shared secrets) solves the problems Jon raised. It does not eliminate > the need for TCP, certs, or any of the other "heavy" stuff. > If you allow > for provisioned shared secrets rather than using TLS to obtain a > short-lived one, it does solve his objection of the need for PKI under > all conditions, although all servers would need to implement it for > sure... > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C1F086.97D04FE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] WGLC - Alternatives for 'securing' STUN

I support Jonathan's call flow below for using the = Digest-like approach. HTTP Digest provides adequate protection against = chosen plain-text attack (which is deemed worse kind of attack than = known plain-text) by using 'cnonce' or client nonce as shown in the = call flow below. These nonces are sufficiently randomly generated for = every transaction to make-up for the inadequecy of long-lived = secrets.

For TLS you still have to perform the RSA or = Diffe-Hellman key exchange, which is processing intensive. The minimum = number of messages exchanged is, I think, eight. The server will = download certs unless anonymous DH is used. In short, TLS brings a lot = of excess baggage, which should be avoided if not required.

So my proposal would be to-
1) Make Digest (with both client and server nonce) = mandatory
2) Support TLS when its needed (i.e., when there's = no shared secret) and the server is willing to build an security = association on the fly.

Thanks,
Sanjoy

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Tuesday, April 30, 2002 2:33 PM
> To: Melinda Shore
> Cc: Christian Huitema; midcom@ietf.org
> Subject: Re: [midcom] WGLC - Alternatives for = 'securing' STUN
>
>
>
>
> Melinda Shore wrote:
> >
> > At 12:17 PM 4/30/02 -0700, Christian = Huitema wrote:
> > >It is true that in any key-hash = signature algorithm, the
> attacker sees
> > >the plain text and the hash. Using a = user generated password as key
> > >material in this context would be very = weak, since user generated
> > >passwords can fall to dictionary = attacks. This is the reason why I
> > >proposed that the server provides the = user with a
> password, which could
> > >well be a 128 binary string of = appropriate randomness --
> it does not
> > >have to be user friendly. It would be = extremely hard to
> reverse this
> > >kind of key, even if you know the = plaintext. I don't think
> we have to
> > >worry about that.
> >
> > I don't think we need to worry about it = with your proposal
> > (while acknowledging that there are some = really, really terrible
> > random number generators out there).  = We do need to worry about
> > it with long-lived pre-shared keys.
>
> Agreed its a problem with long-lived pre-shared = keys. That problem can
> be mitigated using a four-way handshake:
>
>       = request
> C --------------> S
>    response w/ server = nonce
> C<-----------------S
>
>    request w/ hash over = (secret,server-nonce), client nonce
> C----------------> S
>
>    response w/ hash over = (secret,client-nonce)
> C<---------------- S
>
> of course, the hashes also include the content = of the message
> as well as
> the nonce and secret. This is full mutual-auth, = and is the
> same flow as
> used by http digest for that purpose.
>
>
> However, I am still confused about whether this = proposal (TLS
> to obtain
> shared secrets) solves the problems Jon raised. = It does not eliminate
> the need for TCP, certs, or any of the other = "heavy" stuff.
> If you allow
> for provisioned shared secrets rather than = using TLS to obtain a
> short-lived one, it does solve his objection of = the need for PKI under
> all conditions, although all servers would need = to implement it for
> sure...
>
> -Jonathan R.
>
> --
> Jonathan D. Rosenberg, = Ph.D.            = 72 Eagle Rock Avenue
> Chief = Scientist          &nb= sp;           &nb= sp;  First Floor
> = dynamicsoft          &= nbsp;           &= nbsp;      East Hanover, NJ 07936
> = jdrosen@dynamicsoft.com        &= nbsp;        FAX: (973) = 952-5050
> http://www.jdrosen.net    &nbs= p;           &nbs= p; PH:  (973) 952-5000
> http://www.dynamicsoft.com
>
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C1F086.97D04FE0-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 30 17:22:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09333 for ; Tue, 30 Apr 2002 17:22:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA26839 for midcom-archive@odin.ietf.org; Tue, 30 Apr 2002 17:22:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26711; Tue, 30 Apr 2002 17:16:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26682 for ; Tue, 30 Apr 2002 17:16:48 -0400 (EDT) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09228 for ; Tue, 30 Apr 2002 17:16:42 -0400 (EDT) Received: by shell.nominum.com (Postfix, from userid 11089) id C69643190C; Tue, 30 Apr 2002 14:16:14 -0700 (PDT) Date: Tue, 30 Apr 2002 14:16:14 -0700 From: Ted Hardie To: "Peterson, Jon" Cc: midcom@ietf.org Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN Message-ID: <20020430141614.A15383@shell.nominum.com> Reply-To: Ted.Hardie@nominum.com References: <70565611B164D511957A001083FCDD56018702B1@va02.va.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <70565611B164D511957A001083FCDD56018702B1@va02.va.neustar.com>; from jon.peterson@neustar.biz on Tue, Apr 30, 2002 at 03:11:03PM -0500 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Tue, Apr 30, 2002 at 03:11:03PM -0500, Peterson, Jon wrote: > Actually, I think STUN has applicability beyond SIP - if STUN were > SIP-specific, I wouldn't have raised any concerns about CMS (since > personally I would like to encourage all SIP entities to support S/MIME). > But STUN is really targeted at a whole class of UDP applications Before we start thinking about whole classes of UDP applications, let's remind ourselves that developing STUN is interim work. Taken from the charter: "In the interim, a solution is needed that allows applications to operate in the presence of midcom-unaware middleboxes. To support this, the midcom group will develop or document a protocol or approach that allows clients to indirectly obtain address bindings from midcom- unaware middleboxes, through communications with server elements on the public side of the middlebox. The key goals for this effort are rapid delivery of a simple solution (since it is an interim solution), consistency with the midcom framework, and security. In particular, any proposed interim approaches will address (and document) the architectural and pragmatic concerns described in [UNSAF]." The architectural and pragmatic concerns that are documented in http://search.ietf.org/internet-drafts/draft-iab-unsaf-considerations-01.txt are meant to apply to this work. In particular, see Architectural Considerations (Section 4.) bullet 1.: Precise definition of a specific, limited-scope problem that is to be solved with the UNSAF proposal. A short term fix should not be generalized to solve other problems; this is why "short term fixes usually aren't". regards, Ted Hardie _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 30 17:33:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09720 for ; Tue, 30 Apr 2002 17:33:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA27693 for midcom-archive@odin.ietf.org; Tue, 30 Apr 2002 17:33:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27554; Tue, 30 Apr 2002 17:32:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27527 for ; Tue, 30 Apr 2002 17:32:01 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09688 for ; Tue, 30 Apr 2002 17:31:56 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3ULVMN13380; Tue, 30 Apr 2002 16:31:22 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Apr 2002 16:31:17 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E01187AE0@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Ted.Hardie@nominum.com'" , "Peterson, Jon" Cc: midcom@ietf.org Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Date: Tue, 30 Apr 2002 16:31:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F08E.5A2F5C00" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F08E.5A2F5C00 Content-Type: text/plain; charset="iso-8859-1" Even in the shorter term, STUN is applicable for H.323, Megaco, MGCP, RTSP - many of these clients would not support S/MIME or TCP. > -----Original Message----- > From: Ted Hardie [mailto:Ted.Hardie@nominum.com] > Sent: Tuesday, April 30, 2002 4:16 PM > To: Peterson, Jon > Cc: midcom@ietf.org > Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN > > > On Tue, Apr 30, 2002 at 03:11:03PM -0500, Peterson, Jon wrote: > > Actually, I think STUN has applicability beyond SIP - if STUN were > > SIP-specific, I wouldn't have raised any concerns about CMS (since > > personally I would like to encourage all SIP entities to > support S/MIME). > > But STUN is really targeted at a whole class of UDP applications > > Before we start thinking about whole classes of UDP applications, > let's remind ourselves that developing STUN is interim work. Taken > from the charter: > > "In the interim, a solution is needed that allows applications to > operate in the presence of midcom-unaware middleboxes. To support > this, the midcom group will develop or document a protocol or approach > that allows clients to indirectly obtain address bindings from midcom- > unaware middleboxes, through communications with server elements on > the public side of the middlebox. The key goals for this effort are > rapid delivery of a simple solution (since it is an interim solution), > consistency with the midcom framework, and security. In particular, > any proposed interim approaches will address (and document) the > architectural and pragmatic concerns described in [UNSAF]." > > The architectural and pragmatic concerns that are documented in > http://search.ietf.org/internet-drafts/draft-iab-unsaf-conside rations-01.txt are meant to apply to this work. In particular, see Architectural Considerations (Section 4.) bullet 1.: Precise definition of a specific, limited-scope problem that is to be solved with the UNSAF proposal. A short term fix should not be generalized to solve other problems; this is why "short term fixes usually aren't". regards, Ted Hardie _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C1F08E.5A2F5C00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] WGLC - Alternatives for 'securing' STUN

Even in the shorter term, STUN is applicable for = H.323, Megaco, MGCP, RTSP - many of these clients would not support = S/MIME or TCP.

> -----Original Message-----
> From: Ted Hardie [mailto:Ted.Hardie@nominum.com= ]
> Sent: Tuesday, April 30, 2002 4:16 PM
> To: Peterson, Jon
> Cc: midcom@ietf.org
> Subject: Re: [midcom] WGLC - Alternatives for = 'securing' STUN
>
>
> On Tue, Apr 30, 2002 at 03:11:03PM -0500, = Peterson, Jon wrote:
> > Actually, I think STUN has applicability = beyond SIP - if STUN were
> > SIP-specific, I wouldn't have raised any = concerns about CMS (since
> > personally I would like to encourage all = SIP entities to
> support S/MIME).
> > But STUN is really targeted at a whole = class of UDP applications
>
> Before we start thinking about whole classes of = UDP applications,
> let's remind ourselves that developing STUN is = interim work.  Taken
> from the charter:
>
> "In the interim, a solution is needed that = allows applications to
> operate in the presence of midcom-unaware = middleboxes. To support
> this, the midcom group will develop or document = a protocol or approach
> that allows clients to indirectly obtain = address bindings from midcom-
> unaware middleboxes, through communications = with server elements on
> the public side of the middlebox. The key goals = for this effort are
> rapid delivery of a simple solution (since it = is an interim solution),
> consistency with the midcom framework, and = security. In particular,
> any proposed interim approaches will address = (and document) the
> architectural and pragmatic concerns described = in [UNSAF]."
>
> The architectural and pragmatic concerns that = are documented in
> http://search.ietf.org/internet-drafts/draft-iab-unsaf= -conside
rations-01.txt
are meant to apply to this work.  In = particular, see Architectural
Considerations (Section 4.) bullet 1.:

  Precise definition of a specific, = limited-scope problem that is
  to be solved with the UNSAF = proposal.   A short term fix should
  not be generalized to solve other problems; = this is why  "short
  term fixes usually aren't".


        =         =         =         regards,
        =         =         =         =         Ted = Hardie




_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C1F08E.5A2F5C00-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Apr 30 17:40:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09826 for ; Tue, 30 Apr 2002 17:40:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA27939 for midcom-archive@odin.ietf.org; Tue, 30 Apr 2002 17:40:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27749; Tue, 30 Apr 2002 17:35:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27715 for ; Tue, 30 Apr 2002 17:35:00 -0400 (EDT) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09765 for ; Tue, 30 Apr 2002 17:34:56 -0400 (EDT) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g3ULYS725141; Tue, 30 Apr 2002 16:34:28 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Apr 2002 16:34:23 -0500 Message-ID: <70565611B164D511957A001083FCDD56018702B5@va02.va.neustar.com> From: "Peterson, Jon" To: "'Ted.Hardie@nominum.com'" Cc: midcom@ietf.org Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Date: Tue, 30 Apr 2002 16:34:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Agreed - but the charter doesn't call out to SIP or any other application in particular. The short term problem that the charter does suggest we are fixing is application traversal of midcom-unaware middleboxes. I was merely suggesting below that we not artificially restrict this problem to SIP - I think we would in that case fall short of the chartered goal. Personally, I think STUN has a great UNSAF story - it doesn't increase the value of middleboxes in any obvious way, it only addresses NAT traversal (rather than 'firewall traversal' of questionable legitimacy), it has a good exit strategy... well, and everything else that is already recounted in the UNSAF considerations of the STUN draft. Applications other than SIP that run over UDP deserve to be able to use STUN for NAT traversal. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Ted Hardie [mailto:Ted.Hardie@nominum.com] > Sent: Tuesday, April 30, 2002 2:16 PM > To: Peterson, Jon > Cc: midcom@ietf.org > Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN > > > On Tue, Apr 30, 2002 at 03:11:03PM -0500, Peterson, Jon wrote: > > Actually, I think STUN has applicability beyond SIP - if STUN were > > SIP-specific, I wouldn't have raised any concerns about CMS (since > > personally I would like to encourage all SIP entities to support S/MIME). > > But STUN is really targeted at a whole class of UDP applications > > Before we start thinking about whole classes of UDP applications, > let's remind ourselves that developing STUN is interim work. Taken > from the charter: > > "In the interim, a solution is needed that allows applications to > operate in the presence of midcom-unaware middleboxes. To support > this, the midcom group will develop or document a protocol or approach > that allows clients to indirectly obtain address bindings from midcom- > unaware middleboxes, through communications with server elements on > the public side of the middlebox. The key goals for this effort are > rapid delivery of a simple solution (since it is an interim solution), > consistency with the midcom framework, and security. In particular, > any proposed interim approaches will address (and document) the > architectural and pragmatic concerns described in [UNSAF]." > > The architectural and pragmatic concerns that are documented in > http://search.ietf.org/internet-drafts/draft-iab-unsaf-conside rations-01.txt are meant to apply to this work. In particular, see Architectural Considerations (Section 4.) bullet 1.: Precise definition of a specific, limited-scope problem that is to be solved with the UNSAF proposal. A short term fix should not be generalized to solve other problems; this is why "short term fixes usually aren't". regards, Ted Hardie _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom