Subject: Fwd: [midcom] Changes in semantics (Version 05)

From: Melinda Shore <[email-masked]>
Date: Thu, 2 Oct 2003 10:54:53 -0400

I don't think we need to go through full WG last call
on this revision before sending it to the IESG, but I'd
like to give participants a few days to look it over and
raise any objections they may have.  So, if no concerns
are raised by the end-of-business on Monday, 5 October,
I'll be forwarding the document to the IESG for review
next week.  At a minimum, please look at the changes
that Martin has listed.

Thanks,

Melinda

Begin forwarded message:

> From: Martin Stiemerling <[email-masked]>
> Date: Thu Oct 2, 2003  10:44:02 AM US/Eastern
> To: [email-masked]
> Subject: [midcom] Changes in semantics (Version 05)
>
> Hello folks,
>
> I have submitted an updated version of the semantics (Version 05). The  
> version is available in advance here:
>
> ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-ietf-midcom- 
> semantics-05.t
> xt
>
> The changes in this version are:
>
> - Policy Rule List (PRL) and Policy Rule Status (PRS) are now  
> mandatory.
>  (Based on comments from Juergen Schoenwaelder)
>
> - Fixed comments from Daniel
>  - Text in Section 2.1.8
>  - Figure 2, (mc=0) inserted text before Figure 2
>  - Text in 2.3.6  about IPv4 and IPv6 changed
>  - in PRR mode parameter changed to service parameter, adapted text
>    on middlebox modes
>  - Fixed failure text in RLC
>  - fixed all text errors
>
> - added middlebox (NAT) policy rule idle-timeout to middlebox's  
> capabilities
>  with a link to ARE
> - added 'optional interface specific policy rules' capability to
>  capability list
> - inserted new chapter "Interface specific Policy Rules"
> - adapted references in whole text to the new numbering due to issue  
> one
>  above
> - added optional inside/outside interface parameter to PRS (2.3.12)
> - added optional inside/outside interface parameter to PRR (2.3.8)
>   - added to request parameter list
>   - added corresponding failure reasons
>   - added semantical descriptions
> - added optional inside/outside interface parameter to PER (2.3.8)
>   - added to request parameter list
>   - added corresponding failure reasons
>   - added semantical descriptions
> - added statements in conformance section
> - checked spelling
> - added A0 parameter to PRR transaction (Pyda's comment)
>   - added PRR/A0 statement to PER
> - added text about Pyda's concern w.r.t. reserved outside NATed  
> addresses
>  in PRR :
>  Once a PRR transaction has reserved an outside address (A2) for an
>  internal end point (A0) at the middlebox, the middlebox must ensure  
> that
>  this reserved A2 is available in any subsequent PER and PRR  
> transaction.
> - added paragraph about NAT terminology in terminology section
> - revised examples to reflect changes in semantics
>
> With best regards
>
> Martin Stiemerling
>
> NEC Europe Ltd. -- Network Laboratories  [email-masked]
> PGP Key at:        http://www.stiemerling.org/stiemerling_nec.gpg
> IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de
>
>
> _______________________________________________
> midcom mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/midcom
>

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 6 Oct 2003 20:06:01 -0700 (PDT)

Hi,

I briefly read through the draft this weekend. I still do not believe, the
semantics is clear. The abstractions are not adequate to eliminate
ALGs from a middlebox. 

1. Terminology - I do not believe, you should  proliferate of semantics
for "NAT binding". This sounds like, it will be whatever you want it to be in
sessing up a session. 

2. PRR is still fuzzy. The PRR reserves a maximum of two IP addresses (in the
case of twice-NAT) and/or several ports on an address. Depending upon what the
agent lists in the request parameters, this can be reservation of an address
bind, or reservation of a bunch of ports (from a NAPT map entry, presumably) or
reservation of an address each from two map entries. The middlebox returned
rule identifier can represent any of this (Bind handle or single map
reservation or two address map reservations). This is simply a lot of stuff in
a single transaction. Very difficult and confusing for a middlebox to do this.

Specifying the internal IP address helps in reserving a pool of ports in a NAPT
case or an address BIND in the case of basic NAT. But, that alone is not
adequate for twice-NAT. The transaction needs to include the destinaion
end-point. otherwise, PRR is not usable for Twice-NAT for the same reason the
PRR was not usable for traditional NAT in the previous rev of the draft. The
middlebox cannot pick up an arbitrary address from one of the map entries for
twice-nat, not with just A0 in the request list.

As I said earlier, I suggest, the PRR be simplified split up into doing BIND
reservations and MAP reservations independently.

3. PER should simply be labelled as session creation request. The text in the
draft that refers this as BIND in some cases shoudl simply be eliminated. PER
essentially boils down to setting up NAT sessions/flows using pre-established
binds or pre-reserved map entries or simply creating a new session. When the
session is created, the response should indicate the BINDs used, if any, and
the translation end-points for the session. 

The twice-NAT example doesnt make sense. If the session is between A0 & A1 (as
would be in the case of twice-NAT) the agent cannot know A3 ahead of time.
However, that is what the PER request parametere description indicates.
 
3. The document says in several places that the NAT is one of traditional NAT
or Twice-NAT. What about bi-directional NAT? I saw this mentioned just once in
PER description. When you support bi-directional NAT, it is important for the
PRR and PERs to support sessions initiated from the outside, in additiona to
sessions initiated from the private realm. The request parameters in PRR and
PER are not adequate to support this.

4. I still have an issue with GroupId assignment being mandated on the
middlebox. RFC 3304 (Midcom Requirements), section 2.2.3 does not madate this.

Thats all for now.

cheers,
suresh

> > IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de

=====

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 08 Oct 2003 15:57:14 +0200

Hi Suresh,

thanks for checking the document again. More comments inline and I hope on 
more comments from other working group members.

Martin

--On Montag, 6. Oktober 2003 20:06 -0700 Pyda Srisuresh 
<[email-masked]> wrote:

| Hi,
|
| I briefly read through the draft this weekend. I still do not believe, the
| semantics is clear. The abstractions are not adequate to eliminate
| ALGs from a middlebox.
|
| 1. Terminology - I do not believe, you should  proliferate of semantics
| for "NAT binding". This sounds like, it will be whatever you want it to
| be in sessing up a session.

The intention was not to proliferate, but more an approach to bring more 
light to issue of NAT binding. Do you think that it confuses more than it 
does help?

|
| 2. PRR is still fuzzy. The PRR reserves a maximum of two IP addresses (in
| the case of twice-NAT) and/or several ports on an address. Depending upon
| what the agent lists in the request parameters, this can be reservation
| of an address bind, or reservation of a bunch of ports (from a NAPT map
| entry, presumably) or reservation of an address each from two map
| entries. The middlebox returned rule identifier can represent any of this
| (Bind handle or single map reservation or two address map reservations).
| This is simply a lot of stuff in a single transaction. Very difficult and
| confusing for a middlebox to do this.

Yes, that may look confusing, but pushing the task to the MIDCOM agent is 
more even more confusing to him.

|
| Specifying the internal IP address helps in reserving a pool of ports in
| a NAPT case or an address BIND in the case of basic NAT. But, that alone
| is not adequate for twice-NAT. The transaction needs to include the
| destinaion end-point. otherwise, PRR is not usable for Twice-NAT for the
| same reason the PRR was not usable for traditional NAT in the previous
| rev of the draft. The middlebox cannot pick up an arbitrary address from
| one of the map entries for twice-nat, not with just A0 in the request
| list.

The idea behind PRR is that the agent does not know the destination 
address.

This is the case for example in SIP call set-up. Only the data receiver in 
the private address realm is known on the first INVITE, if the caller is in 
this private address realm. This is a very tricky thing and PRR does 
provide a good mean to cope with that, even when it looks somehow strange. 
I could offer a powerpoint presentation from one of the IETF meetings 
explaining the need for PRR if you like.

|
| As I said earlier, I suggest, the PRR be simplified split up into doing
| BIND reservations and MAP reservations independently.
|
| 3. PER should simply be labelled as session creation request. The text in
| the draft that refers this as BIND in some cases shoudl simply be
| eliminated. PER essentially boils down to setting up NAT sessions/flows
| using pre-established binds or pre-reserved map entries or simply
| creating a new session. When the session is created, the response should
| indicate the BINDs used, if any, and the translation end-points for the
| session.

You are right in saying that with PER a NAT session is created. But for 
instance consider this scenario:

A PER request with an internal address (A0) and a wildcarded external 
sender (A3) (dataflow from outside to inside). The external sender is not 
known (One example is SIP early media). For that case you can not start a 
NAT session, since the NAT must create a NAT bind. Via this NAT bind 
several UDP/RTP flows from several destinations may traverse the middlebox 
to A0.

|
| The twice-NAT example doesn't make sense. If the session is between A0 &
| A1 (as would be in the case of twice-NAT) the agent cannot know A3 ahead
| of time. However, that is what the PER request parametere description
| indicates.

Hmm, I don't see the issue you raise immediately.

A3 is the external end point and A1 the inside IP address/port number at 
the twice-NAT. The application level session is between A0 and A3, but the 
IP/transport 'sessions' are between A0/A1 and A2/A3.

Could you give me some more hints?

| 3. The document says in several places that the NAT is one of traditional
| NAT or Twice-NAT. What about bi-directional NAT? I saw this mentioned
| just once in PER description. When you support bi-directional NAT, it is
| important for the PRR and PERs to support sessions initiated from the
| outside, in additiona to sessions initiated from the private realm. The
| request parameters in PRR and PER are not adequate to support this.

That's not true. For PRR the direction is not relevant, since only a 
resource reservation is made at the NAT. In PER there is the flow direction 
parameter that indicates the flow direction (inbound, outbound, or 
bi-directional). So with this it is possible to allow even sessions 
initiated from the outside.

|
| 4. I still have an issue with GroupId assignment being mandated on the
| middlebox. RFC 3304 (Midcom Requirements), section 2.2.3 does not madate
| this.

Right the protocol requirements do not mandate this, but as a lot of other 
points this is a design issue. So far nobody else has any objection about 
this.

|
| That's all for now.

Thanks for the comments.
Martin

[... cut by Martin ]

---

From: Tom Taylor <[email-masked]>
Date: Thu, 09 Oct 2003 16:56:52 -0400

I wanted to address your point regarding PRR.  Please see below.

> semantics is clear. The abstractions are not adequate to eliminate
...
> twice-nat, not with just A0 in the request list.

[PTT] The reason PRR was not usable for traditional NAT without specifying A0 was 
because it was possible the NAT already had a mapping for A0 because of an existing 
dynamically-established session, and had to have the information to choose it.  The 
reason we added an optional interface identifier was because the NAT could be 
supporting multiple private interfaces.

It is a fact that the application, and thus the agent, will often not know A3 at the 
time of the PRR request.  It is thus important to confirm what is or is not possible 
in terms of NAT technology.  I assume you consider A3 necessary for the same reason 
as A0: because the NAT is unable to map the same external address to more than one 
internal address in the twice-NAT case, and the host at A3 may already be involved 
in another session operating through this middlebox.  If this is true (please 
confirm), it may be that we have to accept a certain percentage of cases where the 
PER will fail because the mapping assigned by the PRR is inconsistent with existing 
configuration.

> reservations and MAP reservations independently.

[PTT] I don't believe PRR does more than MAP reservations.

---

From: Pyda Srisuresh <[email-masked]>
Date: Sat, 11 Oct 2003 23:28:32 -0700 (PDT)

Hi Martin,

My apologies for not being able to respond sooner. Please see my comments
below. I am breaking up the response into 3 parts so as to close individual
parts seperately. Hope that is OK by you. In this e-mail I am going to simply
focus on PRR.

regards,
suresh

> light to issue of NAT binding. Do you think that it confuses more than it 

Yes. It is confusing to redefine the term. It would be better to use the term
as originally defined and intended.

> more even more confusing to him.

I wasnt suggesting pushing anything to the Midcom agent, much less make it
confusing. All I am saying is there should be transparency between Midcom
requests and middlebox resources. When there is transparecy, there will be
little consfusion on the part of the agent or the middlebox.

Here is something that might work for the agents as well as the middleboxes. Do
let me know what you think. 

Assume, the agent knows the middlebox IP interface(for which the midcom
requests shoudl be applied). Let us say the purpose of PRR is restricted to
reserve one of the following:

    a) Reserve translation address & port for SrcEndPOint on an inbound session
    b) Reserve translation address & port for DstEndPoint on an inbound session
    c) Reserve translation address & port for SrcEndpOint on an outbound
