Subject: RE: [midcom] Reminder: Comments due to list on draft-ietf-midcom- protocol-eval -00.txt by Monday June 10th, noon CST

From: "Cedric Aoun" <[email-masked]>
Date: Tue, 11 Jun 2002 11:40:57 +0200

Juergen,
Please see my comments below.
Thanks.
Cedric
-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]]
Sent: 10 June 2002 17:08
To: Aoun, Cedric [QPD:MA01:EXCH]; Barnes, Mary [NGC:B602:EXCH];
[email-masked]'
Subject: RE: [midcom] Reminder: Comments due to list on
draft-ietf-midcom- protocol-eval -00.txt by Monday June 10th, noon CST

Cedric,

--On 10 June 2002 09:45 +0200 Cedric Aoun <[email-masked]>
wrote:

>
> Hi Mary,
> General comments:
> There is an inconsistency with the used compliancy method, Tom and you
have
> actually already mentioned that.In the comments below I will point out to
the
> requirements where the SNMP compliancy should be changed.
> I found "Æ" several times in the text instead of "'" it is perhaps due to
CRLF.
>
> Section 1.1.3 SNMP overview section: the Middle Box is a PEP and not a
PDP.
>
> Section 2.1.2. SNMP doesn't include any Midcom agent identifiers, the
identification
>  will be based on matching an IP address and port to a certain SNMP agent.
> In case more a Middlebox applying NAT is deployed between a Midcom agent
and
> the Middlebox being controlled by the Midcom agent then the identification
> can't be known in advance and therefore can't be provisioned.
> I think we could find certain network topologies where firewalls are
deployed
> in certain departments and then a NAT + Firewall is deployed at the
network
> interconnection of the enterprise. In this case all protocols not having
IDs
> will fail, including SNMP.IMO the requirement is not met by SNMP.

Did I get you right?: You think you can find some network cofiguration where
SNMP cannot support multiple Midcom agents communicating with more than one
middlebox simulataneously. But you cannot explain them here and therefore
the requirement is not met by SNMP???

<CA>
SNMP agents uses a particular port number to receive messages forgot if it
was 161 or 162.
In case we have a topology with FW - NAT
					  FW/	
How can the SNMP manager control the FW Middleboxes? If it can't rely to the
same port
the SNMP messages are sent from?THe problem I'm talking about is
MICOM NAT traversal problems.
In addition if we don't have the assymetric port usage, we have the
identification problem that could 
be solved with static bind but this is pretty ugly.
The ID problem is that since we don't discover Middlebox (in the current
architecture),
the Midcom agent is supposed to know them how will you identify them without
using IP address + port (since there is no
ID in the SNMP messages), this implicitly requires to use static binds in
the network scenario shown above.

</CA>

SNMP has several features only built in to explicitly support multiple
Midcom agents (SNMP managers) within a single stack. Not even multiple
instances of the PEP are required, as it is for COPS.

> Section 2.1.2 RSIP compliancy section. In RSIP the Midcom agent is coupled
with
>  the application host, it can't be on a separate host. I see as a failure
to
> meeting the MIDCOM framework, in which we wanted a complete flexible model
> where the Midcom agent function could be hosted on any host. This comment
is
> probably more on the general applicability of RSIP, but since there is a
note
> on it in 2.1.3 the comment is applicable on the section as well.
>
> 2.1.7 Reliability in SNMP is achieved by retransmissions and timers, this
mechanism
> applies only if the messages have a reply, in case of TRAPs this is not
the case.
> Therefore IMO this requirement is not met.

Requirement 2.1.7 says: "The protocol must support unsolicited messages from
middlebox to agent ...". How can you say this is not exactly what SNMP
notifications are available for?

If you require reliability in addition, I suggest the following procedure:
1. add reliability to the requirements
2. state that reliability is not met by SNMP notifications.

Please tell me, if I missed a reliability statement. Then we can discuss
replacing replace SNMP notifications by reliable SNMP inform messages.
I did not mention them yet, because they are not available in SNMPv1,
but they are in v2 and v3.

In any case SNMP meets the requirement.

<CA>
The reliability requirements are hidden behind the deterministic behavior
requirement.
We had initially a bunch of mother hood and applepie requirements that
included explicitly reliability,
but were taken out.
Perhaps we need to add them again in the requirements.
</CA>

