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 12:05:42 +0200

Martin,

[CM] In network topologies containing departmental firewalls, typically it
is not topology hiding (NAT) that is being enforced 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
address 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. 

<CA>
I was discussing usage of packet filtering in Firewalls in the discussed
network topology. As the SNMP agent receive messages on a different port
than the one used to send messages, we have serious problem when the SNMP
agent is behind a NAT.
In case the Midcom agent is within the enterprise then this issue is no
longer relevant.
</CA>

Cedric
-----Original Message-----
From: Christopher A. Martin [mailto:[email-masked]]
Sent: 10 June 2002 21:58
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

Inline 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. 
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  
[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.
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.  
[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 
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. 
[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
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: "Mary Barnes" <[email-masked]>
Date: Sat, 15 Jun 2002 00:33:45 -0500

Hi all,

I've chosen this email out of the thread to respond to how I've dealt with
most of the issues raised in the latest version (-01) of the document [MB].
I think that other than the issue that we've already resolved wrt to the
further clarifications needed for Partial Compliancy (ala P+ and P), that
this thread covers all the requirements for which issues were raised. 

Mary. 

-----Original Message-----
From: Christopher A. Martin [mailto:[email-masked]]
Sent: Monday, June 10, 2002 2:58 PM
To: Aoun, Cedric [QPD:MA01:EXCH]; Barnes, Mary [NGC:B602:EXCH];
[email-masked]

-----Original Message-----

Hi Mary, 
General comments: 
 
[MB] Okay, I think I have fixed all those, however, I won't know for sure
until after it gets into the repository.  As I do have a hardcopy of what I
submitted and don't see those on my version. It is a result of the source
program that I used to create the document.

[CM] Agree [CM]

[MB] I also agree with this statement and I think I do see your point. I've
added an Editor's note as I'm thinking that the intent of the SNMP model was
that the MIDCOM PDP was part of the Middlebox and perhaps rather than equate
the SNMP agent to the MIDCOM PDP, it should be equated to the Middlebox (or
as you say the SNMP agent should be defined as the MIDCOM PEP, although this
term is not defined in the framework as such).  

[MB]I have reworded this as Juergen's response to this on Tuesday indicates
that he is referring to "multiple MIDCOM agents (SNMP Managers)
communicating with more than one middlebox simultaneously", so I believe the
wording should be changed from:
"An SNMP manager can communicate simultaneously with several SNMP agents."
To:
"An SNMP manager can communicate simultaneously with several Middleboxes."
Note, that this proposal is related to the issue raised in section 1.1.3 for
the SNMP overview and the fundamental mapping of SNMP Agent to MIDCOM PDP,
whereas the discussion seems to be that the SNMP Agent should map to the
MIDCOM PEP or the Middlebox OR it needs to be explicitly spelled out that
the MIDCOM PDP using SNMP is inherently part of the Middlebox (which is
allowed per the framework, so it's just something which requires
clarification). 

[MB] I think this point is consistent with the contributor's note, so I've
changed this one to a P and modified the text somewhat. 

[MB] Based upon another email thread, I have reworded this to indicate that
for SNMPv3 INFORMs could be used, thus the concern wrt to replies could be
met. 

[MB] This one is resolved by the addition of the new category of P+ which is
used for the protocols which easily allow the necessary modifications for
MIDCOM via extensions, packages, etc.  

[MB] Resolved with P+ category for SNMP, DIAMETER and COPS, leaving RSIP as
a P (which is consistent with the manner in which Megaco dealt with 2.2.7.)

2.2.9 Mapped port parity 
protocol.P

[MB] Resolved with P+ category.

2.2.10 Consecutive range of port numbers 
SNMP compliance should be partial as it requires the creation of the MIDCOM
MIB  
[CM] Ditto 
[MB] Resolved with P+ category.

2.2.11 Same as 2.2.10 for the SNMP compliance 
[MB] Resolved with P+ category.

3 Conclusion 

[MB] I've added a reference to the need to use SNMPv3 for problems other
than security and updated the conclusion to indicate this. There is an
explicit reference to TRAP with regards to the resolution for 2.1.7. 

 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, 

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

---

From: "Mary Barnes" <[email-masked]>
Date: Sat, 15 Jun 2002 00:33:56 -0500

Hi all,

Just a follow-up on how these comments were handled in the updated document,
responses indicated by [MB] below:

Mary.

-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]]
Sent: Monday, June 10, 2002 10:56 AM
To: Barnes, Mary [NGC:B602:EXCH]; [email-masked]'
Subject: Re: [midcom] Reminder: Comments due to list on

Mary,

Here are my comments.

First of all I agree to the statement that where SNMP evaluation
depends on a proper MIB module definition, "partially met" should
be used.

1.1.3, 2nd paragraph:
  replace "The roles of entities participating in SNMP
  communication are called from the manager."
  by "The roles of entities participating in SNMP
  communication are called manager and agent."

[MB] Done.

1.1.3, 3rd paragraph:
  replace "Although he" by "Although the".

[MB] Done.

2.1.3 COPS, editor's note
  I think COPS meets this requirement. For example the
  RFC 3084 on COPS-PR exlicitly mentions this.

[MB] Removed Editor's note and reworded the text to be consistent with this
being supported per RFC 3084: Changed the word "prohibit" to "preclude" and
removed "However". 

2.1: COPS in general
  I think it would be helpful to clarify, some COPS
  restrictions. For example RFC 3084 says: "When a
  (middlebox) device boots, it opens a COPS connection
  to its Primary PDP (Midcom agent)." This holds for
  each agent that wants to send midcom requests to the
  middlebox. The good point is that agent-PEP associtions
  survive power-failures. The disadvantage is, that each
  agent that intends to send midcom requests must be made
  known to the middlebox by means other than the ones provided
  by COPS.
  (Please correct me if I'm wrong.)

[MB] There's been no changes as a result of this since there was no list
response to this specific comment.  If folks would like to see this
restriction added, then propose explicit text to the list and highlight
whether this restriction applies to a specific requirement.  If it doesn't,
then overall I can't see the need to add anything to the document to address
this. 

2.2.2, SNMP
  We can replace the very generic phrasing by a more specific
  one:
  "SNMP explicilty supports managing different device type
  with different capabilities. First the managed object called
  sysObjectID from basic MIB-II (RFC1213) identifies the
  kind of box. For boxes with varying capabilites, SNMP can
  check the availability of corresponding MIBs."

[MB] Done. 

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

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.