session
    d) Reserve translation address & port for DstEndpoint on an outbound
session
    e) (a) & (b) -- Twice NAT sessions
    f) (c) & (d) -- Twice NAT sessions
    g) (a) | (d) -- Bidirectional sessions
    h) (b) | (c) -- Bidirectional sessions
    i) Reserve translation address & portpair (for matching oddity) for
SrcEndPOint on an inbound session
    j) Reserve translation address & portpair (for matching oddity) for
DstEndPoint on an inbound session
    k) Reserve translation address & portpair (for matching oddity) for
SrcEndpOint on an outbound session
    l) Reserve translation address & portpair (for matching oddity) for
DstEndpoint on an outbound session
               
For these, the response will consist of a maximum of two binds. As you know,
Bind is essentially a reserve entity. A Bind is not enforced unless there is a
live session that uses it. The reponse in the case of (a), (b), (c) or (d), can
be a single address bind or port Bind. In the case of (e) and (f), the response
is two BINDs. In the case of (g) or (h), the response can be a single BIND, but
is set to be bi-directional. In the case of (i), (j), (k) or (l), the response
can be two port binds or a single address bind. In all cases, the response will
indicate the BIND type(address bind or port bind), BindId and the translation
end points. In the case NAT is unable to assign a BIND, the response will
indicate the same. In such a case, the agent will be advised to use PER
directly without the use of PRR.