> 2.2.1 Extensibility. I think we should grade differently protocols that
have existing
> means of extensibility without changing the base protocol messages by
using "objects"
> as means of extensibility and protocols that achieve extensibility by
adding new messages
> or parameters in the base protocol to achieve the extensibility. As such
the RSIP protocol
> requires more work to  be extensible and should be graded differently. I
don't know if it
> fair to put its compliancy to Partially met or Unmet.
>
> 2.2.8 Transport of filtering rules
> SNMP requires a new MIDCOM MIB to meet this requirement, therefore it is
partially
> compliant as the MIB is not existent
>
> RSIP currently couples the filter with the action which is address
translation
> or address and port translation. As we are looking at a model where the
filter
> is decoupled from the action (from a syntax perspective) I think that RSIP
> currently fails to meet the requirement.
>
> 2.2.9 Mapped port parity
> SNMP compliance should be partial as it requires the creation of the
MIDCOM MIB
>
> 2.2.10 Consecutive range of port numbers
> SNMP compliance should be partial as it requires the creation of the
MIDCOM MIB
>
> 2.2.11 Same as 2.2.10 for the SNMP compliance
>
> 3 Conclusion
> I think that in the SNMP statement the reliability problems should be
discussed
> as their fix is not included in of the shelf stacks and do not apply to
TRAP messages.

It is available in commercial off-the-shelf implementations as well as in
even very simple public domain implementations.

> Similarly the statement on the broad deployment of SNMP doesn't include
SNMPv3,
> this should probably stated as well.

Yes, that's right. However, we still should compare SNMPv3
deployment and maturity to COPS, Diameter, Megaco, RSIP deployment.
The SNMPv3 RFCs have already achieved draft standard status.

<CA>
Agreed
</CA>

