Subject: RE: [midcom] Confusion re. text in requirements-01

From: "Fleischman, Eric W" <[email-masked]>
Date: Wed, 27 Jun 2001 08:19:30 -0700

Scott,

My own preference is to exclusively rely upon timers in the middlebox
to close the pinholes, and I'd really prefer not having keep alives
(believing they are non-elegant and waste bandwidth), but I will defer 
to the experience of those who have actually built these systems.

Concerning your middlebox querying the Midcom Agents idea, that would 
be fine except for the question of how long a middlebox needs to wait 
before concluding that the Midcom Agent is gone. Lots of issues arise 
such as slow links, latencies due to the sheer remoteness of the Midcom 
Agent to the middlebox, and the possibility that the Midcom Agent is
experiencing a DoS attack. Back in the 90s, many addressed this issue
by waiting double the normal round-trip time. However, do the 
middleboxes want to keep such round-trip time statistics and is that
approach still appropriate for a more-hostile Internet? What do you think?

--Eric

-----Original Message-----
From: Scott Brim [mailto:[email-masked]]
Sent: Wednesday, June 27, 2001 8:00 AM
To: Fleischman, Eric W
Cc: midcom mail-list
Subject: Re: [midcom] Confusion re. text in requirements-01

On 26 Jun 2001 at 16:49 -0700, Fleischman, Eric W apparently wrote:
> In Section 5.3.2
> Where the communication relationship between a Middlebox and a MIDCOM 
> Agent are broken, all existing pin-holes must be closed. 
>           
> 	Question: Are you requiring "keep alive" overheads?

The question is whether "we" are requiring them.

A middlebox needs to be able to kill off pinholes for whatever reason.
That means keeping state information, in order to remember to do so.
That state could be an absolute timer, and that's a reasonable option
but too rigid to have as the only one.  The alternatives are observed
traffic and/or keepalives.  If an agent chooses to use an absolute
timer, that's fine.  If it chooses to use keepalives, who should be
responsible for the keepalives?  The middlebox has to have state anyway,
in order to kill off the pinhole eventually.  The agent *may* need
state, but not all agents do.  I'm leaning toward having the middlebox
send a query toward the agent -- "do you still want this?", but I still
haven't done a decent analysis.

...Scott

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

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

---

From: Andrew Molitor <[email-masked]>
Date: Wed, 27 Jun 2001 13:17:39 -0500 (CDT)

> to the experience of those who have actually built these systems.

	I assume you still allow Agents to explicitly close pinholes?
I had a bad moment when I read the first line, but I think you mean
that timers, if used, should be in the middlebox itself.

	A wrinkle from SIP-land: A stateless SIP proxy operating as
a MIDCOM Agent can get keepalives from the endpoints of a call, in
the form of re-INVITEs. To the vast amusement of those of us not
intimate with SIP, it turns out the re-INVITEs look pretty much like
INVITEs, and a stateless proxy can't necessarily tell the difference.

	Thus, it becomes convenient to be able to express keepalive in the
form of 'open a pinhole like this' and 'bind a NAT thing like this.' That
is, if keepalives for the middlebox state generated by a request of some
sort can be implemented by re-issuing the request, that is most helpful.
Of course, this is simply propogating the behavior of SIP forward into
MIDCOM, which might be considered brokenness-creep. On the other hand,
this approach also solves some of the 'lost INVITE' cases for call setup.

	In short, Agents WILL issue what are semantically keepalives, in
at least some cases. Whether they have an explicit keepalive method
available remains open.

	Some Middleboxes, of course, will have internal timers for state,
which timers will operate in one of a couple of different ways, as I and
others have indicated.

	I am very dubious of a middlebox-to-Agent 'I am about to delete
this, do you want it?' transaction. It screams of complexity and race
conditions.

	What works for me is this (I know I am getting ahead of
requirements into How To -- this is intended as an illustrative
example, not a proposed protocol): 

	- upon opening a pinhole or otherwise creating state, the
	  Agent can specify a timeout value, and a type (which
	  is either Activity Based or Absolute)
	- the reply from the middlebox can indicate (perhaps):
		OK
		I don't do timers at all, your state won't time out
		I don't do Activity Based timers so I used Absolute
			instead, with your timeout value
		I don't do Absolute timers, so you're getting my
			default Activity Based timeout of <n> seconds

	- a request isomorphic to a previous request for which state
	  still exists in the middlebox is considered a keepalive, and
	  simply restarts middlebox timers (if any) for any associated
	  state, and performs any other reasonable 'renewal' of the state.

	- the middlebox may implement a one-way 'I deleted this
	  piece of state for this reason' alert/trap method to let
	  Agents know when their state disappears.

	This set of methods seems to be to cover most of the bases,
without being insanely complicated. It's nothing more than a small handful
of reply codes, a specific requirement for what to do with duplicate
requests, and an optional trap method. Apart from the notion of Absolute
timers, and the proposed ability of the middlebox to do some sort of 'I
can't do timers like that so I used this other thing', this set of methods
has actually been built and works in the land of SIP.