Essentially, I eliminated the ability to reserve a bunch of ports (> 2). That
would remove the need for address map entry partial/full ownership connotation.

Hope this will work for you.

> The idea behind PRR is that the agent does not know the destination 

If this is twice-NAT and the agent doesnt know the destination address, how do
you propose to reserve an address?

> explaining the need for PRR if you like.
I donot know what you are refering to (i.e, where the caller, callee, midcom
agent and middlebox arelocated relative to each other). You might want to refer
the SIP example in the framework RFC-3303 (section 7.2, 7.3). In this example,
the midcom agent on SIP-Proxy creates/queries binds to permit the application
through.

Basically, unless the parameters in the request are clear, the middlebox cannot
do magic. If this is tricky for the agent, likely it is undoable for the
middlebox.

> | BIND reservations and MAP reservations independently.

Please seem my earlier comment. I think, we can get rid of map reservations and
establish transparency between PRR and Binds.

<... stuff deleted>

regards,
suresh

=====

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 12 Oct 2003 00:01:22 -0700 (PDT)

> several UDP/RTP flows from several destinations may traverse the middlebox 

If a BIND can be created ahead of time, PRR shoudl be used. Any number of
sessions can use that BIND (for the directionality supported by the BIND). The
second half of the session is irrelevant to the BIND. However, if the PRR is
unsuccessful, PER maybe used by the agent to setup a NAT session (with wildcard
match for external source and port) & the PER response will return back the
session Id. When the actual session occurs, that session parameters will be
used to plug the holes in the NAT session. Middlebox may be instructed to
notify the agent when the holes are plugged by the actual session.

