Subject: RE: [midcom] Interim rev. of the famework draft

From: "Sanjoy Sen" <[email-masked]>
Date: Tue, 7 Aug 2001 23:22:50 -0500

I've the following questions/comments on the Interim draft:

1) In Section 4 - Midcom Protocol - it has been stated that the Midcom
protocol will consist of a connection set-up phase, run-time phase and a
connection termination phase. The meaning of "connection" is not clear.   

2) In timeline flow in Section 7.1, how would the SIP proxy identify the
end-to-end RTP, RTCP sessions from the private SIP UA to the external UA on
receiving the INVITE from external SIP UA? The INVITE SDP does not contain
any information of the RTP port of the media source.

3) In Section 7.2, what does creating "NAT session descriptors" mean? In
this context, the authors implied that this allows the early media flow
through the NAT. From the prior definition of session state, I would tend to
think that the flow will be allowed (or disallowed) only after a session
state (i.e., session descriptor + attributes) is created & a function
specific resource (e.g., NAT bind) is associated with the session state. Is
this correct? Please clarify.

Thanks,
Sanjoy

> -----Original Message-----
> From: Pyda Srisuresh [mailto:[email-masked]]
> Sent: Sunday, August 05, 2001 5:58 AM
> To: [email-masked]
> Subject: [midcom] Interim rev. of the famework draft
> 
> 
> Folks,
> 
> Please find attached the interim rev. framework draft.
> You may use this as reference during the editorial meeting. 
> Thanks.
> 
> regards,
> suresh
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with 
> Yahoo! Messenger
> http://phonecard.yahoo.com/
>

---

From: Scott Brim <[email-masked]>
Date: Wed, 8 Aug 2001 10:22:31 +0100

> connection termination phase. The meaning of "connection" is not clear.   

The concept of a "connection" is dubious and should be discussed.  Agent
and middlebox need to authenticate/authorize and then ensure that their
state is synchronized.  That's about it.

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

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 8 Aug 2001 06:35:56 -0400

----- Original Message -----
From: "Sanjoy Sen" <[email-masked]>
To: "'Pyda Srisuresh'" <[email-masked]>; <[email-masked]>
Sent: Wednesday, August 08, 2001 12:22 AM
Subject: RE: [midcom] Interim rev. of the famework draft

> any information of the RTP port of the media source.

End-2-end may not necessarily be a good choice of words, but at this point
all the information that the proxy is going to get on the RTP stream from
private phone to the external phone is know. Information of the RTP port of
the media source is not included either the INVITE's SDP or the 200-OK's
SDP. The RTP destination that the private phone provides in the 200-OK is
not necessarily the source of the media flowing from the private phone to
the external phone.

---

From: Andrew Molitor <[email-masked]>
Date: Wed, 8 Aug 2001 14:36:45 -0500 (CDT)

> connection termination phase. The meaning of "connection" is not clear.   

	I don't think the word 'connection' needs to be defined.
Ideally, there's a better word which means 'some sort of communications
session with sequence numbers or something to make authentication done
at the beginning of the session carry forward without undue effort
throughout the lifetime of the session'

	Then we should use that word. Anything more detailed gets
into implementation, which we're not doing yet.

> any information of the RTP port of the media source.

	This is correct (as Bob has pointed out). The general approach
to this is to use more "funnel" or "cone" shaped pinholes, with
one end unspecified. This is less secure than we would like.

	The SIP community is working on some schemes ("symmetric RTP")
in which the source of one media stream IS in fact the destination of the
other. Also, SIP could surely be extended to include optional media
source information?
> this correct? Please clarify.

	This sounds like it's getting into implementation again,
and not merely protocol implementation but middlebox implementation!

	I think the intention of MIDCOM in general and this document
in particular is to allow a variety of implementations. Certainly it
is reasonable to implement some sort of 'session' object inside the
middlebox, and attach things like pinholes and NAT bindings to it.
It is also reasonable to just treat the middlebox as a huge pile
of NAT bindings and pinholes, some of which are loosely related in
some fashion meaningless to the middlebox, but useful to the Agent.

	It is necessary to perform the NAT bindings before forwarding
a SIP INVITE, since the SDP needs to be re-written with information from
the NAT binding. It is reasonable, and perhaps even a good idea, to
open a pinhole at the same time, to allow the media to flow back to
the originator. It is, I understand, easy for the media to beat the
200 OK back.

	If there is a Session Object implemented in the middlebox,
to which things are attached, I personally would instantiate that
object when I saw the INVITE go by. I would immediately attach to
it a NAT binding, I would forward the INVITE, and then immediately
open a pinhole and associate that to the Session Object for the call.

	This is just one of a variety of schemes that can be used.
I hope that does not make things LESS clear, at any rate.

	I do not think the MIDCOM protocol, when defined, should
explicitly support the creation of session objects. Also, implicit in
the question above (I think) was the idea of being able to create
a Traffic Policy thing (a pinhole, or a NAT binding) and then to
separately activate it. I object strenuously to enshrining this
notion in the MIDCOM protocol. If you require atomic activation
of a collection of Traffic Policy things (which is a heck of a good
idea), you should batch them in a single transaction.

	This suggests a requirement for the protocol, that it should
support transactions with multiple requests in them, to be processed
atomically with respect to traffic processing.

		Andrew

---

From: "Bob Penfield" <[email-masked]>
Date: Thu, 9 Aug 2001 04:38:15 -0400

