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: Mon, 10 Jun 2002 09:45:22 +0200

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.

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.

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.
Similarly the statement on the broad deployment of SNMP doesn't include
SNMPv3,
this should probably stated as well.

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: Mon, 10 Jun 2002 17:08:18 +0200

Cedric,

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

> 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 2.1.2. SNMP doesn't include any Midcom agent identifiers, the identification
> I think we could find certain network topologies where firewalls are deployed

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???

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
> 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.

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.

> 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.

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,

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.

> 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.
>

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

---

From: "Bob Penfield" <[email-masked]>
Date: Mon, 10 Jun 2002 15:44:18 -0400

----- Original Message -----
From: "Juergen Quittek" <[email-masked]>
<snip>
> --On 10 June 2002 09:45 +0200 Cedric Aoun <[email-masked]>
wrote:
<snip>
> > 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.
> 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?
>

I think that reliability is covered by the requirement to maintain "known
and stable state". What's the point of sending a notification (TRAP) to a
midcom agent if there is no mechanism to guarantee that the message gets
there. The INFORM messages will need to be used if SNMP is chosen.

BTW, we did actually have an explicit requirement for reliability at one
point. I think it was deleted because people felt it was covered by the
other requirements.

cheers,
(-:bob

---

From: "Christopher A. Martin" <[email-masked]>
Date: Mon, 10 Jun 2002 14:57:48 -0500

RE: [midcom] Reminder: Comments due to list on
draft-ietf-midcom-protocol-eval -00.txt by Monday June 10th, noon CSTInline
comments....to Cedric.
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of
Cedric Aoun
  Sent: Monday, June 10, 2002 2:45 AM
  To: Mary Barnes; [email-masked]'
  Subject: RE: [midcom] Reminder: Comments due to list on draft-ietf-midcom-
protocol-eval -00.txt by Monday June 10th, noon CST

  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.

  [CM] Agree [CM]

  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.

  [CM] In network topologies containing departmental firewalls, typically it
is not topology hiding (NAT) that is being ebforced by the internal
firewall, rather access. Usually this is a concern which is implemented for
the Internet facing firewall, in addition to the possibility of private
addres space that may exist internally. But even if it is, this seems a bit
out of scope, since the internal agents may be provisioned on the middlebox
as a form of policy, but more often than not these internal firewalls will
not have access to or through the Internet firewall due to security policy.

  The method to identify the internal middleboxes is probably moot IMHO due
to any number of security policy decisions by the company that we could come
up with all day long, and is an issue which would affect any MIDCOM protocol
decided on today with eqaul complexity whether it is an existing protocol,
or  a completely homegrown brand new protocol. [CM]

   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.

  [CM] As far as I am concerned this [RSIP] is the same as NAT, WRT similiar
issues of imbedded IP, and is one of the issues MIDCOM is trying to resolve,
since I dont believe that adding another agent to every host is the answer
to the problem, merely adds another level of complexity to troubleshoot on
the host. [CM]

  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.

  [CM] in 2.1.7 Middlebox can generate unsolicited messages, the fact that a
response is not recieved to acknowledge the trap may be low risk due to the
fact that typically traps do not stop until alarm is mitigated. So it is
reliable unless you cant even communicate over the trap path (such as a WAN
link), in which event all protocols would fail this test. [CM]

  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.

  [CM] Agree with grading suggestion, more discussion could be done here.
Also, see my comment above about RSIP.

  [CM] This is already stated in the draft, however extensibility is not
difficult with SNMP nothing new to be done but develop the MIB.  Agree with
partially compliant, with the qualifier that this applies to any and all
protocols under evaluation/development.

  [CM] I would agree, only due to my opinion of RSIP....   :^)  [CM]

  2.2.9 Mapped port parity
  SNMP compliance should be partial as it requires the creation of the
MIDCOM MIB

  [CM] In this respect all of them fit partial compliance with this as far
as relating to the MIDCOM protocol. The point made, IMO, was that it could
be done easily with SNMP as this is part of its inherent nature as a
management protocol.

  2.2.10 Consecutive range of port numbers
  SNMP compliance should be partial as it requires the creation of the
MIDCOM MIB

  [CM] Ditto

  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.
  Similarly the statement on the broad deployment of SNMP doesn't include
SNMPv3,
  this should probably stated as well.

  [CM] Agree, but it should be noted that SNMPv3 is becoming more prevalent
in newer network implementations.

   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

  Hi all,

  July 26th- Aug (whether another iteration is required for WGLC depends
upon

---

From: Scott Brim <[email-masked]>
Date: Mon, 10 Jun 2002 16:02:46 -0400

> point. I think it was deleted because people felt it was covered by the

iirc we couldn't agree on how, and to what degree, that reliability
would be achieved.  I think it got folded into Christian's wording, that
the state of the middlebox must be deterministic.

...Scott