> Hmm, I don't see the issue you raise immediately.

Basically, in a twice-NAT scenario, both source and destination end-points are
in the same address realm on both end-points. So, A session between A0 and A1
would be translated as a session between A2 & A3.

> IP/transport 'sessions' are between A0/A1 and A2/A3.

Right. So, if the agent is located on A0, the agent only knows A0 and A1. Agent
cannot know A3, right?
> Could you give me some more hints?

Basically, what I am saying is that PER request parameters ought to indicate
the session parameters as it knows. This is irrespective of whether the agent
is inside private domain or outside private domain; whether the agent is
resident on one of the end-hosts or on a proxy in-between.

> resource reservation is made at the NAT. 

Not true. BIND direction determines which sessions are allowed to use the BIND.

>                                          In PER there is the flow direction 
<... snipped>

regards,
suresh

=====

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 12 Oct 2003 00:10:46 -0700 (PDT)

> points this is a design issue. 

If you are saying the semantics design team opted for this approach, while
either approach is acceptable, I understand that. The document should, however,
state this explicitly. Otherwise, the reader gets the impression that the
semantics document is mandating this on the Midcom protocol designer, as it did
with everything else in the document.

>                                So far nobody else has any objection about 
> this.

Neither have i heard objections to not madating this on the middlebox.