Andrew Molitor wrote:
> explicitly support the creation of session objects.

I disagree. It does not have to be mandatory, but it would be nice to
associate all the RTP streams of a SIP session together and be able to do
things like extend the timer or delete them with a single handle/identifer.

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 09 Aug 2001 15:46:37 +0200

I think I agree. I simply do not see what registration/connection/etc. buys. 
I understand "registration" as a way of telling "Expect some requests from me 
later" and do not understand what problem it solves. Unless some nice reasoning
appears, I would prefer dropping it.

If this is fine, there would be little justification for binding validity of 
a rule (or pinhole, resource, flow state and if we agree on none of these
we may call it simply foo!)  to the notion of connection. It would then only
be bound it its timer.

-Jiri

--
Jiri Kuthan            http://iptel.org/~jiri

---

From: Andrew Molitor <[email-masked]>
Date: Thu, 9 Aug 2001 10:15:42 -0500 (CDT)

> things like extend the timer or delete them with a single handle/identifer.

	I agree with the bundling idea (indeed, I consider it a
requirement). What I want to avoid is some CREATE_SESSION method
which doesn't do anything except create an empty box to put things
in. My preferred approach is to permit the Agents to supply a cookie
with meaningful transactions, and then to apply certain operations
to 'all the stuff with <this> cookie'

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 9 Aug 2001 08:26:39 -0700 (PDT)

There have been way too many messages to respond. I have not been up 
on all. I hope, my responses below are not out of context. (just a
cautionary note).

> things like extend the timer or delete them with a single handle/identifer.

Andrew - Why do you say that MIDCOM protocol should not explicitly support
creation of session object? I would think, it is a major requirement to
to be able to create session objects. 

As for session bundling capability - That would be a nice to have, as Bob
points out. Handling a bunch of sessions using a single handle (vs) Agent
tracking the session bundling and sending multiple commands for each of the
bundle member-sessions. (Refer draft-ietf-nat-interface-framework-03.txt for
a way to handle session bundling for NAT).

regards,
suresh

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 9 Aug 2001 08:51:45 -0700 (PDT)

> into implementation, which we're not doing yet.

Yes. 
Folks - We are getting carried away with word-dissection. This type of
thrashing has got to stop. A connection by no means implies TCP/UDP/SCTP
or some other implied transport. Donot assume any transport unless it 
is explicitly stated. People use different terms to imply a lasting 
association (i.e, more than just a datagram association). The FW draft
used the term "connection". That is all there is to it.

RFC 2409 (which uses UDP transport) uses "phase" and "mode" to imply 
a lasting association. (Refer Section 4)

   While Oakley defines "modes", ISAKMP defines "phases"....

   Phase 1 is where the two ISAKMP peers establish a secure,
   authenticated channel with which to communicate... 
   "Main Mode" and "Aggressive Mode" each accomplish a phase 1 exchange. 

   Phase 2 is where Security Associations are negotiated on behalf of
   services such as IPsec or any other service which needs key material
   and/or parameter negotiation. "Quick Mode" accomplishes a phase 2
   exchange.

RFC 2663 uses session/connection toimply a lasting flow.

   A session is defined as the set of traffic that is managed as a unit 
   for translation. TCP/UDP sessions are uniquely identified by the 
   tuple of (source IP address, source TCP/UDP port, target IP address, 
   target TCP/UDP port). 

regards,
suresh

---

From: "Bob Penfield" <[email-masked]>
Date: Thu, 9 Aug 2001 19:27:46 -0400

----- Original Message -----
From: "Andrew Molitor" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, August 09, 2001 11:15 AM
Subject: Re: [midcom] Interim rev. of the famework draft

> to 'all the stuff with <this> cookie'

I think I agree with that. I would want to say to the middlebox "create this
ruleset/pin-hole/whatever, oh and by the way, please give me an id for that,
and please associate it with bundle X". The bundle should not require a
separate command/request. Also, I would like to say to the middlebox "create
this ruleset, give me an id for it, and give me a new bundle id associated
with it that I can use to tell you what other rulesets are a part of this
bundle".

---

From: Scott Brim <[email-masked]>
Date: Mon, 13 Aug 2001 07:51:03 -0400

> we may call it simply foo!)  to the notion of connection. It would then only

It turns out Suresh uses "registration" to mean the simple act of making
an agent's *potential* relationship known -- typically done by
configuration of the policy server or the middlebox.  That's why the
current framework draft says less about deregistration and more about
disconnection.

A frob probably needs more than just a timer.  A middlebox probably
needs to keep track of overlapping requests, and who made the requests
(at least for management, perhaps for other reasons).  But the group
agreed that the "connection" requirement was rejected.

..Scott

---

From: Scott Brim <[email-masked]>
Date: Mon, 13 Aug 2001 07:51:16 -0400

> with it that I can use to tell you what other rulesets are a part of this

This is the where-to-put-state issue again.  It's convenient for the
agent but not for the middlebox.  In the case of a SIP agent, doesn't
the agent have to retain some state information about all the rtp
streams it has arranged for?  The middlebox has no reason to know what's
bundled, except to purportedly offload the agent, and it can't offload
the agent completely.  This looks like an almost perfect example of the
end-to-end argument
<http://web.mit.edu/Saltzer/www/publications/endtoend/>.  If you believe
that you won't put this state into the middlebox.  (On the other hand,
if Christian is right you're going to want lots of state in the
middlebox and very little in the agent anyway.)

..Scott