From owner-rap@ops.ietf.org Mon Jul 2 15:03:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25353 for ; Mon, 2 Jul 2001 15:03:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15H8xJ-0008Eo-00 for rap-data@psg.com; Mon, 02 Jul 2001 12:01:57 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15H8xI-0008Ei-00 for rap@ops.ietf.org; Mon, 02 Jul 2001 12:01:56 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15H8xI-0006GQ-00 for rap@ops.ietf.org; Mon, 02 Jul 2001 12:01:56 -0700 MIME-version: 1.0 From: "Hall, Tom G." To: "'rap@ops.ietf.org'" Subject: Re: draft-ietf-rap-auth-policy-data-00.txt Sender: owner-rap@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 02 Jul 2001 12:01:57 -0700 Good Day All, Seems like a good idea; overall, a very well written draft. I had a few problems understanding the wording in places, but that will change as the draft heads toward RFC status. - - - I encourage anyone and everyone to pursue the key management issue. (pg.11) "It is likely that the IETF will define a standard key management protocol." We really need this. - - - I got a bit confused about the validation of sequence numbers. In one place it talked about storing the last N sequence numbers, then in another it said that a receiver only needs to save the highest sequence number seen, then later on I see a 'reordering window' that will allow for limited ... well, reordering of sequence numbers. But then it says something about both storing a number and therefore removing a number from the lower end of the list (reorder window). I shouldn't complain unless I'm ready to offer an alternative, so I propose the following text to describe the use of reordering windows for sequence numbers: - - - (all sequence numbers computed modulo 2^64) An authenticating receiver maintains a 'reorder window'. The window consists of a list of N consecutive sequence numbers. (N >= 1) The list shall begin with an initial sequence number generated as described in Section 3. Each number in the list shall have an associated 'flag' which indicates whether or not the receiver has received that sequence number in a request message. The authenticating receiver shall: (1) Reject any sequence number less than the smallest number in the list. (2) Reject any sequence number in the list that has been seen before. (3) Accept any sequence number in the list that has never been seen before, and then flag that number as having been seen. (4) Accept any sequence number (S) greater than the largest number in the list, and then create a new list containing the numbers S-N+1 through S, inclusive, along with the flags any numbers that also appeared in the old list. Example: (reorder window of size 10, Initial Sequence Number =35,'+' means seen, and '-' means unseen) Event List ----- ---- Start 35-, 36-, 37-, 38-, 39-, 40-, 41-, 42-, 43-, 44- Get 37 35-, 36-, 37+, 38-, 39-, 40-, 41-, 42-, 43-, 44- Get 36 35-, 36+, 37+, 38-, 39-, 40-, 41-, 42-, 43-, 44- Get 35 35+, 36+, 37+, 38-, 39-, 40-, 41-, 42-, 43-, 44- Get 32 (reject as too small) Get 41 35+, 36+, 37+, 38-, 39-, 40-, 41+, 42-, 43-, 44- Get 36 (reject as duplicate) Get 42 35+, 36+, 37+, 38-, 39-, 40-, 41+, 42+, 43-, 44- Get 48 39-, 40-, 41+, 42-, 43-, 44-, 45-, 46-, 47-, 48+ Note that this algorithm also works for the strict case where N = 1. - - - Regards, -- Tom From owner-rap@ops.ietf.org Mon Jul 2 19:49:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22435 for ; Mon, 2 Jul 2001 19:49:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15HDQf-000G6m-00 for rap-data@psg.com; Mon, 02 Jul 2001 16:48:33 -0700 Received: from birch.ee.vt.edu ([128.173.88.34]) by psg.com with esmtp (Exim 3.30 #1) id 15HDQd-000G6Q-00 for rap@ops.ietf.org; Mon, 02 Jul 2001 16:48:31 -0700 Received: from fox.ee.vt.edu (fox.ee.vt.edu [128.173.88.144]) by birch.ee.vt.edu (8.9.3/8.9.3) with ESMTP id TAA09012 for ; Mon, 2 Jul 2001 19:48:29 -0400 (EDT) Received: from localhost (kphanse@localhost) by fox.ee.vt.edu (8.9.3+Sun/8.9.1) with SMTP id TAA06342 for ; Mon, 2 Jul 2001 19:48:29 -0400 (EDT) Date: Mon, 2 Jul 2001 19:48:29 -0400 (EDT) From: Kaustubh Phanse To: rap@ops.ietf.org Subject: Policy control for RSVP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rap@ops.ietf.org Precedence: bulk Re-sending the message (please see below) that I had sent a few days back. Did not really receive any response...so I am not sure if my query was too naive?! But, either way, I would be grateful if someone could please help me with this. Even after reading the RFCs/drafts, its still not clear why/whether there is a need for policy control on BOTH the PATH and RESV messages for a given RSVP flow. Thank you very much. regards Kaustubh ----------------------------------------------------------------------------- On Fri, 22 Jun 2001, Kaustubh Phanse wrote: > > Just wanted to clarify my understanding of the policy > control/processing of PATH and RESV messages. > > To successfully implement policy-based admission control, during > the initiation of an RSVP reservation, is it really "necessary" to enforce > policy control on both PATH and RESV messages? I understand that policy > elements in PATH message can be used to authenticate users/applications > and the corresponding Tspec. But this may be achieved even by > policy control of the RESV message. So, even if PEP on the sender side > does not perform any policy-based admission control on an "invalid" PATH > message and lets it flow to the receiver, the PEP on the receiver-side > should be able to "reject" the resulting "invalid" RESV message...right? > And hence such a policy framework should still work? Is there a scenario > where this is NOT the case and policy control on both PATH and RESV > message is "critical" for successful enforcement of PAC. > > Please forgive my ignorance on this topic! :) Any comments/clarifications > are more than welcome. > > Thanks in advance. > sincerely, > Kaustubh > ----------------------------------------------------------------------------- > Kaustubh S. Phanse kphanse@ee.vt.edu > PhD student http://www.ee.vt.edu/~kphanse > Alexandria Research Institute > Electrical & Computer Engineering Department > Virginia Polytechnic Institute & State University > ----------------------------------------------------------------------------- > > > From owner-rap@ops.ietf.org Mon Jul 2 23:04:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA25366 for ; Mon, 2 Jul 2001 23:04:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15HGTt-000LJq-00 for rap-data@psg.com; Mon, 02 Jul 2001 20:04:05 -0700 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by psg.com with esmtp (Exim 3.30 #1) id 15HGTr-000LIa-00 for rap@ops.ietf.org; Mon, 02 Jul 2001 20:04:03 -0700 Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0GFV00D1SN5P9L@firewall.mcit.com> for rap@ops.ietf.org; Tue, 3 Jul 2001 03:03:25 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GFV00201N5OB2@dgismtp04.wcomnet.com>; Tue, 03 Jul 2001 03:03:25 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GFV00DCRN5JTG@dgismtp04.wcomnet.com>; Tue, 03 Jul 2001 03:03:19 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2653.19) id ; Tue, 03 Jul 2001 03:03:19 +0000 Content-return: allowed Date: Tue, 03 Jul 2001 03:03:11 +0000 From: "Rawlins, Diana" Subject: RE: Policy control for RSVP To: "'Kaustubh Phanse'" , rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E64750A@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; charset=iso-8859-1 Sender: owner-rap@ops.ietf.org Precedence: bulk Kaustubh, IMHO I would perform access authorization policies on the Request PATH and resource authorization oriented policies on the Request RESV. -Diana -----Original Message----- From: Kaustubh Phanse [mailto:kphanse@ee.vt.edu] Sent: Monday, July 02, 2001 6:48 PM To: rap@ops.ietf.org Subject: Policy control for RSVP Re-sending the message (please see below) that I had sent a few days back. Did not really receive any response...so I am not sure if my query was too naive?! But, either way, I would be grateful if someone could please help me with this. Even after reading the RFCs/drafts, its still not clear why/whether there is a need for policy control on BOTH the PATH and RESV messages for a given RSVP flow. Thank you very much. regards Kaustubh ---------------------------------------------------------------------------- - On Fri, 22 Jun 2001, Kaustubh Phanse wrote: > > Just wanted to clarify my understanding of the policy > control/processing of PATH and RESV messages. > > To successfully implement policy-based admission control, during > the initiation of an RSVP reservation, is it really "necessary" to enforce > policy control on both PATH and RESV messages? I understand that policy > elements in PATH message can be used to authenticate users/applications > and the corresponding Tspec. But this may be achieved even by > policy control of the RESV message. So, even if PEP on the sender side > does not perform any policy-based admission control on an "invalid" PATH > message and lets it flow to the receiver, the PEP on the receiver-side > should be able to "reject" the resulting "invalid" RESV message...right? > And hence such a policy framework should still work? Is there a scenario > where this is NOT the case and policy control on both PATH and RESV > message is "critical" for successful enforcement of PAC. > > Please forgive my ignorance on this topic! :) Any comments/clarifications > are more than welcome. > > Thanks in advance. > sincerely, > Kaustubh > ---------------------------------------------------------------------------- - > Kaustubh S. Phanse kphanse@ee.vt.edu > PhD student http://www.ee.vt.edu/~kphanse > Alexandria Research Institute > Electrical & Computer Engineering Department > Virginia Polytechnic Institute & State University > ---------------------------------------------------------------------------- - > > > From owner-rap@ops.ietf.org Wed Jul 4 05:58:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03456 for ; Wed, 4 Jul 2001 05:58:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15HjP4-0002bR-00 for rap-data@psg.com; Wed, 04 Jul 2001 02:57:02 -0700 Received: from infres-192.enst.fr ([137.194.192.1] helo=infres.enst.fr) by psg.com with esmtp (Exim 3.31 #1) id 15HjP0-0002bI-00 for rap@ops.ietf.org; Wed, 04 Jul 2001 02:56:58 -0700 Received: from yahoo.com (dragon.enst.fr [137.194.192.44]) by infres.enst.fr (Postfix) with ESMTP id A524F1891 for ; Wed, 4 Jul 2001 11:56:52 +0200 (MET DST) Message-ID: <3B42E93E.22813CDB@yahoo.com> Date: Wed, 04 Jul 2001 12:00:30 +0200 From: Nguyen Thi Mai Trang Organization: ENST - INFRES X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: rap@ops.ietf.org Subject: Client Failure References: <492EB4A3F68CD411ABE800508B69362E64750A@RIPEXCH002.wcomnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, In the Error object specified in RFC 2748, there are a error-code = 8 (client failure). Can someone explain to me when we use this error, please ? Thank you in advance. MT ---------------------------------------------------- Nguyen Thi Mai Trang Ecole Nationale Superieure des Telecommunications Dept. INFRES - Bur. C234-4 46 Rue Barrault - 75013 Paris Tel: 01 45 81 74 61 - Fax : 01 45 81 31 19 email : trnguyen@enst.fr From owner-rap@ops.ietf.org Wed Jul 4 16:37:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11354 for ; Wed, 4 Jul 2001 16:37:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15HtNH-0005hx-00 for rap-data@psg.com; Wed, 04 Jul 2001 13:35:51 -0700 Received: from birch.ee.vt.edu ([128.173.88.34]) by psg.com with esmtp (Exim 3.31 #1) id 15HtNF-0005ha-00 for rap@ops.ietf.org; Wed, 04 Jul 2001 13:35:49 -0700 Received: from fox.ee.vt.edu (fox.ee.vt.edu [128.173.88.144]) by birch.ee.vt.edu (8.9.3/8.9.3) with ESMTP id QAA21492 for ; Wed, 4 Jul 2001 16:35:47 -0400 (EDT) Received: from localhost (kphanse@localhost) by fox.ee.vt.edu (8.9.3+Sun/8.9.1) with SMTP id QAA17305 for ; Wed, 4 Jul 2001 16:35:47 -0400 (EDT) Date: Wed, 4 Jul 2001 16:35:47 -0400 (EDT) From: Kaustubh Phanse To: rap@ops.ietf.org Subject: RE: Policy control for RSVP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rap@ops.ietf.org Precedence: bulk Hi! Diana, Thanks for your reply. I do understand that this could be one way to do it and is generally mentioned in most RFCs/published papers. But, I am not yet sure whether this is the ONLY way to do it. Can't both the access and resource authorization policies be performed only on the RESV message? I guess for "valid" RSVP flows, the advantage in doing this seems to be two-fold: (1) Reduction in the set-up time, since now the PEP will forward the PATH message without having to wait for PDP's decision, and (2) Reduction in amount of signalling overhead. Isn't it? Please correct me if I am wrong. Thank you very much. regards Kaustubh ----------------------------------------------------------------------------- On Tue, 3 Jul 2001, Rawlins, Diana wrote: > Kaustubh, > > IMHO I would perform access authorization policies on the Request > PATH and resource authorization oriented policies on the Request > RESV. > > -Diana > > > -----Original Message----- > From: Kaustubh Phanse [mailto:kphanse@ee.vt.edu] > Sent: Monday, July 02, 2001 6:48 PM > To: rap@ops.ietf.org > Subject: Policy control for RSVP > > > > Re-sending the message (please see below) that I had sent a few > days back. Did not really receive any response...so I am not sure if my > query was too naive?! But, either way, I would be grateful if someone > could please help me with this. Even after reading the RFCs/drafts, its > still not clear why/whether there is a need for policy control on BOTH the > PATH and RESV messages for a given RSVP flow. > > Thank you very much. > regards > Kaustubh > > ---------------------------------------------------------------------------- > - > On Fri, 22 Jun 2001, Kaustubh Phanse wrote: > > > > > Just wanted to clarify my understanding of the policy > > control/processing of PATH and RESV messages. > > > > To successfully implement policy-based admission control, during > > the initiation of an RSVP reservation, is it really "necessary" to enforce > > policy control on both PATH and RESV messages? I understand that policy > > elements in PATH message can be used to authenticate users/applications > > and the corresponding Tspec. But this may be achieved even by > > policy control of the RESV message. So, even if PEP on the sender side > > does not perform any policy-based admission control on an "invalid" PATH > > message and lets it flow to the receiver, the PEP on the receiver-side > > should be able to "reject" the resulting "invalid" RESV message...right? > > And hence such a policy framework should still work? Is there a scenario > > where this is NOT the case and policy control on both PATH and RESV > > message is "critical" for successful enforcement of PAC. > > > > Please forgive my ignorance on this topic! :) Any comments/clarifications > > are more than welcome. > > > > Thanks in advance. > > sincerely, > > Kaustubh > > > ---------------------------------------------------------------------------- > - > > Kaustubh S. Phanse kphanse@ee.vt.edu > > PhD student http://www.ee.vt.edu/~kphanse > > Alexandria Research Institute > > Electrical & Computer Engineering Department > > Virginia Polytechnic Institute & State University > > > ---------------------------------------------------------------------------- > - > > > > > > > > From owner-rap@ops.ietf.org Thu Jul 5 14:04:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21864 for ; Thu, 5 Jul 2001 14:04:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15IDS8-000JT2-00 for rap-data@psg.com; Thu, 05 Jul 2001 11:02:12 -0700 Received: from hypnos.cps.intel.com ([192.198.165.17]) by psg.com with esmtp (Exim 3.31 #1) id 15IDS7-000JS8-00 for rap@ops.ietf.org; Thu, 05 Jul 2001 11:02:11 -0700 Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.40 2001/06/06 21:14:49 root Exp $) with SMTP id SAA11757; Thu, 5 Jul 2001 18:02:04 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 05 Jul 2001 18:02:04 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id <3F2WDD9Q>; Thu, 5 Jul 2001 11:02:03 -0700 Message-ID: From: "Hess, Rodney" To: "'rap@ops.ietf.org'" Cc: "'Hall, Tom G.'" Subject: RE: draft-ietf-rap-auth-policy-data-00.txt Date: Thu, 5 Jul 2001 11:01:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Thanks for your feedback, Tom. Yes, the intent is to have a reordered windowing algorithm as you describe below. It would appear that the document's wording does not convey this effectively enough. I can certainly pull in what you have written below and tighten up the other references in the next draft. Rodney -----Original Message----- From: Hall, Tom G. [mailto:Tom.G.Hall@wcom.com] Sent: Monday, July 02, 2001 3:02 PM To: 'rap@ops.ietf.org' Subject: Re: draft-ietf-rap-auth-policy-data-00.txt Good Day All, Seems like a good idea; overall, a very well written draft. I had a few problems understanding the wording in places, but that will change as the draft heads toward RFC status. - - - I encourage anyone and everyone to pursue the key management issue. (pg.11) "It is likely that the IETF will define a standard key management protocol." We really need this. - - - I got a bit confused about the validation of sequence numbers. In one place it talked about storing the last N sequence numbers, then in another it said that a receiver only needs to save the highest sequence number seen, then later on I see a 'reordering window' that will allow for limited ... well, reordering of sequence numbers. But then it says something about both storing a number and therefore removing a number from the lower end of the list (reorder window). I shouldn't complain unless I'm ready to offer an alternative, so I propose the following text to describe the use of reordering windows for sequence numbers: - - - (all sequence numbers computed modulo 2^64) An authenticating receiver maintains a 'reorder window'. The window consists of a list of N consecutive sequence numbers. (N >= 1) The list shall begin with an initial sequence number generated as described in Section 3. Each number in the list shall have an associated 'flag' which indicates whether or not the receiver has received that sequence number in a request message. The authenticating receiver shall: (1) Reject any sequence number less than the smallest number in the list. (2) Reject any sequence number in the list that has been seen before. (3) Accept any sequence number in the list that has never been seen before, and then flag that number as having been seen. (4) Accept any sequence number (S) greater than the largest number in the list, and then create a new list containing the numbers S-N+1 through S, inclusive, along with the flags any numbers that also appeared in the old list. Example: (reorder window of size 10, Initial Sequence Number =35,'+' means seen, and '-' means unseen) Event List ----- ---- Start 35-, 36-, 37-, 38-, 39-, 40-, 41-, 42-, 43-, 44- Get 37 35-, 36-, 37+, 38-, 39-, 40-, 41-, 42-, 43-, 44- Get 36 35-, 36+, 37+, 38-, 39-, 40-, 41-, 42-, 43-, 44- Get 35 35+, 36+, 37+, 38-, 39-, 40-, 41-, 42-, 43-, 44- Get 32 (reject as too small) Get 41 35+, 36+, 37+, 38-, 39-, 40-, 41+, 42-, 43-, 44- Get 36 (reject as duplicate) Get 42 35+, 36+, 37+, 38-, 39-, 40-, 41+, 42+, 43-, 44- Get 48 39-, 40-, 41+, 42-, 43-, 44-, 45-, 46-, 47-, 48+ Note that this algorithm also works for the strict case where N = 1. - - - Regards, -- Tom From owner-rap@ops.ietf.org Fri Jul 6 10:50:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05135 for ; Fri, 6 Jul 2001 10:50:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15IWwL-0002v1-00 for rap-data@psg.com; Fri, 06 Jul 2001 07:50:41 -0700 Received: from pc-62-30-167-16-ca.blueyonder.co.uk ([62.30.167.16] helo=NEXUS.replicants.org.uk) by psg.com with esmtp (Exim 3.31 #1) id 15IWwK-0002td-00 for rap@ops.ietf.org; Fri, 06 Jul 2001 07:50:40 -0700 Received: from mail pickup service by NEXUS.replicants.org.uk with Microsoft SMTPSVC; Fri, 6 Jul 2001 15:54:45 +0100 X-From_: ietf-123-owner@loki.ietf.org Tue Jun 26 15:18:28 2001 Received: from [132.151.1.177] (helo=loki.ietf.org) by mail13.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 15Etfg-0006AX-00; Tue, 26 Jun 2001 15:18:28 +0100 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA19381 for ietf-123-outbound.10@ietf.org; Tue, 26 Jun 2001 08:55:02 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA18588 for ; Tue, 26 Jun 2001 07:02:24 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27231; Tue, 26 Jun 2001 07:02:22 -0400 (EDT) Message-Id: <200106261102.HAA27231@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rap@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rap-new-rsvp-ext-00.txt Date: Tue, 26 Jun 2001 07:02:22 -0400 X-OriginalArrivalTime: 06 Jul 2001 14:54:45.0240 (UTC) FILETIME=[9858C780:01C1062B] Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : RSVP Extensions for Policy Control Author(s) : R. Hess, S. Herzog Filename : draft-ietf-rap-new-rsvp-ext-00.txt Pages : 13 Date : 25-Jun-01 This memo presents a set of extensions for supporting generic policy based admission control in RSVP. It should be perceived as an extension to the RSVP functional specifications [RSVP]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-new-rsvp-ext-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-new-rsvp-ext-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-new-rsvp-ext-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010625095559.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-new-rsvp-ext-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-new-rsvp-ext-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Con --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Fri Jul 6 10:50:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05146 for ; Fri, 6 Jul 2001 10:50:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15IWwC-0002uj-00 for rap-data@psg.com; Fri, 06 Jul 2001 07:50:32 -0700 Received: from pc-62-30-167-16-ca.blueyonder.co.uk ([62.30.167.16] helo=NEXUS.replicants.org.uk) by psg.com with esmtp (Exim 3.31 #1) id 15IWwB-0002td-00 for rap@ops.ietf.org; Fri, 06 Jul 2001 07:50:32 -0700 Received: from mail pickup service by NEXUS.replicants.org.uk with Microsoft SMTPSVC; Fri, 6 Jul 2001 15:54:44 +0100 X-From_: ietf-123-owner@loki.ietf.org Tue Jun 26 15:13:04 2001 Received: from [132.151.1.177] (helo=loki.ietf.org) by mail8.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 15EtaR-0001sT-00; Tue, 26 Jun 2001 15:13:04 +0100 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA19307 for ietf-123-outbound.10@ietf.org; Tue, 26 Jun 2001 08:45:02 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA18581 for ; Tue, 26 Jun 2001 07:02:16 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27213; Tue, 26 Jun 2001 07:02:14 -0400 (EDT) Message-Id: <200106261102.HAA27213@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rap@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rap-rsvp-better-identity-00.txt Date: Tue, 26 Jun 2001 07:02:14 -0400 X-OriginalArrivalTime: 06 Jul 2001 14:54:44.0178 (UTC) FILETIME=[97B6BB20:01C1062B] Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : Identity Representation for RSVP Author(s) : R. Hess et al. Filename : draft-ietf-rap-rsvp-better-identity-00.txt Pages : 17 Date : 25-Jun-01 This document describes the representation of identity information in POLICY_DATA objects [POL-EXT] for supporting policy based admission control in RSVP. The goal of identity representation is to allow a process on a system to securely identify the owner and the application of the communicating process (e.g. user id) and convey this information in RSVP messages (PATH or RESV) in a secure manner. We describe the encoding of identities as a RSVP policy element. We describe the processing rules to generate identity policy elements for multicast merged flows. Subsequently, we describe representations of user identities for Kerberos and Public Key based user authentication mechanisms. In summary we describe the use of this identity information in an operational setting. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-rsvp-better-identity-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-rsvp-better-identity-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-rsvp-better-identity-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010625095551.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-rsvp-better-identity-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-rsvp-better-identity-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-draf" --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Fri Jul 6 10:50:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05160 for ; Fri, 6 Jul 2001 10:50:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15IWwG-0002ur-00 for rap-data@psg.com; Fri, 06 Jul 2001 07:50:36 -0700 Received: from pc-62-30-167-16-ca.blueyonder.co.uk ([62.30.167.16] helo=NEXUS.replicants.org.uk) by psg.com with esmtp (Exim 3.31 #1) id 15IWwF-0002td-00 for rap@ops.ietf.org; Fri, 06 Jul 2001 07:50:36 -0700 Received: from mail pickup service by NEXUS.replicants.org.uk with Microsoft SMTPSVC; Fri, 6 Jul 2001 15:54:44 +0100 X-From_: ietf-123-owner@loki.ietf.org Tue Jun 26 15:08:43 2001 Received: from [132.151.1.177] (helo=loki.ietf.org) by mail8.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 15EtWD-0008IR-00; Tue, 26 Jun 2001 15:08:42 +0100 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA19214 for ietf-123-outbound.10@ietf.org; Tue, 26 Jun 2001 08:35:02 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA18574 for ; Tue, 26 Jun 2001 07:02:08 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27193; Tue, 26 Jun 2001 07:02:06 -0400 (EDT) Message-Id: <200106261102.HAA27193@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rap@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rap-auth-policy-data-00.txt Date: Tue, 26 Jun 2001 07:02:06 -0400 X-OriginalArrivalTime: 06 Jul 2001 14:54:44.0258 (UTC) FILETIME=[97C2F020:01C1062B] Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : Cryptographic Authentication for RSVP POLICY_DATA Objects Author(s) : R. Hess Filename : draft-ietf-rap-auth-policy-data-00.txt Pages : 21 Date : 25-Jun-01 This document describes the format and use of the INTEGRITY option within RSVP's POLICY_DATA object to provide integrity and authentication of POLICY_DATA objects within RSVP messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-auth-policy-data-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-auth-policy-data-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-auth-policy-data-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010625095542.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-auth-policy-data-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-auth-policy-data-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Co --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Fri Jul 6 11:18:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07652 for ; Fri, 6 Jul 2001 11:18:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15IXOF-0003w3-00 for rap-data@psg.com; Fri, 06 Jul 2001 08:19:31 -0700 Received: from [64.223.136.42] (helo=postal.ellacoya.com) by psg.com with esmtp (Exim 3.31 #1) id 15IXOF-0003vU-00 for rap@ops.ietf.org; Fri, 06 Jul 2001 08:19:31 -0700 Received: from ellacoya.com (mstevens.eng.ellacoya.com [192.168.121.50]) by postal.ellacoya.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M489T1Q7; Fri, 6 Jul 2001 11:18:54 -0400 Message-ID: <3B45D5E3.2FB91FDA@ellacoya.com> Date: Fri, 06 Jul 2001 11:14:43 -0400 From: "Mark L. Stevens" Organization: Ellacoya Networks X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: rap@ops.ietf.org Subject: Upcoming Meeting Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The next RAP working group meeting is fast approaching. As you may have noticed we have a number of work items on the new charter. http://www.ietf.org/html.charters/rap-charter.html I am working on the agenda for the meeting and will need to submit it in the coming weeks. So, if you have are working on items on the charter and would like time on the meeting agenda, please contact me by e-mail at your earliest convenience. Also, if you are working on a working group deliverable with a Jul 2001 delivery date, keep these dates in mind: July 13 - Internet Draft Cut-off for initial document (-00) submission at 17:00 ET July 20 - Internet Draft final submission cutoff date at 1700 ET -Mark Stevens (rap wg co-chair) From owner-rap@ops.ietf.org Fri Jul 13 11:24:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22614 for ; Fri, 13 Jul 2001 11:24:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15L43i-000FkH-00 for rap-data@psg.com; Fri, 13 Jul 2001 07:36:46 -0700 Received: from tlvsdy.vim.tlt.alcatel.it ([194.243.74.244]) by psg.com with esmtp (Exim 3.31 #1) id 15L43h-000Fk7-00 for rap@ops.ietf.org; Fri, 13 Jul 2001 07:36:45 -0700 Received: from tlvhdk.netit.alcatel.it (tlvhgd.netit.alcatel.it [151.98.14.48]) by tlvsdy.vim.tlt.alcatel.it (8.9.3+Sun/8.9.3) with ESMTP id QAA09242; Fri, 13 Jul 2001 16:37:23 +0200 (MET DST) Received: from alcatel.it (molgora@tlvhgr.vim.tlt.alcatel.it [151.98.44.119]) by tlvhdk.netit.alcatel.it (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id QAA29300; Fri, 13 Jul 2001 16:32:16 +0200 (METDST) Message-ID: <3B4F04F7.9798C5C8@alcatel.it> Date: Fri, 13 Jul 2001 16:26:00 +0200 From: Molgora Paolo X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.10.20 9000/820) X-Accept-Language: en MIME-Version: 1.0 To: kphanse@ee.vt.edu CC: rap@ops.ietf.org Subject: Re: Policy control for RSVP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sorry, but for my understanding to check resource authorization policies on RESV msg means to execute the control after the connection is already established. This for my point of view cause the following problems if the check fails: - it is provided a not authorized service also for a few time; - the connection just created has to be destoyed; What I had understood was to execute all the checks at the PATH request in order to block the request suddenly; this solution could take time to create a path (i.e. wait PDP decision as you said), but it is anyway irrelevant wrt the global path set-up activities that today an operator has to do on the network. I thank you in advance for any answer. Paolo kphanse@ee.vt.edu wrote: > Hi! Diana, > > Thanks for your reply. I do understand that this could be one way > to do it and is generally mentioned in most RFCs/published papers. But, I > am not yet sure whether this is the ONLY way to do it. > Can't both the access and resource authorization policies be performed > only on the RESV message? I guess for "valid" RSVP flows, the advantage in > doing this seems to be two-fold: (1) Reduction in the set-up time, since > now the PEP will forward the PATH message without having to wait for PDP's > decision, and (2) Reduction in amount of signalling overhead. Isn't it? > Please correct me if I am wrong. > > Thank you very much. > regards > Kaustubh > > ----------------------------------------------------------------------------- > On Tue, 3 Jul 2001, Rawlins, Diana wrote: > > > Kaustubh, > > > > IMHO I would perform access authorization policies on the Request > > PATH and resource authorization oriented policies on the Request > > RESV. > > > > -Diana > > > > > > -----Original Message----- > > From: Kaustubh Phanse [mailto:kphanse@ee.vt.edu] > > Sent: Monday, July 02, 2001 6:48 PM > > To: rap@ops.ietf.org > > Subject: Policy control for RSVP > > > > > > > > Re-sending the message (please see below) that I had sent a few > > days back. Did not really receive any response...so I am not sure if my > > query was too naive?! But, either way, I would be grateful if someone > > could please help me with this. Even after reading the RFCs/drafts, its > > still not clear why/whether there is a need for policy control on BOTH the > > PATH and RESV messages for a given RSVP flow. > > > > Thank you very much. > > regards > > Kaustubh > > > > ---------------------------------------------------------------------------- > > - > > On Fri, 22 Jun 2001, Kaustubh Phanse wrote: > > > > > > > > Just wanted to clarify my understanding of the policy > > > control/processing of PATH and RESV messages. > > > > > > To successfully implement policy-based admission control, during > > > the initiation of an RSVP reservation, is it really "necessary" to enforce > > > policy control on both PATH and RESV messages? I understand that policy > > > elements in PATH message can be used to authenticate users/applications > > > and the corresponding Tspec. But this may be achieved even by > > > policy control of the RESV message. So, even if PEP on the sender side > > > does not perform any policy-based admission control on an "invalid" PATH > > > message and lets it flow to the receiver, the PEP on the receiver-side > > > should be able to "reject" the resulting "invalid" RESV message...right? > > > And hence such a policy framework should still work? Is there a scenario > > > where this is NOT the case and policy control on both PATH and RESV > > > message is "critical" for successful enforcement of PAC. > > > > > > Please forgive my ignorance on this topic! :) Any comments/clarifications > > > are more than welcome. > > > > > > Thanks in advance. > > > sincerely, > > > Kaustubh > > > > > ---------------------------------------------------------------------------- > > - > > > Kaustubh S. Phanse kphanse@ee.vt.edu > > > PhD student http://www.ee.vt.edu/~kphanse > > > Alexandria Research Institute > > > Electrical & Computer Engineering Department > > > Virginia Polytechnic Institute & State University > > > > > ---------------------------------------------------------------------------- > > - > > > > > > > > > > > > > -- ---------------------------------------------------- Paolo Molgora, NM System Team, Alcatel TSD Vimercate E-Mail: mailto: paolofranco.molgora@netit.alcatel.it Tel.: +39-039-686 4032 (or via Alcanet: 2 210 4032) Fax : +39-039-686 4185 (or via Alcanet: 2 210 4185) ---------------------------------------------------- From owner-rap@ops.ietf.org Fri Jul 13 11:53:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26852 for ; Fri, 13 Jul 2001 11:53:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15L5GF-000HCV-00 for rap-data@psg.com; Fri, 13 Jul 2001 08:53:47 -0700 Received: from birch.ee.vt.edu ([128.173.88.34]) by psg.com with esmtp (Exim 3.31 #1) id 15L5GE-000HCP-00 for rap@ops.ietf.org; Fri, 13 Jul 2001 08:53:46 -0700 Received: from yew.ee.vt.edu (yew.ee.vt.edu [128.173.88.43]) by birch.ee.vt.edu (8.9.3/8.9.3) with ESMTP id LAA09320; Fri, 13 Jul 2001 11:53:44 -0400 (EDT) Received: from localhost (kphanse@localhost) by yew.ee.vt.edu (8.9.3+Sun/8.9.1) with SMTP id LAA05736; Fri, 13 Jul 2001 11:53:44 -0400 (EDT) Date: Fri, 13 Jul 2001 11:53:44 -0400 (EDT) From: Kaustubh Phanse To: Molgora Paolo cc: rap@ops.ietf.org Subject: Re: Policy control for RSVP In-Reply-To: <3B4F04F7.9798C5C8@alcatel.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rap@ops.ietf.org Precedence: bulk Hi! Paolo, Thanks for your reply. Yes, I just wanted to confirm/compare the trade-offs and implications of doing or not doing access authorization for the PATH message. The main driving factor of doing this mainly looks to be more of a security stand-point (denial of service etc.) than QoS or resource reservation itself, since the bandwidth reservation and connection set-up is not complete anyway till the RESV message gets back to the sender. Thank you regards Kaustubh ----------------------------------------------------------------------------- On Fri, 13 Jul 2001, Molgora Paolo wrote: > Sorry, > > but for my understanding to check resource authorization policies > on RESV msg means to execute the control after the connection is > already established. This for my point of view cause the following > problems if the check fails: > - it is provided a not authorized service also for a few time; > - the connection just created has to be destoyed; > > What I had understood was to execute all the checks at the PATH request > in order to block the request suddenly; > this solution could take time to create a path (i.e. wait PDP decision as you said), > but it is anyway irrelevant wrt the global path set-up activities that today an > operator > has to do on the network. > > I thank you in advance for any answer. > > Paolo > > kphanse@ee.vt.edu wrote: > > > Hi! Diana, > > > > Thanks for your reply. I do understand that this could be one way > > to do it and is generally mentioned in most RFCs/published papers. But, I > > am not yet sure whether this is the ONLY way to do it. > > Can't both the access and resource authorization policies be performed > > only on the RESV message? I guess for "valid" RSVP flows, the advantage in > > doing this seems to be two-fold: (1) Reduction in the set-up time, since > > now the PEP will forward the PATH message without having to wait for PDP's > > decision, and (2) Reduction in amount of signalling overhead. Isn't it? > > Please correct me if I am wrong. > > > > Thank you very much. > > regards > > Kaustubh > > > > ----------------------------------------------------------------------------- > > On Tue, 3 Jul 2001, Rawlins, Diana wrote: > > > > > Kaustubh, > > > > > > IMHO I would perform access authorization policies on the Request > > > PATH and resource authorization oriented policies on the Request > > > RESV. > > > > > > -Diana > > > > > > > > > -----Original Message----- > > > From: Kaustubh Phanse [mailto:kphanse@ee.vt.edu] > > > Sent: Monday, July 02, 2001 6:48 PM > > > To: rap@ops.ietf.org > > > Subject: Policy control for RSVP > > > > > > > > > > > > Re-sending the message (please see below) that I had sent a few > > > days back. Did not really receive any response...so I am not sure if my > > > query was too naive?! But, either way, I would be grateful if someone > > > could please help me with this. Even after reading the RFCs/drafts, its > > > still not clear why/whether there is a need for policy control on BOTH the > > > PATH and RESV messages for a given RSVP flow. > > > > > > Thank you very much. > > > regards > > > Kaustubh > > > > > > ---------------------------------------------------------------------------- > > > - > > > On Fri, 22 Jun 2001, Kaustubh Phanse wrote: > > > > > > > > > > > Just wanted to clarify my understanding of the policy > > > > control/processing of PATH and RESV messages. > > > > > > > > To successfully implement policy-based admission control, during > > > > the initiation of an RSVP reservation, is it really "necessary" to enforce > > > > policy control on both PATH and RESV messages? I understand that policy > > > > elements in PATH message can be used to authenticate users/applications > > > > and the corresponding Tspec. But this may be achieved even by > > > > policy control of the RESV message. So, even if PEP on the sender side > > > > does not perform any policy-based admission control on an "invalid" PATH > > > > message and lets it flow to the receiver, the PEP on the receiver-side > > > > should be able to "reject" the resulting "invalid" RESV message...right? > > > > And hence such a policy framework should still work? Is there a scenario > > > > where this is NOT the case and policy control on both PATH and RESV > > > > message is "critical" for successful enforcement of PAC. > > > > > > > > Please forgive my ignorance on this topic! :) Any comments/clarifications > > > > are more than welcome. > > > > > > > > Thanks in advance. > > > > sincerely, > > > > Kaustubh > > > > > > > ---------------------------------------------------------------------------- > > > - > > > > Kaustubh S. Phanse kphanse@ee.vt.edu > > > > PhD student http://www.ee.vt.edu/~kphanse > > > > Alexandria Research Institute > > > > Electrical & Computer Engineering Department > > > > Virginia Polytechnic Institute & State University > > > > > > > ---------------------------------------------------------------------------- > > > - > > > > > > > > > > > > > > > > > > > > -- > ---------------------------------------------------- > Paolo Molgora, NM System Team, Alcatel TSD Vimercate > E-Mail: mailto: paolofranco.molgora@netit.alcatel.it > Tel.: +39-039-686 4032 (or via Alcanet: 2 210 4032) > Fax : +39-039-686 4185 (or via Alcanet: 2 210 4185) > ---------------------------------------------------- > > > > From owner-rap@ops.ietf.org Tue Jul 17 08:00:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19054 for ; Tue, 17 Jul 2001 08:00:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MTW9-000EF9-00 for rap-data@psg.com; Tue, 17 Jul 2001 04:59:57 -0700 Received: from goliath.siemens.de ([194.138.37.131]) by psg.com with esmtp (Exim 3.31 #1) id 15MTW8-000EF3-00 for rap@ops.ietf.org; Tue, 17 Jul 2001 04:59:56 -0700 X-Envelope-Sender-Is: Hannes.Tschofenig@mchp.siemens.de (at relayer goliath.siemens.de) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.1/8.11.1) with ESMTP id f6HBxsb27047; Tue, 17 Jul 2001 13:59:54 +0200 (MET DST) Received: from sn52sun1 (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail3.siemens.de (8.11.4/8.11.4) with SMTP id f6HBxrI25912399; Tue, 17 Jul 2001 13:59:54 +0200 (MEST) Reply-To: From: "Hannes Tschofenig" To: "Kaustubh Phanse" , "Molgora Paolo" Cc: Subject: RE: Policy control for RSVP Date: Tue, 17 Jul 2001 13:31:51 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit # hi kaustubh, hi paolo! # from a security perspective access control (access authorization) at the first hop router is provided by # a previous registration to the network e.g. # - authentication at layer 2 e.g. as provided by wireless lan (via eap) # - AAA (radius, diameter) # this registration is finished before the actual qos signaling took place. # furthermore there is the rsvp integrity object which provides host-based # authentication. # hence a denial of service attack is difficult if the sender of the rsvp message is # authenticated. every time a path or a rsvp message is sent from the user to the first # hop router a policy object should! be included to allow policy based admission control. this allows # authenticating the user at the pep or pdp, authorization of the request # and possibly an accounting procedure to be triggered. # in my opinion both the path and resv message (transmitted by the user's host) should include a policy element. # what do you think? # ciao # hannes Hi! Paolo, Thanks for your reply. Yes, I just wanted to confirm/compare the trade-offs and implications of doing or not doing access authorization for the PATH message. The main driving factor of doing this mainly looks to be more of a security stand-point (denial of service etc.) than QoS or resource reservation itself, since the bandwidth reservation and connection set-up is not complete anyway till the RESV message gets back to the sender. Thank you regards Kaustubh From owner-rap@ops.ietf.org Tue Jul 17 13:41:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00059 for ; Tue, 17 Jul 2001 13:41:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MYdN-000PaO-00 for rap-data@psg.com; Tue, 17 Jul 2001 10:27:45 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15MYdL-000Pa6-00; Tue, 17 Jul 2001 10:27:43 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MYb7-0000LK-00; Tue, 17 Jul 2001 13:25:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rsent-To: eos@ops.ietf.org From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group cc: iesg@ietf.org Subject: Note Well Message-Id: Date: Tue, 17 Jul 2001 13:25:25 -0400 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. From owner-rap@ops.ietf.org Tue Jul 17 13:41:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00070 for ; Tue, 17 Jul 2001 13:41:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MYbu-000PVJ-00 for rap-data@psg.com; Tue, 17 Jul 2001 10:26:14 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15MYbt-000PVD-00 for rap@ops.ietf.org; Tue, 17 Jul 2001 10:26:14 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MYbp-0000LS-00 for rap@ops.ietf.org; Tue, 17 Jul 2001 13:26:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group cc: iesg@ietf.org Subject: Note Well Sender: owner-rap@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 17 Jul 2001 10:26:14 -0700 Content-Transfer-Encoding: 7bit Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. From owner-rap@ops.ietf.org Wed Jul 18 07:04:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28113 for ; Wed, 18 Jul 2001 07:04:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Mp6a-000E5w-00 for rap-data@psg.com; Wed, 18 Jul 2001 04:03:00 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.31 #1) id 15Mp6Z-000E5p-00 for rap@ops.ietf.org; Wed, 18 Jul 2001 04:02:59 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27095; Wed, 18 Jul 2001 07:02:04 -0400 (EDT) Message-Id: <200107181102.HAA27095@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rap@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rap-feedback-frwk-00.txt Date: Wed, 18 Jul 2001 07:02:04 -0400 Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : Framework of COPS-PR Policy Usage Feedback Author(s) : D. Rawlins, A. Kulkarni Filename : draft-ietf-rap-feedback-frwk-00.txt Pages : 6 Date : 17-Jul-01 Common Open Policy Services Protocol [COPS], RFC 2748, defined the capability of reporting information to the PDP. The types of report information are success, failure and accounting of an installed state. This document focuses on the accounting report type and the necessary framework for the monitoring and reporting of usage feedback for an installed state. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-frwk-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-feedback-frwk-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-feedback-frwk-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010717134033.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-feedback-frwk-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-feedback-frwk-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010717134033.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Wed Jul 18 07:14:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00361 for ; Wed, 18 Jul 2001 07:14:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Mp6U-000E5l-00 for rap-data@psg.com; Wed, 18 Jul 2001 04:02:54 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.31 #1) id 15Mp6T-000E5e-00 for rap@ops.ietf.org; Wed, 18 Jul 2001 04:02:54 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27041; Wed, 18 Jul 2001 07:01:59 -0400 (EDT) Message-Id: <200107181101.HAA27041@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rap@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rap-feedback-fr-pib-00.txt Date: Wed, 18 Jul 2001 07:01:58 -0400 Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : Framework of COPS-PR Policy Information Base for Policy Usage Feedback Author(s) : D. Rawlins et al. Filename : draft-ietf-rap-feedback-fr-pib-00.txt Pages : 16 Date : 17-Jul-01 Currently there are no policy classes defined for the PEP to convey provisioned policy usage feedback to the PDP. The purpose of this document is to define the policy usage feedback framework PIB that specifies the policy classes common for COPS feedback reports. The basic operation and objects for reporting usage information are defined in [COPS]. A specific clientSI feedback object named REPORT is defined in [COPS-PR]. A framework for approaching solicited and periodic usage feedback is described in [COPS-FEED-FRWK]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-fr-pib-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-feedback-fr-pib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-feedback-fr-pib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010717134023.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-feedback-fr-pib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-feedback-fr-pib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010717134023.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Wed Jul 18 16:10:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22407 for ; Wed, 18 Jul 2001 16:10:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MxSG-000DVi-00 for rap-data@psg.com; Wed, 18 Jul 2001 12:57:56 -0700 Received: from fmfdns01.fm.intel.com ([132.233.247.10] helo=calliope1.fm.intel.com) by psg.com with esmtp (Exim 3.31 #1) id 15MxSF-000DVV-00 for rap@ops.ietf.org; Wed, 18 Jul 2001 12:57:56 -0700 Received: from fmsmsx17.intel.com (fmsmsx17.fm.intel.com [132.233.58.209]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with ESMTP id TAA01512; Wed, 18 Jul 2001 19:57:52 GMT Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2653.19) id <3X1M89D9>; Wed, 18 Jul 2001 12:57:50 -0700 Message-ID: From: "Hess, Rodney" To: "'Hannes.Tschofenig@mchp.siemens.de'" , rap@ops.ietf.org Subject: RE: Question about RFC 2752 Date: Wed, 18 Jul 2001 12:57:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Hey, Hannes, You are correct on both points. RFC 2752 is in error, as are the equivalent paragraphs in (which updates RFC 2752). This will be fixed in the next draft. Thanks for pointing this out. Rodney Hess rodney.hess@intel.com -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@mchp.siemens.de] Sent: Friday, June 29, 2001 3:01 AM To: rap@ops.ietf.org Subject: Question about RFC 2752 hi a remark in RFC 2752 in section 4.2.1 notes: 'The KDC is used to validate the ticket and authentication the user sending RSVP message.'. this sounds strange to me since the network element for which the ticket was requested is able to decrypt the ticket and to authenticated the user and hence no kdc involvement is required at this processing step. an other statement which I think is somewhat misleading is given in section 6.3 of rfc 2752 in the context of user authentication at the router or the PDP: 'Send the Kerberos ticket to the KDC to obtain the session key. Using the session key authenticate the user.' if the service ticket is requested by the user for the router or the pdp then no involvement of the kdc is requried. ciao hannes From owner-rap@ops.ietf.org Wed Jul 18 16:10:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22458 for ; Wed, 18 Jul 2001 16:10:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MxM7-000DFB-00 for rap-data@psg.com; Wed, 18 Jul 2001 12:51:35 -0700 Received: from hypnos.cps.intel.com ([192.198.165.17]) by psg.com with esmtp (Exim 3.31 #1) id 15MxM6-000DEs-00 for rap@ops.ietf.org; Wed, 18 Jul 2001 12:51:34 -0700 Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id TAA02701; Wed, 18 Jul 2001 19:51:25 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 18 Jul 2001 19:51:25 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Jul 2001 12:51:23 -0700 Message-ID: From: "Hess, Rodney" To: "'Hannes.Tschofenig@mchp.siemens.de'" , rap@ops.ietf.org Subject: RE: "Identity Representation for RSVP" question Date: Wed, 18 Jul 2001 12:51:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Hey, Hannes, The statement you high lighted from Section 6.3 is in error. Sending the Kerberos ticket to the KDC is unnecessary to obtain the session key as the ticket already contains the key. This will be fixed in the next draft. Rodney Hess rodney.hess@intel.com -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@mchp.siemens.de] Sent: Friday, June 29, 2001 3:01 AM To: rap@ops.ietf.org Subject: "Identity Representation for RSVP" question hi in section 6.3. of the verification procedure of the user credentials are explained: "Kerberos: Send the Kerberos ticket to the KDC to obtain the session key. Using the session key authenticate the user.". why should the router/pdp send the ticket to the kdc? ciao hannes From owner-rap@ops.ietf.org Wed Jul 18 19:15:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00620 for ; Wed, 18 Jul 2001 19:15:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15N0Oq-000MIt-00 for rap-data@psg.com; Wed, 18 Jul 2001 16:06:36 -0700 Received: from jffdns01.or.intel.com ([134.134.248.3] helo=ganymede.or.intel.com) by psg.com with esmtp (Exim 3.31 #1) id 15N0Op-000MIl-00; Wed, 18 Jul 2001 16:06:35 -0700 Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id XAA23013; Wed, 18 Jul 2001 23:06:29 GMT Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 18 Jul 2001 23:06:29 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2653.19) id <3X1YFD1W>; Wed, 18 Jul 2001 16:06:27 -0700 Message-ID: <4148FEAAD879D311AC5700A0C969E8900655DE32@orsmsx35.jf.intel.com> From: "Hegde, Shriharsha" To: rap@ops.ietf.org, mpls@UU.NET, te-wg@ops.ietf.org Subject: FW: I-D ACTION:draft-hegde-mpls-setup-pib-00.txt Date: Wed, 18 Jul 2001 16:06:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C10FDE.417AD590" 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_000_01C10FDE.417AD590 Content-Type: text/plain; charset="iso-8859-1" Hi, Here is a way to setup MPLS LSPs. thanks, harsha -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, July 18, 2001 4:00 AM Subject: I-D ACTION:draft-hegde-mpls-setup-pib-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MultiProtocol Label Switching (MPLS) Setup Policy Information Base Author(s) : H. Hegde, R. Sahita Filename : draft-hegde-mpls-setup-pib-00.txt Pages : 32 Date : 17-Jul-01 This document specifies a set of provisioning classes (PRC) for configuring a MultiProtocol Label Switching (MPLS) router. Instances of these classes reside in a virtual information store called MPLS Setup Policy Information Base (PIB). COPS protocol [COPS] with the extensions for provisioning [COPS-PR] is used to transmit this MPLS Setup policy information to MPLS Routers. The PRCs defined in this MPLS Setup PIB are intended for use by the COPS-PR MPLS client type. They complement the PRCs defined in the Framework PIB [FR-PIB]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hegde-mpls-setup-pib-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hegde-mpls-setup-pib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hegde-mpls-setup-pib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01C10FDE.417AD590 Content-Type: message/rfc822 To: Subject: Date: Wed, 18 Jul 2001 16:06:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C10FDE.417AD590" ------_=_NextPart_002_01C10FDE.417AD590 Content-Type: text/plain ------_=_NextPart_002_01C10FDE.417AD590 Content-Type: application/octet-stream; name="ATT10250" Content-Disposition: attachment; filename="ATT10250" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010717133252.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hegde-mpls-setup-pib-00.txt ------_=_NextPart_002_01C10FDE.417AD590 Content-Type: message/external-body; site="internet-drafts"; dir="draft-hegde-mpls-setup-pib-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C10FDE.417AD590-- ------_=_NextPart_000_01C10FDE.417AD590-- From owner-rap@ops.ietf.org Wed Jul 18 21:33:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25007 for ; Wed, 18 Jul 2001 21:33:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15N2U7-00036b-00 for rap-data@psg.com; Wed, 18 Jul 2001 18:20:11 -0700 Received: from fmfdns02.fm.intel.com ([132.233.247.11] helo=thalia.fm.intel.com) by psg.com with esmtp (Exim 3.31 #1) id 15N2U7-00036Q-00 for rap@ops.ietf.org; Wed, 18 Jul 2001 18:20:11 -0700 Received: from fmsmsx19.fm.intel.com (fmsmsx19.fm.intel.com [132.233.222.210]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with ESMTP id BAA04877; Thu, 19 Jul 2001 01:20:02 GMT Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2653.19) id <3X1PLYQN>; Wed, 18 Jul 2001 18:20:00 -0700 Message-ID: From: "Hess, Rodney" To: "'Hannes.Tschofenig@mchp.siemens.de'" , rap@ops.ietf.org Subject: RE: Question to Kerberos/Multicast/RSVP Date: Wed, 18 Jul 2001 18:19:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Hey, Hannes, I assume you mean Section 7 of RFC 2747 as RFC 2474 is "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Header," which does not contain the text you are quoting. FYI, your question would also apply to . Yes, all receivers and the KDC must be preconfigured, either dynamically or statically, with the principal name before the reservation takes place. I suspect how this is accomplished is outside the scope of these documents; hence the short descriptions. If you feel you have a better approach, you are welcome to share its merits with the group. Rodney Hess rodney.hess@intel.com -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@mchp.siemens.de] Sent: Friday, June 29, 2001 3:01 AM To: rap@ops.ietf.org Subject: Question to Kerberos/Multicast/RSVP hi! in section 7 of rfc 2474 the use of multicast with kerberos is described as follows: "In the multicast case all receivers of a multicast RSVP message MUST share a single key with the KDC (e.g. the receivers are in effect the same security principal with respect to Kerberos)." is this an appropriate assumption since this requires that before starting a multicast session a new principal name must be created at the kdc and the information (principal name and key) must be send to the participating users (receivers). then the actual reservation can take place to make use of the above mentioned single key. the above mentioned procedure is required since it cannot be assumed that two principals are the same security principal. additionally this creates problems for accounting. am i missing something? how should the exact processing work? ciao hannes From owner-rap@ops.ietf.org Thu Jul 19 04:32:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA00222 for ; Thu, 19 Jul 2001 04:32:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15N9Ew-000Pwo-00 for rap-data@psg.com; Thu, 19 Jul 2001 01:32:58 -0700 Received: from mel.alcatel.fr ([212.208.74.132]) by psg.com with esmtp (Exim 3.31 #1) id 15N9Eq-000PuW-00 for rap@ops.ietf.org; Thu, 19 Jul 2001 01:32:56 -0700 Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id KAA18289 for ; Thu, 19 Jul 2001 10:30:10 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id KAA05839 for ; Thu, 19 Jul 2001 10:31:32 +0200 (MET DST) Received: from ms.ms.alcatel.fr (ms.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id KAA13206 for ; Thu, 19 Jul 2001 10:32:13 +0200 (MET DST) Received: from pc50062 ([188.9.248.194]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with SMTP id KAA26993; Thu, 19 Jul 2001 10:32:17 +0200 (MET DST) Message-ID: <009601c1102d$4dfcf240$c2f809bc@pc50062> From: "Yacine El Mghazli" To: Subject: draft-yacine-cops-an-00.txt Date: Thu, 19 Jul 2001 10:32:07 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0093_01C1103E.0F599370" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-rap@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0093_01C1103E.0F599370 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello all, Please find herewith a new ID describing a new COPS client type for active networks. Thanks, Yacine -- Title : COPS client-type for Active Networks Author(s) : Y. El Mghazli, O. Marce Filename : draft-yacine-cops-an-00.txt Pages : 9 Date : 13-Jul-01 This draft specifies a COPS (Common Open Policy Service, [COPS]) client-type designed for the enforcement of Active IP Networks (AN) policies. The usage of this AN COPS client-type is based upon the activation of the COPS protocol for policy provisioning purposes (COPS-PR, [COPS-PR]). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yacine-cops-an-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-yacine-cops-an-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-yacine-cops-an-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. -- Yacine El Mghazli ---------------------------------------------------------------------- Alcatel R&I Software and Services Strategic Program - VIPeR Marcoussis, France Tel +33 1 6963 4187 Fax +33 1 6963 1169 yacine.el_mghazli@ms.alcatel.fr ---------------------------------------------------------------------- ------=_NextPart_000_0093_01C1103E.0F599370 Content-Type: text/plain; name="draft-yacine-cops-an-00.txt" Content-Disposition: attachment; filename="draft-yacine-cops-an-00.txt" Content-Transfer-Encoding: 7bit Network Working Group Yacine El Mghazli Internet Draft Olivier Marce Document: draft-yacine-cops-an-00.txt Alcatel Category: Experimental June 2001 Expires: December 2001 COPS client-type for Active Networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [STD]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This draft specifies a COPS (Common Open Policy Service, [COPS]) client-type designed for the enforcement of Active IP Networks (AN) policies. The usage of this AN COPS client-type is based upon the activation of the COPS protocol for policy provisioning purposes (COPS-PR, [COPS-PR]). El Mghazli et al. Experimental - Expires December 2001 [Page 1] Internet Draft COPS client-type for Active Networks Jun. 2001 Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Table of Contents..................................................2 1. Introduction....................................................3 2. Terminology.....................................................4 3. Generic model of an AN policy enforcement scheme................4 4. An client-type specific information.............................5 4.1. Common Header, Client-Type....................................5 4.2. COPS messages content.........................................5 4.2.1 Request messages (REQ).......................................5 4.2.2 Decision messages (DEC)......................................5 4.2.3 Report messages (RPT)........................................6 5. COPS-PR usage of the AN client-type.............................6 6. Warning.........................................................7 7. IANA Considerations.............................................7 8. Security Considerations.........................................7 9. References......................................................7 10. Author Information and Acknowledgment..........................8 11. Full Copyright Statement.......................................8 El Mghazli et al. Experimental - Expires December 2001 [Page 2] Internet Draft COPS client-type for Active Networks Jun. 2001 1. Introduction Active networks presents a new paradigm for network service and protocol design. Based on fast growing software technologies, active network architecture provides an open programmable platform that offers users and applications the ability to customize or create new network services and protocols dynamically and to deploy them on the network infrastructure at runtime. The active networking concept offers a new perception of a network as a giant computing machine for communications. It is a network that allows application specific computation to be performed within the network. In effect, application specific processing that used to be done at end systems can be moved to execute inside the network. An active packet network is programmed through packets that contain programs or references. Those packets are called active packets. Users and applications employ active packets to describe, provision, and tailor network resources to design the desired network behaviour. An active IP network is composed of active routers. Since users are able to take advantage of network computing resource, there is a need for active packets admission control in order to prevent from any incorrect or forbidden emission of active packets which would flood or attack active routers. Within the context of this document, an active packet contains reference to downloadable code, located in a code repository or elsewhere. The actual enforcement of AN Policy is based upon the restricted usage of the network computing resource at active edge routers. The agreement reached by both the customer and the active network SP in terms of computing resource usage rights must be reflected in these nodes. From this standpoint, the COPS protocol and its usage for the support of Policy Provisioning is one of the ongoing specification effort of the Resource Allocation Protocol (rap) Working Group of the IETF that should help service providers in dynamically enforcing AN policy. To provide the edge router with the above-mentioned information, one possibility is to use the COPS protocol and its usage for policy provisioning. To do so, a new COPS client-type is specified, the Active Network client-type, and this specification effort is the purpose of this draft. The active packets can be sent prior to the flow containing the data to be processed ([ANEP]), or the data packets can be set active ([AN- OPT]. In both cases, when a PEP receives an active packet, it should outsource the decision of acceptance. This specific mechanism will be further described in a separate document. This document focuses on the provisioning of the AN policy, and does El Mghazli et al. Experimental - Expires December 2001 [Page 3] Internet Draft COPS client-type for Active Networks Jun. 2001 not care about the way this provisioning is triggered, for example by a manager, or by any kind of signalisation or even when an active packet starting a flow is received. The scope of this document is the active IP networks, and related layer 3 nodes only. It is not related at all to the policy provisioning for transmission devices. This document is organized into the following sections: - Section 3 introduces the generic architecture, - Section 4 describes the contents of the COPS messages that MUST include the AN client-type specific information, - Section 5 defines the usage of the AN client-type, including its mode of operation with the PDP (Policy Decision Point, [FRWK]) with whom a COPS communication has been established, - Finally, sections 7 and 8 introduce IANA and some security considerations, respectively. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [KEY]. 3. Generic model of an AN policy enforcement scheme To achieve AN Policy enforcement, the customers must declare to the SP the active code they intend to use and the computing resources they need to process the corresponding code. The enforcement of an Active networks policy is based upon the use of an AN policy server (PDP) that sends AN-related information (allowed references and reserved computing resources) to the PEP embedded in the active router. Following the framework for policy-based admission control [FRWK], the PDP provides the active router (PEP) with references towards process-able code for a specific user, and it allocates computing resources the execution of referenced code. The AN client-type is specified by the PEP to the PDP, and is unique for the area covered by the Active Networks policy, so that the PEP can treat all the COPS client-types it supports as non-overlapping and independent namespaces. The AN specific information in the router is stored and maintained in the AN Policy Information Base ([AN-PIB]), which will be accessed by the PDP to retrieve and update these data whenever necessary. The AN-related information is conveyed between the PDP and the PEP El Mghazli et al. Experimental - Expires December 2001 [Page 4] Internet Draft COPS client-type for Active Networks Jun. 2001 thanks to the establishment of a COPS-PR connection between these two entities. The COPS-PR protocol assumes a named data structure (the PIB), in order to identify the type and purpose of the policy information that is sent by the PDP to the PEP for the provisioning of a given policy. Within the context of this draft, the data structure of the PIB refers to Active Networks policy that is therefore described in the PIB as a specific PIB, namely the AN-PIB. AN-PRCs are instantiated as multiple PRIs (Policy Rule Instance), each of which being identified by Policy Rule Instance Identifier (PRID). A given PRI specifies the data content carried in the COPS-PR (AN client-type specific) objects. An AN PRI typically contains a value for each attribute that has been defined for the AN PRC, for example the reference to the code to be executed and the allocated computing resources. 4. AN client-type specific information This section describes the formalism that is specific to the use of an AN client-type, given that only the COPS messages that require an AN client-type specific definition are described in this section, i.e. the other COPS messages to be exchanged between a PEP that supports the AN client-type and a PDP, and which do not need to carry AN client-type specific information are those described in the corresponding [COPS] and [COPS-PR] documents, without any further elaboration. 4.1. Common Header, Client-Type The AN COPS client type must be registered with IANA. 4.2. COPS Message Content 4.2.1. Request messages (REQ) The REQ message is sent by the PEP with an AN client-type to issue a configuration request to the PDP, as specified in the COPS Context Object. The REQ message includes the current configuration information related to the enforcement of an Active Networks policy. In the context of Active Networks, this information consists in previously installed policies and computing capabilities. It means that the PEP describes its own available computing resources in order for the PDP to provision the router accordingly. As usual, such configuration information is encoded from the AN-PIB according to the ClientSI format that is defined for the Named ClientSI object of the REQ message ([COPS-PR]). El Mghazli et al. Experimental - Expires December 2001 [Page 5] Internet Draft COPS client-type for Active Networks Jun. 2001 4.2.2. Decision messages (DEC) DEC messages typically consist in "install" and/or "remove" Decisions. They contain references towards downloadable code associated with filters in order to identify a specific user IP active flow, as well as allocated computing resources. Such information is encoded from the PIB according to the Decision format that is defined for the Named Decision Data object of the DEC message ([COPS-PR]). The details of the references and computing resources allocations is given in [AN-PIB]. 4.2.3. Report messages (RPT) The Report message allow the PEP to indicate to the PDP that a particular set of AN policy provisioning instances have been successfully or unsuccessfully installed/removed. Note that the AN related RPT messages containing report of type "Accounting" are carrying statistical information related to the usage of the active router computing resource. This statistical information MAY be used by the PDP to possibly modify the resource allocation. 5. COPS-PR usage of the AN client-type This section describes the provisioning of an AN policy enforcement. As mentioned in section 1, the manner the provisioning is triggered is not considered in this document. The Active Network paradigm is based on the assumption that the activation is carried in the data link, following the same path than data, and activating the traversed nodes. It is clear that the provisioning should be triggered by the active packets. After having opened a COPS connection with the PDP, the PEP sends a REQ message to the PDP that will contain a Client Handle. The Client Handle is used to identify a specific request state associated to the AN client-type supported by the PEP. The REQ message will contain a "Configuration Request" context object. This REQ message will also carry the named client specific information -- including the (default) configuration information, as described in section 4.2.1.of the draft. By "default" configuration information, it must be understood the default values that have been instantiated in the AN-PIB. El Mghazli et al. Experimental - Expires December 2001 [Page 6] Internet Draft COPS client-type for Active Networks Jun. 2001 The active node specific computing resources will be conveyed in specific (PRID, EPD) bindings in the REQ message as well. Upon receipt of the REQ message, the PDP will send back a DEC message towards the PEP. This DEC message will carry AN Named Decision Data object that will convey all the appropriate installation/removal of (PRID, EPD), as described in section 4.2.2 of this draft. One of the basic goals of this named Decision objects consist in allowing/making such a user to use such a reference to download a code in the node. Upon receipt of a DEC message, the PEP and the AN client-type it supports will (try to) enforce the corresponding AN decisions by installing the named AN policy data (e.g. to assign a metric value to a recently-installed interface). Then, the PEP will notify the PDP about the actual enforcement of the named AN policy decision data, by sending the appropriate RPT message back to the PDP. The RPT message MAY also carry the "Accounting" report-type, as described in section 5.2.3.of this draft. 6. Warning The Active Networks domain is emerging today and there is no adopted solution yet. Firstly, the concerns of this draft is restricted to a single way to trigger an active behavior of a network. There are other means to realize it and subsequently other means to apply policy on Active Networks. One could simply outsource a AN specific signalisation, like today RSVP messages are outsourced for admission control purposes. Secondly, even in the restricted context of this draft, specifications can slightly evolve and the AN COPS client-type would have to follow these changes. 7. IANA Considerations Section 4.1.of this draft has identified a need for the assignment of a specific number that will uniquely identify the AN client-type in every COPS message to be exchanged between a PEP and a PDP. This value SHOULD be chosen in the range of 0x8000 - 0xFFFF,according to a First Come First Served policy, as mentioned in both [COPS] and [IANA]. 8. Security Considerations This draft specifies a new client-type that will make use of the COPS protocol for the provisioning and the enforcement of AN policies El Mghazli et al. Experimental - Expires December 2001 [Page 7] Internet Draft COPS client-type for Active Networks Jun. 2001 within IP networks. As such, it introduces no new security issues over the COPS protocol itself, or its usage for policy provisioning. 9. References [STD] Bradner S.,"The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [COPS] Boyle J., Cohen R., Durham D., Herzog S., Raja R., Sastry A., "The COPS (Common Open Policy Service) Protocol", RFC 2748, Proposed Standard, January 2000. [COPS-PR] Ho Chan K., Durham D., Gai S., Herzog S., McLoghrie K., Reichmeyer F., Seligson J., Smith A., Yavatkar R., "COPS Usage for Policy Provisioning (COPS-PR)", RFC3084, March 2001. [FRWK] Yavatkar R., Pendarakis D., Guerin R., "A Framework for Policy-Based Admission Control", RFC 2753, January 2000. [ANEP] D. Scott Alexander, Bob Braden, Carl A. Gunter, Alden W. Jackson, Angelos D. Keromytis, Gary J. Minden, David Wetherall, "Active Networks Encapsulation Protocol", July 1997. [AN-OPT] David J. Wetherall, David L. Tennenhouse, "The Active IP option", September 1996. [KEY] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [AN-PIB] , "An Active Networks Policy Information Base", Work in Progress. [IANA] Alvestrand H., Narten T., "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 10. Author Information and Aknowledgement Yacine El Mghazli Alcatel R&I VIPeR Project Route de Nozay F-91460 Marcoussis France Phone : +33 1 69 63 41 87 Email : yacine.el_mghazli@ms.alcatel.fr El Mghazli et al. Experimental - Expires December 2001 [Page 8] Internet Draft COPS client-type for Active Networks Jun. 2001 Olivier Marce Alcatel R&I Active Networks Seed Project Route de Nozay F-91460 Marcoussis France Phone : +33 1 69 63 41 67 Email : olivier.marce@ms.alcatel.fr Special thanks to Nathalie Charton & Damien Galand. 11. Full Copyright Statement Copyright(C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. El Mghazli et al. Experimental - Expires December 2001 [Page 9] ------=_NextPart_000_0093_01C1103E.0F599370-- From owner-rap@ops.ietf.org Thu Jul 19 07:06:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28776 for ; Thu, 19 Jul 2001 07:06:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NBeH-0006z1-00 for rap-data@psg.com; Thu, 19 Jul 2001 04:07:17 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.31 #1) id 15NBeH-0006yv-00 for rap@ops.ietf.org; Thu, 19 Jul 2001 04:07:17 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28567; Thu, 19 Jul 2001 07:06:20 -0400 (EDT) Message-Id: <200107191106.HAA28567@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rap@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rap-access-bind-00.txt Date: Thu, 19 Jul 2001 07:06:19 -0400 Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : Framework for Binding Access Control to COPS Provisioning Author(s) : W. Weiss et al. Filename : draft-ietf-rap-access-bind-00.txt Pages : 77 Date : 18-Jul-01 There is an ever-growing distinction between edge and core functionality. While the core continues to focus on stability and pure forwarding functionality, the edges increasingly need to deal with dynamic capabilities like QoS management, VPN encapsulations, encryption, dynamic steering and service monitoring. The dynamic deployment of these functions is dependent on specific contextual knowledge such as the physical location of the data stream and the identity of the client or system generating the data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-access-bind-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-access-bind-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-access-bind-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010718142335.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-access-bind-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-access-bind-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010718142335.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Thu Jul 19 07:20:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01310 for ; Thu, 19 Jul 2001 07:20:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NBeD-0006y7-00 for rap-data@psg.com; Thu, 19 Jul 2001 04:07:13 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.31 #1) id 15NBeC-0006xc-00 for rap@ops.ietf.org; Thu, 19 Jul 2001 04:07:12 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28536; Thu, 19 Jul 2001 07:06:15 -0400 (EDT) Message-Id: <200107191106.HAA28536@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rap@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rap-cops-frwk-00.txt Date: Thu, 19 Jul 2001 07:06:15 -0400 Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : An Architecture for COPS Based Policy Control Management Framework Author(s) : K. Chan Filename : draft-ietf-rap-cops-frwk-00.txt Pages : 3 Date : 18-Jul-01 This document describes an architecture for a COPS based Policy Control Management System Framework. The architecture is designed to be modular, allowing future modification and addition to existing framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-frwk-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-cops-frwk-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-cops-frwk-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010718142326.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-cops-frwk-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-cops-frwk-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010718142326.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Fri Jul 20 04:04:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13869 for ; Fri, 20 Jul 2001 04:04:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NVGm-000NwO-00 for rap-data@psg.com; Fri, 20 Jul 2001 01:04:20 -0700 Received: from goliath.siemens.de ([194.138.37.131]) by psg.com with esmtp (Exim 3.31 #1) id 15NVGl-000NwD-00 for rap@ops.ietf.org; Fri, 20 Jul 2001 01:04:19 -0700 X-Envelope-Sender-Is: Hannes.Tschofenig@mchp.siemens.de (at relayer goliath.siemens.de) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.1/8.11.1) with ESMTP id f6K84Gb02664; Fri, 20 Jul 2001 10:04:16 +0200 (MET DST) Received: from sn52sun1 (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail3.siemens.de (8.11.4/8.11.4) with SMTP id f6K84GI26968473; Fri, 20 Jul 2001 10:04:16 +0200 (MEST) Reply-To: From: "Hannes Tschofenig" To: "Hess, Rodney" , Subject: RE: Question to Kerberos/Multicast/RSVP Date: Fri, 20 Jul 2001 10:05:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit # hi rodney! Hey, Hannes, I assume you mean Section 7 of RFC 2747 as RFC 2474 is "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Header," which does not contain the text you are quoting. FYI, your question would also apply to . # yes - a typo. Yes, all receivers and the KDC must be preconfigured, either dynamically or statically, with the principal name before the reservation takes place. I suspect how this is accomplished is outside the scope of these documents; hence the short descriptions. If you feel you have a better approach, you are welcome to share its merits with the group. # maybe your are right with the statement that this should be outside the scope # of the document. but in the case of roaming users a kerberos based authentication is # more difficult to accomplish if the principal name and the realm name of the # first hop router (or pdp) are unknown # and no specific procedure is specified to obtain this information. # there may be some mechanisms to learn the identity of the first hop router # (or pdp) to which the user # should authenticate but it seems to be difficult for a mobile node to quickly # figure this out. hence it seems that the approach of using kerberos is well suited # for stationary environments where everything is pre-defined (see windows 2000) but # in the mobile case some issues are still open. # ciao # hannes Rodney Hess rodney.hess@intel.com From owner-rap@ops.ietf.org Fri Jul 20 05:39:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07514 for ; Fri, 20 Jul 2001 05:39:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NWk8-0000ow-00 for rap-data@psg.com; Fri, 20 Jul 2001 02:38:44 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.31 #1) id 15NWk7-0000ok-00 for rap@ops.ietf.org; Fri, 20 Jul 2001 02:38:43 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06696; Fri, 20 Jul 2001 05:37:45 -0400 (EDT) Message-Id: <200107200937.FAA06696@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rap@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rap-modify-sender-behavior-00.txt Date: Fri, 20 Jul 2001 05:37:44 -0400 Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : RSVP ErrorValues Used to Modify Sender Behavior Author(s) : R. Santitoro, R. Pabbati, Y. Bernet Filename : draft-ietf-rap-modify-sender-behavior-00.txt Pages : 7 Date : 19-Jul-01 This draft defines several mechanisms by which network policies can use RSVP signaling to control the behavior of compliant sending applications. Specifically, two new error codes are defined for use in the RSVP Policy Data object [RFC 2752]. In addition, a new use of the DCLASS object [RFC 2996] is defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-modify-sender-behavior-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-modify-sender-behavior-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-modify-sender-behavior-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010719150140.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-modify-sender-behavior-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-modify-sender-behavior-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010719150140.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Fri Jul 20 06:03:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07515 for ; Fri, 20 Jul 2001 05:39:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NWk2-0000oi-00 for rap-data@psg.com; Fri, 20 Jul 2001 02:38:38 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.31 #1) id 15NWk1-0000oV-00 for rap@ops.ietf.org; Fri, 20 Jul 2001 02:38:38 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06652; Fri, 20 Jul 2001 05:37:39 -0400 (EDT) Message-Id: <200107200937.FAA06652@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rap@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rap-session-auth-01.txt Date: Fri, 20 Jul 2001 05:37:39 -0400 Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : Framework for session set-up with media authorization Author(s) : L. Hamer, B. Gage Filename : draft-ietf-rap-session-auth-01.txt Pages : 24 Date : 19-Jul-01 Establishing multimedia streams must take into account requirements for end-to-end QoS, authorization of network resource usage and accurate accounting for resources used. During session set up, policies may be enforced to ensure that the media streams being requested lie within the bounds of the service profile established for the requesting host. Similarly, when a host requests resources to provide a certain QoS for a packet flow, policies may be enforced to ensure that the required resources lie within the bounds of the resource profile established for the requesting host. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-session-auth-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-session-auth-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-session-auth-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010719150131.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-session-auth-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-session-auth-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010719150131.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Fri Jul 20 18:16:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11334 for ; Fri, 20 Jul 2001 18:16:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Ni1b-000Knl-00 for rap-data@psg.com; Fri, 20 Jul 2001 14:41:31 -0700 Received: from [64.223.136.42] (helo=postal.ellacoya.com) by psg.com with esmtp (Exim 3.31 #1) id 15Ni1a-000KmP-00 for rap@ops.ietf.org; Fri, 20 Jul 2001 14:41:30 -0700 Received: from ellacoya.com (mstevens.eng.ellacoya.com [192.168.121.248]) by postal.ellacoya.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PJG9CVA6; Fri, 20 Jul 2001 17:40:58 -0400 Message-ID: <3B58A56E.5780374A@ellacoya.com> Date: Fri, 20 Jul 2001 17:41:02 -0400 From: "Mark L. Stevens" Organization: Ellacoya Networks X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: rap@ops.ietf.org Subject: IETF RAP Working Group Meeting AGENDA for 51st IETF Meeting Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit IETF RAP Working Group Meeting AGENDA for 51st IETF Meeting London August 5 - 10, 2001 ------------------------------------------------------------------- Co-chairs: Mark Stevens mstevens@ellacoya.com Scott Hahn Scott.Hahn@intel.com ------------------------------------------------------------------- Meeting Times/Places ------------------------------------------------------------------- Monday, August 6, 2001 1930-2200 Evening Session Palace Suite/Blenheim OPS rap Resource Allocation Protocol WG ------------------------------------------------------------------- Tuesday, August 7, 2001 1300-1400 Afternoon Session I Palace Suite/Buckingham OPS rap Resource Allocation Protocol WG ------------------------------------------------------------------- Agenda Greetings and Request for Minutes Takers Bluesheet Distribution Agenda Bashing Brief Review of Milestones and Status on Existing Work - Mark Stevens/Kwok Ho Chan http://www.ietf.org/internet-drafts/draft-ietf-rap-modify-sender-behaviour-00.txt Discussions: Binding Access to Provisioning Data - Walter Weiss http://www.ietf.org/internet-drafts/draft-ietf-rap-access-bind-00.txt Framework Policy Information Base - Kwok Ho Chan/Ravi Sahita http://www.ietf.org/internet-drafts/draft-ietf-rap-frameworkpib-05.txt Diffserv PIB - Kwok Ho Chan http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pib-04.txt COPS Framework/Framework for session set-up with media authorization - Kwok Ho Chan http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-frwk-05.txt http://www.ietf.org/internet-drafts/draft-ietf-rap-session-auth-00.txt Feedback Framework and Feedback PIB - Diana Rawlins http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-frwk-00.txt http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-fr-pib-00.txt http://www.ietf.org/internet-drafts/draft-rawlins-rsvppcc-pib-02.txt RSVP drafts - Rodney Hess http://www.ietf.org/internet-drafts/draft-ietf-rap-new-rsvp-ext-00.txt http://www.ietf.org/internet-drafts/draft-ietf-rap-rsvp-better-identity-00.txt http://www.ietf.org/internet-drafts/draft-ietf-rap-auth-policy-data-00.txt IP Traffic Engineering PIB - Christian Jacquenet http://www.ietf.org/internet-drafts/draft-jacquenet-ip-te-pib-00.txt COPS Usage for SLS negotiation (COPS-SLS) - Thi Mai Trang Nguyen http://www.ietf.org/internet-drafts/draft-nguyen-rap-cops-sls-00.txt From owner-rap@ops.ietf.org Fri Jul 27 07:39:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08646 for ; Fri, 27 Jul 2001 07:39:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Q5kg-000GnL-00 for rap-data@psg.com; Fri, 27 Jul 2001 04:25:54 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.31 #1) id 15Q5kf-000GnE-00 for rap@ops.ietf.org; Fri, 27 Jul 2001 04:25:53 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07807; Fri, 27 Jul 2001 07:24:52 -0400 (EDT) Message-Id: <200107271124.HAA07807@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rap@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rap-rsvp-better-identity-01.txt Date: Fri, 27 Jul 2001 07:24:51 -0400 Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : Identity Representation for RSVP Author(s) : R. Hess et al. Filename : draft-ietf-rap-rsvp-better-identity-01.txt Pages : 20 Date : 26-Jul-01 This document describes the representation of identity information in POLICY_DATA objects [POL-EXT] for supporting policy based admission control in RSVP [RFC 2205]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-rsvp-better-identity-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-rsvp-better-identity-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-rsvp-better-identity-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010726171155.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-rsvp-better-identity-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-rsvp-better-identity-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010726171155.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Fri Jul 27 10:45:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23127 for ; Fri, 27 Jul 2001 10:45:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Q8sO-00023I-00 for rap-data@psg.com; Fri, 27 Jul 2001 07:46:04 -0700 Received: from infres-192.enst.fr ([137.194.192.1] helo=infres.enst.fr) by psg.com with esmtp (Exim 3.31 #1) id 15Q8sN-00023A-00 for rap@ops.ietf.org; Fri, 27 Jul 2001 07:46:03 -0700 Received: from yahoo.com (dragon.enst.fr [137.194.192.44]) by infres.enst.fr (Postfix) with ESMTP id 80C9C1893 for ; Fri, 27 Jul 2001 16:46:01 +0200 (MEST) Message-ID: <3B617F98.9E325409@yahoo.com> Date: Fri, 27 Jul 2001 16:50:00 +0200 From: Nguyen Thi Mai Trang Organization: ENST - INFRES X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: rap@ops.ietf.org Subject: draft about COPS-SLS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello all, I would like to present a new COPS client type for SLS negotiation. You can see the draft at this URL : http://www.ietf.org/internet-drafts/draft-nguyen-rap-cops-sls-00.txt Any comments or questions are greatly appreciated. Thank you very much. Mai Trang ---------------------------------------------------- Nguyen Thi Mai Trang Ecole Nationale Superieure des Telecommunications Dept. INFRES - Bur. C234-4 46 Rue Barrault - 75013 Paris Tel: 01 45 81 74 61 - Fax : 01 45 81 31 19 email : trnguyen@enst.fr From owner-rap@ops.ietf.org Mon Jul 30 21:24:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05843 for ; Mon, 30 Jul 2001 21:24:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15ROGb-0008SU-00 for rap-data@psg.com; Mon, 30 Jul 2001 18:24:13 -0700 Received: from cms3.etri.re.kr ([129.254.16.13]) by psg.com with esmtp (Exim 3.31 #1) id 15ROGa-0008SO-00 for rap@ops.ietf.org; Mon, 30 Jul 2001 18:24:13 -0700 Received: from BJLEE (lbj63112.etri.re.kr [129.254.191.69]) by cms3.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PT43DBCD; Tue, 31 Jul 2001 10:22:40 +0900 Message-ID: <01be01c1195f$5cf28630$9afeffcb@BJLEE> From: =?ks_c_5601-1987?B?wMy6tMHY?= To: Subject: [Q] COPS Error Obj Date: Tue, 31 Jul 2001 10:23:11 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit According to RFC 2748, the security and sequence number negotiation phase should be done only once. (page 29) If that statement is correct, then what Error Code the COPS Error Obj should contain when PEP tries to send another OPN message after negotiation is finished already, and PDP replies to that message with CC message? Thank you in advance, and sorry for this abrupt question. - - - Byung-Joon Lee, Network Architecture Team of ETRI lbj63112@etri.re.kr +82 42 860 1728 http://oopsla.snu.ac.kr/~bjlee From owner-rap@ops.ietf.org Mon Jul 30 21:38:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA07705 for ; Mon, 30 Jul 2001 21:38:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15ROVE-0008vE-00 for rap-data@psg.com; Mon, 30 Jul 2001 18:39:20 -0700 Received: from jffdns01.or.intel.com ([134.134.248.3] helo=ganymede.or.intel.com) by psg.com with esmtp (Exim 3.31 #1) id 15ROVE-0008tI-00 for rap@ops.ietf.org; Mon, 30 Jul 2001 18:39:20 -0700 Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id BAA08365; Tue, 31 Jul 2001 01:38:36 GMT Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 31 Jul 2001 01:38:36 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jul 2001 18:38:34 -0700 Message-ID: <10C8636AE359D4119118009027AE99870DA5D9D1@FMSMSX34> From: "Durham, David" To: "'???'" , rap@ops.ietf.org Subject: RE: [Q] COPS Error Obj Date: Mon, 30 Jul 2001 18:38:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ks_c_5601-1987" Sender: owner-rap@ops.ietf.org Precedence: bulk Error #14 Authentication Failure would be appropriate here. Cheers, -Dave > -----Original Message----- > From: lbj63112@etri.re.kr [mailto:lbj63112@etri.re.kr] > Sent: Monday, July 30, 2001 6:23 PM > To: rap@ops.ietf.org > Subject: [Q] COPS Error Obj > > > According to RFC 2748, the security and sequence number > negotiation phase should be done only once. (page 29) > If that statement is correct, then what Error Code the COPS Error Obj > should contain when PEP tries to send another OPN message > after negotiation is finished already, and PDP replies to that message > with CC message? > > Thank you in advance, and sorry for this abrupt question. > > - - - > Byung-Joon Lee, > Network Architecture Team of ETRI > lbj63112@etri.re.kr +82 42 860 1728 > http://oopsla.snu.ac.kr/~bjlee > > > > From owner-rap@ops.ietf.org Mon Jul 30 21:52:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA08530 for ; Mon, 30 Jul 2001 21:52:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15ROi7-0009Hu-00 for rap-data@psg.com; Mon, 30 Jul 2001 18:52:39 -0700 Received: from cms3.etri.re.kr ([129.254.16.13]) by psg.com with esmtp (Exim 3.31 #1) id 15ROi5-0009Hf-00 for rap@ops.ietf.org; Mon, 30 Jul 2001 18:52:39 -0700 Received: from BJLEE (lbj63112.etri.re.kr [129.254.191.69]) by cms3.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PT43DBD3; Tue, 31 Jul 2001 10:51:01 +0900 Message-ID: <020001c11963$5252f670$9afeffcb@BJLEE> From: =?ks_c_5601-1987?B?wMy6tMHY?= To: "Durham, David" , References: <10C8636AE359D4119118009027AE99870DA5D9D1@FMSMSX34> Subject: Re: [Q] COPS Error Obj Date: Tue, 31 Jul 2001 10:51:31 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sorry for Another Question. When sending CC message to PEP in that case, Integrity Obj should be included in it? ----- Original Message ----- From: "Durham, David" To: "'???'" ; Sent: Tuesday, July 31, 2001 10:38 AM Subject: RE: [Q] COPS Error Obj > Error #14 Authentication Failure would be appropriate here. > Cheers, > -Dave > > > -----Original Message----- > > From: lbj63112@etri.re.kr [mailto:lbj63112@etri.re.kr] > > Sent: Monday, July 30, 2001 6:23 PM > > To: rap@ops.ietf.org > > Subject: [Q] COPS Error Obj > > > > > > According to RFC 2748, the security and sequence number > > negotiation phase should be done only once. (page 29) > > If that statement is correct, then what Error Code the COPS Error Obj > > should contain when PEP tries to send another OPN message > > after negotiation is finished already, and PDP replies to that message > > with CC message? > > > > Thank you in advance, and sorry for this abrupt question. > > > > - - - > > Byung-Joon Lee, > > Network Architecture Team of ETRI > > lbj63112@etri.re.kr +82 42 860 1728 > > http://oopsla.snu.ac.kr/~bjlee > > > > > > > > From owner-rap@ops.ietf.org Tue Jul 31 09:54:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15979 for ; Tue, 31 Jul 2001 09:54:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15RZyY-0006uO-00 for rap-data@psg.com; Tue, 31 Jul 2001 06:54:22 -0700 Received: from mumm.ibr.cs.tu-bs.de ([134.169.34.190] ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15RZyX-0006uH-00 for rap@ops.ietf.org; Tue, 31 Jul 2001 06:54:21 -0700 Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id PAA05380; Tue, 31 Jul 2001 15:54:15 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id PAA17334; Tue, 31 Jul 2001 15:54:15 +0200 Date: Tue, 31 Jul 2001 15:54:15 +0200 Message-Id: <200107311354.PAA17334@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: rap@ops.ietf.org Subject: INET-ADDRESS-MIB and Sender: owner-rap@ops.ietf.org Precedence: bulk The latest revision of the INET-ADDRESS-MIB in allows to share InetAddressType values and it introduces some new TCs that you may want to use. In particular, you may want to consider to change FrwkIpFilterEntry ::= SEQUENCE { frwkIpFilterDstAddrType InetAddressType, frwkIpFilterDstAddr InetAddress, frwkIpFilterDstAddrMask Unsigned32, frwkIpFilterSrcAddrType InetAddressType, frwkIpFilterSrcAddr InetAddress, frwkIpFilterSrcAddrMask Unsigned32, frwkIpFilterDscp Integer32, frwkIpFilterProtocol Integer32, frwkIpFilterDstL4PortMin Unsigned32, frwkIpFilterDstL4PortMax Unsigned32, frwkIpFilterSrcL4PortMin Unsigned32, frwkIpFilterSrcL4PortMax Unsigned32 } to the following: FrwkIpFilterEntry ::= SEQUENCE { frwkIpFilterAddrType InetAddressType, frwkIpFilterDstAddr InetAddress, frwkIpFilterDstAddrPrefix InetAddressPrefixLength, frwkIpFilterSrcAddr InetAddress, frwkIpFilterSrcAddrPrefix InetAddressPrefixLength, frwkIpFilterDscp Integer32, frwkIpFilterProtocol Unsigned32, frwkIpFilterDstL4PortMin InetPortNumber, frwkIpFilterDstL4PortMax InetPortNumber, frwkIpFilterSrcL4PortMin InetPortNumber, frwkIpFilterSrcL4PortMax InetPortNumber } This brings the filter definition more or less inline with the definition in the diffserv MIB. Note that there is also a TC for the DSCP code point you can consider to use (although this creates an additional dependency to the diffserv MIB). /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-rap@ops.ietf.org Tue Jul 31 19:25:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02708 for ; Tue, 31 Jul 2001 19:25:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Rita-000KIz-00 for rap-data@psg.com; Tue, 31 Jul 2001 16:25:50 -0700 Received: from hypnos.cps.intel.com ([192.198.165.17]) by psg.com with esmtp (Exim 3.31 #1) id 15Rita-000KIt-00 for rap@ops.ietf.org; Tue, 31 Jul 2001 16:25:50 -0700 Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id XAA26334; Tue, 31 Jul 2001 23:25:46 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 31 Jul 2001 23:25:45 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 16:25:44 -0700 Message-ID: <10C8636AE359D4119118009027AE99870DA5D9E0@FMSMSX34> From: "Durham, David" To: "'???'" , "Durham, David" , rap@ops.ietf.org Subject: RE: [Q] COPS Error Obj Date: Tue, 31 Jul 2001 16:25:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="KS_C_5601-1987" Sender: owner-rap@ops.ietf.org Precedence: bulk > -----Original Message----- > From: lbj63112@etri.re.kr [mailto:lbj63112@etri.re.kr] > Sent: Monday, July 30, 2001 6:52 PM > To: Durham, David; rap@ops.ietf.org > Subject: Re: [Q] COPS Error Obj > > > Sorry for Another Question. > When sending CC message to PEP in that case, > Integrity Obj should be included in it? [Dave] Yes it should be included (though not including it will acheive the same result:-) ). > > > ----- Original Message ----- > From: "Durham, David" > To: "'???'" ; > Sent: Tuesday, July 31, 2001 10:38 AM > Subject: RE: [Q] COPS Error Obj > > > > Error #14 Authentication Failure would be appropriate here. > > Cheers, > > -Dave > > > > > -----Original Message----- > > > From: lbj63112@etri.re.kr [mailto:lbj63112@etri.re.kr] > > > Sent: Monday, July 30, 2001 6:23 PM > > > To: rap@ops.ietf.org > > > Subject: [Q] COPS Error Obj > > > > > > > > > According to RFC 2748, the security and sequence number > > > negotiation phase should be done only once. (page 29) > > > If that statement is correct, then what Error Code the > COPS Error Obj > > > should contain when PEP tries to send another OPN message > > > after negotiation is finished already, and PDP replies to > that message > > > with CC message? > > > > > > Thank you in advance, and sorry for this abrupt question. > > > > > > - - - > > > Byung-Joon Lee, > > > Network Architecture Team of ETRI > > > lbj63112@etri.re.kr +82 42 860 1728 > > > http://oopsla.snu.ac.kr/~bjlee > > > > > > > > > > > > > >