regards,
suresh

=====

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 12 Oct 2003 00:33:27 -0700 (PDT)

--- Tom Taylor <[email-masked]> wrote:
> dynamically-established session, and had to have the information to choose
> it. 

That is not the only or main reason. Without specifying A0, NAT does know which
address to assign from several of its map entries.
 
>     The 

Yes.

> time of the PRR request.  

Fine. I dont have a problem with it. If the PRR makes a reservation for xlation
parameters for just one of the end-points, say A0, then there is no issue here.
The problem is only if the PRR makes reservation for both end-points as would
be the case with twice-NAT. In such a case, NAT cannot know to reserve for the
second endpoint.

>                          It is thus important to confirm what is or is not
> possible 

Mostly, yes, to what you say. NAT goes by the map entries when it has to carry
out PRR reservations. If a PRR requires xlation address reservations for both
src and dest endpoints, then it must provide the original endpoints for both
src and dest. Else, the PRR request for dual reservations will fail.

> [PTT] I don't believe PRR does more than MAP reservations.

As I mentioned in a different e-mail thread to Martin, I believe, PRR can
simply be a mechanism to obtain a maximum of two BINDs. I donot believe, there
is a need for map reservations in midcom protocol. Correct me, if I am wrong.

regards,
suresh

=====

---

From: Melinda Shore <[email-masked]>
Date: Mon, 13 Oct 2003 09:35:37 -0400

Suresh:

Many thanks for your detailed comments.  I am somewhat
concerned that we're getting later and later with this
document and that the issues you're raising deal with
specific NAT/firewall function while we (midcom) are dealing
with abstracted (or idealized) NAT/firewall function.  This
is something we need to be particularly careful about in
a document that describes protocol semantics.  Much of
what you've brought forward is more specifically the goo
between the abstract machinery and the low-level device
function, and as such I think needs to be treated as
implementation issues in many cases.  This gets back to
the question of whether or not we're doing a configuration
protocol, where the device specifics are reflected in
the protocol itself.  We're not, of course.

I'd really like to see us get this wrapped up and shipped
off.

Melinda

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 13 Oct 2003 11:21:19 -0700 (PDT)

Melinda,

I am not raising implementation issues or suggesting that Midcom be a
configuration protocol. I donot appreciate my comments being characterized that
way repeatedly.

The goal of my comments has been to make the transactions transparent and
relate to the resources the middleboxes manage. I pointed out areas that are
not clear or are not enforceable, and suggested way to fix them. It takes a
tremendous amount of time and energy on my part to provide this feedback. I did
not have to do this. I am doign this only for the benefit of the draft. 

I am trying to wrap this up. That was the essence of my last 3 e-mails. FYI.

