From midcom-admin@ietf.org Mon Oct 1 11:38:26 2001 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 LAA20878 for ; Mon, 1 Oct 2001 11:38: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 LAA00938; Mon, 1 Oct 2001 11:07: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 LAA00860 for ; Mon, 1 Oct 2001 11:07:10 -0400 (EDT) Received: from znsgs0ja.europe.nortel.com ([47.165.25.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19881 for ; Mon, 1 Oct 2001 11:07:06 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f91F6Xg14293 for ; Mon, 1 Oct 2001 16:06:33 +0100 (BST) Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com; Mon, 1 Oct 2001 16:06:21 +0100 Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Oct 2001 16:06:12 +0100 Message-ID: <9154CB41F208D5118DD200508BE39C304452AA@zjguc006.europe.nortel.com> From: "Cedric Aoun" To: "'swb@employees.org'" Cc: "Midcom IETF (E-mail)" Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt Date: Mon, 1 Oct 2001 16:06:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14A8A.94C86D70" 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_01C14A8A.94C86D70 Content-Type: text/plain; charset="iso-8859-1" Hi Scott, Please see comments in line. Hope that the comments were not raised before, if so sorry for the spam Thanks Cedric -----Original Message----- From: Scott Brim [mailto:swb@employees.org] Sent: Tuesday, September 18, 2001 4:08 PM To: midcom@ietf.org Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt This is going to be long, because I want to do a more detailed analysis realm identifiers and informant addresses. It's time we went beyond shallow discussion. As I understand the concept, realm identifiers are a local matter -- a particular middlebox decides how it wants to identify the realms connected to it. Agents are expected to communicate with middleboxes and learn what realms they are in. When an agent communicates with another agent, it learns if that agent is in the same realm or not. Based on that it decides whether to send a ruleset to a middlebox. When discussing realm identifiers I'm going to use this figure: +---R1---+ +---R2---+ +---R3---+ | | | | | | | A1A -M1- A2A -M3- | | A1B | | A2B | | A3 | | -M2- -M4- | | | | | || | +--------+ +--------+ |+--------+ | | +--R4------+ +--R5----+ | | | | | +--- A4 -M5- A5 | | | | | +----------+ +--------+ The Rs are realms, the As are agents, the Ms are middleboxes. M5 also connects three realms, at least two with overlapping address space (this is the theoretical situation that was discussed for several days). The problems with realm identifiers are: - Realm identifiers are not just a local matter. Consider ... (1) Coordination of realm identifiers of parallel middleboxes. Suppose agent A1A learns from M1 that it is in realm 42, and agent A1B learns from M2 that it is in realm 65535 (it's the same realm, but the middleboxes are naming them independently). Then when the A1A and A1B exchange invitations, they will exchange addresses for external use because they think they are in different realms. Their packets will be routed between M1 and M2, through R2 (not R1). If R1 and R2 address spaces are overlapping, then packets may inadvertently be spilled further, beyond R2. As a solution, M1 and M2 need to coordinate their realm identifiers. This problem would also occur if A2A and A2B were communicating and got their realm identifiers from M1 and M3 -- it's not limited to the case where middleboxes attach the same realms. ------------- Realm IDs are provisioned against application customer profiles. The application entity co-hosted with the Midcom Agent (MA) contains a mapping of the application customers with the MB reachability information (at least the address), the realms to which the MB is connected.The MB do not provide the realms to the MAs. In the case of standard Middleboxes (MBs), the MB is not connected to more than 2 realms. Let's call them inside and outside as you did in your draft. In the case of provider provisioned Mbs, the MB is splitted to logical Mbs either using a different address for each logical Mb or an identifier + address to associate it with the logical Mb. In case the logical Mb is connected to 2 realms; every thing remains the same as in the previous cases. Things get complicated when the Mb (logical or physical) are requested to connect to more than 2 realms and you have address overlapping. In this case you have 2 outside and you need to name both external realms (relative to the protected entities) differently, and you need to do twice NAT. Since you have address overlapping, the Mb doesn't know to which realm the packet will to come from or go to, you discussed this below.and have some comments below within that section. For this reason we shall need to provide the realm information. ---------------------- (2) Coordination of different middleboxes in a realm. Suppose A1A learns from M1 that it is in realm 42 and A2A learns from M3 that it is in realm 65535, but M1 is calling R2 14285. Then when A1A asks for an address for communicating with realmid 65535, M1 won't know where that is. The first result is that middleboxes have to assume, by default, that any realm id they don't understand is "outside". Inadvertent openings will, without doubt, be created, through administrative merging and splitting, misconfiguration, protocol errors, whatever. The second result is that M1 will need to return a global address, not an R2-specific one (R2 might also be private). As in the previous case packets may go through a different realm, e.g. R3 because they will have global addresses. The solution is that all middleboxes associated with a realm need to be coordinated. A large ISP could have thousands of middleboxes, real or virtual. --------------- When an SP or a big enterprise deploys several MBs, external policy servers are used to prop uniformly policies and configuration parameters (ref to COPS-PR work). We could assume that the Realm IDs are part of them (networks x,y,z : Realm 42; nets a,b,c Realm 50 ...) This will provide the consistency of the realm IDs. In most cases we shall have an inside realm and an outside realm -------------- (3) Finally, multiple overlapping address spaces attached to the same NAT middlebox (this is the theoretical situation we were discussing for the last week or so). Suppose A2A is communicating, using an application layer signaling protocol, with A5. A5 received realmid 42 from M5. M4 doesn't know where that is, and unlike the previous situation, defaulting to "outside" isn't good enough, since in this (theoretical) situation M4 has interfaces to multiple realms where A5's local address and unknown realmid might be valid. When A2A asks M4 for a pinhole/translation for realmid 42, what does M4 do? Either the middlebox needs a map from realmid to interface, for all possible realm identifiers, or the client of A5 must already have been assigned a globally unique address and the middlebox needs to know enough about routing to know how to reach that address. That is, either you need global knowledge of realm identifiers or you're no better than informant addresses even with the realm identifier system. --------------- The realm IDs are provided by the MAs. Consistency between MBs is provided by proper centralized configuration mechanisms -------------- - Using realm identifiers requires coupling of application proxies and agents. Realm identifiers need to be exchanged by agents, since they are the ones speaking to the middleboxes. However, the targets which the realm identifiers point to are first discovered by application signaling. Suppose an application signaling entity and the application agent were separate. Take SIP, for example. If a SIP proxy sends an invitation with a client address, the agent needs to intercept that invitation and somehow discover the realmid of the target. ----------------- The mapping of a customer to a specific realm is achieved through creation of a specific customer profile at the application level, it doesn't require any application modification (depending on the application type, please ref on comment below). But I agree that this specific configuration in the customer profile is an overhead, and could be potentially considered as a show stopper --------------- The only simple way to do that is to piggyback realmid exchange with the application signaling. This makes the midcom scheme much less flexible. For example, in the Midcom WG we have often speculated about placing agents in the same device as the middlebox functions (where the current version of "agents" are now). This tight coupling makes this impossible or at least very difficult. It is architecturally wrong to require all application proxies to be agents and speak the midcom protocol. In summary using realm identifiers requires: - A system for coordinating realm identifier assignment, for both internal and external realms, among middleboxes throughout a realm (possibly configuration). This is additional management overhead and some errors will be difficult to detect. --------- Agreed ----------- - For complex situations, a way for a middlebox to map realm identifiers to interfaces for every realm it might communicate with. ------------- Agreed, practically we shall need to configure an additional parm to the regular one; the realm id --------- - Coupling of agents and application signaling proxies, and new protocol mechanisms for exchanging realm identifiers. -------------- Application modification is not really required (for all applications), the mechanism exist today by using application user ids. The issue is encountered when the id is an address, in device control protocols the id is optional therefore not all implementers may have developed it In SIP the user id (from and to) are mandatory, I think; so we shouldn't have an issue. I recognize that for some none VoIP application we probably need to add the user ids, and your comment is therefore valid. --------------- - Willingness to tolerate a higher possibility of security holes because middleboxes will not have the intelligence to know if a target is inside or outside and must default to believing it is outside, ------------ Unless we provide it the information -------------- and configuration errors are more likely to lead to security holes than other kinds of configuration errors. The advantages of using the realmid scheme are: - It can support almost any situation. In particular it can support control of a middlebox through a NAT, and it can support middleboxes which are not configurable even when they sit between two complex routed topologies (but only when there is only one of these in a domain). - It sends queries to middleboxes less frequently, since it learns (well, some of the time) whether a target is in another realm from other devices, not the middlebox. The advantages of the informant address approach are that it adds no new infrastructure, no configuration or administration overhead, and no security holes. It depends on the middlebox for all its topological knowledge, which is architecturally clean. However, it does not work through NAT, and in the case where a simple middlebox connects two complex realms, it assumes the middlebox at least knows what address prefixes are in the realm shared by the agent and the middlebox. Being able to work through a NAT may have no value at all -- we need customer input on this. ---------- In the case of carrier provided VoIP services, this has a great importance because the Telephony Service Provider devices will be behind Mbs. This is probably the case for other carrier provider applications John raised concerns regarding applicability of anti-spoofing if we do not provide the realm information, we need a way to be able to apply anti-spoofing policies ------------- For the case where the middlebox connects a realm with multiple address prefixes, but the middlebox does not know what they are, there are alternatives to the proposed realm identifier scheme: - Have some other way for agents to discover if they are in the same realm. ----------- and if not which realms they are in --------- - Limit the use of such devices to simple cases. This may be the case today. - Use them in conjunction with more full-featured middleboxes. --------- We need to find a method that is less complex than the first one (realm Id) and doesn't have the caveat of the second one (informant) ----------- More general closing thoughts: The Internet has to be simple or it will be strangled by its complexity. It's not enough for a single system to be simple. There are interactions between systems such that you have to be careful what you assume or require from the underlying Internet behavior or the Internet will ossify. Especially now, when we're about to explore new possibilities in Internet architecture, we want to limit our requirements on it. Limiting what you expect from Internet behavior may require some tradeoffs. We have made such tradeoffs in the past, and Internet services have flourished despite, or more probably because of, them. ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C14A8A.94C86D70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [midcom] draft-brim-midcom-inandout-00.txt

Hi Scott,
Please see comments in line.
Hope that the comments were not raised before, if so = sorry for the spam
Thanks
Cedric

-----Original Message-----
From: Scott Brim [mailto:swb@employees.org]
Sent: Tuesday, September 18, 2001 4:08 PM
To: midcom@ietf.org
Subject: Re: [midcom] = draft-brim-midcom-inandout-00.txt


This is going to be long, because I want to do a more = detailed analysis
realm identifiers and informant addresses.  = It's time we went beyond
shallow discussion.

As I understand the concept, realm identifiers are a = local matter -- a
particular middlebox decides how it wants to = identify the realms
connected to it.  Agents are expected to = communicate with middleboxes
and learn what realms they are in.  When an = agent communicates with
another agent, it learns if that agent is in the = same realm or not.
Based on that it decides whether to send a ruleset = to a middlebox.

When discussing realm identifiers I'm going to use = this figure:


         = +---R1---+  +---R2---+  +---R3---+
         = |        |  = |        |  = |        |
         | = A1A    -M1-  A2A   = -M3-        |
         = |  A1B   |  |   A2B  |  |  = A3    |
         = |        = -M2-        = -M4-        |
         = |        |  = |        | = ||        |
         = +--------+  +--------+ |+--------+
          &nb= sp;           &nb= sp;         |
          &nb= sp;           &nb= sp;         |  = +--R4------+  +--R5----+
          &nb= sp;           &nb= sp;         |  = |          |  = |        |
          &nb= sp;           &nb= sp;         +---   = A4     -M5-   A5   |
          &nb= sp;           &nb= sp;            = |          |  = |        |
          &nb= sp;           &nb= sp;            = +----------+  +--------+

    The Rs are realms, the As are = agents, the Ms are middleboxes.  M5
    also connects three realms, at = least two with overlapping address
    space (this is the theoretical = situation that was discussed for
    several days).

The problems with realm identifiers are:

  - Realm identifiers are not just a local = matter.  Consider ...

    (1) Coordination of realm = identifiers of parallel middleboxes.
    Suppose agent A1A learns from M1 = that it is in realm 42, and agent
    A1B learns from M2 that it is in = realm 65535 (it's the same realm,
    but the middleboxes are naming = them independently).  Then when the
    A1A and A1B exchange invitations, = they will exchange addresses for
    external use because they think = they are in different realms.  Their
    packets will be routed between M1 = and M2, through R2 (not R1).  If
    R1 and R2 address spaces are = overlapping, then packets may
    inadvertently be spilled further, = beyond R2.  As a solution, M1 and
    M2 need to coordinate their realm = identifiers.  This problem would
    also occur if A2A and A2B were = communicating and got their realm
    identifiers from M1 and M3 -- = it's not limited to the case where
    middleboxes attach the same = realms.
-------------
<CA>
Realm IDs are provisioned against application = customer profiles.
The application entity co-hosted with the Midcom = Agent (MA) contains a mapping
of the application customers with the MB = reachability information (at least the address), the realms to which = the
MB is connected.The MB do not provide the realms to = the MAs.
In the case of standard Middleboxes (MBs), the MB is = not connected to more than 2 realms.
Let's call them inside and outside as you did in = your draft.
In the case of provider provisioned Mbs, the MB is = splitted to logical Mbs either using a different address
for each logical Mb or an identifier + address to = associate it with the logical Mb. In case the logical Mb is connected = to 2 realms;

every thing remains the same as in the previous = cases.
Things get complicated when the Mb (logical or = physical) are requested to connect to more than 2 realms and you have = address overlapping.

In this case you have  2 outside and you need to = name both external realms (relative to the protected entities) = differently, and you need to do twice NAT.

Since you have address overlapping, the Mb doesn't = know to which realm the packet will to come from or go to, you = discussed this below.and have some comments

below within that section. For this reason we shall = need to provide the realm information.
</CA>
----------------------
    (2) Coordination of different = middleboxes in a realm.  Suppose A1A
    learns from M1 that it is in = realm 42 and A2A learns from M3 that it
    is in realm 65535, but M1 is = calling R2 14285.  Then when A1A asks
    for an address for communicating = with realmid 65535, M1 won't know
    where that is.  The first = result is that middleboxes have to assume,
    by default, that any realm id = they don't understand is "outside".
    Inadvertent openings will, = without doubt, be created, through
    administrative merging and = splitting, misconfiguration, protocol
    errors, whatever.  The = second result is that M1 will need to return
    a global address, not an = R2-specific one (R2 might also be private).
    As in the previous case packets = may go through a different realm,
    e.g. R3 because they will have = global addresses.  The solution is
    that all middleboxes associated = with a realm need to be coordinated.
    A large ISP could have thousands = of middleboxes, real or virtual.
---------------
<CA>
When an SP or a big enterprise deploys several MBs, = external policy servers are
used to prop uniformly policies and configuration = parameters (ref to COPS-PR work).
We could assume that the Realm IDs are part of them = (networks x,y,z : Realm 42; nets a,b,c Realm 50 ...)
This will provide the consistency of the realm = IDs.
In most cases we shall have an inside realm and an = outside realm
</CA>
--------------
    (3) Finally, multiple overlapping = address spaces attached to the
    same NAT middlebox (this is the = theoretical situation we were
    discussing for the last week or = so).  Suppose A2A is communicating,
    using an application layer = signaling protocol, with A5.  A5 received
    realmid 42 from M5.  M4 = doesn't know where that is, and unlike the
    previous situation, defaulting to = "outside" isn't good enough, since
    in this (theoretical) situation = M4 has interfaces to multiple realms
    where A5's local address and = unknown realmid might be valid.  When
    A2A asks M4 for a = pinhole/translation for realmid 42, what does M4
    do?  Either the middlebox = needs a map from realmid to interface, for
    all possible realm identifiers, = or the client of A5 must already
    have been assigned a globally = unique address and the middlebox needs
    to know enough about routing to = know how to reach that address.
    That is, either you need global = knowledge of realm identifiers or
    you're no better than informant = addresses even with the realm
    identifier system.
---------------
<CA>
The realm IDs are provided by the MAs.
Consistency between MBs is provided by proper = centralized configuration mechanisms
</CA>
--------------
  - Using realm identifiers requires coupling = of application proxies and
    agents.  Realm identifiers = need to be exchanged by agents, since
    they are the ones speaking to the = middleboxes.  However, the targets
    which the realm identifiers point = to are first discovered by
    application signaling.  = Suppose an application signaling entity and
    the application agent were = separate.  Take SIP, for example.  If a
    SIP proxy sends an invitation = with a client address, the agent needs
    to intercept that invitation and = somehow discover the realmid of the
    target.
-----------------
<CA>
The mapping of a customer to a specific realm is = achieved through creation of a specific
customer profile at the application level, it = doesn't require any application modification (depending on the = application type, please ref on comment below).

But I agree that this specific configuration in the = customer profile is an overhead, and could be potentially considered as = a show stopper

</CA>
---------------
  The only simple way to do that is to = piggyback realmid
    exchange with the application = signaling.  This makes the midcom
    scheme much less flexible.  = For example, in the Midcom WG we have
    often speculated about placing = agents in the same device as the
    middlebox functions (where the = current version of "agents" are now).
    This tight coupling makes this = impossible or at least very
    difficult.  It is = architecturally wrong to require all application
    proxies to be agents and speak = the midcom protocol.

In summary using realm identifiers requires:

  - A system for coordinating realm identifier = assignment, for both
    internal and external realms, = among middleboxes throughout a realm
    (possibly configuration).  = This is additional management overhead
    and some errors will be difficult = to detect. 
---------
<CA>
Agreed
</CA>
-----------
  - For complex situations, a way for a = middlebox to map realm
    identifiers to interfaces for = every realm it might communicate with.
-------------
<CA>
Agreed, practically we shall need to configure an = additional parm to the regular one; the realm id
</CA>
---------

  - Coupling of agents and application signaling = proxies, and new
    protocol mechanisms for = exchanging realm identifiers.
--------------
<CA>
Application modification is not really required (for = all applications), the mechanism
exist today by using application user ids.
The issue is encountered when the id is an address, = in device control protocols the id is optional therefore not all = implementers may have developed it

In SIP the user id (from and to) are mandatory, I = think; so we shouldn't have an issue.
I recognize that for some none VoIP application we = probably need to add the user ids, and your comment is therefore = valid.

</CA>
---------------
  - Willingness to tolerate a higher = possibility of security holes
    because middleboxes will not have = the intelligence to know if a
    target is inside or outside and = must default to believing it is
    outside,
------------
<CA>
Unless we provide it the information
</CA>
--------------
and configuration errors are more likely to lead = to
    security holes than other kinds = of configuration errors.

The advantages of using the realmid scheme = are:

  - It can support almost any situation.  = In particular it can support
    control of a middlebox through a = NAT, and it can support middleboxes
    which are not configurable even = when they sit between two complex
    routed topologies (but only when = there is only one of these in a
    domain). 

  - It sends queries to middleboxes less = frequently, since it learns
    (well, some of the time) whether = a target is in another realm from
    other devices, not the = middlebox.

The advantages of the informant address approach are = that it adds no new
infrastructure, no configuration or administration = overhead, and no
security holes.  It depends on the middlebox = for all its topological
knowledge, which is architecturally clean.  = However, it does not work
through NAT, and in the case where a simple = middlebox connects two
complex realms, it assumes the middlebox at least = knows what address
prefixes are in the realm shared by the agent and = the middlebox. 

Being able to work through a NAT may have no value at = all -- we need
customer input on this. 
----------
<CA>
In the case of carrier provided VoIP services, this = has a great importance because the Telephony Service Provider
devices will be behind Mbs.
This is probably the case for other carrier provider = applications
John raised concerns regarding applicability of = anti-spoofing if we do not provide the realm information, we = need
a way to be able to apply anti-spoofing = policies
</CA>
-------------
For the case where the middlebox connects a
realm with multiple address prefixes, but the = middlebox does not know
what they are, there are alternatives to the = proposed realm identifier
scheme:

  - Have some other way for agents to discover = if they are in the same
    realm.
-----------
<CA>
and if not which realms they are in
</CA>
---------
  - Limit the use of such devices to simple = cases.  This may be the case
    today. 

  - Use them in conjunction with more = full-featured middleboxes.
---------
<CA>
We need to find a method that is less complex than = the first one (realm Id) and doesn't have
the caveat of the second one (informant)
</CA>
-----------
More general closing thoughts: The Internet has to = be simple or it will
be strangled by its complexity.  It's not = enough for a single system to
be simple.  There are interactions between = systems such that you have to
be careful what you assume or require from the = underlying Internet
behavior or the Internet will ossify.  = Especially now, when we're about
to explore new possibilities in Internet = architecture, we want to limit
our requirements on it.

Limiting what you expect from Internet behavior may = require some
tradeoffs.  We have made such tradeoffs in the = past, and Internet
services have flourished despite, or more probably = because of, them. 

..Scott


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

------_=_NextPart_001_01C14A8A.94C86D70-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Oct 1 11:45:32 2001 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 LAA21127 for ; Mon, 1 Oct 2001 11:45: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 LAA01384; Mon, 1 Oct 2001 11:20: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 LAA01358 for ; Mon, 1 Oct 2001 11:20:43 -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 LAA20246 for ; Mon, 1 Oct 2001 11:20:39 -0400 (EDT) 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.6/8.9.1) with ESMTP id f91FKCG24604 for ; Mon, 1 Oct 2001 08:20:12 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-119.cisco.com [10.82.192.119]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAB69895; Mon, 1 Oct 2001 08:20:00 -0700 (PDT) Message-Id: <5.1.0.14.0.20011001111749.00a95210@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 01 Oct 2001 11:22:10 -0400 To: midcom From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] That was easy 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 R3b and R59 are deleted, R79 is approved. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Oct 1 11:47:38 2001 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 LAA21220 for ; Mon, 1 Oct 2001 11:47:38 -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 LAA01595; Mon, 1 Oct 2001 11:26: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 LAA01558 for ; Mon, 1 Oct 2001 11:26:42 -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 LAA20439 for ; Mon, 1 Oct 2001 11:26:38 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f91FQNP01261 for ; Mon, 1 Oct 2001 08:26:23 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-119.cisco.com [10.82.192.119]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAB70019; Mon, 1 Oct 2001 08:25:58 -0700 (PDT) Message-Id: <5.1.0.14.0.20011001112606.009d1160@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 01 Oct 2001 11:28:09 -0400 To: midcom From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] More requirements decided 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 Drop: R44 R74 R68 We still haven't come to resolution on R15. We need text that describes the proposed requirement and a decision on that text. So far we haven't been able to reach agreement on what the problem is that's being described. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Oct 1 12:23:30 2001 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 MAA22210 for ; Mon, 1 Oct 2001 12:23: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 MAA03631; Mon, 1 Oct 2001 12:04: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 MAA03600 for ; Mon, 1 Oct 2001 12:04:22 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21701 for ; Mon, 1 Oct 2001 12:04:18 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TB12TGHM; Mon, 1 Oct 2001 12:03:51 -0400 Message-Id: <3.0.5.32.20011001120256.0087ea00@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 01 Oct 2001 12:02:56 -0400 To: Melinda Shore , midcom From: Mark Duffy Subject: Re: [midcom] More requirements decided In-Reply-To: <5.1.0.14.0.20011001112606.009d1160@mira-sjc5-4.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 >We still haven't come to resolution on R15. We need text that >describes the proposed requirement and a decision on that text. >So far we haven't been able to reach agreement on what the >problem is that's being described. > >Melinda I though we were pretty close. We had this: [Bob Penfield] >> The protocol MUST support the ability of an agent to install a ruleset >> that includes multiple types of middlebox functions (e.g. firewall and >> NAT). [Scott Brim] >Rulesets include specifications of actions. A ruleset does not include >a "function" in the sense you seem to be using the term -- for example a >firewall function. A ruleset may include a rule which would be used as >input to a firewall function. > >I don't think the exact words matter much, as long as they don't >thoroughly confuse the WG that comes after us. That's all I'm trying to >avoid. How about this then: The protocol MUST support the ability of an agent to install a ruleset that contains Action Specs governing multiple types of middlebox functions (e.g. firewall and NAT). _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Oct 1 13:01:31 2001 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 NAA23524 for ; Mon, 1 Oct 2001 13:01: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 MAA04870; Mon, 1 Oct 2001 12:38: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 MAA04842 for ; Mon, 1 Oct 2001 12:38:02 -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 MAA22707 for ; Mon, 1 Oct 2001 12:37:58 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id ABE5750F00C6; Mon, 01 Oct 2001 12:37:57 -0400 Message-ID: <005601c14a97$2716b040$2300000a@acmepacket.com> From: "Bob Penfield" To: "Melinda Shore" , "midcom" , "Mark Duffy" References: <3.0.5.32.20011001120256.0087ea00@email.quarrytech.com> Subject: Re: [midcom] More requirements decided Date: Mon, 1 Oct 2001 12:35:58 -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: "Mark Duffy" To: "Melinda Shore" ; "midcom" Sent: Monday, October 01, 2001 12:02 PM Subject: Re: [midcom] More requirements decided > >We still haven't come to resolution on R15. We need text that > >describes the proposed requirement and a decision on that text. > >So far we haven't been able to reach agreement on what the > >problem is that's being described. > > > >Melinda > > > I though we were pretty close. We had this: > > [Bob Penfield] > >> The protocol MUST support the ability of an agent to install a ruleset > >> that includes multiple types of middlebox functions (e.g. firewall and > >> NAT). > > [Scott Brim] > >Rulesets include specifications of actions. A ruleset does not include > >a "function" in the sense you seem to be using the term -- for example a > >firewall function. A ruleset may include a rule which would be used as > >input to a firewall function. > > > >I don't think the exact words matter much, as long as they don't > >thoroughly confuse the WG that comes after us. That's all I'm trying to > >avoid. > > How about this then: > > The protocol MUST support the ability of an agent to install a ruleset that > contains Action Specs governing multiple types of middlebox functions (e.g. > firewall and NAT). > Why do you limit it to the action? s/Action Specs/Filters Specs and Action Specs/ OR ... install a ruleset that governs multiple types of .... > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Oct 1 13:17:54 2001 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 NAA24046 for ; Mon, 1 Oct 2001 13:17: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 MAA05348; Mon, 1 Oct 2001 12:58:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05321 for ; Mon, 1 Oct 2001 12:58:53 -0400 (EDT) Received: from WIN-INET-01.wingroup.windeploy.ntdev.microsoft.com ([131.107.3.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23394 for ; Mon, 1 Oct 2001 12:58:46 -0400 (EDT) Received: from win-hub-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.229]) by WIN-INET-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.3651); Mon, 1 Oct 2001 09:58:04 -0700 Received: from 157.54.5.226 by win-hub-01.wingroup.windeploy.ntdev.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 01 Oct 2001 09:58:04 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by win-hub-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.3651); Mon, 1 Oct 2001 09:58:04 -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(5.0.2195.3651); Mon, 1 Oct 2001 09:57:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] More requirements decided Date: Mon, 1 Oct 2001 09:57:19 -0700 Message-ID: Thread-Topic: [midcom] More requirements decided Thread-Index: AcFKl0IieSRLjk7ITgSdnMBnJ0fuxQAArDDw From: "Christian Huitema" To: "Mark Duffy" , "Melinda Shore" , "midcom" X-OriginalArrivalTime: 01 Oct 2001 16:57:22.0650 (UTC) FILETIME=[23A4B3A0:01C14A9A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA05322 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 protocol MUST support the ability of an agent to install a ruleset > that > contains Action Specs governing multiple types of middlebox functions > (e.g. > firewall and NAT). I would rather not have "functions", but "actions": The protocol MUST support the ability of an agent to install a ruleset that contains Action Specs governing multiple types of middlebox actions (e.g. firewall and NAT). -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Oct 1 13:35:21 2001 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 NAA24557 for ; Mon, 1 Oct 2001 13:35: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 NAA06039; Mon, 1 Oct 2001 13:15: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 NAA06007 for ; Mon, 1 Oct 2001 13:15:00 -0400 (EDT) Received: from ext-ch1gw-3.online-age.net (ext-ch1gw-3.online-age.net [216.34.191.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23936 for ; Mon, 1 Oct 2001 13:14:50 -0400 (EDT) Received: from int-ch1gw-4.online-age.net (int-ch1gw-4 [3.159.232.68]) by ext-ch1gw-3.online-age.net (8.9.3+Sun/8.9.1/990426-RLH) with ESMTP id NAA21287; Mon, 1 Oct 2001 13:14:13 -0400 (EDT) Received: from crdns.crd.ge.com (localhost [127.0.0.1]) by int-ch1gw-4.online-age.net (8.9.3+Sun/8.9.1/990426-RLH) with ESMTP id NAA23688; Mon, 1 Oct 2001 13:14:12 -0400 (EDT) Received: from exc01crdge.crd.ge.com (exc01crdge.crd.ge.com [3.1.116.47]) by crdns.crd.ge.com (8.9.3/8.9.3) with ESMTP id NAA27594; Mon, 1 Oct 2001 13:14:12 -0400 (EDT) Received: by exc01crdge.crd.ge.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Oct 2001 13:13:44 -0400 Message-ID: From: "Bush, Stephen F (CRD)" To: "'midcom@ietf.org'" , "'webi@equinix.com'" , "'nmrg@ibr.cs.tu-bs.de'" , "'ipn-team@list.jpl.nasa.gov'" , "'irtf-iia-interest@apocalypse.org'" Date: Mon, 1 Oct 2001 13:13:40 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] AVNMP Release 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 AVNMP Version 1.3 Release 1.3 of AVNMP (Active Virtual Network Management Prediction) software is available from the download button in http://www.crd.ge.com/~bushsf/an/. Active Networks are a new paradigm in network architecture in which executable code as well as static data may be transmitted in support of fundamental network operation. Intermediate network nodes (e.g. routers) have the capability to execute packet code as the packets travel the network. This requires that intermediate nodes support an Execution Environment (EE). We are beginning to harness active network capability for algorithmic compression and prediction in support of network management; AVNMP is a first step in this direction. Active Virtual Network Management Prediction (AVNMP) provides a network prediction service. Active network state is predicted and propagated throughout the network, allowing the network to simultaneously operate in real time and in the future. State information such as load, CPU utilization, security intrusions, and mobile location and any other state information currently found in Simple Network Management Protocol (SNMP) Management Information Bases can be available for use by the active management system both for the current time and for times in the future. Thus, AVNMP implements a distributed, active, and truly proactive network management system. Active Networks enabled the implementation of new concepts in AVNMP, such as messages that refine their prediction as they travel through the network, as well as several optimizations to the basic AVNMP algorithm, including migration of AVNMP components and reduction in overhead by means of message fusion. A few general notes about the initial release of AVNMP: 1. This release contains the AVNMP code with a sample load prediction application. New versions can be retrieved from http://www.crd.ge.com/~bushsf/an/. 2. The Magician Active Network Execution Environment is required to run AVNMP and can be downloaded from the AVNMP web site as well. 3. Information about an introductory textbook on Active Networks and AVNMP ( Active Networks and Active Network Management: A Proactive Management Framework by Stephen F. Bush and Amit Kulkarni, Kluwer Academic/Plenum Publishers, Boston, March 2001, 200 pp. Hardbound, ISBN 0-306-46560-4) can be found in http://avnmp.sourceforge.net/anabstract.pdf. 4. An SNMP client is required to access and view the AVNMP results stored within the Management Information Base. SNMP packages are available from many sources, one source is http://www.net.cmu.edu/groups/netdev/software.html. Download and compile the snmpwalk utility for your platform and execute: snmpwalk -p 5000 localhost public .1.3.6.1.3.75 to view the entire content of the AVNMP MIB once AVNMP is running. General information about the AVNMP mailing list is at: http://lists.sourceforge.net/lists/listinfo/avnmp-code This research was funded at GE CRD by DARPA/ITO Contract Number: F30602-98-C-0230 supported by the Air Force Research Laboratory/IF. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Oct 1 14:25:41 2001 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 OAA26061 for ; Mon, 1 Oct 2001 14:25: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 OAA07768; Mon, 1 Oct 2001 14:06:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07737 for ; Mon, 1 Oct 2001 14:06:53 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25570 for ; Mon, 1 Oct 2001 14:06:48 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TB12TGRQ; Mon, 1 Oct 2001 14:06:22 -0400 Message-Id: <3.0.5.32.20011001140527.00847100@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 01 Oct 2001 14:05:27 -0400 To: "Bob Penfield" , "Christian Huitema" , "midcom" From: Mark Duffy Subject: Re: [midcom] More requirements decided (R15) In-Reply-To: <005601c14a97$2716b040$2300000a@acmepacket.com> References: <3.0.5.32.20011001120256.0087ea00@email.quarrytech.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 >> The protocol MUST support the ability of an agent to install a ruleset >that >> contains Action Specs governing multiple types of middlebox functions >(e.g. >> firewall and NAT). >> [Bob:] >Why do you limit it to the action? > >s/Action Specs/Filters Specs and Action Specs/ I limited it to the action because I believe that the Filter Spec is *independent* of any of the middlebox functions/actions. I.e. The Ruleset wouuld say for Filter Spec(s) mumble, do this NAT action, this firewall action, and this foobar action. >OR > >... install a ruleset that governs multiple types of .... That's fine and in fact I prefer it because it is more succint! [Christian:] >I would rather not have "functions", but "actions": > >The protocol MUST support the ability of an agent to install a ruleset >that contains Action Specs governing multiple types of middlebox actions >(e.g. firewall and NAT). > >-- Christian Huitema That also sound fine to me. If we integrate Bob's and Christian's: R15': The protocol MUST support the ability of an agent to install a ruleset that governs multiple types of middlebox actions (e.g. firewall and NAT). _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Oct 1 16:04:05 2001 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 QAA29219 for ; Mon, 1 Oct 2001 16:04: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 PAA10522; Mon, 1 Oct 2001 15:48: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 PAA10491 for ; Mon, 1 Oct 2001 15:48:42 -0400 (EDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28853 for ; Mon, 1 Oct 2001 15:48:37 -0400 (EDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 1 Oct 2001 12:48:06 -0700 Received: from 157.54.9.100 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 01 Oct 2001 12:47:55 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 1 Oct 2001 12:47:51 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 1 Oct 2001 12:47:51 -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(5.0.2195.3651); Mon, 1 Oct 2001 12:47:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] More requirements decided (R15) Date: Mon, 1 Oct 2001 12:47:36 -0700 Message-ID: Thread-Topic: [midcom] More requirements decided (R15) Thread-Index: AcFKp3wt3t8JLqvKQTaNsGGEtVHP9wAClDKg From: "Christian Huitema" To: "Mark Duffy" , "Bob Penfield" , "midcom" X-OriginalArrivalTime: 01 Oct 2001 19:47:36.0788 (UTC) FILETIME=[EBBE7940:01C14AB1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA10492 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 > R15': The protocol MUST support the ability of an agent to install a > ruleset that governs multiple types of middlebox actions (e.g. > firewall and > NAT). Good for me. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Oct 1 16:42:58 2001 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 QAA00706 for ; Mon, 1 Oct 2001 16:42: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 QAA11684; Mon, 1 Oct 2001 16:31: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 QAA11659 for ; Mon, 1 Oct 2001 16:31:31 -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 QAA00079 for ; Mon, 1 Oct 2001 16:31:28 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f91KUwq15501 for ; Mon, 1 Oct 2001 13:31:03 -0700 (PDT) Received: from SBRIM-W2K (dhcp-128-107-165-37.cisco.com [128.107.165.37]) by airborne.cisco.com (Mirapoint) with SMTP id AAC88258; Mon, 1 Oct 2001 13:30:54 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Mon, 1 Oct 2001 16:30:57 -0400 Date: Mon, 1 Oct 2001 16:30:57 -0400 From: Scott Brim To: midcom@ietf.org Message-ID: <20011001163057.L516@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [midcom] New requirements bullets, 01 Oct 2001 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 new version of the requirements bullets is available at . I think I got everything right. ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Oct 1 17:54:39 2001 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 RAA02324 for ; Mon, 1 Oct 2001 17: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 RAA13164; Mon, 1 Oct 2001 17:40: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 RAA13134 for ; Mon, 1 Oct 2001 17:40:23 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01983 for ; Mon, 1 Oct 2001 17:40:19 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f91Lcc8P028048; Mon, 1 Oct 2001 17:38:38 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <4A0SMYVV>; Mon, 1 Oct 2001 17:39:40 -0400 Message-ID: From: Jonathan Rosenberg To: "'Abdallah Rayhan'" , Jonathan Rosenberg , Melinda Shore , midcom@ietf.org Subject: RE: [midcom] pre-midcom work item Date: Mon, 1 Oct 2001 17:39:39 -0400 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 Folks, I've just submitted an I-D to the archives, co-authored with Christian Huitema and Rohan Mahy, on what this protocol might look like. Until it appears in the archives, you can pick it up from: http://www.jdrosen.net/papers/draft-rosenberg-midcom-stun-00.txt Its just a step above "echo", but it can determine the presence of nats, diagnose the type, and help determine binding lifetimes. This protocol will suffice to help a SIP enabled voip phone get through a fairly large fraction of nats (full cone and restricted cone, which is about 80-90% of nats depending on who you ask) while still maintaining direct, end-to-end voice transport. The protocol is totally independent of sip; a separate draft (in sipping) is pending on how to use the stun protocol in a sip client. Comments/questions/flames welcome as always. Hopefully this will help clarify the kind of things the new charter item is aiming at. Thanks, Jonathan R. > -----Original Message----- > From: Abdallah Rayhan [mailto:ar_rayhan@yahoo.ca] > Sent: Monday, September 24, 2001 2:21 PM > To: Jonathan Rosenberg; Melinda Shore; midcom@ietf.org > Subject: RE: [midcom] pre-midcom work item > > > --- Jonathan Rosenberg wrote: > > > > Secondly, this introduces > > > new architectural constraints that is going to screw > > > the consensus achieved so far on the architecture draft. > > > > How is that? > > Before amending the charter we at least need to know > what and how this would work. Instead we got a charter > change dictated on us before learning how this > SIP-happy-NAT is going to influence the current architecture, > or being discussed and scrutinized by the WG. > > > > > > > > The deployment argument of IKE/IPSec, IP6, MPLS didnt stop > > > the WGs from developing those standards. Why should we be > > > the exception? > > > > No one is saying that it should not be deployed. Full steam > ahead. We > > need > > midcom, and that hasn't changed. The fact is that midcom can't fully > > solve > > our problems. > > > > Its also worth noting that there are already solutions > being deployed > > today > > that play the role of the proposed addition. Those are all > > proprietary and > > not interoperable. Let us not let that continue. > > What will happen is another beast will be added to the gang. > > _______________________________________________________ > Do You Yahoo!? > Get your free @yahoo.ca address at http://mail.yahoo.ca > --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 2 09:44:28 2001 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 JAA11050 for ; Tue, 2 Oct 2001 09:44: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 JAA12172; Tue, 2 Oct 2001 09:41: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 JAA12143 for ; Tue, 2 Oct 2001 09:41:32 -0400 (EDT) Received: from znsgs0ja.europe.nortel.com ([47.165.25.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10862 for ; Tue, 2 Oct 2001 09:41:28 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f92Deug20535 for ; Tue, 2 Oct 2001 14:40:56 +0100 (BST) Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com; Tue, 2 Oct 2001 14:40:40 +0100 Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Oct 2001 14:40:29 +0100 Message-ID: <9154CB41F208D5118DD200508BE39C304452B6@zjguc006.europe.nortel.com> From: "Cedric Aoun" To: "'Melinda Shore'" , Scott Brim , midcom mail-list Subject: RE: [midcom] accept R3a1 & R3a2 Date: Tue, 2 Oct 2001 14:40:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14B47.C8B57160" 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_01C14B47.C8B57160 Content-Type: text/plain; charset="iso-8859-1" I want to stress that we need a requirement such as: The Midcom protocol MUST work through NATs. Mechanisms such as the informant method will not work through NATs so we should not forget this requirement. In the case of VoIP services provided by service providers (i.e. Telephony Service Providers), the Midcom agent might be behind a NAT . Cedric -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Wednesday, September 26, 2001 4:12 PM To: Scott Brim; midcom mail-list Subject: Re: [midcom] accept R3a1 & R3a2 At 09:40 AM 9/26/01 -0400, Scott Brim wrote: >Would 'must operate through a NAT' be a pathological case? The presence of more than one NAT is not that uncommon, unfortunately. I've personally never heard of multiple middleboxes sharing a single address, other than failover scenarios or clustering, where routing is handled at a lower layer. Are there such things? As I said, it is not my impression that much thought has been given to what this requirement actually means for protocol design. I think we're covered. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C14B47.C8B57160 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] accept R3a1 & R3a2

I want to stress that we need a requirement such = as:
The Midcom protocol MUST work through NATs.
Mechanisms such as the informant method will not = work through NATs so we should not forget this requirement.
In the case of  VoIP services provided by = service providers (i.e. Telephony Service Providers),
the Midcom agent might be behind a NAT .

Cedric

-----Original Message-----
From: Melinda Shore [mailto:mshore@cisco.com]
Sent: Wednesday, September 26, 2001 4:12 PM
To: Scott Brim; midcom mail-list
Subject: Re: [midcom] accept R3a1 & R3a2


At 09:40 AM 9/26/01 -0400, Scott Brim wrote:
>Would 'must operate through a NAT' be a = pathological case?

The presence of more than one NAT is not that = uncommon,
unfortunately.  I've personally never heard of = multiple
middleboxes sharing a single address, other than = failover
scenarios or clustering, where routing is handled at = a
lower layer.  Are there such things?  As I = said, it is not
my impression that much thought has been given to = what
this requirement actually means for protocol = design.  I
think we're covered.

Melinda


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

------_=_NextPart_001_01C14B47.C8B57160-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 2 09:46:04 2001 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 JAA11190 for ; Tue, 2 Oct 2001 09:46:04 -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 JAA12244; Tue, 2 Oct 2001 09:44: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 JAA12212 for ; Tue, 2 Oct 2001 09:44:17 -0400 (EDT) Received: from NREXCH.netrake.net (403217BC.ptr.dia.nextlink.net [64.50.23.188]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11038 for ; Tue, 2 Oct 2001 09:44:13 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: [midcom] pre-midcom work item MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 2 Oct 2001 08:43:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: <7E06D3212981524CA10D2A114937C414073C0D@NREXCH.netrake.net> Thread-Topic: [midcom] pre-midcom work item Thread-Index: AcFKwpbMYjF8+bdzRySAHucbndq/TwAgTadQ From: "Ram Dantu" To: "Jonathan Rosenberg" , "Abdallah Rayhan" , "Melinda Shore" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA12213 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 Jonathan, Following are my observations on the draft. I appreciate if you can confirm/clarify my observations: - How to handle traversal through multiple NATs is not clear in this draft. For example, if the VOIP call goes through more than one service provider, (Section 5, paragraph 4)are the STUN servers going to talk to each other? How are we handling this case? - For every call the NAT bindings have to be discovered. (Section 9.3). This imposes serious limitation to this approach. For example, the latency and scalability issues ? - Determining the timeout discovery (Section 9.2) is trial and error method and very time consuming process and poses scalability and latency problems. - If we run the STUN client in Server, how are we going to pass on the NAT binding to media component (e.g., Section 9.3, paragraph 4) - Security is a big concern. From Section 11. it is clear that the both the STUN client and STUN server are prone to DOS attacks. It seems to me the problem in inherent in the solution. - In Section 11, last paragraph, it is mentioned that if STUN client is within enterprise, the server returns false address. It is not clear to me how this works. Appreciate more text here. - Overall, the solution depends on the discovery by the STUN agent which can be located in the user agent. It appears that there a serious security problem with this solution. - Referring the work in progress documents [1,6] is irritating since the reader cannot get to the documents. Regards Ram Dantu Ph.D., Netrake Corporation 3000 Technology Drive #100, Plano, Texas, 75074 rdantu@netrake.com DISCLAIMER: The opinions expressed in this email are my own and do not represent my employer -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Monday, October 01, 2001 4:40 PM To: 'Abdallah Rayhan'; Jonathan Rosenberg; Melinda Shore; midcom@ietf.org Subject: RE: [midcom] pre-midcom work item Folks, I've just submitted an I-D to the archives, co-authored with Christian Huitema and Rohan Mahy, on what this protocol might look like. Until it appears in the archives, you can pick it up from: http://www.jdrosen.net/papers/draft-rosenberg-midcom-stun-00.txt Its just a step above "echo", but it can determine the presence of nats, diagnose the type, and help determine binding lifetimes. This protocol will suffice to help a SIP enabled voip phone get through a fairly large fraction of nats (full cone and restricted cone, which is about 80-90% of nats depending on who you ask) while still maintaining direct, end-to-end voice transport. The protocol is totally independent of sip; a separate draft (in sipping) is pending on how to use the stun protocol in a sip client. Comments/questions/flames welcome as always. Hopefully this will help clarify the kind of things the new charter item is aiming at. Thanks, Jonathan R. > -----Original Message----- > From: Abdallah Rayhan [mailto:ar_rayhan@yahoo.ca] > Sent: Monday, September 24, 2001 2:21 PM > To: Jonathan Rosenberg; Melinda Shore; midcom@ietf.org > Subject: RE: [midcom] pre-midcom work item > > > --- Jonathan Rosenberg wrote: > > > > Secondly, this introduces > > > new architectural constraints that is going to screw > > > the consensus achieved so far on the architecture draft. > > > > How is that? > > Before amending the charter we at least need to know > what and how this would work. Instead we got a charter > change dictated on us before learning how this > SIP-happy-NAT is going to influence the current architecture, > or being discussed and scrutinized by the WG. > > > > > > > > The deployment argument of IKE/IPSec, IP6, MPLS didnt stop > > > the WGs from developing those standards. Why should we be > > > the exception? > > > > No one is saying that it should not be deployed. Full steam > ahead. We > > need > > midcom, and that hasn't changed. The fact is that midcom can't fully > > solve > > our problems. > > > > Its also worth noting that there are already solutions > being deployed > > today > > that play the role of the proposed addition. Those are all > > proprietary and > > not interoperable. Let us not let that continue. > > What will happen is another beast will be added to the gang. > > _______________________________________________________ > Do You Yahoo!? > Get your free @yahoo.ca address at http://mail.yahoo.ca > --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 2 10:01:13 2001 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 KAA12121 for ; Tue, 2 Oct 2001 10:01: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 JAA12651; Tue, 2 Oct 2001 09:58: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 JAA12564 for ; Tue, 2 Oct 2001 09:58:54 -0400 (EDT) Received: from znsgs0ja.europe.nortel.com ([47.165.25.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11955 for ; Tue, 2 Oct 2001 09:58:50 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f92DwIg25341 for ; Tue, 2 Oct 2001 14:58:18 +0100 (BST) Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com; Tue, 2 Oct 2001 14:57:52 +0100 Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Oct 2001 14:57:40 +0100 Message-ID: <9154CB41F208D5118DD200508BE39C304452B7@zjguc006.europe.nortel.com> From: "Cedric Aoun" To: "Melinda Shore (E-mail)" Cc: "Midcom IETF (E-mail)" Subject: FW: [midcom] More bullets Date: Tue, 2 Oct 2001 14:57:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14B4A.2D95A710" 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_01C14B4A.2D95A710 Content-Type: text/plain; charset="iso-8859-1" Hi Melinda, I think that R74 is useful in case the application requires good reliability. Take the case where 2 redundant Midcom Agents (MA) handles a flows for several hundred of subscribers. If one MA dies, the other will control the rulesets but you need a mechanism for the redundant MA (now active) to synchronize states with the Middlebox. I didn't see any requirement covering state synchronization, this could be part of the how to do hand-over hidden behind R79, but this is not that implicit. Is there anybody in the WG that sees R74 as how to for R79? We could change R74 to be : The midcom protocol MUST allow synchronization of states between the Midcom agent and the Middlebox Thanks Cedric -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Thursday, September 27, 2001 9:44 PM To: midcom Subject: [midcom] More bullets R15: A Midcom agent ought to be able to have a single MIDCOM connection with a middlebox and use the MIDCOM interface on the middlebox to interface with different middlebox functions on the same middlebox interface. I'd like to drop the trailing "interface" on this one and propose keeping this. R44: The protocol MUST permit the expression of direction to be associated with a pin-hole. The direction MUST be specified in terms that apply to external view of the Middlebox. This directionality shall be expressed as 'in', 'out' or 'loopback' (meaning both 'in' and 'out' of the same side of the same Middlebox realm). The proposal is to drop this: we've already accepted R82, which gives broad leeway in descriptions of filtering rules. R74: A Midcom Agent MUST be able to discover what resources are available on a middlebox. Proposal: drop. We've already discussed meaningful error messages. R68: The Midcom Protocol MUST allow for preservation of the control messages once the association has been established. Proposal: drop. Once we get these settled we'll tackle semantics. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C14B4A.2D95A710 Content-Type: text/html; charset="iso-8859-1" FW: [midcom] More bullets

Hi Melinda,
I think that R74 is useful in case the application requires good reliability.
Take the case where 2 redundant Midcom Agents (MA) handles a flows for several hundred of
subscribers. If one MA dies, the other will control the rulesets but you need a mechanism
for the redundant MA (now active) to synchronize states with the Middlebox.
I didn't see any requirement covering state synchronization, this could be part of the how to do hand-over
hidden behind R79, but this is not that implicit. Is there anybody in the WG that sees R74 as how to for
R79?
We could change R74 to be :
The midcom protocol MUST allow synchronization of states between the Midcom agent and the Middlebox

Thanks
Cedric


-----Original Message-----
From: Melinda Shore [mailto:mshore@cisco.com]
Sent: Thursday, September 27, 2001 9:44 PM
To: midcom
Subject: [midcom] More bullets


R15: A Midcom agent ought to be able to have a single MIDCOM
        connection with a middlebox and use the MIDCOM interface on the
        middlebox to interface with different middlebox functions on the
        same middlebox interface.

I'd like to drop the trailing "interface" on this one and propose
keeping this.

R44: The protocol MUST permit the expression of direction to be
        associated with a pin-hole.  The direction MUST be specified in
        terms that apply to external view of the Middlebox.  This
        directionality shall be expressed as 'in', 'out' or 'loopback'
        (meaning both 'in' and 'out' of the same side of the same
        Middlebox realm).

The proposal is to drop this: we've already accepted R82, which gives
broad leeway in descriptions of filtering rules.

R74: A Midcom Agent MUST be able to discover what resources are
        available on a middlebox.

Proposal: drop.  We've already discussed meaningful error messages.

R68: The Midcom Protocol MUST allow for preservation of the control
        messages once the association has been established.

Proposal: drop.

Once we get these settled we'll tackle semantics.

Melinda


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

------_=_NextPart_001_01C14B4A.2D95A710-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 2 10:20:17 2001 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 KAA12955 for ; Tue, 2 Oct 2001 10:20: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 KAA13316; Tue, 2 Oct 2001 10:18: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 KAA13285 for ; Tue, 2 Oct 2001 10:18:05 -0400 (EDT) Received: from znsgs0ja.europe.nortel.com ([47.165.25.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12873 for ; Tue, 2 Oct 2001 10:18:00 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f92EHXg00641 for ; Tue, 2 Oct 2001 15:17:33 +0100 (BST) Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com; Tue, 2 Oct 2001 15:17:14 +0100 Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Oct 2001 15:17:03 +0100 Message-ID: <9154CB41F208D5118DD200508BE39C304452B8@zjguc006.europe.nortel.com> From: "Cedric Aoun" To: "'Christian Huitema'" , Mark Duffy , Bob Penfield , midcom Subject: RE: [midcom] More requirements decided (R15) Date: Tue, 2 Oct 2001 15:16:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14B4C.E57592D0" 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_01C14B4C.E57592D0 Content-Type: text/plain; charset="iso-8859-1" I agree to -----Original Message----- From: Christian Huitema [mailto:huitema@windows.microsoft.com] Sent: Monday, October 01, 2001 9:48 PM To: Mark Duffy; Bob Penfield; midcom Subject: RE: [midcom] More requirements decided (R15) > R15': The protocol MUST support the ability of an agent to install a > ruleset that governs multiple types of middlebox actions (e.g. > firewall and > NAT). Good for me. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C14B4C.E57592D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] More requirements decided (R15)

I agree to

-----Original Message-----
From: Christian Huitema [mailto:huitema@windows.mic= rosoft.com]
Sent: Monday, October 01, 2001 9:48 PM
To: Mark Duffy; Bob Penfield; midcom
Subject: RE: [midcom] More requirements decided = (R15)



> R15': The protocol MUST support the ability of = an agent to install a
> ruleset that governs multiple types of = middlebox actions (e.g.
> firewall and
> NAT).

Good for me.
-- Christian Huitema

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

------_=_NextPart_001_01C14B4C.E57592D0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 2 10:51:23 2001 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 KAA14836 for ; Tue, 2 Oct 2001 10:51: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 KAA14270; Tue, 2 Oct 2001 10:48:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14239 for ; Tue, 2 Oct 2001 10:48:56 -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 KAA14694 for ; Tue, 2 Oct 2001 10:48:52 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A3D43C6D03B8; Tue, 02 Oct 2001 10:48:52 -0400 Message-ID: <004a01c14b50$c9e0bbe0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Cedric Aoun" , "Melinda Shore \(E-mail\)" Cc: "Midcom IETF \(E-mail\)" References: <9154CB41F208D5118DD200508BE39C304452B7@zjguc006.europe.nortel.com> Subject: Re: [midcom] More bullets Date: Tue, 2 Oct 2001 10:44:49 -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: "Cedric Aoun" To: "Melinda Shore (E-mail)" Cc: "Midcom IETF (E-mail)" Sent: Tuesday, October 02, 2001 9:57 AM Subject: FW: [midcom] More bullets > Hi Melinda, > I think that R74 is useful in case the application requires good > reliability. > Take the case where 2 redundant Midcom Agents (MA) handles a flows for > several hundred of > subscribers. If one MA dies, the other will control the rulesets but you > need a mechanism > for the redundant MA (now active) to synchronize states with the Middlebox. > I didn't see any requirement covering state synchronization, this could be > part of the how to do hand-over > hidden behind R79, but this is not that implicit. Is there anybody in the WG > that sees R74 as how to for > R79? > We could change R74 to be : > The midcom protocol MUST allow synchronization of states between the Midcom > agent and the Middlebox > Doesn't R23 cover that? R23: The Midcom Protocol MUST enable the Middlebox and any associated Midcom Agents to establish known and stable state. This must include the case of power failure, or other failure, where the protocol must ensure that any resources used by a failed element can be released. > Thanks > Cedric > > > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Thursday, September 27, 2001 9:44 PM > To: midcom > Subject: [midcom] More bullets > > > R15: A Midcom agent ought to be able to have a single MIDCOM > connection with a middlebox and use the MIDCOM interface on the > middlebox to interface with different middlebox functions on the > same middlebox interface. > > I'd like to drop the trailing "interface" on this one and propose > keeping this. > > R44: The protocol MUST permit the expression of direction to be > associated with a pin-hole. The direction MUST be specified in > terms that apply to external view of the Middlebox. This > directionality shall be expressed as 'in', 'out' or 'loopback' > (meaning both 'in' and 'out' of the same side of the same > Middlebox realm). > > The proposal is to drop this: we've already accepted R82, which gives > broad leeway in descriptions of filtering rules. > > R74: A Midcom Agent MUST be able to discover what resources are > available on a middlebox. > > Proposal: drop. We've already discussed meaningful error messages. > > R68: The Midcom Protocol MUST allow for preservation of the control > messages once the association has been established. > > Proposal: drop. > > Once we get these settled we'll tackle semantics. > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 2 11:18:46 2001 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 LAA16143 for ; Tue, 2 Oct 2001 11:18:46 -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 LAA15291; Tue, 2 Oct 2001 11:16: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 LAA15261 for ; Tue, 2 Oct 2001 11:16:57 -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 LAA16023 for ; Tue, 2 Oct 2001 11:16:52 -0400 (EDT) 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.6/8.9.1) with ESMTP id f92FGRG24759; Tue, 2 Oct 2001 08:16:27 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-6.cisco.com [10.82.192.6]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAL11360; Tue, 2 Oct 2001 08:16:13 -0700 (PDT) Message-Id: <5.1.0.14.0.20011002111710.00a3dec0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Oct 2001 11:18:24 -0400 To: "Bob Penfield" , "Cedric Aoun" From: Melinda Shore Subject: Re: [midcom] More bullets Cc: "Midcom IETF \(E-mail\)" In-Reply-To: <004a01c14b50$c9e0bbe0$2300000a@acmepacket.com> References: <9154CB41F208D5118DD200508BE39C304452B7@zjguc006.europe.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 R74 is already dropped. We won't be reconsidering it. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 2 11:27:36 2001 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 LAA16508 for ; Tue, 2 Oct 2001 11:27: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 LAA15502; Tue, 2 Oct 2001 11:23:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15470 for ; Tue, 2 Oct 2001 11:23:53 -0400 (EDT) Received: from znsgs0ja.europe.nortel.com ([47.165.25.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16403 for ; Tue, 2 Oct 2001 11:23:49 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f92FNEg20353 for ; Tue, 2 Oct 2001 16:23:14 +0100 (BST) Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com; Tue, 2 Oct 2001 16:22:48 +0100 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Oct 2001 16:22:37 +0100 Message-ID: <9154CB41F208D5118DD200508BE39C304452B9@zjguc006.europe.nortel.com> From: "Cedric Aoun" To: "'Bob Penfield'" , "Melinda Shore (E-mail)" Cc: "Midcom IETF (E-mail)" Subject: RE: [midcom] More bullets Date: Tue, 2 Oct 2001 16:22:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14B55.FCB1D220" 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_01C14B55.FCB1D220 Content-Type: text/plain; charset="iso-8859-1" Bob, Yes synchronization is part of the "how to"s for R23, so I agree to drop R74 Thanks :-) Cedric -----Original Message----- From: Bob Penfield [mailto:bpenfield@acmepacket.com] Sent: Tuesday, October 02, 2001 4:45 PM To: Aoun, Cedric [QPD:MA01:EXCH]; Melinda Shore (E-mail) Cc: Midcom IETF (E-mail) Subject: Re: [midcom] More bullets ----- Original Message ----- From: "Cedric Aoun" To: "Melinda Shore (E-mail)" Cc: "Midcom IETF (E-mail)" Sent: Tuesday, October 02, 2001 9:57 AM Subject: FW: [midcom] More bullets > Hi Melinda, > I think that R74 is useful in case the application requires good > reliability. > Take the case where 2 redundant Midcom Agents (MA) handles a flows for > several hundred of > subscribers. If one MA dies, the other will control the rulesets but you > need a mechanism > for the redundant MA (now active) to synchronize states with the Middlebox. > I didn't see any requirement covering state synchronization, this could be > part of the how to do hand-over > hidden behind R79, but this is not that implicit. Is there anybody in the WG > that sees R74 as how to for > R79? > We could change R74 to be : > The midcom protocol MUST allow synchronization of states between the Midcom > agent and the Middlebox > Doesn't R23 cover that? R23: The Midcom Protocol MUST enable the Middlebox and any associated Midcom Agents to establish known and stable state. This must include the case of power failure, or other failure, where the protocol must ensure that any resources used by a failed element can be released. > Thanks > Cedric > > > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Thursday, September 27, 2001 9:44 PM > To: midcom > Subject: [midcom] More bullets > > > R15: A Midcom agent ought to be able to have a single MIDCOM > connection with a middlebox and use the MIDCOM interface on the > middlebox to interface with different middlebox functions on the > same middlebox interface. > > I'd like to drop the trailing "interface" on this one and propose > keeping this. > > R44: The protocol MUST permit the expression of direction to be > associated with a pin-hole. The direction MUST be specified in > terms that apply to external view of the Middlebox. This > directionality shall be expressed as 'in', 'out' or 'loopback' > (meaning both 'in' and 'out' of the same side of the same > Middlebox realm). > > The proposal is to drop this: we've already accepted R82, which gives > broad leeway in descriptions of filtering rules. > > R74: A Midcom Agent MUST be able to discover what resources are > available on a middlebox. > > Proposal: drop. We've already discussed meaningful error messages. > > R68: The Midcom Protocol MUST allow for preservation of the control > messages once the association has been established. > > Proposal: drop. > > Once we get these settled we'll tackle semantics. > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C14B55.FCB1D220 Content-Type: text/html; charset="iso-8859-1" RE: [midcom] More bullets

Bob,
Yes synchronization is part of the "how to"s for R23, so I agree to drop R74
Thanks :-)
Cedric

-----Original Message-----
From: Bob Penfield [mailto:bpenfield@acmepacket.com]
Sent: Tuesday, October 02, 2001 4:45 PM
To: Aoun, Cedric [QPD:MA01:EXCH]; Melinda Shore (E-mail)
Cc: Midcom IETF (E-mail)
Subject: Re: [midcom] More bullets



----- Original Message -----
From: "Cedric Aoun" <CEDRIC.AOUN@nortelnetworks.com>
To: "Melinda Shore (E-mail)" <mshore@cisco.com>
Cc: "Midcom IETF (E-mail)" <midcom@ietf.org>
Sent: Tuesday, October 02, 2001 9:57 AM
Subject: FW: [midcom] More bullets


> Hi Melinda,
> I think that R74 is useful in case the application requires good
> reliability.
> Take the case where 2 redundant Midcom Agents (MA) handles a flows for
> several hundred of
> subscribers. If one MA dies, the other will control the rulesets but you
> need a mechanism
> for the redundant MA (now active) to synchronize states with the
Middlebox.
> I didn't see any requirement covering state synchronization, this could be
> part of the how to do hand-over
> hidden behind R79, but this is not that implicit. Is there anybody in the
WG
> that sees R74 as how to for
> R79?
> We could change R74 to be :
> The midcom protocol MUST allow synchronization of states between the
Midcom
> agent and the Middlebox
>
Doesn't R23 cover that?

R23: The Midcom Protocol MUST enable the Middlebox and any associated
     Midcom Agents to establish known and stable state.  This must
     include the case of power failure, or other failure, where the
     protocol must ensure that any resources used by a failed element
     can be released.



> Thanks
> Cedric
>
>
> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Thursday, September 27, 2001 9:44 PM
> To: midcom
> Subject: [midcom] More bullets
>
>
> R15: A Midcom agent ought to be able to have a single MIDCOM
>         connection with a middlebox and use the MIDCOM interface on the
>         middlebox to interface with different middlebox functions on the
>         same middlebox interface.
>
> I'd like to drop the trailing "interface" on this one and propose
> keeping this.
>
> R44: The protocol MUST permit the expression of direction to be
>         associated with a pin-hole.  The direction MUST be specified in
>         terms that apply to external view of the Middlebox.  This
>         directionality shall be expressed as 'in', 'out' or 'loopback'
>         (meaning both 'in' and 'out' of the same side of the same
>         Middlebox realm).
>
> The proposal is to drop this: we've already accepted R82, which gives
> broad leeway in descriptions of filtering rules.
>
> R74: A Midcom Agent MUST be able to discover what resources are
>         available on a middlebox.
>
> Proposal: drop.  We've already discussed meaningful error messages.
>
> R68: The Midcom Protocol MUST allow for preservation of the control
>         messages once the association has been established.
>
> Proposal: drop.
>
> Once we get these settled we'll tackle semantics.
>
> Melinda
>
>
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C14B55.FCB1D220-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 2 11:33:16 2001 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 LAA16782 for ; Tue, 2 Oct 2001 11:33: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 LAA15649; Tue, 2 Oct 2001 11:29: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 LAA15619 for ; Tue, 2 Oct 2001 11:29:25 -0400 (EDT) Received: from znsgs0ja.europe.nortel.com ([47.165.25.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16565 for ; Tue, 2 Oct 2001 11:29:20 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f92FSsg22030 for ; Tue, 2 Oct 2001 16:28:54 +0100 (BST) Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com; Tue, 2 Oct 2001 16:28:36 +0100 Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Oct 2001 16:28:21 +0100 Message-ID: <9154CB41F208D5118DD200508BE39C304452BA@zjguc006.europe.nortel.com> From: "Cedric Aoun" To: "'Melinda Shore'" , Bob Penfield Cc: "Midcom IETF (E-mail)" Subject: RE: [midcom] More bullets Date: Tue, 2 Oct 2001 16:28:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14B56.DC554150" 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_01C14B56.DC554150 Content-Type: text/plain; charset="iso-8859-1" I don't have any objections since Bob pointed out that it is under R23. sorry for the spam :-) Cedric -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Tuesday, October 02, 2001 5:18 PM To: Bob Penfield; Aoun, Cedric [QPD:MA01:EXCH] Cc: Midcom IETF (E-mail) Subject: Re: [midcom] More bullets R74 is already dropped. We won't be reconsidering it. Melinda ------_=_NextPart_001_01C14B56.DC554150 Content-Type: text/html; charset="iso-8859-1" RE: [midcom] More bullets

I don't have any objections since Bob pointed out that it is under R23.
sorry for the spam :-)
Cedric

-----Original Message-----
From: Melinda Shore [mailto:mshore@cisco.com]
Sent: Tuesday, October 02, 2001 5:18 PM
To: Bob Penfield; Aoun, Cedric [QPD:MA01:EXCH]
Cc: Midcom IETF (E-mail)
Subject: Re: [midcom] More bullets


R74 is already dropped.  We won't be reconsidering it.

Melinda

------_=_NextPart_001_01C14B56.DC554150-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 2 11:35:17 2001 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 LAA16865 for ; Tue, 2 Oct 2001 11: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 LAA15893; Tue, 2 Oct 2001 11:30: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 LAA15862 for ; Tue, 2 Oct 2001 11:30:38 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16614 for ; Tue, 2 Oct 2001 11:30:33 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f92FSq8P002939; Tue, 2 Oct 2001 11:28:52 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <4A0SM5PW>; Tue, 2 Oct 2001 11:29:55 -0400 Message-ID: From: Jonathan Rosenberg To: "'Ram Dantu'" , Abdallah Rayhan , Melinda Shore , midcom@ietf.org Subject: RE: [midcom] pre-midcom work item Date: Tue, 2 Oct 2001 11:29:54 -0400 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 > -----Original Message----- > From: Ram Dantu [mailto:ramd@netrake.com] > Sent: Tuesday, October 02, 2001 9:44 AM > To: Jonathan Rosenberg; Abdallah Rayhan; Melinda Shore; > midcom@ietf.org > Subject: RE: [midcom] pre-midcom work item > > > Jonathan, > > Following are my observations on the > draft. I appreciate if you can confirm/clarify my observations: > > - How to handle traversal through multiple NATs is not > clear in this draft. For example, if the VOIP > call goes through more than one service provider, > (Section 5, paragraph 4)are the STUN servers > going to talk to each other? No, no, definitely not. > How are we handling this case?\ In the stun model, each user has a service provider. The client talks to the stun server of their service provider. Through that communications, they obtain a publically usable IP address for media. That requires no coordination between providers. So, consider the case where I am a user of foo.com (sip:jdrosen@foo.com). When I start my phone, my phone uses stun, and talks to the foo.com stun server on the public Internet. Using the discovery procedure in the spec, my phone discovers that there is at least one nat between me and the public Internet, and that its full cone. Now, when I make a call to sip:alice@bar.edu, I send a stun query to the server, and get back my IP address. I then use that in the SDP in my INVITE. From here, its regular, plain old vanilla sip. I send an INVITE to my proxy at foo.com, and it looks up bar.edu in dns, and forwards the INVITE there. That goes to alice. Alice may be behind a nat - but thats her problem. She would use the stun protocol as well to learn her public ip address, and she would use the bar.edu stun server to do that. Once she gets one, she sends back a 200 OK with that address in the SDP, and we're all set. The detailed usage of stun for sip will be described in a to-be-written I-D for the sipping group. > > - For every call the NAT bindings have to be discovered. > (Section 9.3). This imposes serious limitation to this approach. > For example, the latency and scalability issues ? The usage of stun will add one RTT of latency between a client and the stun server, if one side is behind a nat. If both sides are behind a nat, its two. I don't consider this a serious increase in latency, especially considering the alternative - no media. As for scalability, this scales really well. Stun servers are stateless. You can have farms of them using SRV lookups. What about it doesn't scale? > > - Determining the timeout discovery (Section 9.2) > is trial and error method and very time consuming > process and poses scalability and latency problems. Yeah, it would take a while. Its one of these things you would do in the background when the phone comes on. I don't see the scalability issue though. > > - If we run the STUN client in Server, how are we going > to pass on the NAT binding to media component > (e.g., Section 9.3, paragraph 4) Again, this is something that will be described in far more detail in the sipping draft. The idea here is that within an enterprise, you could have a "B2BUA with media". THis would be a server on the inside of the nat, which receives the INVITE requests from clients within the enterprise. This server would be the one to act as a stun client, and it would rewrite the SDP based on the addresses it receives. It would, as a consequence, be on the media path, so that media from the outside goes to it first, and then to the clients. The advantage of this approach is that it requires no changes in client software, only the addition of this element on the inside of the network. The disadvantage is that it introduces an intermediate point for media relaying. > > - Security is a big concern. From Section 11. > it is clear that the both the STUN client and STUN > server are prone to DOS attacks. It seems to me > the problem in inherent in the solution. Oh? How is that? The stun server is stateless. How can you launch a DoS attack against it? You can flood it with packets, sure, but thats possible for any protocol. I do point out that the stun server can be used for certain DDos attacks against other elements, as its a "reflector". I will, however, note that there are other protocols that send a packet when they receive a packet, which include DNS, SIP, HTTP, and so on. The remedy for this attack is to include the source address of the attacker for tracing purposes, which is what does happen. So, the protocol seems to satisfactorily handle that case. I also don't see how the stun client is prone to attacks. Can you please provide supporting evidence for your claims. > > - In Section 11, last paragraph, it is mentioned that if STUN > client is within enterprise, the server returns false > address. It is not clear to me how this works. > Appreciate more text here. No, no. I am not proposing that a server return false addresses. All I am saying is that a compromise of the stun server cannot introduce new holes into the security perimeter of the enterprise. A stun server does only one thing - returns IP addresses. The worst thing it can do is return the wrong ones, in which case calls don't get set up. > > - Overall, the solution depends on the discovery by the > STUN agent which can be located in the user agent. No. First off, I don't know what a "stun agent" is, as this term is never used in the document. A stun client exists within the user agent, but its not discovered. Its part of the software within the client application. I.e., my PC phone would have some code in it to implement a stun client in order to get IP addresses. >It appears that there a serious security problem with this solution. Unsubstantiated claims like this serve no one. Please provide specific objections. > > - Referring the work in progress documents [1,6] is irritating > since the reader cannot get to the documents. > I am sorry this irritates you. However, these documents are all readily accessible from the IETF site. It is standard practice for an Internet Draft to reference other Internet Drafts. "Work in progress" is the standard terminology required when one references an Internet draft. To save you some trouble, I took a few seconds to get the URLs for you: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-natreq4udp-00.txt http://www.ietf.org/internet-drafts/draft-ietf-nat-app-guide-06.txt -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 2 14:31:09 2001 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 OAA24751 for ; Tue, 2 Oct 2001 14:31:04 -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 OAA21760; Tue, 2 Oct 2001 14:28: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 OAA21732 for ; Tue, 2 Oct 2001 14:28:24 -0400 (EDT) Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24574 for ; Tue, 2 Oct 2001 14:28:19 -0400 (EDT) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.wcom.com (PMDF V5.2-32 #42257) with ESMTP id <0GKL003HNCMFRT@firewall.wcom.com> for midcom@ietf.org; Tue, 2 Oct 2001 18:27:51 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GKL00G01CM9YB@pmismtp03.wcomnet.com>; Tue, 02 Oct 2001 18:27:49 +0000 (GMT) Received: from rccc6131 ([166.35.224.112]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GKL00G4ECLXDZ@pmismtp03.wcomnet.com>; Tue, 02 Oct 2001 18:27:33 +0000 (GMT) Date: Tue, 02 Oct 2001 13:27:25 -0500 From: "Christopher A. Martin" Subject: RE: [midcom] pre-midcom work item In-reply-to: To: "'Jonathan Rosenberg'" , "'Ram Dantu'" , "'Abdallah Rayhan'" , "'Melinda Shore'" , midcom@ietf.org Reply-to: christopher.a.martin@wcom.com Message-id: <008501c14b6f$e2ecb020$70e023a6@rccc6131.mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 jumping in in the middle of this but here goes, my questions are inline > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Jonathan Rosenberg > Sent: Tuesday, October 02, 2001 10:30 AM > To: 'Ram Dantu'; Abdallah Rayhan; Melinda Shore; midcom@ietf.org > Subject: RE: [midcom] pre-midcom work item > > > > > > > > -----Original Message----- > > From: Ram Dantu [mailto:ramd@netrake.com] > > Sent: Tuesday, October 02, 2001 9:44 AM > > To: Jonathan Rosenberg; Abdallah Rayhan; Melinda Shore; > > midcom@ietf.org > > Subject: RE: [midcom] pre-midcom work item > > > > > > Jonathan, > > > > Following are my observations on the > > draft. I appreciate if you can confirm/clarify my observations: > > > > - How to handle traversal through multiple NATs is not > > clear in this draft. For example, if the VOIP > > call goes through more than one service provider, > > (Section 5, paragraph 4)are the STUN servers > > going to talk to each other? > > No, no, definitely not. > > > How are we handling this case?\ > > In the stun model, each user has a service provider. The > client talks to the > stun server of their service provider. Through that > communications, they > obtain a publically usable IP address for media. That requires no > coordination between providers. They obtain an IP address, but what about a port number? does the client guess what port number that the nat may assign to the transaction? In the case of NAPT(PAT) there is a pool of ports being used randomly in most cases. Now in the case of multiple nats this gets even more complicated, unless we assumethe outermost nat is the ip address seed. > > So, consider the case where I am a user of foo.com > (sip:jdrosen@foo.com). > When I start my phone, my phone uses stun, and talks to the > foo.com stun > server on the public Internet. Using the discovery procedure > in the spec, my > phone discovers that there is at least one nat between me and > the public > Internet, and that its full cone. What is "full cone"? These are my only two questions for now, until I read the rest of the draft. > > Now, when I make a call to sip:alice@bar.edu, I send a stun > query to the > server, and get back my IP address. I then use that in the > SDP in my INVITE. > From here, its regular, plain old vanilla sip. I send an > INVITE to my proxy > at foo.com, and it looks up bar.edu in dns, and forwards the > INVITE there. > That goes to alice. Alice may be behind a nat - but thats her > problem. She > would use the stun protocol as well to learn her public ip > address, and she > would use the bar.edu stun server to do that. Once she gets > one, she sends > back a 200 OK with that address in the SDP, and we're all set. > > The detailed usage of stun for sip will be described in a > to-be-written I-D > for the sipping group. > > > > > - For every call the NAT bindings have to be discovered. > > (Section 9.3). This imposes serious limitation to this approach. > > For example, the latency and scalability issues ? > > The usage of stun will add one RTT of latency between a > client and the stun > server, if one side is behind a nat. If both sides are behind > a nat, its > two. I don't consider this a serious increase in latency, especially > considering the alternative - no media. > > As for scalability, this scales really well. Stun servers are > stateless. You > can have farms of them using SRV lookups. What about it doesn't scale? > > > > > - Determining the timeout discovery (Section 9.2) > > is trial and error method and very time consuming > > process and poses scalability and latency problems. > > Yeah, it would take a while. Its one of these things you > would do in the > background when the phone comes on. I don't see the scalability issue > though. > > > > > - If we run the STUN client in Server, how are we going > > to pass on the NAT binding to media component > > (e.g., Section 9.3, paragraph 4) > > Again, this is something that will be described in far more > detail in the > sipping draft. The idea here is that within an enterprise, > you could have a > "B2BUA with media". THis would be a server on the inside of > the nat, which > receives the INVITE requests from clients within the > enterprise. This server > would be the one to act as a stun client, and it would > rewrite the SDP based > on the addresses it receives. It would, as a consequence, be > on the media > path, so that media from the outside goes to it first, and then to the > clients. The advantage of this approach is that it requires > no changes in > client software, only the addition of this element on the > inside of the > network. The disadvantage is that it introduces an > intermediate point for > media relaying. > > > > > - Security is a big concern. From Section 11. > > it is clear that the both the STUN client and STUN > > server are prone to DOS attacks. It seems to me > > the problem in inherent in the solution. > > Oh? How is that? The stun server is stateless. How can you > launch a DoS > attack against it? You can flood it with packets, sure, but > thats possible > for any protocol. I do point out that the stun server can be used for > certain DDos attacks against other elements, as its a > "reflector". I will, > however, note that there are other protocols that send a > packet when they > receive a packet, which include DNS, SIP, HTTP, and so on. > The remedy for > this attack is to include the source address of the attacker > for tracing > purposes, which is what does happen. So, the protocol seems to > satisfactorily handle that case. > > I also don't see how the stun client is prone to attacks. Can > you please > provide supporting evidence for your claims. > > > > > - In Section 11, last paragraph, it is mentioned that if STUN > > client is within enterprise, the server returns false > > address. It is not clear to me how this works. > > Appreciate more text here. > > No, no. I am not proposing that a server return false > addresses. All I am > saying is that a compromise of the stun server cannot > introduce new holes > into the security perimeter of the enterprise. A stun server > does only one > thing - returns IP addresses. The worst thing it can do is > return the wrong > ones, in which case calls don't get set up. > > > > > - Overall, the solution depends on the discovery by the > > STUN agent which can be located in the user agent. > > No. First off, I don't know what a "stun agent" is, as this > term is never > used in the document. A stun client exists within the user > agent, but its > not discovered. Its part of the software within the client > application. > I.e., my PC phone would have some code in it to implement a > stun client in > order to get IP addresses. > > > >It appears that there a serious security problem with this solution. > > Unsubstantiated claims like this serve no one. Please provide specific > objections. > > > > > - Referring the work in progress documents [1,6] is irritating > > since the reader cannot get to the documents. > > > > I am sorry this irritates you. However, these documents are > all readily > accessible from the IETF site. It is standard practice for an > Internet Draft > to reference other Internet Drafts. "Work in progress" is the standard > terminology required when one references an Internet draft. > To save you some > trouble, I took a few seconds to get the URLs for you: > > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-natreq4u dp-00.txt http://www.ietf.org/internet-drafts/draft-ietf-nat-app-guide-06.txt -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 2 14:41:21 2001 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 OAA24954 for ; Tue, 2 Oct 2001 14:41: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 OAA22346; Tue, 2 Oct 2001 14:36: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 OAA22311 for ; Tue, 2 Oct 2001 14:35:59 -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 OAA24863 for ; Tue, 2 Oct 2001 14:35:50 -0400 (EDT) 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 f92IXF701210 for ; Tue, 2 Oct 2001 11:33:17 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-6.cisco.com [10.82.192.6]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAM06622; Tue, 2 Oct 2001 11:34:50 -0700 (PDT) Message-Id: <5.1.0.14.0.20011002143619.00a7aec0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Oct 2001 14:36:58 -0400 To: midcom From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] R15 accepted 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 Requirement R15 is accepted with the following text: R15: The protocol MUST support the ability of an agent to install a ruleset that governs multiple types of middlebox actions (e.g. firewall and NAT). _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 2 15:08:15 2001 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 PAA26100 for ; Tue, 2 Oct 2001 15:08: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 PAA23332; Tue, 2 Oct 2001 15:04: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 PAA23303 for ; Tue, 2 Oct 2001 15:04:19 -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 PAA25926 for ; Tue, 2 Oct 2001 15:04:14 -0400 (EDT) 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 f92J3oq15891 for ; Tue, 2 Oct 2001 12:03:50 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-6.cisco.com [10.82.192.6]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAM08046; Tue, 2 Oct 2001 12:03:35 -0700 (PDT) Message-Id: <5.1.0.14.0.20011002150505.00a1dec0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Oct 2001 15:05:40 -0400 To: midcom From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Another terminology issue 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 need a term for the thing on the middlebox that's created in response to a request from an agent. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 2 15:14:30 2001 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 PAA26325 for ; Tue, 2 Oct 2001 15:14: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 PAA23271; Tue, 2 Oct 2001 15:03: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 PAA23244 for ; Tue, 2 Oct 2001 15:03:36 -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 PAA25897 for ; Tue, 2 Oct 2001 15:03:31 -0400 (EDT) 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.6/8.9.1) with ESMTP id f92J36G24300 for ; Tue, 2 Oct 2001 12:03:06 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-6.cisco.com [10.82.192.6]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAM08012; Tue, 2 Oct 2001 12:02:51 -0700 (PDT) Message-Id: <5.1.0.14.0.20011002145708.00a3b440@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Oct 2001 15:04:54 -0400 To: midcom From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] New requirement bullets for decision 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 Now under consideration: R46: The Midcom Protocol MUST support the concept of an aggregated Pinhole-Descriptor comprising a multiple of individual flows to be treated as an aggregate. Proposal: keep R47: When accepting a request for a pin-hole, the Middlebox MUST be able to provide the MIDCOM Agent with information that may be used to identify the resource in subsequent operations. Proposal: clean up the language and keep. Need to change "accepting a request for a pin-hole" and "resource." R60: An operation is needed to enable a MIDCOM Agent to request that a Middlebox maintain (refresh) an established Pin-Hole over which the Agent has ownership. Choose between two options: 1) accept this, or 2) instead create a requirement for idempotent operations which can create new thing-on- the-box or extend the lifetime of an existing thing-on-the-box. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 2 15:52:11 2001 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 PAA27203 for ; Tue, 2 Oct 2001 15:52: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 PAA24504; Tue, 2 Oct 2001 15:49:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24472 for ; Tue, 2 Oct 2001 15:49:53 -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 PAA27102 for ; Tue, 2 Oct 2001 15:49:47 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id AA5BA6B903B8; Tue, 02 Oct 2001 15:49:47 -0400 Message-ID: <003001c14b7a$afd8d140$2300000a@acmepacket.com> From: "Bob Penfield" To: "midcom" , "Melinda Shore" References: <5.1.0.14.0.20011002150505.00a1dec0@mira-sjc5-4.cisco.com> Subject: Re: [midcom] Another terminology issue Date: Tue, 2 Oct 2001 15:44:44 -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: "Melinda Shore" To: "midcom" Sent: Tuesday, October 02, 2001 3:05 PM Subject: [midcom] Another terminology issue > We need a term for the thing on the middlebox that's created > in response to a request from an agent. Isn't that what we've been calling a ruleset? > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 2 15:59:29 2001 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 PAA27515 for ; Tue, 2 Oct 2001 15:59: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 PAA24653; Tue, 2 Oct 2001 15:56: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 PAA24619 for ; Tue, 2 Oct 2001 15:56:05 -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 PAA27362 for ; Tue, 2 Oct 2001 15:55:59 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f92Jt7P20149; Tue, 2 Oct 2001 12:55:07 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-6.cisco.com [10.82.192.6]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAM10095; Tue, 2 Oct 2001 12:54:40 -0700 (PDT) Message-Id: <5.1.0.14.0.20011002155325.00a257c0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Oct 2001 15:56:41 -0400 To: "Bob Penfield" , "midcom" From: Melinda Shore Subject: Re: [midcom] Another terminology issue In-Reply-To: <003001c14b7a$afd8d140$2300000a@acmepacket.com> References: <5.1.0.14.0.20011002150505.00a1dec0@mira-sjc5-4.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 At 03:44 PM 10/2/01 -0400, Bob Penfield wrote: >Isn't that what we've been calling a ruleset? We need to clarify that, I think. As things currently stand a ruleset could be the aggregation of stuff describing the request as carried by the midcom protocol to the middlebox, or it could be the instantiation of that aggregation as a pinhole on a firewall or a NAT table entry. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 2 16:14:18 2001 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 QAA28098 for ; Tue, 2 Oct 2001 16:14: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 QAA25361; Tue, 2 Oct 2001 16:10: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 QAA25287 for ; Tue, 2 Oct 2001 16:10:28 -0400 (EDT) Received: from WIN-INET-01.wingroup.windeploy.ntdev.microsoft.com ([131.107.3.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27927 for ; Tue, 2 Oct 2001 16:10:22 -0400 (EDT) Received: from win-hub-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.229]) by WIN-INET-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.3651); Tue, 2 Oct 2001 13:09:39 -0700 Received: from 157.54.5.226 by win-hub-01.wingroup.windeploy.ntdev.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 02 Oct 2001 13:09:39 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by win-hub-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.3651); Tue, 2 Oct 2001 13:09:39 -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(5.0.2195.2966); Tue, 2 Oct 2001 13:08:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] New requirement bullets for decision Date: Tue, 2 Oct 2001 13:08:52 -0700 Message-ID: Thread-Topic: [midcom] New requirement bullets for decision Thread-Index: AcFLd99ooy0rDWzlRey/1Kbp6cHeCgABapJw From: "Christian Huitema" To: "Melinda Shore" , "midcom" X-OriginalArrivalTime: 02 Oct 2001 20:08:52.0823 (UTC) FILETIME=[0EBBB670:01C14B7E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA25293 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 > R46: The Midcom Protocol MUST support the concept of an aggregated > Pinhole-Descriptor comprising a multiple of individual flows > to > be treated as an aggregate. > > Proposal: keep Yes. > R47: When accepting a request for a pin-hole, the Middlebox MUST be > able to provide the MIDCOM Agent with information that may be > used to identify the resource in subsequent operations. > > Proposal: clean up the language and keep. Need to change "accepting > a request for a pin-hole" and "resource." No. Accepting this would imply that the pin-hole is identified by something else than the filter specification, which would be a major source of complexity; in particular, it creates the possibility for having several rulesets with the same filter specification, and the need to define how to handle them, deal with possible contradictions, etc. We may or may not have a consensus that the pinhole should be identified solely by the filter specification, but we certainly don't have a consensus that it should not. I propose to drop this and leave it for the protocol design phase. > R60: An operation is needed to enable a MIDCOM Agent to request that > a Middlebox maintain (refresh) an established Pin-Hole over > which the Agent has ownership. > > Choose between two options: 1) accept this, or 2) instead create a > requirement for idempotent operations which can create new thing-on- > the-box or extend the lifetime of an existing thing-on-the-box. Idempotent is much better. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 2 16:14:26 2001 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 QAA28109 for ; Tue, 2 Oct 2001 16:14: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 QAA25320; Tue, 2 Oct 2001 16:10: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 QAA25289 for ; Tue, 2 Oct 2001 16:10:29 -0400 (EDT) Received: from WIN-INET-01.wingroup.windeploy.ntdev.microsoft.com ([131.107.3.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27929 for ; Tue, 2 Oct 2001 16:10:23 -0400 (EDT) Received: from win-hub-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.229]) by WIN-INET-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.3651); Tue, 2 Oct 2001 13:09:57 -0700 Received: from 157.54.5.226 by win-hub-01.wingroup.windeploy.ntdev.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 02 Oct 2001 13:09:57 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-hub-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.3651); Tue, 2 Oct 2001 13:09:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] Another terminology issue Date: Tue, 2 Oct 2001 13:09:56 -0700 Message-ID: Thread-Topic: [midcom] Another terminology issue Thread-Index: AcFLfZb+4VuHKQdFSsKphirhFLImsgAAI0Lw From: "Christian Huitema" To: "Melinda Shore" , "Bob Penfield" , "midcom" X-OriginalArrivalTime: 02 Oct 2001 20:09:57.0155 (UTC) FILETIME=[3513FF30:01C14B7E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA25290 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 believe that a ruleset contains a filter specification, a set of actions, and a set of attributes. The stuff that is passed in the protocol is a subset of the ruleset; some attributes are generated by the middlebox. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Tuesday, October 02, 2001 12:57 PM > To: Bob Penfield; midcom > Subject: Re: [midcom] Another terminology issue > > At 03:44 PM 10/2/01 -0400, Bob Penfield wrote: > >Isn't that what we've been calling a ruleset? > > We need to clarify that, I think. As things currently stand > a ruleset could be the aggregation of stuff describing the > request as carried by the midcom protocol to the middlebox, > or it could be the instantiation of that aggregation as a > pinhole on a firewall or a NAT table entry. > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 2 16:23:08 2001 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 QAA28241 for ; Tue, 2 Oct 2001 16:23: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 QAA25699; Tue, 2 Oct 2001 16:20: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 QAA25668 for ; Tue, 2 Oct 2001 16:20:44 -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 QAA28162 for ; Tue, 2 Oct 2001 16:20:38 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A193184D03B4; Tue, 02 Oct 2001 16:20:35 -0400 Message-ID: <003601c14b7e$f8cc8500$2300000a@acmepacket.com> From: "Bob Penfield" To: "midcom" , "Melinda Shore" References: <5.1.0.14.0.20011002145708.00a3b440@mira-sjc5-4.cisco.com> Subject: Re: [midcom] New requirement bullets for decision Date: Tue, 2 Oct 2001 16:15:23 -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 "Melinda Shore" wrote: > Now under consideration: > > R46: The Midcom Protocol MUST support the concept of an aggregated > Pinhole-Descriptor comprising a multiple of individual flows to > be treated as an aggregate. > > Proposal: keep OK, but suggest the following wording: "The protocol MUST support the concept of a ruleset group comprising a multiple of individual rulesets to be treated as an aggregate." The idea is to associate together a bunch of rulesets that form some sort of application level session. For example, all the RTP flows for a SIP session. Do we need to explicitly say that this should not preclude the agent from issuing requests that effect individual rulesets or the group as a whole? > > R47: When accepting a request for a pin-hole, the Middlebox MUST be > able to provide the MIDCOM Agent with information that may be > used to identify the resource in subsequent operations. > > Proposal: clean up the language and keep. Need to change "accepting > a request for a pin-hole" and "resource." > OK. Suggest: "The protocol MUST allow the middlebox to provide information to the midcom agent for an installed ruleset (or ruleset group) that may be used to identify the ruleset (or ruleset group) in subsequent operations." The idea is to allow the middlebox to allocate some sort of identifier that could be used in subsequent requests instead of having to use the 5-tuple+. > R60: An operation is needed to enable a MIDCOM Agent to request that > a Middlebox maintain (refresh) an established Pin-Hole over > which the Agent has ownership. > > Choose between two options: 1) accept this, or 2) instead create a > requirement for idempotent operations which can create new thing-on- > the-box or extend the lifetime of an existing thing-on-the-box. Option 2. Suggest: "The protocol MUST allow the midcom agent to extend the lifetime of an existing ruleset that otherwise would be deleted by the middlebox." This could be done by having the midcom agent 1) re-issue the whole request in the same manner that the SIP session timer is adjusted by issusing a re-INVITE, OR 2) issue a request that identifies the ruleset and specifies the specific attribute(s) to be changed (the timer) like the Megaco Modify command does. The requirements should not dicate/proscribe a choice. > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 2 16:27:33 2001 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 QAA28366 for ; Tue, 2 Oct 2001 16:27: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 QAA25815; Tue, 2 Oct 2001 16:24: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 QAA25786 for ; Tue, 2 Oct 2001 16:24:20 -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 QAA28279 for ; Tue, 2 Oct 2001 16:24:15 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A26FAD2403B8; Tue, 02 Oct 2001 16:24:15 -0400 Message-ID: <005c01c14b7f$7bb0d200$2300000a@acmepacket.com> From: "Bob Penfield" To: "Christian Huitema" , "Melinda Shore" , "midcom" References: Subject: Re: [midcom] Another terminology issue Date: Tue, 2 Oct 2001 16:19:05 -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: "Christian Huitema" To: "Melinda Shore" ; "Bob Penfield" ; "midcom" Sent: Tuesday, October 02, 2001 4:09 PM Subject: RE: [midcom] Another terminology issue > I believe that a ruleset contains a filter specification, a set of > actions, and a set of attributes. The stuff that is passed in the > protocol is a subset of the ruleset; some attributes are generated by > the middlebox. That was my understanding too. > > > -----Original Message----- > > From: Melinda Shore [mailto:mshore@cisco.com] > > Sent: Tuesday, October 02, 2001 12:57 PM > > To: Bob Penfield; midcom > > Subject: Re: [midcom] Another terminology issue > > > > At 03:44 PM 10/2/01 -0400, Bob Penfield wrote: > > >Isn't that what we've been calling a ruleset? > > > > We need to clarify that, I think. As things currently stand > > a ruleset could be the aggregation of stuff describing the > > request as carried by the midcom protocol to the middlebox, > > or it could be the instantiation of that aggregation as a > > pinhole on a firewall or a NAT table entry. > > > > Melinda > > > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > http://www1.ietf.org/mailman/listinfo/midcom > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 2 16:32:29 2001 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 QAA28540 for ; Tue, 2 Oct 2001 16:32: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 QAA25960; Tue, 2 Oct 2001 16:29: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 QAA25932 for ; Tue, 2 Oct 2001 16:29:07 -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 QAA28408 for ; Tue, 2 Oct 2001 16:29:01 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f92KQT707680 for ; Tue, 2 Oct 2001 13:26:31 -0700 (PDT) Received: from SBRIM-W2K (dhcp-128-107-165-37.cisco.com [128.107.165.37]) by airborne.cisco.com (Mirapoint) with SMTP id AAD12538; Tue, 2 Oct 2001 13:28:31 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Tue, 2 Oct 2001 16:28:32 -0400 Date: Tue, 2 Oct 2001 16:28:32 -0400 From: Scott Brim To: midcom Subject: Re: [midcom] Another terminology issue Message-ID: <20011002162832.Z1144@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom References: <5.1.0.14.0.20011002150505.00a1dec0@mira-sjc5-4.cisco.com> 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.20011002150505.00a1dec0@mira-sjc5-4.cisco.com>; from mshore@cisco.com on Tue, Oct 02, 2001 at 03:05:40PM -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, Oct 02, 2001 03:05:40PM -0400, Melinda Shore allegedly wrote: > We need a term for the thing on the middlebox that's created > in response to a request from an agent. I don't know that this will be possible to name. We don't want to require anything of implementations. There might not be a "thing". A single rule could be instantiated in novel ways, and a group of rules certainly will be. Since we're doing protocols, perhaps we won't need to refer to that "thing" often. If/when we do, we could (1) just talk about the application of the rules, since that's all we're interested in (now how that is done); (2) simply say "the instantiation of the ruleset in the middlebox" or some such phrase (if you only have to say it a few times you can be long-winded); (3) or anything else along those lines -- to avoid making assumptions about implementation. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 2 16:37:28 2001 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 QAA28595 for ; Tue, 2 Oct 2001 16:37: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 QAA26442; Tue, 2 Oct 2001 16:35: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 QAA26416 for ; Tue, 2 Oct 2001 16:35:57 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28586 for ; Tue, 2 Oct 2001 16:35:51 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id PAA28080 for ; Tue, 2 Oct 2001 15:35:25 -0500 (CDT) Received: from zsc4c000.us.nortel.com by smtprch2.nortel.com; Tue, 2 Oct 2001 15:28:32 -0500 Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Oct 2001 13:34:48 -0700 Message-ID: From: "Reinaldo Penno" To: "'Christian Huitema'" , "'Melinda Shore'" , "'midcom'" Subject: RE: [midcom] New requirement bullets for decision Date: Tue, 2 Oct 2001 13:34:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14B81.A98ED8A0" X-Orig: 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_01C14B81.A98ED8A0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Tuesday, October 02, 2001 1:09 PM > To: Melinda Shore; midcom > Subject: RE: [midcom] New requirement bullets for decision > > No. Accepting this would imply that the pin-hole is identified by > something else than the filter specification, which would be a major > source of complexity; in particular, it creates the possibility for > having several rulesets with the same filter specification, > and the need > to define how to handle them, deal with possible > contradictions, etc. > may or may not have a consensus that the pinhole should be identified > solely by the filter specification, but we certainly don't have a > consensus that it should not. I propose to drop this and leave it for > the protocol design phase. > > Christian, The protocol design phase *is* based on the requirements, so if it's not there, it might not be addressed. We already discussed this lenghtly. There are severeal boxes out there that might have exactly the same filter specification applied for different entities (or call it users/CPE, etc). We need something to distinguish between these two filter specifications. regards, Reinaldo ------_=_NextPart_001_01C14B81.A98ED8A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] New requirement bullets for decision

> -----Original Message-----
> From: Christian Huitema [mailto:huitema@windows.mic= rosoft.com]
> Sent: Tuesday, October 02, 2001 1:09 PM
> To: Melinda Shore; midcom
> Subject: RE: [midcom] New requirement bullets = for decision
>
> No. Accepting this would imply that the = pin-hole is identified by
> something else than the filter specification, = which would be a major
> source of complexity; in particular, it creates = the possibility for
> having several rulesets with the same filter = specification,
> and the need
> to define how to handle them, deal with = possible
> contradictions, etc.
> may or may not have a consensus that the = pinhole should be identified
> solely by the filter specification, but we = certainly don't have a
> consensus that it should not. I propose to drop = this and leave it for
> the protocol design phase.
>
>

Christian,

The protocol design phase *is* based on the = requirements, so if it's not there, it might not be addressed.

We already discussed this lenghtly. There are = severeal boxes out there that might have exactly the same filter = specification applied for different entities (or call it users/CPE, = etc). We need something to distinguish between these two filter = specifications.

regards,

Reinaldo

------_=_NextPart_001_01C14B81.A98ED8A0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 2 17:17:59 2001 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 RAA29942 for ; Tue, 2 Oct 2001 17:17: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 RAA27658; Tue, 2 Oct 2001 17:12: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 RAA27624 for ; Tue, 2 Oct 2001 17:12:07 -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 RAA29796 for ; Tue, 2 Oct 2001 17:12:03 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.11.6/8.9.1) with ESMTP id f92LBcG03944 for ; Tue, 2 Oct 2001 14:11:38 -0700 (PDT) Received: from SBRIM-W2K (dhcp-128-107-165-37.cisco.com [128.107.165.37]) by airborne.cisco.com (Mirapoint) with SMTP id AAD13463; Tue, 2 Oct 2001 14:11:35 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Tue, 2 Oct 2001 17:11:37 -0400 Date: Tue, 2 Oct 2001 17:11:37 -0400 From: Scott Brim To: "'midcom'" Subject: Re: [midcom] New requirement bullets for decision Message-ID: <20011002171136.D1144@SBRIM-W2K> Mail-Followup-To: Scott Brim , 'midcom' 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 reinaldo_penno@nortelnetworks.com on Tue, Oct 02, 2001 at 01:34:41PM -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 Tue, Oct 02, 2001 01:34:41PM -0700, Reinaldo Penno allegedly wrote: > > > > -----Original Message----- > > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > > Sent: Tuesday, October 02, 2001 1:09 PM > > To: Melinda Shore; midcom > > Subject: RE: [midcom] New requirement bullets for decision > > > > No. Accepting this would imply that the pin-hole is identified by > > something else than the filter specification, which would be a major > > source of complexity; in particular, it creates the possibility for > > having several rulesets with the same filter specification, > > and the need > > to define how to handle them, deal with possible > > contradictions, etc. > > may or may not have a consensus that the pinhole should be identified > > solely by the filter specification, but we certainly don't have a > > consensus that it should not. I propose to drop this and leave it for > > the protocol design phase. > > > > > > Christian, > > The protocol design phase *is* based on the requirements, so if it's not > there, it might not be addressed. > > We already discussed this lenghtly. There are severeal boxes out there that > might have exactly the same filter specification applied for different > entities (or call it users/CPE, etc). We need something to distinguish > between these two filter specifications. Why? _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 2 17:26:26 2001 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 RAA00181 for ; Tue, 2 Oct 2001 17:26: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 RAA27474; Tue, 2 Oct 2001 17:10: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 RAA27392 for ; Tue, 2 Oct 2001 17:10: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 RAA29724 for ; Tue, 2 Oct 2001 17:10:38 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.11.6/8.9.1) with ESMTP id f92LADG02868 for ; Tue, 2 Oct 2001 14:10:13 -0700 (PDT) Received: from SBRIM-W2K (dhcp-128-107-165-37.cisco.com [128.107.165.37]) by airborne.cisco.com (Mirapoint) with SMTP id AAD13433; Tue, 2 Oct 2001 14:10:10 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Tue, 2 Oct 2001 17:10:12 -0400 Date: Tue, 2 Oct 2001 17:10:12 -0400 From: Scott Brim To: midcom Subject: Re: [midcom] New requirement bullets for decision Message-ID: <20011002171011.C1144@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom References: <5.1.0.14.0.20011002145708.00a3b440@mira-sjc5-4.cisco.com> <003601c14b7e$f8cc8500$2300000a@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <003601c14b7e$f8cc8500$2300000a@acmepacket.com>; from bpenfield@acmepacket.com on Tue, Oct 02, 2001 at 04:15:23PM -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, Oct 02, 2001 04:15:23PM -0400, Bob Penfield allegedly wrote: > > "Melinda Shore" wrote: > > Now under consideration: > > > > R46: The Midcom Protocol MUST support the concept of an aggregated > > Pinhole-Descriptor comprising a multiple of individual flows to > > be treated as an aggregate. > > > > Proposal: keep > OK, but suggest the following wording: > > "The protocol MUST support the concept of a ruleset group comprising a > multiple of individual rulesets to be treated as an aggregate." > > The idea is to associate together a bunch of rulesets that form some sort of > application level session. For example, all the RTP flows for a SIP session. This is a lot better than the original. > Do we need to explicitly say that this should not preclude the agent from > issuing requests that effect individual rulesets or the group as a whole? I'd leave it without the extra comment. > > R47: When accepting a request for a pin-hole, the Middlebox MUST be > > able to provide the MIDCOM Agent with information that may be > > used to identify the resource in subsequent operations. > > > > Proposal: clean up the language and keep. Need to change "accepting > > a request for a pin-hole" and "resource." > > > OK. Suggest: > > "The protocol MUST allow the middlebox to provide information to the midcom > agent for an installed ruleset (or ruleset group) that may be used to > identify the ruleset (or ruleset group) in subsequent operations." What's the goal? The easiest way to identify a ruleset or a ruleset group is to state it again. What exactly are you trying to do that brings out this requirement? > > R60: An operation is needed to enable a MIDCOM Agent to request that > > a Middlebox maintain (refresh) an established Pin-Hole over > > which the Agent has ownership. > > > > Choose between two options: 1) accept this, or 2) instead create a > > requirement for idempotent operations which can create new thing-on- > > the-box or extend the lifetime of an existing thing-on-the-box. > > Option 2. Suggest: > > "The protocol MUST allow the midcom agent to extend the lifetime of an > existing ruleset that otherwise would be deleted by the middlebox." > > This could be done by having the midcom agent 1) re-issue the whole request > in the same manner that the SIP session timer is adjusted by issusing a > re-INVITE, OR 2) issue a request that identifies the ruleset and specifies > the specific attribute(s) to be changed (the timer) like the Megaco Modify > command does. The requirements should not dicate/proscribe a choice. OK. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 2 18:25:40 2001 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 SAA01693 for ; Tue, 2 Oct 2001 18:25: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 SAA29380; Tue, 2 Oct 2001 18:23: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 SAA29347 for ; Tue, 2 Oct 2001 18:23:37 -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 SAA01643 for ; Tue, 2 Oct 2001 18:23:32 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id AE66DC803FA; Tue, 02 Oct 2001 18:23:34 -0400 Message-ID: <000f01c14b90$1322b4e0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Scott Brim" , "midcom" References: <5.1.0.14.0.20011002145708.00a3b440@mira-sjc5-4.cisco.com> <003601c14b7e$f8cc8500$2300000a@acmepacket.com> <20011002171011.C1144@SBRIM-W2K> Subject: Re: [midcom] New requirement bullets for decision Date: Tue, 2 Oct 2001 18:17:50 -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 "Scott Brim" wrote: > > > R47: When accepting a request for a pin-hole, the Middlebox MUST be > > > able to provide the MIDCOM Agent with information that may be > > > used to identify the resource in subsequent operations. > > > > > > Proposal: clean up the language and keep. Need to change "accepting > > > a request for a pin-hole" and "resource." > > > > > OK. Suggest: > > > > "The protocol MUST allow the middlebox to provide information to the midcom > > agent for an installed ruleset (or ruleset group) that may be used to > > identify the ruleset (or ruleset group) in subsequent operations." > > What's the goal? The easiest way to identify a ruleset or a ruleset > group is to state it again. What exactly are you trying to do that > brings out this requirement? > The idea is that the middlebox could assign an ID that could be used in subsequent requests to refer to the ruleset (or group). It decreases the verbosity of the protocol. Otherwise you would have to specify the whole 5-tuple every time. Also, if parts of the 5-tuple change as a result of the request, do you use the original one or the modified one? For example, if I'm requesting a NAT for an RTP flow for SIP/H.323 the ruleset request will look something like this: filter: source=*:*,dest=:,transport=UDP action: forward-to-dest=10.0.0.7:47210 If the middlebox collapses from a cone-NAT to a symmetric-NAT based on the first packet, the "source" in the 5-tuple changes, and the midcom agent does not necessarily find out what it is. Which is a better "key" for the ruleset? One that is allocated when the ruleset is created and remains constant or one the changes over the life of the ruleset? (-:bob _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 2 18:55:55 2001 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 SAA02227 for ; Tue, 2 Oct 2001 18:55: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 SAA29950; Tue, 2 Oct 2001 18:48:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29923 for ; Tue, 2 Oct 2001 18:48:52 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02015 for ; Tue, 2 Oct 2001 18:48:46 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id RAA09025 for ; Tue, 2 Oct 2001 17:48:13 -0500 (CDT) Received: from zsc4c000.us.nortel.com by smtprch2.nortel.com; Tue, 2 Oct 2001 17:41:25 -0500 Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Oct 2001 15:47:41 -0700 Message-ID: From: "Reinaldo Penno" To: "'Scott Brim'" , "'midcom'" Subject: RE: [midcom] New requirement bullets for decision Date: Tue, 2 Oct 2001 15:47:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14B94.3C4DCFE0" X-Orig: 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_01C14B94.3C4DCFE0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Scott Brim [mailto:swb@employees.org] > Sent: Tuesday, October 02, 2001 2:12 PM > To: 'midcom' > Subject: Re: [midcom] New requirement bullets for decision > > > On Tue, Oct 02, 2001 01:34:41PM -0700, Reinaldo Penno allegedly wrote: > > > > > > > Christian, > > > > The protocol design phase *is* based on the requirements, > so if it's not > > there, it might not be addressed. > > > > We already discussed this lenghtly. There are severeal > boxes out there that > might have exactly the same filter specification applied > for different > > entities (or call it users/CPE, etc). We need something to > distinguish > > between these two filter specifications. > > Why? > What you mean Scott? Besides Bob's reply, the need is straightforward. Let's suppose Scott and Reinaldo are part of different VPNs with overlapping IP addresses served by the same MB. If I install two firewall rules: one for Scott saying "10.0.0.1 yahoo.com drop" and another one for Reinaldo saying "10.0.0.1 yahoo.com drop" and later want to modify or delete one of them, how can I identify them? Not to mention that the protocol might get confused saying that a rule already exists or think its a refresh. regards, Reinaldo ------_=_NextPart_001_01C14B94.3C4DCFE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] New requirement bullets for decision

> -----Original Message-----
> From: Scott Brim [mailto:swb@employees.org]
> Sent: Tuesday, October 02, 2001 2:12 PM
> To: 'midcom'
> Subject: Re: [midcom] New requirement bullets = for decision
>
>
> On Tue, Oct 02, 2001 01:34:41PM -0700, Reinaldo = Penno allegedly wrote:
> >
> >
>
> > Christian,
> >
> > The protocol design phase *is* based on = the requirements,
> so if it's not
> > there, it might not be addressed.
> >
> > We already discussed this lenghtly. There = are severeal
> boxes out there that
> might have exactly the same filter = specification applied
> for different
> > entities (or call it users/CPE, etc). We = need something to
> distinguish
> > between these two filter specifications. =
>
> Why?
>

What you mean Scott? Besides Bob's reply, the need is = straightforward. Let's suppose Scott and Reinaldo are part of different = VPNs with overlapping IP addresses served by the same MB.

If I install two firewall rules:

one for Scott saying "10.0.0.1 yahoo.com = drop" and another one for Reinaldo saying
"10.0.0.1 yahoo.com drop"

and later want to modify or delete one of them, how = can I identify them? Not to mention that the protocol might get = confused saying that a rule already exists or think its a = refresh.

regards,

Reinaldo

------_=_NextPart_001_01C14B94.3C4DCFE0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 2 19:52:18 2001 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 TAA03551 for ; Tue, 2 Oct 2001 19:52: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 TAA01562; Tue, 2 Oct 2001 19:47: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 TAA01533 for ; Tue, 2 Oct 2001 19:47:19 -0400 (EDT) Received: from WIN-INET-01.wingroup.windeploy.ntdev.microsoft.com ([131.107.3.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03447 for ; Tue, 2 Oct 2001 19:47:15 -0400 (EDT) Received: from win-hub-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.229]) by WIN-INET-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.3651); Tue, 2 Oct 2001 16:46:33 -0700 Received: from 157.54.5.226 by win-hub-01.wingroup.windeploy.ntdev.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 02 Oct 2001 16:46:33 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-hub-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.3651); Tue, 2 Oct 2001 16:46:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] New requirement bullets for decision Date: Tue, 2 Oct 2001 16:46:32 -0700 Message-ID: Thread-Topic: [midcom] New requirement bullets for decision Thread-Index: AcFLkrWjkngpZcL9TxSaqXCa17dmwgACTZng From: "Christian Huitema" To: "Bob Penfield" , "Scott Brim" , "midcom" X-OriginalArrivalTime: 02 Oct 2001 23:46:33.0136 (UTC) FILETIME=[77495300:01C14B9C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA01534 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 > Which is a better "key" for the ruleset? One that is > allocated when the > ruleset is created and remains constant or one the changes > over the life of > the ruleset? We debated that in London, and in fact I am supposed to head a panel and write a draft on the issue. (Volunteers are welcome.) There are two options. If you want to keep "id=filter-spec", then the H.323 scenario is solved by creating two rulesets: create first a wildcard ruleset, then delete the wild card ruleset and create a specific ruleset. There are all kinds of pros and cons in this debate, but as an architecture rule, it is preferable to avoid creating extra identifiers whenever possible. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 2 20:18:19 2001 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 UAA04315 for ; Tue, 2 Oct 2001 20: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 UAA02076; Tue, 2 Oct 2001 20:01: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 UAA02049 for ; Tue, 2 Oct 2001 20:01:30 -0400 (EDT) Received: from WIN-INET-01.wingroup.windeploy.ntdev.microsoft.com ([131.107.3.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03893 for ; Tue, 2 Oct 2001 20:01:26 -0400 (EDT) Received: from win-hub-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.229]) by WIN-INET-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.3651); Tue, 2 Oct 2001 16:57:39 -0700 Received: from 157.54.5.226 by win-hub-01.wingroup.windeploy.ntdev.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 02 Oct 2001 16:57:38 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-hub-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.3651); Tue, 2 Oct 2001 16:57:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] New requirement bullets for decision Date: Tue, 2 Oct 2001 16:57:38 -0700 Message-ID: Thread-Topic: [midcom] New requirement bullets for decision Thread-Index: AcFLlqwTuCb7JWcTRPaKRR9dlEAPtgABePpA From: "Christian Huitema" To: "Reinaldo Penno" , "Scott Brim" , "midcom" X-OriginalArrivalTime: 02 Oct 2001 23:57:38.0886 (UTC) FILETIME=[041AB660:01C14B9E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA02050 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 Suppose that instead of installing the two rules that you mention, I install one for Scott saying "10.0.0.1 yahoo.com drop" and another one for Reinaldo saying "10.0.0.1 yahoo.com pass". What is the firewall supposed to do? And how do you reconcile that with requirement R23? (By the way, we should definitley not use DNS names in example, since DNS names resolve to an indeterminate number of addresses.) On the contrary, if you insist that the rule is identified by "10.0.0.1 128.9.10.11 TCP * *" then you get the following sequence, which is strictly deterministic: 1) Scott creates "10.0.0.1 128.9.10.11 TCP * *, action=Pass". The midcom server on the firewall checks Scotts credentials, and installs a ruleset: "10.0.0.1 128.9.10.11 TCP * *, action=Pass, owner=Scott" 2) Reinaldo attempts to create "10.0.0.1 128.9.10.11 TCP * *, action=Drop". Them midcom server notices that there is already a ruleset for that filter. It returns an error. 3) Reinaldo insits. It sends a modify on the existing rule, requesting "action=Drop". Depending on access control lists, whether or not reinaldo is a privileged user, etc., the firewall accepts or refuses the modification. 4) Scott suspects that something fishy is happening. He issues a read request for the rule "10.0.0.1 128.9.10.11 TCP * *", and get the information "action=drop, owner=Scott, modifiedBy=Reinaldo". 5) The two of you sort that out by out of band mechanisms. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 2 20:28:29 2001 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 UAA04473 for ; Tue, 2 Oct 2001 20: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 UAA02643; Tue, 2 Oct 2001 20:27: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 UAA02612 for ; Tue, 2 Oct 2001 20:27:22 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04439 for ; Tue, 2 Oct 2001 20:27:18 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id TAA01643 for ; Tue, 2 Oct 2001 19:26:51 -0500 (CDT) Received: from zsc4c000.us.nortel.com by smtprch2.nortel.com; Tue, 2 Oct 2001 19:20:09 -0500 Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Oct 2001 17:26:24 -0700 Message-ID: From: "Reinaldo Penno" To: "'Christian Huitema'" , "'Scott Brim'" , "'midcom'" Subject: RE: [midcom] New requirement bullets for decision Date: Tue, 2 Oct 2001 17:26:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14BA2.078D9930" X-Orig: 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_01C14BA2.078D9930 Content-Type: text/plain; charset="iso-8859-1" Hello Christian, In the example I had in mind Reinaldo and Scott are not MAs, but home users or some company. They have no control over the MB which is owned by a carrier or ISP. The carrier's MA has the responsability to create the two rules and ask the MB to apply them to different users which have overlapping IP address. BTW, count me in as a volunteer. regards, Reinaldo. > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Tuesday, October 02, 2001 4:58 PM > To: Penno, Reinaldo [SC9:T327:EXCH]; Scott Brim; midcom > Subject: RE: [midcom] New requirement bullets for decision > > > Suppose that instead of installing the two rules that you mention, I > install one for Scott saying "10.0.0.1 yahoo.com drop" and another one > for Reinaldo saying "10.0.0.1 yahoo.com pass". What is the firewall > supposed to do? And how do you reconcile that with > requirement R23? (By > the way, we should definitley not use DNS names in example, since DNS > names resolve to an indeterminate number of addresses.) > > On the contrary, if you insist that the rule is identified by > "10.0.0.1 128.9.10.11 TCP * *" > then you get the following sequence, which is strictly deterministic: > > 1) Scott creates "10.0.0.1 128.9.10.11 TCP * *, action=Pass". > The midcom > server on the firewall checks Scotts credentials, and installs a > ruleset: > "10.0.0.1 128.9.10.11 TCP * *, action=Pass, owner=Scott" > 2) Reinaldo attempts to create "10.0.0.1 128.9.10.11 TCP * *, > action=Drop". Them midcom server notices that there is > already a ruleset > for that filter. It returns an error. > 3) Reinaldo insits. It sends a modify on the existing rule, requesting > "action=Drop". Depending on access control lists, whether or not > reinaldo is a privileged user, etc., the firewall accepts or > refuses the > modification. > 4) Scott suspects that something fishy is happening. He issues a read > request for the rule "10.0.0.1 128.9.10.11 TCP * *", and get the > information "action=drop, owner=Scott, modifiedBy=Reinaldo". > 5) The two of you sort that out by out of band mechanisms. > > -- Christian Huitema > ------_=_NextPart_001_01C14BA2.078D9930 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] New requirement bullets for decision

Hello Christian,

In the example I had in mind Reinaldo and Scott are = not MAs, but home users or some company. They have no control over the = MB which is owned by a carrier or ISP. The carrier's MA has the = responsability to create the two rules and ask the MB to apply them to = different users which have overlapping IP address. 

BTW, count me in as a volunteer.

regards,

Reinaldo.

> -----Original Message-----
> From: Christian Huitema [mailto:huitema@windows.mic= rosoft.com]
> Sent: Tuesday, October 02, 2001 4:58 PM
> To: Penno, Reinaldo [SC9:T327:EXCH]; Scott = Brim; midcom
> Subject: RE: [midcom] New requirement bullets = for decision
>
>
> Suppose that instead of installing the two = rules that you mention, I
> install one for Scott saying "10.0.0.1 = yahoo.com drop" and another one
> for Reinaldo saying "10.0.0.1 yahoo.com = pass". What is the firewall
> supposed to do? And how do you reconcile that = with
> requirement R23? (By
> the way, we should definitley not use DNS names = in example, since DNS
> names resolve to an indeterminate number of = addresses.)
>
> On the contrary, if you insist that the rule is = identified by
>       "10.0.0.1 = 128.9.10.11 TCP * *"
> then you get the following sequence, which is = strictly deterministic:
>
> 1) Scott creates "10.0.0.1 128.9.10.11 TCP = * *, action=3DPass".
> The midcom
> server on the firewall checks Scotts = credentials, and installs a
> ruleset:
>       "10.0.0.1 = 128.9.10.11 TCP * *, action=3DPass, owner=3DScott"
> 2) Reinaldo attempts to create "10.0.0.1 = 128.9.10.11 TCP * *,
> action=3DDrop". Them midcom server notices = that there is
> already a ruleset
> for that filter. It returns an error.
> 3) Reinaldo insits. It sends a modify on the = existing rule, requesting
> "action=3DDrop". Depending on access = control lists, whether or not
> reinaldo is a privileged user, etc., the = firewall accepts or
> refuses the
> modification.
> 4) Scott suspects that something fishy is = happening. He issues a read
> request for the rule "10.0.0.1 128.9.10.11 = TCP * *", and get the
> information "action=3Ddrop, owner=3DScott, = modifiedBy=3DReinaldo".
> 5) The two of you sort that out by out of band = mechanisms.
>
> -- Christian Huitema
>

------_=_NextPart_001_01C14BA2.078D9930-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 2 23:35:18 2001 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 XAA12113 for ; Tue, 2 Oct 2001 23:35: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 XAA07509; Tue, 2 Oct 2001 23:31: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 XAA07480 for ; Tue, 2 Oct 2001 23:31:15 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11829 for ; Tue, 2 Oct 2001 23:31:09 -0400 (EDT) Received: from MDUFFY ([10.1.1.15]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TB12TJ4N; Tue, 2 Oct 2001 23:30:42 -0400 Message-Id: <3.0.5.32.20011002232935.008722c0@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 02 Oct 2001 23:29:35 -0400 To: "Bob Penfield" , "Christian Huitema" , "Melinda Shore" , "midcom" From: Mark Duffy Subject: Re: [midcom] Another terminology issue In-Reply-To: <005c01c14b7f$7bb0d200$2300000a@acmepacket.com> 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 It seems to me that there are at least 3 parallel concepts here: 1. The MB behavior that is desired by an agent 2. The encoding of that in a message in the midcom protocol 3. The state installed in the MB to realize the desired behavior. I suppose it could be argued that 1 and 3 are the same. In any event, I think we could get away with using "Ruleset" for all of these and adding some qualifying words with it in those situations where a distinction is needed. (Such as Scott's "the instantiation of the ruleset in the middlebox"). Looking at the existing definition of "Ruleset" it seems general enough to fit any of the uses above. Mark At 04:19 PM 10/2/01 -0400, Bob Penfield wrote: > >----- Original Message ----- >From: "Christian Huitema" >To: "Melinda Shore" ; "Bob Penfield" >; "midcom" >Sent: Tuesday, October 02, 2001 4:09 PM >Subject: RE: [midcom] Another terminology issue > > >> I believe that a ruleset contains a filter specification, a set of >> actions, and a set of attributes. The stuff that is passed in the >> protocol is a subset of the ruleset; some attributes are generated by >> the middlebox. > >That was my understanding too. > > >> >> > -----Original Message----- >> > From: Melinda Shore [mailto:mshore@cisco.com] >> > Sent: Tuesday, October 02, 2001 12:57 PM >> > To: Bob Penfield; midcom >> > Subject: Re: [midcom] Another terminology issue >> > >> > At 03:44 PM 10/2/01 -0400, Bob Penfield wrote: >> > >Isn't that what we've been calling a ruleset? >> > >> > We need to clarify that, I think. As things currently stand >> > a ruleset could be the aggregation of stuff describing the >> > request as carried by the midcom protocol to the middlebox, >> > or it could be the instantiation of that aggregation as a >> > pinhole on a firewall or a NAT table entry. >> > >> > Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 2 23:46:25 2001 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 XAA12296 for ; Tue, 2 Oct 2001 23:46: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 XAA07706; Tue, 2 Oct 2001 23: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 XAA07679 for ; Tue, 2 Oct 2001 23:45:14 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12283 for ; Tue, 2 Oct 2001 23:45:08 -0400 (EDT) Received: from MDUFFY ([10.1.1.15]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TB12TJ4W; Tue, 2 Oct 2001 23:44:42 -0400 Message-Id: <3.0.5.32.20011002234343.00870dd0@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 02 Oct 2001 23:43:43 -0400 To: "Reinaldo Penno" , "'Scott Brim'" , "'midcom'" From: Mark Duffy Subject: RE: [midcom] New requirement bullets for decision In-Reply-To: Mime-Version: 1.0 Content-Type: text/enriched; 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:47 PM 10/2/01 -0700, Reinaldo Penno wrote: >>>> > -----Original Message----- > From: Scott Brim [<mailto:swb@employees.org] > Sent: Tuesday, October 02, 2001 2:12 PM > To: 'midcom' > Subject: Re: [midcom] New requirement bullets for decision > > > On Tue, Oct 02, 2001 01:34:41PM -0700, Reinaldo Penno allegedly wrote: > > > > > > > Christian, > > > > The protocol design phase *is* based on the requirements, > so if it's not > > there, it might not be addressed. > > > > We already discussed this lenghtly. There are severeal > boxes out there that > might have exactly the same filter specification applied > for different > > entities (or call it users/CPE, etc). We need something to > distinguish > > between these two filter specifications. > > Why? > What you mean Scott? Besides Bob's reply, the need is straightforward. Let's suppose Scott and Reinaldo are part of different VPNs with overlapping IP addresses served by the same MB. If I install two firewall rules: one for Scott saying "10.0.0.1 yahoo.com drop" and another one for Reinaldo saying "10.0.0.1 yahoo.com drop" and later want to modify or delete one of them, how can I identify them? Not to mention that the protocol might get confused saying that a rule already exists or think its a refresh. regards, Reinaldo <<<<<<<< Since the two rules when initially installed were intended to be applied by the MB to different interfaces/realms/whatevers, presumably there was a way when they were installed to specify that. Perhaps a realm identifier, perhaps by addressing a different logical middlebox, perhaps some other way. In any event, it seems to me that the same way of distinguishing them will still be available when agents want to go change them, delete them, or refresh their timeouts. So whether or not another key for the ruleset is desirable for other reasons, I don't see the multi-context MB driving such a requirement. -Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 2 23:58:03 2001 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 XAA12469 for ; Tue, 2 Oct 2001 23:57: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 XAA07862; Tue, 2 Oct 2001 23:56: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 XAA07833 for ; Tue, 2 Oct 2001 23:56:06 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12411 for ; Tue, 2 Oct 2001 23:56:00 -0400 (EDT) Received: from MDUFFY ([10.1.1.15]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TB12TJ48; Tue, 2 Oct 2001 23:55:34 -0400 Message-Id: <3.0.5.32.20011002235403.00897740@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 02 Oct 2001 23:54:03 -0400 To: "Bob Penfield" , "midcom" , "Melinda Shore" From: Mark Duffy Subject: Re: [midcom] New requirement bullets for decision In-Reply-To: <003601c14b7e$f8cc8500$2300000a@acmepacket.com> References: <5.1.0.14.0.20011002145708.00a3b440@mira-sjc5-4.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 At 04:15 PM 10/2/01 -0400, Bob Penfield wrote: > >"Melinda Shore" wrote: >> Now under consideration: >> >> R46: The Midcom Protocol MUST support the concept of an aggregated >> Pinhole-Descriptor comprising a multiple of individual flows to >> be treated as an aggregate. >> >> Proposal: keep > >OK, but suggest the following wording: > >"The protocol MUST support the concept of a ruleset group comprising a >multiple of individual rulesets to be treated as an aggregate." > >The idea is to associate together a bunch of rulesets that form some sort of >application level session. For example, all the RTP flows for a SIP session. If in fact this is a requirement, I like Bob's statement of it above. I would however make the observation that if there is such a requirement, then there must be a way to name the ruleset group in the midcom protocol. _Perhaps_ that can be based on naming a ruleset in the group and indicating a reference as being to the entire group containing thet ruleset rather than to the individual rule. However, I would not be surprised if the protocol ended up with some other identifier assigned to the group itself. Which sounds to me to be pretty closely related to what R47 is about. If we have the MB assigning handles for ruleset groups, it may as well assign them for individual rulesets as well. >> R47: When accepting a request for a pin-hole, the Middlebox MUST be >> able to provide the MIDCOM Agent with information that may be >> used to identify the resource in subsequent operations. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Oct 3 07:30:53 2001 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 HAA07891 for ; Wed, 3 Oct 2001 07:30: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 HAA26703; Wed, 3 Oct 2001 07:13: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 HAA26673 for ; Wed, 3 Oct 2001 07:13:06 -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 HAA07265; Wed, 3 Oct 2001 07:13:03 -0400 (EDT) Message-Id: <200110031113.HAA07265@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org, midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 03 Oct 2001 07:13:02 -0400 Subject: [midcom] I-D ACTION:draft-rosenberg-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. Title : STUN - Simple Traversal of UDP Through NATs Author(s) : J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy Filename : draft-rosenberg-midcom-stun-00.txt Pages : 20 Date : 02-Oct-01 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 nearly all 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 very simple, being almost identical to echo. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-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-rosenberg-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-rosenberg-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: <20011002120839.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-midcom-stun-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosenberg-midcom-stun-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011002120839.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Oct 3 08:41:19 2001 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 IAA11005 for ; Wed, 3 Oct 2001 08:41: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 IAA29259; Wed, 3 Oct 2001 08:36: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 IAA29175 for ; Wed, 3 Oct 2001 08:36:28 -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 IAA10801 for ; Wed, 3 Oct 2001 08:36:24 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A64B84EB0362; Wed, 03 Oct 2001 08:36:27 -0400 Message-ID: <004201c14c07$21ec4960$2300000a@acmepacket.com> From: "Bob Penfield" To: "midcom" References: Subject: Re: [midcom] New requirement bullets for decision Date: Wed, 3 Oct 2001 08:30:04 -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: "Christian Huitema" >To: "Bob Penfield" ; "Scott Brim" ; "midcom" >Sent: Tuesday, October 02, 2001 7:46 PM >Subject: RE: [midcom] New requirement bullets for decision > >> Which is a better "key" for the ruleset? One that is >> allocated when the >> ruleset is created and remains constant or one the changes >> over the life of >> the ruleset? > >We debated that in London, and in fact I am supposed to head a panel and >write a draft on the issue. (Volunteers are welcome.) There are two >options. If you want to keep "id=filter-spec", then the H.323 scenario >is solved by creating two rulesets: create first a wildcard ruleset, >then delete the wild card ruleset and create a specific ruleset. This is only possible if the midcom agent becomes aware that the NAT has collapsed. Since this would be a middlebox function (to look for the first packet and change the source address in the filter), it makes no sense for the midcom agent to make a new rule. The middlebox has already changed the existing rule. > >There are all kinds of pros and cons in this debate, but as an >architecture rule, it is preferable to avoid creating extra identifiers >whenever possible. > >-- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Oct 3 09:06:42 2001 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 JAA12610 for ; Wed, 3 Oct 2001 09:06: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 JAA00220; Wed, 3 Oct 2001 09:05: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 JAA00187 for ; Wed, 3 Oct 2001 09:05:10 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12512 for ; Wed, 3 Oct 2001 09:05:05 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f93D3O8P009724; Wed, 3 Oct 2001 09:03:24 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <4A0SM8HQ>; Wed, 3 Oct 2001 09:04:27 -0400 Message-ID: From: Jonathan Rosenberg To: "'christopher.a.martin@wcom.com'" , Jonathan Rosenberg , "'Ram Dantu'" , "'Abdallah Rayhan'" , "'Melinda Shore'" , midcom@ietf.org Subject: RE: [midcom] pre-midcom work item Date: Wed, 3 Oct 2001 09:04:25 -0400 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 > -----Original Message----- > From: Christopher A. Martin [mailto:christopher.a.martin@wcom.com] > Sent: Tuesday, October 02, 2001 2:27 PM > To: 'Jonathan Rosenberg'; 'Ram Dantu'; 'Abdallah Rayhan'; 'Melinda > Shore'; midcom@ietf.org > Subject: RE: [midcom] pre-midcom work item > > > I'm jumping in in the middle of this but here goes, my > questions are inline Responses inline. > > > -----Original Message----- > > From: midcom-admin@ietf.org > [mailto:midcom-admin@ietf.org]On Behalf Of > > Jonathan Rosenberg > > Sent: Tuesday, October 02, 2001 10:30 AM > > To: 'Ram Dantu'; Abdallah Rayhan; Melinda Shore; midcom@ietf.org > > Subject: RE: [midcom] pre-midcom work item > > > > > > > > > > In the stun model, each user has a service provider. The > > client talks to the > > stun server of their service provider. Through that > > communications, they > > obtain a publically usable IP address for media. That requires no > > coordination between providers. > > They obtain an IP address, but what about a port number? does > the client > guess what port number that the nat may assign to the > transaction? In the > case of NAPT(PAT) there is a pool of ports being used randomly in most > cases. My apologies for being imprecise. Yes, they obtain the port number too. The server returns an attribute called MAPPED-ADDRESS which includes a port and IP address. Our assumption was that NAPT was the norm. > > Now in the case of multiple nats this gets even more > complicated, unless we > assumethe outermost nat is the ip address seed. Exactly. The server is on the public Internet. Since it returns the source address it saw in the request packet, this will be the source address that was set by the outermost NAT. This is also a publically routable address. Packets sent to that address will get properly routed back through that nat, and any other nats between it and the client. > > > > > So, consider the case where I am a user of foo.com > > (sip:jdrosen@foo.com). > > When I start my phone, my phone uses stun, and talks to the > > foo.com stun > > server on the public Internet. Using the discovery procedure > > in the spec, my > > phone discovers that there is at least one nat between me and > > the public > > Internet, and that its full cone. > > What is "full cone"? These are my only two questions for > now, until I read > the rest of the draft. Full cone is defined in the document: Full Cone: A full cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. Furthermore, any external host can send a packet to the internal host, by sending a packet to the mapped external address. I have heard that this represents about 35 - 40% of deployed NAT. Thanks, Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Oct 3 10:25:34 2001 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 KAA16165 for ; Wed, 3 Oct 2001 10:25: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 KAA02610; Wed, 3 Oct 2001 10:23: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 KAA02583 for ; Wed, 3 Oct 2001 10:23:39 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16115 for ; Wed, 3 Oct 2001 10:23:34 -0400 (EDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA05305 for ; Wed, 3 Oct 2001 09:23:03 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Wed, 3 Oct 2001 09:22:45 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Oct 2001 09:22:44 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E06F1C5@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Christian Huitema'" , Bob Penfield , Scott Brim , midcom Subject: RE: [midcom] New requirement bullets for decision Date: Wed, 3 Oct 2001 09:22:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14C16.DC667C20" 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_01C14C16.DC667C20 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Tuesday, October 02, 2001 6:47 PM > To: Bob Penfield; Scott Brim; midcom > Subject: RE: [midcom] New requirement bullets for decision > > > > Which is a better "key" for the ruleset? One that is > > allocated when the > > ruleset is created and remains constant or one the changes > > over the life of > > the ruleset? > > We debated that in London, and in fact I am supposed to head > a panel and > write a draft on the issue. (Volunteers are welcome.) There are two > options. If you want to keep "id=filter-spec", then the H.323 scenario > is solved by creating two rulesets: create first a wildcard ruleset, > then delete the wild card ruleset and create a specific ruleset. I don't think its a good idea to create a ruleset id which can change in the middle of a session (what purpose does your name serves if it changes in the middle of your life! You need to advertise to everybody who knows you that you've a new name). I like Bob's idea of an id for rule-set and a separate id for rule-set aggregate. These ids should be separate from any attribute describing the entity and should remain unchanged for the lifetime of the entity. > > There are all kinds of pros and cons in this debate, but as an > architecture rule, it is preferable to avoid creating extra > identifiers > whenever possible. > > -- Christian Huitema > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C14C16.DC667C20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] New requirement bullets for decision

> -----Original Message-----
> From: Christian Huitema [mailto:huitema@windows.mic= rosoft.com]
> Sent: Tuesday, October 02, 2001 6:47 PM
> To: Bob Penfield; Scott Brim; midcom
> Subject: RE: [midcom] New requirement bullets = for decision
>
>
> > Which is a better "key" for the = ruleset? One that is
> > allocated when the
> > ruleset is created and remains constant or = one the changes
> > over the life of
> > the ruleset?
>
> We debated that in London, and in fact I am = supposed to head
> a panel and
> write a draft on the issue. (Volunteers are = welcome.) There are two
> options. If you want to keep = "id=3Dfilter-spec", then the H.323 scenario
> is solved by creating two rulesets: create = first a wildcard ruleset,
> then delete the wild card ruleset and create a = specific ruleset.

I don't think its a good idea to create a ruleset id = which can change in
the middle of a session (what purpose does your name = serves if it changes
in the middle of your life!  You need to = advertise to everybody who knows you
that you've a new name).
I like Bob's idea of an id for rule-set and a = separate id for rule-set aggregate.
These ids should be separate from any attribute = describing the entity and should remain
unchanged for the lifetime of the entity.  =

>
> There are all kinds of pros and cons in this = debate, but as an
> architecture rule, it is preferable to avoid = creating extra
> identifiers
> whenever possible.
>
> -- Christian Huitema
>
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C14C16.DC667C20-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Oct 3 14:47:51 2001 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 OAA25756 for ; Wed, 3 Oct 2001 14:47: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 OAA13259; Wed, 3 Oct 2001 14:44: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 OAA13226 for ; Wed, 3 Oct 2001 14:44: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 OAA25682 for ; Wed, 3 Oct 2001 14:44:46 -0400 (EDT) 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 f93IiKq17909 for ; Wed, 3 Oct 2001 11:44:20 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-119.cisco.com [10.82.192.119]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAB06883; Wed, 3 Oct 2001 11:44:01 -0700 (PDT) Message-Id: <5.1.0.14.0.20011003144433.00a57790@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 03 Oct 2001 14:46:16 -0400 To: midcom From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Fwd: I-D ACTION:draft-shore-friendly-midcom-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 For those who aren't on the ietf-announce mailing list, I'm forwarding this along. It's a draft on an alternative model for communicating with middleboxes that gets around some of the topology-related problems we're experiencing in the working group. This is NOT for discussion on the midcom mailing list. Melinda >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-shore-friendly-midcom-00.txt >Date: Wed, 03 Oct 2001 07:13:10 -0400 >Sender: nsyracus@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Towards a Network-friendlier Midcom > Author(s) : M. Shore > Filename : draft-shore-friendly-midcom-00.txt > Pages : 14 > Date : 02-Oct-01 > >While IP was designed around the notion that the network would be >invisible to the applications that run on them, an increasingly >complex service environment along with the compartmentalization of >'policy' into administrative domains has led to a proliferation of >types of middleboxes for policy enforcement, and those middleboxes >are interfering with applications. Applications now need to influ- >ence the behavior of middleboxes, but violating network layering >principles by establishing explicit communication channels from >applications to network-layer middleboxes introduces a new set of >problems related to topology and discovery as well as consequent >problems that ripple out from those. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-shore-friendly-midcom-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-shore-friendly-midcom-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-shore-friendly-midcom-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: <20011002120848.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-shore-friendly-midcom-00.txt > > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Oct 3 17:21:08 2001 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 RAA00363 for ; Wed, 3 Oct 2001 17:21: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 RAA17534; Wed, 3 Oct 2001 17:17: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 RAA17505 for ; Wed, 3 Oct 2001 17:17:15 -0400 (EDT) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00199 for ; Wed, 3 Oct 2001 17:17:10 -0400 (EDT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (PMDF V5.2-33 #42260) with ESMTP id <0GKN00084F3SUE@firewall.wcom.com> for midcom@ietf.org; Wed, 3 Oct 2001 21:16:40 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GKN00I01F3O8H@pmismtp01.wcomnet.com>; Wed, 03 Oct 2001 21:16:40 +0000 (GMT) Received: from rccc6131 ([166.35.248.245]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GKN00H3KF3AVD@pmismtp01.wcomnet.com>; Wed, 03 Oct 2001 21:16:22 +0000 (GMT) Date: Wed, 03 Oct 2001 16:16:19 -0500 From: "Christopher A. Martin" Subject: RE: [midcom] pre-midcom work item In-reply-to: To: "'Jonathan Rosenberg'" , "'Ram Dantu'" , "'Abdallah Rayhan'" , "'Melinda Shore'" , midcom@ietf.org Reply-to: christopher.a.martin@wcom.com Message-id: <005001c14c50$a58f2140$f5f823a6@rccc6131.mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 inline > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, October 03, 2001 8:04 AM > To: 'christopher.a.martin@wcom.com'; Jonathan Rosenberg; 'Ram Dantu'; > 'Abdallah Rayhan'; 'Melinda Shore'; midcom@ietf.org > Subject: RE: [midcom] pre-midcom work item > > > > > > > > -----Original Message----- > > From: Christopher A. Martin [mailto:christopher.a.martin@wcom.com] > > Sent: Tuesday, October 02, 2001 2:27 PM > > To: 'Jonathan Rosenberg'; 'Ram Dantu'; 'Abdallah Rayhan'; 'Melinda > > Shore'; midcom@ietf.org > > Subject: RE: [midcom] pre-midcom work item > > > > > > I'm jumping in in the middle of this but here goes, my > > questions are inline > > Responses inline. > > > > > > -----Original Message----- > > > From: midcom-admin@ietf.org > > [mailto:midcom-admin@ietf.org]On Behalf Of > > > Jonathan Rosenberg > > > Sent: Tuesday, October 02, 2001 10:30 AM > > > To: 'Ram Dantu'; Abdallah Rayhan; Melinda Shore; midcom@ietf.org > > > Subject: RE: [midcom] pre-midcom work item > > > > > > > > > > > > > > > In the stun model, each user has a service provider. The > > > client talks to the > > > stun server of their service provider. Through that > > > communications, they > > > obtain a publically usable IP address for media. That requires no > > > coordination between providers. > > > > They obtain an IP address, but what about a port number? does > > the client > > guess what port number that the nat may assign to the > > transaction? In the > > case of NAPT(PAT) there is a pool of ports being used > randomly in most > > cases. > > My apologies for being imprecise. Yes, they obtain the port > number too. The > server returns an attribute called MAPPED-ADDRESS which > includes a port and > IP address. Our assumption was that NAPT was the norm. Excellent. Does the attribute also facilitate the RTCP port as well? > > > > > Now in the case of multiple nats this gets even more > > complicated, unless we > > assumethe outermost nat is the ip address seed. > > Exactly. The server is on the public Internet. Since it > returns the source > address it saw in the request packet, this will be the source > address that > was set by the outermost NAT. This is also a publically > routable address. > Packets sent to that address will get properly routed back > through that nat, > and any other nats between it and the client. > > > > > > > > > So, consider the case where I am a user of foo.com > > > (sip:jdrosen@foo.com). > > > When I start my phone, my phone uses stun, and talks to the > > > foo.com stun > > > server on the public Internet. Using the discovery procedure > > > in the spec, my > > > phone discovers that there is at least one nat between me and > > > the public > > > Internet, and that its full cone. > > > > What is "full cone"? These are my only two questions for > > now, until I read > > the rest of the draft. > > Full cone is defined in the document: > > Full Cone: A full cone NAT is one where all requests from the > same internal IP address and port are mapped to the same > external IP address and port. Furthermore, any external > host can send a packet to the internal host, by sending a > packet to the mapped external address. > > I have heard that this represents about 35 - 40% of deployed NAT. Thanks, And I would concur with that (and add that the number may be possibly an even larger percentage from my experience) > > Thanks, > Jonathan R. > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Oct 4 11:24:00 2001 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 LAA16230 for ; Thu, 4 Oct 2001 11:23: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 LAA22674; Thu, 4 Oct 2001 11:20: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 LAA22641 for ; Thu, 4 Oct 2001 11:20:52 -0400 (EDT) Received: from linux.aravox.com (linux.aravox.com [209.46.41.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16121 for ; Thu, 4 Oct 2001 11:20:48 -0400 (EDT) Received: from MPIETRAS (dyn-1-110.aravox.com [192.168.1.110] (may be forged)) by linux.aravox.com (8.9.3/8.9.3) with SMTP id KAA26236; Thu, 4 Oct 2001 10:19:44 -0500 From: "Mark Pietras" To: "Jonathan Rosenberg" , Subject: RE: [midcom] pre-midcom work item Date: Thu, 4 Oct 2001 10:20:19 -0500 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.4133.2400 In-Reply-To: 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, More of a question about the _solution_ than the particulars of STUN: Have you found a solution to the problem of "misguided" media? That is, when two clients are behind the same NAT and there's no call-control/routing element with them in that same "realm?!", both will be forced to assume that the other is on the "outside" the NAT. Both the signaling and the media will be sent "outside" just to be routed right back. Signaling might not be a big deal, but media might be (from a latency or more interestingly a NAT-loading perspective). Mark P. -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Jonathan Rosenberg Sent: Monday, October 01, 2001 4:40 PM To: 'Abdallah Rayhan'; Jonathan Rosenberg; Melinda Shore; midcom@ietf.org Subject: RE: [midcom] pre-midcom work item Folks, I've just submitted an I-D to the archives, co-authored with Christian Huitema and Rohan Mahy, on what this protocol might look like. Until it appears in the archives, you can pick it up from: http://www.jdrosen.net/papers/draft-rosenberg-midcom-stun-00.txt Its just a step above "echo", but it can determine the presence of nats, diagnose the type, and help determine binding lifetimes. This protocol will suffice to help a SIP enabled voip phone get through a fairly large fraction of nats (full cone and restricted cone, which is about 80-90% of nats depending on who you ask) while still maintaining direct, end-to-end voice transport. The protocol is totally independent of sip; a separate draft (in sipping) is pending on how to use the stun protocol in a sip client. Comments/questions/flames welcome as always. Hopefully this will help clarify the kind of things the new charter item is aiming at. Thanks, Jonathan R. > -----Original Message----- > From: Abdallah Rayhan [mailto:ar_rayhan@yahoo.ca] > Sent: Monday, September 24, 2001 2:21 PM > To: Jonathan Rosenberg; Melinda Shore; midcom@ietf.org > Subject: RE: [midcom] pre-midcom work item > > > --- Jonathan Rosenberg wrote: > > > > Secondly, this introduces > > > new architectural constraints that is going to screw > > > the consensus achieved so far on the architecture draft. > > > > How is that? > > Before amending the charter we at least need to know > what and how this would work. Instead we got a charter > change dictated on us before learning how this > SIP-happy-NAT is going to influence the current architecture, > or being discussed and scrutinized by the WG. > > > > > > > > The deployment argument of IKE/IPSec, IP6, MPLS didnt stop > > > the WGs from developing those standards. Why should we be > > > the exception? > > > > No one is saying that it should not be deployed. Full steam > ahead. We > > need > > midcom, and that hasn't changed. The fact is that midcom can't fully > > solve > > our problems. > > > > Its also worth noting that there are already solutions > being deployed > > today > > that play the role of the proposed addition. Those are all > > proprietary and > > not interoperable. Let us not let that continue. > > What will happen is another beast will be added to the gang. > > _______________________________________________________ > Do You Yahoo!? > Get your free @yahoo.ca address at http://mail.yahoo.ca > --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Oct 4 14:23:48 2001 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 OAA21333 for ; Thu, 4 Oct 2001 14:23: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 OAA29004; Thu, 4 Oct 2001 14:18: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 OAA28975 for ; Thu, 4 Oct 2001 14:18:05 -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 OAA21220 for ; Thu, 4 Oct 2001 14:18:01 -0400 (EDT) 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 f94IHag01963 for ; Thu, 4 Oct 2001 11:17:36 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-1.cisco.com [10.82.192.1]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAC00548; Thu, 4 Oct 2001 11:17:16 -0700 (PDT) Message-Id: <5.1.0.14.0.20011004141349.00a51cf0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 04 Oct 2001 14:19:27 -0400 To: midcom From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Update on bullets currently under consideration 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 R46 is accepted as revised: R46: The protocol MUST support the concept of a ruleset group comprising a multiple of individual rulesets to be treated as an aggregate. We'll await the output of Christian's team for R47. For R60, we have a proposal for replacement text as follows: "The protocol MUST allow the midcom agent to extend the lifetime of an existing ruleset that otherwise would be deleted by the middlebox" but no decision yet. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Oct 4 14:23:49 2001 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 OAA21331 for ; Thu, 4 Oct 2001 14:23: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 OAA29099; Thu, 4 Oct 2001 14:21: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 OAA29068 for ; Thu, 4 Oct 2001 14:21:26 -0400 (EDT) Received: from WIN-INET-01.wingroup.windeploy.ntdev.microsoft.com ([131.107.3.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21274 for ; Thu, 4 Oct 2001 14:21:10 -0400 (EDT) Received: from win-hub-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.229]) by WIN-INET-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.3651); Thu, 4 Oct 2001 11:12:16 -0700 Received: from 157.54.5.226 by win-hub-01.wingroup.windeploy.ntdev.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 04 Oct 2001 11:12:16 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-hub-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.3651); Thu, 4 Oct 2001 11:12:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] pre-midcom work item Date: Thu, 4 Oct 2001 11:12:14 -0700 Message-ID: Thread-Topic: [midcom] pre-midcom work item Thread-Index: AcFM6pwOYLKYb1WKQvCofEw9bNzy1wAFXWXg From: "Christian Huitema" To: "Mark Pietras" , "Jonathan Rosenberg" , X-OriginalArrivalTime: 04 Oct 2001 18:12:16.0023 (UTC) FILETIME=[19244270:01C14D00] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA29069 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 There are no good solutions to this problem. The current alternative to STUN is to have a media relay outside the NAT; the traffic between two local hosts crosses the relay twice. > -----Original Message----- > From: Mark Pietras [mailto:mpietras@aravox.com] > Sent: Thursday, October 04, 2001 8:20 AM > To: Jonathan Rosenberg; midcom@ietf.org > Subject: RE: [midcom] pre-midcom work item > > > Jonathan, > > More of a question about the _solution_ than the particulars of STUN: > > Have you found a solution to the problem of "misguided" > media? That is, > when two clients are behind the same NAT and there's no > call-control/routing > element with them in that same "realm?!", both will be forced > to assume that > the other is on the "outside" the NAT. Both the signaling > and the media > will be sent "outside" just to be routed right back. > Signaling might not be > a big deal, but media might be (from a latency or more interestingly a > NAT-loading perspective). > > Mark P. > > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Jonathan Rosenberg > Sent: Monday, October 01, 2001 4:40 PM > To: 'Abdallah Rayhan'; Jonathan Rosenberg; Melinda Shore; > midcom@ietf.org > Subject: RE: [midcom] pre-midcom work item > > > > Folks, > > I've just submitted an I-D to the archives, co-authored with Christian > Huitema and Rohan Mahy, on what this protocol might look > like. Until it > appears in the archives, you can pick it up from: > > http://www.jdrosen.net/papers/draft-rosenberg-midcom-stun-00.txt > > Its just a step above "echo", but it can determine the > presence of nats, > diagnose the type, and help determine binding lifetimes. This > protocol will > suffice to help a SIP enabled voip phone get through a fairly > large fraction > of nats (full cone and restricted cone, which is about 80-90% of nats > depending on who you ask) while still maintaining direct, > end-to-end voice > transport. The protocol is totally independent of sip; a > separate draft (in > sipping) is pending on how to use the stun protocol in a sip client. > > Comments/questions/flames welcome as always. Hopefully this will help > clarify the kind of things the new charter item is aiming at. > > Thanks, > Jonathan R. > > > > -----Original Message----- > > From: Abdallah Rayhan [mailto:ar_rayhan@yahoo.ca] > > Sent: Monday, September 24, 2001 2:21 PM > > To: Jonathan Rosenberg; Melinda Shore; midcom@ietf.org > > Subject: RE: [midcom] pre-midcom work item > > > > > > --- Jonathan Rosenberg wrote: > > > > > > Secondly, this introduces > > > > new architectural constraints that is going to screw > > > > the consensus achieved so far on the architecture draft. > > > > > > How is that? > > > > Before amending the charter we at least need to know > > what and how this would work. Instead we got a charter > > change dictated on us before learning how this > > SIP-happy-NAT is going to influence the current architecture, > > or being discussed and scrutinized by the WG. > > > > > > > > > > > > The deployment argument of IKE/IPSec, IP6, MPLS didnt stop > > > > the WGs from developing those standards. Why should we be > > > > the exception? > > > > > > No one is saying that it should not be deployed. Full steam > > ahead. We > > > need > > > midcom, and that hasn't changed. The fact is that midcom > can't fully > > > solve > > > our problems. > > > > > > Its also worth noting that there are already solutions > > being deployed > > > today > > > that play the role of the proposed addition. Those are all > > > proprietary and > > > not interoperable. Let us not let that continue. > > > > What will happen is another beast will be added to the gang. > > > > _______________________________________________________ > > Do You Yahoo!? > > Get your free @yahoo.ca address at http://mail.yahoo.ca > > > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Oct 4 15:11:09 2001 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 PAA22804 for ; Thu, 4 Oct 2001 15:11: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 PAA01000; Thu, 4 Oct 2001 15:09: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 PAA00976 for ; Thu, 4 Oct 2001 15:09:17 -0400 (EDT) Received: from ss8mail1.ss8ott (mail.ss8.ca [209.87.228.147]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22737 for ; Thu, 4 Oct 2001 15:09:12 -0400 (EDT) Received: by mail.ss8.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 4 Oct 2001 15:09:06 -0400 Message-ID: <8BAF8B40C4D2D411ADC300508BD63D69AF38F9@mail.ss8.ca> From: Li Li To: "'Jonathan Rosenberg'" , "'huitema@microsoft.com'" , midcom@ietf.org Subject: RE: [midcom] pre-midcom work item Date: Thu, 4 Oct 2001 15:09:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14D08.07AB6FFC" 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_01C14D08.07AB6FFC Content-Type: text/plain; charset="iso-8859-1" A few quick questions about the stun draft: (1) in section 9.1, close to the bottom of p.10, "If a response is received, the client knows that it has open access to the Internet (or, at least, its behind a firewall that behaves like a port restricted NAT, but without the translation)." Why it is like a port restricted NAT? To me somehow this behaves more like a full cone NAT without translation? (2) I can see STU works well with the full-cone nat. But how about restricted cone or restricted port? It may help if these two cases can be explained in the draft. I remember saw in previous emails that the restricted cone and port restricted cone nats are all supported? The public IP address/port learned from the server can only be used by the server, not the other party in the call that wants to send you audio? How can the client get the mapped address that can be used by the sender? (3) The changed address is returned to the client. How client uses it? Thanks in advance, Li Li ------_=_NextPart_001_01C14D08.07AB6FFC Content-Type: text/html; charset="iso-8859-1" RE: [midcom] pre-midcom work item

A few quick questions about the stun draft:

(1) in section 9.1, close to the bottom of p.10,

"If a response is received, the client knows that it has open access to the
Internet (or, at least, its behind a firewall that behaves like a
port restricted NAT, but without the translation)."

Why it is like a port restricted NAT? To me somehow this behaves more like
a full cone NAT without translation?

(2) I can see STU works well with the full-cone nat. But how about
restricted cone or restricted port? It may help if these two cases can
be explained in the draft. I remember saw in previous emails that the restricted
cone and port restricted cone nats are all supported? The public IP address/port
learned from the server can only be used by the server, not the other party in the
call that wants to send you audio? How can the client get the mapped address
that can be used by the sender?

(3) The changed address is returned to the client. How client uses it? 

Thanks in advance,

Li Li

------_=_NextPart_001_01C14D08.07AB6FFC-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Oct 4 16:01:51 2001 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 QAA24098 for ; Thu, 4 Oct 2001 16:01: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 PAA02452; Thu, 4 Oct 2001 15:52: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 PAA02422 for ; Thu, 4 Oct 2001 15:52:06 -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 PAA23935 for ; Thu, 4 Oct 2001 15:51:57 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f94JpXg09652 for ; Thu, 4 Oct 2001 12:51:33 -0700 (PDT) Received: from SBRIM-W2K (dhcp-171-71-95-177.cisco.com [171.71.95.177]) by airborne.cisco.com (Mirapoint) with SMTP id AAE09715; Thu, 4 Oct 2001 12:51:27 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Thu, 4 Oct 2001 15:51:29 -0400 Date: Thu, 4 Oct 2001 15:51:29 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] pre-midcom work item Message-ID: <20011004155129.C1516@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org 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 huitema@windows.microsoft.com on Thu, Oct 04, 2001 at 11:12:14AM -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 Thu, Oct 04, 2001 11:12:14AM -0700, Christian Huitema allegedly wrote: > There are no good solutions to this problem. The current alternative to > STUN is to have a media relay outside the NAT; the traffic between two > local hosts crosses the relay twice. ...which should cause some concern for security. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Oct 4 19:28:05 2001 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 TAA26283 for ; Thu, 4 Oct 2001 19:28: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 TAA09053; Thu, 4 Oct 2001 19:24: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 TAA08970 for ; Thu, 4 Oct 2001 19:24:08 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26257 for ; Thu, 4 Oct 2001 19:24:04 -0400 (EDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id SAA16271 for ; Thu, 4 Oct 2001 18:23:37 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Thu, 4 Oct 2001 18:23:02 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Oct 2001 18:23:07 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E06F1D7@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: midcom@ietf.org Cc: "Patrick Sollee" , "Sean March" Date: Thu, 4 Oct 2001 18:23:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C14D2B.88AA28F0" Subject: [midcom] Submission of a new Internet 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 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_000_01C14D2B.88AA28F0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14D2B.88AA28F0" ------_=_NextPart_001_01C14D2B.88AA28F0 Content-Type: text/plain; charset="iso-8859-1" Folks, We've submitted an ID called "Midcom-unaware NAT/Firewall Traversal" describing an alternative solution framework (that is implementable today) to solve the problem of traversing deployed NAT/FW's. Two key components of this solution working in tandem are a SIP Proxy & an RTP Proxy. The solution needs interaction between the Proxies, but does not need the clients know about the NAT binds or types and is applicable to all traditional types of NAT's/Firewalls. Attached is a copy of the submitted draft for your reading until it appears in the IETF website. Best Regards, Sanjoy Sen ========= Interactive Multimedia Server Nortel Networks Ph: 972-685-8274, Fax: 972-685-3813 Mobile: 972-571-2062 ------_=_NextPart_001_01C14D2B.88AA28F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Submission of a new Internet draft

Folks,

        We've = submitted an ID called "Midcom-unaware NAT/Firewall = Traversal" describing an alternative solution framework (that is = implementable today) to solve the problem of traversing deployed = NAT/FW's. Two key components of this solution working in tandem are a = SIP Proxy & an RTP Proxy. The solution needs interaction between = the Proxies, but does not need the clients know about the NAT binds or = types and is applicable to all traditional types of NAT's/Firewalls. = Attached is a copy of the submitted draft for your reading until it = appears in the IETF website.

Best Regards,

Sanjoy Sen

=3D=3D=3D=3D=3D=3D=3D=3D=3D
Interactive Multimedia Server
Nortel Networks
Ph: 972-685-8274, Fax: 972-685-3813
Mobile: 972-571-2062

 




  ------_=_NextPart_001_01C14D2B.88AA28F0-- ------_=_NextPart_000_01C14D2B.88AA28F0 Content-Type: text/plain; name="draft-sen-midcom-fw-nat-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-sen-midcom-fw-nat-00.txt" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable =20 Midcom Working Group Sanjoy = Sen Internet Draft Patrick = Sollee Sean = March Category: Standards Track Nortel = Networks Expires on March 2002 September = 2001 =20 =20 Midcom-unaware NAT/Firewall Traversal =20 =20 Status of this Memo =20 This document is an Internet-Draft and is in full conformance=20 with all provisions of Section 10 of RFC2026.=20 Internet-Drafts are working documents of the Internet Engineering =20 Task Force (IETF), its areas, and its working groups. Note that = =20 other groups may also distribute working documents as Internet-=20 Drafts.=20 Internet-Drafts are draft documents valid for a maximum of six =20 months and may be updated, replaced, or obsoleted by other documents = =20 at any time. It is inappropriate to use Internet-Drafts as =20 reference material or to cite them other than as "work in progress." = The list of current Internet-Drafts can be accessed at=20 =20 http://www.ietf.org/ietf/1id-abstracts.txt=20 =20 The list of Internet-Draft Shadow Directories can be accessed at=20 =20 http://www.ietf.org/shadow.html = =20 =20 Abstract=20 =20 Bundled session applications such as FTP, H.323, SIP and RTSP, which = use a signaling/control connection to establish a data/media flow,=20 are usually broken, en-route, by Middleboxes such as NAT. Midcom=20 proposes to solve this problem by allowing the Middlebox to be=20 controlled through a generalized control interface by an=20 application-aware entity called Midcom Agent. Since ubiquitous=20 deployment of Midcom is still a few years away, an interim solution=20 is needed to allow applications traverse NAT and Firewalls=20 seamlessly without the help of embedded Application Layer Gateways=20 (ALG). In this draft, a pre-Midcom solution framework is developed.=20 A solution for the problem of NAT/FW traversal is needed both for=20 the signaling and media/data paths. Two key components of the=20 proposed solution are: (1) a Signaling Proxy server on the signaling = path, and (2) a Media Proxy server on the media path. The Signaling=20 server interacts with the Media server through a control interface.=20 Although the primary applicability of this framework is shown for=20 real-time RTP/UDP-based SIP multimedia sessions, these concepts =20 =0D=0CInternet Draft Midcom-unaware Firewall/NAT Traversal Sept = 2001 =20 should be generally applicable to other types of data sessions=20 established through a control connection.=20 =20 Table of Contents=20 =20 Status of this Memo................................................1 = Abstract...........................................................1 = 1 Introduction ...................................................2 = 2 Conventions used in this document ..............................3 = 3 NAT Terminologies and Concepts .................................3 = 4 Problem Statement ..............................................4 = 5 Key Solution Requirements ......................................4 = 6 A Solution Framework ...........................................5 = 6.1 Approach ........................................................5 = 6.2 Signaling Path ..................................................6 = 6.3 Media Path: The Case for RTP (Media) Proxy ......................8 = 7 Advantages and Disadvantages of the Solution ..................11 = 8 New Requirements on SIP Client, Signaling Proxy Server and RTP=20 Proxy.............................................................12 = 9 Consistency with the Midcom Framework .........................12 = 10 Security Considerations .......................................13 = 11 References ....................................................13 = 12 Acknowledgments ...............................................13 = 13 Author's Address ..............................................13 = 14 Intellectual Property Statement ...............................14 = 15 Full Copyright Statement ......................................14 = =20 =20 =20 1 Introduction=20 =20 Bundled session applications such as FTP, H.323, SIP and RTSP, which = use a signaling/control connection to establish a data/media flow,=20 are usually broken, en-route, by Middleboxes such as NAT. Midcom=20 proposes to solve this problem by allowing the Middlebox to be=20 controlled through a generalized control interface by an=20 application-aware entity called Midcom Agent. Since ubiquitous=20 development of Midcom is still a few years away, an interim solution = is needed to allow applications traverse NAT and Firewalls=20 seamlessly without the help of embedded Application Layer Gateways=20 (ALG). In this draft, a pre-Midcom solution framework is developed.=20 A solution for the problem of NAT/FW traversal is needed both for=20 the signaling and media/data paths. Two key components of the=20 proposed solution are: (1) a Signaling Proxy server on the signaling = path, and (2) a Media Proxy server on the media path. The Signaling=20 server interacts with the Media server through a control interface.=20 Although the primary applicability of this framework is shown for=20 real-time RTP/UDP-based multimedia sessions, these concepts are=20 =20 Sen Expires March 2002 [Page 2] Internet Draft Midcom-unaware Firewall/NAT Traversal Sept 2001 =20 generally applicable to other types of data sessions established=20 through a control connection. =20 2 Conventions used in this document =20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", = "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in =20 this document are to be interpreted as described in RFC-2119. =20 =20 =20 3 NAT Terminologies and Concepts=20 =20 The types of NAT considered in this draft fall under the Traditional = NAT category as discussed in [1]:=20 =20 Traditional (or Outbound) NAT: In a traditional NAT, sessions are=20 uni-directional, outbound from the private network. This is in=20 contrast with Bi-directional NAT, which permits sessions in both=20 inbound and outbound directions. Traditional NAT's are of two types: = =20 Basic NAT: With Basic NAT, a block of external addresses are set=20 aside for translating addresses of hosts in a private domain as=20 they originate sessions to the external domain.=20 =20 Network Address and Port Translation: NAPT extends the notion of=20 translation one step further by also translating transport=20 identifier (e.g., TCP and UDP port numbers, ICMP query=20 identifiers).=20 =20 [1] also describes two other types of NAT's - Bi-directional NAT and = Twice NAT.=20 =20 In [2], the Traditional NAT's have been classified as follows: =20 =20 Symmetric NAT: These create an address binding when routing the=20 first packet from 'private' to 'public' address realms in the usual=20 way, but will only allow return packets from the public host=20 address/port to which the first packet was sent.=20 =20 Full Cone NAT: Unlike Symmetric NAT, they will allow return packets=20 from any host on the public network. =20 =20 Needless to say that, the Symmetric NAT's offer the most=20 excruciating constraints for media traversal. We also note that,=20 Full Cone NAT's by themselves, without the aid of a Firewall, may=20 not provide adequate level of security for the Enterprises. =20 =20 =20 =20 Sen Expires March 2002 [Page 3] Internet Draft Midcom-unaware Firewall/NAT Traversal Sept 2001 =20 4 Problem Statement=20 =20 As discussed in [3], bundled session applications such as FTP,=20 H.323, SIP and RTSP, which use a control connection to establish a=20 data/media flow are usually broken by NAT devices en-route (Note:=20 media and data are used synonymously in this draft). The reason is=20 as follows: these applications exchange, within control sessions,=20 address and port parameters for the media sessions, which may be=20 realm-specific and not valid (i.e., not reachable) outside the realm = boundary. Another problem is that the media session, being=20 established by the control session, may not be permitted through the = NAT. The problem can be decomposed into two sub-components:=20 =20 1) Problem of establishing and maintaining the control session=20 through the NAT/FW=20 2) Problem of establishing and maintaining the associated media=20 session(s) through the NAT/FW =20 =20 Let us illustrate the above set of problems using SIP. SIP carries=20 within the message the IP address and ports describing the media=20 streams that it controls. For example, the SDP in the SIP message=20 body carries the IP address and port at which the endpoint wishes to = receive media. If the endpoint has a private address (advertised=20 through the SDP), then media from an external endpoint will not=20 reach it, as the address is not globally routable. =20 =20 Note that, the above inconsistencies can be solved easily by=20 allowing the usage of Application Level Gateways (ALG) in the=20 FW/NAT's, which would make all the necessary changes in the SIP=20 messages to ensure that the application works properly without any=20 perceived changes (this would, for example, mean that all instances=20 of private IP addresses occurring within the SIP message from the=20 private endpoint to the public, will be replaced by the publicly=20 reachable address provided by the NAT). However, this has not been a = popular solution as the majority of the deployed NAT's continue to=20 be SIP unaware. =20 =20 A stateful, packet-filter firewall has been (implicitly) assumed to=20 exist along with the NAT, as this is the most commonly occurring=20 Enterprise scenario. In the SIP examples, it is assumed that this=20 firewall is configured to allow packets to and from the SIP and RTP=20 Proxies. =20 =20 =20 5 Key Solution Requirements=20 =20 We envisage some of key requirements as follows:=20 =20 Sen Expires March 2002 [Page 4] Internet Draft Midcom-unaware Firewall/NAT Traversal Sept 2001 = =20 =20 - Any interim solution to be deployed today requires that the=20 NAT/FW's need none or very minimal configuration changes. =20 - Enable establishment of a bi-directional control session(s)=20 through the NAT/FW's by ensuring proper routing of control messages. = - Enable establishment of a bi-directional media session(s)=20 through the NAT/FW's by ensuring proper routing of media packets.=20 - Ensure robustness of both media and control sessions in the face = of dynamic NAT binds and Firewall pin-holes.=20 - Must require minimal changes in the end applications due to=20 time-to-market reasons=20 - Must provide low call set-up time by keeping the number of=20 roundtrip message exchanges to a minimum.=20 - Must be secured against all kinds of security attacks - denial=20 of service, address spoofing etc.=20 - A single simple solution should serve all types of NAT's and=20 network topologies=20 - Must be consistent with the Midcom framework=20 =20 The NAT's considered in this draft are Symmetric and Full Cone types = [2].=20 =20 6 A Solution Framework =20 =20 6.1 Approach=20 =20 We note that the above problems are most difficult to solve for=20 Symmetric NAT's, and that a solution for this type of NAT=20 automatically applies to the other types, e.g., Full Cone. We=20 shall start with seemingly the most complex network topology, in=20 which both the communicating entities are behind a Symmetric NAT=20 in their respective Enterprise domains. Solutions for other=20 topologies can be easily derived from this base solution. In all=20 cases, the generic concept will be described first followed by an=20 illustration of its application with SIP.=20 =20 There are two main components of the solution - one addressing the = control/signaling path issues, and the other, the media path. The=20 signaling path component consists of a stateful Signaling Proxy=20 server exhibiting some distinct behavior to be discussed later.=20 The media path component consists of a Media Proxy server. In the=20 context of SIP and RTP, the signaling path component will be a SIP = Proxy server called Back-to-Back-User-Agent (BBUA) and the media=20 path component is an RTP Proxy, as shown in Figure 1. The=20 signaling and media proxies interact using some control protocol,=20 which is transparent to the end users. =20 =20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . = =20 Service Provider=20 =20 Sen Expires March 2002 [Page 5] Internet Draft Midcom-unaware Firewall/NAT Traversal Sept 2001=20 =20 +-------+ +-------+ = =20 | SIP | | SIP | = =20 | Proxy |+ + + + + + + + +| Proxy | = =20 | X' | | Y' | = =20 | |\ | | = =20 +-------+ \ +-------+ = =20 + \+---------+ + = =20 + | | + = = =20 + |RTP Proxy| +=20 + ^ ^ ^ | |^ ^ ^ + = =20 + ^ +---------+ ^ + = =20 . . . + . . ^ . . . . . . . . . . . . . . ^ . + . . . = =20 + ^ ^ + = =20 + ^ ^ + = =20 +---------+ +---------+ = =20 ........|Symmetric|........... .........|Symmetric|........ = =20 . | NAT/FW | . . | NAT/FW | . = =20 . +---------+ . . +---------+ . = =20 . + ^ . . ^ + . = =20 . + ^ . . ^ + . = =20 . + ^ . . ^ + . = =20 . + ^ . . ^ + . = =20 . +-------+ . . +-------+ . = =20 . | SIP UA| . . | SIP UA| . = =20 . | X | . . | Y | . . +-------+ . . +-------+ . = = =20 .............................. ............................ = =20 = =20 Enterprise or Enterprise or=20 Residence Residence =20 =20 ++++ Control path for media=20 ^^^^ Media path=20 ---- Control path between=20 Signaling and Media Proxies=20 =20 Figure 1. =20 =20 =20 =20 =20 6.2 Signaling Path =20 =20 The following perquisites must be met in order for the solution to=20 work:=20 1. The solution described here, relies on the principle that=20 connections from within the Enterprise are allowed out and that the=20 corresponding responses to those connections are allowed back in (as=20 in case of Traditional NAT's). This enables the end points inside=20 the enterprise to maintain a connection to the Signaling server via a = "keep-alive" mechanism. =20 =20 Sen Expires March 2002 [Page 6] Internet Draft Midcom-unaware Firewall/NAT Traversal Sept 2001 = =20 =20 2. All signaling messages must travel via the Signaling Proxy. The = SIP Signaling Proxy server with whom the UA registered must be the=20 one through which all incoming (outgoing) calls are routed to (from)=20 the UA.=20 =20 3. The SIP Signaling Proxy server must be one hop away from the=20 UA. =20 =20 4. The destination port of the requests at the Signaling Proxy=20 server is the same as the source port of the corresponding responses. = =20 =20 In the example configuration shown in Figure 1, the signaling path is = established when the SIP UA's register with the corresponding=20 Proxy/Register (Signaling server). The SIP REGISTER message contains=20 an extension tag carried in the Proxy-Require header, indicating to=20 the Proxy that the client is behind a NAT (Note: the client or the=20 Proxy does not care about the type of NAT, as the same solution=20 applies to all types). This packet is NAT-ed by the Enterprise NAT=20 with a new source IP address and port. If the Proxy supports the=20 extension tag, it creates an association between the IP address and=20 port from which the packet arrived and the actual address of the=20 user. The response to the Registration message is sent to this IP=20 address and port (not to the Contact address in the REGISTER). =20 =20 Once the signaling path is established, this can be used to send=20 subsequent requests and responses to the user using the above=20 association stored at the Proxy, i.e., the request is sent (as=20 above) to the address/port assigned by the NAT instead of to the=20 actual address of the user. All requests and responses must be=20 routed via this Signaling Proxy. All requests from the user=20 should carry the Proxy-require header with the special tag=20 indicating that it is behind NAT/FW.=20 =20 The signaling path is always kept open through the NAT using a keep- alive mechanism. This can be done using REGISTER refreshes as=20 proposed in [2]. One disadvantage of using the REGISTER method for=20 this purpose is it forces frequent (at least once every minute),=20 unnecessary involvement on the part of the Registrar. In this=20 solution, "keep-alive" is achieved by periodically sending a new=20 lightweight SIP method from the UA to the Server designed=20 specifically for this purpose. The new SIP method is called PING and=20 contains the following mandatory SIP headers: From, To, Via, Proxy- require, Contact, Call-id, Cseq. The Proxy Server responds to the=20 PING method with a 200 OK final response. The timeout values in=20 Firewalls and NAT's are observed to be between 1 to 3 mins and the=20 =20 Sen Expires March 2002 [Page 7] Internet Draft Midcom-unaware Firewall/NAT Traversal Sept 2001=20 =20 "keep-alive" frequency must be higher than this. This keep-alive=20 mechanism must continue during the call. =20 =20 The public IP address/port allocated by the NAT is returned to the=20 Client in the Contact header of 200 OK sent by the Proxy server. This = allows the UA to perform NAT/FW failure detection by - (a) not=20 receiving 200 OK over a prolonged period of time, and (b) detecting=20 that the NAT IP address has changed in a received 200 OK. The second=20 event can serve as an indication that the UA needs to re-register=20 with the Proxy server to maintain the signaling path open. The NAT=20 address/port, although sent to the registered UA, is never carried in = SIP messages towards the remote callee. This provides certain amount=20 of security through IP address hiding.=20 =20 =20 6.3 Media Path: The Case for RTP (Media) Proxy =20 =20 RTP Proxy, as the name suggests, terminates an RTP session on one=20 side and originates the same session on the other. The UA always=20 sends (and receives) media to (and from) an assigned address and = port=20 of the RTP proxy. The RTP Proxy can perform NAPT function both on = the=20 source and destination address/port of packets. For a solution using = an RTP Proxy to work, the requirement is that any media stream=20 traversing the NAT from the private side (e.g., Enterprise) must=20 always go through the RTP Proxy (and any intra-Enterprise traffic=20 should be able to bypass the RTP Proxy). Since incoming packets are=20 received from the same address and port as the outgoing packets are=20 sent to, a Symmetric NAT will always allow the packets from the RTP=20 proxy inside the Enterprise for the duration of the session. This=20 implies that a Full Cone NAT (or any restricted version of it) will=20 also allow flows to and from the RTP Proxy. This principle can be=20 generalized to be applicable to any type of application session, not = just RTP/RTCP sessions. =20 =20 The following are the prerequisites for this solution to work:=20 =20 1. Any media stream that traverses the NAT from private side to the=20 public will pass through the RTP Proxy.=20 =20 2. The addresses and ports in the RTP Proxy are assigned either=20 during the call set-up or before it.=20 =20 3. The RTP Proxy should know where to send the received media. For=20 example, if it is acting as a bridge between two private endpoints X = and Y (X and Y are behind different NAT's), this implies that the=20 =20 Sen Expires March 2002 [Page 8] Internet Draft Midcom-unaware Firewall/NAT Traversal Sept 2001=20 =20 Proxy should be aware of the X's external address/port before (or at = least, as soon as) it starts receiving media from Y, and vice-versa. = =20 =20 4. The send and receive ports of the media in the UA's are = configured=20 to be the same. =20 =20 Reverting back to our example configuration in Figure 1, let us=20 illustrate using a call flow, how resource allocation in the RTP=20 Proxy will take place when UA X wants to establish a SIP session = with=20 UA Y (only relevant parts of the call flow is shown). It is assumed=20 that the signaling paths between the UA's and the Proxy are already=20 established by the method described in Section 6.2. Please refer to=20 Figure 2 for the address/port allocations at various devices and the = call flow. =20 =20 Legends:-=20 <><> : bi-directional flow=20 ---- : signaling =20 =3D=3D=3D=3D : media =20 px, px', py*, px*, py', py : ports=20 PXA, NX, A, NY, PYA : IP addresses=20 =20 PXA NX A NY PYA=20 +-----+ +-----+ +--------+ +-----+ +-----+ =20 | | | | | | | | | | = =20 | px|<><><| px'|<><><>py* px*|<><>|py' |<><>|py | = =20 | | | | | | | | | | =20 +-----+ +-----+ +--------+ +-----+ +-----+ = =20 =20 UA X NAT Proxy RTP Proxy NAT UA Y =20 X'=20 =20 | 1.INVITE | | | | |=20 |---------->|------>| | | |=20 | | |------->| | |=20 | | | 2.Create | |=20 | | | port bind | |=20 | | |<-------| | |=20 | | | |3.INVITE | |=20 | | |------------------>|-------->| =20 | | | | | |=20 |<----------|<------|<------------------|<--------|=20 | 5. 200 OK | | |4.200 OK | |=20 | | | | | |=20 = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D>| | | =20 | | 6.RTP | = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D|<=3D=3D=3D=3D=3D=3D=3D=3D| =20 | | | | 6.RTP | |=20 | | | | | |=20 |---------->|------>|------------------>|-------->|=20 |7. ACK | | | | |=20 =20 Sen Expires March 2002 [Page 9] Internet Draft Midcom-unaware Firewall/NAT Traversal Sept 2001 =20 | | | | | |=20 = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D>|<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >|<=3D=3D=3D=3D=3D=3D=3D=3D>|<=3D=3D=3D=3D=3D=3D=3D>|=20 RTP=20 =20 =20 Figure 2.=20 =20 =20 1. UA X sends a SIP INVITE message towards UA Y through the Proxy X' = specifying that it wishes to receive media at (private) IP address,=20 PXA and port, px, i.e., PXA:px.=20 =20 2. Proxy X' instructs the RTP Proxy to reserve a pair of IP=20 address/port, one representing each end of the connection. To UA Y,=20 the remote end of the connection is perceived to be A:px*, whereas = to=20 UA X, this is perceived to be A:py*. Note 1: Due to the presence of=20 the NAT's, the source IP address/port of the media packets from the=20 UA's are yet unknown to the RTP Proxy. Note 2: Consecutive port = binds=20 are also created for RTCP sessions corresponding to RTP.=20 =20 3. Proxy X' forwards the INVITE towards UA Y (perhaps through Proxy=20 Y') specifying that Y should send media to the RTP Proxy at A:px* = (by=20 modifying the SDP).=20 =20 4. UA Y responds with a 200 OK specifying that it wishes to receive=20 media at (private) IP address, PYA and port, py, i.e., PYA:py.=20 =20 5. When Proxy X' receives the 200 OK, it changes these IP address = and=20 port parameters in SDP specifying X should transmit media to the RTP = Proxy at A:py*, and forwards the 200 OK towards UA X (Note: Proxy X' = actually forwards the message to the external NAT-ed address/port of = UA X).=20 =20 6. When UA X receives the 200 OK, it starts transmitting media = (e.g.,=20 background noise) towards the RTP Proxy. When the first of these = NAT- ed RTP packets reach the RTP Proxy, the Proxy remembers the source=20 address/port (say, NX, px') of that packet as the external=20 representation for the media end point of UA X. Any media received=20 from Y to X should be sent to this address/port.=20 =20 Similarly, when the first RTP packet is received from UA Y, the RTP=20 Proxy notes down the source IP address/port (say, NY:py'), which = will=20 be used as the destination address to transmit media received from X = to Y.=20 =20 7. Finally, UA X responds with an ACK message and the call set-up is = complete. =20 =20 Sen Expires March 2002 [Page 10] Internet Draft Midcom-unaware Firewall/NAT Traversal Sept 2001 = =20 =20 =20 Note that, since all signaling is routed via the Proxy, which can=20 determine whether both the UA's are in the same domain, all intra- Enterprise calls (behind the same NAT) can avoid the trip to the RTP=20 Proxy. This is one of the key advantages of the Proxy mediating the=20 address/port of the endpoints of a call.=20 =20 Once the media path is established through the NAT, keep-alive=20 messages in the form of periodic RTP packets are sent to keep the=20 connection alive when the users are in mute (i.e., when no speech=20 packets are transmitted).=20 =20 There needs to be some control interaction between the SIP and the=20 RTP Proxies to establish the end-to-end sessions. The protocol can=20 be one of the device control protocols such as MGCP, Megaco etc.=20 =20 7 Advantages and Disadvantages of the Solution =20 =20 Key Advantages:=20 =20 1. Simple, one-size-fits-all solution for all types of traditional=20 NAT's and Firewalls. We believe that the majority of the deployed=20 NAT's are either Symmetric or restricted Full Cone (e.g., fronted by = a Firewall), which will need an RTP Proxy or some form of=20 Intermediary [2] based solution.=20 =20 2. The RTP Proxy offers additional level of security as the only=20 source (destination) of media to (from) the Enterprise NAT/FW. The=20 Signaling Proxy also provides protection against "address spoofing"=20 by IP address hiding.=20 =20 3. Allows UA's behind the same Symmetric NAT bypass the RTP Proxy =20 =20 4. Light weight refresh mechanism for FW/NAT pinhole/bind =20 =20 5. Can provide advanced, value-added services such as media=20 replication (used for legal intercept), media anchor/pivoting etc.=20 =20 Key Disadvantages:=20 =20 1. Scalability of the solution heavily dependent on the Media Proxy=20 =20 2. May be costly to maintain and provision=20 =20 =20 =20 Sen Expires March 2002 [Page 11] Internet Draft Midcom-unaware Firewall/NAT Traversal Sept 2001=20 =20 8 New Requirements on SIP Client, Signaling Proxy Server and RTP Proxy = =20 Client:=20 =20 (a) Support the proposed SIP PING method to keep open the NAT/FW=20 pinholes in the signaling path. The client also has to transmit=20 periodic RTP packets (in case of mute) to keep the NAT/FW pinholes=20 open in the media path. =20 =20 (b) Support a new tag in the Proxy-require header to indicate to the = Proxy that the client is behind a NAT. This and the PING method are=20 the only extensions required for SIP.=20 =20 (c) The caller UA must start transmitting media after receiving the=20 200 OK from the callee. This is required to update the media=20 address/port bindings in the RTP Proxy. For similar reasons, the=20 callee must start transmitting media after sending the 200 OK. =20 =20 SIP Proxy Server:=20 =20 (a) Support the SIP PING method.=20 =20 (b) Be able to interpret the new tag in the Proxy-require header=20 indicating presence of NAT. Maintain the association between the=20 actual address/port of the UA and the NAT external address /port bind to properly route the requests and responses.=20 =20 (c) Request for and receive media ports and addresses from the RTP=20 Proxy through a control interface. Perform required replacement of=20 SDP parameters in SIP messages with address/port provided by the RTP = Proxy. =20 =20 RTP Proxy:=20 =20 (a) Support detection of source address/port of the media packets=20 and update its routing table.=20 =20 (b) Interact with Signaling Proxy server to allocate address/port=20 binds for the media. =20 =20 =20 9 Consistency with the Midcom Framework=20 =20 The above solution is very much consistent with the Midcom framework = [5] and can almost be seen as a precursor to Midcom. Nothing=20 prevents us from viewing the RTP Proxy as a Middlebox, and then the=20 above-mentioned control protocol (with suitable extensions, if=20 =20 Sen Expires March 2002 [Page 12] Internet Draft Midcom-unaware Firewall/NAT Traversal Sept 2001 =20 required) between the Signaling and RTP Proxies becomes the Midcom=20 protocol. Since the RTP Proxy is only acting as terminating points=20 for application sessions at the transport layer and below, the same=20 concept can be generalized to other similar applications. =20 =20 =20 10 Security Considerations =20 =20 Denial of Service: The RTP Proxy does not open ports unnecessarily=20 to allow media packets, i.e., ports remain closed unless=20 specifically opened by the Proxy. This limits the possibility of DoS = attacks. Also, since all media (except intra-Enterprise traffic=20 which does not traverse the public Internet) flows through the=20 Proxy, it is able to identify denial of service attacks by=20 monitoring the actual bandwidth usage in the ports against the=20 expected bandwidth utilization. =20 =20 IP Address Spoofing: All SIP signaling to and from the Enterprise=20 must traverse a trusted SIP Proxy and will be authenticated. Only=20 this Signaling Proxy is authorized to request opening of media ports = at the RTP Proxy. The external IP address/port bind of the=20 Enterprise NAT is NOT carried within any of the SIP messages towards = the remote end. All these restrictions limit the possibility of=20 address spoofing to a great extent.=20 =20 =20 11 References =20 [1] "IP Network Address Translator (NAT) Terminology and=20 Considerations", RFC 2663=20 [2] "NAT Friendly SIP", draft-rosenberg-sip-entfw-02.txt=20 [3] "Protocol Complications with the IP Network Address Translator", = draft-ietf-nat-protocol-complications-06.txt=20 [4] "SIP: Session Initiation Protocol", draft-ietf-sip-rfc2543bis- 04.txt =20 [5] "Midcom Architecture & Framework", Internet draft, draft-ietf- midcom-framework-03.txt (work in progress)=20 =20 =20 =20 12 Acknowledgments=20 =20 The authors would like to thank Mark Watson, Cedric Aoun and Mary=20 Barnes for their useful comments and suggestions related to this=20 draft. =20 =20 =20 13 Author's Address=20 =20 =20 Sen Expires March 2002 [Page 13] Internet Draft Midcom-unaware Firewall/NAT Traversal Sept 2001=20 =20 Sanjoy Sen=20 Nortel Networks=20 sanjoy@nortelnetworks.com=20 =20 Patrick Sollee=20 Nortel Networks=20 pats@nortelnetworks.com=20 =20 Sean March=20 Nortel Networks=20 march@nortelnetworks.com=20 =20 14 Intellectual Property Statement=20 =20 Nortel may have patent rights for technologies described in this=20 draft. =20 =20 15 Full Copyright Statement =20 Copyright (C) The Internet Society (2000). All Rights Reserved.=20 =20 This document and translations of it may be copied and furnished to=20 others, and derivative works that comment on or otherwise explain it = or assist in its implementation may be prepared, copied, published=20 and distributed, in whole or in part, without restriction of any=20 kind, provided that the above copyright notice and this paragraph=20 are included on all such copies and derivative works. However, this = document itself may not be modified in any way, such as by removing=20 the copyright notice or references to the Internet Society or other=20 Internet organizations, except as needed for the purpose of=20 developing Internet standards in which case the procedures for=20 copyrights defined in the Internet Standards process must be=20 followed, or as required to translate it into languages other than=20 English. The limited permissions granted above are perpetual and=20 will not be revoked by the Internet Society or its successors or=20 assigns. This document and the information contained=20 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND=20 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES,=20 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT=20 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR=20 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A=20 PARTICULAR PURPOSE."=20 =20 =20 =20 Sen Expires March 2002 [Page = 14]=0D=0C ------_=_NextPart_000_01C14D2B.88AA28F0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Oct 5 01:47:39 2001 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 BAA03733 for ; Fri, 5 Oct 2001 01:47: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 BAA24715; Fri, 5 Oct 2001 01:45: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 BAA24689 for ; Fri, 5 Oct 2001 01:45:43 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03644 for ; Fri, 5 Oct 2001 01:45:41 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f955g18P027606; Fri, 5 Oct 2001 01:42:01 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <4A0SN1J1>; Fri, 5 Oct 2001 01:43:05 -0400 Message-ID: From: Jonathan Rosenberg To: "'christopher.a.martin@wcom.com'" , Jonathan Rosenberg , "'Ram Dantu'" , "'Abdallah Rayhan'" , "'Melinda Shore'" , midcom@ietf.org Subject: RE: [midcom] pre-midcom work item Date: Fri, 5 Oct 2001 01:43:03 -0400 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 > -----Original Message----- > From: Christopher A. Martin [mailto:christopher.a.martin@wcom.com] > Sent: Wednesday, October 03, 2001 5:16 PM > To: 'Jonathan Rosenberg'; 'Ram Dantu'; 'Abdallah Rayhan'; 'Melinda > Shore'; midcom@ietf.org > Subject: RE: [midcom] pre-midcom work item > > > > They obtain an IP address, but what about a port number? does > > > the client > > > guess what port number that the nat may assign to the > > > transaction? In the > > > case of NAPT(PAT) there is a pool of ports being used > > randomly in most > > > cases. > > > > My apologies for being imprecise. Yes, they obtain the port > > number too. The > > server returns an attribute called MAPPED-ADDRESS which > > includes a port and > > IP address. Our assumption was that NAPT was the norm. > > Excellent. Does the attribute also facilitate the RTCP port as well? You would need to use a separate socket, and thus obtain a separate MAPPED-ADDRESS, for RTCP. This has the unfortunate side effect that the RTP and RTCP ports will no longer be adjacent. However, at the last avt meeting it was agreed that this was OK so long as the signaling indicated that RTCP was a different port. There is now an mmmusic work item to define an SDP extension for RTCP IP addresses and ports, draft-ietf-mmusic-sdp4nat. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Oct 5 02:00:12 2001 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 CAA04700 for ; Fri, 5 Oct 2001 02:00: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 BAA24806; Fri, 5 Oct 2001 01:49: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 BAA24778 for ; Fri, 5 Oct 2001 01:49:12 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03838 for ; Fri, 5 Oct 2001 01:49:11 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f955lb8P027621; Fri, 5 Oct 2001 01:47:37 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <4A0SN1JJ>; Fri, 5 Oct 2001 01:48:41 -0400 Message-ID: From: Jonathan Rosenberg To: "'Mark Pietras'" , Jonathan Rosenberg , midcom@ietf.org Subject: RE: [midcom] pre-midcom work item Date: Fri, 5 Oct 2001 01:48:40 -0400 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 > -----Original Message----- > From: Mark Pietras [mailto:mpietras@aravox.com] > Sent: Thursday, October 04, 2001 11:20 AM > To: Jonathan Rosenberg; midcom@ietf.org > Subject: RE: [midcom] pre-midcom work item > > > Jonathan, > > More of a question about the _solution_ than the particulars of STUN: > > Have you found a solution to the problem of "misguided" > media? That is, > when two clients are behind the same NAT and there's no > call-control/routing > element with them in that same "realm?!", both will be forced > to assume that > the other is on the "outside" the NAT. Both the signaling > and the media > will be sent "outside" just to be routed right back. > Signaling might not be > a big deal, but media might be (from a latency or more interestingly a > NAT-loading perspective). There is a solution to this that I have been discussing with some folks (there was actually a thread on the sip list about it), but its not documented yet in any I-D. The basic idea is that the INVITE from the caller would contain TWO SDP media streams. One lists the private address, and the other, the public address obtained through STUN. There is some kind of FID style tagging that lets the other side know that it should only use one of them, and the one with the internal address is the higher priority. When the called party gets this, it tries both streams, and uses the private address if that succeeds, otherwise the public if it succeeds. The result is that you get direct communication if both are behind the same NAT, and use the NAT as a relay otherwise. Again, this is something commonly done in proprietary protocols, particularly some network games. Seems like a really good idea for VoIP. It needs some additional SDP work in order to function. Also, please note that this is quite orthogonal to stun. Stun is needed for this approach to work, but they are independent. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Oct 5 02:11:24 2001 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 CAA13040 for ; Fri, 5 Oct 2001 02:11: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 CAA25402; Fri, 5 Oct 2001 02:09: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 CAA25369 for ; Fri, 5 Oct 2001 02:09:44 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12934 for ; Fri, 5 Oct 2001 02:09:42 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9567x8P027676; Fri, 5 Oct 2001 02:08:00 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <4A0SN1J0>; Fri, 5 Oct 2001 02:09:03 -0400 Message-ID: From: Jonathan Rosenberg To: "'Li Li'" , Jonathan Rosenberg , "'huitema@microsoft.com'" , midcom@ietf.org Subject: RE: [midcom] pre-midcom work item Date: Fri, 5 Oct 2001 02:09:02 -0400 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 -----Original Message----- From: Li Li [mailto:Li.Li@SS8.com] Sent: Thursday, October 04, 2001 3:09 PM To: 'Jonathan Rosenberg'; 'huitema@microsoft.com'; midcom@ietf.org Subject: RE: [midcom] pre-midcom work item >A few quick questions about the stun draft: >(1) in section 9.1, close to the bottom of p.10, >"If a response is received, the client knows that it has open access to the >Internet (or, at least, its behind a firewall that behaves like a >port restricted NAT, but without the translation)." >Why it is like a port restricted NAT? To me somehow this behaves more like >a full cone NAT without translation? Yes, you're right. This is an error. >(2) I can see STU works well with the full-cone nat. But how about >restricted cone or restricted port? It may help if these two cases can >be explained in the draft. I remember saw in previous emails that the restricted >cone and port restricted cone nats are all supported? The public IP address/port >learned from the server can only be used by the server, not the other party in the >call that wants to send you audio? How can the client get the mapped address >that can be used by the sender? We were trying to focus on just the protocol, and not its usage for SIP, so many of these details, which are very important, were not in here. In the case of restricted cone nats, it will work just fine if the peer sends and receives from the same IP address. This is not always true (i'll explain in a moment how to handle that case when its not). Assuming it is, lets say its A (behind a port restricted NAT) calling B. A uses stun, and gets an address. It puts that into the INVITE SDP. The 200 OK comes back. That contains the address that B will receive on. A takes that address, and "primes" its nat by sending a packet to that address. The nat will now allow packets to A from that address. Since I assumed that the address that B receives on is also the one it sends from, packets from B will flow through the nat to A. Now, it won't always be true that B sends from the same IP it receives on. The way to handle that is symmetric RTP. Symmetric RTP is nothing more than RTP where one side sends packets back to the source address/port where it got packets from. Handling this in SDP is documented in draft-ietf-mmusic-comedia, which describes generally connection oriented media in SDP. By definition, this meets the constraints in most cases. Port restricted are more complicated (as is symmetric nat), and it requires a common media intermediary on the public Internet. Thats not addressed in stun, although we debated putting it in (security was a bit more complex). >(3) The changed address is returned to the client. How client uses it? Its used in the tests for full cone. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Oct 5 07:11:13 2001 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 HAA18493 for ; Fri, 5 Oct 2001 07:11: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 HAA03826; Fri, 5 Oct 2001 07:08: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 HAA03795 for ; Fri, 5 Oct 2001 07:08:37 -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 HAA18340; Fri, 5 Oct 2001 07:08:36 -0400 (EDT) Message-Id: <200110051108.HAA18340@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: Fri, 05 Oct 2001 07:08:35 -0400 Subject: [midcom] I-D ACTION:draft-ietf-midcom-framework-04.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 : Middlebox Communication Architecture and framework Author(s) : P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan Filename : draft-ietf-midcom-framework-04.txt Pages : 36 Date : 04-Oct-01 There are a variety of intermediate devices in the Internet today that require application intelligence for their operation. Datagrams pertaining to real-time streaming applications such as SIP and H.323 and peer-to-peer applications such as Napster and NetMeeting cannot be identified by merely examining packet headers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-framework-04.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-framework-04.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-framework-04.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: <20011004143228.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-framework-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-framework-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011004143228.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Oct 5 09:14:40 2001 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 JAA21322 for ; Fri, 5 Oct 2001 09:14: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 JAA07295; Fri, 5 Oct 2001 09:12:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07264 for ; Fri, 5 Oct 2001 09:12: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 JAA21250 for ; Fri, 5 Oct 2001 09:12:48 -0400 (EDT) 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 f95DCNg05133 for ; Fri, 5 Oct 2001 06:12:23 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-155.cisco.com [10.82.192.155]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAQ04914; Fri, 5 Oct 2001 06:12:04 -0700 (PDT) Message-Id: <5.1.0.14.0.20011005090920.00a6b110@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 05 Oct 2001 09:14:24 -0400 To: midcom From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] New deliverable approved 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've gotten the go-ahead on the new deliverable. The most recent description that I've seen is this: Ubiquitous deployment of midcom in all middleboxes could take many years. 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. We need to move quickly on choosing a base document and moving it forward. Please take the charter text to heart, particularly " [ ... ] allows clients to indirectly obtain address bindings from midcom-unaware middleboxes." Note that it does not say that we'll be using tunneling. Also, let's try to keep moving the other deliverables towards closure. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Oct 5 09:17:52 2001 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 JAA21382 for ; Fri, 5 Oct 2001 09:17: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 JAA07203; Fri, 5 Oct 2001 09:09: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 JAA07174 for ; Fri, 5 Oct 2001 09:09:47 -0400 (EDT) Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21196 for ; Fri, 5 Oct 2001 09:09:44 -0400 (EDT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.wcom.com (PMDF V5.2-32 #42257) with ESMTP id <0GKQ009KCHVFLC@firewall.wcom.com> for midcom@ietf.org; Fri, 5 Oct 2001 13:09:15 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GKQ00001HV8J0@dgismtp02.wcomnet.com> for midcom@ietf.org; Fri, 05 Oct 2001 13:09:15 +0000 (GMT) Received: from rccc6131 ([166.35.224.112]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GKQ00JDWHV4UY@dgismtp02.wcomnet.com> for midcom@ietf.org; Fri, 05 Oct 2001 13:09:04 +0000 (GMT) Date: Fri, 05 Oct 2001 07:55:29 -0500 From: "Christopher A. Martin" Subject: RE: [midcom] pre-midcom work item In-reply-to: To: midcom@ietf.org Reply-to: christopher.a.martin@wcom.com Message-id: <000201c14d9e$e76964a0$70e023a6@rccc6131.mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 Inline > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Jonathan Rosenberg > Sent: Friday, October 05, 2001 12:49 AM > To: 'Mark Pietras'; Jonathan Rosenberg; midcom@ietf.org > Subject: RE: [midcom] pre-midcom work item > > > > > > > > -----Original Message----- > > From: Mark Pietras [mailto:mpietras@aravox.com] > > Sent: Thursday, October 04, 2001 11:20 AM > > To: Jonathan Rosenberg; midcom@ietf.org > > Subject: RE: [midcom] pre-midcom work item > > > > > > Jonathan, > > > > More of a question about the _solution_ than the > particulars of STUN: > > > > Have you found a solution to the problem of "misguided" > > media? That is, > > when two clients are behind the same NAT and there's no > > call-control/routing > > element with them in that same "realm?!", both will be forced > > to assume that > > the other is on the "outside" the NAT. Both the signaling > > and the media > > will be sent "outside" just to be routed right back. > > Signaling might not be > > a big deal, but media might be (from a latency or more > interestingly a > > NAT-loading perspective). > > There is a solution to this that I have been discussing with > some folks > (there was actually a thread on the sip list about it), but its not > documented yet in any I-D. The basic idea is that the INVITE > from the caller > would contain TWO SDP media streams. One lists the private > address, and the > other, the public address obtained through STUN. There is > some kind of FID > style tagging that lets the other side know that it should > only use one of > them, and the one with the internal address is the higher > priority. When the > called party gets this, it tries both streams, and uses the > private address > if that succeeds, otherwise the public if it succeeds. The > result is that > you get direct communication if both are behind the same NAT, > and use the > NAT as a relay otherwise. > > Again, this is something commonly done in proprietary protocols, > particularly some network games. Seems like a really good > idea for VoIP. It > needs some additional SDP work in order to function. I can see the idea of including the internal address in an external packet (in the clear) as being considered as a possible security risk by the IT community. This approach should be considered very carefully, since VoIP and gaming are two completely different animals. When addressing MMoIP as a whole one needs to remember that issues of privacy (including internal topology) are key concerns with many individuals/organizations. Of course many individuals immediately bring up the fact that everyone knows about the RFC1918 address ranges, so whats the secret? This applies more to the use of NAT when it is used to hide legal address space as many organizations do as an additional form of security/peering. When divulging private address space within a packet that has been NAT'd can also be useful in mapping a network, knowing that many network designers, for instance, place routers at the top or bottom ranges of a network (i.e., 10.1.1.1 or 10.1.1.254) and server farms within contiguous ranges, one could easily use information gleaned, from what might appear as an apparent attempt to contact internal users to map the network to identify possible targets. I am not trying to shoot down the idea, just want to make aware some of the implications with an approach such as this. > > Also, please note that this is quite orthogonal to stun. Stun > is needed for > this approach to work, but they are independent. > > -Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Oct 5 12:35:11 2001 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 MAA25893 for ; Fri, 5 Oct 2001 12:35: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 MAA15156; Fri, 5 Oct 2001 12:32: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 MAA15126 for ; Fri, 5 Oct 2001 12:32:18 -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 MAA25829 for ; Fri, 5 Oct 2001 12:32:15 -0400 (EDT) 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 f95GVnk05501 for ; Fri, 5 Oct 2001 09:31:49 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-155.cisco.com [10.82.192.155]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAQ09249; Fri, 5 Oct 2001 09:31:31 -0700 (PDT) Message-Id: <5.1.0.14.0.20011005123303.00a5d250@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 05 Oct 2001 12:33:48 -0400 To: midcom From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] R60 accepted 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 Requirement R60 is accepted with the replacement text: "The protocol MUST allow the midcom agent to extend the lifetime of an existing ruleset that otherwise would be deleted by the middlebox." Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Oct 5 14:21:34 2001 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 OAA27993 for ; Fri, 5 Oct 2001 14:21: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 OAA18509; Fri, 5 Oct 2001 14:19: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 OAA18478 for ; Fri, 5 Oct 2001 14:19:41 -0400 (EDT) Received: from avgw.vxserver.com (mail.ridgeway-sys.com [194.128.67.178]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27979 for ; Fri, 5 Oct 2001 14:19:34 -0400 (EDT) Received: from ridgeway.ridgeway-sys.com ([10.1.1.1]) by avgw.vxserver.com (NAVGW 2.5.1.2) with SMTP id M2001100519165812923 ; Fri, 05 Oct 2001 19:16:58 +0100 Received: by ThisAddressDoesNotExist with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Oct 2001 19:18:52 +0100 Message-ID: <00533D13955AD411AF3800A0C9B42639E91F98@ThisAddressDoesNotExist> From: Steve Davies To: Melinda Shore Cc: midcom Subject: RE: [midcom] New deliverable approved Date: Fri, 5 Oct 2001 19:18:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14DCA.29EBDB20" 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_01C14DCA.29EBDB20 Content-Type: text/plain; charset="ISO-8859-1" Melinda, Interesting. I'd liked to put forward a candidate method that meet these needs. We've been working on the 'flipped' or 'reversed' version on our original method (published last March in draft_davies_fw_nat_traversal_00.txt) that is very midcom like and does just this. This announcement has caught us somewhat on the hop, but I hope to publish a new I-D by the middle of next week. I'll email the group as soon as it is available. Steve Davies -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: 05 October 2001 14:14 To: midcom Subject: [midcom] New deliverable approved We've gotten the go-ahead on the new deliverable. The most recent description that I've seen is this: Ubiquitous deployment of midcom in all middleboxes could take many years. 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. We need to move quickly on choosing a base document and moving it forward. Please take the charter text to heart, particularly " [ ... ] allows clients to indirectly obtain address bindings from midcom-unaware middleboxes." Note that it does not say that we'll be using tunneling. Also, let's try to keep moving the other deliverables towards closure. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C14DCA.29EBDB20 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] New deliverable approved

Melinda,

Interesting. I'd liked to put forward a candidate = method that meet these needs. We've been working on the 'flipped' or = 'reversed' version on our original method (published last March in = draft_davies_fw_nat_traversal_00.txt) that is very midcom like and does = just this. This announcement has caught us somewhat on the hop, but I = hope to publish a new I-D by the middle of next week.

I'll email the group as soon as it is = available.

Steve Davies

-----Original Message-----
From: Melinda Shore [mailto:mshore@cisco.com]
Sent: 05 October 2001 14:14
To: midcom
Subject: [midcom] New deliverable approved


We've gotten the go-ahead on the new = deliverable.  The
most recent description that I've seen is = this:

Ubiquitous deployment of midcom in all middleboxes = could take many years.
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.

We need to move quickly on choosing a base document = and moving
it forward.  Please take the charter text to = heart, particularly
" [ ... ] allows clients to indirectly obtain = address bindings from
midcom-unaware middleboxes."  Note that it = does not say that we'll
be using tunneling.

Also, let's try to keep moving the other deliverables = towards
closure. 

Melinda


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

------_=_NextPart_001_01C14DCA.29EBDB20-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Oct 5 15:06:14 2001 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 PAA29099 for ; Fri, 5 Oct 2001 15: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 PAA20091; Fri, 5 Oct 2001 15:04: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 PAA20063 for ; Fri, 5 Oct 2001 15:04:34 -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 PAA28992 for ; Fri, 5 Oct 2001 15:04:31 -0400 (EDT) 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 f95J42g24990; Fri, 5 Oct 2001 12:04:02 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-155.cisco.com [10.82.192.155]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAT02126; Fri, 5 Oct 2001 12:03:41 -0700 (PDT) Message-Id: <5.1.0.14.0.20011005150356.00a64820@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 05 Oct 2001 15:05:56 -0400 To: Steve Davies From: Melinda Shore Subject: RE: [midcom] New deliverable approved Cc: midcom In-Reply-To: <00533D13955AD411AF3800A0C9B42639E91F98@ThisAddressDoesNotE xist> 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:18 PM 10/5/01 +0100, Steve Davies wrote: >This announcement has caught us somewhat on the hop, but I hope to publish a new I-D by the middle of next week. It would be very helpful for those who are planning on submitting something to get a description to the mailing list soonish so that we can start sorting through basic approaches. Also, it's my understanding the Ridgeway has some IPR claims on the technology you describe in your draft. If my understanding is correct we need to get that out in the open at the start of discussions. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sat Oct 6 14:35:55 2001 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 OAA28507 for ; Sat, 6 Oct 2001 14:35: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 OAA27771; Sat, 6 Oct 2001 14:31: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 OAA27746 for ; Sat, 6 Oct 2001 14:31:49 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28495 for ; Sat, 6 Oct 2001 14:31:46 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f96IUD8P011128; Sat, 6 Oct 2001 14:30:14 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <4KFCAKYA>; Sat, 6 Oct 2001 14:31:17 -0400 Message-ID: From: Jonathan Rosenberg To: "'christopher.a.martin@wcom.com'" , midcom@ietf.org Subject: RE: [midcom] pre-midcom work item Date: Sat, 6 Oct 2001 14:31:17 -0400 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 > -----Original Message----- > From: Christopher A. Martin [mailto:christopher.a.martin@wcom.com] > Sent: Friday, October 05, 2001 8:55 AM > To: midcom@ietf.org > Subject: RE: [midcom] pre-midcom work item > > > Again, this is something commonly done in proprietary protocols, > > particularly some network games. Seems like a really good > > idea for VoIP. It > > needs some additional SDP work in order to function. > > I can see the idea of including the internal address in an > external packet > (in the clear) as being considered as a possible security > risk by the IT > community. This approach should be considered very carefully, > since VoIP and > gaming are two completely different animals. If you are concerned about revealing internal IP addresses outside, then that would be an issue independent if you were using games or VoIP, right? > When addressing > MMoIP as a > whole one needs to remember that issues of privacy (including internal > topology) are key concerns with many individuals/organizations. I don't think its really different for gaming, if you think about it. But in any case, its irrelevant. If you are using nat to hide internal addresses, then yes, using the approach of having these two media streams will reveal your internal address to the outside. One can always get around that problem by starting with the public address, and if the call terminates on an another internal user (known through authenticated identities, perhaps), then you do a re-INVITE to update to the private address. I do want to emphasize that all of this has nothing to do with stun; we are discussing an SDP extension which has not yet even been written. Let us first focus on the main problem at hand. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sun Oct 7 10:03:33 2001 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 KAA23173 for ; Sun, 7 Oct 2001 10:03: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 KAA26639; Sun, 7 Oct 2001 10:00: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 KAA26610 for ; Sun, 7 Oct 2001 10:00:55 -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 KAA23145 for ; Sun, 7 Oct 2001 10:00:52 -0400 (EDT) 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 f97E0Qk27171 for ; Sun, 7 Oct 2001 07:00:26 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-60.cisco.com [10.82.192.60]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAB00916; Sun, 7 Oct 2001 07:00:05 -0700 (PDT) Message-Id: <5.1.0.14.0.20011007095738.00a625e0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 07 Oct 2001 10:02:28 -0400 To: midcom From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Document proposals for new work item 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 value in the new pre-midcom work item lies completely in getting it done quickly, so I'd like to propose that any documents that you'd like to promote as the basis for the deliverable be available to the working group by next Friday. That's very short notice and I understand that as a result the document may be in very rough shape, but we need something that lays out the basic proposal. As always, please format as an internet draft and submit to internet-drafts@ietf.org. If it hasn't been posted to ietf-announce by Friday send a pointer to the document in another location to the midcom mailing list. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sun Oct 7 14:36:40 2001 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 OAA24964 for ; Sun, 7 Oct 2001 14:36: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 OAA02377; Sun, 7 Oct 2001 14:34: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 OAA02348 for ; Sun, 7 Oct 2001 14:34:03 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24956 for ; Sun, 7 Oct 2001 14:34:00 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f97IWK8P013754; Sun, 7 Oct 2001 14:32:20 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <4KFCALQ6>; Sun, 7 Oct 2001 14:33:24 -0400 Message-ID: From: Jonathan Rosenberg To: "'Sanjoy Sen'" , midcom@ietf.org Cc: Patrick Sollee , Sean March Subject: RE: [midcom] Submission of a new Internet draft Date: Sun, 7 Oct 2001 14:33:20 -0400 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 A very nice draft. Some comments:. First off, please note that your draft requires the end systems to support symmetric RTP. You don't explicitly state that, but since you have the clients "priming" the nats by sending RTP packets to the RTP proxy, with the media going back to the source address. That is not normal RTP behavior, but is what we call symmetric RTP. You can tell its symmetric RTP since, in your proposal, the IP/port in the SDP sent from the client is actually never used by the RTP proxy to figure out where to send media. The mechanism you describe in this draft is largely the same as what we proposed in draft-rosenberg-sip-entfw-01.txt (NOT the current -02 version, which is much different), which had the proxies performing the rewrites of the SDP as you describe. As we began to work through the details of this solution, it became terribly complex. THe main reason for that is that you have to assume multiple domains, each of which has its own proxy, and that you can have cases where the user is not natted on one side, the other side, or both. Add to that the need to determine whether one side, the other side, or both support symmetric RTP. As an example of what I mean, you show an RTP proxy only on the originating domain. What if the originating domain doesn't support this capability? What if the originating domain doesn't use nats at all, in fact? In that case, the terminating proxy also needs to do this (rewrite SDP and act as a b2bua) when its users are natted. But, what if the originating domain IS natted? Does that mean there are TWO RTP proxies on each call setup path? It gets really complicated when you add, as a goal, direct media communications whenever possible. In your proposal, media always flows through this intermediary. Since the location of that device is generally going to be physically uncorrelated with the location of the endpoints, media latency can suffer a LOT. As such, you really only want that thing in there when its needed. If you want to ensure direct media whenever possible, then you get into further complications of making decisions based on which type of nats there are. We came up with on the order of 100 different cases that needed to be considered (something like 7 different yes/no orthogonal variables). The approach you propose also requires that there are call stateful B2BUAs in each call path, which has significant impacts on performance and fault tolerance in particular. The cost to the VoIP provider is VERY high from this solution, because of all the additional rtp traffic that comes in, and back out. Our conclusion was that the whole mess gets a lot easier when you push the intelligence to the end systems. Rather than the proxy mucking with SDP, being call stateful, and so on, the client simply discovers its public IP address, and the type of nat, and uses that information. Once the client knows what its situation is, it can involve a RTP media proxy only in the case where its behing a symmetric NAT. As such, our approach is truly a client discovery mechanism, which is EXACTLY how it would work if midcom were deployed. If midcom were in place, the client would talk to its enterprise/residential NAT, obtain some addresses, and put those in SDP. No B2BUAs. No proxies mucking with SDP. None of that. In our case, the same thing happens. However, since the client can't speak midcom to the nat, it speaks stun THROUGH the nat, to a server on the other side. The result is the same, though - it gets an IP address, and puts those in SDP. No B2BUAs. No proxies mucking with SDP. The solution retains all of the scalability and fault tolerance characteristics of SIP, and also ensures that direct media takes place whenever possible. This saves the VoIP provider money and improves the voice quality perceived by the endpoints. STUn also allows other applications to work, just as midcom will. As an important note on our proposal, it does not cover the symmetric NAT case at the moment. We did originally have that in a version of the doc that the co-authors were passing around. It requires stronger security than the pure reflector case, since you have to have an RTP proxy of sorts, with the stun request asking for a binding on that RTP proxy. The use of resources like that requires better security. There were also more complex failure and load balancing considerations. As such, its easily added back in, or even better we think, documented separately. However, the idea is the same - the client sends a request to the server, and the server tells it the IP address to use. Also, I'd like to point out Melinda's statement: What I'm after here is something that's more-or-less consistent with the midcom notion that the external address is "learned" by the endpoint and then used for signaling purposes. No such thing happens in your proposal. The endpoints are not learning their addresses. THis is, however, exactly how stun works. A few minor comments: 1. You write: 4. The destination port of the requests at the Signaling Proxy server is the same as the source port of the corresponding responses. That is not true for rfc2543, since the responses are sent to the source IP, but to the port written in the Via header, or 5060 if not present. This will not work through NAPT. This has been fixed with our SIP extensions for an rport parameter: http://www.ietf.org/internet-drafts/draft-ietf-sip-nat-00.txt which is a SIP wg work item. 2. You write: Proxy/Register (Signaling server). The SIP REGISTER message contains an extension tag carried in the Proxy-Require header, indicating to the Proxy that the client is behind a NAT (Note: the client or the Proxy does not care about the type of NAT, as the same solution applies to all types). This packet is NAT-ed by the Enterprise NAT with a new source IP address and port. If the Proxy supports the extension tag, it creates an association between the IP address and port from which the packet arrived and the actual address of the user. The response to the Registration message is sent to this IP address and port (not to the Contact address in the REGISTER). This is also covered by the above draft, using the Translate header. Note that implicit translation requests do not work, because registrations are not always for the purpose of binding an address-of-record to the host sending the registration. Thanks, Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com -----Original Message----- From: Sanjoy Sen [mailto:sanjoy@nortelnetworks.com] Sent: Thursday, October 04, 2001 7:23 PM To: midcom@ietf.org Cc: Patrick Sollee; Sean March Subject: [midcom] Submission of a new Internet draft Folks, We've submitted an ID called "Midcom-unaware NAT/Firewall Traversal" describing an alternative solution framework (that is implementable today) to solve the problem of traversing deployed NAT/FW's. Two key components of this solution working in tandem are a SIP Proxy & an RTP Proxy. The solution needs interaction between the Proxies, but does not need the clients know about the NAT binds or types and is applicable to all traditional types of NAT's/Firewalls. Attached is a copy of the submitted draft for your reading until it appears in the IETF website. Best Regards, Sanjoy Sen ========= Interactive Multimedia Server Nortel Networks Ph: 972-685-8274, Fax: 972-685-3813 Mobile: 972-571-2062 _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Oct 8 07:09:31 2001 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 HAA17514 for ; Mon, 8 Oct 2001 07:09: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 HAA29219; Mon, 8 Oct 2001 07:07: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 HAA29188 for ; Mon, 8 Oct 2001 07:07:05 -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 HAA17392; Mon, 8 Oct 2001 07:07:03 -0400 (EDT) Message-Id: <200110081107.HAA17392@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 Oct 2001 07:07:03 -0400 Subject: [midcom] I-D ACTION:draft-sen-midcom-fw-nat-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 : Midcom-unaware NAT/Firewall Traversal Author(s) : S. Sen, P. Sollee, S. March Filename : draft-sen-midcom-fw-nat-00.txt Pages : 14 Date : 05-Oct-01 Bundled session applications such as FTP, H.323, SIP and RTSP, which use a signaling/control connection to establish a data/media flow, are usually broken, en-route, by Middleboxes such as NAT. Midcom proposes to solve this problem by allowing the Middlebox to be controlled through a generalized control interface by an application-aware entity called Midcom Agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sen-midcom-fw-nat-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-sen-midcom-fw-nat-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-sen-midcom-fw-nat-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: <20011005124654.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-sen-midcom-fw-nat-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-sen-midcom-fw-nat-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011005124654.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Oct 8 10:19:36 2001 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 KAA22216 for ; Mon, 8 Oct 2001 10:19: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 KAA04757; Mon, 8 Oct 2001 10:12: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 KAA04727 for ; Mon, 8 Oct 2001 10:12: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 KAA22122 for ; Mon, 8 Oct 2001 10:12:20 -0400 (EDT) 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 f98EBvg03515 for ; Mon, 8 Oct 2001 07:11:57 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-283.cisco.com [10.21.65.27]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAG04593; Mon, 8 Oct 2001 07:11:33 -0700 (PDT) Message-Id: <5.1.0.14.0.20011008100418.00a3c6a0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 08 Oct 2001 10:13:56 -0400 To: midcom From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] New requirements bullets 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 R20: As Pin-Holes may be shared across Middlebox functions, it MUST be possible for a Pinhole-Descriptor to be created by one function, and terminated by a different one. Proposal: delete. We're covered by other requirements bullets. R33: The relationship between a Midcom Agent and a given Middlebox may be pre-configured through a manual configuration process or may be established dynamically through a registration process. In either case, depending upon the policy applied to the Middlebox, the Middlebox MUST appropriately authenticate the identity and credentials of the Midcom Agent seeking to make use of its services prior to servicing any other requests from the Midcom Agent. Proposal: delete anything to do with provisioning (the first part) and change the second part so that 1) the requirement is on the protocol and not the middlebox, 2) the requirement is the capability to do bidirectional authentication. The choice to actually do authentication is a question of site-local security policy. R65: Individual message authentication MUST be used in addition to host authentication. Further message confidentiality MAY be administered by employing techniques appropriate to Midcom messages. Simple Source-address based security is the least form of security and MAY be permitted only to the most trusted hosts. Proposal: Again, we can't tell network administrators how to run their networks. The protocol must support message authentication and message confidentiality. That's it. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Oct 8 10:20:20 2001 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 KAA22235 for ; Mon, 8 Oct 2001 10:20: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 KAA04949; Mon, 8 Oct 2001 10:18: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 KAA04913 for ; Mon, 8 Oct 2001 10:18:15 -0400 (EDT) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22191 for ; Mon, 8 Oct 2001 10:18:13 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f98EHDS13437 for ; Mon, 8 Oct 2001 10:17:13 -0400 (EDT) Received: from zsc4c000.us.nortel.com by smtprch2.nortel.com; Mon, 8 Oct 2001 09:11:10 -0500 Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Oct 2001 07:17:24 -0700 Message-ID: From: "Reinaldo Penno" To: "'Melinda Shore'" , "'midcom'" Subject: RE: [midcom] New requirements bullets Date: Mon, 8 Oct 2001 07:17:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15003.F2241720" X-Orig: 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_01C15003.F2241720 Content-Type: text/plain; charset="iso-8859-1" agreed with all proposals. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Monday, October 08, 2001 7:14 AM > To: midcom > Subject: [midcom] New requirements bullets > > > R20: As Pin-Holes may be shared across Middlebox functions, it MUST > be possible for a Pinhole-Descriptor to be created by one > function, and terminated by a different one. > > Proposal: delete. We're covered by other requirements bullets. > > R33: The relationship between a Midcom Agent and a given Middlebox > may be pre-configured through a manual configuration > process or > may be established dynamically through a registration process. > In either case, depending upon the policy applied to the > Middlebox, the Middlebox MUST appropriately authenticate the > identity and credentials of the Midcom Agent seeking > to make use > of its services prior to servicing any other requests from the > Midcom Agent. > > Proposal: delete anything to do with provisioning (the first part) and > change the second part so that 1) the requirement is on the protocol > and not the middlebox, 2) the requirement is the capability to do > bidirectional authentication. The choice to actually do > authentication > is a question of site-local security policy. > > R65: Individual message authentication MUST be used in addition to > host authentication. Further message confidentiality MAY be > administered by employing techniques appropriate to Midcom > messages. Simple Source-address based security is the least > form of security and MAY be permitted only to the most trusted > hosts. > > Proposal: Again, we can't tell network administrators how to run their > networks. The protocol must support message authentication > and message > confidentiality. That's it. > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C15003.F2241720 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] New requirements bullets

agreed with all proposals.

> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Monday, October 08, 2001 7:14 AM
> To: midcom
> Subject: [midcom] New requirements = bullets
>
>
>  R20: As Pin-Holes may be shared across = Middlebox functions, it MUST
>         = be possible for a Pinhole-Descriptor to be created by one
>         = function, and terminated by a different one.
>
> Proposal: delete.  We're covered by other = requirements bullets.
>
>  R33: The relationship between a Midcom = Agent and a given Middlebox
>         = may be pre-configured through a manual configuration
> process or
>         = may be established dynamically through a registration process.
>         = In either case, depending upon the policy applied to the
>         = Middlebox, the Middlebox MUST appropriately authenticate the
>         = identity and credentials of the Midcom Agent seeking
> to make use
>         = of its services prior to servicing any other requests from the
>         = Midcom Agent.
>
> Proposal: delete anything to do with = provisioning (the first part) and
> change the second part so that 1) the = requirement is on the protocol
> and not the middlebox, 2) the requirement is = the capability to do
> bidirectional authentication.  The choice = to actually do
> authentication
> is a question of site-local security = policy.
>
>  R65: Individual message authentication = MUST be used in addition to
>         = host authentication.  Further message confidentiality MAY = be
>         = administered by employing techniques appropriate to Midcom
>         = messages.  Simple Source-address based security is the = least
>         = form of security and MAY be permitted only to the most trusted
>         = hosts.
>
> Proposal: Again, we can't tell network = administrators how to run their
> networks.  The protocol must support = message authentication
> and message
> confidentiality.  That's it.
>
> Melinda
>
>
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C15003.F2241720-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Oct 8 11:00:44 2001 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 LAA23139 for ; Mon, 8 Oct 2001 11:00: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 KAA05990; Mon, 8 Oct 2001 10:48: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 KAA05906 for ; Mon, 8 Oct 2001 10:48:55 -0400 (EDT) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22860 for ; Mon, 8 Oct 2001 10:48:52 -0400 (EDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f98ElqS22663 for ; Mon, 8 Oct 2001 10:47:52 -0400 (EDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Mon, 8 Oct 2001 09:47:34 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Oct 2001 09:47:51 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E06F1DD@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Mark Pietras'" , Jonathan Rosenberg , midcom Subject: RE: [midcom] pre-midcom work item Date: Mon, 8 Oct 2001 09:47:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15008.2E67A770" 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_01C15008.2E67A770 Content-Type: text/plain; charset="iso-8859-1" Mark, Sorry for jumping in late! But a solution for this is described in our recently submitted draft at http://www.ietf.org/internet-drafts/draft-sen-midcom-fw-nat-00.txt. Basically, if you use an RTP proxy like device under the control of a SIP Proxy, then the SIP Proxy can decide whether or not to force the media to go to the RTP Proxy (i.e., in case of 2 UA's behind the same NAT, the SDP is not changed by the SIP Proxy & the media can bypass the RTP Proxy). Please let me know your comments/feedback. Thanks, Sanjoy > -----Original Message----- > From: Mark Pietras [mailto:mpietras@aravox.com] > Sent: Thursday, October 04, 2001 10:20 AM > To: Jonathan Rosenberg; midcom > Subject: RE: [midcom] pre-midcom work item > > > Jonathan, > > More of a question about the _solution_ than the particulars of STUN: > > Have you found a solution to the problem of "misguided" > media? That is, > when two clients are behind the same NAT and there's no > call-control/routing > element with them in that same "realm?!", both will be forced > to assume that > the other is on the "outside" the NAT. Both the signaling > and the media > will be sent "outside" just to be routed right back. > Signaling might not be > a big deal, but media might be (from a latency or more interestingly a > NAT-loading perspective). > > Mark P. > > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Jonathan Rosenberg > Sent: Monday, October 01, 2001 4:40 PM > To: 'Abdallah Rayhan'; Jonathan Rosenberg; Melinda Shore; > midcom@ietf.org > Subject: RE: [midcom] pre-midcom work item > > > > Folks, > > I've just submitted an I-D to the archives, co-authored with Christian > Huitema and Rohan Mahy, on what this protocol might look > like. Until it > appears in the archives, you can pick it up from: > > http://www.jdrosen.net/papers/draft-rosenberg-midcom-stun-00.txt > > Its just a step above "echo", but it can determine the > presence of nats, > diagnose the type, and help determine binding lifetimes. This > protocol will > suffice to help a SIP enabled voip phone get through a fairly > large fraction > of nats (full cone and restricted cone, which is about 80-90% of nats > depending on who you ask) while still maintaining direct, > end-to-end voice > transport. The protocol is totally independent of sip; a > separate draft (in > sipping) is pending on how to use the stun protocol in a sip client. > > Comments/questions/flames welcome as always. Hopefully this will help > clarify the kind of things the new charter item is aiming at. > > Thanks, > Jonathan R. > > > > -----Original Message----- > > From: Abdallah Rayhan [mailto:ar_rayhan@yahoo.ca] > > Sent: Monday, September 24, 2001 2:21 PM > > To: Jonathan Rosenberg; Melinda Shore; midcom@ietf.org > > Subject: RE: [midcom] pre-midcom work item > > > > > > --- Jonathan Rosenberg wrote: > > > > > > Secondly, this introduces > > > > new architectural constraints that is going to screw > > > > the consensus achieved so far on the architecture draft. > > > > > > How is that? > > > > Before amending the charter we at least need to know > > what and how this would work. Instead we got a charter > > change dictated on us before learning how this > > SIP-happy-NAT is going to influence the current architecture, > > or being discussed and scrutinized by the WG. > > > > > > > > > > > > The deployment argument of IKE/IPSec, IP6, MPLS didnt stop > > > > the WGs from developing those standards. Why should we be > > > > the exception? > > > > > > No one is saying that it should not be deployed. Full steam > > ahead. We > > > need > > > midcom, and that hasn't changed. The fact is that midcom > can't fully > > > solve > > > our problems. > > > > > > Its also worth noting that there are already solutions > > being deployed > > > today > > > that play the role of the proposed addition. Those are all > > > proprietary and > > > not interoperable. Let us not let that continue. > > > > What will happen is another beast will be added to the gang. > > > > _______________________________________________________ > > Do You Yahoo!? > > Get your free @yahoo.ca address at http://mail.yahoo.ca > > > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C15008.2E67A770 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] pre-midcom work item

Mark, Sorry for jumping in late! But a solution for = this is described in our recently submitted draft at http://www.ietf.org/internet-drafts/draft-sen-midcom-f= w-nat-00.txt. Basically, if you use an RTP proxy like device under = the control of a SIP Proxy, then the SIP Proxy can decide whether or = not to force the media to go to the RTP Proxy (i.e., in case of 2 UA's = behind the same NAT, the SDP is not changed by the SIP Proxy & the = media can bypass the RTP Proxy). Please let me know your = comments/feedback.

Thanks,
Sanjoy


> -----Original Message-----
> From: Mark Pietras [mailto:mpietras@aravox.com]
> Sent: Thursday, October 04, 2001 10:20 = AM
> To: Jonathan Rosenberg; midcom
> Subject: RE: [midcom] pre-midcom work = item
>
>
> Jonathan,
>
> More of a question about the _solution_ than = the particulars of STUN:
>
> Have you found a solution to the problem of = "misguided"
> media?  That is,
> when two clients are behind the same NAT and = there's no
> call-control/routing
> element with them in that same = "realm?!", both will be forced
> to assume that
> the other is on the "outside" the = NAT.  Both the signaling
> and the media
> will be sent "outside" just to be = routed right back. 
> Signaling might not be
> a big deal, but media might be (from a latency = or more interestingly a
> NAT-loading perspective).
>
> Mark P.
>
> -----Original Message-----
> From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]O= n Behalf Of
> Jonathan Rosenberg
> Sent: Monday, October 01, 2001 4:40 PM
> To: 'Abdallah Rayhan'; Jonathan Rosenberg; = Melinda Shore;
> midcom@ietf.org
> Subject: RE: [midcom] pre-midcom work = item
>
>
>
> Folks,
>
> I've just submitted an I-D to the archives, = co-authored with Christian
> Huitema and Rohan Mahy, on what this protocol = might look
> like. Until it
> appears in the archives, you can pick it up = from:
>
> http://www.jdrosen.net/papers/draft-rosenberg-midcom-s= tun-00.txt
>
> Its just a step above "echo", but it = can determine the
> presence of nats,
> diagnose the type, and help determine binding = lifetimes. This
> protocol will
> suffice to help a SIP enabled voip phone get = through a fairly
> large fraction
> of nats (full cone and restricted cone, which = is about 80-90% of nats
> depending on who you ask) while still = maintaining direct,
> end-to-end voice
> transport. The protocol is totally independent = of sip; a
> separate draft (in
> sipping) is pending on how to use the stun = protocol in a sip client.
>
> Comments/questions/flames welcome as always. = Hopefully this will help
> clarify the kind of things the new charter item = is aiming at.
>
> Thanks,
> Jonathan R.
>
>
> > -----Original Message-----
> > From: Abdallah Rayhan [mailto:ar_rayhan@yahoo.ca]=
> > Sent: Monday, September 24, 2001 2:21 = PM
> > To: Jonathan Rosenberg; Melinda Shore; = midcom@ietf.org
> > Subject: RE: [midcom] pre-midcom work = item
> >
> >
> > --- Jonathan Rosenberg = <jdrosen@dynamicsoft.com> wrote:
> >
> > > > Secondly, this introduces
> > > > new architectural constraints = that is going to screw
> > > > the consensus achieved so far on = the architecture draft.
> > >
> > > How is that?
> >
> > Before amending the charter we at least = need to know
> > what and how this would work. Instead we = got a charter
> > change dictated on us before learning how = this
> > SIP-happy-NAT is going to influence the = current architecture,
> > or being discussed and scrutinized by the = WG.
> >
> > <snip>
> > > >
> > > > The deployment argument of = IKE/IPSec, IP6, MPLS didnt stop
> > > > the WGs from developing those = standards. Why should we be
> > > > the exception?
> > >
> > > No one is saying that it should not = be deployed. Full steam
> > ahead. We
> > > need
> > > midcom, and that hasn't changed. The = fact is that midcom
> can't fully
> > > solve
> > > our problems.
> > >
> > > Its also worth noting that there are = already solutions
> > being deployed
> > > today
> > > that play the role of the proposed = addition. Those are all
> > > proprietary and
> > > not interoperable. Let us not let = that continue.
> >
> > What will happen is another beast will be = added to the gang.
> >
> > = _______________________________________________________
> > Do You Yahoo!?
> > Get your free @yahoo.ca address at http://mail.yahoo.ca
> >
>
> ---
> Jonathan D. Rosenberg, = Ph.D.           &= nbsp;    72 Eagle Rock Ave.
> 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;     PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
>
>
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C15008.2E67A770-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Oct 8 11:26:55 2001 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 LAA23682 for ; Mon, 8 Oct 2001 11:26: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 LAA07097; Mon, 8 Oct 2001 11:25: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 LAA07065 for ; Mon, 8 Oct 2001 11:25:12 -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 LAA23647 for ; Mon, 8 Oct 2001 11:25:09 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f98FOik23978 for ; Mon, 8 Oct 2001 08:24:44 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn2-307.cisco.com [10.21.113.51]) by airborne.cisco.com (Mirapoint) with SMTP id AAI03059; Mon, 8 Oct 2001 08:24:41 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Mon, 8 Oct 2001 11:24:44 -0400 Date: Mon, 8 Oct 2001 11:24:44 -0400 From: Scott Brim To: midcom@ietf.org Message-ID: <20011008112444.A604@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [midcom] new bullet list, 8 Oct 2001 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 R46, R60 accepted. The list is at http://www.employees.org/~swb/midcom.html. ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Oct 8 12:00:42 2001 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 MAA24444 for ; Mon, 8 Oct 2001 12:00:38 -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 LAA07910; Mon, 8 Oct 2001 11:45:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07881 for ; Mon, 8 Oct 2001 11:45:46 -0400 (EDT) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24080 for ; Mon, 8 Oct 2001 11:45:43 -0400 (EDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f98FihS11615 for ; Mon, 8 Oct 2001 11:44:43 -0400 (EDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Mon, 8 Oct 2001 10:44:23 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Oct 2001 10:44:40 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E06F1E1@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Melinda Shore'" , midcom Subject: RE: [midcom] New requirements bullets Date: Mon, 8 Oct 2001 10:44:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15010.1F3D89B0" 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_01C15010.1F3D89B0 Content-Type: text/plain; charset="iso-8859-1" Melinda, Comments below. Thanks. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Monday, October 08, 2001 9:14 AM > To: midcom > Subject: [midcom] New requirements bullets > > > R20: As Pin-Holes may be shared across Middlebox functions, it MUST > be possible for a Pinhole-Descriptor to be created by one > function, and terminated by a different one. > > Proposal: delete. We're covered by other requirements bullets. Agreed. > > R33: The relationship between a Midcom Agent and a given Middlebox > may be pre-configured through a manual configuration > process or > may be established dynamically through a registration process. > In either case, depending upon the policy applied to the > Middlebox, the Middlebox MUST appropriately authenticate the > identity and credentials of the Midcom Agent seeking > to make use > of its services prior to servicing any other requests from the > Midcom Agent. > > Proposal: delete anything to do with provisioning (the first part) and > change the second part so that 1) the requirement is on the protocol > and not the middlebox, 2) the requirement is the capability to do > bidirectional authentication. The choice to actually do > authentication > is a question of site-local security policy. I agree that this depends on the local security policies. The requirement is that the Midcom protocol must specify the mechanism(s) to do bidirectional authentication (e.g., using an undelying protocol like TLS, IPSec etc.). I don't see a reason why we need to build in authentication mechanisms within the protocol itself. > > R65: Individual message authentication MUST be used in addition to > host authentication. Further message confidentiality MAY be > administered by employing techniques appropriate to Midcom > messages. Simple Source-address based security is the least > form of security and MAY be permitted only to the most trusted > hosts. > > Proposal: Again, we can't tell network administrators how to run their > networks. The protocol must support message authentication > and message > confidentiality. That's it. Again, for the same reason as above, Midcom must specify the use existing protocols for doing these. ------_=_NextPart_001_01C15010.1F3D89B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] New requirements bullets

Melinda, Comments below. Thanks.

> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Monday, October 08, 2001 9:14 AM
> To: midcom
> Subject: [midcom] New requirements = bullets
>
>
>  R20: As Pin-Holes may be shared across = Middlebox functions, it MUST
>         = be possible for a Pinhole-Descriptor to be created by one
>         = function, and terminated by a different one.
>
> Proposal: delete.  We're covered by other = requirements bullets.

Agreed.

>
>  R33: The relationship between a Midcom = Agent and a given Middlebox
>         = may be pre-configured through a manual configuration
> process or
>         = may be established dynamically through a registration process.
>         = In either case, depending upon the policy applied to the
>         = Middlebox, the Middlebox MUST appropriately authenticate the
>         = identity and credentials of the Midcom Agent seeking
> to make use
>         = of its services prior to servicing any other requests from the
>         = Midcom Agent.
>
> Proposal: delete anything to do with = provisioning (the first part) and
> change the second part so that 1) the = requirement is on the protocol
> and not the middlebox, 2) the requirement is = the capability to do
> bidirectional authentication.  The choice = to actually do
> authentication
> is a question of site-local security = policy.

I agree that this depends on the local security = policies. The requirement is that
the Midcom protocol must specify the mechanism(s) to = do bidirectional authentication (e.g.,
using an undelying protocol like TLS, IPSec etc.). I = don't see a reason why we need to
build in authentication mechanisms within the = protocol itself.

>
>  R65: Individual message authentication = MUST be used in addition to
>         = host authentication.  Further message confidentiality MAY = be
>         = administered by employing techniques appropriate to Midcom
>         = messages.  Simple Source-address based security is the = least
>         = form of security and MAY be permitted only to the most trusted
>         = hosts.
>
> Proposal: Again, we can't tell network = administrators how to run their
> networks.  The protocol must support = message authentication
> and message
> confidentiality.  That's it.

Again, for the same reason as above, Midcom must = specify the use existing protocols for doing these.

------_=_NextPart_001_01C15010.1F3D89B0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Oct 8 12:01:23 2001 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 MAA24478 for ; Mon, 8 Oct 2001 12:01: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 LAA08140; Mon, 8 Oct 2001 11:55: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 LAA08111 for ; Mon, 8 Oct 2001 11:55:08 -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 LAA24301 for ; Mon, 8 Oct 2001 11:55:05 -0400 (EDT) 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 f98Fshg07030; Mon, 8 Oct 2001 08:54:43 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-283.cisco.com [10.21.65.27]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAI00008; Mon, 8 Oct 2001 08:54:19 -0700 (PDT) Message-Id: <5.1.0.14.0.20011008115041.00a46d50@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 08 Oct 2001 11:56:39 -0400 To: "Sanjoy Sen" , midcom From: Melinda Shore Subject: RE: [midcom] New requirements bullets In-Reply-To: <933FADF5E673D411B8A30002A5608A0E06F1E1@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 10:44 AM 10/8/01 -0500, Sanjoy Sen wrote: >I agree that this depends on the local security policies. The requirement is that >the Midcom protocol must specify the mechanism(s) to do bidirectional authentication (e.g., >using an undelying protocol like TLS, IPSec etc.). I don't see a reason why we need to >build in authentication mechanisms within the protocol itself. Note that I didn't say that. However, since you bring it up, it seems to me that for security-sensitive applications it's preferable that the application have some awareness of its own security state. I think that people tend to be awfully casual in recommending TLS or IPSec - it may be the case that it would be preferable to use SASL for authentication. In any event, we aren't specifying mechanism during this iteration of the working group. I think it's sufficient to say that the protocol must support bidirectional authentication and let the next midcom working group decide how that's to be done. >> Proposal: Again, we can't tell network administrators how to run their >> networks. The protocol must support message authentication >> and message >> confidentiality. That's it. > >Again, for the same reason as above, Midcom must specify the use existing protocols for doing these. See above. Also, if you choose to do application layer authentication using, say, HMAC-SHA1 you're still using an existing authentication mechanism. I'd like to keep the requirement broad until someone does a proper security analysis. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Oct 8 12:02:50 2001 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 MAA24524 for ; Mon, 8 Oct 2001 12:02: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 LAA08266; Mon, 8 Oct 2001 11:58: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 LAA08233 for ; Mon, 8 Oct 2001 11:58:02 -0400 (EDT) Received: from znsgs0ja.europe.nortel.com ([47.165.25.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24395 for ; Mon, 8 Oct 2001 11:57:59 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f98FvOg07064 for ; Mon, 8 Oct 2001 16:57:24 +0100 (BST) Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com; Mon, 8 Oct 2001 16:57:10 +0100 Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Oct 2001 16:56:53 +0100 Message-ID: <9154CB41F208D5118DD200508BE39C304452E7@zjguc006.europe.nortel.com> From: "Cedric Aoun" To: "Sanjoy Sen" , "'Christian Huitema'" , Bob Penfield , Scott Brim , midcom Subject: RE: [midcom] New requirement bullets for decision Date: Mon, 8 Oct 2001 16:56:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15011.D001CE90" 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_01C15011.D001CE90 Content-Type: text/plain; charset="iso-8859-1" I agree with Bob and Sanjoy about having a single identifier(that doesn't change) during the lifetime of the ruleset or aggregate. -----Original Message----- From: Sen, Sanjoy [NGB:B602:EXCH] Sent: Wednesday, October 03, 2001 4:23 PM To: 'Christian Huitema'; Bob Penfield; Scott Brim; midcom Subject: RE: [midcom] New requirement bullets for decision > -----Original Message----- > From: Christian Huitema [ mailto:huitema@windows.microsoft.com ] > Sent: Tuesday, October 02, 2001 6:47 PM > To: Bob Penfield; Scott Brim; midcom > Subject: RE: [midcom] New requirement bullets for decision > > > > Which is a better "key" for the ruleset? One that is > > allocated when the > > ruleset is created and remains constant or one the changes > > over the life of > > the ruleset? > > We debated that in London, and in fact I am supposed to head > a panel and > write a draft on the issue. (Volunteers are welcome.) There are two > options. If you want to keep "id=filter-spec", then the H.323 scenario > is solved by creating two rulesets: create first a wildcard ruleset, > then delete the wild card ruleset and create a specific ruleset. I don't think its a good idea to create a ruleset id which can change in the middle of a session (what purpose does your name serves if it changes in the middle of your life! You need to advertise to everybody who knows you that you've a new name). I like Bob's idea of an id for rule-set and a separate id for rule-set aggregate. These ids should be separate from any attribute describing the entity and should remain unchanged for the lifetime of the entity. > > There are all kinds of pros and cons in this debate, but as an > architecture rule, it is preferable to avoid creating extra > identifiers > whenever possible. > > -- Christian Huitema > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C15011.D001CE90 Content-Type: text/html; charset="iso-8859-1" RE: [midcom] New requirement bullets for decision
I agree with Bob and Sanjoy about having a single identifier(that doesn't change) during the lifetime of the ruleset or aggregate.

-----Original Message-----
From: Sen, Sanjoy [NGB:B602:EXCH]
Sent: Wednesday, October 03, 2001 4:23 PM
To: 'Christian Huitema'; Bob Penfield; Scott Brim; midcom
Subject: RE: [midcom] New requirement bullets for decision



> -----Original Message-----
> From: Christian Huitema [mailto:huitema@windows.microsoft.com]
> Sent: Tuesday, October 02, 2001 6:47 PM
> To: Bob Penfield; Scott Brim; midcom
> Subject: RE: [midcom] New requirement bullets for decision
>
>
> > Which is a better "key" for the ruleset? One that is
> > allocated when the
> > ruleset is created and remains constant or one the changes
> > over the life of
> > the ruleset?
>
> We debated that in London, and in fact I am supposed to head
> a panel and
> write a draft on the issue. (Volunteers are welcome.) There are two
> options. If you want to keep "id=filter-spec", then the H.323 scenario
> is solved by creating two rulesets: create first a wildcard ruleset,
> then delete the wild card ruleset and create a specific ruleset.

I don't think its a good idea to create a ruleset id which can change in
the middle of a session (what purpose does your name serves if it changes
in the middle of your life!  You need to advertise to everybody who knows you
that you've a new name).
I like Bob's idea of an id for rule-set and a separate id for rule-set aggregate.
These ids should be separate from any attribute describing the entity and should remain
unchanged for the lifetime of the entity. 

>
> There are all kinds of pros and cons in this debate, but as an
> architecture rule, it is preferable to avoid creating extra
> identifiers
> whenever possible.
>
> -- Christian Huitema
>
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C15011.D001CE90-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Oct 8 13:00:57 2001 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 NAA26153 for ; Mon, 8 Oct 2001 13:00: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 MAA10761; Mon, 8 Oct 2001 12:58:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10730 for ; Mon, 8 Oct 2001 12:58:52 -0400 (EDT) Received: from linux.aravox.com (linux.aravox.com [209.46.41.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26104 for ; Mon, 8 Oct 2001 12:58:50 -0400 (EDT) Received: from MPIETRAS (dyn-1-106.aravox.com [192.168.1.106] (may be forged)) by linux.aravox.com (8.9.3/8.9.3) with SMTP id LAA24139; Mon, 8 Oct 2001 11:57:07 -0500 From: "Mark Pietras" To: "Sanjoy Sen" , "Jonathan Rosenberg" , "midcom" Subject: RE: [midcom] pre-midcom work item Date: Mon, 8 Oct 2001 11:57:40 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01C14FF0.6E5DC930" 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.4133.2400 In-Reply-To: <933FADF5E673D411B8A30002A5608A0E06F1DD@zrc2c012.us.nortel.com> 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. ------=_NextPart_000_001A_01C14FF0.6E5DC930 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: [midcom] pre-midcom work itemSanjoy, jump in any time. My question was specifically about an environment (like an enterprise) with _no_ call control element (e.g. SIP Proxy) in the same realm. This is the PSTN equivalent of a Centrex environment. If there _is_ a call control element in the same realm, this more closely mimics a PBX environment. Your proposal clearly has additional call control, as well as media control in the solution, so it's really a different environment and a different question. As a side note, the media routing problem I pointed out in the IP-packet world is the same as what you find in the PSTN world today. That is, in a Centrex configuration, TDM traffic goes to the first TDM switch in the service provider network before getting routed back. Of course, there's no where near the latency (and other QoS issues) involved so it's not a big issue... To keep TDM traffic on site, one would put a PBX (a local TDM switch) on prem... equivalent to putting a call control element (SIP Proxy) on prem. Ideally, we (us packet voice folks) could solve this media routing problem rather than mimicking some of the same problems. More intelligence in call control and client, like Jonathan suggests, is an option... Mark. -----Original Message----- From: Sanjoy Sen [mailto:sanjoy@nortelnetworks.com] Sent: Monday, October 08, 2001 9:48 AM To: 'Mark Pietras'; Jonathan Rosenberg; midcom Subject: RE: [midcom] pre-midcom work item Mark, Sorry for jumping in late! But a solution for this is described in our recently submitted draft at http://www.ietf.org/internet-drafts/draft-sen-midcom-fw-nat-00.txt. Basically, if you use an RTP proxy like device under the control of a SIP Proxy, then the SIP Proxy can decide whether or not to force the media to go to the RTP Proxy (i.e., in case of 2 UA's behind the same NAT, the SDP is not changed by the SIP Proxy & the media can bypass the RTP Proxy). Please let me know your comments/feedback. Thanks, Sanjoy > -----Original Message----- > From: Mark Pietras [mailto:mpietras@aravox.com] > Sent: Thursday, October 04, 2001 10:20 AM > To: Jonathan Rosenberg; midcom > Subject: RE: [midcom] pre-midcom work item > > > Jonathan, > > More of a question about the _solution_ than the particulars of STUN: > > Have you found a solution to the problem of "misguided" > media? That is, > when two clients are behind the same NAT and there's no > call-control/routing > element with them in that same "realm?!", both will be forced > to assume that > the other is on the "outside" the NAT. Both the signaling > and the media > will be sent "outside" just to be routed right back. > Signaling might not be > a big deal, but media might be (from a latency or more interestingly a > NAT-loading perspective). > > Mark P. > > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Jonathan Rosenberg > Sent: Monday, October 01, 2001 4:40 PM > To: 'Abdallah Rayhan'; Jonathan Rosenberg; Melinda Shore; > midcom@ietf.org > Subject: RE: [midcom] pre-midcom work item > > > > Folks, > > I've just submitted an I-D to the archives, co-authored with Christian > Huitema and Rohan Mahy, on what this protocol might look > like. Until it > appears in the archives, you can pick it up from: > > http://www.jdrosen.net/papers/draft-rosenberg-midcom-stun-00.txt > > Its just a step above "echo", but it can determine the > presence of nats, > diagnose the type, and help determine binding lifetimes. This > protocol will > suffice to help a SIP enabled voip phone get through a fairly > large fraction > of nats (full cone and restricted cone, which is about 80-90% of nats > depending on who you ask) while still maintaining direct, > end-to-end voice > transport. The protocol is totally independent of sip; a > separate draft (in > sipping) is pending on how to use the stun protocol in a sip client. > > Comments/questions/flames welcome as always. Hopefully this will help > clarify the kind of things the new charter item is aiming at. > > Thanks, > Jonathan R. > > > > -----Original Message----- > > From: Abdallah Rayhan [mailto:ar_rayhan@yahoo.ca] > > Sent: Monday, September 24, 2001 2:21 PM > > To: Jonathan Rosenberg; Melinda Shore; midcom@ietf.org > > Subject: RE: [midcom] pre-midcom work item > > > > > > --- Jonathan Rosenberg wrote: > > > > > > Secondly, this introduces > > > > new architectural constraints that is going to screw > > > > the consensus achieved so far on the architecture draft. > > > > > > How is that? > > > > Before amending the charter we at least need to know > > what and how this would work. Instead we got a charter > > change dictated on us before learning how this > > SIP-happy-NAT is going to influence the current architecture, > > or being discussed and scrutinized by the WG. > > > > > > > > > > > > The deployment argument of IKE/IPSec, IP6, MPLS didnt stop > > > > the WGs from developing those standards. Why should we be > > > > the exception? > > > > > > No one is saying that it should not be deployed. Full steam > > ahead. We > > > need > > > midcom, and that hasn't changed. The fact is that midcom > can't fully > > > solve > > > our problems. > > > > > > Its also worth noting that there are already solutions > > being deployed > > > today > > > that play the role of the proposed addition. Those are all > > > proprietary and > > > not interoperable. Let us not let that continue. > > > > What will happen is another beast will be added to the gang. > > > > _______________________________________________________ > > Do You Yahoo!? > > Get your free @yahoo.ca address at http://mail.yahoo.ca > > > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > ------=_NextPart_000_001A_01C14FF0.6E5DC930 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] pre-midcom work item
Sanjoy, jump in any time.
 
My question was specifically = about an=20 environment (like an enterprise) with _no_ call control element (e.g. = SIP Proxy)=20 in the same realm.  This is = the PSTN equivalent of a Centrex=20 environment.  If there _is_ a call control element in the same = realm, this=20 more closely mimics a PBX = environment.
 
Your proposal clearly has = additional call=20 control, as well as media control in the solution, so it's really a = different=20 environment and a different = question.
 
As a side note, the media = routing problem=20 I pointed out in the IP-packet world is the same as what you find in the = PSTN=20 world today.  That is, in a Centrex configuration, TDM traffic goes = to the=20 first TDM switch in the service provider network before getting routed=20 back.  Of course, there's no where near the latency (and other QoS = issues)=20 involved so it's not a big issue...  To keep TDM traffic on site, = one would=20 put a PBX (a local TDM switch) on prem... equivalent to putting a = call=20 control element (SIP Proxy) on prem.  Ideally, we (us packet voice = folks)=20 could solve this media routing problem rather than mimicking some of the = same=20 problems.  More intelligence in call control and client, like = Jonathan=20 suggests, is an option...
 
Mark.
=
-----Original Message-----
From: Sanjoy Sen=20 [mailto:sanjoy@nortelnetworks.com]
Sent: Monday, October 08, = 2001=20 9:48 AM
To: 'Mark Pietras'; Jonathan Rosenberg;=20 midcom
Subject: RE: [midcom] pre-midcom work=20 item

Mark, Sorry for jumping in late! But a solution for = this is=20 described in our recently submitted draft at http://www.ietf.org/internet-drafts/draft-sen-midcom-fw-nat-00.txt= .=20 Basically, if you use an RTP proxy like device under the control of a = SIP=20 Proxy, then the SIP Proxy can decide whether or not to force the media = to go=20 to the RTP Proxy (i.e., in case of 2 UA's behind the same NAT, the SDP = is not=20 changed by the SIP Proxy & the media can bypass the RTP Proxy). = Please let=20 me know your comments/feedback.

Thanks,
Sanjoy =


> -----Original Message-----
>=20 From: Mark Pietras [mailto:mpietras@aravox.com]=20
> Sent: Thursday, October 04, 2001 10:20 = AM=20
> To: Jonathan Rosenberg; midcom =
> Subject: RE: [midcom] pre-midcom work item =
>
>
>=20 Jonathan,
>
> More of a=20 question about the _solution_ than the particulars of STUN: =
>
> Have you found a solution = to the=20 problem of "misguided"
> media?  = That=20 is,
> when two clients are behind the = same NAT and=20 there's no
> call-control/routing =
> element with them in that same "realm?!", both will be = forced=20
> to assume that
> the=20 other is on the "outside" the NAT.  Both the signaling =
> and the media
> will be = sent "outside"=20 just to be routed right back. 
> = Signaling=20 might not be
> a big deal, but media = might be (from=20 a latency or more interestingly a
> = NAT-loading=20 perspective).
>
> Mark=20 P.
>
> = -----Original=20 Message-----
> From: = midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On= Behalf=20 Of
> Jonathan Rosenberg
> Sent: Monday, October 01, 2001 4:40 PM
> To: 'Abdallah Rayhan'; Jonathan Rosenberg; Melinda = Shore;=20
> midcom@ietf.org
> = Subject:=20 RE: [midcom] pre-midcom work item
>=20
>
> =
> Folks,
>
>=20 I've just submitted an I-D to the archives, co-authored with = Christian=20
> Huitema and Rohan Mahy, on what this protocol = might look=20
> like. Until it
>=20 appears in the archives, you can pick it up from:
>=20
> http://www.jdrosen.net/papers/draft-rosenberg-midcom-stun-00.txt=20
>
> Its just a step = above=20 "echo", but it can determine the
> = presence of=20 nats,
> diagnose the type, and help = determine=20 binding lifetimes. This
> protocol = will=20
> suffice to help a SIP enabled voip phone get = through a=20 fairly
> large fraction
> of nats (full cone and restricted cone, which is about = 80-90% of=20 nats
> depending on who you ask) while = still=20 maintaining direct,
> end-to-end = voice=20
> transport. The protocol is totally independent = of sip; a=20
> separate draft (in
>=20 sipping) is pending on how to use the stun protocol in a sip = client.=20
>
> = Comments/questions/flames=20 welcome as always. Hopefully this will help
>=20 clarify the kind of things the new charter item is aiming at. =
>
> Thanks,
>=20 Jonathan R.
>
>=20
> > -----Original Message----- =
> > From: Abdallah Rayhan [mailto:ar_rayhan@yahoo.ca] =
> > Sent: Monday, September 24, 2001 2:21 = PM=20
> > To: Jonathan Rosenberg; Melinda Shore;=20 midcom@ietf.org
> > Subject: RE: = [midcom]=20 pre-midcom work item
> > =
> >
> > --- Jonathan = Rosenberg=20 <jdrosen@dynamicsoft.com> wrote:
>=20 >
> > > > Secondly, this=20 introduces
> > > > new = architectural=20 constraints that is going to screw
> > = > >=20 the consensus achieved so far on the architecture draft. =
> > >
> > > How = is=20 that?
> >
> >=20 Before amending the charter we at least need to know
> > what and how this would work. Instead we got a = charter=20
> > change dictated on us before learning how = this
> > SIP-happy-NAT is going to = influence the=20 current architecture,
> > or being = discussed and=20 scrutinized by the WG.
> > =
> > <snip>
> > = >=20 >
> > > > The deployment = argument of=20 IKE/IPSec, IP6, MPLS didnt stop
> > = > >=20 the WGs from developing those standards. Why should we be =
> > > > the exception?
> >=20 >
> > > No one is saying that it = should=20 not be deployed. Full steam
> > ahead. = We=20
> > > need
> = > >=20 midcom, and that hasn't changed. The fact is that midcom =
> can't fully
> > > = solve=20
> > > our problems.
>=20 > >
> > > Its also worth = noting that=20 there are already solutions
> > being=20 deployed
> > > today =
> > > that play the role of the proposed addition. = Those are=20 all
> > > proprietary and =
> > > not interoperable. Let us not let that = continue.=20
> >
> > What = will happen=20 is another beast will be added to the gang.
>=20 >
> >=20 _______________________________________________________ =
> > Do You Yahoo!?
> > = Get your=20 free @yahoo.ca address at http://mail.yahoo.ca =
> >
>
>=20 ---
> Jonathan D. Rosenberg,=20 = Ph.D.           &n= bsp;   =20 72 Eagle Rock Ave.
> Chief=20 = Scientist          &nbs= p;            = ;     =20 First Floor
>=20 = dynamicsoft          &n= bsp;           &nb= sp;         =20 East Hanover, NJ 07936
>=20 = jdrosen@dynamicsoft.com        &n= bsp;           =20 FAX:   (973) 952-5050
> http://www.jdrosen.net  &nb= sp;           &nbs= p;      =20 PHONE: (973) 952-5000
> http://www.dynamicsoft.com= =20
>
>=20 _______________________________________________
>=20 midcom mailing list
> = midcom@ietf.org=20
> http://www1.ietf.or= g/mailman/listinfo/midcom=20
>
> =
> _______________________________________________ =
> midcom mailing list
>=20 midcom@ietf.org
> http://www1.ietf.or= g/mailman/listinfo/midcom=20
>

------=_NextPart_000_001A_01C14FF0.6E5DC930-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Oct 8 17:32:23 2001 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 RAA02793 for ; Mon, 8 Oct 2001 17:32: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 RAA18625; Mon, 8 Oct 2001 17:19: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 RAA18539 for ; Mon, 8 Oct 2001 17:19:01 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02502 for ; Mon, 8 Oct 2001 17:18:59 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id QAA07831 for ; Mon, 8 Oct 2001 16:18:33 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Mon, 8 Oct 2001 16:11:38 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Oct 2001 16:17:53 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E06F1E8@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Jonathan Rosenberg'" , midcom@ietf.org Cc: "Patrick Sollee" , "Sean March" , "Cedric Aoun" Subject: RE: [midcom] Submission of a new Internet draft Date: Mon, 8 Oct 2001 16:17:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1503E.AA2E25B0" X-Orig: 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_01C1503E.AA2E25B0 Content-Type: text/plain; charset="iso-8859-1" Jonathan, Thanks for your insightful comments! Please see responses inline. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Sunday, October 07, 2001 1:33 PM > To: Sen, Sanjoy [NGB:B602:EXCH]; midcom@ietf.org > Cc: Sollee, Patrick [NGC:B610:EXCH]; March, Sean [NGC:B642:EXCH] > Subject: RE: [midcom] Submission of a new Internet draft > > > A very nice draft. Some comments:. > > First off, please note that your draft requires the end > systems to support > symmetric RTP. You don't explicitly state that, but since you have the > clients "priming" the nats by sending RTP packets to the RTP > proxy, with the > media going back to the source address. That is not normal > RTP behavior, but > is what we call symmetric RTP. You can tell its symmetric RTP > since, in your > proposal, the IP/port in the SDP sent from the client is > actually never used > by the RTP proxy to figure out where to send media. Yes, but the only restriction is send & receive ports are the same, which is easily configurable in the majority of the VoIP clients available today. But having the RTP Proxy in between allows us to avoid any SDP extensions (needed for Symmetric RTP) needed to tell the "passive" entity to send the RTP packets to the source address of the received RTP packets. The primary goal of the media proxy method is to allow deployment of multimedia services in the fastest way possible without requiring a lot of development on the application clients. > > The mechanism you describe in this draft is largely the same > as what we > proposed in draft-rosenberg-sip-entfw-01.txt (NOT the current > -02 version, > which is much different), which had the proxies performing > the rewrites of > the SDP as you describe. Quite similar. However, the draft talks about supporting SDP extensions for Bi-directional RTP which we don't need to. > As we began to work through the > details of this > solution, it became terribly complex. THe main reason for > that is that you > have to assume multiple domains, each of which has its own > proxy, and that > you can have cases where the user is not natted on one side, > the other side, > or both. Add to that the need to determine whether one side, > the other side, > or both support symmetric RTP. To ease complexity, the following rules are used: 1. The SIP BBUA supports multiple domains. 2. All media for cross domain calls uses the RTP proxy. 3. Media for calls within the same domain (assuming the originator and terminator have the same firewall setting) do not use the RTP proxy. This implies that endpoints within the same domain are in the same address space. If this is not the case, then seperate domains need to be used for each address space. If the UA's are not behind NAT's, the RTP Proxy can be bypassed. > > As an example of what I mean, you show an RTP proxy only on > the originating > domain. What if the originating domain doesn't support this > capability? What > if the originating domain doesn't use nats at all, in fact? > In that case, > the terminating proxy also needs to do this (rewrite SDP and > act as a b2bua) > when its users are natted. But, what if the originating > domain IS natted? > Does that mean there are TWO RTP proxies on each call setup path? The BBUAs representing the originator and terminator can be seperate. Each BBUA is responsible for modifing the SIP signalling so that its users are addressable. In a cross domain call, one or more the RTP proxy(s) would always be used when the users are NAT-ed. Even if the both the users are behind NAT's, the call can still go through a single RTP Proxy, when the other domain does not support RTP Proxy. Also, if the two endpoints were registered with the same BBUA (BBUA support multiple domains), then one RTP proxy would be used. > > It gets really complicated when you add, as a goal, direct media > communications whenever possible. In your proposal, media always flows > through this intermediary. Since the location of that device > is generally > going to be physically uncorrelated with the location of the > endpoints, > media latency can suffer a LOT. As such, you really only want > that thing in > there when its needed. If you want to ensure direct media > whenever possible, > then you get into further complications of making decisions > based on which > type of nats there are. We came up with on the order of 100 > different cases > that needed to be considered (something like 7 different > yes/no orthogonal > variables). Media does not always flow through the RTP Proxy. If the endpoints are in the same domain, and are behind the same NAT/FW, then media does not traverse the RTP Proxy. > > The approach you propose also requires that there are call > stateful B2BUAs > in each call path, which has significant impacts on > performance and fault > tolerance in particular. The cost to the VoIP provider is > VERY high from > this solution, because of all the additional rtp traffic that > comes in, and > back out. The cost is primarily a management issue from the Service Provider perspective. The only requirement is that the SIP Proxy will find the Media Proxy closest to the UA. The voice quality issue is negligible because the Media Proxy is expected to be in the Service Provider (or even within the Enterprise) network close to the end-users. The latency impact we've noted in live deployments in major service provider networks has been negligible. We use standard mechanisms to deploy fault-tolerant BBUA's and RTP Proxies. A less sophisticated version of the solution can also be used for small Enterprise customers. On the other hand, the solution adds the benefits of address hiding, and services such as Legal Intercept and Supervision Listen In. Also, a stun-like protocol will need more software upgrades on the Enterprise clients, which has cost disadvantages too. Doesn't it? > > Our conclusion was that the whole mess gets a lot easier when > you push the > intelligence to the end systems. Rather than the proxy > mucking with SDP, > being call stateful, and so on, the client simply discovers > its public IP > address, and the type of nat, and uses that information. Once > the client > knows what its situation is, it can involve a RTP media proxy > only in the > case where its behing a symmetric NAT. The real tradeoff here is how much intelligence you want to put in the client as opposed to that in the network. Our solution is "simple" and "dumb" in the sense that neither the client nor the Proxy need to know about the Enterprise NAT binds or types. It eliminates the need for SDP extensions for Symmetric RTP and a few of the SIP extensions (e.g., NAT type). The tradeoff is against the performance impact on the network, which has been discussed earlier. Also, our solution is targeted primarily for Enterprise customers (although applicable for residential too), for whom we believe something like a Full Cone NAT (alone) does not make a great deal of sense. The most prevalent (we believe to be > 90%) cases will be Restricted Cone NAT's and Symmetric NAT's, both of which will need RTP Proxy-like devices. So our conclusion was the additional client signaling development complexity to support Full Cone NAT's is not worth doing. In residential environment with sharewares and other publicly available software on the net, the stun approach is probably better since you can't afford putting a media proxy for a single host. > > As such, our approach is truly a client discovery mechanism, which is > EXACTLY how it would work if midcom were deployed. If midcom > were in place, > the client would talk to its enterprise/residential NAT, obtain some > addresses, and put those in SDP. It depends on where the Midcom Agent resides - the client or the Proxy. Midcom would also allow the Proxy to do all these things transparently for the client, which is also desirable. > No B2BUAs. No proxies > mucking with SDP. > None of that. In our case, the same thing happens. However, > since the client > can't speak midcom to the nat, it speaks stun THROUGH the > nat, to a server > on the other side. The result is the same, though - it gets > an IP address, > and puts those in SDP. No B2BUAs. No proxies mucking with > SDP. The solution > retains all of the scalability and fault tolerance > characteristics of SIP, > and also ensures that direct media takes place whenever > possible. This saves > the VoIP provider money and improves the voice quality > perceived by the > endpoints. As stated earlier, the voice quality issue is negligible because the Media Proxy is expected to be in the Service Provider (or even in Enterprise) network close to the end-users. > STUn also allows other applications to work, just as midcom will. The usage of the media proxies do not limit the application to SIP. > > Also, I'd like to point out Melinda's statement: > > What I'm after here is something that's more-or-less consistent > with the midcom notion that the external address is "learned" by > the endpoint and then used for signaling purposes. > > No such thing happens in your proposal. The endpoints are not > learning their > addresses. THis is, however, exactly how stun works. > It depends where the Midcom Agent is located - according to the Midcom framework, this can reside in the client or in the Proxy. Our target is doing minimal software upgrade on the clients. The clients in our case are also learning the RTP Proxy address to send media to. It is also learning about the NAT binding when the 200 OK response of the REGISTER comes back, but we don't want the client to send it to the remote end, as we prefer the "SDP-mangling" to happen at the Proxy instead of the client for reasons described earlier. > > A few minor comments: > > 1. You write: > > 4. The destination port of the requests at the Signaling Proxy > server is the same as the source port of the corresponding > responses. > > That is not true for rfc2543, since the responses are sent to > the source IP, > but to the port written in the Via header, or 5060 if not > present. This will > not work through NAPT. This has been fixed with our SIP > extensions for an > rport parameter: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-nat-00.txt > > which is a SIP wg work item. > > 2. You write: > > Proxy/Register (Signaling server). The SIP REGISTER message contains > an extension tag carried in the Proxy-Require header, indicating to > the Proxy that the client is behind a NAT (Note: the client or the > Proxy does not care about the type of NAT, as the same solution > applies to all types). This packet is NAT-ed by the Enterprise NAT > with a new source IP address and port. If the Proxy supports the > extension tag, it creates an association between the IP address and > port from which the packet arrived and the actual address of the > user. The response to the Registration message is sent to this IP > address and port (not to the Contact address in the REGISTER). > > This is also covered by the above draft, using the Translate > header. Note > that implicit translation requests do not work, because > registrations are > not always for the purpose of binding an address-of-record to the host > sending the registration. Agreed. Thanks, Sanjoy ------_=_NextPart_001_01C1503E.AA2E25B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Submission of a new Internet draft

Jonathan,

   Thanks for your insightful comments! = Please see responses inline.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Sunday, October 07, 2001 1:33 PM
> To: Sen, Sanjoy [NGB:B602:EXCH]; = midcom@ietf.org
> Cc: Sollee, Patrick [NGC:B610:EXCH]; March, = Sean [NGC:B642:EXCH]
> Subject: RE: [midcom] Submission of a new = Internet draft
>
>
> A very nice draft. Some comments:.
>
> First off, please note that your draft requires = the end
> systems to support
> symmetric RTP. You don't explicitly state that, = but since you have the
> clients "priming" the nats by sending = RTP packets to the RTP
> proxy, with the
> media going back to the source address. That is = not normal
> RTP behavior, but
> is what we call symmetric RTP. You can tell its = symmetric RTP
> since, in your
> proposal, the IP/port in the SDP sent from the = client is
> actually never used
> by the RTP proxy to figure out where to send = media.

Yes, but the only restriction is send & receive = ports are the same, which is easily configurable in the majority of the = VoIP clients available today. But having the RTP Proxy in between = allows us to avoid any SDP extensions (needed for Symmetric RTP) needed = to tell the "passive" entity to send the RTP packets to the = source address of the received RTP packets.

The primary goal of the media proxy method is to = allow deployment of multimedia services in the fastest way possible = without requiring a lot of development on the application = clients.


>
> The mechanism you describe in this draft is = largely the same
> as what we
> proposed in draft-rosenberg-sip-entfw-01.txt = (NOT the current
> -02 version,
> which is much different), which had the proxies = performing
> the rewrites of
> the SDP as you describe.

Quite similar. However, the draft talks about = supporting SDP extensions for Bi-directional RTP which we don't need = to.

> As we began to work through the
> details of this
> solution, it became terribly complex. THe main = reason for
> that is that you
> have to assume multiple domains, each of which = has its own
> proxy, and that
> you can have cases where the user is not natted = on one side,
> the other side,
> or both. Add to that the need to determine = whether one side,
> the other side,
> or both support symmetric RTP.

To ease complexity, the following rules are = used:
1. The SIP BBUA supports multiple domains.
2. All media for cross domain calls uses the RTP = proxy.
3. Media for calls within the same domain (assuming = the originator
and terminator have the same firewall setting) do = not use the
RTP proxy.  This implies that endpoints within = the same domain
are in the same address space.  If this is not = the case, then
seperate domains need to be used for each address = space.

If the UA's are not behind NAT's, the RTP Proxy can = be bypassed.

>
> As an example of what I mean, you show an RTP = proxy only on
> the originating
> domain. What if the originating domain doesn't = support this
> capability? What
> if the originating domain doesn't use nats at = all, in fact?
> In that case,
> the terminating proxy also needs to do this = (rewrite SDP and
> act as a b2bua)
> when its users are natted. But, what if the = originating
> domain IS natted?
> Does that mean there are TWO RTP proxies on = each call setup path?

The BBUAs representing the originator and terminator = can be seperate. Each BBUA is responsible for modifing the SIP = signalling so that its users are addressable.  In a cross domain = call, one or more the RTP proxy(s) would always be used when the users = are NAT-ed. Even if the both the users

are behind NAT's, the call can still go through a = single RTP Proxy, when the other domain does not support RTP Proxy. = Also, if the two endpoints were registered with the same BBUA (BBUA = support multiple domains), then one RTP proxy would be used.

 
>
> It gets really complicated when you add, as a = goal, direct media
> communications whenever possible. In your = proposal, media always flows
> through this intermediary. Since the location = of that device
> is generally
> going to be physically uncorrelated with the = location of the
> endpoints,
> media latency can suffer a LOT. As such, you = really only want
> that thing in
> there when its needed. If you want to ensure = direct media
> whenever possible,
> then you get into further complications of = making decisions
> based on which
> type of nats there are. We came up with on the = order of 100
> different cases
> that needed to be considered (something like 7 = different
> yes/no orthogonal
> variables).

Media does not always flow through the RTP Proxy. If = the endpoints are in the same domain, and are behind the same NAT/FW, = then media does not traverse the RTP Proxy.

>
> The approach you propose also requires that = there are call
> stateful B2BUAs
> in each call path, which has significant = impacts on
> performance and fault
> tolerance in particular. The cost to the VoIP = provider is
> VERY high from
> this solution, because of all the additional = rtp traffic that
> comes in, and
> back out.

The cost is primarily a management issue from the = Service Provider perspective. The only requirement is that the SIP = Proxy will find the Media Proxy closest to the UA. The voice quality = issue is negligible because the Media Proxy is expected to be in the = Service Provider (or even within the Enterprise) network close to the = end-users. The latency impact we've noted in live deployments in major = service provider networks has been negligible. We use standard = mechanisms to deploy fault-tolerant BBUA's and RTP Proxies. A less = sophisticated version of the solution can also be used for small = Enterprise customers. On the other hand, the solution adds the benefits = of address hiding, and services such as Legal Intercept and Supervision = Listen In. 

Also, a stun-like protocol will need more software = upgrades on the Enterprise clients, which has
cost disadvantages too. Doesn't it?

>
> Our conclusion was that the whole mess gets a = lot easier when
> you push the
> intelligence to the end systems. Rather than = the proxy
> mucking with SDP,
> being call stateful, and so on, the client = simply discovers
> its public IP
> address, and the type of nat, and uses that = information. Once
> the client
> knows what its situation is, it can involve a = RTP media proxy
> only in the
> case where its behing a symmetric NAT.

The real tradeoff here is how much intelligence you = want to put in the client as opposed to
that in the network. Our solution is = "simple" and "dumb" in the sense that neither the = client
nor the Proxy need to know about the Enterprise NAT = binds or types. It eliminates the need for SDP extensions for Symmetric = RTP and a few of the SIP extensions (e.g., NAT type). The tradeoff is = against the performance impact on the network, which has been discussed = earlier.  Also, our solution is targeted primarily for Enterprise = customers (although applicable for residential too), for whom we = believe something like a Full Cone NAT (alone) does not make a great = deal of sense. The most prevalent (we believe to be > 90%) cases = will be Restricted Cone NAT's and Symmetric NAT's, both of which will = need RTP Proxy-like devices. So our conclusion was the additional = client signaling development complexity to support Full Cone NAT's is = not worth doing.

 
In residential environment with sharewares and other = publicly available software on the net, the stun approach is probably = better since you can't afford putting a media proxy for a single = host.

 

>
> As such, our approach is truly a client = discovery mechanism, which is
> EXACTLY how it would work if midcom were = deployed. If midcom
> were in place,
> the client would talk to its = enterprise/residential NAT, obtain some
> addresses, and put those in SDP.

It depends on where the Midcom Agent resides - the = client or the Proxy. Midcom would also allow the Proxy to do all these = things transparently for the client, which is also desirable. =

> No B2BUAs. No proxies
> mucking with SDP.
> None of that. In our case, the same thing = happens. However,
> since the client
> can't speak midcom to the nat, it speaks stun = THROUGH the
> nat, to a server
> on the other side. The result is the same, = though - it gets
> an IP address,
> and puts those in SDP. No B2BUAs. No proxies = mucking with
> SDP. The solution
> retains all of the scalability and fault = tolerance
> characteristics of SIP,
> and also ensures that direct media takes place = whenever
> possible. This saves
> the VoIP provider money and improves the voice = quality
> perceived by the
> endpoints.

As stated earlier, the voice quality issue is = negligible because the Media Proxy
is expected to be in the Service Provider (or even = in Enterprise) network close
to the end-users.

> STUn also allows other applications to work, = just as midcom will.

The usage of the media proxies do not limit the = application to SIP.


>
> Also, I'd like to point out Melinda's = statement:
>
>   What I'm after here is something = that's more-or-less consistent
>   with the midcom notion that the = external address is "learned" by
>   the endpoint and then used for = signaling purposes.
>
> No such thing happens in your proposal. The = endpoints are not
> learning their
> addresses. THis is, however, exactly how stun = works.
>

It depends where the Midcom Agent is located - = according to the Midcom framework, this can reside in the client or in = the Proxy. Our target is doing minimal software upgrade on the clients. = The clients in our case are also learning the RTP Proxy address to send = media to. It is also learning about the NAT binding when the 200 OK = response of the REGISTER comes back, but we don't want the client to = send it to the remote end, as we prefer the "SDP-mangling" to = happen at the Proxy instead of the client for reasons described = earlier.


>
> A few minor comments:
>
> 1. You write:
>
>  4. The destination port of the requests = at the Signaling Proxy
>   server is the same as the source = port of the corresponding
> responses.
>
> That is not true for rfc2543, since the = responses are sent to
> the source IP,
> but to the port written in the Via header, or = 5060 if not
> present. This will
> not work through NAPT. This has been fixed with = our SIP
> extensions for an
> rport parameter:
>
> http://www.ietf.org/internet-drafts/draft-ietf-sip-nat= -00.txt
>
> which is a SIP wg work item.
>
> 2. You write:
>
>  Proxy/Register (Signaling server). The = SIP REGISTER message contains
>   an extension tag carried in the = Proxy-Require header, indicating to
>   the Proxy that the client is behind = a NAT (Note: the client or the
>   Proxy does not care about the type = of NAT, as the same solution
>   applies to all types). This packet = is NAT-ed by the Enterprise NAT
>   with a new source IP address and = port. If the Proxy supports the
>   extension tag, it creates an = association between the IP address and
>   port from which the packet arrived = and the actual address of the
>   user. The response to the = Registration message is sent to this IP
>   address and port (not to the = Contact address in the REGISTER). 
>
> This is also covered by the above draft, using = the Translate
> header. Note
> that implicit translation requests do not work, = because
> registrations are
> not always for the purpose of binding an = address-of-record to the host
> sending the registration.

Agreed.

Thanks,
Sanjoy
 

------_=_NextPart_001_01C1503E.AA2E25B0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Oct 8 17:40:31 2001 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 RAA02879 for ; Mon, 8 Oct 2001 17:40: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 RAA19195; Mon, 8 Oct 2001 17:39: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 RAA19166 for ; Mon, 8 Oct 2001 17:39:03 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02867 for ; Mon, 8 Oct 2001 17:39:00 -0400 (EDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id QAA12403 for ; Mon, 8 Oct 2001 16:38:34 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Mon, 8 Oct 2001 16:37:45 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Oct 2001 16:38:03 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E06F1E9@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Melinda Shore'" , "'midcom'" Subject: RE: [midcom] New requirements bullets Date: Mon, 8 Oct 2001 16:37:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15041.7D95CC30" 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_01C15041.7D95CC30 Content-Type: text/plain; charset="iso-8859-1" OK. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Monday, October 08, 2001 10:57 AM > To: Sen, Sanjoy [NGB:B602:EXCH]; midcom > Subject: RE: [midcom] New requirements bullets > > > At 10:44 AM 10/8/01 -0500, Sanjoy Sen wrote: > >I agree that this depends on the local security policies. > The requirement is that > >the Midcom protocol must specify the mechanism(s) to do > bidirectional authentication (e.g., > >using an undelying protocol like TLS, IPSec etc.). I don't > see a reason why we need to > >build in authentication mechanisms within the protocol itself. > > Note that I didn't say that. However, since you bring it up, > it seems to me that for security-sensitive applications it's > preferable that the application have some awareness of its > own security state. I think that people tend to be awfully > casual in recommending TLS or IPSec - it may be the case that > it would be preferable to use SASL for authentication. > > In any event, we aren't specifying mechanism during this iteration > of the working group. I think it's sufficient to say that the > protocol must support bidirectional authentication and let the > next midcom working group decide how that's to be done. > > >> Proposal: Again, we can't tell network administrators how > to run their > >> networks. The protocol must support message authentication > >> and message > >> confidentiality. That's it. > > > >Again, for the same reason as above, Midcom must specify the > use existing protocols for doing these. > > See above. Also, if you choose to do application layer authentication > using, say, HMAC-SHA1 you're still using an existing authentication > mechanism. I'd like to keep the requirement broad until someone does > a proper security analysis. > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C15041.7D95CC30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] New requirements bullets

OK.

> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Monday, October 08, 2001 10:57 AM
> To: Sen, Sanjoy [NGB:B602:EXCH]; midcom
> Subject: RE: [midcom] New requirements = bullets
>
>
> At 10:44 AM 10/8/01 -0500, Sanjoy Sen = wrote:
> >I agree that this depends on the local = security policies.
> The requirement is that
> >the Midcom protocol must specify the = mechanism(s) to do
> bidirectional authentication (e.g.,
> >using an undelying protocol like TLS, IPSec = etc.). I don't
> see a reason why we need to
> >build in authentication mechanisms within = the protocol itself.
>
> Note that I didn't say that.  However, = since you bring it up,
> it seems to me that for security-sensitive = applications it's
> preferable that the application have some = awareness of its
> own security state.  I think that people = tend to be awfully
> casual in recommending TLS or IPSec - it may be = the case that
> it would be preferable to use SASL for = authentication.
>
> In any event, we aren't specifying mechanism = during this iteration
> of the working group.  I think it's = sufficient to say that the
> protocol must support bidirectional = authentication and let the
> next midcom working group decide how that's to = be done.
>
> >> Proposal: Again, we can't tell network = administrators how
> to run their
> >> networks.  The protocol must = support message authentication
> >> and message
> >> confidentiality.  That's it. =
> >
> >Again, for the same reason as above, Midcom = must specify the
> use existing protocols for doing these.
>
> See above.  Also, if you choose to do = application layer authentication
> using, say, HMAC-SHA1 you're still using an = existing authentication
> mechanism.  I'd like to keep the = requirement broad until someone does
> a proper security analysis.
>
> Melinda
>
>
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C15041.7D95CC30-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Oct 8 19:25:06 2001 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 TAA04025 for ; Mon, 8 Oct 2001 19:25: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 TAA21194; Mon, 8 Oct 2001 19:23: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 TAA21169 for ; Mon, 8 Oct 2001 19:23:21 -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 TAA04015 for ; Mon, 8 Oct 2001 19:23:19 -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.2966); Mon, 8 Oct 2001 16:20:45 -0700 Received: from 157.54.1.52 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 08 Oct 2001 16:20:45 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 8 Oct 2001 16:20:34 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 8 Oct 2001 16:20:32 -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(5.0.2195.3651); Mon, 8 Oct 2001 16:20:03 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [midcom] Submission of a new Internet draft X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0 Date: Mon, 8 Oct 2001 16:20:03 -0700 Message-ID: Thread-Topic: [midcom] Submission of a new Internet draft Thread-Index: AcFQQn4GmhF7A8EARaC3hzCaDS+OeQAC3Sdw From: "Christian Huitema" To: "Sanjoy Sen" , "Jonathan Rosenberg" , Cc: "Patrick Sollee" , "Sean March" , "Cedric Aoun" X-OriginalArrivalTime: 08 Oct 2001 23:20:03.0481 (UTC) FILETIME=[C241B890:01C1504F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA21170 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 primary goal of the media proxy method is to allow deployment > of multimedia services in the fastest way possible without requiring > a lot of development on the application clients. The media proxy is only transparent if it is located in the immediate proximity of the firewall, e.g. in a DMZ, so that the proxy can actually send packets to the "private address" of the client. If this is not the case, then you cannot have a solution that is transparent to the client; for example, a proxy located in the middle of the network does not help you at all if yur client is located behind a residential NAT. If you want to do that, you need to use some form of tunnel between the proxy and the client, and you need to run some form of proxy control protocol, in effect a variation of the future MIDCOM protocol. It is true that the application needs to be made aware of the STUN service, but there are very high incentives for application developers to do just that: the STUN awareness can be confined to the client located behind a NAT, which means no impact on proxies or server, and very minimal impact on the remote client; the transmission can be peer-to-peer, which means that there is no need to provision a proxy and to buy extra transmission capacity for all the calls routed through it. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 9 14:01:53 2001 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 OAA10795 for ; Tue, 9 Oct 2001 14:01: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 NAA01078; Tue, 9 Oct 2001 13:45: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 NAA01053 for ; Tue, 9 Oct 2001 13:45:56 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10307 for ; Tue, 9 Oct 2001 13:45:50 -0400 (EDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id MAA06571 for ; Tue, 9 Oct 2001 12:45:24 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Tue, 9 Oct 2001 12:44:21 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Oct 2001 12:44:43 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E06F1EC@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Christian Huitema'" , Jonathan Rosenberg , midcom Cc: "Patrick Sollee" , "Sean March" , "Cedric Aoun" Subject: RE: [midcom] Submission of a new Internet draft Date: Tue, 9 Oct 2001 12:44:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C150EA.12D9AF70" 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_01C150EA.12D9AF70 Content-Type: text/plain; charset="iso-8859-1" Christian, Please see responses inline. Regards. > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Monday, October 08, 2001 6:20 PM > To: Sen, Sanjoy [NGB:B602:EXCH]; Jonathan Rosenberg; midcom > Cc: Sollee, Patrick [NGC:B610:EXCH]; March, Sean > [NGC:B642:EXCH]; Aoun, > Cedric [QPD:MA01:EXCH] > Subject: RE: [midcom] Submission of a new Internet draft > > > The media proxy is only transparent if it is located in the immediate > proximity of the firewall, e.g. in a DMZ, so that the proxy > can actually > send packets to the "private address" of the client. If this > is not the > case, then you cannot have a solution that is transparent to > the client; > for example, a proxy located in the middle of the network > does not help > you at all if yur client is located behind a residential NAT. We never claimed that the media proxy is transparent to the client, did we? The client is unaware of the differences between the media destinations. I also wanted to point out here that this is exactly what you need for legal intercept. We sure need a control protocol between the Signaling & Media proxies, but an existing device control protocol can be virtually reused. > > It is true that the application needs to be made aware of the STUN > service, but there are very high incentives for application developers > to do just that: the STUN awareness can be confined to the client > located behind a NAT, which means no impact on proxies or server, and > very minimal impact on the remote client; Yes, but there're other network elements involved such as reflectors, as well as control protocol between client-reflector and between the reflectors. Also, for types of NAT which we believe to be the most prevalent among Enterprise, you've to involve some sort of Media proxy. Not sure how much we gain here? > the transmission can be > peer-to-peer, which means that there is no need to provision > a proxy and > to buy extra transmission capacity for all the calls routed > through it. > In our case, the clients can bypass the RTP Proxy (i.e., peer-peer) when they're not behind NAT's or behind the same NAT. ------_=_NextPart_001_01C150EA.12D9AF70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Submission of a new Internet draft

Christian, Please see responses inline. = Regards.

> -----Original Message-----
> From: Christian Huitema [mailto:huitema@windows.mic= rosoft.com]
> Sent: Monday, October 08, 2001 6:20 PM
> To: Sen, Sanjoy [NGB:B602:EXCH]; Jonathan = Rosenberg; midcom
> Cc: Sollee, Patrick [NGC:B610:EXCH]; March, = Sean
> [NGC:B642:EXCH]; Aoun,
> Cedric [QPD:MA01:EXCH]
> Subject: RE: [midcom] Submission of a new = Internet draft
>
>
> The media proxy is only transparent if it is = located in the immediate
> proximity of the firewall, e.g. in a DMZ, so = that the proxy
> can actually
> send packets to the "private address" = of the client. If this
> is not the
> case, then you cannot have a solution that is = transparent to
> the client;
> for example, a proxy located in the middle of = the network
> does not help
> you at all if yur client is located behind a = residential NAT.

We never claimed that the media proxy is transparent = to the client, did we?
The client is unaware of the differences between the = media destinations. I also
wanted to point out here that this is exactly what = you need for legal intercept.
We sure need a control protocol between the = Signaling & Media proxies, but an existing device control protocol = can be virtually reused.

>
> It is true that the application needs to be = made aware of the STUN
> service, but there are very high incentives for = application developers
> to do just that: the STUN awareness can be = confined to the client
> located behind a NAT, which means no impact on = proxies or server, and
> very minimal impact on the remote client; =

Yes, but there're other network elements involved = such as reflectors, as well as control protocol between = client-reflector and between the reflectors. Also, for types of NAT = which we believe to be the most prevalent among Enterprise, you've to = involve some sort of Media proxy. Not sure how much we gain here? =

> the transmission can be
> peer-to-peer, which means that there is no need = to provision
> a proxy and
> to buy extra transmission capacity for all the = calls routed
> through it.
>

In our case, the clients can bypass the RTP Proxy = (i.e., peer-peer) when they're not behind NAT's or behind the same = NAT.



------_=_NextPart_001_01C150EA.12D9AF70-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 9 14:38:02 2001 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 OAA11396 for ; Tue, 9 Oct 2001 14:37: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 OAA02823; Tue, 9 Oct 2001 14: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 OAA02792 for ; Tue, 9 Oct 2001 14:31:34 -0400 (EDT) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11303 for ; Tue, 9 Oct 2001 14:31:29 -0400 (EDT) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.wcom.com (PMDF V5.2-33 #42260) with ESMTP id <0GKY00EGUBFQ49@firewall.wcom.com> for midcom@ietf.org; Tue, 9 Oct 2001 18:31:02 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GKY00001BFFWM@pmismtp03.wcomnet.com>; Tue, 09 Oct 2001 18:31:01 +0000 (GMT) Received: from rccc6131 ([166.35.225.46]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GKY00M7LBEP84@pmismtp03.wcomnet.com>; Tue, 09 Oct 2001 18:30:25 +0000 (GMT) Date: Tue, 09 Oct 2001 13:30:22 -0500 From: "Christopher A. Martin" Subject: RE: [midcom] pre-midcom work item In-reply-to: To: "'Jonathan Rosenberg'" , midcom@ietf.org Reply-to: christopher.a.martin@wcom.com Message-id: <008501c150f0$75e37aa0$2ee123a6@rccc6131.mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 inline > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Saturday, October 06, 2001 1:31 PM > To: 'christopher.a.martin@wcom.com'; midcom@ietf.org > Subject: RE: [midcom] pre-midcom work item > > > > > > > > -----Original Message----- > > From: Christopher A. Martin [mailto:christopher.a.martin@wcom.com] > > Sent: Friday, October 05, 2001 8:55 AM > > To: midcom@ietf.org > > Subject: RE: [midcom] pre-midcom work item > > > > > Again, this is something commonly done in proprietary protocols, > > > particularly some network games. Seems like a really good > > > idea for VoIP. It > > > needs some additional SDP work in order to function. > > > > I can see the idea of including the internal address in an > > external packet > > (in the clear) as being considered as a possible security > > risk by the IT > > community. This approach should be considered very carefully, > > since VoIP and > > gaming are two completely different animals. > > If you are concerned about revealing internal IP addresses > outside, then > that would be an issue independent if you were using games or > VoIP, right? That is correct..was just using those as an example.. the issue of divulging internal addressing is actually an item that is frowned upon by many security policies. As such we should consider this. Should I take this to the SIP mailing list to discuss this since we are talking in terms of a SIP working item arent we? > > > When addressing > > MMoIP as a > > whole one needs to remember that issues of privacy > (including internal > > topology) are key concerns with many individuals/organizations. > > I don't think its really different for gaming, if you think > about it. But in > any case, its irrelevant. If you are using nat to hide > internal addresses, > then yes, using the approach of having these two media > streams will reveal > your internal address to the outside. One can always get > around that problem > by starting with the public address, and if the call terminates on an > another internal user (known through authenticated > identities, perhaps), > then you do a re-INVITE to update to the private address. > > I do want to emphasize that all of this has nothing to do > with stun; we are > discussing an SDP extension which has not yet even been > written. Let us > first focus on the main problem at hand. Sounds good. Just wanted to bring this up now before any writing has begun. > > -Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 9 15:09:02 2001 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 PAA11769 for ; Tue, 9 Oct 2001 15:09: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 OAA03304; Tue, 9 Oct 2001 14:53:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03273 for ; Tue, 9 Oct 2001 14:53:46 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11592 for ; Tue, 9 Oct 2001 14:53:40 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TB12TV6F; Tue, 9 Oct 2001 14:53:14 -0400 Message-Id: <3.0.5.32.20011009145151.0088ce50@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 09 Oct 2001 14:51:51 -0400 To: Melinda Shore , midcom From: Mark Duffy Subject: Re: [midcom] New requirements bullets In-Reply-To: <5.1.0.14.0.20011008100418.00a3c6a0@mira-sjc5-4.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 At 10:13 AM 10/8/01 -0400, Melinda Shore wrote: > R20: As Pin-Holes may be shared across Middlebox functions, it MUST > be possible for a Pinhole-Descriptor to be created by one > function, and terminated by a different one. > >Proposal: delete. We're covered by other requirements bullets. Agreed. > R33: The relationship between a Midcom Agent and a given Middlebox > may be pre-configured through a manual configuration process or > may be established dynamically through a registration process. > In either case, depending upon the policy applied to the > Middlebox, the Middlebox MUST appropriately authenticate the > identity and credentials of the Midcom Agent seeking to make use > of its services prior to servicing any other requests from the > Midcom Agent. > >Proposal: delete anything to do with provisioning (the first part) and >change the second part so that 1) the requirement is on the protocol >and not the middlebox, 2) the requirement is the capability to do >bidirectional authentication. The choice to actually do authentication >is a question of site-local security policy. Agreed mostly. I think R33 should mention message integrity as well as authentication. > R65: Individual message authentication MUST be used in addition to > host authentication. Further message confidentiality MAY be > administered by employing techniques appropriate to Midcom > messages. Simple Source-address based security is the least > form of security and MAY be permitted only to the most trusted > hosts. > >Proposal: Again, we can't tell network administrators how to run their >networks. The protocol must support message authentication and message >confidentiality. That's it. I agree with your point. What does this mean for R65? We have already accepted R69 dealing with message confidentiality. Between R33 above and R69 I think this is covered and we can just delete R65. >Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Oct 10 10:24:15 2001 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 KAA10858 for ; Wed, 10 Oct 2001 10:24: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 KAA16327; Wed, 10 Oct 2001 10:16: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 KAA16297 for ; Wed, 10 Oct 2001 10:16:29 -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 KAA10671 for ; Wed, 10 Oct 2001 10:16:27 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f9AEDsC23602; Wed, 10 Oct 2001 07:13:54 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn2-110.cisco.com [10.21.112.110]) by airborne.cisco.com (Mirapoint) with SMTP id AAP00186; Wed, 10 Oct 2001 07:15:57 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Wed, 10 Oct 2001 10:15:52 -0400 Date: Wed, 10 Oct 2001 10:15:52 -0400 From: Scott Brim To: Cedric Aoun Cc: "'Melinda Shore'" , midcom mail-list Subject: Re: [midcom] accept R3a1 & R3a2 Message-ID: <20011010101552.S1788@SBRIM-W2K> Mail-Followup-To: Scott Brim , Cedric Aoun , 'Melinda Shore' , midcom mail-list References: <9154CB41F208D5118DD200508BE39C304452B6@zjguc006.europe.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: <9154CB41F208D5118DD200508BE39C304452B6@zjguc006.europe.nortel.com>; from CEDRIC.AOUN@nortelnetworks.com on Tue, Oct 02, 2001 at 02:40:22PM +0100 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, Oct 02, 2001 02:40:22PM +0100, Cedric Aoun allegedly wrote: > I want to stress that we need a requirement such as: The Midcom > protocol MUST work through NATs. Mechanisms such as the informant > method will not work through NATs so we should not forget this > requirement. In the case of VoIP services provided by service > providers (i.e. Telephony Service Providers), the Midcom agent might > be behind a NAT . Cedric, I think you're confused. Agents are only relevant in terms of the middleboxes they can control. In the case above, where an agent is "behind" a NAT, does it control that NAT? If so there is no problem, because they share an address space. If you're saying there is a client on one side of a NAT, and some midcom agent on the other side, and the agent does NOT control the NAT, then the agent is irrelevant and you can take it out of your picture -- what you have is the current situation, with no agent at all. (Midcom agents are distinct from application helpers.) In a situation with a simple network and no scope for a separate agent device, e.g. a home network, you provide a software "shim" to match the application. That bit of software has application-specific intelligence, and is either a simple midcom agent to control the NAT or something that speaks one of the short-term protocol approaches people are discussing now. So I don't think your objection has merit. ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Oct 10 11:58:34 2001 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 LAA12858 for ; Wed, 10 Oct 2001 11:58: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 LAA20921; Wed, 10 Oct 2001 11:57: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 LAA20890 for ; Wed, 10 Oct 2001 11:56:58 -0400 (EDT) Received: from znsgs0ja.europe.nortel.com ([47.165.25.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12829 for ; Wed, 10 Oct 2001 11:56:55 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f9AFuMg26590 for ; Wed, 10 Oct 2001 16:56:22 +0100 (BST) Received: from nwcwi1a.europe.nortel.com by znsgs016; Wed, 10 Oct 2001 16:37:12 +0100 Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <44J0R4XY>; Wed, 10 Oct 2001 16:07:09 +0100 Message-ID: <9154CB41F208D5118DD200508BE39C3044530B@zjguc006.europe.nortel.com> From: "Cedric Aoun" To: "'Scott Brim'" Cc: "'Melinda Shore'" , midcom mail-list Subject: RE: [midcom] accept R3a1 & R3a2 Date: Wed, 10 Oct 2001 16:05:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1519D.119D95A0" 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_01C1519D.119D95A0 Content-Type: text/plain; charset="iso-8859-1" Scott, The topology I have in mind is the following ++++++++++ ++++++++++ ++++++++++++ +foo.com +MB1-----+the net +-------MB2+MA bar.com+ ++++++++++ ++++++++++ +++++++++++ In case the Midcom Agent sends a Midcom request to MiddleBox1 we don't want the protocol messages to contain any IP addresses or ports relevant to the bar.com realm. This is what I actually meant. If this is a mother hood and apple pie requirement let's drop it, if it is not we have to add it to the list. Cedric -----Original Message----- From: Scott Brim [mailto:swb@employees.org] Sent: Wednesday, October 10, 2001 4:16 PM To: Aoun, Cedric [QPD:MA01:EXCH] Cc: 'Melinda Shore'; midcom mail-list Subject: Re: [midcom] accept R3a1 & R3a2 On Tue, Oct 02, 2001 02:40:22PM +0100, Cedric Aoun allegedly wrote: > I want to stress that we need a requirement such as: The Midcom > protocol MUST work through NATs. Mechanisms such as the informant > method will not work through NATs so we should not forget this > requirement. In the case of VoIP services provided by service > providers (i.e. Telephony Service Providers), the Midcom agent might > be behind a NAT . Cedric, I think you're confused. Agents are only relevant in terms of the middleboxes they can control. In the case above, where an agent is "behind" a NAT, does it control that NAT? If so there is no problem, because they share an address space. If you're saying there is a client on one side of a NAT, and some midcom agent on the other side, and the agent does NOT control the NAT, then the agent is irrelevant and you can take it out of your picture -- what you have is the current situation, with no agent at all. (Midcom agents are distinct from application helpers.) In a situation with a simple network and no scope for a separate agent device, e.g. a home network, you provide a software "shim" to match the application. That bit of software has application-specific intelligence, and is either a simple midcom agent to control the NAT or something that speaks one of the short-term protocol approaches people are discussing now. So I don't think your objection has merit. ..Scott ------_=_NextPart_001_01C1519D.119D95A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] accept R3a1 & R3a2

Scott,
The topology I have in mind is the following

 ++++++++++        = ;   ++++++++++        =      = ++++++++++++      
 +foo.com    +MB1-----+the = net      +-------MB2+MA   = bar.com+
 ++++++++++     =         = ++++++++++          &n= bsp;   +++++++++++


In case the Midcom Agent sends a Midcom request to = MiddleBox1
we don't want the protocol messages to contain any = IP addresses or ports relevant to the bar.com realm.
This is what I actually meant.

If this is a mother hood and apple pie requirement = let's drop it, if it is not we have to add it to the list.
Cedric

 
-----Original Message-----
From: Scott Brim [mailto:swb@employees.org]
Sent: Wednesday, October 10, 2001 4:16 PM
To: Aoun, Cedric [QPD:MA01:EXCH]
Cc: 'Melinda Shore'; midcom mail-list
Subject: Re: [midcom] accept R3a1 & R3a2


On Tue, Oct 02, 2001 02:40:22PM +0100, Cedric Aoun = allegedly wrote:
> I want to stress that we need a requirement = such as: The Midcom
> protocol MUST work through NATs.  = Mechanisms such as the informant
> method will not work through NATs so we should = not forget this
> requirement.  In the case of  VoIP = services provided by service
> providers (i.e. Telephony Service Providers), = the Midcom agent might
> be behind a NAT .

Cedric, I think you're confused.  Agents are = only relevant in terms of
the middleboxes they can control. 

In the case above, where an agent is = "behind" a NAT, does it control
that NAT?  If so there is no problem, because = they share an address
space. 

If you're saying there is a client on one side of a = NAT, and some midcom
agent on the other side, and the agent does NOT = control the NAT, then
the agent is irrelevant and you can take it out of = your picture -- what
you have is the current situation, with no agent at = all.  (Midcom agents
are distinct from application helpers.)

In a situation with a simple network and no scope for = a separate agent
device, e.g. a home network, you provide a software = "shim" to match the
application.  That bit of software has = application-specific
intelligence, and is either a simple midcom agent to = control the NAT or
something that speaks one of the short-term protocol = approaches people
are discussing now.

So I don't think your objection has merit.

..Scott

------_=_NextPart_001_01C1519D.119D95A0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Oct 10 12:31:02 2001 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 MAA13845 for ; Wed, 10 Oct 2001 12:31: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 MAA22894; Wed, 10 Oct 2001 12:28: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 MAA22866 for ; Wed, 10 Oct 2001 12:28:26 -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 MAA13665 for ; Wed, 10 Oct 2001 12:28:23 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f9AGPnC05611; Wed, 10 Oct 2001 09:25:50 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn2-110.cisco.com [10.21.112.110]) by airborne.cisco.com (Mirapoint) with SMTP id AAQ00540; Wed, 10 Oct 2001 09:27:52 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Wed, 10 Oct 2001 12:27:47 -0400 Date: Wed, 10 Oct 2001 12:27:47 -0400 From: Scott Brim To: Cedric Aoun Cc: "'Melinda Shore'" , midcom mail-list Subject: Re: [midcom] accept R3a1 & R3a2 Message-ID: <20011010122746.U1788@SBRIM-W2K> Mail-Followup-To: Scott Brim , Cedric Aoun , 'Melinda Shore' , midcom mail-list References: <9154CB41F208D5118DD200508BE39C3044530B@zjguc006.europe.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: <9154CB41F208D5118DD200508BE39C3044530B@zjguc006.europe.nortel.com>; from CEDRIC.AOUN@nortelnetworks.com on Wed, Oct 10, 2001 at 04:05:59PM +0100 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, Oct 10, 2001 04:05:59PM +0100, Cedric Aoun allegedly wrote: > Scott, > The topology I have in mind is the following > > ++++++++++ ++++++++++ ++++++++++++ > +foo.com +MB1-----+the net +-------MB2+MA bar.com+ > ++++++++++ ++++++++++ +++++++++++ > > > In case the Midcom Agent sends a Midcom request to MiddleBox1 > we don't want the protocol messages to contain any IP addresses or ports > relevant to the bar.com realm. > This is what I actually meant. As long as the MA in the picture is a midcom agent, not an application helper of some sort, I have trouble believing this scenario would be deployed in real life. Can any ISP (not vendor) out there give any example of where they would want such a scenario? We're talking about a security relationship between agent and middlebox crossing a NAT. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Oct 11 06:41:29 2001 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 GAA14343 for ; Thu, 11 Oct 2001 06:41: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 GAA01368; Thu, 11 Oct 2001 06:38: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 GAA01337 for ; Thu, 11 Oct 2001 06:38:33 -0400 (EDT) Received: from znsgs0ja.europe.nortel.com ([47.165.25.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14330 for ; Thu, 11 Oct 2001 06:38:32 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f9BAc4g29688 for ; Thu, 11 Oct 2001 11:38:04 +0100 (BST) Received: from nwcwi1a.europe.nortel.com by znsgs016; Thu, 11 Oct 2001 11:37:38 +0100 Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <44J0SDK0>; Thu, 11 Oct 2001 11:37:18 +0100 Message-ID: <9154CB41F208D5118DD200508BE39C30445312@zjguc006.europe.nortel.com> From: "Cedric Aoun" To: "'Scott Brim'" Cc: "'Melinda Shore'" , midcom mail-list Subject: RE: [midcom] accept R3a1 & R3a2 Date: Thu, 11 Oct 2001 11:37:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15240.B1165560" 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_01C15240.B1165560 Content-Type: text/plain; charset="iso-8859-1" Scott, In the context of carrier managed services, the Telephony Service Provider (TSP) will put Media GateWays (MGW) in the customer premise. The MGWs will be controlled by Media Gateway Controllers (MGC) that are located in the TSP. The Midcom Agent (MA) will be co-hosted with the MGC instance. When you are running several hundred thousands (even millions) of calls, obviously we are not talking of a couple of IP addresses for the MGC instances. Depending on your assigned registered address space, you might want to assign private addresses to your MGC instances, therefore you will need to NAT the application signaling messages. Does it make any sense? Cedric -----Original Message----- From: Scott Brim [mailto:swb@employees.org] Sent: Wednesday, October 10, 2001 6:28 PM To: Aoun, Cedric [QPD:MA01:EXCH] Cc: 'Melinda Shore'; midcom mail-list Subject: Re: [midcom] accept R3a1 & R3a2 On Wed, Oct 10, 2001 04:05:59PM +0100, Cedric Aoun allegedly wrote: > Scott, > The topology I have in mind is the following > > ++++++++++ ++++++++++ ++++++++++++ > +foo.com +MB1-----+the net +-------MB2+MA bar.com+ > ++++++++++ ++++++++++ +++++++++++ > > > In case the Midcom Agent sends a Midcom request to MiddleBox1 > we don't want the protocol messages to contain any IP addresses or ports > relevant to the bar.com realm. > This is what I actually meant. As long as the MA in the picture is a midcom agent, not an application helper of some sort, I have trouble believing this scenario would be deployed in real life. Can any ISP (not vendor) out there give any example of where they would want such a scenario? We're talking about a security relationship between agent and middlebox crossing a NAT. ------_=_NextPart_001_01C15240.B1165560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] accept R3a1 & R3a2

Scott,
In the context of carrier managed services, the = Telephony Service Provider (TSP)
 will put Media GateWays (MGW) in the customer = premise.
The MGWs will be controlled by Media Gateway = Controllers (MGC) that are located in the TSP.
The Midcom Agent (MA) will be co-hosted with the MGC = instance.

When you are running several hundred thousands (even = millions) of calls, obviously we are not talking of a couple of IP = addresses for the MGC instances. Depending on your assigned registered = address space, you might want to assign private addresses to your MGC = instances, therefore you will need to NAT the application signaling = messages.

Does it make any sense?
Cedric

-----Original Message-----
From: Scott Brim [mailto:swb@employees.org]
Sent: Wednesday, October 10, 2001 6:28 PM
To: Aoun, Cedric [QPD:MA01:EXCH]
Cc: 'Melinda Shore'; midcom mail-list
Subject: Re: [midcom] accept R3a1 & R3a2


On Wed, Oct 10, 2001 04:05:59PM +0100, Cedric Aoun = allegedly wrote:
> Scott,
> The topology I have in mind is the = following
>
>  = ++++++++++           = ++++++++++           = ++++++++++++      
>  +foo.com    +MB1-----+the = net      +-------MB2+MA   = bar.com+
>  ++++++++++   =         = ++++++++++          &n= bsp;   +++++++++++
>
>
> In case the Midcom Agent sends a Midcom request = to MiddleBox1
> we don't want the protocol messages to contain = any IP addresses or ports
> relevant to the bar.com realm.
> This is what I actually meant.

As long as the MA in the picture is a midcom agent, = not an application
helper of some sort, I have trouble believing this = scenario would be
deployed in real life. 

Can any ISP (not vendor) out there give any example = of where they would
want such a scenario?  We're talking about a = security relationship
between agent and middlebox crossing a NAT.

------_=_NextPart_001_01C15240.B1165560-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Oct 11 09:27:10 2001 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 JAA15935 for ; Thu, 11 Oct 2001 09:27: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 JAA05866; Thu, 11 Oct 2001 09:25: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 JAA05834 for ; Thu, 11 Oct 2001 09:25:17 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15897 for ; Thu, 11 Oct 2001 09:25:17 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9BDNd8P013957; Thu, 11 Oct 2001 09:23:39 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <4QPLLCCT>; Thu, 11 Oct 2001 09:24:46 -0400 Message-ID: From: Jonathan Rosenberg To: "'christopher.a.martin@wcom.com'" , Jonathan Rosenberg , midcom@ietf.org Subject: RE: [midcom] pre-midcom work item Date: Thu, 11 Oct 2001 09:24:45 -0400 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 > -----Original Message----- > From: Christopher A. Martin [mailto:christopher.a.martin@wcom.com] > Sent: Tuesday, October 09, 2001 2:30 PM > To: 'Jonathan Rosenberg'; midcom@ietf.org > Subject: RE: [midcom] pre-midcom work item > > > > I can see the idea of including the internal address in an > > > external packet > > > (in the clear) as being considered as a possible security > > > risk by the IT > > > community. This approach should be considered very carefully, > > > since VoIP and > > > gaming are two completely different animals. > > > > If you are concerned about revealing internal IP addresses > > outside, then > > that would be an issue independent if you were using games or > > VoIP, right? > > That is correct..was just using those as an example.. the > issue of divulging > internal addressing is actually an item that is frowned upon by many > security policies. As such we should consider this. Should I > take this to > the SIP mailing list to discuss this since we are talking in > terms of a SIP > working item arent we? Its an mmusic thing, actually. Now is a good time, since a related thread has just started - on including both v6 and v4 addresses in SDP as alternate addresses for the same media stream. Same problem here. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Oct 11 09:56:12 2001 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 JAA16537 for ; Thu, 11 Oct 2001 09:56: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 JAA06922; Thu, 11 Oct 2001 09:49: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 JAA06893 for ; Thu, 11 Oct 2001 09:49:09 -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 JAA16450 for ; Thu, 11 Oct 2001 09:49:08 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f9BDfxC20360; Thu, 11 Oct 2001 06:44:01 -0700 (PDT) Received: from SBRIM-W2K (ssh-sj1.cisco.com [171.68.225.134]) by airborne.cisco.com (Mirapoint) with SMTP id AAQ14327; Thu, 11 Oct 2001 06:44:02 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Thu, 11 Oct 2001 09:44:10 -0400 Date: Thu, 11 Oct 2001 09:44:10 -0400 From: Scott Brim To: Cedric Aoun Cc: "'Melinda Shore'" , midcom mail-list Subject: Re: [midcom] accept R3a1 & R3a2 Message-ID: <20011011094410.F1216@SBRIM-W2K> Mail-Followup-To: Scott Brim , Cedric Aoun , 'Melinda Shore' , midcom mail-list References: <9154CB41F208D5118DD200508BE39C30445312@zjguc006.europe.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: <9154CB41F208D5118DD200508BE39C30445312@zjguc006.europe.nortel.com>; from CEDRIC.AOUN@nortelnetworks.com on Thu, Oct 11, 2001 at 11:37:14AM +0100 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, Oct 11, 2001 11:37:14AM +0100, Cedric Aoun allegedly wrote: > Scott, > In the context of carrier managed services, the Telephony Service Provider > (TSP) > will put Media GateWays (MGW) in the customer premise. > The MGWs will be controlled by Media Gateway Controllers (MGC) that are > located in the TSP. > The Midcom Agent (MA) will be co-hosted with the MGC instance. > > When you are running several hundred thousands (even millions) of calls, > obviously we are not talking of a couple of IP addresses for the MGC > instances. Depending on your assigned registered address space, you might > want to assign private addresses to your MGC instances, therefore you will > need to NAT the application signaling messages. > > Does it make any sense? Yes. The NAT and its controlling Midcom Agent share an address space. The *midcom* messages don't have to go through a NAT. The application signaling does -- but that's why we're doing this midcom thing in the first place. I see no problem. > Cedric > > -----Original Message----- > From: Scott Brim [mailto:swb@employees.org] > Sent: Wednesday, October 10, 2001 6:28 PM > To: Aoun, Cedric [QPD:MA01:EXCH] > Cc: 'Melinda Shore'; midcom mail-list > Subject: Re: [midcom] accept R3a1 & R3a2 > > > On Wed, Oct 10, 2001 04:05:59PM +0100, Cedric Aoun allegedly wrote: > > Scott, > > The topology I have in mind is the following > > > > ++++++++++ ++++++++++ ++++++++++++ > > +foo.com +MB1-----+the net +-------MB2+MA bar.com+ > > ++++++++++ ++++++++++ +++++++++++ > > > > > > In case the Midcom Agent sends a Midcom request to MiddleBox1 > > we don't want the protocol messages to contain any IP addresses or ports > > relevant to the bar.com realm. > > This is what I actually meant. > > As long as the MA in the picture is a midcom agent, not an application > helper of some sort, I have trouble believing this scenario would be > deployed in real life. > > Can any ISP (not vendor) out there give any example of where they would > want such a scenario? We're talking about a security relationship > between agent and middlebox crossing a NAT. > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Oct 11 10:03:52 2001 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 KAA16639 for ; Thu, 11 Oct 2001 10:03: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 KAA07569; Thu, 11 Oct 2001 10:01: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 KAA07542 for ; Thu, 11 Oct 2001 10:01:57 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16629 for ; Thu, 11 Oct 2001 10:01:56 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9BE0B8P014359; Thu, 11 Oct 2001 10:00:11 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <4QPLLC22>; Thu, 11 Oct 2001 10:01:18 -0400 Message-ID: From: Jonathan Rosenberg To: "'Sanjoy Sen'" , Jonathan Rosenberg , midcom@ietf.org Cc: Patrick Sollee , Sean March , Cedric Aoun Subject: RE: [midcom] Submission of a new Internet draft Date: Thu, 11 Oct 2001 10:01:16 -0400 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 Inline. -----Original Message----- From: Sanjoy Sen [mailto:sanjoy@nortelnetworks.com] Sent: Monday, October 08, 2001 5:18 PM To: 'Jonathan Rosenberg'; midcom@ietf.org Cc: Patrick Sollee; Sean March; Cedric Aoun Subject: RE: [midcom] Submission of a new Internet draft >> First off, please note that your draft requires the end >> systems to support >> symmetric RTP. You don't explicitly state that, but since you have the >> clients "priming" the nats by sending RTP packets to the RTP >> proxy, with the >> media going back to the source address. That is not normal >> RTP behavior, but >> is what we call symmetric RTP. You can tell its symmetric RTP >> since, in your >> proposal, the IP/port in the SDP sent from the client is >> actually never used >> by the RTP proxy to figure out where to send media. > >Yes, but the only restriction is send & receive ports are the same, which is easily >configurable in the majority of the VoIP clients available today. But having the RTP >Proxy in between allows us to avoid any SDP extensions (needed for Symmetric RTP) needed >to tell the "passive" entity to send the RTP packets to the source address of the >received RTP packets. > >The primary goal of the media proxy method is to allow deployment of multimedia services >in the fastest way possible without requiring a lot of development on the application >clients. Well, you are already requiring changes to the clients for the SIP extensions. Once you need to touch them even a drop, there is not much pain for additional changes. >> >> The mechanism you describe in this draft is largely the same >> as what we >> proposed in draft-rosenberg-sip-entfw-01.txt (NOT the current >> -02 version, >> which is much different), which had the proxies performing >> the rewrites of >> the SDP as you describe. >Quite similar. However, the draft talks about supporting SDP extensions for Bi- >directional RTP which we don't need to. And the reason for that is that you are using an external intermediary so long as either of the parties is behind any kind of nat. This is really the fundamental issue. My goal is to provide a solution that is cheap for providers to deploy, and provides acceptable voice quality to users. To me, that means I avoid triangle routing of media to the provider's network, which is both expensive and can add a huge amount of delay. It also gets in the way of things like SRTP, which would not be possible end-to-end with your solution. In our solution, we end up with an intermediary ONLY when both sides are behind symmetric NATs, which is a much much smaller subset of cases. In fact, if you take the pain of always going through an intermediary, there are even simpler solutions than yours. Just use a VPN, for example. THis way, the client sends all media and signaling through a VPN server in the providers network, and the VPN would provide the client with a publically routable IP on the VPN server. Problem solved, and we could do it without touching the clients. Why is this a bad solution? Well, the provider now needs to handle all this RTP traffic through the VPN server, and voice latencies will frequently be bad. Same with your approach. >To ease complexity, the following rules are used: >1. The SIP BBUA supports multiple domains. >2. All media for cross domain calls uses the RTP proxy. Which will indeed result in two intermediaries for cross-domain calls where both sides are natted. >> It gets really complicated when you add, as a goal, direct media >> communications whenever possible. In your proposal, media always flows >> through this intermediary. Since the location of that device >> is generally >> going to be physically uncorrelated with the location of the >> endpoints, >> media latency can suffer a LOT. As such, you really only want >> that thing in >> there when its needed. If you want to ensure direct media >> whenever possible, >> then you get into further complications of making decisions >> based on which >> type of nats there are. We came up with on the order of 100 >> different cases >> that needed to be considered (something like 7 different >> yes/no orthogonal >> variables). > >Media does not always flow through the RTP Proxy. If the endpoints are in the same >domain, and are behind the same NAT/FW, then media does not traverse the RTP Proxy. I think you will find that determination of this (whether both endpoints are behind the same NAT) is a very nontrivial exercise. I think you have a centrex-style model in mind for this, where you can tell by the domains in the From and To fields whether both are behind the same nat. That won't work in dozens and dozens of cases. The most basic case is where I am behind an enterprise nat, and am using service from a retail provider (say, foo.com), so that my address is sip:jdrosen@foo.com. If I call someone else who also has a foo.com address, but who works in a different enterprise, how, per se, will the foo.com proxy know whether we are behind the same nat (which we're not in this case) or a different one? >> The approach you propose also requires that there are call >> stateful B2BUAs >> in each call path, which has significant impacts on >> performance and fault >> tolerance in particular. The cost to the VoIP provider is >> VERY high from >> this solution, because of all the additional rtp traffic that >> comes in, and >> back out. > >The cost is primarily a management issue from the Service Provider perspective. That is false. It is false because you have made an unreasonable assumption about topological and geographical proximity, see below. >The only >requirement is that the SIP Proxy will find the Media Proxy closest to the UA. The voice >quality issue is negligible because the Media Proxy is expected to be in the Service >Provider (or even within the Enterprise) network close to the end-users. That is a monstrous assumption that will almost always NOT be true. Your assumption is a specific centrex-like model where the provider contracts with the enterprise, so that they can place an RTP proxy near the enterprise nat, but on the public side of it. That is a very specific, very narrow case, and will not work for any kind of retail model. Much more common will be when you have a retail provider (like net2phone, dialpad, deltathree, etc.) who signs up customers. The provider has no relationship with the enterprise (if there even is one, remember residential users!). They don't know the network topology. How is the provider to select an RTP proxy that is topologically and geopraphically close to the subscriber?? That is a known HARD problem, and I would assert that the costs of solving it are profound (requiring deployment of a network similar to Akamai in order to do this). How can you realistically claim that this is not prohibitively expensive? Even without a distributed RTP proxy network like this, its expensive. The more likely case is that the provider has a farm of RTP proxies in their primary data center (say, in San Jose). This means that a call from me to my neighbor will go from New Jersey, to San Jose, and back to Jersey. That adds substantial latencies, and is also expensive for the provider. Now, they need to by enough bandwidth in the S.J. data center to support twice the bandwidth (in and out) for each simultenaous call they would ever carry! How can you claim that is not expensive? Compare that to the alternative where, using stun, almost no traffic flows through an intermediary (and arguably, you might not even bother with one). Thus, you need only be a signaling point, not a media transit point. Much cheaper, much lower latency. >Also, a stun-like protocol will need more software upgrades on the Enterprise clients, >which has >cost disadvantages too. Doesn't it? You are already doing that even in your solution. There are not so many SIP clients deployed at this time in any case. Let us do it right while we still can. >The real tradeoff here is how much intelligence you want to put in the client as opposed >to >that in the network. Our solution is "simple" and "dumb" in the sense that neither the >client >nor the Proxy need to know about the Enterprise NAT binds or types. It eliminates the >need for SDP extensions for Symmetric RTP and a few of the SIP extensions (e.g., NAT >type). The tradeoff is against the performance impact on the network, which has been >discussed earlier. You are already changing the client. You are changing the proxies. Whether you change them "more" with a few additional capabilities is irrelevant in terms of total cost. However, the operational cost of your solution is high, whereas it is nearly zero in our proposal. > Also, our solution is targeted primarily for Enterprise customers >(although applicable for residential too), I would like to know how you have solved the problem of locating RTP proxies close to residential users. for whom we believe something like a Full Cone >NAT (alone) does not make a great deal of sense. The most prevalent (we believe to be > >90%) cases will be Restricted Cone NAT's and Symmetric NAT's, both of which will need RTP >Proxy-like devices. That is not a consistent assessment from what I have heard from people who have actually tested them. I hear its about 30% full cone, 40% restricted cone. >> As such, our approach is truly a client discovery mechanism, which is >> EXACTLY how it would work if midcom were deployed. If midcom >> were in place, >> the client would talk to its enterprise/residential NAT, obtain some >> addresses, and put those in SDP. > >It depends on where the Midcom Agent resides - the client or the Proxy. Midcom would also >allow the Proxy to do all these things transparently for the client, which is also >desirable. In your solution, there are two nats - the residential/enterprise one, and the "RTP proxy" which is effectively a nat as well. You are using midcom from your sip B2BUA to that media proxy, but there is no midcom type of solution for the first nat. My point is, if midcom were deployed, we would not use your solution at all. The client would talk to its enterprise/residential nat, and obtain a binding, and put that in its SDP in the INVITE. There would be no RTP proxy. Our approach mirrors what the solution would be if we had midcom, but I talk through the nat, instead of to it. >> STUn also allows other applications to work, just as midcom will. > >The usage of the media proxies do not limit the application to SIP. It limits it to applications that use media proxies. For H.323, you could reuse them, but you'd need to upgrade your gatekeepers to do this. It would not be useful at all for games, for example. That is not true for stun. Stun is just as useful for a game where I need to receive UDP updates of game moves. It works even when there is no network server at all (like gnutella), and it requires NO relationship between the stun server and the application. Indeed, people with public IP connectivity could simply deploy stun servers as a public service, to assist people in discovering and dealing with their nat connectivity. Stun also helps with diagnostics, and allows you to launch a complaint against a provider or vendor for deploying a nat when you didn't think there should be one of that type. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Oct 11 12:32:49 2001 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 MAA19309 for ; Thu, 11 Oct 2001 12:32: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 MAA12928; Thu, 11 Oct 2001 12:16: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 MAA12846 for ; Thu, 11 Oct 2001 12:16:48 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18937 for ; Thu, 11 Oct 2001 12:16:45 -0400 (EDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id LAA07125 for ; Thu, 11 Oct 2001 11:16:19 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Thu, 11 Oct 2001 11:15:28 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Oct 2001 11:15:54 -0500 Message-ID: From: "Patrick Sollee" To: "'Jonathan Rosenberg'" , "Sanjoy Sen" , midcom@ietf.org Cc: "Sean March" , "Cedric Aoun" Subject: RE: [midcom] Submission of a new Internet draft Date: Thu, 11 Oct 2001 11:15:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15270.005C2C60" 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_01C15270.005C2C60 Content-Type: text/plain; charset="iso-8859-1" Jonathan, As you say, your proposal requires an intermediatary when symmetric NATs are used. Most enterprises have firewalls in addition to NATs. These firewalls, when "UDP conversations" are activated, function in a similar way to symetric NATs. (allow inbound traffic only from IP+Port where traffic was sent to). If both domains in a cross domain call are hosted by the same service provider then only 1 RTP Proxy is used. Each endpoint is responsible for knowing if it is behind a firewall/NAT. This is done during configuration of the endpoint. If a single domain spans multiple different IP address space, then that domain is configured to route all media via the RTP Proxy. We have observed that the most common case, though, is a particular enterprise has one domain, and the devices within that domain are in the same IP address space. This allows media to stay within the enterprise (not use the RTP Proxy). Determining which RTP Proxy to use based on the location of the client is a difficult issue in the pure residential case. However, it is not difficult in the enterprise case. As for delays encountered when using the RTP Proxy, an argument could be made that it will be less, since the path from the ISPs to the SIP telephony provider would be well known, and hence provisioned with large bandwidth. As opposed to the path directly from one endpoint to another, where the path travers many hops. In addition, once the media traffic hits the SIP telephony provider, it will be treated with greater care (less hops, more bandwidth) than it would be treated on the internet. Thanks, Pat -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Thursday, October 11, 2001 9:01 AM To: Sen, Sanjoy [NGB:B602:EXCH]; Jonathan Rosenberg; midcom@ietf.org Cc: Sollee, Patrick [NGC:B610:EXCH]; March, Sean [NGC:B642:EXCH]; Aoun, Cedric [QPD:MA01:EXCH] Subject: RE: [midcom] Submission of a new Internet draft Inline. -----Original Message----- From: Sanjoy Sen [mailto:sanjoy@nortelnetworks.com] Sent: Monday, October 08, 2001 5:18 PM To: 'Jonathan Rosenberg'; midcom@ietf.org Cc: Patrick Sollee; Sean March; Cedric Aoun Subject: RE: [midcom] Submission of a new Internet draft >> First off, please note that your draft requires the end >> systems to support >> symmetric RTP. You don't explicitly state that, but since you have the >> clients "priming" the nats by sending RTP packets to the RTP >> proxy, with the >> media going back to the source address. That is not normal >> RTP behavior, but >> is what we call symmetric RTP. You can tell its symmetric RTP >> since, in your >> proposal, the IP/port in the SDP sent from the client is >> actually never used >> by the RTP proxy to figure out where to send media. > >Yes, but the only restriction is send & receive ports are the same, which is easily >configurable in the majority of the VoIP clients available today. But having the RTP >Proxy in between allows us to avoid any SDP extensions (needed for Symmetric RTP) needed >to tell the "passive" entity to send the RTP packets to the source address of the >received RTP packets. > >The primary goal of the media proxy method is to allow deployment of multimedia services >in the fastest way possible without requiring a lot of development on the application >clients. Well, you are already requiring changes to the clients for the SIP extensions. Once you need to touch them even a drop, there is not much pain for additional changes. >> >> The mechanism you describe in this draft is largely the same >> as what we >> proposed in draft-rosenberg-sip-entfw-01.txt (NOT the current >> -02 version, >> which is much different), which had the proxies performing >> the rewrites of >> the SDP as you describe. >Quite similar. However, the draft talks about supporting SDP extensions for Bi- >directional RTP which we don't need to. And the reason for that is that you are using an external intermediary so long as either of the parties is behind any kind of nat. This is really the fundamental issue. My goal is to provide a solution that is cheap for providers to deploy, and provides acceptable voice quality to users. To me, that means I avoid triangle routing of media to the provider's network, which is both expensive and can add a huge amount of delay. It also gets in the way of things like SRTP, which would not be possible end-to-end with your solution. In our solution, we end up with an intermediary ONLY when both sides are behind symmetric NATs, which is a much much smaller subset of cases. In fact, if you take the pain of always going through an intermediary, there are even simpler solutions than yours. Just use a VPN, for example. THis way, the client sends all media and signaling through a VPN server in the providers network, and the VPN would provide the client with a publically routable IP on the VPN server. Problem solved, and we could do it without touching the clients. Why is this a bad solution? Well, the provider now needs to handle all this RTP traffic through the VPN server, and voice latencies will frequently be bad. Same with your approach. >To ease complexity, the following rules are used: >1. The SIP BBUA supports multiple domains. >2. All media for cross domain calls uses the RTP proxy. Which will indeed result in two intermediaries for cross-domain calls where both sides are natted. >> It gets really complicated when you add, as a goal, direct media >> communications whenever possible. In your proposal, media always flows >> through this intermediary. Since the location of that device >> is generally >> going to be physically uncorrelated with the location of the >> endpoints, >> media latency can suffer a LOT. As such, you really only want >> that thing in >> there when its needed. If you want to ensure direct media >> whenever possible, >> then you get into further complications of making decisions >> based on which >> type of nats there are. We came up with on the order of 100 >> different cases >> that needed to be considered (something like 7 different >> yes/no orthogonal >> variables). > >Media does not always flow through the RTP Proxy. If the endpoints are in the same >domain, and are behind the same NAT/FW, then media does not traverse the RTP Proxy. I think you will find that determination of this (whether both endpoints are behind the same NAT) is a very nontrivial exercise. I think you have a centrex-style model in mind for this, where you can tell by the domains in the From and To fields whether both are behind the same nat. That won't work in dozens and dozens of cases. The most basic case is where I am behind an enterprise nat, and am using service from a retail provider (say, foo.com), so that my address is sip:jdrosen@foo.com. If I call someone else who also has a foo.com address, but who works in a different enterprise, how, per se, will the foo.com proxy know whether we are behind the same nat (which we're not in this case) or a different one? >> The approach you propose also requires that there are call >> stateful B2BUAs >> in each call path, which has significant impacts on >> performance and fault >> tolerance in particular. The cost to the VoIP provider is >> VERY high from >> this solution, because of all the additional rtp traffic that >> comes in, and >> back out. > >The cost is primarily a management issue from the Service Provider perspective. That is false. It is false because you have made an unreasonable assumption about topological and geographical proximity, see below. >The only >requirement is that the SIP Proxy will find the Media Proxy closest to the UA. The voice >quality issue is negligible because the Media Proxy is expected to be in the Service >Provider (or even within the Enterprise) network close to the end-users. That is a monstrous assumption that will almost always NOT be true. Your assumption is a specific centrex-like model where the provider contracts with the enterprise, so that they can place an RTP proxy near the enterprise nat, but on the public side of it. That is a very specific, very narrow case, and will not work for any kind of retail model. Much more common will be when you have a retail provider (like net2phone, dialpad, deltathree, etc.) who signs up customers. The provider has no relationship with the enterprise (if there even is one, remember residential users!). They don't know the network topology. How is the provider to select an RTP proxy that is topologically and geopraphically close to the subscriber?? That is a known HARD problem, and I would assert that the costs of solving it are profound (requiring deployment of a network similar to Akamai in order to do this). How can you realistically claim that this is not prohibitively expensive? Even without a distributed RTP proxy network like this, its expensive. The more likely case is that the provider has a farm of RTP proxies in their primary data center (say, in San Jose). This means that a call from me to my neighbor will go from New Jersey, to San Jose, and back to Jersey. That adds substantial latencies, and is also expensive for the provider. Now, they need to by enough bandwidth in the S.J. data center to support twice the bandwidth (in and out) for each simultenaous call they would ever carry! How can you claim that is not expensive? Compare that to the alternative where, using stun, almost no traffic flows through an intermediary (and arguably, you might not even bother with one). Thus, you need only be a signaling point, not a media transit point. Much cheaper, much lower latency. >Also, a stun-like protocol will need more software upgrades on the Enterprise clients, >which has >cost disadvantages too. Doesn't it? You are already doing that even in your solution. There are not so many SIP clients deployed at this time in any case. Let us do it right while we still can. >The real tradeoff here is how much intelligence you want to put in the client as opposed >to >that in the network. Our solution is "simple" and "dumb" in the sense that neither the >client >nor the Proxy need to know about the Enterprise NAT binds or types. It eliminates the >need for SDP extensions for Symmetric RTP and a few of the SIP extensions (e.g., NAT >type). The tradeoff is against the performance impact on the network, which has been >discussed earlier. You are already changing the client. You are changing the proxies. Whether you change them "more" with a few additional capabilities is irrelevant in terms of total cost. However, the operational cost of your solution is high, whereas it is nearly zero in our proposal. > Also, our solution is targeted primarily for Enterprise customers >(although applicable for residential too), I would like to know how you have solved the problem of locating RTP proxies close to residential users. for whom we believe something like a Full Cone >NAT (alone) does not make a great deal of sense. The most prevalent (we believe to be > >90%) cases will be Restricted Cone NAT's and Symmetric NAT's, both of which will need RTP >Proxy-like devices. That is not a consistent assessment from what I have heard from people who have actually tested them. I hear its about 30% full cone, 40% restricted cone. >> As such, our approach is truly a client discovery mechanism, which is >> EXACTLY how it would work if midcom were deployed. If midcom >> were in place, >> the client would talk to its enterprise/residential NAT, obtain some >> addresses, and put those in SDP. > >It depends on where the Midcom Agent resides - the client or the Proxy. Midcom would also >allow the Proxy to do all these things transparently for the client, which is also >desirable. In your solution, there are two nats - the residential/enterprise one, and the "RTP proxy" which is effectively a nat as well. You are using midcom from your sip B2BUA to that media proxy, but there is no midcom type of solution for the first nat. My point is, if midcom were deployed, we would not use your solution at all. The client would talk to its enterprise/residential nat, and obtain a binding, and put that in its SDP in the INVITE. There would be no RTP proxy. Our approach mirrors what the solution would be if we had midcom, but I talk through the nat, instead of to it. >> STUn also allows other applications to work, just as midcom will. > >The usage of the media proxies do not limit the application to SIP. It limits it to applications that use media proxies. For H.323, you could reuse them, but you'd need to upgrade your gatekeepers to do this. It would not be useful at all for games, for example. That is not true for stun. Stun is just as useful for a game where I need to receive UDP updates of game moves. It works even when there is no network server at all (like gnutella), and it requires NO relationship between the stun server and the application. Indeed, people with public IP connectivity could simply deploy stun servers as a public service, to assist people in discovering and dealing with their nat connectivity. Stun also helps with diagnostics, and allows you to launch a complaint against a provider or vendor for deploying a nat when you didn't think there should be one of that type. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com ------_=_NextPart_001_01C15270.005C2C60 Content-Type: text/html; charset="iso-8859-1" RE: [midcom] Submission of a new Internet draft

Jonathan,

As you say, your proposal requires an intermediatary when
symmetric NATs are used. Most enterprises have firewalls in
addition to NATs.  These firewalls, when "UDP conversations"
are activated, function in a similar way to symetric NATs.
(allow inbound traffic only from IP+Port where traffic was
sent to).

If both domains in a cross domain call are hosted by the same
service provider then only 1 RTP Proxy is used.

Each endpoint is responsible for knowing if it is behind a
firewall/NAT. This is done during configuration of the
endpoint.  If a single domain spans multiple different
IP address space, then that domain is configured to route
all media via the RTP Proxy. We have observed that the most
common case, though, is a particular enterprise has one domain, and
the devices within that domain are in the same IP address
space. This allows media to stay within the enterprise (not
use the RTP Proxy).

Determining which RTP Proxy to use based on the location of the
client is a difficult issue in the pure residential case. However,
it is not difficult in the enterprise case.

As for delays encountered when using the RTP Proxy, an argument
could be made that it will be less, since the path from the ISPs
to the SIP telephony provider would be well known, and hence
provisioned with large bandwidth. As opposed to the path directly
from one endpoint to another, where the path travers many hops.
In addition, once the media traffic hits the SIP telephony provider,
it will be treated with greater care (less hops, more bandwidth) than
it would be treated on the internet.

Thanks,
Pat


-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Thursday, October 11, 2001 9:01 AM
To: Sen, Sanjoy [NGB:B602:EXCH]; Jonathan Rosenberg; midcom@ietf.org
Cc: Sollee, Patrick [NGC:B610:EXCH]; March, Sean [NGC:B642:EXCH]; Aoun,
Cedric [QPD:MA01:EXCH]
Subject: RE: [midcom] Submission of a new Internet draft


Inline.

 
-----Original Message-----
From: Sanjoy Sen [mailto:sanjoy@nortelnetworks.com]
Sent: Monday, October 08, 2001 5:18 PM
To: 'Jonathan Rosenberg'; midcom@ietf.org
Cc: Patrick Sollee; Sean March; Cedric Aoun
Subject: RE: [midcom] Submission of a new Internet draft

>> First off, please note that your draft requires the end
>> systems to support
>> symmetric RTP. You don't explicitly state that, but since you have the
>> clients "priming" the nats by sending RTP packets to the RTP
>> proxy, with the
>> media going back to the source address. That is not normal
>> RTP behavior, but
>> is what we call symmetric RTP. You can tell its symmetric RTP
>> since, in your
>> proposal, the IP/port in the SDP sent from the client is
>> actually never used
>> by the RTP proxy to figure out where to send media.
>
>Yes, but the only restriction is send & receive ports are the same, which
is easily
>configurable in the majority of the VoIP clients available today. But
having the RTP
>Proxy in between allows us to avoid any SDP extensions (needed for
Symmetric RTP) needed
>to tell the "passive" entity to send the RTP packets to the source address
of the
>received RTP packets.
>
>The primary goal of the media proxy method is to allow deployment of
multimedia services
>in the fastest way possible without requiring a lot of development on the
application
>clients.

Well, you are already requiring changes to the clients for the SIP
extensions. Once you need to touch them even a drop, there is not much pain
for additional changes.



>>
>> The mechanism you describe in this draft is largely the same
>> as what we
>> proposed in draft-rosenberg-sip-entfw-01.txt (NOT the current
>> -02 version,
>> which is much different), which had the proxies performing
>> the rewrites of
>> the SDP as you describe.
>Quite similar. However, the draft talks about supporting SDP extensions for
Bi-
>directional RTP which we don't need to.

And the reason for that is that you are using an external intermediary so
long as either of the parties is behind any kind of nat. This is really the
fundamental issue. My goal is to provide a solution that is cheap for
providers to deploy, and provides acceptable voice quality to users. To me,
that means I avoid triangle routing of media to the provider's network,
which is both expensive and can add a huge amount of delay. It also gets in
the way of things like SRTP, which would not be possible end-to-end with
your solution. In our solution, we end up with an intermediary ONLY when
both sides are behind symmetric NATs, which is a much much smaller subset of
cases.

In fact, if you take the pain of always going through an intermediary, there
are even simpler solutions than yours. Just use a VPN, for example. THis
way, the client sends all media and signaling through a VPN server in the
providers network, and the VPN would provide the client with a publically
routable IP on the VPN server. Problem solved, and we could do it without
touching the clients.

Why is this a bad solution? Well, the provider now needs to handle all this
RTP traffic through the VPN server, and voice latencies will frequently be
bad. Same with your approach.

>To ease complexity, the following rules are used:
>1. The SIP BBUA supports multiple domains.
>2. All media for cross domain calls uses the RTP proxy.

Which will indeed result in two intermediaries for cross-domain calls where
both sides are natted.


>> It gets really complicated when you add, as a goal, direct media
>> communications whenever possible. In your proposal, media always flows
>> through this intermediary. Since the location of that device
>> is generally
>> going to be physically uncorrelated with the location of the
>> endpoints,
>> media latency can suffer a LOT. As such, you really only want
>> that thing in
>> there when its needed. If you want to ensure direct media
>> whenever possible,
>> then you get into further complications of making decisions
>> based on which
>> type of nats there are. We came up with on the order of 100
>> different cases
>> that needed to be considered (something like 7 different
>> yes/no orthogonal
>> variables).
>
>Media does not always flow through the RTP Proxy. If the endpoints are in
the same
>domain, and are behind the same NAT/FW, then media does not traverse the
RTP Proxy.

I think you will find that determination of this (whether both endpoints are
behind the same NAT) is a very nontrivial exercise. I think you have a
centrex-style model in mind for this, where you can tell by the domains in
the From and To fields whether both are behind the same nat. That won't work
in dozens and dozens of cases. The most basic case is where I am behind an
enterprise nat, and am using service from a retail provider (say, foo.com),
so that my address is sip:jdrosen@foo.com. If I call someone else who also
has a foo.com address, but who works in a different enterprise, how, per se,
will the foo.com proxy know whether we are behind the same nat (which we're
not in this case) or a different one?

>> The approach you propose also requires that there are call
>> stateful B2BUAs
>> in each call path, which has significant impacts on
>> performance and fault
>> tolerance in particular. The cost to the VoIP provider is
>> VERY high from
>> this solution, because of all the additional rtp traffic that
>> comes in, and
>> back out.
>
>The cost is primarily a management issue from the Service Provider
perspective.

That is false. It is false because you have made an unreasonable assumption
about topological and geographical proximity, see below.

>The only
>requirement is that the SIP Proxy will find the Media Proxy closest to the
UA. The voice
>quality issue is negligible because the Media Proxy is expected to be in
the Service
>Provider (or even within the Enterprise) network close to the end-users.

That is a monstrous assumption that will almost always NOT be true. Your
assumption is a specific centrex-like model where the provider contracts
with the enterprise, so that they can place an RTP proxy near the enterprise
nat, but on the public side of it. That is a very specific, very narrow
case, and will not work for any kind of retail model. Much more common will
be when you have a retail provider (like net2phone, dialpad, deltathree,
etc.) who signs up customers. The provider has no relationship with the
enterprise (if there even is one, remember residential users!). They don't
know the network topology. How is the provider to select an RTP proxy that
is topologically and geopraphically close to the subscriber?? That is a
known HARD problem, and I would assert that the costs of solving it are
profound (requiring deployment of a network similar to Akamai in order to do
this). How can you realistically claim that this is not prohibitively
expensive?

Even without a distributed RTP proxy network like this, its expensive. The
more likely case is that the provider has a farm of RTP proxies in their
primary data center (say, in San Jose). This means that a call from me to my
neighbor will go from New Jersey, to San Jose, and back to Jersey. That adds
substantial latencies, and is also expensive for the provider. Now, they
need to by enough bandwidth in the S.J. data center to support twice the
bandwidth (in and out) for each simultenaous call they would ever carry! How
can you claim that is not expensive? Compare that to the alternative where,
using stun, almost no traffic flows through an intermediary (and arguably,
you might not even bother with one). Thus, you need only be a signaling
point, not a media transit point. Much cheaper, much lower latency.

>Also, a stun-like protocol will need more software upgrades on the
Enterprise clients,
>which has
>cost disadvantages too. Doesn't it?

You are already doing that even in your solution.

There are not so many SIP clients deployed at this time in any case. Let us
do it right while we still can.


>The real tradeoff here is how much intelligence you want to put in the
client as opposed
>to
>that in the network. Our solution is "simple" and "dumb" in the sense that
neither the
>client
>nor the Proxy need to know about the Enterprise NAT binds or types. It
eliminates the
>need for SDP extensions for Symmetric RTP and a few of the SIP extensions
(e.g., NAT
>type). The tradeoff is against the performance impact on the network, which
has been
>discussed earlier.

You are already changing the client. You are changing the proxies. Whether
you change them "more" with a few additional capabilities is irrelevant in
terms of total cost. However, the operational cost of your solution is high,
whereas it is nearly zero in our proposal.

> Also, our solution is targeted primarily for Enterprise customers
>(although applicable for residential too),

I would like to know how you have solved the problem of locating RTP proxies
close to residential users.

 for whom we believe something like a Full Cone
>NAT (alone) does not make a great deal of sense. The most prevalent (we
believe to be >
>90%) cases will be Restricted Cone NAT's and Symmetric NAT's, both of which
will need RTP
>Proxy-like devices.

That is not a consistent assessment from what I have heard from people who
have actually tested them. I hear its about 30% full cone, 40% restricted
cone.

>> As such, our approach is truly a client discovery mechanism, which is
>> EXACTLY how it would work if midcom were deployed. If midcom
>> were in place,
>> the client would talk to its enterprise/residential NAT, obtain some
>> addresses, and put those in SDP.
>
>It depends on where the Midcom Agent resides - the client or the Proxy.
Midcom would also
>allow the Proxy to do all these things transparently for the client, which
is also
>desirable.

In your solution, there are two nats - the residential/enterprise one, and
the "RTP proxy" which is effectively a nat as well. You are using midcom
from your sip B2BUA to that media proxy, but there is no midcom type of
solution for the first nat. My point is, if midcom were deployed, we would
not use your solution at all. The client would talk to its
enterprise/residential nat, and obtain a binding, and put that in its SDP in
the INVITE. There would be no RTP proxy. Our approach mirrors what the
solution would be if we had midcom, but I talk through the nat, instead of
to it.

>> STUn also allows other applications to work, just as midcom will.
>
>The usage of the media proxies do not limit the application to SIP.

It limits it to applications that use media proxies. For H.323, you could
reuse them, but you'd need to upgrade your gatekeepers to do this. It would
not be useful at all for games, for example.

That is not true for stun. Stun is just as useful for a game where I need to
receive UDP updates of game moves. It works even when there is no network
server at all (like gnutella), and it requires NO relationship between the
stun server and the application. Indeed, people with public IP connectivity
could simply deploy stun servers as a public service, to assist people in
discovering and dealing with their nat connectivity.

Stun also helps with diagnostics, and allows you to launch a complaint
against a provider or vendor for deploying a nat when you didn't think there
should be one of that type.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

------_=_NextPart_001_01C15270.005C2C60-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Oct 11 13:20:01 2001 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 NAA20328 for ; Thu, 11 Oct 2001 13:20: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 NAA15085; Thu, 11 Oct 2001 13:17: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 NAA15058 for ; Thu, 11 Oct 2001 13:17:08 -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 NAA20277 for ; Thu, 11 Oct 2001 13:17:06 -0400 (EDT) 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 f9BH7rC21967 for ; Thu, 11 Oct 2001 10:13:56 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-tmp153.cisco.com [10.21.64.153]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAB05555; Thu, 11 Oct 2001 10:09:34 -0700 (PDT) Message-Id: <5.1.0.14.0.20011011131022.00a4a620@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 11 Oct 2001 13:11:51 -0400 To: midcom From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Pre-midcom 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 Don't forget - tomorrow is the deadline for submissions for documents for consideration as candidates for the pre-midcom work. If your document hasn't been posted to ietf-announce by tomorrow please send a copy of the document (or a pointer to it) to the midcom mailing list. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Oct 11 13:27:57 2001 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 NAA20529 for ; Thu, 11 Oct 2001 13:27: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 NAA15264; Thu, 11 Oct 2001 13:24: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 NAA15238 for ; Thu, 11 Oct 2001 13:24: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 NAA20461 for ; Thu, 11 Oct 2001 13:24:09 -0400 (EDT) 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 f9BHNSg25201 for ; Thu, 11 Oct 2001 10:23:28 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-tmp153.cisco.com [10.21.64.153]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAB06162; Thu, 11 Oct 2001 10:22:57 -0700 (PDT) Message-Id: <5.1.0.14.0.20011011131452.00a53c60@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 11 Oct 2001 13:25:15 -0400 To: midcom From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Resolved 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 R20: deleted R33: rewritten - "The midcom protocol must provide for the mutual authentication of midcom agent and middlebox to one another" R65: rewritten - "The midcom protocol must provide for message authentication confidentiality and integrity." Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Oct 11 16:38:40 2001 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 QAA24905 for ; Thu, 11 Oct 2001 16:38: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 QAA21133; Thu, 11 Oct 2001 16:35: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 QAA21102 for ; Thu, 11 Oct 2001 16:35: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 QAA24826 for ; Thu, 11 Oct 2001 16:35:21 -0400 (EDT) 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 f9BKYvk28022 for ; Thu, 11 Oct 2001 13:34:57 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-tmp153.cisco.com [10.21.64.153]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAG00485; Thu, 11 Oct 2001 13:34:32 -0700 (PDT) Message-Id: <5.1.0.14.0.20011011163255.00a48a00@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 11 Oct 2001 16:36:11 -0400 To: midcom From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Thought you'd want to know 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 down to six (give or take my sloppy counting) unresolved requirements bullets. We'll get these wrapped up ASAP. PLEASE: 1) if you think there's still something missing or that needs further attention, tell us NOW, and 2) if you're responsible for completing a piece of work as input to the requirements document, it's time to deliver. Many thanks for all your hard work, Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Oct 11 16:53:01 2001 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 QAA25176 for ; Thu, 11 Oct 2001 16:53: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 QAA21365; Thu, 11 Oct 2001 16:45: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 QAA21336 for ; Thu, 11 Oct 2001 16:45:05 -0400 (EDT) Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25057 for ; Thu, 11 Oct 2001 16:45:03 -0400 (EDT) Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.44 2001/10/01 19:10:43 root Exp $) with SMTP id UAA18497 for ; Thu, 11 Oct 2001 20:45:07 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001101113442228915 for ; Thu, 11 Oct 2001 13:44:22 -0700 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Oct 2001 13:46:18 -0700 Message-ID: <17A7C43776A6D5118A2800508B68D7A89B1A99@orsmsx113.jf.intel.com> From: "Anderson, Todd A" To: midcom Date: Thu, 11 Oct 2001 13:45:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [midcom] R65 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 > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Thursday, October 11, 2001 10:25 AM > To: midcom > Subject: [midcom] Resolved > > R65: rewritten - "The midcom protocol must provide for message > authentication confidentiality and integrity." It seems to me that you wouldn't want somebody to be able to capture an open or close pinhole/NAT binding request and play it back at some arbitrary point in the future. I don't think any of the stated security properties listed above protect against replay attacks. My preference would be to see the "freshness" security property added to this requirement but if people want to make a new requirement that is fine too. Possible attacks if freshness is not required: 1. someone captures an open request and plays it back to reopen the pinhole after it has been closed. 2. someone captures a close request and plays it back to close a duplicate pinhole reopened later. Todd Anderson Intel Labs _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Oct 11 17:14:41 2001 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 RAA25688 for ; Thu, 11 Oct 2001 17:14: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 RAA22113; Thu, 11 Oct 2001 17:13: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 RAA22084 for ; Thu, 11 Oct 2001 17:13:11 -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 RAA25657 for ; Thu, 11 Oct 2001 17:13:09 -0400 (EDT) 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 f9BLAcC23675 for ; Thu, 11 Oct 2001 14:10:38 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-tmp153.cisco.com [10.21.64.153]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAK00254; Thu, 11 Oct 2001 14:12:19 -0700 (PDT) Message-Id: <5.1.0.14.0.20011011171120.00a6cc60@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 11 Oct 2001 17:13:52 -0400 To: midcom From: Melinda Shore Subject: Re: [midcom] R65 In-Reply-To: <17A7C43776A6D5118A2800508B68D7A89B1A99@orsmsx113.jf.intel. 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:45 PM 10/11/01 -0700, Anderson, Todd A wrote: >It seems to me that you wouldn't want somebody to be able to >capture an open or close pinhole/NAT binding request and play it >back at some arbitrary point in the future. We've talked about anti-replay protect in the context of the framework document but we don't have any requirement text covering it. I do think we need something. I'd personally rather see a separate requirement - I don't think that all security-related requirements should be lumped together as one - but it's up to the discretion of the working group. Whichever way we go let's get it settled by tomorrow afternoon EDT. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Oct 11 18:03:48 2001 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 SAA26693 for ; Thu, 11 Oct 2001 18:03: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 SAA23462; Thu, 11 Oct 2001 18:01: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 SAA23436 for ; Thu, 11 Oct 2001 18:01:47 -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 SAA26653 for ; Thu, 11 Oct 2001 18:01:45 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9BM1Xu03302 for ; Thu, 11 Oct 2001 15:01:33 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-667.cisco.com [10.21.98.155]) by airborne.cisco.com (Mirapoint) with SMTP id AAQ22319; Thu, 11 Oct 2001 15:01:19 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Thu, 11 Oct 2001 18:01:17 -0400 Date: Thu, 11 Oct 2001 18:01:17 -0400 From: Scott Brim To: midcom Subject: Re: [midcom] Thought you'd want to know Message-ID: <20011011180117.T1216@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom References: <5.1.0.14.0.20011011163255.00a48a00@mira-sjc5-4.cisco.com> 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.20011011163255.00a48a00@mira-sjc5-4.cisco.com>; from mshore@cisco.com on Thu, Oct 11, 2001 at 04:36:11PM -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 Thu, Oct 11, 2001 04:36:11PM -0400, Melinda Shore allegedly wrote: > We are down to six (give or take my sloppy counting) unresolved > requirements bullets. We'll get these wrapped up ASAP. My opinions on the remaining ones ... R86: It should possible to define rulesets that contain a more specific filter than an overlapping ruleset, and a different set of attributes. This should allow Midcom agent to request that a subset of the traffic that would be allowed by the overlapping ruleset be specifically disallowed. Reasoning: this is required for rapid response to intrusion detection. Accept. R35: Once the need for the relationship between a Midcom Agent and a Middlebox established during the registration process has lapsed, a deregistration process will be required. This will break the trust relationship between the specific Middlebox and Midcom Agent. Once this has been done, a Middlebox MUST NOT service any further requests from a given Midcom Agent without the Midcom Agent first re-establishing the appropriate trust relationship with the Middlebox. Wording problems. "Registration" needs better definition (in framework?). "Lapsed" is not understood the same by everyone. This is obvious. Discard. R38: The Midcom Protocol MUST enable the Middlebox and/or Midcom Agent to determine when a registration session is no longer valid. This is to address cases such as when either a Middlebox or MIDCOM Agent restarts. "Registration", as used by Suresh and in this case, is a policy issue. It's what happens when a middlebox (or agent) hears from some policy entity that an agent (or a middlebox) is allowed to communicate at all. This doesn't have anything to do with the midcom protocol, but rather with policy interactions. So far we've done close to nothing wrt policy. I say discard this one, since it will be included in whatever we finally do with policy. R43: The Midcom Protocol SHOULD allow the aggregation of commands, requests and responses. We don't know what this one really means, but we're putting off judgment until we know more about our other requirements. Already covered by already accepted ones. Discard. R47: When accepting a request for a pin-hole, the Middlebox MUST be able to provide the MIDCOM Agent with information that may be used to identify the resource in subsequent operations. Temporarily changed "flow" to "resource". Need better word than "resource". I think we should discard this too. We don't know how midcom will be used, especially when multiple agents and middleboxes get involved. There are two possible approaches. First, accept this requirement, and require a field in the protocol packets with a note that it *might* be used for an identifier, but keep it reserved and do our best not to use it. After a while we'll know if we need it. If we don't we can use it for future expansion. The other option is to abandon this requirement, and if in the future someone decides they really need an identifier, they can add it using the protocol's extensibility features. The only reason to stick the field in now is if there are performance issues. R75: The Midcom Protocol must produce robust operation even when routing changes such that traffic from a particular end system passes through a different middlebox. (Huitema) Eliot Lear says "this takes too much state". I don't think supporting this kind of robustness is the job of the midcom protocol. I think the model underlying this one is poorly formed. Discard. ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Oct 11 19:26:50 2001 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 TAA28491 for ; Thu, 11 Oct 2001 19:26: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 TAA25154; Thu, 11 Oct 2001 19:25: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 TAA25125 for ; Thu, 11 Oct 2001 19:25:22 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28462 for ; Thu, 11 Oct 2001 19:25:22 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TB12T6M3; Thu, 11 Oct 2001 19:24:53 -0400 Message-Id: <3.0.5.32.20011011192207.00931320@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 11 Oct 2001 19:22:07 -0400 To: Scott Brim , midcom From: Mark Duffy Subject: Re: [midcom] Thought you'd want to know In-Reply-To: <20011011180117.T1216@SBRIM-W2K> References: <5.1.0.14.0.20011011163255.00a48a00@mira-sjc5-4.cisco.com> <5.1.0.14.0.20011011163255.00a48a00@mira-sjc5-4.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 At 06:01 PM 10/11/01 -0400, Scott Brim wrote: >On Thu, Oct 11, 2001 04:36:11PM -0400, Melinda Shore allegedly wrote: >> We are down to six (give or take my sloppy counting) unresolved >> requirements bullets. We'll get these wrapped up ASAP. > >My opinions on the remaining ones ... > > R86: It should possible to define rulesets that contain a more > specific filter than an overlapping ruleset, and a different set > of attributes. This should allow Midcom agent to request that a > subset of the traffic that would be allowed by the overlapping > ruleset be specifically disallowed. > > Reasoning: this is required for rapid response to intrusion > detection. > >Accept. Yes, accept. But terminology needs to be updated. Here is proposed wording (I also changed the bit about 'allowing' traffic to 'affecting' traffic, to be less firewall-centric): R86: It should be possible to define rulesets which contain filter spec(s) that overlap with those of other rulesets. This should allow a Midcom agent to install a ruleset affecting only a subset of the traffic that would be affected by the overlapping ruleset. > > > R35: Once the need for the relationship between a Midcom Agent and a > Middlebox established during the registration process has > lapsed, a deregistration process will be required. This will > break the trust relationship between the specific Middlebox and > Midcom Agent. Once this has been done, a Middlebox MUST NOT > service any further requests from a given Midcom Agent without > the Midcom Agent first re-establishing the appropriate trust > relationship with the Middlebox. > > Wording problems. "Registration" needs better definition (in > framework?). "Lapsed" is not understood the same by > everyone. > >This is obvious. Discard. Yes, discard. > R38: The Midcom Protocol MUST enable the Middlebox and/or Midcom > Agent to determine when a registration session is no longer > valid. This is to address cases such as when either a Middlebox > or MIDCOM Agent restarts. > >"Registration", as used by Suresh and in this case, is a policy issue. >It's what happens when a middlebox (or agent) hears from some policy >entity that an agent (or a middlebox) is allowed to communicate at all. >This doesn't have anything to do with the midcom protocol, but rather >with policy interactions. So far we've done close to nothing wrt >policy. I say discard this one, since it will be included in whatever >we finally do with policy. Yes, discard. > R43: The Midcom Protocol SHOULD allow the aggregation of commands, > requests and responses. > > We don't know what this one really means, but we're putting > off judgment until we know more about our other > requirements. > >Already covered by already accepted ones. Discard. I'm not sure what accepted reqts cover this one. But I vote for discard anyway. > R47: When accepting a request for a pin-hole, the Middlebox MUST be > able to provide the MIDCOM Agent with information that may be > used to identify the resource in subsequent operations. > > Temporarily changed "flow" to "resource". Need better word > than "resource". > >I think we should discard this too. We don't know how midcom will be >used, especially when multiple agents and middleboxes get involved. >There are two possible approaches. First, accept this requirement, and >require a field in the protocol packets with a note that it *might* be >used for an identifier, but keep it reserved and do our best not to use >it. After a while we'll know if we need it. If we don't we can use it >for future expansion. The other option is to abandon this requirement, >and if in the future someone decides they really need an identifier, >they can add it using the protocol's extensibility features. The only >reason to stick the field in now is if there are performance issues. > > R75: The Midcom Protocol must produce robust operation even when > routing changes such that traffic from a particular end system > passes through a different middlebox. (Huitema) > > Eliot Lear says "this takes too much state". > >I don't think supporting this kind of robustness is the job of the >midcom protocol. I think the model underlying this one is poorly >formed. Discard. Isn't this really part of the topology question? What is the result of the breakfast ^h^h^h^h^h^h^h^h^h contest of champions and how does that result feed back into the requirements?? >..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Oct 11 20:34:22 2001 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 UAA29552 for ; Thu, 11 Oct 2001 20:34: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 UAA26663; Thu, 11 Oct 2001 20:29: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 UAA26636 for ; Thu, 11 Oct 2001 20:28:59 -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 UAA29405 for ; Thu, 11 Oct 2001 20:28: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.2966); Thu, 11 Oct 2001 17:28:25 -0700 Received: from 157.54.9.108 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 11 Oct 2001 17:28:25 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 11 Oct 2001 17:28:24 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 11 Oct 2001 17:28:24 -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(5.0.2195.3651); Thu, 11 Oct 2001 17:28:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Thu, 11 Oct 2001 17:27:59 -0700 Message-ID: Thread-Topic: R86 Thread-Index: AcFSrVOk55r3TzwNSmeCye8dSyC4gAABw59A From: "Christian Huitema" To: "Mark Duffy" , "Scott Brim" , "midcom" X-OriginalArrivalTime: 12 Oct 2001 00:28:00.0146 (UTC) FILETIME=[BF60AF20:01C152B4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA26637 Subject: [midcom] R86 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 > -----Original Message----- > From: Mark Duffy [mailto:mduffy@quarrytech.com] > Sent: Thursday, October 11, 2001 4:22 PM > To: Scott Brim; midcom > Subject: Re: [midcom] Thought you'd want to know > > At 06:01 PM 10/11/01 -0400, Scott Brim wrote: > >On Thu, Oct 11, 2001 04:36:11PM -0400, Melinda Shore allegedly wrote: > >> We are down to six (give or take my sloppy counting) unresolved > >> requirements bullets. We'll get these wrapped up ASAP. > > > >My opinions on the remaining ones ... > > > > R86: It should possible to define rulesets that contain a more > > specific filter than an overlapping ruleset, and a different > set > > of attributes. This should allow Midcom agent to request > that a > > subset of the traffic that would be allowed by the > overlapping > > ruleset be specifically disallowed. > > > > Reasoning: this is required for rapid response to intrusion > > detection. > > > >Accept. > > Yes, accept. But terminology needs to be updated. Here is proposed > wording (I also changed the bit about 'allowing' traffic to > 'affecting' > traffic, to be less firewall-centric): > > R86: It should be possible to define rulesets which contain filter > spec(s) that overlap with those of other rulesets. This > should > allow a Midcom agent to install a ruleset affecting only a > subset of the traffic that would be affected by the > overlapping > ruleset. Uh, no. The terminology was actually carefully chosen. We don't want filters that "overlap"; we want a hierarchy of filters, otherwise the whole protocol becomes undeterministic. I would say, accept the original version. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Oct 11 20:34:40 2001 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 UAA29577 for ; Thu, 11 Oct 2001 20:34: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 UAA27086; Thu, 11 Oct 2001 20:33: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 UAA27058 for ; Thu, 11 Oct 2001 20:33:49 -0400 (EDT) Received: from inet-vrs-05.redmond.corp.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29544 for ; Thu, 11 Oct 2001 20:33:45 -0400 (EDT) Received: from 157.54.7.70 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 11 Oct 2001 17:33:19 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 11 Oct 2001 17:33: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); Thu, 11 Oct 2001 17:33: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(5.0.2195.3651); Thu, 11 Oct 2001 17:32:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [midcom] Thought you'd want to know Date: Thu, 11 Oct 2001 17:32:53 -0700 Message-ID: Thread-Topic: [midcom] Thought you'd want to know Thread-Index: AcFSrVOk55r3TzwNSmeCye8dSyC4gAAB3VrA From: "Christian Huitema" To: "Mark Duffy" , "Scott Brim" , "midcom" X-OriginalArrivalTime: 12 Oct 2001 00:32:54.0254 (UTC) FILETIME=[6EAE00E0:01C152B5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA27059 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 > > R35: Once the need for the relationship between a Midcom Agent and > a > > Middlebox established during the registration process has > > lapsed, a deregistration process will be required. This will > > break the trust relationship between the specific Middlebox > and > > Midcom Agent. Once this has been done, a Middlebox MUST NOT > > service any further requests from a given Midcom Agent > without > > the Midcom Agent first re-establishing the appropriate trust > > relationship with the Middlebox. > > > > Wording problems. "Registration" needs better definition > (in > > framework?). "Lapsed" is not understood the same by > > everyone. > > > >This is obvious. Discard. > > Yes, discard. Yes, discard. > > > R38: The Midcom Protocol MUST enable the Middlebox and/or Midcom > > Agent to determine when a registration session is no longer > > valid. This is to address cases such as when either a > Middlebox > > or MIDCOM Agent restarts. > > > >"Registration", as used by Suresh and in this case, is a policy > issue. > >It's what happens when a middlebox (or agent) hears from some policy > >entity that an agent (or a middlebox) is allowed to communicate at > all. > >This doesn't have anything to do with the midcom protocol, but rather > >with policy interactions. So far we've done close to nothing wrt > >policy. I say discard this one, since it will be included in > whatever > >we finally do with policy. > > Yes, discard. Yes, discard. > > > R43: The Midcom Protocol SHOULD allow the aggregation of commands, > > requests and responses. > > > > We don't know what this one really means, but we're > putting > > off judgment until we know more about our other > > requirements. > > > >Already covered by already accepted ones. Discard. > > I'm not sure what accepted reqts cover this one. But I vote for > discard > anyway. Ditto. Discard. > > R47: When accepting a request for a pin-hole, the Middlebox MUST > be > > able to provide the MIDCOM Agent with information that may be > > used to identify the resource in subsequent operations. > > > > Temporarily changed "flow" to "resource". Need better > word > > than "resource". > > > >I think we should discard this too. We don't know how midcom will be > >used, especially when multiple agents and middleboxes get involved. > >There are two possible approaches. First, accept this requirement, > and > >require a field in the protocol packets with a note that it *might* > be > >used for an identifier, but keep it reserved and do our best not to > use > >it. After a while we'll know if we need it. If we don't we can use > it > >for future expansion. The other option is to abandon this > requirement, > >and if in the future someone decides they really need an identifier, > >they can add it using the protocol's extensibility features. The > only > >reason to stick the field in now is if there are performance issues. Discard. At best, this is a protocol design issue, not a protocol functionality issue. > > R75: The Midcom Protocol must produce robust operation even when > > routing changes such that traffic from a particular end > system > > passes through a different middlebox. (Huitema) > > > > Eliot Lear says "this takes too much state". > > > >I don't think supporting this kind of robustness is the job of the > >midcom protocol. I think the model underlying this one is poorly > >formed. Discard. > > Isn't this really part of the topology question? What is the result > of the > breakfast ^h^h^h^h^h^h^h^h^h contest of champions and how does that > result > feed back into the requirements?? OK. What I have really in mind is the support of an explicit media relay: internal client sends to specific port on media relay, the traffic is then relayed to final destination, and vice versa. Since the traffic is pinned to the media relay, the configuration is immune to routing vagaries. Several SIP implementations use such relays to cross firewalls. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Oct 12 08:22:02 2001 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 IAA23603 for ; Fri, 12 Oct 2001 08:22: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 IAA22576; Fri, 12 Oct 2001 08:17: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 IAA22547 for ; Fri, 12 Oct 2001 08:17:34 -0400 (EDT) Received: from znsgs0ja.europe.nortel.com ([47.165.25.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23473 for ; Fri, 12 Oct 2001 08:17:30 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f9CCH0k26736 for ; Fri, 12 Oct 2001 13:17:00 +0100 (BST) Received: from znsgd00t.europe.nortel.com by znsgs016; Fri, 12 Oct 2001 13:16:42 +0100 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <44VK06VN>; Fri, 12 Oct 2001 13:16:22 +0100 Message-ID: <9154CB41F208D5118DD200508BE39C3044531C@zjguc006.europe.nortel.com> From: "Cedric Aoun" To: "'Scott Brim'" Cc: "'Melinda Shore'" , midcom mail-list Subject: RE: [midcom] accept R3a1 & R3a2 Date: Fri, 12 Oct 2001 13:16:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15317.B3DA5CB0" 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_01C15317.B3DA5CB0 Content-Type: text/plain; charset="iso-8859-1" my vision was that we try to avoid using midcom to put specific rulesets to allow traversal of midcom flows to control remote Middle boxes. That's actually my point, sorry if I wasn't clear. I see that using midcom to allow midcom flow traverse is an overkill, no? So are you considering that embedded nat traversal capabilities (as what is being specified to other protocols, as for SIP) in the midcom protocol are optional, in order to open the choice on several potential midcom protocols? -----Original Message----- From: Scott Brim [mailto:swb@employees.org] Sent: Thursday, October 11, 2001 3:44 PM To: Aoun, Cedric [QPD:MA01:EXCH] Cc: 'Melinda Shore'; midcom mail-list Subject: Re: [midcom] accept R3a1 & R3a2 On Thu, Oct 11, 2001 11:37:14AM +0100, Cedric Aoun allegedly wrote: > Scott, > In the context of carrier managed services, the Telephony Service Provider > (TSP) > will put Media GateWays (MGW) in the customer premise. > The MGWs will be controlled by Media Gateway Controllers (MGC) that are > located in the TSP. > The Midcom Agent (MA) will be co-hosted with the MGC instance. > > When you are running several hundred thousands (even millions) of calls, > obviously we are not talking of a couple of IP addresses for the MGC > instances. Depending on your assigned registered address space, you might > want to assign private addresses to your MGC instances, therefore you will > need to NAT the application signaling messages. > > Does it make any sense? Yes. The NAT and its controlling Midcom Agent share an address space. The *midcom* messages don't have to go through a NAT. The application signaling does -- but that's why we're doing this midcom thing in the first place. I see no problem. > Cedric > > -----Original Message----- > From: Scott Brim [mailto:swb@employees.org] > Sent: Wednesday, October 10, 2001 6:28 PM > To: Aoun, Cedric [QPD:MA01:EXCH] > Cc: 'Melinda Shore'; midcom mail-list > Subject: Re: [midcom] accept R3a1 & R3a2 > > > On Wed, Oct 10, 2001 04:05:59PM +0100, Cedric Aoun allegedly wrote: > > Scott, > > The topology I have in mind is the following > > > > ++++++++++ ++++++++++ ++++++++++++ > > +foo.com +MB1-----+the net +-------MB2+MA bar.com+ > > ++++++++++ ++++++++++ +++++++++++ > > > > > > In case the Midcom Agent sends a Midcom request to MiddleBox1 > > we don't want the protocol messages to contain any IP addresses or ports > > relevant to the bar.com realm. > > This is what I actually meant. > > As long as the MA in the picture is a midcom agent, not an application > helper of some sort, I have trouble believing this scenario would be > deployed in real life. > > Can any ISP (not vendor) out there give any example of where they would > want such a scenario? We're talking about a security relationship > between agent and middlebox crossing a NAT. > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C15317.B3DA5CB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] accept R3a1 & R3a2

my vision was that we try to avoid using midcom to = put specific rulesets to allow traversal
of midcom flows to control remote Middle boxes. = That's actually my point, sorry if I wasn't clear.
I see that using midcom to allow midcom flow = traverse is an overkill, no?
So  are you considering that embedded nat = traversal capabilities (as what is being specified to other protocols, = as for SIP) in the midcom protocol are optional, in order to open the = choice on several potential midcom protocols?



-----Original Message-----
From: Scott Brim [mailto:swb@employees.org]
Sent: Thursday, October 11, 2001 3:44 PM
To: Aoun, Cedric [QPD:MA01:EXCH]
Cc: 'Melinda Shore'; midcom mail-list
Subject: Re: [midcom] accept R3a1 & R3a2


On Thu, Oct 11, 2001 11:37:14AM +0100, Cedric Aoun = allegedly wrote:
> Scott,
> In the context of carrier managed services, the = Telephony Service Provider
> (TSP)
>  will put Media GateWays (MGW) in the = customer premise.
> The MGWs will be controlled by Media Gateway = Controllers (MGC) that are
> located in the TSP.
> The Midcom Agent (MA) will be co-hosted with = the MGC instance.
>
> When you are running several hundred thousands = (even millions) of calls,
> obviously we are not talking of a couple of IP = addresses for the MGC
> instances. Depending on your assigned = registered address space, you might
> want to assign private addresses to your MGC = instances, therefore you will
> need to NAT the application signaling = messages.
>
> Does it make any sense?

Yes.  The NAT and its controlling Midcom Agent = share an address space.
The *midcom* messages don't have to go through a = NAT.  The application
signaling does -- but that's why we're doing this = midcom thing in the
first place.  I see no problem.

> Cedric
>
> -----Original Message-----
> From: Scott Brim [mailto:swb@employees.org]
> Sent: Wednesday, October 10, 2001 6:28 = PM
> To: Aoun, Cedric [QPD:MA01:EXCH]
> Cc: 'Melinda Shore'; midcom mail-list
> Subject: Re: [midcom] accept R3a1 & = R3a2
>
>
> On Wed, Oct 10, 2001 04:05:59PM +0100, Cedric = Aoun allegedly wrote:
> > Scott,
> > The topology I have in mind is the = following
> >
> >  = ++++++++++           = ++++++++++         = ++++++++++++      
> >  +foo.com    = +MB1-----+the net      = +-------MB2+MA   bar.com+
> >  ++++++++++ =         = ++++++++++          &n= bsp;   +++++++++++
> >
> >
> > In case the Midcom Agent sends a Midcom = request to MiddleBox1
> > we don't want the protocol messages to = contain any IP addresses or ports
> > relevant to the bar.com realm.
> > This is what I actually meant.
>
> As long as the MA in the picture is a midcom = agent, not an application
> helper of some sort, I have trouble believing = this scenario would be
> deployed in real life. 
>
> Can any ISP (not vendor) out there give any = example of where they would
> want such a scenario?  We're talking about = a security relationship
> between agent and middlebox crossing a = NAT.
>

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

------_=_NextPart_001_01C15317.B3DA5CB0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Oct 12 08:38:19 2001 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 IAA24193 for ; Fri, 12 Oct 2001 08:38: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 IAA23472; Fri, 12 Oct 2001 08:36: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 IAA23386 for ; Fri, 12 Oct 2001 08:36:30 -0400 (EDT) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24146 for ; Fri, 12 Oct 2001 08:36:26 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f9CCZ6S28637 for ; Fri, 12 Oct 2001 08:35:06 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 12 Oct 2001 08:35:09 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4SX6R414>; Fri, 12 Oct 2001 08:34:49 -0400 Message-ID: <28560036253BD41191A10000F8BCBD110514FC72@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "'Christian Huitema'" , Mark Duffy , Scott Brim , midcom Subject: RE: [midcom] R86 Date: Fri, 12 Oct 2001 08:34:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1531A.4727A480" X-Orig: 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_01C1531A.4727A480 Content-Type: text/plain; charset="iso-8859-1" A key point that came out a couple of messages ago is that it should be possible to install actions for the subset which contradict those for the parent set. This should be included somehow. -----Original Message----- From: Christian Huitema [mailto:huitema@windows.microsoft.com] Sent: Thursday, October 11, 2001 8:28 PM To: Mark Duffy; Scott Brim; midcom Subject: [midcom] R86 > -----Original Message----- > From: Mark Duffy [mailto:mduffy@quarrytech.com] > Sent: Thursday, October 11, 2001 4:22 PM > To: Scott Brim; midcom > Subject: Re: [midcom] Thought you'd want to know > > At 06:01 PM 10/11/01 -0400, Scott Brim wrote: > >On Thu, Oct 11, 2001 04:36:11PM -0400, Melinda Shore allegedly wrote: > >> We are down to six (give or take my sloppy counting) unresolved > >> requirements bullets. We'll get these wrapped up ASAP. > > > >My opinions on the remaining ones ... > > > > R86: It should possible to define rulesets that contain a more > > specific filter than an overlapping ruleset, and a different > set > > of attributes. This should allow Midcom agent to request > that a > > subset of the traffic that would be allowed by the > overlapping > > ruleset be specifically disallowed. > > > > Reasoning: this is required for rapid response to intrusion > > detection. > > > >Accept. > > Yes, accept. But terminology needs to be updated. Here is proposed > wording (I also changed the bit about 'allowing' traffic to > 'affecting' > traffic, to be less firewall-centric): > > R86: It should be possible to define rulesets which contain filter > spec(s) that overlap with those of other rulesets. This > should > allow a Midcom agent to install a ruleset affecting only a > subset of the traffic that would be affected by the > overlapping > ruleset. Uh, no. The terminology was actually carefully chosen. We don't want filters that "overlap"; we want a hierarchy of filters, otherwise the whole protocol becomes undeterministic. I would say, accept the original version. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C1531A.4727A480 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] R86

A key point that came out a couple of messages ago is = that it should be possible to install actions for the subset which = contradict those for the parent set.  This should be included = somehow.

-----Original Message-----
From: Christian Huitema [mailto:huitema@windows.mic= rosoft.com]
Sent: Thursday, October 11, 2001 8:28 PM
To: Mark Duffy; Scott Brim; midcom
Subject: [midcom] R86




> -----Original Message-----
> From: Mark Duffy [mailto:mduffy@quarrytech.com]<= /FONT>
> Sent: Thursday, October 11, 2001 4:22 PM
> To: Scott Brim; midcom
> Subject: Re: [midcom] Thought you'd want to = know
>
> At 06:01 PM 10/11/01 -0400, Scott Brim = wrote:
> >On Thu, Oct 11, 2001 04:36:11PM -0400, = Melinda Shore allegedly wrote:
> >> We are down to six (give or take my = sloppy counting) unresolved
> >> requirements bullets.  We'll get = these wrapped up ASAP.
> >
> >My opinions on the remaining ones = ...
> >
> >   R86: It should possible to = define rulesets that contain a more
> >        = specific filter than an overlapping ruleset, and a different
> set
> >        = of attributes.  This should allow Midcom agent to request
> that a
> >        = subset of the traffic that would be allowed by the
> overlapping
> >        = ruleset be specifically disallowed.
> >
> >        = Reasoning: this is required for rapid response to intrusion
> >        = detection.
> >
> >Accept.
>
> Yes, accept.  But terminology needs to be = updated.  Here is proposed
> wording (I also changed the bit about = 'allowing' traffic to
> 'affecting'
> traffic, to be less firewall-centric):
>
>    R86: It should be possible to = define rulesets which contain filter
>         = spec(s) that overlap with those of other rulesets.  This
> should
>         = allow a Midcom agent to install a ruleset affecting only a
>         = subset of the traffic that would be affected by the
> overlapping
>         = ruleset.

Uh, no. The terminology was actually carefully = chosen. We don't want
filters that "overlap"; we want a = hierarchy of filters, otherwise the
whole protocol becomes undeterministic. I would say, = accept the original
version.

-- Christian Huitema

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

------_=_NextPart_001_01C1531A.4727A480-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Oct 12 11:03:12 2001 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 LAA00605 for ; Fri, 12 Oct 2001 11:03: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 KAA27371; Fri, 12 Oct 2001 10:44: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 KAA27341 for ; Fri, 12 Oct 2001 10:44:45 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00057 for ; Fri, 12 Oct 2001 10:44:40 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TB12T7NS; Fri, 12 Oct 2001 10:44:14 -0400 Message-Id: <3.0.5.32.20011012104309.007f6b00@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 12 Oct 2001 10:43:09 -0400 To: "Christian Huitema" , "Scott Brim" , "midcom" From: Mark Duffy In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Re: R86 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 >Uh, no. The terminology was actually carefully chosen. We don't want >filters that "overlap"; we want a hierarchy of filters, otherwise the >whole protocol becomes undeterministic. I would say, accept the original >version. Hi Christian. I think I have the same interpretation of this requirement as you do, but I don't see that the suggested wording change undermines it. Here is what and why I was attempting to change; I still think these are desirable changes. Can you say specifically where you diagree? 1. Replace the word filter with filter spec. 2. Clarify that it is really overlap of the the *filter spec* portions of the rulesets that we are talking about. (Overlap of the other components of rulesets is irrelevant here, perhaps even meaningless.) Those two objectives drove the change in the first sentence: original: R86: It should possible to define rulesets that contain a more specific filter than an overlapping ruleset, and a different set of attributes. Mark's proposed changes: R86: It should be possible to define rulesets which contain filter spec(s) that overlap with those of other rulesets. As an added observation, it is implicit here that "other rulesets" may have a "different set of attributes". If "that overlap with" were changed back to "that are more specific than", would that fix it in your mind? I had been thinking that the the two had to be synonymous here. I was thinking in terms of address prefixes where the only way one can overlap another is to be a more specific subset. Thinking about it a little more now, that is obviously not the case for an overall n-tuple filter spec. In fact, as a practical matter, if there are two filter specs and both have wildcards, and there is some overlap, I don't think it is possible to determine which is "more specific", absent some arbitrary rules for doing so. (I know you have previously proposed some such rules.) 3. Remove the firewall-centricity in the concept of "allowing" traffic. Replace it by the more general concept of "affecting" traffic. Thus the change in the 2nd sentence: original: R86: This should allow Midcom agent to request that a subset of the traffic that would be allowed by the overlapping ruleset be specifically disallowed. Mark's proposed changes: R86: This should allow a Midcom agent to install a ruleset affecting only a subset of the traffic that would be affected by the overlapping ruleset. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Oct 12 12:02:51 2001 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 MAA02330 for ; Fri, 12 Oct 2001 12:02:46 -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 LAA29246; Fri, 12 Oct 2001 11: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 LAA29216 for ; Fri, 12 Oct 2001 11:43:42 -0400 (EDT) Received: from inet-vrs-04.redmond.corp.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01874 for ; Fri, 12 Oct 2001 11:43:36 -0400 (EDT) Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 12 Oct 2001 08:41:54 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 12 Oct 2001 08:41:52 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 12 Oct 2001 08:41:46 -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(5.0.2195.3651); Fri, 12 Oct 2001 08:41:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Fri, 12 Oct 2001 08:41:20 -0700 Message-ID: Thread-Topic: R86 Thread-Index: AcFTLFRCduqOL3UQQbmmXG/WCeljngABmUIg From: "Christian Huitema" To: "Mark Duffy" , "Scott Brim" , "midcom" X-OriginalArrivalTime: 12 Oct 2001 15:41:21.0197 (UTC) FILETIME=[575975D0:01C15334] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA29217 Subject: [midcom] RE: R86 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 > 1. Replace the word filter with filter spec. No issue there. > R86: It should possible to define rulesets that contain a more > specific filter than an overlapping ruleset, and a different > set > of attributes. > > Mark's proposed changes: > R86: It should be possible to define rulesets which contain filter > spec(s) that overlap with those of other rulesets. There is a difference between the restricted overlap mentioned in "more specific" and the general overlap induced by the second phrasing. So, the first phrase should definitely be: "It should possible to define rulesets that contain a more specific filter spec than an overlapping ruleset, and specify a different set of actions." > As an added observation, it is implicit here that "other rulesets" may > have a "different set of attributes". Maybe, but there is also no harm in being explicit. > 3. Remove the firewall-centricity in the concept of "allowing" > traffic. > Replace it by the more general concept of "affecting" traffic. Thus > the > change in the 2nd sentence: > > original: > R86: This should allow Midcom agent to request that a > subset of the traffic that would be allowed by the overlapping > ruleset be specifically disallowed. > > Mark's proposed changes: > R86: This should > allow a Midcom agent to install a ruleset affecting only a > subset of the traffic that would be affected by the overlapping > ruleset. The problem is that we actually need the firewall specific phrasing as an example of application. After all, firewalls *are* our main concern. Your second wording is too generic, and in fact is almost equivalent to the "different actions" phrase. To quote Tom's message, "A key point that came out a couple of messages ago is that it should be possible to install actions for the subset which contradict those for the parent set. This should be included somehow." So, to take into account everybody's input, I suggest the following: R86: It should possible to define rulesets that contain a more specific filter spec than an overlapping ruleset. This should allow agents to request actions for the subset that contradict those of the overlapping set. This should allow Midcom agent to request to a Midcom server controlling a firewall function that a subset of the traffic that would be allowed by the overlapping ruleset be specifically disallowed. OK? -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Oct 12 12:17:31 2001 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 MAA02650 for ; Fri, 12 Oct 2001 12:17: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 MAA00867; Fri, 12 Oct 2001 12:15: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 MAA00836 for ; Fri, 12 Oct 2001 12:15:15 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02599 for ; Fri, 12 Oct 2001 12:15:09 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TB12T7V0; Fri, 12 Oct 2001 12:14:45 -0400 Message-Id: <3.0.5.32.20011012121342.0088e650@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 12 Oct 2001 12:13:42 -0400 To: "Christian Huitema" , "midcom" From: Mark Duffy In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] RE: R86 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 >R86: It should possible to define rulesets that contain a more specific >filter spec than an overlapping ruleset. This should allow agents to >request actions for the subset that contradict those of the overlapping >set. This should allow Midcom agent to request to a Midcom server >controlling a firewall function that a subset of the traffic that would >be allowed by the overlapping ruleset be specifically disallowed. > >OK? Fine by me. I'm not sure how rigirous we think we are being about use of words must vs should but most of the other reqts on the list use must. Unless we condider this just a desirable feature of a midcom protocol then I'd venture that the very first "should" above should be replaced by must. -Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Oct 12 16:10:54 2001 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 QAA08643 for ; Fri, 12 Oct 2001 16:10: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 PAA08203; Fri, 12 Oct 2001 15: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 PAA08174 for ; Fri, 12 Oct 2001 15:57:57 -0400 (EDT) Received: from avgw.vxserver.com (mail.ridgeway-sys.com [194.128.67.178]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08398 for ; Fri, 12 Oct 2001 15:57:52 -0400 (EDT) Received: from ridgeway.ridgeway-sys.com ([10.1.1.1]) by avgw.vxserver.com (NAVGW 2.5.1.2) with SMTP id M2001101220554322829 ; Fri, 12 Oct 2001 20:55:43 +0100 Received: by ThisAddressDoesNotExist with Internet Mail Service (5.5.2653.19) id <4L1QSNPC>; Fri, 12 Oct 2001 20:57:14 +0100 Message-ID: <00533D13955AD411AF3800A0C9B42639E9205F@ThisAddressDoesNotExist> From: Steve Davies To: Melinda Shore , midcom Subject: RE: [midcom] Pre-midcom work item - candidate draft-davies-fw-nat -traversal-01.txt Date: Fri, 12 Oct 2001 20:57:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15358.11ABBE20" 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_01C15358.11ABBE20 Content-Type: text/plain; charset="ISO-8859-1" All, Today Ridgeway has submitted a new internet draft as a candidate for the work item specified below. Until it is available via the IETF website, it may be downloaded from: http://www.ridgewaysystems.com/pdf/Whitepapers/draft-davies-fw-nat-traversal -01.txt Steve -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: 05 October 2001 14:14 To: midcom Subject: [midcom] New deliverable approved We've gotten the go-ahead on the new deliverable. The most recent description that I've seen is this: Ubiquitous deployment of midcom in all middleboxes could take many years. 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. We need to move quickly on choosing a base document and moving it forward. Please take the charter text to heart, particularly " [ ... ] allows clients to indirectly obtain address bindings from midcom-unaware middleboxes." Note that it does not say that we'll be using tunneling. Also, let's try to keep moving the other deliverables towards closure. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C15358.11ABBE20 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Pre-midcom work item - candidate = draft-davies-fw-nat-traversal-01.txt

All,

Today Ridgeway has submitted a new internet draft as = a candidate for the work item specified below. Until it is available = via the IETF website, it may be downloaded from:

http://www.ridgewaysystems.com/pdf/Whitepapers/draft-d= avies-fw-nat-traversal-01.txt

Steve

-----Original Message-----
From: Melinda Shore [mailto:mshore@cisco.com]
Sent: 05 October 2001 14:14
To: midcom
Subject: [midcom] New deliverable approved


We've gotten the go-ahead on the new = deliverable.  The
most recent description that I've seen is = this:

Ubiquitous deployment of midcom in all middleboxes = could take many years.
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.

We need to move quickly on choosing a base document = and moving
it forward.  Please take the charter text to = heart, particularly
" [ ... ] allows clients to indirectly obtain = address bindings from
midcom-unaware middleboxes."  Note that it = does not say that we'll
be using tunneling.

Also, let's try to keep moving the other deliverables = towards
closure. 

Melinda


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

------_=_NextPart_001_01C15358.11ABBE20-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Oct 12 16:58:14 2001 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 QAA09536 for ; Fri, 12 Oct 2001 16:58: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 QAA09690; Fri, 12 Oct 2001 16:56:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09662 for ; Fri, 12 Oct 2001 16:56:46 -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 QAA09480 for ; Fri, 12 Oct 2001 16:56:41 -0400 (EDT) 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 f9CKuFg25960 for ; Fri, 12 Oct 2001 13:56:15 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-tmp238.cisco.com [10.21.64.238]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAN23863; Fri, 12 Oct 2001 13:55:46 -0700 (PDT) Message-Id: <5.1.0.14.0.20011012164712.00a77890@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 12 Oct 2001 16:58:07 -0400 To: midcom From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] pre-midcom candidates 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 we now have three candidate documents for the pre-midcom work item, and we need to work quickly towards getting one selected for use as the base document. Those three documents are: http://search.ietf.org/internet-drafts/draft-sen-midcom-fw-nat-00.txt http://search.ietf.org/internet-drafts/draft-rosenberg-midcom-stun-00.txt http://www.ridgewaysystems.com/pdf/Whitepapers/draft-davies-fw-nat-traversal-01.txt Please read these, and let's have some serious discussions about this over the next week. Remember, the ability to compromise is a virtue. Note, as well, that although the document does not state as much there are some intellectual property claims on technology described in the Davies draft. I've appended some text that originally appeared on the APPS area web page, giving a rough description of the IETF position on IPR (http://www.apps.ietf.org/procedures.html). Please read it and take particular note of the second bullet item. In the future, if you submit a technology for consideration that is encumbered you MUST inform the working group. Thanks, Melinda ======== As all who have been with the IETF for a while know, IPR problems are a pain. The most interesting discussions are found in RFC 2026 chapter 10; the basic tenets of which are: * All IPR problems known to participants MUST be identified to the WG. * The WG is expected to prefer non-encumbered technology whenever such technology exists and is not significantly worse than the encumbered alternative. * Where licensing is an issue, licensing MUST be available on "reasonable and non-discriminatory terms". The first test is whether 2 independent licenses have in fact been granted under such terms between the Proposed and Draft status for the specification. * Patents where the patent holder has filed a grant of rights to freely use the patent are not considered terribly encumbering. For discussions of release of IPR, the correct address is the ISOC vice president for standards, Scott Bradner, ; also send CC to the IETF Chair (Fred Baker ) and the IESG secretary _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Oct 15 10:47:02 2001 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 KAA01025 for ; Mon, 15 Oct 2001 10:47: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 KAA25152; Mon, 15 Oct 2001 10: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 KAA25125 for ; Mon, 15 Oct 2001 10:35: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 KAA00628 for ; Mon, 15 Oct 2001 10:35:40 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9FEZFk13193 for ; Mon, 15 Oct 2001 07:35:15 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn2-70.cisco.com [10.21.112.70]) by airborne.cisco.com (Mirapoint) with SMTP id AAR16723; Mon, 15 Oct 2001 07:35:10 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Mon, 15 Oct 2001 10:35:17 -0400 Date: Mon, 15 Oct 2001 10:35:15 -0400 From: Scott Brim To: midcom@ietf.org Message-ID: <20011015103515.D1772@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [midcom] new bullets, 15 Oct 2001 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 new version of the bullets is now available at http://www.employees.org/~swb/midcom.html. 33 and 65 are accepted. 20 is rejected. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Oct 15 10:47:37 2001 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 KAA01050 for ; Mon, 15 Oct 2001 10:47:33 -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 KAA25332; Mon, 15 Oct 2001 10:42: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 KAA25300 for ; Mon, 15 Oct 2001 10:42:44 -0400 (EDT) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00904 for ; Mon, 15 Oct 2001 10:42:24 -0400 (EDT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.wcom.com (PMDF V5.2-33 #42261) with ESMTP id <0GL900G1N4TCYK@firewall.wcom.com> for midcom@ietf.org; Mon, 15 Oct 2001 14:41:45 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GL9006014SOOP@dgismtp04.wcomnet.com>; Mon, 15 Oct 2001 14:41:12 +0000 (GMT) Received: from rccc6131 ([166.35.225.46]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GL9003GV4S1EX@dgismtp04.wcomnet.com>; Mon, 15 Oct 2001 14:40:59 +0000 (GMT) Date: Mon, 15 Oct 2001 09:40:46 -0500 From: "Christopher A. Martin" Subject: RE: [midcom] R65 In-reply-to: <5.1.0.14.0.20011011171120.00a6cc60@mira-sjc5-4.cisco.com> To: "'Melinda Shore'" , "'midcom'" Reply-to: christopher.a.martin@wcom.com Message-id: <000001c15587$60e2b260$2ee123a6@rccc6131.mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 This is true, and this one actually falls into an authentication security category...perhaps . Possibly via SSL/TLS or some other means of transporting the MIDCOM protocol traffic. > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Melinda Shore > Sent: Thursday, October 11, 2001 4:14 PM > To: midcom > Subject: Re: [midcom] R65 > > > At 01:45 PM 10/11/01 -0700, Anderson, Todd A wrote: > >It seems to me that you wouldn't want somebody to be able to > >capture an open or close pinhole/NAT binding request and play it > >back at some arbitrary point in the future. > > We've talked about anti-replay protect in the context of the > framework document but we don't have any requirement text > covering it. I do think we need something. I'd personally > rather see a separate requirement - I don't think that all > security-related requirements should be lumped together as > one - but it's up to the discretion of the working group. > Whichever way we go let's get it settled by tomorrow > afternoon EDT. > > Melinda > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Oct 15 11:01:06 2001 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 LAA01584 for ; Mon, 15 Oct 2001 11:01: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 KAA25493; Mon, 15 Oct 2001 10:47: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 KAA25464 for ; Mon, 15 Oct 2001 10:47:39 -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 KAA01053 for ; Mon, 15 Oct 2001 10:47:37 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9FElNu00279; Mon, 15 Oct 2001 07:47:23 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-106.cisco.com [10.82.192.106]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAC05456; Mon, 15 Oct 2001 07:46:45 -0700 (PDT) Message-Id: <5.1.0.14.0.20011015104740.00a431f0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 15 Oct 2001 10:49:18 -0400 To: christopher.a.martin@wcom.com, "'midcom'" From: Melinda Shore Subject: RE: [midcom] R65 In-Reply-To: <000001c15587$60e2b260$2ee123a6@rccc6131.mcit.com> References: <5.1.0.14.0.20011011171120.00a6cc60@mira-sjc5-4.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 At 09:40 AM 10/15/01 -0500, Christopher A. Martin wrote: >This is true, and this one actually falls into an authentication security >category...perhaps . We'd talked about how to represent time increments, etc. At any rate we're not going to be requiring mechanisms, so let's get a new requirement in there: Rxx: The midcom protocol must provide protection against replay attacks. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Oct 15 11:45:51 2001 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 LAA03299 for ; Mon, 15 Oct 2001 11:45: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 LAA27306; Mon, 15 Oct 2001 11:43: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 LAA27283 for ; Mon, 15 Oct 2001 11:43:37 -0400 (EDT) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03125 for ; Mon, 15 Oct 2001 11:43:33 -0400 (EDT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.wcom.com (PMDF V5.2-33 #42260) with ESMTP id <0GL900C8N7JHE2@firewall.wcom.com> for midcom@ietf.org; Mon, 15 Oct 2001 15:41:32 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GL900A017IJCX@dgismtp04.wcomnet.com>; Mon, 15 Oct 2001 15:39:58 +0000 (GMT) Received: from rccc6131 ([166.35.225.46]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GL9007N27I195@dgismtp04.wcomnet.com>; Mon, 15 Oct 2001 15:39:38 +0000 (GMT) Date: Mon, 15 Oct 2001 10:39:34 -0500 From: "Christopher A. Martin" Subject: RE: [midcom] Thought you'd want to know In-reply-to: <20011011180117.T1216@SBRIM-W2K> To: "'Scott Brim'" , "'midcom'" Reply-to: christopher.a.martin@wcom.com Message-id: <005401c1558f$975ca500$2ee123a6@rccc6131.mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Scott Brim > Sent: Thursday, October 11, 2001 5:01 PM > To: midcom > Subject: Re: [midcom] Thought you'd want to know > > > On Thu, Oct 11, 2001 04:36:11PM -0400, Melinda Shore allegedly wrote: > > We are down to six (give or take my sloppy counting) unresolved > > requirements bullets. We'll get these wrapped up ASAP. > > My opinions on the remaining ones ... > > R86: It should possible to define rulesets that contain a more > specific filter than an overlapping ruleset, and a > different set > of attributes. This should allow Midcom agent to > request that a > subset of the traffic that would be allowed by the overlapping > ruleset be specifically disallowed. > > Reasoning: this is required for rapid response to intrusion > detection. > > Accept. > > > R35: Once the need for the relationship between a Midcom > Agent and a > Middlebox established during the registration process has > lapsed, a deregistration process will be required. This will > break the trust relationship between the specific > Middlebox and > Midcom Agent. Once this has been done, a Middlebox MUST NOT > service any further requests from a given Midcom Agent without > the Midcom Agent first re-establishing the appropriate trust > relationship with the Middlebox. How about this, : ------------ R35: If MIDCOM peer authentication timer has expired, assuming that an authentication timeout is implemented, MIDCOM peers must renegotiate for proper authentication. If renegotiation fails further MIDCOM requests MUST be denied by the Middlebox until authentication negotiation is successful. ------------ This should possibly also be coupled with a maximum retry period to lock out renegotian after n*failed attempts. > > Wording problems. "Registration" needs better > definition (in > framework?). "Lapsed" is not understood the same by > everyone. > > This is obvious. Discard. > > R38: The Midcom Protocol MUST enable the Middlebox and/or Midcom > Agent to determine when a registration session is no longer > valid. This is to address cases such as when either > a Middlebox > or MIDCOM Agent restarts. Maybe we should reword it to place it more in line with the actual authentication between the two entities (Middlebox and MIDCOM agent). We should address some form of authentication mechanism if not within the protocol, then at least require some form of authentication such as SSL/TLS be used. Policy server would be more inline with the fact that the two entities are allowed to authenticate. > > "Registration", as used by Suresh and in this case, is a policy issue. > It's what happens when a middlebox (or agent) hears from some policy > entity that an agent (or a middlebox) is allowed to > communicate at all. > This doesn't have anything to do with the midcom protocol, but rather > with policy interactions. So far we've done close to nothing wrt > policy. I say discard this one, since it will be included in whatever > we finally do with policy. > > R43: The Midcom Protocol SHOULD allow the aggregation of commands, > requests and responses. > > We don't know what this one really means, but we're putting > off judgment until we know more about our other > requirements. This could possibly be used in relation to a protocol such as SIP that can initiate several conversations through the same middle box (as in the case of a conference call) to request multiple rulesets for the call leg(s) at the same time...to lower call setup time. Just my two cents...for further discussion during judgement :^) > > Already covered by already accepted ones. Discard. > > R47: When accepting a request for a pin-hole, the Middlebox MUST be > able to provide the MIDCOM Agent with information that may be > used to identify the resource in subsequent operations. > > Temporarily changed "flow" to "resource". Need better word > than "resource". > How about initiator/terminator... to identify an end host within the Middleboxes realm that may either be intitiating or terminating IP traffic. > I think we should discard this too. We don't know how midcom will be > used, especially when multiple agents and middleboxes get involved. > There are two possible approaches. First, accept this > requirement, and > require a field in the protocol packets with a note that it *might* be > used for an identifier, but keep it reserved and do our best > not to use > it. After a while we'll know if we need it. If we don't we > can use it > for future expansion. The other option is to abandon this > requirement, > and if in the future someone decides they really need an identifier, > they can add it using the protocol's extensibility features. The only > reason to stick the field in now is if there are performance issues. > > R75: The Midcom Protocol must produce robust operation even when > routing changes such that traffic from a particular end system > passes through a different middlebox. (Huitema) > > Eliot Lear says "this takes too much state". > > I don't think supporting this kind of robustness is the job of the > midcom protocol. I think the model underlying this one is poorly > formed. Discard. > > ..Scott > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Oct 15 13:39:47 2001 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 NAA07007 for ; Mon, 15 Oct 2001 13:39:47 -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 NAA00644; Mon, 15 Oct 2001 13:26: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 NAA00615 for ; Mon, 15 Oct 2001 13:26:01 -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 NAA06438 for ; Mon, 15 Oct 2001 13:25:59 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9FHPiu24717; Mon, 15 Oct 2001 10:25:44 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-106.cisco.com [10.82.192.106]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAD01837; Mon, 15 Oct 2001 10:25:03 -0700 (PDT) Message-Id: <5.1.0.14.0.20011015132345.00a70da0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 15 Oct 2001 13:27:35 -0400 To: christopher.a.martin@wcom.com, "'Scott Brim'" , "'midcom'" From: Melinda Shore Subject: RE: [midcom] Thought you'd want to know In-Reply-To: <005401c1558f$975ca500$2ee123a6@rccc6131.mcit.com> References: <20011011180117.T1216@SBRIM-W2K> 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 10/15/01 -0500, Christopher A. Martin wrote: >How about this, : >------------ >R35: If MIDCOM peer authentication timer has expired, assuming that an >authentication timeout is implemented, MIDCOM peers must renegotiate for >proper authentication. If renegotiation fails further MIDCOM requests MUST >be denied by the Middlebox until authentication negotiation is successful. >------------ No, I think it's not what we mean (we don't care why authentication would be terminated, but we might care that it is - and this is really an authorization question, anyway). I'm with Scott. R35 is obvious and should be deleted. >> R38: The Midcom Protocol MUST enable the Middlebox and/or Midcom >> Agent to determine when a registration session is no longer >> valid. This is to address cases such as when either >> a Middlebox >> or MIDCOM Agent restarts. > >Maybe we should reword it to place it more in line with the actual >authentication between the two entities (Middlebox and MIDCOM agent). No, because it needs to be consistent across authenticated and unauthenticated sessions. I'm all for deleting it, especially since we've got another requirement mandating the ability to notify agents of various middlebox events, including restarts. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Oct 15 13:57:01 2001 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 NAA07904 for ; Mon, 15 Oct 2001 13:57: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 NAA01584; Mon, 15 Oct 2001 13:52: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 NAA01553 for ; Mon, 15 Oct 2001 13:52:35 -0400 (EDT) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07747 for ; Mon, 15 Oct 2001 13:52:34 -0400 (EDT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.wcom.com (PMDF V5.2-33 #42260) with ESMTP id <0GL9008GMDMOTO@firewall.wcom.com> for midcom@ietf.org; Mon, 15 Oct 2001 17:52:00 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GL900K01DLX6V@dgismtp04.wcomnet.com>; Mon, 15 Oct 2001 17:51:59 +0000 (GMT) Received: from rccc6131 ([166.35.225.46]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GL900ILVDLL4X@dgismtp04.wcomnet.com>; Mon, 15 Oct 2001 17:51:22 +0000 (GMT) Date: Mon, 15 Oct 2001 12:51:17 -0500 From: "Christopher A. Martin" Subject: RE: [midcom] R65 In-reply-to: <17A7C43776A6D5118A2800508B68D7A89B1A99@orsmsx113.jf.intel.com> To: "'Anderson, Todd A'" , "'midcom'" Reply-to: christopher.a.martin@wcom.com Message-id: <008701c155a1$fe47d2a0$2ee123a6@rccc6131.mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 authentication methods typically include some form of hash over the authentication field, or perhaps a separate protocol can be used such as SSL/TLS. If MIDCOM protocol can be implemented with SSL/TLS (i.e. is TCP protocol)then it would naturally fit into a possible future architecture that can also garauntee non-repudiation. > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Anderson, Todd A > Sent: Thursday, October 11, 2001 3:45 PM > To: midcom > Subject: [midcom] R65 > > > > -----Original Message----- > > From: Melinda Shore [mailto:mshore@cisco.com] > > Sent: Thursday, October 11, 2001 10:25 AM > > To: midcom > > Subject: [midcom] Resolved > > > > R65: rewritten - "The midcom protocol must provide for message > > authentication confidentiality and integrity." > > It seems to me that you wouldn't want somebody to be able to > capture an open or close pinhole/NAT binding request and play it > back at some arbitrary point in the future. I don't think any > of the stated security properties listed above protect against > replay attacks. My preference would be to see the "freshness" > security property added to this requirement but if people want > to make a new requirement that is fine too. > > Possible attacks if freshness is not required: > 1. someone captures an open request and plays it back to reopen > the pinhole after it has been closed. > 2. someone captures a close request and plays it back to close > a duplicate pinhole reopened later. > > Todd Anderson > Intel Labs > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 16 07:09:17 2001 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 HAA09225 for ; Tue, 16 Oct 2001 07:09: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 HAA03872; Tue, 16 Oct 2001 07:06: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 HAA03843 for ; Tue, 16 Oct 2001 07:06:32 -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 HAA08861; Tue, 16 Oct 2001 07:06:30 -0400 (EDT) Message-Id: <200110161106.HAA08861@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, 16 Oct 2001 07:06:30 -0400 Subject: [midcom] I-D ACTION:draft-bryan-midcom-simple-strawman-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 : A Simple Middlebox Protocol Author(s) : D. Bryant Filename : draft-bryan-midcom-simple-strawman-00.txt Pages : 19 Date : 15-Oct-01 This is a very simple strawman protocol for agents to request NAT address translations and firewall pinholes from a middlebox. This protocol uses the underlying transport for reliability and to avoid reinventing TCP. This protocol does not use an existing protocol like COPS, SOAP, HTTP or DIAMETER as these protocols include significant complexity that is not required to solve the middlebox problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bryan-midcom-simple-strawman-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-bryan-midcom-simple-strawman-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-bryan-midcom-simple-strawman-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: <20011015133504.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bryan-midcom-simple-strawman-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-bryan-midcom-simple-strawman-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011015133504.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 16 13:03:00 2001 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 NAA10782 for ; Tue, 16 Oct 2001 13: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 MAA14383; Tue, 16 Oct 2001 12:59: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 MAA14356 for ; Tue, 16 Oct 2001 12:59:27 -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 MAA10622 for ; Tue, 16 Oct 2001 12:59:26 -0400 (EDT) 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 f9GGx2k23543 for ; Tue, 16 Oct 2001 09:59:02 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-125.cisco.com [10.82.192.125]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAH00074; Tue, 16 Oct 2001 09:58:35 -0700 (PDT) Message-Id: <5.1.0.14.0.20011016125351.00a68500@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 16 Oct 2001 13:01:00 -0400 To: midcom From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Status 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 R86 Accepted with revisions: R86: It should possible to define rulesets that contain a more specific filter spec than an overlapping ruleset. This should allow agents to request actions for the subset that contradict those of the overlapping set. This should allow Midcom agent to request to a Midcom server controlling a firewall function that a subset of the traffic that would be allowed by the overlapping ruleset be specifically disallowed. R35 Delete R38 Delete R43 Delete R47 Delete R75 Needs more discussion R?? Accepted: "The midcom protocol must provide protection against replay attacks" Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 16 13:34:58 2001 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 NAA11997 for ; Tue, 16 Oct 2001 13:34: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 NAA15103; Tue, 16 Oct 2001 13:18: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 NAA15072 for ; Tue, 16 Oct 2001 13:18:38 -0400 (EDT) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11320 for ; Tue, 16 Oct 2001 13:18:36 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f9GHHXS21486 for ; Tue, 16 Oct 2001 13:17:34 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Tue, 16 Oct 2001 13:17:45 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4SX6TNWS>; Tue, 16 Oct 2001 13:17:24 -0400 Message-ID: <28560036253BD41191A10000F8BCBD110514FCA4@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "'Melinda Shore'" , midcom Subject: RE: [midcom] Status Date: Tue, 16 Oct 2001 13:17:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15666.6ADBD7D0" X-Orig: 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_01C15666.6ADBD7D0 Content-Type: text/plain; charset="iso-8859-1" Is there any restriction on which Midcom agent can create the overriding ruleset? Does it have to be the MA that created the parent ruleset, or can it be another one? If the latter, does the protocol have to provide the capability for the MB to notify the creator of the parent ruleset that it is being partially overridden? -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Tuesday, October 16, 2001 1:01 PM To: midcom Subject: [midcom] Status R86 Accepted with revisions: R86: It should possible to define rulesets that contain a more specific filter spec than an overlapping ruleset. This should allow agents to request actions for the subset that contradict those of the overlapping set. This should allow Midcom agent to request to a Midcom server controlling a firewall function that a subset of the traffic that would be allowed by the overlapping ruleset be specifically disallowed. R35 Delete R38 Delete R43 Delete R47 Delete R75 Needs more discussion R?? Accepted: "The midcom protocol must provide protection against replay attacks" Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C15666.6ADBD7D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Status

Is there any restriction on which Midcom agent can = create the overriding ruleset?  Does it have to be the MA that = created the parent ruleset, or can it be another one?  If the = latter, does the protocol have to provide the capability for the MB to = notify the creator of the parent ruleset that it is being partially = overridden?

-----Original Message-----
From: Melinda Shore [mailto:mshore@cisco.com]
Sent: Tuesday, October 16, 2001 1:01 PM
To: midcom
Subject: [midcom] Status


R86 Accepted with revisions:
  R86: It should possible to define rulesets = that contain a more specific
  filter spec than an overlapping ruleset. This = should allow agents to
  request actions for the subset that = contradict those of the overlapping
  set. This should allow Midcom agent to = request to a Midcom server
  controlling a firewall function that a subset = of the traffic that would
  be allowed by the overlapping ruleset be = specifically disallowed.

R35 Delete
R38 Delete
R43 Delete
R47 Delete
R75 Needs more discussion
R?? Accepted:
  "The midcom protocol must provide = protection against replay
  attacks"

Melinda


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

------_=_NextPart_001_01C15666.6ADBD7D0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 16 14:17:45 2001 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 OAA13756 for ; Tue, 16 Oct 2001 14:17: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 OAA17089; Tue, 16 Oct 2001 14:08: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 OAA17060 for ; Tue, 16 Oct 2001 14:08:37 -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 OAA13431 for ; Tue, 16 Oct 2001 14:08:34 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9GI8Ku17539 for ; Tue, 16 Oct 2001 11:08:20 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn2-211.cisco.com [10.21.112.211]) by airborne.cisco.com (Mirapoint) with SMTP id AAV03881; Tue, 16 Oct 2001 11:08:05 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Tue, 16 Oct 2001 14:08:03 -0400 Date: Tue, 16 Oct 2001 14:08:03 -0400 From: Scott Brim To: midcom Subject: Re: [midcom] Status Message-ID: <20011016140803.E1696@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom References: <5.1.0.14.0.20011016125351.00a68500@mira-sjc5-4.cisco.com> 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.20011016125351.00a68500@mira-sjc5-4.cisco.com>; from mshore@cisco.com on Tue, Oct 16, 2001 at 01:01:00PM -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, Oct 16, 2001 01:01:00PM -0400, Melinda Shore allegedly wrote: > R86 Accepted with revisions: > R86: It should possible to define rulesets that contain a more > specific filter spec than an overlapping ruleset. This should allow > agents to request actions for the subset that contradict those of > the overlapping set. This should allow Midcom agent to request to a > Midcom server controlling a firewall function that a subset of the > traffic that would be allowed by the overlapping ruleset be > specifically disallowed. First I don't see what SHOULD statements are doing in requirements. Is this a requirement or not? Second, why is there a firewall example? Why is there an example at all? > R35 Delete > R38 Delete > R43 Delete > R47 Delete > R75 Needs more discussion > R?? Accepted: > "The midcom protocol must provide protection against replay > attacks" R73 is currently "The Midcom Protocol MUST define mechanisms to mitigate reply attacks on the control messages." and was already accepted. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 16 15:05:38 2001 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 PAA15902 for ; Tue, 16 Oct 2001 15:05:38 -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 PAA19067; Tue, 16 Oct 2001 15:03: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 PAA19039 for ; Tue, 16 Oct 2001 15:03:09 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15732 for ; Tue, 16 Oct 2001 15:03:08 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id OAA02089 for ; Tue, 16 Oct 2001 14:02:41 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Tue, 16 Oct 2001 13:55:39 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Oct 2001 14:01:47 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E06F22C@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'midcom@ietf.org'" Date: Tue, 16 Oct 2001 14:01:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15675.007BF2D0" X-Orig: Subject: [midcom] R85? 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_01C15675.007BF2D0 Content-Type: text/plain; charset="iso-8859-1" R85: It must be possible to deterministically predict the behavior of the middlebox in the presence of overlapping rules. Why is this a Midcom protocol requirement? ------_=_NextPart_001_01C15675.007BF2D0 Content-Type: text/html; charset="iso-8859-1" R85?

R85: It must be possible to deterministically predict the behavior of
        the middlebox in the presence of overlapping rules.

Why is this a Midcom protocol requirement?

------_=_NextPart_001_01C15675.007BF2D0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 16 16:47:41 2001 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 QAA20442 for ; Tue, 16 Oct 2001 16:47: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 QAA22840; Tue, 16 Oct 2001 16:42:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22810 for ; Tue, 16 Oct 2001 16:42:51 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20271 for ; Tue, 16 Oct 2001 16:42:50 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 49ZFBTQX; Tue, 16 Oct 2001 16:42:23 -0400 Message-Id: <3.0.5.32.20011016164120.008c4260@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 16 Oct 2001 16:41:20 -0400 To: midcom From: Mark Duffy In-Reply-To: <5.1.0.14.0.20011016125351.00a68500@mira-sjc5-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] additional midcom reqts 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 Now that all but one of the requirements items have been dispositioned, I re-read the list. It strikes me that most of the remaining requirements concern the protocol mechanisms and are pretty generic at that. There is not that much about what semantics may be conveyed between an agent and a mb. Sect. 2.7 contains some reqts that discuss things having to do with rulesets but most of them are housekeeping types of reqts. R83 and R84 are the only ones that say anything at all about what the ruleset action specs may be. (These are requirements about requesting NAT bindings according to some constraints on port numbers.) I would like to see us add a few more requirements about the action specs that an agent may invoke. It seems to me that this is a fundamental aspect of what we are trying to accomplish. What is the use of all the protocol mechanism if we don't say what you can use it for? Here are a few specific midlebox actions I think are needed: . Allocate a NAT address binding . Allocate a NAPT address & port binding . Create a firewall hole For all the above I think we need several flavors of when the action spec goes away, here are a few suggestions: . only when explicitly removed by an authorized agent . at the expiration of a timer (and/or at a specific date/time) . after a TCP connection associated with the filterspec closes (e.g. FINs and ACKs exchanged) And perhaps even some flavors of when the action spec goes into effect: . immediately . when TCP SYN is seen incoming . when tcp SYN is seen outgoing If there is interest I can bundle theses into some requirements statements for discussion. If there is the outpouring of "that stuff is out of scope" sentiment that I half expect, then I'll go back into my corner :-) -Mark P.S. One other requirement area that I think is still not addressed is a way to scope a ruleset to only those packets that arrive/depart the middlebox on cetain interface(s)/realm(s) etc. I am presuming this will be addressed when the "topology question" is resolved. Yes? _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 16 17:08:15 2001 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 RAA20968 for ; Tue, 16 Oct 2001 17:08: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 RAA23571; Tue, 16 Oct 2001 17:06: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 RAA23542 for ; Tue, 16 Oct 2001 17:06:43 -0400 (EDT) Received: from eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20961 for ; Tue, 16 Oct 2001 17:06:41 -0400 (EDT) Received: (from sob@localhost) by eecs.harvard.edu (8.10.2/8.10.2) id f9GL6Oo03066 for midcom@ietf.org; Tue, 16 Oct 2001 17:06:24 -0400 (EDT) Date: Tue, 16 Oct 2001 17:06:24 -0400 (EDT) From: Scott Bradner Message-Id: <200110162106.f9GL6Oo03066@eecs.harvard.edu> To: midcom@ietf.org Subject: [midcom] additional midcom reqts 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 sigh - I'd sure like to get this phase wrapped up - the aim is not to figure out all possible requirements for something like midcom - it should be to figure out the basic set of functions needed to get the job done. This is surely a case of 'done when the last non-basic thing is removed' not 'done when the document gets too big to print' Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 16 17:35:57 2001 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 RAA21327 for ; Tue, 16 Oct 2001 17:35: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 RAA24016; Tue, 16 Oct 2001 17:29: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 RAA23985 for ; Tue, 16 Oct 2001 17:29:00 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21234 for ; Tue, 16 Oct 2001 17:28:58 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 49ZFBTTD; Tue, 16 Oct 2001 17:28:31 -0400 Message-Id: <3.0.5.32.20011016172727.008b79a0@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 16 Oct 2001 17:27:27 -0400 To: Scott Bradner , midcom@ietf.org From: Mark Duffy Subject: Re: [midcom] additional midcom reqts In-Reply-To: <200110162106.f9GL6Oo03066@eecs.harvard.edu> 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 Hi Scott, My apologies for asking this but perhaps your message is too subtle for me :-) I'd love to get the phase wrapped up too. The tone of your message suggests that you believe the additional requirements I proposed are perhaps beyond what we should be working on. From my perspective, identifying a reasonable, common set of actions that an agent may use midcom to ask a middlebox to do should be part of our work. But stating every possible action is not something we should do. I do not believe the current list of requirements says anything about what an agent may ask a mb to do, with the exception of 2 very specific requirements related to a somewhat specialized request to be made of a NAT middlebox. Do you feel we should not identify any actions the midcom protocol may be used request? Or that we already have a sufficient identification of such actions? Or we need something in that area but my proposal goes too far? Or I have misunderstood you entirely? Thanks, Mark At 05:06 PM 10/16/01 -0400, Scott Bradner wrote: > >sigh - I'd sure like to get this phase wrapped up - the aim is not to figure >out all possible requirements for something like midcom - it should be to >figure out the basic set of functions needed to get the job done. >This is surely a case of 'done when the last non-basic thing is removed' >not 'done when the document gets too big to print' > >Scott > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 16 17:50:00 2001 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 RAA21450 for ; Tue, 16 Oct 2001 17:50: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 RAA24570; Tue, 16 Oct 2001 17:48: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 RAA24539 for ; Tue, 16 Oct 2001 17:48:44 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21396 for ; Tue, 16 Oct 2001 17:48:41 -0400 (EDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id QAA05091 for ; Tue, 16 Oct 2001 16:48:09 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Tue, 16 Oct 2001 14:40:36 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Oct 2001 14:41:24 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E06F22E@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Scott Brim'" , midcom@ietf.org Subject: RE: [midcom] new bullets, 15 Oct 2001 Date: Tue, 16 Oct 2001 14:41:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1567A.891E7CC0" 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_01C1567A.891E7CC0 Content-Type: text/plain; charset="iso-8859-1" Scott, In the draft, is everything under Section 5 (and its subsections) rejected? For example: R6: A middlebox must be able to associate a timer with a ruleset. When a timer expires, resources are freed. R81: The Midcom Protocol MUST enable a Midcom Agent to associate a timer with a ruleset. I don't remember that these are rejected. Sanjoy > -----Original Message----- > From: Scott Brim [mailto:swb@employees.org] > Sent: Monday, October 15, 2001 9:35 AM > To: midcom@ietf.org > Subject: [midcom] new bullets, 15 Oct 2001 > > > A new version of the bullets is now available at > http://www.employees.org/~swb/midcom.html. > > 33 and 65 are accepted. > 20 is rejected. > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C1567A.891E7CC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] new bullets, 15 Oct 2001

Scott,

In the draft, is everything under Section 5 (and its = subsections) rejected?
For example:
R6: A middlebox must be able to associate a timer = with a ruleset.
       When a timer = expires, resources are freed.
R81: The Midcom Protocol MUST enable a Midcom Agent = to associate a
        timer = with a ruleset. 

I don't remember that these are rejected.

Sanjoy

> -----Original Message-----
> From: Scott Brim [mailto:swb@employees.org]
> Sent: Monday, October 15, 2001 9:35 AM
> To: midcom@ietf.org
> Subject: [midcom] new bullets, 15 Oct = 2001
>
>
> A new version of the bullets is now available = at
> http://www.employees.org/~swb/midcom.html.  =
>
> 33 and 65 are accepted.
> 20 is rejected.
>
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C1567A.891E7CC0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 16 17:50:42 2001 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 RAA21497 for ; Tue, 16 Oct 2001 17:50: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 RAA24612; Tue, 16 Oct 2001 17:49: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 RAA24581 for ; Tue, 16 Oct 2001 17:49:08 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21406 for ; Tue, 16 Oct 2001 17:49:06 -0400 (EDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id QAA05097 for ; Tue, 16 Oct 2001 16:48:09 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Tue, 16 Oct 2001 13:41:29 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Oct 2001 13:42:16 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E06F22B@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Melinda Shore'" , midcom Subject: RE: [midcom] Status Date: Tue, 16 Oct 2001 13:42:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15672.42AF9BF0" 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_01C15672.42AF9BF0 Content-Type: text/plain; charset="iso-8859-1" Why is R43 deleted? I think its a very useful requirement to be able to group multiple commands within a single transaction for efficiency reasons. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Tuesday, October 16, 2001 12:01 PM > To: midcom > Subject: [midcom] Status > > > R86 Accepted with revisions: > R86: It should possible to define rulesets that contain a > more specific > filter spec than an overlapping ruleset. This should allow agents to > request actions for the subset that contradict those of the > overlapping > set. This should allow Midcom agent to request to a Midcom server > controlling a firewall function that a subset of the > traffic that would > be allowed by the overlapping ruleset be specifically disallowed. > > R35 Delete > R38 Delete > R43 Delete > R47 Delete > R75 Needs more discussion > R?? Accepted: > "The midcom protocol must provide protection against replay > attacks" > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C15672.42AF9BF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Status

Why is R43 deleted? I think its a very useful = requirement to be able to group multiple commands within a single = transaction for efficiency reasons.

> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Tuesday, October 16, 2001 12:01 PM
> To: midcom
> Subject: [midcom] Status
>
>
> R86 Accepted with revisions:
>   R86: It should possible to define = rulesets that contain a
> more specific
>   filter spec than an overlapping = ruleset. This should allow agents to
>   request actions for the subset that = contradict those of the
> overlapping
>   set. This should allow Midcom agent = to request to a Midcom server
>   controlling a firewall function = that a subset of the
> traffic that would
>   be allowed by the overlapping = ruleset be specifically disallowed.
>
> R35 Delete
> R38 Delete
> R43 Delete
> R47 Delete
> R75 Needs more discussion
> R?? Accepted:
>   "The midcom protocol must = provide protection against replay
>   attacks"
>
> Melinda
>
>
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C15672.42AF9BF0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 16 18:21:40 2001 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 SAA22046 for ; Tue, 16 Oct 2001 18:21: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 SAA25328; Tue, 16 Oct 2001 18:13: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 SAA25299 for ; Tue, 16 Oct 2001 18:13:56 -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 SAA21912 for ; Tue, 16 Oct 2001 18:13:54 -0400 (EDT) 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 f9GMDXg07354; Tue, 16 Oct 2001 15:13:33 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-118.cisco.com [10.82.192.118]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAH13011; Tue, 16 Oct 2001 15:13:03 -0700 (PDT) Message-Id: <5.1.0.14.0.20011016181441.00a6ddd0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 16 Oct 2001 18:15:23 -0400 To: "Sanjoy Sen" , midcom From: Melinda Shore Subject: RE: [midcom] Status In-Reply-To: <933FADF5E673D411B8A30002A5608A0E06F22B@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 01:42 PM 10/16/01 -0500, Sanjoy Sen wrote: >Why is R43 deleted? I think its a very useful requirement to be able to group multiple commands within a single transaction for efficiency reasons. R43 was deleted because there was rough consensus to delete it. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 16 18:25:49 2001 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 SAA22101 for ; Tue, 16 Oct 2001 18:25: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 SAA25532; Tue, 16 Oct 2001 18:24: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 SAA25503 for ; Tue, 16 Oct 2001 18:24:01 -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 SAA22074 for ; Tue, 16 Oct 2001 18:23:58 -0400 (EDT) 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 f9GMNak25197; Tue, 16 Oct 2001 15:23:36 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-118.cisco.com [10.82.192.118]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAH13375; Tue, 16 Oct 2001 15:23:08 -0700 (PDT) Message-Id: <5.1.0.14.0.20011016181545.00a6a490@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 16 Oct 2001 18:25:28 -0400 To: Mark Duffy , midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] additional midcom reqts In-Reply-To: <3.0.5.32.20011016172727.008b79a0@email.quarrytech.com> References: <200110162106.f9GL6Oo03066@eecs.harvard.edu> 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 not Scott (did you notice?), but I'm going to take a crack at this from the chair's perspective: At 05:27 PM 10/16/01 -0400, Mark Duffy wrote: >I >do not believe the current list of requirements says anything about what an >agent may ask a mb to do, with the exception of 2 very specific >requirements related to a somewhat specialized request to be made of a NAT >middlebox. I think that should be considered a good thing. The charter and the framework documents convey the gist of what it is we're trying to do, and from those it should be self-evident what sorts of requests are going to be sent to the middlebox. Loading up with detail essentially translates to protocol design and that's not our job right now. In the meantime we've lost a *lot* of time to going into unnecessary detail in the first place and then whittling down the list in the second. Scott is, I think, alluding to a quote by Saint-Exupery, who says "Perfection is achieved, not when there is nothing left to add, but when there is nothing left to remove." By that yardstick we've fallen well short of perfection. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 16 18:34:35 2001 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 SAA22243 for ; Tue, 16 Oct 2001 18:34: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 SAA26017; Tue, 16 Oct 2001 18:33: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 SAA25991 for ; Tue, 16 Oct 2001 18:33:20 -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 SAA22238 for ; Tue, 16 Oct 2001 18:33:17 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9GMWtk02983 for ; Tue, 16 Oct 2001 15:32:55 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn2-211.cisco.com [10.21.112.211]) by airborne.cisco.com (Mirapoint) with SMTP id AAV08755; Tue, 16 Oct 2001 15:32:50 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Tue, 16 Oct 2001 18:32:47 -0400 Date: Tue, 16 Oct 2001 18:32:47 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] new bullets, 15 Oct 2001 Message-ID: <20011016183247.P1696@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <933FADF5E673D411B8A30002A5608A0E06F22E@zrc2c012.us.nortel.com> <20011016183030.N1696@SBRIM-W2K> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011016183030.N1696@SBRIM-W2K>; from swb@employees.org on Tue, Oct 16, 2001 at 06:30: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, Oct 16, 2001 02:41:22PM -0500, Sanjoy Sen allegedly wrote: > Scott, > > In the draft, is everything under Section 5 (and its subsections) rejected? Right. > For example: > R6: A middlebox must be able to associate a timer with a ruleset. > When a timer expires, resources are freed. > R81: The Midcom Protocol MUST enable a Midcom Agent to associate a > timer with a ruleset. > > I don't remember that these are rejected. Oh boy. I stopped taking notes on the discussions of the different bullets. My memory is that these were considered too specific, that they were solutions, not requirements. I think their requirements were considered to be a subset of R23 (must be a known and stable state). If you want to be sure, I'd search the archives. Sorry, I abandoned keeping an audit trail because discussion was so free-wheeling. ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Oct 16 18:38:48 2001 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 SAA22298 for ; Tue, 16 Oct 2001 18:38: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 SAA26202; Tue, 16 Oct 2001 18:37: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 SAA26117 for ; Tue, 16 Oct 2001 18:37:45 -0400 (EDT) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22282 for ; Tue, 16 Oct 2001 18:37:37 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f9GMaaS02000 for ; Tue, 16 Oct 2001 18:36:36 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Tue, 16 Oct 2001 18:37:08 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4SX6TV91>; Tue, 16 Oct 2001 18:36:45 -0400 Message-ID: <28560036253BD41191A10000F8BCBD110514FCAB@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "Sanjoy Sen" , "'Scott Brim'" , midcom Subject: RE: [midcom] Latest requirements bullets resolved Date: Tue, 16 Oct 2001 18:36:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15693.073F8870" X-Orig: 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_01C15693.073F8870 Content-Type: text/plain; charset="iso-8859-1" I pulled this out of the archive from a month back. -----Original Message----- From: Sen, Sanjoy [NGB:B602:EXCH] Sent: Monday, September 24, 2001 3:40 PM To: 'Scott Brim'; midcom Subject: RE: [midcom] Latest requirements bullets resolved > -----Original Message----- > From: Scott Brim [ mailto:swb@employees.org ] > Sent: Monday, September 24, 2001 1:10 PM > To: midcom > Subject: Re: [midcom] Latest requirements bullets resolved > > > On Mon, Sep 24, 2001 12:56:40PM -0500, Sanjoy Sen allegedly wrote: > > > You want to know when a ruleset timer expires? But > you're the one who > > > set it. > > > > The Midcom Agent may not want to maintain the timer state. > It may just want > > to install a timer state in the MB and be notified when the > timer expires & > > react to that notification with specific activities. > > This is a months-old argument, about where to put the complexity. > Recent trends seem to be to pile complexity in the agent and keep the > middlebox simple -- viz. the example of a simple bump-in-the-wire > firewall, and the tendency to bundle application proxies with midcom > agents. That's evidence of where people seem to want to go. I also > think it's a safer base for the future to keep control state > complexity > in the controller, not the controlled object. That's about > fate-sharing > and "ownership" of state. > If I remember correctly, people actually thought that there was no need for the Agent to maintain the timer state as they'll be maintained by the MB anyway (what's the purpose of reqmts R6 & R81? What if the Agent dies after installing a ruleset?). If the MA is not keeping timer state, how would it know when to refresh the ruleset unless notified by the MB? ------_=_NextPart_001_01C15693.073F8870 Content-Type: text/html; charset="iso-8859-1" RE: [midcom] Latest requirements bullets resolved
I pulled this out of the archive from a month back.
-----Original Message-----
From: Sen, Sanjoy [NGB:B602:EXCH]
Sent: Monday, September 24, 2001 3:40 PM
To: 'Scott Brim'; midcom
Subject: RE: [midcom] Latest requirements bullets resolved



> -----Original Message-----
> From: Scott Brim [mailto:swb@employees.org]
> Sent: Monday, September 24, 2001 1:10 PM
> To: midcom
> Subject: Re: [midcom] Latest requirements bullets resolved
>
>
> On Mon, Sep 24, 2001 12:56:40PM -0500, Sanjoy Sen allegedly wrote:
> > > You want to know when a ruleset timer expires?  But
> you're the one who
> > > set it. 
> >
> > The Midcom Agent may not want to maintain the timer state.
> It may just want
> > to install a timer state in the MB and be notified when the
> timer expires &
> > react to that notification with specific activities.
>
> This is a months-old argument, about where to put the complexity.
> Recent trends seem to be to pile complexity in the agent and keep the
> middlebox simple -- viz. the example of a simple bump-in-the-wire
> firewall, and the tendency to bundle application proxies with midcom
> agents.  That's evidence of where people seem to want to go.  I also
> think it's a safer base for the future to keep control state
> complexity
> in the controller, not the controlled object.  That's about
> fate-sharing
> and "ownership" of state.
>

If I remember correctly, people actually thought that there was no need for the Agent to maintain the timer state as they'll be maintained by the MB anyway (what's the purpose of reqmts R6 & R81? What if the Agent dies after installing a ruleset?). If the MA is not keeping timer state, how would it know when to refresh the ruleset unless notified by the MB?  

------_=_NextPart_001_01C15693.073F8870-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Oct 17 08:18:02 2001 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 IAA20017 for ; Wed, 17 Oct 2001 08:18: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 IAA22604; Wed, 17 Oct 2001 08:14: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 IAA22575 for ; Wed, 17 Oct 2001 08:14:26 -0400 (EDT) Received: from web13802.mail.yahoo.com (web13802.mail.yahoo.com [216.136.175.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19878 for ; Wed, 17 Oct 2001 08:14:24 -0400 (EDT) Message-ID: <20011017121426.70434.qmail@web13802.mail.yahoo.com> Received: from [65.12.33.187] by web13802.mail.yahoo.com via HTTP; Wed, 17 Oct 2001 05:14:26 PDT Date: Wed, 17 Oct 2001 05:14:26 -0700 (PDT) From: Pyda Srisuresh To: midcom@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [midcom] Rev4 of MIDCOM Architecture & framework document 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 Folks, Rev4 of the Architecture & Framework document has been out for a couple of weeks. This rev includes updates to some of the exisiting definitions, newer terminology additions and various other comments received during and before the last IETF. I have also tried to ensure that the document is in line with section 2 of "Bullets -010924.txt", available at . Please review the document and let us know your comments. Thanks. cheers, suresh ===== __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Oct 17 11:34:11 2001 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 LAA27564 for ; Wed, 17 Oct 2001 11:34: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 LAA28450; Wed, 17 Oct 2001 11:29:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28415 for ; Wed, 17 Oct 2001 11:29:50 -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 LAA27449 for ; Wed, 17 Oct 2001 11:29:49 -0400 (EDT) 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 f9HFRDC03944; Wed, 17 Oct 2001 08:27:13 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-38.cisco.com [10.82.192.38]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAO04617; Wed, 17 Oct 2001 08:28:55 -0700 (PDT) Message-Id: <5.1.0.14.0.20011017113029.00a66980@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 17 Oct 2001 11:31:29 -0400 To: Mark Duffy , midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] additional midcom reqts In-Reply-To: <3.0.5.32.20011017112621.008ff720@email.quarrytech.com> References: <5.1.0.14.0.20011016181545.00a6a490@mira-sjc5-4.cisco.com> <3.0.5.32.20011016172727.008b79a0@email.quarrytech.com> <200110162106.f9GL6Oo03066@eecs.harvard.edu> 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:26 AM 10/17/01 -0400, Mark Duffy wrote: > Rxxx: The Midcom protocol MUST allow a Midcom agent to request a > firewall opening from a middlebox that provides a firewall > function. > > Ryyy: The Midcom protocol MUST allow a Midcom agent to request > creation of an address binding or an address+port binding > from a middlebox that provides a NAT function. > > Rzzz: The Midcom protocol MUST allow a Midcom agent to learn the > address and port values assigned when a middlebox providing > a NAT function creates a binding at the behest of the > midcom agent. > >Those to me are a minimalist embodiment of our charter that Midcom must >address NAT and firewall middleboxes. Do you think that if we leave these out, the next iteration of the working group would fail to include these functions in the protocol? Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Oct 17 11:34:20 2001 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 LAA27576 for ; Wed, 17 Oct 2001 11:34: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 LAA28374; Wed, 17 Oct 2001 11:27: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 LAA28345 for ; Wed, 17 Oct 2001 11:27:52 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27384 for ; Wed, 17 Oct 2001 11:27:51 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 49ZFBWPM; Wed, 17 Oct 2001 11:27:23 -0400 Message-Id: <3.0.5.32.20011017112621.008ff720@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 17 Oct 2001 11:26:21 -0400 To: Melinda Shore , midcom@ietf.org From: Mark Duffy Subject: Re: [midcom] additional midcom reqts In-Reply-To: <5.1.0.14.0.20011016181545.00a6a490@mira-sjc5-4.cisco.com> References: <3.0.5.32.20011016172727.008b79a0@email.quarrytech.com> <200110162106.f9GL6Oo03066@eecs.harvard.edu> 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 06:25 PM 10/16/01 -0400, Melinda Shore wrote: >I'm not Scott (did you notice?), but I'm going to take a crack at >this from the chair's perspective: > >At 05:27 PM 10/16/01 -0400, Mark Duffy wrote: >>I >>do not believe the current list of requirements says anything about what an >>agent may ask a mb to do, with the exception of 2 very specific >>requirements related to a somewhat specialized request to be made of a NAT >>middlebox. > >I think that should be considered a good thing. The charter >and the framework documents convey the gist of what it is >we're trying to do, and from those it should be self-evident >what sorts of requests are going to be sent to the middlebox. >Loading up with detail essentially translates to protocol >design and that's not our job right now. Melinda, I disagree somewhat. What we have loaded up on (in the requirements) is mostly generic signalling protocol requirements (security, reliability, support for redundancy, determinism, etc.) If we are just trying to capture "the gist" of midcom, fine. Let's finish the framework and go home. If we are to write requirements, then let's make them complete. As you and Scott have stressed, and I agree, complete does not in this case mean finely detailed. But I think it does mean covering the entire scope. I cannot see that we have covered the scope with the requirements if they do not address what an agent may ask a middlebox to do. That is after all the heart and soul of what midcom is about -- all that stuff about signalling is subsidiary! I concede that the suggestions in my message yesterday on this topic were too detailed/arcane for the current circumstances. I propose that the following requirements will address the matter: Rxxx: The Midcom protocol MUST allow a Midcom agent to request a firewall opening from a middlebox that provides a firewall function. Ryyy: The Midcom protocol MUST allow a Midcom agent to request creation of an address binding or an address+port binding from a middlebox that provides a NAT function. Rzzz: The Midcom protocol MUST allow a Midcom agent to learn the address and port values assigned when a middlebox providing a NAT function creates a binding at the behest of the midcom agent. Those to me are a minimalist embodiment of our charter that Midcom must address NAT and firewall middleboxes. Thanks. --Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Oct 17 11:42:48 2001 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 LAA27798 for ; Wed, 17 Oct 2001 11:42: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 LAA29025; Wed, 17 Oct 2001 11:40: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 LAA28996 for ; Wed, 17 Oct 2001 11:40:22 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27741 for ; Wed, 17 Oct 2001 11:40:20 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 49ZFBWQX; Wed, 17 Oct 2001 11:39:53 -0400 Message-Id: <3.0.5.32.20011017113833.00942e00@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 17 Oct 2001 11:38:33 -0400 To: Melinda Shore , midcom@ietf.org From: Mark Duffy Subject: Re: [midcom] additional midcom reqts In-Reply-To: <5.1.0.14.0.20011017113029.00a66980@mira-sjc5-4.cisco.com> References: <3.0.5.32.20011017112621.008ff720@email.quarrytech.com> <5.1.0.14.0.20011016181545.00a6a490@mira-sjc5-4.cisco.com> <3.0.5.32.20011016172727.008b79a0@email.quarrytech.com> <200110162106.f9GL6Oo03066@eecs.harvard.edu> 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:31 AM 10/17/01 -0400, Melinda Shore wrote: >At 11:26 AM 10/17/01 -0400, Mark Duffy wrote: > >> Rxxx: The Midcom protocol MUST allow a Midcom agent to request a >> firewall opening from a middlebox that provides a firewall >> function. >> >> Ryyy: The Midcom protocol MUST allow a Midcom agent to request >> creation of an address binding or an address+port binding >> from a middlebox that provides a NAT function. >> >> Rzzz: The Midcom protocol MUST allow a Midcom agent to learn the >> address and port values assigned when a middlebox providing >> a NAT function creates a binding at the behest of the >> midcom agent. >> >>Those to me are a minimalist embodiment of our charter that Midcom must >>address NAT and firewall middleboxes. > >Do you think that if we leave these out, the next iteration of >the working group would fail to include these functions in the >protocol? > >Melinda No. Do you think that is reason enough to omit them from the requirements? I am unfamiliar with the way of writing requirements that leaves out fundamental requirements just because they should be obvious. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Oct 17 12:10:56 2001 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 MAA28727 for ; Wed, 17 Oct 2001 12:10: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 MAA00734; Wed, 17 Oct 2001 12:04: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 MAA00698 for ; Wed, 17 Oct 2001 12:04:03 -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 MAA28476 for ; Wed, 17 Oct 2001 12:04:01 -0400 (EDT) From: sbrim@cisco.com Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f9HG3eg03358; Wed, 17 Oct 2001 09:03:40 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn1-84.cisco.com [10.21.96.84]) by airborne.cisco.com (Mirapoint) with ESMTP id AAZ04123; Wed, 17 Oct 2001 09:03:33 -0700 (PDT) X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 I); VM 6.96 under Emacs 20.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15309.43985.15000.159127@gargle.gargle.HOWL> Date: Wed, 17 Oct 2001 12:03:29 -0400 To: Mark Duffy Cc: Melinda Shore , midcom@ietf.org Subject: Re: [midcom] additional midcom reqts In-Reply-To: <3.0.5.32.20011017112621.008ff720@email.quarrytech.com> References: <3.0.5.32.20011016172727.008b79a0@email.quarrytech.com> <200110162106.f9GL6Oo03066@eecs.harvard.edu> <3.0.5.32.20011017112621.008ff720@email.quarrytech.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 On 17 Oct 2001 at 11:26 -0400, Mark Duffy apparently wrote: > What we have loaded up on (in the requirements) is mostly generic > signalling protocol requirements (security, reliability, support for > redundancy, determinism, etc.) I'm with Melinda et al. What we've loaded it up with is *supposed* to be information to make life easier for the protocol designers. In theory we've thought about the protocol a lot, reached difficult conclusions, and recorded those conclusions. The requirements don't need to set context -- that's what the framework draft is for. The requirements also don't need to record what should be obvious to anyone. We've slipped over that line into a vast space of possible obvious requirements, but we aren't lost yet. We can step away. > If we are just trying to capture "the gist" of midcom, fine. Let's finish > the framework and go home. If we are to write requirements, then let's > make them complete. As you and Scott have stressed, and I agree, complete > does not in this case mean finely detailed. But I think it does mean > covering the entire scope. I don't think it's worth noting that the protocol must be able to run at speeds less than the speed of light. Where do you draw the line? I draw the line at work which is useful to our successors. > I cannot see that we have covered the scope with the requirements if > they do not address what an agent may ask a middlebox to do. That is > after all the heart and soul of what midcom is about -- all that stuff > about signalling is subsidiary! We have, in fact, spent a lot of time on what an agent may ask a middlebox to do. For example, remember the weeks which concluded with the requirement for the well-defined 5-tuple and room for future extensions? We intentionally ignored the obvious and worked on the gray areas, the boundary cases. > Rzzz: The Midcom protocol MUST allow a Midcom agent to learn the > address and port values assigned when a middlebox providing > a NAT function creates a binding at the behest of the > midcom agent. This one might actually be worth discussing ... but not the others. Here's a test: suppose this WG is finished, and the next one, the protocol design one, is starting out. Would you stand up in front of the group and say "I just want to be sure everyone realizes this protocol has to be able to request a pinhole in a firewall."? Wouldn't you be embarrassed at the silence while everyone tries to figure out the catch? ...Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Oct 17 13:05:42 2001 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 NAA00384 for ; Wed, 17 Oct 2001 13:05: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 NAA03075; Wed, 17 Oct 2001 13:03: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 NAA03043 for ; Wed, 17 Oct 2001 13:03:16 -0400 (EDT) Received: from znsgs0ja.europe.nortel.com ([47.165.25.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00324 for ; Wed, 17 Oct 2001 13:03:16 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f9HH2gk10621 for ; Wed, 17 Oct 2001 18:02:42 +0100 (BST) Received: from znsgd00t.europe.nortel.com by znsgs016; Wed, 17 Oct 2001 18:02:16 +0100 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <44VLDH8G>; Wed, 17 Oct 2001 18:01:51 +0100 Message-ID: <9154CB41F208D5118DD200508BE39C30445348@zjguc006.europe.nortel.com> From: "Cedric Aoun" To: "'Melinda Shore'" Cc: midcom Subject: RE: [midcom] Status Date: Wed, 17 Oct 2001 18:01:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1572D.6632E1C0" 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_01C1572D.6632E1C0 Content-Type: text/plain; charset="iso-8859-1" Melinda Please see my comments below Thanks Cedric -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Tuesday, October 16, 2001 7:01 PM To: midcom Subject: [midcom] Status R86 Accepted with revisions: R86: It should possible to define rulesets that contain a more specific filter spec than an overlapping ruleset. This should allow agents to request actions for the subset that contradict those of the overlapping set. This should allow Midcom agent to request to a Midcom server controlling a firewall function that a subset of the traffic that would be allowed by the overlapping ruleset be specifically disallowed. OK R35 Delete OK R38 Delete OK R43 Delete I agree that this one is not obvious to find in an existing protocol but we should remember the real time nature of certain applications. Some of us could think that on a wireless device (or on a dial-up link) bandwidth could be scarce and we would like to optimize the message length. R43 was originally intended for both of the above reasons. I think we should keep it. Is there any other advocates for it? R47 Delete This one is also related to bandwidth savings (message length) as well as to the aggregation (which again is linked to bandwidth saving and real time). I think that R43 and R47 will come back at the design phase R75 Needs more discussion What I understood from the requirement was that in case one Middle Box was traversed at a certain time x, when the network topology has changed (due to a failure) or when the traffic load increased another Middle Box could be traversed at time y. Therefore we should be able to put the same ruleset on all the Middle Boxes at the edge of the realm, this will allow the application flows to traverse in all cases. This requirement overlaps with the ability to request certain actions to be performed on certain flows with all details (i.e. requested address/port for the bind) as well as forbidding another agent to use the same bind for another flow (i.e. some inter agent coordination on what could be requested while avoiding conflicts. There is also the issue where a bind is already allocated on a Middle Box and another Middle Box is not aware that the previous bind was used (i.e. Middle Box ruleset coordination which could be considered as a result of Midcom agent coordination). And all of this is not totally linked to Midcom, especially the coordination part R?? Accepted: "The midcom protocol must provide protection against replay attacks" Isn't this already handled by R73 (probably mitigate is a soft word depending how we look at it) or we could modify R73 to be the above: "The Midcom Protocol MUST define mechanisms to mitigate replay attacks on the control messages." Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C1572D.6632E1C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Status

Melinda
Please see my comments below
Thanks
Cedric

-----Original Message-----
From: Melinda Shore [mailto:mshore@cisco.com]
Sent: Tuesday, October 16, 2001 7:01 PM
To: midcom
Subject: [midcom] Status


R86 Accepted with revisions:
  R86: It should possible to define rulesets = that contain a more specific
  filter spec than an overlapping ruleset. This = should allow agents to
  request actions for the subset that = contradict those of the overlapping
  set. This should allow Midcom agent to = request to a Midcom server
  controlling a firewall function that a subset = of the traffic that would
  be allowed by the overlapping ruleset be = specifically disallowed.

<CA>
OK
</CA>

R35 Delete
<CA>
OK
</CA>
R38 Delete
<CA>
OK
</CA>
R43 Delete
<CA>
I agree that this one is not obvious to find in an = existing protocol but we should remember the real time nature of = certain applications.

Some of us could think that on a wireless device (or = on a dial-up link) bandwidth could be scarce and we would like to = optimize the message length.

R43 was originally intended for both of the above = reasons.
I think we should keep it.
Is there any other advocates for it?
</CA>
R47 Delete
<CA>
This one is also related to bandwidth savings = (message length) as well as to the aggregation (which again is linked = to bandwidth saving and real time).

I think that R43 and R47 will come back at the design = phase
</CA>
R75 Needs more discussion
<CA>
What I understood from the requirement was that in = case one Middle Box was traversed at a certain time x, when the network = topology has changed (due to a failure) or when the traffic load = increased another Middle Box could be traversed at time y.

Therefore we should be able to put the same ruleset = on all the Middle Boxes at the edge of the realm, this will allow the = application flows to traverse in all cases.

This requirement overlaps with the ability to request = certain actions to be performed on certain flows with all details (i.e. = requested address/port for the bind) as well as forbidding another = agent to use the same bind for another flow (i.e. some inter agent = coordination on what could be requested while avoiding conflicts. There = is also the issue where a bind is already allocated on a Middle Box and = another Middle Box is not aware that the previous bind was used (i.e. = Middle Box ruleset coordination which could be considered as a result = of Midcom agent coordination).

And all of this is not totally linked to Midcom, = especially the coordination part
</CA>

R?? Accepted:
  "The midcom protocol must provide = protection against replay
  attacks"
<CA>
Isn't this already handled by R73 (probably mitigate = is a soft word depending how we look at it) or we could modify R73 to = be the above:

"The Midcom Protocol MUST define mechanisms to = mitigate replay
        attacks = on the control messages."

Melinda


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

------_=_NextPart_001_01C1572D.6632E1C0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Oct 17 14:47:23 2001 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 OAA03477 for ; Wed, 17 Oct 2001 14:47: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 OAA05975; Wed, 17 Oct 2001 14:36: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 OAA05944 for ; Wed, 17 Oct 2001 14:36:49 -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 OAA02985 for ; Wed, 17 Oct 2001 14:36:48 -0400 (EDT) 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 f9HIaPY03266 for ; Wed, 17 Oct 2001 11:36:25 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-38.cisco.com [10.82.192.38]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAQ03118; Wed, 17 Oct 2001 11:27:29 -0700 (PDT) Message-Id: <5.1.0.14.0.20011017142722.00a83b80@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 17 Oct 2001 14:30:01 -0400 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] R75 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 text of R75 is this: R75: The Midcom Protocol must produce robust operation even when routing changes such that traffic from a particular end system passes through a different middlebox. (Huitema) Eliot Lear says "this takes too much state". I'm with Eliot on this, but even if I weren't this really is too closely related to the topology issue to be able to resolve now. I'm proposing deleting R75. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Oct 17 15:14:08 2001 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 PAA04416 for ; Wed, 17 Oct 2001 15:14: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 PAA06919; Wed, 17 Oct 2001 15:10:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06891 for ; Wed, 17 Oct 2001 15:10:51 -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 PAA04300 for ; Wed, 17 Oct 2001 15:10:50 -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 f9HJBbP07481; Wed, 17 Oct 2001 15:11:38 -0400 (EDT) Message-Id: <200110171911.f9HJBbP07481@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Melinda Shore cc: midcom@ietf.org Subject: Re: [midcom] R75 In-reply-to: Your message of "Wed, 17 Oct 2001 14:30:01 EDT." <5.1.0.14.0.20011017142722.00a83b80@mira-sjc5-4.cisco.com> Date: Wed, 17 Oct 2001 15:11:37 -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 text of R75 is this: > R75: The Midcom Protocol must produce robust operation even when > routing changes such that traffic from a particular end system > passes through a different middlebox. (Huitema) > > Eliot Lear says "this takes too much state". > > I'm with Eliot on this, but even if I weren't this really is > too closely related to the topology issue to be able to resolve > now. I'm proposing deleting R75. seems to me that it's silly to talk about robust operation in the presence of NATs. since midcom is inherently an attempt to address NAT problems, robust operation would appear to be out-of-scope. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Oct 17 17:15:12 2001 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 RAA07643 for ; Wed, 17 Oct 2001 17:15: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 RAA09435; Wed, 17 Oct 2001 17:12: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 RAA09406 for ; Wed, 17 Oct 2001 17:12:02 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07572 for ; Wed, 17 Oct 2001 17:11:57 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id QAA20090 for ; Wed, 17 Oct 2001 16:11:25 -0500 (CDT) Received: from zsc4c000.us.nortel.com by smtprch2.nortel.com; Wed, 17 Oct 2001 16:04:37 -0500 Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Oct 2001 14:10:44 -0700 Message-ID: From: "Reinaldo Penno" To: "'Melinda Shore'" , "'midcom@ietf.org'" Subject: RE: [midcom] R75 Date: Wed, 17 Oct 2001 14:10:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15750.2EC9C5A0" X-Orig: 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_01C15750.2EC9C5A0 Content-Type: text/plain; charset="iso-8859-1" I would like more clarification on that before deleting. Are we saying that in the case of, for instance BGP, where ingress and egress traffic can take different paths and pass through different MBs, MIDCOM will not work OR that it will work on any topology but IF routing changes then it might fails? If we are somewhat restricting MIDCOM usage to certain topologies or routing configurations I disagree. thanks, > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Wednesday, October 17, 2001 11:30 AM > To: midcom@ietf.org > Subject: [midcom] R75 > > > The text of R75 is this: > R75: The Midcom Protocol must produce robust operation even when > routing changes such that traffic from a particular end system > passes through a different middlebox. (Huitema) > > Eliot Lear says "this takes too much state". > > I'm with Eliot on this, but even if I weren't this really is > too closely related to the topology issue to be able to resolve > now. I'm proposing deleting R75. > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C15750.2EC9C5A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] R75

I would like more clarification on that before = deleting.

Are we saying that in the case of, for instance BGP, = where ingress and egress traffic can take different paths and pass = through different MBs, MIDCOM will not work OR that it will work on any = topology but IF routing changes then it might fails?

If we are somewhat restricting MIDCOM usage to = certain topologies or routing configurations I disagree.

thanks,

> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Wednesday, October 17, 2001 11:30 = AM
> To: midcom@ietf.org
> Subject: [midcom] R75
>
>
> The text of R75 is this:
>  R75: The Midcom Protocol must produce = robust operation even when
>         = routing changes such that traffic from a particular end system
>         = passes through a different middlebox.  (Huitema)
>
>          = Eliot Lear says "this takes too much state".
>
> I'm with Eliot on this, but even if I weren't = this really is
> too closely related to the topology issue to be = able to resolve
> now.  I'm proposing deleting R75.
>
> Melinda
>
>
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C15750.2EC9C5A0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Oct 17 17:43:50 2001 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 RAA07986 for ; Wed, 17 Oct 2001 17:43: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 RAA09872; Wed, 17 Oct 2001 17:30: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 RAA09829 for ; Wed, 17 Oct 2001 17:30:40 -0400 (EDT) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07811 for ; Wed, 17 Oct 2001 17:30:37 -0400 (EDT) Received: from ELEARW2K1 (sjc-vpn1-133.cisco.com [10.21.96.133]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id OAA28257; Wed, 17 Oct 2001 14:29:18 -0700 (PDT) Message-ID: <004f01c15752$d0cc9dd0$56f5af40@cisco.com> From: "Eliot Lear" To: "Reinaldo Penno" , "'Melinda Shore'" , References: Subject: Re: [midcom] R75 Date: Wed, 17 Oct 2001 14:29:33 -0700 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 If one takes R75 at face value it REQUIRES state to be shared amongst middle boxes. And if we thought we had a tough job before, this would really put the nail in the coffin. NATs aren't required to share state. Firewalls aren't required to share state. Let's not do things that make it impossible for middle boxes to share state, but then let's not require it either. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Oct 17 18:20:48 2001 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 SAA08541 for ; Wed, 17 Oct 2001 18:20: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 SAA10793; Wed, 17 Oct 2001 18: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 SAA10764 for ; Wed, 17 Oct 2001 18:19:52 -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 SAA08522 for ; Wed, 17 Oct 2001 18:19:51 -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 f9HMKQP08181; Wed, 17 Oct 2001 18:20:26 -0400 (EDT) Message-Id: <200110172220.f9HMKQP08181@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Reinaldo Penno" cc: "'Melinda Shore'" , "'midcom@ietf.org'" Subject: Re: [midcom] R75 In-reply-to: Your message of "Wed, 17 Oct 2001 14:10:43 PDT." Date: Wed, 17 Oct 2001 18:20:26 -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 > Are we saying that in the case of, for instance BGP, where ingress and egress > traffic can take different paths and pass through different MBs, MIDCOM will > not work OR that it will work on any topology but IF routing changes then it > might fails? of course! it's clearly unreasonable to expect midcom to fix this. midcom exists for the very purpose of allowing (and manipulating) state in NATs and firewalls. loss of robustness is an inherent consequence of a decision to put devices with unrecoverable state in the network. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Oct 17 20:38:49 2001 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 UAA10058 for ; Wed, 17 Oct 2001 20:38: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 UAA13529; Wed, 17 Oct 2001 20:31: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 UAA13500 for ; Wed, 17 Oct 2001 20:31:08 -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 UAA10040 for ; Wed, 17 Oct 2001 20:31:07 -0400 (EDT) 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 f9I0UhU14223; Wed, 17 Oct 2001 17:30:43 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-38.cisco.com [10.82.192.38]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAQ17016; Wed, 17 Oct 2001 17:30:14 -0700 (PDT) Message-Id: <5.1.0.14.0.20011017202856.00a75ab0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 17 Oct 2001 20:32:36 -0400 To: "Reinaldo Penno" , "'midcom@ietf.org'" From: Melinda Shore Subject: RE: [midcom] R75 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:10 PM 10/17/01 -0700, Reinaldo Penno wrote: >Are we saying that in the case of, for instance BGP, where ingress and egress traffic can take different paths and pass through different MBs, MIDCOM will not work OR that it will work on any topology but IF routing changes then it might fails? > >If we are somewhat restricting MIDCOM usage to certain topologies or routing configurations I disagree. If you've read my network-friendlier draft you'll find that I believe that midcom is self-limiting regarding topology - there are some topologies that simply won't work. We went into this knowing that we were going to be violating network layer boundaries. I don't think we fully appreciated the extent to which that violation would affect topological concerns. There is simply no way to make middleboxes robust across routing changes without profound changes to middlebox functions, and even if it were desirable it would still be out of scope. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Oct 17 21:15:31 2001 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 VAA10363 for ; Wed, 17 Oct 2001 21:15: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 VAA14473; Wed, 17 Oct 2001 21:14: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 VAA14445 for ; Wed, 17 Oct 2001 21:14:25 -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 VAA10358 for ; Wed, 17 Oct 2001 21:14:23 -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.2966); Wed, 17 Oct 2001 18:12:58 -0700 Received: from 157.54.8.109 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 17 Oct 2001 18:12:57 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 17 Oct 2001 18:12:56 -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.2966); Wed, 17 Oct 2001 18:12:49 -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.3541.1); Wed, 17 Oct 2001 18:12:47 -0700 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6063.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] R75 Date: Wed, 17 Oct 2001 18:12:19 -0700 Message-ID: Thread-Topic: [midcom] R75 Thread-Index: AcFXb+xru/rWDHKhQf2C5Q52wnxPuwAAfrdg From: "Christian Huitema" To: "Melinda Shore" , "Reinaldo Penno" , X-OriginalArrivalTime: 18 Oct 2001 01:12:47.0620 (UTC) FILETIME=[FFB72C40:01C15771] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id VAA14446 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 was the original proponent of R75. In light of the discussion, I agree it should be dropped. Too much of a rathole. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Oct 17 21:45:58 2001 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 VAA11639 for ; Wed, 17 Oct 2001 21:45: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 VAA15102; Wed, 17 Oct 2001 21:44: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 VAA15073 for ; Wed, 17 Oct 2001 21:44:12 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11617 for ; Wed, 17 Oct 2001 21:44:10 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id UAA12069 for ; Wed, 17 Oct 2001 20:43:43 -0500 (CDT) Received: from zsc4c000.us.nortel.com by smtprch2.nortel.com; Wed, 17 Oct 2001 20:36:46 -0500 Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Oct 2001 18:42:52 -0700 Message-ID: From: "Reinaldo Penno" To: "'Melinda Shore'" , "'midcom@ietf.org'" Subject: RE: [midcom] R75 Date: Wed, 17 Oct 2001 18:42:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15776.31464210" X-Orig: 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_01C15776.31464210 Content-Type: text/plain; charset="iso-8859-1" Hello Melinda, > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Wednesday, October 17, 2001 5:33 PM > To: Penno, Reinaldo [SC9:T327:EXCH]; 'midcom@ietf.org' > Subject: RE: [midcom] R75 > > > At 02:10 PM 10/17/01 -0700, Reinaldo Penno wrote: > >Are we saying that in the case of, for instance BGP, where > ingress and egress traffic can take different paths and pass > through different MBs, MIDCOM will not work OR that it will > work on any topology but IF routing changes then it might fails? > > > >If we are somewhat restricting MIDCOM usage to certain > topologies or routing configurations I disagree. > > If you've read my network-friendlier draft you'll find that > I believe that midcom is self-limiting regarding topology - there > are some topologies that simply won't work. We went into this > knowing that we were going to be violating network layer > boundaries. I don't think we fully appreciated the extent to > which that violation would affect topological concerns. There > is simply no way to make middleboxes robust across routing > changes without profound changes to middlebox functions This is much I agree (NOT be robust across routing changes) . What I disagreed (and asked clarification) was if R75 was implying some sort of topological restriction to the use of MIDCOM, although I agree that inevitably there will be some. regards, -Reinaldo ------_=_NextPart_001_01C15776.31464210 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] R75

Hello Melinda,

> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Wednesday, October 17, 2001 5:33 = PM
> To: Penno, Reinaldo [SC9:T327:EXCH]; = 'midcom@ietf.org'
> Subject: RE: [midcom] R75
>
>
> At 02:10 PM 10/17/01 -0700, Reinaldo Penno = wrote:
> >Are we saying that in the case of, for = instance BGP, where
> ingress and egress traffic can take different = paths and pass
> through different MBs, MIDCOM will not work OR = that it will
> work on any topology but IF routing changes = then it might fails?
> >
> >If we are somewhat restricting MIDCOM usage = to certain
> topologies or routing configurations I = disagree.
>
> If you've read my network-friendlier draft = you'll find that
> I believe that midcom is self-limiting = regarding topology - there
> are some topologies that simply won't = work.  We went into this
> knowing that we were going to be violating = network layer
> boundaries.  I don't think we fully = appreciated the extent to
> which that violation would affect topological = concerns.  There
> is simply no way to make middleboxes robust = across routing
> changes without profound changes to middlebox = functions

This is much I agree (NOT be robust across routing = changes) . What I disagreed (and asked clarification) was if R75 was = implying some sort of topological restriction to the use of MIDCOM, = although I agree that inevitably there will be some.

regards,

-Reinaldo

------_=_NextPart_001_01C15776.31464210-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Oct 19 09:09:57 2001 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 JAA17846 for ; Fri, 19 Oct 2001 09:09: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 JAA23733; Fri, 19 Oct 2001 09:04: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 JAA23704 for ; Fri, 19 Oct 2001 09:04:51 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17647 for ; Fri, 19 Oct 2001 09:04:49 -0400 (EDT) Received: from spandex.cisco.com (rtp-vpn-47.cisco.com [10.82.192.47]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ABD03019 (AUTH mshore); Fri, 19 Oct 2001 06:03:52 -0700 (PDT) Message-Id: <5.1.0.14.0.20011019090615.00a4b170@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 19 Oct 2001 09:06:33 -0400 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] R75 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 R75 is deleted. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Oct 19 09:15:19 2001 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 JAA17983 for ; Fri, 19 Oct 2001 09:15: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 JAA23827; Fri, 19 Oct 2001 09:08: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 JAA23797 for ; Fri, 19 Oct 2001 09:08:49 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17798 for ; Fri, 19 Oct 2001 09:08:47 -0400 (EDT) Received: from spandex.cisco.com (rtp-vpn-47.cisco.com [10.82.192.47]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ABD03061 (AUTH mshore); Fri, 19 Oct 2001 06:07:51 -0700 (PDT) Message-Id: <5.1.0.14.0.20011019090634.00a4b800@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 19 Oct 2001 09:10:32 -0400 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Status 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 With the deletion of R75, we've completed working through the list of unresolved requirements in Scott's documents. Many, many thanks to all of you who have put in the long hours on this, and particular thanks to Scott for collecting, structuring, organizing, and then maintaining the list. It was a lot of work. I've asked Richard to try to get a new revision of the requirements document out very quickly. In the meantime, there's a new version of the framework document and we need to take a careful look at it and make sure that there's agreement with its contents. Please, let's not repeat our last experience trying to get it through last call. Once again, many thanks, and let's get these documents wrapped up. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Oct 19 09:23:45 2001 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 JAA18224 for ; Fri, 19 Oct 2001 09:23: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 JAA24010; Fri, 19 Oct 2001 09:22: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 JAA23982 for ; Fri, 19 Oct 2001 09:22:39 -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 JAA18200 for ; Fri, 19 Oct 2001 09:22:36 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f9JDMFY29481; Fri, 19 Oct 2001 06:22:15 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-267.cisco.com [10.21.97.11]) by airborne.cisco.com (Mirapoint) with SMTP id ABG03448; Fri, 19 Oct 2001 06:22:07 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Fri, 19 Oct 2001 09:22:09 -0400 Date: Fri, 19 Oct 2001 09:22:09 -0400 From: Scott Brim To: Melinda Shore Cc: midcom@ietf.org Subject: Re: [midcom] R75 Message-ID: <20011019092209.A1216@SBRIM-W2K> Mail-Followup-To: Scott Brim , Melinda Shore , midcom@ietf.org References: <5.1.0.14.0.20011019090615.00a4b170@mira-sjc5-4.cisco.com> 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.20011019090615.00a4b170@mira-sjc5-4.cisco.com>; from mshore@cisco.com on Fri, Oct 19, 2001 at 09:06:33AM -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, Oct 19, 2001 09:06:33AM -0400, Melinda Shore wrote: > R75 is deleted. And with that, the requirements bullets are done! I'll send out the last version tonight. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Oct 19 15:53:52 2001 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 PAA29636 for ; Fri, 19 Oct 2001 15:53: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 PAA06685; Fri, 19 Oct 2001 15:48: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 PAA06655 for ; Fri, 19 Oct 2001 15:48:27 -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 PAA29511 for ; Fri, 19 Oct 2001 15:48:24 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f9JJm2Y14983 for ; Fri, 19 Oct 2001 12:48:02 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-267.cisco.com [10.21.97.11]) by airborne.cisco.com (Mirapoint) with SMTP id ABH02644; Fri, 19 Oct 2001 12:47:54 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Fri, 19 Oct 2001 15:47:53 -0400 Date: Fri, 19 Oct 2001 15:47:52 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Status Message-ID: <20011019154752.A948@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <5.1.0.14.0.20011019090634.00a4b800@mira-sjc5-4.cisco.com> 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.20011019090634.00a4b800@mira-sjc5-4.cisco.com>; from mshore@cisco.com on Fri, Oct 19, 2001 at 09:10:32AM -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 new and final version of the bullets is now at http://www.employees.org/~swb/midcom.html ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Oct 22 16:14:24 2001 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 QAA28872 for ; Mon, 22 Oct 2001 16:14: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 QAA05318; Mon, 22 Oct 2001 16:10: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 QAA05289 for ; Mon, 22 Oct 2001 16:09:59 -0400 (EDT) Received: from homemail.bjt.net (homemail.bjt.net [209.237.6.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28782 for ; Mon, 22 Oct 2001 16:09:54 -0400 (EDT) Received: from Tesla [209.237.31.183] by homemail.bjt.net (SMTPD32-6.05) id AC002B026E; Mon, 22 Oct 2001 13:05:20 -0700 Message-ID: <023801c15b35$a36abc00$3301a8c0@Tesla> From: "David A. Bryan" To: Date: Mon, 22 Oct 2001 13:10:47 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0235_01C15AFA.F6B7F7A0" 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 Subject: [midcom] New Submission 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. ------=_NextPart_000_0235_01C15AFA.F6B7F7A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I had submitted this draft last week, but had not yet sent a message = about it to this list. Here is the announcement I sent last week: I would like to propose a new internet draft for consideration. This = draft is of interest to the MIDCOM working group. Title : A Simple Middlebox Protocol Author: D. Bryan Filename: draft-bryan-midcom-simple-strawman.txt URL: = http://www.employees.org/~dbryan/draft-bryan-midcom-simple-strawman-00.tx= t Abstract: This is a very simple strawman protocol for agents to request NAT = address translations and firewall pinholes from a middlebox. This = protocol uses the underlying transport for reliability and to avoid = reinventing TCP. This protocol does not use an existing protocol like = COPS, SOAP, HTTP or DIAMETER as these protocols include significant = complexity that is not required to solve the middlebox problem. Thank you very much. David Bryan David A. Bryan - Vice-President, Engineering Jasomi Networks, Inc. - 408-252-8647 - Fax 408-437-1201 2033 Gateway Place, Suite 500, San Jose, CA 95110, USA dbryan@jasomi.com - www.jasomi.com ------=_NextPart_000_0235_01C15AFA.F6B7F7A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I had submitted this draft last week, = but had not=20 yet sent a message about it to this list. Here is the announcement I = sent last=20 week:
 
I would like to propose a new internet = draft for=20 consideration. This draft is of interest to the MIDCOM working=20 group.

Title : A Simple Middlebox Protocol
Author: D.=20 Bryan
Filename: draft-bryan-midcom-simple-strawman.txt
URL: http://www.employees.org/~dbryan/draft-bryan-midcom-simple-str= awman-00.txt
Abstract:

This is a very simple = strawman=20 protocol for agents to request NAT address translations and firewall = pinholes=20 from a middlebox. This protocol uses the underlying transport for = reliability=20 and to avoid reinventing TCP.  This protocol does not use an = existing=20 protocol like COPS, SOAP, HTTP or DIAMETER as these protocols include=20 significant complexity that is not required to solve the middlebox=20 problem.

Thank you very much.

David Bryan


David = A.=20 Bryan - Vice-President, Engineering
Jasomi Networks, Inc. - =20 408-252-8647 - Fax 408-437-1201
2033 Gateway Place, Suite 500, San = Jose, CA=20 95110, USA
dbryan@jasomi.com = - www.jasomi.com
= ------=_NextPart_000_0235_01C15AFA.F6B7F7A0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Oct 24 01:18:53 2001 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 BAA02011 for ; Wed, 24 Oct 2001 01:18: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 BAA12446; Wed, 24 Oct 2001 01:15: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 BAA12416 for ; Wed, 24 Oct 2001 01:15:02 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01705 for ; Wed, 24 Oct 2001 01:15:00 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9O5DLPI015526; Wed, 24 Oct 2001 01:13:21 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Oct 2001 01:14:32 -0400 Message-ID: From: Jonathan Rosenberg To: "'Melinda Shore'" , midcom Subject: RE: [midcom] pre-midcom candidates Date: Wed, 24 Oct 2001 01:14:27 -0400 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 Well, things have been quiet.... Let me give my 2 cents about these three documents, and how they relate to each other and the problems they are trying to solve. Both the Sen proposal and the Davies proposal assume the worst case - symmetric NAT, and involve the use of some kind of provider based intermediary to deal with that case. The drawback is that there is increased cost to the provider to deploy these boxes and for the bandwidth in the co-locs to received the media and turn it back around. There is also increased voice latencies due to speed of light delays to this intermediary, whose location is generally uncorrelated with the location of the end users. The Sen proposal is protocol specific; that is, it works for SIP only. The general concept could be made to work for other protocols, but that would need to be documented separately. Its benefit is that there is no need for further protocol development beyond what we are doing today. The Davies approach is not protocol specific, and provides a general way to allocate bindings from a relay server in the provider network. It would work for any application. The Davies approach is really nothing more than RSIP applied to the transport layer (UDP and TCP). RSIP works at the IP layer, and thus requires host IP stack changes. The Davies protocol, by using RSIP concepts at the transport layer, pushes those functions into the applications, at the cost of additional protocol mecahnisms (for example, indications of tcp connection establishment, carried on the control channel, are needed in the davies protocol, but are not needed in RSIP). There are other issues with the Davies protocol, primarily having to do with consistency with enterprise firewall policy, but I will get to that in a separate note. Stun is a different beast. It tries to optimize media by first figuring out the type of nat, and in the case of full cone and address-restricted nats, provides the IP address allocated by the nat. In these cases, there is no need for the intermediaries that the Sen and Davies protocols use. In the case where the user is behind a symmetric nat, some kind of intermediary is needed. Stun, as described, doesn't have capability for allocating an address from an intermediary. We have done some work on how that might be done as a simple extension to what stun does now, but with the addition of some security and load balancing capabilities. In my opinion, a usable solution requires the ability to avoid the intermediary when its not needed, and to involve one when it is needed. THis means that its a two-pronged solution: first, detect the nat situation, and get addresses if its not symmetric. Stun is the only proposal that does that. The second stage is, if you find you are behind a symmetric nat, involve the use of a network intermediary. There are three proposals for that piece - the sen draft, the davies draft, and the unpublished stun attributes I have mentioned. Arguably, handling the symmetric case is the far more complex scenario. It has more complex security issues, requires more protocol primitives, and so on. Its also an area richer in solutions. Besides the three we have seen, there is also pure VPN solutions and even my favorite, rfc3093. So, my proposal is to attack the low hanging fruit first, and the harder stuff next. Lets take stun as documented, finish that, and have a solution for the detection and for handling the non-symmetric cases. We can then work on the symmetric case, but I suspect that will take longer. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Friday, October 12, 2001 4:58 PM > To: midcom > Subject: [midcom] pre-midcom candidates > > > I believe we now have three candidate documents for the > pre-midcom work item, and we need to work quickly towards > getting one selected for use as the base document. Those > three documents are: > > http://search.ietf.org/internet-drafts/draft-sen-midcom-fw-nat-00.txt > http://search.ietf.org/internet-drafts/draft-rosenberg-midcom- > stun-00.txt > w-nat-traversal-01.txt>http://www.ridgewaysystems.com/pdf/Whit > epapers/draft-davies-fw-nat-traversal-01.txt > > Please read these, and let's have some serious discussions about > this over the next week. Remember, the ability to compromise is > a virtue. > > Note, as well, that although the document does not state as much > there are some intellectual property claims on technology described > in the Davies draft. I've appended some text that originally > appeared on the APPS area web page, giving a rough description of > the IETF position on IPR (http://www.apps.ietf.org/procedures.html). > Please read it and take particular note of the second bullet item. > In the future, if you submit a technology for consideration that > is encumbered you MUST inform the working group. > > Thanks, > > Melinda > ======== > > As all who have been with the IETF for a while know, IPR > problems are a pain. > > The most interesting discussions are found in RFC 2026 > chapter 10; the basic tenets of which are: > > * All IPR problems known to participants MUST be > identified to the WG. > * The WG is expected to prefer non-encumbered technology > whenever such technology exists and is not significantly > worse than the encumbered alternative. > * Where licensing is an issue, licensing MUST be > available on "reasonable and non-discriminatory terms". The > first test is whether 2 independent licenses have in fact > been granted under such terms between the Proposed and Draft > status for the specification. > * Patents where the patent holder has filed a grant of > rights to freely use the patent are not considered terribly > encumbering. > > For discussions of release of IPR, the correct address is the > ISOC vice president for standards, Scott Bradner, > ; also send CC to the IETF Chair (Fred Baker > ) and the IESG secretary > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Oct 24 10:53:23 2001 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 KAA02354 for ; Wed, 24 Oct 2001 10:53: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 KAA27793; Wed, 24 Oct 2001 10:46: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 KAA27765 for ; Wed, 24 Oct 2001 10:46:33 -0400 (EDT) Received: from linux.aravox.com (linux.aravox.com [209.46.41.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02082 for ; Wed, 24 Oct 2001 10:46:31 -0400 (EDT) Received: from MPIETRAS (dyn-1-102.aravox.com [192.168.1.102] (may be forged)) by linux.aravox.com (8.9.3/8.9.3) with SMTP id JAA15596; Wed, 24 Oct 2001 09:44:49 -0500 From: "Mark Pietras" To: "midcom" , "Jonathan Rosenberg" Subject: RE: [midcom] pre-midcom candidates Date: Wed, 24 Oct 2001 09:45:22 -0500 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 In-Reply-To: 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 After going over STUN in more detail, I've got a few lower-level detail comments/questions (some pretty minor) about the document rather than concerning the approach. I haven't read other comments on the document, or seen an update, so I apologize if these have been addressed already: These two statements seem to be conflicting (or maybe I'm just taking it out of context), but I think the second statement needs clarification in that there is another place that the response might go than the obseved addr/port: > 6 Message Overview > There is also a RESPONSE-ADDRESS attribute, which > is also an IP address and port. The RESPONSE-ADDRESS attribute can be > present in the request, and >>indicates where the response is to be > sent<<. Its optional, and when not present, the response is sent to the > source IP address and port of the request. > 7 Server Behavior > The server MUST add a MAPPED-ADDRESS attribute to the response. The > IP address component of this attribute >>MUST be set to the source IP > address observed<< in the request. The port component of this attribute > MUST be set to the source port observed in the query request. Seems to me that the FLAGS attribute could be optional in the request, although that's not stated. As a side note, if that's not reasonable, then the line: "After the header are 0 or more attributes" shouldn't be: "0 or more" as there will always be at least 1 (Request with flags, or Response with mapped-address). In the attribute, the length field isn't specifically defined as to whether the attribute header is included or not. I'd suggest that it doesn't include the four octets (type and length) to be consistent with the main header. > 10.2 Message Attributes > After the header are 0 or more attributes. Each attribute is TLV > encoded, with a 16 bit type, 16 bit length, and variable value:... Unless I'm missing something, it seems to me a multi-homed implementation would be more efficient (and therefore perhaps a better suggestion) than using the RESPONSE-ADDRESS. I suppose the RESPONSE-ADDRESS is the more complex implementation though and deserves more attention... > One potential way to implement the change-IP feature is for the > server to generate its own request, and send it to another server... From what I can tell, this is also the only reason for RESPONSE-ADDRESS too, right? Seems to me that CHANGED-ADDRESS is missing from the list: > 0x0001: MAPPED-ADDRESS > 0x0002: RESPONSE-ADDRESS > 0x0003: FLAGS > 0x0004: SOURCE-ADDRESS Based on layout of document, I think this was intended: > 0x0001: MAPPED-ADDRESS > 0x0002: RESPONSE-ADDRESS > 0x0003: CHANGED-ADDRESS > 0x0004: FLAGS > 0x0005: SOURCE-ADDRESS A side note on address realms: If a STUN packet traverses address realm types (ipv4 client <-> ipv6 server) a client in the ipv4 realm will have to be ipv6 aware because the response will contain the ipv6 address of the NAT. And when I say client, I mean both the STUN client _and_ the client using the information as it will be communicating it somewhere else in it's signaling (e.g. SIP/SDP). Note on attributes: There's no explicit or implied order to how attributes appear in messages, I suppose that's okay (although slightly more work to deal with), but I don't recall seeing a statement about what servers (or clients for that matter) do when 1) they see an attribute in a request meant only for a response (or visa versa), or 2) there is more than one attribute of the same type in a message (e.g. two FLAGS attributes). That's it for now... looks good. Mark Pietras. -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Jonathan Rosenberg Sent: Wednesday, October 24, 2001 12:14 AM To: 'Melinda Shore'; midcom Subject: RE: [midcom] pre-midcom candidates Well, things have been quiet.... [deleted] _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Oct 30 01:53:34 2001 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 BAA12650 for ; Tue, 30 Oct 2001 01:53:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA19630 for midcom-archive@odin.ietf.org; Tue, 30 Oct 2001 01:53: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 BAA19113; Tue, 30 Oct 2001 01:16: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 BAA19084 for ; Tue, 30 Oct 2001 01:16:07 -0500 (EST) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07592 for ; Tue, 30 Oct 2001 01:16:06 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9U6ENb7006988; Tue, 30 Oct 2001 01:14:24 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Oct 2001 01:15:37 -0500 Message-ID: From: Jonathan Rosenberg To: "'Mark Pietras'" , midcom Subject: RE: [midcom] pre-midcom candidates Date: Tue, 30 Oct 2001 01:15: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 Comments inline > -----Original Message----- > From: Mark Pietras [mailto:mpietras@aravox.com] > Sent: Wednesday, October 24, 2001 10:45 AM > To: midcom; Jonathan Rosenberg > Subject: RE: [midcom] pre-midcom candidates > > > These two statements seem to be conflicting (or maybe I'm > just taking it out > of context), but I think the second statement needs > clarification in that > there is another place that the response might go than the obseved > addr/port: > > 6 Message Overview > > There is also a RESPONSE-ADDRESS attribute, which > > is also an IP address and port. The RESPONSE-ADDRESS > attribute can be > > present in the request, and >>indicates where the > response is to be > > sent<<. Its optional, and when not present, the response > is sent to the > > source IP address and port of the request. > > 7 Server Behavior > > The server MUST add a MAPPED-ADDRESS attribute to the > response. The > > IP address component of this attribute >>MUST be set to > the source IP > > address observed<< in the request. The port component of > this attribute > > MUST be set to the source port observed in the query request. > These don't conflict at all. I server receives a request, lets say, from IP address/port X. THe request has a RESPONSE-ADDRESS attribute with IP address/port Y. The server will send a response. The response is sent to (i.e., its destination address/port) Y. The response has a MAPPED-ADDRESS attribute, and the value of that attribute is X. > > > > Seems to me that the FLAGS attribute could be optional in the request, > although that's not stated. As a side note, if that's not > reasonable, then > the line: "After the header are 0 or more attributes" > shouldn't be: "0 or > more" as there will always be at least 1 (Request with flags, > or Response > with mapped-address). Flags is optional. The document does explicitly say that, but not in the section where its first introduced. I added a sentence to that effect. > In the attribute, the length field isn't specifically defined > as to whether > the attribute header is included or not. I'd suggest that it doesn't > include the four octets (type and length) to be consistent > with the main > header. > > 10.2 Message Attributes > > After the header are 0 or more attributes. Each attribute is TLV > > encoded, with a 16 bit type, 16 bit length, and variable value:... > Yes, it refers to only the attribute value, so that it does not include the four octets you refer to. I will clarify that. > > > Unless I'm missing something, it seems to me a multi-homed > implementation > would be more efficient (and therefore perhaps a better > suggestion) than > using the RESPONSE-ADDRESS. I suppose the RESPONSE-ADDRESS > is the more > complex implementation though and deserves more attention... RESPONSE-ADDRESS is only useful if you are multihomed in the first place, so I'm not sure I understand what you are saying here. > > One potential way to implement the change-IP feature is for the > > server to generate its own request, and send it to > another server... > From what I can tell, this is also the only reason for > RESPONSE-ADDRESS too, > right? No, its unrelated. RESPONSE-ADDRESS allows the client to tell the server where teh response should go. The FLAGS has a change-IP that allows the client to tell the server from where to send its response (i.e., the RESPONSE-ADDRESS determines the destination IP and destination port of the response, and the FLAGS determines the source IP and source port of the response). > > > > Seems to me that CHANGED-ADDRESS is missing from the list: > > 0x0001: MAPPED-ADDRESS > > 0x0002: RESPONSE-ADDRESS > > 0x0003: FLAGS > > 0x0004: SOURCE-ADDRESS > Based on layout of document, I think this was intended: > > 0x0001: MAPPED-ADDRESS > > 0x0002: RESPONSE-ADDRESS > > 0x0003: CHANGED-ADDRESS > > 0x0004: FLAGS > > 0x0005: SOURCE-ADDRESS > Correct. I've fixed that. > > A side note on address realms: > If a STUN packet traverses address realm types (ipv4 client > <-> ipv6 server) > a client in the ipv4 realm will have to be ipv6 aware because > the response > will contain the ipv6 address of the NAT. And when I say > client, I mean > both the STUN client _and_ the client using the information > as it will be > communicating it somewhere else in it's signaling (e.g. SIP/SDP). Correct. > > > Note on attributes: > There's no explicit or implied order to how attributes appear > in messages, I > suppose that's okay (although slightly more work to deal > with), but I don't > recall seeing a statement about what servers (or clients for > that matter) do > when 1) they see an attribute in a request meant only for a > response (or > visa versa), or 2) there is more than one attribute of the > same type in a > message (e.g. two FLAGS attributes). Right, I have not specified anything. Since there isn't really any error handling, the server should accept attributes in any order, and ignore any attributes that are defined but not supposed to be present in that message. I will add that. > > > That's it for now... looks good. Thanks for your comments and questions. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Oct 31 16:01:51 2001 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 QAA01599 for ; Wed, 31 Oct 2001 16:01:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA07983 for midcom-archive@odin.ietf.org; Wed, 31 Oct 2001 16:01: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 PAA07422; Wed, 31 Oct 2001 15:57: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 PAA07393 for ; Wed, 31 Oct 2001 15:57:14 -0500 (EST) Received: from avgw.vxserver.com (mail.ridgeway-sys.com [194.128.67.178]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01343 for ; Wed, 31 Oct 2001 15:57:13 -0500 (EST) Received: from ridgeway.ridgeway-sys.com ([10.1.1.1]) by avgw.vxserver.com (NAVGW 2.5.1.2) with SMTP id M2001103120542724843 ; Wed, 31 Oct 2001 20:54:27 GMT Received: by ThisAddressDoesNotExist with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Oct 2001 20:56:43 -0000 Message-ID: <00533D13955AD411AF3800A0C9B42639E921A4@ThisAddressDoesNotExist> From: Steve Davies To: "'midcom'" Cc: "'Melinda Shore'" , "'Jonathan Rosenberg'" Subject: RE: [midcom] pre-midcom candidates - the Davies Critique Date: Wed, 31 Oct 2001 20:56:42 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1624E.8AE3A370" 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_01C1624E.8AE3A370 Content-Type: text/plain; charset="ISO-8859-1" (Apologies if you get this twice. The first attempt was too long for the mailing list so I've deleted the history.).... Naturally, I don't entirely agree with Jonathan's analysis. Here is mine: The Sen Proposal: ----------------- I don't see the Sen proposal as an adequate near-term/pre-midcom solution for two main reasons: (a) it requires changes to the protocol: ---------------------------------------- In order to make the Sen proposal work we are told that a new service tag must be incorporated in the SIP Register request and a new SIP Ping (keep-alive) method must be incorporated. Not only will this take time to implement in SIP but presumably we'll also need corresponding protocol changes for Megaco, MGCP, H.323, etc. Or is Midcom SIP-specific? (b) it requires behavioural changes to the client: -------------------------------------------------- It requires symmetric RTP and the continual transmission of RTP and RTCP packets to keep the NAT bindings open. While symmetric RTP may be a good thing, that doesn't imply all applications have constant bi-directional streams - think of 'broadcast' type applications. Also why should terminals be expected to turn off silence suppression? How are endpoints to know when and when not to make this behavioural change? Other weaknesses of the proposal include a requirement on terminals to signal to the SIP proxy when they are behind a NAT. It is not explained how they are supposed to know whether or not they are. Additionally, the use of random ports on the RTP Proxy makes it difficult to protect such a device with a regular filtering firewall. Such configurations would be required for an enterprise do-it-yourself solution(the enterprise is its own provider) and by service providers wanting to protect their networks and service from DoS attacks. Note that correction of all these shortcomings results in the same architecture and method outlined in the Davies proposal. The Rosenberg/STUN Proposal: ---------------------------- Whilst I acknowledge the STUN proposal provides a method to determine the type of NAT a terminal may be behind, I view the proposal as incomplete and potentially impractical candidate as a near-term/pre-midcom solution. a) Firewalls are everywhere: ---------------------------- Whenever a firewall is deployed in conjunction with a NAT, irrespective of the type of NAT, the net result is equivalent to what the STUN method describes as a Symmetric NAT. In the case of symmetric NATs, the Rosenberg proposal acknowledges that a media intermediary/relay (or RTP Proxy) is required. However, the STUN proposal doesn't inform us what the architecture and method are for making calls in this case, although Jonathan acknowledges in his email that there are three solutions - the Davies proposal, the Sen proposal and an unpublished STUN proposal. Firewalls are a fact of life in all enterprises connected to the internet. An ever-increasing number of users are installing firewalls in their homes as well. The majority of calls will require a media intermediary/RTP Proxy. In other words, VoIP providers will have to install media intermediaries from Day One of any service. Can you imagine the subscription scenario if they don't: Customer: 'Please may I subscribe to your service' Provider: 'Is your terminal behind a firewall?' Customer: 'Yes' Provider: 'Sorry our service won't work for you' or 'Yes, but please place your terminal outside the firewall' or 'Yes, but you can only call other people not behind a firewall or symmetric NAT'. This is not what the VoIP industry needs right now! b) Too early to optimise: ------------------------- The STUN proposal boils down to a port saving technique for VoIP providers. But in a nascent market its impractical to start with a port saving technique particularly when its unquantifiable how many ports a provider may save. What providers need is a solution that is deployable in all cases - that implies a media intermediary solution. Trying to combine a port saving technique in conjunction with a media intermediary solution will add complexity that will delay and stall the VoIP market. From a provider's perspective, this delay and additional testing could far outweigh any savings gained by requiring fewer media intermediary ports. c) Unproven: ------------ i) TIMEOUTS. When a user is behind a firewall or symmetric NAT, to avoid use of a media intermediary the terminal must invoke the STUN protocol on a call by call basis. The STUN protocol requires potentially significant timeouts to expire in order to determine whether media may go direct. What will this do to call setup times? ii) NETWORK BASED NATS. There may be cases where the terminal determines that the media may go direct, but in fact the media passes through network based NATs and the call will fail. This would typically happen at the provider boundary, because the provider uses some internal addressing scheme or when passing from IPv4 to IPv6 networks. The solution would be to place the STUN server on the remote side of those network based NATs, but this would have the consequence of tromboning the media via those network based NATs for 'provider-internal' calls, defeating the reason for STUN. Alternatively, multiple STUN servers would need to be deployed - one for each different NAT location, but that then poses the question of how a terminal would know which STUN server to use on a call-by-call basis. Davies proposal: ---------------- The Davies proposal is very midcom-like. The Proxy Extension Agent (PEA) is like a MIDDLEBOX and the Application Proxy (AP) is like a MIDCOM AGENT. The AP is responsible for getting publicly reachable transport addresses on the PEA for external calls and publishing those addresses in the protocol messages. The Davies proposal simplifies the security policy problem being grappled with by MIDCOM to a very simple static policy administered and controlled by the IT manager and implemented on existing firewalls. Just three static pinholes are required to be configured in the firewall. Furthermore, these pinholes are outbound pinholes(i.e. out from the enterprise). Jonathan writes that in the Davies draft there are issues to do with consistency with enterprise firewall policy, but this is unsubstantiated. When details of these issues are provided, we will be happy to discuss them. The Davies method is entirely consistent with enterprise firewall policy - it is similar to, but actually far more restrictive than the firewall policy that allows web browsing for example. The Davies proposal's policy has been vetted by service providers and is already in commercial deployments - we can only assume enterprises find it acceptable. As well as being midcom-like, the Davies method has many other significant advantages: * It provides a 100% solution. It will work anywhere no matter how many and what type and combination of firewalls and NATs there are. * No change is required to any of the protocols. It is not even necessary for endpoints to implement symmetric RTP. * The implementation can be made transparent to the endpoints or be implemented by them. * Enterprise or Service Provider deployments are possible. The PEA may be deployed within a service provider's network or within the DMZ of an enterprise's own service centre. * Passing through a media intermediary is seen as enhancing security and saving IP addresses. Hiding an enterprise IP address from the remote party (only the transport addresses of the PEA are published in messages) is seen as a benefit and enables the enterprise to use the same IP address used for other Internet traffic. * Service Providers see a benefit in handling the media through PEA for several reasons. It enables them to hide the transport addresses of their other service equipment. It provides them with a suitable point to implement wire-tapping (e.g.CALEA) - ITSPs in many countries are bound to provide such capabilities. It also provides them with a media QOS execution point and it provides suitable IPv4/IPv6 migration boundary points. Jonathan seeks to belittle the Davies proposal by likening it to RSIP. I'm not sure what the point is here. It is true that we have borrowed and learnt from many of the principles and techniques used within the Internet. That's why we have well known ports, outbound initiated connections, and TCP multiplexing, so it's not surprising the method is recognisable and architecturally looks similar to other protocols. What is unique, is the way in which this method combines the different Internet techniques together with the transport of real-time UDP streams without any tunneling overhead. In fact, the single disadvantage of the Davies proposal is that it requires media intermediaries, but no-one has devised a non-media intermediary solution that solves all of today's firewall and NAT deployments. In any case, media intermediaries are not of much concern to service providers because they will co-locate those intermediaries with their access equipment in their POPs. In due course, those intermediaries may even be implemented in the access routers or Midcom will obviate them. Pre-Midcom Recommendation: -------------------------- Jonathan writes that he wants to tackle the harder stuff, i.e. firewalls and symmetric NATs, later. The fact of the matter is that the Davies proposal has solved the harder stuff already. It is the Davies proposal that is the low-hanging fruit because it addresses 100% of deployments and it has working examples. Surely this is where a pre-midcom solution must start. A VoIP provider needs it from Day One because it is very likely some/many customers will have a firewall or symmetric NAT. If in time, providers are seeking more efficient deployments or are seeking to reduce costs, then the Davies solution is easily extended to incorporate a STUN-like method. But before embarking on this effort it would be wise to judge the market need and determine when MIDCOM will kick in. Steve Davies ------_=_NextPart_001_01C1624E.8AE3A370 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] pre-midcom candidates - the Davies Critique

(Apologies if you get this twice. The first attempt = was too long for the mailing list so I've deleted the = history.)....

Naturally, I don't entirely agree with Jonathan's = analysis. Here is mine:

The Sen Proposal:
-----------------
I don't see the Sen proposal as an adequate = near-term/pre-midcom solution for two main reasons:

(a) it requires changes to the protocol:
----------------------------------------
In order to make the Sen proposal work we are told = that a new service tag must be incorporated in the SIP Register request = and a new SIP Ping (keep-alive) method must be incorporated. Not only = will this take time to implement in SIP but presumably we'll also need = corresponding protocol changes for Megaco, MGCP, H.323, etc. Or is = Midcom SIP-specific?

(b) it requires behavioural changes to the = client:
--------------------------------------------------
It requires symmetric RTP and the continual = transmission of RTP and RTCP packets to keep the NAT bindings open. = While symmetric RTP may be a good thing, that doesn't imply all = applications have constant bi-directional streams - think of = 'broadcast' type applications. Also why should terminals be expected to = turn off silence suppression? How are endpoints to know when and when = not to make this behavioural change?

Other weaknesses of the proposal include a = requirement on terminals to signal to the SIP proxy when they are = behind a NAT. It is not explained how they are supposed to know whether = or not they are. Additionally, the use of random ports on the RTP Proxy = makes it difficult to protect such a device with a regular filtering = firewall. Such configurations would be required for an enterprise = do-it-yourself solution(the enterprise is its own provider) and by = service providers wanting to protect their networks and service from = DoS attacks.

Note that correction of all these shortcomings = results in the same architecture and method outlined in the Davies = proposal.

The Rosenberg/STUN Proposal:
----------------------------
Whilst I acknowledge the STUN proposal provides a = method to determine the type of NAT a terminal may be behind, I view = the proposal as incomplete and potentially impractical candidate as a = near-term/pre-midcom solution.

a) Firewalls are everywhere:
----------------------------
Whenever a firewall is deployed in conjunction with = a NAT, irrespective of the type of NAT, the net result is equivalent to = what the STUN method describes as a Symmetric NAT. In the case of = symmetric NATs, the Rosenberg proposal acknowledges that a media = intermediary/relay (or RTP Proxy) is required. However, the STUN = proposal doesn't inform us what the architecture and method are for = making calls in this case, although Jonathan acknowledges in his email = that there are three solutions - the Davies proposal, the Sen proposal = and an unpublished STUN proposal.

Firewalls are a fact of life in all enterprises = connected to the internet. An ever-increasing number of users are = installing firewalls in their homes as well. The majority of calls will = require a media intermediary/RTP Proxy. In other words, VoIP providers = will have to install media intermediaries from Day One of any service. = Can you imagine the subscription scenario if they don't:

Customer: 'Please may I subscribe to your = service'
Provider: 'Is your terminal behind a = firewall?'
Customer: 'Yes'
Provider: 'Sorry our service won't work for you' or = 'Yes, but please place your terminal outside the firewall' or 'Yes, but = you can only call other people not behind a firewall or symmetric = NAT'.

This is not what the VoIP industry needs right = now!

b) Too early to optimise:
-------------------------
The STUN proposal boils down to a port saving = technique for VoIP providers. But in a nascent market its impractical = to start with a port saving technique particularly when its = unquantifiable how many ports a provider may save. What providers need = is a solution that is deployable in all cases - that implies a media = intermediary solution. Trying to combine a port saving technique in = conjunction with a media intermediary solution will add complexity that = will delay and stall the VoIP market. From a provider's perspective, = this delay and additional testing could far outweigh any savings gained = by requiring fewer media intermediary ports.

c) Unproven:
------------
i) TIMEOUTS. When a user is behind a firewall or = symmetric NAT, to avoid use of a media intermediary the terminal must = invoke the STUN protocol on a call by call basis. The STUN protocol = requires potentially significant timeouts to expire in order to = determine whether media may go direct. What will this do to call setup = times?

ii) NETWORK BASED NATS. There may be cases where the = terminal determines that the media may go direct, but in fact the media = passes through network based NATs and the call will fail. This would = typically happen at the provider boundary, because the provider uses = some internal addressing scheme or when passing from IPv4 to IPv6 = networks. The solution would be to place the STUN server on the remote = side of those network based NATs, but this would have the consequence = of tromboning the media via those network based NATs for = 'provider-internal' calls, defeating the reason for STUN. = Alternatively, multiple STUN servers would need to be deployed - one = for each different NAT location, but that then poses the question of = how a terminal would know which STUN server to use on a call-by-call = basis.

Davies proposal:
----------------
The Davies proposal is very midcom-like. The Proxy = Extension Agent (PEA) is like a MIDDLEBOX and the Application Proxy = (AP) is like a MIDCOM AGENT. The AP is responsible for getting publicly = reachable transport addresses on the PEA for external calls and = publishing those addresses in the protocol messages.

The Davies proposal simplifies the security policy = problem being grappled with by MIDCOM to a very simple static policy = administered and controlled by the IT manager and implemented on = existing firewalls. Just three static pinholes are required to be = configured in the firewall. Furthermore, these pinholes are outbound = pinholes(i.e. out from the enterprise).

Jonathan writes that in the Davies draft there are = issues to do with consistency with enterprise firewall policy, but this = is unsubstantiated. When details of these issues are provided, we will = be happy to discuss them. The Davies method is entirely consistent with = enterprise firewall policy - it is similar to, but actually far more = restrictive than the firewall policy that allows web browsing for = example. The Davies proposal's policy has been vetted by service = providers and is already in commercial deployments - we can only assume = enterprises find it acceptable.

As well as being midcom-like, the Davies method has = many other significant advantages:
* It provides a 100% solution. It will work anywhere = no matter how many and what type and combination of firewalls and NATs = there are.

* No change is required to any of the protocols. It = is not even necessary for endpoints to implement symmetric RTP.
* The implementation can be made transparent to the = endpoints or be implemented by them.
* Enterprise or Service Provider deployments are = possible. The PEA may be deployed within a service provider's network = or within the DMZ of an enterprise's own service centre.

* Passing through a media intermediary is seen as = enhancing security and saving IP addresses. Hiding an enterprise IP = address from the remote party (only the transport addresses of the PEA = are published in messages) is seen as a benefit and enables the = enterprise to use the same IP address used for other Internet = traffic.

* Service Providers see a benefit in handling the = media through PEA for several reasons. It enables them to hide the = transport addresses of their other service equipment. It provides them = with a suitable point to implement wire-tapping (e.g.CALEA) - ITSPs in = many countries are bound to provide such capabilities. It also provides = them with a media QOS execution point and it provides suitable = IPv4/IPv6 migration boundary points.

Jonathan seeks to belittle the Davies proposal by = likening it to RSIP. I'm not sure what the point is here. It is true = that we have borrowed and learnt from many of the principles and = techniques used within the Internet. That's why we have well known = ports, outbound initiated connections, and TCP multiplexing, so it's = not surprising the method is recognisable and architecturally looks = similar to other protocols. What is unique, is the way in which this = method combines the different Internet techniques together with the = transport of real-time UDP streams without any tunneling overhead. =

In fact, the single disadvantage of the Davies = proposal is that it requires media intermediaries, but no-one has = devised a non-media intermediary solution that solves all of today's = firewall and NAT deployments. In any case, media intermediaries are not = of much concern to service providers because they will co-locate those = intermediaries with their access equipment in their POPs. In due = course, those intermediaries may even be implemented in the access = routers or Midcom will obviate them.

Pre-Midcom Recommendation:
--------------------------
Jonathan writes that he wants to tackle the harder = stuff, i.e. firewalls and symmetric NATs, later. The fact of the matter = is that the Davies proposal has solved the harder stuff already. It is = the Davies proposal that is the low-hanging fruit because it addresses = 100% of deployments and it has working examples. Surely this is where a = pre-midcom solution must start. A VoIP provider needs it from Day One = because it is very likely some/many customers will have a firewall or = symmetric NAT. If in time, providers are seeking more efficient = deployments or are seeking to reduce costs, then the Davies solution is = easily extended to incorporate a STUN-like method. But before embarking = on this effort it would be wise to judge the market need and determine = when MIDCOM will kick in.

Steve Davies

------_=_NextPart_001_01C1624E.8AE3A370-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Oct 31 17:25:31 2001 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 RAA04821 for ; Wed, 31 Oct 2001 17:25:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA13074 for midcom-archive@odin.ietf.org; Wed, 31 Oct 2001 17:25: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 RAA12944; Wed, 31 Oct 2001 17:20: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 RAA12915 for ; Wed, 31 Oct 2001 17:20:00 -0500 (EST) Received: from hotmail.com (f163.pav1.hotmail.com [64.4.31.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04748 for ; Wed, 31 Oct 2001 17:19:59 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 31 Oct 2001 14:19:31 -0800 Received: from 207.5.1.168 by pv1fd.pav1.hotmail.msn.com with HTTP; Wed, 31 Oct 2001 22:19:31 GMT X-Originating-IP: [207.5.1.168] From: "James Ho" To: midcom@ietf.org Subject: RE: [midcom] pre-midcom candidates Date: Wed, 31 Oct 2001 14:19:31 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 31 Oct 2001 22:19:31.0931 (UTC) FILETIME=[1D2F6AB0:01C1625A] 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 understand it, the Davies proposal requires an open UDP port on the firewall for media traversal. I can't think of many/any enterprises being willing to implement such a firewall policy. Or maybe my understanding is faulty?? james _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Oct 31 17:44:44 2001 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 RAA05180 for ; Wed, 31 Oct 2001 17:44:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA13891 for midcom-archive@odin.ietf.org; Wed, 31 Oct 2001 17:44:45 -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 RAA13803; Wed, 31 Oct 2001 17:37:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13720 for ; Wed, 31 Oct 2001 17:37:32 -0500 (EST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05070 for ; Wed, 31 Oct 2001 17:37:30 -0500 (EST) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 31 Oct 2001 14:27:14 -0800 Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 31 Oct 2001 14:27:14 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 31 Oct 2001 14:27:13 -0800 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.2966); Wed, 31 Oct 2001 14:27:13 -0800 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.3562.0); Wed, 31 Oct 2001 14:26:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [midcom] pre-midcom candidates - the Davies Critique Date: Wed, 31 Oct 2001 14:26:28 -0800 Message-ID: Thread-Topic: [midcom] pre-midcom candidates - the Davies Critique thread-index: AcFiTs681fQtjSIDSOit6UZaPwMeuQAC572A From: "Christian Huitema" To: "Steve Davies" , "midcom" Cc: "Melinda Shore" , "Jonathan Rosenberg" X-OriginalArrivalTime: 31 Oct 2001 22:26:30.0907 (UTC) FILETIME=[16EA14B0:01C1625B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA13721 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 Steve, Your point regarding "Stun and firewalls" is mistaken. The STUN requirement is that if there is a firewall, it let a response come in to a packet sent from an internal port. This is the default behavior of most "residential NAT/firewall", and it is also an optional behavior in many enterprise firewalls. Whether such a policy is deemed acceptable by the local IT manager is debatable -- there are pros and cons. -- Christian Huitema -----Original Message----- From: Steve Davies [mailto:sdavies@ridgewaysystems.com] Sent: Wednesday, October 31, 2001 12:57 PM To: 'midcom' Cc: 'Melinda Shore'; 'Jonathan Rosenberg' Subject: RE: [midcom] pre-midcom candidates - the Davies Critique (Apologies if you get this twice. The first attempt was too long for the mailing list so I've deleted the history.).... Naturally, I don't entirely agree with Jonathan's analysis. Here is mine: The Sen Proposal: ----------------- I don't see the Sen proposal as an adequate near-term/pre-midcom solution for two main reasons: (a) it requires changes to the protocol: ---------------------------------------- In order to make the Sen proposal work we are told that a new service tag must be incorporated in the SIP Register request and a new SIP Ping (keep-alive) method must be incorporated. Not only will this take time to implement in SIP but presumably we'll also need corresponding protocol changes for Megaco, MGCP, H.323, etc. Or is Midcom SIP-specific? (b) it requires behavioural changes to the client: -------------------------------------------------- It requires symmetric RTP and the continual transmission of RTP and RTCP packets to keep the NAT bindings open. While symmetric RTP may be a good thing, that doesn't imply all applications have constant bi-directional streams - think of 'broadcast' type applications. Also why should terminals be expected to turn off silence suppression? How are endpoints to know when and when not to make this behavioural change? Other weaknesses of the proposal include a requirement on terminals to signal to the SIP proxy when they are behind a NAT. It is not explained how they are supposed to know whether or not they are. Additionally, the use of random ports on the RTP Proxy makes it difficult to protect such a device with a regular filtering firewall. Such configurations would be required for an enterprise do-it-yourself solution(the enterprise is its own provider) and by service providers wanting to protect their networks and service from DoS attacks. Note that correction of all these shortcomings results in the same architecture and method outlined in the Davies proposal. The Rosenberg/STUN Proposal: ---------------------------- Whilst I acknowledge the STUN proposal provides a method to determine the type of NAT a terminal may be behind, I view the proposal as incomplete and potentially impractical candidate as a near-term/pre-midcom solution. a) Firewalls are everywhere: ---------------------------- Whenever a firewall is deployed in conjunction with a NAT, irrespective of the type of NAT, the net result is equivalent to what the STUN method describes as a Symmetric NAT. In the case of symmetric NATs, the Rosenberg proposal acknowledges that a media intermediary/relay (or RTP Proxy) is required. However, the STUN proposal doesn't inform us what the architecture and method are for making calls in this case, although Jonathan acknowledges in his email that there are three solutions - the Davies proposal, the Sen proposal and an unpublished STUN proposal. Firewalls are a fact of life in all enterprises connected to the internet. An ever-increasing number of users are installing firewalls in their homes as well. The majority of calls will require a media intermediary/RTP Proxy. In other words, VoIP providers will have to install media intermediaries from Day One of any service. Can you imagine the subscription scenario if they don't: Customer: 'Please may I subscribe to your service' Provider: 'Is your terminal behind a firewall?' Customer: 'Yes' Provider: 'Sorry our service won't work for you' or 'Yes, but please place your terminal outside the firewall' or 'Yes, but you can only call other people not behind a firewall or symmetric NAT'. This is not what the VoIP industry needs right now! b) Too early to optimise: ------------------------- The STUN proposal boils down to a port saving technique for VoIP providers. But in a nascent market its impractical to start with a port saving technique particularly when its unquantifiable how many ports a provider may save. What providers need is a solution that is deployable in all cases - that implies a media intermediary solution. Trying to combine a port saving technique in conjunction with a media intermediary solution will add complexity that will delay and stall the VoIP market. From a provider's perspective, this delay and additional testing could far outweigh any savings gained by requiring fewer media intermediary ports. c) Unproven: ------------ i) TIMEOUTS. When a user is behind a firewall or symmetric NAT, to avoid use of a media intermediary the terminal must invoke the STUN protocol on a call by call basis. The STUN protocol requires potentially significant timeouts to expire in order to determine whether media may go direct. What will this do to call setup times? ii) NETWORK BASED NATS. There may be cases where the terminal determines that the media may go direct, but in fact the media passes through network based NATs and the call will fail. This would typically happen at the provider boundary, because the provider uses some internal addressing scheme or when passing from IPv4 to IPv6 networks. The solution would be to place the STUN server on the remote side of those network based NATs, but this would have the consequence of tromboning the media via those network based NATs for 'provider-internal' calls, defeating the reason for STUN. Alternatively, multiple STUN servers would need to be deployed - one for each different NAT location, but that then poses the question of how a terminal would know which STUN server to use on a call-by-call basis. Davies proposal: ---------------- The Davies proposal is very midcom-like. The Proxy Extension Agent (PEA) is like a MIDDLEBOX and the Application Proxy (AP) is like a MIDCOM AGENT. The AP is responsible for getting publicly reachable transport addresses on the PEA for external calls and publishing those addresses in the protocol messages. The Davies proposal simplifies the security policy problem being grappled with by MIDCOM to a very simple static policy administered and controlled by the IT manager and implemented on existing firewalls. Just three static pinholes are required to be configured in the firewall. Furthermore, these pinholes are outbound pinholes(i.e. out from the enterprise). Jonathan writes that in the Davies draft there are issues to do with consistency with enterprise firewall policy, but this is unsubstantiated. When details of these issues are provided, we will be happy to discuss them. The Davies method is entirely consistent with enterprise firewall policy - it is similar to, but actually far more restrictive than the firewall policy that allows web browsing for example. The Davies proposal's policy has been vetted by service providers and is already in commercial deployments - we can only assume enterprises find it acceptable. As well as being midcom-like, the Davies method has many other significant advantages: * It provides a 100% solution. It will work anywhere no matter how many and what type and combination of firewalls and NATs there are. * No change is required to any of the protocols. It is not even necessary for endpoints to implement symmetric RTP. * The implementation can be made transparent to the endpoints or be implemented by them. * Enterprise or Service Provider deployments are possible. The PEA may be deployed within a service provider's network or within the DMZ of an enterprise's own service centre. * Passing through a media intermediary is seen as enhancing security and saving IP addresses. Hiding an enterprise IP address from the remote party (only the transport addresses of the PEA are published in messages) is seen as a benefit and enables the enterprise to use the same IP address used for other Internet traffic. * Service Providers see a benefit in handling the media through PEA for several reasons. It enables them to hide the transport addresses of their other service equipment. It provides them with a suitable point to implement wire-tapping (e.g.CALEA) - ITSPs in many countries are bound to provide such capabilities. It also provides them with a media QOS execution point and it provides suitable IPv4/IPv6 migration boundary points. Jonathan seeks to belittle the Davies proposal by likening it to RSIP. I'm not sure what the point is here. It is true that we have borrowed and learnt from many of the principles and techniques used within the Internet. That's why we have well known ports, outbound initiated connections, and TCP multiplexing, so it's not surprising the method is recognisable and architecturally looks similar to other protocols. What is unique, is the way in which this method combines the different Internet techniques together with the transport of real-time UDP streams without any tunneling overhead. In fact, the single disadvantage of the Davies proposal is that it requires media intermediaries, but no-one has devised a non-media intermediary solution that solves all of today's firewall and NAT deployments. In any case, media intermediaries are not of much concern to service providers because they will co-locate those intermediaries with their access equipment in their POPs. In due course, those intermediaries may even be implemented in the access routers or Midcom will obviate them. Pre-Midcom Recommendation: -------------------------- Jonathan writes that he wants to tackle the harder stuff, i.e. firewalls and symmetric NATs, later. The fact of the matter is that the Davies proposal has solved the harder stuff already. It is the Davies proposal that is the low-hanging fruit because it addresses 100% of deployments and it has working examples. Surely this is where a pre-midcom solution must start. A VoIP provider needs it from Day One because it is very likely some/many customers will have a firewall or symmetric NAT. If in time, providers are seeking more efficient deployments or are seeking to reduce costs, then the Davies solution is easily extended to incorporate a STUN-like method. But before embarking on this effort it would be wise to judge the market need and determine when MIDCOM will kick in. Steve Davies _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Oct 31 17:53:11 2001 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 RAA05255 for ; Wed, 31 Oct 2001 17:53:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA14011 for midcom-archive@odin.ietf.org; Wed, 31 Oct 2001 17:53: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 RAA13975; Wed, 31 Oct 2001 17:50:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13946 for ; Wed, 31 Oct 2001 17:50:44 -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 RAA05227 for ; Wed, 31 Oct 2001 17:50:43 -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 f9VMoFa18012 for ; Wed, 31 Oct 2001 14:50:15 -0800 (PST) Received: from spandex.cisco.com (rtp-vpn-27.cisco.com [10.82.192.27]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ABU73786; Wed, 31 Oct 2001 14:49:47 -0800 (PST) Message-Id: <5.1.0.14.0.20011031174517.00a5b0c0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 31 Oct 2001 17:52:08 -0500 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Current status 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 Pre-midcom: some issues have arisen at lofty levels and those are being ground through. For better or worse these issues are completely out of our hands. Many thanks for your patience while these get worked through, and I'll let you know when there's something to let you know. Requirements: The new revision of the requirements documents will be in your hands shortly. This should not hold up progress on ... Framework: There have been *no* comments on the recent revision of the framework draft. I'm not sure I want to start WG last call on it until I have some sense of whether or not more than a few people have given it a good going-over already. Have you? Salt Lake City: we're tentatively scheduled to meet Monday evening. I'll get a draft agenda to you in the next few days; needless to say the primary topic will be rechartering. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom