Subject: [midcom] RE: Comments on requirements draft v2

From: "Cedric Aoun" <[email-masked]>
Date: Thu, 2 Aug 2001 17:19:36 +0100

Hopefully the email will go through ...

-----Original Message-----
From: Aoun, Cedric [QPD:MA01:EXCH] 
Sent: Thursday, August 02, 2001 5:41 PM
To: Richard Swale (E-mail)
Cc: Midcom IETF (E-mail)
Subject: Comments on requirements draft v2

Richard,
Here are my comments (as well from others sent back on draft v1) on
requirements draftv2:
I hope I didn't overlap with comments already sent, if so sorry for the
spam.

1.1.   Background 
Session *orientated* applications - Typo 
4.1, page 5
"A Middlebox may establish whether the association with a specific
   MIDCOM Agent should be allowed via a Policy Server"
I think this should be reworded as:
A Middle Box may establish an association with a specific MIDCOM agent,
following a
query with the policy server to check the rights and authorization of the
Midcom agent.

4.4.    Distribution of MIDCOM elements
"The Middlebox therefore needs to support multiple simultaneous
   MIDCOM Agents"
We should also state:
Similarly a Midcom agent should support multiple simultaneous Middle Boxes. 

5. page 6
Pinhole opening are not the only things the Midcom protocol should allow the

Midcom agent to request the Middle box to do.
Address and ports binds need to be added, a statement should say that other 
middle box functions will be handled as well but not in the initial version
of the protocol.

5.1, page 6
I think we should also mention the lifetime of the aggregated flows related
descriptor 
(what is called session descriptor in the framework draft).
The descriptor can be by default taken out explicitly. Lifetime could be an
idle timer 
(periodic after each packet traversal) or absolute.
5.1.1
"The MIDCOM Protocol must allow a MIDCOM Agent to specify a Pin-Hole
   in terms of the address and port mappings required."
It seems that you are mixing BINDs with pinholes, this provide a lot
confusion. 
I suggest that we modify the entire section 5 by doing a distinction between

address/port binds and pinholes.

5.3.3 
"A Pin-Hole may be closed such that ICMP reporting for subsequently
   discarded packets is either enabled or disabled."
Should we understand that when the pinhole is closed the Middle Box will
send an ICMP 
error message (type 3) with code 10 or 13.
I think it is best to reword it as:

When the pinhole is closed, ICMP may either be enabled or disable to send
error messages 
to the originator when packets are not allowed path through (doesn't this
look easier to digest).

5.3.6
Error handling includes also :
-Messages that did not arrive in the required protocol sequence
-Cases where an agent request things that are not allowed (try to get
control on other session descriptor)
-Misunderstood messages or unknown messages
- ...

6.6.1
"The MIDCOM Agent may report its status to a Middlebox with which it
   is associated.

   A Middlebox may report its status to a MIDCOM Agent with which it is
   associated."

How is do we define status?
Is it the load of the device, if it is still working properly etc...
Or does it include a self audit report on booked resources by the peer?
I think we need to be a little bit more specific.

6.6.3.  Protocol Failure

 "  To enable management systems to interact with the MIDCOM
   environment, the protocol needs to include failure reasons that
   allow the MIDCOM Agent behavior to be modified as a result of the
   information contained in the reason. Failure reasons need to be
   chosen such that they do not make an attack on security easier."

I would see this paragraph merging with the error handling section. no?

"MIDCOM session disconnection may be prompted by a successful de-
   registration request or a failure of some sort, such asa
   communications failure between the Middlebox and MIDCOM Agent.

   At the end of a MIDCOM session between a Middlebox and MIDCOM Agent,
   it should be possible for either the Middlebox or the MIDCOM Agent
   to initiate the disconnection of the relationship."

This is assuming that the MIDCOM protocol is a connection oriented protocol,
in which 
the peers have established a connection, and then the peers started to send
allocation 
of application session related things( pinhole opening, BINDs request,
bandwidth 
allocation requests ..). This is not currently the case since we have not
decided that 
MIDCOM is a connection oriented protocol.

What you mention might be achieved by using a root type of descriptor that
includes all
 the descriptors currently defined between the Middle Box and the Midcom
agent. 
When the MIDCOM agent has no longer authorization, the Middle box sends a
message
 saying that it is taking out the root descriptor and says the reason for
the decision.

Thanks

Cedric