regards,
suresh

=====

---

From: "Ajay Garg" <[email-masked]>
Date: Mon, 13 Oct 2003 13:32:28 -0500

Please remove me.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Pyda Srisuresh
Sent: Monday, October 13, 2003 1:21 PM
To: Melinda Shore
Cc: Martin Stiemerling; [email-masked]
Subject: Re: PER (Part 2 of what was Re: Fwd: [midcom] Changes in
semantics (Version 05))

Melinda,

I am not raising implementation issues or suggesting that Midcom be a
configuration protocol. I donot appreciate my comments being characterized
that
way repeatedly.

tremendous amount of time and energy on my part to provide this feedback. I
did

regards,
suresh

=====

---

From: Melinda Shore <[email-masked]>
Date: Mon, 13 Oct 2003 16:01:32 -0400

On Monday, October 13, 2003, at 02:21 PM, Pyda Srisuresh wrote:
> configuration protocol.

I realize that that's not your intent but I do think it's
a consequence.  So rather than describing what you're
talking about as "configuration" let me amend that to say
that I think you're closer to the metal than we intend to
be.  You describe the difference quite well towards the
bottom of your message  
http://www.ietf.org/mail-archive/working-groups/midcom/current/ 
msg03332.html .

I would feel far more comfortable with this discussion if
there were more participants arguing for a more middlebox-
centric view of the protocol.  Absent that I'd really like us
to move on.

Melinda

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 13 Oct 2003 17:52:25 -0700 (PDT)

Melinda,

When the abstraction is high and takes the
leave-it-to-vendors-to-do-the-right-thing approach, the resulting protocol can
have serious interoperability issues. That is why I believe, it is important
for the semantics to state and the middlebox /agent administrators to know what
has changed and why, when a command is run. This is what I am working with the
authors on over the mailing list. If you view this as middlebox centric
approach and is not pertinent to the document, you may certainly make the call
to send the doc to the IESG as soon as you wish.

regards,
suresh

=====

---

From: Melinda Shore <[email-masked]>
Date: Tue, 14 Oct 2003 12:32:57 -0400

On Monday, October 13, 2003, at 08:52 PM, Pyda Srisuresh wrote:
> have serious interoperability issues.

Overspecification has other drawbacks, as well (for example
the use of interface identifiers in requests has implications
for how routing information is passed around, which is an
enormous problem).

I've been thinking about how to proceed.  On the one hand
the concerns you've been raising really should have been
brought up before or during WG last call on the document, and
they aren't specifically responsive to the changes that were
made as a result of last call comments.  However, I don't want
to allow process to trump document quality (to a point - obviously
the discussion has to be bounded).  Given that, you were right to
raise issues that you identified.  On the other hand I'm not
seeing feedback from the other working group participants and
it's my sense that there's either not a lot of agreement or
not a lot of interest.  So, I would request that the document
editors close out the current discussions and if there are
no changes to the current draft that result from them to
let me know and I'll send the document to the IESG for review
and publication.  If there are substantive changes to the
document based on the current discussions we will need another
revision of the draft and another WG last call.

Melinda

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 14 Oct 2003 12:50:24 -0700 (PDT)

> for how routing information is passed around, which is an

[Suresh] Well, I dont buy this. I dont believe including the interface in a
request is ovespecifying or has implications on routing. Interface
specification was necessary because NAT/FW are configured per-interface, and is
independent of how the routing occurs in the box.

> made as a result of last call comments. 

[Suresh] I agree, I have not been part of the WG discussions until after the
first WG last call. I simply could not spare the time before. Sorry about that.
 
>                                         However, I don't want

[suresh] I understand what you say. 

regards,
suresh

=====

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 14 Oct 2003 20:31:55 -0400

