From owner-rap@ops.ietf.org Sat Aug 3 17:19:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10920 for ; Sat, 3 Aug 2002 17:19:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17b6Gr-000CPu-00 for rap-data@psg.com; Sat, 03 Aug 2002 14:17:09 -0700 Received: from max.phys.uu.nl ([131.211.32.73]) by psg.com with esmtp (Exim 3.36 #1) id 17b6Gm-000CPj-00 for rap@ops.ietf.org; Sat, 03 Aug 2002 14:17:05 -0700 Received: from ruunat.phys.uu.nl (ruunat.phys.uu.nl [131.211.32.69]) by max.phys.uu.nl (8.9.3/8.9.3/hjm) with ESMTP id XAA00468 for ; Sat, 3 Aug 2002 23:17:03 +0200 (MET DST) Received: from localhost (fdijkstr@localhost) by ruunat.phys.uu.nl (8.9.3/8.9.3) with ESMTP id XAA03832 for ; Sat, 3 Aug 2002 23:17:02 +0200 (MET DST) X-Authentication-Warning: ruunat.phys.uu.nl: fdijkstr owned process doing -bs Date: Sat, 3 Aug 2002 23:17:02 +0200 (MET DST) From: Freek Dijkstra To: RAP workinggroup Subject: frameworkpib: Prid and InstanceId question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.4 required=5.0 tests=X_AUTH_WARNING,DOUBLE_CAPSWORD version=2.31 Sender: owner-rap@ops.ietf.org Precedence: bulk I just read draft-ietf-rap-frameworkpib-09.txt and got confused. Can someone please de-confuse (profuse? :-) ) me? Most data structures defined by a PIB start with some id attribute, which is of type InstanceId. It is my understanding that this InstanceId is something different than the PRID. For one thing, the definition of InstanceId, ReferenceID and PRID are in RFC 3159. ReferenceID and PRID are different. However, in draft-ietf-rap-frameworkpib-09.txt most (if not all) classes start with an attrbute of type InstanceId, and are called something like 'frwkBaseFilterPrid' (ending with the word Prid). This is very confusing: is it a Prid or a InstanceId, or are InstanceId's and Prid's the same? If they are not the same (as I hope), I strongly suggest to change the naming in your draft, becaused it really confused me! (Make it 'frwkBaseFilterId' and similar). Background, why I believed (perhaps incorrectly, but hopefully correct) that InstanceId's and Prid's are different: It is my understanding that a PRID is encapsulated in a COPS message in the following way: COPS common header (client type, action) COPS message-header (decision, command: install/delete) COPS-PR header (s-num = 1) PRID COPS-PR header (s-num = 3) PRI COPS-PR header (s-num = 1) PRID COPS-PR header (s-num = 3) PRI COPS message-header (named client info?) COPS-PR header (s-num = 1) PRID COPS-PR header (s-num = 3) PRI Is this correct? It's quite some time that I tried to figure this out, by reading RFC 3084 (COPS-PR). This made me assume that the PRID is an identifier which is created and maintained by the SPPI / COPS API, while the InstanceId is just an Id maintained by the application which maintains the rest of the data. So please tell me that they are really different, and it was just the naming that confused me. Thanks and regards, Freek From owner-rap@ops.ietf.org Sat Aug 3 18:01:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11430 for ; Sat, 3 Aug 2002 18:01:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17b6y0-000D4r-00 for rap-data@psg.com; Sat, 03 Aug 2002 15:01:44 -0700 Received: from max.phys.uu.nl ([131.211.32.73]) by psg.com with esmtp (Exim 3.36 #1) id 17b6xu-000D4f-00 for rap@ops.ietf.org; Sat, 03 Aug 2002 15:01:38 -0700 Received: from ruunat.phys.uu.nl (ruunat.phys.uu.nl [131.211.32.69]) by max.phys.uu.nl (8.9.3/8.9.3/hjm) with ESMTP id AAA23364 for ; Sun, 4 Aug 2002 00:01:36 +0200 (MET DST) Received: from localhost (fdijkstr@localhost) by ruunat.phys.uu.nl (8.9.3/8.9.3) with ESMTP id AAA23347 for ; Sun, 4 Aug 2002 00:01:36 +0200 (MET DST) X-Authentication-Warning: ruunat.phys.uu.nl: fdijkstr owned process doing -bs Date: Sun, 4 Aug 2002 00:01:36 +0200 (MET DST) From: Freek Dijkstra To: RAP working group Subject: frameworkpib & access-bind: filters Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.4 required=5.0 tests=X_AUTH_WARNING,DOUBLE_CAPSWORD version=2.31 Sender: owner-rap@ops.ietf.org Precedence: bulk Hi, I've got another, more technical problem, which basically boils down to the question how to specify wildcards in filters, like the ones defined in draft-ietf-rap-frameworkpib-09.txt. The issue merely applies to the Access Bind PIB (draft-ietf-rap-access-bind-01.txt), in case there will be a new revision, but maybe it's an interesting thought for PIB authors designing filters, like the ones in the frameworkpib. The current revision of the Access Bind PIB, draft-ietf-rap-access-bind-01.txt, uses scopes, which are classes which, among other things, specify a filter. They do that by including an attribute called eventHdlrEventScopeFilter in these scope classes. This ScopeFilter is a PRID pointing to some Filter Instance, for example one of the filters defined in in draft-ietf-rap-frameworkpib-09.txt. (See Background bellow for a one alinea introduction to the Access Bind PIB) Now, this scope is not only used to filter data traffic, used also use to trigger certain events. For example, you can specify that each data filter that matches the filter also triggers a certain event. However, in most cases, you don't want to trigger for each event, but only for the first data packet coming from an unknown source. So for example, you may want to say "allow traffic coming from source IP address in the range 10.0.0.0 to 10.0.255.225, and generate an event every time you see a new IP address". This can be done by specifying a filter, in particular a filter of type frwkIpFilter. This can be done. However, the frwkIpFilter also specifies other fields to filter on, like destination IP address and source- and destination port. I want to be able to say 'ignore the port field'. If I don't say that, the PEP will not only trigger an event for each new source IP address it encounters, but for each different port it encounters as well. So we are tempted to specify in the Access Pind PIB to say 'ignore every field that is a wildcard'. However, this is not entirely correct. For example, we may want to say allow any source IP address (don't filter on that, but do trigger on it), and allow any destination port (don't filter on that, and neither trigger on it). So we want to make a difference between: - Filter on it, and trigger on it - Don't filter on it, and trigger on it - Don't filter on it, and don't trigger on it (the fourth option, filter on it, but don't trigger on it is already dealt with, using an atttribute called eventHdlrEventScopeChangeFlag. The exact solution is out of scope of this e-mail). The last two options can be rephrased into my main question: Given a filter, can I distinguish between "ignore a field" and "don't ignore a field, but match every possible value"? For most filtering purposes, this seem to boil down to the same thing (i.e. wildcard that field). However, I hope I showed you that for the Access Bind PIB, these two things are not the same. I would be pleased if someone could at least answer this question for the frwkIpFilter class. A problem I encountered is that all the Framework PIB says about wildcards is: "Wildcards may be specified for those fields that are not relevant." However, it is not clear HOW such a wildcard should be specified (perhaps using the value 0?). The document does talk about wildcards for Roles, but that doesn't seem to apply to the filter classes in the PIB in chapter 5. Background: People not familiar with the Access Bind PIB, but familiar with the DiffServ model: just think of the Access Bind PIB as a PIB defining a Classifier, albeit a very rather complex one. The complexity comes from the fact that it can not only filter data traffic to decide what the next datapath (DiffServ) element is, but it can also communicate with the PDP in order to authenticate a data stream. Regards, Freek Dijkstra From owner-rap@ops.ietf.org Mon Aug 5 07:11:37 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07761 for ; Mon, 5 Aug 2002 07:11:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17bflO-000Me4-00 for rap-data@psg.com; Mon, 05 Aug 2002 04:11:02 -0700 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by psg.com with esmtp (Exim 3.36 #1) id 17bflG-000Md4-00 for rap@ops.ietf.org; Mon, 05 Aug 2002 04:10:54 -0700 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g75BAqZ18604 for ; Mon, 5 Aug 2002 07:10:52 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Aug 2002 13:10:51 +0200 Message-ID: From: "Wijnen, Bert (Bert)" To: "Rap-wg (E-mail)" Subject: RE: draft-ietf-rap-rsvp-authsession documents Date: Mon, 5 Aug 2002 13:10:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-rap@ops.ietf.org Precedence: bulk OK, w.r.t. documents: draft-ietf-rap-rsvp-authsession-03.txt draft-ietf-rap-session-auth-04.txt it seems that the list of security related issues that I posted over a week ago now are the most serious items to address. Here are 2 more issues to take into account when you re-edit the docs: - When you talk about: 5 UNICODE_DN X.500 Distinguished name as defined in RFC-2253 as a UNICODE string. we assume you mean a UTF-8 string? Might be good to make that clear. - The replay protection that was added to rsvp-auth depends on some clock synchronization (when there isn't a policy server). It would be good to specify that this requires that the system be using NTP or GPS. Thanks, Bert > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: vrijdag 26 juli 2002 22:59 > To: Rap-wg (E-mail) > Cc: Steve Bellovin (E-mail); Eric Rescorla (E-mail) > Subject: FW: draft-ietf-rap-rsvp-authsession documents > > > Authors/WG, > > The documents > draft-ietf-rap-rsvp-authsession-03.txt > draft-ietf-rap-session-auth-04.txt > were on the IESG agenda yesterday. > > I still have to collect some more feedback, so the below is > incomplete. > > But the security issues are the most serious concern, so here it is > for your response and corrections. I have added Steve Bellovin and > Eric Rescorla on the cc: list, so that when you respond, they can > also see the responses and react immediately/directly. Steve and Eric > (as you can see below) have worked on the comments together. > > Here we go: > > --- comment from Steve > > The new version is a lot better, and goes a long way towards > resolving > my objections. But I don't think it specifies the authentication > process clearly enough for people to implement from the spec. > I suspect > we can resolve this by email in the next couple of days. > > For shared secret and Kerberos, I *think* that the intent is > the key is > used only for an HMAC or similar algorithm such as a CBC-MAC. That > should be stated explicitly. It should also state that the expected > length of the authentication data is a preconfigured parameter, and > MUST match the data length in the message. (There's an attack if the > data length is taken from the message; details are left as an > exercise > for the reader.) > > Be more explicit about what HMAC-MD5-96 means -- I don't believe that > that string is defined in 2104. Why truncate to 96 bits? > It's secure > -- but it's done in IPsec because of boundary alignment > considerations. > > Anyway -- the text should say something like this: > > > If AUTH_ENT_ID is of types AUTH_ENT_ID IPV4_ADDR, IPV6_ADDR, > FQDN, ASCII_DN, UNICODE_DN or URI, the receiver should use > the identity to consult a table keyed by that identity. The > table should identify the cryptographic authentication algorithm > to be used and the expected length of the authentication data. > At a minimum, all implementations must support HMAC [RFC2104] > using the MD5 [RFC1321] hash algorithm with an output length of > 16 bytes. New algorithms may be added by the IETF standards > process. > > If AUTH_ENT_ID is of type KRB_PRINCIPAL, a similar algorithm > table is consulted. In this case, however, the key is taken > from the Kerberos ticket. At a minimum, all implementations > must support the same HMAC hash described above. > > Authentication is done as follows. The entire message is > constructed, excluding the length, type, and subtype fields > of the AUTH DATA field. Note that the message MUST include > either a START_TIME or a SESSION_ID (See Section 9), to prevent > replay attacks. The output of the authentication algorithm, > plus appropriate header information, is appended to the message. > > Verification is done by a similar process; however, the receiver > MUST verify that the indicated length of the authentication data > is consistent with the configured table entry. > > > Much more needs to be said about generating signatures to be verified > via an X.509 certificate. I'm not 100% certain which RFCs need to be > cited -- ekr or jis, can you fill in some details? -- but > they probably > include PKCS 1 and 7 (published as RFCs -- btw, there is an obsolete > RFC cited for PKIX). I frankly don't recall if the preferred hash > algorithm is in the X.509 certificate, though the public key > algorithm > used is implicit in the key type in the cert. Similar > concerns apply to > PGP_CERT, but I don't even know what to cite for it. > > --- here comes a response to the above from Eric > > I agree that this is unsatisfactory, on several fronts: > (1) It only appears to be possible to pass a single certificate. > What about certificate chains? > (2) It doesn't actually SAY that a signature is what is present > in the authentication data field, though I suppose we're supposed > to intuit that. > (3) It doesn't specify the digest algorithm. > > In answer to your questions: > (1) It's necessary to reference PKCS-1 [RFC 2437] since that describes > how to perform RSA signatures. (I'm assuming that they want to use > PKCS-1 rather than PSS or some other newfangled RSA padding > If DSS is to permitted they should also reference FIPS 186-2. > > (2) It's not necessary to reference PKCS-7 unless you're using > it as a certificate chain container. (See my comment about > chains above). > > (3) In general, X.509v3 certificates do not carry preferred digest > indicators. Either the digest name should be manually configured > or contained in the message. While it's technically possible > to discover what digest was used from the signature (it's in the > DigestInfo), generally APIs and hardware assume that you already > know. > > > Further more: > > (1) Section 4.1 talks about "shared private keys". This is confusing > since "private key" is generally used to refer to the private half of > an asymmetric key pair. I think this would be clearer if it talked > about "shared symmetric keys". > > (2) The Kerberos authentication mechanism doesn't appear to contain > authentication data but instead merely the principal name. The text > here suggests that the authentication is interactive: > > An authorizing entity is configured to construct the > AUTH_SESSION > policy element that designates use of the Kerberos authentication > method (KRB_PRINCIPAL). Upon reception of the RSVP request, the > router/PDP contacts the local KDC to request a ticket for the > authorizing entity (principal@realm). The router/PDP uses > the ticket > to access the authorizing entity and obtain authentication > data for > the message. > > That seems unusual. Wouldn't you want the authorizing entity to send a > ticket, thus avoiding a round trip? Is the problem that the > authorizing entity can't guess the principal name of the router/PDP? > If so, how does he know it's right when the router/PDP asks for > authorization? What are the contents of the "authentication data" that > the router/PDP obtains? This all seems quite hairy and underspecified. > > From owner-rap@ops.ietf.org Tue Aug 6 12:40:47 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17813 for ; Tue, 6 Aug 2002 12:40:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17c7Mq-000H31-00 for rap-data@psg.com; Tue, 06 Aug 2002 09:39:32 -0700 Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by psg.com with esmtp (Exim 3.36 #1) id 17c7Mh-000H2k-00 for rap@ops.ietf.org; Tue, 06 Aug 2002 09:39:23 -0700 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g76GdJo27860; Tue, 6 Aug 2002 12:39:19 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Aug 2002 12:39:20 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C04387C8E@zcard031.ca.nortel.com> From: "Louis-Nicolas Hamer" To: "Rap-wg (E-mail)" Cc: "'Wijnen, Bert (Bert)'" , "Steve Bellovin (E-mail)" , "Eric Rescorla (E-mail)" Subject: RE: draft-ietf-rap-rsvp-authsession documents Date: Tue, 6 Aug 2002 12:39:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23D67.CC439182" X-Spam-Status: No, hits=0.9 required=5.0 tests=MIME_NULL_BLOCK,MAILTO_LINK,MSG_ID_ADDED_BY_MTA_3 version=2.31 Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C23D67.CC439182 Content-Type: text/plain; charset="iso-8859-1" Bert, Steve, Eric, All, Sorry for the late response. I just came back from an overseas meeting and the other co-authors were on vacation. Please see my comments/questions below. Cheers, Louis-Nicolas > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Monday, August 05, 2002 7:11 AM > To: Rap-wg (E-mail) > Subject: RE: draft-ietf-rap-rsvp-authsession documents > > > OK, w.r.t. documents: > > draft-ietf-rap-rsvp-authsession-03.txt > draft-ietf-rap-session-auth-04.txt > > it seems that the list of security related issues > that I posted over a week ago now are the most serious > items to address. Here are 2 more issues to take into > account when you re-edit the docs: > > - When you talk about: > > 5 UNICODE_DN X.500 Distinguished name as defined > in RFC-2253 as a UNICODE string. > > we assume you mean a UTF-8 string? > Might be good to make that clear. YES - That's what RFC-2253 specifies...I can clarify this in the draft. > > - The replay protection that was added to rsvp-auth depends > on some clock synchronization (when there isn't a policy > server). It would be good to specify that this requires > that the system be using NTP or GPS. No problem. We specified NTP...I will make this clear also. > > > Thanks, > Bert > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: vrijdag 26 juli 2002 22:59 > > To: Rap-wg (E-mail) > > Cc: Steve Bellovin (E-mail); Eric Rescorla (E-mail) > > Subject: FW: draft-ietf-rap-rsvp-authsession documents > > > > > > Authors/WG, > > > > The documents > > draft-ietf-rap-rsvp-authsession-03.txt > > draft-ietf-rap-session-auth-04.txt > > were on the IESG agenda yesterday. > > > > I still have to collect some more feedback, so the below is > > incomplete. > > > > But the security issues are the most serious concern, so here it is > > for your response and corrections. I have added Steve Bellovin and > > Eric Rescorla on the cc: list, so that when you respond, they can > > also see the responses and react immediately/directly. > Steve and Eric > > (as you can see below) have worked on the comments together. > > > > Here we go: > > > > --- comment from Steve > > > > The new version is a lot better, and goes a long way towards > > resolving > > my objections. But I don't think it specifies the authentication > > process clearly enough for people to implement from the spec. > > I suspect > > we can resolve this by email in the next couple of days. I agree. Once we agree on the changes, I will provide an updated version. Hopefully, we can resolve all issues this week. > > > > For shared secret and Kerberos, I *think* that the intent is > > the key is > > used only for an HMAC or similar algorithm such as a CBC-MAC. That > > should be stated explicitly. It should also state that the > expected > > length of the authentication data is a preconfigured parameter, and > > MUST match the data length in the message. (There's an > attack if the > > data length is taken from the message; details are left as an > > exercise > > for the reader.) > > > > Be more explicit about what HMAC-MD5-96 means -- I don't > believe that > > that string is defined in 2104. Why truncate to 96 bits? I simply followed what was specified in the COPS RFC (rfc 2748 SECTION 2.2.16) to encourage re-use of what has been specified already. But, as you suggest in the text below, I am fine with 16 bytes. > > It's secure > > -- but it's done in IPsec because of boundary alignment > > considerations. > > > > Anyway -- the text should say something like this: > > > > > > If AUTH_ENT_ID is of types AUTH_ENT_ID IPV4_ADDR, IPV6_ADDR, > > FQDN, ASCII_DN, UNICODE_DN or URI, the receiver should use > > the identity to consult a table keyed by that identity. The > > table should identify the cryptographic authentication algorithm > > to be used and the expected length of the authentication data. > > At a minimum, all implementations must support HMAC [RFC2104] > > using the MD5 [RFC1321] hash algorithm with an output length of > > 16 bytes. New algorithms may be added by the IETF standards > > process. > > > > If AUTH_ENT_ID is of type KRB_PRINCIPAL, a similar algorithm > > table is consulted. In this case, however, the key is taken > > from the Kerberos ticket. At a minimum, all implementations > > must support the same HMAC hash described above. > > > > Authentication is done as follows. The entire message is > > constructed, excluding the length, type, and subtype fields > > of the AUTH DATA field. Note that the message MUST include > > either a START_TIME or a SESSION_ID (See Section 9), to prevent > > replay attacks. The output of the authentication algorithm, > > plus appropriate header information, is appended to the message. > > > > Verification is done by a similar process; however, the receiver > > MUST verify that the indicated length of the authentication data > > is consistent with the configured table entry. > > This text does clarify. I will input it your suggested text into the appropriate sections of the next revision. > > > > Much more needs to be said about generating signatures to > be verified > > via an X.509 certificate. I'm not 100% certain which RFCs > need to be > > cited -- ekr or jis, can you fill in some details? -- but > > they probably > > include PKCS 1 and 7 (published as RFCs -- btw, there is an > obsolete > > RFC cited for PKIX). I frankly don't recall if the preferred hash > > algorithm is in the X.509 certificate, though the public key > > algorithm > > used is implicit in the key type in the cert. Similar > > concerns apply to > > PGP_CERT, but I don't even know what to cite for it. PGP_CERT: Maybe Eric can help out here also? If not, I will dig deeper into this and provide the references and needed text. > > > > --- here comes a response to the above from Eric > > > > I agree that this is unsatisfactory, on several fronts: > > (1) It only appears to be possible to pass a single certificate. > > What about certificate chains? We should support certificate chains. We define it as follows: 8 X509_V3_CERT A chain of authorizing entity's X.509 V3 digital certificates. I can simply state this also in section 4.3 and reference the appropriate RFCs (see comment below). > > (2) It doesn't actually SAY that a signature is what is present > > in the authentication data field, though I suppose we're supposed > > to intuit that. I though this was sort of straightforward. I can add a sentence specifying that a signature is present. > > (3) It doesn't specify the digest algorithm. > > > > In answer to your questions: > > (1) It's necessary to reference PKCS-1 [RFC 2437] since > that describes > > how to perform RSA signatures. (I'm assuming that they want to use > > PKCS-1 rather than PSS or some other newfangled RSA padding > > If DSS is to permitted they should also reference FIPS 186-2. Will add a reference to RFC 2437. > > > > (2) It's not necessary to reference PKCS-7 unless you're using > > it as a certificate chain container. (See my comment about > > chains above). Yes, should be supported. Will add a reference to PKCS-7. > > > > (3) In general, X.509v3 certificates do not carry preferred digest > > indicators. Either the digest name should be manually configured > > or contained in the message. While it's technically possible > > to discover what digest was used from the signature (it's in the > > DigestInfo), generally APIs and hardware assume that you already > > know. We would prefer to have this contained in the message. How should I specify this? Should I simply state that the preferred digest name is contained in the certificate? What do other applications using X.509v3 certificates specify? > > > > > > Further more: > > > > (1) Section 4.1 talks about "shared private keys". This is confusing > > since "private key" is generally used to refer to the > private half of > > an asymmetric key pair. I think this would be clearer if it talked > > about "shared symmetric keys". Agreed. Will make the change. > > > > (2) The Kerberos authentication mechanism doesn't appear to contain > > authentication data but instead merely the principal name. The text > > here suggests that the authentication is interactive: > > > > An authorizing entity is configured to construct the > > AUTH_SESSION > > policy element that designates use of the Kerberos > authentication > > method (KRB_PRINCIPAL). Upon reception of the RSVP request, the > > router/PDP contacts the local KDC to request a ticket for the > > authorizing entity (principal@realm). The router/PDP uses > > the ticket > > to access the authorizing entity and obtain authentication > > data for > > the message. > > > > That seems unusual. Wouldn't you want the authorizing > entity to send a > > ticket, thus avoiding a round trip? Is the problem that the > > authorizing entity can't guess the principal name of the router/PDP? > > If so, how does he know it's right when the router/PDP asks for > > authorization? What are the contents of the "authentication > data" that > > the router/PDP obtains? This all seems quite hairy and > underspecified. This is explained in section 9: "If shared private keys are not a valid option, the Kerberos authentication mechanism is reasonably well secured and efficient in terms of AUTH_SESSION size. The AUTH_SESSION only needs to contain the principal@realm name of the authorizing entity. This is much more efficient than the PKI authentication option. " Does that answer your questions? Basically, since only the principal@realm name is needed the AUTH_SESSION is smaller in size (as compared to if it contained the kerberos ticket). > > > > > > ------_=_NextPart_001_01C23D67.CC439182 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-ietf-rap-rsvp-authsession documents

Bert, Steve, Eric, All,

Sorry for the late response. I just came back from an = overseas meeting and
the other co-authors were on vacation.
Please see my comments/questions below.

Cheers,
Louis-Nicolas

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=
> Sent: Monday, August 05, 2002 7:11 AM
> To: Rap-wg (E-mail)
> Subject: RE: draft-ietf-rap-rsvp-authsession = documents
>
>
> OK, w.r.t. documents:
>
>      = draft-ietf-rap-rsvp-authsession-03.txt
>      = draft-ietf-rap-session-auth-04.txt
>
> it seems that the list of security related = issues
> that I posted over a week ago now are the most = serious
> items to address. Here are 2 more issues to = take into
> account when you re-edit the docs:
>
> - When you talk about:
>
>       5  = UNICODE_DN   X.500 Distinguished name as defined
>          = ;            = ; in RFC-2253 as a UNICODE string.
>
>   we assume you mean a UTF-8 = string?
>   Might be good to make that = clear.

YES - That's what RFC-2253 specifies...I can clarify = this in the draft.

>
> - The replay protection that was added to = rsvp-auth depends
>   on some clock synchronization (when = there isn't a policy
>   server). It would be good to = specify that this requires
>   that the system be using NTP or = GPS.

No problem. We specified NTP...I will make this clear = also.

>
>
> Thanks,
> Bert
>
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=
> > Sent: vrijdag 26 juli 2002 22:59
> > To: Rap-wg (E-mail)
> > Cc: Steve Bellovin (E-mail); Eric Rescorla = (E-mail)
> > Subject: FW: = draft-ietf-rap-rsvp-authsession documents
> >
> >
> > Authors/WG,
> >
> > The documents
> >     = draft-ietf-rap-rsvp-authsession-03.txt
> >     = draft-ietf-rap-session-auth-04.txt
> > were on the IESG agenda yesterday.
> >
> > I still have to collect some more = feedback, so the below is
> > incomplete.
> >
> > But the security issues are the most = serious concern, so here it is
> > for your response and corrections. I have = added Steve Bellovin and
> > Eric Rescorla on the cc: list, so that = when you respond, they can
> > also see the responses and react = immediately/directly.
> Steve and Eric
> > (as you can see below) have worked on the = comments together.
> >
> > Here we go:
> >
> > --- comment from Steve
> >
> > The new version is a lot better, and goes = a long way towards
> > resolving
> > my objections.  But I don't think it = specifies the authentication
> > process clearly enough for people to = implement from the spec.
> >  I suspect
> > we can resolve this by email in the next = couple of days.

I agree. Once we agree on the changes, I will provide = an updated version. Hopefully,
we can resolve all issues this week.

> >
> > For shared secret and Kerberos, I *think* = that the intent is
> > the key is
> > used only for an HMAC or similar algorithm = such as a CBC-MAC.  That
> > should be stated explicitly.  It = should also state that the
> expected
> > length of the authentication data is a = preconfigured parameter, and
> > MUST match the data length in the = message.  (There's an
> attack if the
> > data length is taken from the message; = details are left as an
> > exercise
> > for the reader.) 
> >
> > Be more explicit about what HMAC-MD5-96 = means -- I don't
> believe that
> > that string is defined in 2104.  Why = truncate to 96 bits?

I simply followed what was specified in the COPS RFC = (rfc 2748 SECTION 2.2.16) to encourage
re-use of what has been specified already. But, as = you suggest in the text below,
I am fine with 16 bytes.
 
> > It's secure
> > -- but it's done in IPsec because of = boundary alignment
> > considerations.
> >
> > Anyway -- the text should say something = like this:
> >
> >
> >     If AUTH_ENT_ID is of = types AUTH_ENT_ID IPV4_ADDR, IPV6_ADDR,
> >     FQDN, ASCII_DN, = UNICODE_DN or URI, the receiver should use
> >     the identity to consult = a table keyed by that identity.  The
> >     table should identify = the cryptographic authentication algorithm
> >     to be used and the = expected length of the authentication data.
> >     At a minimum, all = implementations must support HMAC [RFC2104]
> >     using the MD5 [RFC1321] = hash algorithm with an output length of
> >     16 bytes.  New = algorithms may be added by the IETF standards
> >     process.
> >
> >     If AUTH_ENT_ID is of = type KRB_PRINCIPAL, a similar algorithm
> >     table is = consulted.  In this case, however, the key is taken
> >     from the Kerberos = ticket.  At a minimum, all implementations
> >     must support the same = HMAC hash described above.
> >
> >     Authentication is done = as follows.  The entire message is
> >     constructed, excluding = the length, type, and subtype fields
> >     of the AUTH DATA = field.  Note that the message MUST include
> >     either a START_TIME or = a SESSION_ID (See Section 9), to prevent
> >     replay attacks.  = The output of the authentication algorithm,
> >     plus appropriate header = information, is appended to the message.
> >
> >     Verification is done by = a similar process; however, the receiver
> >     MUST verify that the = indicated length of the authentication data
> >     is consistent with the = configured table entry.
> >

This text does clarify. I will input it your = suggested text into the appropriate sections of the next = revision.


> >
> > Much more needs to be said about = generating signatures to
> be verified
> > via an X.509 certificate.  I'm not = 100% certain which RFCs
> need to be
> > cited -- ekr or jis, can you fill in some = details? -- but
> > they probably
> > include PKCS 1 and 7 (published as RFCs -- = btw, there is an
> obsolete
> > RFC cited for PKIX).  I frankly don't = recall if the preferred hash
> > algorithm is in the X.509 certificate, = though the public key
> > algorithm
> > used is implicit in the key type in the = cert.  Similar
> > concerns apply to
> > PGP_CERT, but I don't even know what to = cite for it.
PGP_CERT: Maybe Eric can help out here also? If not, = I will dig deeper into
this and provide the references and needed = text.

> >
> > --- here comes a response to the above = from Eric
> >
> > I agree that this is unsatisfactory, on = several fronts:
> > (1) It only appears to be possible to pass = a single certificate.
> > What about certificate chains?

We should support certificate chains. We define it as = follows:
8  = X509_V3_CERT        A chain of = authorizing entity's X.509 V3 
          &nb= sp;           &nb= sp;      digital certificates.

I can simply state this also in section 4.3 and = reference
the appropriate RFCs (see comment below).

> > (2) It doesn't actually SAY that a = signature is what is present
> > in the authentication data field, though I = suppose we're supposed
> > to intuit that.
I though this was sort of straightforward. I can add = a sentence specifying that
a signature is present.

> > (3) It doesn't specify the digest = algorithm.
> >
> > In answer to your questions:
> > (1) It's necessary to reference PKCS-1 = [RFC 2437] since
> that describes
> > how to perform RSA signatures. (I'm = assuming that they want to use
> > PKCS-1 rather than PSS or some other = newfangled RSA padding
> > If DSS is to permitted they should also = reference FIPS 186-2.

Will add a reference to RFC 2437.

> >
> > (2) It's not necessary to reference PKCS-7 = unless you're using
> > it as a certificate chain container. (See = my comment about
> > chains above).

Yes, should be supported. Will add a reference to = PKCS-7.

> >
> > (3) In general, X.509v3 certificates do = not carry preferred digest
> > indicators. Either the digest name should = be manually configured
> > or contained in the message. While it's = technically possible
> > to discover what digest was used from the = signature (it's in the
> > DigestInfo), generally APIs and hardware = assume that you already
> > know.

We would prefer to have this contained in the = message. How should I specify this?
Should I simply state that the preferred digest name = is contained in the certificate?
What do other applications using X.509v3 = certificates specify?

> >
> >
> > Further more:
> >
> > (1) Section 4.1 talks about "shared = private keys". This is confusing
> > since "private key" is generally = used to refer to the
> private half of
> > an asymmetric key pair. I think this would = be clearer if it talked
> > about "shared symmetric = keys".

Agreed. Will make the change.

> >
> > (2) The Kerberos authentication mechanism = doesn't appear to contain
> > authentication data but instead merely the = principal name. The text
> > here suggests that the authentication is = interactive:
> >
> >       An = authorizing entity is configured to construct the
> > AUTH_SESSION
> >    policy element that = designates use of the Kerberos
> authentication
> >    method = (KRB_PRINCIPAL).  Upon reception of the RSVP request, the
> >    router/PDP contacts the = local KDC to request a ticket for the
> >    authorizing entity = (principal@realm). The router/PDP uses
> > the ticket
> >    to access the = authorizing entity and obtain authentication
> > data for
> >    the message.
> >
> > That seems unusual. Wouldn't you want the = authorizing
> entity to send a
> > ticket, thus avoiding a round trip? Is the = problem that the
> > authorizing entity can't guess the = principal name of the router/PDP?
> > If so, how does he know it's right when = the router/PDP asks for
> > authorization? What are the contents of = the "authentication
> data" that
> > the router/PDP obtains? This all seems = quite hairy and
> underspecified.

This is explained in section 9:
"If shared private keys are not a valid option, = the Kerberos
   authentication mechanism is reasonably = well secured and efficient in
   terms of AUTH_SESSION size. The = AUTH_SESSION only needs to contain
   the principal@realm name of the = authorizing entity. This is much
   more efficient than the PKI = authentication option. "
Does that answer your questions? Basically, since = only the principal@realm name is needed
the AUTH_SESSION is smaller in size (as compared to = if it contained the kerberos ticket).




> >
> >
>
>

------_=_NextPart_001_01C23D67.CC439182-- From owner-rap@ops.ietf.org Tue Aug 6 12:56:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18435 for ; Tue, 6 Aug 2002 12:56:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17c7ds-000HQP-00 for rap-data@psg.com; Tue, 06 Aug 2002 09:57:08 -0700 Received: from momus.sc.intel.com ([143.183.152.8]) by psg.com with esmtp (Exim 3.36 #1) id 17c7do-000HQE-00 for rap@ops.ietf.org; Tue, 06 Aug 2002 09:57:04 -0700 Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by momus.sc.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g76Gv1Z27598 for ; Tue, 6 Aug 2002 16:57:01 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002080609580630347 ; Tue, 06 Aug 2002 09:58:06 -0700 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id <3WZ2YXWM>; Tue, 6 Aug 2002 09:57:00 -0700 Message-ID: <10C8636AE359D4119118009027AE998719B46E7B@fmsmsx34.fm.intel.com> From: "Durham, David" To: "'Louis-Nicolas Hamer'" , "Rap-wg (E-mail)" Cc: "'Wijnen, Bert (Bert)'" , "Steve Bellovin (E-mail)" , "Eric Rescorla (E-mail)" Subject: RE: draft-ietf-rap-rsvp-authsession documents Date: Tue, 6 Aug 2002 09:56:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-rap@ops.ietf.org Precedence: bulk > -----Original Message----- > From: Louis-Nicolas Hamer [mailto:nhamer@nortelnetworks.com] > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: Monday, August 05, 2002 7:11 AM > > To: Rap-wg (E-mail) > > Subject: RE: draft-ietf-rap-rsvp-authsession documents > > > > > > Be more explicit about what HMAC-MD5-96 means -- I don't > > believe that > > > that string is defined in 2104. Why truncate to 96 bits? > > I simply followed what was specified in the COPS RFC (rfc 2748 SECTION 2.2.16) to encourage > re-use of what has been specified already. But, as you suggest in the text below, > I am fine with 16 bytes. [Dave] COPS RFC truncates the HMAC-MD5 because a full precision 16 byte HMAC opens the system up to attacks. It is recommended to truncate to some subset of the bits. See 2104 section 5. Note also that the HMAC-MD5-XX string convention is indeed introduced in RFC 2104 section 5! From owner-rap@ops.ietf.org Tue Aug 20 10:57:37 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16532 for ; Tue, 20 Aug 2002 10:57:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hAPW-000F4G-00 for rap-data@psg.com; Tue, 20 Aug 2002 07:55:10 -0700 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by psg.com with esmtp (Exim 3.36 #1) id 17hAPL-000F3P-00 for rap@ops.ietf.org; Tue, 20 Aug 2002 07:55:00 -0700 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g7KEsvc29195 for ; Tue, 20 Aug 2002 10:54:57 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Aug 2002 16:54:56 +0200 Message-ID: From: "Wijnen, Bert (Bert)" To: "Hahn, Scott" , "Mark Stevens (E-mail)" Cc: "Rap-wg (E-mail)" Subject: RE: Request to advance drafts Date: Tue, 20 Aug 2002 16:54:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-rap@ops.ietf.org Precedence: bulk RAP WG, I got this requestst from your WG chairs. > > I would like to submit the following draft to the IESG for > consideration as a Informational RFC: > http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-frwk-02.txt > My AD-evaluation comments (I understand that a lot of it is admin/bureaucratic, but you basically knew that and it is always best to avoid such comments at this late stage).: 1. Title and abstract contain Acronyms that RFC-Editor no longer want to see. You have to expand them. See: http://www.rfc-editor.org/policy.html 2. abstract should not have references. You have a [COPS] reference. I think you can just use RFC 2478 and leave the ref out. See: http://www.rfc-editor.org/policy.html 3. References need to be split in normative and informative references 4. You have text in "Conventions used in this document" on MUST language and such. That is good. Probably better to include it in the intro section (or at least after the abstract). But more important, you need to add [RFC-2119] reference to the references section 5. I think it would be good to do some sort of terminology at the beginning of the intro. Either explain terms like PDP, PEP, SIP, PRC (or at least extend the acronym first time it is used). Might also add a reference to the terminology as per RFC3198 6. You seem to be using (what we call) redmond-characters in a few places: 2nd para sect 2, sdt para sect 7, may be other places 7. Last sect of para 4.1. Could we add HOW a PDP may sollicit usage feedback/ 8. sect 7, 2nd para Can you ellaborate on what sort of "additional information must be provided to uniquely identify...." 9. Sect 8, can you explain what a "context switch" is? 10. Security consideration. - You must specify one mandatory to implement. you are now just saying "...protection can be accomplished". - When you specify the use of IPsec, pls do not just say "just use IPsec". A clearer statement is needed, specifying the necessary IPsec selectors (per RFC 2401) and the way the cryptographically protected endpoints are related to the authorization model, i.e., who can do what. > > the following draft to the IESG for consideration as a > standards track RFC: > http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-fr-pib-03.txt > > Both have completed WG last call. > The 2nd one I still need to review, will try to post later today or tomorrow. My main question is if we want to go through a similar process as we did for the earlier PIBs, or if the WG rather decides that this PIB can be also informational, just as the Framework PIB and the Diffserv PIB. Bert From owner-rap@ops.ietf.org Tue Aug 20 11:39:49 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17656 for ; Tue, 20 Aug 2002 11:39:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hB7i-000GH5-00 for rap-data@psg.com; Tue, 20 Aug 2002 08:40:50 -0700 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by psg.com with esmtp (Exim 3.36 #1) id 17hB7e-000GGs-00 for rap@ops.ietf.org; Tue, 20 Aug 2002 08:40:46 -0700 Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.wcom.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H150094EFGHGY@firewall.wcom.com> for rap@ops.ietf.org; Tue, 20 Aug 2002 15:38:42 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H1500B01FGHRI@dgismtp02.wcomnet.com>; Tue, 20 Aug 2002 15:38:41 +0000 (GMT) Received: from dgmexch08.wcomnet.com ([166.38.58.238]) by dgismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H1500ALSFGH22@dgismtp02.wcomnet.com>; Tue, 20 Aug 2002 15:38:41 +0000 (GMT) Received: by DGMEXCH08.wcomnet.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Aug 2002 15:38:41 +0000 Content-return: allowed Date: Tue, 20 Aug 2002 15:38:37 +0000 From: "Rawlins, Diana" Subject: RE: Request to advance drafts To: "'Wijnen, Bert (Bert)'" , "Hahn, Scott" , "Mark Stevens (E-mail)" Cc: "Rap-wg (E-mail)" Message-id: <6EFD2D8565069542A1029F2D17B546250FD004@ripexch001.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; CHARSET=us-ascii X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-rap@ops.ietf.org Precedence: bulk I will work with the other authors to address the below comments and with the WG chair on that last question. Thank you for the feedback! -Diana -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Tuesday, August 20, 2002 9:55 AM To: Hahn, Scott; Mark Stevens (E-mail) Cc: Rap-wg (E-mail) Subject: RE: Request to advance drafts RAP WG, I got this requestst from your WG chairs. > > I would like to submit the following draft to the IESG for > consideration as a Informational RFC: > http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-frwk-02.txt > My AD-evaluation comments (I understand that a lot of it is admin/bureaucratic, but you basically knew that and it is always best to avoid such comments at this late stage).: 1. Title and abstract contain Acronyms that RFC-Editor no longer want to see. You have to expand them. See: http://www.rfc-editor.org/policy.html 2. abstract should not have references. You have a [COPS] reference. I think you can just use RFC 2478 and leave the ref out. See: http://www.rfc-editor.org/policy.html 3. References need to be split in normative and informative references 4. You have text in "Conventions used in this document" on MUST language and such. That is good. Probably better to include it in the intro section (or at least after the abstract). But more important, you need to add [RFC-2119] reference to the references section 5. I think it would be good to do some sort of terminology at the beginning of the intro. Either explain terms like PDP, PEP, SIP, PRC (or at least extend the acronym first time it is used). Might also add a reference to the terminology as per RFC3198 6. You seem to be using (what we call) redmond-characters in a few places: 2nd para sect 2, sdt para sect 7, may be other places 7. Last sect of para 4.1. Could we add HOW a PDP may sollicit usage feedback/ 8. sect 7, 2nd para Can you ellaborate on what sort of "additional information must be provided to uniquely identify...." 9. Sect 8, can you explain what a "context switch" is? 10. Security consideration. - You must specify one mandatory to implement. you are now just saying "...protection can be accomplished". - When you specify the use of IPsec, pls do not just say "just use IPsec". A clearer statement is needed, specifying the necessary IPsec selectors (per RFC 2401) and the way the cryptographically protected endpoints are related to the authorization model, i.e., who can do what. > > the following draft to the IESG for consideration as a > standards track RFC: > http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-fr-pib-03.txt > > Both have completed WG last call. > The 2nd one I still need to review, will try to post later today or tomorrow. My main question is if we want to go through a similar process as we did for the earlier PIBs, or if the WG rather decides that this PIB can be also informational, just as the Framework PIB and the Diffserv PIB. Bert From owner-rap@ops.ietf.org Fri Aug 23 16:02:49 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16245 for ; Fri, 23 Aug 2002 16:02:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17iKcW-000Hmz-00 for rap-data@psg.com; Fri, 23 Aug 2002 13:01:24 -0700 Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by psg.com with esmtp (Exim 3.36 #1) id 17iKcQ-000Hmh-00 for rap@ops.ietf.org; Fri, 23 Aug 2002 13:01:18 -0700 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7NK1Cr07352; Fri, 23 Aug 2002 16:01:12 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RPMD2T02; Fri, 23 Aug 2002 16:01:14 -0400 Received: from tweedy.NortelNetworks.com (tweedy.engeast.baynetworks.com [192.32.135.157]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NSA9LVW5; Fri, 23 Aug 2002 16:01:12 -0400 Message-Id: <5.0.0.25.0.20020823154819.02b60a10@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 23 Aug 2002 15:59:24 -0400 To: rap@ops.ietf.org, iana@icann.org From: Kwok Ho Chan Subject: IANA's COPS Parameter Page Cc: bwijnen@lucent.com, Kwok Ho Chan Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-rap@ops.ietf.org Precedence: bulk RAP Participants, PIB Creators, IANA Administrator: While reviewing the IANA assigned numbers for Framework and DiffServ PIBs, I have notice some improvement that can be make to http://www.iana.org/assignments/cops-parameters Notice for Client Types there are only 3 columns: {Value, Description, Reference} I propose to change it to: {Value, Name, Description, Reference} where 'Name' is defined by the MODULE-IDENTITY clause contained in the PIB identified by 'Reference'. As it is done in: http://www.iana.org/assignments/smi-numbers I think this helps organize and promote the use of the well defined PIB Module 'Name' referencing in future PIBs. Please provide any comments to myself and the RAP WG list. Thank you! -- Kwok Ho Chan -- From owner-rap@ops.ietf.org Fri Aug 23 16:26:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16779 for ; Fri, 23 Aug 2002 16:26:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17iL1Y-000IcM-00 for rap-data@psg.com; Fri, 23 Aug 2002 13:27:16 -0700 Received: from [192.11.222.161] (helo=ihemail1.firewall.lucent.com) by psg.com with esmtp (Exim 3.36 #1) id 17iL1P-000Ic1-00 for rap@ops.ietf.org; Fri, 23 Aug 2002 13:27:07 -0700 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g7NKR5Y00785 for ; Fri, 23 Aug 2002 16:27:06 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Aug 2002 22:27:04 +0200 Message-ID: From: "Wijnen, Bert (Bert)" To: Kwok Ho Chan , rap@ops.ietf.org, iana@icann.org Cc: bwijnen@lucent.com Subject: RE: IANA's COPS Parameter Page Date: Fri, 23 Aug 2002 22:27:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-rap@ops.ietf.org Precedence: bulk > RAP Participants, PIB Creators, IANA Administrator: > > While reviewing the IANA assigned numbers for Framework and > DiffServ PIBs, I have notice some improvement that can be make > to http://www.iana.org/assignments/cops-parameters > > Notice for Client Types there are only 3 columns: > {Value, Description, Reference} > > I propose to change it to: > {Value, Name, Description, Reference} > where 'Name' is defined by the MODULE-IDENTITY clause contained > in the PIB identified by 'Reference'. > Well, did you see that for the DIFFSERV_PIB we already added the PIB name in the Description column? And if you check it out, then what name would go in the Name column for current values 0x01 and the onse form IP Highway? They are not PIB related are they? But we could leave them blank in such cases. I am OK with it... Bert From owner-rap@ops.ietf.org Fri Aug 23 16:42:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17011 for ; Fri, 23 Aug 2002 16:42:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17iLHc-000J7Q-00 for rap-data@psg.com; Fri, 23 Aug 2002 13:43:52 -0700 Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by psg.com with esmtp (Exim 3.36 #1) id 17iLHZ-000J71-00 for rap@ops.ietf.org; Fri, 23 Aug 2002 13:43:49 -0700 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7NKhfr09686; Fri, 23 Aug 2002 16:43:41 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RPMD24JJ; Fri, 23 Aug 2002 16:43:44 -0400 Received: from tweedy.NortelNetworks.com (tweedy.engeast.baynetworks.com [192.32.135.157]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NSA9LVZK; Fri, 23 Aug 2002 16:43:42 -0400 Message-Id: <5.0.0.25.0.20020823163010.02ac4970@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 23 Aug 2002 16:41:53 -0400 To: "Wijnen, Bert (Bert)" From: Kwok Ho Chan Subject: RE: IANA's COPS Parameter Page Cc: "Kwok-Ho Chan" , rap@ops.ietf.org, iana@icann.org, bwijnen@lucent.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-rap@ops.ietf.org Precedence: bulk Bert, all: Please see response embedded below. Thanks! -- Kwok -- At 10:27 PM 8/23/02 +0200, Wijnen, Bert (Bert) wrote: > > RAP Participants, PIB Creators, IANA Administrator: > > > > While reviewing the IANA assigned numbers for Framework and > > DiffServ PIBs, I have notice some improvement that can be make > > to http://www.iana.org/assignments/cops-parameters > > > > Notice for Client Types there are only 3 columns: > > {Value, Description, Reference} > > > > I propose to change it to: > > {Value, Name, Description, Reference} > > where 'Name' is defined by the MODULE-IDENTITY clause contained > > in the PIB identified by 'Reference'. > > >Well, did you see that for the DIFFSERV_PIB we already added >the PIB name in the Description column? Yes, the Description column is very helpful. For the proposed 'Name' column, for example, the Diffserv PIB row will use 'dsPolicyPib' (as defined by the MODULE-IDENTITY clause) as it was done for the Diffserv MIB using 'diffServMib'. >And if you check it out, then what name would go in the >Name column for current values 0x01 and the onse form IP Highway? >They are not PIB related are they? >But we could leave them blank in such cases. Agree. >I am OK with it... Thanks! > > >Bert From owner-rap@ops.ietf.org Fri Aug 23 17:42:43 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18311 for ; Fri, 23 Aug 2002 17:42:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17iMDZ-000KsE-00 for rap-data@psg.com; Fri, 23 Aug 2002 14:43:45 -0700 Received: from [192.11.222.161] (helo=ihemail1.firewall.lucent.com) by psg.com with esmtp (Exim 3.36 #1) id 17iMDU-000Krn-00 for rap@ops.ietf.org; Fri, 23 Aug 2002 14:43:40 -0700 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g7NLhcE20134 for ; Fri, 23 Aug 2002 17:43:38 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Aug 2002 23:43:37 +0200 Message-ID: From: "Wijnen, Bert (Bert)" To: Louis-Nicolas Hamer , "Kwok Chan (E-mail)" , "Rap-wg (E-mail)" Cc: "Stephen Hayes (E-mail)" , "Scott Bradner (E-mail)" , "Allison Mankin (E-mail)" , "Thomas Narten (E-mail)" , "Randy Bush (E-mail)" Subject: 3GPP Go-PIB Date: Fri, 23 Aug 2002 23:43:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.4 required=5.0 tests=DOUBLE_CAPSWORD,DEAR_SOMEBODY version=2.31 Sender: owner-rap@ops.ietf.org Precedence: bulk Louis/Kwok, I really do not have time to check the 3gpp GO PIB in all details. But I did a quick check of the version you did send to me on Aug 14th. - I have already reported that the REVISION clause is invalid syntax. It needs a timespamp according to SPPI (RFC3159) and any text needs to go in a DESCRIPTION clasue. - We did our very very best to get the framework and diffserv PIBs approved in the IETF, so that 3GPP could re-use. However in the 3gpp GO PIB I see: Go3gppIpFilterEntry ::= SEQUENCE { go3gppIpFilterAddrType InetAddressType, go3gppIpFilterDstAddr InetAddress, go3gppIpFilterDstPrefixLength InetAddressPrefixLength, go3gppIpFilterSrcAddr InetAddress, go3gppIpFilterSrcPrefixLength InetAddressPrefixLength, go3gppIpFilterProtocol Integer32, go3gppIpFilterDstL4PortMin InetPortNumber, go3gppIpFilterDstL4PortMax InetPortNumber, go3gppIpFilterSrcL4PortMin InetPortNumber, go3gppIpFilterSrcL4PortMax InetPortNumber } which is not exactly the same as the one in the framework PIB but comes VERY VERY close. This does not seem the correct approach to me. HHHre is the framework PIB version: FrwkIpFilterEntry ::= SEQUENCE { frwkIpFilterAddrType InetAddressType, frwkIpFilterDstAddr InetAddress, frwkIpFilterDstPrefixLength InetAddressPrefixLength, frwkIpFilterSrcAddr InetAddress, frwkIpFilterSrcPrefixLength InetAddressPrefixLength, frwkIpFilterDscp DscpOrAny, frwkIpFilterFlowId Unsigned32, frwkIpFilterProtocol Unsigned32, frwkIpFilterDstL4PortMin InetPortNumber, frwkIpFilterDstL4PortMax InetPortNumber, frwkIpFilterSrcL4PortMin InetPortNumber, frwkIpFilterSrcL4PortMax InetPortNumber } Can you explain/justify why you are not reusing the filters from the framework PIB. Let me also point out that your go3gppIpFilterProtocol (Integer32) is repeating the problem that we finally got fixed in the frwkIpFilterProtocol (Unsigned32) - I also think that your references to [INETADDR] in your PIB should be done with a REFERENCE clause, as they are done in the framework-pib. - I guess I could ask the same about the baseFilterTable, but then the one in your go3gppPib seems empty as far as I can tell. - your go3gppRprtGPRSChrgInfoEntry ::= SEQUENCE { go3gppRprtGPRSChrgInfoPrid InstanceId, go3gppRprtGPRSChrgInfoGGSNAddr InetAddress, go3gppRprtGPRSChrgInfoGCID OCTET STRING } is using an InetAddress type without an acompanying InetAddressType which is required as per the INET-ADDRESS-MIB from which you import the InetAddress TC. Without an associated InetAddressType, there is no way to know the format of the InetAddress attribute! - I am kind of surprised that your PIB seems to require far less GROUPs to be supported from the FRAMEWORK PIB as has been delcared MANDATORY in the framework PIB... I guess I will never understand... Note that I did not do a SYNTAX compile check. Hope this helps you improve, and hope that you either have a very good justifcation for not re-using the filtertable from framework PIB or other wise change your pib to actually do reuse that part of the framework PIB. Bert > -----Original Message----- > From: Louis-Nicolas Hamer [mailto:nhamer@nortelnetworks.com] > Sent: vrijdag 23 augustus 2002 22:29 > To: 'Wijnen, Bert (Bert)' > Cc: Stephen Hayes (E-mail) > Subject: RE: COPS Client-Type assignment 0x8009 (Namer) > > > Bert, > > Right. That is beyond my control...MCC is suppose to take > care of the assignements under the 3GPP entreprise branch... > no document exist on this matter for me to consult...they > should tell me if my proposition is OK or not. So I will ask > to delay approval of this document until the next meeting - > hopefully we can sort this all out. > > see below for more comments. > > cheers, > > > l-n > > Louis-Nicolas Hamer > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Friday, August 23, 2002 2:01 PM > To: Hamer, Louis-Nicolas [WDLN2:AN22:EXCH] > Cc: Stephen Hayes (E-mail) > Subject: RE: COPS Client-Type assignment 0x8009 (Namer) > > > You have: > ::= { 1.3.6.1.4.1.10415.1 } -go3gpp PIB branch under the > --3GPP > (10415) enterprise branch > I can hardly believe that there are no other assignment > sunder the 3GPP branch yet? > Why else would the branch have been requested quite a while > ago (we are now at > enterprise OID 14495 )... > It is all within 3GPP tree, so it is 3GPP control... and I > may be totally wrong... > But it feels as if it potentially re-uses some other assignment. > > Just to make sure you did the proper checks within 3GPP (or the with > the cisco guy who has his name attached to teh 3GPP tree branch). > By the way, a > REVISION "Use Version Number of 3GPP TS 29.207" > is syntactically incorrect also. It should be something like > REVISION "200205152200Z" > DESCRIPTION "Initial version as published in > 3GPP TS 29.207" > [[LNH]] 3GPP procedures require that you show changes to the > last official version of the specs. > The section you quote are from this last version...since > then, that section has been modified appropriatly...see > the pib I sent you the other day. > > I would strongly recommend that you get your final PIB syntax > checked by a tool like > the one Ravi at Intel uses. > Yes, we did run it thru the compiler. > Thanks, > Bert > -----Original Message----- > From: Louis-Nicolas Hamer [mailto:nhamer@NORTELNETWORKS.COM] > Sent: vrijdag 23 augustus 2002 18:50 > To: 3GPP_TSG_CN_WG3@LIST.ETSI.FR > Subject: FW: COPS Client-Type assignment 0x8009 (Namer) > > > All, > Please see below. IANA has assigned us a COPS Client-type. > Since the submission deadline was yesterday for this item, I > guess we will have to wait > for the next CN3 meeting to approve the CR (unless we can > make an exception in this case since > this is a very minor change - What is the > chairman's/delegates view on this?). > The proposed CR is attached to this email. > Cheers, > L-N > > > -----Original Message----- > From: IANA [mailto:iana@icann.org] > Sent: Thursday, August 22, 2002 1:43 PM > To: Hamer, Louis-Nicolas [WDLN2:AN22:EXCH] > Subject: COPS Client-Type assignment 0x8009 (Namer) > > > Dear Louis-Nicolas, > The IANA has assigned the following COPS Client-Type: > 0x8009 COPS usage for 3GPP GO interface [3GPP T.S. 29.207 > - Release 5] > [3GPP T.S. 29.207 - Release 5] > ftp://ftp.3gpp.org/specs/Specs/archive/29_series/29.207/ > If there is any updates to the reference (new version), please let > us know so we can correct the webpage. > Please see: > > Please let us know if you have any questions. > Thank you, > Michelle S. Cotton > IANA Administrator > *************************************************************** > Internet Assigned Numbers Authority (IANA) > 4676 Admiralty Way, Suite 330 > Marina del Rey, California 90292 > Voice: (310) 823-9358 > FAX: (310) 823-8649 > email: iana@iana.org > *************************************************************** > From owner-rap@ops.ietf.org Mon Aug 26 09:57:01 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08560 for ; Mon, 26 Aug 2002 09:57:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17jKJt-000NBx-00 for rap-data@psg.com; Mon, 26 Aug 2002 06:54:17 -0700 Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.ca.nortel.com) by psg.com with esmtp (Exim 3.36 #1) id 17jKJn-000NBk-00; Mon, 26 Aug 2002 06:54:11 -0700 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7QDs3D11030; Mon, 26 Aug 2002 09:54:03 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Aug 2002 09:54:05 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C04387DCB@zcard031.ca.nortel.com> From: "Louis-Nicolas Hamer" To: "'Wijnen, Bert (Bert)'" , "Kwok-Ho Chan" , "Rap-wg (E-mail)" Cc: "Stephen Hayes (E-mail)" , "Scott Bradner (E-mail)" , "Allison Mankin (E-mail)" , "Thomas Narten (E-mail)" , "Randy Bush (E-mail)" Subject: RE: 3GPP Go-PIB Date: Mon, 26 Aug 2002 09:53:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24D08.04ADEEA0" X-Spam-Status: No, hits=1.6 required=5.0 tests=MIME_NULL_BLOCK,DOUBLE_CAPSWORD,DEAR_SOMEBODY,WEIRD_PORT, MAILTO_LINK,MSG_ID_ADDED_BY_MTA_3 version=2.31 X-Spam-Level: * Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C24D08.04ADEEA0 Content-Type: text/plain; charset="iso-8859-1" Bert, The Go PIB is considered "functionaly frozen", but small corrections and improvements are still bound to show up. I will write the appropriate CRs to address your comments. Maybe in the future, sending you comments to the 3GPP CN3 mailing list would be helpfull. CN3 drives the Go PIB by consensus - I am just a participant - and thus cannot make changes without proper approval of the WG. Thanks. please see below. > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Friday, August 23, 2002 5:44 PM > To: Hamer, Louis-Nicolas [WDLN2:AN22:EXCH]; Chan, Kwok-Ho > [BL60:470:EXCH]; Rap-wg (E-mail) > Cc: Stephen Hayes (E-mail); Scott Bradner (E-mail); Allison Mankin > (E-mail); Thomas Narten (E-mail); Randy Bush (E-mail) > Subject: 3GPP Go-PIB > > > Louis/Kwok, > > I really do not have time to check the 3gpp GO PIB in all > details. But I did a quick check of the version you did send > to me on Aug 14th. > > - I have already reported that the REVISION clause is > invalid syntax. It needs a timespamp according to SPPI > (RFC3159) and any text needs to go in a DESCRIPTION clasue. Yes, thanks...will update this. > > - We did our very very best to get the framework and diffserv > PIBs approved in the IETF, so that 3GPP could re-use. > > However in the 3gpp GO PIB I see: > > Go3gppIpFilterEntry ::= SEQUENCE { > go3gppIpFilterAddrType InetAddressType, > go3gppIpFilterDstAddr InetAddress, > go3gppIpFilterDstPrefixLength InetAddressPrefixLength, > go3gppIpFilterSrcAddr InetAddress, > go3gppIpFilterSrcPrefixLength InetAddressPrefixLength, > go3gppIpFilterProtocol Integer32, > go3gppIpFilterDstL4PortMin InetPortNumber, > go3gppIpFilterDstL4PortMax InetPortNumber, > go3gppIpFilterSrcL4PortMin InetPortNumber, > go3gppIpFilterSrcL4PortMax InetPortNumber > } > > which is not exactly the same as the one in the framework PIB > but comes VERY VERY close. This does not seem the correct > approach to me. HHHre is the framework PIB version: > > > FrwkIpFilterEntry ::= SEQUENCE { > frwkIpFilterAddrType InetAddressType, > frwkIpFilterDstAddr InetAddress, > frwkIpFilterDstPrefixLength InetAddressPrefixLength, > frwkIpFilterSrcAddr InetAddress, > frwkIpFilterSrcPrefixLength InetAddressPrefixLength, > frwkIpFilterDscp DscpOrAny, > frwkIpFilterFlowId Unsigned32, > frwkIpFilterProtocol Unsigned32, > frwkIpFilterDstL4PortMin InetPortNumber, > frwkIpFilterDstL4PortMax InetPortNumber, > frwkIpFilterSrcL4PortMin InetPortNumber, > frwkIpFilterSrcL4PortMax InetPortNumber > } > > Can you explain/justify why you are not reusing the filters from > the framework PIB. We, Nortel, tried very hard to reuse the filters from the framework PIB, but other companies objected to this. So I guess you should ask them to justify themsleves. Remember, 3GPP works by consensus between all attending companies. > > Let me also point out that your go3gppIpFilterProtocol (Integer32) > is repeating the problem that we finally got fixed in the > frwkIpFilterProtocol (Unsigned32) > > - I also think that your references to [INETADDR] in your PIB > should be done with a REFERENCE clause, as they are done in > the framework-pib. Will do. > > - I guess I could ask the same about the baseFilterTable, but then > the one in your go3gppPib seems empty as far as I can tell. Same as other comment - we wanted to import, others did not...I will let them explain why. It might be more than usefull if you clearly stated this on the CN3 mailing list. Maybe you could help us convince others. > > - your > go3gppRprtGPRSChrgInfoEntry ::= SEQUENCE { > go3gppRprtGPRSChrgInfoPrid InstanceId, > go3gppRprtGPRSChrgInfoGGSNAddr InetAddress, > go3gppRprtGPRSChrgInfoGCID OCTET STRING } > > is using an InetAddress type without an acompanying InetAddressType > which is required as per the INET-ADDRESS-MIB from which you import > the InetAddress TC. Without an associated InetAddressType, there > is no way to know the format of the InetAddress attribute! Good catch...will correct. The Go PIB is considered functionaly frozen, but small corrections and improvements are still bound to show up. I will write the appropriate CR. > > - I am kind of surprised that your PIB seems to require far less > GROUPs to be supported from the FRAMEWORK PIB as has been > delcared MANDATORY in the framework PIB... I guess I will > never understand... > > Note that I did not do a SYNTAX compile check. > > Hope this helps you improve, and hope that you either have a very > good justifcation for not re-using the filtertable from > framework PIB or other wise change your pib to actually do > reuse that part of the framework PIB. Again, sorry I can't help. Please consult prior contributions...you will clealy see we advocated this while others did not. > > Bert > > > -----Original Message----- > > From: Louis-Nicolas Hamer [mailto:nhamer@nortelnetworks.com] > > Sent: vrijdag 23 augustus 2002 22:29 > > To: 'Wijnen, Bert (Bert)' > > Cc: Stephen Hayes (E-mail) > > Subject: RE: COPS Client-Type assignment 0x8009 (Namer) > > > > > > Bert, > > > > Right. That is beyond my control...MCC is suppose to take > > care of the assignements under the 3GPP entreprise branch... > > no document exist on this matter for me to consult...they > > should tell me if my proposition is OK or not. So I will ask > > to delay approval of this document until the next meeting - > > hopefully we can sort this all out. > > > > see below for more comments. > > > > cheers, > > > > > > l-n > > > > Louis-Nicolas Hamer > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: Friday, August 23, 2002 2:01 PM > > To: Hamer, Louis-Nicolas [WDLN2:AN22:EXCH] > > Cc: Stephen Hayes (E-mail) > > Subject: RE: COPS Client-Type assignment 0x8009 (Namer) > > > > > > You have: > > ::= { 1.3.6.1.4.1.10415.1 } -go3gpp PIB branch under the > > --3GPP > > (10415) enterprise branch > > I can hardly believe that there are no other assignment > > sunder the 3GPP branch yet? > > Why else would the branch have been requested quite a while > > ago (we are now at > > enterprise OID 14495 )... > > It is all within 3GPP tree, so it is 3GPP control... and I > > may be totally wrong... > > But it feels as if it potentially re-uses some other assignment. > > > > Just to make sure you did the proper checks within 3GPP > (or the with > > the cisco guy who has his name attached to teh 3GPP tree branch). > > By the way, a > > REVISION "Use Version Number of 3GPP TS 29.207" > > is syntactically incorrect also. It should be something like > > REVISION "200205152200Z" > > DESCRIPTION "Initial version as published in > > 3GPP TS 29.207" > > [[LNH]] 3GPP procedures require that you show changes to the > > last official version of the specs. > > The section you quote are from this last version...since > > then, that section has been modified appropriatly...see > > the pib I sent you the other day. > > > > I would strongly recommend that you get your final PIB syntax > > checked by a tool like > > the one Ravi at Intel uses. > > Yes, we did run it thru the compiler. > > Thanks, > > Bert > > -----Original Message----- > > From: Louis-Nicolas Hamer [mailto:nhamer@NORTELNETWORKS.COM] > > Sent: vrijdag 23 augustus 2002 18:50 > > To: 3GPP_TSG_CN_WG3@LIST.ETSI.FR > > Subject: FW: COPS Client-Type assignment 0x8009 (Namer) > > > > > > All, > > Please see below. IANA has assigned us a COPS Client-type. > > Since the submission deadline was yesterday for this item, I > > guess we will have to wait > > for the next CN3 meeting to approve the CR (unless we can > > make an exception in this case since > > this is a very minor change - What is the > > chairman's/delegates view on this?). > > The proposed CR is attached to this email. > > Cheers, > > L-N > > > > > > -----Original Message----- > > From: IANA [mailto:iana@icann.org] > > Sent: Thursday, August 22, 2002 1:43 PM > > To: Hamer, Louis-Nicolas [WDLN2:AN22:EXCH] > > Subject: COPS Client-Type assignment 0x8009 (Namer) > > > > > > Dear Louis-Nicolas, > > The IANA has assigned the following COPS Client-Type: > > 0x8009 COPS usage for 3GPP GO interface [3GPP T.S. 29.207 > > - Release 5] > > [3GPP T.S. 29.207 - Release 5] > > ftp://ftp.3gpp.org/specs/Specs/archive/29_series/29.207/ > > If there is any updates to the reference (new version), please let > > us know so we can correct the webpage. > > Please see: > > > > Please let us know if you have any questions. > > Thank you, > > Michelle S. Cotton > > IANA Administrator > > *************************************************************** > > Internet Assigned Numbers Authority (IANA) > > 4676 Admiralty Way, Suite 330 > > Marina del Rey, California 90292 > > Voice: (310) 823-9358 > > FAX: (310) 823-8649 > > email: iana@iana.org > > *************************************************************** > > > ------_=_NextPart_001_01C24D08.04ADEEA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: 3GPP Go-PIB

Bert,

The Go PIB is considered "functionaly = frozen", but small corrections
and improvements are still bound to show up. I will = write the appropriate CRs to address your comments.

Maybe in the future, sending you comments to the 3GPP = CN3 mailing list would be helpfull. CN3 drives the
Go PIB by consensus - I am just a participant - and = thus cannot make changes without proper approval of the WG.

Thanks.

please see below.

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=
> Sent: Friday, August 23, 2002 5:44 PM
> To: Hamer, Louis-Nicolas [WDLN2:AN22:EXCH]; = Chan, Kwok-Ho
> [BL60:470:EXCH]; Rap-wg (E-mail)
> Cc: Stephen Hayes (E-mail); Scott Bradner = (E-mail); Allison Mankin
> (E-mail); Thomas Narten (E-mail); Randy Bush = (E-mail)
> Subject: 3GPP Go-PIB
>
>
> Louis/Kwok,
>
> I really do not have time to check the 3gpp GO = PIB in all
> details. But I did a quick check of the version = you did send
> to me on Aug 14th.
>
> - I have already reported that the REVISION = clause is
>   invalid syntax. It needs a = timespamp according to SPPI
>   (RFC3159) and any text needs to go = in a DESCRIPTION clasue.
Yes, thanks...will update this.

>
> - We did our very very best to get the = framework and diffserv
>   PIBs approved in the IETF, so that = 3GPP could re-use.
>  
>   However in the 3gpp GO PIB I = see:
>
>   Go3gppIpFilterEntry ::=3D SEQUENCE = {
>          = ;  = go3gppIpFilterAddrType         = InetAddressType,
>          = ;  = go3gppIpFilterDstAddr        &nb= sp; InetAddress, 
>          = ;  go3gppIpFilterDstPrefixLength  InetAddressPrefixLength, =
>          = ;  = go3gppIpFilterSrcAddr        &nb= sp; InetAddress, 
>          = ;  go3gppIpFilterSrcPrefixLength  InetAddressPrefixLength, =
>          = ;  = go3gppIpFilterProtocol         = Integer32,
>          = ;  go3gppIpFilterDstL4PortMin     = InetPortNumber,
>          = ;  go3gppIpFilterDstL4PortMax     = InetPortNumber,
>          = ;  go3gppIpFilterSrcL4PortMin     = InetPortNumber,
>          = ;  go3gppIpFilterSrcL4PortMax     = InetPortNumber
>    }
>
>    which is not exactly the same = as the one in the framework PIB
>    but comes VERY VERY close. = This does not seem the correct
>    approach to me. HHHre is the = framework PIB version:
>
>
>    FrwkIpFilterEntry ::=3D = SEQUENCE {
>          = ;  = frwkIpFilterAddrType         = InetAddressType,
>          = ;  = frwkIpFilterDstAddr         = ; InetAddress, 
>          = ;  frwkIpFilterDstPrefixLength  InetAddressPrefixLength, =
>          = ;  = frwkIpFilterSrcAddr         = ; InetAddress, 
>          = ;  frwkIpFilterSrcPrefixLength  InetAddressPrefixLength, =
>          = ;  = frwkIpFilterDscp         &n= bsp;   DscpOrAny,
>          = ;  = frwkIpFilterFlowId         =   Unsigned32,
>          = ;  = frwkIpFilterProtocol         = Unsigned32,
>          = ;  frwkIpFilterDstL4PortMin     = InetPortNumber,
>          = ;  frwkIpFilterDstL4PortMax     = InetPortNumber,
>          = ;  frwkIpFilterSrcL4PortMin     = InetPortNumber,
>          = ;  frwkIpFilterSrcL4PortMax     InetPortNumber =
>    }
>    
>    Can you explain/justify why = you are not reusing the filters from
>    the framework PIB.
We, Nortel, tried very hard to reuse the filters = from the framework PIB, but other companies objected
to this. So I guess you should ask them to justify = themsleves. Remember, 3GPP works by consensus between
all attending companies.


>
>    Let me also point out that = your go3gppIpFilterProtocol (Integer32)
>    is repeating the problem that = we finally got fixed in the
>    frwkIpFilterProtocol = (Unsigned32)
>
> - I also think that your references to = [INETADDR] in your PIB
>   should be done with a REFERENCE = clause, as they are done in
>   the framework-pib.
Will do.

>
> - I guess I could ask the same about the = baseFilterTable, but then
>   the one in your go3gppPib seems = empty as far as I can tell.
Same as other comment - we wanted to import, others = did not...I will let them explain why.
It might be more than usefull if you clearly stated = this on the CN3 mailing list. Maybe you could
help us convince others.

>
> - your
>     = go3gppRprtGPRSChrgInfoEntry ::=3D SEQUENCE {
>          = ;  go3gppRprtGPRSChrgInfoPrid       = InstanceId,
>          = ;  go3gppRprtGPRSChrgInfoGGSNAddr   InetAddress,
>          = ;  go3gppRprtGPRSChrgInfoGCID       = OCTET STRING }  
>
>   is using an InetAddress type = without an acompanying InetAddressType
>   which is required as per the = INET-ADDRESS-MIB from which you import
>   the InetAddress TC. Without an = associated InetAddressType, there
>   is no way to know the format of the = InetAddress attribute!
Good catch...will correct. The Go PIB is considered = functionaly frozen, but small corrections
and improvements are still bound to show up. I will = write the appropriate CR.

>
> - I am kind of surprised that your PIB seems to = require far less
>   GROUPs to be supported from the = FRAMEWORK PIB as has been
>   delcared MANDATORY in the framework = PIB... I guess I will
>   never understand...
>
> Note that I did not do a SYNTAX compile = check.
>
> Hope this helps you improve, and hope that you = either have a very
> good justifcation for not re-using the = filtertable from
> framework PIB or other wise change your pib to = actually do
> reuse that part of the framework PIB.
Again, sorry I can't help. Please consult prior = contributions...you will clealy see we advocated this while others did = not.

>
> Bert
>
> > -----Original Message-----
> > From: Louis-Nicolas Hamer [mailto:nhamer@nortelnetworks.c= om]
> > Sent: vrijdag 23 augustus 2002 = 22:29
> > To: 'Wijnen, Bert (Bert)'
> > Cc: Stephen Hayes (E-mail)
> > Subject: RE: COPS Client-Type assignment = 0x8009 (Namer)
> >
> >
> > Bert,
> > 
> > Right. That is beyond my control...MCC is = suppose to take
> > care of the assignements under the 3GPP = entreprise branch...
> > no document exist on this matter for me to = consult...they
> > should tell me if my proposition is OK or = not. So I will ask
> > to delay approval of this document until = the next meeting -
> > hopefully we can sort this all out.
> > 
> > see below for more comments.
> > 
> > cheers,
> > 
> > 
> > l-n
> >
> > Louis-Nicolas Hamer
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=
> > Sent: Friday, August 23, 2002 2:01 = PM
> > To: Hamer, Louis-Nicolas = [WDLN2:AN22:EXCH]
> > Cc: Stephen Hayes (E-mail)
> > Subject: RE: COPS Client-Type assignment = 0x8009 (Namer)
> >
> >
> >  You have:
> >      ::=3D { = 1.3.6.1.4.1.10415.1 } -go3gpp PIB branch under the  
> = >           &n= bsp;           &n= bsp;           &n= bsp;           &n= bsp;   --3GPP
> > (10415) enterprise branch
> > I can hardly believe that there are no = other assignment
> > sunder the 3GPP branch yet?
> > Why else would the branch have been = requested quite a while
> > ago (we are now at
> >  enterprise OID 14495 )...
> > It is all within 3GPP tree, so it is 3GPP = control... and I
> > may be totally wrong...
> > But it feels as if it potentially re-uses = some other assignment.
> > 
> > Just to make sure you did the  proper = checks within 3GPP
> (or the with
> > the cisco guy who has his name attached to = teh 3GPP tree branch).
> > By the way, a
> = >            = REVISION "Use Version Number of 3GPP TS 29.207"
> > is syntactically incorrect also. It should = be something like
> = >            = REVISION "200205152200Z"
> = >            = DESCRIPTION    "Initial version as published = in 
> > 3GPP TS 29.207"
> > [[LNH]] 3GPP procedures require that you = show changes to the
> > last official version of the specs.
> > The section you quote are from this last = version...since
> > then, that section has been modified approp= riatly...see
> > the pib I sent you the other day.
> > 
> > I would strongly recommend that you get = your final PIB syntax
> > checked by a tool like
> > the one Ravi at Intel uses.
> > Yes, we did run it thru the = compiler.
> > Thanks,
> > Bert
> > -----Original Message-----
> > From: Louis-Nicolas Hamer [mailto:nhamer@NORTELNETWORKS.C= OM]
> > Sent: vrijdag 23 augustus 2002 = 18:50
> > To: 3GPP_TSG_CN_WG3@LIST.ETSI.FR
> > Subject: FW: COPS Client-Type assignment = 0x8009 (Namer)
> >
> >
> > All,
> > Please see below. IANA has assigned us a = COPS Client-type.
> > Since the submission deadline was = yesterday for this item, I
> > guess we will have to wait
> > for the next CN3 meeting to approve the CR = (unless we can
> > make an exception in this case since =
> > this is a very minor change - What is the =
> > chairman's/delegates view on this?). =
> > The proposed CR is attached to this email. =
> > Cheers,
> > L-N
> >
> >
> > -----Original Message-----
> > From: IANA [mailto:iana@icann.org]
> > Sent: Thursday, August 22, 2002 1:43 PM =
> > To: Hamer, Louis-Nicolas [WDLN2:AN22:EXCH] =
> > Subject: COPS Client-Type assignment = 0x8009 (Namer)
> >
> >
> > Dear Louis-Nicolas,
> > The IANA has assigned the following COPS = Client-Type:
> > 0x8009  COPS usage for 3GPP GO = interface   [3GPP T.S. 29.207
> > - Release 5]
> > [3GPP T.S. 29.207 - Release 5]  =
> = >            = ftp://ftp.3gpp.org/specs/Specs/archive/29_series/29.20= 7/
> > If there is any updates to the reference = (new version), please let
> > us know so we can correct the webpage. =
> > Please see:
> > <http://www.iana.org/assignments/cops-parameters>= ;
> > Please let us know if you have any = questions.
> > Thank you,
> > Michelle S. Cotton
> > IANA Administrator
> > = ***************************************************************
> > Internet Assigned Numbers Authority (IANA) =
> > 4676 Admiralty Way, Suite 330
> > Marina del Rey, California 90292
> > Voice: (310) 823-9358
> > FAX:   (310) 823-8649
> > email: iana@iana.org
> > = ***************************************************************
> >
>

------_=_NextPart_001_01C24D08.04ADEEA0-- From owner-rap@ops.ietf.org Tue Aug 27 17:45:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13787 for ; Tue, 27 Aug 2002 17:45:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17jo9N-000If1-00 for rap-data@psg.com; Tue, 27 Aug 2002 14:45:25 -0700 Received: from dhcp64-134-81-89.hat.dca.wayport.net ([64.134.81.89] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17jo9K-000Ieq-00 for rap@ops.ietf.org; Tue, 27 Aug 2002 14:45:22 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17jo9K-00038r-00 for rap@ops.ietf.org; Tue, 27 Aug 2002 14:45:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200208271844.OAA06546@ietf.org> From: Phil Roberts To: IETF WG Participants: ; Subject: Nomcom call for volunteers Date: Tue, 27 Aug 2002 14:44:44 -0400 X-Spam-Status: No, hits=1.1 required=5.0 tests=TO_MALFORMED version=2.31 X-Spam-Level: * Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The members of the IESG and IAB and the IETF chair are selected by a nominations committee made up of volunteers from the IETF community. The nominations committee is now in the process of being formed and volunteers are being accepted until Sep 6. Please see (http://www.ietf.org/nomcom/msg19765.html) for information if you are interested in volunteering to be on the nominations committee.