Subject: [Tsvwg] New Internet Draft on SIMCO over SCTP

From: Sebastian Kiesel <[email-masked]>
Date: Mon, 17 Oct 2005 10:54:07 +0200

Dear all,

Please find below the announcement for a new Internet Draft that
specifies how to transport SIMCO over SCTP. SIMCO is a rather simple,
transaction based protocol for controlling firewalls and NATs. While
this ID is primarily a concern of the MIDCOM WG it might be of interest
here as well. Experience with a prototype implementation has shown that
SIMCO over SCTP has several advantages over using TCP. Any comments are
welcome.

Thanks,
   Sebastian

-- 
Sebastian Kiesel                University of Stuttgart
Tel: +49 711 685 7992           Institute of Communication Networks and
Fax: +49 711 685 7983           Computer Engineering (IKR, formerly: IND)
[email-masked]     Pfaffenwaldring 47, 70569 Stuttgart, Germany

----- Forwarded message from [email-masked] -----

To: [email-masked]
From: [email-masked]
Date: Thu, 13 Oct 2005 18:50:01 -0400
Subject: I-D ACTION:draft-kiesel-midcom-simco-sctp-00.txt 
Reply-To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: SIMCO over SCTP
	Author(s)	: S. Kiesel
	Filename	: draft-kiesel-midcom-simco-sctp-00.txt
	Pages		: 13
	Date		: 2005-10-13
	
   This document specifies how to use SCTP for the transport of the
   SIMCO (Version 3.0) protocol.  SIMCO (SImple Middlebox COnfiguration)
   is a protocol that implements the MIDCOM semantics.  It can be used
   for controlling middleboxes such as firewalls and network address
   translators.  SCTP (Stream Control Transmission Protocol) is a
   transport layer protocol that is expected to have advantages for this
   type of application, compared to TCP, which is the default transport
   layer protocol for SIMCO.  The specific requirements for SIMCO when
   using SCTP instead of TCP are specified in this document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kiesel-midcom-simco-sctp-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-kiesel-midcom-simco-sctp-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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-kiesel-midcom-simco-sctp-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.

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

----- End forwarded message -----

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

---

From: Randall Stewart <[email-masked]>
Date: Tue, 18 Oct 2005 14:10:58 -0400

Sebastian:

Very nice draft... one typo I saw in my quick
read..

In section 4.1 you typo'd SCTP as "SCPT"... other
than that it looks good..

One other question I had..  now I have not read SIMCO so
some of this is new to me.. so forgive me if I have something
wrong..

In section 4.4.1.3 you mention a PID rule learned by other
means.. so the agent does not know the mapping of what
stream the message goes to (you mention "especially PS"..
I assume this is the message type)..

Anyway.. In section 4.4.2.x I did not see anything
that had the server build a mapping of this aka
keep the responses to the PS message (if such a thing
exists) in the same stream... does that sort of
thing need to be mentioned here?

Just food for thought..

R

-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 19 Oct 2005 02:04:30 +0200

Randall,

thank you for your comments, please see inline:

> than that it looks good..
ok. thank you. it will be fixed in the next version.
 
> some of this is new to me.. so forgive me if I have something

Let me briefly explain the relevant SIMCO mechanism:

Under normal circumstances the agent ("client") asks the middlebox
("server") to establish a new policy rule, e.g., by means of a PER
request. The middlebox creates the rule and assigns a PID to it. The
PID is returned to the agent, e.g., in the PER positive reply. The agent
uses the PID in later modify/delete requests to refer to this specific
policy rule.

However, there is one special case, if we consider high reliability
solutions with redundant standby SIMCO agents. A (standby) SIMCO agent
may send a PRL (Policy Rule List) request to get a list of all PIDs that
are currently established in the middlebox. Then, it may send several PS
(Policy Status) requests, each containing one PID, in order to get more
information about the respective policy rule.

> thing need to be mentioned here?

With respect to the normal case, one basic idea of my draft is that the
agent shall remember the stream on which it received the message from
which it learned the PID (last paragraph of 4.4.1.2.). This stream pair
shall be used for all subsequent requests referring to this PID (first
paragraph of 4.4.1.3.).

The second paragraph of 4.4.1.3. refers to the special case. As the
PRL reply may contain quite a large list of PIDs, it is not reasonable
to remember the stream on which the PRL reply was received on for each
of these PIDs. Instead, the agent should distribute the requests over
all stream pairs.

> Just food for thought..

Considering that piece of additional information about SIMCO, 
does the text now become clearer, or do you feel that I should
reword something?

Thank you,
   Sebastian