Way back during the requirements phase this issue of middlebox interfaces
and topology came up, and I believe it was Scott Brim's draft (one of the 3
drafts on the topic) which suggested that the application (a.k.a. midcom
agent) could pass an IP address that it knew was in the network the desired
interface was connected to. For the SIP example in the framework document,
this would be the next-hop SIP server that the signaling was being sent to.

   signaling  +----+  +-----------+   +----+
      +-------+ S1 +--+-----------+---+ S2 +------+
      |       +----+  |           |   +----+      |
+-----+----+          | middlebox |          +----+-----+
| internal | A0    A1 |           | A2    A3 | external |
| endpoint +==========+===========+==========+ endpoint |
+----------+  media   +-----------+          +----------+

The midcom agent (S1) knows A0, but does not know A3 until the external
endpoint responds to the signaling request. What it does know is the
next-hop signaling server (S2) which the midcom-agent believes is in the
network that A2 is connected to. If the agent could pass this 'next-hop'
address (S2), the middlebox can figure out which interface on which to
reserve A2.  This way, the midcom-agent does not need to know the middlebox
interfaces or have any explicit knowledge of the topology.

cheers,
(-:bob

----- Original Message ----- 
From: "Pyda Srisuresh" <[email-masked]>

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 15 Oct 2003 20:49:51 +0200

Hi Suresh,

Am Sonntag, 12.10.03, um 08:28 Uhr (Europe/Berlin) schrieb Pyda 

> My apologies for not being able to respond sooner. Please see my 

Sorry for the delayed answer, I have been on a trip. I'll answer to all 
the three parts.

Regards
Martin

> as originally defined and intended.

Ok, I see the point, but then we are returning to the starting point: 
No clear defintion of how NAT binding is used in the semantics document.

> DstEndpoint on an outbound session

It is quite late for me, but as far as I can see we agree on this above.

> indicate the BIND type(address bind or port bind), BindId and the 

This example is quite fine, but since we are dealing with middleboxes 
(that includes any type of packet filters with any type of filter 
engine cababilites), returning a one-to-one mapping may not be 
possible. The goal of the semantics is to give a simple handle to the 
agent for acting with the middlebox.

Consider a NAT with a firewall engine, first of all if you give a 
one-to-one handle to all resources you need to know the location of the 
firewall engine (side of the NAT).  Second a single NAT bind may be 
sufficient for the NAt, but it may involve several firewall rules. For 
instance a single SIP call may involve up to four different firewall 
rules (one UDP stream in each direction, plus perhaps one RTCP in each 
direction). With the approach that the semantics take you have as an 
agent only a single handle to deal with NAT binding and firewall rules.

> Essentially, I eliminated the ability to reserve a bunch of ports (> 

Reserving a bunch of ports is required by the MIDCOM protocol 
requirements.

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 15 Oct 2003 21:04:45 +0200

here comes number 3!

Am Sonntag, 12.10.03, um 09:10 Uhr (Europe/Berlin) schrieb Pyda 

> with everything else in the document.

Yes, the design team has chosen the approach. Unfortunately, I do not 
see the opportunity to justify every design choice within the document. 
Every protocol description has some implicit design choices that are 
not explicitly stated within the specific document.

Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 15 Oct 2003 21:01:23 +0200

Am Sonntag, 12.10.03, um 09:01 Uhr (Europe/Berlin) schrieb Pyda 
Srisuresh:

> sessions can use that BIND (for the directionality supported by the 
> BIND).

The intention is of PRR is just reservation of resources at the 
middlebox. A PRR does not enable any BIND in the NAT.

> would be translated as a session between A2 & A3.

OK, I see.

> Right. So, if the agent is located on A0, the agent only knows A0 and 

The agent is the ALG which is not on A0. Of course it is possible to 
run MIDCOM between A0 (the host inside the private address realm).  In 
this case (agent = A0) it cannot know A3.

The agent (agent != A0)  can know A3, since he intercepts and receives 
the signalling messages.

> the session parameters as it knows.

When I see it right, PER does. PER returns to the agent A1 and A2. But 
PER requires that the agent knows A3.

> This is irrespective of whether the agent

You are right that BIND direction determines the sessions that are 
allowed to use the BIND. But PRR does not create necessarily a BIND, 
PRR does a resource reservation at the middlebox. If a BIND is created 
it must be blocked by any mean, so it is not used through any packet.

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 16 Oct 2003 02:54:44 -0700 (PDT)

> not explicitly stated within the specific document.

Well, the problem is that the semantics document states "the semantics below
provide a minimum necessary subset of what must be implemented". I.e., there is
a mandating tone on the midcom protocol designer throughout the document.

Yet, from what you say above, the Midcom protocol designer need not go with the
design choice you made and still meet the midcom requirements. The document
should state what really is mandatory and what is not.

regards,
suresh

=====

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 16 Oct 2003 03:28:55 -0700 (PDT)

Martin,

Please see my comments inline below.

regards,
suresh

> middlebox. A PRR does not enable any BIND in the NAT.

[suresh] A newly created Bind without an active NAT session is merely a
reservation of a resource.

> The agent (agent != A0)  can know A3, since he intercepts and receives 
[Suresh] Sounds like, that the document makes assumptions on where the agent
should be. 

> PER requires that the agent knows A3.
[suresh] OK. Is this the case where the the agent knows the end-2-end session
to be A0-to-A3 or A3-to-A0? 

What if the the agent knew just A0 and A1. What transaction would the agent use
to obtain the S2 and A3? That woudlnt be PER, right?

It seems to me, the semantics document is defined for a specific application,
and asuming a specific location of where the agent might be located. Is this
the case? 

> it must be blocked by any mean, so it is not used through any packet.
[suresh] This does not make sense. If an address is reserved by an agent for a
private end-host (A0); and, another agent representing the same end host (but
for a diferent application) needs to use a BIND for that end-host, what do you
supoose the middlebox should do?  

=====

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 16 Oct 2003 03:46:58 -0700 (PDT)

Martin,

My comments inline below.

regards,
suresh

<... stuff deleted>
> No clear defintion of how NAT binding is used in the semantics document.
[suresh] I am suggesting that the usage of bind in the document be changed to
adhere to the definition of the term as it is used by NAT middleboxes.

> It is quite late for me, but as far as I can see we agree on this above.
[suresh] OK.

> agent for acting with the middlebox.
[suresh] You can still have a single handle back in response.

> agent only a single handle to deal with NAT binding and firewall rules.

[Suresh] I understand the need for 2 RTP sessions and 2 RTCP sessions. These
sessions are not reserved using a PRR. PRR is only for NAT. With PER, sessions
can be made as restrictive as you like.

> Reserving a bunch of ports is required by the MIDCOM protocol 
[suresh] I looked up RFC 3304. I could find just two requirements listed
concerning port reservation. These are 2.2.9 and 2.2.10. I am quoting these
below for every one's benefit.

2.2.9.

   When the middlebox performs a port mapping function, the protocol
   should allow the Midcom agent to request that the external port
   number have the same oddity as the internal port.

   This requirement is to support RTP and RTCP [RFC1889] "oddity"
   requirements.

2.2.10.

   When the middlebox performs a port mapping function, the protocol
   should allow the Midcom agent to request that a consecutive range of
   external port numbers be mapped to consecutive internal ports.  This
   requirement is to support RTP and RTCP "sequence" requirements

2.2.9 and 2.2.10 refer to preserving oddity requirement for consecutive ports
as required by RTP and RTCP (RFC 1889}. This is no more than 2 ports at a time.
In other words, Reserving a bunch of ports (> 2) is not required by RFC 3304.
Sound to me, we can establish transparency between PRR and Binds.

<... stuff deleted>

=====

---

From: Tom Taylor <[email-masked]>
Date: Fri, 17 Oct 2003 15:24:11 -0400

For heaven's sake, stop equating PRR with BINDs.  You keep creating that same straw 
man only to knock it over.  PRR at most creates address map entries.  PER creates BINDs.

Pyda Srisuresh wrote:

[snip]