> Cedric
>
>
> -----Original Message-----
> From: Barnes, Mary [NGC:B602:EXCH]
> Sent: 07 June 2002 02:58
> To: [email-masked]'
> Subject: [midcom] Reminder: Comments due to list on
draft-ietf-midcom-protocol-eval -00.txt by Monday June 10th, noon CST
>
> Hi all,
> Just a reminder that comments on the protocol evaluation draft are due by
noon on Monday, June 10th.  It's available at:
>
> http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol-eval-00.txt
> The level of discussion on this draft by members of the WG has been rather
disquieting.  The draft is not incredibly long, with the new material being
primarily in the Overview and Conclusion sections. There are a also few
areas which definitely need
> discussion and WG feedback which are indicated by [Contributor's note:
blah...blah...blah] and [Editor's note: yadda...yadda...yadda].  So, please
try to set aside 30 minutes and at least review those portions. The
objective is for the draft to be
> fairly complete and actually undergoing WGLC by the Yokohama meeting, so
comments now are definitely preferred over during the WG session or after
the Yokohama meeting.
>
> As a reminder, the remaining schedule for this WG draft is as follows:
> June 14th       Second version of draft available.
> June 14th-June 21st  Mailing list discussion of version 2 of draft.
> June 28th       Draft ready for WGLC
> July 19th       WGLC ends
> July 26th       Updated draft based upon WGLC comments available
> July 26th- Aug (whether another iteration is required for WGLC depends
upon
>                 the extent of changes, etc.)
> Aug     Draft submitted to IESG
> Regards,
> Mary H. Barnes
> [email-masked]
> 972-684-5432
> Wireless 817-703-4806
>

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 14 Jun 2002 11:41:34 +0200

Cedric,

Please see my comments inline.

Regards,

    Juergen
-- 
Juergen Quittek     [email-masked]     Tel: +49 6221 90511-15
NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de

--On 11 June 2002 11:40 +0200 Cedric Aoun <[email-masked]> wrote:

> --On 10 June 2002 09:45 +0200 Cedric Aoun <[email-masked]> wrote:
>
>>
>> Hi Mary,
>> General comments:
>> There is an inconsistency with the used compliancy method, Tom and you have
>> actually already mentioned that.In the comments below I will point out to the
>> I found "Æ" several times in the text instead of "'" it is perhaps due to CRLF.
>>
>> Section 1.1.3 SNMP overview section: the Middle Box is a PEP and not a PDP.
>>
>> Section 2.1.2. SNMP doesn't include any Midcom agent identifiers, the identification
>> In case more a Middlebox applying NAT is deployed between a Midcom agent and
>> I think we could find certain network topologies where firewalls are deployed
>> in certain departments and then a NAT + Firewall is deployed at the network
>> interconnection of the enterprise. In this case all protocols not having IDs
> SNMP agents uses a particular port number to receive messages forgot if it was 161 or 162.

Standard is using 161 for receiving get/set messages
and 162 for receiving traps. But you can use any available
port number, if you like.

> How can the SNMP manager control the FW Middleboxes? If it can't rely to the same port

Well, I assume that the NAT in your example is midcom-capable
(otherwise the scenario would be very strange). But then you
can use midcom to configure the NAT properly in a way that it
uses the same port numbers for both directions. So if you first
use MIDCOM to configure the NAT in front of you, you can
then use midcom to configure the FW behind the NAT without
any problem.

> In addition if we don't have the assymetric port usage, we have the identification problem that could

Yes, but isn't this what midcom is for.

> The ID problem is that since we don't discover Middlebox (in the current architecture),
> the Midcom agent is supposed to know them how will you identify them without using IP address + port (since there is no
> ID in the SNMP messages), this implicitly requires to use static binds in the network scenario shown above.

I share your concern about missing middlebox discovery in general.
However, in many concrete sceanrios you want to restrict midcom
agents to control middleboxes from within the protected network
only. Then discovery might be of less importance, because on the
administration side, knowledge about all middleboxes should be
available.

>> Section 2.1.2 RSIP compliancy section. In RSIP the Midcom agent is coupled with
>>  the application host, it can't be on a separate host. I see as a failure to
>> where the Midcom agent function could be hosted on any host. This comment is
>> probably more on the general applicability of RSIP, but since there is a note
>> 2.1.7 Reliability in SNMP is achieved by retransmissions and timers, this mechanism
>> applies only if the messages have a reply, in case of TRAPs this is not the case.
> The reliability requirements are hidden behind the deterministic behavior requirement.
> We had initially a bunch of mother hood and applepie requirements that included explicitly reliability,
> but were taken out.

If this was the intention, the reuqirements are not well phrased.
After carefully reading them I assumed that deterministic
behavior is requested only with respect to overlapping rules and
multiple agents.

So rephrasing seems to be a good idea. It is preferable to clearly state
individual  requirements compared to coding everything into a minimal
number of words, even if then some requirements repeat phrases
several times.

Anyway, I have a general concern about deterministic behavior.
Some way, it can easily get by policy control of the middlebox.
If we have policy control of how to handle overlapping rules,
we cannot change these policies during operation of the middlebox,
because otherwise the behavior of the box would be non-deterministic
from the affected agent's point of view.

    Juergen

> </CA>
>
>> 2.2.1 Extensibility. I think we should grade differently protocols that have existing
>> means of extensibility without changing the base protocol messages by using "objects"
>> as means of extensibility and protocols that achieve extensibility by adding new messages
>> or parameters in the base protocol to achieve the extensibility. As such the RSIP protocol
>> requires more work to  be extensible and should be graded differently. I don't know if it
>> SNMP requires a new MIDCOM MIB to meet this requirement, therefore it is partially
>> RSIP currently couples the filter with the action which is address translation
>> or address and port translation. As we are looking at a model where the filter
>> SNMP compliance should be partial as it requires the creation of the MIDCOM MIB
>>
>> SNMP compliance should be partial as it requires the creation of the MIDCOM MIB
>>
>> I think that in the SNMP statement the reliability problems should be discussed
>> as their fix is not included in of the shelf stacks and do not apply to TRAP messages.
>
>> Similarly the statement on the broad deployment of SNMP doesn't include SNMPv3,
>> Subject: [midcom] Reminder: Comments due to list on draft-ietf-midcom-protocol-eval -00.txt by Monday June 10th, noon CST
>
>>
>> Hi all,
>> Just a reminder that comments on the protocol evaluation draft are due by noon on Monday, June 10th.  It's available at:
>
>>
>> The level of discussion on this draft by members of the WG has been rather disquieting.  The draft is not incredibly long, with the new material being primarily in the Overview and Conclusion sections. There are a also few areas which definitely need
>
>> discussion and WG feedback which are indicated by [Contributor's note: blah...blah...blah] and [Editor's note: yadda...yadda...yadda].  So, please try to set aside 30 minutes and at least review those portions. The objective is for the draft to be
>
>> fairly complete and actually undergoing WGLC by the Yokohama meeting, so comments now are definitely preferred over during the WG session or after the Yokohama meeting.
>
>>
>> July 26th- Aug (whether another iteration is required for WGLC depends upon

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