From owner-aaa-bof@merit.edu Fri Jun 1 06:01:46 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03504 for ; Fri, 1 Jun 2001 06:01:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6E31A912E9; Fri, 1 Jun 2001 06:01:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 487B0912ED; Fri, 1 Jun 2001 06:01:29 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 52285912E9 for ; Fri, 1 Jun 2001 06:01:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7D5375DD8E; Fri, 1 Jun 2001 06:00:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 9A8995DD8D for ; Fri, 1 Jun 2001 06:00:53 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f51A0cN15285 for ; Fri, 1 Jun 2001 12:00:38 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Fri Jun 01 12:00:37 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Jun 2001 12:00:37 +0200 Message-ID: <577066326047D41180AC00508B955DDA02C00A2D@eestqnt104.es.eu.ericsson.se> From: "Yolanda Garcia-Serrano (ECE)" To: "'pcalhoun@diameter.org'" , "'aaa-wg@merit.edu'" Subject: [AAA-WG]: [#issue 55] Accounting clarifications Date: Fri, 1 Jun 2001 12:00:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA03504 Hi, Pat Here I send you an official new issue from something already brought up in the Mailing-list. Thanks /Yolanda García -----Original Message----- From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] Sent: Monday, May 28, 2001 9:43 AM To: Yolanda Garcia-Serrano (ECE) Cc: 'pcalhoun@diameter.org'; 'aaa-wg@merit.edu' Subject: Re: [AAA-WG]: Accounting clarifications Replying to an old e-mail on accounting issues, hope this helps: Yolanda Garcia-Serrano (ECE) wrote: > 12.5. Accounting-Records > What can be exactly an accounted service? Is it an extension (Mobile IP, NASREQ), or is it indicated > by Service-Type AVP in NASREQ, but in Mobile IP which is the service/s? Could be the text more specific, > giving some examples? This was already discussed earlier on the list. In general the service could be anything, and the included AVPs must specify what service was provided. What AVPs are used for this specification is service-specific. > 14.1 Accounting-Record-Type > Are EVENT_RECORDs (one-time events) and START-STOP records mutually exclusive for the same > Session-Id, i.e. if received an event record for sessionId=x.abc.com:8888:1234567890 is/is not possible > to receive a Start/interim/stop one for same sessionId=x.abc.com:8888:1234567890 ? I think we should have just one submitted event or start-stop for one session-id. There is definately sometimes a need to correlate several records related to the same true user session. However, at a diameter level this is often not possible. Rather, such coordination should be left up to the postprocessing systems. For instance, one box could be delivering NASREQ data, including the user's IP address while another box might be providing some additional service. Both records would contain IP addresses which would help the postprocessing systems in correlating the records even if they came from two different boxes. And as you indicate below, there is a need to clarify this text in the draft. I propose that we add a statement to the explanation of the session id AVP that prohibits the submission of several sessions with the same session id, and says that the type of the session must be one of event or start-interim-stop for a particular session id. > > Is the type or record (EVENT vs START/INTERIM/STOP) tight to the particular kind of service, so that > when some services are used, it is reported accounted info of kind EVENT, and when some other services > are used, it is reported accounted info in the style Start/Interim/Stop ? This should be dictated by the text appearing in a particular extension document. > > Is it possible to send (Diameter client)/receive (Accounting server) several EVENT_RECORD for the same > Session-Id? > > Same question but for measurable length services: is it possible to send/receive several START-STOP > sequences for the same Session-Id? For both, see above. > > For the answer of all these questions, could be added the corresponding clarifying text on the I-D? > It would be quite helpful. I agree. Jari From owner-aaa-bof@merit.edu Fri Jun 1 09:00:54 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07214 for ; Fri, 1 Jun 2001 09:00:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1FB77912F3; Fri, 1 Jun 2001 08:54:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E5672912F4; Fri, 1 Jun 2001 08:54:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 97093912F3 for ; Fri, 1 Jun 2001 08:54:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1E8AC5DDA2; Fri, 1 Jun 2001 08:54:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id 8C1EC5DD8D for ; Fri, 1 Jun 2001 08:54:43 -0400 (EDT) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 155oRl-000Ddd-00 for aaa-wg@merit.edu; Fri, 01 Jun 2001 05:54:33 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: aaa-wg@merit.edu Subject: [AAA-WG]: WECA 'extending' RADIUS? Message-Id: Date: Fri, 01 Jun 2001 05:54:33 -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit via bert Story date(time): 05/29/2001(02:18 AM) Effort afoot to provide wireless LAN roaming InfoWorld Daily News via DowVision By John Cox, Network World Fusion InfoWorld.com A group of leading vendors is working to iron out the technical and financial details needed to let mobile wireless LAN users connect to almost any wireless ISP, similar to the way cell phone users can roam and use multiple carriers to complete calls. The Wireless Ethernet Compatibility Alliance (WECA), which includes Cisco, IBM, Intel, 3Com and Microsoft, is looking to forge relationships and network standards among wireless ISPs and eventually carriers that will enable roaming for 802.11b wireless LAN users. These standards will let vendors share subscriber usage and billing data, so no matter how many different ISPs' subscribers are used to make a connection from a plane, train or automobile, they only get one bill from their "home" ISP. According to WECA members involved in the roaming project, the public access wireless LANs now being deployed in airports, convention centers and even restaurants will create a burgeoning web of wireless LAN hot spots. These hot spots will let mobile workers, with 802.11b-equipped computers, connect over a shared 11M-bit/sec link to Internet-based services and corporate networks. Most wide-area wireless data links today are based on much slower cell phone nets. "What we're talking about is interservice provider roaming. As you go from a corporate to a public net, you want to have user ID and a password for the ISP. But you don't want to have a different one for every wireless ISP net that you might traverse," said Greg Homan, director of systems engineering at MobileStar Network of Richardson, Texas, and a spokesman for the Wireless Internet Service Provider Roaming (WISPr), a contingent within WECA that is preparing the roaming proposal. "Within a corporate wireless LAN, roaming among access points is handled as part of the 802.11b protocol." The group is a mix of service providers, LAN equipment vendors and PC makers, including Agere Systems, Dell, Enterasys and Nokia and wireless ISPs MobileStar and Wayport. A draft will be presented at the next WECA board meeting, June 13 in Helsinki, Finland. "Having roaming agreements is a great idea for any network," said Andy Kasznay, software engineer with Northeast Utilities in Berlin, Conn. The utility uses a cellular phone network to connect field workers with laptops or PDAs to corporate data. "We currently don't use 802.11b networks because there are only very limited locations where they're available and a limited number of providers." Kasznay is clear on what he'd want from such a service as proposed by WISPr. "One service provider with one bill," he said. "As far as cost is concerned, it must be similar in cost to dial-up connections from a hotel room, including the hotel fees and long-distance charges for an average user session, but with faster throughput [compared to dial up]." He's also convinced a WISPr service would be used mainly by the utility's traveling executives and managers, not by electricians and others in the field. "The area that our field force covers is far too broad to be served by such a network," Kasznay said. Other issues could slow the roaming proposal. For example, the reach of such a wireless LAN (WLAN) service will still be severely limited compared to the cell networks because 802.11b, sometimes called Wi-Fi, is a local network with a radio range of roughly 150 feet. The public access WLANs being created by the likes of wireless ISPs MobileStar and Wayport, initially will be found in urban, high-density areas. Most of these public WLANs are targeted at white-collar business travelers. Blue-collar mobile workers likely will have to rely on low-speed, but widespread, cell networks, such as Cellular Digital Packet Data nets, for accessing data wirelessly. In addition, the service providers that go forward with the WISPr roaming will have to ensure they're offering a simple connection process and a single bill to make such roaming a desirable service for target users. And then there are security concerns. Specifically, WISPr is looking to define a tag that users could tack onto their subscriber name. The tag will alert any WISP that the user requesting service is "owned" by some other provider. Data about the user and the service request will be passed to an independent clearinghouse, which would coordinate transactions among different parties-in this case, the WISPs. WISPr spokesman Homan said the arrangement will most likely use the Remote Authentication Dial-In User Service (RADIUS) protocol, which is widely used to coordinate authorization information between remote users and an authorization server. The clearinghouse would pass the user data to that user's WISP, which then completes the authentication, bills the user and makes the appropriate payment to the WISP serving as the user's access connection. Users can then access their home WISP services and, through the provider, their corporate net. WISPr members said the technology for sharing data between the ISPs is relatively straightforward and most of the complexity involves setting up standards for handling transactions between service providers. "The billing systems are key to this," Homan said. "We're extending the RADIUS protocol with specific [new] attributes, such as user name, time spent online, bytes in or out, and so on. We'll also have information about where the user is, through a location code, so we can return site-specific services to that user." A WISP subscriber from the U.S., gaining access via a wireless LAN service in a Swedish airport, would receive information in English, for example. Keeping it simple will be the key to user acceptance, said Jeff Manning, business development manager at Agere. "We've failed if this is difficult [to use]," he says. "Everyone has a vested interest in making this work." There will be significant investment. The overall 802.11b market is expected to keep growing at a healthy rate despite the economic slowdown, according to an April report by Cahners In-Stat. By 2005, the firm estimates that companies will be spending nearly $6.4 billion on WLAN equipment. Companies such as IBM, Compaq and Dell are introducing notebook PCs with built-in 802.11b radios and antennas. Adapter card vendors have just started bringing out 802.11b cards for handheld computers, such as those using the Microsoft PocketPC software. The carriers are watching the project closely, according to WISPr members. "There's a tremendous amount of work going on by all the carriers," said Allan Scott, business manager for the Americas at Agere. "They're all involved in Wi-Fi products. They're very quiet about it, but they're all doing it." The WISPr group has no set schedule to complete its work, so it's difficult to say exactly when 802.11b roaming will become reality. Agere's Manning says he hopes the group will have a final document by year-end. Users can expect to see roaming being implemented more widely in the next two years, with the pace accelerating as carriers get into the action as the number of WLAN clients surges, each one representing a potential subscriber for wireless data services. ------- end of forwarded message ------- From owner-aaa-bof@merit.edu Fri Jun 1 09:42:13 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08156 for ; Fri, 1 Jun 2001 09:42:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 84DA6912F4; Fri, 1 Jun 2001 09:42:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 52663912F5; Fri, 1 Jun 2001 09:42:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3C4BD912F4 for ; Fri, 1 Jun 2001 09:42:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BE17A5DDAC; Fri, 1 Jun 2001 09:42:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 6E0915DD8D for ; Fri, 1 Jun 2001 09:42:16 -0400 (EDT) Received: (qmail 12900 invoked by uid 500); 1 Jun 2001 13:31:51 -0000 Date: Fri, 1 Jun 2001 06:31:51 -0700 From: Pat Calhoun To: Taneli Haverinen Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Error signaling ('A' msg.) Message-ID: <20010601063151.I1078@charizard.diameter.org> Mail-Followup-To: Taneli Haverinen , Pat Calhoun , aaa-wg@merit.edu References: <3B1641E9.790B9AD7@lmf.ericsson.se> <20010531062921.C10291@charizard.diameter.org> <3B1772EE.8D2C50EA@lmf.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B1772EE.8D2C50EA@lmf.ericsson.se>; from Taneli.Haverinen@lmf.ericsson.se on Fri, Jun 01, 2001 at 01:48:14PM +0300 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Fri, Jun 01, 2001 at 01:48:14PM +0300, Taneli Haverinen wrote: > > > Chapter 9.1. (End-To-End Error Signaling) of the base protocol does not > > > seem to define what to do when an error occurs while processing an > > > Answer message. Earlier the situation was handled by sending an MRI, but > > > this command was eliminated recently. I noticed that this problem was > > > discussed in Pat's message "A proposal for the elimination of MRI" > > > (http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00110.html). In > > > that message it was proposed that a STR with a Termination-Cause should > > > be issued. I also noticed, that Issue #10 "Sessions that do not start" > > > deals with my question, but only in the case of authorization messages. > > > I wonder what is the procedure in a general case? > > > > So do you mean what one does if an accounting answer is received, > > with an error, or a bad STA or DWA? > > > > I believe that these are the only remanining messages that aren't > > covered by #10. > > Yes, I mean the ones you mentioned above, and also any > extension-specific or vendor-specific answer messages. > So if the message in question is used to create a session, or to extend the lifetime of a session, then #10 describes how to handle this. I don't think that there will be any additional extension-specific, or even vendor-specific answer messages that do not fall within this class, do you? As far as STA and DWA, I believe that there is nothing you can (nor should) do for the former. For the latter, I suppose you SHOULD shutdown the connection since if your peer cannot send a basic DW message correctly, then you've got bigger problems. PatC From owner-aaa-bof@merit.edu Fri Jun 1 09:44:01 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08191 for ; Fri, 1 Jun 2001 09:44:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A5CAE912F5; Fri, 1 Jun 2001 09:43:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 775E8912F6; Fri, 1 Jun 2001 09:43:55 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 40CFD912F5 for ; Fri, 1 Jun 2001 09:43:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D68375DDAC; Fri, 1 Jun 2001 09:44:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 4AA405DD8D for ; Fri, 1 Jun 2001 09:44:07 -0400 (EDT) Received: (qmail 12999 invoked by uid 500); 1 Jun 2001 13:33:42 -0000 Date: Fri, 1 Jun 2001 06:33:42 -0700 From: Pat Calhoun To: Randy Bush Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: WECA 'extending' RADIUS? Message-ID: <20010601063342.J1078@charizard.diameter.org> Mail-Followup-To: Randy Bush , aaa-wg@merit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from randy@psg.com on Fri, Jun 01, 2001 at 05:54:33AM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk Another case of a group of vendors finding the fact that RADIUS has an RFC is most convenient. Another reason for us to get done quickly :) PatC On Fri, Jun 01, 2001 at 05:54:33AM -0700, Randy Bush wrote: > via bert > > Story date(time): 05/29/2001(02:18 AM) > Effort afoot to provide wireless LAN roaming > InfoWorld Daily News via DowVision > > By John Cox, Network World Fusion InfoWorld.com > > A group of leading vendors is working to iron out the technical and > financial details needed to let mobile wireless LAN users connect > to almost any wireless ISP, similar to the way cell phone users can roam > and use multiple carriers to complete calls. > > The Wireless Ethernet Compatibility Alliance (WECA), which includes > Cisco, IBM, Intel, 3Com and Microsoft, is looking to forge > relationships and network standards among wireless ISPs and eventually > carriers that will enable roaming for 802.11b wireless LAN > users. These standards will let vendors share subscriber usage and > billing data, so no matter how many different ISPs' subscribers are > used to make a connection from a plane, train or automobile, they only > get one bill from their "home" ISP. > > According to WECA members involved in the roaming project, the public > access wireless LANs now being deployed in airports, > convention centers and even restaurants will create a burgeoning web of > wireless LAN hot spots. These hot spots will let mobile > workers, with 802.11b-equipped computers, connect over a shared > 11M-bit/sec link to Internet-based services and corporate > networks. Most wide-area wireless data links today are based on much > slower cell phone nets. > > "What we're talking about is interservice provider roaming. As you go > from a corporate to a public net, you want to have user ID and > a password for the ISP. But you don't want to have a different one for > every wireless ISP net that you might traverse," said Greg > Homan, director of systems engineering at MobileStar Network of > Richardson, Texas, and a spokesman for the Wireless Internet > Service Provider Roaming (WISPr), a contingent within WECA that is > preparing the roaming proposal. "Within a corporate wireless > LAN, roaming among access points is handled as part of the 802.11b > protocol." > > The group is a mix of service providers, LAN equipment vendors and PC > makers, including Agere Systems, Dell, Enterasys and Nokia > and wireless ISPs MobileStar and Wayport. A draft will be presented at > the next WECA board meeting, June 13 in Helsinki, Finland. > > "Having roaming agreements is a great idea for any network," said Andy > Kasznay, software engineer with Northeast Utilities in Berlin, > Conn. The utility uses a cellular phone network to connect field workers > with laptops or PDAs to corporate data. "We currently don't > use 802.11b networks because there are only very limited locations where > they're available and a limited number of providers." > > Kasznay is clear on what he'd want from such a service as proposed by > WISPr. "One service provider with one bill," he said. "As far > as cost is concerned, it must be similar in cost to dial-up connections > from a hotel room, including the hotel fees and long-distance > charges for an average user session, but with faster throughput > [compared to dial up]." > > He's also convinced a WISPr service would be used mainly by the > utility's traveling executives and managers, not by electricians and > others in the field. "The area that our field force covers is far too > broad to be served by such a network," Kasznay said. > > Other issues could slow the roaming proposal. For example, the reach of > such a wireless LAN (WLAN) service will still be severely > limited compared to the cell networks because 802.11b, sometimes called > Wi-Fi, is a local network with a radio range of roughly 150 > feet. The public access WLANs being created by the likes of wireless > ISPs MobileStar and Wayport, initially will be found in urban, > high-density areas. Most of these public WLANs are targeted at > white-collar business travelers. Blue-collar mobile workers likely will > have to rely on low-speed, but widespread, cell networks, such as > Cellular Digital Packet Data nets, for accessing data wirelessly. In > addition, the service providers that go forward with the WISPr roaming > will have to ensure they're offering a simple connection > process and a single bill to make such roaming a desirable service for > target users. And then there are security concerns. > > Specifically, WISPr is looking to define a tag that users could tack > onto their subscriber name. The tag will alert any WISP that the > user requesting service is "owned" by some other provider. Data about > the user and the service request will be passed to an > independent clearinghouse, which would coordinate transactions among > different parties-in this case, the WISPs. > > WISPr spokesman Homan said the arrangement will most likely use the > Remote Authentication Dial-In User Service (RADIUS) > protocol, which is widely used to coordinate authorization information > between remote users and an authorization server. The > clearinghouse would pass the user data to that user's WISP, which then > completes the authentication, bills the user and makes the > appropriate payment to the WISP serving as the user's access connection. > Users can then access their home WISP services and, > through the provider, their corporate net. > > WISPr members said the technology for sharing data between the ISPs is > relatively straightforward and most of the complexity > involves setting up standards for handling transactions between service > providers. > > "The billing systems are key to this," Homan said. "We're extending the > RADIUS protocol with specific [new] attributes, such as user > name, time spent online, bytes in or out, and so on. We'll also have > information about where the user is, through a location code, so > we can return site-specific services to that user." > > A WISP subscriber from the U.S., gaining access via a wireless LAN > service in a Swedish airport, would receive information in > English, for example. > > Keeping it simple will be the key to user acceptance, said Jeff Manning, > business development manager at Agere. "We've failed if this > is difficult [to use]," he says. "Everyone has a vested interest in > making this work." > > There will be significant investment. The overall 802.11b market is > expected to keep growing at a healthy rate despite the economic > slowdown, according to an April report by Cahners In-Stat. By 2005, the > firm estimates that companies will be spending nearly $6.4 > billion on WLAN equipment. Companies such as IBM, Compaq and Dell are > introducing notebook PCs with built-in 802.11b radios and > antennas. Adapter card vendors have just started bringing out 802.11b > cards for handheld computers, such as those using the > Microsoft PocketPC software. > > The carriers are watching the project closely, according to WISPr > members. "There's a tremendous amount of work going on by all > the carriers," said Allan Scott, business manager for the Americas at > Agere. "They're all involved in Wi-Fi products. They're very quiet > about it, but they're all doing it." > > The WISPr group has no set schedule to complete its work, so it's > difficult to say exactly when 802.11b roaming will become reality. > Agere's Manning says he hopes the group will have a final document by > year-end. Users can expect to see roaming being > implemented more widely in the next two years, with the pace > accelerating as carriers get into the action as the number of WLAN > clients surges, each one representing a potential subscriber for > wireless data services. > ------- end of forwarded message ------- From owner-aaa-bof@merit.edu Fri Jun 1 10:35:23 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08932 for ; Fri, 1 Jun 2001 10:35:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2E99B912FC; Fri, 1 Jun 2001 10:35:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 21E0F912FB; Fri, 1 Jun 2001 10:35:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EB9E9912F8 for ; Fri, 1 Jun 2001 10:34:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 79BFB5DDAD; Fri, 1 Jun 2001 10:34:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 241A95DDAC for ; Fri, 1 Jun 2001 10:34:19 -0400 (EDT) Received: (qmail 13914 invoked by uid 500); 1 Jun 2001 14:07:36 -0000 Date: Fri, 1 Jun 2001 07:07:36 -0700 From: Pat Calhoun To: "Yolanda Garcia-Serrano (ECE)" Cc: "'pcalhoun@diameter.org'" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: [#issue 55] Accounting clarifications Message-ID: <20010601070736.M1078@charizard.diameter.org> Mail-Followup-To: "Yolanda Garcia-Serrano (ECE)" , "'pcalhoun@diameter.org'" , "'aaa-wg@merit.edu'" References: <577066326047D41180AC00508B955DDA02C00A2D@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <577066326047D41180AC00508B955DDA02C00A2D@eestqnt104.es.eu.ericsson.se>; from yolanda.garcia-serrano@ece.ericsson.se on Fri, Jun 01, 2001 at 12:00:28PM +0200 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Fri, Jun 01, 2001 at 12:00:28PM +0200, Yolanda Garcia-Serrano (ECE) wrote: > Hi, Pat > Here I send you an official new issue from something already brought up > in the Mailing-list. May I ask that you actually submit the issue in the format that we've been using, as opposed to having me sift through this e-mail and guess what the issue should be? Thanks, PatC > > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Monday, May 28, 2001 9:43 AM > To: Yolanda Garcia-Serrano (ECE) > Cc: 'pcalhoun@diameter.org'; 'aaa-wg@merit.edu' > Subject: Re: [AAA-WG]: Accounting clarifications > > > > Replying to an old e-mail on accounting issues, hope this helps: > > Yolanda Garcia-Serrano (ECE) wrote: > > > 12.5. Accounting-Records > > What can be exactly an accounted service? Is it an extension (Mobile IP, NASREQ), or is it indicated > > by Service-Type AVP in NASREQ, but in Mobile IP which is the service/s? Could be the text more specific, > > giving some examples? > > This was already discussed earlier on the list. In general the service > could be anything, and the included > AVPs must specify what service was provided. What AVPs are used for this > specification is > service-specific. > > > 14.1 Accounting-Record-Type > > Are EVENT_RECORDs (one-time events) and START-STOP records mutually exclusive for the same > > Session-Id, i.e. if received an event record for sessionId=x.abc.com:8888:1234567890 is/is not possible > > to receive a Start/interim/stop one for same sessionId=x.abc.com:8888:1234567890 ? > > I think we should have just one submitted event or start-stop for one > session-id. There > is definately sometimes a need to correlate several records related to > the same true > user session. However, at a diameter level this is often not possible. > Rather, such > coordination should be left up to the postprocessing systems. For > instance, one box > could be delivering NASREQ data, including the user's IP address while > another > box might be providing some additional service. Both records would > contain IP > addresses which would help the postprocessing systems in correlating the > records > even if they came from two different boxes. > > And as you indicate below, there is a need to clarify this text in the > draft. I propose > that we add a statement to the explanation of the session id AVP that > prohibits > the submission of several sessions with the same session id, and says > that the type of > the session must be one of event or start-interim-stop for a particular > session id. > > > > > Is the type or record (EVENT vs START/INTERIM/STOP) tight to the particular kind of service, so that > > when some services are used, it is reported accounted info of kind EVENT, and when some other services > > are used, it is reported accounted info in the style Start/Interim/Stop ? > > This should be dictated by the text appearing in a particular extension > document. > > > > > Is it possible to send (Diameter client)/receive (Accounting server) several EVENT_RECORD for the same > > Session-Id? > > > > Same question but for measurable length services: is it possible to send/receive several START-STOP > > sequences for the same Session-Id? > > For both, see above. > > > > > For the answer of all these questions, could be added the corresponding clarifying text on the I-D? > > It would be quite helpful. > > I agree. > > Jari From owner-aaa-bof@merit.edu Fri Jun 1 11:34:57 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10039 for ; Fri, 1 Jun 2001 11:34:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A9DC4912ED; Fri, 1 Jun 2001 11:35:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 63A43912FE; Fri, 1 Jun 2001 11:35:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0E7CF912ED for ; Fri, 1 Jun 2001 11:33:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8F53D5DDB5; Fri, 1 Jun 2001 11:33:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id E1D8C5DDAD for ; Fri, 1 Jun 2001 11:33:21 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id IAA54038; Fri, 1 Jun 2001 08:22:59 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Fri, 1 Jun 2001 08:22:59 -0700 (PDT) From: Bernard Aboba To: Randy Bush Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: WECA 'extending' RADIUS? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk A good argument for "Expert review" as opposed to IANA assignment ;) On Fri, 1 Jun 2001, Randy Bush wrote: > via bert > > Story date(time): 05/29/2001(02:18 AM) > Effort afoot to provide wireless LAN roaming > InfoWorld Daily News via DowVision > > By John Cox, Network World Fusion InfoWorld.com From owner-aaa-bof@merit.edu Fri Jun 1 13:00:58 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12577 for ; Fri, 1 Jun 2001 13:00:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9CBC1912EE; Fri, 1 Jun 2001 06:50:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 45BE2912EC; Fri, 1 Jun 2001 06:49:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2522B912ED for ; Fri, 1 Jun 2001 06:48:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 72FAB5DD8F; Fri, 1 Jun 2001 06:48:37 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 9AFA55DD8D for ; Fri, 1 Jun 2001 06:48:36 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f51AmPN24236; Fri, 1 Jun 2001 12:48:25 +0200 (MEST) Received: from lmf.ericsson.se (turqws113.lmf.ericsson.se [131.160.120.113]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f51AmP428833; Fri, 1 Jun 2001 13:48:25 +0300 (EET DST) Message-ID: <3B1772EE.8D2C50EA@lmf.ericsson.se> Date: Fri, 01 Jun 2001 13:48:14 +0300 From: Taneli Haverinen Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Error signaling ('A' msg.) References: <3B1641E9.790B9AD7@lmf.ericsson.se> <20010531062921.C10291@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > Chapter 9.1. (End-To-End Error Signaling) of the base protocol does not > > seem to define what to do when an error occurs while processing an > > Answer message. Earlier the situation was handled by sending an MRI, but > > this command was eliminated recently. I noticed that this problem was > > discussed in Pat's message "A proposal for the elimination of MRI" > > (http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00110.html). In > > that message it was proposed that a STR with a Termination-Cause should > > be issued. I also noticed, that Issue #10 "Sessions that do not start" > > deals with my question, but only in the case of authorization messages. > > I wonder what is the procedure in a general case? > > So do you mean what one does if an accounting answer is received, > with an error, or a bad STA or DWA? > > I believe that these are the only remanining messages that aren't > covered by #10. Yes, I mean the ones you mentioned above, and also any extension-specific or vendor-specific answer messages. BR, Taneli H. From owner-aaa-bof@merit.edu Fri Jun 1 13:43:11 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14396 for ; Fri, 1 Jun 2001 13:43:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8459191304; Fri, 1 Jun 2001 13:43:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4D8CD91305; Fri, 1 Jun 2001 13:43:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 31A2391304 for ; Fri, 1 Jun 2001 13:43:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F07385DD96; Fri, 1 Jun 2001 13:43:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 727CD5DD92 for ; Fri, 1 Jun 2001 13:43:24 -0400 (EDT) Received: (qmail 19888 invoked by uid 500); 1 Jun 2001 17:32:58 -0000 Date: Fri, 1 Jun 2001 10:32:58 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: [Issue] #32 NASREQ extension includes Indication messages Message-ID: <20010601103258.C1078@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, In the process of attempting to fix up Issue #32, I've come across an interesting problem. The indication messages were also used by servers to request unsolicited re-auth to the nas. By removing these messages, we remove this feature. Therefore, it looks like there is a need for a message from the server to the access device to request a re-auth. The issue, though, is whether this should be an extension specific message, or more of a generalized message? Does anyone have any ideas on the best way to solve this problem? I am currently inclined to create a new message set, which would lead to the following: NAS Server <--- re-auth-req ---- ---- re-auth-answ --> ---- AAR -----------> <--- AAA ------------ Ideas? PatC From owner-aaa-bof@merit.edu Fri Jun 1 14:32:02 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15698 for ; Fri, 1 Jun 2001 14:32:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0731691316; Fri, 1 Jun 2001 14:28:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C486891310; Fri, 1 Jun 2001 14:28:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 475AE91318 for ; Fri, 1 Jun 2001 14:28:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 442B65DDB5; Fri, 1 Jun 2001 14:28:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from roam.psg.com (unknown [131.107.37.68]) by segue.merit.edu (Postfix) with ESMTP id 2811A5DDB0 for ; Fri, 1 Jun 2001 14:28:38 -0400 (EDT) Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 155tel-0001xA-00; Fri, 01 Jun 2001 11:28:19 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: James Kempf Cc: aaa-wg@merit.edu, gwz@cisco.com Subject: RE: [AAA-WG]: WECA 'extending' RADIUS? References: <200106011824.LAA29038@heliopolis.eng.sun.com> Message-Id: Date: Fri, 01 Jun 2001 11:28:19 -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Actually, I think they are probably in need of some strong guidance > from IETF. thanks for volunteering! :-)/2 randy From owner-aaa-bof@merit.edu Fri Jun 1 15:16:13 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16578 for ; Fri, 1 Jun 2001 15:16:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 44CBB91300; Fri, 1 Jun 2001 11:49:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E2E7A91301; Fri, 1 Jun 2001 11:49:56 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5E51E91300 for ; Fri, 1 Jun 2001 11:47:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0D4195DDAF; Fri, 1 Jun 2001 11:48:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by segue.merit.edu (Postfix) with ESMTP id 86C865DDB0 for ; Fri, 1 Jun 2001 11:47:56 -0400 (EDT) Received: from JSCHNIZL-W2K.cisco.com (rtp-vpn-201.cisco.com [10.82.192.201]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA07939; Fri, 1 Jun 2001 08:45:54 -0700 (PDT) Message-Id: <4.3.2.7.2.20010601113628.033a8008@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 01 Jun 2001 11:45:21 -0400 To: Bernard Aboba From: John Schnizlein Subject: Re: [AAA-WG]: WECA 'extending' RADIUS? Cc: Randy Bush , aaa-wg@merit.edu In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk What is the fuss about? The reporter discovered that using RADIUS accounting for 802.11b wireless access exploits the benefits built into it for dial access. Nice of him to notice, but not a technology breakthrough. The article does not mention any extensions to RADIUS, it simply describes a new use of RADIUS, especially its capability for global roaming through what we have been calling proxy forwarding. The "tag" the article mentions is just the home domain. The discussion about the importance of billing might create the impression of something new, but it looks like RADIUS accounting to me. And clearinghouse technology for RADIUS accounting has been used for PPP and voice calls, so this is not new either. Considering who has chimed in on this thread, I am now wearing my flame-retardant shorts. ;-) John At 11:22 AM 6/1/2001, Bernard Aboba wrote: >A good argument for "Expert review" as opposed to IANA assignment ;) > >On Fri, 1 Jun 2001, Randy Bush wrote: >> via bert >> >> Story date(time): 05/29/2001(02:18 AM) >> Effort afoot to provide wireless LAN roaming >> InfoWorld Daily News via DowVision >> >> By John Cox, Network World Fusion InfoWorld.com From owner-aaa-bof@merit.edu Fri Jun 1 15:22:03 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16635 for ; Fri, 1 Jun 2001 15:22:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3731B91313; Fri, 1 Jun 2001 15:21:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BCD5591315; Fri, 1 Jun 2001 15:21:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 501BC91313 for ; Fri, 1 Jun 2001 15:21:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2EF275DDC0; Fri, 1 Jun 2001 15:21:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id C4ED55DDAF for ; Fri, 1 Jun 2001 15:21:53 -0400 (EDT) Received: (qmail 23123 invoked by uid 500); 1 Jun 2001 19:04:46 -0000 Date: Fri, 1 Jun 2001 12:04:45 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: [Issue] Server-initiated re-auth Message-ID: <20010601120445.A22616@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk Server-initiated re-auth Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: June 01, 2001 Reference: Document: All Comment type: C Priority: 1 Section: Rationale/Explanation of issue: In the process of fixing Issue #32, the Indication messages have been removed from the NASREQ extension. However, the specification also makes use of the indication messages to allow a server to send an unsolicited request for re-auth. Is this feature required? If so, is it specific to NASREQ, or could it be generalized and defined in the base protocol specification? Three options: 1. Delete the feature 2. Create a new message set in the nasreq specification that is sent by a server to request that a user be re-auth. 3. Create a new message set in the base protocol that is sent by a server to request that a user be re-auth. Comments? PatC From owner-aaa-bof@merit.edu Fri Jun 1 15:50:49 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17300 for ; Fri, 1 Jun 2001 15:50:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D8B6B91307; Fri, 1 Jun 2001 14:14:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 95B909130E; Fri, 1 Jun 2001 14:14:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D74A791307 for ; Fri, 1 Jun 2001 14:14:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CF9655DDB0; Fri, 1 Jun 2001 14:14:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 4FD345DD8D for ; Fri, 1 Jun 2001 14:14:21 -0400 (EDT) Received: from gwzpc (sjc-vpn-372.cisco.com [10.21.65.116]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id LAA09238; Fri, 1 Jun 2001 11:13:38 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Randy Bush" , Subject: RE: [AAA-WG]: WECA 'extending' RADIUS? Date: Fri, 1 Jun 2001 11:13:27 -0700 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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Randy Bush [maILTO:randy@psg.com] writes: One wonders if these people have ever heard of roamops (or the IETF, for that matter)...but wait, wireless is _differenr_ ;-) > via bert > > Story date(time): 05/29/2001(02:18 AM) > Effort afoot to provide wireless LAN roaming > InfoWorld Daily News via DowVision > > By John Cox, Network World Fusion InfoWorld.com > > A group of leading vendors is working to iron out the technical and > financial details needed to let mobile wireless LAN users connect > to almost any wireless ISP, similar to the way cell phone users can roam > and use multiple carriers to complete calls. > > The Wireless Ethernet Compatibility Alliance (WECA), which includes > Cisco, IBM, Intel, 3Com and Microsoft, is looking to forge > relationships and network standards among wireless ISPs and eventually > carriers that will enable roaming for 802.11b wireless LAN > users. These standards will let vendors share subscriber usage and > billing data, so no matter how many different ISPs' subscribers are > used to make a connection from a plane, train or automobile, they only > get one bill from their "home" ISP. > > According to WECA members involved in the roaming project, the public > access wireless LANs now being deployed in airports, > convention centers and even restaurants will create a burgeoning web of > wireless LAN hot spots. These hot spots will let mobile > workers, with 802.11b-equipped computers, connect over a shared > 11M-bit/sec link to Internet-based services and corporate > networks. Most wide-area wireless data links today are based on much > slower cell phone nets. > > "What we're talking about is interservice provider roaming. As you go > from a corporate to a public net, you want to have user ID and > a password for the ISP. But you don't want to have a different one for > every wireless ISP net that you might traverse," said Greg > Homan, director of systems engineering at MobileStar Network of > Richardson, Texas, and a spokesman for the Wireless Internet > Service Provider Roaming (WISPr), a contingent within WECA that is > preparing the roaming proposal. "Within a corporate wireless > LAN, roaming among access points is handled as part of the 802.11b > protocol." > > The group is a mix of service providers, LAN equipment vendors and PC > makers, including Agere Systems, Dell, Enterasys and Nokia > and wireless ISPs MobileStar and Wayport. A draft will be presented at > the next WECA board meeting, June 13 in Helsinki, Finland. > > "Having roaming agreements is a great idea for any network," said Andy > Kasznay, software engineer with Northeast Utilities in Berlin, > Conn. The utility uses a cellular phone network to connect field workers > with laptops or PDAs to corporate data. "We currently don't > use 802.11b networks because there are only very limited locations where > they're available and a limited number of providers." > > Kasznay is clear on what he'd want from such a service as proposed by > WISPr. "One service provider with one bill," he said. "As far > as cost is concerned, it must be similar in cost to dial-up connections > from a hotel room, including the hotel fees and long-distance > charges for an average user session, but with faster throughput > [compared to dial up]." > > He's also convinced a WISPr service would be used mainly by the > utility's traveling executives and managers, not by electricians and > others in the field. "The area that our field force covers is far too > broad to be served by such a network," Kasznay said. > > Other issues could slow the roaming proposal. For example, the reach of > such a wireless LAN (WLAN) service will still be severely > limited compared to the cell networks because 802.11b, sometimes called > Wi-Fi, is a local network with a radio range of roughly 150 > feet. The public access WLANs being created by the likes of wireless > ISPs MobileStar and Wayport, initially will be found in urban, > high-density areas. Most of these public WLANs are targeted at > white-collar business travelers. Blue-collar mobile workers likely will > have to rely on low-speed, but widespread, cell networks, such as > Cellular Digital Packet Data nets, for accessing data wirelessly. In > addition, the service providers that go forward with the WISPr roaming > will have to ensure they're offering a simple connection > process and a single bill to make such roaming a desirable service for > target users. And then there are security concerns. > > Specifically, WISPr is looking to define a tag that users could tack > onto their subscriber name. The tag will alert any WISP that the > user requesting service is "owned" by some other provider. Data about > the user and the service request will be passed to an > independent clearinghouse, which would coordinate transactions among > different parties-in this case, the WISPs. > > WISPr spokesman Homan said the arrangement will most likely use the > Remote Authentication Dial-In User Service (RADIUS) > protocol, which is widely used to coordinate authorization information > between remote users and an authorization server. The > clearinghouse would pass the user data to that user's WISP, which then > completes the authentication, bills the user and makes the > appropriate payment to the WISP serving as the user's access connection. > Users can then access their home WISP services and, > through the provider, their corporate net. > > WISPr members said the technology for sharing data between the ISPs is > relatively straightforward and most of the complexity > involves setting up standards for handling transactions between service > providers. > > "The billing systems are key to this," Homan said. "We're extending the > RADIUS protocol with specific [new] attributes, such as user > name, time spent online, bytes in or out, and so on. We'll also have > information about where the user is, through a location code, so > we can return site-specific services to that user." > > A WISP subscriber from the U.S., gaining access via a wireless LAN > service in a Swedish airport, would receive information in > English, for example. > > Keeping it simple will be the key to user acceptance, said Jeff Manning, > business development manager at Agere. "We've failed if this > is difficult [to use]," he says. "Everyone has a vested interest in > making this work." > > There will be significant investment. The overall 802.11b market is > expected to keep growing at a healthy rate despite the economic > slowdown, according to an April report by Cahners In-Stat. By 2005, the > firm estimates that companies will be spending nearly $6.4 > billion on WLAN equipment. Companies such as IBM, Compaq and Dell are > introducing notebook PCs with built-in 802.11b radios and > antennas. Adapter card vendors have just started bringing out 802.11b > cards for handheld computers, such as those using the > Microsoft PocketPC software. > > The carriers are watching the project closely, according to WISPr > members. "There's a tremendous amount of work going on by all > the carriers," said Allan Scott, business manager for the Americas at > Agere. "They're all involved in Wi-Fi products. They're very quiet > about it, but they're all doing it." > > The WISPr group has no set schedule to complete its work, so it's > difficult to say exactly when 802.11b roaming will become reality. > Agere's Manning says he hopes the group will have a final document by > year-end. Users can expect to see roaming being > implemented more widely in the next two years, with the pace > accelerating as carriers get into the action as the number of WLAN > clients surges, each one representing a potential subscriber for > wireless data services. > ------- end of forwarded message ------- > From owner-aaa-bof@merit.edu Fri Jun 1 15:54:03 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17328 for ; Fri, 1 Jun 2001 15:54:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AF4D29131A; Fri, 1 Jun 2001 15:53:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 82AF99131B; Fri, 1 Jun 2001 15:53:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5A9659131A for ; Fri, 1 Jun 2001 15:53:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6EB125DD96; Fri, 1 Jun 2001 15:54:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 81E2D5DDC3 for ; Fri, 1 Jun 2001 15:54:06 -0400 (EDT) Received: (qmail 23418 invoked by uid 500); 1 Jun 2001 19:43:39 -0000 Date: Fri, 1 Jun 2001 12:43:39 -0700 From: Pat Calhoun To: Mark Eklund Cc: Pat Calhoun , David Spence , Bernard Aboba , David Mitton , AAA Working Group , David Mitton Subject: Re: [AAA-WG]: [issue] Server Identification Message-ID: <20010601124339.C22616@charizard.diameter.org> Mail-Followup-To: Mark Eklund , Pat Calhoun , David Spence , Bernard Aboba , David Mitton , AAA Working Group , David Mitton References: <20010531114154.P10291@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from meklund@cisco.com on Thu, May 31, 2001 at 04:03:26PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Thu, May 31, 2001 at 04:03:26PM -0400, Mark Eklund wrote: > Pat, > > On Thu, 31 May 2001, Pat Calhoun wrote: > > > On Wed, May 30, 2001 at 04:38:10PM -0400, Mark Eklund wrote: > > > Pat, > > > > > > If you had > > > > > > If you have a proxy that speaks both radius and diameter and is > > > connected to a radius NAS and a Diameter server, could it set > > > the NAS identifier as below before proxying to the Diameter > > > server? > > > > > > radius://nas.legacy.xyz:1813;transport=udp > > > > Seems like a good idea for a protocol gateway to do. I guess > > that would belong somewhere in the NASREQ spec. I suppose I should > > open a separate issue on that one. > > Sounds good. It would also involve the base. A change > something like this would be needed. > Actually, what I've come up with is the following: 2.7 Diameter Identity Encoding Several Diameter AVPs are used to include a node's identity, such as the Destination-Host, Origin-Host, Route-Record, etc. The contents of such AVPs follow the Uniform Resource Identifiers (URI) syntax [47] rules specified below: Diameter-Identity = [protocol] fqdn [ port ] [ transport ] protocol-name = ( "diameter" | "radius" | "tacacs+" ) protocol = protocol-name "://" ; If absent, the default is "diameter://" fqdn = Fully Qualified Host Name port = ":" port ; If absent, the default Diameter port (TBD) is assumed. transport = ";transport=" ( "tcp" | "sctp" | "udp") ; If absent, the default SCTP [26] protocol is assumed. ; UDP is ONLY used when the protocol is set to RADIUS The following are examples of valid Diameter host identities: host.abc.com:6666;transport=tcp diameter://host.abc.com diameter://host.abc.com:6666 diameter://host.abc.com;transport=tcp diameter://host.abc.com:6666;transport=tcp radius://host.abc.com:1813;transport=udp Comments? PatC From owner-aaa-bof@merit.edu Fri Jun 1 16:04:25 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17483 for ; Fri, 1 Jun 2001 16:04:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D22549131E; Fri, 1 Jun 2001 16:03:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9B58591320; Fri, 1 Jun 2001 16:03:53 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 19EDA9131E for ; Fri, 1 Jun 2001 16:03:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2CB855DDA2; Fri, 1 Jun 2001 16:04:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 54FA65DD96 for ; Fri, 1 Jun 2001 16:04:05 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA11763; Fri, 1 Jun 2001 15:58:30 -0400 (EDT) Date: Fri, 1 Jun 2001 15:59:38 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: Pat Calhoun Cc: David Spence , Bernard Aboba , David Mitton , AAA Working Group , David Mitton Subject: Re: [AAA-WG]: [issue] Server Identification In-Reply-To: <20010601124339.C22616@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, This looks good. At first I was concerned about the possibility that someone comes up with some other protocol, but I'm not too worded about that. If they want to use something other than (tacacs+, diameter, or radius), they can. They will be in violation of the RFC, but only the most pedantic will care. If a new version of the RFC comes out, they will probably push to get it added. No need to document a procedure for everything. -mark On Fri, 1 Jun 2001, Pat Calhoun wrote: > On Thu, May 31, 2001 at 04:03:26PM -0400, Mark Eklund wrote: > > Pat, > > > > On Thu, 31 May 2001, Pat Calhoun wrote: > > > > > On Wed, May 30, 2001 at 04:38:10PM -0400, Mark Eklund wrote: > > > > Pat, > > > > > > > > If you had > > > > > > > > If you have a proxy that speaks both radius and diameter and is > > > > connected to a radius NAS and a Diameter server, could it set > > > > the NAS identifier as below before proxying to the Diameter > > > > server? > > > > > > > > radius://nas.legacy.xyz:1813;transport=udp > > > > > > Seems like a good idea for a protocol gateway to do. I guess > > > that would belong somewhere in the NASREQ spec. I suppose I should > > > open a separate issue on that one. > > > > Sounds good. It would also involve the base. A change > > something like this would be needed. > > > > Actually, what I've come up with is the following: > > 2.7 Diameter Identity Encoding > > Several Diameter AVPs are used to include a node's identity, such as > the Destination-Host, Origin-Host, Route-Record, etc. The contents of > such AVPs follow the Uniform Resource Identifiers (URI) syntax [47] > rules specified below: > > Diameter-Identity = [protocol] fqdn [ port ] > [ transport ] > > protocol-name = ( "diameter" | "radius" | "tacacs+" ) > > protocol = protocol-name "://" > ; If absent, the default is "diameter://" > > fqdn = Fully Qualified Host Name > > port = ":" port > ; If absent, the default Diameter port (TBD) is assumed. > > transport = ";transport=" ( "tcp" | "sctp" | "udp") > ; If absent, the default SCTP [26] protocol is assumed. > ; UDP is ONLY used when the protocol is set to RADIUS > > The following are examples of valid Diameter host identities: > > host.abc.com:6666;transport=tcp > diameter://host.abc.com > diameter://host.abc.com:6666 > diameter://host.abc.com;transport=tcp > diameter://host.abc.com:6666;transport=tcp > radius://host.abc.com:1813;transport=udp > > Comments? > > PatC > From owner-aaa-bof@merit.edu Fri Jun 1 16:06:06 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17501 for ; Fri, 1 Jun 2001 16:06:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 62FC091320; Fri, 1 Jun 2001 16:05:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DF35891321; Fri, 1 Jun 2001 16:05:55 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5FA8591320 for ; Fri, 1 Jun 2001 16:05:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 713565DDB0; Fri, 1 Jun 2001 16:06:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by segue.merit.edu (Postfix) with ESMTP id 217BE5DDA2 for ; Fri, 1 Jun 2001 16:06:02 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id NAA25521 for ; Fri, 1 Jun 2001 13:05:51 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id MAA06038 for ; Fri, 1 Jun 2001 12:59:28 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Jun 2001 15:05:50 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECF11@IL27EXM10.cig.mot.com> From: Cain Brian-BCAIN1 To: "'Pat Calhoun'" Cc: AAA Working Group Subject: RE: [AAA-WG]: [issue] Server Identification Date: Fri, 1 Jun 2001 15:05:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-bof@merit.edu Precedence: bulk > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > On Thu, May 31, 2001 at 04:03:26PM -0400, Mark Eklund wrote: > > Pat, > > > > On Thu, 31 May 2001, Pat Calhoun wrote: > > > > > On Wed, May 30, 2001 at 04:38:10PM -0400, Mark Eklund wrote: > > > > Pat, > > > > > > > > If you had > > > > > > > > If you have a proxy that speaks both radius and diameter and is > > > > connected to a radius NAS and a Diameter server, could it set > > > > the NAS identifier as below before proxying to the Diameter > > > > server? > > > > > > > > radius://nas.legacy.xyz:1813;transport=udp > > > > > > Seems like a good idea for a protocol gateway to do. I guess > > > that would belong somewhere in the NASREQ spec. I suppose I should > > > open a separate issue on that one. > > > > Sounds good. It would also involve the base. A change > > something like this would be needed. > > ... > port = ":" port This is the only part I would draw into question, because it looks slightly unclear. I know what the intent was, but it looks as if this is a recursive rule, and it will end up being one or more colons. Perhaps I'm nitpicking, but maybe this would be better: port = ":" 1*DIGIT ; A colon followed by the port number ; If absent, the default Diameter port (TBD) is assumed. ... > Comments? Looks good! From owner-aaa-bof@merit.edu Fri Jun 1 16:13:13 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17592 for ; Fri, 1 Jun 2001 16:13:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9E02E91322; Fri, 1 Jun 2001 16:13:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 126FE91323; Fri, 1 Jun 2001 16:13:10 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9D8E691322 for ; Fri, 1 Jun 2001 16:13:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BADDE5DDB5; Fri, 1 Jun 2001 16:13:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 399BD5DDB0 for ; Fri, 1 Jun 2001 16:13:23 -0400 (EDT) Received: (qmail 23585 invoked by uid 500); 1 Jun 2001 20:02:56 -0000 Date: Fri, 1 Jun 2001 13:02:56 -0700 From: Pat Calhoun To: Cain Brian-BCAIN1 Cc: "'Pat Calhoun'" , AAA Working Group Subject: Re: [AAA-WG]: [issue] Server Identification Message-ID: <20010601130256.D22616@charizard.diameter.org> Mail-Followup-To: Cain Brian-BCAIN1 , 'Pat Calhoun' , AAA Working Group References: <35DBB8B7AC89D4118E98009027B1009B0ECF11@IL27EXM10.cig.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B0ECF11@IL27EXM10.cig.mot.com>; from Brian.Cain@motorola.com on Fri, Jun 01, 2001 at 03:05:47PM -0500 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Fri, Jun 01, 2001 at 03:05:47PM -0500, Cain Brian-BCAIN1 wrote: > This is the only part I would draw into question, because it looks slightly > unclear. I know what the intent was, but it looks as if this is a recursive > rule, and it will end up being one or more colons. > > Perhaps I'm nitpicking, but maybe this would be better: > > port = ":" 1*DIGIT > ; A colon followed by the port number > ; If absent, the default Diameter port (TBD) is > assumed. Perhaps a nit, but I believe you are correct. I will make the change. PatC From owner-aaa-bof@merit.edu Fri Jun 1 16:29:58 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17735 for ; Fri, 1 Jun 2001 16:29:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6C1299130A; Fri, 1 Jun 2001 14:24:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 313D79130B; Fri, 1 Jun 2001 14:24:46 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 114579130A for ; Fri, 1 Jun 2001 14:24:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0E2055DDB0; Fri, 1 Jun 2001 14:24:59 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id B622F5DDAF for ; Fri, 1 Jun 2001 14:24:58 -0400 (EDT) Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA21130; Fri, 1 Jun 2001 11:24:43 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id LAA29038; Fri, 1 Jun 2001 11:24:41 -0700 (PDT) Message-Id: <200106011824.LAA29038@heliopolis.eng.sun.com> Date: Fri, 1 Jun 2001 11:24:42 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: RE: [AAA-WG]: WECA 'extending' RADIUS? To: randy@psg.com, aaa-wg@merit.edu, gwz@cisco.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: aP52DsRcZGHiX8NYCblOfA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-aaa-bof@merit.edu Precedence: bulk Actually, I think they are probably in need of some strong guidance from IETF. I recently reviewed a prerelease copy of a protocol done by a non-IETF group based on IETF protocols. The proposal was sketchy and obviously in an early phase, but there were misassumptions about how particular IETF protocols work, and lack of knowledge about ongoing work in IETF groups associated with wireless networking. I actually wondered if the authors had even read the RFCs upon which they were basing their work. Considering the breadth of things going on in IETF, it is probably not suprising that this is the case, but it does mean we are going to have to make an effort to educate them if we want them to use the protocols the way they were intended by the designers. jak >Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu >Delivered-To: aaa-wg@trapdoor.merit.edu >Delivered-To: aaa-wg@merit.edu >From: "Glen Zorn" >To: "Randy Bush" , >Subject: RE: [AAA-WG]: WECA 'extending' RADIUS? >Date: Fri, 1 Jun 2001 11:13:27 -0700 >X-Priority: 3 (Normal) >X-MSMail-Priority: Normal >X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 >Importance: Normal > >Randy Bush [maILTO:randy@psg.com] writes: > >One wonders if these people have ever heard of roamops (or the IETF, for >that matter)...but wait, wireless is _differenr_ ;-) > >> via bert >> >> Story date(time): 05/29/2001(02:18 AM) >> Effort afoot to provide wireless LAN roaming >> InfoWorld Daily News via DowVision >> >> By John Cox, Network World Fusion InfoWorld.com >> >> A group of leading vendors is working to iron out the technical and >> financial details needed to let mobile wireless LAN users connect >> to almost any wireless ISP, similar to the way cell phone users can roam >> and use multiple carriers to complete calls. >> >> The Wireless Ethernet Compatibility Alliance (WECA), which includes >> Cisco, IBM, Intel, 3Com and Microsoft, is looking to forge >> relationships and network standards among wireless ISPs and eventually >> carriers that will enable roaming for 802.11b wireless LAN >> users. These standards will let vendors share subscriber usage and >> billing data, so no matter how many different ISPs' subscribers are >> used to make a connection from a plane, train or automobile, they only >> get one bill from their "home" ISP. >> >> According to WECA members involved in the roaming project, the public >> access wireless LANs now being deployed in airports, >> convention centers and even restaurants will create a burgeoning web of >> wireless LAN hot spots. These hot spots will let mobile >> workers, with 802.11b-equipped computers, connect over a shared >> 11M-bit/sec link to Internet-based services and corporate >> networks. Most wide-area wireless data links today are based on much >> slower cell phone nets. >> >> "What we're talking about is interservice provider roaming. As you go >> from a corporate to a public net, you want to have user ID and >> a password for the ISP. But you don't want to have a different one for >> every wireless ISP net that you might traverse," said Greg >> Homan, director of systems engineering at MobileStar Network of >> Richardson, Texas, and a spokesman for the Wireless Internet >> Service Provider Roaming (WISPr), a contingent within WECA that is >> preparing the roaming proposal. "Within a corporate wireless >> LAN, roaming among access points is handled as part of the 802.11b >> protocol." >> >> The group is a mix of service providers, LAN equipment vendors and PC >> makers, including Agere Systems, Dell, Enterasys and Nokia >> and wireless ISPs MobileStar and Wayport. A draft will be presented at >> the next WECA board meeting, June 13 in Helsinki, Finland. >> >> "Having roaming agreements is a great idea for any network," said Andy >> Kasznay, software engineer with Northeast Utilities in Berlin, >> Conn. The utility uses a cellular phone network to connect field workers >> with laptops or PDAs to corporate data. "We currently don't >> use 802.11b networks because there are only very limited locations where >> they're available and a limited number of providers." >> >> Kasznay is clear on what he'd want from such a service as proposed by >> WISPr. "One service provider with one bill," he said. "As far >> as cost is concerned, it must be similar in cost to dial-up connections >> from a hotel room, including the hotel fees and long-distance >> charges for an average user session, but with faster throughput >> [compared to dial up]." >> >> He's also convinced a WISPr service would be used mainly by the >> utility's traveling executives and managers, not by electricians and >> others in the field. "The area that our field force covers is far too >> broad to be served by such a network," Kasznay said. >> >> Other issues could slow the roaming proposal. For example, the reach of >> such a wireless LAN (WLAN) service will still be severely >> limited compared to the cell networks because 802.11b, sometimes called >> Wi-Fi, is a local network with a radio range of roughly 150 >> feet. The public access WLANs being created by the likes of wireless >> ISPs MobileStar and Wayport, initially will be found in urban, >> high-density areas. Most of these public WLANs are targeted at >> white-collar business travelers. Blue-collar mobile workers likely will >> have to rely on low-speed, but widespread, cell networks, such as >> Cellular Digital Packet Data nets, for accessing data wirelessly. In >> addition, the service providers that go forward with the WISPr roaming >> will have to ensure they're offering a simple connection >> process and a single bill to make such roaming a desirable service for >> target users. And then there are security concerns. >> >> Specifically, WISPr is looking to define a tag that users could tack >> onto their subscriber name. The tag will alert any WISP that the >> user requesting service is "owned" by some other provider. Data about >> the user and the service request will be passed to an >> independent clearinghouse, which would coordinate transactions among >> different parties-in this case, the WISPs. >> >> WISPr spokesman Homan said the arrangement will most likely use the >> Remote Authentication Dial-In User Service (RADIUS) >> protocol, which is widely used to coordinate authorization information >> between remote users and an authorization server. The >> clearinghouse would pass the user data to that user's WISP, which then >> completes the authentication, bills the user and makes the >> appropriate payment to the WISP serving as the user's access connection. >> Users can then access their home WISP services and, >> through the provider, their corporate net. >> >> WISPr members said the technology for sharing data between the ISPs is >> relatively straightforward and most of the complexity >> involves setting up standards for handling transactions between service >> providers. >> >> "The billing systems are key to this," Homan said. "We're extending the >> RADIUS protocol with specific [new] attributes, such as user >> name, time spent online, bytes in or out, and so on. We'll also have >> information about where the user is, through a location code, so >> we can return site-specific services to that user." >> >> A WISP subscriber from the U.S., gaining access via a wireless LAN >> service in a Swedish airport, would receive information in >> English, for example. >> >> Keeping it simple will be the key to user acceptance, said Jeff Manning, >> business development manager at Agere. "We've failed if this >> is difficult [to use]," he says. "Everyone has a vested interest in >> making this work." >> >> There will be significant investment. The overall 802.11b market is >> expected to keep growing at a healthy rate despite the economic >> slowdown, according to an April report by Cahners In-Stat. By 2005, the >> firm estimates that companies will be spending nearly $6.4 >> billion on WLAN equipment. Companies such as IBM, Compaq and Dell are >> introducing notebook PCs with built-in 802.11b radios and >> antennas. Adapter card vendors have just started bringing out 802.11b >> cards for handheld computers, such as those using the >> Microsoft PocketPC software. >> >> The carriers are watching the project closely, according to WISPr >> members. "There's a tremendous amount of work going on by all >> the carriers," said Allan Scott, business manager for the Americas at >> Agere. "They're all involved in Wi-Fi products. They're very quiet >> about it, but they're all doing it." >> >> The WISPr group has no set schedule to complete its work, so it's >> difficult to say exactly when 802.11b roaming will become reality. >> Agere's Manning says he hopes the group will have a final document by >> year-end. Users can expect to see roaming being >> implemented more widely in the next two years, with the pace >> accelerating as carriers get into the action as the number of WLAN >> clients surges, each one representing a potential subscriber for >> wireless data services. >> ------- end of forwarded message ------- >> > From owner-aaa-bof@merit.edu Fri Jun 1 17:15:47 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18210 for ; Fri, 1 Jun 2001 17:15:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C702C91328; Fri, 1 Jun 2001 17:11:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C5D091329; Fri, 1 Jun 2001 17:11:42 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 889A591328 for ; Fri, 1 Jun 2001 17:11:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AD1285DDB1; Fri, 1 Jun 2001 17:11:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 6EBFA5DDB0 for ; Fri, 1 Jun 2001 17:11:55 -0400 (EDT) Received: (qmail 24511 invoked by uid 500); 1 Jun 2001 21:01:29 -0000 Date: Fri, 1 Jun 2001 14:01:28 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Support for multi-process Message-ID: <20010601140128.G22616@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk Mark, I am going through the last items that I haven't had a chance to address, and this one in particular appears to be problematic. The suggested fix is to remove an entry in the peer state machine, which would affect legitimate cases where two connections are established by the same process. Should there instead be some text that states that the peer's identity be examined, and not just look at the IP Address? What exactly was the suggested fix? The issue definition isn't really clear :( Thanks, PatC From owner-aaa-bof@merit.edu Fri Jun 1 17:26:08 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18287 for ; Fri, 1 Jun 2001 17:26:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 66F3C91329; Fri, 1 Jun 2001 17:16:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1CCE79132B; Fri, 1 Jun 2001 17:16:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BA19D91329 for ; Fri, 1 Jun 2001 17:16:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EC7C05DDB5; Fri, 1 Jun 2001 17:16:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id ABC0D5DDB1 for ; Fri, 1 Jun 2001 17:16:35 -0400 (EDT) Received: (qmail 24565 invoked by uid 500); 1 Jun 2001 21:06:09 -0000 Date: Fri, 1 Jun 2001 14:06:09 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: What does "Snd-Conn-Nack" mean? Message-ID: <20010601140609.H22616@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk Mark, The proposal you have is to modify the state machine, but it doesn't really state what we had agreed upon. I suspect that instead of Snd-Conn-Nack, it should be Disc. Does this work for you? PatC From owner-aaa-bof@merit.edu Fri Jun 1 17:36:14 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18427 for ; Fri, 1 Jun 2001 17:36:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DBE759133A; Fri, 1 Jun 2001 17:31:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 71B5D91339; Fri, 1 Jun 2001 17:31:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 53B6A91337 for ; Fri, 1 Jun 2001 17:29:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 854375DDBD; Fri, 1 Jun 2001 17:29:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 39C2A5DDB5 for ; Fri, 1 Jun 2001 17:29:22 -0400 (EDT) Received: from gwzpc (sjc-vpn-tmp8.cisco.com [10.21.64.8]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id OAA02224; Fri, 1 Jun 2001 14:26:52 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "John Schnizlein" , "Bernard Aboba" Cc: "Randy Bush" , Subject: RE: [AAA-WG]: WECA 'extending' RADIUS? Date: Fri, 1 Jun 2001 14:26:44 -0700 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.00.2615.200 Importance: Normal In-Reply-To: <4.3.2.7.2.20010601113628.033a8008@diablo.cisco.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit John Schnizlein [mailto:jschnizl@cisco.com] writes: > What is the fuss about? > The reporter discovered that using RADIUS accounting for 802.11b > wireless access exploits the benefits built into it for dial access. > Nice of him to notice, but not a technology breakthrough. If it was just the reporter it wouldn't bother me, but it seems that WISPr itself is on a voyage of discovery through laboriously charted lands... > > The article does not mention any extensions to RADIUS, > it simply describes a new use of RADIUS, especially its capability > for global roaming through what we have been calling proxy forwarding. > The "tag" the article mentions is just the home domain. From the article: "Specifically, WISPr is looking to define a tag that users could tack onto their subscriber name. ^^^^^^ The tag will alert any WISP that the user requesting service is "owned" by some other provider." RFC 2486. > > The discussion about the importance of billing might create the > impression of something new, but it looks like RADIUS accounting to me. > And clearinghouse technology for RADIUS accounting has been used for > PPP and voice calls, so this is not new either. From the article, again: '"The billing systems are key to this," Homan said. "We're extending the RADIUS protocol with specific [new] attributes, such as user name, time spent online, bytes in or out, and so on. We'll also have information about where the user is, through a location code, so we can return site-specific services to that user.' Of these, the only thing that is new is the "location code" (which poses significant privacy issues, BTW). Note that this quote is from a WISPr "spokesman", not the reporter. Although it's certainly possible that he was misquoted, if this statement is close to accurate we have people "extending" the RADIUS protocol with "features" already present in it... > > Considering who has chimed in on this thread, > I am now wearing my flame-retardant shorts. ;-) > > John > > At 11:22 AM 6/1/2001, Bernard Aboba wrote: > >A good argument for "Expert review" as opposed to IANA assignment ;) > > > >On Fri, 1 Jun 2001, Randy Bush wrote: > >> via bert > >> > >> Story date(time): 05/29/2001(02:18 AM) > >> Effort afoot to provide wireless LAN roaming > >> InfoWorld Daily News via DowVision > >> > >> By John Cox, Network World Fusion InfoWorld.com > > From owner-aaa-bof@merit.edu Fri Jun 1 17:37:01 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18461 for ; Fri, 1 Jun 2001 17:37:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6BD0A91334; Fri, 1 Jun 2001 17:35:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3B34991336; Fri, 1 Jun 2001 17:35:39 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F05D491334 for ; Fri, 1 Jun 2001 17:32:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 34FC15DDBD; Fri, 1 Jun 2001 17:33:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by segue.merit.edu (Postfix) with ESMTP id D85C25DDB5 for ; Fri, 1 Jun 2001 17:33:13 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id OAA11210 for ; Fri, 1 Jun 2001 14:32:15 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id OAA22150 for ; Fri, 1 Jun 2001 14:32:14 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Jun 2001 16:32:14 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECF13@IL27EXM10.cig.mot.com> From: Cain Brian-BCAIN1 To: "'Pat Calhoun'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: What does "Snd-Conn-Nack" mean? Date: Fri, 1 Jun 2001 16:32:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-bof@merit.edu Precedence: bulk > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] ... > state what we had agreed upon. I suspect that instead of > Snd-Conn-Nack, it > should be Disc. > > Does this work for you? I like it. I would assume we can replace the corresponding "Rcv-Conn-Nack" events with the "Peer-Disc" events, too, right? -Brian From owner-aaa-bof@merit.edu Fri Jun 1 17:42:11 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18564 for ; Fri, 1 Jun 2001 17:42:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5BCAF91339; Fri, 1 Jun 2001 17:42:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 213E691337; Fri, 1 Jun 2001 17:42:02 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D469A91344 for ; Fri, 1 Jun 2001 17:41:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1D0E35DDBD; Fri, 1 Jun 2001 17:42:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 53D525DDB5 for ; Fri, 1 Jun 2001 17:42:07 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA12848; Fri, 1 Jun 2001 17:41:00 -0400 (EDT) Date: Fri, 1 Jun 2001 17:42:09 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: What does "Snd-Conn-Nack" mean? In-Reply-To: <20010601140609.H22616@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk On Fri, 1 Jun 2001, Pat Calhoun wrote: > Mark, > > The proposal you have is to modify the state machine, but it doesn't really > state what we had agreed upon. I suspect that instead of Snd-Conn-Nack, it > should be Disc. > > Does this work for you? Yes, that works. -mark > > PatC > From owner-aaa-bof@merit.edu Fri Jun 1 18:00:46 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18700 for ; Fri, 1 Jun 2001 18:00:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 992C791332; Fri, 1 Jun 2001 17:31:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 113A391339; Fri, 1 Jun 2001 17:31:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 868EA91335 for ; Fri, 1 Jun 2001 17:28:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C130C5DDB5; Fri, 1 Jun 2001 17:28:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 82F885DDB0 for ; Fri, 1 Jun 2001 17:28:23 -0400 (EDT) Received: (qmail 24600 invoked by uid 500); 1 Jun 2001 21:17:57 -0000 Date: Fri, 1 Jun 2001 14:17:57 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: NASREQ KDC proposed text Message-ID: <20010601141756.I22616@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, I am in the process of addressing the issue that can be found at http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00230.html, and I have some... problems. First off, the general idea is the provide some keying services, similar to those used in MObile IP. However, in the Mobile IP extension, how these keys are used is well defined. In this proposed text, it is really up in the air, and it leaves the reader wondering why this is needed. Am I the only one that sees this as a potential problem with the IESG? Thanks, PatC From owner-aaa-bof@merit.edu Fri Jun 1 18:10:00 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18788 for ; Fri, 1 Jun 2001 18:10:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7DE6891336; Fri, 1 Jun 2001 18:10:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5148091337; Fri, 1 Jun 2001 18:10:03 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2F49E91336 for ; Fri, 1 Jun 2001 18:10:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4A49C5DDBD; Fri, 1 Jun 2001 18:10:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id C02B75DDB5 for ; Fri, 1 Jun 2001 18:10:15 -0400 (EDT) Received: (qmail 24758 invoked by uid 500); 1 Jun 2001 21:59:49 -0000 Date: Fri, 1 Jun 2001 14:59:48 -0700 From: Pat Calhoun To: Cain Brian-BCAIN1 Cc: "'Pat Calhoun'" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: What does "Snd-Conn-Nack" mean? Message-ID: <20010601145948.J22616@charizard.diameter.org> Mail-Followup-To: Cain Brian-BCAIN1 , 'Pat Calhoun' , aaa-wg@merit.edu References: <35DBB8B7AC89D4118E98009027B1009B0ECF13@IL27EXM10.cig.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B0ECF13@IL27EXM10.cig.mot.com>; from Brian.Cain@motorola.com on Fri, Jun 01, 2001 at 04:32:14PM -0500 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Fri, Jun 01, 2001 at 04:32:14PM -0500, Cain Brian-BCAIN1 wrote: > > > -----Original Message----- > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > ... > > state what we had agreed upon. I suspect that instead of > > Snd-Conn-Nack, it > > should be Disc. > > > > Does this work for you? > > I like it. I would assume we can replace the corresponding "Rcv-Conn-Nack" > events with the "Peer-Disc" events, too, right? Is this really required? Isn't the above the equivalent of connect() failing? PatC From owner-aaa-bof@merit.edu Fri Jun 1 18:35:16 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18959 for ; Fri, 1 Jun 2001 18:35:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E387891337; Fri, 1 Jun 2001 18:35:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E2C5891338; Fri, 1 Jun 2001 18:35:05 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 056F791337 for ; Fri, 1 Jun 2001 18:33:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 48DE85DDB1; Fri, 1 Jun 2001 18:33:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 7601E5DDB0 for ; Fri, 1 Jun 2001 18:33:42 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA13358; Fri, 1 Jun 2001 18:32:05 -0400 (EDT) Date: Fri, 1 Jun 2001 18:33:14 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Support for multi-process In-Reply-To: <20010601140128.G22616@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, Actually, at one time I thought I had a suggested fix, but now I'm not sure. Every time I think of changing the state machine, I get a headache :(. Here is the gist of the problem. If we allow multiple peers at the same IP address, we have to wait until receiving a DRI (or whatever it is now called) to find out which peer it is. Even then, how do we know which peer to which we are connecting? The diameter identity is [protocol] fqdn [ port ]. If I am a server listening on port 1812, and I want to establish a connection to another server on 1812, I can set the destination port to 1812, but I cannot use 1812 on the source port. Why? Because I'm already listening to that port and can't bind to it for a connect. So imagine one system a.b.c with a server (listening on port 1812) and a client (listening on port 2000) and system x.y.z with a server (listening on port 1812). Everything comes up at the same time and attempts to make a connection. Application SAddr SPort DAddr DPort Diameter Identity a.b.c client a.b.c 3847 x.y.z 1812 a.b.c:3847 a.b.c server a.b.c 8852 x.y.z 1812 a.b.c:8852 x.y.z server x.y.z 9253 a.b.c 1812 x.y.z:9253 x.y.z.server x.y.z 9986 a.b.c 2000 x.y.z:9986 * The source port (SPort) is randomly chosen when binding to '*'. * The identifier is the identifier sent in the DRI. * when x.y.z receives "a.b.c:3847" and "a.b.c:8852", it doesn't know which application to associate it with. My conclusions: 1. We cannot drop a connection until the DRI is received. 2. The state machine must be modified to reflect this. (commence headaches) 3. The Diameter Identifier port number must be the port on which the peer listens, not the source port that from which connecting. For the example above, the a.b.c client would have a Diameter Identifier of "a.b.c:2000" even if the source port were 3847. Sorry, no solutions at this point. -mark On Fri, 1 Jun 2001, Pat Calhoun wrote: > Mark, > > I am going through the last items that I haven't had a chance to address, > and this one in particular appears to be problematic. The suggested fix is > to remove an entry in the peer state machine, which would affect legitimate > cases where two connections are established by the same process. Should there > instead be some text that states that the peer's identity be examined, and not just > look at the IP Address? > > What exactly was the suggested fix? The issue definition isn't really clear :( > > Thanks, > > PatC > From owner-aaa-bof@merit.edu Fri Jun 1 18:51:05 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19060 for ; Fri, 1 Jun 2001 18:51:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CC58191338; Fri, 1 Jun 2001 18:50:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9FD049133D; Fri, 1 Jun 2001 18:50:39 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 634D091338 for ; Fri, 1 Jun 2001 18:50:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A79A65DDB1; Fri, 1 Jun 2001 18:50:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 5B94E5DDB0 for ; Fri, 1 Jun 2001 18:50:52 -0400 (EDT) Received: (qmail 24869 invoked by uid 500); 1 Jun 2001 22:40:25 -0000 Date: Fri, 1 Jun 2001 15:40:25 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: [Issue] proposed text for NASREQ KDC Message-ID: <20010601154025.M22616@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, Below is my proposed (slightly modified) text that discusses the KDC proposal. I did remove the SPI field, since this is really a Mobile IP thing, and the original author had stated that he wasn't sure it would be needed in PPP. Note, however, that I sent an e-mail earlier about how this should be used, as it really isn't clear, and perhaps what is needed is an additional AVP that informs the NAS what to do with the key. Without this, the NAS would have to guess whether it should use the key for 802.11 over the air security, securing the phone line, etc. Ideas? PatC ---- 2.1.3 NAS-Session-Key AVP Calhoun et al. expires October 2001 [Page 9] Internet-Draft May 2001 The NAS-Session-Key AVP (AVP Code TBD) is of type Grouped, and contains a session key distributed from Diameter servers to clients. The keys MAY be used for integrity and/or confidentiality protection between the NAS and the user. The keys MAY be distributed to the user as part of an EAP authentication exchange. Its Data field has the following ABNF grammar: NAS-Session-Key ::= < AVP Header: TBD > { NAS-Key-Direction } { NAS-Key-Type } { NAS-Key } * [ AVP ] NAS session keys are the keys created by a Diameter server, which it distributes to the NAS, acting as a Diameter client. The keys can be used for integrity and confidentiality protection between the NAS and the user. The keys can be distributed to the user for example as part of the EAP authentication procedure. If strong authentication and confidentiality of the session keys is required, it is recommended that the CMS security application [13] be used to protect the NAS-Session-Key AVP. The NAS-Session-Key AVP MAY appear zero or more times in the AAA and DEA messages. When more than one NAS-Session-Key AVP is present in a message, either the NAS-Key-Type or the NAS-Key-Direction AVPs MUST have different values. Otherwise, the AVPs would conflict with each other. The lifetime of the NAS-Session-Key AVP is found in the Authorization-Lifetime AVP. If a re-authorization request is received prior to the expiration of the lifetime, new keys will need to be distributed. 2.1.4 NAS-Key-Direction The NAS-Key-Direction AVP (AVP Code TBD) is of type Unsigned32, and specifies the direction that the traffic is to be protected with the key. The following values are supported: BIDIRECTIONAL 0 The key is used in both directions UPLINK 1 The key is used for traffic from the user DOWNLINK 2 Calhoun et al. expires October 2001 [Page 10] Internet-Draft May 2001 The key is used for traffic sent to user 2.1.5 NAS-Key-Type The NAS-Key-Type AVP (AVP Code TBD) is of type Unsigned32, and specifies how the key is to be used. The following values are supported: CIPHER_KEY 1 The key is used to encrypt data INTEGRITY_KEY 2 The key is used to authenticate the data 2.1.6 NAS-Key-Data The NAS-Key-Data AVP (AVP Code TBD) is of type OctetString and contains the session key to be used between the user and the access device. From owner-aaa-bof@merit.edu Fri Jun 1 19:05:10 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19117 for ; Fri, 1 Jun 2001 19:05:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 54FF89133D; Fri, 1 Jun 2001 19:05:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5ADA49133F; Fri, 1 Jun 2001 19:05:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 804329133D for ; Fri, 1 Jun 2001 19:03:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BDC6B5DDB1; Fri, 1 Jun 2001 19:03:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 3B0195DDB0 for ; Fri, 1 Jun 2001 19:03:41 -0400 (EDT) Received: (qmail 24892 invoked by uid 500); 1 Jun 2001 22:53:14 -0000 Date: Fri, 1 Jun 2001 15:53:14 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: [Issue] Multi-roundtrip Mobile IP authentication Message-ID: <20010601155314.N22616@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, While fixing Issue #32, I have had to add some provisions in the base protocol to allow for multi-round authentication exchanges. The following Result-Code was added to handle this case: " DIAMETER_ERROR_MULTI_ROUND_AUTH 1001 This informational error is returned by a Diameter server to inform the access device that the authentication mechanism being used required multiple round trip, and a subsequent request needs to be issued in order for access to be granted." Since the base now supports this, I have made the following change to section 2.2 of the Mobile IP extension, which handles this specific issue: "An AMA message with the Result-Code set to DIAMETER_ERROR_MULTI_ROUND_AUTH MAY include mobile node registration key AVPs (see Section 6.1) such as the MIP-MN-to-FA-Key AVP and the MIP-MN-to-HA-Key AVP. If such an AVP is present in the AMA message, the foreign agent MUST include the corresponding Mobile IP key distribution extension in the Registration Reply it sends to the mobile node. This is to support multi-roundtrip authentication mechanisms." Hopefully this one is dead. Thanks, PatC From owner-aaa-bof@merit.edu Sat Jun 2 02:14:50 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA06231 for ; Sat, 2 Jun 2001 02:14:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AEF94912F1; Sat, 2 Jun 2001 01:58:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7E84D91344; Sat, 2 Jun 2001 01:58:05 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 55677912F1 for ; Sat, 2 Jun 2001 01:58:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1D7C75DDC2; Sat, 2 Jun 2001 01:58:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 6C4165DDB0 for ; Sat, 2 Jun 2001 01:58:18 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id WAA54827; Fri, 1 Jun 2001 22:47:56 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Fri, 1 Jun 2001 22:47:56 -0700 (PDT) From: Bernard Aboba To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: NASREQ KDC proposed text In-Reply-To: <20010601141756.I22616@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > First off, the general idea is the provide some keying services, similar to those used in > MObile IP. For AAA, the need is for "key transport" as opposed to "key derivation". For EAP methods that derive session keys, there needs to be a mechanism to transport the keys from the AAA server to the NAS. Typically the keys are required by layer 2 media that provide security services -- PPP ECP, 802.11 WEP, etc. From owner-aaa-bof@merit.edu Sat Jun 2 11:35:22 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11972 for ; Sat, 2 Jun 2001 11:35:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C02CE9134D; Sat, 2 Jun 2001 11:32:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3BB569134E; Sat, 2 Jun 2001 11:32:16 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4A5759134D for ; Sat, 2 Jun 2001 11:32:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B55BC5DDB0; Sat, 2 Jun 2001 11:32:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 3894E5DD98 for ; Sat, 2 Jun 2001 11:32:24 -0400 (EDT) Received: (qmail 29653 invoked by uid 500); 2 Jun 2001 15:21:54 -0000 Date: Sat, 2 Jun 2001 08:21:54 -0700 From: Pat Calhoun To: Bernard Aboba Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: NASREQ KDC proposed text Message-ID: <20010602082154.T22616@charizard.diameter.org> Mail-Followup-To: Bernard Aboba , Pat Calhoun , aaa-wg@merit.edu References: <20010601141756.I22616@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from aboba@internaut.com on Fri, Jun 01, 2001 at 10:47:56PM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Fri, Jun 01, 2001 at 10:47:56PM -0700, Bernard Aboba wrote: > > First off, the general idea is the provide some keying services, similar to those used in > > MObile IP. > > For AAA, the need is for "key transport" as opposed to "key derivation". > > For EAP methods that derive session keys, there needs to be a mechanism to > transport the keys from the AAA server to the NAS. Typically the keys are > required by layer 2 media that provide security services -- PPP ECP, > 802.11 WEP, etc. > Cool, then the spec really should be able to state why the keys are being delivered. Perhaps a new enum AVP that includes 802.11 WEP, PPP ECP, etc. Without this, the reader is left wondering why these keys are even used. Of course, for each enum, a reference to a spec that explains how the keys are used would be most beneficial. PatC From owner-aaa-bof@merit.edu Sat Jun 2 15:59:48 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13247 for ; Sat, 2 Jun 2001 15:59:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A96A991201; Sat, 2 Jun 2001 15:53:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F77791203; Sat, 2 Jun 2001 15:53:06 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 62F1391201 for ; Sat, 2 Jun 2001 15:53:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6051F5DDA5; Sat, 2 Jun 2001 15:53:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 96CB25DD91 for ; Sat, 2 Jun 2001 15:53:20 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA01866; Sat, 2 Jun 2001 15:53:02 -0400 (EDT) Date: Sat, 2 Jun 2001 15:53:17 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Support for multi-process In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, Here is my proposed solution for multi-process access. * The state table is massively modified. * I added a drawing of the state changes for an initiator and requester when everything goes correctly as Section 8.5. * The Diameter-Identifier still has to use the port number which the Diameter server Listens which may not be the source port. * I couldn't remember what DRI changed to so I called it DRR and DRA in this document. * I couldn't remember if Origin-FQDN changed. So it still has the same name. 8.0 Peer State Machine This section contains a finite state machine, that MUST be observed by all Diameter implementations. Each Diameter node MUST follow the state machine described below when communicating with each peer. Multiple actions are separated by commas, and may continue on succeeding lines as space requires. Similarly, state and next state may also span multiple lines as space requires. There may be at most one transport connection between any two peers over which Diameter messages may be passed. This state machine is intended to handle both the simple case, in which one peer initiates a connection to the other, and the complex case, in which each peer simultaneously initiates a connection to the other. In the complex case, an election occurs to determine which transport connection will survive. I- is used to represent the initiator (connecting) connection, while the R- is used to represent the responder (listening) connection. The lack of a prefix indicates that the event or action is the same regardless of the connection on which the event occurred. The stable states that a state machine may be in are Closed, and Open; all other states are intermediate. The DRR is always sent by the initiator immediately after a connection establishment. After the election, the responder sends a DRA. This DRA will contain either a Result-Code AVP of DIAMETER_SUCCESS, DIAMETER_SESSION_DENIED or DIAMETER_SESSION_EXISTS. If the result is DIAMETER_SESSION_DENIED or DIAMETER_SESSION_EXISTS, the receiver of the DRA MUST close the connection. Since the identity of the peer is not known until either a DRR or DRA is received, it is possible for two connections to be briefly established. This is why there is an election process for both the initiator and the responder. This also means that each program may only have one election at a time. This is the reason for the *-Wait-Lock state. The state machine constrains only the behavior of a Diameter implementation as seen by Diameter peers through events on the wire. Any implementation that produces equivalent results is considered compliant. state event action next state ----------------------------------------------------------------- Closed Start Snd-Conn-Req I-Wait-Conn-Ack Rcv-Conn-Req Snd-Conn-Ack R-Wait-DRR I-Wait-Conn-Ack Rcv-Conn-Ack Snd-DRR I-Wait-DRA Rcv-Conn-Nack Cleanup Closed Timeout Error Closed I-Wait-DRA Rcv-DRA Elect-Lock I-Wait-Lock Rcv-DRA-Exist I-Disc Open Rcv-DRA-Fail I-Disc Closed Peer-Disc Error Closed Timeout Error Closed I-Wait-Lock Locked Elect I-Wait-Returns I-Wait-Returns No-Contest Elect-Unlock Open Win-Election Elect-Unlock/ Open R-Disc Lose-Election Elect-Unlock/ Open I-Disc R-Wait-DRR Rcv-DRR Elect-Lock, R-Wait-Lock Timeout Error Closed Rcv-Conn-Disc Error Closed R-Wait-Lock Locked Elect R-Wait-Returns R-Wait-Returns No-Contest Elect-Unlock Open Win-Election Snd-DRA/ Open Elect-Unlock/ I-Disc Lose-Election Elect-Unlock/ Open Snd-DRA-Exist Not-Allowed Elect-Unlock/ Closed Snd-DRA-Fail Open Send-Message Snd-Non-DRI Open Rcv-Non-DRI Process Open WatchDog-Timer Snd-DWR Open Rcv-DWA Process-DWA Open Stop Disc Closed Peer-Disc Disc Closed Rcv-DRR Error Closed 8.1 States Following is a more detailed description of each automaton state. Closed A peer is initially in the closed state, and no transport connection exists with the peer. I-Wait-Conn-Ack A transport connection has been initiated with the peer, and an acknowledgment is pending. I-Wait-DRA The local Diameter node is waiting for the peer to issue a DRA. I-Wait-Lock The initiator is waiting for an election lock. I-Wait-Returns The initiator is waiting on the results of the election returns. R-Wait-DRR A transport connection indication has been received from the peer, and a DRR has yet to be received by the peer. R-Wait-Lock The responder is waiting for an election lock. R-Wait-Returns The responder is waiting on the results of the election returns. Open The peer connection is open. 8.2 Events Transitions and actions in the automaton are caused by events. Start The Diameter application has signaled that a connection should be initiated with the peer. Rcv-Conn-Req A transport connection indication from the peer has been received. Rcv-Conn-Ack A positive acknowledgment was received to a locally initiated transport connection. Rcv-Conn-Nack A negative acknowledgment was received to a locally initiated transport connection. Timeout An application-defined timer has expired while waiting for some event. Rcv-DRA A DRA message from the peer was received. Rcv-DRA-Exist A DRA failure of DIAMETER_SESSION_EXISTS was received. Rcv-DRA-Fail A DRA failure of DIAMETER_SESSION_DENIED was received. Rcv-DRR A DRR message from the peer was received. Peer-Disc A disconnection indication from the peer was received. Locked The election locking mechanism succeeded. No-Contest An election was held, and there was only one connection to this peer. Win-Election An election was held, and the new connection to the peer was the winner. Lose-Election An election was held, and the existing connection to the peer was the winner. Not-Allowed Before the election was held, it was determined that the peer was not allowed. Send-Message A Non-DRI message is to be sent. Rcv-Non-DRI A Non-DRI message was received. WatchDog-Timer The Watchdog timer expired, indicating that a DWR message is to be sent to the peer. Rcv-DWA A DWA message was received. Stop The Diameter application has signaled that a connection should be terminated (e.g., on system shutdown). 8.3 Actions Actions in the automaton are caused by events and typically indicate the transmission of packets and/or an action to be taken on the connection. Snd-Conn-Req A transport connection is initiated with the peer. Snd-Conn-Ack an acknowledgment is sent in response to a connect request, confirming that the transport layer connection is open. Snd-Conn-Nack A negative acknowledgment is sent in response to a connect request, indicating that the request was refused. Snd-DRR A DRR message is sent to the peer. Snd-DRA A DRA message is sent to the peer. Cleanup If necessary, the connection is shutdown, and any local resources are freed. Error The transport layer connection is disconnected, either politely or abortively, in response to an error condition. Local resources are freed. Process-DRI A received DRI is processed. Disc The transport layer connection is disconnected, and local resources are freed. I-Disc When two connections exist to the same peer, disconnect the connection to the initiator. R-Disc When two connections exist to the same peer, disconnect the transport connection of the responder. Elect An election occurs (see Section 8.4 for more information). Elect-Lock Block any other elections from happening. If the election can happen in multiple threads, some form of locking is needed. If it can only happen in one thread, no action is needed. Elect-Unlock If election can happen in multiple threads, the remove the lock gotten from Elect-Lock. Error Report an error and do cleanup. Snd-DRA Send a DRA with a Result-Code AVP of DIAMETER_SUCCESS. Snd-DRA-Exist Send a DRA with a Result-Code AVP of DIAMETER_SESSION_EXISTS. Snd-DRA-Fail Send a DRA with a Result-Code AVP of DIAMETER_SESSION_DENIED. Snd-Non-DRI A non-DRI message is sent. Snd-DWR A DWR message is sent. Process-DWA The DWA message is serviced. Process A non-DRI Diameter message is serviced. 8.4 The Election Process The election is performed after receipt of either a DRR or a DRA. If this is the receipt of a DRR and the peer is not allowed to connect, a result of Not-Allowed is returned. If the Origin-FQDN received in the DRR/DRA is not a peer that already has an open connection, No-Contest is returned. Otherwise, there is a comparison of the the Origin-FQDN sent by its peer with its own Origin-FQDN (which it may or may not have actually sent). The transport layer connection with the higher value of Origin-FQDN is the one that survives. The comparison proceeds by considering the shorter OctetString to be null-padded to the length of the longer, then performing an octet by octet unsigned comparison with the first octet being most significant. If the peer is the victor, Lose-Election is returned otherwise Win-Election is returned. 8.5 Most Common State Transitions Below is a drawing of the most common state transitions where either a connection initiated (left) or requested (right) and the connection is made with no problems. States are boxed. Events are plain text. Actions are in parenthesis. All states are shown in this drawing but several events not show. +------+ |Closed| +------+ | | +-----------+ +-----------+ | | Start Rcv-Conn-Req | | (Snd-Conn-Req) (Snd-Conn-Ack) | | +---------------+ | |I-Wait-Conn-Ack| | +---------------+ | | | Rec-Conn-Ack | | | (Snd-DRR) | | | +----------+ +----------+ |I-Wait-DRA| |R-Wait-DRR| +----------+ +----------+ | | Rcv-DRA Rcv-DRR | | (Elect-Lock) (Elect-Lock) | | +-----------+ +-----------+ |I-Wait-Lock| |R-Wait-Lock| +-----------+ +-----------+ | | Locked Locked | | (Elect) (Elect) | | +--------------+ +--------------+ |I-Wait-Returns| |R-Wait-Returns| +--------------+ +--------------+ | | No-Contest No-Contest | | (Elect-Unlock) (Snd-DRA/Elect-Unlock) | | +-----------+ +-----------+ | | +----+ |OPEN| +----+ -mark From owner-aaa-bof@merit.edu Sat Jun 2 18:01:59 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13916 for ; Sat, 2 Jun 2001 18:01:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7F19291203; Sat, 2 Jun 2001 18:02:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D1A1C91205; Sat, 2 Jun 2001 18:02:00 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A8ECD91203 for ; Sat, 2 Jun 2001 18:01:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CDA875DDC0; Sat, 2 Jun 2001 18:02:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id E89335DDA5 for ; Sat, 2 Jun 2001 18:02:14 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id OAA57972; Sat, 2 Jun 2001 14:51:48 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Sat, 2 Jun 2001 14:51:48 -0700 (PDT) From: Bernard Aboba To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Multi-roundtrip Mobile IP authentication In-Reply-To: <20010601155314.N22616@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Why is this an error message rather than being handled the same way that multi-round trip EAP authentication is (e.g. by use of a Challenge method)? On Fri, 1 Jun 2001, Pat Calhoun wrote: > All, > > While fixing Issue #32, I have had to add some provisions in the base protocol > to allow for multi-round authentication exchanges. The following Result-Code > was added to handle this case: > > " DIAMETER_ERROR_MULTI_ROUND_AUTH 1001 > This informational error is returned by a Diameter server to > inform the access device that the authentication mechanism > being used required multiple round trip, and a subsequent > request needs to be issued in order for access to be granted." > > Since the base now supports this, I have made the following change to > section 2.2 of the Mobile IP extension, which handles this specific > issue: > > "An AMA message with the Result-Code set to DIAMETER_ERROR_MULTI_ROUND_AUTH > MAY include mobile node registration key AVPs (see Section 6.1) such as > the MIP-MN-to-FA-Key AVP and the MIP-MN-to-HA-Key AVP. If such an AVP > is present in the AMA message, the foreign agent MUST include the > corresponding Mobile IP key distribution extension in the Registration > Reply it sends to the mobile node. This is to support multi-roundtrip > authentication mechanisms." > > Hopefully this one is dead. > > Thanks, > > PatC > From owner-aaa-bof@merit.edu Sat Jun 2 18:10:18 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13944 for ; Sat, 2 Jun 2001 18:10:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7B45491205; Sat, 2 Jun 2001 18:10:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4933C91206; Sat, 2 Jun 2001 18:10:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2EAD091205 for ; Sat, 2 Jun 2001 18:10:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5C7675DDB5; Sat, 2 Jun 2001 18:10:26 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 9A8E55DDA5 for ; Sat, 2 Jun 2001 18:10:25 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id OAA57979; Sat, 2 Jun 2001 14:59:59 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Sat, 2 Jun 2001 14:59:59 -0700 (PDT) From: Bernard Aboba To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] proposed text for NASREQ KDC In-Reply-To: <20010601154025.M22616@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > informs the NAS what to do with the key. Without this, the NAS would have to > guess whether it should use the key for 802.11 over the air security, securing > the phone line, etc. > The NAS-Port-Type has been traditionally used by the AAA server in order to determine what keying material to provide. However, this may not be granular enough. For example, a NAS-Port-Type=802.11 can today do only WEP v1.0, but in the future might also be capable of doing WEP2, AES/OCB, etc. So I think it might make sense to have a NAS-Ciphersuite AVP that could encode the various security mechanisms the NAS is capable of implementing: PPP DES PPP 3DES PPP MPPE 802.11 WEP 802.11 WEP2 802.11 AES/OCB From owner-aaa-bof@merit.edu Sun Jun 3 13:43:42 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10502 for ; Sun, 3 Jun 2001 13:43:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B73969129D; Sun, 3 Jun 2001 13:40:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7804091222; Sun, 3 Jun 2001 13:40:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E59539129D for ; Sun, 3 Jun 2001 13:39:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B8AB35DDD3; Sun, 3 Jun 2001 13:39:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id 4ADFA5DDC5 for ; Sun, 3 Jun 2001 13:39:45 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id NAA07463 for ; Sun, 3 Jun 2001 13:30:57 -0400 (EDT) Message-Id: <4.1.20010603130125.01cd88b0@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sun, 03 Jun 2001 13:18:18 -0400 To: aaa-wg@merit.edu From: Paul Funk Subject: [AAA-WG]: [issue] OctetString with null value Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk OctetString with null value [This is a new issue, and has not been assigned a number.] Submitter name: Paul Funk Submitter email address: paul@funk.com Date first submitted: May, 20001 Reference: Document: Base Comment Type: Technical Priority: 2 Section: 4.3 Rationale/Explanation of issue: The base draft calls for the value of an OctetString to be at least one octet long (9 or 13 octets in entire AVP). This conflicts with the NASREQ requirement for a NULL EAP-Payload to signify EAP-Start. Either we must change NASREQ or we must change the definition of OctetString. Requested change: Note that RADIUS also uses an empty EAP-Message attribute to signify EAP-Start, and it would be wise to preserve that mechanism. Presumably, the motivation for requiring at least one data octet is the notion that if the value were empty the AVP shouldn't be present at all. But there is clearly a use for a distinction between empty AVPs vs. absent AVPs, as evidenced by EAP-Start. I suggest we allow OctetString to have 0-length values, and say that the AVP length must be at least 8 or 12. Paul Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-bof@merit.edu Sun Jun 3 14:50:50 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10791 for ; Sun, 3 Jun 2001 14:50:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 01B0E91224; Sun, 3 Jun 2001 14:50:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C3D8C91225; Sun, 3 Jun 2001 14:50:47 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CE0AC91224 for ; Sun, 3 Jun 2001 14:50:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BF51C5DDA0; Sun, 3 Jun 2001 14:51:03 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by segue.merit.edu (Postfix) with ESMTP id DBDD05DD94 for ; Sun, 3 Jun 2001 14:51:02 -0400 (EDT) Received: from jariws1 ([62.248.154.165]) by fep02-app.kolumbus.fi (InterMail vM.5.01.02.00 201-253-122-103-20001017) with SMTP id <20010603185048.VXSR7775.fep02-app.kolumbus.fi@jariws1>; Sun, 3 Jun 2001 21:50:48 +0300 Message-ID: <002901c0ec5e$1a5c2020$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: Cc: , "Yolanda Garcia-Serrano (ECE)" , Subject: [AAA-WG]: Accounting issue submission Date: Sun, 3 Jun 2001 21:50:47 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Here's the accounting clarification issue in an issue-form. Issue number to be assigned. Yolanda, Pat, please review the proposed modification. /Jari ------ Accounting-Record-Type and clarification Submitter name: Jari Arkko (originally Yolanda Garcia-Serrano) Submitter email address: jari.arkko@ericsson.fi Date first submitted: 16-May-2001 Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00256.html Document: Base Comment type: C Priority: 2 Section: 12.5 Rationale/Explanation of issue: The current draft version seems to have unclarity with respect to the use of the same session identity in several records, and the use of different Accounting-Record-Types over the same session. This needs to be clarified. Requested change: At the end of section 12.5, add the following text: A particular value of Accounting-Session-Id MUST appear only in one sequence of accounting records from a DIAMETER client, except for the purposes of retransmission. Note that sometimes such sequence of records is related to a higher-level session, possibly spanning several DIAMETER clients. The linking of such record sequences together lies, however, outside DIAMETER and is typically performed by postprocessing systems. It is the responsibility of the particular extensions document to define a sufficient set of AVPs so that this correlation can be done based on, for instance, IP addresses. Likewise, the extensions document MUST also define the exact concept of a session that is being accounted. For instance, the NASREQ DIAMETER extension treats a single PPP connection to a Network Access Server as one session. The one sequence that is sent MUST be either one record with Accounting-Record-Type AVP set to the value EVENT_RECORD, or several records starting with one having the value START_RECORD, followed by zero or more INTERIM_RECORD, and a single STOP_RECORD. That is, it is not allowed to mix record types, such as sending interim records followed by an event record. A particular extensions document MUST define which kind of sequences should be used for the particular application. Resolution: tbd From owner-aaa-bof@merit.edu Sun Jun 3 15:59:58 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11035 for ; Sun, 3 Jun 2001 15:59:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4B69E9122E; Sun, 3 Jun 2001 15:51:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 16D6F91233; Sun, 3 Jun 2001 15:51:38 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1B2DB9122E for ; Sun, 3 Jun 2001 15:50:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 25E455DDAB; Sun, 3 Jun 2001 15:50:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by segue.merit.edu (Postfix) with ESMTP id 7D0135DD94 for ; Sun, 3 Jun 2001 15:50:29 -0400 (EDT) Received: from jariws1 ([62.248.154.165]) by fep01-app.kolumbus.fi (InterMail vM.5.01.02.00 201-253-122-103-20001017) with SMTP id <20010603195015.SCOX21049.fep01-app.kolumbus.fi@jariws1>; Sun, 3 Jun 2001 22:50:15 +0300 Message-ID: <004501c0ec66$688156a0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: Cc: , Subject: [AAA-WG]: e2e issue submissions Date: Sun, 3 Jun 2001 22:50:14 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi folks, I've put my review comments for the e2e draft to an issue form, 7 issues total. They are: e2e draft essr/essa delay e2e mandatory status e2e draft cert names e2e cms and pki profiling e2e unnecessary step via pkcs7-mime e2e unverified certs e2e draft editorial issues (If possible, maybe we could sort the issue list according to the draft they are on, so we could get the base draft done first, then tackle these?) Jari ----- e2e draft essr/essa delay Submitter name: Jari Arkko Submitter email address: jari.arkko@ericsson.fi Date first submitted: 17-May-2001 Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00272.html Document: e2e Comment type: Technical Priority: 1 Section: - Rationale/Explanation of issue: - 3.1, the ESSR&ESSA scheme: here I think lies an issue that we should discuss in-depth and make sure we make the right design choice for DIAMETER. The way that the spec is written now, it basically requires all DIAMETER nodes to initiate the ESSR&ESSA handshake for all new domains. Nodes that do not support e2e will not be able to do this. Nodes that do support e2e are forced to an additional roundtrip delay even in the case that e2e wasn't really necessary for the domain. One way to deal with these kinds of situations is to use an optimistic mechanisms which naks the use of unsecured messages when e2e is required. However, the drawback of that is that potentially some data has already been revealed. But has it? It is hard for me to see exactly what sensitive information the first DIAMETER message versus the later ones have... this may need further analysis. I also lack a proposal how to handle the mixed security case with the currently proposed ESSR&ESSA scheme, i.e. who is responsible for doing the probing, and what support is mandated for which nodes. - The caching of ESSR&ESSA information isn't discussed. Shouldn't it be? - 5,0, the flow: what happens if the DRIs from the proxy onwards indicated that e2e security is not supported? Will the proxy return back a lower level DIAMETER error, or a fake ESSA with an error code? ----- e2e mandatory status Submitter name: Jari Arkko Submitter email address: jari.arkko@ericsson.fi Date first submitted: 17-May-2001 Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00272.html Document: e2e Comment type: Technical Priority: 1 Section: - Rationale/Explanation of issue: - Before Figure 3, you talk about the expensive transformations and the need to have a mixed security model in some cases. I agree, but shouldn't we consider this also in the discussion of where e2e extension is mandatory? I.e. not make it a must for NASes... ----- e2e draft cert names Submitter name: Jari Arkko Submitter email address: jari.arkko@ericsson.fi Date first submitted: 17-May-2001 Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00272.html Document: e2e Comment type: Technical Priority: 3 Section: - Rationale/Explanation of issue: - 3.1, the rfc822Address scheme: can we clarify the reason why the host name must take a special form? Is it because the CA might be the CA also for other nodes, but we want only a subset of nodes to be authorized to do DIAMETER. In other words, we are using the name field as a poor man's attribute certificate? I'm fine with it, just want to know... ----- e2e cms and pki profiling Submitter name: Jari Arkko Submitter email address: jari.arkko@ericsson.fi Date first submitted: 17-May-2001 Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00272.html Document: e2e Comment type: Technical Priority: 2 Section: - Rationale/Explanation of issue: - 3.2, I think it would be valuable indeed to specify a more limited profile of both the PKI and CMS parts! In my opinion this work should perhaps take place now, before we publish the DIAMETER RFCs... one way to do this is to list exactly what is really required from CMS for instance... my guess is that we actually do need only a small fraction of CMS and not all variants of encapsulations. - 6.1, the S/MIME profile reuse. Doesn't this limit the CMS to a fairly small subset? I lack sufficient knowledge of the S/MIME & CMS details to say whether something relevant is taken away, but perhaps you would care to comment on this? Note that I *do* want a small subset, but am just wondering if the s/mime subset is the one that we want. - 6.1 and 6.2, the CMS object ContentInfo. May I suggest that we explicitly state here which one of the various alternative ContentInfo representations should be used? Perhaps we need just a single one, which would simplify implementation and analysis. - The protocol provides support (although as a MAY?) for both CRLs and OCSP. Perhaps one would be enough. Or maybe we should go even further and state that if you want online or crl functionality, you must provide these outside DIAMETER... ----- e2e unnecessary step via pkcs7-mime Submitter name: Jari Arkko Submitter email address: jari.arkko@ericsson.fi Date first submitted: 17-May-2001 Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00272.html Document: e2e Comment type: Technical Priority: 2 Section: - Rationale/Explanation of issue: - In 6.1 you mention the signing of an encrypted AVP to be done through the MIME type application/ pkcs7-mime. Is this really necessary, and doesn't it introduce an unnecessary temporary (and large) object creation? We couldn't we just state that the signature applies to the BER result? ----- e2e unverified certs Submitter name: Jari Arkko Submitter email address: jari.arkko@ericsson.fi Date first submitted: 17-May-2001 Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00272.html Document: e2e Comment type: Technical Priority: 2 Section: - Rationale/Explanation of issue: - I'm wondering about the SHOULD NOT in the use of the PKI certs before they have been verified. I also see the note later in the doc. But nowhere you state what such other mechanisms might be! I really wonder why we need to do PKI schemes and then not use them... if these special cases don't need strong security, couldn't they live with hop-by-hop security? --------- e2e draft editorial issues Submitter name: Jari Arkko Submitter email address: jari.arkko@ericsson.fi Date first submitted: 17-May-2001 Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00272.html Document: e2e Comment type: Editorial Priority: 3 Section: - Rationale/Explanation of issue: - 1.0: "IPSec" => "IPsec" (elsewhere correct) - Abstract refers to non-repudiation. I seem to remember many discussions on the exact meaning of non-repudiation, perhaps it would make sense to change the text to be more specific. Like this: "..., for making it possible to prove the real sender of the data." - Figure 1, maybe the example should number the servers DIA1, DIA2, and DIA3. - 1.2: I don't understand why a node that supports e2e would not advertise this. Why not? - 3.1: "digial" => "digital" - 3.4, I would expect that the number of AVP encryptions one can do with the same symmetric key is fairly high, more like hours of use rather than minutes or few sessions. Also, perhaps the document would benefit from stating that the symmetric key optimization isn't possible for the signatures if non-repudiation is desires. (Right?) - I suppose for the example's sake you're only signing NAS->home and only encrypting Home->NAS? But still both are possible on both directions, right? - 6.5, I think it is better to keep the OCSP-desire and the nonce together. - 6.8, I think we should just drop the top CA since that cert must be known by the initiator anyway. - Reference [4]: dash might be in the wrong place. From owner-aaa-bof@merit.edu Sun Jun 3 16:53:04 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11206 for ; Sun, 3 Jun 2001 16:53:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0875391236; Sun, 3 Jun 2001 16:53:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D09E391237; Sun, 3 Jun 2001 16:53:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A3D5E91236 for ; Sun, 3 Jun 2001 16:53:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B2A145DDAB; Sun, 3 Jun 2001 16:53:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by segue.merit.edu (Postfix) with ESMTP id D09E75DD94 for ; Sun, 3 Jun 2001 16:53:17 -0400 (EDT) Received: from jariws1 ([62.248.154.165]) by fep02-app.kolumbus.fi (InterMail vM.5.01.02.00 201-253-122-103-20001017) with SMTP id <20010603205303.WFQT7775.fep02-app.kolumbus.fi@jariws1>; Sun, 3 Jun 2001 23:53:03 +0300 Message-ID: <006501c0ec6f$2ee72880$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Bernard Aboba" , "Pat Calhoun" Cc: , References: Subject: Re: [AAA-WG]: [Issue] proposed text for NASREQ KDC Date: Sun, 3 Jun 2001 23:53:03 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard writes: > The NAS-Port-Type has been traditionally used by the AAA server in order > to determine what keying material to provide. However, this may not be > granular enough. For example, a NAS-Port-Type=802.11 can today do only WEP > v1.0, but in the future might also be capable of doing WEP2, AES/OCB, etc. I think we need to separate three issues clearly here. One, several authentication methods provide session keys as a side effect in their operation. Second, home aaa servers may wish to dictate policy that some (or specific) sort of crytographic protection shall be applied. Third, user devices and e.g. NASes have certain capabilities which generally aren't the same in all the devices. As we discuss the AVPs necessary for the KDC to operate, we need to decide which of the above three aspects we are really looking at. Are we making the home aaa server the ultimate policy server? In that case it needs to deliver a lot of information regarding how the desired protection scheme is run, and with which parameters. This may not be easy in all cases. If the home AAA server delivers keys and dictates that WEP2 shall be applied, the particular NAS the user is on today might not support that. For this reason it is necessary to do what Bernard suggests, either look at the NAS-Port-Type or the NAS-Ciphersuite AVP, and therefore have the aaa server get more information on this. However, even this may not be enough, as the user device might also have some limitations in this respect. In some cases such information would be available, such as in the following: I think the 3GPP intends to use a new header field in SIP to deliver protection scheme capability information in the REGISTER messages. On some other cases this might not be available, such as in PPP we can't easily (?) ask the peer if they can do encryption without turning it on at the same time. Another way to look at this is to consider the home AAA server just as a provider of the keying material, and leaving the actual selection of schemes to the NAS and the user device. For instance, on PPP links we can negotiate the use of PPP encryption. Or on 802.1x systems Key Descriptor Frame contains an indication of which scheme should be run. Specific application protocols may have their own schemes, such as in the SIP example I gave above. How the actual selection is done, what the alternatives are and so forth would be left to the particular access type or application definitions, such as the 802.1x documents. Benefits of this approach include simplicity and the main drawback is the possibility that weaker security than desired by the home aaa server could be applied (but that could be dealt with by having the clients require a certain level by themselves). What shall we do, then? I would say this depends on how much we are required to do. I personally feel that the just-keying-material approach is sufficient, and the user/NAS can handle the rest. But I'm willing to be convinced otherwise... Jari From owner-aaa-bof@merit.edu Sun Jun 3 17:44:57 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11378 for ; Sun, 3 Jun 2001 17:44:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3F17691239; Sun, 3 Jun 2001 17:28:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0D0DA9123A; Sun, 3 Jun 2001 17:28:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E8A3C91239 for ; Sun, 3 Jun 2001 17:28:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 06D105DDD5; Sun, 3 Jun 2001 17:28:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by segue.merit.edu (Postfix) with ESMTP id 2EB1D5DDD3 for ; Sun, 3 Jun 2001 17:28:40 -0400 (EDT) Received: from jariws1 ([62.248.154.165]) by fep01-app.kolumbus.fi (InterMail vM.5.01.02.00 201-253-122-103-20001017) with SMTP id <20010603212825.SIMC21049.fep01-app.kolumbus.fi@jariws1>; Mon, 4 Jun 2001 00:28:25 +0300 Message-ID: <008d01c0ec74$20217940$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "David Spence" , "Bernard Aboba" , , "AAA Working Group" , "David Mitton" Cc: References: <3B059F74.C481A12@Interlinknetworks.com> <3B154D65.C578BA12@Interlinknetworks.com> Subject: Re: [AAA-WG]: [issue] 3GPP2 Accounting Requirements Date: Mon, 4 Jun 2001 00:28:26 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit David Spence wrote: > In thinking about this proposal since the interim meeting, I do have > one reservation. In the primary use of the Acct-Multi-Session-ID AVP > to support PPP Multilink connections, there is an authentication/ > authorization request for each single link as it comes up. Thus, > each Accounting-Request message can be matched to an authentication/ > authorization message by using the Session-ID AVP. With the 3GPP2 > standard, this will not be the case. Successive accounting sessions > do not have corresponding auth/auth sessions. Instead, one long > auth/auth session will match a series of shorter accounting sessions. I'm not sure the difference is significant. We already agreed earlier to allow accounting records for sessions that do not perform authentication/ authorization. So, for PPP multilink we get a bunch of correlated accounting records, all of which happen to be also authenticated. For 3GPP2, we also get a bunch of correlated accounting records, except that only one of them is authenticated in the DIAMETER sense. Also, the mult-session-identity would potentially be useful also elsewhere. Jari From owner-aaa-bof@merit.edu Mon Jun 4 09:52:07 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07610 for ; Mon, 4 Jun 2001 09:52:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8869A9125F; Mon, 4 Jun 2001 09:52:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5435E91260; Mon, 4 Jun 2001 09:52:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2781F9125F for ; Mon, 4 Jun 2001 09:52:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 808645DDAB; Mon, 4 Jun 2001 09:52:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 2A67E5DD94 for ; Mon, 4 Jun 2001 09:52:27 -0400 (EDT) Received: (qmail 8670 invoked by uid 500); 4 Jun 2001 13:41:48 -0000 Date: Mon, 4 Jun 2001 06:41:48 -0700 From: Pat Calhoun To: Bernard Aboba Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Multi-roundtrip Mobile IP authentication Message-ID: <20010604064148.Y22616@charizard.diameter.org> Mail-Followup-To: Bernard Aboba , Pat Calhoun , aaa-wg@merit.edu References: <20010601155314.N22616@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from aboba@internaut.com on Sat, Jun 02, 2001 at 02:51:48PM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Sat, Jun 02, 2001 at 02:51:48PM -0700, Bernard Aboba wrote: > Why is this an error message rather than being handled the same way that > multi-round trip EAP authentication is (e.g. by use of a Challenge > method)? I caught that over the weekend, and have since fixed it. It was a cut-and-paste like error :( PatC > > On Fri, 1 Jun 2001, Pat Calhoun wrote: > > > All, > > > > While fixing Issue #32, I have had to add some provisions in the base protocol > > to allow for multi-round authentication exchanges. The following Result-Code > > was added to handle this case: > > > > " DIAMETER_ERROR_MULTI_ROUND_AUTH 1001 > > This informational error is returned by a Diameter server to > > inform the access device that the authentication mechanism > > being used required multiple round trip, and a subsequent > > request needs to be issued in order for access to be granted." > > > > Since the base now supports this, I have made the following change to > > section 2.2 of the Mobile IP extension, which handles this specific > > issue: > > > > "An AMA message with the Result-Code set to DIAMETER_ERROR_MULTI_ROUND_AUTH > > MAY include mobile node registration key AVPs (see Section 6.1) such as > > the MIP-MN-to-FA-Key AVP and the MIP-MN-to-HA-Key AVP. If such an AVP > > is present in the AMA message, the foreign agent MUST include the > > corresponding Mobile IP key distribution extension in the Registration > > Reply it sends to the mobile node. This is to support multi-roundtrip > > authentication mechanisms." > > > > Hopefully this one is dead. > > > > Thanks, > > > > PatC > > > From owner-aaa-bof@merit.edu Mon Jun 4 10:23:35 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08434 for ; Mon, 4 Jun 2001 10:23:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8678B91261; Mon, 4 Jun 2001 10:23:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5A4CA91263; Mon, 4 Jun 2001 10:23:27 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4406191261 for ; Mon, 4 Jun 2001 10:23:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BFE125DDE2; Mon, 4 Jun 2001 10:23:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id F27425DDE1 for ; Mon, 4 Jun 2001 10:23:44 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA11491 for ; Mon, 4 Jun 2001 10:23:27 -0400 (EDT) Date: Mon, 4 Jun 2001 10:23:45 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: aaa-wg@merit.edu Subject: [AAA-WG]: [issue] What to do if STR is sent to unavailable server. (2nd try) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk All, I had sent this issue out earlier and got no response. My vote is for option #3. If someone wants to send an STR a second time with no Destination-FQDN, let them. -mark Submitter name: Mark Eklund Submitter email address: meklund@cisco.com Date first submitted: 24-May-2001 Reference: Document: Base Comment type: T Priority: 1 Section: Rationale/Explanation of issue: * The Session-Terminate-Request requires a Destination-FQDN * There was going to be text added to state that the Destination-FQDN should be that of the last place you authenticated. * What happens if that Destination-FQDN is down? If this is a cluster of servers, there may still be a need for the STR to be sent to the realm. Requested change: One or more of the following changes: 1. Do nothing. If the authenticating server goes down, either all the state data is lost, or session timeouts will cleanup any STRs missed. A statement as such should be added to the RFC reflecting this. 2. Make the Destination-FQDN optional. If the client receives a DIAMETER_UNABLE_TO_DELIVER, the client may send the request without a Destination-FQDN. 3. #2 above, but allow a proxy to also do this. 4. Make the Destination-FQDN optional. Add an STR-Destination AVP that is of type integer that is sent as a part of the authentication process. This would contain the Destination-Realm and optionally the Destination-FQDN to which this should be sent. ==================================================================== From owner-aaa-bof@merit.edu Mon Jun 4 10:32:18 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08662 for ; Mon, 4 Jun 2001 10:32:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 585E891263; Mon, 4 Jun 2001 10:31:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 200C691264; Mon, 4 Jun 2001 10:31:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D546E91263 for ; Mon, 4 Jun 2001 10:31:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5CAE15DDE1; Mon, 4 Jun 2001 10:32:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id D304F5DD94 for ; Mon, 4 Jun 2001 10:32:15 -0400 (EDT) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id KAA07945 for ; Mon, 4 Jun 2001 10:26:21 -0400 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id KAA13188 for ; Mon, 4 Jun 2001 10:33:01 -0400 (EDT) From: "Mark Jones" To: "IETF AAA WG" Subject: [AAA-WG]: [issue] Issue 35: Device-Reboot-Ind isn't an appropriate name Date: Mon, 4 Jun 2001 10:32:53 -0400 Message-ID: <071a01c0ed03$3d831720$2096a8c0@mjones.bridgewatersys.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA-1; boundary="----=_NextPart_000_070F_01C0ECE1.B502A4E0" X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_070F_01C0ECE1.B502A4E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Submitter name: Mark Jones Submitter email address: mjones@bridgewatersystems.com Date first submitted: Interim AAA Meeting in May, 2001 Reference: Issue #35 on http://www.diameter.org/issues.html Document: Base Comment type: T Priority: 2 Section: 3.1, 6.0, 6.2.*, 8.*, 9.2.2.4 Rationale/Explanation of issue: The Device-Reboot-Ind (DRI) command is mis-named since this command is sent when Diameter peers establish a transport connection and this does not necessarily imply a reboot of either peer. The command is sent to inform the receiver of the identity and capabilities of the sender and so Device-Capability-Request/Device-Capability-Answer are more appropriate for this command exchange. Requested changes: + Replace references to "DRI" with "DCR/DCA". + Remove section for Device-Reboot-Ind. + Add section for Device-Capability-Request: The Device-Capability-Request (DCR), indicated by the Command-Code set to 257, is sent by the initiator of the transport connection to inform a Diameter peer of the identity and capabilities of the sender. + Add section for Device-Capability-Answer: The Device-Capability-Answer (DCA), indicated by the Command-Code set to [x], is sent in response to a DCR to inform a Diameter peer of the identity and capabilities of the responder. + Command content is unchanged from DRI except that Device-Capability-Answer also contains the Result-Code AVP (DIAMETER_SUCCESS, DIAMETER_UNSUPPORTED_VERSION, DIAMETER_NO_COMMON_EXTENSION). + Update peer state machine: replace *-I-*-DRI with -DCR and *-R-*-DRI with -DCA Regards, Mark ------=_NextPart_000_070F_01C0ECE1.B502A4E0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9jCCApQw ggH9oAMCAQICAwS4ODANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDUwMTE4MTgwOFoXDTAyMDUwMTE4MTgwOFowTzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdbWpvbmVzQGJyaWRnZXdhdGVyc3lzdGVt cy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMemr5diJO/8+r2Hj3Opr9LbaVAXFgo2 Fhu0tfSSdvlMy52Y67GMoJbv0I282FWO9z4bsnuSIU7y3arEmyA78mwjTSdt2GK5QJHT6jKOqF6M 81Q5j2fU3dQwCPiCQZlOqUJEA3PySRjUQNOgnRUhoSuzGd7IMJ3Y6oeMtE8a02nTAgMBAAGjOjA4 MCgGA1UdEQQhMB+BHW1qb25lc0BicmlkZ2V3YXRlcnN5c3RlbXMuY29tMAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEEBQADgYEANyubKv2ajV9VxVe4xUDaqZbQ2DEXgGKSFWwsdC06zUucuCmeHHqT vLcoUnI8/dCbSnSwRrELpemSoqTv/99uW+jS6cN5320w1ZEBsC2RSVrSJd8LqxKALmMexgbywYvF /hMe120ctocvwnfbeZmzBIKSF7BDs8YPGzSWgsa5gKUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3 DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0 aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2 17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqAD AgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRk W3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP 6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9 edvlWsQcuQIDAQABoxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O +PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyi rNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1R hGvk+NHOd6KBMYICmzCCApcCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0 aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDBLg4MAkGBSsOAwIaBQCgggFWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDYwNDE0MzI1MVowIwYJKoZIhvcNAQkEMRYEFBEW8oUxJBXdnUdD13GYbUDBUxlq MEkGCSqGSIb3DQEJDzE8MDowCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h aWwgUlNBIDIwMDAuOC4zMAIDBLg4MA0GCSqGSIb3DQEBAQUABIGAusci6KM6+Bhhu+YWaiFNcX/5 2QNyctcVm/A+Ym101w14GrrihbDgx+XrIVAdrLcQWQ1C25p7aO7P4g8NcQwJw+tBlpnVnyzW0w8o T7tvC7fFlbjI1ii4OdUDBYe5UC25qOt6xxbJvaElMhCm1ji8HNPxkoHI29wrVU/eXeMlXBAAAAAA AAA= ------=_NextPart_000_070F_01C0ECE1.B502A4E0-- From owner-aaa-bof@merit.edu Mon Jun 4 10:34:14 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08712 for ; Mon, 4 Jun 2001 10:34:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EC77D91264; Mon, 4 Jun 2001 10:34:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B835591265; Mon, 4 Jun 2001 10:34:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8370191264 for ; Mon, 4 Jun 2001 10:34:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C1BBB5DDE1; Mon, 4 Jun 2001 10:34:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id BECD85DD94 for ; Mon, 4 Jun 2001 10:34:28 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id HAA60097; Mon, 4 Jun 2001 07:23:30 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Mon, 4 Jun 2001 07:23:30 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: Pat Calhoun , aaa-wg@merit.edu, jari.arkko@ericsson.fi Subject: Re: [AAA-WG]: [Issue] proposed text for NASREQ KDC In-Reply-To: <006501c0ec6f$2ee72880$8a1b6e0a@arenanet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > As we discuss the AVPs necessary for the KDC to operate, we need > to decide which of the above three aspects we are really looking at. > Are we making the home aaa server the ultimate policy server? In most cases, the client and NAS negotiate the level of cryptographic protection. For example, in PPP we have ECP; in 802.11 we have beacon and association messages. There are cases where the NAS may not be aware of what ciphersuite has been negotiated -- when the negotiation occurs between the client and AAA server, such as in RFC 2716. In this case, the AAA server informs the NAS as to what ciphersuite has been negotiated with the client. Similarly with keying -- the AAA server informs the NAS of the key that has already been negotiated with the client via an EAP key deriving method. Calling the AAA server "KDC" can be confusing -- because such a KDC may exist somewhere else in the system (as when Kerberos is being used within EAP). In all of this it is really the EAP method that is doing the keying, and ciphersuite negotiation, not the AAA server. I think that it would be helpful if this architecture could be explained somewhere. Otherwise, people are likely to get confused by the terminology. > If the home AAA server delivers keys > and dictates that WEP2 shall be applied WEP2 would probably be negotiated between client and NAS, in which case the AAA server would be *told* what was negotiated. If for some reason it did not like this (e.g. a better level of protection is required), then it would send a REJECT message. About the only time when the AAA server would need to tell the NAS what to do would be if protected ciphersuite negotiation is supported within the EAP method, as it is in RFC 2716. In that case, the AAA server and client negotiate a method, and then this method is reflected in subsequent negotiations between client and NAS (e.g. ECP). Typically the NAS supports the right method because the AAA server took this into account during the negotiation. > as in PPP we can't easily (?) ask the peer if they can do encryption without > turning it on at the same time. Doesn't ECP negotiation handle this? > Another way to look at this is to consider the home AAA server > just as a provider of the keying material, and leaving the actual > selection of schemes to the NAS and the user device. For instance, > on PPP links we can negotiate the use of PPP encryption. Or on > 802.1x systems Key Descriptor Frame contains an indication of > which scheme should be run. The Key descriptor frame is used mostly for conveyance of multicast keys, *after* the session key has been derived and is available to both client and AP. So it is not used for ciphersuite negotiation. I believe that the latest proposal is that this information be placed in Beacon and Association frames. > What shall we do, then? I would say this depends on how much > we are required to do. I personally feel that the just-keying-material > approach is sufficient, and the user/NAS can handle the rest. But > I'm willing to be convinced otherwise... > Typically we will expect an unprotected ciphersuite negotiation between client and NAS, in which case the AAA server only needs to be informed of what has happened. However, there are cases in which protected ciphersuite negotiation occurs between client and AAA server, in which case the AAA server needs to tell the NAS what has been negotiated. Note that since this architecture has been in use for several years now, we have some prototypes of how this can be done. See RFC 2548 for examples. From owner-aaa-bof@merit.edu Mon Jun 4 10:41:25 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08895 for ; Mon, 4 Jun 2001 10:41:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2C74E91265; Mon, 4 Jun 2001 10:41:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E83F591266; Mon, 4 Jun 2001 10:41:17 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AD6C391265 for ; Mon, 4 Jun 2001 10:41:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 306985DDE1; Mon, 4 Jun 2001 10:41:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 347165DD94 for ; Mon, 4 Jun 2001 10:41:35 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id HAA60107; Mon, 4 Jun 2001 07:30:56 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Mon, 4 Jun 2001 07:30:56 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: aaa-wg@merit.edu, pcalhoun@diameter.org, "Yolanda Garcia-Serrano (ECE)" , jari.arkko@ericsson.fi Subject: Re: [AAA-WG]: Accounting issue submission In-Reply-To: <002901c0ec5e$1a5c2020$8a1b6e0a@arenanet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Question about this recommended change. Will we now have *both* the Acct-Multi-Session-Id and some other AVP? Also, AAA has traditionally supplied the Acct-Multi-Session-Id for the explicit purpose of linking sessions together, so that this would *not* be the responsibility of the back-end system (which can have a devil of a time doing this without some help). IP addresses are generally not sufficient since they are dynamically allocated, so I don't think this is a good example to give. I do agree that the individual extension documents need to define what a session is. For PPP, a summary accounting record is issued for each link in use. Multiple links within the same session share an Acct-Multi-Session-Id. Within 802.11, a summary accounting record is issued for each client-AP session. Sessions created as a result of roaming between APs have different Session-Ids, but are linked via the Acct-Multi-Session-Id. Why can't one send Interim records, followed by a summary record? Isn't this how RADIUS accounting works? On Sun, 3 Jun 2001, Jari Arkko wrote: > > Here's the accounting clarification issue in an issue-form. > Issue number to be assigned. Yolanda, Pat, please review > the proposed modification. > > /Jari > ------ > > Accounting-Record-Type and clarification > Submitter name: Jari Arkko (originally Yolanda Garcia-Serrano) > Submitter email address: jari.arkko@ericsson.fi > Date first submitted: 16-May-2001 > Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00256.html > Document: Base > Comment type: C > Priority: 2 > Section: 12.5 > Rationale/Explanation of issue: > > The current draft version seems to have unclarity with respect to the > use of the same session identity in several records, and the use of > different Accounting-Record-Types over the same session. This needs > to be clarified. > > Requested change: > > At the end of section 12.5, add the following text: > > A particular value of Accounting-Session-Id MUST appear only > in one sequence of accounting records from a DIAMETER client, > except for the purposes of retransmission. Note that sometimes such > sequence of records is related to a higher-level session, possibly > spanning several DIAMETER clients. The linking of such record > sequences together lies, however, outside DIAMETER and is > typically performed by postprocessing systems. It is the responsibility > of the particular extensions document to define a sufficient set > of AVPs so that this correlation can be done based on, for instance, > IP addresses. Likewise, the extensions document MUST also define > the exact concept of a session that is being accounted. For instance, > the NASREQ DIAMETER extension treats a single PPP connection > to a Network Access Server as one session. > > The one sequence that is sent MUST be either one record with > Accounting-Record-Type AVP set to the value EVENT_RECORD, > or several records starting with one having the value > START_RECORD, followed by zero or more > INTERIM_RECORD, and a single STOP_RECORD. > That is, it is not allowed to mix record types, such as sending > interim records followed by an event record. A particular > extensions document MUST define which kind of sequences > should be used for the particular application. > > Resolution: tbd > > > > From owner-aaa-bof@merit.edu Mon Jun 4 10:47:14 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09019 for ; Mon, 4 Jun 2001 10:47:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 47A6491213; Mon, 4 Jun 2001 10:47:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9458491266; Mon, 4 Jun 2001 10:47:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4E90891213 for ; Mon, 4 Jun 2001 10:47:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9369F5DDE2; Mon, 4 Jun 2001 10:47:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id CE9675DD94 for ; Mon, 4 Jun 2001 10:47:34 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id HAA60114; Mon, 4 Jun 2001 07:36:44 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Mon, 4 Jun 2001 07:36:44 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: David Spence , David@Mitton.com, AAA Working Group , David Mitton , jari.arkko@ericsson.fi Subject: Re: [AAA-WG]: [issue] 3GPP2 Accounting Requirements In-Reply-To: <008d01c0ec74$20217940$8a1b6e0a@arenanet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > David Spence wrote: > > > In thinking about this proposal since the interim meeting, I do have > > one reservation. In the primary use of the Acct-Multi-Session-ID AVP > > to support PPP Multilink connections, there is an authentication/ > > authorization request for each single link as it comes up. Thus, > > each Accounting-Request message can be matched to an authentication/ > > authorization message by using the Session-ID AVP. With the 3GPP2 > > standard, this will not be the case. Successive accounting sessions > > do not have corresponding auth/auth sessions. Instead, one long > > auth/auth session will match a series of shorter accounting sessions. > The same thing is true of 802.11. If the session is established on an AP due to context transfer, then the AAA server will not have been contacted for the purposes of authentication and authorization. Instead, the context established originally is transferred to the new AP. The Acct-Multi-Session-Id links the two sessions together. From owner-aaa-bof@merit.edu Mon Jun 4 12:18:17 2001 Received: from trapdoor.merit.edu ([198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11689 for ; Mon, 4 Jun 2001 12:18:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 278BF91267; Mon, 4 Jun 2001 12:18:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E575191269; Mon, 4 Jun 2001 12:18:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A889E91267 for ; Mon, 4 Jun 2001 12:18:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5350C5DDB9; Mon, 4 Jun 2001 12:18:20 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 135255DDB4 for ; Mon, 4 Jun 2001 12:18:19 -0400 (EDT) Received: (qmail 12195 invoked by uid 500); 4 Jun 2001 16:07:39 -0000 Date: Mon, 4 Jun 2001 09:07:39 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Cc: aboba@internaut.com, jonwood@eng.sun.com Subject: [AAA-WG]: Comments on draft-ietf-aaa-transport-03.txt Message-ID: <20010604090739.A22616@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu, aboba@internaut.com, jonwood@eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, First, sorry if I'm jumping all over the document, but I am trying to read the problem statement (section 2), and then the solution (section 3), and at times, the section numbers don't necessarily line up (e.g. sections 2.5 and 3.6 discuss duplicates). So, I am not asking that the document be re-arranged, I am just justifying why my comments aren't linear. PatC ---- 1. Conflicting Nagle info Section 2.3 states "... the Nagle algorithm [12] is ineffective.", while section 3.3 states "AAA implementations MUST enable the Nagle algorithm, RFC 896 [12]." So if it is ineffective, why is it's support mandatory? 2. Multiple Connections Section 3.4 states "AAA protocols SHOULD use only a single persistent connection between a AAA client and a AAA proxy or server...". I have two issues with this text: a. The current base protocol's state machine goes out of its way to ensure that there is only one connection between two peers by running an election process when two connections are received. This text states that it is possible to have multiple connections. Is this required, or not? One of the documents will need to change. b. The new and improved base protocol makes use of the term agent to represent relay, redirect and proxies. Perhaps you want to use this overloaded term instead of proxy. 3. editorial nits in 2.5 The following is wrong "... to cache responses so as to make it possible respond to such duplicate requests more efficiently." I am not sure what the implications are of the following sentence "As a result, AAA servers must be prepared to detect duplicate requests sent to multiple servers." This implies inter-server communication of e2e ids, I think. The last sentence in this section implies that a duplicate is ignored, while in the earlier paragraph it states that one should cache responses to handle duplicates. 4. Editorial nits in 3.5 The first paragraph that head of line blocking isn't ameliorated since only a single connection is in use at a time. I assume that this text was targetted specifically for TCP, and NOT SCTP that supports streams, right? btw, the following paragraph sort-of discusses this, but this is misleading. The second paragraph discusses multiple connections, and I understand that this is between two peers, but the first paragraph introduces primary and secondaries. This then sort-of questions whether we are talking about multiple connections to a single server, or to the primary/alts. Bullet item one is in direct conflict with the actual protocol. Do we really want multiple connections? "Note that this requires a way to easily to determine whether a Request represents a new conversation or the continuation of an existing conversation." First off, "... to easily to ..." needs to be fixed. Second, the protocol doesn't really require this, but instead a way for a sender to state whether a message needs to be sent to a specific server is required. This is handled via the Desination-Host AVP (yes, all *-FQDNs have been changed to reflect the server identity issue). "...transactions that were to have been assigned..." perhaps should be changed to "... transactions that should have been assigned..." Further, I am not sure what this text really states. I presume that you aren't stating that if a message is destined for a particular server, based on the message's Destination-Host AVP, it should be sent to another server instead. Surely this could be done as an optimization if the servers were redundant, but this doesn't belong in the spec. Perhaps you really meant based on the hash table, right? "Similarly, re-opened connections not accumulating sufficient watchdog responses do not force a reconfiguration until they are returned to service." This implies that although a connection has been established with a peer, and according to the state machine it would be in the open state, it really shouldn't be used for some time. If this is true, does it need to be reflected in the state machine, or this is text sufficient? What is a table of transaction outcomes? You mean simple stats? 5. Nit in 3.6 "AAA protocols MUST support an end-to-end message identifier, to enable the home server to detect duplicates." This reads as if the protocol is missing something, and it is supported in Diameter. Perhaps change the sentence so it doesn't read as a requirement of a missing feature. 6. Clarification in 3.8 required Although if one was to look at RFC 2861, it would be obvious, this whole section doesn't make it clear that this is specifically for TCP (I believe since RFC 2861 is specifically for TCP). Perhaps SCTP has this feature built-in, or not. What does one do in regards to SCTP? ummm... same comment for 3.7 7. Terminology in 2.8 is inconsistent with base protocol The term store and forward and transport proxies is used, but never discussed in the base protocol. I would remove these, and perhaps even use agents instead of intermediaries. 8. editorial nit in 3.9.1 diamter->Diameter I honestly do not understand what the figure, or its explanation, really means 9. app vs. net driven The more usage of these terms I see in the spec, the more I believe they need to be defined in the terminology section. 10. Clarification required in 3.11 The text implies that only the NAS performs failover. However, the base protocol allows agents to handle failover, reducing the latency required by the NAS in receiving a response. So, only the agent (or client) that notices that its peer is unavailable is the one that handles the failover. Is this section implying that the base protocol needs to change? 11. Inconsistency between 3.1 and Issue 2 While the transport draft states that a NAS MUST support TCP, and MAY support SCTP, issue two states that a NAS MUST support one of the two. This was the decision at the interim meeting, from comments generated on the list that the text in the transport draft doesn't allow an SCTP only client. 12. Questions on section 3.2 What does "The watchdog is also used to re-open and validate connections that have returned to health." mean? The state machine requires that the DRR be used to set the state to open, not the watchdog. The text reads that the watchdog may be used with primary/secondary or load balancing configurations, but these concepts are introduced in later sections. Either include a reference, or change the order of the sections. "Watchdog packets are not retransmitted where AAA protocols operate over reliable transports." Huh?? "If the queue is not empty, then failover is initiated..." something is missing here. Somehow failover is detected, but it appears a little too "out of the blue" (for lack of better terms.... and caffein) "Once the primary connection has failed, subsequent requests are sent to the alternate server until the watchdog timer on the primary connection is reset." if the connection has failed, how does one send watchdogs? "The AAA client SHOULD wait to the transport to report connection" doesn't read right, as does "but MAY chose to bound this wait time by the watchdog interval, Tw." "Once three watchdog messages have been sent and responded to, the connection is returned to service, and transactions are once again sent over it." is inconsistent with the base protocol state machine. Do we need to fix the base, or leave this as an implementation issue? From owner-aaa-bof@merit.edu Mon Jun 4 13:44:58 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14181 for ; Mon, 4 Jun 2001 13:44:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C458B91270; Mon, 4 Jun 2001 13:11:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9215891271; Mon, 4 Jun 2001 13:11:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3D68F91270 for ; Mon, 4 Jun 2001 13:11:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CD4FC5DDDF; Mon, 4 Jun 2001 13:12:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 7BBD95DDB9 for ; Mon, 4 Jun 2001 13:12:16 -0400 (EDT) Received: (qmail 14119 invoked by uid 500); 4 Jun 2001 17:00:20 -0000 Date: Mon, 4 Jun 2001 10:00:20 -0700 From: Pat Calhoun To: "Yolanda Garcia-Serrano (ECE)" Cc: "'pcalhoun@diameter.org'" , "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Re: AVP code address space Message-ID: <20010604100020.G22616@charizard.diameter.org> Mail-Followup-To: "Yolanda Garcia-Serrano (ECE)" , "'pcalhoun@diameter.org'" , "'aaa-wg@merit.edu'" References: <577066326047D41180AC00508B955DDA02C00A35@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <577066326047D41180AC00508B955DDA02C00A35@eestqnt104.es.eu.ericsson.se>; from yolanda.garcia-serrano@ece.ericsson.se on Mon, Jun 04, 2001 at 07:04:20PM +0200 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Mon, Jun 04, 2001 at 07:04:20PM +0200, Yolanda Garcia-Serrano (ECE) wrote: > > So here comes the doubt, and is regarding *uniquely* under AVP Code paragraph: could the same AVP code (lets say 501) exist with different meaning for vendor Id=123456 and vendor Id=987654? In other words, the unique key that identifies an AVP is vendorId + AVP Code or just > AVP Code? You are correct. The Vendor-Id is used to identify the AVP Code namespace. The absence of the Vendor Id implies that it is zero (0), which is the IETF standards namespace. There is more explanation in the IANA considerations section 15.1.1: "the AVP Code namespace is used to identify attributes. When the Vendor ID value is set to zero (0), IANA will maintain a registry of assigned AVP codes, and in some cases also their values. AVP Codes 0-254 are managed separately as RADIUS Attribute Types [46], while the remaining namespace is available for assignment via Specification Required [12]. Vendor-Specific AVP Codes, where the Vendor-Id field in the AVP header is set to a non-zero value, is for Private Use." PatC From owner-aaa-bof@merit.edu Mon Jun 4 13:59:47 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14602 for ; Mon, 4 Jun 2001 13:59:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 715849126D; Mon, 4 Jun 2001 13:04:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2ED769126E; Mon, 4 Jun 2001 13:04:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ABC7A9126D for ; Mon, 4 Jun 2001 13:04:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5C3155DDAB; Mon, 4 Jun 2001 13:04:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 79B5A5DD9F for ; Mon, 4 Jun 2001 13:04:39 -0400 (EDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f54H4OO24526 for ; Mon, 4 Jun 2001 19:04:24 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Mon Jun 04 19:04:22 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Jun 2001 19:04:22 +0200 Message-ID: <577066326047D41180AC00508B955DDA02C00A35@eestqnt104.es.eu.ericsson.se> From: "Yolanda Garcia-Serrano (ECE)" To: "'pcalhoun@diameter.org'" , "'aaa-wg@merit.edu'" Subject: [AAA-WG]: AVP code address space Date: Mon, 4 Jun 2001 19:04:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi, Pat and others: I have a question on how the address to define AVP codes works for different vendor ids. The I-D says: -------------------------------------------------------------------------------------------------------------- 4.1 AVP Code The AVP Code identifies the attribute uniquely. ... The 'V' bit, ...... When set the AVP Code belongs to the specific vendor code address space. 4.2 Vendor-Id Any vendor wishing to implement a Diameter extension MUST use their own Vendor-ID along with their privately managed AVP address space, guaranteeing that they will not collide with any other vendor's extensions, nor with future IETF extensions. -------------------------------------------------------------------------------------------------------------- So here comes the doubt, and is regarding *uniquely* under AVP Code paragraph: could the same AVP code (lets say 501) exist with different meaning for vendor Id=123456 and vendor Id=987654? In other words, the unique key that identifies an AVP is vendorId + AVP Code or just AVP Code? Thanks in advance for your answer BR /Yolanda Garcia From owner-aaa-bof@merit.edu Mon Jun 4 14:15:10 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14999 for ; Mon, 4 Jun 2001 14:15:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9B14791273; Mon, 4 Jun 2001 13:42:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 68D9791274; Mon, 4 Jun 2001 13:42:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4042491273 for ; Mon, 4 Jun 2001 13:42:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 041725DDAB; Mon, 4 Jun 2001 13:43:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id A700C5DD9F for ; Mon, 4 Jun 2001 13:43:03 -0400 (EDT) Received: (qmail 14960 invoked by uid 500); 4 Jun 2001 17:32:24 -0000 Date: Mon, 4 Jun 2001 10:32:24 -0700 From: Pat Calhoun To: Bernard Aboba Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] proposed text for NASREQ KDC Message-ID: <20010604103223.J22616@charizard.diameter.org> Mail-Followup-To: Bernard Aboba , Pat Calhoun , aaa-wg@merit.edu References: <20010601154025.M22616@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from aboba@internaut.com on Sat, Jun 02, 2001 at 02:59:59PM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk OK, I think that I have a good handle on what is needed, and am proposing the following text. I believe this addresses the issues that were raised (sorry, I couldn't come up with a better name :( PatC ---- 2.1.7 NAS-Key-Binding AVP The NAS-Key-Binding AVP (AVP Code TBD) is of type Unsigned32, and specifies the purpose for the key. A Diameter client MAY include this AVP in a request to specify to the Diameter server the type of key it desires. This AVP MAY be present in a response from the Diameter server to inform the client of the type of key found in the NAS- Session-Key AVP. The following values are supported: PPP DES The key created is used to secure PPP links using DES [36] PPP 3DES The key created is used to secure PPP links using Triple DES [37] PPP MPPE The key created is used to secure PPP links using MPPE [38] 802.11 WEP The key created is used to secure 802.11 links using WEP [x] 802.11 WEP2 The key created is used to secure 802.11 links using WEP/2 [x] 802.11 AES/OCB The key created is used to secure 802.11 links using AES/OCB [x] From owner-aaa-bof@merit.edu Mon Jun 4 14:15:18 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15011 for ; Mon, 4 Jun 2001 14:15:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F128991271; Mon, 4 Jun 2001 13:31:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7106A91273; Mon, 4 Jun 2001 13:31:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F2A0891271 for ; Mon, 4 Jun 2001 13:31:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B5F045DDAB; Mon, 4 Jun 2001 13:31:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 389FD5DD9F for ; Mon, 4 Jun 2001 13:31:34 -0400 (EDT) Received: (qmail 14906 invoked by uid 500); 4 Jun 2001 17:20:54 -0000 Date: Mon, 4 Jun 2001 10:20:54 -0700 From: Pat Calhoun To: Bernard Aboba Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] proposed text for NASREQ KDC Message-ID: <20010604102054.I22616@charizard.diameter.org> Mail-Followup-To: Bernard Aboba , Pat Calhoun , aaa-wg@merit.edu References: <20010601154025.M22616@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from aboba@internaut.com on Sat, Jun 02, 2001 at 02:59:59PM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Sat, Jun 02, 2001 at 02:59:59PM -0700, Bernard Aboba wrote: > 802.11 WEP > 802.11 WEP2 > 802.11 AES/OCB Do you have references for these? From owner-aaa-bof@merit.edu Mon Jun 4 14:56:53 2001 Received: from trapdoor.merit.edu ([198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15748 for ; Mon, 4 Jun 2001 14:56:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 362DF9127F; Mon, 4 Jun 2001 14:55:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 038BC9127E; Mon, 4 Jun 2001 14:55:39 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1EBCA9127D for ; Mon, 4 Jun 2001 14:55:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EA9EC5DDEA; Mon, 4 Jun 2001 14:55:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by segue.merit.edu (Postfix) with ESMTP id CC0CC5DDB4 for ; Mon, 4 Jun 2001 14:55:55 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id LAA05376 for ; Mon, 4 Jun 2001 11:55:36 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id LAA24372 for ; Mon, 4 Jun 2001 11:55:36 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Jun 2001 13:55:35 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECF16@IL27EXM10.cig.mot.com> From: Cain Brian-BCAIN1 To: "'Pat Calhoun'" , Cain Brian-BCAIN1 Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: What does "Snd-Conn-Nack" mean? Date: Mon, 4 Jun 2001 13:55:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-bof@merit.edu Precedence: bulk > > > Does this work for you? > > > > I like it. I would assume we can replace the corresponding > "Rcv-Conn-Nack" > > events with the "Peer-Disc" events, too, right? > > Is this really required? Isn't the above the equivalent of > connect() failing? I'll defer to the expertise of the list. I'm under the impression that calling accept() or some such equivalent on a listening socket, will send a transport "Conn-Ack" as soon as it receives the connection request. (i.e. accept would continue to block until after it had sent the ACK). This should cause the connect() on the other side to succeed, though it would be quickly followed by a disconnection. Can someone confirm/deny this? If I'm right about the above, then I think we'd want to ADD, not replace (as I suggested before) the new disconnect events. -Brian From owner-aaa-bof@merit.edu Mon Jun 4 15:04:54 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15855 for ; Mon, 4 Jun 2001 15:04:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A5EB29127D; Mon, 4 Jun 2001 15:04:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 71AFD9127E; Mon, 4 Jun 2001 15:04:46 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 42F9E9127D for ; Mon, 4 Jun 2001 15:04:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 25AAB5DDB4; Mon, 4 Jun 2001 15:05:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 93FED5DD94 for ; Mon, 4 Jun 2001 15:05:04 -0400 (EDT) Received: (qmail 15717 invoked by uid 500); 4 Jun 2001 18:54:24 -0000 Date: Mon, 4 Jun 2001 11:54:24 -0700 From: Pat Calhoun To: Cain Brian-BCAIN1 Cc: "'Pat Calhoun'" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: What does "Snd-Conn-Nack" mean? Message-ID: <20010604115424.M22616@charizard.diameter.org> Mail-Followup-To: Cain Brian-BCAIN1 , 'Pat Calhoun' , aaa-wg@merit.edu References: <35DBB8B7AC89D4118E98009027B1009B0ECF16@IL27EXM10.cig.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B0ECF16@IL27EXM10.cig.mot.com>; from Brian.Cain@motorola.com on Mon, Jun 04, 2001 at 01:55:33PM -0500 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Mon, Jun 04, 2001 at 01:55:33PM -0500, Cain Brian-BCAIN1 wrote: > > > > Does this work for you? > > > > > > I like it. I would assume we can replace the corresponding > > "Rcv-Conn-Nack" > > > events with the "Peer-Disc" events, too, right? > > > > Is this really required? Isn't the above the equivalent of > > connect() failing? > > I'll defer to the expertise of the list. > > I'm under the impression that calling accept() or some such equivalent on a > listening socket, will send a transport "Conn-Ack" as soon as it receives > the connection request. (i.e. accept would continue to block until after it > had sent the ACK). This should cause the connect() on the other side to > succeed, though it would be quickly followed by a disconnection. > > Can someone confirm/deny this? There are really two cases. One where a connection request is unsuccessful, hence the Nack, and one where the peers decides it does not wish the connection to be established (after calling accept), and issues a disconnect. > > If I'm right about the above, then I think we'd want to ADD, not replace (as > I suggested before) the new disconnect events. I believe that the case you are talking about is already covered: Closed Start I-Snd-Conn-Req Wait-Conn-Ack R-Rcv-Conn-Req R-Snd-Conn-Ack Wait-R-DRR +-> Wait-Conn-Ack I-Rcv-Conn-Ack I-Snd-DRR Wait-I-DRA | I-Rcv-Conn-Nack Cleanup Closed | R-Rcv-Conn-Req R-Snd-Conn-Ack Wait-Conn-Ack/ | Wait-R-DRR | Timeout Error Closed | | Wait-I-DRA I-Rcv-DRA Process-DRA I-Open | R-Rcv-Conn-Req R-Snd-Conn-Ack Wait-R-DRR/ | Elect | +--> I-Peer-Disc I-Disc Closed | | Timeout Error Closed +----- Connection is accepted, state is changed to Wait-I-CEA | +--- Disconnect is sent by peer Is this handling the case you were refering to? PatC From owner-aaa-bof@merit.edu Mon Jun 4 15:33:33 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16311 for ; Mon, 4 Jun 2001 15:33:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 202CA91286; Mon, 4 Jun 2001 15:33:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E1DFC91287; Mon, 4 Jun 2001 15:33:39 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BD8CA91286 for ; Mon, 4 Jun 2001 15:33:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B970C5DDEA; Mon, 4 Jun 2001 15:33:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id B00E55DDB4 for ; Mon, 4 Jun 2001 15:33:56 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA14327; Mon, 4 Jun 2001 15:33:00 -0400 (EDT) Date: Mon, 4 Jun 2001 15:33:18 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: Cain Brian-BCAIN1 Cc: "'Pat Calhoun'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: What does "Snd-Conn-Nack" mean? In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B0ECF16@IL27EXM10.cig.mot.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Brian, In my suggested state table update (Re: [AAA-WG]: Support for multi-process), I removed all Snd-Conn-Nacks and only have Disc. -mark On Mon, 4 Jun 2001, Cain Brian-BCAIN1 wrote: > > > > Does this work for you? > > > > > > I like it. I would assume we can replace the corresponding > > "Rcv-Conn-Nack" > > > events with the "Peer-Disc" events, too, right? > > > > Is this really required? Isn't the above the equivalent of > > connect() failing? > > I'll defer to the expertise of the list. > > I'm under the impression that calling accept() or some such equivalent on a > listening socket, will send a transport "Conn-Ack" as soon as it receives > the connection request. (i.e. accept would continue to block until after it > had sent the ACK). This should cause the connect() on the other side to > succeed, though it would be quickly followed by a disconnection. > > Can someone confirm/deny this? > > If I'm right about the above, then I think we'd want to ADD, not replace (as > I suggested before) the new disconnect events. > > -Brian > From owner-aaa-bof@merit.edu Mon Jun 4 16:14:49 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18397 for ; Mon, 4 Jun 2001 16:14:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ED63191281; Mon, 4 Jun 2001 15:08:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B8F2D91280; Mon, 4 Jun 2001 15:08:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D968C91281 for ; Mon, 4 Jun 2001 15:08:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C9EEC5DDB4; Mon, 4 Jun 2001 15:09:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by segue.merit.edu (Postfix) with ESMTP id 7B7725DD94 for ; Mon, 4 Jun 2001 15:09:07 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id MAA17115 for ; Mon, 4 Jun 2001 12:08:52 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id MAA06682 for ; Mon, 4 Jun 2001 12:08:51 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Jun 2001 14:08:52 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECF17@IL27EXM10.cig.mot.com> From: Cain Brian-BCAIN1 To: "'Pat Calhoun'" Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: What does "Snd-Conn-Nack" mean? Date: Mon, 4 Jun 2001 14:08:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-bof@merit.edu Precedence: bulk > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > On Mon, Jun 04, 2001 at 01:55:33PM -0500, Cain Brian-BCAIN1 wrote: ... > > I'll defer to the expertise of the list. > > > > I'm under the impression that calling accept() or some such > equivalent on a > > listening socket, will send a transport "Conn-Ack" as soon > as it receives > > the connection request. (i.e. accept would continue to > block until after it > > had sent the ACK). This should cause the connect() on the > other side to > > succeed, though it would be quickly followed by a disconnection. > > > > Can someone confirm/deny this? > > There are really two cases. One where a connection request is > unsuccessful, hence > the Nack, and one where the peers decides it does not wish > the connection to be > established (after calling accept), and issues a disconnect. Ah. I assumed "Nack" refered to explicit TCP or SCTP messaging. I understand now. > > If I'm right about the above, then I think we'd want to > ADD, not replace (as > > I suggested before) the new disconnect events. > > I believe that the case you are talking about is already covered: You're right. From owner-aaa-bof@merit.edu Mon Jun 4 16:56:44 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19190 for ; Mon, 4 Jun 2001 16:56:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F127A9128D; Mon, 4 Jun 2001 16:56:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BAB6B9128E; Mon, 4 Jun 2001 16:56:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 965B99128D for ; Mon, 4 Jun 2001 16:56:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A25EC5DDDF; Mon, 4 Jun 2001 16:56:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 190695DDB8 for ; Mon, 4 Jun 2001 16:56:55 -0400 (EDT) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id QAA12422 for ; Mon, 4 Jun 2001 16:51:00 -0400 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id QAA08086 for ; Mon, 4 Jun 2001 16:57:39 -0400 (EDT) From: "Mark Jones" To: "IETF AAA WG" Subject: [AAA-WG]: [issue] Issue 40: Can an AVP have zero data length? Date: Mon, 4 Jun 2001 16:57:32 -0400 Message-ID: <076d01c0ed38$f94712b0$2096a8c0@mjones.bridgewatersys.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA-1; boundary="----=_NextPart_000_0762_01C0ED17.71319740" X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0762_01C0ED17.71319740 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit [Note: This appears to be a duplicate of the issue raised by Paul Funk earlier today but I'm posting it for completeness since it is already being tracked on the issues web page. If Paul agrees, I suggest we track his issue under #40 rather than create a new one.] Submitter name: Mark Jones Submitter email address: mjones@bridgewatersystems.com Date first submitted: Interim AAA Meeting in May, 2001 Reference: Issue #40 on http://www.diameter.org/issues.html Document: Base Comment type: T Priority: 2 Section: 4.3 Rationale/Explanation of issue: In section 4.3 of the base protocol draft (-04), the Data field is described as being zero or more octets in length. However, none of the data types as defined in section 4.3 of the -04 draft can have zero data bytes. From Paul's email earlier today (issue: OctetString with null value), the Octet String can have zero bytes when the EAP-Payload AVP indicates EAP-Start so the OctetString description is incorrect. Requested changes: + Update the OctetString description as follows: OctetString The data contains arbitrary data of variable length and MAY be a null value, i.e. zero data bytes. Unless otherwise noted, the AVP Length field MUST be set to at least 8 (12 if the 'V' bit is enabled). Data used to transmit (human readable) character string data uses the UTF-8 [24] character set and is NOT NULL-terminated. AVP Values of this type that do not align on a 32-bit boundary MUST have the necessary padding. Regards, Mark ------=_NextPart_000_0762_01C0ED17.71319740 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9jCCApQw ggH9oAMCAQICAwS4ODANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDUwMTE4MTgwOFoXDTAyMDUwMTE4MTgwOFowTzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdbWpvbmVzQGJyaWRnZXdhdGVyc3lzdGVt cy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMemr5diJO/8+r2Hj3Opr9LbaVAXFgo2 Fhu0tfSSdvlMy52Y67GMoJbv0I282FWO9z4bsnuSIU7y3arEmyA78mwjTSdt2GK5QJHT6jKOqF6M 81Q5j2fU3dQwCPiCQZlOqUJEA3PySRjUQNOgnRUhoSuzGd7IMJ3Y6oeMtE8a02nTAgMBAAGjOjA4 MCgGA1UdEQQhMB+BHW1qb25lc0BicmlkZ2V3YXRlcnN5c3RlbXMuY29tMAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEEBQADgYEANyubKv2ajV9VxVe4xUDaqZbQ2DEXgGKSFWwsdC06zUucuCmeHHqT vLcoUnI8/dCbSnSwRrELpemSoqTv/99uW+jS6cN5320w1ZEBsC2RSVrSJd8LqxKALmMexgbywYvF /hMe120ctocvwnfbeZmzBIKSF7BDs8YPGzSWgsa5gKUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3 DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0 aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2 17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqAD AgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRk W3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP 6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9 edvlWsQcuQIDAQABoxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O +PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyi rNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1R hGvk+NHOd6KBMYICmzCCApcCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0 aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDBLg4MAkGBSsOAwIaBQCgggFWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDYwNDIwNTczMFowIwYJKoZIhvcNAQkEMRYEFMgA2mb7RgvYkfA5OvDoARZZFmLs MEkGCSqGSIb3DQEJDzE8MDowCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h aWwgUlNBIDIwMDAuOC4zMAIDBLg4MA0GCSqGSIb3DQEBAQUABIGAmO6DYOFLq5wNL2SfbgKkWkpb 9lcMXShfzXOEIVLkpYVPoGFKC3ooE9sl0RZEh3D8CPBk5JSn4iy/SGDw0DwhQ26XLerUDH7fqEKc Nm9z0XJWY1Ml3irXw1NSqNcxp6bXtIbbtrwnEMk5bGh5mIn+epR18O2eopNGhwM/xUS/90AAAAAA AAA= ------=_NextPart_000_0762_01C0ED17.71319740-- From owner-aaa-bof@merit.edu Mon Jun 4 17:11:07 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19390 for ; Mon, 4 Jun 2001 17:11:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B67EF91290; Mon, 4 Jun 2001 17:11:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 882D591291; Mon, 4 Jun 2001 17:11:00 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 579F891290 for ; Mon, 4 Jun 2001 17:10:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 57DD55DDE2; Mon, 4 Jun 2001 17:11:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 1530C5DDB8 for ; Mon, 4 Jun 2001 17:11:19 -0400 (EDT) Received: (qmail 18352 invoked by uid 500); 4 Jun 2001 21:00:38 -0000 Date: Mon, 4 Jun 2001 14:00:38 -0700 From: Pat Calhoun To: Mark Jones Cc: IETF AAA WG Subject: Re: [AAA-WG]: [issue] Issue 40: Can an AVP have zero data length? Message-ID: <20010604140038.B22616@charizard.diameter.org> Mail-Followup-To: Mark Jones , IETF AAA WG References: <076d01c0ed38$f94712b0$2096a8c0@mjones.bridgewatersys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <076d01c0ed38$f94712b0$2096a8c0@mjones.bridgewatersys.com>; from mjones@bridgewatersystems.com on Mon, Jun 04, 2001 at 04:57:32PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Mon, Jun 04, 2001 at 04:57:32PM -0400, Mark Jones wrote: > [Note: This appears to be a duplicate of the issue raised by Paul Funk > earlier today but I'm posting it for completeness since it is already > being tracked on the issues web page. If Paul agrees, I suggest we track > his issue under #40 rather than create a new one.] We could, but I've already added the issue to the web site (and accepted it by me to be included in the base -05 since EAP will not work without this change). This issue, one the other hand, is asking for the inverse :) PatC > > Submitter name: Mark Jones > Submitter email address: mjones@bridgewatersystems.com > Date first submitted: Interim AAA Meeting in May, 2001 > Reference: Issue #40 on http://www.diameter.org/issues.html > Document: Base > Comment type: T > Priority: 2 > Section: 4.3 > Rationale/Explanation of issue: > > In section 4.3 of the base protocol draft (-04), the Data field is > described as being zero or more octets in length. However, none of the > data types as defined in section 4.3 of the -04 draft can have zero data > bytes. > > From Paul's email earlier today (issue: OctetString with null value), the > Octet String can have zero bytes when the EAP-Payload AVP indicates > EAP-Start so the OctetString description is incorrect. > > Requested changes: > > + Update the OctetString description as follows: > > OctetString > The data contains arbitrary data of variable length and MAY be > a null value, i.e. zero data bytes. Unless otherwise noted, > the AVP Length field MUST be set to at least 8 (12 if the 'V' > bit is enabled). Data used to transmit (human readable) > character string data uses the UTF-8 [24] character set and is > NOT NULL-terminated. AVP Values of this type that do not align > on a 32-bit boundary MUST have the necessary padding. > > Regards, > Mark From owner-aaa-bof@merit.edu Mon Jun 4 17:17:31 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19449 for ; Mon, 4 Jun 2001 17:17:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ED6CE91284; Mon, 4 Jun 2001 15:32:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C116C91286; Mon, 4 Jun 2001 15:32:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 866BB91284 for ; Mon, 4 Jun 2001 15:32:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 73F225DDEA; Mon, 4 Jun 2001 15:32:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 1146A5DDB4 for ; Mon, 4 Jun 2001 15:32:22 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id MAA60469; Mon, 4 Jun 2001 12:21:43 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Mon, 4 Jun 2001 12:21:42 -0700 (PDT) From: Bernard Aboba To: Pat Calhoun Cc: aaa-wg@merit.edu, david@mitton.com, jonwood@eng.sun.com Subject: Re: [AAA-WG]: Comments on draft-ietf-aaa-transport-03.txt In-Reply-To: <20010604090739.A22616@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > 1. Conflicting Nagle info > > Section 2.3 states "... the Nagle algorithm [12] is ineffective.", while > section 3.3 states "AAA implementations MUST enable the Nagle algorithm, RFC > 896 [12]." > > So if it is ineffective, why is it's support mandatory? It's only effective when requests are spaced closer together than the RTT. That's not usually the case, but when it is, Nagling is useful. I'll clarify the language on this. > > > 2. Multiple Connections > > Section 3.4 states "AAA protocols SHOULD use only a single persistent > connection between a AAA client and a AAA proxy or server...". I have two > issues with this text: > > a. The current base protocol's state machine goes out of its way > to ensure that there is only one connection between two peers > by running an election process when two connections are received. > This text states that it is possible to have multiple connections. > Is this required, or not? One of the documents will need to change. It was a SHOULD because making it mandatory seemed too harsh. I'm not clear that allowing two connections for some short period of time is really that bad, for example. If this would simplify the state machine, then I think it would be a good tradeoff. > b. The new and improved base protocol makes use of the term agent > to represent relay, redirect and proxies. Perhaps you want to > use this overloaded term instead of proxy. Actually I was intending to substitute the term "agent" for "intermediary". Where the term proxy is used, it really does mean proxy, not all agent types (at least I think so... ) > > 3. editorial nits in 2.5 > > The following is wrong "... to cache responses so as to make it possible > respond to such duplicate requests more efficiently." > > I am not sure what the implications are of the following sentence "As a > result, AAA servers must be prepared to detect duplicate requests sent to > multiple servers." This implies inter-server communication of e2e ids, I > think. In practice it means having an accounting system that can weed out dupes once received. If doing simultaneous usage assessment, it would mean caching the response or including the session-id in the database so that if a duplicate request comes in, you wouldn't send a Reject because the person was already logged in once. > > The last sentence in this section implies that a duplicate is ignored, while > in the earlier paragraph it states that one should cache responses to handle > duplicates. I think that ignoring dupes is a bad idea. The goal should be to send the same response. Whether that results from caching or not is an implementation issue. > > 4. Editorial nits in 3.5 > > The first paragraph that head of line blocking isn't ameliorated since > only a single connection is in use at a time. I assume that this text was > targetted specifically for TCP, and NOT SCTP that supports streams, right? Yes. Will clarify. > btw, the following paragraph sort-of discusses this, but this is misleading. > > The second paragraph discusses multiple connections, and I understand that > this is between two peers, but the first paragraph introduces primary > and secondaries. This then sort-of questions whether we are talking about > multiple connections to a single server, or to the primary/alts. This is multiple connections to different peers, not the same peer. > > Bullet item one is in direct conflict with the actual protocol. Do we really > want multiple connections? Don't think there's a conflict because it's about multiple peers. > > "Note that this requires a way to easily to determine whether a Request > represents a new conversation or the continuation of an existing > conversation." First off, "... to easily to ..." needs to be fixed. Second, > the protocol doesn't really require this, but instead a way for a sender > to state whether a message needs to be sent to a specific server is required. > This is handled via the Desination-Host AVP (yes, all *-FQDNs have been > changed to reflect the server identity issue). The question is whether the Destination-Host AVP MUST always be present in continuing conversations and MUST NOT be present in new conversations. If so, then this would be a suitable mechanism: if it's there, it's a continuing conversation, otherwise a new one. > > "...transactions that were to have been assigned..." perhaps should be changed > to "... transactions that should have been assigned..." Further, I am not > sure what this text really states. I presume that you aren't stating that if > a message is destined for a particular server, based on the message's > Destination-Host AVP, it should be sent to another server instead. Surely this > could be done as an optimization if the servers were redundant, but this > doesn't belong in the spec. Perhaps you really meant based on the > hash table, right? If a message has a Destination-Host AVP then it should be sent to that destination, UNLESS the destination is no longer available. Then it either is dropped, an error message is sent, or it is sent to another server. What is the appropriate action? > > "Similarly, re-opened connections not accumulating sufficient watchdog > responses do not force a reconfiguration until they are returned to service." > This implies that although a connection has been established with a peer, > and according to the state machine it would be in the open state, it really > shouldn't be used for some time. If this is true, does it need to be reflected > in the state machine, or this is text sufficient? I think that it does need to be reflected in the state machine. Note that this is only for re-opened connections, though, not new ones. > > What is a table of transaction outcomes? You mean simple stats? Yes. > > > 5. Nit in 3.6 > > "AAA protocols MUST support an end-to-end message identifier, to enable > the home server to detect duplicates." This reads as if the protocol > is missing something, and it is supported in Diameter. Perhaps change the > sentence so it doesn't read as a requirement of a missing feature. > Sure. That section was put in before this feature was added. > > 6. Clarification in 3.8 required > > Although if one was to look at RFC 2861, it would be obvious, this whole > section doesn't make it clear that this is specifically for TCP (I believe > since RFC 2861 is specifically for TCP). Perhaps SCTP has this feature > built-in, or not. What does one do in regards to SCTP? > > ummm... same comment for 3.7 Will fix. > > 7. Terminology in 2.8 is inconsistent with base protocol > > The term store and forward and transport proxies is used, but never > discussed in the base protocol. I would remove these, and perhaps even > use agents instead of intermediaries. Yup. Will change "intermediaries" to "agents". It's ok if S&F and Transport proxies aren't discussed in base -- as noted in the Appendix they're not all that useful. > > 8. editorial nit in 3.9.1 > > diamter->Diameter > > I honestly do not understand what the figure, or its explanation, really means Will try to make it more clear. > > 9. app vs. net driven > > The more usage of these terms I see in the spec, the more I believe they > need to be defined in the terminology section. OK. Will do. > > 10. Clarification required in 3.11 > > The text implies that only the NAS performs failover. However, the base > protocol allows agents to handle failover, reducing the latency required > by the NAS in receiving a response. So, only the agent (or client) that > notices that its peer is unavailable is the one that handles the > failover. > > Is this section implying that the base protocol needs to change? No. The term NAS should probably be changed to "AAA client". Agents can indeed to failover. > > 11. Inconsistency between 3.1 and Issue 2 > > While the transport draft states that a NAS MUST support TCP, and MAY support > SCTP, issue two states that a NAS MUST support one of the two. This was the > decision at the interim meeting, from comments generated on the list that > the text in the transport draft doesn't allow an SCTP only client. OK. Is there text somewhere that should be inserted here? > > 12. Questions on section 3.2 > > What does "The watchdog is also used to re-open and validate connections > that have returned to health." mean? The state machine requires that the > DRR be used to set the state to open, not the watchdog. It means that when a connection is re-opened after being closed, that it should not be used immediately until it is determined that the watchdog can be transported reliably. This could result in flapping during periods where there are connectivity problems. > > The text reads that the watchdog may be used with primary/secondary > or load balancing configurations, but these concepts are introduced > in later sections. Either include a reference, or change the order of > the sections. > > "Watchdog packets are not retransmitted where AAA protocols operate over > reliable transports." Huh?? Jon added this, to mean that the app does not send another watchdog, the re-transmission is handled by the transport. Will try to make it more clear. > > "If the queue is not empty, then failover is initiated..." something is > missing here. Somehow failover is detected, but it appears a little > too "out of the blue" (for lack of better terms.... and caffein) Failure is detected from the fact that watchdog timer has expired and the queue is not empty. > > "Once the primary connection has failed, subsequent requests are sent to the > alternate server until the watchdog timer on the primary connection > is reset." if the connection has failed, how does one send watchdogs? The connection has not been reset and so it is still open. However, the watchdog timer continues to run. It is possible that a watchdog response will eventually arrive. If another watchdog timer expires, the connection is closed. If the response arrives, then the connection can be marked as "available" again. > > "The AAA client SHOULD wait to the transport to report connection" doesn't > read right, as does "but MAY chose to bound this wait time by the watchdog > interval, Tw." > > "Once three watchdog messages have been sent and responded to, the connection > is returned to service, and transactions are once again sent over > it." is inconsistent with the base protocol state machine. Do we need > to fix the base, or leave this as an implementation issue? > I think that there is a state machine change required for this. From owner-aaa-bof@merit.edu Mon Jun 4 17:18:17 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19468 for ; Mon, 4 Jun 2001 17:18:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DAFE291292; Mon, 4 Jun 2001 17:15:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A48B391296; Mon, 4 Jun 2001 17:15:47 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D99D591292 for ; Mon, 4 Jun 2001 17:15:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 041DD5DDE2; Mon, 4 Jun 2001 17:16:03 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id E39185DDB8 for ; Mon, 4 Jun 2001 17:16:02 -0400 (EDT) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id EEF6179; Mon, 4 Jun 2001 17:15:55 -0400 (EDT) Message-ID: <3B1BFA30.720E8234@Interlinknetworks.com> Date: Mon, 04 Jun 2001 17:14:24 -0400 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Eklund Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] What to do if STR is sent to unavailable server.(2nd try) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit #3 sounds good to me. That includes #2, resend the STR without the Destination-FQDN, plus let certain types (to be specified later) of proxy resend the STR without the Destination-FQDN to relieve the client from having to do so. I must admit, I don't quite understand #4. If anyone favors it, perhaps they could elaborate. Mark Eklund wrote: > > All, > > I had sent this issue out earlier and got no response. My vote > is for option #3. If someone wants to send an STR a second time > with no Destination-FQDN, let them. > > -mark > > Submitter name: Mark Eklund > Submitter email address: meklund@cisco.com > Date first submitted: 24-May-2001 > Reference: > Document: Base > Comment type: T > Priority: 1 > Section: > Rationale/Explanation of issue: > > * The Session-Terminate-Request requires a Destination-FQDN > > * There was going to be text added to state that the Destination-FQDN > should be that of the last place you authenticated. > > * What happens if that Destination-FQDN is down? If this is a cluster > of servers, there may still be a need for the STR to be sent to the > realm. > > Requested change: > > One or more of the following changes: > > 1. Do nothing. If the authenticating server goes down, either all the > state data is lost, or session timeouts will cleanup any STRs missed. > A statement as such should be added to the RFC reflecting this. > > 2. Make the Destination-FQDN optional. If the client receives a > DIAMETER_UNABLE_TO_DELIVER, the client may send the request without > a Destination-FQDN. > > 3. #2 above, but allow a proxy to also do this. > > 4. Make the Destination-FQDN optional. Add an STR-Destination AVP > that is of type integer that is sent as a part of the authentication > process. This would contain the Destination-Realm and optionally > the Destination-FQDN to which this should be sent. > > ==================================================================== -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Mon Jun 4 17:19:19 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19502 for ; Mon, 4 Jun 2001 17:19:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B334C91294; Mon, 4 Jun 2001 17:18:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7EC079129A; Mon, 4 Jun 2001 17:18:26 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 72CCB91294 for ; Mon, 4 Jun 2001 17:18:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7DFFB5DDEA; Mon, 4 Jun 2001 17:18:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id DB20C5DDB8 for ; Mon, 4 Jun 2001 17:18:44 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA28745; Mon, 4 Jun 2001 15:18:10 -0600 (MDT) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA08483; Mon, 4 Jun 2001 14:18:05 -0700 (PDT) Received: from jafo (jafo [152.70.40.123]) by nasnfs.Eng.Sun.COM (8.10.2+Sun/8.10.2) with SMTP id f54LI1w03052; Mon, 4 Jun 2001 14:18:02 -0700 (PDT) Date: Mon, 4 Jun 2001 14:20:05 -0700 (PDT) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: [issue] 3GPP2 Accounting Requirements To: Jari Arkko Cc: David Spence , Bernard Aboba , David@Mitton.com, AAA Working Group , David Mitton , jari.arkko@ericsson.fi In-Reply-To: "Your message with ID" <008d01c0ec74$20217940$8a1b6e0a@arenanet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > David Spence wrote: > > > In thinking about this proposal since the interim meeting, I do have > > one reservation. In the primary use of the Acct-Multi-Session-ID AVP > > to support PPP Multilink connections, there is an authentication/ > > authorization request for each single link as it comes up. Thus, > > each Accounting-Request message can be matched to an authentication/ > > authorization message by using the Session-ID AVP. With the 3GPP2 > > standard, this will not be the case. Successive accounting sessions > > do not have corresponding auth/auth sessions. Instead, one long > > auth/auth session will match a series of shorter accounting sessions. > > I'm not sure the difference is significant. We already agreed earlier to > allow accounting records for sessions that do not perform authentication/ > authorization. So, for PPP multilink we get a bunch of correlated accounting > records, all of which happen to be also authenticated. For 3GPP2, we > also get a bunch of correlated accounting records, except that only one > of them is authenticated in the DIAMETER sense. > > Also, the mult-session-identity would potentially be useful also elsewhere. Well, the Mobile IP extension actually uses the Accounting-Session-Id in a special way. When the authorization answer is sent back to the access device, the message MAY include an Accounting-Session-Id, and if so, then all accounting records for the particular session MUST use the session id returned. Of course, this is only for accounting, and would solve this particular problem. My solution: Propagate this information into the definition of the Accounting- Session-Id in the base protocol. PatC From owner-aaa-bof@merit.edu Mon Jun 4 17:33:57 2001 Received: from trapdoor.merit.edu ([198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19651 for ; Mon, 4 Jun 2001 17:33:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 480AD9129B; Mon, 4 Jun 2001 17:30:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 392339129C; Mon, 4 Jun 2001 17:30:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9CE389129B for ; Mon, 4 Jun 2001 17:27:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8B8A15DDE2; Mon, 4 Jun 2001 17:27:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 8A7DB5DDB8 for ; Mon, 4 Jun 2001 17:27:56 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA15457; Mon, 4 Jun 2001 17:27:35 -0400 (EDT) Date: Mon, 4 Jun 2001 17:27:54 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: David Spence Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] What to do if STR is sent to unavailable server.(2nd try) In-Reply-To: <3B1BFA30.720E8234@Interlinknetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk David, On Mon, 4 Jun 2001, David Spence wrote: > #3 sounds good to me. That includes #2, resend the STR without the > Destination-FQDN, plus let certain types (to be specified later) of proxy > resend the STR without the Destination-FQDN to relieve the client from > having to do so. > > I must admit, I don't quite understand #4. If anyone favors it, perhaps > they could elaborate. I don't favor #4, but I'll elaborate. The basic idea was to give the server control over what is sent. It could tell the client to not use a Destination-FQDN. It would do this with an STR-Destination AVP which would be included in the AAA. -mark > > Mark Eklund wrote: > > > > All, > > > > I had sent this issue out earlier and got no response. My vote > > is for option #3. If someone wants to send an STR a second time > > with no Destination-FQDN, let them. > > > > -mark > > > > Submitter name: Mark Eklund > > Submitter email address: meklund@cisco.com > > Date first submitted: 24-May-2001 > > Reference: > > Document: Base > > Comment type: T > > Priority: 1 > > Section: > > Rationale/Explanation of issue: > > > > * The Session-Terminate-Request requires a Destination-FQDN > > > > * There was going to be text added to state that the Destination-FQDN > > should be that of the last place you authenticated. > > > > * What happens if that Destination-FQDN is down? If this is a cluster > > of servers, there may still be a need for the STR to be sent to the > > realm. > > > > Requested change: > > > > One or more of the following changes: > > > > 1. Do nothing. If the authenticating server goes down, either all the > > state data is lost, or session timeouts will cleanup any STRs missed. > > A statement as such should be added to the RFC reflecting this. > > > > 2. Make the Destination-FQDN optional. If the client receives a > > DIAMETER_UNABLE_TO_DELIVER, the client may send the request without > > a Destination-FQDN. > > > > 3. #2 above, but allow a proxy to also do this. > > > > 4. Make the Destination-FQDN optional. Add an STR-Destination AVP > > that is of type integer that is sent as a part of the authentication > > process. This would contain the Destination-Realm and optionally > > the Destination-FQDN to which this should be sent. > > > > ==================================================================== > > From owner-aaa-bof@merit.edu Mon Jun 4 17:34:25 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19665 for ; Mon, 4 Jun 2001 17:34:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CE9D49129F; Mon, 4 Jun 2001 17:31:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 93B9D912A3; Mon, 4 Jun 2001 17:31:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 99C589129F for ; Mon, 4 Jun 2001 17:31:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F2C785DDE2; Mon, 4 Jun 2001 17:31:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 52E4D5DDB8 for ; Mon, 4 Jun 2001 17:31:51 -0400 (EDT) Received: (qmail 18871 invoked by uid 500); 4 Jun 2001 21:21:10 -0000 Date: Mon, 4 Jun 2001 14:21:10 -0700 From: Pat Calhoun To: David Spence Cc: Mark Eklund , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] What to do if STR is sent to unavailable server.(2nd try) Message-ID: <20010604142110.C22616@charizard.diameter.org> Mail-Followup-To: David Spence , Mark Eklund , aaa-wg@merit.edu References: <3B1BFA30.720E8234@Interlinknetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B1BFA30.720E8234@Interlinknetworks.com>; from DSpence@Interlinknetworks.com on Mon, Jun 04, 2001 at 05:14:24PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Mon, Jun 04, 2001 at 05:14:24PM -0400, David Spence wrote: > #3 sounds good to me. That includes #2, resend the STR without the > Destination-FQDN, plus let certain types (to be specified later) of proxy > resend the STR without the Destination-FQDN to relieve the client from > having to do so. > > I must admit, I don't quite understand #4. If anyone favors it, perhaps > they could elaborate. I think that #2 is really the only sensible way of doing this. Otherwise, this requires special handling of the STR by relays, and how would a client know that it has been handled by a relay? Further, I really think that the only way to fix this is to fix #38. The home should state whether it *requires* that follow-on messages are to be sent to the same server (for the session) or not. Otherwise, sending an STR to the wrong server in the same realm MAY only cause confusion. PatC > > Mark Eklund wrote: > > > > All, > > > > I had sent this issue out earlier and got no response. My vote > > is for option #3. If someone wants to send an STR a second time > > with no Destination-FQDN, let them. > > > > -mark > > > > Submitter name: Mark Eklund > > Submitter email address: meklund@cisco.com > > Date first submitted: 24-May-2001 > > Reference: > > Document: Base > > Comment type: T > > Priority: 1 > > Section: > > Rationale/Explanation of issue: > > > > * The Session-Terminate-Request requires a Destination-FQDN > > > > * There was going to be text added to state that the Destination-FQDN > > should be that of the last place you authenticated. > > > > * What happens if that Destination-FQDN is down? If this is a cluster > > of servers, there may still be a need for the STR to be sent to the > > realm. > > > > Requested change: > > > > One or more of the following changes: > > > > 1. Do nothing. If the authenticating server goes down, either all the > > state data is lost, or session timeouts will cleanup any STRs missed. > > A statement as such should be added to the RFC reflecting this. > > > > 2. Make the Destination-FQDN optional. If the client receives a > > DIAMETER_UNABLE_TO_DELIVER, the client may send the request without > > a Destination-FQDN. > > > > 3. #2 above, but allow a proxy to also do this. > > > > 4. Make the Destination-FQDN optional. Add an STR-Destination AVP > > that is of type integer that is sent as a part of the authentication > > process. This would contain the Destination-Realm and optionally > > the Destination-FQDN to which this should be sent. > > > > ==================================================================== > > -- > David Spence email: DSpence@Interlinknetworks.com > Interlink Networks, Inc. phone: (734) 821-1203 > 775 Technology Drive, Suite 200 fax: (734) 821-1235 > Ann Arbor, MI 48108 > U.S.A. From owner-aaa-bof@merit.edu Mon Jun 4 17:35:18 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19697 for ; Mon, 4 Jun 2001 17:35:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 358149129A; Mon, 4 Jun 2001 17:32:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ED035912A7; Mon, 4 Jun 2001 17:32:15 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 790E8912A3 for ; Mon, 4 Jun 2001 17:32:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A0AC75DDE2; Mon, 4 Jun 2001 17:32:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 54F8B5DDB8 for ; Mon, 4 Jun 2001 17:32:31 -0400 (EDT) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id RAA12685; Mon, 4 Jun 2001 17:26:36 -0400 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id RAA10249; Mon, 4 Jun 2001 17:33:16 -0400 (EDT) From: "Mark Jones" To: "Pat Calhoun" Cc: "IETF AAA WG" Subject: RE: [AAA-WG]: [issue] Issue 40: Can an AVP have zero data length? Date: Mon, 4 Jun 2001 17:33:08 -0400 Message-ID: <079501c0ed3d$f2af3310$2096a8c0@mjones.bridgewatersys.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20010604140038.B22616@charizard.diameter.org> Importance: Normal Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA-1; boundary="----=_NextPart_000_078A_01C0ED1C.6AB3A840" X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_078A_01C0ED1C.6AB3A840 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Pat, > This issue, one the other hand, is asking for the inverse :) > Didn't Paul request a change to the OctetString description such that it can have 0-length values? I thought the OctetString text I suggested addressed this. What do you have for the OctetString description in the -05 draft? Regards, Mark ------=_NextPart_000_078A_01C0ED1C.6AB3A840 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9jCCApQw ggH9oAMCAQICAwS4ODANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDUwMTE4MTgwOFoXDTAyMDUwMTE4MTgwOFowTzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdbWpvbmVzQGJyaWRnZXdhdGVyc3lzdGVt cy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMemr5diJO/8+r2Hj3Opr9LbaVAXFgo2 Fhu0tfSSdvlMy52Y67GMoJbv0I282FWO9z4bsnuSIU7y3arEmyA78mwjTSdt2GK5QJHT6jKOqF6M 81Q5j2fU3dQwCPiCQZlOqUJEA3PySRjUQNOgnRUhoSuzGd7IMJ3Y6oeMtE8a02nTAgMBAAGjOjA4 MCgGA1UdEQQhMB+BHW1qb25lc0BicmlkZ2V3YXRlcnN5c3RlbXMuY29tMAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEEBQADgYEANyubKv2ajV9VxVe4xUDaqZbQ2DEXgGKSFWwsdC06zUucuCmeHHqT vLcoUnI8/dCbSnSwRrELpemSoqTv/99uW+jS6cN5320w1ZEBsC2RSVrSJd8LqxKALmMexgbywYvF /hMe120ctocvwnfbeZmzBIKSF7BDs8YPGzSWgsa5gKUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3 DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0 aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2 17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqAD AgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRk W3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP 6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9 edvlWsQcuQIDAQABoxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O +PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyi rNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1R hGvk+NHOd6KBMYICmzCCApcCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0 aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDBLg4MAkGBSsOAwIaBQCgggFWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDYwNDIxMzMwN1owIwYJKoZIhvcNAQkEMRYEFHrbz3Syu16yCBDQ716xK83oGaeB MEkGCSqGSIb3DQEJDzE8MDowCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h aWwgUlNBIDIwMDAuOC4zMAIDBLg4MA0GCSqGSIb3DQEBAQUABIGAsyyQfHLgQI3fyuw8gO1DQbRA KfabFJ/eJvFkzvMuEAthGjsjbgrUy96UmPDAT2a6Ezu1h4kSnexL5u6+IhB6Q+SaEOd3mvt/deod 7Gv3LRtn3x3JXIoM4ZGiwtNa5Yq6wwnEA4F/d2xpFPuEzfK8AZyRe1omNoTry+sUZs+ZRC8AAAAA AAA= ------=_NextPart_000_078A_01C0ED1C.6AB3A840-- From owner-aaa-bof@merit.edu Mon Jun 4 17:35:54 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19714 for ; Mon, 4 Jun 2001 17:35:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E66D7912AB; Mon, 4 Jun 2001 17:33:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ADC8E912C8; Mon, 4 Jun 2001 17:33:47 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 45A34912AB for ; Mon, 4 Jun 2001 17:33:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6D0CB5DDE2; Mon, 4 Jun 2001 17:34:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 1BFAF5DDB8 for ; Mon, 4 Jun 2001 17:34:04 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA23925; Mon, 4 Jun 2001 14:33:38 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA23462; Mon, 4 Jun 2001 14:33:37 -0700 (PDT) Received: from jafo (jafo [152.70.40.123]) by nasnfs.Eng.Sun.COM (8.10.2+Sun/8.10.2) with SMTP id f54LXVw03179; Mon, 4 Jun 2001 14:33:31 -0700 (PDT) Date: Mon, 4 Jun 2001 14:35:35 -0700 (PDT) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: [issue] 3GPP2 Accounting Requirements To: Patrice Calhoun Cc: Jari Arkko , David Spence , Bernard Aboba , David@Mitton.com, AAA Working Group , David Mitton , jari.arkko@ericsson.fi In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > > > David Spence wrote: > > > > > In thinking about this proposal since the interim meeting, I do have > > > one reservation. In the primary use of the Acct-Multi-Session-ID AVP > > > to support PPP Multilink connections, there is an authentication/ > > > authorization request for each single link as it comes up. Thus, > > > each Accounting-Request message can be matched to an authentication/ > > > authorization message by using the Session-ID AVP. With the 3GPP2 > > > standard, this will not be the case. Successive accounting sessions > > > do not have corresponding auth/auth sessions. Instead, one long > > > auth/auth session will match a series of shorter accounting sessions. > > > > I'm not sure the difference is significant. We already agreed earlier to > > allow accounting records for sessions that do not perform authentication/ > > authorization. So, for PPP multilink we get a bunch of correlated accounting > > records, all of which happen to be also authenticated. For 3GPP2, we > > also get a bunch of correlated accounting records, except that only one > > of them is authenticated in the DIAMETER sense. > > > > Also, the mult-session-identity would potentially be useful also elsewhere. > > Well, the Mobile IP extension actually uses the Accounting-Session-Id in a > special way. When the authorization answer is sent back to the access device, > the message MAY include an Accounting-Session-Id, and if so, then all > accounting records for the particular session MUST use the session id > returned. > Of course, this is only for accounting, and would solve this particular > problem. > > My solution: Propagate this information into the definition of the > Accounting- Session-Id in the base protocol. oops, Bernard is right, this *should* have been the Accounting-Multi-Session-Id AVP, not the Accounting-Session-Id. PatC From owner-aaa-bof@merit.edu Mon Jun 4 17:47:59 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19887 for ; Mon, 4 Jun 2001 17:47:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8F55391297; Mon, 4 Jun 2001 17:37:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 60F429129C; Mon, 4 Jun 2001 17:37:17 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1F67591297 for ; Mon, 4 Jun 2001 17:37:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1D2DD5DDE2; Mon, 4 Jun 2001 17:37:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id C13DB5DDB8 for ; Mon, 4 Jun 2001 17:37:35 -0400 (EDT) Received: (qmail 18914 invoked by uid 500); 4 Jun 2001 21:26:55 -0000 Date: Mon, 4 Jun 2001 14:26:55 -0700 From: Pat Calhoun To: Mark Jones Cc: Pat Calhoun , IETF AAA WG Subject: Re: [AAA-WG]: [issue] Issue 40: Can an AVP have zero data length? Message-ID: <20010604142655.D22616@charizard.diameter.org> Mail-Followup-To: Mark Jones , Pat Calhoun , IETF AAA WG References: <20010604140038.B22616@charizard.diameter.org> <079501c0ed3d$f2af3310$2096a8c0@mjones.bridgewatersys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <079501c0ed3d$f2af3310$2096a8c0@mjones.bridgewatersys.com>; from mjones@bridgewatersystems.com on Mon, Jun 04, 2001 at 05:33:08PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Mon, Jun 04, 2001 at 05:33:08PM -0400, Mark Jones wrote: > Pat, > > > This issue, one the other hand, is asking for the inverse :) > > > > Didn't Paul request a change to the OctetString description such that it > can have 0-length values? I thought the OctetString text I suggested > addressed this. > What do you have for the OctetString description in the -05 draft? hmm.... now I'm really confused. -05 currently has: The Data field is zero or more octets and contains information specific to the Attribute. The format and length of the Data field is determined by the AVP Code and AVP Length fields. The format of the Data field MAY be one of the following data types. The interpretation of the values depends on the specification of the AVP. For example, an OctetString may be used to transmit human readable string data and Unsigned32 may be used to transmit a time value. Conventions for these common interpretations are described below. OctetString The data contains arbitrary data of variable length. Unless otherwise noted, the AVP Length field MUST be set to at least 8 (12 if the 'V' bit is enabled). Data used to transmit (human readable) character string data uses the UTF-8 [24] character set and is NOT NULL-terminated. The minimum Length field MUST be 9, but can be set to any value up to 65504 bytes. AVP Values of this type that do not align on a 32-bit boundary MUST have the necessary padding. So if your issue is consistent with the above change, then we can delete Paul's issue and simply mark it as a dup. PatC From owner-aaa-bof@merit.edu Mon Jun 4 17:49:00 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19906 for ; Mon, 4 Jun 2001 17:48:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D0DC79129C; Mon, 4 Jun 2001 17:37:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9E8A6912A0; Mon, 4 Jun 2001 17:37:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 72A7A9129C for ; Mon, 4 Jun 2001 17:37:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 89C1E5DDE2; Mon, 4 Jun 2001 17:38:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id DD06A5DDB8 for ; Mon, 4 Jun 2001 17:38:16 -0400 (EDT) Received: (qmail 18930 invoked by uid 500); 4 Jun 2001 21:27:36 -0000 Date: Mon, 4 Jun 2001 14:27:36 -0700 From: Pat Calhoun To: Mark Eklund Cc: David Spence , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] What to do if STR is sent to unavailable server.(2nd try) Message-ID: <20010604142736.E22616@charizard.diameter.org> Mail-Followup-To: Mark Eklund , David Spence , aaa-wg@merit.edu References: <3B1BFA30.720E8234@Interlinknetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from meklund@cisco.com on Mon, Jun 04, 2001 at 05:27:54PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Mon, Jun 04, 2001 at 05:27:54PM -0400, Mark Eklund wrote: > David, > > On Mon, 4 Jun 2001, David Spence wrote: > > > #3 sounds good to me. That includes #2, resend the STR without the > > Destination-FQDN, plus let certain types (to be specified later) of proxy > > resend the STR without the Destination-FQDN to relieve the client from > > having to do so. > > > > I must admit, I don't quite understand #4. If anyone favors it, perhaps > > they could elaborate. > > I don't favor #4, but I'll elaborate. The basic idea was to give > the server control over what is sent. It could tell the client > to not use a Destination-FQDN. It would do this with an > STR-Destination AVP which would be included in the AAA. That's my preference. Don't send it unless the home server tells you it is ok. PatC > > -mark > > > > > Mark Eklund wrote: > > > > > > All, > > > > > > I had sent this issue out earlier and got no response. My vote > > > is for option #3. If someone wants to send an STR a second time > > > with no Destination-FQDN, let them. > > > > > > -mark > > > > > > Submitter name: Mark Eklund > > > Submitter email address: meklund@cisco.com > > > Date first submitted: 24-May-2001 > > > Reference: > > > Document: Base > > > Comment type: T > > > Priority: 1 > > > Section: > > > Rationale/Explanation of issue: > > > > > > * The Session-Terminate-Request requires a Destination-FQDN > > > > > > * There was going to be text added to state that the Destination-FQDN > > > should be that of the last place you authenticated. > > > > > > * What happens if that Destination-FQDN is down? If this is a cluster > > > of servers, there may still be a need for the STR to be sent to the > > > realm. > > > > > > Requested change: > > > > > > One or more of the following changes: > > > > > > 1. Do nothing. If the authenticating server goes down, either all the > > > state data is lost, or session timeouts will cleanup any STRs missed. > > > A statement as such should be added to the RFC reflecting this. > > > > > > 2. Make the Destination-FQDN optional. If the client receives a > > > DIAMETER_UNABLE_TO_DELIVER, the client may send the request without > > > a Destination-FQDN. > > > > > > 3. #2 above, but allow a proxy to also do this. > > > > > > 4. Make the Destination-FQDN optional. Add an STR-Destination AVP > > > that is of type integer that is sent as a part of the authentication > > > process. This would contain the Destination-Realm and optionally > > > the Destination-FQDN to which this should be sent. > > > > > > ==================================================================== > > > > > From owner-aaa-bof@merit.edu Mon Jun 4 17:52:59 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19963 for ; Mon, 4 Jun 2001 17:52:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 85DE2912A8; Mon, 4 Jun 2001 17:48:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D3E81912A5; Mon, 4 Jun 2001 17:47:38 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2B38B912A1 for ; Mon, 4 Jun 2001 17:43:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 516EE5DDE2; Mon, 4 Jun 2001 17:44:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by segue.merit.edu (Postfix) with ESMTP id 69AD05DDB8 for ; Mon, 4 Jun 2001 17:44:04 -0400 (EDT) Received: from jariws1 ([62.248.154.223]) by fep02-app.kolumbus.fi (InterMail vM.5.01.02.00 201-253-122-103-20001017) with SMTP id <20010604214348.FCQH7775.fep02-app.kolumbus.fi@jariws1>; Tue, 5 Jun 2001 00:43:48 +0300 Message-ID: <00a501c0ee08$9a246780$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Pat Calhoun" , "Bernard Aboba" Cc: References: <20010601154025.M22616@charizard.diameter.org> <20010604103223.J22616@charizard.diameter.org> Subject: Re: [AAA-WG]: [Issue] proposed text for NASREQ KDC Date: Wed, 6 Jun 2001 00:43:47 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > 2.1.7 NAS-Key-Binding AVP > > The NAS-Key-Binding AVP (AVP Code TBD) is of type Unsigned32, and > specifies the purpose for the key. A Diameter client MAY include this > AVP in a request to specify to the Diameter server the type of key it > desires. This AVP MAY be present in a response from the Diameter > server to inform the client of the type of key found in the NAS- > Session-Key AVP. The following values are supported: Looks good, just wanted to make sure we have a way to add new enumerated values _when_ new protection schemes arrive. Do we? Jari From owner-aaa-bof@merit.edu Mon Jun 4 17:56:54 2001 Received: from trapdoor.merit.edu ([198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19992 for ; Mon, 4 Jun 2001 17:56:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2BF97912E1; Mon, 4 Jun 2001 17:48:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B47D4912C8; Mon, 4 Jun 2001 17:47:26 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1693F912A5 for ; Mon, 4 Jun 2001 17:44:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B22C35DDE2; Mon, 4 Jun 2001 17:45:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 640A65DDB8 for ; Mon, 4 Jun 2001 17:45:16 -0400 (EDT) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id RAA12775; Mon, 4 Jun 2001 17:39:22 -0400 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id RAA10775; Mon, 4 Jun 2001 17:46:01 -0400 (EDT) From: "Mark Jones" To: "Pat Calhoun" Cc: "IETF AAA WG" Subject: RE: [AAA-WG]: [issue] Issue 40: Can an AVP have zero data length? Date: Mon, 4 Jun 2001 17:45:53 -0400 Message-ID: <07d301c0ed3f$bac15990$2096a8c0@mjones.bridgewatersys.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20010604142655.D22616@charizard.diameter.org> Importance: Normal Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA-1; boundary="----=_NextPart_000_07C8_01C0ED1E.32EDA210" X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_07C8_01C0ED1E.32EDA210 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Pat, > hmm.... now I'm really confused. -05 currently has: > The new text looks good to me. My "issue" #40 was really just a question I posed at the interim meeting. I noticed the discrepancy in the data types description text in -04 but was unaware of scenarios which justified a zero data length AVP. Paul answered my question with his EAP example so I consider issue #40 closed. Regards, Mark ------=_NextPart_000_07C8_01C0ED1E.32EDA210 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9jCCApQw ggH9oAMCAQICAwS4ODANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDUwMTE4MTgwOFoXDTAyMDUwMTE4MTgwOFowTzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdbWpvbmVzQGJyaWRnZXdhdGVyc3lzdGVt cy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMemr5diJO/8+r2Hj3Opr9LbaVAXFgo2 Fhu0tfSSdvlMy52Y67GMoJbv0I282FWO9z4bsnuSIU7y3arEmyA78mwjTSdt2GK5QJHT6jKOqF6M 81Q5j2fU3dQwCPiCQZlOqUJEA3PySRjUQNOgnRUhoSuzGd7IMJ3Y6oeMtE8a02nTAgMBAAGjOjA4 MCgGA1UdEQQhMB+BHW1qb25lc0BicmlkZ2V3YXRlcnN5c3RlbXMuY29tMAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEEBQADgYEANyubKv2ajV9VxVe4xUDaqZbQ2DEXgGKSFWwsdC06zUucuCmeHHqT vLcoUnI8/dCbSnSwRrELpemSoqTv/99uW+jS6cN5320w1ZEBsC2RSVrSJd8LqxKALmMexgbywYvF /hMe120ctocvwnfbeZmzBIKSF7BDs8YPGzSWgsa5gKUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3 DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0 aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2 17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqAD AgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRk W3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP 6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9 edvlWsQcuQIDAQABoxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O +PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyi rNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1R hGvk+NHOd6KBMYICmzCCApcCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0 aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDBLg4MAkGBSsOAwIaBQCgggFWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDYwNDIxNDU1MlowIwYJKoZIhvcNAQkEMRYEFIlwslJqgbjncl83/+6q/Ax0UN9z MEkGCSqGSIb3DQEJDzE8MDowCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h aWwgUlNBIDIwMDAuOC4zMAIDBLg4MA0GCSqGSIb3DQEBAQUABIGAspBKNEAPzvlDsPDRk/qs6X76 afgSHTBMyUAbw1Da/tzCpVGxeCP9F6dtkJkC+g0KPsuCH5NDtmAl3Ea+F4NE2NOMueIL/KZAuqrL z3BxngVsKsQsBtEH1gFS90xiWOhEpvGp7umH9gRWYsQU9r8PbPi0YUA3Wsz6X4ZVEzR77hQAAAAA AAA= ------=_NextPart_000_07C8_01C0ED1E.32EDA210-- From owner-aaa-bof@merit.edu Mon Jun 4 17:57:19 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20008 for ; Mon, 4 Jun 2001 17:57:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AE983912A3; Mon, 4 Jun 2001 17:56:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3A4E59132A; Mon, 4 Jun 2001 17:52:42 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B1E64912A1 for ; Mon, 4 Jun 2001 17:50:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DA5E55DDE2; Mon, 4 Jun 2001 17:50:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by segue.merit.edu (Postfix) with ESMTP id 065A95DDB8 for ; Mon, 4 Jun 2001 17:50:55 -0400 (EDT) Received: from jariws1 ([62.248.154.223]) by fep01-app.kolumbus.fi (InterMail vM.5.01.02.00 201-253-122-103-20001017) with SMTP id <20010604215039.YCW21049.fep01-app.kolumbus.fi@jariws1>; Tue, 5 Jun 2001 00:50:39 +0300 Message-ID: <00c101c0ee09$8f0ec4c0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Patrice Calhoun" Cc: "David Spence" , "Bernard Aboba" , , "AAA Working Group" , "David Mitton" , References: Subject: Re: [AAA-WG]: [issue] 3GPP2 Accounting Requirements Date: Wed, 6 Jun 2001 00:50:38 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > My solution: Propagate this information into the definition of the > > Accounting- Session-Id in the base protocol. > > oops, Bernard is right, this *should* have been the Accounting-Multi-Session-Id > AVP, not the Accounting-Session-Id. Good. If we have this, then there should be no major problem left. By the way, in the proposed text that I sent to issue #57 (http://www.diameter.org/issues.html#Issue%20#57, Accounting- Record-Type and clarification I wrote the text as if we still had only Accounting-Session-Id. That text needs to be modified to say how both Ids should be treated. Note that there still remains a need to correlate records from several nodes, even if within one node we can solve the correlation through Accounting-Multi-Session-Id.) Jari From owner-aaa-bof@merit.edu Mon Jun 4 18:10:07 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20275 for ; Mon, 4 Jun 2001 18:10:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E0689912A0; Mon, 4 Jun 2001 18:10:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ABFFF912A1; Mon, 4 Jun 2001 18:10:03 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 801DC912A0 for ; Mon, 4 Jun 2001 18:10:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 77A125DDE2; Mon, 4 Jun 2001 18:10:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by segue.merit.edu (Postfix) with ESMTP id 92BA45DDB8 for ; Mon, 4 Jun 2001 18:10:21 -0400 (EDT) Received: from jariws1 ([62.248.154.223]) by fep02-app.kolumbus.fi (InterMail vM.5.01.02.00 201-253-122-103-20001017) with SMTP id <20010604221005.FEYP7775.fep02-app.kolumbus.fi@jariws1>; Tue, 5 Jun 2001 01:10:05 +0300 Message-ID: <00e301c0ee0c$4650e9e0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Bernard Aboba" Cc: , , "Yolanda Garcia-Serrano (ECE)" , References: Subject: Re: [AAA-WG]: Accounting issue submission Date: Wed, 6 Jun 2001 01:10:04 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Question about this recommended change. Will we now have *both* the > Acct-Multi-Session-Id and some other AVP? I believe consensus to the issue #5 results in a need to add the Acct-Multi-Session-Id. We still need Acct-Session-Id as well to identify the subsessions, don't we? Otherwise there'd be no way to see for which subsession a particular Stop belongs to, for instance. > Also, AAA has traditionally supplied the Acct-Multi-Session-Id for the > explicit purpose of linking sessions together, so that this would *not* be > the responsibility of the back-end system (which can have a devil of a > time doing this without some help). IP addresses are generally not > sufficient since they are dynamically allocated, so I don't think this is > a good example to give. I agree this isn't a good example, but there may be cases where you can't implement context transfer such that the Acct-Multi-Session-Id gets transferred between nodes. One possible way forward on this issue would be to define Diameter sessions as those being identified either by Acct-Multi-Session-Id or Acct-Session-Id, and leave any further correlation issues outside the scope of Diameter, i.e. to the back-end systems. > I do agree that the individual extension documents need to define what a > session is. For PPP, a summary accounting record is issued for each link > in use. Multiple links within the same session share an > Acct-Multi-Session-Id. Within 802.11, a summary accounting record is > issued for each client-AP session. Sessions created as a result of roaming > between APs have different Session-Ids, but are linked via the > Acct-Multi-Session-Id. > > Why can't one send Interim records, followed by a summary record? Isn't > this how RADIUS accounting works? We do allow Interims to be followed by a Stop. Just that a set of Start and Interims may not be followed by an Event. Below you'll find another trial at the proposed text: /Jari -------------new proposed text--------------- At the end of section 12.5, add the following text: A particular value of Accounting-Session-Id MUST appear only in one sequence of accounting records from a DIAMETER client, except for the purposes of retransmission. Note that sometimes such sequence of records is related to a higher-level session, possibly spanning several DIAMETER clients. The linking of such record sequences together MUST be performed using the Accounting-Multi- Session-Id AVP. The extensions document MUST define the exact concept of a session that is being accounted, and MAY define the concept of a multi-session. For instance, the NASREQ DIAMETER extension treats a single PPP connection to a Network Access Server as one session, and a set of Multilink PPP sessions as one multi-session. The one sequence that is sent MUST be either one record with Accounting-Record-Type AVP set to the value EVENT_RECORD, or several records starting with one having the value START_RECORD, followed by zero or more INTERIM_RECORD, and a single STOP_RECORD. A particular extensions document MUST define which kind of sequences should be used for the particular application. From owner-aaa-bof@merit.edu Mon Jun 4 18:11:16 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20308 for ; Mon, 4 Jun 2001 18:11:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 480F4912A1; Mon, 4 Jun 2001 18:11:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 19BD2912A2; Mon, 4 Jun 2001 18:11:16 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B0A7E912A1 for ; Mon, 4 Jun 2001 18:11:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E10D75DDB8; Mon, 4 Jun 2001 18:11:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 69A415DDE2 for ; Mon, 4 Jun 2001 18:11:34 -0400 (EDT) Received: from heliopolis.eng.sun.com ([152.70.1.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA08369; Mon, 4 Jun 2001 16:11:17 -0600 (MDT) Received: from sloth (dsl199-239.Eng.Sun.COM [129.146.199.239]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA07594; Mon, 4 Jun 2001 15:11:17 -0700 (PDT) Message-Id: <200106042211.PAA07594@heliopolis.eng.sun.com> Date: Mon, 4 Jun 2001 15:11:17 -0700 (PDT) From: Jonathan Wood Reply-To: Jonathan Wood Subject: Re: [AAA-WG]: Comments on draft-ietf-aaa-transport-03.txt To: pcalhoun@diameter.org, aboba@internaut.com Cc: aaa-wg@merit.edu, david@mitton.com, Jonathan.Wood@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: bY9WyasV1ISkdSb9tIM5pA== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Sender: owner-aaa-bof@merit.edu Precedence: bulk > > > > 1. Conflicting Nagle info > > > > Section 2.3 states "... the Nagle algorithm [12] is ineffective.", while > > section 3.3 states "AAA implementations MUST enable the Nagle algorithm, RFC > > 896 [12]." > > > > So if it is ineffective, why is it's support mandatory? > > It's only effective when requests are spaced closer together than the > RTT. That's not usually the case, but when it is, Nagling is useful. I'll > clarify the language on this. Also, there is no Nagle for SCTP. I'll come up with some text for this. > > > > 3. editorial nits in 2.5 > > > > The following is wrong "... to cache responses so as to make it possible > > respond to such duplicate requests more efficiently." > > > > I am not sure what the implications are of the following sentence "As a > > result, AAA servers must be prepared to detect duplicate requests sent to > > multiple servers." This implies inter-server communication of e2e ids, I > > think. > > In practice it means having an accounting system that can weed out > dupes once received. If doing simultaneous usage assessment, it would mean > caching the response or including the session-id in the database so that > if a duplicate request comes in, you wouldn't send a Reject because the > person was already logged in once. The first paragraph of section 2.5 implies that duplicates may arrive as a result of transport-level retransmissions. However, TCP and SCTP do their own duplicate detection, and so will not pass these on to AAA. We could probably just remove the first paragraph. > > > > 8. editorial nit in 3.9.1 > > > > diamter->Diameter Actually, it should be AAA in this document. > > > > I honestly do not understand what the figure, or its explanation, really means > > Will try to make it more clear. This diagram attempts to show a way to handle the case where an agent needs to forward messages between two SCTP associations that have different numbers of streams. I'll add some clarifying text. > > 12. Questions on section 3.2 > > > > What does "The watchdog is also used to re-open and validate connections > > that have returned to health." mean? The state machine requires that the > > DRR be used to set the state to open, not the watchdog. > > It means that when a connection is re-opened after being closed, that it > should not be used immediately until it is determined that the watchdog > can be transported reliably. This could result in flapping during > periods where there are connectivity problems. The DRR is indeed elided in the text. We should clarify this. > > > > > The text reads that the watchdog may be used with primary/secondary > > or load balancing configurations, but these concepts are introduced > > in later sections. Either include a reference, or change the order of > > the sections. > > > > "Watchdog packets are not retransmitted where AAA protocols operate over > > reliable transports." Huh?? > > Jon added this, to mean that the app does not send another watchdog, the > re-transmission is handled by the transport. Will try to make it more > clear. > > > > > "If the queue is not empty, then failover is initiated..." something is > > missing here. Somehow failover is detected, but it appears a little > > too "out of the blue" (for lack of better terms.... and caffein) > > Failure is detected from the fact that watchdog timer has expired and the > queue is not empty. Maybe we should include Allison and Randy's pseudo algorithm in some form to help make this clearer? I agree it is a bit tricky to follow just from the text. > > > > > "The AAA client SHOULD wait to the transport doesn't > > read right, as does "but MAY chose to bound this wait time by the watchdog > > interval, Tw." Should read "The AAA client SHOULD wait for the transport layer to report connection" success, but MAY chose to bound this wait time by the watchdog interval, Tw." The intent is to let the transport layer decide when a connection attempt has failed (TCP and SCTP both retransmit and back off connection attempts). However, in some cases, the RTO can grow quite large, which means it may take minutes for the transport to decide that a connection attempt has failed. The second half of the sentence, "but MAY chose ..." gives the AAA layer a way out of this, by limiting the wait time to something more reasonable. Let me know if you still think it needs fixing. Jon From owner-aaa-bof@merit.edu Mon Jun 4 18:17:21 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20429 for ; Mon, 4 Jun 2001 18:17:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0E4DF912A5; Mon, 4 Jun 2001 18:15:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CDF39912C0; Mon, 4 Jun 2001 18:15:41 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BBFE2912A5 for ; Mon, 4 Jun 2001 18:15:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EC8FC5DDE2; Mon, 4 Jun 2001 18:15:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id D9BA55DDB8 for ; Mon, 4 Jun 2001 18:15:56 -0400 (EDT) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id BBA1A79; Mon, 4 Jun 2001 18:15:49 -0400 (EDT) Message-ID: <3B1C0839.64934E14@Interlinknetworks.com> Date: Mon, 04 Jun 2001 18:14:17 -0400 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Patrice Calhoun Cc: Jari Arkko , Bernard Aboba , David@Mitton.com, AAA Working Group , David Mitton , jari.arkko@ericsson.fi Subject: Re: [AAA-WG]: [issue] 3GPP2 Accounting Requirements References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I'm not sure I understand where you are going with this. I thought Jari and Bernard were arguing the the Session-ID should be different in each of the accounting records to distinguish them from each other. The Acct-Multi-Session-ID AVP would tie them all together. What I wanted was to allow the same Session-ID to appear in all the accounting messages. Some other mechanism could be used to indicate that multiple accounting records are present for the same session. My proposal would be to create a new value for the Accounting-Record-Type AVP, call it SUBSESSION_RECORD, to indicate that this record needs to be kept, but it is not the final or STOP_RECORD for the session. In either proposal, I don't see where the Acccounting-Session-Id would be needed. Patrice Calhoun wrote: > > > > > David Spence wrote: > > > > > In thinking about this proposal since the interim meeting, I do have > > > one reservation. In the primary use of the Acct-Multi-Session-ID AVP > > > to support PPP Multilink connections, there is an authentication/ > > > authorization request for each single link as it comes up. Thus, > > > each Accounting-Request message can be matched to an authentication/ > > > authorization message by using the Session-ID AVP. With the 3GPP2 > > > standard, this will not be the case. Successive accounting sessions > > > do not have corresponding auth/auth sessions. Instead, one long > > > auth/auth session will match a series of shorter accounting sessions. > > > > I'm not sure the difference is significant. We already agreed earlier to > > allow accounting records for sessions that do not perform authentication/ > > authorization. So, for PPP multilink we get a bunch of correlated accounting > > records, all of which happen to be also authenticated. For 3GPP2, we > > also get a bunch of correlated accounting records, except that only one > > of them is authenticated in the DIAMETER sense. > > > > Also, the mult-session-identity would potentially be useful also elsewhere. > > Well, the Mobile IP extension actually uses the Accounting-Session-Id in a > special way. When the authorization answer is sent back to the access device, > the message MAY include an Accounting-Session-Id, and if so, then all > accounting records for the particular session MUST use the session id returned. > Of course, this is only for accounting, and would solve this particular > problem. > > My solution: Propagate this information into the definition of the Accounting- > Session-Id in the base protocol. > > PatC -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Mon Jun 4 18:22:34 2001 Received: from trapdoor.merit.edu ([198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20501 for ; Mon, 4 Jun 2001 18:22:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 65E27912CE; Mon, 4 Jun 2001 18:19:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1D1A6912B1; Mon, 4 Jun 2001 18:19:15 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2509C912CE for ; Mon, 4 Jun 2001 18:18:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 55FA35DDBA; Mon, 4 Jun 2001 18:18:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 063BE5DDB8 for ; Mon, 4 Jun 2001 18:18:46 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA13727; Mon, 4 Jun 2001 15:18:19 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA03770; Mon, 4 Jun 2001 15:18:17 -0700 (PDT) Received: from jafo (jafo [152.70.40.123]) by nasnfs.Eng.Sun.COM (8.10.2+Sun/8.10.2) with SMTP id f54MIFw03717; Mon, 4 Jun 2001 15:18:15 -0700 (PDT) Date: Mon, 4 Jun 2001 15:20:19 -0700 (PDT) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: Accounting issue submission To: Jari Arkko Cc: Bernard Aboba , aaa-wg@merit.edu, pcalhoun@diameter.org, "Yolanda Garcia-Serrano (ECE)" , jari.arkko@ericsson.fi In-Reply-To: "Your message with ID" <00e301c0ee0c$4650e9e0$8a1b6e0a@arenanet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > > Question about this recommended change. Will we now have *both* the > > Acct-Multi-Session-Id and some other AVP? > > I believe consensus to the issue #5 results in a need to add the > Acct-Multi-Session-Id. We still need Acct-Session-Id as well to > identify the subsessions, don't we? Otherwise there'd be no > way to see for which subsession a particular Stop belongs to, > for instance. Accounting-Session-Id is already defined in the base protocol spec. I've updated the issues web page with your new proposed text. PatC From owner-aaa-bof@merit.edu Mon Jun 4 18:26:18 2001 Received: from trapdoor.merit.edu ([198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20553 for ; Mon, 4 Jun 2001 18:26:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 138EB9136A; Mon, 4 Jun 2001 18:23:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AAAF39136C; Mon, 4 Jun 2001 18:23:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6291F9136A for ; Mon, 4 Jun 2001 18:23:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8C2FD5DDE2; Mon, 4 Jun 2001 18:23:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 46A445DDBA for ; Mon, 4 Jun 2001 18:23:44 -0400 (EDT) Received: (qmail 19209 invoked by uid 500); 4 Jun 2001 22:13:00 -0000 Date: Mon, 4 Jun 2001 15:13:00 -0700 From: Pat Calhoun To: Jari Arkko Cc: Patrice Calhoun , David Spence , Bernard Aboba , David@Mitton.com, AAA Working Group , David Mitton , jari.arkko@ericsson.fi Subject: Re: [AAA-WG]: [issue] 3GPP2 Accounting Requirements Message-ID: <20010604151300.G22616@charizard.diameter.org> Mail-Followup-To: Jari Arkko , Patrice Calhoun , David Spence , Bernard Aboba , David@Mitton.com, AAA Working Group , David Mitton , jari.arkko@ericsson.fi References: <00c101c0ee09$8f0ec4c0$8a1b6e0a@arenanet.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <00c101c0ee09$8f0ec4c0$8a1b6e0a@arenanet.fi>; from jari.arkko@kolumbus.fi on Wed, Jun 06, 2001 at 12:50:38AM +0300 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Wed, Jun 06, 2001 at 12:50:38AM +0300, Jari Arkko wrote: > > > My solution: Propagate this information into the definition of the > > > Accounting- Session-Id in the base protocol. > > > > oops, Bernard is right, this *should* have been the Accounting-Multi-Session-Id > > AVP, not the Accounting-Session-Id. > > Good. If we have this, then there should be no major problem left. > > By the way, in the proposed text that I sent to issue #57 > (http://www.diameter.org/issues.html#Issue%20#57, Accounting- > Record-Type and clarification I wrote the text as if we still had only > Accounting-Session-Id. That text needs to be modified to say how > both Ids should be treated. Note that there still remains a need to > correlate records from several nodes, even if within one node we > can solve the correlation through Accounting-Multi-Session-Id.) The definition of the Accounting-Multi-Session-Id states: " The Accounting-Multi-Session-Id AVP (AVP Code 50) is of type OctetString and SHOULD be encoded in UTF08 format [13], following the format specified in section 10.3. The Accounting-Multi-Session-Id AVP is used to link together multiple related accounting sessions, where each session would have a unique Accounting-Session-Id, but the same Acounting-Multi-Session-Id AVP. This AVP MAY be returned by the Diameter server in an authorization answer, and MUST be used in all accounting messages for the given session." Is this sufficient? PatC From owner-aaa-bof@merit.edu Mon Jun 4 18:36:59 2001 Received: from trapdoor.merit.edu ([198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20703 for ; Mon, 4 Jun 2001 18:36:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D388B9136F; Mon, 4 Jun 2001 18:35:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 844AF91371; Mon, 4 Jun 2001 18:35:02 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D6C039136F for ; Mon, 4 Jun 2001 18:34:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1F1515DDBA; Mon, 4 Jun 2001 18:35:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by segue.merit.edu (Postfix) with ESMTP id 2DBAD5DDB8 for ; Mon, 4 Jun 2001 18:35:16 -0400 (EDT) Received: from jariws1 ([62.248.154.223]) by fep02-app.kolumbus.fi (InterMail vM.5.01.02.00 201-253-122-103-20001017) with SMTP id <20010604223500.FGZZ7775.fep02-app.kolumbus.fi@jariws1>; Tue, 5 Jun 2001 01:35:00 +0300 Message-ID: <013901c0ee0f$c1402320$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "David Spence" , "Patrice Calhoun" Cc: "Bernard Aboba" , , "AAA Working Group" , "David Mitton" , References: <3B1C0839.64934E14@Interlinknetworks.com> Subject: Re: [AAA-WG]: [issue] 3GPP2 Accounting Requirements Date: Wed, 6 Jun 2001 01:34:59 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I'm not sure I understand where you are going with this. I thought Jari and > Bernard were arguing the the Session-ID should be different in each of the > accounting records to distinguish them from each other. The > Acct-Multi-Session-ID AVP would tie them all together. Yes. > What I wanted was to allow the same Session-ID to appear in all the > accounting messages. Some other mechanism could be used to indicate that > multiple accounting records are present for the same session. My proposal > would be to create a new value for the Accounting-Record-Type AVP, call it > SUBSESSION_RECORD, to indicate that this record needs to be kept, but it is > not the final or STOP_RECORD for the session. Ah, now I see where you're going! But would that be sufficient? I can think of situations where we want the subsessions to survive. Say, access from base station #1 costs more than from #2... What about possibly interleaved subsessions? Also, would we need SUBSESSION_RECORD_{START, INTERIM,STOP}? In any case, wouldn't Acct-Multi-Session-Id and Acct-Session-Id do the job? Jari From owner-aaa-bof@merit.edu Mon Jun 4 19:45:52 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21529 for ; Mon, 4 Jun 2001 19:45:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 24283912AE; Mon, 4 Jun 2001 19:35:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 876589129E; Mon, 4 Jun 2001 19:34:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5D2F0912AC for ; Mon, 4 Jun 2001 19:33:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A3D295DDBA; Mon, 4 Jun 2001 19:34:03 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id DDDD35DDEF for ; Mon, 4 Jun 2001 19:31:51 -0400 (EDT) Received: (qmail 21612 invoked by uid 500); 4 Jun 2001 23:21:00 -0000 Date: Mon, 4 Jun 2001 16:21:00 -0700 From: Pat Calhoun To: Jari Arkko Cc: David Spence , Patrice Calhoun , Bernard Aboba , David@Mitton.com, AAA Working Group , David Mitton , jari.arkko@ericsson.fi Subject: Re: [AAA-WG]: [issue] 3GPP2 Accounting Requirements Message-ID: <20010604162100.I22616@charizard.diameter.org> Mail-Followup-To: Jari Arkko , David Spence , Patrice Calhoun , Bernard Aboba , David@Mitton.com, AAA Working Group , David Mitton , jari.arkko@ericsson.fi References: <3B1C0839.64934E14@Interlinknetworks.com> <013901c0ee0f$c1402320$8a1b6e0a@arenanet.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <013901c0ee0f$c1402320$8a1b6e0a@arenanet.fi>; from jari.arkko@kolumbus.fi on Wed, Jun 06, 2001 at 01:34:59AM +0300 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Wed, Jun 06, 2001 at 01:34:59AM +0300, Jari Arkko wrote: > > > I'm not sure I understand where you are going with this. I thought Jari and > > Bernard were arguing the the Session-ID should be different in each of the > > accounting records to distinguish them from each other. The > > Acct-Multi-Session-ID AVP would tie them all together. > > Yes. > > > What I wanted was to allow the same Session-ID to appear in all the > > accounting messages. Some other mechanism could be used to indicate that > > multiple accounting records are present for the same session. My proposal > > would be to create a new value for the Accounting-Record-Type AVP, call it > > SUBSESSION_RECORD, to indicate that this record needs to be kept, but it is > > not the final or STOP_RECORD for the session. > > Ah, now I see where you're going! But would that be sufficient? I can think > of situations where we want the subsessions to survive. Say, access from > base station #1 costs more than from #2... What about possibly interleaved > subsessions? Also, would we need SUBSESSION_RECORD_{START, > INTERIM,STOP}? In any case, wouldn't Acct-Multi-Session-Id and Acct-Session-Id > do the job? I support this! RADIUS Tunneling has some rather gross hacks, and introduces new accounting message types (tunneling vs. sessions). Using subsessions could be re-used for nasreq tunneling. Jari, will you propose text, or should I just "go for it". PatC From owner-aaa-bof@merit.edu Mon Jun 4 19:57:19 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21657 for ; Mon, 4 Jun 2001 19:57:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 27700912A9; Mon, 4 Jun 2001 19:36:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C797A9129E; Mon, 4 Jun 2001 19:36:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1EEAD912AC for ; Mon, 4 Jun 2001 19:35:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 59ED45DDE2; Mon, 4 Jun 2001 19:35:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 6A1B15DDBA for ; Mon, 4 Jun 2001 19:35:19 -0400 (EDT) Received: (qmail 21628 invoked by uid 500); 4 Jun 2001 23:24:38 -0000 Date: Mon, 4 Jun 2001 16:24:38 -0700 From: Pat Calhoun To: Jonathan Wood Cc: pcalhoun@diameter.org, aboba@internaut.com, aaa-wg@merit.edu, david@mitton.com Subject: Re: [AAA-WG]: Comments on draft-ietf-aaa-transport-03.txt Message-ID: <20010604162438.J22616@charizard.diameter.org> Mail-Followup-To: Jonathan Wood , pcalhoun@diameter.org, aboba@internaut.com, aaa-wg@merit.edu, david@mitton.com References: <200106042211.PAA07594@heliopolis.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106042211.PAA07594@heliopolis.eng.sun.com>; from Jonathan.Wood@Sun.COM on Mon, Jun 04, 2001 at 03:11:17PM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Mon, Jun 04, 2001 at 03:11:17PM -0700, Jonathan Wood wrote: > > > > > > "If the queue is not empty, then failover is initiated..." something is > > > missing here. Somehow failover is detected, but it appears a little > > > too "out of the blue" (for lack of better terms.... and caffein) > > > > Failure is detected from the fact that watchdog timer has expired and the > > queue is not empty. > > Maybe we should include Allison and Randy's pseudo algorithm > in some form to help make this clearer? I agree it is a bit > tricky to follow just from the text. I don't think so, but the paragraph should probably read "If a failure is detected, and the queue is not empty, then failover is initiated..." That just makes so much more sense. > > > > > > > > > "The AAA client SHOULD wait to the transport doesn't > > > read right, as does "but MAY chose to bound this wait time by the watchdog > > > interval, Tw." > > Should read "The AAA client SHOULD wait for the transport layer > to report connection" success, but MAY chose to bound this wait > time by the watchdog interval, Tw." > > The intent is to let the transport layer decide when a connection > attempt has failed (TCP and SCTP both retransmit and back off > connection attempts). However, in some cases, the RTO can > grow quite large, which means it may take minutes for the > transport to decide that a connection attempt has failed. The > second half of the sentence, "but MAY chose ..." gives the > AAA layer a way out of this, by limiting the wait time to > something more reasonable. > > Let me know if you still think it needs fixing. s/bound/bind/ PatC From owner-aaa-bof@merit.edu Mon Jun 4 20:05:16 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21747 for ; Mon, 4 Jun 2001 20:04:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9453A91364; Mon, 4 Jun 2001 19:42:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 313639136B; Mon, 4 Jun 2001 19:41:53 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0B77C91368 for ; Mon, 4 Jun 2001 19:41:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 467F15DDE7; Mon, 4 Jun 2001 19:42:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 066385DDE2 for ; Mon, 4 Jun 2001 19:42:07 -0400 (EDT) Received: (qmail 21644 invoked by uid 500); 4 Jun 2001 23:31:26 -0000 Date: Mon, 4 Jun 2001 16:31:26 -0700 From: Pat Calhoun To: Jari Arkko Cc: Pat Calhoun , Bernard Aboba , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] proposed text for NASREQ KDC Message-ID: <20010604163126.K22616@charizard.diameter.org> Mail-Followup-To: Jari Arkko , Pat Calhoun , Bernard Aboba , aaa-wg@merit.edu References: <20010601154025.M22616@charizard.diameter.org> <20010604103223.J22616@charizard.diameter.org> <00a501c0ee08$9a246780$8a1b6e0a@arenanet.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <00a501c0ee08$9a246780$8a1b6e0a@arenanet.fi>; from jari.arkko@kolumbus.fi on Wed, Jun 06, 2001 at 12:43:47AM +0300 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Wed, Jun 06, 2001 at 12:43:47AM +0300, Jari Arkko wrote: > > > 2.1.7 NAS-Key-Binding AVP > > > > The NAS-Key-Binding AVP (AVP Code TBD) is of type Unsigned32, and > > specifies the purpose for the key. A Diameter client MAY include this > > AVP in a request to specify to the Diameter server the type of key it > > desires. This AVP MAY be present in a response from the Diameter > > server to inform the client of the type of key found in the NAS- > > Session-Key AVP. The following values are supported: > > Looks good, just wanted to make sure we have a way to add new > enumerated values _when_ new protection schemes arrive. Do we? ok, I should also have included the following: 11.5 NAS-Key-Binding AVP Values As defined in Section 2.1.7, the NAS-Key-Binding AVP (AVP Code TBD) defines the values 1-6. All remaining values, other than zero, are available for assignment via a Designated Expert [12]. PatC From owner-aaa-bof@merit.edu Mon Jun 4 21:15:41 2001 Received: from trapdoor.merit.edu ([198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22575 for ; Mon, 4 Jun 2001 21:15:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 42ACC912B5; Mon, 4 Jun 2001 21:14:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0A60D9136C; Mon, 4 Jun 2001 21:14:28 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 63408912B5 for ; Mon, 4 Jun 2001 21:14:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C2A195DDE2; Mon, 4 Jun 2001 21:14:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 41FE65DDE1 for ; Mon, 4 Jun 2001 21:14:45 -0400 (EDT) Received: (qmail 21813 invoked by uid 500); 5 Jun 2001 01:04:04 -0000 Date: Mon, 4 Jun 2001 18:04:04 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: New set of drafts posted Message-ID: <20010604180404.P22616@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, In order to give people time to digest the changes that have been made to the Diameter drafts, I am sending a new version to the secretariat. The new versions, as usual, can be found at www.diameter.org. Please note that the E2E draft has changed name. After a security review, it was decided that End-to-End really wasn't an appropriate name, and has been called the CMS Security Application. Yes, extensions are now applications, as per Issue #54. I changed the issues web site considerable today. All of the closed issues are in a separate table, and the table shows the rev of the draft an issue was take care of. All open issues are in their own table. I am still waiting for a few issue description from folks, so I would appreciate if those people could send text. Enjoy, PatC From owner-aaa-bof@merit.edu Mon Jun 4 21:21:38 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22635 for ; Mon, 4 Jun 2001 21:21:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 98250912B7; Mon, 4 Jun 2001 21:21:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 69D98912B6; Mon, 4 Jun 2001 21:21:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5644B91368 for ; Mon, 4 Jun 2001 21:21:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B093D5DDE1; Mon, 4 Jun 2001 21:21:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 37C045DDB3 for ; Mon, 4 Jun 2001 21:21:54 -0400 (EDT) Received: from heliopolis.eng.sun.com ([152.70.1.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14130 for ; Mon, 4 Jun 2001 17:47:46 -0600 (MDT) Received: from sloth (dsl199-239.Eng.Sun.COM [129.146.199.239]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id QAA11186 for ; Mon, 4 Jun 2001 16:47:45 -0700 (PDT) Message-Id: <200106042347.QAA11186@heliopolis.eng.sun.com> Date: Mon, 4 Jun 2001 16:47:45 -0700 (PDT) From: Jonathan Wood Reply-To: Jonathan Wood Subject: Re: [AAA-WG]: Comments on draft-ietf-aaa-transport-03.txt To: aaa-wg@merit.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: vr1cf1Ap80HiSMYxPrRhuA== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Sender: owner-aaa-bof@merit.edu Precedence: bulk > > > > Should read "The AAA client SHOULD wait for the transport layer > > to report connection" success, but MAY chose to bound this wait > > time by the watchdog interval, Tw." > > > > The intent is to let the transport layer decide when a connection > > attempt has failed (TCP and SCTP both retransmit and back off > > connection attempts). However, in some cases, the RTO can > > grow quite large, which means it may take minutes for the > > transport to decide that a connection attempt has failed. The > > second half of the sentence, "but MAY chose ..." gives the > > AAA layer a way out of this, by limiting the wait time to > > something more reasonable. > > > > Let me know if you still think it needs fixing. > s/bound/bind/ Hmm my Websters agrees with 'bound'. How about s/bound/limit and be done with it? From owner-aaa-bof@merit.edu Mon Jun 4 21:30:00 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22740 for ; Mon, 4 Jun 2001 21:29:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EE6FE9132F; Mon, 4 Jun 2001 18:00:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BBDD691370; Mon, 4 Jun 2001 18:00:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2B17A9132F for ; Mon, 4 Jun 2001 18:00:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 553B65DDE2; Mon, 4 Jun 2001 18:00:37 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 84A6B5DDB8 for ; Mon, 4 Jun 2001 18:00:36 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA15749; Mon, 4 Jun 2001 17:59:48 -0400 (EDT) Date: Mon, 4 Jun 2001 18:00:06 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: Pat Calhoun Cc: David Spence , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] What to do if STR is sent to unavailable server.(2nd try) In-Reply-To: <20010604142736.E22616@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, Would you have a similar AVP for accounting? Would re-auth be the same AVP as STR? Can we combine option 2 and 4? AA-Destination-Config The AA-Destination-Config is of type Enumerated. It specifies how subsequent AAR and STR MUST be sent. This may be sent in either the initial authentication, or any re-auth. If not present, BOTH is used. BOTH(0) - Always use Destination-FQDN and Destination-Realm REALM(1) - Only send Destination-Realm TWICE(2) - Do BOTH. If DIAMETER_UNABLE_TO_DELIVER retransmit using REALM Acct-Destination-Config Same as above except this may be sent in accounting packets. Mobile-Destination-Config Do we need this too, or does AA-Destination-Config handle this? Also, could it be simply Destination-Config and what it configures is dependent upon what type of packet this is? Also, this would break using the presence of Destination-FQDN as an indicator of continued conversation. -mark On Mon, 4 Jun 2001, Pat Calhoun wrote: > On Mon, Jun 04, 2001 at 05:27:54PM -0400, Mark Eklund wrote: > > David, > > > > On Mon, 4 Jun 2001, David Spence wrote: > > > > > #3 sounds good to me. That includes #2, resend the STR without the > > > Destination-FQDN, plus let certain types (to be specified later) of proxy > > > resend the STR without the Destination-FQDN to relieve the client from > > > having to do so. > > > > > > I must admit, I don't quite understand #4. If anyone favors it, perhaps > > > they could elaborate. > > > > I don't favor #4, but I'll elaborate. The basic idea was to give > > the server control over what is sent. It could tell the client > > to not use a Destination-FQDN. It would do this with an > > STR-Destination AVP which would be included in the AAA. > > That's my preference. Don't send it unless the home server tells you it is ok. > > PatC > > > > -mark > > > > > > > > Mark Eklund wrote: > > > > > > > > All, > > > > > > > > I had sent this issue out earlier and got no response. My vote > > > > is for option #3. If someone wants to send an STR a second time > > > > with no Destination-FQDN, let them. > > > > > > > > -mark > > > > > > > > Submitter name: Mark Eklund > > > > Submitter email address: meklund@cisco.com > > > > Date first submitted: 24-May-2001 > > > > Reference: > > > > Document: Base > > > > Comment type: T > > > > Priority: 1 > > > > Section: > > > > Rationale/Explanation of issue: > > > > > > > > * The Session-Terminate-Request requires a Destination-FQDN > > > > > > > > * There was going to be text added to state that the Destination-FQDN > > > > should be that of the last place you authenticated. > > > > > > > > * What happens if that Destination-FQDN is down? If this is a cluster > > > > of servers, there may still be a need for the STR to be sent to the > > > > realm. > > > > > > > > Requested change: > > > > > > > > One or more of the following changes: > > > > > > > > 1. Do nothing. If the authenticating server goes down, either all the > > > > state data is lost, or session timeouts will cleanup any STRs missed. > > > > A statement as such should be added to the RFC reflecting this. > > > > > > > > 2. Make the Destination-FQDN optional. If the client receives a > > > > DIAMETER_UNABLE_TO_DELIVER, the client may send the request without > > > > a Destination-FQDN. > > > > > > > > 3. #2 above, but allow a proxy to also do this. > > > > > > > > 4. Make the Destination-FQDN optional. Add an STR-Destination AVP > > > > that is of type integer that is sent as a part of the authentication > > > > process. This would contain the Destination-Realm and optionally > > > > the Destination-FQDN to which this should be sent. > > > > > > > > ==================================================================== > > > > > > > > > From owner-aaa-bof@merit.edu Mon Jun 4 21:40:10 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23798 for ; Mon, 4 Jun 2001 21:40:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 63A0891368; Mon, 4 Jun 2001 21:40:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2EA539136B; Mon, 4 Jun 2001 21:40:03 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B464E91368 for ; Mon, 4 Jun 2001 21:40:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 25F885DDE1; Mon, 4 Jun 2001 21:40:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from tp.databus.com (p101-46.acedsl.com [160.79.101.46]) by segue.merit.edu (Postfix) with ESMTP id 4762F5DDB3 for ; Mon, 4 Jun 2001 21:40:20 -0400 (EDT) Received: (from barney@localhost) by tp.databus.com (8.11.3/8.11.3) id f551duW43968; Mon, 4 Jun 2001 21:39:56 -0400 (EDT) (envelope-from barney) Date: Mon, 4 Jun 2001 21:39:51 -0400 From: Barney Wolff To: Mark Jones , Pat Calhoun , IETF AAA WG Subject: Re: [AAA-WG]: [issue] Issue 40: Can an AVP have zero data length? Message-ID: <20010604213951.C43535@tp.databus.com> References: <20010604140038.B22616@charizard.diameter.org> <079501c0ed3d$f2af3310$2096a8c0@mjones.bridgewatersys.com> <20010604142655.D22616@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010604142655.D22616@charizard.diameter.org>; from pcalhoun@diameter.org on Mon, Jun 04, 2001 at 02:26:55PM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, is the 9 below a typo, or are you intending to say that an AVP that is intended to have human-readable text cannot be empty? If so, I respectfully disagree. But if that's the way it ends up, the text should say explicitly "An AVP defined as containing human-readable text cannot be empty." Barney On Mon, Jun 04, 2001 at 02:26:55PM -0700, Pat Calhoun wrote: > On Mon, Jun 04, 2001 at 05:33:08PM -0400, Mark Jones wrote: > > Pat, > > > > > This issue, one the other hand, is asking for the inverse :) > > > > > > > Didn't Paul request a change to the OctetString description such that it > > can have 0-length values? I thought the OctetString text I suggested > > addressed this. > > What do you have for the OctetString description in the -05 draft? > > hmm.... now I'm really confused. -05 currently has: > > The Data field is zero or more octets and contains information > specific to the Attribute. The format and length of the Data field is > determined by the AVP Code and AVP Length fields. The format of the > Data field MAY be one of the following data types. > > The interpretation of the values depends on the specification of the > AVP. For example, an OctetString may be used to transmit human > readable string data and Unsigned32 may be used to transmit a time > value. Conventions for these common interpretations are described > below. > > OctetString > The data contains arbitrary data of variable length. Unless > otherwise noted, the AVP Length field MUST be set to at least 8 > (12 if the 'V' bit is enabled). Data used to transmit (human > readable) character string data uses the UTF-8 [24] character > set and is NOT NULL-terminated. The minimum Length field MUST > be 9, but can be set to any value up to 65504 bytes. AVP Values > of this type that do not align on a 32-bit boundary MUST have > the necessary padding. > > So if your issue is consistent with the above change, then we can delete Paul's > issue and simply mark it as a dup. > > PatC > From owner-aaa-bof@merit.edu Mon Jun 4 21:48:03 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23871 for ; Mon, 4 Jun 2001 21:48:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B57A391371; Mon, 4 Jun 2001 21:47:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4689E91370; Mon, 4 Jun 2001 21:47:15 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C7B099136C for ; Mon, 4 Jun 2001 21:47:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4E8555DDE3; Mon, 4 Jun 2001 21:47:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 8FD2D5DDE2 for ; Mon, 4 Jun 2001 21:47:33 -0400 (EDT) Received: (qmail 21934 invoked by uid 500); 5 Jun 2001 01:36:52 -0000 Date: Mon, 4 Jun 2001 18:36:52 -0700 From: Pat Calhoun To: Barney Wolff Cc: Mark Jones , Pat Calhoun , IETF AAA WG Subject: Re: [AAA-WG]: [issue] Issue 40: Can an AVP have zero data length? Message-ID: <20010604183652.R22616@charizard.diameter.org> Mail-Followup-To: Barney Wolff , Mark Jones , Pat Calhoun , IETF AAA WG References: <20010604140038.B22616@charizard.diameter.org> <079501c0ed3d$f2af3310$2096a8c0@mjones.bridgewatersys.com> <20010604142655.D22616@charizard.diameter.org> <20010604213951.C43535@tp.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010604213951.C43535@tp.databus.com>; from barney@databus.com on Mon, Jun 04, 2001 at 09:39:51PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Mon, Jun 04, 2001 at 09:39:51PM -0400, Barney Wolff wrote: > Pat, is the 9 below a typo, or are you intending to say that an AVP > that is intended to have human-readable text cannot be empty? sigh. yes, I missed that one :( :( PatC > so, I respectfully disagree. But if that's the way it ends up, > the text should say explicitly "An AVP defined as containing > human-readable text cannot be empty." > > Barney > > On Mon, Jun 04, 2001 at 02:26:55PM -0700, Pat Calhoun wrote: > > On Mon, Jun 04, 2001 at 05:33:08PM -0400, Mark Jones wrote: > > > Pat, > > > > > > > This issue, one the other hand, is asking for the inverse :) > > > > > > > > > > Didn't Paul request a change to the OctetString description such that it > > > can have 0-length values? I thought the OctetString text I suggested > > > addressed this. > > > What do you have for the OctetString description in the -05 draft? > > > > hmm.... now I'm really confused. -05 currently has: > > > > The Data field is zero or more octets and contains information > > specific to the Attribute. The format and length of the Data field is > > determined by the AVP Code and AVP Length fields. The format of the > > Data field MAY be one of the following data types. > > > > The interpretation of the values depends on the specification of the > > AVP. For example, an OctetString may be used to transmit human > > readable string data and Unsigned32 may be used to transmit a time > > value. Conventions for these common interpretations are described > > below. > > > > OctetString > > The data contains arbitrary data of variable length. Unless > > otherwise noted, the AVP Length field MUST be set to at least 8 > > (12 if the 'V' bit is enabled). Data used to transmit (human > > readable) character string data uses the UTF-8 [24] character > > set and is NOT NULL-terminated. The minimum Length field MUST > > be 9, but can be set to any value up to 65504 bytes. AVP Values > > of this type that do not align on a 32-bit boundary MUST have > > the necessary padding. > > > > So if your issue is consistent with the above change, then we can delete Paul's > > issue and simply mark it as a dup. > > > > PatC > > From owner-aaa-bof@merit.edu Mon Jun 4 21:48:47 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23908 for ; Mon, 4 Jun 2001 21:48:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 19B179136C; Mon, 4 Jun 2001 21:48:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C08439136E; Mon, 4 Jun 2001 21:48:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DFC1E9136C for ; Mon, 4 Jun 2001 21:48:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 694235DDB3; Mon, 4 Jun 2001 21:48:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 4B60A5DDE1 for ; Mon, 4 Jun 2001 21:48:27 -0400 (EDT) Received: from knox6046.cisco.com (knox6046.cisco.com [161.44.216.46]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id VAA17690; Mon, 4 Jun 2001 21:48:08 -0400 (EDT) Received: (from srich@localhost) by knox6046.cisco.com (8.11.3/8.11.3) id f551rQG59302; Mon, 4 Jun 2001 21:53:26 -0400 (EDT) (envelope-from srich@cisco.com) X-Authentication-Warning: knox6046.cisco.com: srich set sender to srich@cisco.com using -f From: Steve Rich MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15132.15253.869472.994396@knox6046.cisco.com> Date: Mon, 4 Jun 2001 21:53:25 -0400 To: Jonathan Wood Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Comments on draft-ietf-aaa-transport-03.txt In-Reply-To: <200106042347.QAA11186@heliopolis.eng.sun.com> References: <200106042347.QAA11186@heliopolis.eng.sun.com> X-Mailer: VM 6.90 under Emacs 20.7.2 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Perhaps, changing to 'limit' can avoid confusion/controversy. Certainly, though, 'bound' is correct in this context, as 'bounding' something is very different than 'binding' something... $0.02, sjr Jonathan Wood writes: > > > > > > Should read "The AAA client SHOULD wait for the transport layer > > > to report connection" success, but MAY chose to bound this wait > > > time by the watchdog interval, Tw." > > > > > > The intent is to let the transport layer decide when a connection > > > attempt has failed (TCP and SCTP both retransmit and back off > > > connection attempts). However, in some cases, the RTO can > > > grow quite large, which means it may take minutes for the > > > transport to decide that a connection attempt has failed. The > > > second half of the sentence, "but MAY chose ..." gives the > > > AAA layer a way out of this, by limiting the wait time to > > > something more reasonable. > > > > > > Let me know if you still think it needs fixing. > > s/bound/bind/ > > Hmm my Websters agrees with 'bound'. How about > s/bound/limit > and be done with it? > From owner-aaa-bof@merit.edu Mon Jun 4 23:18:27 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA25705 for ; Mon, 4 Jun 2001 23:18:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6DDDC912B8; Mon, 4 Jun 2001 23:18:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F32AA91370; Mon, 4 Jun 2001 23:18:03 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A589E912B8 for ; Mon, 4 Jun 2001 23:18:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2C6E55DDE2; Mon, 4 Jun 2001 23:18:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 9C7A05DDE1 for ; Mon, 4 Jun 2001 23:18:20 -0400 (EDT) Received: (qmail 22046 invoked by uid 500); 5 Jun 2001 03:07:39 -0000 Date: Mon, 4 Jun 2001 20:07:39 -0700 From: Pat Calhoun To: Jonathan Wood Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Comments on draft-ietf-aaa-transport-03.txt Message-ID: <20010604200739.T22616@charizard.diameter.org> Mail-Followup-To: Jonathan Wood , aaa-wg@merit.edu References: <200106042347.QAA11186@heliopolis.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106042347.QAA11186@heliopolis.eng.sun.com>; from Jonathan.Wood@Sun.COM on Mon, Jun 04, 2001 at 04:47:45PM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Mon, Jun 04, 2001 at 04:47:45PM -0700, Jonathan Wood wrote: > > > > > > Should read "The AAA client SHOULD wait for the transport layer > > > to report connection" success, but MAY chose to bound this wait > > > time by the watchdog interval, Tw." > > > > > > The intent is to let the transport layer decide when a connection > > > attempt has failed (TCP and SCTP both retransmit and back off > > > connection attempts). However, in some cases, the RTO can > > > grow quite large, which means it may take minutes for the > > > transport to decide that a connection attempt has failed. The > > > second half of the sentence, "but MAY chose ..." gives the > > > AAA layer a way out of this, by limiting the wait time to > > > something more reasonable. > > > > > > Let me know if you still think it needs fixing. > > s/bound/bind/ > > Hmm my Websters agrees with 'bound'. How about > s/bound/limit > and be done with it? Deal! PatC From owner-aaa-bof@merit.edu Tue Jun 5 03:29:54 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA12531 for ; Tue, 5 Jun 2001 03:29:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6C84C912BE; Tue, 5 Jun 2001 03:12:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2910791373; Tue, 5 Jun 2001 03:12:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BAC14912BE for ; Tue, 5 Jun 2001 03:12:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B045A5DDB3; Tue, 5 Jun 2001 03:12:39 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id C80EC5DDA6 for ; Tue, 5 Jun 2001 03:12:38 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f557CSq21055 for ; Tue, 5 Jun 2001 10:12:28 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 5 Jun 2001 10:12:22 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Tue, 5 Jun 2001 10:12:22 +0300 Message-ID: <6D1A8E7871B9D211B3B00008C7490AA504E626B3@treis03nok> From: henry.haverinen@nokia.com To: pcalhoun@diameter.org Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: [Issue] proposed text for NASREQ KDC Date: Tue, 5 Jun 2001 10:12:18 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Pat, The NAS session key sections in the new NASREQ draft look pretty good to me. Many thanks. I just have an editorial comment: in section 2.1.3, the text below the ABNF grammar seems to be repetition of the first paragraph of 2.1.3. I think you can simply delete it. Regards, Henry From owner-aaa-bof@merit.edu Tue Jun 5 05:31:08 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA13706 for ; Tue, 5 Jun 2001 05:31:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6B4D3912BF; Tue, 5 Jun 2001 05:30:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E343591374; Tue, 5 Jun 2001 05:30:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 68AED912BF for ; Tue, 5 Jun 2001 05:30:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1B8F55DDEA; Tue, 5 Jun 2001 05:30:37 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 6642A5DDCA for ; Tue, 5 Jun 2001 05:30:34 -0400 (EDT) Received: from fredrikj (sierra.local.ipunplugged.com [192.168.4.88]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id LAA29915; Tue, 5 Jun 2001 11:31:53 +0200 From: "Fredrik Johansson" To: "Pat Calhoun" , Subject: RE: [AAA-WG]: [Issue] Server-initiated re-auth Date: Tue, 5 Jun 2001 11:31:41 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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) In-Reply-To: <20010601120445.A22616@charizard.diameter.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pat, I believe that the message sequence that you suggest is good (re-auth req/re-auth answer followed by the actual re-auth). The message should be added to the NASREQ extension since there is no way for a access device to request a mobile node to re-auth in MIP. Or should it be a request to the FA to go via AAA the next time the MN register instead of sending the MIP Reg Req directly to the HA? /Fredrik >-----Original Message----- >From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf >Of Pat Calhoun >Sent: den 1 juni 2001 21:05 >To: aaa-wg@merit.edu >Subject: [AAA-WG]: [Issue] Server-initiated re-auth > > >Server-initiated re-auth >Submitter name: Pat Calhoun >Submitter email address: pcalhoun@diameter.org >Date first submitted: June 01, 2001 >Reference: >Document: All >Comment type: C >Priority: 1 >Section: >Rationale/Explanation of issue: > >In the process of fixing Issue #32, the Indication messages have >been removed from >the NASREQ extension. However, the specification also makes use of >the indication >messages to allow a server to send an unsolicited request for re-auth. > >Is this feature required? If so, is it specific to NASREQ, or >could it be generalized >and defined in the base protocol specification? > >Three options: >1. Delete the feature >2. Create a new message set in the nasreq specification that is sent by > a server to request that a user be re-auth. >3. Create a new message set in the base protocol that is sent by > a server to request that a user be re-auth. > >Comments? > >PatC From owner-aaa-bof@merit.edu Tue Jun 5 07:35:56 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15512 for ; Tue, 5 Jun 2001 07:35:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CF38D912C1; Tue, 5 Jun 2001 07:35:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 989E691373; Tue, 5 Jun 2001 07:35:48 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6401D912C1 for ; Tue, 5 Jun 2001 07:35:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A039C5DDE1; Tue, 5 Jun 2001 07:36:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id B87DA5DDB8 for ; Tue, 5 Jun 2001 07:36:07 -0400 (EDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f55Ba3m04412 for ; Tue, 5 Jun 2001 14:36:03 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 5 Jun 2001 14:35:49 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Tue, 5 Jun 2001 14:35:49 +0300 Message-ID: <6D1A8E7871B9D211B3B00008C7490AA504E626B9@treis03nok> From: henry.haverinen@nokia.com To: pcalhoun@diameter.org, aaa-wg@merit.edu Subject: RE: [AAA-WG]: [Issue] Multi-roundtrip Mobile IP authentication Date: Tue, 5 Jun 2001 14:35:32 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Pat, I believe the new Diameter Mobile IP draft fixes this issue (#52). Thanks! Regards, Henry From owner-aaa-bof@merit.edu Tue Jun 5 09:33:36 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20072 for ; Tue, 5 Jun 2001 09:33:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6C1099126F; Tue, 5 Jun 2001 09:33:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7841D912C3; Tue, 5 Jun 2001 09:33:26 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8E3D99126F for ; Tue, 5 Jun 2001 09:33:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A6EF15DDE7; Tue, 5 Jun 2001 09:33:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 241B95DDB8 for ; Tue, 5 Jun 2001 09:33:44 -0400 (EDT) Received: (qmail 26308 invoked by uid 500); 5 Jun 2001 13:23:00 -0000 Date: Tue, 5 Jun 2001 06:23:00 -0700 From: Pat Calhoun To: Fredrik Johansson Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Server-initiated re-auth Message-ID: <20010605062300.V22616@charizard.diameter.org> Mail-Followup-To: Fredrik Johansson , Pat Calhoun , aaa-wg@merit.edu References: <20010601120445.A22616@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from fredrik.johansson@ipunplugged.com on Tue, Jun 05, 2001 at 11:31:41AM +0200 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Tue, Jun 05, 2001 at 11:31:41AM +0200, Fredrik Johansson wrote: > I believe that the message sequence that you suggest is good (re-auth > req/re-auth answer followed by the actual re-auth). The message should be > added to the NASREQ extension since there is no way for a access device to > request a mobile node to re-auth in MIP. Or should it be a request to the FA > to go via AAA the next time the MN register instead of sending the MIP Reg > Req directly to the HA? Right, but there MAY be future Diameter applications that require re-auth support. So, I am sort-of wondering whether it belongs in the base (similar to STR). PatC From owner-aaa-bof@merit.edu Tue Jun 5 09:42:35 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20438 for ; Tue, 5 Jun 2001 09:42:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 976C5912C3; Tue, 5 Jun 2001 09:42:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 62C9491374; Tue, 5 Jun 2001 09:42:28 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 264BE912C3 for ; Tue, 5 Jun 2001 09:42:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 87F8F5DDB8; Tue, 5 Jun 2001 09:42:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 0094B5DDE7 for ; Tue, 5 Jun 2001 09:42:47 -0400 (EDT) Received: (qmail 26377 invoked by uid 500); 5 Jun 2001 13:32:04 -0000 Date: Tue, 5 Jun 2001 06:32:04 -0700 From: Pat Calhoun To: henry.haverinen@nokia.com Cc: pcalhoun@diameter.org, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] proposed text for NASREQ KDC Message-ID: <20010605063204.Y22616@charizard.diameter.org> Mail-Followup-To: henry.haverinen@nokia.com, pcalhoun@diameter.org, aaa-wg@merit.edu References: <6D1A8E7871B9D211B3B00008C7490AA504E626B3@treis03nok> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <6D1A8E7871B9D211B3B00008C7490AA504E626B3@treis03nok>; from henry.haverinen@nokia.com on Tue, Jun 05, 2001 at 10:12:18AM +0300 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Tue, Jun 05, 2001 at 10:12:18AM +0300, henry.haverinen@nokia.com wrote: > The NAS session key sections in the new NASREQ draft > look pretty good to me. Many thanks. Thanks. > > I just have an editorial comment: in section 2.1.3, > the text below the ABNF grammar seems to be repetition of > the first paragraph of 2.1.3. I think you can simply > delete it. You are right. Somehow missed that one :( PatC From owner-aaa-bof@merit.edu Tue Jun 5 09:50:38 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20736 for ; Tue, 5 Jun 2001 09:50:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B1629912C4; Tue, 5 Jun 2001 09:50:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 86EE891374; Tue, 5 Jun 2001 09:50:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7D1A6912C4 for ; Tue, 5 Jun 2001 09:50:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 046555DDF2; Tue, 5 Jun 2001 09:50:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 7C7655DDE7 for ; Tue, 5 Jun 2001 09:50:50 -0400 (EDT) Received: (qmail 26984 invoked by uid 500); 5 Jun 2001 13:39:45 -0000 Date: Tue, 5 Jun 2001 06:39:45 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue #51: EAP Roundtrips Message-ID: <20010605063945.Z22616@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, I'd like to get some discussion started on issue 51. My interpretation of Bernard's comments on this particular issues, which may be found at http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00340.html is that this isn't something that we can really fix in Diameter. Does anyone else have a comments on how to proceed with this issue? Thanks, PatC From owner-aaa-bof@merit.edu Tue Jun 5 10:03:26 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21135 for ; Tue, 5 Jun 2001 10:03:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 53C2A912C5; Tue, 5 Jun 2001 10:03:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2536591376; Tue, 5 Jun 2001 10:03:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F32B0912C5 for ; Tue, 5 Jun 2001 10:03:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 671815DDE7; Tue, 5 Jun 2001 10:03:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id D90C75DD9E for ; Tue, 5 Jun 2001 10:03:40 -0400 (EDT) Received: (qmail 27130 invoked by uid 500); 5 Jun 2001 13:52:57 -0000 Date: Tue, 5 Jun 2001 06:52:57 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue #3: Bring back UTF-8 Message-ID: <20010605065257.B22616@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, Mark Eklund made a proposal in http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00392.html, and there hasn't been any discussions on this. This e-mail was specifically targetted to Erik Guttman and Juergen, but no response was received. Do people feel comfortable with this approach? I believe that this request has been made several times in the past year, and there seemed to be considerable interest. Of course, we could simply state that this is a dictionary issue, and doesn't belong in the core specs, but it would be nice to allow dictionary creation to follow the author of an application's original intent, and not have any second guessing to do. Comments? PatC From owner-aaa-bof@merit.edu Tue Jun 5 10:08:54 2001 Received: from trapdoor.merit.edu ([198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21383 for ; Tue, 5 Jun 2001 10:08:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6D7DD91384; Tue, 5 Jun 2001 10:07:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4091591383; Tue, 5 Jun 2001 10:07:28 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F3D9F91382 for ; Tue, 5 Jun 2001 10:07:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7EE325DDF2; Tue, 5 Jun 2001 10:07:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id C974E5DDF7 for ; Tue, 5 Jun 2001 10:07:44 -0400 (EDT) Received: (qmail 27143 invoked by uid 500); 5 Jun 2001 13:57:01 -0000 Date: Tue, 5 Jun 2001 06:57:01 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue #33: Is API Considered Useful Message-ID: <20010605065701.C22616@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, I spoke with Tom Hiller, the editor of the various 3GPP2 specs, and talked to him about P.R001, and the rather obscure requirement to allow for a server initiated accounting poll. He stated that if the feature wasn't discussed in P.S001, then it isn't a requirement, and P.R001 is a non-normative reference in P.S001 (it is informational only). So, it sounds as if we can get rid of this feature, but I would like to ask, one last time, whether people feel it is necessary for an accounting server to be able to issue a request to an access device to force it to send an accounting message. If so, then we will keep this feature, but if there is no demand..... out it goes. PatC From owner-aaa-bof@merit.edu Tue Jun 5 10:12:34 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21564 for ; Tue, 5 Jun 2001 10:12:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2CC0E91378; Tue, 5 Jun 2001 10:12:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EFF9C91379; Tue, 5 Jun 2001 10:12:27 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E486691378 for ; Tue, 5 Jun 2001 10:12:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 718A45DDE7; Tue, 5 Jun 2001 10:12:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id E4F265DD9E for ; Tue, 5 Jun 2001 10:12:47 -0400 (EDT) Received: (qmail 27166 invoked by uid 500); 5 Jun 2001 14:02:04 -0000 Date: Tue, 5 Jun 2001 07:02:04 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue #64: E2E Editorial Issues Message-ID: <20010605070204.D22616@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk Jari, These editorial issues have been taken care of in cms-00.txt. The only remaining items are 6.5 (keep the OSCP-desire and nonce together), which we determined we wanted to have as split AVPs. Also 6.8 (whether the top CA needs to remain), we didn't feel comfortable removing this from the draft, but there is an explicit editor's note in the draft stating that this needs to be taken care of. So, perhaps we can now open discussions on these two items. 1. 6.5: Does anyone object to the use of the OCSP-Nonce and the OCSP-Request AVPs in the cms draft, as opposed to combining these into a single AVP? 2. 6.8: Does anyone believe that the top CA is not required since that cert must be known anyways. Comments? PatC From owner-aaa-bof@merit.edu Tue Jun 5 10:14:10 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21695 for ; Tue, 5 Jun 2001 10:14:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 55AD591379; Tue, 5 Jun 2001 10:14:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CAB7D9137A; Tue, 5 Jun 2001 10:14:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8373C91379 for ; Tue, 5 Jun 2001 10:14:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 100015DDE7; Tue, 5 Jun 2001 10:14:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id B4C075DD9E for ; Tue, 5 Jun 2001 10:14:33 -0400 (EDT) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id KAA17680; Tue, 5 Jun 2001 10:08:33 -0400 Received: from preston (cisconas241.bridgewatersys.com [192.168.150.241]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id KAA02429; Tue, 5 Jun 2001 10:15:11 -0400 (EDT) From: "Mark Jones" To: "Pat Calhoun" , Subject: RE: [AAA-WG]: Issue #35: Device-Reboot-Ind isn't an appropriate name Date: Tue, 5 Jun 2001 10:17:27 -0400 MIME-Version: 1.0 Message-ID: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0008_01C0EDA8.6DB15240"; micalg=SHA1 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <20010605064654.A22616@charizard.diameter.org> Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C0EDA8.6DB15240 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Pat, I have no objections to your suggested command names. They are clear and maintain the all important TLA uniqueness. So unless there are objections on the mailing list, the DRI is renamed to Capabilities-Exchange-Request/Capabilities-Exchange-Answer and issue 35 is closed. Regards, Mark ------=_NextPart_000_0008_01C0EDA8.6DB15240 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFxTCCApQw ggH9oAMCAQICAwS4ODANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDUwMTE4MTgwOFoXDTAyMDUwMTE4MTgwOFowTzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdbWpvbmVzQGJyaWRnZXdhdGVyc3lzdGVt cy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMemr5diJO/8+r2Hj3Opr9LbaVAXFgo2 Fhu0tfSSdvlMy52Y67GMoJbv0I282FWO9z4bsnuSIU7y3arEmyA78mwjTSdt2GK5QJHT6jKOqF6M 81Q5j2fU3dQwCPiCQZlOqUJEA3PySRjUQNOgnRUhoSuzGd7IMJ3Y6oeMtE8a02nTAgMBAAGjOjA4 MCgGA1UdEQQhMB+BHW1qb25lc0BicmlkZ2V3YXRlcnN5c3RlbXMuY29tMAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEEBQADgYEANyubKv2ajV9VxVe4xUDaqZbQ2DEXgGKSFWwsdC06zUucuCmeHHqT vLcoUnI8/dCbSnSwRrELpemSoqTv/99uW+jS6cN5320w1ZEBsC2RSVrSJd8LqxKALmMexgbywYvF /hMe120ctocvwnfbeZmzBIKSF7BDs8YPGzSWgsa5gKUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3 DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0 aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2 17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gxggKOMIICigIB ATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgw JgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMEuDgwCQYFKw4DAhoFAKCC AUkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwNjA1MTQxNTIx WjAjBgkqhkiG9w0BCQQxFgQUi4ivR+69ndECuuvKgitlP7tHJ90wPAYJKoZIhvcNAQkPMS8wLTAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCBqwYJKwYBBAGCNxAE MYGdMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD YXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMx KDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwS4ODANBgkqhkiG9w0B AQEFAASBgL9SgElLED+1qYSI6hpgWLqIAkMMv6dW6ZDZ00H9PwRewNDFeF9yQ9iwQTFejqB+Qyh/ RrBxc3VePR9De5J/A4hFXAG6WuCk2WEFf/pzZxH68hsZ0defHsJKGuCQaHTKHrZEC95a+yYfa51l KpvRKUZmBw3ryIbhFTNz5zJ+lEWSAAAAAAAA ------=_NextPart_000_0008_01C0EDA8.6DB15240-- From owner-aaa-bof@merit.edu Tue Jun 5 10:24:55 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22108 for ; Tue, 5 Jun 2001 10:24:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BE7979137A; Tue, 5 Jun 2001 10:24:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8F96C9137E; Tue, 5 Jun 2001 10:24:57 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 75EBE9137A for ; Tue, 5 Jun 2001 10:24:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 07C025DDF2; Tue, 5 Jun 2001 10:25:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 375A65DDD4 for ; Tue, 5 Jun 2001 10:25:17 -0400 (EDT) Received: (qmail 27256 invoked by uid 500); 5 Jun 2001 14:14:33 -0000 Date: Tue, 5 Jun 2001 07:14:33 -0700 From: Pat Calhoun To: Mark Eklund Cc: Pat Calhoun , David Spence , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] What to do if STR is sent to unavailable server.(2nd try) Message-ID: <20010605071433.F22616@charizard.diameter.org> Mail-Followup-To: Mark Eklund , Pat Calhoun , David Spence , aaa-wg@merit.edu References: <20010604142736.E22616@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from meklund@cisco.com on Mon, Jun 04, 2001 at 06:00:06PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Mon, Jun 04, 2001 at 06:00:06PM -0400, Mark Eklund wrote: > Would you have a similar AVP for accounting? hmmmm... it would be interesting to include an AVP that contains the identity of the server that handles accountinng for a particular session. others? > Would re-auth be the same AVP as STR? > Can we combine option 2 and 4? > > AA-Destination-Config > The AA-Destination-Config is of type Enumerated. It specifies > how subsequent AAR and STR MUST be sent. This may be sent in > either the initial authentication, or any re-auth. If not > present, BOTH is used. > > BOTH(0) - Always use Destination-FQDN and Destination-Realm > REALM(1) - Only send Destination-Realm > TWICE(2) - Do BOTH. If DIAMETER_UNABLE_TO_DELIVER retransmit > using REALM That works for me. Anyone object? > > Acct-Destination-Config > Same as above except this may be sent in accounting packets. > > Mobile-Destination-Config > Do we need this too, or does AA-Destination-Config handle this? Actually, by pulling this particular AVP into the base protocol, it would be used by *any* application > > Also, could it be simply Destination-Config and what it > configures is dependent upon what type of packet this is? Right, that's my thought. It would handle all re-auths and STRs. > > Also, this would break using the presence of Destination-FQDN as > an indicator of continued conversation. Not at all. If a server states that it does not care where the message is sent, then this implies that the servers have shared state, and therefore it really doesn't matter where the message is sent to. So, load balancing would allow this message to be sent to *any* server. PatC > On Mon, 4 Jun 2001, Pat Calhoun wrote: > > > On Mon, Jun 04, 2001 at 05:27:54PM -0400, Mark Eklund wrote: > > > David, > > > > > > On Mon, 4 Jun 2001, David Spence wrote: > > > > > > > #3 sounds good to me. That includes #2, resend the STR without the > > > > Destination-FQDN, plus let certain types (to be specified later) of proxy > > > > resend the STR without the Destination-FQDN to relieve the client from > > > > having to do so. > > > > > > > > I must admit, I don't quite understand #4. If anyone favors it, perhaps > > > > they could elaborate. > > > > > > I don't favor #4, but I'll elaborate. The basic idea was to give > > > the server control over what is sent. It could tell the client > > > to not use a Destination-FQDN. It would do this with an > > > STR-Destination AVP which would be included in the AAA. > > > > That's my preference. Don't send it unless the home server tells you it is ok. > > > > PatC > > > > > > -mark > > > > > > > > > > > Mark Eklund wrote: > > > > > > > > > > All, > > > > > > > > > > I had sent this issue out earlier and got no response. My vote > > > > > is for option #3. If someone wants to send an STR a second time > > > > > with no Destination-FQDN, let them. > > > > > > > > > > -mark > > > > > > > > > > Submitter name: Mark Eklund > > > > > Submitter email address: meklund@cisco.com > > > > > Date first submitted: 24-May-2001 > > > > > Reference: > > > > > Document: Base > > > > > Comment type: T > > > > > Priority: 1 > > > > > Section: > > > > > Rationale/Explanation of issue: > > > > > > > > > > * The Session-Terminate-Request requires a Destination-FQDN > > > > > > > > > > * There was going to be text added to state that the Destination-FQDN > > > > > should be that of the last place you authenticated. > > > > > > > > > > * What happens if that Destination-FQDN is down? If this is a cluster > > > > > of servers, there may still be a need for the STR to be sent to the > > > > > realm. > > > > > > > > > > Requested change: > > > > > > > > > > One or more of the following changes: > > > > > > > > > > 1. Do nothing. If the authenticating server goes down, either all the > > > > > state data is lost, or session timeouts will cleanup any STRs missed. > > > > > A statement as such should be added to the RFC reflecting this. > > > > > > > > > > 2. Make the Destination-FQDN optional. If the client receives a > > > > > DIAMETER_UNABLE_TO_DELIVER, the client may send the request without > > > > > a Destination-FQDN. > > > > > > > > > > 3. #2 above, but allow a proxy to also do this. > > > > > > > > > > 4. Make the Destination-FQDN optional. Add an STR-Destination AVP > > > > > that is of type integer that is sent as a part of the authentication > > > > > process. This would contain the Destination-Realm and optionally > > > > > the Destination-FQDN to which this should be sent. > > > > > > > > > > ==================================================================== > > > > > > > > > > > > > > > From owner-aaa-bof@merit.edu Tue Jun 5 10:28:09 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22227 for ; Tue, 5 Jun 2001 10:28:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AC5E79137E; Tue, 5 Jun 2001 10:28:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7D8359137F; Tue, 5 Jun 2001 10:28:00 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 720719137E for ; Tue, 5 Jun 2001 10:27:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 062E05DDF2; Tue, 5 Jun 2001 10:28:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id B5E075DDD4 for ; Tue, 5 Jun 2001 10:28:20 -0400 (EDT) Received: (qmail 27276 invoked by uid 500); 5 Jun 2001 14:17:37 -0000 Date: Tue, 5 Jun 2001 07:17:37 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 60: E2E cert names Message-ID: <20010605071737.G22616@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk My understanding of the cert names was that by adding the -diameter in the cert name, it became obvious that this cert was useful ONLY for Diameter, not for anything else. However, I believe that Stephen could answer this question better than I could given that this particular section is his text. PatC From owner-aaa-bof@merit.edu Tue Jun 5 10:45:53 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22622 for ; Tue, 5 Jun 2001 10:45:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2C99891380; Tue, 5 Jun 2001 10:45:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B1BD191381; Tue, 5 Jun 2001 10:45:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 226B091380 for ; Tue, 5 Jun 2001 10:45:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 81EAB5DDF2; Tue, 5 Jun 2001 10:45:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by segue.merit.edu (Postfix) with ESMTP id 34C085DDD4 for ; Tue, 5 Jun 2001 10:45:27 -0400 (EDT) Received: from knox6195.CISCO.COM (rsargent@knox6195.cisco.com [161.44.216.195]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA14668; Tue, 5 Jun 2001 07:45:09 -0700 (PDT) Date: Tue, 5 Jun 2001 10:45:06 -0400 From: Robert Sargent To: Mark Eklund , Pat Calhoun , David Spence , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] What to do if STR is sent to unavailable server.(2nd try) Message-ID: <20010605104506.B5081@Cisco.COM> Reply-To: Robert Sargent References: <20010604142736.E22616@charizard.diameter.org> <20010605071433.F22616@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010605071433.F22616@charizard.diameter.org>; from pcalhoun@diameter.org on Tue, Jun 05, 2001 at 07:14:33AM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Tue, Jun 05, 2001 at 07:14:33AM -0700, Pat Calhoun promised: > On Mon, Jun 04, 2001 at 06:00:06PM -0400, Mark Eklund wrote: > > Would you have a similar AVP for accounting? > > hmmmm... it would be interesting to include an AVP that contains the > identity of the server that handles accountinng for a particular session. > > others? accounting host ip, key, port ??? Rob > > > Would re-auth be the same AVP as STR? > > Can we combine option 2 and 4? > > > > AA-Destination-Config > > The AA-Destination-Config is of type Enumerated. It specifies > > how subsequent AAR and STR MUST be sent. This may be sent in > > either the initial authentication, or any re-auth. If not > > present, BOTH is used. > > > > BOTH(0) - Always use Destination-FQDN and Destination-Realm > > REALM(1) - Only send Destination-Realm > > TWICE(2) - Do BOTH. If DIAMETER_UNABLE_TO_DELIVER retransmit > > using REALM > > That works for me. Anyone object? > > > > > Acct-Destination-Config > > Same as above except this may be sent in accounting packets. > > > > Mobile-Destination-Config > > Do we need this too, or does AA-Destination-Config handle this? > > Actually, by pulling this particular AVP into the base protocol, > it would be used by *any* application > > > > Also, could it be simply Destination-Config and what it > > configures is dependent upon what type of packet this is? > > Right, that's my thought. It would handle all re-auths and STRs. > > > > Also, this would break using the presence of Destination-FQDN as > > an indicator of continued conversation. > > Not at all. If a server states that it does not care where the message > is sent, then this implies that the servers have shared state, and therefore > it really doesn't matter where the message is sent to. So, load balancing > would allow this message to be sent to *any* server. > > PatC > > > On Mon, 4 Jun 2001, Pat Calhoun wrote: > > > > > On Mon, Jun 04, 2001 at 05:27:54PM -0400, Mark Eklund wrote: > > > > David, > > > > > > > > On Mon, 4 Jun 2001, David Spence wrote: > > > > > > > > > #3 sounds good to me. That includes #2, resend the STR without the > > > > > Destination-FQDN, plus let certain types (to be specified later) of proxy > > > > > resend the STR without the Destination-FQDN to relieve the client from > > > > > having to do so. > > > > > > > > > > I must admit, I don't quite understand #4. If anyone favors it, perhaps > > > > > they could elaborate. > > > > > > > > I don't favor #4, but I'll elaborate. The basic idea was to give > > > > the server control over what is sent. It could tell the client > > > > to not use a Destination-FQDN. It would do this with an > > > > STR-Destination AVP which would be included in the AAA. > > > > > > That's my preference. Don't send it unless the home server tells you it is ok. > > > > > > PatC > > > > > > > > -mark > > > > > > > > > > > > > > Mark Eklund wrote: > > > > > > > > > > > > All, > > > > > > > > > > > > I had sent this issue out earlier and got no response. My vote > > > > > > is for option #3. If someone wants to send an STR a second time > > > > > > with no Destination-FQDN, let them. > > > > > > > > > > > > -mark > > > > > > > > > > > > Submitter name: Mark Eklund > > > > > > Submitter email address: meklund@cisco.com > > > > > > Date first submitted: 24-May-2001 > > > > > > Reference: > > > > > > Document: Base > > > > > > Comment type: T > > > > > > Priority: 1 > > > > > > Section: > > > > > > Rationale/Explanation of issue: > > > > > > > > > > > > * The Session-Terminate-Request requires a Destination-FQDN > > > > > > > > > > > > * There was going to be text added to state that the Destination-FQDN > > > > > > should be that of the last place you authenticated. > > > > > > > > > > > > * What happens if that Destination-FQDN is down? If this is a cluster > > > > > > of servers, there may still be a need for the STR to be sent to the > > > > > > realm. > > > > > > > > > > > > Requested change: > > > > > > > > > > > > One or more of the following changes: > > > > > > > > > > > > 1. Do nothing. If the authenticating server goes down, either all the > > > > > > state data is lost, or session timeouts will cleanup any STRs missed. > > > > > > A statement as such should be added to the RFC reflecting this. > > > > > > > > > > > > 2. Make the Destination-FQDN optional. If the client receives a > > > > > > DIAMETER_UNABLE_TO_DELIVER, the client may send the request without > > > > > > a Destination-FQDN. > > > > > > > > > > > > 3. #2 above, but allow a proxy to also do this. > > > > > > > > > > > > 4. Make the Destination-FQDN optional. Add an STR-Destination AVP > > > > > > that is of type integer that is sent as a part of the authentication > > > > > > process. This would contain the Destination-Realm and optionally > > > > > > the Destination-FQDN to which this should be sent. > > > > > > > > > > > > ==================================================================== > > > > > > > > > > > > > > > > > > > > > -- Rob Sargent Tel: (865) 671-8823 Software Development Manager -*- Remote Site Manager - Knoxville 10850 Murdock Dr Knoxville TN 37932 http://darien.cisco.com/ From owner-aaa-bof@merit.edu Tue Jun 5 10:59:54 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22870 for ; Tue, 5 Jun 2001 10:59:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7D25B91374; Tue, 5 Jun 2001 09:57:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 482CF91376; Tue, 5 Jun 2001 09:57:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3089B91374 for ; Tue, 5 Jun 2001 09:57:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A42B05DDF7; Tue, 5 Jun 2001 09:57:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 64F0A5DDE7 for ; Tue, 5 Jun 2001 09:57:38 -0400 (EDT) Received: (qmail 27100 invoked by uid 500); 5 Jun 2001 13:46:54 -0000 Date: Tue, 5 Jun 2001 06:46:54 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue #35: Device-Reboot-Ind isn't an appropriate name Message-ID: <20010605064654.A22616@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All (and Mark), I had already changed the spec by the time I received your issue update, and used the command names Capabilities-Exchange-Request and Capabilities-Exchange-Answer, but I am not adverse to your proposed Device-Capabilities-Request and Device-Capabilities-Answer. Would people prefer Mark's command names? If so, I can make this rather trivial change in -06. PatC From owner-aaa-bof@merit.edu Tue Jun 5 11:12:27 2001 Received: from trapdoor.merit.edu ([198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23109 for ; Tue, 5 Jun 2001 11:12:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3DEF991388; Tue, 5 Jun 2001 11:08:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 02C109138B; Tue, 5 Jun 2001 11:08:53 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 598CD91388 for ; Tue, 5 Jun 2001 11:07:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EACD85DDD4; Tue, 5 Jun 2001 11:07:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 08FDA5DDA6 for ; Tue, 5 Jun 2001 11:07:45 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA21897; Tue, 5 Jun 2001 11:06:27 -0400 (EDT) Date: Tue, 5 Jun 2001 11:06:46 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: Pat Calhoun Cc: David Spence , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] What to do if STR is sent to unavailable server.(2nd try) In-Reply-To: <20010605071433.F22616@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, On Tue, 5 Jun 2001, Pat Calhoun wrote: > On Mon, Jun 04, 2001 at 06:00:06PM -0400, Mark Eklund wrote: > > Would you have a similar AVP for accounting? > > hmmmm... it would be interesting to include an AVP that contains the > identity of the server that handles accountinng for a particular session. > > others? Just to verify. The above question and comments have to do with having the present AAA contain something telling where to send the ACR. If there is interest, this would be a different issue. Correct? > > > Would re-auth be the same AVP as STR? > > Can we combine option 2 and 4? > > > > AA-Destination-Config > > The AA-Destination-Config is of type Enumerated. It specifies > > how subsequent AAR and STR MUST be sent. This may be sent in > > either the initial authentication, or any re-auth. If not > > present, BOTH is used. > > > > BOTH(0) - Always use Destination-FQDN and Destination-Realm > > REALM(1) - Only send Destination-Realm > > TWICE(2) - Do BOTH. If DIAMETER_UNABLE_TO_DELIVER retransmit > > using REALM > > That works for me. Anyone object? > > > > > Acct-Destination-Config > > Same as above except this may be sent in accounting packets. > > > > Mobile-Destination-Config > > Do we need this too, or does AA-Destination-Config handle this? > > Actually, by pulling this particular AVP into the base protocol, > it would be used by *any* application How about we call it Application-Destination-Config (or something abbreviated). When received, all subsequent requests for that session with that application type will be controlled by that config. Before sending, you would have to lookup where to send it. Session_ID Application AA/Acct Destination-Config XYZ... NASREQ AA BOTH XYZ... NASREQ Acct REALM MNO... MOBILEIP AA TWO MNO... MOBILEIP Acct TWO MNO... NEWWAY Acct ONE This is getting a little complex. What if we made it really simple with a new option. 4. If the client receives a DIAMETER_UNABLE_TO_DELIVER, the client MUST re-send the request with a Destination-FQDN of "*". "*" denotes that this is a rebroadcast because the initial Destination-FQDN was unreachable. If a server cannot handle re-auths or accounting records for a fellow server, it can drop it. -mark > > > > Also, could it be simply Destination-Config and what it > > configures is dependent upon what type of packet this is? > > Right, that's my thought. It would handle all re-auths and STRs. > > > > Also, this would break using the presence of Destination-FQDN as > > an indicator of continued conversation. > > Not at all. If a server states that it does not care where the message > is sent, then this implies that the servers have shared state, and therefore > it really doesn't matter where the message is sent to. So, load balancing > would allow this message to be sent to *any* server. > > PatC > > > On Mon, 4 Jun 2001, Pat Calhoun wrote: > > > > > On Mon, Jun 04, 2001 at 05:27:54PM -0400, Mark Eklund wrote: > > > > David, > > > > > > > > On Mon, 4 Jun 2001, David Spence wrote: > > > > > > > > > #3 sounds good to me. That includes #2, resend the STR without the > > > > > Destination-FQDN, plus let certain types (to be specified later) of proxy > > > > > resend the STR without the Destination-FQDN to relieve the client from > > > > > having to do so. > > > > > > > > > > I must admit, I don't quite understand #4. If anyone favors it, perhaps > > > > > they could elaborate. > > > > > > > > I don't favor #4, but I'll elaborate. The basic idea was to give > > > > the server control over what is sent. It could tell the client > > > > to not use a Destination-FQDN. It would do this with an > > > > STR-Destination AVP which would be included in the AAA. > > > > > > That's my preference. Don't send it unless the home server tells you it is ok. > > > > > > PatC > > > > > > > > -mark > > > > > > > > > > > > > > Mark Eklund wrote: > > > > > > > > > > > > All, > > > > > > > > > > > > I had sent this issue out earlier and got no response. My vote > > > > > > is for option #3. If someone wants to send an STR a second time > > > > > > with no Destination-FQDN, let them. > > > > > > > > > > > > -mark > > > > > > > > > > > > Submitter name: Mark Eklund > > > > > > Submitter email address: meklund@cisco.com > > > > > > Date first submitted: 24-May-2001 > > > > > > Reference: > > > > > > Document: Base > > > > > > Comment type: T > > > > > > Priority: 1 > > > > > > Section: > > > > > > Rationale/Explanation of issue: > > > > > > > > > > > > * The Session-Terminate-Request requires a Destination-FQDN > > > > > > > > > > > > * There was going to be text added to state that the Destination-FQDN > > > > > > should be that of the last place you authenticated. > > > > > > > > > > > > * What happens if that Destination-FQDN is down? If this is a cluster > > > > > > of servers, there may still be a need for the STR to be sent to the > > > > > > realm. > > > > > > > > > > > > Requested change: > > > > > > > > > > > > One or more of the following changes: > > > > > > > > > > > > 1. Do nothing. If the authenticating server goes down, either all the > > > > > > state data is lost, or session timeouts will cleanup any STRs missed. > > > > > > A statement as such should be added to the RFC reflecting this. > > > > > > > > > > > > 2. Make the Destination-FQDN optional. If the client receives a > > > > > > DIAMETER_UNABLE_TO_DELIVER, the client may send the request without > > > > > > a Destination-FQDN. > > > > > > > > > > > > 3. #2 above, but allow a proxy to also do this. > > > > > > > > > > > > 4. Make the Destination-FQDN optional. Add an STR-Destination AVP > > > > > > that is of type integer that is sent as a part of the authentication > > > > > > process. This would contain the Destination-Realm and optionally > > > > > > the Destination-FQDN to which this should be sent. > > > > > > > > > > > > ==================================================================== > > > > > > > > > > > > > > > > > > > > > > From owner-aaa-bof@merit.edu Tue Jun 5 11:13:01 2001 Received: from trapdoor.merit.edu ([198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23120 for ; Tue, 5 Jun 2001 11:13:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 12E269138B; Tue, 5 Jun 2001 11:12:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B3E4291394; Tue, 5 Jun 2001 11:12:15 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D4C099138B for ; Tue, 5 Jun 2001 11:12:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 57D855DDF2; Tue, 5 Jun 2001 11:12:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by segue.merit.edu (Postfix) with ESMTP id 9FAE05DDF0 for ; Tue, 5 Jun 2001 11:12:32 -0400 (EDT) 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 RAA14309; Tue, 5 Jun 2001 17:12:15 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA14971; Tue, 5 Jun 2001 17:12:14 +0200 Date: Tue, 5 Jun 2001 17:12:14 +0200 Message-Id: <200106051512.RAA14971@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: meklund@cisco.com Cc: aaa-wg@merit.edu, erik.guttman@germany.sun.com, pcalhoun@diameter.org In-reply-to: (message from Mark Eklund on Thu, 31 May 2001 18:34:28 -0400 (EDT)) Subject: Re: [AAA-WG]: Re: [issue] Bring back UTF8 datatype. References: Sender: owner-aaa-bof@merit.edu Precedence: bulk Mark> Juergen, Mark> Mark> Is the following acceptable. Mark> Mark> 1. I renamed "AVP Data Formats" to "AVP Base Data Formats". OK Mark> 2. I created a new section, "AVP Derived Data Formats". OK Mark> 3. I stated that an AVP Derived Data Format MUST only be Mark> defined in one RFC. I guess you mean "AVP Base Data Formats" here. With that assumption, OK. Mark> 4. I stated that a new AVP Derived Data Format MUST be Mark> registered with IANA. (This may be a little extreme.) This at least ensures that you get unique names. Mark> 5. I moved Address to the AVP Derived Data Formats. OK Mark> 6. I added a time format to the AVP Derived Data Formats. OK Mark> 7. I added UTF8String and used most of the explanation from Mark> your example to describe it. OK Mark> 8. Additionally, I specified that UTF8String MUST not contain Mark> an octet with a value of zero. Note sure this is necessary - but see below. Mark> 9. I added a DiameterIdentity format (formerly FQDN) to the AVP Mark> Derived Data Formats. OK Mark> 10. I added an Enumerated format to the AVP Derived Data Mark> Formats. OK. Mark> Below is the new text. Is the basic idea getting closer to Mark> respectable? If so, any comments on the details? Looks good. Below are some more detailed comments. Mark> OctetString Mark> The data contains arbitrary data of variable length. Unless Mark> otherwise noted, the AVP Length field MUST be set to at least 9 Mark> (13 if the 'V' bit is enabled). AVP Values of this type that Mark> do not align on a 32-bit boundary MUST have the necessary Mark> padding. Note that the length should be 8 or 12 to allow for zero-length strings (as noted already somewhere else). Mark> Unsigned32 Mark> 32 bit unsigned value, in network byte order. The AVP Length Mark> field MUST be set to 12 (16 if the 'V' bit is enabled). Mark> Unsigned32 values used to transmit time data contains the four Mark> most significant octets returned from NTP [18], in network byte Mark> order. I suggest to remove the last sentence as it is irrelevant for understanding what an Unsigned32 value looks like. Mark> Address Mark> The Address format is derived from the OctetString AVP Base Mark> Format. It represents 32 bit (IPv4) [17] or 128 bit (IPv6) Mark> [16] address, most significant octet first. The format of the Mark> address (IPv4 or IPv6) is determined by the length. If the Mark> attribute value is an IPv4 address, the AVP Length field MUST Mark> be 12 (16 if 'V' bit is enabled), otherwise the AVP Length Mark> field MUST be set to 24 (28 if the 'V' bit is enabled) for Mark> IPv6 addresses. Perhaps this should be called IpAddress to make it clearer that it is restricted to IP addresses. Another question is whether Diameter will ever have to deal with scoped IPv6 addresses which require another 4 bytes to make them unique in a given domain (scope identifier). RFC 2851 has take the approach to allow 16 or 20 bytes for an IPv6 address. Mark> UTF8String [...] Mark> The UTF8String MUST not contain any octets with a value of Mark> zero. I am not sure this is needed since you already have this: Mark> Since additional code points are added by amendments to the Mark> 10646 standard from time to time, implementations MUST be Mark> prepared to encounter any code point from 0x00000001 to Mark> 0x7fffffff. Byte sequences that do not correspond to the Mark> valid UTF-8 encoding of a code point or are outside this Mark> range are prohibited. I am not a UTF-8 expert but it appears to me (from reading RFC 2279) that the UTF-8 encoding can only contain a 0x00 byte if the code point is actually 0x00000000. But I might be wrong on this. Mark> Enumerated Mark> Enumerated is Derived from the Unsigned32 AVP Base Format. Mark> This contains a list of valid values and their interpretation Mark> and is described in the Diameter application introducing the AVP. I personally would allow negative enumerated values (which is consistent with the SMIv2/SMIng and XDR) and thus I would use Integer32 as the AVP base format here. There remaining range of positive numbers should still be large enough to hold real-world enumerated values. From owner-aaa-bof@merit.edu Tue Jun 5 11:13:53 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23141 for ; Tue, 5 Jun 2001 11:13:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D841C91387; Tue, 5 Jun 2001 11:13:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7FE3591386; Tue, 5 Jun 2001 11:13:51 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 429C091385 for ; Tue, 5 Jun 2001 11:13:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D72755DDF2; Tue, 5 Jun 2001 11:14:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 9C6C55DDF0 for ; Tue, 5 Jun 2001 11:14:09 -0400 (EDT) Received: (qmail 29824 invoked by uid 500); 5 Jun 2001 15:03:25 -0000 Date: Tue, 5 Jun 2001 08:03:25 -0700 From: Pat Calhoun To: Mark Eklund Cc: Pat Calhoun , David Spence , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] What to do if STR is sent to unavailable server.(2nd try) Message-ID: <20010605080325.H22616@charizard.diameter.org> Mail-Followup-To: Mark Eklund , Pat Calhoun , David Spence , aaa-wg@merit.edu References: <20010605071433.F22616@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from meklund@cisco.com on Tue, Jun 05, 2001 at 11:06:46AM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Tue, Jun 05, 2001 at 11:06:46AM -0400, Mark Eklund wrote: > Pat, > > On Tue, 5 Jun 2001, Pat Calhoun wrote: > > > On Mon, Jun 04, 2001 at 06:00:06PM -0400, Mark Eklund wrote: > > > Would you have a similar AVP for accounting? > > > > hmmmm... it would be interesting to include an AVP that contains the > > identity of the server that handles accountinng for a particular session. > > > > others? > > Just to verify. The above question and comments have to do > with having the present AAA contain something telling where to > send the ACR. If there is interest, this would be a different > issue. Correct? Right. So would it make more sense to send the identity of the accounting server, or just something similar to the AA-Destination-Config AVP below, where all accounting records will be guaranteed to be sent to the authorizing server. Yes, this would be a separate issue, IMHO. Oh, and this sure smells like a new feature, so we should be careful here in adopting new features. PatC > > > > > > Would re-auth be the same AVP as STR? > > > Can we combine option 2 and 4? > > > > > > AA-Destination-Config > > > The AA-Destination-Config is of type Enumerated. It specifies > > > how subsequent AAR and STR MUST be sent. This may be sent in > > > either the initial authentication, or any re-auth. If not > > > present, BOTH is used. > > > > > > BOTH(0) - Always use Destination-FQDN and Destination-Realm > > > REALM(1) - Only send Destination-Realm > > > TWICE(2) - Do BOTH. If DIAMETER_UNABLE_TO_DELIVER retransmit > > > using REALM > > > > That works for me. Anyone object? > > > > > > > > Acct-Destination-Config > > > Same as above except this may be sent in accounting packets. > > > > > > Mobile-Destination-Config > > > Do we need this too, or does AA-Destination-Config handle this? > > > > Actually, by pulling this particular AVP into the base protocol, > > it would be used by *any* application > > How about we call it Application-Destination-Config (or > something abbreviated). When received, all subsequent requests > for that session with that application type will be controlled > by that config. Before sending, you would have to lookup where > to send it. > > Session_ID Application AA/Acct Destination-Config > XYZ... NASREQ AA BOTH > XYZ... NASREQ Acct REALM > MNO... MOBILEIP AA TWO > MNO... MOBILEIP Acct TWO > MNO... NEWWAY Acct ONE > > This is getting a little complex. What if we made it really > simple with a new option. > > 4. If the client receives a DIAMETER_UNABLE_TO_DELIVER, the > client MUST re-send the request with a Destination-FQDN of > "*". "*" denotes that this is a rebroadcast because the > initial Destination-FQDN was unreachable. > > If a server cannot handle re-auths or accounting records for a > fellow server, it can drop it. > > -mark > > > > > > > Also, could it be simply Destination-Config and what it > > > configures is dependent upon what type of packet this is? > > > > Right, that's my thought. It would handle all re-auths and STRs. > > > > > > Also, this would break using the presence of Destination-FQDN as > > > an indicator of continued conversation. > > > > Not at all. If a server states that it does not care where the message > > is sent, then this implies that the servers have shared state, and therefore > > it really doesn't matter where the message is sent to. So, load balancing > > would allow this message to be sent to *any* server. > > > > PatC > > > > > On Mon, 4 Jun 2001, Pat Calhoun wrote: > > > > > > > On Mon, Jun 04, 2001 at 05:27:54PM -0400, Mark Eklund wrote: > > > > > David, > > > > > > > > > > On Mon, 4 Jun 2001, David Spence wrote: > > > > > > > > > > > #3 sounds good to me. That includes #2, resend the STR without the > > > > > > Destination-FQDN, plus let certain types (to be specified later) of proxy > > > > > > resend the STR without the Destination-FQDN to relieve the client from > > > > > > having to do so. > > > > > > > > > > > > I must admit, I don't quite understand #4. If anyone favors it, perhaps > > > > > > they could elaborate. > > > > > > > > > > I don't favor #4, but I'll elaborate. The basic idea was to give > > > > > the server control over what is sent. It could tell the client > > > > > to not use a Destination-FQDN. It would do this with an > > > > > STR-Destination AVP which would be included in the AAA. > > > > > > > > That's my preference. Don't send it unless the home server tells you it is ok. > > > > > > > > PatC > > > > > > > > > > -mark > > > > > > > > > > > > > > > > > Mark Eklund wrote: > > > > > > > > > > > > > > All, > > > > > > > > > > > > > > I had sent this issue out earlier and got no response. My vote > > > > > > > is for option #3. If someone wants to send an STR a second time > > > > > > > with no Destination-FQDN, let them. > > > > > > > > > > > > > > -mark > > > > > > > > > > > > > > Submitter name: Mark Eklund > > > > > > > Submitter email address: meklund@cisco.com > > > > > > > Date first submitted: 24-May-2001 > > > > > > > Reference: > > > > > > > Document: Base > > > > > > > Comment type: T > > > > > > > Priority: 1 > > > > > > > Section: > > > > > > > Rationale/Explanation of issue: > > > > > > > > > > > > > > * The Session-Terminate-Request requires a Destination-FQDN > > > > > > > > > > > > > > * There was going to be text added to state that the Destination-FQDN > > > > > > > should be that of the last place you authenticated. > > > > > > > > > > > > > > * What happens if that Destination-FQDN is down? If this is a cluster > > > > > > > of servers, there may still be a need for the STR to be sent to the > > > > > > > realm. > > > > > > > > > > > > > > Requested change: > > > > > > > > > > > > > > One or more of the following changes: > > > > > > > > > > > > > > 1. Do nothing. If the authenticating server goes down, either all the > > > > > > > state data is lost, or session timeouts will cleanup any STRs missed. > > > > > > > A statement as such should be added to the RFC reflecting this. > > > > > > > > > > > > > > 2. Make the Destination-FQDN optional. If the client receives a > > > > > > > DIAMETER_UNABLE_TO_DELIVER, the client may send the request without > > > > > > > a Destination-FQDN. > > > > > > > > > > > > > > 3. #2 above, but allow a proxy to also do this. > > > > > > > > > > > > > > 4. Make the Destination-FQDN optional. Add an STR-Destination AVP > > > > > > > that is of type integer that is sent as a part of the authentication > > > > > > > process. This would contain the Destination-Realm and optionally > > > > > > > the Destination-FQDN to which this should be sent. > > > > > > > > > > > > > > ==================================================================== > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-aaa-bof@merit.edu Tue Jun 5 11:37:46 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23647 for ; Tue, 5 Jun 2001 11:37:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 67F8B91385; Tue, 5 Jun 2001 11:37:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 36F2291386; Tue, 5 Jun 2001 11:37:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F31A991385 for ; Tue, 5 Jun 2001 11:37:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8D8065DDF7; Tue, 5 Jun 2001 11:38:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id CE80B5DDFB for ; Tue, 5 Jun 2001 11:38:03 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id IAA61822; Tue, 5 Jun 2001 08:27:20 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 5 Jun 2001 08:27:20 -0700 (PDT) From: Bernard Aboba To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue #33: Is API Considered Useful In-Reply-To: <20010605065701.C22616@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk As far as I can see, this is not a requirement in RFC 2989. Personally, I don't feel that this is necessary because given the failover/failback functionality, if it is possible to bring up a reliable connection, Diameter will get the accounting packets through. So there shouldn't be any need to poll for the data. On Tue, 5 Jun 2001, Pat Calhoun wrote: > All, > > I spoke with Tom Hiller, the editor of the various 3GPP2 specs, and talked to him about > P.R001, and the rather obscure requirement to allow for a server initiated accounting > poll. He stated that if the feature wasn't discussed in P.S001, then it isn't a requirement, > and P.R001 is a non-normative reference in P.S001 (it is informational only). > > So, it sounds as if we can get rid of this feature, but I would like to ask, one last time, > whether people feel it is necessary for an accounting server to be able to issue a request > to an access device to force it to send an accounting message. If so, then we will keep this > feature, but if there is no demand..... out it goes. > > PatC > From owner-aaa-bof@merit.edu Tue Jun 5 11:53:15 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24040 for ; Tue, 5 Jun 2001 11:53:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 862429138D; Tue, 5 Jun 2001 11:53:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 571EB9138E; Tue, 5 Jun 2001 11:53:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 541E99138D for ; Tue, 5 Jun 2001 11:53:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E35715DDFC; Tue, 5 Jun 2001 11:53:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by segue.merit.edu (Postfix) with ESMTP id 951AE5DDD9 for ; Tue, 5 Jun 2001 11:53:29 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id IAA16501 for ; Tue, 5 Jun 2001 08:53:13 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id IAA25811 for ; Tue, 5 Jun 2001 08:53:13 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Jun 2001 10:53:13 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECF1B@IL27EXM10.cig.mot.com> From: Cain Brian-BCAIN1 To: "'Mark Eklund'" , Pat Calhoun Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Support for multi-process Date: Tue, 5 Jun 2001 10:53:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-bof@merit.edu Precedence: bulk > -----Original Message----- > From: Mark Eklund [mailto:meklund@cisco.com] > > Pat, > > Here is my proposed solution for multi-process access. Looks good so far. My only recommendation is non-technical -> call the Win/Lose Election events something more in line with their description, something like "Existing-Conn-Win" and "New-Conn-Win", maybe? This is slightly off topic from the current thread, but I've been wondering a few things. How do multihoming and ip aliasing interfere w/this model? My understanding is that connections can be bound to any subset of the IPs available. I've done a little digging, and this seems somewhat different for SCTP and TCP, but the conditions below are possible with both. If that's the case, and the client listening on "w.x.y.z" is initiating connections from "p.q.r.s", it would seem that he could create undetectable duplicate connections. It seems like quite a bit of effort has gone into the state machine to eliminate duplicate transport connections, so I figured this case needs to be mentioned. I did a quick search of the list archive, and couldn't find any reference to this sort of situation. Perhaps it should be explicitly disallowed in the spec, if it isn't already. (e.g. "All initiator connections from a given AAA entity must be bound to the same IP(s) as that entity's responder connection(s)"). This does not seem to prevent duplicate connections entirely (apparently outgoing TCP connections can't really logically bind themselves to more than one address), but it does seem to eliminate a few extra possibilities. Can anyone think of a logical reason to have a AAA entity that functions otherwise? -Brian From owner-aaa-bof@merit.edu Tue Jun 5 11:54:01 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24082 for ; Tue, 5 Jun 2001 11:53:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0F4089138E; Tue, 5 Jun 2001 11:53:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CE5079138F; Tue, 5 Jun 2001 11:53:56 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BADE29138E for ; Tue, 5 Jun 2001 11:53:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 63E175DDFC; Tue, 5 Jun 2001 11:54:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 7625F5DE00 for ; Tue, 5 Jun 2001 11:54:16 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA22224; Tue, 5 Jun 2001 11:53:22 -0400 (EDT) Date: Tue, 5 Jun 2001 11:53:40 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: Juergen Schoenwaelder Cc: aaa-wg@merit.edu, erik.guttman@germany.sun.com, pcalhoun@diameter.org Subject: Re: [AAA-WG]: Re: [issue] Bring back UTF8 datatype. In-Reply-To: <200106051512.RAA14971@henkell.ibr.cs.tu-bs.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Juergen, On Tue, 5 Jun 2001, Juergen Schoenwaelder wrote: > > Mark> Juergen, > Mark> > Mark> Is the following acceptable. > Mark> > Mark> 1. I renamed "AVP Data Formats" to "AVP Base Data Formats". > > OK > > Mark> 2. I created a new section, "AVP Derived Data Formats". > > OK > > Mark> 3. I stated that an AVP Derived Data Format MUST only be > Mark> defined in one RFC. > > I guess you mean "AVP Base Data Formats" here. With that assumption, OK. Correct > > Mark> 4. I stated that a new AVP Derived Data Format MUST be > Mark> registered with IANA. (This may be a little extreme.) > > This at least ensures that you get unique names. > > Mark> 5. I moved Address to the AVP Derived Data Formats. > > OK > > Mark> 6. I added a time format to the AVP Derived Data Formats. > > OK > > Mark> 7. I added UTF8String and used most of the explanation from > Mark> your example to describe it. > > OK > > Mark> 8. Additionally, I specified that UTF8String MUST not contain > Mark> an octet with a value of zero. > > Note sure this is necessary - but see below. > > Mark> 9. I added a DiameterIdentity format (formerly FQDN) to the AVP > Mark> Derived Data Formats. > > OK > > Mark> 10. I added an Enumerated format to the AVP Derived Data > Mark> Formats. > > OK. > > Mark> Below is the new text. Is the basic idea getting closer to > Mark> respectable? If so, any comments on the details? > > Looks good. Below are some more detailed comments. > > Mark> OctetString > Mark> The data contains arbitrary data of variable length. Unless > Mark> otherwise noted, the AVP Length field MUST be set to at least 9 > Mark> (13 if the 'V' bit is enabled). AVP Values of this type that > Mark> do not align on a 32-bit boundary MUST have the necessary > Mark> padding. > > Note that the length should be 8 or 12 to allow for zero-length > strings (as noted already somewhere else). Agreed. > > Mark> Unsigned32 > Mark> 32 bit unsigned value, in network byte order. The AVP Length > Mark> field MUST be set to 12 (16 if the 'V' bit is enabled). > Mark> Unsigned32 values used to transmit time data contains the four > Mark> most significant octets returned from NTP [18], in network byte > Mark> order. > > I suggest to remove the last sentence as it is irrelevant for > understanding what an Unsigned32 value looks like. Agreed. > > Mark> Address > Mark> The Address format is derived from the OctetString AVP Base > Mark> Format. It represents 32 bit (IPv4) [17] or 128 bit (IPv6) > Mark> [16] address, most significant octet first. The format of the > Mark> address (IPv4 or IPv6) is determined by the length. If the > Mark> attribute value is an IPv4 address, the AVP Length field MUST > Mark> be 12 (16 if 'V' bit is enabled), otherwise the AVP Length > Mark> field MUST be set to 24 (28 if the 'V' bit is enabled) for > Mark> IPv6 addresses. > > Perhaps this should be called IpAddress to make it clearer that it is > restricted to IP addresses. Another question is whether Diameter will > ever have to deal with scoped IPv6 addresses which require another 4 > bytes to make them unique in a given domain (scope identifier). RFC > 2851 has take the approach to allow 16 or 20 bytes for an IPv6 > address. Good point. I'll leave the above as is for now, but create a new issue concerning the above. > > Mark> UTF8String > [...] > > Mark> The UTF8String MUST not contain any octets with a value of > Mark> zero. > > I am not sure this is needed since you already have this: > > Mark> Since additional code points are added by amendments to the > Mark> 10646 standard from time to time, implementations MUST be > Mark> prepared to encounter any code point from 0x00000001 to > Mark> 0x7fffffff. Byte sequences that do not correspond to the > Mark> valid UTF-8 encoding of a code point or are outside this > Mark> range are prohibited. > > I am not a UTF-8 expert but it appears to me (from reading RFC 2279) > that the UTF-8 encoding can only contain a 0x00 byte if the code point > is actually 0x00000000. But I might be wrong on this. I'm no expert either. I'd like to explicitely state that no octet may contain a 0x00 byte. I agree the statement is redundant. How about I change and move the statement to be the last sentence in the below paragraph. Since additional code points are added by amendments to the 10646 standard from time to time, implementations MUST be prepared to encounter any code point from 0x00000001 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. Note that since a code point of 0x00000000 is prohibited, no octet will contain a value of 0x00. > > Mark> Enumerated > Mark> Enumerated is Derived from the Unsigned32 AVP Base Format. > Mark> This contains a list of valid values and their interpretation > Mark> and is described in the Diameter application introducing the AVP. > > I personally would allow negative enumerated values (which is > consistent with the SMIv2/SMIng and XDR) and thus I would use > Integer32 as the AVP base format here. There remaining range of > positive numbers should still be large enough to hold real-world > enumerated values. > Good point. Making it an Integer32 is fine by me. -mark From owner-aaa-bof@merit.edu Tue Jun 5 11:57:44 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24249 for ; Tue, 5 Jun 2001 11:57:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 361979138F; Tue, 5 Jun 2001 11:57:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F112B91390; Tue, 5 Jun 2001 11:57:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E9CF49138F for ; Tue, 5 Jun 2001 11:57:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 94C795DDD9; Tue, 5 Jun 2001 11:57:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by segue.merit.edu (Postfix) with ESMTP id E00EE5DDFD for ; Tue, 5 Jun 2001 11:57:57 -0400 (EDT) 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 RAA16801; Tue, 5 Jun 2001 17:57:41 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA15176; Tue, 5 Jun 2001 17:57:40 +0200 Date: Tue, 5 Jun 2001 17:57:40 +0200 Message-Id: <200106051557.RAA15176@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: meklund@cisco.com Cc: aaa-wg@merit.edu, erik.guttman@germany.sun.com, pcalhoun@diameter.org In-reply-to: (message from Mark Eklund on Tue, 5 Jun 2001 11:53:40 -0400 (EDT)) Subject: Re: [AAA-WG]: Re: [issue] Bring back UTF8 datatype. References: Sender: owner-aaa-bof@merit.edu Precedence: bulk >>>>> Mark Eklund writes: Mark> I'm no expert either. I'd like to explicitely state that no Mark> octet may contain a 0x00 byte. I agree the statement is Mark> redundant. How about I change and move the statement to be the Mark> last sentence in the below paragraph. Mark> Since additional code points are added by amendments to the Mark> 10646 standard from time to time, implementations MUST be Mark> prepared to encounter any code point from 0x00000001 to Mark> 0x7fffffff. Byte sequences that do not correspond to the valid Mark> UTF-8 encoding of a code point or are outside this range are Mark> prohibited. Note that since a code point of 0x00000000 is Mark> prohibited, no octet will contain a value of 0x00. Looks good to me. /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-aaa-bof@merit.edu Tue Jun 5 11:59:49 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24340 for ; Tue, 5 Jun 2001 11:59:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DE54F91390; Tue, 5 Jun 2001 11:59:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF6E091391; Tue, 5 Jun 2001 11:59:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2AB8291390 for ; Tue, 5 Jun 2001 11:59:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C80B35DDFD; Tue, 5 Jun 2001 12:00:09 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 6A9305DDB8 for ; Tue, 5 Jun 2001 12:00:09 -0400 (EDT) Received: (qmail 937 invoked by uid 500); 5 Jun 2001 15:49:25 -0000 Date: Tue, 5 Jun 2001 08:49:25 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Proposed fix for issues 26, 38 and 48 Message-ID: <20010605084925.M22616@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, Here is my proposed fix for issues 26, 38 and 48. This proposed text is similar to Mark's text earlier this week, but also addresses other issues. PatC ---- 10.12 Session-Binding AVP The Session-Binding AVP (AVP Code TBD) is of type Unsigned32, and MAY be present in application-specific authorization answer messages. If present, this AVP MAY inform the Diameter client that all future application-specific re-auth messages for this session MUST be sent to the same authorization server. This AVP MAY also specify that a Session-Termination-Request message for this session MUST be sent to the same authorizing server. The following values are supported: DONT_CARE 0 The Destination-Host AVP does not need to be present in future re-auth and STR messages for this session. RE_AUTH_ONLY 1 The Destination-Host AVP in future re-auth messages for this session MUST be set to the value of the Origin-Host AVP in the authorization answer message. STR_ONLY 2 The Destination-Host AVP in Session-Termination-Request message for this session MUST be set to the value of the Origin-Host AVP in the authorization answer message. DO_BOTH 3 The Destination-Host AVP in future re-auth and the Session- Termination-Request message for this session MUST be set to the value of the Origin-Host AVP in the authorization answer message. 10.13 Session-Server-Failover AVP The Session-Server-Failover AVP (AVP Code TBD) is of type Unsigned32, and MAY be present in application-specific authorization answer messages that include the Session-Binding AVP with a non-zero value. If present, this AVP MAY inform the Diameter client that if a re-auth or STR message fails due to a delivery problem, the Diameter client SHOULD issue a subsequent message without the Destination-Host AVP. REFUSE_SERVICE 0 If either the re-auth or the STR message delivery fails, terminate service with the user, and do not attempt any subsequent attempts. TRY_AGAIN 1 If either the re-auth or the STR message delivery fails, resend the failed message without the Destination-Host AVP present. From owner-aaa-bof@merit.edu Tue Jun 5 12:00:14 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24392 for ; Tue, 5 Jun 2001 12:00:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D6750912C6; Tue, 5 Jun 2001 10:18:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A28889137A; Tue, 5 Jun 2001 10:18:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 22E88912C6 for ; Tue, 5 Jun 2001 10:18:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7550B5DDFF; Tue, 5 Jun 2001 10:18:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from newman.frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id F36A75DDFD for ; Tue, 5 Jun 2001 10:18:49 -0400 (EDT) Received: (qmail 9640 invoked by uid 500); 5 Jun 2001 14:18:32 -0000 Date: Tue, 5 Jun 2001 09:18:32 -0500 From: David Frascone To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue #3: Bring back UTF-8 Message-ID: <20010605091832.C18382@newman.frascone.com> Mail-Followup-To: aaa-wg@merit.edu References: <20010605065257.B22616@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010605065257.B22616@charizard.diameter.org>; from pcalhoun@diameter.org on Tue, Jun 05, 2001 at 06:52:57AM -0700 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk I think that the "Derived Data Formats" are something that should be left to implementations. If we want to formalize them, it should be in a different draft, and should not be in Diameter's critical path. Currently, we have implemented something similar in XML, anthough Mark has done MUCH more work than we have on formalizing the types. So, I guess my vote is that it is a dictionary issue. Although, that does *not* imply that it cannot be formalized. Just that it should not be formalized in the core documents. -Dave On Tue, Jun 05, 2001 at 06:52:57AM -0700, Pat Calhoun wrote: > All, > > Mark Eklund made a proposal in http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00392.html, > and there hasn't been any discussions on this. This e-mail was specifically targetted to > Erik Guttman and Juergen, but no response was received. > > Do people feel comfortable with this approach? I believe that this request has been made > several times in the past year, and there seemed to be considerable interest. Of course, > we could simply state that this is a dictionary issue, and doesn't belong in the core > specs, but it would be nice to allow dictionary creation to follow the author of an > application's original intent, and not have any second guessing to do. > > Comments? > > PatC > From owner-aaa-bof@merit.edu Tue Jun 5 12:09:16 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24684 for ; Tue, 5 Jun 2001 12:09:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ECF1F91395; Tue, 5 Jun 2001 12:08:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B9FAF91394; Tue, 5 Jun 2001 12:08:46 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7056391396 for ; Tue, 5 Jun 2001 12:08:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C6E315DDFE; Tue, 5 Jun 2001 12:09:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 4C4D35DDB8 for ; Tue, 5 Jun 2001 12:09:05 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12599; Tue, 5 Jun 2001 10:08:43 -0600 (MDT) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29285; Tue, 5 Jun 2001 09:08:43 -0700 (PDT) Received: from jafo (jafo [152.70.40.123]) by nasnfs.Eng.Sun.COM (8.10.2+Sun/8.10.2) with SMTP id f55G8ew13386; Tue, 5 Jun 2001 09:08:40 -0700 (PDT) Date: Tue, 5 Jun 2001 09:10:44 -0700 (PDT) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: Re: [issue] Bring back UTF8 datatype. To: Mark Eklund Cc: Juergen Schoenwaelder , aaa-wg@merit.edu, erik.guttman@germany.sun.com, pcalhoun@diameter.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Mark, Could you please update the text to include Juergen's comments and resend to the list? I would then include the text into the base protocol spec. PatC > Juergen, > > On Tue, 5 Jun 2001, Juergen Schoenwaelder wrote: > > > > > Mark> Juergen, > > Mark> > > Mark> Is the following acceptable. > > Mark> > > Mark> 1. I renamed "AVP Data Formats" to "AVP Base Data Formats". > > > > OK > > > > Mark> 2. I created a new section, "AVP Derived Data Formats". > > > > OK > > > > Mark> 3. I stated that an AVP Derived Data Format MUST only be > > Mark> defined in one RFC. > > > > I guess you mean "AVP Base Data Formats" here. With that assumption, OK. > > Correct > > > > > Mark> 4. I stated that a new AVP Derived Data Format MUST be > > Mark> registered with IANA. (This may be a little extreme.) > > > > This at least ensures that you get unique names. > > > > Mark> 5. I moved Address to the AVP Derived Data Formats. > > > > OK > > > > Mark> 6. I added a time format to the AVP Derived Data Formats. > > > > OK > > > > Mark> 7. I added UTF8String and used most of the explanation from > > Mark> your example to describe it. > > > > OK > > > > Mark> 8. Additionally, I specified that UTF8String MUST not contain > > Mark> an octet with a value of zero. > > > > Note sure this is necessary - but see below. > > > > Mark> 9. I added a DiameterIdentity format (formerly FQDN) to the AVP > > Mark> Derived Data Formats. > > > > OK > > > > Mark> 10. I added an Enumerated format to the AVP Derived Data > > Mark> Formats. > > > > OK. > > > > Mark> Below is the new text. Is the basic idea getting closer to > > Mark> respectable? If so, any comments on the details? > > > > Looks good. Below are some more detailed comments. > > > > Mark> OctetString > > Mark> The data contains arbitrary data of variable length. Unless > > Mark> otherwise noted, the AVP Length field MUST be set to at least 9 > > Mark> (13 if the 'V' bit is enabled). AVP Values of this type that > > Mark> do not align on a 32-bit boundary MUST have the necessary > > Mark> padding. > > > > Note that the length should be 8 or 12 to allow for zero-length > > strings (as noted already somewhere else). > > Agreed. > > > > > Mark> Unsigned32 > > Mark> 32 bit unsigned value, in network byte order. The AVP Length > > Mark> field MUST be set to 12 (16 if the 'V' bit is enabled). > > Mark> Unsigned32 values used to transmit time data contains the four > > Mark> most significant octets returned from NTP [18], in network byte > > Mark> order. > > > > I suggest to remove the last sentence as it is irrelevant for > > understanding what an Unsigned32 value looks like. > > Agreed. > > > > > Mark> Address > > Mark> The Address format is derived from the OctetString AVP Base > > Mark> Format. It represents 32 bit (IPv4) [17] or 128 bit (IPv6) > > Mark> [16] address, most significant octet first. The format of the > > Mark> address (IPv4 or IPv6) is determined by the length. If the > > Mark> attribute value is an IPv4 address, the AVP Length field MUST > > Mark> be 12 (16 if 'V' bit is enabled), otherwise the AVP Length > > Mark> field MUST be set to 24 (28 if the 'V' bit is enabled) for > > Mark> IPv6 addresses. > > > > Perhaps this should be called IpAddress to make it clearer that it is > > restricted to IP addresses. Another question is whether Diameter will > > ever have to deal with scoped IPv6 addresses which require another 4 > > bytes to make them unique in a given domain (scope identifier). RFC > > 2851 has take the approach to allow 16 or 20 bytes for an IPv6 > > address. > > Good point. I'll leave the above as is for now, but create a > new issue concerning the above. > > > > > Mark> UTF8String > > [...] > > > > Mark> The UTF8String MUST not contain any octets with a value of > > Mark> zero. > > > > I am not sure this is needed since you already have this: > > > > Mark> Since additional code points are added by amendments to the > > Mark> 10646 standard from time to time, implementations MUST be > > Mark> prepared to encounter any code point from 0x00000001 to > > Mark> 0x7fffffff. Byte sequences that do not correspond to the > > Mark> valid UTF-8 encoding of a code point or are outside this > > Mark> range are prohibited. > > > > I am not a UTF-8 expert but it appears to me (from reading RFC 2279) > > that the UTF-8 encoding can only contain a 0x00 byte if the code point > > is actually 0x00000000. But I might be wrong on this. > > I'm no expert either. I'd like to explicitely state that no > octet may contain a 0x00 byte. I agree the statement is > redundant. How about I change and move the statement to be the > last sentence in the below paragraph. > > Since additional code points are added by amendments to the > 10646 standard from time to time, implementations MUST be > prepared to encounter any code point from 0x00000001 to > 0x7fffffff. Byte sequences that do not correspond to the > valid UTF-8 encoding of a code point or are outside this > range are prohibited. Note that since a code point of > 0x00000000 is prohibited, no octet will contain a value of > 0x00. > > > > > Mark> Enumerated > > Mark> Enumerated is Derived from the Unsigned32 AVP Base Format. > > Mark> This contains a list of valid values and their interpretation > > Mark> and is described in the Diameter application introducing the AVP. > > > > I personally would allow negative enumerated values (which is > > consistent with the SMIv2/SMIng and XDR) and thus I would use > > Integer32 as the AVP base format here. There remaining range of > > positive numbers should still be large enough to hold real-world > > enumerated values. > > > > Good point. Making it an Integer32 is fine by me. > > -mark > > From owner-aaa-bof@merit.edu Tue Jun 5 13:51:07 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27138 for ; Tue, 5 Jun 2001 13:50:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A06C0912CB; Tue, 5 Jun 2001 13:47:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 63AC99139D; Tue, 5 Jun 2001 13:47:16 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 76889912CB for ; Tue, 5 Jun 2001 13:46:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 402CA5DDF6; Tue, 5 Jun 2001 13:46:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id B1E425DDD4 for ; Tue, 5 Jun 2001 13:46:45 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA17375; Tue, 5 Jun 2001 10:46:20 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28074; Tue, 5 Jun 2001 10:46:09 -0700 (PDT) Received: from luckee (luckee.Eng.Sun.COM [129.146.88.225]) by nasnfs.Eng.Sun.COM (8.10.2+Sun/8.10.2) with SMTP id f55Hk7w15203; Tue, 5 Jun 2001 10:46:07 -0700 (PDT) Date: Tue, 5 Jun 2001 10:43:58 -0700 (PDT) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: [AAA-WG]: Support for multi-process To: Cain Brian-BCAIN1 Cc: "'Mark Eklund'" , Pat Calhoun , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <35DBB8B7AC89D4118E98009027B1009B0ECF1B@IL27EXM10.cig.mot.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > This is slightly off topic from the current thread, but I've been wondering > a few things. How do multihoming and ip aliasing interfere w/this model? Not a problem since the peer's identity is used, not IP addresses. > If that's the case, and the client listening on "w.x.y.z" is initiating > connections from "p.q.r.s", it would seem that he could create undetectable > duplicate connections. It seems like quite a bit of effort has gone into > the state machine to eliminate duplicate transport connections, so I figured > this case needs to be mentioned. ok, but again, since the state machine doesn't use IP addresses, but rather peer identities, and of course assuming the same identity is sent regardless of the source IP address, the state machine would work fine. > > I did a quick search of the list archive, and couldn't find any reference to > this sort of situation. Perhaps it should be explicitly disallowed in the > spec, if it isn't already. (e.g. "All initiator connections from a given > AAA entity must be bound to the same IP(s) as that entity's responder > connection(s)"). This does not seem to prevent duplicate connections > entirely (apparently outgoing TCP connections can't really logically bind > themselves to more than one address), but it does seem to eliminate a few > extra possibilities. > > Can anyone think of a logical reason to have a AAA entity that functions > otherwise? multi-homing should be support (actually already is), and I wouldn't feel comfortable eliminating this. Having said that, for those of you have have seen my comments to the transport draft, that spec implies that a AAA protocol MUST allow multiple connections between peers for non SCTP transports in order to minimize head of line blocking. Now that's is completely against what we've been doing in the base protocol spec, so what do folks think we should do? Single or multiple connections? PatC From owner-aaa-bof@merit.edu Tue Jun 5 14:02:21 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27438 for ; Tue, 5 Jun 2001 14:02:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 792DD9139E; Tue, 5 Jun 2001 13:59:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3DFFC913A3; Tue, 5 Jun 2001 13:59:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4C1B79139E for ; Tue, 5 Jun 2001 13:59:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 264195DE06; Tue, 5 Jun 2001 13:59:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from DTV3.DeltaTel.RU (dtv3.deltatel.ru [194.8.169.65]) by segue.merit.edu (Postfix) with SMTP id E07AC5DDD4 for ; Tue, 5 Jun 2001 13:59:26 -0400 (EDT) Received: from SMTP.DeltaTel.RU ([172.16.6.9]) by DTV5.DeltaTel.RU with ESMTP for aaa-wg@merit.edu; Tue, 5 Jun 2001 21:59:08 GMT Message-ID: <3B1D2033.879899BC@SMTP.DeltaTel.RU> Date: Tue, 05 Jun 2001 22:08:51 +0400 From: "Ruslan R. Laishev" Organization: StarLet Group, http://www.StarLet.SPb.RU X-Mailer: Mozilla 4.08 [en] (WinNT; U) MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Support for multi-process References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Now that's is completely against what we've been doing in the base protocol > spec, so what do folks think we should do? Single or multiple connections? multiple. > > PatC -- Cheers, Ruslan. +----------------pure personal opinion------------------------+ RADIUS Server for OpenVMS project - www.radiusvms.com vms-isps@dls.net - Forum for ISP running OpenVMS Mobile: +7 (901) 971-3222 From owner-aaa-bof@merit.edu Tue Jun 5 14:59:42 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28243 for ; Tue, 5 Jun 2001 14:59:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A4552912D0; Tue, 5 Jun 2001 14:59:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 77D969139F; Tue, 5 Jun 2001 14:59:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6C047912D0 for ; Tue, 5 Jun 2001 14:59:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D351F5DE07; Tue, 5 Jun 2001 15:00:03 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by segue.merit.edu (Postfix) with ESMTP id 50F325DE06 for ; Tue, 5 Jun 2001 15:00:03 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id LAA23177 for ; Tue, 5 Jun 2001 11:59:46 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id LAA03261 for ; Tue, 5 Jun 2001 11:59:46 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Jun 2001 13:59:47 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECF1D@IL27EXM10.cig.mot.com> From: Cain Brian-BCAIN1 To: "'Pat Calhoun'" Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Support for multi-process Date: Tue, 5 Jun 2001 13:59:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-bof@merit.edu Precedence: bulk > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] ... > > a few things. How do multihoming and ip aliasing interfere > w/this model? > > Not a problem since the peer's identity is used, not IP addresses. I see. I missed the point of the whole "Server Identification" thread. ... > Having said that, for those of you have have seen my comments > to the transport > draft, that spec implies that a AAA protocol MUST allow > multiple connections > between peers for non SCTP transports in order to minimize > head of line > blocking. > > Now that's is completely against what we've been doing in the > base protocol > spec, so what do folks think we should do? Single or multiple > connections? Multiple's ok with me, if it needs to be there. Would/Should we distinguish between transports when deciding whether to allow an nth connection, or does this have to be a Pandora's Box of sorts? (i.e. is this an "all or nothing" situation?) -Brian From owner-aaa-bof@merit.edu Tue Jun 5 16:05:38 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29357 for ; Tue, 5 Jun 2001 16:05:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7C221912D2; Tue, 5 Jun 2001 16:05:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 47867913A1; Tue, 5 Jun 2001 16:05:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E4C2E912D2 for ; Tue, 5 Jun 2001 16:05:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D9D1A5DD9C; Tue, 5 Jun 2001 16:05:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id AC19A5DE03 for ; Tue, 5 Jun 2001 16:05:52 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA24603; Tue, 5 Jun 2001 16:04:59 -0400 (EDT) Date: Tue, 5 Jun 2001 16:05:17 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Proposed fix for issues 26, 38 and 48 In-Reply-To: <20010605084925.M22616@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, Two thoughts. On Tue, 5 Jun 2001, Pat Calhoun wrote: > > All, > > Here is my proposed fix for issues 26, 38 and 48. This proposed text is > similar to Mark's text earlier this week, but also addresses other issues. > > PatC > ---- > > 10.12 Session-Binding AVP > > The Session-Binding AVP (AVP Code TBD) is of type Unsigned32, and MAY > be present in application-specific authorization answer messages. If > present, this AVP MAY inform the Diameter client that all future > application-specific re-auth messages for this session MUST be sent > to the same authorization server. This AVP MAY also specify that a > Session-Termination-Request message for this session > MUST be sent to the same authorizing server. The following values > are supported: > > DONT_CARE 0 > The Destination-Host AVP does not need to be present in future > re-auth and STR messages for this session. > > RE_AUTH_ONLY 1 > The Destination-Host AVP in future re-auth messages for this > session MUST be set to the value of the Origin-Host AVP in the > authorization answer message. > > STR_ONLY 2 > The Destination-Host AVP in Session-Termination-Request message > for this session MUST be set to the value of the Origin-Host > AVP in the authorization answer message. > 1. If the AVP is not present, is the default DO_BOTH? > DO_BOTH 3 > The Destination-Host AVP in future re-auth and the Session- > Termination-Request message for this session MUST be set to the > value of the Origin-Host AVP in the authorization answer > message. > > > 10.13 Session-Server-Failover AVP > > The Session-Server-Failover AVP (AVP Code TBD) is of type Unsigned32, > and MAY be present in application-specific authorization answer > messages that include the Session-Binding AVP with a non-zero value. > If present, this AVP MAY inform the Diameter client that if a re-auth > or STR message fails due to a delivery problem, the Diameter client > SHOULD issue a subsequent message without the Destination-Host AVP. > > REFUSE_SERVICE 0 > If either the re-auth or the STR message delivery fails, > terminate service with the user, and do not attempt any > subsequent attempts. > > TRY_AGAIN 1 > If either the re-auth or the STR message delivery fails, resend > the failed message without the Destination-Host AVP present. 2. If the AVP is not sent, is the default REFUSE_SERVICE? 3. Any possibility of adding the below two? ALLOW_SERVICE 2 If re-auth message delivery fails, assume that re-authorization succeeded. If STR message delivery fails, terminate the session. TRY_AGAIN_ALLOW_SERVICE 3 If either the re-auth or the STR message delivery fails, resend the failed message without the Destination-Host AVP present. If the second delivery fails for re-auth, assume re-authorization succeeded. If the second delivery fails for STR, terminate the session. -mark From owner-aaa-bof@merit.edu Tue Jun 5 16:18:33 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29498 for ; Tue, 5 Jun 2001 16:18:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 173BA912D3; Tue, 5 Jun 2001 16:18:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D0CA0912D4; Tue, 5 Jun 2001 16:18:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 16485912D3 for ; Tue, 5 Jun 2001 16:18:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 12E305DDB6; Tue, 5 Jun 2001 16:18:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp014.mail.yahoo.com (smtp014.mail.yahoo.com [216.136.173.58]) by segue.merit.edu (Postfix) with SMTP id 7FCD65DD9C for ; Tue, 5 Jun 2001 16:18:50 -0400 (EDT) Received: from pc121.etc.psi.com (HELO jc.yahoo.com) (195.94.40.121) by smtp.mail.vip.sc5.yahoo.com with SMTP; 5 Jun 2001 20:18:33 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010605182622.00d9b4a0@pop.fr.psi.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 05 Jun 2001 22:18:11 +0200 To: aaa-wg@merit.edu From: Jacques Caron Subject: [AAA-WG]: Comments on base draft 05 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi, I've been reading though the Diameter drafts, and had a few comments. Please forgive me if any of those have already been discussed to death, I tried to check as much as possible in the issues list on the Web site, but since I haven't been following the list for very long, I might have missed some. I understand that formal issues have to be submitted using the appropriate template, but given the number of comments I have, I guess a first quick run through on which others can give a quick word on whether the issue is not new would be better, to then formally submit only those that are actually valid? Let me know if you'd rather have me submit everything in the correct format directly... =========== In 2.5.3, can a server that received a redirect cache the result (e.g. based on realm+application)? =========== In 2.6/3, when using DNS, what if there are indirect relationships? Imagine the following: - ISP A is a customer of roaming clearinghouse B. - Company E is a customer of ISP D, which is a customer of roaming clearinghouse C. - B & C have a "peering" relationship. B---C | | A D | E (the idea is to duplicate the peering/transit mechanisms of routing within the Internet, to reduce direct peering relationships, but still with the ability to have multiple competing roaming clearinghouse that talk to each other). Since there are only direct relationships between A&B, B&C, C&D and D&E, the request must be proxied along all that path, but there is no mechanism to find it. Let's say that A->B is done using a simple "default route". I then see multiple options for B to send the request to E: 1. DNS+"backward" redirects - The home diameter server (E) is found via SRV RRs by B, but since E doesn't "know" B, it redirects it to D (using some "default" mechanism) - D points to C (ditto) - request gets to C, which starts again, and so on until we get to E. Has many drawbacks, amongst which there must be a way for diameter servers that don't know each other to talk at least a bit (not a good idea), and many round-trips accross the net. Might be shortened a bit by A sending directly to B (default). 2. DNS+"backward" RRs - B looks up SRV RRs for E - since it doesn't know that server (in its peers list), it looks for another type of RR (TBD) that points to D (might be a TXT RR giving the realm for D) - starts again to find C, which B knows and can forward the request to. Probably the most elegant. May have issue with different applications, though (unless the server pointed to by SRV RRs is always a proxy that then sends to the right server for the specific application). 3. BGP-routing-like realm distribution in CER Use the Capabilities-Exchange-Request to advertise the realm/application pairs that a server supports, not just applications. This would include realms that upstream servers support, so it could become quite large. Probably not very scalable. 4. BGP-routing-like realm distribution using something else Might use other commands, a different protocol, or even use extensions to BGP? My favorite is 2. Note that all of this might be outside the scope of the (base) document, but I think it would be very useful for roaming, especially in the wireless (WLAN) context. ============== In 3.1/4.1/4.5, what about reserving ranges for experimental command & AVP codes? ============== In 3.2, Command ABNF: - "fixed" isn't defined. It seems to mean that it is required, but at a specific position or in a specific order, but that's really unclear. - the defaults for min & max in qual are not defined if only one of them is present (i.e. no qual = 1*1, but what about *n or n*? I guess the latter means n*infinity, but does *n mean 1*n or 0*n)? - it says that it describes AVPs which MUST NOT be present, but that's not part of the ABNF (it's implicit). =============== In 4.1, AVP Flags: - still mentions both 'r' and reserved bits - says that unrecognized bits should be considered an error, but also that r/reserved bits should be ignored. ============== In 4.1, what about having a AVP type (OctetString, Address, etc.) in the header? This would be useful for logging/debugging purposes in relays that wouldn't need to have (up-to-date) dictionnary files. ============== In 4.5, AVP Flag rules: - what about a flag that isn't in any of the MUST/MAY/SHOULD NOT/MUST NOT categories for a given command? - isn't there some redundancy between the "MAY encr" column and the position of P? ============== In 4.3/4.4, do the AVP codes in a Grouped AVP share the same scope as those at "first level"? ============== In 4.3, max length of an OctetString is still 65504. ============== In 5.1, "the local host's identity is encoded in the Origin-Host and Origin-Host AVPs" (getting picky, sorry). ============== In 5.0/5.3, it is unclear whether the Destination-Realm derivation from the User-Name should be done only in the NAS, or can be done by any agent on the way. ============== In 5.3, Diameter agents *MAY* have a list of locally supported realms... ============== In 5.0/5.3.4/5.6 - the use of Destination-Host for answers quite puzzles me. There's contradiction between 5.6 and 5.3.4 on how routing should be done (based on Destination-Host or Route-Record AVPs?). Using Destination-Host in any case would bypass relays/proxies, which would then lose the ability to track state, to perform accounting (especially in a roaming environment), etc. Not really sure it should ever be used? - even better, the Destination-Realm should probably never be used to routes answers? - Should original client add a Route-Record AVP (or Proxy-Info)? Or should a proxy check the Origin-Host for a loop too? How does routing back to the client work? ============== In 5.3.2 - the use of MRA for redirects doesn't look "clean" to me. I'd rather always have an answer with the same command code as the request, with a specific result-code. - loops should be checked ============== In 5.3.3/5.0, loop checking should be done upon receipt of a message? ============== In 6.0/5.3.1, how does a relay (which adverstised the relay application ID) know which commands are part of which application, if it has multiple upstream peers with different applications? Shouldn't the application ID be included in the packet header? ============== In 5.3.4, the agent sending an STR "on behalf of the access device" is a violation of 5.4? ============== In 5.3.1: - clarify possibility of default realm (which would probably most often be the only realm on access devices). - indicate multiple possible hosts for a realm, or is that handled at DNS/transport level? ============== In 5.5, what's the purpose of the origin-realm? How is it defined/derived? ============== In 5.8, isn't there some redundancy between Route-Record and Proxy-Host? ============== Somewhere in 5, it might be interesting to include a way for diameter proxy/relay/server clusters to exchange state information to facilitate failover. This might be done by sending a copy of all received packets to the other node of the cluster, with either a specific flag set (so the other node updates its state tables, but does not act on the packet or forward it), or some other mechanism. Might be outside the scope of the spec, though. ============== I guess that's it for today. I have a number of other issues, but they were against release 4 of the draft, so I have to check them against rev 5 first before bothering you any more :-) And thanks to all for all the good work that's already been done! Thanks, Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-bof@merit.edu Tue Jun 5 17:47:47 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00369 for ; Tue, 5 Jun 2001 17:47:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A2D7F912D7; Tue, 5 Jun 2001 17:47:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 600CF913A1; Tue, 5 Jun 2001 17:47:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 52B5D912D7 for ; Tue, 5 Jun 2001 17:47:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 684F75DD9C; Tue, 5 Jun 2001 17:47:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 11BBB5DD99 for ; Tue, 5 Jun 2001 17:47:28 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA25518; Tue, 5 Jun 2001 17:46:29 -0400 (EDT) Date: Tue, 5 Jun 2001 17:46:49 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: Patrice Calhoun Cc: Juergen Schoenwaelder , aaa-wg@merit.edu, erik.guttman@germany.sun.com, pcalhoun@diameter.org Subject: Re: [AAA-WG]: Re: [issue] Bring back UTF8 datatype. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, Below are the changes with Juergen's suggestions. -mark 4.3 AVP Base Data Format The Data field is zero or more octets and contains information specific to the Attribute. The format and length of the Data field is determined by the AVP Code and AVP Length fields. The format of the Data field MUST be one of the following base data types or a data type derived from the base data types. In the event that a new AVP Base Data Format is needed, a new version of this RFC must be created. OctetString The data contains arbitrary data of variable length. Unless otherwise noted, the AVP Length field MUST be set to at least 8 (12 if the 'V' bit is enabled). AVP Values of this type that do not align on a 32-bit boundary MUST have the necessary padding. Integer32 32 bit signed value, in network byte order. The AVP Length field MUST be set to 12 (16 if the 'V' bit is enabled). Integer64 64 bit signed value, in network byte order. The AVP Length field MUST be set to 16 (20 if the 'V' bit is enabled). Unsigned32 32 bit unsigned value, in network byte order. The AVP Length field MUST be set to 12 (16 if the 'V' bit is enabled). Unsigned64 64 bit unsigned value, in network byte order. The AVP Length field MUST be set to 16 (20 if the 'V' bit is enabled). Float32 This represents floating point values of single precision as described by [30]. The 32 bit value is transmitted in network byte order. The AVP Length field MUST be set to 12 (16 if the 'V' bit is enabled). Float64 This represents floating point values of double precision as described by [30]. The 64 bit value is transmitted in network byte order. The AVP Length field MUST be set to 16 (20 if the 'V' bit is enabled). Float128 This represents floating point values of quadruple precision as described by [30]. The 128 bit value is transmitted in network byte order. The AVP Length field MUST be set to 24 (28 if the 'V' bit is enabled). Grouped The Data field is specified as a sequence of AVPs. Each of these AVPs follows - in the order in which they are specified - including their headers and padding. The AVP Length field is set to 8 (12 if the 'V' bit is enabled) plus the total length of all included AVPs, including their headers and padding. 4.4 AVP Derived Data Formats In addition to the AVP Base Data Formats, applications may define data formats derived from the AVP Base Data Formats. New AVP Derived Data Formats MUST be registered with IANA. A derived Data Format can only be defined in one active (non-obsolete) RFC. An application that uses AVP Derived Data Formats other than those defined in the base protocol MUST have a section "AVP Derived Data Formats" that includes each of these formats. In that section, each format is either defined or listed with a reference to the RFC that defines this format. If the AVP Derived Data Format is defined, it SHOULD use a format similar to the format definitions below. The below AVP Derived DATA Formats are commonly used by applications. Address The Address format is derived from the OctetString AVP Base Format. It represents 32 bit (IPv4) [17] or 128 bit (IPv6) [16] address, most significant octet first. The format of the address (IPv4 or IPv6) is determined by the length. If the attribute value is an IPv4 address, the AVP Length field MUST be 12 (16 if 'V' bit is enabled), otherwise the AVP Length field MUST be set to 24 (28 if the 'V' bit is enabled) for IPv6 addresses. Time The Time format is derived from the Unsigned32 AVP Base Format. This is 32 bit unsigned value containing the four most significant octets returned from NTP [18], in network byte order. This represent the number of seconds since 0h on 1 January 1900 with respect to the Coordinated Universal Time (UTC). On 6h 28m 16s UTC, 7 February 2036 the time value will overflow. NTP [18] describes a procedure to extend the time to 2104. UTF8String The UTF8String format is derived from the OctetString AVP Base Format. This is a human readable string represented using the ISO/IEC IS 10646-1 character set, encoded as an OctetString using the UTF-8 [29] transformation format described in RFC 2279. Since additional code points are added by amendments to the 10646 standard from time to time, implementations MUST be prepared to encounter any code point from 0x00000001 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. Note that since a code point of 0x00000000 is prohibited, no octet will contain a value of 0x00. The use of control codes SHOULD be avoided. When it is necessary to represent a newline, the control code sequence CR LF SHOULD be used. The use of leading or trailing white space SHOULD be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, MAY be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of a UTF8String in octets may be different from the number of characters encoded. Note that the size of an UTF8String is measured in octets, not characters." The UTF8String MUST not contain any octets with a value of zero. DiameterIdentity The DiameterIdentity format is derived from the OctetString AVP Base Format. It uses the UTF-8 encoding and has the same requirements as the UTF8String. In addition, it must follow the Uniform Resource Identifiers (URI) syntax [29] rules specified below: Diameter-Identity = [protocol] fqdn [ port ] [ transport ] protocol-name = ( "diameter" | "radius" | "tacacs+" ) protocol = protocol-name "://" ; If absent, the default is "diameter://" fqdn = Fully Qualified Host Name port = ":" 1*DIGIT ; If absent, the default Diameter port (TBD) is assumed. transport = ";transport=" ( "tcp" | "sctp" | "udp") ; If absent, the default SCTP [26] protocol is assumed. ; UDP is ONLY used when the protocol is set to RADIUS The following are examples of valid Diameter host identities: host.abc.com:6666;transport=tcp diameter://host.abc.com diameter://host.abc.com:6666 diameter://host.abc.com;transport=tcp diameter://host.abc.com:6666;transport=tcp radius://host.abc.com:1813;transport=udp Enumerated Enumerated is Derived from the Integer32 AVP Base Format. This contains a list of valid values and their interpretation and is described in the Diameter application introducing the AVP. From owner-aaa-bof@merit.edu Tue Jun 5 18:41:10 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00937 for ; Tue, 5 Jun 2001 18:41:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 31D5B912AA; Tue, 5 Jun 2001 18:41:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 058C1912CD; Tue, 5 Jun 2001 18:41:03 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DD77A912AA for ; Tue, 5 Jun 2001 18:41:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EBDA25DDE1; Tue, 5 Jun 2001 18:41:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 9AF8C5DD99 for ; Tue, 5 Jun 2001 18:41:24 -0400 (EDT) Received: (qmail 12778 invoked by uid 500); 5 Jun 2001 22:30:39 -0000 Date: Tue, 5 Jun 2001 15:30:39 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Cc: Pat Calhoun , dave@frascone.com Subject: Re: [AAA-WG]: Issue #3: Bring back UTF-8 (fwd) Message-ID: <20010605153039.H12278@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu, Pat Calhoun , dave@frascone.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from meklund@cisco.com on Tue, Jun 05, 2001 at 05:52:07PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk > I think that the "Derived Data Formats" are something that should be left to > implementations. If we want to formalize them, it should be in a different > draft, and should not be in Diameter's critical path. Is this actually true? This argument has been made throughout the data type discussions, and I don't buy it. Let's take the User-Name AVP, whose definition is: " The User-Name AVP (AVP Code 1) [1] is of type OctetString, which contains the User-Name. The value is represented as a UTF-8 character encoded string in a format consistent with the NAI specification [8]." Note that the second sentence specifically states that this AVP MUST be encoded in UTF-8 format. If it isn't, then an implementation is NOT conformant. Therefore, this type does in fact affect the on-the-wire protocol, since although it doesn't affect the headers, it affects the data encapsulated within the AVP. DiameterIdentity is another perfect example. Since there aren't sub-types being defined, I added it to section 2, which is rather odd. > > Currently, we have implemented something similar in XML, anthough Mark has > done MUCH more work than we have on formalizing the types. > > So, I guess my vote is that it is a dictionary issue. Although, that does > *not* imply that it cannot be formalized. Just that it should not be > formalized in the core documents. I think that it would make much more sense for the author of an application to define in the specification any sub-types, as opposed to let the creators of the dictionaries assume the sub-type. PatC From owner-aaa-bof@merit.edu Tue Jun 5 18:50:30 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01003 for ; Tue, 5 Jun 2001 18:50:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7DAE3912CD; Tue, 5 Jun 2001 18:47:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 50471912D5; Tue, 5 Jun 2001 18:47:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CC6CC912CD for ; Tue, 5 Jun 2001 18:46:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BCECF5DDE1; Tue, 5 Jun 2001 18:47:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from newman.frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 4EF435DD99 for ; Tue, 5 Jun 2001 18:47:02 -0400 (EDT) Received: (qmail 29923 invoked by uid 500); 5 Jun 2001 22:46:45 -0000 Date: Tue, 5 Jun 2001 17:46:45 -0500 From: David Frascone To: aaa-wg@merit.edu, Pat Calhoun Subject: Re: [AAA-WG]: Issue #3: Bring back UTF-8 (fwd) Message-ID: <20010605174645.Q7612@newman.frascone.com> Mail-Followup-To: aaa-wg@merit.edu, Pat Calhoun References: <20010605153039.H12278@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010605153039.H12278@charizard.diameter.org>; from pcalhoun@diameter.org on Tue, Jun 05, 2001 at 03:30:39PM -0700 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk When I first started objecting to this, it was because proxies did not need to know about the inner data to be able to proxy the packets. That is very far from true now. Given that UTF-8, time formats, etc are now part of the core protocol, and need to be examined by even the dumbest proxies, it would probably be better to include the subtypes in the core protocol. "I have been swayed" :) -Dave On Tue, Jun 05, 2001 at 03:30:39PM -0700, Pat Calhoun wrote: > > I think that the "Derived Data Formats" are something that should be left to > > implementations. If we want to formalize them, it should be in a different > > draft, and should not be in Diameter's critical path. > > Is this actually true? This argument has been made throughout the data type > discussions, and I don't buy it. Let's take the User-Name AVP, whose definition > is: > > " The User-Name AVP (AVP Code 1) [1] is of type OctetString, which > contains the User-Name. The value is represented as a UTF-8 > character encoded string in a format consistent with the NAI > specification [8]." > > Note that the second sentence specifically states that this AVP MUST be > encoded in UTF-8 format. If it isn't, then an implementation is NOT conformant. > > Therefore, this type does in fact affect the on-the-wire protocol, since although > it doesn't affect the headers, it affects the data encapsulated within the AVP. > > DiameterIdentity is another perfect example. Since there aren't sub-types being > defined, I added it to section 2, which is rather odd. > > > > > Currently, we have implemented something similar in XML, anthough Mark has > > done MUCH more work than we have on formalizing the types. > > > > So, I guess my vote is that it is a dictionary issue. Although, that does > > *not* imply that it cannot be formalized. Just that it should not be > > formalized in the core documents. > > I think that it would make much more sense for the author of an application to > define in the specification any sub-types, as opposed to let the creators of > the dictionaries assume the sub-type. > > PatC > From owner-aaa-bof@merit.edu Tue Jun 5 18:59:33 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01111 for ; Tue, 5 Jun 2001 18:59:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9DD54912D5; Tue, 5 Jun 2001 18:59:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 652B7912D6; Tue, 5 Jun 2001 18:59:35 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 43025912D5 for ; Tue, 5 Jun 2001 18:59:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7182E5DDE1; Tue, 5 Jun 2001 18:59:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id E88F55DD99 for ; Tue, 5 Jun 2001 18:59:55 -0400 (EDT) Received: (qmail 12917 invoked by uid 500); 5 Jun 2001 22:49:10 -0000 Date: Tue, 5 Jun 2001 15:49:10 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: [Issue] Server Discovery Message-ID: <20010605154910.M12278@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk It seems this one fell through the crack :( Issue nn: Server Discovery Text to change Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: 2001-06-05 Reference: Document: Base Comment type: C Priority: 1 Section: 2.6 Rationale/Explanation of issue: At the Interim Meeting, Bernard stated that we should adopt the procedures described in draft-ietf-sip-srv-02.txt. Requested change: I am not sure what Bernard had in mind. Should we replace the whole section, including the proposal to use SLPv2, and just use the DNS SRV proposed in the above draft, or just replace the one section that deals with DNS SRVs? From owner-aaa-bof@merit.edu Tue Jun 5 19:20:02 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01399 for ; Tue, 5 Jun 2001 19:20:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 52BEC912D8; Tue, 5 Jun 2001 19:20:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 243B1912D9; Tue, 5 Jun 2001 19:20:02 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E328F912D8 for ; Tue, 5 Jun 2001 19:20:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2597E5DD99; Tue, 5 Jun 2001 19:20:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 9713F5DE11 for ; Tue, 5 Jun 2001 19:20:22 -0400 (EDT) Received: (qmail 13036 invoked by uid 500); 5 Jun 2001 23:09:37 -0000 Date: Tue, 5 Jun 2001 16:09:37 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 24: Transport Selection Message-ID: <20010605160936.O12278@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, This one was previously owned by Bernard, but we have no issue on it, so I've taken it over, below, and am proposing text to close this one. PatC ---- Issue 24: Transport Selection Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: 2001-06-05 Reference: Document: Base Comment type: C Priority: 1 Section: 2.1 Rationale/Explanation of issue: At the Interim Meeting, Bernard stated that the base protocol should describe how to connect to a peer in the case where more than one transport is available, or the transport wasn't specified. Requested change: Add the following text to the end of section 2.1: When connecting to a peer, and either zero or more transports are specified, SCTP SHOULD be tried first (if supported), followed by TCP. Diameter implementations SHOULD be able to interpret explicit network notifications (such as ICMP messages) which indicate that a server is not reachable, rather than relying solely on timeouts (e.g. connect() returns ECONNREFUSED if the client could not connect to a server at that address). From owner-aaa-bof@merit.edu Tue Jun 5 19:22:36 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01428 for ; Tue, 5 Jun 2001 19:22:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6F81C912D9; Tue, 5 Jun 2001 19:22:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3496E912DA; Tue, 5 Jun 2001 19:22:31 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B99EA912D9 for ; Tue, 5 Jun 2001 19:22:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0AD7A5DDB6; Tue, 5 Jun 2001 19:22:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id C03005DD99 for ; Tue, 5 Jun 2001 19:22:51 -0400 (EDT) Received: (qmail 13064 invoked by uid 500); 5 Jun 2001 23:12:06 -0000 Date: Tue, 5 Jun 2001 16:12:06 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 56: Flag bit for start of conversation Message-ID: <20010605161206.P12278@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, I'd like to propose that this issue can be rejected. The Destination-Host AVP is used to determine whether a message has a fixed destination or not, so no additional protocol changes are required to support Bernard's requirements. Any objections? PatC From owner-aaa-bof@merit.edu Tue Jun 5 19:28:48 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01482 for ; Tue, 5 Jun 2001 19:28:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 98DBC912DA; Tue, 5 Jun 2001 19:28:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6440D912DB; Tue, 5 Jun 2001 19:28:41 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4C435912DA for ; Tue, 5 Jun 2001 19:28:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8CC015DDB6; Tue, 5 Jun 2001 19:29:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 0E4E35DD99 for ; Tue, 5 Jun 2001 19:29:02 -0400 (EDT) Received: (qmail 13085 invoked by uid 500); 5 Jun 2001 23:18:16 -0000 Date: Tue, 5 Jun 2001 16:18:16 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 20: How to handle no common extensions Message-ID: <20010605161816.Q12278@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, This one was previously owned by Paul, but we have no issue on it, so I've taken it over, below, and am proposing text to close this one. PatC ---- Issue 20: How to handle no common extensions Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: 2001-06-05 Reference: Document: Base Comment type: C Priority: 1 Section: 2.1 Rationale/Explanation of issue: At the Interim meeting there were discussions on how to handle the case where two peers connect, and realize that they have no common applications (was extensions). My take on this is that they should disconnect, since there will not be any further protocol exchanges, but Paul preferred that they stay in communication. Requested change: None. Section 6.0 in the -06 draft currently states: " A receiver of a Capabilities-Exchange-Req message which does not have any applications in common with the sender MUST return a Capabilities-Exchange-Answer with the Result-Code AVP set to DIAMETER_NO_COMMON_APPLICATION, and SHOULD disconnect the transport layer connection." From owner-aaa-bof@merit.edu Tue Jun 5 19:57:11 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01723 for ; Tue, 5 Jun 2001 19:57:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 580C0912DB; Tue, 5 Jun 2001 19:57:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2780B912DC; Tue, 5 Jun 2001 19:57:03 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E7B6B912DB for ; Tue, 5 Jun 2001 19:57:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 445FA5DDB6; Tue, 5 Jun 2001 19:57:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id E4C7C5DD99 for ; Tue, 5 Jun 2001 19:57:22 -0400 (EDT) Received: (qmail 13266 invoked by uid 500); 5 Jun 2001 23:44:54 -0000 Date: Tue, 5 Jun 2001 16:44:54 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 29: IPv6 AVPs Message-ID: <20010605164453.R12278@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, This one was previously owned by Bernard, but we have no issue on it, so I've taken it over, below, and am proposing text to close this one. PatC ---- Issue 29: IPv6 AVPs Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: 2001-06-05 Reference: Document: nasreq Comment type: C Priority: 1 Section: 7.2.5 Rationale/Explanation of issue: At the Interim Meeting, Bernard stated that two RADIUS ipv6 attributes were missing from the NASREQ application, specifically the Framed-Interface-Id, and the Framed-IPv6-Prefix. Proposed Text: 7.2.5.4 Framed-Interface-Id AVP The Framed-Interface-Id AVP (AVP Code TBD) is of type Unsigned64 and contains the IPv6 interface identifier to be configured for the user. It MAY be used in authorization requests as a hint to the server that a specific interface id is desired, but the server is not required to honor the hint in the corresponding response. 7.2.5.5 Framed-IPv6-Prefix AVP The Framed-Interface-Id AVP (AVP Code TBD) is of type Address and contains the IPv6 prefix to be configured for the user. It MAY be used in authorization requests as a hint to the server that a specific interface id is desired, but the server is not required to honor the hint in the corresponding response. From owner-aaa-bof@merit.edu Tue Jun 5 20:10:45 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01894 for ; Tue, 5 Jun 2001 20:10:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 495AE912DC; Tue, 5 Jun 2001 20:10:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 10A9F912DD; Tue, 5 Jun 2001 20:10:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A9CDF912DC for ; Tue, 5 Jun 2001 20:10:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EEFA85DDE1; Tue, 5 Jun 2001 20:10:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by segue.merit.edu (Postfix) with SMTP id 6E5F35DD99 for ; Tue, 5 Jun 2001 20:10:58 -0400 (EDT) Received: from ip98.zurich28.pub-ip.ch.psi.net (HELO jc.yahoo.com) (154.15.28.98) by smtp.mail.vip.sc5.yahoo.com with SMTP; 6 Jun 2001 00:10:11 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010606004514.00bcd7f0@pop.fr.psi.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Jun 2001 02:09:53 +0200 To: aaa-wg@merit.edu From: Jacques Caron Subject: [AAA-WG]: More comments on base draft 05 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi, Me again... I have some more :-) ========== What about having a bit in the header flags to indicate that this message should not be proxied, but only handled locally? This would enable a relay/proxy to recognize messages it doesn't know about that it's supposed to handle (and complain about it?). [I'm really in favor of having relays be able to do as much as possible while knowing as little as possible about the specifics of any application, command, or AVP]. ========== For answers, since in most cases (other than the (in-)famous MRA) the command code is the same as the request, we have a bit to distinguish requests from answers, and the result-code is mandatory, why not simply put the result-code in the command code field? The distinction between protocol and application errors could then be done either based on the result-code (protocol errors are in the 3xxx range) or using the proxy/local flag above... ========== Regarding loop detection, I think the text should specify exactly how host matching is done: based on host descriptor (text), name+port, IP+port, any of the above... ========== Back on the routing of answers: if one admits we forget about Destination-Host to make sure the answers travels the same path back, should a proxy use the route-record AVP, or send it back on the same connection it received the request on (and which it saved in the transaction state table, or in Proxy-State AVPs)? If route-record, then it should be checked on receipt that it matches where the message was received from? Alternatively, it could be decided that the route-record AVP is added upon _receipt_ of a message, not when forwarding it. Which elimites the need for a NAS to insert it. ========= I have only glanced at the NASREQ & Mobile-IP applications, but I really wonder why there is any need for separate Auth Request commands? I think the protocol should be streamlined as much as possible by limiting the number of commands (in too classes: those that are used for local hop interactions: Capability Exchange, Device Watchdog...; and those that are used for end-to-end requests: Auth req, Acct start, Acct stop...; the difference being made with the flag mentionned earlier). The difference between different types of auth requests would then be indicated by an application Id in the command header (which is way more efficient than a Auth/Acct-Application-Id that is mandatory anyway). Having standard auth and acct commands also permits relays to make the difference between auth and acct commands for routing purposes (when a downstream server advertises Auth capability and another Acct capability for a given Application Id), without having to check Auth/Acct-Application-Id presence which have complex rules that are not stated anywhere (only one of them should be present, obviously). ======== Some minor nit-picking: - in 6.0, Device Reboot should be changed to whatever is the new name of those messages - in 6.0 first paragraph, there is a "first", but no "next" or "then" or "second"... - in 6.1, "Relay and redirect agents MUST advertise the *Relay* application..." - in the same paragraph, Device Reboot again - in the next paragraph, it should be upstream, not downstream. - in 7.2, the RTT/RTO stuff isn't used anymore? (didn't go through all the state machine, but there are plenty of DRIs and such in there) ======== In 9.0, what happens if there is no alternate to send the request to? Should the MRA be forwarded upstream? As-is? With stuff changed (Origin-Host, Hop-by-hop, End-to-End Ids...)? ======== In 9.0, in the result-code AVPs that require Failed-AVPs, need a clarification whether this is done only by the home server, or by any proxy/relay on the way ======== In 9.0 still, what about errors regarding invalid length (packet or AVP)? Especially for AVPs, since it will be difficult to include a correctly formatted AVP if length is wrong anyway? ======== Which raises another question: what about a Grouped AVP with M not set containing AVPs with M set? Yes I know I have silly questions. ======== In 5.3.2/9.1: Unless I'm blind (which could be true), DIAMETER_REDIRECT_INDICATION is not defined. ======== In 9.1.3: - as stated above, a separate class for protocol errors is redundant with the use of MRA. - what's the difference between UNABLE_TO_DELIVER and NOT_SERVED? i.e. in which case is which sent? - any specific messages for DNS errors (transient such as timeouts, or permanent such as NXDOMAIN)? ======== In 9.1.4/9.1.5: - should AUTHENTICATION_REJECTED and USER_UNKNOWN really be different? I guess that's the usual tradeoff security (having only one prevents an attacker to find active accounts on which to focus) against user-friendliness... - the difference between AUTHORIZATION_REJECTED and AUTHORIZATION_FAILED is, er, unclear. - NO_COMMON_APPLICATION and UNSUPPORTED_VERSION would be better off in Protocol errors? - missing errors for message or AVP length errors ======= In 10.0 third paragraph, "If the server does not receive another authorization request before the timeout occurs", I guess some leeway for transmission and processing delays would be a good thing :-) The other option is to use Authorization-Lifetime only as a "Reauth timer", and Session-Timeout as the max length after which the user is to be disconnected and forgotten (and even then, keeping state a tad more to match the accounting stop info that is supposed to arrive would still be a good idea). ======= In 10.3 second paragraph, an example of a reason to have multiple Session-IDs in the same message would be good. ======= In 10.7, the STR should be sent along the same path as previous requests, not directly to the server (by using Origin-Host of the auth answer as Destination-Host), for proxies along the way to be able to update state. More generally, again, I really find the Destination-Host AVP very annoying and probably not very useful, except for unsollicited requests from the server to the client, and even in those cases, something should be done to make sure proxies along the way are aware of what's going on. The other use would be to make sure the STR goes to the same server that authorized the connection, but it should apply to all intermediate proxies/relays too, so it should be based on some other mechanism. Anyway, in many cases it simply won't be possible to use Destination-Host because of the lack of security associations between the two endpoints... ======= In 12.3, still a -Ind command. ======= Isn't there some redundancy between STR and an Accounting-Request with type=STOP? ======= 15.1.2 is not up to date (bit numbers) 15.4 does not include protocol errors ======= I guess that's it for the second round... Again, my apologies if any of anything has already been discussed, is already a known issue, or is not relevant, just tell me which ones would be in that case, so I can fill in formal issue templates for the others. Thanks, Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-bof@merit.edu Tue Jun 5 20:16:27 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01958 for ; Tue, 5 Jun 2001 20:16:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3AA40912DD; Tue, 5 Jun 2001 20:16:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6769D912E0; Tue, 5 Jun 2001 20:16:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9D9DA912DD for ; Tue, 5 Jun 2001 20:16:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E2BB85DE03; Tue, 5 Jun 2001 20:16:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 62FFB5DDB6 for ; Tue, 5 Jun 2001 20:16:27 -0400 (EDT) Received: (qmail 13651 invoked by uid 500); 6 Jun 2001 00:05:41 -0000 Date: Tue, 5 Jun 2001 17:05:41 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Cc: aboba@internaut.com Subject: [AAA-WG]: Issue 42: Session-Timeout inconsistent with RADIUS spec Message-ID: <20010605170541.S12278@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu, aboba@internaut.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, This one was previously owned by Bernard, but we have no issue on it, so I've taken it over, below, have questions on what exactly the problem is. PatC ---- Issue 42: Session-Timeout inconsistent with RADIUS spec Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: 2001-06-05 Reference: Document: NASREQ Comment type: C Priority: 1 Section: 3.1.2 and 4.2.2 Rationale/Explanation of issue: At the Interim Meeting, Bernard stated that the use of Session-Timeout in Diameter was inconsistent with RADIUS (RFC 2865). The only difference that I can see is that in RADIUS, the Session-Timeout can be used in an access-challenge (presumably to limit the amount of time a user can respond). If this is the only change required, then the NASREQ AAA and DEA commands would have to be updated. Any other inconsistencies? From owner-aaa-bof@merit.edu Tue Jun 5 20:22:34 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02013 for ; Tue, 5 Jun 2001 20:22:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B7057912E0; Tue, 5 Jun 2001 20:22:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7378D912E2; Tue, 5 Jun 2001 20:22:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3DC58912E0 for ; Tue, 5 Jun 2001 20:22:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 965AC5DDB6; Tue, 5 Jun 2001 20:22:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 599BB5DD99 for ; Tue, 5 Jun 2001 20:22:54 -0400 (EDT) Received: (qmail 13671 invoked by uid 500); 6 Jun 2001 00:12:08 -0000 Date: Tue, 5 Jun 2001 17:12:08 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 37: Home State Blob Message-ID: <20010605171208.T12278@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-bof@merit.edu Precedence: bulk All, I am going through my notes, and I cannot figure out what this issue was all about. Since it was assigned to Paul, and I have yet to receive any text from Paul, I assume that either he also doesn't remember, or it wasn't that important. Does anyone else that was at the interim meeting recall what Issue 37 was all about? PatC From owner-aaa-bof@merit.edu Tue Jun 5 23:58:03 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06925 for ; Tue, 5 Jun 2001 23:58:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6AF88913A5; Tue, 5 Jun 2001 23:58:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3BF33913A6; Tue, 5 Jun 2001 23:58:07 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F1FE5913A5 for ; Tue, 5 Jun 2001 23:58:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 711675DDB4; Tue, 5 Jun 2001 23:58:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by segue.merit.edu (Postfix) with ESMTP id 0B65C5DDAA for ; Tue, 5 Jun 2001 23:58:28 -0400 (EDT) Received: from minotaur.east.isi.edu (minotaur.east.isi.edu [38.218.19.202]) by east.isi.edu (8.11.3/8.9.2) with ESMTP id f563vsK14791; Tue, 5 Jun 2001 23:57:54 -0400 (EDT) Received: from minotaur (mankin@localhost) by minotaur.east.isi.edu (8.11.0/8.11.0) with ESMTP id f563wAR28492; Tue, 5 Jun 2001 23:58:10 -0400 Message-Id: <200106060358.f563wAR28492@minotaur.east.isi.edu> To: Pat Calhoun Cc: aaa-wg@merit.edu Reply-To: mankin@isi.edu Subject: Re: [AAA-WG]: Issue 24: Transport Selection In-reply-to: Your message of Tue, 05 Jun 2001 16:09:37 -0700. <20010605160936.O12278@charizard.diameter.org> Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Date: Tue, 05 Jun 2001 23:58:10 -0400 From: Allison Mankin Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, > > At the Interim Meeting, Bernard stated that the base protocol should > describe how to connect to a peer in the case where more than one > transport is available, or the transport wasn't specified. > > Requested change: > > Add the following text to the end of section 2.1: > When connecting to a peer, and either zero or more transports are > specified, SCTP SHOULD be tried first (if supported), followed by TCP. It'd be useful also to point to the sections showing SRV and URI use for transport selection. > Diameter implementations SHOULD be able to interpret explicit network > notifications (such as ICMP messages) which indicate that a server is > not reachable, rather than relying solely on timeouts (e.g. connect() > returns ECONNREFUSED if the client could not connect to a server at > that address). About ICMP unreachables - destination and host unreachables shouldn't be fed by TCP or SCTP to the application (the reliable transport treats them as probably transient, e.g. a route flap). The ECONNREFUSED example needs a little more precision too, imo. The text could be more like: Diameter implementations SHOULD be able to interpret ICMP protocol and port unreachable messages as explicit indications that the server is not reachable, in addition to interpreting ECONNREFUSED (a reset from the transport) and timed-out connection attempts. Allison From owner-aaa-bof@merit.edu Wed Jun 6 02:54:20 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA21765 for ; Wed, 6 Jun 2001 02:54:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 55C78912E7; Wed, 6 Jun 2001 02:54:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0874A912E8; Wed, 6 Jun 2001 02:54:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B434C912E7 for ; Wed, 6 Jun 2001 02:54:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8A5C95DDD9; Wed, 6 Jun 2001 02:54:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id E73425DD97 for ; Wed, 6 Jun 2001 02:54:34 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id XAA62732; Tue, 5 Jun 2001 23:43:47 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 5 Jun 2001 23:43:47 -0700 (PDT) From: Bernard Aboba To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 29: IPv6 AVPs In-Reply-To: <20010605164453.R12278@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Actually, I think there are two more missing: Framed-IPv6-Pool and Framed-Ipv6-Route. I'll have updated text for these later this week. On Tue, 5 Jun 2001, Pat Calhoun wrote: > All, > > This one was previously owned by Bernard, but we have no issue on it, so I've taken it > over, below, and am proposing text to close this one. > > PatC > ---- > Issue 29: IPv6 AVPs > Submitter name: Pat Calhoun > Submitter email address: pcalhoun@diameter.org > Date first submitted: 2001-06-05 > Reference: > Document: nasreq > Comment type: C > Priority: 1 > Section: 7.2.5 > Rationale/Explanation of issue: > > At the Interim Meeting, Bernard stated that two RADIUS ipv6 > attributes were missing from the NASREQ application, specifically > the Framed-Interface-Id, and the Framed-IPv6-Prefix. > > Proposed Text: > > 7.2.5.4 Framed-Interface-Id AVP > > The Framed-Interface-Id AVP (AVP Code TBD) is of type Unsigned64 and > contains the IPv6 interface identifier to be configured for the user. > It MAY be used in authorization requests as a hint to the server that > a specific interface id is desired, but the server is not required to > honor the hint in the corresponding response. > > > 7.2.5.5 Framed-IPv6-Prefix AVP > > The Framed-Interface-Id AVP (AVP Code TBD) is of type Address and > contains the IPv6 prefix to be configured for the user. It MAY be > used in authorization requests as a hint to the server that a > specific interface id is desired, but the server is not required to > honor the hint in the corresponding response. > From owner-aaa-bof@merit.edu Wed Jun 6 02:56:04 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA21888 for ; Wed, 6 Jun 2001 02:55:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E8F4C912E8; Wed, 6 Jun 2001 02:55:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BA78D913A6; Wed, 6 Jun 2001 02:55:59 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ACA18912E8 for ; Wed, 6 Jun 2001 02:55:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9287D5DD97; Wed, 6 Jun 2001 02:56:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id CF4DF5DDD9 for ; Wed, 6 Jun 2001 02:56:20 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id XAA62739; Tue, 5 Jun 2001 23:45:33 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 5 Jun 2001 23:45:33 -0700 (PDT) From: Bernard Aboba To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Server Discovery In-Reply-To: <20010605154910.M12278@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk I don't think we have to remove SLP support. The text in the SIP-SRV draft specifies how SRV and A records are used in a very detailed way that would be helpful (for example, how caching is done, etc.). I sent along some text that could be gleaned from it that I thought would be useful to insert. On Tue, 5 Jun 2001, Pat Calhoun wrote: > It seems this one fell through the crack :( > > Issue nn: Server Discovery Text to change > Submitter name: Pat Calhoun > Submitter email address: pcalhoun@diameter.org > Date first submitted: 2001-06-05 > Reference: > Document: Base > Comment type: C > Priority: 1 > Section: 2.6 > Rationale/Explanation of issue: > > At the Interim Meeting, Bernard stated that we should adopt the > procedures described in draft-ietf-sip-srv-02.txt. > > Requested change: > > I am not sure what Bernard had in mind. Should we replace the whole > section, including the proposal to use SLPv2, and just use the DNS SRV > proposed in the above draft, or just replace the one section that deals > with DNS SRVs? > > From owner-aaa-bof@merit.edu Wed Jun 6 03:32:25 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA23034 for ; Wed, 6 Jun 2001 03:32:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5E06A913A8; Wed, 6 Jun 2001 03:31:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C1B4B913A7; Wed, 6 Jun 2001 03:31:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3058E913A6 for ; Wed, 6 Jun 2001 03:31:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 19DE65DDD9; Wed, 6 Jun 2001 03:31:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id B26B55DD90 for ; Wed, 6 Jun 2001 03:31:44 -0400 (EDT) Received: from Interlinknetworks.com (hst32135.phys.uu.nl [131.211.32.135]) by aaa.interlinknetworks.com (Postfix) with ESMTP id E2AEA79; Wed, 6 Jun 2001 03:31:34 -0400 (EDT) Message-ID: <3B1D8074.9836F2A5@Interlinknetworks.com> Date: Wed, 06 Jun 2001 02:59:32 +0200 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Proposed fixes for Issues 13, 18 and 30 References: <20010525052346.P30735@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I have a number of editorial comments which I am finally getting a around to documenting. See below. Pat Calhoun wrote: > > All, > > Below is the new text for section 9, which attempts to address the issues > mentioned above. I would appreciate some feedback from folks on whether the > text is consistent with their understanding of the outcome of the Interim > meeting. > > Actual fixes: > > Issue 13: DSI is removed, and a new answer only message is used to report > protocol errors. Protocol errors MAY be treated at each hop. The DSI-Events > are moved to a new class within the Result-Code AVP. > > Issue 18: Error-Reporting-FQDN was a dup of Origin-FQDN, and therefore MUST > only be included if a host is changing the result-code AVP, and is not the > one whose identity is in the Origin-FQDN. > > Issue 30: Failed-AVP should be a grouped AVP, and include the offending AVP > in it's group. > > Thanks, > > PatC > ---- > 9.0 Error Handling >... > > 9.1.3 Protocol Errors >... > > DIAMETER_TOO_BUSY 3005 > When returned, a Diameter node SHOULD attempt to sent the ^^^^ send > message to an alternate peer. >... > > 9.1.5 Permanent Failures >... > > DIAMETER_MISSING_AVP 5006 > The request did not contain an AVP that is required by the > > Calhoun et al. expires October 2001 [Page 45] > > Internet-Draft May 2001 > > Command Code definition. If this value is sent in the Result- > Code AVP, a Failed-AVP AVP SHOULD be included in the message. > The data portion of the Failed-AVP MUST contain an AVP header > containing the AVP Code and vendor-Id. Actually the Failed-AVP AVP MUST contain an example of the missing AVP complete with the Vendor-Id if applicable. The value field of the missing AVP should be of correct minimum length and contain zeroes. >... > > DIAMETER_AVP_NOT_ALLOWED 5009 > A message was received with an AVP that MUST NOT be present. > The Failed-AVP AVP MUST be included and contain the AVP Code of > the offending AVP. The Failed-AVP AVP MUST be included and contain a copy of the offending AVP. > > DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5010 > A message was received that included an AVP that appeared more > often than permitted in the message definition. The Failed-AVP > AVP MUST be included and contain the AVP Code of the offending > AVP. The Failed-AVP AVP MUST be included and contain a copy of the first instance of the offending AVP that exceeded the maximum number of occurrences allowed. > > DIAMETER_VENDOR_ID_UNSUPPORTED 5011 > The Home Diameter server has detected vendor-specific AVPs in > the message, and the vendor dictionary is not supported. One or > more Failed-AVP MUST be present, containing the offending AVPs. I thought this was only an error if the offending AVPs had the M bit set. Otherwise the receiving server should just ignore the offending AVPs. >... > > 9.4 Error-Reporting-Host AVP > > The Error-Reporting-Host AVP (AVP Code 294) is of type OctetString, > encoded in the UTF-8 [24] format, according to the Diameter identity > rules defined in section 2.6. This AVP contains the identity of the > Diameter host that set the Result-Code AVP to a value other than 2001 > (Success), only if the host setting the Result-Code is different from > the one encoded in the Origin-Host AVP. This AVP is intended to be > used for troubleshooting purposes, and MUST be set when the Result- ^^^ sent > Code AVP indicates a failure. >... -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Wed Jun 6 03:32:40 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA23050 for ; Wed, 6 Jun 2001 03:32:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7DE3E913A6; Wed, 6 Jun 2001 03:31:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3467A913AA; Wed, 6 Jun 2001 03:31:28 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 05ED9913A6 for ; Wed, 6 Jun 2001 03:31:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E027F5DDD9; Wed, 6 Jun 2001 03:31:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 9F8B95DD90 for ; Wed, 6 Jun 2001 03:31:46 -0400 (EDT) Received: from Interlinknetworks.com (hst32135.phys.uu.nl [131.211.32.135]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 56C9F7A; Wed, 6 Jun 2001 03:31:37 -0400 (EDT) Message-ID: <3B1DA237.BB24B5E4@Interlinknetworks.com> Date: Wed, 06 Jun 2001 05:23:35 +0200 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Funk Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Boot-Id References: <4.1.20010527212341.01cc9560@cairo.funk.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Please note the editorial change offered below. Paul Funk wrote: > > Submitter name: Paul Funk > Submitter email address: paul@funk.com > Date first submitted: May, 20001 > Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00135.html > Document: Base > Comment Type: Technical > Priority: 1 or 2 (?) > Section: Somewhere in section 6 > Rationale/Explanation of issue: > Servers need to know if a NAS has rebooted, to be able to > clean up state. A new connection is not necessarily and > indication of reboot, since it could be a reconnect after a > connection was broken. > > Requested change: > > The interim group felt that, of the three proposals in the foot-fetish > thread, Paul's and Pat's should be adopted. Briefly, a Boot-Id is passed > in DRI to allow a server to determine when a peer has rebooted, and > Boot-Id is also passed in other messages, to allow downstream > servers more than one hop away to glean this information. > > Randy suggested that the name of the AVP be changed from Boot-Id to > State-Id, since a server may retain state across reboots. Therefore, > a new id is really indicative of fresh state. I suggest we in fact > call it Origin-State-Id, to emphasize its relationship to Origin-FQDN. > > Origin-State-Id will have to be added to the ABNF for DRI as well as all > other messages, as an optional AVP. > > Suggested language: > > [add the following somewhere in the DRI section:] > > Origin-State-Id AVP > > The Origin-State-Id AVP (AVP Code ?), of type Unsigned32, is a > monotonically increasing value that is advanced whenever a Diameter > entity restarts with loss of previous state, for example upon reboot. > Origin-State-Id MAY be included in any Diameter message, including > DRI. > > A Diameter entity issuing this AVP MUST create a higher value for > this AVP each time its state is reset. A Diameter entity MAY set > Origin-State-Id to the time of startup, or it MAY use an incrementing > counter retained in non-volatile memory across restarts. > > The Origin-State-Id, if present, MUST reflect the state of the > entity indicated by Origin-FQDN. If a proxy modifies Origin-FQDN, > it MUST either remove Origin-State-Id or modify it appropriately as > well. > > Typically, Origin-State-Id is used by an access device that always > starts up with no active sessions; that is, any session active prior > to restart will have been been lost. By including Origin-State-Id in > a message, it allows other Diameter entities to infer that sessions > associated with a lower Origin-State-Id are no longer active. If an > access device does not intend for such inferences to be made, it > MUST either not include Origin-FQDN in any message, or set its value ^^^^^^^^^^^ ==========> Origin-State-Id > to 0. > > [add the following to the Session Termination section:] > > 10.10 Inferring Session Termination from Origin-State-Id > > Origin-State-Id is used to allow rapid detection of terminated > sessions for which no STR would have been issued, due to unanticipated > shutdown of an access device. > > By including Origin-State-Id in DRI messages, an access device allows > a next-hop server to determine immediately upon connection whether the > device has lost its sessions since the last connection. > > By including Origin-State-Id in request messages, an access device > also allows a server with which it communicates via proxy to make > such a determination. However, a server that is not directly connected > with the access device will not discover that the access device has > been restarted unless and until it receives a new request from the > access device. Thus, use of this mechanism across proxies is > opportunistic rather than reliable, but useful nonetheless. > > When a Diameter server receives a Origin-State-Id that is greater > than the Origin-State-Id previously received from the same issuer, > it may assume that the issuer has lost state since the previous > message and that all sessions that were active under the lower > Origin-State-Id have been terminated. The Diameter server MAY clean > up all session state associated with such lost sessions, and MAY also > issues STRs for all such lost sessions that were authorized on > downstream servers, to allow session state to be cleaned up globally. > > Paul > > Paul Funk > Funk Software, Inc. > 617 497-6339 > paul@funk.com -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Wed Jun 6 05:04:20 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA24040 for ; Wed, 6 Jun 2001 05:04:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 45A72913A7; Wed, 6 Jun 2001 05:04:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 025BE913AA; Wed, 6 Jun 2001 05:04:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CCBAC913A7 for ; Wed, 6 Jun 2001 05:04:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CCD2B5DE00; Wed, 6 Jun 2001 05:04:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 2355E5DDEE for ; Wed, 6 Jun 2001 05:04:40 -0400 (EDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f5694Ym04722 for ; Wed, 6 Jun 2001 12:04:34 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 6 Jun 2001 12:04:21 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Wed, 6 Jun 2001 12:03:51 +0300 Message-ID: <6D1A8E7871B9D211B3B00008C7490AA504E626C0@treis03nok> From: henry.haverinen@nokia.com To: pcalhoun@diameter.org, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue #51: EAP Roundtrips Date: Wed, 6 Jun 2001 12:03:43 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk > From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] > I'd like to get some discussion started on issue 51. My > interpretation of Bernard's > comments on this particular issues, which may be found at > http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00340.html > is that this isn't > something that we can really fix in Diameter. I agree with Bernard's comments -- there are murky areas in the Radius extensions document (RFC 2869), and ambiguities in the EAP specification (RFC 2284). #51 is trying to address one specific problem: EAP-Success cannot contain any data, and even if it could, it is never re-transmitted so problems would arise if it was lost. So we need to transmit all data to the client in EAP-Requests, which quite often results in an unnecessary NAS-AAA-NAS roundtrip. I still believe that the message sequences in my e-mail available at the URL below would be feasible in Diameter. This wouldn't fix all the issues Bernard identified, but this would save a roundtrip without requiring any changes to RFC 2284 or current PPP client implementations. http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00347.html Regards, Henry From owner-aaa-bof@merit.edu Wed Jun 6 05:05:57 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA24078 for ; Wed, 6 Jun 2001 05:05:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 15239913AA; Wed, 6 Jun 2001 05:05:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CA233913AD; Wed, 6 Jun 2001 05:05:57 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A85DF913AA for ; Wed, 6 Jun 2001 05:05:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BB41B5DE00; Wed, 6 Jun 2001 05:06:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id C45B85DDEE for ; Wed, 6 Jun 2001 05:06:18 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f56960O10901; Wed, 6 Jun 2001 11:06:00 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f56960523239; Wed, 6 Jun 2001 12:06:00 +0300 (EET DST) Message-ID: <3B1DF277.1CDC16F2@lmf.ericsson.se> Date: Wed, 06 Jun 2001 12:05:59 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 60: E2E cert names References: <20010605071737.G22616@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun wrote: > My understanding of the cert names was that by adding the -diameter in the > cert name, it became obvious that this cert was useful ONLY for Diameter, not > for anything else. Yes. Well, to be exact, this is obvious only to humans with a brain; not necessarily to mindless machines executing PKI operations. For instance, a Netscape browser would propably happily accept a name like foo-diameter@org.com since the knowledge of the naming rules exists only within Diameter implementations, not elsewhere. Therefore, what this spec really means that is that a Diameter client doesn't by accident accept the certificate of the ISP's web server even if the web server and the AAA server use the same CA. But a web client could accept the AAA server's certificate. I suppose the spec is fine; having a specific naming in the certificates shouldn't be that much of an issue and it does buy _some_ level of additional ease as the same CA can be used for different purposes. The only drawback is that in some cases additional certificates may have to be manufactured for a node, for instance to support VPN layer and application layer authentication, and Diameter. However, since currently we don't have similar naming constraints on other areas it could still be that e.g. a SIP proxy would use a Diameter certificate with the name "proxy-diameter@telco.com" in Diameter, IPsec, and SIP layer operations. Jari From owner-aaa-bof@merit.edu Wed Jun 6 09:43:21 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00577 for ; Wed, 6 Jun 2001 09:43:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CB67D912F3; Wed, 6 Jun 2001 09:43:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9ADCA913AF; Wed, 6 Jun 2001 09:43:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 82E20912F3 for ; Wed, 6 Jun 2001 09:43:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C30E65DDEA; Wed, 6 Jun 2001 09:43:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 4311E5DDA3 for ; Wed, 6 Jun 2001 09:43:44 -0400 (EDT) Received: (qmail 18037 invoked by uid 500); 6 Jun 2001 13:32:55 -0000 Date: Wed, 6 Jun 2001 06:32:55 -0700 From: Pat Calhoun To: Bernard Aboba Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Server Discovery Message-ID: <20010606063255.X12278@charizard.diameter.org> Mail-Followup-To: Bernard Aboba , Pat Calhoun , aaa-wg@merit.edu References: <20010605154910.M12278@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from aboba@internaut.com on Tue, Jun 05, 2001 at 11:45:33PM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Tue, Jun 05, 2001 at 11:45:33PM -0700, Bernard Aboba wrote: > I don't think we have to remove SLP support. The text in the SIP-SRV draft > specifies how SRV and A records are used in a very detailed way that would > be helpful (for example, how caching is done, etc.). I sent along some > text that could be gleaned from it that I thought would be useful to > insert. Good, that's my preference too. I will take care of this one today. Thanks, PatC From owner-aaa-bof@merit.edu Wed Jun 6 09:46:21 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00694 for ; Wed, 6 Jun 2001 09:46:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 46B41913AF; Wed, 6 Jun 2001 09:46:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D2F13913B0; Wed, 6 Jun 2001 09:46:00 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AB402913AF for ; Wed, 6 Jun 2001 09:45:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0B2A45DDC9; Wed, 6 Jun 2001 09:46:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 7E2425DDA3 for ; Wed, 6 Jun 2001 09:46:22 -0400 (EDT) Received: (qmail 18054 invoked by uid 500); 6 Jun 2001 13:35:34 -0000 Date: Wed, 6 Jun 2001 06:35:34 -0700 From: Pat Calhoun To: Allison Mankin Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 24: Transport Selection Message-ID: <20010606063534.Y12278@charizard.diameter.org> Mail-Followup-To: Allison Mankin , Pat Calhoun , aaa-wg@merit.edu References: <20010605160936.O12278@charizard.diameter.org> <200106060358.f563wAR28492@minotaur.east.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106060358.f563wAR28492@minotaur.east.isi.edu>; from mankin@isi.edu on Tue, Jun 05, 2001 at 11:58:10PM -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Tue, Jun 05, 2001 at 11:58:10PM -0400, Allison Mankin wrote: > The text could be more like: > > Diameter implementations SHOULD be > able to interpret ICMP protocol and port unreachable messages as > explicit indications that the server is not reachable, in addition > to interpreting ECONNREFUSED (a reset from the transport) > and timed-out connection attempts. Great! Thanks for the text. PatC From owner-aaa-bof@merit.edu Wed Jun 6 09:52:02 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00870 for ; Wed, 6 Jun 2001 09:52:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F0281912EE; Wed, 6 Jun 2001 09:51:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BD8D5912EF; Wed, 6 Jun 2001 09:51:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A38A4912EE for ; Wed, 6 Jun 2001 09:51:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 192695DDEA; Wed, 6 Jun 2001 09:52:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id BCA6A5DDC9 for ; Wed, 6 Jun 2001 09:52:16 -0400 (EDT) Received: (qmail 18075 invoked by uid 500); 6 Jun 2001 13:41:28 -0000 Date: Wed, 6 Jun 2001 06:41:28 -0700 From: Pat Calhoun To: Jari Arkko Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 60: E2E cert names Message-ID: <20010606064128.Z12278@charizard.diameter.org> Mail-Followup-To: Jari Arkko , Pat Calhoun , aaa-wg@merit.edu References: <20010605071737.G22616@charizard.diameter.org> <3B1DF277.1CDC16F2@lmf.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B1DF277.1CDC16F2@lmf.ericsson.se>; from Jari.Arkko@lmf.ericsson.se on Wed, Jun 06, 2001 at 12:05:59PM +0300 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Wed, Jun 06, 2001 at 12:05:59PM +0300, Jari Arkko wrote: > Pat Calhoun wrote: > > > My understanding of the cert names was that by adding the -diameter in the > > cert name, it became obvious that this cert was useful ONLY for Diameter, not > > for anything else. > > Yes. Well, to be exact, this is obvious only to humans with > a brain; not necessarily to mindless machines executing PKI > operations. For instance, a Netscape browser would propably > happily accept a name like foo-diameter@org.com since the > knowledge of the naming rules exists only within Diameter > implementations, not elsewhere. Therefore, what this spec > really means that is that a Diameter client doesn't by > accident accept the certificate of the ISP's web server > even if the web server and the AAA server use the same > CA. But a web client could accept the AAA server's > certificate. > > I suppose the spec is fine; having a specific naming in the > certificates shouldn't be that much of an issue and it > does buy _some_ level of additional ease as the same CA > can be used for different purposes. The only drawback is > that in some cases additional certificates may have to > be manufactured for a node, for instance to support VPN > layer and application layer authentication, and Diameter. > However, since currently we don't have similar naming > constraints on other areas it could still be that e.g. > a SIP proxy would use a Diameter certificate with the > name "proxy-diameter@telco.com" in Diameter, IPsec, and > SIP layer operations. > Perhaps Stephen has a response to your comment... PatC From owner-aaa-bof@merit.edu Wed Jun 6 10:00:02 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01095 for ; Wed, 6 Jun 2001 10:00:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AD521912EF; Wed, 6 Jun 2001 09:59:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 80DDC912F4; Wed, 6 Jun 2001 09:59:59 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 64C7B912EF for ; Wed, 6 Jun 2001 09:59:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D0BF65DDD6; Wed, 6 Jun 2001 10:00:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 507D85DDC9 for ; Wed, 6 Jun 2001 10:00:21 -0400 (EDT) Received: (qmail 18100 invoked by uid 500); 6 Jun 2001 13:49:33 -0000 Date: Wed, 6 Jun 2001 06:49:33 -0700 From: Pat Calhoun To: David Spence Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Proposed fixes for Issues 13, 18 and 30 Message-ID: <20010606064933.B12278@charizard.diameter.org> Mail-Followup-To: David Spence , Pat Calhoun , aaa-wg@merit.edu References: <20010525052346.P30735@charizard.diameter.org> <3B1D8074.9836F2A5@Interlinknetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B1D8074.9836F2A5@Interlinknetworks.com>; from DSpence@Interlinknetworks.com on Wed, Jun 06, 2001 at 02:59:32AM +0200 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Wed, Jun 06, 2001 at 02:59:32AM +0200, David Spence wrote: > I have a number of editorial comments which I am finally getting a around to > documenting. See below. Thanks for catching these errors. See below... > > DIAMETER_VENDOR_ID_UNSUPPORTED 5011 > > The Home Diameter server has detected vendor-specific AVPs in > > the message, and the vendor dictionary is not supported. One or > > more Failed-AVP MUST be present, containing the offending AVPs. > > I thought this was only an error if the offending AVPs had the M bit set. > Otherwise the receiving server should just ignore the offending AVPs. hmmmm... I believe that you are correct, and this Result-Code is therefore no longer necessary. PatC From owner-aaa-bof@merit.edu Wed Jun 6 10:03:01 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01221 for ; Wed, 6 Jun 2001 10:03:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 38CFA912F4; Wed, 6 Jun 2001 10:02:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 12916912F5; Wed, 6 Jun 2001 10:02:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F09E4912F4 for ; Wed, 6 Jun 2001 10:02:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5D2545DDA3; Wed, 6 Jun 2001 10:02:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 01E595DDC9 for ; Wed, 6 Jun 2001 10:02:38 -0400 (EDT) Received: from fredrikj (sierra.local.ipunplugged.com [192.168.4.88]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id QAA26320; Wed, 6 Jun 2001 16:04:11 +0200 From: "Fredrik Johansson" To: "Pat Calhoun" , Subject: RE: [AAA-WG]: Issue 20: How to handle no common extensions Date: Wed, 6 Jun 2001 16:03:56 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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) In-Reply-To: <20010605161816.Q12278@charizard.diameter.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Perhaps it should be stated that a node that advertise a wildcard should keep the connection. /Fredrik >-----Original Message----- >From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf >Of Pat Calhoun >Sent: den 6 juni 2001 01:18 >To: aaa-wg@merit.edu >Subject: [AAA-WG]: Issue 20: How to handle no common extensions > > >All, > >This one was previously owned by Paul, but we have no issue on it, >so I've taken it >over, below, and am proposing text to close this one. > >PatC >---- >Issue 20: How to handle no common extensions >Submitter name: Pat Calhoun >Submitter email address: pcalhoun@diameter.org >Date first submitted: 2001-06-05 >Reference: >Document: Base >Comment type: C >Priority: 1 >Section: 2.1 >Rationale/Explanation of issue: > >At the Interim meeting there were discussions on how to handle the >case where two peers connect, and realize that they have no common >applications (was extensions). My take on this is that they should >disconnect, since there will not be any further protocol exchanges, >but Paul preferred that they stay in communication. > > >Requested change: > >None. Section 6.0 in the -06 draft currently states: > >" A receiver of a Capabilities-Exchange-Req message which does >not have any > applications in common with the sender MUST return a > Capabilities-Exchange-Answer with the Result-Code AVP set to > DIAMETER_NO_COMMON_APPLICATION, and SHOULD disconnect the >transport layer > connection." From owner-aaa-bof@merit.edu Wed Jun 6 10:06:11 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01308 for ; Wed, 6 Jun 2001 10:06:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5D4A7912F5; Wed, 6 Jun 2001 10:06:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2EB6D913B0; Wed, 6 Jun 2001 10:06:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0268C912F5 for ; Wed, 6 Jun 2001 10:06:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 612855DDC9; Wed, 6 Jun 2001 10:06:26 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id EEFA35DDA3 for ; Wed, 6 Jun 2001 10:06:25 -0400 (EDT) Received: (qmail 18137 invoked by uid 500); 6 Jun 2001 13:55:37 -0000 Date: Wed, 6 Jun 2001 06:55:37 -0700 From: Pat Calhoun To: David Spence Cc: Paul Funk , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Boot-Id Message-ID: <20010606065537.C12278@charizard.diameter.org> Mail-Followup-To: David Spence , Paul Funk , aaa-wg@merit.edu References: <4.1.20010527212341.01cc9560@cairo.funk.com> <3B1DA237.BB24B5E4@Interlinknetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B1DA237.BB24B5E4@Interlinknetworks.com>; from DSpence@Interlinknetworks.com on Wed, Jun 06, 2001 at 05:23:35AM +0200 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Wed, Jun 06, 2001 at 05:23:35AM +0200, David Spence wrote: > Please note the editorial change offered below. I had already fixed this in -05 :) PatC > > Paul Funk wrote: > > > > Submitter name: Paul Funk > > Submitter email address: paul@funk.com > > Date first submitted: May, 20001 > > Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00135.html > > Document: Base > > Comment Type: Technical > > Priority: 1 or 2 (?) > > Section: Somewhere in section 6 > > Rationale/Explanation of issue: > > Servers need to know if a NAS has rebooted, to be able to > > clean up state. A new connection is not necessarily and > > indication of reboot, since it could be a reconnect after a > > connection was broken. > > > > Requested change: > > > > The interim group felt that, of the three proposals in the foot-fetish > > thread, Paul's and Pat's should be adopted. Briefly, a Boot-Id is passed > > in DRI to allow a server to determine when a peer has rebooted, and > > Boot-Id is also passed in other messages, to allow downstream > > servers more than one hop away to glean this information. > > > > Randy suggested that the name of the AVP be changed from Boot-Id to > > State-Id, since a server may retain state across reboots. Therefore, > > a new id is really indicative of fresh state. I suggest we in fact > > call it Origin-State-Id, to emphasize its relationship to Origin-FQDN. > > > > Origin-State-Id will have to be added to the ABNF for DRI as well as all > > other messages, as an optional AVP. > > > > Suggested language: > > > > [add the following somewhere in the DRI section:] > > > > Origin-State-Id AVP > > > > The Origin-State-Id AVP (AVP Code ?), of type Unsigned32, is a > > monotonically increasing value that is advanced whenever a Diameter > > entity restarts with loss of previous state, for example upon reboot. > > Origin-State-Id MAY be included in any Diameter message, including > > DRI. > > > > A Diameter entity issuing this AVP MUST create a higher value for > > this AVP each time its state is reset. A Diameter entity MAY set > > Origin-State-Id to the time of startup, or it MAY use an incrementing > > counter retained in non-volatile memory across restarts. > > > > The Origin-State-Id, if present, MUST reflect the state of the > > entity indicated by Origin-FQDN. If a proxy modifies Origin-FQDN, > > it MUST either remove Origin-State-Id or modify it appropriately as > > well. > > > > Typically, Origin-State-Id is used by an access device that always > > starts up with no active sessions; that is, any session active prior > > to restart will have been been lost. By including Origin-State-Id in > > a message, it allows other Diameter entities to infer that sessions > > associated with a lower Origin-State-Id are no longer active. If an > > access device does not intend for such inferences to be made, it > > MUST either not include Origin-FQDN in any message, or set its value > ^^^^^^^^^^^ > ==========> Origin-State-Id > > > to 0. > > > > [add the following to the Session Termination section:] > > > > 10.10 Inferring Session Termination from Origin-State-Id > > > > Origin-State-Id is used to allow rapid detection of terminated > > sessions for which no STR would have been issued, due to unanticipated > > shutdown of an access device. > > > > By including Origin-State-Id in DRI messages, an access device allows > > a next-hop server to determine immediately upon connection whether the > > device has lost its sessions since the last connection. > > > > By including Origin-State-Id in request messages, an access device > > also allows a server with which it communicates via proxy to make > > such a determination. However, a server that is not directly connected > > with the access device will not discover that the access device has > > been restarted unless and until it receives a new request from the > > access device. Thus, use of this mechanism across proxies is > > opportunistic rather than reliable, but useful nonetheless. > > > > When a Diameter server receives a Origin-State-Id that is greater > > than the Origin-State-Id previously received from the same issuer, > > it may assume that the issuer has lost state since the previous > > message and that all sessions that were active under the lower > > Origin-State-Id have been terminated. The Diameter server MAY clean > > up all session state associated with such lost sessions, and MAY also > > issues STRs for all such lost sessions that were authorized on > > downstream servers, to allow session state to be cleaned up globally. > > > > Paul > > > > Paul Funk > > Funk Software, Inc. > > 617 497-6339 > > paul@funk.com > > -- > David Spence email: DSpence@Interlinknetworks.com > Interlink Networks, Inc. phone: (734) 821-1203 > 775 Technology Drive, Suite 200 fax: (734) 821-1235 > Ann Arbor, MI 48108 > U.S.A. > From owner-aaa-bof@merit.edu Wed Jun 6 10:40:23 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02252 for ; Wed, 6 Jun 2001 10:40:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9A0AA913B2; Wed, 6 Jun 2001 10:40:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 60DE1913B3; Wed, 6 Jun 2001 10:40:07 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3D2FB913B2 for ; Wed, 6 Jun 2001 10:40:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BC1245DDC9; Wed, 6 Jun 2001 10:40:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 8A53D5DD90 for ; Wed, 6 Jun 2001 10:40:28 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA02130; Wed, 6 Jun 2001 10:39:27 -0400 (EDT) Date: Wed, 6 Jun 2001 10:39:47 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: Cain Brian-BCAIN1 Cc: Pat Calhoun , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Support for multi-process In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B0ECF1B@IL27EXM10.cig.mot.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Brian, > Looks good so far. My only recommendation is non-technical > -> call the Win/Lose Election events something more in line > with their description, something like "Existing-Conn-Win" > and "New-Conn-Win", maybe? I changed it to be Peer-Wins and Local-Wins and changed the description wording. In changing that, I found that I had a part of the election process backwards. The diffs between my original proposal and the corrected one summarize the entire process and are listed below. Could you give your O.K. on those? I have included the changed text below the diffs. -mark --- 1,3 ---- *************** *** 88,96 **** I-Wait-Lock Locked Elect I-Wait-Returns I-Wait-Returns No-Contest Elect-Unlock Open ! Win-Election Elect-Unlock/ Open R-Disc ! Lose-Election Elect-Unlock/ Open I-Disc R-Wait-DRR Rcv-DRR Elect-Lock, R-Wait-Lock --- 63,71 ---- I-Wait-Lock Locked Elect I-Wait-Returns I-Wait-Returns No-Contest Elect-Unlock Open ! Local-Wins Elect-Unlock/ Open R-Disc ! Peer-Wins Elect-Unlock/ Open I-Disc R-Wait-DRR Rcv-DRR Elect-Lock, R-Wait-Lock *************** *** 100,109 **** R-Wait-Lock Locked Elect R-Wait-Returns R-Wait-Returns No-Contest Elect-Unlock Open ! Win-Election Snd-DRA/ Open Elect-Unlock/ I-Disc ! Lose-Election Elect-Unlock/ Open Snd-DRA-Exist Not-Allowed Elect-Unlock/ Closed Snd-DRA-Fail --- 75,84 ---- R-Wait-Lock Locked Elect R-Wait-Returns R-Wait-Returns No-Contest Elect-Unlock Open ! Peer-Wins Snd-DRA/ Open Elect-Unlock/ I-Disc ! Local-Wins Elect-Unlock/ Open Snd-DRA-Exist Not-Allowed Elect-Unlock/ Closed Snd-DRA-Fail *************** *** 184,194 **** No-Contest An election was held, and there was only one connection to this peer. ! Win-Election An election was held, and the new connection to ! the peer was the winner. ! Lose-Election An election was held, and the existing connection to ! the peer was the winner. Not-Allowed Before the election was held, it was determined that the peer was not allowed. --- 159,169 ---- No-Contest An election was held, and there was only one connection to this peer. ! Local-Wins An election was held, and the connection initiated ! locally wins. ! Peer-Wins An election was held, and the connection initiated by ! the peer wins. Not-Allowed Before the election was held, it was determined that the peer was not allowed. *************** *** 289,295 **** shorter OctetString to be null-padded to the length of the longer, then performing an octet by octet unsigned comparison with the first octet being most significant. If the peer is the victor, ! Lose-Election is returned otherwise Win-Election is returned. 8.5 Most Common State Transitions --- 264,270 ---- shorter OctetString to be null-padded to the length of the longer, then performing an octet by octet unsigned comparison with the first octet being most significant. If the peer is the victor, ! Peer-Wins is returned otherwise Local-Wins is returned. 8.5 Most Common State Transitions ******************* New Proposed Text ******************* 8.0 Peer State Machine This section contains a finite state machine, that MUST be observed by all Diameter implementations. Each Diameter node MUST follow the state machine described below when communicating with each peer. Multiple actions are separated by commas, and may continue on succeeding lines as space requires. Similarly, state and next state may also span multiple lines as space requires. There may be at most one transport connection between any two peers over which Diameter messages may be passed. This state machine is intended to handle both the simple case, in which one peer initiates a connection to the other, and the complex case, in which each peer simultaneously initiates a connection to the other. In the complex case, an election occurs to determine which transport connection will survive. I- is used to represent the initiator (connecting) connection, while the R- is used to represent the responder (listening) connection. The lack of a prefix indicates that the event or action is the same regardless of the connection on which the event occurred. The stable states that a state machine may be in are Closed, and Open; all other states are intermediate. The DRR is always sent by the initiator immediately after a connection establishment. After the election, the responder sends a DRA. This DRA will contain either a Result-Code AVP of DIAMETER_SUCCESS, DIAMETER_SESSION_DENIED or DIAMETER_SESSION_EXISTS. If the result is DIAMETER_SESSION_DENIED or DIAMETER_SESSION_EXISTS, the receiver of the DRA MUST close the connection. Since the identity of the peer is not known until either a DRR or DRA is received, it is possible for two connections to be briefly established. This is why there is an election process for both the initiator and the responder. This also means that each program may only have one election at a time. This is the reason for the *-Wait-Lock state. The state machine constrains only the behavior of a Diameter implementation as seen by Diameter peers through events on the wire. Any implementation that produces equivalent results is considered compliant. state event action next state ----------------------------------------------------------------- Closed Start Snd-Conn-Req I-Wait-Conn-Ack Rcv-Conn-Req Snd-Conn-Ack R-Wait-DRR I-Wait-Conn-Ack Rcv-Conn-Ack Snd-DRR I-Wait-DRA Rcv-Conn-Nack Cleanup Closed Timeout Error Closed I-Wait-DRA Rcv-DRA Elect-Lock I-Wait-Lock Rcv-DRA-Exist I-Disc Open Rcv-DRA-Fail I-Disc Closed Peer-Disc Error Closed Timeout Error Closed I-Wait-Lock Locked Elect I-Wait-Returns I-Wait-Returns No-Contest Elect-Unlock Open Local-Wins Elect-Unlock/ Open R-Disc Peer-Wins Elect-Unlock/ Open I-Disc R-Wait-DRR Rcv-DRR Elect-Lock, R-Wait-Lock Timeout Error Closed Rcv-Conn-Disc Error Closed R-Wait-Lock Locked Elect R-Wait-Returns R-Wait-Returns No-Contest Elect-Unlock Open Peer-Wins Snd-DRA/ Open Elect-Unlock/ I-Disc Local-Wins Elect-Unlock/ Open Snd-DRA-Exist Not-Allowed Elect-Unlock/ Closed Snd-DRA-Fail Open Send-Message Snd-Non-DRI Open Rcv-Non-DRI Process Open WatchDog-Timer Snd-DWR Open Rcv-DWA Process-DWA Open Stop Disc Closed Peer-Disc Disc Closed Rcv-DRR Error Closed 8.1 States Following is a more detailed description of each automaton state. Closed A peer is initially in the closed state, and no transport connection exists with the peer. I-Wait-Conn-Ack A transport connection has been initiated with the peer, and an acknowledgment is pending. I-Wait-DRA The local Diameter node is waiting for the peer to issue a DRA. I-Wait-Lock The initiator is waiting for an election lock. I-Wait-Returns The initiator is waiting on the results of the election returns. R-Wait-DRR A transport connection indication has been received from the peer, and a DRR has yet to be received by the peer. R-Wait-Lock The responder is waiting for an election lock. R-Wait-Returns The responder is waiting on the results of the election returns. Open The peer connection is open. 8.2 Events Transitions and actions in the automaton are caused by events. Start The Diameter application has signaled that a connection should be initiated with the peer. Rcv-Conn-Req A transport connection indication from the peer has been received. Rcv-Conn-Ack A positive acknowledgment was received to a locally initiated transport connection. Rcv-Conn-Nack A negative acknowledgment was received to a locally initiated transport connection. Timeout An application-defined timer has expired while waiting for some event. Rcv-DRA A DRA message from the peer was received. Rcv-DRA-Exist A DRA failure of DIAMETER_SESSION_EXISTS was received. Rcv-DRA-Fail A DRA failure of DIAMETER_SESSION_DENIED was received. Rcv-DRR A DRR message from the peer was received. Peer-Disc A disconnection indication from the peer was received. Locked The election locking mechanism succeeded. No-Contest An election was held, and there was only one connection to this peer. Local-Wins An election was held, and the connection initiated locally wins. Peer-Wins An election was held, and the connection initiated by the peer wins. Not-Allowed Before the election was held, it was determined that the peer was not allowed. Send-Message A Non-DRI message is to be sent. Rcv-Non-DRI A Non-DRI message was received. WatchDog-Timer The Watchdog timer expired, indicating that a DWR message is to be sent to the peer. Rcv-DWA A DWA message was received. Stop The Diameter application has signaled that a connection should be terminated (e.g., on system shutdown). 8.3 Actions Actions in the automaton are caused by events and typically indicate the transmission of packets and/or an action to be taken on the connection. Snd-Conn-Req A transport connection is initiated with the peer. Snd-Conn-Ack an acknowledgment is sent in response to a connect request, confirming that the transport layer connection is open. Snd-Conn-Nack A negative acknowledgment is sent in response to a connect request, indicating that the request was refused. Snd-DRR A DRR message is sent to the peer. Snd-DRA A DRA message is sent to the peer. Cleanup If necessary, the connection is shutdown, and any local resources are freed. Error The transport layer connection is disconnected, either politely or abortively, in response to an error condition. Local resources are freed. Process-DRI A received DRI is processed. Disc The transport layer connection is disconnected, and local resources are freed. I-Disc When two connections exist to the same peer, disconnect the connection to the initiator. R-Disc When two connections exist to the same peer, disconnect the transport connection of the responder. Elect An election occurs (see Section 8.4 for more information). Elect-Lock Block any other elections from happening. If the election can happen in multiple threads, some form of locking is needed. If it can only happen in one thread, no action is needed. Elect-Unlock If election can happen in multiple threads, the remove the lock gotten from Elect-Lock. Error Report an error and do cleanup. Snd-DRA Send a DRA with a Result-Code AVP of DIAMETER_SUCCESS. Snd-DRA-Exist Send a DRA with a Result-Code AVP of DIAMETER_SESSION_EXISTS. Snd-DRA-Fail Send a DRA with a Result-Code AVP of DIAMETER_SESSION_DENIED. Snd-Non-DRI A non-DRI message is sent. Snd-DWR A DWR message is sent. Process-DWA The DWA message is serviced. Process A non-DRI Diameter message is serviced. 8.4 The Election Process The election is performed after receipt of either a DRR or a DRA. If this is the receipt of a DRR and the peer is not allowed to connect, a result of Not-Allowed is returned. If the Origin-FQDN received in the DRR/DRA is not a peer that already has an open connection, No-Contest is returned. Otherwise, there is a comparison of the the Origin-FQDN sent by its peer with its own Origin-FQDN (which it may or may not have actually sent). The transport layer connection with the higher value of Origin-FQDN is the one that survives. The comparison proceeds by considering the shorter OctetString to be null-padded to the length of the longer, then performing an octet by octet unsigned comparison with the first octet being most significant. If the peer is the victor, Peer-Wins is returned otherwise Local-Wins is returned. 8.5 Most Common State Transitions Below is a drawing of the most common state transitions where either a connection initiated (left) or requested (right) and the connection is made with no problems. States are boxed. Events are plain text. Actions are in parenthesis. All states are shown in this drawing but several events not show. +------+ |Closed| +------+ | | +-----------+ +-----------+ | | Start Rcv-Conn-Req | | (Snd-Conn-Req) (Snd-Conn-Ack) | | +---------------+ | |I-Wait-Conn-Ack| | +---------------+ | | | Rec-Conn-Ack | | | (Snd-DRR) | | | +----------+ +----------+ |I-Wait-DRA| |R-Wait-DRR| +----------+ +----------+ | | Rcv-DRA Rcv-DRR | | (Elect-Lock) (Elect-Lock) | | +-----------+ +-----------+ |I-Wait-Lock| |R-Wait-Lock| +-----------+ +-----------+ | | Locked Locked | | (Elect) (Elect) | | +--------------+ +--------------+ |I-Wait-Returns| |R-Wait-Returns| +--------------+ +--------------+ | | No-Contest No-Contest | | (Elect-Unlock) (Snd-DRA/Elect-Unlock) | | +-----------+ +-----------+ | | +----+ |OPEN| +----+ From owner-aaa-bof@merit.edu Wed Jun 6 11:23:50 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02910 for ; Wed, 6 Jun 2001 11:23:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A40B0912F8; Wed, 6 Jun 2001 11:23:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7186E912FD; Wed, 6 Jun 2001 11:23:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 59773912F8 for ; Wed, 6 Jun 2001 11:23:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D6B405DE0C; Wed, 6 Jun 2001 11:24:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (unknown [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id C78985DDC9 for ; Wed, 6 Jun 2001 11:24:14 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA02474; Wed, 6 Jun 2001 11:23:47 -0400 (EDT) Date: Wed, 6 Jun 2001 11:24:07 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: aaa-wg@merit.edu Cc: Patrice Calhoun , Bernard Aboba , Dave Mitton Subject: [AAA-WG]: [issue] Address Name and 20 byte IPV6 length. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Submitter name: Mark Eklund Submitter email address: meklund@cisco.com Date first submitted: 06-Jun-2001 Reference: http://www.ietf.org/rfc/rfc2851.txt Document: Base Comment type: T Priority: 2 Section: 4.3 AVP Data Formats Rationale/Explanation of issue: Juergen Schoenwaelder suggested that we may want to look into two related issues for the Address data format. 1. We may want to change the name to IpAddress to make it clearer that this is restricted to IP addresses. 2. RFC 2851 also has a 20 byte IPv6 addresses. We may consider allowing a 20 byte address. Both of these issues need to be at least addressed (no pun intended) on the mailing list. Requested change: 1. I don't care either way if it is Address or IpAddress. I would suggest it be IPAddress (capital P) if it is changed. This is just because if we are capitalizing first letters of words, I consider acronyms to be multiple words. 2. As far as I can tell, the extra four bytes in the 20 byte IPv6 address is to identify which interface the address is associated with if more than one interface has an address. Since we never did this for RADIUS and IPv4, I don't suggest we do it for IPv6. ==================================================================== From owner-aaa-bof@merit.edu Wed Jun 6 12:45:12 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05060 for ; Wed, 6 Jun 2001 12:45:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 958B0913D6; Wed, 6 Jun 2001 12:42:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 626EB913CE; Wed, 6 Jun 2001 12:42:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1F820913BA for ; Wed, 6 Jun 2001 12:41:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C64935DE01; Wed, 6 Jun 2001 12:41:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 6E4A05DDAD for ; Wed, 6 Jun 2001 12:41:23 -0400 (EDT) Received: (qmail 19016 invoked by uid 500); 6 Jun 2001 16:30:34 -0000 Date: Wed, 6 Jun 2001 09:30:34 -0700 From: Pat Calhoun To: Bernard Aboba Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Server Discovery Message-ID: <20010606093034.I12278@charizard.diameter.org> Mail-Followup-To: Bernard Aboba , Pat Calhoun , aaa-wg@merit.edu References: <20010605154910.M12278@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from aboba@internaut.com on Tue, Jun 05, 2001 at 11:45:33PM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk All, Here is my proposed text for this particular issue (specifically, I changed text in item 3): 2.6 Diameter Agent Discovery Allowing for dynamic Diameter agent discovery will make it possible for simpler and more robust deployment of AAA services. In order to promote interoperable implementations of Diameter agent discovery, the following mechanisms are described. These are based on existing IETF standards. There are two cases where Diameter agent discovery may be performed. The first is when a Diameter client needs to discover a first-hop Diameter agent. The second case is when a Diameter agent needs to discover another agent - for further handling of a Diameter operation. In both cases, the following 'search order' is recommended: 1. The Diameter implementation consults its list of static (manual) configured Diameter agent locations. These will be used if they exist and respond. 2. The Diameter implementation uses SLPv2 [28] to discover Diameter services. The Diameter service template [32] is included in Appendix A. It is recommended that SLPv2 security be deployed (this requires distributing keys to SLPv2 agents.) This is discussed further in Appendix A. SLPv2 will allow Diameter implementations to discover the location of Diameter agents in the local site, as well as their characteristics. Diameter agents with specific capabilities (say support for the Mobile IP application) can be requested, and only those will be discovered. 3. The Diameter implementation uses DNS to request the SRV RR [33] for the '_diameter._sctp' and/or '_diameter._tcp' server in a particular domain. The Diameter implementation has to know in advance which domain to look for an Diameter agent in. This could be deduced, for example, from the 'realm' in a NAI that an Diameter implementation needed to perform an Diameter operation on. 3.1 If the destination address is a numeric IP address, the requestor contacts the peer at the given address and the port number specified in the SRV record or, if not specified, the default port (TBD). 3.2 The results of the query or queries are merged and ordered based on priority. Then, the searching technique outlined in [46] is used to select servers in order. The requestor attempts to contact each peer in the order listed, at the port number specified in the SRV record. If none of the servers can be contacted, the requestor gives up. If there are no SRV records, DNS address records are used, as described below. 3.3 If the destination specifies a port number other than TBD or if there are no SRV records, the requestor queries the DNS server for address records for the destination address. Address records include A RR's, AAAA RR's, or other similar records, chosen according to the requestor's network protocol capabilities. If the DNS server returns no address records, the requestor gives up. If there are address records, the same rules as in step 3.2 apply. Requestors MUST NOT cache query results except according to the rules in [47]. Diameter allows AAA peers to protect the integrity and privacy of communication as well as to perform end-point authentication. Still, it is prudent to employ DNS Security as a precaution when using DNS SRV RRs to look up the location of a Diameter agent. [34, 35, 36] PatC From owner-aaa-bof@merit.edu Wed Jun 6 12:48:22 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05142 for ; Wed, 6 Jun 2001 12:48:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 645A1912F6; Wed, 6 Jun 2001 12:48:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 39E64912FF; Wed, 6 Jun 2001 12:48:27 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 21E3B912F6 for ; Wed, 6 Jun 2001 12:48:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CDDF05DDAD; Wed, 6 Jun 2001 12:48:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 4B8C65DDAC for ; Wed, 6 Jun 2001 12:48:49 -0400 (EDT) Received: (qmail 19041 invoked by uid 500); 6 Jun 2001 16:38:00 -0000 Date: Wed, 6 Jun 2001 09:38:00 -0700 From: Pat Calhoun To: Allison Mankin , Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 24: Transport Selection Message-ID: <20010606093800.J12278@charizard.diameter.org> Mail-Followup-To: Allison Mankin , Pat Calhoun , aaa-wg@merit.edu References: <20010605160936.O12278@charizard.diameter.org> <200106060358.f563wAR28492@minotaur.east.isi.edu> <20010606063534.Y12278@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010606063534.Y12278@charizard.diameter.org>; from pcalhoun@diameter.org on Wed, Jun 06, 2001 at 06:35:34AM -0700 Sender: owner-aaa-bof@merit.edu Precedence: bulk Just to close this issue, below is the text that I am proposing we use in -06: When connecting to a peer, and either zero or more transports are specified, SCTP SHOULD be tried first, followed by TCP. See section 2.6 for more information on peer discovery. Diameter implementations SHOULD be able to interpret ICMP protocol and port unreachable messages as explicit indications that the server is not reachable, in addition to interpreting ECONNREFUSED (a reset from the transport) and timed-out connection attempts. PatC From owner-aaa-bof@merit.edu Wed Jun 6 12:54:47 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05344 for ; Wed, 6 Jun 2001 12:54:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3931D912FF; Wed, 6 Jun 2001 12:54:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0086E91300; Wed, 6 Jun 2001 12:54:39 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DAA1C912FF for ; Wed, 6 Jun 2001 12:54:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 932B35DE01; Wed, 6 Jun 2001 12:55:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 13F0E5DDAC for ; Wed, 6 Jun 2001 12:55:02 -0400 (EDT) Received: (qmail 19060 invoked by uid 500); 6 Jun 2001 16:44:13 -0000 Date: Wed, 6 Jun 2001 09:44:13 -0700 From: Pat Calhoun To: Fredrik Johansson Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 20: How to handle no common extensions Message-ID: <20010606094413.K12278@charizard.diameter.org> Mail-Followup-To: Fredrik Johansson , Pat Calhoun , aaa-wg@merit.edu References: <20010605161816.Q12278@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from fredrik.johansson@ipunplugged.com on Wed, Jun 06, 2001 at 04:03:56PM +0200 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Wed, Jun 06, 2001 at 04:03:56PM +0200, Fredrik Johansson wrote: > Perhaps it should be stated that a node that advertise a wildcard should > keep the connection. fair enough, how about: A receiver of a Capabilities-Exchange-Req (CER) message which does not have any applications in common with the sender MUST return a Capabilities-Exchange-Answer (CEA) with the Result-Code AVP set to DIAMETER_NO_COMMON_APPLICATION, and SHOULD disconnect the transport layer connection. Note that receiving a CER or CEA from a peer advertising itself as a Relay (see section 6.1) MUST be interpreted as having common applications with the peer. PatC From owner-aaa-bof@merit.edu Wed Jun 6 13:03:22 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05610 for ; Wed, 6 Jun 2001 13:03:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C138191300; Wed, 6 Jun 2001 13:03:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A6BA291301; Wed, 6 Jun 2001 13:02:55 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 18EDC91300 for ; Wed, 6 Jun 2001 13:02:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B99005DE01; Wed, 6 Jun 2001 13:02:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by segue.merit.edu (Postfix) with ESMTP id 67CD65DDAC for ; Wed, 6 Jun 2001 13:02:55 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id KAA11846 for ; Wed, 6 Jun 2001 10:02:37 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id JAA27077 for ; Wed, 6 Jun 2001 09:56:09 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Jun 2001 12:02:36 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECF23@IL27EXM10.cig.mot.com> From: Cain Brian-BCAIN1 To: "'Pat Calhoun'" , Allison Mankin , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 24: Transport Selection Date: Wed, 6 Jun 2001 12:02:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-bof@merit.edu Precedence: bulk > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > Just to close this issue, below is the text that I am proposing we > use in -06: > > > When connecting to a peer, and either zero or more transports are > specified, SCTP SHOULD be tried first, followed by TCP. See section More? If a Diameter Identity of "diameter://host.abc.com;transport=tcp" were specified, SCTP should still be tried first? Maybe this should be along the lines of "if no transports are specified, or if SCTP is one of the specified transports, it should be tried first"...? And if it's a good idea to specify more than one transport, should we make it possible to have a Diameter Identity that contains more than one transport? > 2.6 for more information on peer discovery. > > Diameter implementations SHOULD be able to interpret ICMP protocol > and port unreachable messages as explicit indications that > the server > is not reachable, in addition to interpreting ECONNREFUSED (a reset > from the transport) and timed-out connection attempts. From owner-aaa-wg@merit.edu Wed Jun 6 13:32:20 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06306 for ; Wed, 6 Jun 2001 13:32:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9D6B691302; Wed, 6 Jun 2001 13:32:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 586FF913B8; Wed, 6 Jun 2001 13:32:07 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 366FA91302 for ; Wed, 6 Jun 2001 13:32:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EA9505DE01; Wed, 6 Jun 2001 13:32:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 869415DDAD for ; Wed, 6 Jun 2001 13:32:28 -0400 (EDT) Received: (qmail 20299 invoked by uid 500); 6 Jun 2001 17:21:39 -0000 Date: Wed, 6 Jun 2001 10:21:38 -0700 From: Pat Calhoun To: Jacques Caron Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Comments on base draft 05 Message-ID: <20010606102138.L12278@charizard.diameter.org> Mail-Followup-To: Jacques Caron , aaa-wg@merit.edu References: <4.3.2.7.2.20010605182622.00d9b4a0@pop.fr.psi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010605182622.00d9b4a0@pop.fr.psi.com>; from jacques_m_caron@yahoo.com on Tue, Jun 05, 2001 at 10:18:11PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Jun 05, 2001 at 10:18:11PM +0200, Jacques Caron wrote: > I understand that formal issues have to be submitted using the appropriate > template, but given the number of comments I have, I guess a first quick > run through on which others can give a quick word on whether the issue is > not new would be better, to then formally submit only those that are > actually valid? Let me know if you'd rather have me submit everything in > the correct format directly... Your proposal makes sense. Let's make sure there are issues in order to minimize opening unnecessary issues. See my response below. > > =========== > > In 2.5.3, can a server that received a redirect cache the result (e.g. > based on realm+application)? yes, and this should probably be discussed in the base draft. Please open an issue on this one. > > =========== > > In 2.6/3, when using DNS, what if there are indirect relationships? Imagine > the following: > - ISP A is a customer of roaming clearinghouse B. > - Company E is a customer of ISP D, which is a customer of roaming > clearinghouse C. > - B & C have a "peering" relationship. > > B---C > | | > A D > | > E > > (the idea is to duplicate the peering/transit mechanisms of routing within > the Internet, to reduce direct peering relationships, but still with the > ability to have multiple competing roaming clearinghouse that talk to each > other). > > Since there are only direct relationships between A&B, B&C, C&D and D&E, > the request must be proxied along all that path, but there is no mechanism > to find it. > > Let's say that A->B is done using a simple "default route". > > I then see multiple options for B to send the request to E: > 1. DNS+"backward" redirects > - The home diameter server (E) is found via SRV RRs by B, but since E > doesn't "know" B, it redirects it to D (using some "default" mechanism) > - D points to C (ditto) > - request gets to C, which starts again, and so on until we get to E. > Has many drawbacks, amongst which there must be a way for diameter servers > that don't know each other to talk at least a bit (not a good idea), and > many round-trips accross the net. > Might be shortened a bit by A sending directly to B (default). > > 2. DNS+"backward" RRs > - B looks up SRV RRs for E > - since it doesn't know that server (in its peers list), it looks for > another type of RR (TBD) that points to D (might be a TXT RR giving the > realm for D) > - starts again to find C, which B knows and can forward the request to. > > Probably the most elegant. May have issue with different applications, > though (unless the server pointed to by SRV RRs is always a proxy that then > sends to the right server for the specific application). > > 3. BGP-routing-like realm distribution in CER > Use the Capabilities-Exchange-Request to advertise the realm/application > pairs that a server supports, not just applications. This would include > realms that upstream servers support, so it could become quite large. > Probably not very scalable. > > 4. BGP-routing-like realm distribution using something else > Might use other commands, a different protocol, or even use extensions to BGP? > > My favorite is 2. > > Note that all of this might be outside the scope of the (base) document, > but I think it would be very useful for roaming, especially in the wireless > (WLAN) context. Support for DNS was added in order for peers that do want to communicate directly, and have a need to. So, in my implementation, I can state that in order to get to E (or perhaps any domain that I don't recognize), I need to talk to a server in B. However, I don't have any servers setup for B, so I do a DNS query. I think that this is the best (and easiest) approach. Options 2 requires that B know that C talks to D, which talks to E. It isn't clear to me how this would be known. Certainly not in DNS, since one doesn't encode business relationships within DNS records. Business relationships != low latency/round trips :( Options 3 and 4 have been discusses as research issues many times in the past few years, but there are plenty of additional problems that arise (e.g. looping). So, if someone believes this is necessary in the future, the protocol could be extended to support this, but as it stands, this is a fairly large new feature to add at such a late date. > In 3.1/4.1/4.5, what about reserving ranges for experimental command & AVP > codes? Isn't the private AVP and command similar to experimental? I know that RADIUS has such a thing, but it's never been managed properly. Look at the Status-Client for example, there isn't a spec out there, and it is only used by a single vendor. I believe that experimental commands made sense in RADIUS because its lack of vendor specific commands. > In 3.2, Command ABNF: > - "fixed" isn't defined. It seems to mean that it is required, but at a > specific position or in a specific order, but that's really unclear. > - the defaults for min & max in qual are not defined if only one of them is > present (i.e. no qual = 1*1, but what about *n or n*? I guess the latter > means n*infinity, but does *n mean 1*n or 0*n)? > - it says that it describes AVPs which MUST NOT be present, but that's not > part of the ABNF (it's implicit). Please open an issue for the above. > In 4.1, AVP Flags: > - still mentions both 'r' and reserved bits > - says that unrecognized bits should be considered an error, but also that > r/reserved bits should be ignored. Please open an issue for the above. > In 4.1, what about having a AVP type (OctetString, Address, etc.) in the > header? This would be useful for logging/debugging purposes in relays that > wouldn't need to have (up-to-date) dictionnary files. This has been discussed at length in the past, and we decided against it. I agree that for logging and debugging, this is useful, but the format of the AVP is required in order to process it anyways. If you don't know the format of the AVP, simply print it as a hex value. I you feel this is a MUST, open an issue, and we can see where this goes. > In 4.5, AVP Flag rules: > - what about a flag that isn't in any of the MUST/MAY/SHOULD NOT/MUST NOT > categories for a given command? > - isn't there some redundancy between the "MAY encr" column and the > position of P? There aren't any flags that aren't in the flag rules (or rather there shouldn't be). P is not used for encrypting, but rather for signing. > In 4.3/4.4, do the AVP codes in a Grouped AVP share the same scope as those > at "first level"? Sorry this seems to break my parser. Could you try again? :) > In 4.3, max length of an OctetString is still 65504. Please open an issue. > In 5.1, "the local host's identity is encoded in the Origin-Host and > Origin-Host AVPs" (getting picky, sorry). A nit that needs to be fixed. Please open an issue (btw, given that most of these issues that I agree to do in fact need to be fixed, perhaps you want to open a single issue, and just include all these comments). They are protocol bugs, and need to be fixed, and not necessarily controversial enough that they need to be tracked separately. > In 5.0/5.3, it is unclear whether the Destination-Realm derivation from the > User-Name should be done only in the NAS, or can be done by any agent on > the way. It is intentionally unclear. There are certain cases (e.g. dial-up outsourcing) where the user-name is not know because the Diameter request is sent prior to the call being answered. In such an example, the Destination-Realm would be identified via the called (or calling number). > In 5.3, Diameter agents *MAY* have a list of locally supported realms... Add that one to your issue. > In 5.0/5.3.4/5.6 > - the use of Destination-Host for answers quite puzzles me. There's > contradiction between 5.6 and 5.3.4 on how routing should be done (based on > Destination-Host or Route-Record AVPs?). Using Destination-Host in any case > would bypass relays/proxies, which would then lose the ability to track > state, to perform accounting (especially in a roaming environment), etc. > Not really sure it should ever be used? > > - even better, the Destination-Realm should probably never be used to > routes answers? MUST NOT > > - Should original client add a Route-Record AVP (or Proxy-Info)? Or should > a proxy check the Origin-Host for a loop too? How does routing back to the > client work? As long as there is a Route-Record AVP in the answer message, the agents use the information in the Route-Record to find the next hop. When no Route-Record is present, the Destination-Host AVP is used to forward the message to the intended target Diameter node. I see that 5.3.4 needs a last sentence, such as: " Once the local Route-Record AVP has been removed, if no Route-Records AVPs are present in the message, the Destination-Host AVP is used to forward the message to the intended target Diameter node, as described in 5.2" Please open an issue specifically for this one. > In 5.3.2 > - the use of MRA for redirects doesn't look "clean" to me. I'd rather > always have an answer with the same command code as the request, with a > specific result-code. Well I sympathize with your desire, but consensus at the interim meeting shows that people want this approach. (I personally believe that a Result- Code class is a MUCH better approach, and works MUCH better with the Diameter API). Open an issue on this if you feel this is important to you. > - loops should be checked Now sure why.... > In 5.3.3/5.0, loop checking should be done upon receipt of a message? Not sure that I understand the question... > In 6.0/5.3.1, how does a relay (which adverstised the relay application ID) > know which commands are part of which application, if it has multiple > upstream peers with different applications? Shouldn't the application ID be > included in the packet header? This has been discussed, and including it in the header makes vendor specific applications more difficult to handle. So, since the message must be parsed to determine the Realm or Host to forward/route the message to, the application id can be extracted at that time as well. > In 5.3.4, the agent sending an STR "on behalf of the access device" is a > violation of 5.4? On behalf doesn't mean that the Origin-Host is to be set to the access device's identity. Of course, this would be broken. When sending a message, the Origin-Host AVP is always to the local identity. Am I missing something? > In 5.3.1: > - clarify possibility of default realm (which would probably most often be > the only realm on access devices). open issue on this > - indicate multiple possible hosts for a realm, or is that handled at > DNS/transport level? The routing table definition already states that one or more server can be configured for a particular realm. Is this not sufficient? > In 5.5, what's the purpose of the origin-realm? How is it defined/derived? Not sure why we decided that it was necessary, and perhaps it isn't required at all. All operations are done on Origin-Host, Destination-Host and Destination-Realm. Open separate issue on this requesting that the Origin-Realm be abolished. > In 5.8, isn't there some redundancy between Route-Record and Proxy-Host? Yes, and I had been thinking about how to add the proxy info to the Route-Record, but doing so would require that the Route-Record be a Grouped AVP, which has additional processing requirements, and I prefer to keep the Route-Record AVP as simple as possible. For proxies that insist on distributing their state across the network, let them deal with the added cost of adding an AVP. > Somewhere in 5, it might be interesting to include a way for diameter > proxy/relay/server clusters to exchange state information to facilitate > failover. This might be done by sending a copy of all received packets to > the other node of the cluster, with either a specific flag set (so the > other node updates its state tables, but does not act on the packet or > forward it), or some other mechanism. Might be outside the scope of the > spec, though. Interesting, but clearly outside the scope of the base protocol :) > I guess that's it for today. I have a number of other issues, but they were > against release 4 of the draft, so I have to check them against rev 5 first > before bothering you any more :-) And thanks to all for all the good work > that's already been done! And likewise, thanks for the great comments, PatC From owner-aaa-wg@merit.edu Wed Jun 6 13:37:36 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06442 for ; Wed, 6 Jun 2001 13:37:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 630E3913C2; Wed, 6 Jun 2001 13:34:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1DFD1913C0; Wed, 6 Jun 2001 13:34:49 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 058AC913BA for ; Wed, 6 Jun 2001 13:34:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BE80E5DE01; Wed, 6 Jun 2001 13:35:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 765A15DDAD for ; Wed, 6 Jun 2001 13:35:08 -0400 (EDT) Received: (qmail 20313 invoked by uid 500); 6 Jun 2001 17:24:19 -0000 Date: Wed, 6 Jun 2001 10:24:19 -0700 From: Pat Calhoun To: Cain Brian-BCAIN1 Cc: "'Pat Calhoun'" , Allison Mankin , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 24: Transport Selection Message-ID: <20010606102419.M12278@charizard.diameter.org> Mail-Followup-To: Cain Brian-BCAIN1 , 'Pat Calhoun' , Allison Mankin , aaa-wg@merit.edu References: <35DBB8B7AC89D4118E98009027B1009B0ECF23@IL27EXM10.cig.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B0ECF23@IL27EXM10.cig.mot.com>; from Brian.Cain@motorola.com on Wed, Jun 06, 2001 at 12:02:36PM -0500 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Jun 06, 2001 at 12:02:36PM -0500, Cain Brian-BCAIN1 wrote: > > > > -----Original Message----- > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > > > Just to close this issue, below is the text that I am proposing we > > use in -06: > > > > > > When connecting to a peer, and either zero or more transports are > > specified, SCTP SHOULD be tried first, followed by TCP. See section > > More? If a Diameter Identity of "diameter://host.abc.com;transport=tcp" > were specified, SCTP should still be tried first? > > Maybe this should be along the lines of "if no transports are specified, or > if SCTP is one of the specified transports, it should be tried first"...? > And if it's a good idea to specify more than one transport, should we make > it possible to have a Diameter Identity that contains more than one > transport? I suppose it SHOULD be possible for a redirect server to return a host with multiple transports. no? PatC From owner-aaa-wg@merit.edu Wed Jun 6 13:52:31 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06821 for ; Wed, 6 Jun 2001 13:52:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2BC8C91303; Wed, 6 Jun 2001 13:52:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ED4F691304; Wed, 6 Jun 2001 13:52:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9C7F691303 for ; Wed, 6 Jun 2001 13:52:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 65B6D5DE01; Wed, 6 Jun 2001 13:52:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 4BEFD5DDAD for ; Wed, 6 Jun 2001 13:52:33 -0400 (EDT) Received: (qmail 20881 invoked by uid 500); 6 Jun 2001 17:41:44 -0000 Date: Wed, 6 Jun 2001 10:41:44 -0700 From: Pat Calhoun To: Jacques Caron Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: More comments on base draft 05 Message-ID: <20010606104144.N12278@charizard.diameter.org> Mail-Followup-To: Jacques Caron , aaa-wg@merit.edu References: <4.3.2.7.2.20010606004514.00bcd7f0@pop.fr.psi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010606004514.00bcd7f0@pop.fr.psi.com>; from jacques_m_caron@yahoo.com on Wed, Jun 06, 2001 at 02:09:53AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Jun 06, 2001 at 02:09:53AM +0200, Jacques Caron wrote: > What about having a bit in the header flags to indicate that this message > should not be proxied, but only handled locally? This would enable a > relay/proxy to recognize messages it doesn't know about that it's supposed > to handle (and complain about it?). > > [I'm really in favor of having relays be able to do as much as possible > while knowing as little as possible about the specifics of any application, > command, or AVP]. Well, the protocol already states that it the Destination-Realm is NOT in a message's ABNF, then it isn't proxiable, but perhaps something more explicit for dumb relays? Open an issue... > For answers, since in most cases (other than the (in-)famous MRA) the > command code is the same as the request, we have a bit to distinguish > requests from answers, and the result-code is mandatory, why not simply put > the result-code in the command code field? > The distinction between protocol and application errors could then be done > either based on the result-code (protocol errors are in the 3xxx range) or > using the proxy/local flag above... This would break the API, and I really don't like it much. I think that the command really needs to be maintained across answers. > Regarding loop detection, I think the text should specify exactly how host > matching is done: based on host descriptor (text), name+port, IP+port, any > of the above... ok, open an issue > Back on the routing of answers: if one admits we forget about > Destination-Host to make sure the answers travels the same path back, > should a proxy use the route-record AVP, or send it back on the same > connection it received the request on (and which it saved in the > transaction state table, or in Proxy-State AVPs)? > If route-record, then it should be checked on receipt that it matches where > the message was received from? > Alternatively, it could be decided that the route-record AVP is added upon > _receipt_ of a message, not when forwarding it. Which elimites the need for > a NAS to insert it. ok, if that will make it clearer, please open an issue. > I have only glanced at the NASREQ & Mobile-IP applications, but I really > wonder why there is any need for separate Auth Request commands? I think > the protocol should be streamlined as much as possible by limiting the > number of commands (in too classes: those that are used for local hop > interactions: Capability Exchange, Device Watchdog...; and those that are > used for end-to-end requests: Auth req, Acct start, Acct stop...; the > difference being made with the flag mentionned earlier). The difference > between different types of auth requests would then be indicated by an > application Id in the command header (which is way more efficient than a > Auth/Acct-Application-Id that is mandatory anyway). > > Having standard auth and acct commands also permits relays to make the > difference between auth and acct commands for routing purposes (when a > downstream server advertises Auth capability and another Acct capability > for a given Application Id), without having to check > Auth/Acct-Application-Id presence which have complex rules that are not > stated anywhere (only one of them should be present, obviously). The way the messages are handled in both NASREQ and Mobile IP are vastly different. The command ABNFs are different, the behavior of the command is different, etc. I think that streamlining would only cause additional confusion, and complexity in implementation. I would prefer we keep it the way it is now. btw, if a new service is provided, and an existing Diameter application may be used, then we do encourage that new AVPs be defined, and existing work be used. > Some minor nit-picking: > - in 6.0, Device Reboot should be changed to whatever is the new name of > those messages > - in 6.0 first paragraph, there is a "first", but no "next" or "then" or > "second"... > - in 6.1, "Relay and redirect agents MUST advertise the *Relay* application..." > - in the same paragraph, Device Reboot again > - in the next paragraph, it should be upstream, not downstream. > - in 7.2, the RTT/RTO stuff isn't used anymore? > (didn't go through all the state machine, but there are plenty of DRIs and > such in there) > Add this to your large nits issue > In 9.0, what happens if there is no alternate to send the request to? > Should the MRA be forwarded upstream? As-is? With stuff changed > (Origin-Host, Hop-by-hop, End-to-End Ids...)? send back towards originator of the request. > In 9.0, in the result-code AVPs that require Failed-AVPs, need a > clarification whether this is done only by the home server, or by any > proxy/relay on the way hmmm... ok. open issue. > In 9.0 still, what about errors regarding invalid length (packet or AVP)? > Especially for AVPs, since it will be difficult to include a correctly > formatted AVP if length is wrong anyway? open issue > Which raises another question: what about a Grouped AVP with M not set > containing AVPs with M set? Yes I know I have silly questions. that's not a problem. If any AVP has the 'M' bit set, and it isn't recognized then the behavior is well defined. It doesn't matter whether an AVP is encapsulated in a group or not. > In 5.3.2/9.1: > > Unless I'm blind (which could be true), DIAMETER_REDIRECT_INDICATION is not > defined. darn..... issue > In 9.1.3: > - as stated above, a separate class for protocol errors is redundant with > the use of MRA. yes, and I'd prefer to see MRA eliminated, rather than the class > - what's the difference between UNABLE_TO_DELIVER and NOT_SERVED? i.e. in > which case is which sent? I know the domain, but cannot reach any servers. I don't know the domain. > - any specific messages for DNS errors (transient such as timeouts, or > permanent such as NXDOMAIN)? I'd prefer we not have any, buy if you feel it is necessary, please propose some text. > In 9.1.4/9.1.5: > - should AUTHENTICATION_REJECTED and USER_UNKNOWN really be different? I > guess that's the usual tradeoff security (having only one prevents an > attacker to find active accounts on which to focus) against > user-friendliness... Right and it is up the server's policy to determine which error it wishes to return. > - the difference between AUTHORIZATION_REJECTED and AUTHORIZATION_FAILED > is, er, unclear. issue. > - NO_COMMON_APPLICATION and UNSUPPORTED_VERSION would be better off in > Protocol errors? except that protocol errors MUST only be used in MRA... see the problem :) > - missing errors for message or AVP length errors issue > In 10.0 third paragraph, "If the server does not receive another > authorization request before the timeout occurs", I guess some leeway for > transmission and processing delays would be a good thing :-) The other > option is to use Authorization-Lifetime only as a "Reauth timer", and > Session-Timeout as the max length after which the user is to be > disconnected and forgotten (and even then, keeping state a tad more to > match the accounting stop info that is supposed to arrive would still be a > good idea). Sorry I don't understand. Your other option is exactly the way the protocol is defined. btw, I don't get the accounting stop thing. please try again... > In 10.3 second paragraph, an example of a reason to have multiple > Session-IDs in the same message would be good. The Accounting Poll command (which I believe we will eliminate), and the Resource Management (which is not a WG work item), as well as batched accounting. Since none of these are either supported by the protocol, or a WG work item, we can eliminate this sentence. > In 10.7, the STR should be sent along the same path as previous requests, > not directly to the server (by using Origin-Host of the auth answer as > Destination-Host), for proxies along the way to be able to update state. hmmmm... don't know how this can be achieved. > More generally, again, I really find the Destination-Host AVP very annoying > and probably not very useful, except for unsollicited requests from the > server to the client, and even in those cases, something should be done to > make sure proxies along the way are aware of what's going on. The other use > would be to make sure the STR goes to the same server that authorized the > connection, but it should apply to all intermediate proxies/relays too, so > it should be based on some other mechanism. > > Anyway, in many cases it simply won't be possible to use Destination-Host > because of the lack of security associations between the two endpoints... I am not sure that I understand where this is leading.... > In 12.3, still a -Ind command. and I had to keep it in the spec until the issue was closed. I didn't want to create a new command set with the possibility of the command being eliminated. > Isn't there some redundancy between STR and an Accounting-Request with > type=STOP? no. Unlike RADIUS, Diameter doesn't rely on accounting messages to maintain state. The STR message is used instead. > 15.1.2 is not up to date (bit numbers) > > 15.4 does not include protocol errors Add these to your large nits issue Thanks again, PatC From owner-aaa-wg@merit.edu Wed Jun 6 14:49:36 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07736 for ; Wed, 6 Jun 2001 14:49:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3D62E91307; Wed, 6 Jun 2001 14:49:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0CC1391309; Wed, 6 Jun 2001 14:49:35 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0106191307 for ; Wed, 6 Jun 2001 14:49:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D3D4C5DE0C; Wed, 6 Jun 2001 14:49:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by segue.merit.edu (Postfix) with ESMTP id 60EBA5DD8D for ; Wed, 6 Jun 2001 14:49:58 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f56Ine821183 for ; Wed, 6 Jun 2001 13:49:40 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f56IndB05180 for ; Wed, 6 Jun 2001 13:49:39 -0500 (CDT) Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA07655; Wed, 6 Jun 2001 13:49:39 -0500 (CDT) Received: from ericsson.com ([138.85.159.105]) by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id NAA02951; Wed, 6 Jun 2001 13:49:37 -0500 (CDT) Message-ID: <3B1E7A7D.3FF51B29@ericsson.com> Date: Wed, 06 Jun 2001 11:46:21 -0700 From: Tony Johansson X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Cc: kevin.purser@ericsson.com Subject: [AAA-WG]: Issue #67: How to deal with CER and CEA in the case of SCTP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, Here is one more issue.... /Tony Issue 67: How to deal with CER and CEA in the case of SCTP Submitter name: Tony Johansson Submitter email address: tony.johansson@ericsson.com Date first submitted: 2001-06-06 Reference: Document: Base Comment type: T Priority: 1 Section: 8.0 Rationale/Explanation of issue: The text defined in 8.0 is obviously based on the TCP case (even though its not explicitly stated) and there is no case described that covers the SCTP case. So, when we now have changed the DRI to CER and CEA, who will issue the CER in the SCTP case? To my understanding, the SCTP protocol can't tell the upper layer, which one of the the peers that first initiated the connection request in the case that both peers issued a connection establishment request almost at the same time. The SCTP protocol is a peer-to-peer protocol, so this type of issue is resolved by various mechanisms in the SCTP protocol itself. The upper layer is guaranteed to always get one connection between the peers. So the I-connection and R-connection, which are need in the TCP case doesn't make sense for SCTP case and the problem right now is that the CER and CEA is based on the I-xx and R-xx (which is determined from indications from the TCP transport layer). IMHO, I suggest that we go back and use something like the DRI. Because as soon as we have one single transport connection established it doesn't really matter, which peer that issues its capability exchange message first. This would make the capability exchange flow independent from specific indications from the transport layer which may or may not be present depending on the transport layer in use. Comments... From owner-aaa-wg@merit.edu Wed Jun 6 16:23:56 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08765 for ; Wed, 6 Jun 2001 16:23:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B6C0B9131B; Wed, 6 Jun 2001 16:23:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 822B49131A; Wed, 6 Jun 2001 16:23:51 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D8C2A91315 for ; Wed, 6 Jun 2001 16:23:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 33C1C5DE17; Wed, 6 Jun 2001 16:24:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by segue.merit.edu (Postfix) with SMTP id CAEDA5DE12 for ; Wed, 6 Jun 2001 16:24:10 -0400 (EDT) Received: from ip21.zurich31.pub-ip.ch.psi.net (HELO jc.yahoo.com) (154.15.31.21) by smtp.mail.vip.sc5.yahoo.com with SMTP; 6 Jun 2001 20:23:42 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010606213833.00c21730@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Jun 2001 22:11:31 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: More comments on base draft 05 Cc: aaa-wg@merit.edu In-Reply-To: <20010606104144.N12278@charizard.diameter.org> References: <4.3.2.7.2.20010606004514.00bcd7f0@pop.fr.psi.com> <4.3.2.7.2.20010606004514.00bcd7f0@pop.fr.psi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA08765 At 19:41 06/06/01, Pat Calhoun wrote: >Well, the protocol already states that it the Destination-Realm is NOT in >a message's ABNF, then it isn't proxiable, but perhaps something more explicit >for dumb relays? I thought in some cases the Destination-Realm could be added by a proxy? :-) >Open an issue... > > > For answers, since in most cases (other than the (in-)famous MRA) the > > command code is the same as the request, we have a bit to distinguish > > requests from answers, and the result-code is mandatory, why not simply > put > > the result-code in the command code field? > > The distinction between protocol and application errors could then be done > > either based on the result-code (protocol errors are in the 3xxx range) or > > using the proxy/local flag above... > >This would break the API, and I really don't like it much. I think that >the command really needs to be maintained across answers. Haven't looked at the API yet (it's in the pile of drafts on my reading list though), but will come back as soon as I have read it ;-> > > In 9.0, what happens if there is no alternate to send the request to? > > Should the MRA be forwarded upstream? As-is? With stuff changed > > (Origin-Host, Hop-by-hop, End-to-End Ids...)? > >send back towards originator of the request. With what processing? Since it's supposed to be handled locally, it probably shouldn't be forwarded as-is? Note that I think there is another discussion on the Error-Reporting-Host AVP that would be related. > > Which raises another question: what about a Grouped AVP with M not set > > containing AVPs with M set? Yes I know I have silly questions. > >that's not a problem. If any AVP has the 'M' bit set, and it isn't recognized >then the behavior is well defined. It doesn't matter whether an AVP is >encapsulated in a group or not. Not possible. Imagine a server receives an AVP it doesn't recognize, but is not marked M. It ignores it. Bad luck, it was actually a grouped AVP (which the server doesn't know since it doesn't recognize the AVP, and there is no AVP type) with an AVP with M set somewhere in it. I would say one should not be allowed to put an 'M' AVP within a non-'M' grouped AVP? > > In 9.1.3: > > - as stated above, a separate class for protocol errors is redundant with > > the use of MRA. > >yes, and I'd prefer to see MRA eliminated, rather than the class I concur. > > - what's the difference between UNABLE_TO_DELIVER and NOT_SERVED? i.e. in > > which case is which sent? > >I know the domain, but cannot reach any servers. I don't know the domain. Mmmm. Needs clarification? > > - any specific messages for DNS errors (transient such as timeouts, or > > permanent such as NXDOMAIN)? > >I'd prefer we not have any, buy if you feel it is necessary, please propose >some text. I understand that it's an indirect error and that we don't want to have all values of errno around, but I think those would be quite helpful for debugging purposes... > > - NO_COMMON_APPLICATION and UNSUPPORTED_VERSION would be better off in > > Protocol errors? > >except that protocol errors MUST only be used in MRA... see the problem :) Get rid of MRA :-) Or define a "class" of inter-server requests with can have protocol errors in their answers, and end-to-end requests which cannot? Which amounts to my local/non-proxyable flag ;-> > > In 10.0 third paragraph, "If the server does not receive another > > authorization request before the timeout occurs", I guess some leeway for > > transmission and processing delays would be a good thing :-) The other > > option is to use Authorization-Lifetime only as a "Reauth timer", and > > Session-Timeout as the max length after which the user is to be > > disconnected and forgotten (and even then, keeping state a tad more to > > match the accounting stop info that is supposed to arrive would still be a > > good idea). > >Sorry I don't understand. Your other option is exactly the way the protocol >is defined. btw, I don't get the accounting stop thing. > >please try again... Well, Authorization-Lifetime is a timer for doing a Reauth. But Reauth is not instantaneous, so everybody maintaining state (stateful proxies and servers) should not forget about that session when Authorization-Lifetime expires (as stated in the draft), but only when Session-Timeout expires, which should be larger than Authorization-Lifetime. And for the accounting stop, if for some reason the server wants to match that record with an existing connection (which just finished), it should keep information about that connection a little bit longer than Session-Timeout to make sure it's still there when the accounting stop message arrives. Clearer? > > In 10.3 second paragraph, an example of a reason to have multiple > > Session-IDs in the same message would be good. > >The Accounting Poll command (which I believe we will eliminate), and the >Resource Management (which is not a WG work item), as well as batched >accounting. Since none of these are either supported by the protocol, >or a WG work item, we can eliminate this sentence. Issue? > > In 10.7, the STR should be sent along the same path as previous requests, > > not directly to the server (by using Origin-Host of the auth answer as > > Destination-Host), for proxies along the way to be able to update state. > >hmmmm... don't know how this can be achieved. Just don't send it to Destination-Host, but leave it to be routed exactly like the auth request for that session (based on Destination-Realm and the routing tables)? > > More generally, again, I really find the Destination-Host AVP very > annoying > > and probably not very useful, except for unsollicited requests from the > > server to the client, and even in those cases, something should be done to > > make sure proxies along the way are aware of what's going on. The other > use > > would be to make sure the STR goes to the same server that authorized the > > connection, but it should apply to all intermediate proxies/relays too, so > > it should be based on some other mechanism. > > > > Anyway, in many cases it simply won't be possible to use Destination-Host > > because of the lack of security associations between the two endpoints... > >I am not sure that I understand where this is leading.... Well, get rid of Destination-Host :-) Always do hop-by-hop routing based on Destination-Realm. Still a problem with unsollicited requests, though, unless the server (as well as proxies that hide topology) remembers route-records for requests from that host, and we have source routing. Urg. > > Isn't there some redundancy between STR and an Accounting-Request with > > type=STOP? > >no. Unlike RADIUS, Diameter doesn't rely on accounting messages to >maintain state. >The STR message is used instead. Maybe a note about that somewhere would be useful so that people with a Radius background understand that? Unless it's already there and dear precious eyes failed to take notice of it of course :-) >Thanks again, Terrible what a "naïve" review of a document seemingly close to conclusion can do, eh? Sorry about that and coming so late in the discussion. :-( And I'll send in all the mentionned issues. Thanks, Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Wed Jun 6 17:00:46 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09105 for ; Wed, 6 Jun 2001 17:00:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5A25191306; Wed, 6 Jun 2001 16:23:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2376F91313; Wed, 6 Jun 2001 16:23:34 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C6CA791306 for ; Wed, 6 Jun 2001 16:23:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C49C05DE12; Wed, 6 Jun 2001 16:23:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by segue.merit.edu (Postfix) with SMTP id 66CBA5DD92 for ; Wed, 6 Jun 2001 16:23:56 -0400 (EDT) Received: from ip21.zurich31.pub-ip.ch.psi.net (HELO jc.yahoo.com) (154.15.31.21) by smtp.mail.vip.sc5.yahoo.com with SMTP; 6 Jun 2001 20:23:22 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010606204906.00bb3890@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Jun 2001 22:05:17 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Comments on base draft 05 Cc: aaa-wg@merit.edu In-Reply-To: <20010606102138.L12278@charizard.diameter.org> References: <4.3.2.7.2.20010605182622.00d9b4a0@pop.fr.psi.com> <4.3.2.7.2.20010605182622.00d9b4a0@pop.fr.psi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 19:21 06/06/01, Pat Calhoun wrote: > > In 2.6/3, when using DNS, what if there are indirect relationships? > Imagine > > the following: > > - ISP A is a customer of roaming clearinghouse B. > > - Company E is a customer of ISP D, which is a customer of roaming > > clearinghouse C. > > - B & C have a "peering" relationship. > > > > B---C > > | | > > A D > > | > > E > > > > (the idea is to duplicate the peering/transit mechanisms of routing within > > the Internet, to reduce direct peering relationships, but still with the > > ability to have multiple competing roaming clearinghouse that talk to each > > other). > > > > Since there are only direct relationships between A&B, B&C, C&D and D&E, > > the request must be proxied along all that path, but there is no mechanism > > to find it. > > > > Let's say that A->B is done using a simple "default route". > > > > I then see multiple options for B to send the request to E: > > 1. DNS+"backward" redirects > > - The home diameter server (E) is found via SRV RRs by B, but since E > > doesn't "know" B, it redirects it to D (using some "default" mechanism) > > - D points to C (ditto) > > - request gets to C, which starts again, and so on until we get to E. > > Has many drawbacks, amongst which there must be a way for diameter servers > > that don't know each other to talk at least a bit (not a good idea), and > > many round-trips accross the net. > > Might be shortened a bit by A sending directly to B (default). > > > > 2. DNS+"backward" RRs > > - B looks up SRV RRs for E > > - since it doesn't know that server (in its peers list), it looks for > > another type of RR (TBD) that points to D (might be a TXT RR giving the > > realm for D) > > - starts again to find C, which B knows and can forward the request to. > > > > Probably the most elegant. May have issue with different applications, > > though (unless the server pointed to by SRV RRs is always a proxy that > then > > sends to the right server for the specific application). > > > > 3. BGP-routing-like realm distribution in CER > > Use the Capabilities-Exchange-Request to advertise the realm/application > > pairs that a server supports, not just applications. This would include > > realms that upstream servers support, so it could become quite large. > > Probably not very scalable. > > > > 4. BGP-routing-like realm distribution using something else > > Might use other commands, a different protocol, or even use extensions > to BGP? > > > > My favorite is 2. > > > > Note that all of this might be outside the scope of the (base) document, > > but I think it would be very useful for roaming, especially in the > wireless > > (WLAN) context. > >Support for DNS was added in order for peers that do want to communicate >directly, >and have a need to. So, in my implementation, I can state that in order to >get to E >(or perhaps any domain that I don't recognize), I need to talk to a server >in B. >However, I don't have any servers setup for B, so I do a DNS query. I think >that this is the best (and easiest) approach. > >Options 2 requires that B know that C talks to D, which talks to E. It >isn't clear >to me how this would be known. Certainly not in DNS, since one doesn't encode >business relationships within DNS records. Business relationships != low >latency/round trips :( That's where: > > - since it doesn't know that server (in its peers list), it looks for > > another type of RR (TBD) that points to D (might be a TXT RR giving the > > realm for D) comes in. E would have some DNS RR that says "hey, if you don't know how to talk to me directly, please see with D", either directly (some slightly modified SRV RR) or indirectly (with a TXT RR giving the realm of D). D is a bit like a transit provider to E in routing analogies. Same thing would apply for finding C from D. And many people encode many things about business relationships in DNS records. Most "hosting" cases (for NSes, MXes, As...) are quite evident in DNS records. Many other business relationships are visible through BGP or other means. This would allow for "universal" roaming. Anyone could roam using a NAI very close to one's e-mail address, provided the domain has "routing" information to get to its Radius server via the appropriate roaming providers (that would do all the compensation stuff), without the need for a unique (badly scalable) roaming provider (or disjoint roaming "universes"). >Options 3 and 4 have been discusses as research issues many times in the >past few years, >but there are plenty of additional problems that arise (e.g. looping). So, >if someone >believes this is necessary in the future, the protocol could be extended >to support >this, but as it stands, this is a fairly large new feature to add at such >a late >date. Indeed, and they are not necessarily my favorites. Just for the sake of it, another issue is that of selection of the peer to use when two announce the same realm. We could have local weights, MEDs, communities... ;-> > > In 3.1/4.1/4.5, what about reserving ranges for experimental command & AVP > > codes? > >Isn't the private AVP and command similar to experimental? I know that RADIUS >has such a thing, but it's never been managed properly. Look at the >Status-Client >for example, there isn't a spec out there, and it is only used by a single >vendor. >I believe that experimental commands made sense in RADIUS because its lack of >vendor specific commands. It was purely a rethoric question. Many protocols that have IANA-assigned ranges include experimental ranges, so I wondered if there was any reason/need to have those here. Probably not, then :-) > > In 4.1, what about having a AVP type (OctetString, Address, etc.) in the > > header? This would be useful for logging/debugging purposes in relays that > > wouldn't need to have (up-to-date) dictionnary files. > >This has been discussed at length in the past, and we decided against it. >I agree that for logging and debugging, this is useful, but the format of >the AVP is required in order to process it anyways. If you don't know the >format of the AVP, simply print it as a hex value. >I you feel this is a MUST, open an issue, and we can see where this goes. Well, it certainly would not be a MUST. Would just have been nice :-) > > In 4.5, AVP Flag rules: > > - what about a flag that isn't in any of the MUST/MAY/SHOULD NOT/MUST NOT > > categories for a given command? > > - isn't there some redundancy between the "MAY encr" column and the > > position of P? > >There aren't any flags that aren't in the flag rules (or rather there >shouldn't >be). Well, P often isn't in any column, and M isn't in any in Error-Message and Error-Reporting-Host. > P is not used for encrypting, but rather for signing. Ooops. Have only glanced at the strong security draft yet :-( > > In 4.3/4.4, do the AVP codes in a Grouped AVP share the same scope as > those > > at "first level"? > >Sorry this seems to break my parser. Could you try again? :) Errrr, are the numbers assigned to AVPs within a given Grouped AVP specific to that Grouped AVP, or should all AVP codes be unique, whether they are in a Grouped AVP or not? Or, to take an example, if I have a grouped AVP (The-Famous-Host) which contains an AVP with code 500 (The-Famous-Port), can I reuse 500 for a "regular" AVP (which is not within my "The-Famous-Host" grouped AVP), or within another grouped AVP (The-Not-So-Famous-Host), with a different meaning? You can see that like the enums: their name/values are specific to a given AVP, not to all AVPs. > > In 5.0/5.3, it is unclear whether the Destination-Realm derivation from > the > > User-Name should be done only in the NAS, or can be done by any agent on > > the way. > >It is intentionally unclear. There are certain cases (e.g. dial-up >outsourcing) >where the user-name is not know because the Diameter request is sent prior to >the call being answered. In such an example, the Destination-Realm would be >identified via the called (or calling number). Mmmm. Maybe the unclarity should be made clear then? At some point it says it's done by the NAS, and then it's not so sure any more... > > In 5.0/5.3.4/5.6 > > - the use of Destination-Host for answers quite puzzles me. There's > > contradiction between 5.6 and 5.3.4 on how routing should be done > (based on > > Destination-Host or Route-Record AVPs?). Using Destination-Host in any > case > > would bypass relays/proxies, which would then lose the ability to track > > state, to perform accounting (especially in a roaming environment), etc. > > Not really sure it should ever be used? > > > > - even better, the Destination-Realm should probably never be used to > > routes answers? >MUST NOT Issue? Or is that already written somewhere, other than implicitly from the way answers are supposed to be routed? If it is, it's unclear (the Message processing section should be called "Request Processing" then, and another section for "Answer processing" would be needed). > > - Should original client add a Route-Record AVP (or Proxy-Info)? Or should > > a proxy check the Origin-Host for a loop too? How does routing back to the > > client work? > >As long as there is a Route-Record AVP in the answer message, the agents use >the information in the Route-Record to find the next hop. When no Route-Record >is present, the Destination-Host AVP is used to forward the message to the >intended target Diameter node. > >I see that 5.3.4 needs a last sentence, such as: > >" Once the local Route-Record AVP has been removed, if no Route-Records > AVPs are present in the message, the Destination-Host AVP is used to > forward > the message to the intended target Diameter node, as described in 5.2" > >Please open an issue specifically for this one. I will. I'm not convinced by this method :-/ > > In 5.3.2 > > - the use of MRA for redirects doesn't look "clean" to me. I'd rather > > always have an answer with the same command code as the request, with a > > specific result-code. > >Well I sympathize with your desire, but consensus at the interim meeting >shows that people want this approach. (I personally believe that a Result- >Code class is a MUCH better approach, and works MUCH better with the Diameter >API). > >Open an issue on this if you feel this is important to you. Not that it's so important, but it would really make the whole thing neater. I will combine that with my remarks on related subjects in the other mail. > > - loops should be checked > >Now sure why.... A sends request to B. B says "redirect to C". What if: - C is A - C is B - C is a host in the route-records? > > In 5.3.3/5.0, loop checking should be done upon receipt of a message? > >Not sure that I understand the question... Instead of doing loop checking when sending a forwarded message, it might be simpler to always do it when the message is received (in any context: server, proxy, relay, redirect... as a given agent might assume different roles anyway). This depends a bit on exactly how Route-Record is handled, though (i.e. whether even a client should include it). > > In 5.3.4, the agent sending an STR "on behalf of the access device" is a > > violation of 5.4? > >On behalf doesn't mean that the Origin-Host is to be set to the access >device's >identity. Of course, this would be broken. When sending a message, the >Origin-Host >AVP is always to the local identity. > >Am I missing something? Then what does the "on behalf of" mean? What exactly is set as if it was the access device sending it? > > - indicate multiple possible hosts for a realm, or is that handled at > > DNS/transport level? >The routing table definition already states that one or more server can be >configured for a particular realm. Is this not sufficient? I should open those things called eyes sometimes :-) > > In 5.8, isn't there some redundancy between Route-Record and Proxy-Host? > >Yes, and I had been thinking about how to add the proxy info to the >Route-Record, >but doing so would require that the Route-Record be a Grouped AVP, which has >additional processing requirements, and I prefer to keep the Route-Record >AVP as simple as possible. For proxies that insist on distributing their state >across the network, let them deal with the added cost of adding an AVP. Mmmm. Should that be an issue? > > Somewhere in 5, it might be interesting to include a way for diameter > > proxy/relay/server clusters to exchange state information to facilitate > > failover. This might be done by sending a copy of all received packets to > > the other node of the cluster, with either a specific flag set (so the > > other node updates its state tables, but does not act on the packet or > > forward it), or some other mechanism. Might be outside the scope of the > > spec, though. > >Interesting, but clearly outside the scope of the base protocol :) I'll keep it for desert :-) Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Wed Jun 6 18:54:26 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10196 for ; Wed, 6 Jun 2001 18:54:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 578C59131F; Wed, 6 Jun 2001 18:54:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2F04C91322; Wed, 6 Jun 2001 18:54:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D057F9131F for ; Wed, 6 Jun 2001 18:54:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0C1505DDAD; Wed, 6 Jun 2001 18:54:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 432BE5DD8D for ; Wed, 6 Jun 2001 18:54:41 -0400 (EDT) Received: (qmail 22928 invoked by uid 500); 6 Jun 2001 22:43:51 -0000 Date: Wed, 6 Jun 2001 15:43:51 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: More comments on base draft 05 Message-ID: <20010606154351.S12278@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <4.3.2.7.2.20010606004514.00bcd7f0@pop.fr.psi.com> <4.3.2.7.2.20010606004514.00bcd7f0@pop.fr.psi.com> <20010606104144.N12278@charizard.diameter.org> <4.3.2.7.2.20010606213833.00c21730@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010606213833.00c21730@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Wed, Jun 06, 2001 at 10:11:31PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Wed, Jun 06, 2001 at 10:11:31PM +0200, Jacques Caron wrote: > At 19:41 06/06/01, Pat Calhoun wrote: > >Well, the protocol already states that it the Destination-Realm is NOT in > >a message's ABNF, then it isn't proxiable, but perhaps something more explicit > >for dumb relays? > > I thought in some cases the Destination-Realm could be added by a proxy? :-) or modified by a proxy > > > In 9.0, what happens if there is no alternate to send the request to? > > > Should the MRA be forwarded upstream? As-is? With stuff changed > > > (Origin-Host, Hop-by-hop, End-to-End Ids...)? > > > >send back towards originator of the request. > > With what processing? Since it's supposed to be handled locally, it > probably shouldn't be forwarded as-is? Note that I think there is another > discussion on the Error-Reporting-Host AVP that would be related. Well, proxies are requested to take action, but if they cannot, the message is sent downstream towards the access device, as in any other answer message. > > > > Which raises another question: what about a Grouped AVP with M not set > > > containing AVPs with M set? Yes I know I have silly questions. > > > >that's not a problem. If any AVP has the 'M' bit set, and it isn't recognized > >then the behavior is well defined. It doesn't matter whether an AVP is > >encapsulated in a group or not. > > Not possible. Imagine a server receives an AVP it doesn't recognize, but is > not marked M. It ignores it. Bad luck, it was actually a grouped AVP (which > the server doesn't know since it doesn't recognize the AVP, and there is no > AVP type) with an AVP with M set somewhere in it. I would say one should > not be allowed to put an 'M' AVP within a non-'M' grouped AVP? ok, fair enough. Then please open an issue on this one. > > > - what's the difference between UNABLE_TO_DELIVER and NOT_SERVED? i.e. in > > > which case is which sent? > > > >I know the domain, but cannot reach any servers. I don't know the domain. > > Mmmm. Needs clarification? open issue. Again, a single issue with all of these clarification requests is sufficient. This is not intended to be too much of a burden, but we have decided that we need to track all changes going into the document, and the chairs have decided that opening an issue is the best way. and it works for me... > > > In 10.0 third paragraph, "If the server does not receive another > > > authorization request before the timeout occurs", I guess some leeway for > > > transmission and processing delays would be a good thing :-) The other > > > option is to use Authorization-Lifetime only as a "Reauth timer", and > > > Session-Timeout as the max length after which the user is to be > > > disconnected and forgotten (and even then, keeping state a tad more to > > > match the accounting stop info that is supposed to arrive would still be a > > > good idea). > > > >Sorry I don't understand. Your other option is exactly the way the protocol > >is defined. btw, I don't get the accounting stop thing. > > > >please try again... > > Well, Authorization-Lifetime is a timer for doing a Reauth. But Reauth is > not instantaneous, so everybody maintaining state (stateful proxies and > servers) should not forget about that session when Authorization-Lifetime > expires (as stated in the draft), but only when Session-Timeout expires, > which should be larger than Authorization-Lifetime. > > And for the accounting stop, if for some reason the server wants to match > that record with an existing connection (which just finished), it should > keep information about that connection a little bit longer than > Session-Timeout to make sure it's still there when the accounting stop > message arrives. > > Clearer? right which is why we have the following in the base: 10.4 Authorization-Lifetime AVP [...] If both this AVP and the Session-Timeout AVP are present in a message, the value of the latter MUST NOT be smaller than the Authorization-Lifetime AVP. > > > > In 10.3 second paragraph, an example of a reason to have multiple > > > Session-IDs in the same message would be good. > > > >The Accounting Poll command (which I believe we will eliminate), and the > >Resource Management (which is not a WG work item), as well as batched > >accounting. Since none of these are either supported by the protocol, > >or a WG work item, we can eliminate this sentence. > > Issue? yup :( > > > > In 10.7, the STR should be sent along the same path as previous requests, > > > not directly to the server (by using Origin-Host of the auth answer as > > > Destination-Host), for proxies along the way to be able to update state. > > > >hmmmm... don't know how this can be achieved. > > Just don't send it to Destination-Host, but leave it to be routed exactly > like the auth request for that session (based on Destination-Realm and the > routing tables)? We were there about a year ago, and this was removed from the protocol. > > > > More generally, again, I really find the Destination-Host AVP very > > annoying > > > and probably not very useful, except for unsollicited requests from the > > > server to the client, and even in those cases, something should be done to > > > make sure proxies along the way are aware of what's going on. The other > > use > > > would be to make sure the STR goes to the same server that authorized the > > > connection, but it should apply to all intermediate proxies/relays too, so > > > it should be based on some other mechanism. > > > > > > Anyway, in many cases it simply won't be possible to use Destination-Host > > > because of the lack of security associations between the two endpoints... > > > >I am not sure that I understand where this is leading.... > > Well, get rid of Destination-Host :-) Always do hop-by-hop routing based on > Destination-Realm. Still a problem with unsollicited requests, though, > unless the server (as well as proxies that hide topology) remembers > route-records for requests from that host, and we have source routing. Urg. Again, this was in a version of the draft, and was removed from the protocol at the request of the WG. > > > > Isn't there some redundancy between STR and an Accounting-Request with > > > type=STOP? > > > >no. Unlike RADIUS, Diameter doesn't rely on accounting messages to > >maintain state. > >The STR message is used instead. > > Maybe a note about that somewhere would be useful so that people with a > Radius background understand that? Unless it's already there and dear > precious eyes failed to take notice of it of course :-) ok. I thought that the STR made this obvious, but you are correct :) > > >Thanks again, > > Terrible what a "naïve" review of a document seemingly close to conclusion > can do, eh? Sorry about that and coming so late in the discussion. :-( Actually, such a review was *exactly* was we needed. Many of us have been too close to this for a while, and some fresh eyes helps alot. > And I'll send in all the mentionned issues. Most appreciated. PatC From owner-aaa-wg@merit.edu Wed Jun 6 18:59:54 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10299 for ; Wed, 6 Jun 2001 18:59:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 62C929131E; Wed, 6 Jun 2001 18:39:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 29F359132E; Wed, 6 Jun 2001 18:39:59 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B10D99131E for ; Wed, 6 Jun 2001 18:39:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DDD175DE01; Wed, 6 Jun 2001 18:40:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 05DD45DD8D for ; Wed, 6 Jun 2001 18:40:17 -0400 (EDT) Received: (qmail 22894 invoked by uid 500); 6 Jun 2001 22:29:26 -0000 Date: Wed, 6 Jun 2001 15:29:26 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Comments on base draft 05 Message-ID: <20010606152926.Q12278@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <4.3.2.7.2.20010605182622.00d9b4a0@pop.fr.psi.com> <4.3.2.7.2.20010605182622.00d9b4a0@pop.fr.psi.com> <20010606102138.L12278@charizard.diameter.org> <4.3.2.7.2.20010606204906.00bb3890@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010606204906.00bb3890@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Wed, Jun 06, 2001 at 10:05:17PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Jun 06, 2001 at 10:05:17PM +0200, Jacques Caron wrote: > That's where: > > > - since it doesn't know that server (in its peers list), it looks for > > > another type of RR (TBD) that points to D (might be a TXT RR giving the > > > realm for D) > > comes in. E would have some DNS RR that says "hey, if you don't know how to > talk to me directly, please see with D", either directly (some slightly > modified SRV RR) or indirectly (with a TXT RR giving the realm of D). D is > a bit like a transit provider to E in routing analogies. Same thing would > apply for finding C from D. > > And many people encode many things about business relationships in DNS > records. Most "hosting" cases (for NSes, MXes, As...) are quite evident in > DNS records. Many other business relationships are visible through BGP or > other means. > > This would allow for "universal" roaming. Anyone could roam using a NAI > very close to one's e-mail address, provided the domain has "routing" > information to get to its Radius server via the appropriate roaming > providers (that would do all the compensation stuff), without the need for > a unique (badly scalable) roaming provider (or disjoint roaming "universes"). hmmm... ok. This very topic was brought up several times in roamops (a WG that has since closed that I co-chaired with Glen Zorn), and was shot down. The reason is that a DNS request is static. DNS doesn't know who is asking and this is a very important piece of information. For example, in order for B to talk to E, it needs to go through D, but when Z wants to talk to E, it needs to go through X. So clearly, DNS cannot provide this information. > > >Options 3 and 4 have been discusses as research issues many times in the > >past few years, > >but there are plenty of additional problems that arise (e.g. looping). So, > >if someone > >believes this is necessary in the future, the protocol could be extended > >to support > >this, but as it stands, this is a fairly large new feature to add at such > >a late > >date. > > Indeed, and they are not necessarily my favorites. Just for the sake of it, > another issue is that of selection of the peer to use when two announce the > same realm. We could have local weights, MEDs, communities... ;-> ok, well this is more of a research topic, and could be investigated within the AAA WG, but once the base protocol is released. We have some pretty strict deadlines to deal with, and cannot afford to start looking at new features (in fact, the chairs have ruled out major new features at the Minn meeting). > > > In 4.5, AVP Flag rules: > > > - what about a flag that isn't in any of the MUST/MAY/SHOULD NOT/MUST NOT > > > categories for a given command? > > > - isn't there some redundancy between the "MAY encr" column and the > > > position of P? > > > >There aren't any flags that aren't in the flag rules (or rather there > >shouldn't > >be). > > Well, P often isn't in any column, and M isn't in any in Error-Message and > Error-Reporting-Host. Then these should be brought up as issues. P shouldn't be set in all AVPs, btw. Only those that are static across agents (meaning agents do not modify them in transit). > > > In 4.3/4.4, do the AVP codes in a Grouped AVP share the same scope as > > those > > > at "first level"? > > > >Sorry this seems to break my parser. Could you try again? :) > > Errrr, are the numbers assigned to AVPs within a given Grouped AVP specific > to that Grouped AVP, or should all AVP codes be unique, whether they are in > a Grouped AVP or not? They are. There is one AVP Code namespace, and it is used regardless of whether an AVP is grouped or not. > > Or, to take an example, if I have a grouped AVP (The-Famous-Host) which > contains an AVP with code 500 (The-Famous-Port), can I reuse 500 for a > "regular" AVP (which is not within my "The-Famous-Host" grouped AVP), or > within another grouped AVP (The-Not-So-Famous-Host), with a different meaning? no > > > In 5.0/5.3, it is unclear whether the Destination-Realm derivation from > > the > > > User-Name should be done only in the NAS, or can be done by any agent on > > > the way. > > > >It is intentionally unclear. There are certain cases (e.g. dial-up > >outsourcing) > >where the user-name is not know because the Diameter request is sent prior to > >the call being answered. In such an example, the Destination-Realm would be > >identified via the called (or calling number). > > Mmmm. Maybe the unclarity should be made clear then? At some point it says > it's done by the NAS, and then it's not so sure any more... Open an issue, then. > > > > In 5.0/5.3.4/5.6 > > > - the use of Destination-Host for answers quite puzzles me. There's > > > contradiction between 5.6 and 5.3.4 on how routing should be done > > (based on > > > Destination-Host or Route-Record AVPs?). Using Destination-Host in any > > case > > > would bypass relays/proxies, which would then lose the ability to track > > > state, to perform accounting (especially in a roaming environment), etc. > > > Not really sure it should ever be used? > > > > > > - even better, the Destination-Realm should probably never be used to > > > routes answers? > >MUST NOT > > Issue? Or is that already written somewhere, other than implicitly from the > way answers are supposed to be routed? If it is, it's unclear (the Message > processing section should be called "Request Processing" then, and another > section for "Answer processing" would be needed). 5.7 Destination-Realm AVP The Destination-Realm AVP (AVP Code 283) is of type UTF8String, and contains the realm the message is to be routed to. The Destination- Realm AVP MUST NOT be present in Answer messages. [...] > > > > - loops should be checked > > > >Now sure why.... > > A sends request to B. B says "redirect to C". What if: > - C is A Then A would presumably notice that it is being told to redirect to itself. > - C is B Then B is clearly broken... > - C is a host in the route-records? Then when routing, this will be discovered. Additional text could be added, as you state, but these are strange problems that would be detected regardless. > > > > In 5.3.3/5.0, loop checking should be done upon receipt of a message? > > > >Not sure that I understand the question... > > Instead of doing loop checking when sending a forwarded message, it might > be simpler to always do it when the message is received (in any context: > server, proxy, relay, redirect... as a given agent might assume different > roles anyway). This depends a bit on exactly how Route-Record is handled, > though (i.e. whether even a client should include it). ok, but that would cause one to add a Route-Record even when the message is locally processed. That would be most odd. > > > > In 5.3.4, the agent sending an STR "on behalf of the access device" is a > > > violation of 5.4? > > > >On behalf doesn't mean that the Origin-Host is to be set to the access > >device's > >identity. Of course, this would be broken. When sending a message, the > >Origin-Host > >AVP is always to the local identity. > > > >Am I missing something? > > Then what does the "on behalf of" mean? What exactly is set as if it was > the access device sending it? The agent sends it, not the access device. I will change the words, if you could create an issue (or amend the one you've already sent) > > > In 5.8, isn't there some redundancy between Route-Record and Proxy-Host? > > > >Yes, and I had been thinking about how to add the proxy info to the > >Route-Record, > >but doing so would require that the Route-Record be a Grouped AVP, which has > >additional processing requirements, and I prefer to keep the Route-Record > >AVP as simple as possible. For proxies that insist on distributing their state > >across the network, let them deal with the added cost of adding an AVP. > > Mmmm. Should that be an issue? I'd prefer not, but if you insist, we can let the WG decide. From owner-aaa-wg@merit.edu Wed Jun 6 19:34:06 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10612 for ; Wed, 6 Jun 2001 19:34:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 12D9B91322; Wed, 6 Jun 2001 19:34:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D254E91324; Wed, 6 Jun 2001 19:34:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AA29B91322 for ; Wed, 6 Jun 2001 19:34:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E91145DDAD; Wed, 6 Jun 2001 19:34:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (unknown [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 053085DD8D for ; Wed, 6 Jun 2001 19:34:27 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id TAA07050; Wed, 6 Jun 2001 19:33:59 -0400 (EDT) Date: Wed, 6 Jun 2001 19:34:19 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: Cain Brian-BCAIN1 Cc: Pat Calhoun , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Support for multi-process In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B0ECF26@IL27EXM10.cig.mot.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Brian, Thanks for the comments. I think this state table will work well for TCP, but Tony Johansson demonstrated that this state table may not work well for SCTP (see Issue #67: How to deal with CER and CEA in the case of SCTP). I'll have to think about that. As to your comment about waiting until all state machines know the identity of the peer they're connected to, I think that could cause a deadlock. If you have two peers (P1 and P2) attempting to connect at exactly the same time, you will have an initiated and responding state machine for each. P1-I sends a CER and P1-R has just received a CER. P2-I sends a CER and P1-R has just received a CER. The state machine of P1-I does not know the Diameter-Identifier of P2 so an election can't happen on P1. The same thing is happening on P2. Deadlock. Let me try to explain the logic behind the locking mechanism. Consider the following time-line. ________Conversation A________ ________Conversation B________ Time P1-I P2-R P1-R P2-I 1 Start 2 Rcv-Conn-Req 3 Start Rcv-Conn-Ack 4 Rcv-CER 5 Locked 6 Rcv-Conn-Req Elect 7 Rcv-Conn-Ack No-Contest 8 Rcv-CER * Rcv-CEA * 9 Elect Elect This is the point where there is a problem without locking. Both P2-R and P2-I are not aware that the other has made a connection at exactly the same time. Since they will be changing the same state machine at exactly the same time, who knows what will happen. As far as I can tell, there is only one minor way this could go wrong without locking. That is when they both think they succeeded. If that happens, P2 could assume that there are two simultaneous connections. This should only last a brief moment. After P2-R sends the CEA, P1-I will have an election and disconnect one of the connections. Maybe this is an implementation detail and doesn't need to be a part of the state machine. Maybe some text warning of this is sufficient without the need of a state machine. Do you have an opinion? -mark On Wed, 6 Jun 2001, Cain Brian-BCAIN1 wrote: > > -----Original Message----- > > From: Mark Eklund [mailto:meklund@cisco.com] > > Sent: Wednesday, June 06, 2001 9:40 AM > > > > Brian, > ... > > process and are listed below. Could you give your O.K. on > > those? > > Hmmm..I never got a chance to go over the last version in detail, so here's > my comments on the revised version: > > I'm relieved to say that it seems simpler than the previous version (the one > w/"Wait-R-DRI/Elect", etc., not your previous suggestion). > > I like the new election scheme, it answers some questions I had. I think > the only suggestion I could offer would be some text that would advise > Election implementations to wait until all state machines know the identity > of the peer they're connected to (i.e. wait until they've received the Cap. > Exchange) before returning a "No Contest" verdict. Maybe it's restating the > obvious (or overstepping the bounds of the doc), maybe not... > > Why do we lock on the Election? Am I correct in assuming that each > transport connection/state machine performs its own election? Why is it bad > to have two concurrent elections? This kinda makes sense, but I must just > be missing something. (Does it relate to the above comment about waiting > for the CE message, maybe?) > > PS - Terminology update: Device Reboot -> Capabilities Exchange > (s/DR(R|A)/CE$1/g). (Also pertains to "*-Non-DRI" events, etc.) > > -Brian > From owner-aaa-wg@merit.edu Wed Jun 6 19:37:07 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10634 for ; Wed, 6 Jun 2001 19:37:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4F8AC91324; Wed, 6 Jun 2001 19:37:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1CDD691325; Wed, 6 Jun 2001 19:37:03 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DEAC591324 for ; Wed, 6 Jun 2001 19:37:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 19A4C5DDAD; Wed, 6 Jun 2001 19:37:26 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 8B3E45DD8D for ; Wed, 6 Jun 2001 19:37:25 -0400 (EDT) Received: (qmail 23495 invoked by uid 500); 6 Jun 2001 23:26:35 -0000 Date: Wed, 6 Jun 2001 16:26:35 -0700 From: Pat Calhoun To: Mark Eklund Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Proposed fix for issues 26, 38 and 48 Message-ID: <20010606162635.V12278@charizard.diameter.org> Mail-Followup-To: Mark Eklund , Pat Calhoun , aaa-wg@merit.edu References: <20010605084925.M22616@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from meklund@cisco.com on Tue, Jun 05, 2001 at 04:05:17PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Jun 05, 2001 at 04:05:17PM -0400, Mark Eklund wrote: > Pat, > Two thoughts. > > On Tue, 5 Jun 2001, Pat Calhoun wrote: > > > > > All, > > > > Here is my proposed fix for issues 26, 38 and 48. This proposed text is > > similar to Mark's text earlier this week, but also addresses other issues. > > > > PatC > > ---- > > > > 10.12 Session-Binding AVP > > > > The Session-Binding AVP (AVP Code TBD) is of type Unsigned32, and MAY > > be present in application-specific authorization answer messages. If > > present, this AVP MAY inform the Diameter client that all future > > application-specific re-auth messages for this session MUST be sent > > to the same authorization server. This AVP MAY also specify that a > > Session-Termination-Request message for this session > > MUST be sent to the same authorizing server. The following values > > are supported: > > > > DONT_CARE 0 > > The Destination-Host AVP does not need to be present in future > > re-auth and STR messages for this session. > > > > RE_AUTH_ONLY 1 > > The Destination-Host AVP in future re-auth messages for this > > session MUST be set to the value of the Origin-Host AVP in the > > authorization answer message. > > > > STR_ONLY 2 > > The Destination-Host AVP in Session-Termination-Request message > > for this session MUST be set to the value of the Origin-Host > > AVP in the authorization answer message. > > > > 1. If the AVP is not present, is the default DO_BOTH? No, if absent, default is DONT_CARE. I will add clarifying text. > > > DO_BOTH 3 > > The Destination-Host AVP in future re-auth and the Session- > > Termination-Request message for this session MUST be set to the > > value of the Origin-Host AVP in the authorization answer > > message. > > > > > > 10.13 Session-Server-Failover AVP > > > > The Session-Server-Failover AVP (AVP Code TBD) is of type Unsigned32, > > and MAY be present in application-specific authorization answer > > messages that include the Session-Binding AVP with a non-zero value. > > If present, this AVP MAY inform the Diameter client that if a re-auth > > or STR message fails due to a delivery problem, the Diameter client > > SHOULD issue a subsequent message without the Destination-Host AVP. > > > > REFUSE_SERVICE 0 > > If either the re-auth or the STR message delivery fails, > > terminate service with the user, and do not attempt any > > subsequent attempts. > > > > TRY_AGAIN 1 > > If either the re-auth or the STR message delivery fails, resend > > the failed message without the Destination-Host AVP present. > > 2. If the AVP is not sent, is the default REFUSE_SERVICE? yes. new text will be added. > 3. Any possibility of adding the below two? > > ALLOW_SERVICE 2 > If re-auth message delivery fails, assume that re-authorization > succeeded. If STR message delivery fails, terminate > the session. > > TRY_AGAIN_ALLOW_SERVICE 3 > If either the re-auth or the STR message delivery fails, resend > the failed message without the Destination-Host AVP > present. If the second delivery fails for re-auth, > assume re-authorization succeeded. If the second > delivery fails for STR, terminate the session. ok. PatC > -mark > > From owner-aaa-wg@merit.edu Wed Jun 6 19:56:24 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10769 for ; Wed, 6 Jun 2001 19:56:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2445691326; Wed, 6 Jun 2001 19:48:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BA60C91329; Wed, 6 Jun 2001 19:47:29 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6215791326 for ; Wed, 6 Jun 2001 19:47:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 999D75DDAD; Wed, 6 Jun 2001 19:47:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 4017E5DD8D for ; Wed, 6 Jun 2001 19:47:47 -0400 (EDT) Received: (qmail 23527 invoked by uid 500); 6 Jun 2001 23:36:56 -0000 Date: Wed, 6 Jun 2001 16:36:56 -0700 From: Pat Calhoun To: Mark Eklund Cc: Cain Brian-BCAIN1 , Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Support for multi-process Message-ID: <20010606163656.W12278@charizard.diameter.org> Mail-Followup-To: Mark Eklund , Cain Brian-BCAIN1 , Pat Calhoun , aaa-wg@merit.edu References: <35DBB8B7AC89D4118E98009027B1009B0ECF26@IL27EXM10.cig.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from meklund@cisco.com on Wed, Jun 06, 2001 at 07:34:19PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Jun 06, 2001 at 07:34:19PM -0400, Mark Eklund wrote: [lots of great stuff deleted] > Do you have an > opinion? I do. We seem to be going out of our way to ensure that we only have a single connection, but both Bernard, and others, have indicated that multiple connections MAY be necessary (at least for TCP). So given that SCTP will handle the case where two connections occur simultaneously, is this all now overkill? :( PatC > > -mark > > On Wed, 6 Jun 2001, Cain Brian-BCAIN1 wrote: > > > > -----Original Message----- > > > From: Mark Eklund [mailto:meklund@cisco.com] > > > Sent: Wednesday, June 06, 2001 9:40 AM > > > > > > Brian, > > ... > > > process and are listed below. Could you give your O.K. on > > > those? > > > > Hmmm..I never got a chance to go over the last version in detail, so here's > > my comments on the revised version: > > > > I'm relieved to say that it seems simpler than the previous version (the one > > w/"Wait-R-DRI/Elect", etc., not your previous suggestion). > > > > I like the new election scheme, it answers some questions I had. I think > > the only suggestion I could offer would be some text that would advise > > Election implementations to wait until all state machines know the identity > > of the peer they're connected to (i.e. wait until they've received the Cap. > > Exchange) before returning a "No Contest" verdict. Maybe it's restating the > > obvious (or overstepping the bounds of the doc), maybe not... > > > > Why do we lock on the Election? Am I correct in assuming that each > > transport connection/state machine performs its own election? Why is it bad > > to have two concurrent elections? This kinda makes sense, but I must just > > be missing something. (Does it relate to the above comment about waiting > > for the CE message, maybe?) > > > > PS - Terminology update: Device Reboot -> Capabilities Exchange > > (s/DR(R|A)/CE$1/g). (Also pertains to "*-Non-DRI" events, etc.) > > > > -Brian > > > > > From owner-aaa-wg@merit.edu Thu Jun 7 09:19:01 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06548 for ; Thu, 7 Jun 2001 09:19:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 215A691345; Thu, 7 Jun 2001 09:18:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CB38291344; Thu, 7 Jun 2001 09:18:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0805591345 for ; Thu, 7 Jun 2001 09:18:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 601835DE1E; Thu, 7 Jun 2001 09:19:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp014.mail.yahoo.com (smtp014.mail.yahoo.com [216.136.173.58]) by segue.merit.edu (Postfix) with SMTP id D9C9B5DD8C for ; Thu, 7 Jun 2001 09:19:07 -0400 (EDT) Received: from ip-74.lan.psi.calva.net (HELO jc.yahoo.com) (195.134.197.74) by smtp.mail.vip.sc5.yahoo.com with SMTP; 7 Jun 2001 13:18:44 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010606223429.00bf9100@pop.fr.psi.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Jun 2001 23:26:58 +0200 To: aaa-wg@merit.edu From: Jacques Caron Subject: [AAA-WG]: [Issue] Caching of redirects Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Jacques Caron Submitter email address: jacques_m_caron@yahoo.com Date first submitted: 06-Jun-2001 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg01150.html Document: Base Comment type: T Priority: 2 Section: 2.5.3 Redirector Agents Rationale/Explanation of issue: jc> Can a server that received a redirect cache the result (e.g. based on realm+application)? pc> yes, and this should probably be discussed in the base draft. jc> additional info: what should be the key for the cache? realm+application only? What if the redirect was based on some other information? What if the redirector acts as a load balancer? I'm personally against caching (unless the redirector explicitly allows it maybe?). If caching is allowed, there should be guidelines for expiration. Requested change: Text to be added for clarification. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Thu Jun 7 09:19:23 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06565 for ; Thu, 7 Jun 2001 09:19:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E0D9E91347; Thu, 7 Jun 2001 09:18:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 60A4591346; Thu, 7 Jun 2001 09:18:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 57B4A91344 for ; Thu, 7 Jun 2001 09:18:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A260C5DE1E; Thu, 7 Jun 2001 09:19:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp014.mail.yahoo.com (smtp014.mail.yahoo.com [216.136.173.58]) by segue.merit.edu (Postfix) with SMTP id 280C25DD8C for ; Thu, 7 Jun 2001 09:19:07 -0400 (EDT) Received: from ip-74.lan.psi.calva.net (HELO jc.yahoo.com) (195.134.197.74) by smtp.mail.vip.sc5.yahoo.com with SMTP; 7 Jun 2001 13:18:46 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010606232708.00c12ae0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Jun 2001 23:37:52 +0200 To: aaa-wg@merit.edu From: Jacques Caron Subject: [AAA-WG]: [Issue] ABNF editorial changes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Jacques Caron Submitter email address: jacques_m_caron@yahoo.com Date first submitted: 06-Jun-2001 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg01150.html Document: Base Comment type: E Priority: 2 Section: 3.2 Command code ABNF specification Rationale/Explanation of issue: - "fixed" isn't defined. It seems to mean that it is required, but at a specific position or in a specific order, but that's really unclear. - the defaults for min & max in qual are not defined if only one of them is present (i.e. no qual = 1*1, but what about *n or n*? I guess the latter means n*infinity, but does *n mean 1*n or 0*n)? - it says that it describes AVPs which MUST NOT be present, but that's not part of the ABNF (it's implicit). Requested change: [add following text under definition of fixed] ; defines AVPs the position and order of which is fixed, ; either at the start or at the AVP list [add following text under definition of min and associated comments] ; default is 0 [add following text under definition of max and associated comments] ; default is infinity for resolution of the MUST NOT issue, either: - replace MUST, MAY or MUST NOT by MUST or MAY in first paragraph - add a specific notation: forbidden = "%" avp-spec "%" - or add text under qual: ; 0*0 means the AVP is not allowed in this command _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Thu Jun 7 09:32:34 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06973 for ; Thu, 7 Jun 2001 09:32:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E53BA91346; Thu, 7 Jun 2001 09:32:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9392391344; Thu, 7 Jun 2001 09:32:25 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 11A2B91348 for ; Thu, 7 Jun 2001 09:32:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 694E05DE20; Thu, 7 Jun 2001 09:32:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from hip.baltimore.ie (unknown [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id 681815DD8C for ; Thu, 7 Jun 2001 09:32:46 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by hip.baltimore.ie (8.9.3/8.9.3) with SMTP id OAA13616 for ; Thu, 7 Jun 2001 14:32:26 +0100 Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.1) with SMTP id for ; Thu, 7 Jun 2001 14:30:34 +0100 Received: from baltimore.ie (ip226-24.ie.baltimore.com [10.153.24.226]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id OAA31287; Thu, 7 Jun 2001 14:39:56 +0100 Message-ID: <3B1F826C.45351D32@baltimore.ie> Date: Thu, 07 Jun 2001 14:32:28 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: Jari Arkko , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 60: E2E cert names References: <20010605071737.G22616@charizard.diameter.org> <3B1DF277.1CDC16F2@lmf.ericsson.se> <20010606064128.Z12278@charizard.diameter.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit The -diameter naming is intended to make it easier to use an existing CA for Diameter, as pointed out below, it means that a Diameter node won't accidentally accept e.g. an end user's email certificate. I don't believe there's any problem if you also want to use the same certificate for other purposes as well, since a single certificate can contain as many subjectAltName extensions as the CA likes to put there. All the Diameter node has to check is that -diameter@ is present as any one of the alt names. In other words, its a CA operational issue whether the certs used for Diamater E2E are usable for other purposes, which is, I think, the correct approach. Stephen. > > [...] Therefore, what this spec > > really means that is that a Diameter client doesn't by > > accident accept the certificate of the ISP's web server > > even if the web server and the AAA server use the same > > CA. But a web client could accept the AAA server's > > certificate. > > > > I suppose the spec is fine; having a specific naming in the > > certificates shouldn't be that much of an issue and it > > does buy _some_ level of additional ease as the same CA > > can be used for different purposes. The only drawback is > > that in some cases additional certificates may have to > > be manufactured for a node, for instance to support VPN > > layer and application layer authentication, and Diameter. > > However, since currently we don't have similar naming > > constraints on other areas it could still be that e.g. > > a SIP proxy would use a Diameter certificate with the > > name "proxy-diameter@telco.com" in Diameter, IPsec, and > > SIP layer operations. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Thu Jun 7 09:47:20 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07197 for ; Thu, 7 Jun 2001 09:47:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 09473913BC; Thu, 7 Jun 2001 09:47:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D0938913C1; Thu, 7 Jun 2001 09:47:16 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 49179913BC for ; Thu, 7 Jun 2001 09:47:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8D2395DE1E; Thu, 7 Jun 2001 09:47:39 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 8BB075DD8C for ; Thu, 7 Jun 2001 09:47:38 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f57DlEN23920; Thu, 7 Jun 2001 15:47:14 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f57DlE513087; Thu, 7 Jun 2001 16:47:14 +0300 (EET DST) Message-ID: <3B1F85E1.1C91DD1B@lmf.ericsson.se> Date: Thu, 07 Jun 2001 16:47:13 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: stephen.farrell@baltimore.ie Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 60: E2E cert names References: <20010605071737.G22616@charizard.diameter.org> <3B1DF277.1CDC16F2@lmf.ericsson.se> <20010606064128.Z12278@charizard.diameter.org> <3B1F826C.45351D32@baltimore.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Stephen Farrell wrote: > same certificate for other purposes as well, since a single > certificate can contain as many subjectAltName extensions as > the CA likes to put there. All the Diameter node has to check > is that -diameter@ is present as any one of the alt > names. In other words, its a CA operational issue whether Sounds good. I think we can then close this issue, though some clarifying text would perhaps be useful in the draft. jari From owner-aaa-wg@merit.edu Thu Jun 7 09:52:33 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07349 for ; Thu, 7 Jun 2001 09:52:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DDEDA913C1; Thu, 7 Jun 2001 09:52:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B0EC7913C8; Thu, 7 Jun 2001 09:52:27 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7D023913C1 for ; Thu, 7 Jun 2001 09:52:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D30655DE1E; Thu, 7 Jun 2001 09:52:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (unknown [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id E6B875DD8C for ; Thu, 7 Jun 2001 09:52:50 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA10902; Thu, 7 Jun 2001 09:52:21 -0400 (EDT) Date: Thu, 7 Jun 2001 09:52:43 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: Pat Calhoun Cc: Cain Brian-BCAIN1 , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Support for multi-process In-Reply-To: <20010606163656.W12278@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Pat, On Wed, 6 Jun 2001, Pat Calhoun wrote: > On Wed, Jun 06, 2001 at 07:34:19PM -0400, Mark Eklund wrote: > [lots of great stuff deleted] > > Do you have an > > opinion? > > I do. We seem to be going out of our way to ensure that we only have a single > connection, but both Bernard, and others, have indicated that multiple connections > MAY be necessary (at least for TCP). Are you talking about a connection to two different processes on the same server? Are you saying that there will be two (or more) connections to the same process on the same server? Is this for redundancy? I.E. connect through two interfaces so if one goes down, the connection still exists. > > So given that SCTP will handle the case where two connections occur simultaneously, > is this all now overkill? > This helps distinguish two things for TCP. 1. Server A and Server B simultaneously connecting to each other. 2. Multiple processes connecting to Server B. Depending upon the answers to my previous questions, this may be overkill. Or it might be the wrong state table that needs to be replaced by a new one that is equally complex. -mark > :( > > PatC > > > > -mark > > > > On Wed, 6 Jun 2001, Cain Brian-BCAIN1 wrote: > > > > > > -----Original Message----- > > > > From: Mark Eklund [mailto:meklund@cisco.com] > > > > Sent: Wednesday, June 06, 2001 9:40 AM > > > > > > > > Brian, > > > ... > > > > process and are listed below. Could you give your O.K. on > > > > those? > > > > > > Hmmm..I never got a chance to go over the last version in detail, so here's > > > my comments on the revised version: > > > > > > I'm relieved to say that it seems simpler than the previous version (the one > > > w/"Wait-R-DRI/Elect", etc., not your previous suggestion). > > > > > > I like the new election scheme, it answers some questions I had. I think > > > the only suggestion I could offer would be some text that would advise > > > Election implementations to wait until all state machines know the identity > > > of the peer they're connected to (i.e. wait until they've received the Cap. > > > Exchange) before returning a "No Contest" verdict. Maybe it's restating the > > > obvious (or overstepping the bounds of the doc), maybe not... > > > > > > Why do we lock on the Election? Am I correct in assuming that each > > > transport connection/state machine performs its own election? Why is it bad > > > to have two concurrent elections? This kinda makes sense, but I must just > > > be missing something. (Does it relate to the above comment about waiting > > > for the CE message, maybe?) > > > > > > PS - Terminology update: Device Reboot -> Capabilities Exchange > > > (s/DR(R|A)/CE$1/g). (Also pertains to "*-Non-DRI" events, etc.) > > > > > > -Brian > > > > > > > > > > From owner-aaa-wg@merit.edu Thu Jun 7 10:16:25 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07817 for ; Thu, 7 Jun 2001 10:16:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 45746913CD; Thu, 7 Jun 2001 10:15:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1854D913CE; Thu, 7 Jun 2001 10:15:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C86EC913CD for ; Thu, 7 Jun 2001 10:15:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3AEAF5DE1B; Thu, 7 Jun 2001 10:16:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id D2E6C5DD8C for ; Thu, 7 Jun 2001 10:16:07 -0400 (EDT) Received: (qmail 26926 invoked by uid 500); 7 Jun 2001 14:05:14 -0000 Date: Thu, 7 Jun 2001 07:05:14 -0700 From: Pat Calhoun To: Mark Eklund Cc: Pat Calhoun , Cain Brian-BCAIN1 , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Support for multi-process Message-ID: <20010607070513.A12278@charizard.diameter.org> Mail-Followup-To: Mark Eklund , Pat Calhoun , Cain Brian-BCAIN1 , aaa-wg@merit.edu References: <20010606163656.W12278@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from meklund@cisco.com on Thu, Jun 07, 2001 at 09:52:43AM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, Jun 07, 2001 at 09:52:43AM -0400, Mark Eklund wrote: > Pat, > > On Wed, 6 Jun 2001, Pat Calhoun wrote: > > > On Wed, Jun 06, 2001 at 07:34:19PM -0400, Mark Eklund wrote: > > [lots of great stuff deleted] > > > Do you have an > > > opinion? > > > > I do. We seem to be going out of our way to ensure that we only have a single > > connection, but both Bernard, and others, have indicated that multiple connections > > MAY be necessary (at least for TCP). > > Are you talking about a connection to two different processes on > the same server? > > Are you saying that there will be two (or more) connections to > the same process on the same server? > > Is this for redundancy? I.E. connect through two interfaces so > if one goes down, the connection still exists. No. For TCP, they want to simulate streams by opening multiple connections. People have stated on the list that they want this functionality, as has Bernard and it is included in the transports draft. > > > > > So given that SCTP will handle the case where two connections occur simultaneously, > > is this all now overkill? > > > > This helps distinguish two things for TCP. > 1. Server A and Server B simultaneously connecting to each other. > 2. Multiple processes connecting to Server B. > > Depending upon the answers to my previous questions, this may be > overkill. Or it might be the wrong state table that needs to be > replaced by a new one that is equally complex. So the way that the transport draft is written is that multiple connections may exist, and they may be maintained. However, after some time, if the connection is deemed to be unnecessary, it can be closed. PatC From owner-aaa-wg@merit.edu Thu Jun 7 10:20:37 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07860 for ; Thu, 7 Jun 2001 10:20:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 71518913CF; Thu, 7 Jun 2001 10:20:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2E039913D0; Thu, 7 Jun 2001 10:20:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E20DB913CF for ; Thu, 7 Jun 2001 10:20:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 59EE75DE20; Thu, 7 Jun 2001 10:21:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id C3EE65DE1E for ; Thu, 7 Jun 2001 10:21:06 -0400 (EDT) Received: (qmail 27040 invoked by uid 500); 7 Jun 2001 14:10:13 -0000 Date: Thu, 7 Jun 2001 07:10:13 -0700 From: Pat Calhoun To: Jari Arkko Cc: stephen.farrell@baltimore.ie, Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 60: E2E cert names Message-ID: <20010607071013.C12278@charizard.diameter.org> Mail-Followup-To: Jari Arkko , stephen.farrell@baltimore.ie, Pat Calhoun , aaa-wg@merit.edu References: <20010605071737.G22616@charizard.diameter.org> <3B1DF277.1CDC16F2@lmf.ericsson.se> <20010606064128.Z12278@charizard.diameter.org> <3B1F826C.45351D32@baltimore.ie> <3B1F85E1.1C91DD1B@lmf.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B1F85E1.1C91DD1B@lmf.ericsson.se>; from Jari.Arkko@lmf.ericsson.se on Thu, Jun 07, 2001 at 04:47:13PM +0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, Jun 07, 2001 at 04:47:13PM +0300, Jari Arkko wrote: > > same certificate for other purposes as well, since a single > > certificate can contain as many subjectAltName extensions as > > the CA likes to put there. All the Diameter node has to check > > is that -diameter@ is present as any one of the alt > > names. In other words, its a CA operational issue whether > > Sounds good. I think we can then close this issue, though > some clarifying text would perhaps be useful in the draft. Then I suggest that we do not close this one until we get some clarifying text. PatC From owner-aaa-wg@merit.edu Thu Jun 7 10:21:55 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07891 for ; Thu, 7 Jun 2001 10:21:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E24F7913D0; Thu, 7 Jun 2001 10:21:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AB108913D1; Thu, 7 Jun 2001 10:21:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 732CE913D0 for ; Thu, 7 Jun 2001 10:21:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DD8E55DE24; Thu, 7 Jun 2001 10:22:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 4B19A5DE1E for ; Thu, 7 Jun 2001 10:22:18 -0400 (EDT) Received: (qmail 27057 invoked by uid 500); 7 Jun 2001 14:11:25 -0000 Date: Thu, 7 Jun 2001 07:11:25 -0700 From: Pat Calhoun To: Jacques Caron Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] ABNF editorial changes Message-ID: <20010607071125.D12278@charizard.diameter.org> Mail-Followup-To: Jacques Caron , aaa-wg@merit.edu References: <4.3.2.7.2.20010606232708.00c12ae0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010606232708.00c12ae0@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Wed, Jun 06, 2001 at 11:37:52PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Jun 06, 2001 at 11:37:52PM +0200, Jacques Caron wrote: > Submitter name: Jacques Caron [...] Thanks for the submission. The web page has been updated, and I consider this one closed since I've already addressed the necessary text which will appear in the next revision of the draft. Thanks for your help! PatC From owner-aaa-wg@merit.edu Thu Jun 7 11:33:02 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08803 for ; Thu, 7 Jun 2001 11:33:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5C65B9134A; Thu, 7 Jun 2001 11:32:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2DA099134C; Thu, 7 Jun 2001 11:32:59 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5577E9134A for ; Thu, 7 Jun 2001 11:32:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BFB9D5DDC1; Thu, 7 Jun 2001 11:33:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from redmailwall2.attws.com (redmailwall2.attws.com [199.108.253.116]) by segue.merit.edu (Postfix) with ESMTP id 344D95DD8D for ; Thu, 7 Jun 2001 11:33:19 -0400 (EDT) Received: from viruswall1.entp.attws.com (viruswall1.entp.attws.com [135.214.40.161]) by redmailwall2.attws.com (8.9.3/8.9.3) with ESMTP id IAA18825; Thu, 7 Jun 2001 08:30:23 -0700 (PDT) Received: from neastmail.neast.attws.com by viruswall1.entp.attws.com (8.8.8+Sun/AT&T Wireless Services, Inc. V8 version 2) id IAA17960; Thu, 7 Jun 2001 08:32:16 -0700 (PDT) Received: from ner-msgbh.wireless.attws.com (ner-msgbh.wireless.attws.com [135.216.177.192]) by neastmail.neast.attws.com (8.8.8+Sun/8.8.8) with ESMTP id IAA06937; Thu, 7 Jun 2001 08:32:14 -0700 (PDT) Received: by ner-msgbh.wireless.attws.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 11:32:12 -0400 Message-ID: <0D3BDFD96647D211B43A00805F15E589050868B1@ner-msg03.wireless.attws.com> From: "Kobylarz, Thaddeus" To: "'Pat Calhoun'" , Mark Eklund Cc: Cain Brian-BCAIN1 , aaa-wg@merit.edu, "Molchan, John" , "Engelhart, Bob" Subject: RE: [AAA-WG]: Support for multi-process Date: Thu, 7 Jun 2001 11:32:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Folks, I am concerned that a single connection limitation may interfere with using Diameter as a 3GPP charging protocol. I hope that either I don't totally understand this discussion or that no such limitation is planned. Thad -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Wednesday, June 06, 2001 7:37 PM To: Mark Eklund Cc: Cain Brian-BCAIN1; Pat Calhoun; aaa-wg@merit.edu Subject: Re: [AAA-WG]: Support for multi-process On Wed, Jun 06, 2001 at 07:34:19PM -0400, Mark Eklund wrote: [lots of great stuff deleted] > Do you have an > opinion? I do. We seem to be going out of our way to ensure that we only have a single connection, but both Bernard, and others, have indicated that multiple connections MAY be necessary (at least for TCP). So given that SCTP will handle the case where two connections occur simultaneously, is this all now overkill? :( PatC > > -mark > > On Wed, 6 Jun 2001, Cain Brian-BCAIN1 wrote: > > > > -----Original Message----- > > > From: Mark Eklund [mailto:meklund@cisco.com] > > > Sent: Wednesday, June 06, 2001 9:40 AM > > > > > > Brian, > > ... > > > process and are listed below. Could you give your O.K. on > > > those? > > > > Hmmm..I never got a chance to go over the last version in detail, so here's > > my comments on the revised version: > > > > I'm relieved to say that it seems simpler than the previous version (the one > > w/"Wait-R-DRI/Elect", etc., not your previous suggestion). > > > > I like the new election scheme, it answers some questions I had. I think > > the only suggestion I could offer would be some text that would advise > > Election implementations to wait until all state machines know the identity > > of the peer they're connected to (i.e. wait until they've received the Cap. > > Exchange) before returning a "No Contest" verdict. Maybe it's restating the > > obvious (or overstepping the bounds of the doc), maybe not... > > > > Why do we lock on the Election? Am I correct in assuming that each > > transport connection/state machine performs its own election? Why is it bad > > to have two concurrent elections? This kinda makes sense, but I must just > > be missing something. (Does it relate to the above comment about waiting > > for the CE message, maybe?) > > > > PS - Terminology update: Device Reboot -> Capabilities Exchange > > (s/DR(R|A)/CE$1/g). (Also pertains to "*-Non-DRI" events, etc.) > > > > -Brian > > > > > From owner-aaa-wg@merit.edu Thu Jun 7 11:46:22 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09007 for ; Thu, 7 Jun 2001 11:46:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 93BDB913D8; Thu, 7 Jun 2001 11:44:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 50C02913D9; Thu, 7 Jun 2001 11:44:56 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D75C8913D8 for ; Thu, 7 Jun 2001 11:44:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 67EB55DE1E; Thu, 7 Jun 2001 11:45:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 097D55DDAF for ; Thu, 7 Jun 2001 11:45:17 -0400 (EDT) Received: (qmail 28084 invoked by uid 500); 7 Jun 2001 15:34:23 -0000 Date: Thu, 7 Jun 2001 08:34:22 -0700 From: Pat Calhoun To: "Kobylarz, Thaddeus" Cc: "'Pat Calhoun'" , Mark Eklund , Cain Brian-BCAIN1 , aaa-wg@merit.edu, "Molchan, John" , "Engelhart, Bob" Subject: Re: [AAA-WG]: Support for multi-process Message-ID: <20010607083422.G12278@charizard.diameter.org> Mail-Followup-To: "Kobylarz, Thaddeus" , 'Pat Calhoun' , Mark Eklund , Cain Brian-BCAIN1 , aaa-wg@merit.edu, "Molchan, John" , "Engelhart, Bob" References: <0D3BDFD96647D211B43A00805F15E589050868B1@ner-msg03.wireless.attws.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0D3BDFD96647D211B43A00805F15E589050868B1@ner-msg03.wireless.attws.com>; from thaddeus.kobylarz@attws.com on Thu, Jun 07, 2001 at 11:32:05AM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, Jun 07, 2001 at 11:32:05AM -0400, Kobylarz, Thaddeus wrote: > Folks, > I am concerned that a single connection limitation may interfere > with using Diameter as a 3GPP charging protocol. I hope that either I don't > totally understand this discussion or that no such limitation is planned. I suspect that you don't understand the discussion. The general idea is to allow two Diameter processes to communicate over several transport connections. The protocol behavior is the same, and could be used for 3GPP charging, regardless of the outcome of this particular thread. However, what it would do is reduce the possibility for packets to be held up at the transport layer waiting for a retransmission from its peer. Thanks, PatC > Thad > > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Wednesday, June 06, 2001 7:37 PM > To: Mark Eklund > Cc: Cain Brian-BCAIN1; Pat Calhoun; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Support for multi-process > > > On Wed, Jun 06, 2001 at 07:34:19PM -0400, Mark Eklund wrote: > [lots of great stuff deleted] > > Do you have an > > opinion? > > I do. We seem to be going out of our way to ensure that we only have a > single > connection, but both Bernard, and others, have indicated that multiple > connections > MAY be necessary (at least for TCP). > > So given that SCTP will handle the case where two connections occur > simultaneously, > is this all now overkill? > > :( > > PatC > > > > -mark > > > > On Wed, 6 Jun 2001, Cain Brian-BCAIN1 wrote: > > > > > > -----Original Message----- > > > > From: Mark Eklund [mailto:meklund@cisco.com] > > > > Sent: Wednesday, June 06, 2001 9:40 AM > > > > > > > > Brian, > > > ... > > > > process and are listed below. Could you give your O.K. on > > > > those? > > > > > > Hmmm..I never got a chance to go over the last version in detail, so > here's > > > my comments on the revised version: > > > > > > I'm relieved to say that it seems simpler than the previous version (the > one > > > w/"Wait-R-DRI/Elect", etc., not your previous suggestion). > > > > > > I like the new election scheme, it answers some questions I had. I > think > > > the only suggestion I could offer would be some text that would advise > > > Election implementations to wait until all state machines know the > identity > > > of the peer they're connected to (i.e. wait until they've received the > Cap. > > > Exchange) before returning a "No Contest" verdict. Maybe it's restating > the > > > obvious (or overstepping the bounds of the doc), maybe not... > > > > > > Why do we lock on the Election? Am I correct in assuming that each > > > transport connection/state machine performs its own election? Why is it > bad > > > to have two concurrent elections? This kinda makes sense, but I must > just > > > be missing something. (Does it relate to the above comment about > waiting > > > for the CE message, maybe?) > > > > > > PS - Terminology update: Device Reboot -> Capabilities Exchange > > > (s/DR(R|A)/CE$1/g). (Also pertains to "*-Non-DRI" events, etc.) > > > > > > -Brian > > > > > > > > > From owner-aaa-wg@merit.edu Thu Jun 7 12:14:47 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09586 for ; Thu, 7 Jun 2001 12:14:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7F5219134C; Thu, 7 Jun 2001 11:37:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2A33D913D2; Thu, 7 Jun 2001 11:37:17 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EE04B9134C for ; Thu, 7 Jun 2001 11:37:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 711D85DDC1; Thu, 7 Jun 2001 11:37:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from hip.baltimore.ie (unknown [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id D52CF5DD8D for ; Thu, 7 Jun 2001 11:37:40 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by hip.baltimore.ie (8.9.3/8.9.3) with SMTP id QAA14485 for ; Thu, 7 Jun 2001 16:37:21 +0100 Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.1) with SMTP id for ; Thu, 7 Jun 2001 16:35:28 +0100 Received: from baltimore.ie (ip226-24.ie.baltimore.com [10.153.24.226]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id QAA02644; Thu, 7 Jun 2001 16:44:52 +0100 Message-ID: <3B1F9FB3.A81354E7@baltimore.ie> Date: Thu, 07 Jun 2001 16:37:23 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: Jari Arkko , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 60: E2E cert names References: <20010605071737.G22616@charizard.diameter.org> <3B1DF277.1CDC16F2@lmf.ericsson.se> <20010606064128.Z12278@charizard.diameter.org> <3B1F826C.45351D32@baltimore.ie> <3B1F85E1.1C91DD1B@lmf.ericsson.se> <20010607071013.C12278@charizard.diameter.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Then I suggest that we do not close this one until we get some > clarifying text. "The naming scheme presented here is intended to: - make it simple to use existing certification authorities (CAs) for Diamater CMS - allow CAs to ensure that only "proper" Diameter certificiates are accepted by Diameter nodes - allow Diameter certfificates to be used for other purposes where that meets a CA's practices." That do? Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Thu Jun 7 13:27:46 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11065 for ; Thu, 7 Jun 2001 13:27:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 50515912E9; Thu, 7 Jun 2001 13:27:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1DBCD913AE; Thu, 7 Jun 2001 13:27:39 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BEFF3912E9 for ; Thu, 7 Jun 2001 13:27:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6FEF35DE0A; Thu, 7 Jun 2001 13:28:03 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from redmailwall2.attws.com (redmailwall2.attws.com [199.108.253.116]) by segue.merit.edu (Postfix) with ESMTP id DAFF15DDC1 for ; Thu, 7 Jun 2001 13:28:02 -0400 (EDT) Received: from viruswall.entp.attws.com (viruswall.entp.attws.com [135.214.42.163]) by redmailwall2.attws.com (8.9.3/8.9.3) with ESMTP id KAA13786; Thu, 7 Jun 2001 10:25:07 -0700 (PDT) Received: from neastmail.neast.attws.com by viruswall.entp.attws.com (8.8.8+Sun/AT&T Wireless Services, Inc. V8 version 2) id KAA10832; Thu, 7 Jun 2001 10:27:02 -0700 (PDT) Received: from ner-msgbh.wireless.attws.com (ner-msgbh.wireless.attws.com [135.216.177.192]) by neastmail.neast.attws.com (8.8.8+Sun/8.8.8) with ESMTP id KAA18724; Thu, 7 Jun 2001 10:27:01 -0700 (PDT) Received: by ner-msgbh.wireless.attws.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 13:26:59 -0400 Message-ID: <0D3BDFD96647D211B43A00805F15E589050868B7@ner-msg03.wireless.attws.com> From: "Kobylarz, Thaddeus" To: "'Pat Calhoun'" , "Kobylarz, Thaddeus" Cc: Mark Eklund , Cain Brian-BCAIN1 , aaa-wg@merit.edu, "Molchan, John" , "Engelhart, Bob" Subject: RE: [AAA-WG]: Support for multi-process Date: Thu, 7 Jun 2001 13:26:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Pat, Thanks for your clarification. Thad -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Thursday, June 07, 2001 11:34 AM To: Kobylarz, Thaddeus Cc: 'Pat Calhoun'; Mark Eklund; Cain Brian-BCAIN1; aaa-wg@merit.edu; Molchan, John; Engelhart, Bob Subject: Re: [AAA-WG]: Support for multi-process On Thu, Jun 07, 2001 at 11:32:05AM -0400, Kobylarz, Thaddeus wrote: > Folks, > I am concerned that a single connection limitation may interfere > with using Diameter as a 3GPP charging protocol. I hope that either I don't > totally understand this discussion or that no such limitation is planned. I suspect that you don't understand the discussion. The general idea is to allow two Diameter processes to communicate over several transport connections. The protocol behavior is the same, and could be used for 3GPP charging, regardless of the outcome of this particular thread. However, what it would do is reduce the possibility for packets to be held up at the transport layer waiting for a retransmission from its peer. Thanks, PatC > Thad > > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Wednesday, June 06, 2001 7:37 PM > To: Mark Eklund > Cc: Cain Brian-BCAIN1; Pat Calhoun; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Support for multi-process > > > On Wed, Jun 06, 2001 at 07:34:19PM -0400, Mark Eklund wrote: > [lots of great stuff deleted] > > Do you have an > > opinion? > > I do. We seem to be going out of our way to ensure that we only have a > single > connection, but both Bernard, and others, have indicated that multiple > connections > MAY be necessary (at least for TCP). > > So given that SCTP will handle the case where two connections occur > simultaneously, > is this all now overkill? > > :( > > PatC > > > > -mark > > > > On Wed, 6 Jun 2001, Cain Brian-BCAIN1 wrote: > > > > > > -----Original Message----- > > > > From: Mark Eklund [mailto:meklund@cisco.com] > > > > Sent: Wednesday, June 06, 2001 9:40 AM > > > > > > > > Brian, > > > ... > > > > process and are listed below. Could you give your O.K. on > > > > those? > > > > > > Hmmm..I never got a chance to go over the last version in detail, so > here's > > > my comments on the revised version: > > > > > > I'm relieved to say that it seems simpler than the previous version (the > one > > > w/"Wait-R-DRI/Elect", etc., not your previous suggestion). > > > > > > I like the new election scheme, it answers some questions I had. I > think > > > the only suggestion I could offer would be some text that would advise > > > Election implementations to wait until all state machines know the > identity > > > of the peer they're connected to (i.e. wait until they've received the > Cap. > > > Exchange) before returning a "No Contest" verdict. Maybe it's restating > the > > > obvious (or overstepping the bounds of the doc), maybe not... > > > > > > Why do we lock on the Election? Am I correct in assuming that each > > > transport connection/state machine performs its own election? Why is it > bad > > > to have two concurrent elections? This kinda makes sense, but I must > just > > > be missing something. (Does it relate to the above comment about > waiting > > > for the CE message, maybe?) > > > > > > PS - Terminology update: Device Reboot -> Capabilities Exchange > > > (s/DR(R|A)/CE$1/g). (Also pertains to "*-Non-DRI" events, etc.) > > > > > > -Brian > > > > > > > > > From owner-aaa-wg@merit.edu Thu Jun 7 14:02:18 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11644 for ; Thu, 7 Jun 2001 14:02:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C30E3913DA; Thu, 7 Jun 2001 14:01:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 81D5E913DB; Thu, 7 Jun 2001 14:01:27 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 032AD913DA for ; Thu, 7 Jun 2001 14:01:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A56CB5DD8C; Thu, 7 Jun 2001 14:01:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id E41D55DE1A for ; Thu, 7 Jun 2001 14:01:50 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id KAA65242; Thu, 7 Jun 2001 10:50:22 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Thu, 7 Jun 2001 10:50:22 -0700 (PDT) From: Bernard Aboba To: "Kobylarz, Thaddeus" Cc: "'Pat Calhoun'" , Mark Eklund , Cain Brian-BCAIN1 , aaa-wg@merit.edu, "Molchan, John" , "Engelhart, Bob" Subject: RE: [AAA-WG]: Support for multi-process In-Reply-To: <0D3BDFD96647D211B43A00805F15E589050868B1@ner-msg03.wireless.attws.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk In transport-03, the intention was to enable a NAS or proxy to have connections open to multiple servers for the purpose of failover/failback and load balancing. Enabling two peers to have multiple connections between them is a different issue -- and in general this can cause problems with congestion avoidance. > Folks, > I am concerned that a single connection limitation may interfere > with using Diameter as a 3GPP charging protocol. I hope that either I don't > totally understand this discussion or that no such limitation is planned. > Thad From owner-aaa-wg@merit.edu Thu Jun 7 14:57:58 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12532 for ; Thu, 7 Jun 2001 14:57:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A0C1091207; Thu, 7 Jun 2001 14:57:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C9FD913DD; Thu, 7 Jun 2001 14:57:53 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2F88591207 for ; Thu, 7 Jun 2001 14:57:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EA4245DDFA; Thu, 7 Jun 2001 14:58:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by segue.merit.edu (Postfix) with ESMTP id 996185DDBB for ; Thu, 7 Jun 2001 14:58:17 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id LAA04336 for ; Thu, 7 Jun 2001 11:57:58 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id LAA01155 for ; Thu, 7 Jun 2001 11:57:58 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 13:57:58 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECF2A@IL27EXM10.cig.mot.com> From: Cain Brian-BCAIN1 To: "'Pat Calhoun'" , Mark Eklund Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Support for multi-process Date: Thu, 7 Jun 2001 13:57:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Wednesday, June 06, 2001 6:37 PM > > On Wed, Jun 06, 2001 at 07:34:19PM -0400, Mark Eklund wrote: > [lots of great stuff deleted] > > Do you have an > > opinion? > > I do. We seem to be going out of our way to ensure that we > only have a single > connection, but both Bernard, and others, have indicated that > multiple connections > MAY be necessary (at least for TCP). > > So given that SCTP will handle the case where two connections > occur simultaneously, > is this all now overkill? Hmm...yeah, probably. If that is the case, what should the state machine look like now? WRT SCTP handling two simultaneous connections, that would probably only work if you used DIAMETER's well-known port (I guess it wouldn't necessarily have to be the well-known one, but whichever one you're listening on) as the local port on outbound connections, right? Otherwise I can't see how it would be able to distinguish b/t this case and any other pair of transport connections between two machines. > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Thursday, June 07, 2001 9:05 AM ... >may exist, and they may be maintained. However, after some time, if the connection >is deemed to be unnecessary, it can be closed. > >PatC Along those lines: Maybe implementations should just police their connections at certain intervals. If you find two connections with the same peer "Identity", you arbitrarily disconnect one. Maybe you would send a message w/DUPLICATE_CONNECTION_DETECTED or UNNECESSARY_DUPLICATE_CONNECTION_DETECTED, and wait for a response? -Brian From owner-aaa-wg@merit.edu Thu Jun 7 16:00:45 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13498 for ; Thu, 7 Jun 2001 16:00:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D7BAB913E4; Thu, 7 Jun 2001 15:42:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C838913E5; Thu, 7 Jun 2001 15:42:59 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 37DF6913E4 for ; Thu, 7 Jun 2001 15:42:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 07F215DE08; Thu, 7 Jun 2001 15:43:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from redmailwall2.attws.com (redmailwall2.attws.com [199.108.253.116]) by segue.merit.edu (Postfix) with ESMTP id 6989E5DDFA for ; Thu, 7 Jun 2001 15:43:23 -0400 (EDT) Received: from viruswall1.entp.attws.com (viruswall1.entp.attws.com [135.214.40.161]) by redmailwall2.attws.com (8.9.3/8.9.3) with ESMTP id MAA19890; Thu, 7 Jun 2001 12:36:15 -0700 (PDT) Received: from neastmail.neast.attws.com by viruswall1.entp.attws.com (8.8.8+Sun/AT&T Wireless Services, Inc. V8 version 2) id MAA17466; Thu, 7 Jun 2001 12:38:11 -0700 (PDT) Received: from ner-msgbh.wireless.attws.com (ner-msgbh.wireless.attws.com [135.216.177.192]) by neastmail.neast.attws.com (8.8.8+Sun/8.8.8) with ESMTP id MAA03984; Thu, 7 Jun 2001 12:38:09 -0700 (PDT) Received: by ner-msgbh.wireless.attws.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 15:38:07 -0400 Message-ID: <0D3BDFD96647D211B43A00805F15E589050868B8@ner-msg03.wireless.attws.com> From: "Kobylarz, Thaddeus" To: "'Bernard Aboba'" , "Kobylarz, Thaddeus" Cc: "'Pat Calhoun'" , Mark Eklund , Cain Brian-BCAIN1 , aaa-wg@merit.edu, "Molchan, John" , "Engelhart, Bob" Subject: RE: [AAA-WG]: Support for multi-process Date: Thu, 7 Jun 2001 15:38:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Bernard, Thanks for your reply. I agree with the point of congestion control problems. Thad -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Thursday, June 07, 2001 1:50 PM To: Kobylarz, Thaddeus Cc: 'Pat Calhoun'; Mark Eklund; Cain Brian-BCAIN1; aaa-wg@merit.edu; Molchan, John; Engelhart, Bob Subject: RE: [AAA-WG]: Support for multi-process In transport-03, the intention was to enable a NAS or proxy to have connections open to multiple servers for the purpose of failover/failback and load balancing. Enabling two peers to have multiple connections between them is a different issue -- and in general this can cause problems with congestion avoidance. > Folks, > I am concerned that a single connection limitation may interfere > with using Diameter as a 3GPP charging protocol. I hope that either I don't > totally understand this discussion or that no such limitation is planned. > Thad From owner-aaa-wg@merit.edu Thu Jun 7 17:14:29 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14712 for ; Thu, 7 Jun 2001 17:14:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1F205913EA; Thu, 7 Jun 2001 17:14:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E62C4913EC; Thu, 7 Jun 2001 17:14:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3279F913EA for ; Thu, 7 Jun 2001 17:14:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2501B5DE25; Thu, 7 Jun 2001 17:14:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id B17295DE23 for ; Thu, 7 Jun 2001 17:14:44 -0400 (EDT) Received: (qmail 5042 invoked by uid 500); 7 Jun 2001 20:59:34 -0000 Date: Thu, 7 Jun 2001 13:59:34 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 5: 3GPP2 Accounting Requirements Message-ID: <20010607135933.T12278@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, A few of us got together on the phone today to try to iron out some of the remaining issues, and I will be sending out how we propose to close any remaining issues (well, we haven't been through them all... yet). In this particular issue, the problem is how to do accounting record correlation when many accounting "subsessions" are needed. 3GPP2, btw, has a requirement for this, and have addressed this in a largely proprietary nature. We would prefer to detail how this should be done to ensure consistency across services. So, we agreed that the protocol already had the necessary components, but the lack of clarity was what caused this issue to be opened. Here is my proposed text to be included in the base protocol: 11.6 Correlation of Accounting Records The Diameter protocol's Session-Id AVP, which is globally unique (see section 10.3), is used during the authorization phase to identify a particular session. Services that do not require any authorization still use the Session-Id AVP to identify sessions. However, there are certain applications that require multiple accounting sub-sessions. Such applications would send messages with a constant Session-Id AVP, but a different Accounting-Session-Id AVP. In these cases, correlation is performed using the Session-Id. Furthermore, there are certain applications where a user receives service from different access devices (e.g. Mobile IP), each with their own unique Session-Id. In such cases, the Accounting-Multi- Session-Id AVP is used for correlation. During authorization, a server that determines that a request is for an existing session, SHOULD include the Accounting-Multi-Session-Id AVP, which the access device MUST include in all subsequent accounting messages. The Accounting-Multi-Session-Id AVP MAY include the value of the original Session-Id. It's contents are implementation specific, but MUST be globally unique across other Accounting-Multi-Session-Id, and MUST NOT change during the life of a session. Thanks, PatC From owner-aaa-wg@merit.edu Thu Jun 7 18:18:57 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15414 for ; Thu, 7 Jun 2001 18:18:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7BBD491203; Thu, 7 Jun 2001 18:18:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4DB3791205; Thu, 7 Jun 2001 18:18:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A7F1D91203 for ; Thu, 7 Jun 2001 18:18:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AE2495DD96; Thu, 7 Jun 2001 18:19:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 2CD265DD91 for ; Thu, 7 Jun 2001 18:19:21 -0400 (EDT) Received: (qmail 1715 invoked by uid 500); 7 Jun 2001 22:08:41 -0000 Date: Thu, 7 Jun 2001 15:08:41 -0700 From: Pat Calhoun To: Jari Arkko Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 5: 3GPP2 Accounting Requirements Message-ID: <20010607150841.B1100@charizard.diameter.org> Mail-Followup-To: Jari Arkko , Pat Calhoun , aaa-wg@merit.edu References: <20010607135933.T12278@charizard.diameter.org> <010701c0f066$591431c0$8a1b6e0a@arenanet.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <010701c0f066$591431c0$8a1b6e0a@arenanet.fi>; from jari.arkko@kolumbus.fi on Sat, Jun 09, 2001 at 12:59:53AM +0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Sat, Jun 09, 2001 at 12:59:53AM +0300, Jari Arkko wrote: > > 11.6 Correlation of Accounting Records > > Looks good! > > One editorial issue is that some of > this text overlaps a little with issue #57 > proposed text. Perhaps you could fix that > by trimming the text in #57 as follows. > [great text deleted] ok, thanks for the text. PatC From owner-aaa-wg@merit.edu Thu Jun 7 18:44:34 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15628 for ; Thu, 7 Jun 2001 18:44:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3EFAB91205; Thu, 7 Jun 2001 18:42:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3EDA991206; Thu, 7 Jun 2001 18:42:31 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C9A8E91205 for ; Thu, 7 Jun 2001 18:42:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D997A5DD96; Thu, 7 Jun 2001 18:42:39 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 53F9E5DD8C for ; Thu, 7 Jun 2001 18:42:39 -0400 (EDT) Received: (qmail 1877 invoked by uid 500); 7 Jun 2001 22:32:03 -0000 Date: Thu, 7 Jun 2001 15:32:03 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Proposed for 26, 38 and 48 Message-ID: <20010607153203.D1100@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, The following is the concept that was agreed upon during today's discussion. I'd like to request comments. Thanks, PatC ---- 10.12 Session-Binding AVP The Session-Binding AVP (AVP Code TBD) is of type Unsigned32, and MAY be present in application-specific authorization answer messages. If present, this AVP MAY inform the Diameter client that all future application-specific re-auth messages for this session MUST be sent to the same authorization server. This AVP MAY also specify that a Session-Termination-Request message for this session MUST be sent to the same authorizing server. This field is a bit mask, and the following bits have been defined: RE_AUTH 1 When set, future re-auth messages for this session MUST NOT include the Destination-Host AVP. When cleared, the default value, the Destination-Host AVP MUST be present in all re-auth messages for this session. STR 2 When set, the STR message for this session MUST NOT include the Destination-Host AVP. When cleared, the default value, the Destination-Host AVP MUST be present in the STR message for this session. ACCOUNTING 4 When set, all accounting messages for this session MUST include the Destiation-Host AVP. When cleared, the default value, the Destination-Host AVP MUST be present in all accounting messages for this session. 10.13 Session-Server-Failover AVP The Session-Server-Failover AVP (AVP Code TBD) is of type Enumerated, and MAY be present in application-specific authorization answer messages that include the Session-Binding AVP with a non-zero value. If present, this AVP MAY inform the Diameter client that if a re-auth or STR message fails due to a delivery problem, the Diameter client SHOULD issue a subsequent message without the Destination-Host AVP. When absent, the default value is REFUSE_SERVICE. The following values are supported: REFUSE_SERVICE 0 If either the re-auth or the STR message delivery fails, terminate service with the user, and do not attempt any subsequent attempts. TRY_AGAIN 1 If either the re-auth or the STR message delivery fails, resend the failed message without the Destination-Host AVP present. ALLOW_SERVICE 2 If re-auth message delivery fails, assume that re-authorization succeeded. If STR message delivery fails, terminate the session. TRY_AGAIN_ALLOW_SERVICE 3 If either the re-auth or the STR message delivery fails, resend the failed message without the Destination-Host AVP present. If the second delivery fails for re-auth, assume re- authorization succeeded. If the second delivery fails for STR, terminate the session. From owner-aaa-wg@merit.edu Thu Jun 7 18:50:08 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15721 for ; Thu, 7 Jun 2001 18:50:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4A52F91206; Thu, 7 Jun 2001 18:50:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C523A9120A; Thu, 7 Jun 2001 18:50:06 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4722A91206 for ; Thu, 7 Jun 2001 18:50:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6886D5DD8D; Thu, 7 Jun 2001 18:50:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id DD0A35DD8C for ; Thu, 7 Jun 2001 18:50:30 -0400 (EDT) Received: (qmail 1897 invoked by uid 500); 7 Jun 2001 22:39:54 -0000 Date: Thu, 7 Jun 2001 15:39:54 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 56: Flag bit for start of conversation Message-ID: <20010607153954.E1100@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, Bernard felt that if clarifying text could be added that states that a message has NO fixed destination if the Destination-Host AVP is missing, we could close this issue. So, I'd like to propose the following (new 3rd paragraph): 5.6 Destination-Host AVP The Destination-Host AVP (AVP Code 293) is of type DiameterIdentity. This AVP MUST be present in all unsolicited agent initiated messages, MAY be present in request messages, and MUST be present in Answer messages. When responding to requests, the value of the Destination-Host AVP is set to the value of the Origin-Host AVP found in the request. The absence of the Destination-Host AVP will cause a message to be sent to any Diameter server supporting the application within the realm specified in Destination-Realm AVP. This AVP SHOULD be placed as close to the Diameter header as possible. PatC From owner-aaa-wg@merit.edu Thu Jun 7 18:58:26 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15813 for ; Thu, 7 Jun 2001 18:58:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D89C8913F5; Thu, 7 Jun 2001 18:55:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 99ACF913F7; Thu, 7 Jun 2001 18:55:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7F4C7913F5 for ; Thu, 7 Jun 2001 18:55:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 292235DD96; Thu, 7 Jun 2001 18:55:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 9E7795DD8D for ; Thu, 7 Jun 2001 18:55:32 -0400 (EDT) Received: (qmail 1924 invoked by uid 500); 7 Jun 2001 22:44:56 -0000 Date: Thu, 7 Jun 2001 15:44:56 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 58: e2e draft essr/essa delay Message-ID: <20010607154456.F1100@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk We discussed this topic today, which is whether the correct design choice was made in introducing a new round trip to establish a Diameter SA. The point was made that if some optimization is done, it will require that some (possibly sensitive) information will be disclosed in the process of setting up a key. For example: NAS Server ------------ AAA + PAP PW --------------> <-- HEY! Don't send PAP here's a key ---- ----- AAA + Encrypted PAP PW -----------> Therefore, the is no choice other than to have a round trip to establish the SA, such as: NAS Server ---------------- ESSR -------------------> <--------------- ESSA -------------------- ------------ AAA + PAP PW ---------------> So the group decided that we could close this issue without any changes to the protocol specification, and would entertain any objections from the WG. Thanks, PatC From owner-aaa-wg@merit.edu Thu Jun 7 19:08:08 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15954 for ; Thu, 7 Jun 2001 19:08:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 56500913F7; Thu, 7 Jun 2001 19:08:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 252EC913F8; Thu, 7 Jun 2001 19:08:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DF5CC913F7 for ; Thu, 7 Jun 2001 19:08:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F2A125DD96; Thu, 7 Jun 2001 19:08:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 7343C5DD8C for ; Thu, 7 Jun 2001 19:08:28 -0400 (EDT) Received: (qmail 1957 invoked by uid 500); 7 Jun 2001 22:57:52 -0000 Date: Thu, 7 Jun 2001 15:57:52 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 68: Address name and 20 byte IPv6 length Message-ID: <20010607155752.H1100@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, This issue really has two separate issues, so let's deal with them separately. First, there was a request to change the AVP Type Address to IPAddress, since it is much more descriptive. The group today agreed this was the proper approach, and the following is the proposed text (note, the change is Address->IPAddress): IPAddress The IPAddress format is derived from the OctetString AVP Base Format. It represents 32 bit (IPv4) [17] or 128 bit (IPv6) [16] address, most significant octet first. The format of the address (IPv4 or IPv6) is determined by the length. If the attribute value is an IPv4 address, the AVP Length field MUST be 12 (16 if 'V' bit is enabled), otherwise the AVP Length field MUST be set to 24 (28 if the 'V' bit is enabled) for IPv6 addresses. The second issue was how to deal with IPv6 addresses that would include IPv6 Interface Ids. Well, the RADIUS IPv6 extensions defines a separate AVP to include the interface Id, and the group felt that this was a much cleaner approach, than to require that an IPAddress have 3 different lengths. So, we decided to reject this particular proposal. Any comments? PatC From owner-aaa-wg@merit.edu Thu Jun 7 19:45:50 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16264 for ; Thu, 7 Jun 2001 19:45:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DB4FD913F2; Thu, 7 Jun 2001 17:59:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AE2F2913F5; Thu, 7 Jun 2001 17:59:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 88949913F2 for ; Thu, 7 Jun 2001 17:59:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 264E25DD96; Thu, 7 Jun 2001 18:00:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by segue.merit.edu (Postfix) with ESMTP id 148EE5DD91 for ; Thu, 7 Jun 2001 18:00:06 -0400 (EDT) Received: from jariws1 ([62.248.154.223]) by fep02-app.kolumbus.fi (InterMail vM.5.01.02.00 201-253-122-103-20001017) with SMTP id <20010607215945.EKWE22409.fep02-app.kolumbus.fi@jariws1>; Fri, 8 Jun 2001 00:59:45 +0300 Message-ID: <010701c0f066$591431c0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Pat Calhoun" , References: <20010607135933.T12278@charizard.diameter.org> Subject: Re: [AAA-WG]: Issue 5: 3GPP2 Accounting Requirements Date: Sat, 9 Jun 2001 00:59:53 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > 11.6 Correlation of Accounting Records Looks good! One editorial issue is that some of this text overlaps a little with issue #57 proposed text. Perhaps you could fix that by trimming the text in #57 as follows. "A particular value of Accounting-Session-Id MUST appear only in one sequence of accounting records from a DIAMETER client, except for the purposes of retransmission. The one sequence that is sent MUST be either one record with Accounting-Record-Type AVP set to the value EVENT_RECORD, or several records starting with one having the value START_RECORD, followed by zero or more INTERIM_RECORD, and a single STOP_RECORD. A particular extensions document MUST define which kind of sequences should be used for the particular application. " and then move the text below to the end of your proposed text for #5: "A Diameter extension document MUST define the exact concept of a session that is being accounted, and MAY define the concept of a multi-session. For instance, the NASREQ DIAMETER extension treats a single PPP connection to a Network Access Server as one session, and a set of Multilink PPP sessions as one multi-session." Jari From owner-aaa-wg@merit.edu Thu Jun 7 19:46:54 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16282 for ; Thu, 7 Jun 2001 19:46:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A147691208; Thu, 7 Jun 2001 19:45:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 148B09120C; Thu, 7 Jun 2001 19:45:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4327991208 for ; Thu, 7 Jun 2001 19:45:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5DE055DD96; Thu, 7 Jun 2001 19:45:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by segue.merit.edu (Postfix) with ESMTP id 0C3395DD8C for ; Thu, 7 Jun 2001 19:45:45 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id QAA28306 for ; Thu, 7 Jun 2001 16:45:25 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA04977 for ; Thu, 7 Jun 2001 16:45:25 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 18:45:25 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECF2D@IL27EXM10.cig.mot.com> From: Cain Brian-BCAIN1 To: "'Pat Calhoun'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Proposed for 26, 38 and 48 Date: Thu, 7 Jun 2001 18:45:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] ... > today's discussion. I'd > like to request comments. > > PatC ... Minutiae: > ACCOUNTING 4 > When set, all accounting messages for this session > MUST include MUST NOT, instead? > the Destiation-Host AVP. When cleared, the default value, the Should be "Destination" > Destination-Host AVP MUST be present in all > accounting messages > for this session. -Brian From owner-aaa-wg@merit.edu Thu Jun 7 20:18:22 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16465 for ; Thu, 7 Jun 2001 20:18:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1BA149120C; Thu, 7 Jun 2001 20:18:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B9388913F8; Thu, 7 Jun 2001 20:18:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 843789120C for ; Thu, 7 Jun 2001 20:18:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C1F715DD96; Thu, 7 Jun 2001 20:18:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 411B25DD8C for ; Thu, 7 Jun 2001 20:18:47 -0400 (EDT) Received: (qmail 2064 invoked by uid 500); 8 Jun 2001 00:08:10 -0000 Date: Thu, 7 Jun 2001 17:08:10 -0700 From: Pat Calhoun To: Cain Brian-BCAIN1 Cc: "'Pat Calhoun'" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Proposed for 26, 38 and 48 Message-ID: <20010607170810.I1100@charizard.diameter.org> Mail-Followup-To: Cain Brian-BCAIN1 , 'Pat Calhoun' , aaa-wg@merit.edu References: <35DBB8B7AC89D4118E98009027B1009B0ECF2D@IL27EXM10.cig.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B0ECF2D@IL27EXM10.cig.mot.com>; from Brian.Cain@motorola.com on Thu, Jun 07, 2001 at 06:45:24PM -0500 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, Jun 07, 2001 at 06:45:24PM -0500, Cain Brian-BCAIN1 wrote: > > ACCOUNTING 4 > > When set, all accounting messages for this session > > MUST include > > MUST NOT, instead? yup > > > the Destiation-Host AVP. When cleared, the default value, the > > Should be "Destination" sigh. Gotta slow down :( PatC From owner-aaa-wg@merit.edu Thu Jun 7 20:31:00 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16589 for ; Thu, 7 Jun 2001 20:31:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1A046913DD; Thu, 7 Jun 2001 15:12:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DF083913E0; Thu, 7 Jun 2001 15:12:02 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A9353913DD for ; Thu, 7 Jun 2001 15:12:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7532B5DE06; Thu, 7 Jun 2001 15:12:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from longmail2.lboard.com (unknown [63.109.116.89]) by segue.merit.edu (Postfix) with ESMTP id 103D65DDFA for ; Thu, 7 Jun 2001 15:12:27 -0400 (EDT) Received: by longmail2.lboard.com with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Jun 2001 15:12:11 -0400 Message-ID: From: Ed Ellesson To: "'aaa-wg@merit.edu'" Cc: "'Wijnen, Bert (Bert)'" , "'Joel M. Halpern'" Subject: [AAA-WG]: AAA WG Notice: Policy Terminology Last Call is now complete Date: Thu, 7 Jun 2001 15:12:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, AAA WG: We apologize to those of you who receive more than one copy of this notice. The extended working group last call is now completed, for the draft titled "Terminology" (draft-ietf-policy-terminology-03.txt), which is being re-titled as "Terminology for Policy-Based Management". This extended last call provided an opportunity for the following working groups to comment on the draft, and discuss proposed changes on the Policy Framework WG mailing list. Working groups participating in the extended working group last call for this draft: Policy DiffServ RAP IPSP SNMPCONF AAA AAAArch (IRTF) RSVP MPLS Comments resulting from this extended multiple working group last call were discussed and accepted on the policy framework working group mailing list. The document will be revised in accordance with the results of that discussion. The Policy Framework working group will then submit it to the IESG to request their review and approval for publication as an Informational RFC. Thanks to all of you who participated in this successful extended working group last call, and a special thanks to Andrea Westerinen, who edited the draft, engaged in the discussion of the comments, and who will update it per the discussion results. Ed Ellesson, with Joel Halpern, Co-chairs, Policy Framework WG From owner-aaa-wg@merit.edu Thu Jun 7 20:52:45 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16771 for ; Thu, 7 Jun 2001 20:52:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5EB80913F9; Thu, 7 Jun 2001 20:52:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2D811913FB; Thu, 7 Jun 2001 20:52:41 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 05EA4913F9 for ; Thu, 7 Jun 2001 20:52:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4E5E65DD96; Thu, 7 Jun 2001 20:53:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 04A065DD8C for ; Thu, 7 Jun 2001 20:53:06 -0400 (EDT) Received: (qmail 2187 invoked by uid 500); 8 Jun 2001 00:42:29 -0000 Date: Thu, 7 Jun 2001 17:42:29 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 70: Caching of redirects Message-ID: <20010607174229.K1100@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, The following text reflects the decision that was taken during today's discussion, and I'd like to get any WG comments on the proposed text. 5.9 Recommended-Redirect-Cache-Time AVP The Recommended-Redirect-Cache-Time AVP (AVP Code TBD) is of type Unsigned32. This AVP MUST be present in Message-Reject-Answer messages that include the Result-Code AVP set to DIAMETER_REDIRECT_INDICATION. This AVP contains the maximum number of seconds the redirector recommends when caching any route entries resulting from the MRA message. 5.10 Redirect-Host-Usage AVP The Redirect-Host-Usage AVP (AVP Code TBD) is of type Enumerated. This AVP MAY be present in Message-Reject-Answer messages that include the Result-Code AVP set to DIAMETER_REDIRECT_INDICATION. When present, this AVP dictates how the routing entry resulting from the MRA is to be used. The following values are supported: ALL_REALM 0 All messages destined for the realm requested MAY be sent to the host specified in the Redirect-Host AVP. This is the default value. REALM_AND_APPLICATION 1 All messages for the application requested to the realm specified MAY be sent to the host specified in the Redirect- Host AVP. Thanks, PatC From owner-aaa-wg@merit.edu Fri Jun 8 04:08:54 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07437 for ; Fri, 8 Jun 2001 04:08:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 165EF91356; Fri, 8 Jun 2001 04:08:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CF6C891357; Fri, 8 Jun 2001 04:08:47 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9136C91356 for ; Fri, 8 Jun 2001 04:08:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 713B45DDB1; Fri, 8 Jun 2001 04:09:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 6159B5DD8C for ; Fri, 8 Jun 2001 04:09:12 -0400 (EDT) Received: from fredrikj (sierra.local.ipunplugged.com [192.168.4.88]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id KAA30981; Fri, 8 Jun 2001 10:10:43 +0200 From: "Fredrik Johansson" To: "Pat Calhoun" , Subject: RE: [AAA-WG]: Proposed for 26, 38 and 48 Date: Fri, 8 Jun 2001 10:10:25 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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) In-Reply-To: <20010607153203.D1100@charizard.diameter.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, The Session-Binding AVP and the Session-Server-Failover AVP both suggests the same thing. The former suggest that if it has a non-zero value the Destination-Host AVP should NOT be present and the latter says that if the former has a non-zero value it should try without the Destination-Host AVP. I don't believe that it's a good idea to change the Session-Binding AVP because the default value of zero should mean that the Destination-Host AVP must be present, so how about changing the Session-Server-Failover AVP to: 10.13 Session-Server-Failover AVP The Session-Server-Failover AVP (AVP Code TBD) is of type Enumerated, and MAY be present in application-specific authorization answer messages that does not include the Session-Binding AVP or include the Session-Binding AVP with any of the bits set to a zero value. If present, this AVP MAY inform the Diameter client that if a re-auth or STR message fails due to a delivery problem, the Diameter client SHOULD issue a subsequent message without the Destination-Host AVP. When absent, the default value is REFUSE_SERVICE. The following values are supported: REFUSE_SERVICE 0 If either the re-auth or the STR message delivery fails, terminate service with the user, and do not attempt any subsequent attempts. TRY_AGAIN 1 If either the re-auth or the STR message delivery fails, resend the failed message without the Destination-Host AVP present. ALLOW_SERVICE 2 If re-auth message delivery fails, assume that re-authorization succeeded. If STR message delivery fails, terminate the session. TRY_AGAIN_ALLOW_SERVICE 3 If either the re-auth or the STR message delivery fails, resend the failed message without the Destination-Host AVP present. If the second delivery fails for re-auth, assume re- authorization succeeded. If the second delivery fails for STR, terminate the session. /Fredrik >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >Pat Calhoun >Sent: den 8 juni 2001 00:32 >To: aaa-wg@merit.edu >Subject: [AAA-WG]: Proposed for 26, 38 and 48 > > >All, > >The following is the concept that was agreed upon during today's >discussion. I'd >like to request comments. > >Thanks, > >PatC >---- >10.12 Session-Binding AVP > > The Session-Binding AVP (AVP Code TBD) is of type Unsigned32, and MAY > be present in application-specific authorization answer messages. If > present, this AVP MAY inform the Diameter client that all future > application-specific re-auth messages for this session MUST be sent > to the same authorization server. This AVP MAY also specify that a > Session-Termination-Request message for this session MUST be sent to > the same authorizing server. > > This field is a bit mask, and the following bits have been defined: > > RE_AUTH 1 > When set, future re-auth messages for this session MUST NOT > include the Destination-Host AVP. When cleared, the default > value, the Destination-Host AVP MUST be present in all re-auth > messages for this session. > > STR 2 > When set, the STR message for this session MUST NOT include the > Destination-Host AVP. When cleared, the default value, the > Destination-Host AVP MUST be present in the STR message for > this session. > > ACCOUNTING 4 > When set, all accounting messages for this session MUST include > the Destiation-Host AVP. When cleared, the default value, the > Destination-Host AVP MUST be present in all accounting messages > for this session. > > > >10.13 Session-Server-Failover AVP > > The Session-Server-Failover AVP (AVP Code TBD) is of type Enumerated, > and MAY be present in application-specific authorization answer > messages that include the Session-Binding AVP with a non-zero value. > If present, this AVP MAY inform the Diameter client that if a re-auth > or STR message fails due to a delivery problem, the Diameter client > SHOULD issue a subsequent message without the Destination-Host AVP. > When absent, the default value is REFUSE_SERVICE. > > The following values are supported: > > REFUSE_SERVICE 0 > If either the re-auth or the STR message delivery fails, > terminate service with the user, and do not attempt any > subsequent attempts. > > TRY_AGAIN 1 > If either the re-auth or the STR message delivery fails, resend > the failed message without the Destination-Host AVP present. > > ALLOW_SERVICE 2 > If re-auth message delivery fails, assume that re-authorization > succeeded. If STR message delivery fails, terminate the > session. > > TRY_AGAIN_ALLOW_SERVICE 3 > If either the re-auth or the STR message delivery fails, resend > the failed message without the Destination-Host AVP present. > If the second delivery fails for re-auth, assume re- > authorization succeeded. If the second delivery fails for STR, > terminate the session. From owner-aaa-wg@merit.edu Fri Jun 8 05:53:49 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08335 for ; Fri, 8 Jun 2001 05:53:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3B76391359; Fri, 8 Jun 2001 05:53:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D42459135A; Fri, 8 Jun 2001 05:53:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B245391359 for ; Fri, 8 Jun 2001 05:53:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 952995DD95; Fri, 8 Jun 2001 05:54:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp010.mail.yahoo.com (smtp010.mail.yahoo.com [216.136.173.30]) by segue.merit.edu (Postfix) with SMTP id 4ABD45DD8C for ; Fri, 8 Jun 2001 05:54:18 -0400 (EDT) Received: from jc-mac.planete.net (HELO jc.yahoo.com) (194.2.222.120) by smtp.mail.vip.sc5.yahoo.com with SMTP; 8 Jun 2001 09:53:56 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010608111753.00d29a10@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Jun 2001 11:20:06 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 70: Caching of redirects Cc: aaa-wg@merit.edu In-Reply-To: <20010607174229.K1100@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, Sorry I couldn't get on the call. I think it would be useful to also have a value for not allowing caching. I guess it could be implicitly done with a value of 0 for Recommanded-Redirect-Cache-Time, but that should be stated as such? And since it's recommended only, that might not be strong enough? Jacques. At 02:42 08/06/01, Pat Calhoun wrote: >All, > >The following text reflects the decision that was taken during today's >discussion, and I'd like to get any WG comments on the proposed text. > >5.9 Recommended-Redirect-Cache-Time AVP > > The Recommended-Redirect-Cache-Time AVP (AVP Code TBD) is of type > Unsigned32. This AVP MUST be present in Message-Reject-Answer > messages that include the Result-Code AVP set to > DIAMETER_REDIRECT_INDICATION. > > This AVP contains the maximum number of seconds the redirector > recommends when caching any route entries resulting from the MRA > message. > > >5.10 Redirect-Host-Usage AVP > > The Redirect-Host-Usage AVP (AVP Code TBD) is of type Enumerated. > This AVP MAY be present in Message-Reject-Answer messages that > include the Result-Code AVP set to DIAMETER_REDIRECT_INDICATION. > > When present, this AVP dictates how the routing entry resulting from > the MRA is to be used. The following values are supported: > > ALL_REALM 0 > All messages destined for the realm requested MAY be sent to > the host specified in the Redirect-Host AVP. This is the > default value. > > REALM_AND_APPLICATION 1 > All messages for the application requested to the realm > specified MAY be sent to the host specified in the Redirect- > Host AVP. > > >Thanks, > >PatC _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Fri Jun 8 06:29:49 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08675 for ; Fri, 8 Jun 2001 06:29:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A120F9135A; Fri, 8 Jun 2001 06:15:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 725BD9135B; Fri, 8 Jun 2001 06:15:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E69249135A for ; Fri, 8 Jun 2001 06:15:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D65915DDB1; Fri, 8 Jun 2001 06:15:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by segue.merit.edu (Postfix) with ESMTP id 296735DD9B for ; Fri, 8 Jun 2001 06:15:57 -0400 (EDT) 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 MAA25356; Fri, 8 Jun 2001 12:15:35 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id MAA08136; Fri, 8 Jun 2001 12:15:33 +0200 Date: Fri, 8 Jun 2001 12:15:33 +0200 Message-Id: <200106081015.MAA08136@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: pcalhoun@diameter.org Cc: aaa-wg@merit.edu In-reply-to: <20010607155752.H1100@charizard.diameter.org> (message from Pat Calhoun on Thu, 7 Jun 2001 15:57:52 -0700) Subject: Re: [AAA-WG]: Issue 68: Address name and 20 byte IPv6 length References: <20010607155752.H1100@charizard.diameter.org> Sender: owner-aaa-wg@merit.edu Precedence: bulk >>>>> Pat Calhoun writes: Pat> First, there was a request to change the AVP Type Address to Pat> IPAddress, since it is much more descriptive. The group today Pat> agreed this was the proper approach, and the following is the Pat> proposed text (note, the change is Address->IPAddress): [...] OK Pat> The second issue was how to deal with IPv6 addresses that would Pat> include IPv6 Interface Ids. Well, the RADIUS IPv6 extensions Pat> defines a separate AVP to include the interface Id, and the group Pat> felt that this was a much cleaner approach, than to require that Pat> an IPAddress have 3 different lengths. So, we decided to reject Pat> this particular proposal. So you leave it to the sender/receiver of the message to do the right thing. It might get tricky in cases where you have multiple IPAddress AVPs in a single message and/or the ABNF grammar did not provide for a scope identifier when it was written. Anyway, I think it is OK to see whether this turns out to be a real problem in practice and so I can live with this decision. /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-aaa-wg@merit.edu Fri Jun 8 09:51:19 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12585 for ; Fri, 8 Jun 2001 09:51:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E794D9135B; Fri, 8 Jun 2001 09:51:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B4C959135C; Fri, 8 Jun 2001 09:51:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A10D39135B for ; Fri, 8 Jun 2001 09:51:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F336C5DDB0; Fri, 8 Jun 2001 09:51:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans-old.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 2D4175DD91 for ; Fri, 8 Jun 2001 09:51:34 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA20715; Fri, 8 Jun 2001 09:50:32 -0400 (EDT) Date: Fri, 8 Jun 2001 09:50:54 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 70: Caching of redirects In-Reply-To: <4.3.2.7.2.20010608111753.00d29a10@pop.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Jacques, To not allow caching, would adding the following statement be sufficient? 5.10 Redirect-Host-Usage AVP ... If the Redirect-Host-Usage AVP is not present, this redirect may be used for this transaction only. ... -mark On Fri, 8 Jun 2001, Jacques Caron wrote: > Hi, > > Sorry I couldn't get on the call. I think it would be useful to also have a > value for not allowing caching. I guess it could be implicitly done with a > value of 0 for Recommanded-Redirect-Cache-Time, but that should be stated > as such? And since it's recommended only, that might not be strong enough? > > Jacques. > > At 02:42 08/06/01, Pat Calhoun wrote: > >All, > > > >The following text reflects the decision that was taken during today's > >discussion, and I'd like to get any WG comments on the proposed text. > > > >5.9 Recommended-Redirect-Cache-Time AVP > > > > The Recommended-Redirect-Cache-Time AVP (AVP Code TBD) is of type > > Unsigned32. This AVP MUST be present in Message-Reject-Answer > > messages that include the Result-Code AVP set to > > DIAMETER_REDIRECT_INDICATION. > > > > This AVP contains the maximum number of seconds the redirector > > recommends when caching any route entries resulting from the MRA > > message. > > > > > >5.10 Redirect-Host-Usage AVP > > > > The Redirect-Host-Usage AVP (AVP Code TBD) is of type Enumerated. > > This AVP MAY be present in Message-Reject-Answer messages that > > include the Result-Code AVP set to DIAMETER_REDIRECT_INDICATION. > > > > When present, this AVP dictates how the routing entry resulting from > > the MRA is to be used. The following values are supported: > > > > ALL_REALM 0 > > All messages destined for the realm requested MAY be sent to > > the host specified in the Redirect-Host AVP. This is the > > default value. > > > > REALM_AND_APPLICATION 1 > > All messages for the application requested to the realm > > specified MAY be sent to the host specified in the Redirect- > > Host AVP. > > > > > >Thanks, > > > >PatC > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > From owner-aaa-wg@merit.edu Fri Jun 8 10:02:20 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12747 for ; Fri, 8 Jun 2001 10:02:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2F81B9135F; Fri, 8 Jun 2001 10:02:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D8C9A91361; Fri, 8 Jun 2001 10:02:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 622389135F for ; Fri, 8 Jun 2001 10:02:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BB8B05DDB0; Fri, 8 Jun 2001 10:02:37 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) by segue.merit.edu (Postfix) with SMTP id 421E55DD91 for ; Fri, 8 Jun 2001 10:02:37 -0400 (EDT) Received: from pc25.paris-dc.fr.psi.com (HELO jc.yahoo.com) (212.81.116.25) by smtp.mail.vip.sc5.yahoo.com with SMTP; 8 Jun 2001 14:02:15 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010608155208.00c29820@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Jun 2001 16:02:04 +0200 To: Mark Eklund From: Jacques Caron Subject: Re: [AAA-WG]: Issue 70: Caching of redirects Cc: Pat Calhoun , aaa-wg@merit.edu In-Reply-To: References: <4.3.2.7.2.20010608111753.00d29a10@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 15:50 08/06/01, Mark Eklund wrote: >Jacques, > >To not allow caching, would adding the following statement be >sufficient? > >5.10 Redirect-Host-Usage AVP > ... If the Redirect-Host-Usage AVP is not present, this > redirect may be used for this transaction only. ... This contradicts the fact that ALL_REALM is the default. I see the following options: 1. State that a value of 0 for Recommended-Redirect-Cache-Time means no caching (and is not recommended but mandatory in this case?) 2. Add a new value for Redirect-Host-Usage: DONT_CACHE 2 The host specified in the Redirect-Host AVP should not be cached. 3. State that when Redirect-Host-Usage is not present, no caching is to be done by changing the text to: When present, this AVP dictates how the routing entry resulting from the MRA is to be used. If absent, the results should not be cached. The following values are supported: And removing the "This is the default value" for ALL_REALM. In the latter two cases, it makes no sense to make Recommended-Redirect-Cache-Time mandatory, though. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Fri Jun 8 10:34:56 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13194 for ; Fri, 8 Jun 2001 10:34:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 83D3891214; Fri, 8 Jun 2001 10:27:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5BE9091216; Fri, 8 Jun 2001 10:27:39 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 53A7B91214 for ; Fri, 8 Jun 2001 10:27:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B332C5DDBB; Fri, 8 Jun 2001 10:28:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 713365DDB1 for ; Fri, 8 Jun 2001 10:28:05 -0400 (EDT) Received: (qmail 8039 invoked by uid 500); 8 Jun 2001 14:17:26 -0000 Date: Fri, 8 Jun 2001 07:17:26 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 63: e2e unverified certs Message-ID: <20010608071725.I4931@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, The new CMS (01) draft will not include any text that states that certs do not need to be verified. Therefore, I will close this issue. This particular issue also caused some issues with the preliminary security review. Thanks, PatC From owner-aaa-wg@merit.edu Fri Jun 8 10:44:50 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13400 for ; Fri, 8 Jun 2001 10:44:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6E4C191405; Fri, 8 Jun 2001 10:33:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3AB5D91404; Fri, 8 Jun 2001 10:33:53 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 43F1391369 for ; Fri, 8 Jun 2001 10:33:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A6A845DDBB; Fri, 8 Jun 2001 10:34:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 638215DDB0 for ; Fri, 8 Jun 2001 10:34:16 -0400 (EDT) Received: (qmail 8072 invoked by uid 500); 8 Jun 2001 14:23:37 -0000 Date: Fri, 8 Jun 2001 07:23:37 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 59: e2e mandatory status Message-ID: <20010608072337.L4931@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk I believe that the Minn meeting minutes show that cms is mandatory to implement. This issue is asking whether this was the correct decision. Could we get some WG discussions on this? I'd like to get some agreement, and close this issue. Thanks, PatC From owner-aaa-wg@merit.edu Fri Jun 8 10:46:27 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13453 for ; Fri, 8 Jun 2001 10:46:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 48C6D91217; Fri, 8 Jun 2001 10:45:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C600391362; Fri, 8 Jun 2001 10:45:14 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EEA3A91217 for ; Fri, 8 Jun 2001 10:45:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5AA6D5DDBB; Fri, 8 Jun 2001 10:45:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans-old.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 8B4AB5DDB0 for ; Fri, 8 Jun 2001 10:45:39 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA21062; Fri, 8 Jun 2001 10:44:38 -0400 (EDT) Date: Fri, 8 Jun 2001 10:45:00 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 70: Caching of redirects In-Reply-To: <4.3.2.7.2.20010608155208.00c29820@pop.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Jacques, On Fri, 8 Jun 2001, Jacques Caron wrote: > At 15:50 08/06/01, Mark Eklund wrote: > >Jacques, > > > >To not allow caching, would adding the following statement be > >sufficient? > > > >5.10 Redirect-Host-Usage AVP > > ... If the Redirect-Host-Usage AVP is not present, this > > redirect may be used for this transaction only. ... > > This contradicts the fact that ALL_REALM is the default. I see the > following options: Whoops, I missed the statement saying ALL_REALM is default. > 1. State that a value of 0 for Recommended-Redirect-Cache-Time means no > caching (and is not recommended but mandatory in this case?) > > 2. Add a new value for Redirect-Host-Usage: > DONT_CACHE 2 > The host specified in the Redirect-Host AVP should not > be cached. I would like a prefer a slight variation on this. Add a DONT_CACHE value, make it the first one, and make it default. That way, you don't cache unless you are told that caching is allowed. -mark > > 3. State that when Redirect-Host-Usage is not present, no caching is to be > done by changing the text to: > > When present, this AVP dictates how the routing entry resulting from > the MRA is to be used. If absent, the results should not be cached. > The following values are supported: > > And removing the "This is the default value" for ALL_REALM. > > In the latter two cases, it makes no sense to make > Recommended-Redirect-Cache-Time mandatory, though. > > Jacques. > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > From owner-aaa-wg@merit.edu Fri Jun 8 10:46:28 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13454 for ; Fri, 8 Jun 2001 10:46:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 18DAD91366; Fri, 8 Jun 2001 10:30:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 95BFD91369; Fri, 8 Jun 2001 10:30:31 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0DE1991366 for ; Fri, 8 Jun 2001 10:30:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6CEEC5DDBB; Fri, 8 Jun 2001 10:30:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id B15BB5DDB0 for ; Fri, 8 Jun 2001 10:30:49 -0400 (EDT) Received: (qmail 8055 invoked by uid 500); 8 Jun 2001 14:20:10 -0000 Date: Fri, 8 Jun 2001 07:20:10 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 64: e2e draft editorial issues Message-ID: <20010608072010.J4931@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk I've already sent my comments on this particular issue, but there were two remaining items that needed to be addressed before it could be closed. - 6.5, I think it is better to keep the OCSP-desire and the nonce together. I do not know what this means? A grouped AVP? btw, the current draft is incorrect since it shows that the nonce and OSCP-Request can occur multiple times in the DSAR, and it MUST NOT occur more than once. The ABNF will be updated to reflect this. Jari, could you please expand on what you meant? - 6.8, I think we should just drop the top CA since that cert must be known by the initiator anyway. I agree, and the new version will reflect this change. Thanks, PatC From owner-aaa-wg@merit.edu Fri Jun 8 11:13:41 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14044 for ; Fri, 8 Jun 2001 11:13:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A7E5191398; Fri, 8 Jun 2001 11:13:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 76DE591400; Fri, 8 Jun 2001 11:13:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6B8BD91398 for ; Fri, 8 Jun 2001 11:13:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DD4FD5DDBC; Fri, 8 Jun 2001 11:14:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans-old.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 17CBF5DDBB for ; Fri, 8 Jun 2001 11:14:02 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA21344; Fri, 8 Jun 2001 11:12:16 -0400 (EDT) Date: Fri, 8 Jun 2001 11:12:38 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 70: Caching of redirects In-Reply-To: <4.3.2.7.2.20010608164905.00d58100@pop.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Jacques, I don't know why cache time is "recommended" either. I prefer DONT_CACHE to be default because in the case where you aren't caching, you will have the most traffic. So not having that AVP when there is the most traffic makes sense to me. -mark On Fri, 8 Jun 2001, Jacques Caron wrote: > At 16:45 08/06/01, Mark Eklund wrote: > > > 1. State that a value of 0 for Recommended-Redirect-Cache-Time means no > > > caching (and is not recommended but mandatory in this case?) > > > > > > 2. Add a new value for Redirect-Host-Usage: > > > DONT_CACHE 2 > > > The host specified in the Redirect-Host AVP should not > > > be cached. > > > >I would like a prefer a slight variation on this. Add a > >DONT_CACHE value, make it the first one, and make it default. > >That way, you don't cache unless you are told that caching is > >allowed. > > I agree with making it the first one, it's more logical. I thought about > making it the default, but I'm not so sure. It depends what we expect would > be the default behaviour, actually. And then it raises the issue of the > mandatory clause for the caching time. > > In fact, I would reverse the descriptions for the two AVPs, make DONT_CACHE > first, and state for the others that in those cases one can specify the > caching time with the other AVP. > > In the cache time AVP I would then probably add a default value... Though I > don't know how much that should be (5 minutes, an hour, a day...)? > > Still wonder why it should be "recommended" only, though? > > Jacques. > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > From owner-aaa-wg@merit.edu Fri Jun 8 11:16:56 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14157 for ; Fri, 8 Jun 2001 11:16:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8BDC691400; Fri, 8 Jun 2001 11:16:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 580B791402; Fri, 8 Jun 2001 11:16:31 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E025591400 for ; Fri, 8 Jun 2001 11:16:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5AA785DDBB; Fri, 8 Jun 2001 11:16:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by segue.merit.edu (Postfix) with ESMTP id B9A135DDB0 for ; Fri, 8 Jun 2001 11:16:56 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id IAA24318 for ; Fri, 8 Jun 2001 08:09:58 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id IAA27578 for ; Fri, 8 Jun 2001 08:16:30 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Jun 2001 10:16:30 -0500 Message-ID: From: Thomas Panagiotis-PTHOMAS1 To: "'Jacques Caron'" , Pat Calhoun Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 70: Caching of redirects Date: Fri, 8 Jun 2001 10:16:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk > I think it would be useful to also have a value for not allowing caching. Jacques, could you please elaborate more on this? I guess I have difficulties seeing why would a redirector recommend the requestor not to cache routing information. -Panos -----Original Message----- From: Jacques Caron [mailto:jacques_m_caron@yahoo.com] Sent: 08 June 2001 04:20 To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 70: Caching of redirects Hi, Sorry I couldn't get on the call. I think it would be useful to also have a value for not allowing caching. I guess it could be implicitly done with a value of 0 for Recommanded-Redirect-Cache-Time, but that should be stated as such? And since it's recommended only, that might not be strong enough? Jacques. At 02:42 08/06/01, Pat Calhoun wrote: >All, > >The following text reflects the decision that was taken during today's >discussion, and I'd like to get any WG comments on the proposed text. > >5.9 Recommended-Redirect-Cache-Time AVP > > The Recommended-Redirect-Cache-Time AVP (AVP Code TBD) is of type > Unsigned32. This AVP MUST be present in Message-Reject-Answer > messages that include the Result-Code AVP set to > DIAMETER_REDIRECT_INDICATION. > > This AVP contains the maximum number of seconds the redirector > recommends when caching any route entries resulting from the MRA > message. > > >5.10 Redirect-Host-Usage AVP > > The Redirect-Host-Usage AVP (AVP Code TBD) is of type Enumerated. > This AVP MAY be present in Message-Reject-Answer messages that > include the Result-Code AVP set to DIAMETER_REDIRECT_INDICATION. > > When present, this AVP dictates how the routing entry resulting from > the MRA is to be used. The following values are supported: > > ALL_REALM 0 > All messages destined for the realm requested MAY be sent to > the host specified in the Redirect-Host AVP. This is the > default value. > > REALM_AND_APPLICATION 1 > All messages for the application requested to the realm > specified MAY be sent to the host specified in the Redirect- > Host AVP. > > >Thanks, > >PatC _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Fri Jun 8 11:43:52 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14736 for ; Fri, 8 Jun 2001 11:43:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C0ECF91402; Fri, 8 Jun 2001 11:43:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 972CB91403; Fri, 8 Jun 2001 11:43:56 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7A65491402 for ; Fri, 8 Jun 2001 11:43:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CE2785DDBB; Fri, 8 Jun 2001 11:44:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 66D335DDB0 for ; Fri, 8 Jun 2001 11:44:21 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id IAA66661; Fri, 8 Jun 2001 08:33:13 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Fri, 8 Jun 2001 08:33:13 -0700 (PDT) From: Bernard Aboba To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 59: e2e mandatory status In-Reply-To: <20010608072337.L4931@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > I believe that the Minn meeting minutes show that cms is > mandatory to implement. This issue is asking whether this > was the correct decision. > > Could we get some WG discussions on this? I'd like to > get some agreement, and close this issue. > At IETF 50, we discussed this issue and were given guidance by the IESG that e2e security would need to be mandatory. The question is where. I would suggest that Relays and Re-directs have no need to implement e2e security. Servers MUST implement it -- and since proxies act as servers, that includes them too. The interesting question is whether NASes MUST implement e2e security. This seems somewhat too harsh to me, because some are quite modest devices (e.g. Access Points selling for $250). Also, it is likely that proxies will frequently be the endpoint for e2e, not NASes, purely for the purpose of manageability (don't have to put certs on every NAS, etc.). So this might be a SHOULD. From owner-aaa-wg@merit.edu Fri Jun 8 11:45:56 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14808 for ; Fri, 8 Jun 2001 11:45:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B276191401; Fri, 8 Jun 2001 10:32:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 04E0A91400; Fri, 8 Jun 2001 10:32:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7D44A91369 for ; Fri, 8 Jun 2001 10:32:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D79255DDBB; Fri, 8 Jun 2001 10:32:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 9880B5DDB0 for ; Fri, 8 Jun 2001 10:32:54 -0400 (EDT) Received: (qmail 8064 invoked by uid 500); 8 Jun 2001 14:22:15 -0000 Date: Fri, 8 Jun 2001 07:22:15 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 61: e2e cms and pki profiling Message-ID: <20010608072215.K4931@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, After having talked this over with my co-author, we both agree that some profiling would be beneficial, but both agree that this is something that should occur between proposed standard and draft standard. The reason being that this information will require implementations, and operational experience. Guessing the right profile prior to this may be tricky. Does anyone object? If not, then we could leave this issue open, but defer it to "Address in DS" Thanks, PatC From owner-aaa-wg@merit.edu Fri Jun 8 11:46:14 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14822 for ; Fri, 8 Jun 2001 11:46:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CF06791362; Fri, 8 Jun 2001 10:53:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9A14F91369; Fri, 8 Jun 2001 10:53:15 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8A8AA91362 for ; Fri, 8 Jun 2001 10:53:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F24BA5DDBB; Fri, 8 Jun 2001 10:53:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp010.mail.yahoo.com (smtp010.mail.yahoo.com [216.136.173.30]) by segue.merit.edu (Postfix) with SMTP id 78E2D5DDB0 for ; Fri, 8 Jun 2001 10:53:41 -0400 (EDT) Received: from pc25.paris-dc.fr.psi.com (HELO jc.yahoo.com) (212.81.116.25) by smtp.mail.vip.sc5.yahoo.com with SMTP; 8 Jun 2001 14:53:20 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010608164905.00d58100@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Jun 2001 16:53:04 +0200 To: Mark Eklund From: Jacques Caron Subject: Re: [AAA-WG]: Issue 70: Caching of redirects Cc: Pat Calhoun , aaa-wg@merit.edu In-Reply-To: References: <4.3.2.7.2.20010608155208.00c29820@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 16:45 08/06/01, Mark Eklund wrote: > > 1. State that a value of 0 for Recommended-Redirect-Cache-Time means no > > caching (and is not recommended but mandatory in this case?) > > > > 2. Add a new value for Redirect-Host-Usage: > > DONT_CACHE 2 > > The host specified in the Redirect-Host AVP should not > > be cached. > >I would like a prefer a slight variation on this. Add a >DONT_CACHE value, make it the first one, and make it default. >That way, you don't cache unless you are told that caching is >allowed. I agree with making it the first one, it's more logical. I thought about making it the default, but I'm not so sure. It depends what we expect would be the default behaviour, actually. And then it raises the issue of the mandatory clause for the caching time. In fact, I would reverse the descriptions for the two AVPs, make DONT_CACHE first, and state for the others that in those cases one can specify the caching time with the other AVP. In the cache time AVP I would then probably add a default value... Though I don't know how much that should be (5 minutes, an hour, a day...)? Still wonder why it should be "recommended" only, though? Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Fri Jun 8 12:23:52 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15729 for ; Fri, 8 Jun 2001 12:23:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DFCD09140C; Fri, 8 Jun 2001 12:17:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF1439140B; Fri, 8 Jun 2001 12:17:42 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5351B9140A for ; Fri, 8 Jun 2001 12:17:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CE8CF5DDBC; Fri, 8 Jun 2001 12:18:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by segue.merit.edu (Postfix) with SMTP id 542445DDB0 for ; Fri, 8 Jun 2001 12:18:02 -0400 (EDT) Received: from pc25.paris-dc.fr.psi.com (HELO jc.yahoo.com) (212.81.116.25) by smtp.mail.vip.sc5.yahoo.com with SMTP; 8 Jun 2001 16:17:41 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010608174513.00d414d0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Jun 2001 18:17:30 +0200 To: Thomas Panagiotis-PTHOMAS1 From: Jacques Caron Subject: RE: [AAA-WG]: Issue 70: Caching of redirects Cc: Pat Calhoun , aaa-wg@merit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 17:16 08/06/01, Thomas Panagiotis-PTHOMAS1 wrote: > > I think it would be useful to also have a value for not allowing caching. > >Jacques, could you please elaborate more on this? I guess I have >difficulties seeing why would a redirector recommend the requestor not to >cache routing information. I think I stated it in the original issue. Just in case, at least two situations where you wouldn't want that: 1. the redirection is not based on realm or realm+app. Might be based on Called or Calling number, might be based on part of the login (imagine you have one server handling customers with logins beginning with a-m, another for those with logins beginning with n-z), might be based on the NAS it comes from, on the service type. Anything, actually. It would be OK to cache if you can specify exactly what the key for caching is, but in the absence of that... 2. the redirector acts as a load balancer. Not sure this would be the best place to put LB features, but just in case... BTW, even if caching is not allowed or restricted, at least one case might be interesting to be allowed: cache the redirect host for all subsequent requests with the same session-ID/multi-session-ID/Class/State/whatever it is today. Maybe we need another value for Redirect-Host-Usage? Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Fri Jun 8 12:39:58 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16093 for ; Fri, 8 Jun 2001 12:39:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 372AB91409; Fri, 8 Jun 2001 12:40:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 035189140A; Fri, 8 Jun 2001 12:39:59 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DA9EF91409 for ; Fri, 8 Jun 2001 12:39:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4D8AF5DDBD; Fri, 8 Jun 2001 12:40:26 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 0A4205DDB0 for ; Fri, 8 Jun 2001 12:40:26 -0400 (EDT) Received: (qmail 11668 invoked by uid 500); 8 Jun 2001 16:29:46 -0000 Date: Fri, 8 Jun 2001 09:29:46 -0700 From: Pat Calhoun To: Bernard Aboba Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 59: e2e mandatory status Message-ID: <20010608092946.B11643@charizard.diameter.org> Mail-Followup-To: Bernard Aboba , Pat Calhoun , aaa-wg@merit.edu References: <20010608072337.L4931@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from aboba@internaut.com on Fri, Jun 08, 2001 at 08:33:13AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Fri, Jun 08, 2001 at 08:33:13AM -0700, Bernard Aboba wrote: > At IETF 50, we discussed this issue and were given guidance by the IESG > that e2e security would need to be mandatory. The question is where. I > would suggest that Relays and Re-directs have no need to implement e2e > security. Servers MUST implement it -- and since proxies act as servers, > that includes them too. See the CMS I-D on a relay initiating a CMS session on behalf of the access device. > > The interesting question is whether NASes MUST implement e2e > security. This seems somewhat too harsh to me, because some are quite > modest devices (e.g. Access Points selling for $250). Also, it is likely > that proxies will frequently be the endpoint for e2e, not NASes, purely > for the purpose of manageability (don't have to put certs on every NAS, > etc.). So this might be a SHOULD. I am ok with the NAS being a SHOULD, but operators will have to ensure that some device in their network supports it. PatC From owner-aaa-wg@merit.edu Fri Jun 8 12:47:43 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16326 for ; Fri, 8 Jun 2001 12:47:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 03A539140A; Fri, 8 Jun 2001 12:47:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2D7BF9140B; Fri, 8 Jun 2001 12:47:41 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 29BC29140A for ; Fri, 8 Jun 2001 12:47:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B46CC5DDBD; Fri, 8 Jun 2001 12:48:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 26C495DDB0 for ; Fri, 8 Jun 2001 12:48:07 -0400 (EDT) Received: (qmail 11742 invoked by uid 500); 8 Jun 2001 16:37:27 -0000 Date: Fri, 8 Jun 2001 09:37:27 -0700 From: Pat Calhoun To: Mark Eklund Cc: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 70: Caching of redirects Message-ID: <20010608093727.G11643@charizard.diameter.org> Mail-Followup-To: Mark Eklund , Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <4.3.2.7.2.20010608164905.00d58100@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from meklund@cisco.com on Fri, Jun 08, 2001 at 11:12:38AM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Fri, Jun 08, 2001 at 11:12:38AM -0400, Mark Eklund wrote: > I don't know why cache time is "recommended" either. Well, we can make it a MUST instead of a recommendation. But what happens if one doesn't cache entries? Are they non-conformant? PatC From owner-aaa-wg@merit.edu Fri Jun 8 13:06:58 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17155 for ; Fri, 8 Jun 2001 13:06:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C78969140B; Fri, 8 Jun 2001 13:06:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 919A19140D; Fri, 8 Jun 2001 13:06:46 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4C3949140B for ; Fri, 8 Jun 2001 13:06:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BD85A5DDBD; Fri, 8 Jun 2001 13:07:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by segue.merit.edu (Postfix) with SMTP id 4421E5DDB0 for ; Fri, 8 Jun 2001 13:07:12 -0400 (EDT) Received: from pc25.paris-dc.fr.psi.com (HELO jc.yahoo.com) (212.81.116.25) by smtp.mail.vip.sc5.yahoo.com with SMTP; 8 Jun 2001 17:06:44 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010608190320.00d27260@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Jun 2001 19:06:31 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 70: Caching of redirects Cc: Mark Eklund , Pat Calhoun , aaa-wg@merit.edu In-Reply-To: <20010608093727.G11643@charizard.diameter.org> References: <4.3.2.7.2.20010608164905.00d58100@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 18:37 08/06/01, Pat Calhoun wrote: >On Fri, Jun 08, 2001 at 11:12:38AM -0400, Mark Eklund wrote: > > I don't know why cache time is "recommended" either. > >Well, we can make it a MUST instead of a recommendation. But >what happens if one doesn't cache entries? Are they non-conformant? I'd at least say that the host sending the request MUST NOT cache the redirect-Host longer than the value of the AVP. Doesn't force it to cache, but makes sure that it doesn't cache it longer than the redirector wants. You can see that a bit like DNS TTL or HTTP expiration (or whatever it's nowadays in Cache-Control). Nothing prevents the requestor/proxy from forgetting immediately about it, but it should not keep it longer than indicated. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Fri Jun 8 13:21:17 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17415 for ; Fri, 8 Jun 2001 13:21:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5E1789140E; Fri, 8 Jun 2001 13:18:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 13F8D91411; Fri, 8 Jun 2001 13:18:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 306149140E for ; Fri, 8 Jun 2001 13:16:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BC3965DDC0; Fri, 8 Jun 2001 13:17:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 2E6135DDB0 for ; Fri, 8 Jun 2001 13:17:06 -0400 (EDT) Received: (qmail 12954 invoked by uid 500); 8 Jun 2001 17:06:26 -0000 Date: Fri, 8 Jun 2001 10:06:26 -0700 From: Pat Calhoun To: Mark Eklund Cc: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 70: Caching of redirects Message-ID: <20010608100626.K11643@charizard.diameter.org> Mail-Followup-To: Mark Eklund , Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <4.3.2.7.2.20010608190320.00d27260@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from meklund@cisco.com on Fri, Jun 08, 2001 at 01:14:34PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Fri, Jun 08, 2001 at 01:14:34PM -0400, Mark Eklund wrote: > Pat, I agree with Jacques. Maybe a name of I was thinking > Maximum-Redirect-Cache-Time makes more sense. sounds good. > > One question. We mentioned creating a default value for > Maximum-Redirect-Cache-Time. This would only be true if it > isn't required in a Message-Reject-Answer of type > DIAMETER_REDIRECT_INDICATION. Should it no longer be required > and just have a default value if not present? That works for me if the default is to cache. patC From owner-aaa-wg@merit.edu Fri Jun 8 16:15:50 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20095 for ; Fri, 8 Jun 2001 16:15:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C7FE19121B; Fri, 8 Jun 2001 13:14:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 91DE19140D; Fri, 8 Jun 2001 13:14:27 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 837EF9121B for ; Fri, 8 Jun 2001 13:14:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 058A45DDC0; Fri, 8 Jun 2001 13:14:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans-old.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 2E7035DDB0 for ; Fri, 8 Jun 2001 13:14:53 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA22193; Fri, 8 Jun 2001 13:14:13 -0400 (EDT) Date: Fri, 8 Jun 2001 13:14:34 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 70: Caching of redirects In-Reply-To: <4.3.2.7.2.20010608190320.00d27260@pop.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Pat, I agree with Jacques. Maybe a name of I was thinking Maximum-Redirect-Cache-Time makes more sense. One question. We mentioned creating a default value for Maximum-Redirect-Cache-Time. This would only be true if it isn't required in a Message-Reject-Answer of type DIAMETER_REDIRECT_INDICATION. Should it no longer be required and just have a default value if not present? -mark On Fri, 8 Jun 2001, Jacques Caron wrote: > At 18:37 08/06/01, Pat Calhoun wrote: > >On Fri, Jun 08, 2001 at 11:12:38AM -0400, Mark Eklund wrote: > > > I don't know why cache time is "recommended" either. > > > >Well, we can make it a MUST instead of a recommendation. But > >what happens if one doesn't cache entries? Are they non-conformant? > > I'd at least say that the host sending the request MUST NOT cache the > redirect-Host longer than the value of the AVP. Doesn't force it to cache, > but makes sure that it doesn't cache it longer than the redirector wants. > > You can see that a bit like DNS TTL or HTTP expiration (or whatever it's > nowadays in Cache-Control). Nothing prevents the requestor/proxy from > forgetting immediately about it, but it should not keep it longer than > indicated. > > Jacques. > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > From owner-aaa-wg@merit.edu Sun Jun 10 15:39:14 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13225 for ; Sun, 10 Jun 2001 15:39:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C868D9125D; Sun, 10 Jun 2001 15:39:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8E1649125E; Sun, 10 Jun 2001 15:39:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 75B629125D for ; Sun, 10 Jun 2001 15:39:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0A2915DD90; Sun, 10 Jun 2001 15:39:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by segue.merit.edu (Postfix) with ESMTP id 23D6E5DD8D for ; Sun, 10 Jun 2001 15:39:34 -0400 (EDT) Received: from jariws1 ([62.248.154.223]) by fep01-app.kolumbus.fi (InterMail vM.5.01.02.00 201-253-122-103-20001017) with SMTP id <20010610193909.JMED16740.fep01-app.kolumbus.fi@jariws1>; Sun, 10 Jun 2001 22:39:09 +0300 Message-ID: <00fe01c0f2ae$37a27980$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Bernard Aboba" , "Pat Calhoun" Cc: References: Subject: Re: [AAA-WG]: Issue 59: e2e mandatory status Date: Mon, 11 Jun 2001 22:39:23 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >The question is where. Yes! > would suggest that Relays and Re-directs have no need to implement e2e > security. Right. >Servers MUST implement it -- and since proxies act as servers, > that includes them too. Sounds ok. > The interesting question is whether NASes MUST implement e2e > security. This seems somewhat too harsh to me, because some are quite > modest devices (e.g. Access Points selling for $250). Also, it is likely > that proxies will frequently be the endpoint for e2e, not NASes, purely > for the purpose of manageability (don't have to put certs on every NAS, > etc.). So this might be a SHOULD. I support SHOULD. Jari From owner-aaa-wg@merit.edu Sun Jun 10 16:02:00 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13334 for ; Sun, 10 Jun 2001 16:01:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9F98D91260; Sun, 10 Jun 2001 16:01:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6F6DA91262; Sun, 10 Jun 2001 16:01:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 612FD91260 for ; Sun, 10 Jun 2001 16:01:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1AEBF5DD90; Sun, 10 Jun 2001 16:02:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from hip.baltimore.ie (unknown [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id DE3B05DD8D for ; Sun, 10 Jun 2001 16:02:27 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by hip.baltimore.ie (8.9.3/8.9.3) with SMTP id VAA23595 for ; Sun, 10 Jun 2001 21:02:03 +0100 Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.1) with SMTP id for ; Sun, 10 Jun 2001 21:00:09 +0100 Received: from baltimore.ie (wks114-25.ie.baltimore.com [10.153.25.114]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id VAA19399; Sun, 10 Jun 2001 21:09:48 +0100 Message-ID: <3B23D23D.338D428@baltimore.ie> Date: Sun, 10 Jun 2001 21:02:05 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko Cc: Bernard Aboba , Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 59: e2e mandatory status References: <00fe01c0f2ae$37a27980$8a1b6e0a@arenanet.fi> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit One note, > > The interesting question is whether NASes MUST implement e2e > > security. This seems somewhat too harsh to me, because some are quite > > modest devices (e.g. Access Points selling for $250). Also, it is likely > > that proxies will frequently be the endpoint for e2e, not NASes, purely > > for the purpose of manageability (don't have to put certs on every NAS, > > etc.). So this might be a SHOULD. > > I support SHOULD. A NAS can easily support parts of the CMS app. Basically, the difference is whether the NAS has a private key or not. If it hasn't then the configuration of the NAS for CMS only requires static data like root CA keys and the only cost that'd possibly appear in the $250 is code footprint. (In case someone's skeptical about this, mobile phones also cost about that amount and some include similar functionality.) Also worth noting is that there's really not that much additional footprint required if you add the private key operations. The costs related to private key support are largely around provisioning and the like. ('Course if someone wants to save some dosh, leave a space for a WIM chipcard in your NAS - there'll be lots of them about.) On this basis, my preference would be to make support for the CMS app a MUST, but to explicitly call out (wherever the text goes - where's that?) that even with the CMS app code present, you can't assume that a private key is actually present - this means that a conformant NAS can be developed, configured and used without incurring the costly side of the CMS app. (which is NAS-specific provisioning) Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Sun Jun 10 19:19:16 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14505 for ; Sun, 10 Jun 2001 19:19:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B595891265; Sun, 10 Jun 2001 19:19:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8359591266; Sun, 10 Jun 2001 19:19:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 60D7A91265 for ; Sun, 10 Jun 2001 19:19:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4F5FA5DD9A; Sun, 10 Jun 2001 19:19:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by segue.merit.edu (Postfix) with SMTP id 064BB5DD90 for ; Sun, 10 Jun 2001 19:19:51 -0400 (EDT) Received: from jc-mac.planete.net (HELO jc.yahoo.com) (194.2.222.120) by smtp.mail.vip.sc5.yahoo.com with SMTP; 10 Jun 2001 23:19:25 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010606233818.00c1fba0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Jun 2001 00:54:33 +0200 To: aaa-wg@merit.edu From: Jacques Caron Subject: [AAA-WG]: [Issue] Various editorial changes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Jacques Caron Submitter email address: jacques_m_caron@yahoo.com Date first submitted: 11-Jun-2001 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg01150.html Document: Base Comment type: E Priority: 2 Section: throughout Rationale/Explanation of issue: In 4.1 AVP Header: - still mentions both 'r' and reserved bits - says that unrecognized bits should be considered an error, but also that r/reserved bits should be ignored. In 4.3 AVP Data formats, max length of an OctetString is still 65504 (btw, why was it 65504 and not 2^16-20=65516?) In 5.1 Processing Local Messages, "the local host's identity is encoded in the Origin-Host and Origin-Host AVPs" (double Origin-Host) In 5.3 Message Routing, Diameter agents *MAY* have a list of locally supported realms... In 6.0, 6.1, minor editing. In 7.2, remove unused RTO stuff. Requested changes: In 4.1, replace: AVP Flags The AVP Flags field informs the receiver how each attribute must be handled. Note that subsequent Diameter applications MAY define bits to be used within the AVP Header, and an unrecognized bit should be considered an error. The 'r' and the reserved bits are unused and should be set to 0 and ignored on receipt, while the 'P' bit is defined in [11]. With: AVP Flags The AVP Flags field informs the receiver how each attribute must be handled. The 'r' (reserved) bits are unused and SHOULD be set to 0. Note that subsequent Diameter applications MAY define additional bits within the AVP Header, and an unrecognized bit SHOULD be considered an error. The 'P' bit is defined in [11]. In 4.3, replace: OctetString The data contains arbitrary data of variable length. Unless otherwise noted, the AVP Length field MUST be set to at least 8 (12 if the 'V' bit is enabled). Data used to transmit (human readable) character string data uses the UTF-8 [24] character set and is NOT NULL-terminated. The minimum Length field MUST be 9, but can be set to any value up to 65504 bytes. AVP Values of this type that do not align on a 32-bit boundary MUST have the necessary padding. With: OctetString The data contains arbitrary data of variable length. Unless otherwise noted, the AVP Length field MUST be set to at least 8 (12 if the 'V' bit is enabled). Data used to transmit (human readable) character string data uses the UTF-8 [24] character set and is NOT NULL-terminated. The minimum Length field MUST be 9, but can be set to any value up to 2^24-20=16777196 bytes. AVP Values of this type that do not align on a 32-bit boundary MUST have the necessary padding. In 5.1, replace: - The local host's identity is encoded in the Origin-Host and Origin-Host AVPs. With: - The local host's identity is encoded in the Origin-Host AVPs. In 5.3, replace: Diameter agents have a list of locally supported realms, and MAY have a list of externally supported realms. When a request is received that includes a realm that is not locally supported, the message is routed to the peer configured in the Domain Routing Table table (see section 5.3.1). With: Diameter agents MAY have a list of locally supported realms, and MAY have a list of externally supported realms. When a request is received that includes a realm that is not locally supported, the message is routed to the peer configured in the Domain Routing Table table (see section 5.3.1). In 6.0 Capabilities Exchange, replace: When two Diameter peers establish a transport connection, they MUST exchange the Device Reboot messages, as specified in the peer state machine (see section 8.0). This message has two purposes. First it allows a peer's identity to be discovered, and allows for capabilities exchange, such as the supported protocol version number, the locally supported Diameter applications, etc. With: When two Diameter peers establish a transport connection, they MUST exchange the Capabilities Exchange messages, as specified in the peer state machine (see section 8.0). This message allows the discovery of both the peer's identity, and its capabilities, such as the supported protocol version number, the locally supported Diameter applications, etc. In 6.1 Application Identifiers, replace: Relay and redirect agents MUST advertise the Proxy application identifier, while all other Diameter nodes MUST advertise locally supported applications. The receiver of a Device Reboot message advertising Relay service MUST assume that the sender supports all current and future applications. with: Relay and redirect agents MUST advertise the Relay application identifier, while all other Diameter nodes MUST advertise locally supported applications. The receiver of a Capabilities Exchange message advertising Relay service MUST assume that the sender supports all current and future applications. In 7.2 Device-Watchdog-Answer, remove: A receiver of the DWA SHOULD perform RTT calculation in the event that the transport RTO information is not available. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Sun Jun 10 20:29:45 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA14974 for ; Sun, 10 Jun 2001 20:29:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A9CB991269; Sun, 10 Jun 2001 19:19:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F29691266; Sun, 10 Jun 2001 19:19:27 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7419891267 for ; Sun, 10 Jun 2001 19:19:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 665FC5DD90; Sun, 10 Jun 2001 19:19:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by segue.merit.edu (Postfix) with SMTP id DB1625DD8D for ; Sun, 10 Jun 2001 19:19:52 -0400 (EDT) Received: from jc-mac.planete.net (HELO jc.yahoo.com) (194.2.222.120) by smtp.mail.vip.sc5.yahoo.com with SMTP; 10 Jun 2001 23:19:28 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010611005402.00cc4620@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Jun 2001 01:11:01 +0200 To: aaa-wg@merit.edu From: Jacques Caron Subject: [AAA-WG]: [Issue] Downstream/upstream confusion Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Jacques Caron Submitter email address: jacques_m_caron@yahoo.com Date first submitted: 11-Jun-2001 Reference: Document: Base Comment type: E Priority: 1 Section: throughout Rationale/Explanation of issue: The terms "upstream" and "downstream" are not used consistently. Even the definitions seem contrary to logic: things usually flow from upstream to downstream, so upstream should be towards the client, and downstream towards the home server. Requested changes: In 1.3 Terminology, replace: Downstream Server Diameter Proxy servers identify a downstream server as one that is providing routing services towards the Diameter client. with: Downstream Server Diameter Proxy servers identify a downstream server as one that is providing routing services towards the home server for a particular message. and replace: Upstream Server Diameter Proxy servers identify an upstream server as one that is providing routing services towards the home server for a particular message. with: Upstream Server Diameter Proxy servers identify an upstream server as one that is providing routing services towards the Diameter client. In 2.5.2 Proxy Agents, replace: Similarly to Relays, Proxy agents route Diameter messages using the Diameter Routing Table. However, they differ since they modify messages to implement policy enforcement. This requires that proxies maintain the state of their downstream peers (e.g. access devices) to enforce resource usage, provide admission control, and provisioning. with: Similarly to Relays, Proxy agents route Diameter messages using the Diameter Routing Table. However, they differ since they modify messages to implement policy enforcement. This requires that proxies maintain the state of their upstream peers (e.g. access devices) to enforce resource usage, provide admission control, and provisioning. In 6.0 Capabilities Exchange, replace: Since the CER/CEA messages cannot be proxied, it is still possible that an upstream proxy receives a message for which it has no available peers to handle the application that corresponds to the Command-Code. In such instances, the Message-Reject-Answer message is used (see Section 9.2.1) to inform the downstream to take action (e.g. re-routing request to an alternate peer). With: Since the CER/CEA messages cannot be proxied, it is still possible that a downstream proxy receives a message for which it has no available peers to handle the application that corresponds to the Command-Code. In such instances, the Message-Reject-Answer message is used (see Section 9.2.1) to inform the upstream to take action (e.g. re-routing request to an alternate peer). In 9.0, Error Handling, replace: Figure 4 provides an example of a message forwarded upstream by a Diameter relay. When the message is received by Relay 2, and it detects that it cannot forward the request to the home server, an MRA message is returned with the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER. Given that this error falls within the protocol error category, Relay 1 would take special action, and given the error, attempt to route the message through its alternate Relay 3. with: Figure 4 provides an example of a message forwarded downstream by a Diameter relay. When the message is received by Relay 2, and it detects that it cannot forward the request to the home server, an MRA message is returned with the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER. Given that this error falls within the protocol error category, Relay 1 would take special action, and given the error, attempt to route the message through its alternate Relay 3. Alternatively, leave the definitions as they are (though I don't understand them?) and fix down/upstream in 6.2 and 10.10. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Sun Jun 10 23:40:38 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA18300 for ; Sun, 10 Jun 2001 23:40:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9E3E491270; Sun, 10 Jun 2001 23:40:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 61D4891271; Sun, 10 Jun 2001 23:40:34 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 55B0C91270 for ; Sun, 10 Jun 2001 23:40:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9F6375DD9D; Sun, 10 Jun 2001 23:41:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by segue.merit.edu (Postfix) with ESMTP id C57FF5DD9C for ; Sun, 10 Jun 2001 23:41:04 -0400 (EDT) Received: from jariws1 ([62.248.154.223]) by fep02-app.kolumbus.fi (InterMail vM.5.01.02.00 201-253-122-103-20001017) with SMTP id <20010611034040.BFJE22409.fep02-app.kolumbus.fi@jariws1>; Mon, 11 Jun 2001 06:40:40 +0300 Message-ID: <012c01c0f2f1$7db49280$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: Cc: "Bernard Aboba" , "Pat Calhoun" , References: <00fe01c0f2ae$37a27980$8a1b6e0a@arenanet.fi> <3B23D23D.338D428@baltimore.ie> Subject: Re: [AAA-WG]: Issue 59: e2e mandatory status Date: Tue, 12 Jun 2001 06:40:57 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > A NAS can easily support parts of the CMS app. Basically, the difference > is whether the NAS has a private key or not. If it hasn't then the Well, this is one aspect but there aren't there also issues in making e.g. a 50k-port NAS be prepared to do PK cryptographic operations per each call (worst case call distribution to different end servers etc)? Note that h2h security would be set-up just once at boot time, or might even be statically keyed in the case of IPsec. Jari From owner-aaa-wg@merit.edu Mon Jun 11 04:10:13 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04617 for ; Mon, 11 Jun 2001 04:10:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1A87391275; Mon, 11 Jun 2001 04:10:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DE77491276; Mon, 11 Jun 2001 04:10:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C20D491275 for ; Mon, 11 Jun 2001 04:10:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5A7545DDAF; Mon, 11 Jun 2001 04:10:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from hip.baltimore.ie (unknown [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id DFA805DD9C for ; Mon, 11 Jun 2001 04:10:39 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by hip.baltimore.ie (8.9.3/8.9.3) with SMTP id JAA24267 for ; Mon, 11 Jun 2001 09:10:14 +0100 Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.1) with SMTP id for ; Mon, 11 Jun 2001 09:08:19 +0100 Received: from baltimore.ie (ip226-24.ie.baltimore.com [10.153.24.226]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id JAA26265; Mon, 11 Jun 2001 09:18:04 +0100 Message-ID: <3B247CED.8DA56516@baltimore.ie> Date: Mon, 11 Jun 2001 09:10:21 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko Cc: Bernard Aboba , Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 59: e2e mandatory status References: <00fe01c0f2ae$37a27980$8a1b6e0a@arenanet.fi> <3B23D23D.338D428@baltimore.ie> <012c01c0f2f1$7db49280$8a1b6e0a@arenanet.fi> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jari, Jari Arkko wrote: > > > A NAS can easily support parts of the CMS app. Basically, the difference > > is whether the NAS has a private key or not. If it hasn't then the > > Well, this is one aspect but there aren't there also issues in making e.g. > a 50k-port NAS be prepared to do PK cryptographic operations per each call > (worst case call distribution to different end servers etc)? Note that h2h security > would be set-up just once at boot time, or might even be statically keyed in the > case of IPsec. With the algorithm we're using (RSA) public key operations aren't much slower than the symmetric crypto that'll be used for h2h. Private key operations OTOH are expensive on a less capable CPU, which is what I guess you mean. Bottom line is that this can be treated the same as the issue as I raised in my last mail (provisioning). Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Mon Jun 11 04:36:26 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04804 for ; Mon, 11 Jun 2001 04:36:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5D38691276; Mon, 11 Jun 2001 04:36:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 22DEF91277; Mon, 11 Jun 2001 04:36:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A965B91276 for ; Mon, 11 Jun 2001 04:36:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4EAD75DDBA; Mon, 11 Jun 2001 04:37:03 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 64B0F5DD97 for ; Mon, 11 Jun 2001 04:37:02 -0400 (EDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f5B8abO29162 for ; Mon, 11 Jun 2001 10:36:37 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Mon Jun 11 10:36:33 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Jun 2001 10:36:32 +0200 Message-ID: <577066326047D41180AC00508B955DDA04D1A991@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'aaa-wg@merit.edu'" Cc: "Martin Julien (ECE)" Subject: [AAA-WG]: NASREQ Request-Type AVP??? Date: Mon, 11 Jun 2001 10:36:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA04804 Hi, Looking at the NASREQ Request-Type AVP, I would appreciate if someone could give me his interpretation of the following possible values for the Request-Type AVP. >> AUTHENTICATE_ONLY 1 The request being sent is for authentication only, and MUST contain the relevant authentication AVPs that are needed by the Diameter server to authenticate the user. << Since the specification says that it should not be permitted to authenticate-only a session, and then authorize-only the same session, I was wondering for what that value could really be useful? Should that Request-Type value be only used when answering a AA-Request Challenge? That also suggests that a scenario in which an authenticate-only followed by an authorize-only for the same session does not seem to be a valid one between a NAS and a AAA server, right? Then, AA-request with Authenticate-Only for sessions that are not already started should simply be rejected. What result-code should be used? DIAMETER_UNKNOWN_SESSION_ID?, or DIAMETER_AUTHORIZATION_REJECTED? Also, when a session is already started, should we consider the session to be renewed in terms of Authorization- Lifetime, when it is received? I think that it should not be renewed, since only a re-authorization request should renew the authorization- lifetime, unless it is in response to a challenge sent by the AAA server, to re-authenticate, right? >> AUTHORIZE_ONLY 2 The request being sent is for authorization only, and MUST contain the authorization AVPs that are necessary to identify the service being requested/offered. << I guess that a new session should then be started, if not already started. Also, when it is already started, such a request should renew the lease for the authorization, which means the Authorization-Lifetime. Normally, that should be received when a request for a tunnel is made, which I guess means that the NAS should have known in advance that the request would be tunnelled???, and also possibly for re-authorization of an existing session. Should such requests be rejected when received in the AAA for which no tunnel is defined and no session is already started? By the way, when a AA-Request is received in a AAA server without a User-Name, but containing either a Called-Station-Id or a Calling-Station-Id, is it implicit that tunnelling should be defined in the receiving AAA node or not? The thing is that I am wondering if it is possible for a AAA proxy server to forward an AA-Request based on DNI or ANIS? Is it common practice? Since the specification considers that the allowed usage of those fields is outside its scope, I guess it does not have to be reserved for tunnel, but I´m not sure?? BR, Martin From owner-aaa-wg@merit.edu Mon Jun 11 04:57:03 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04950 for ; Mon, 11 Jun 2001 04:57:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 44E9291277; Mon, 11 Jun 2001 04:56:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0C8F191278; Mon, 11 Jun 2001 04:56:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DC35E91277 for ; Mon, 11 Jun 2001 04:56:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8E3E25DD9C; Mon, 11 Jun 2001 04:57:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp010.mail.yahoo.com (smtp010.mail.yahoo.com [216.136.173.30]) by segue.merit.edu (Postfix) with SMTP id 440815DD97 for ; Mon, 11 Jun 2001 04:57:30 -0400 (EDT) Received: from jc-mac.planete.net (HELO jc.yahoo.com) (194.2.222.120) by smtp.mail.vip.sc5.yahoo.com with SMTP; 11 Jun 2001 08:57:04 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010611105046.00c493f0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Jun 2001 10:55:43 +0200 To: "Martin Julien (ECE)" From: Jacques Caron Subject: Re: [AAA-WG]: NASREQ Request-Type AVP??? Cc: "'aaa-wg@merit.edu'" In-Reply-To: <577066326047D41180AC00508B955DDA04D1A991@eestqnt104.es.eu. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 10:36 11/06/01, Martin Julien (ECE) wrote: >Hi, > >Looking at the NASREQ Request-Type AVP, I would appreciate if >someone could give me his interpretation of the following >possible values for the Request-Type AVP. > > >> > AUTHENTICATE_ONLY 1 > The request being sent is for authentication only, and MUST > contain the relevant authentication AVPs that are needed by the > Diameter server to authenticate the user. ><< > >Since the specification says that it should not be permitted to >authenticate-only a session, and then authorize-only the same session, >I was wondering for what that value could really be useful? >Should that Request-Type value be only used when answering a AA-Request >Challenge? The nasreq draft indeed says in 3.1.1: It is possible for a single session to be authorized only first, then followed by an authentication request. However, the inverse SHOULD NOT be permitted. I quite think that somebody meant the opposite (e.g. TAC+ to Diameter gateway where authentication and authorization are two different steps, done in that order). On cannot authorize a user which hasn't been authenticated yet. The other possibility is that some authorization is granted first (e.g. based on calling/called numbers to authorize a NAS to accept an ISDN call), then authentication and authorization again (using PPP and some PPP authentication method). But I'm not quite sure both would be linked to the same session, actually, since it would be two different services? Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Mon Jun 11 07:14:36 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06313 for ; Mon, 11 Jun 2001 07:14:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7B4B191278; Mon, 11 Jun 2001 07:14:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 490F891279; Mon, 11 Jun 2001 07:14:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1C69A91278 for ; Mon, 11 Jun 2001 07:14:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F1D1F5DDC3; Mon, 11 Jun 2001 07:15:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59]) by segue.merit.edu (Postfix) with SMTP id 29C7D5DDBC for ; Mon, 11 Jun 2001 07:15:03 -0400 (EDT) Received: from jc-mac.planete.net (HELO jc.yahoo.com) (194.2.222.120) by smtp.mail.vip.sc5.yahoo.com with SMTP; 11 Jun 2001 11:14:37 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010611101130.00bfd900@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Jun 2001 13:10:35 +0200 To: aaa-wg@merit.edu From: Jacques Caron Subject: [AAA-WG]: [Issue] Request & answer routing clarification Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Jacques Caron Submitter email address: jacques_m_caron@yahoo.com Date first submitted: 11-Jun-2001 Reference: Document: Base Comment type: E Priority: 2 Section: throughout 5.x Rationale/Explanation of issue: It is necessary to clarify the use of Destination-Realm & Destination-Host in Request routing. If I finally got it right, Destination-Host is used only to target a specific host within a number of servers serving a given realm. This is achieved by sending to that host when said host is in the peer table, otherwise Destination-Realm is used. When reading the draft, it looks like it is used to talk directly from the client to the specified server. Should be described early in 5.0, not be spread over 5.0, 5.1, 5.2. This is also somewhat linked to the proposed text for issue 56 (flag bit for start of conversation). It is also necessary to clarify the following points for answer routing: - it is completely different from request routing - no Destination-Realm should be present Other misc. changes: - add default routing table entry description. - change "Domain" to "Realm" - clarify actions on origination and sending of message, including saving pending requests Requested change: Sorry, a bit long. The important changes are: - added overview in 5.1, with 3 cases for Destination-Realm & Destination-Host - added sections 5.1.1 & 5.1.2 about originated and sending a request - separated request (5.1.x) and answer (5.2.x) processing & routing - used "request" rather than message where it is needed to clarify things - moved answer generation to 5.2 - changed "domain" to "realm" in routing table - added default routing table entry discussion The rest is mainly renumbering and moving stuff around. Replace sections 5.0 to 5.3.5 with: 5.0 Diameter message processing This section describes how Diameter requests and answers are created and processed. 5.1 Diameter request routing overview A request is sent towards its final destination using a combination of the Destination-Realm and Destination-Host AVPs, in one of these three combinations: - a request that is not proxiable (such as CER) MUST NOT contain either Destination-Realm or Destination-Host AVPs. - a request that needs to be sent to a home server serving a specific realm, but not to a specific server (such as the first request of a series of round-trips), MUST contain a Destination-Realm AVP, but MUST NOT contain a Destination-Host AVP. - a request that needs to be sent to a specific home server among those serving a given realm, MUST contain both the Destination-Realm and Destination-Host AVPs. The Destination-Host AVP is used as described above when the destination of the request is fixed, which includes: - Authentication requests that span multiple round trips - A Diameter request that uses a security mechanism that makes use of a pre-established session key shared between the source and the final destination of the request. - Server initiated requests that MUST be received by a specific Diameter client (e.g. access device), such as the Abort- Session-Request message, which is used to request that a particular user's session be terminated. Note that an agent can forward a request to a host described in the Destination-Host AVP only if said host is included in its peer table (see sections 5.1.4 and 5.1.5). Otherwise, the request is routed based on the Destination-Realm only (see sections 5.1.6 and 5.1.7). The Destination-Realm AVP MUST be present if the request is routable. A request that MUST NOT be relayed, proxied or redirected MUST NOT include the Destination-Realm in its ABNF. The value of the Destination-Realm AVP MAY be extracted from the User-Name AVP, or other application-specific methods. When a request is received, the message is processed in the following order: 1. If the request is destined for the local host, the procedures listed in section 5.1.1 are followed. 2. If the request is intended for a Diameter peer with whom the local host is able to directly communicate with, the procedures listed in section 5.1.2 are followed. This is known as Message Forwarding. 3. The procedures listed in section 5.1.4 are followed, which is known as Message Routing. 4. If none of the above are successful, an answer is returned with the Result-Code set to DIAMETER_UNABLE_TO_DELIVER. Note the processing rules contained in this section are intended to be used as general guidelines to Diameter developers. Certain implementations MAY use different methods than the ones described here, and still be in compliance with the protocol specification. 5.1.1 Originating a Request When creating a request, on top of any other procedures described in the application definition for that specific request, the following procedures MUST be followed: - the Command-Code should be set to the appropriate value - the 'R' bit should be set - the End-to-End Identifier should be set to a locally unique value - the Origin-Host and Origin-Realm AVPs MUST be set to the appropriate values, used to identify the source of the message - the Destination-Host and Destination-Realm AVPs MUST be set to the appropriate values as described in section 5.1. 5.1.2 Sending a Request When sending a request, either originated locally, or as the result of a forwarding or routing operation, the following procedures MUST be followed: - the Hop-by-Hop Identifier should be set to a locally unique value - the message should be saved in the list of pending requests Other actions to perform on the message based on the particular role the agent is playing are described in the following sections. 5.1.3 Processing Local Requests A request is known to be for local comsumption when one of the following conditions occur: - The Destination-Host AVP contains the local host's identity, - The Destination-Host AVP is not present, the Destination-Realm AVP contains a realm the server is configured to process locally, and the Diameter application is locally supported, or - The Destination-Realm AVP is not present. When a request is locally processed, the rules in section 5.2 should be used to generate the associated answer. 5.1.4 Request Forwarding Request forwarding is done using the Diameter Peer Table. The Diameter peer table contains all of the peers that the local node is able to directly communicate with. When a request is received, and the host encoded in the Destination- Host AVP is one that is present in the peer table, the message SHOULD be forwarded to the peer. 5.1.5 Peer Table The Diameter Peer Table is used in message forwarding, and referenced by the Domain Routing Table. A Peer Table entry contains the following fields: - Host descriptor, as defined in section 2.7. This MAY be resolved locally, or known via the CER or CEA message. - TLS Enabled. Specifies whether TLS is to be used when communicating with the peer. - Security informations (keys, certificates...) as appropriate. 5.1.6 Request Routing Diameter request message routing is done via realms. A Diameter message that is proxyable MUST include the target realm in the Destination-Realm AVP. The realm MAY be retrieved from the User-Name AVP, which is in the form of a Network Access Identifier (NAI). The realm portion of the NAI is inserted in the Destination-Realm AVP. Diameter agents have a list of locally supported realms, and MAY have a list of externally supported realms. When a request is received that includes a realm that is not locally supported, the message is routed to the peer configured in the Domain Routing Table table (see following section). 5.1.7 Realm-Based Routing Table All Realm-Based routing lookups are performed against what is commonly known as the Realm Routing Table (see section 16.0). A Realm Routing Table Entry contains the following fields: - Realm Name. This is the field that is typically used as a primary key in the routing table lookups. Note that some implementations perform their lookups based on longest-match- from-the-right on the realm rather than requiring an exact match. - Application Identifier. It is possible for a routing entry to have a different destination based on the Acct-Application-Id (for accounting messages) or Auth-Application-Id (for non- accounting messages) of the message. This field is typically used as a secondary key field in routing table lookups. - Local Action. The Local Action field is used to identify how a message should be treated. The following actions are supported: 1. LOCAL - Diameter messages that resolve to a routing entry with the Local Action set to Local can be satisfied locally, and do not need to be routed to another server. 2. RELAY - All Diameter messages that fall within this category MUST be routed to a next hop server, without modifying any non-routing AVPs. See section 5.1.9 for relaying guidelines 3. PROXY - All Diameter messages that fall within this category MUST be routed to a next hop server. The local server MAY apply its local policies to the message by including new AVPs to the message prior to routing. See section 5.1.9 for relaying guidelines. 4. REDIRECT - Diameter messages that fall within this category MUST have the identity of the home Diameter server(s) appended, and returned to the sender of the message. See section 5.1.8 for redirect guidelines. - Server Identifier - One or more servers the message is to be routed to. These servers MUST also be present in the Peer table. When the Local Action is set to RELAY or PROXY, this field contains the identity of the server(s) the message must be routed to. When the Local Action field is set to REDIRECT, this field contains the identity of one or more servers the message should be redirected to. It is important to note that Diameter agents MUST support at least one of the LOCAL, RELAY, PROXY or REDIRECT modes of operation. Agents do not need to support all modes of operation in order to conform with the protocol specification, but MUST follow the protocol compliance guidelines in section 2.0. Relay agents MUST NOT reorder AVPs, and proxies SHOULD NOT reorder AVPs. The routing table MAY include a default entry which MUST be used for any requests not matching any of the other entries. The routing table MAY consist of only such an entry. When a request is routed, the target server MUST have advertised the Application Identifier (see section 6.1) for the given message, or have advertised itself as a relay or proxy agent. 5.1.8 Redirecting requests [... unchanged from 5.3.2 in current draft ...] 5.1.9 Relaying and Proxying Requests [... unchanged from 5.3.3 in current draft ...] 5.2 Diameter Answer Processing When an request is locally processed, the following procedures MUST be applied to create the associated answer, in addition to any additional procedures that MAY be discussed in the Diameter application defining the command: - The same Hop-by-Hop identifier in the request is used in the answer. - The local host's identity is encoded in the Origin-Host AVP. - The value of the Origin-Host AVP in the request is included in the answer's Destination-Host AVP. - There MUST NOT be any Destination-Realm AVP present in the answer. - The Result-Code AVP is added with its value indicating success or failure. - If the Session-Id is present in the request, it MUST be included in the answer. - Any Route-Record or Proxy-Info AVPs in the request MUST be added to the answer message, in the same order they were present in the request. 5.2.1 Processing received Answers A diameter client or proxy MUST match the Hop-by-Hop Identifier in an answer received against the list of pending requests. The corresponding message should be removed from the list of pending requests. It SHOULD ignore answers received that do not match a known Hop-by-Hop Identifier. 5.2.2 Relaying and Proxying Answers A relay or proxy agent MUST only process Answers whose last Route- Record AVP matches one of its identities. Any answers that do not conform to this rule MUST be dropped. The last Route-Record AVP MUST be removed from the message before it is forwarded to the next hop, which is identified by the second to last Route-Record AVP. If the host in the Destination-Host AVP is in the peer table and there are no Route-Record AVPs in the message, the message MUST be forwarded to the peer. If the last Proxy-Info AVP in the message is targeted to the local Diameter server, the AVP MUST be removed. If a relay or proxy agent receives an answer with a Result-Code AVP indicating a failure, it MUST NOT modify the contents of the AVP. Any additional local errors detected SHOULD be logged, but not reflected in the Result-Code AVP. If the agent receives an answer message with a Result-Code AVP indicating success, and it wishes to modify the AVP to indicate an error, it MUST issue an STR on behalf of the access device. Prior to forwarding the answer, the agent MUST restore the original value of the Diameter header's Hop-by-Hop Identifier field. 5.3 Hiding Network Topology A Relay or Proxy agent routing messages outside of their administrative domain MAY need to hide the internal Diameter topology. This is done by removing all Route-Record AVPs in a request, and later adding them back into the corresponding answer, in the same order. Such agents MUST take care to not assume that the absence of any Route-Record AVPs implies the message is for local comsumption. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Mon Jun 11 07:54:30 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07245 for ; Mon, 11 Jun 2001 07:54:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1A3299127A; Mon, 11 Jun 2001 07:54:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DE2389127B; Mon, 11 Jun 2001 07:54:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BFB1C9127A for ; Mon, 11 Jun 2001 07:54:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B226D5DDC7; Mon, 11 Jun 2001 07:55:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by segue.merit.edu (Postfix) with SMTP id 33FB75DDC3 for ; Mon, 11 Jun 2001 07:55:02 -0400 (EDT) Received: from jc-mac.planete.net (HELO jc.yahoo.com) (194.2.222.120) by smtp.mail.vip.sc5.yahoo.com with SMTP; 11 Jun 2001 11:54:36 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010611114639.00c9ec50@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Jun 2001 13:50:00 +0200 To: aaa-wg@merit.edu From: Jacques Caron Subject: [AAA-WG]: [Issue] Do not use Route-Record for answer routing Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Jacques Caron Submitter email address: jacques_m_caron@yahoo.com Date first submitted: 11-Jun-2001 Reference: Document: Base Comment type: T Priority: 2 Section: 5.x Rationale/Explanation of issue: Currently, relays/proxies are supposed to use a combination of Route-Record and Destination-Host to route answers back to the client. On the other hand, they need to save pending requests, including the local Hop-by-Hop identifier they assigned, and the original Hop-by-Hop identifier. I propose to add the host the request was received from to the state information. Then we can remove Route-Record AVPs from answers, and use saved state information for answer routing. Route-Record AVPs would be used only in requests to perform loop checking. Note that both the original Hop-by-Hop Identifier and the host the request was received from could be saved in a Proxy-State AVP, but since the whole request needs to be saved in the pending request list, I'm not really sure the Proxy-State AVP is useful at all? Destination-Host would not be needed in answers either. Requested changes: [as this touches the same sections as the issue "Request & answer routing clarification" I just sent, this is based on the changes I sent, not the current draft] In 5.1.9 Relaying and Proxying requests, add: The host the request was received from is also saved. after the "The Hop-by-Hop identifier in the request is saved...". In Figure 6, remove the Destination-Host and Route-Record AVPs on the bottom. In 5.2 Diameter Answer Processing, replace: - The value of the Origin-Host AVP in the request is included in the answer's Destination-Host AVP. - There MUST NOT be any Destination-Realm AVP present in the answer. with: - There MUST NOT be any Destination-Realm or Destination-Host AVPs present in the answer. and replace: - Any Route-Record or Proxy-Info AVPs in the request MUST be added to the answer message, in the same order they were present in the request. with: - Any Proxy-Info AVPs in the request MUST be added to the answer message, in the same order they were present in the request. Replace: 5.2.2 Relaying and Proxying Answers A relay or proxy agent MUST only process Answers whose last Route- Record AVP matches one of its identities. Any answers that do not conform to this rule MUST be dropped. The last Route-Record AVP MUST be removed from the message before it is forwarded to the next hop, which is identified by the second to last Route-Record AVP. If the host in the Destination-Host AVP is in the peer table and there are no Route-Record AVPs in the message, the message MUST be forwarded to the peer. If the last Proxy-Info AVP in the message is targeted to the local Diameter server, the AVP MUST be removed. If a relay or proxy agent receives an answer with a Result-Code AVP indicating a failure, it MUST NOT modify the contents of the AVP. Any additional local errors detected SHOULD be logged, but not reflected in the Result-Code AVP. If the agent receives an answer message with a Result-Code AVP indicating success, and it wishes to modify the AVP to indicate an error, it MUST issue an STR on behalf of the access device. Prior to forwarding the answer, the agent MUST restore the original value of the Diameter header's Hop-by-Hop Identifier field. With: 5.2.2 Relaying and Proxying Answers If the answer is for a request which was proxied or relayed, the agent MUST restore the original value of the Diameter header's Hop-by-Hop Identifier field. If the last Proxy-Info AVP in the message is targeted to the local Diameter server, the AVP MUST be removed before the answer is forwarded. The agent MUST then send the answer to the host which it received the original request from. If a relay or proxy agent receives an answer with a Result-Code AVP indicating a failure, it MUST NOT modify the contents of the AVP. Any additional local errors detected SHOULD be logged, but not reflected in the Result-Code AVP. If the agent receives an answer message with a Result-Code AVP indicating success, and it wishes to modify the AVP to indicate an error, it MUST issue an STR on behalf of the access device. Replace: 5.3 Hiding Network Topology A Relay or Proxy agent routing messages outside of their administrative domain MAY need to hide the internal Diameter topology. This is done by removing all Route-Record AVPs in a request, and later adding them back into the corresponding answer, in the same order. Such agents MUST take care to not assume that the absence of any Route-Record AVPs implies the message is for local comsumption. With: 5.3 Hiding Network Topology A Relay or Proxy agent routing messages outside of their administrative domain MAY need to hide the internal Diameter topology. This is done by removing all Route-Record AVPs in a request. In 5.6 Destination-Host AVP, replace: The Destination-Host AVP (AVP Code 293) is of type OctetString, encoded in the UTF-8 [24] format, according to the Diameter identity rules defined in section 2.7. This AVP MUST be present in all unsolicited agent initiated messages, MAY be present in request messages, and MUST be present in Answer messages. The value of the Destination-Host AVP is set to the value of the Origin-Host AVP found in a message from the intended target host. with: The Destination-Host AVP (AVP Code 293) is of type OctetString, encoded in the UTF-8 [24] format, according to the Diameter identity rules defined in section 2.7. This AVP MUST be present in all unsolicited agent initiated messages, MAY be present in request messages, and MUST NOT be present in Answer messages. Other changes may be required in 14.1 and 14.2 to reflect this. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Mon Jun 11 07:54:47 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07261 for ; Mon, 11 Jun 2001 07:54:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 52F5A9127C; Mon, 11 Jun 2001 07:54:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 24CCD9127B; Mon, 11 Jun 2001 07:54:35 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1F49B9127C for ; Mon, 11 Jun 2001 07:54:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 168F95DDC7; Mon, 11 Jun 2001 07:55:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by segue.merit.edu (Postfix) with SMTP id 922C45DDC3 for ; Mon, 11 Jun 2001 07:55:04 -0400 (EDT) Received: from jc-mac.planete.net (HELO jc.yahoo.com) (194.2.222.120) by smtp.mail.vip.sc5.yahoo.com with SMTP; 11 Jun 2001 11:54:39 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010611135049.00c4dd20@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Jun 2001 13:52:47 +0200 To: aaa-wg@merit.edu From: Jacques Caron Subject: Re: [AAA-WG]: [Issue] Request & answer routing clarification In-Reply-To: <4.3.2.7.2.20010611101130.00bfd900@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk I forgot to mention in the changes that I also modified the peer table description to use Host descriptors rather than host name, port, and protocol independently. At 13:10 11/06/01, Jacques Caron wrote: >Submitter name: Jacques Caron >Submitter email address: jacques_m_caron@yahoo.com >Date first submitted: 11-Jun-2001 >Reference: >Document: Base >Comment type: E >Priority: 2 >Section: throughout 5.x >Rationale/Explanation of issue: [...] >5.1.5 Peer Table > > The Diameter Peer Table is used in message forwarding, and referenced > by the Domain Routing Table. A Peer Table entry contains the > following fields: > - Host descriptor, as defined in section 2.7. This MAY be resolved > locally, or known via the CER or CEA message. > - TLS Enabled. Specifies whether TLS is to be used when > communicating with the peer. > - Security informations (keys, certificates...) as appropriate. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Mon Jun 11 08:09:02 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07644 for ; Mon, 11 Jun 2001 08:09:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A34C39127B; Mon, 11 Jun 2001 08:08:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 710979127D; Mon, 11 Jun 2001 08:08:56 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 423299127B for ; Mon, 11 Jun 2001 08:08:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 288745DDC3; Mon, 11 Jun 2001 08:09:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by segue.merit.edu (Postfix) with SMTP id A20F25DDBC for ; Mon, 11 Jun 2001 08:09:27 -0400 (EDT) Received: from jc-mac.planete.net (HELO jc.yahoo.com) (194.2.222.120) by smtp.mail.vip.sc5.yahoo.com with SMTP; 11 Jun 2001 12:09:02 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010611135318.00c93d00@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Jun 2001 14:08:39 +0200 To: aaa-wg@merit.edu From: Jacques Caron Subject: [AAA-WG]: [Issue] Unsolicited server-to-client requests Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Jacques Caron Submitter email address: jacques_m_caron@yahoo.com Date first submitted: 11-Jun-2001 Reference: Document: Base Comment type: T Priority: 2 Section: 5.x Rationale/Explanation of issue: The draft is unclear about how unsolicited server-to-client requests are routed. It says Destination-Host should be used, but does not say anything about Destination-Realm. I see the following options: 1. Use the Origin-Realm received in previous requests as the Destination-Realm. However, it raises the issue of asymmetrical routing, and thus proxies not being able to track session state accurately 2. Do some kind of source-based routing (saving the Route-Records from a previous request and using that to route the unsolicited request to the client). Is a problem with network topology hiding proxies. Those might be forced to be stateful and save route-records on a per-session basis. 3. Have the client send a certificate in the original request, so that servers can then send unsolicited requests directly. It should then be compulsory for the client to send requests towards the server to update session state in the proxies if the server requests modifies state in any way. Raises the issue of proxies that might want to "authorize" server-to-client requests first, though. Comments, suggestions? Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Mon Jun 11 08:27:45 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08116 for ; Mon, 11 Jun 2001 08:27:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9364B9127D; Mon, 11 Jun 2001 08:27:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F19A9127E; Mon, 11 Jun 2001 08:27:39 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 368A19127D for ; Mon, 11 Jun 2001 08:27:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3419C5DDCC; Mon, 11 Jun 2001 08:28:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp014.mail.yahoo.com (smtp014.mail.yahoo.com [216.136.173.58]) by segue.merit.edu (Postfix) with SMTP id A9E6D5DDC7 for ; Mon, 11 Jun 2001 08:28:10 -0400 (EDT) Received: from jc-mac.planete.net (HELO jc.yahoo.com) (194.2.222.120) by smtp.mail.vip.sc5.yahoo.com with SMTP; 11 Jun 2001 12:27:45 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010611142149.00c9d640@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Jun 2001 14:27:27 +0200 To: Pat Calhoun From: Jacques Caron Subject: RE: [AAA-WG]: Support for multi-process Cc: aaa-wg@merit.edu In-Reply-To: References: <"Your message with ID" <35DBB8B7AC89D4118E98009027B1009B0ECF1B@IL27EXM10.cig.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, Coming a bit late into that discussion, but I just had a quick comment... If we need to make sure we have only one TCP connection between two hosts, why not use the same port as source as the one we're listening on? Since TCP connections must be unique based on (souce addr, source port, dest addr, dest port), and only on that, it should make the problem trivial? Still don't know whether we should have one single connection (better for congestion avoidance) or multiple ones (to avoid head of line blocking). Maybe this should be left as a configuration switch (as depending on the particular circumstances, one or the other might be better), the consequence of which could simply be to use the assigned port as source port or keep the random one. Just my EUR 0.02. Jacques. At 19:43 05/06/01, Pat Calhoun wrote: >Having said that, for those of you have have seen my comments to the transport >draft, that spec implies that a AAA protocol MUST allow multiple connections >between peers for non SCTP transports in order to minimize head of line >blocking. > >Now that's is completely against what we've been doing in the base protocol >spec, so what do folks think we should do? Single or multiple connections? > >PatC _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Mon Jun 11 09:43:00 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10437 for ; Mon, 11 Jun 2001 09:42:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6299B9126D; Mon, 11 Jun 2001 09:42:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3875A9126E; Mon, 11 Jun 2001 09:42:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 243309126D for ; Mon, 11 Jun 2001 09:42:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 44D5B5DDD6; Mon, 11 Jun 2001 09:43:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id B5ABD5DDCC for ; Mon, 11 Jun 2001 09:43:23 -0400 (EDT) Received: (qmail 6119 invoked by uid 500); 11 Jun 2001 13:32:31 -0000 Date: Mon, 11 Jun 2001 06:32:31 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Support for multi-process Message-ID: <20010611063231.L17928@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <"Your <35DBB8B7AC89D4118E98009027B1009B0ECF1B@IL27EXM10.cig.mot.com> <4.3.2.7.2.20010611142149.00c9d640@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010611142149.00c9d640@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Mon, Jun 11, 2001 at 02:27:27PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Jun 11, 2001 at 02:27:27PM +0200, Jacques Caron wrote: > Hi, > > Coming a bit late into that discussion, but I just had a quick comment... > > If we need to make sure we have only one TCP connection between two hosts, > why not use the same port as source as the one we're listening on? Since > TCP connections must be unique based on (souce addr, source port, dest > addr, dest port), and only on that, it should make the problem trivial? Because that would not allow multiple processes on a box, since the second Diameter process wouldn't be able to bind to the necessary port. PatC From owner-aaa-wg@merit.edu Mon Jun 11 09:49:55 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10648 for ; Mon, 11 Jun 2001 09:49:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 76DE591282; Mon, 11 Jun 2001 09:47:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1E83291284; Mon, 11 Jun 2001 09:47:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5D2E391282 for ; Mon, 11 Jun 2001 09:47:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7D2415DDD7; Mon, 11 Jun 2001 09:47:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans-old.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id A2F965DDD6 for ; Mon, 11 Jun 2001 09:47:40 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA13994; Mon, 11 Jun 2001 09:44:02 -0400 (EDT) Date: Mon, 11 Jun 2001 09:44:28 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Support for multi-process In-Reply-To: <4.3.2.7.2.20010611142149.00c9d640@pop.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Jacques, On Mon, 11 Jun 2001, Jacques Caron wrote: > Hi, > > Coming a bit late into that discussion, but I just had a quick comment... > > If we need to make sure we have only one TCP connection between two hosts, > why not use the same port as source as the one we're listening on? Since > TCP connections must be unique based on (souce addr, source port, dest > addr, dest port), and only on that, it should make the problem trivial? The problem is that you can't accept and connect using the same source port. We also want to be able to support two Diameter servers on the same host. > > Still don't know whether we should have one single connection (better for > congestion avoidance) or multiple ones (to avoid head of line blocking). > Maybe this should be left as a configuration switch (as depending on the > particular circumstances, one or the other might be better), the > consequence of which could simply be to use the assigned port as source > port or keep the random one. > I hear a lot of talk of head of line blocking. Exactly what does that mean? I can think of two instances that don't require multiple connections to fix it. Is there something that would? 1. One packet takes 10 times as long as another packet to broadcast, thus backing up all the other packets? - Either use SCTP, or speed up the physical layer. 2. The server takes a long time to process incoming packets. - If this is as fast as the server goes, multiple connections won't help. - If the server takes a long time to process one type of packet, add extra threads to process the other packets. -mark > Just my EUR 0.02. > > Jacques. > > At 19:43 05/06/01, Pat Calhoun wrote: > >Having said that, for those of you have have seen my comments to the transport > >draft, that spec implies that a AAA protocol MUST allow multiple connections > >between peers for non SCTP transports in order to minimize head of line > >blocking. > > > >Now that's is completely against what we've been doing in the base protocol > >spec, so what do folks think we should do? Single or multiple connections? > > > >PatC > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > From owner-aaa-wg@merit.edu Mon Jun 11 10:14:13 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11175 for ; Mon, 11 Jun 2001 10:14:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AD45491281; Mon, 11 Jun 2001 10:14:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 82FC091283; Mon, 11 Jun 2001 10:14:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 60A0D91281 for ; Mon, 11 Jun 2001 10:14:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7837D5DDD8; Mon, 11 Jun 2001 10:14:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 3119E5DDD6 for ; Mon, 11 Jun 2001 10:14:40 -0400 (EDT) Received: (qmail 7172 invoked by uid 500); 11 Jun 2001 14:03:47 -0000 Date: Mon, 11 Jun 2001 07:03:47 -0700 From: Pat Calhoun To: Mark Eklund Cc: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Support for multi-process Message-ID: <20010611070347.R17928@charizard.diameter.org> Mail-Followup-To: Mark Eklund , Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <4.3.2.7.2.20010611142149.00c9d640@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from meklund@cisco.com on Mon, Jun 11, 2001 at 09:44:28AM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Jun 11, 2001 at 09:44:28AM -0400, Mark Eklund wrote: > I hear a lot of talk of head of line blocking. Exactly what > does that mean? I can think of two instances that don't require > multiple connections to fix it. Is there something that would? > > 1. One packet takes 10 times as long as another packet to > broadcast, thus backing up all the other packets? > - Either use SCTP, or speed up the physical layer. > > 2. The server takes a long time to process incoming packets. > - If this is as fast as the server goes, multiple connections > won't help. > - If the server takes a long time to process one type of > packet, add extra threads to process the other packets. I think the basic idea was to simulate SCTP streams by opening up multiple TCP connections. In any case, we've already agreed that this will not be done in Diameter. PatC From owner-aaa-wg@merit.edu Mon Jun 11 10:38:24 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11865 for ; Mon, 11 Jun 2001 10:38:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 024F891283; Mon, 11 Jun 2001 10:38:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C812291284; Mon, 11 Jun 2001 10:38:27 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9DA7791283 for ; Mon, 11 Jun 2001 10:38:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D148F5DDDA; Mon, 11 Jun 2001 10:38:59 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59]) by segue.merit.edu (Postfix) with SMTP id 56EC05DDD9 for ; Mon, 11 Jun 2001 10:38:59 -0400 (EDT) Received: from pc25.paris-dc.fr.psi.com (HELO jc.yahoo.com) (212.81.116.25) by smtp.mail.vip.sc5.yahoo.com with SMTP; 11 Jun 2001 14:38:34 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010611163129.00b95ed0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Jun 2001 16:37:28 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Support for multi-process Cc: Pat Calhoun , aaa-wg@merit.edu In-Reply-To: <20010611063231.L17928@charizard.diameter.org> References: <4.3.2.7.2.20010611142149.00c9d640@pop.mail.yahoo.com> <"Your <35DBB8B7AC89D4118E98009027B1009B0ECF1B@IL27EXM10.cig.mot.com> <4.3.2.7.2.20010611142149.00c9d640@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 15:32 11/06/01, Pat Calhoun wrote: >On Mon, Jun 11, 2001 at 02:27:27PM +0200, Jacques Caron wrote: > > Hi, > > > > Coming a bit late into that discussion, but I just had a quick comment... > > > > If we need to make sure we have only one TCP connection between two hosts, > > why not use the same port as source as the one we're listening on? Since > > TCP connections must be unique based on (souce addr, source port, dest > > addr, dest port), and only on that, it should make the problem trivial? > >Because that would not allow multiple processes on a box, since the second >Diameter process wouldn't be able to bind to the necessary port. Well, to have multiple processes on a box, you surely need to use different ports (and/or IP addresses), and then you can have as many processes as you want? Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Mon Jun 11 11:17:54 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12577 for ; Mon, 11 Jun 2001 11:17:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7165991285; Mon, 11 Jun 2001 11:17:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 40FC791286; Mon, 11 Jun 2001 11:17:55 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 26D0091285 for ; Mon, 11 Jun 2001 11:17:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5B5765DDD1; Mon, 11 Jun 2001 11:18:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id BAB385DDC7 for ; Mon, 11 Jun 2001 11:18:26 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id IAA01406; Mon, 11 Jun 2001 08:08:34 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Mon, 11 Jun 2001 08:08:34 -0700 (PDT) From: Bernard Aboba To: Pat Calhoun Cc: Mark Eklund , Jacques Caron , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Support for multi-process In-Reply-To: <20010611070347.R17928@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > On Mon, Jun 11, 2001 at 09:44:28AM -0400, Mark Eklund wrote: > > I hear a lot of talk of head of line blocking. Exactly what > > does that mean? I can think of two instances that don't require > > multiple connections to fix it. Is there something that would? > > > > 1. One packet takes 10 times as long as another packet to > > broadcast, thus backing up all the other packets? > > - Either use SCTP, or speed up the physical layer. > > > > 2. The server takes a long time to process incoming packets. > > - If this is as fast as the server goes, multiple connections > > won't help. > > - If the server takes a long time to process one type of > > packet, add extra threads to process the other packets. > It should be kept in mind that head of line blocking will only occur when the time between requests is less than RTO, and where timeouts are present. Thus, the problem will only manifest on large NASes where mechanisms such as fast re-transmit, SACK, or limited-transmit cannot avoid a timeout. For a NAS communicating with a server through an agent, a slow server will not create a head of line blocking problem. This is because the agent will ACK at the transport layer, and will also respond to Watchdog messages. The server application response will not be returned in a timely way, but this will not result in failover or inability of the NAS to send additional requests. From owner-aaa-wg@merit.edu Mon Jun 11 11:52:20 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13179 for ; Mon, 11 Jun 2001 11:52:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0C88491286; Mon, 11 Jun 2001 11:52:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CA33C91287; Mon, 11 Jun 2001 11:52:15 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A1C9F91286 for ; Mon, 11 Jun 2001 11:52:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DED805DDDE; Mon, 11 Jun 2001 11:52:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by segue.merit.edu (Postfix) with SMTP id 604D95DDD5 for ; Mon, 11 Jun 2001 11:52:47 -0400 (EDT) Received: from pc25.paris-dc.fr.psi.com (HELO jc.yahoo.com) (212.81.116.25) by smtp.mail.vip.sc5.yahoo.com with SMTP; 11 Jun 2001 15:52:21 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010611173820.00c948e0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Jun 2001 17:51:04 +0200 To: aaa-wg@merit.edu From: Jacques Caron Subject: [AAA-WG]: [Issue] Destination-Realm & proxies/relays Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Jacques Caron Submitter email address: jacques_m_caron@yahoo.com Date first submitted: 11-Jun-2001 Reference: Document: Base Comment type: T Priority: 1 Section: 5.x Rationale/Explanation of issue: Destination-Realm is used to route messages towards the home server. In a "normal" situation (i.e. authentication of a user with a NAI-formatted User-Name), the realm is extracted from the User-Name by the NAS. However, in some cases (e.g. authorization based on called/calling number), a proxy might create the Destination-Realm AVP itself. This is incompatible with the fact that a message without a Destination-Realm should not be proxied. Possible options: 1. Create a flag in the message header to specify that a message is not proxiable. 2. Create different classes for "protocol" messages (all not proxiable?) and for "application" messages. 3. Define a dummy realm to be included in messages where the "real" realm is to be inserted later on? It is also necessary to clarify the wording regarding where the Destination-Realm is created and how. Requested changes: pending discussion and selection of one of the above options. Comments/suggestions welcome. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Mon Jun 11 12:26:10 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14028 for ; Mon, 11 Jun 2001 12:26:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3B4C991287; Mon, 11 Jun 2001 12:26:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 06E3A91288; Mon, 11 Jun 2001 12:26:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 091D291287 for ; Mon, 11 Jun 2001 12:26:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 525B95DDDC; Mon, 11 Jun 2001 12:26:37 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id CCB0D5DDD6 for ; Mon, 11 Jun 2001 12:26:36 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27621; Mon, 11 Jun 2001 10:24:58 -0600 (MDT) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28496; Mon, 11 Jun 2001 09:24:58 -0700 (PDT) Received: from jafo (jafo [152.70.40.123]) by nasnfs.Eng.Sun.COM (8.10.2+Sun/8.10.2) with SMTP id f5BGOsw11622; Mon, 11 Jun 2001 09:24:54 -0700 (PDT) Date: Mon, 11 Jun 2001 09:27:03 -0700 (PDT) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: Support for multi-process To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <4.3.2.7.2.20010611163129.00b95ed0@pop.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > At 15:32 11/06/01, Pat Calhoun wrote: > >On Mon, Jun 11, 2001 at 02:27:27PM +0200, Jacques Caron wrote: > > > Hi, > > > > > > Coming a bit late into that discussion, but I just had a quick comment... > > > > > > If we need to make sure we have only one TCP connection between two hosts, > > > why not use the same port as source as the one we're listening on? Since > > > TCP connections must be unique based on (souce addr, source port, dest > > > addr, dest port), and only on that, it should make the problem trivial? > > > >Because that would not allow multiple processes on a box, since the second > >Diameter process wouldn't be able to bind to the necessary port. > > Well, to have multiple processes on a box, you surely need to use different > ports (and/or IP addresses), and then you can have as many processes as you > want? Ah, then you are suggesting that both sides know that multiple processes are used, and be configured for each process by a common port number. This seems like alot of configuration to me :( PatC From owner-aaa-wg@merit.edu Mon Jun 11 12:51:19 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14580 for ; Mon, 11 Jun 2001 12:51:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B322F9128D; Mon, 11 Jun 2001 12:50:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7CC1F9128E; Mon, 11 Jun 2001 12:50:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 56F829128D for ; Mon, 11 Jun 2001 12:50:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 285CE5DDD5; Mon, 11 Jun 2001 12:51:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by segue.merit.edu (Postfix) with SMTP id D15F45DDBC for ; Mon, 11 Jun 2001 12:51:29 -0400 (EDT) Received: from pc25.paris-dc.fr.psi.com (HELO jc.yahoo.com) (212.81.116.25) by smtp.mail.vip.sc5.yahoo.com with SMTP; 11 Jun 2001 16:51:04 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010611183231.00bd18d0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Jun 2001 18:50:44 +0200 To: Patrice Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Support for multi-process Cc: Pat Calhoun , aaa-wg@merit.edu In-Reply-To: References: <"Your message with ID" <4.3.2.7.2.20010611163129.00b95ed0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 18:27 11/06/01, Patrice Calhoun wrote: > > At 15:32 11/06/01, Pat Calhoun wrote: > > >On Mon, Jun 11, 2001 at 02:27:27PM +0200, Jacques Caron wrote: > > > > Hi, > > > > > > > > Coming a bit late into that discussion, but I just had a quick > comment... > > > > > > > > If we need to make sure we have only one TCP connection between two > hosts, > > > > why not use the same port as source as the one we're listening on? > Since > > > > TCP connections must be unique based on (souce addr, source port, dest > > > > addr, dest port), and only on that, it should make the problem trivial? > > > > > >Because that would not allow multiple processes on a box, since the second > > >Diameter process wouldn't be able to bind to the necessary port. > > > > Well, to have multiple processes on a box, you surely need to use > different > > ports (and/or IP addresses), and then you can have as many processes as > you > > want? > >Ah, then you are suggesting that both sides know that multiple processes are >used, and be configured for each process by a common port number. This seems >like alot of configuration to me :( Errrr? Whatever happens, if you have multiple processes on the same box, they will have different port numbers, and their peers need to know that (that's part of the Host descricptor thing)... The only thing I say is: "if you want to make sure only one connection is established, use the port number you're listening on as your source port also". Indeed, that would need to be done on the processes on both sides of the connection that is wished to be unique, but that is totally independent from the fact that one or multiple processes are running on any given box. I just ran a very small test, which shows this: 1. I have a process listening for requests on port 1812 on the local box: unix14: {121} netstat -anf inet | grep 1812 tcp 0 0 *.1812 *.* LISTEN 2. I also have a process listening for requests on port 1812 on some remote box. 3. I then connect from the local box (using source port 1812) to the remote box (on port 1812 of course): unix14: {123} netstat -anf inet | grep 1812 tcp 0 0 194.2.222.14.1812 194.150.27.98.1812 ESTABLISHED tcp 0 0 *.1812 *.* LISTEN 4. If I try to connect from the remote box (port 1812) to the local box (port 1812), it fails (Address already in use). Of course, none of this is relevant if we actually want multiple connections, but I have to admit I'm completely lost on the final result of that part of the discussion... Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Mon Jun 11 12:55:28 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14666 for ; Mon, 11 Jun 2001 12:55:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 940069128F; Mon, 11 Jun 2001 12:55:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6BBE891290; Mon, 11 Jun 2001 12:55:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5BAF19128F for ; Mon, 11 Jun 2001 12:55:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BE5845DDD6; Mon, 11 Jun 2001 12:55:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 6A7805DDD5 for ; Mon, 11 Jun 2001 12:55:54 -0400 (EDT) Received: (qmail 10176 invoked by uid 500); 11 Jun 2001 16:45:01 -0000 Date: Mon, 11 Jun 2001 09:45:01 -0700 From: Pat Calhoun To: Jacques Caron Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Various editorial changes Message-ID: <20010611094501.T17928@charizard.diameter.org> Mail-Followup-To: Jacques Caron , aaa-wg@merit.edu References: <4.3.2.7.2.20010606233818.00c1fba0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010606233818.00c1fba0@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Mon, Jun 11, 2001 at 12:54:33AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk First, thanks for taking the time to read the base protocol in the level of detail that is necessary to catch these bugs. Please see my comments below. > OctetString > The data contains arbitrary data of variable length. Unless > otherwise noted, the AVP Length field MUST be set to at least 8 > (12 if the 'V' bit is enabled). Data used to transmit (human > readable) character string data uses the UTF-8 [24] character > set and is NOT NULL-terminated. The minimum Length field MUST > be 9, but can be set to any value up to 2^24-20=16777196 bytes. > AVP Values of this type that do not align on a 32-bit boundary > MUST have the necessary padding. Actually a previous fix for the subtypes eliminated the maximum length in the OctetString (not sure why). So we still want to state the obvious? > With: > When two Diameter peers establish a transport connection, they MUST > exchange the Capabilities Exchange messages, as specified in the peer > state machine (see section 8.0). This message allows the discovery of > both the peer's identity, and its capabilities, such as the supported > protocol version number, the locally supported Diameter applications, > etc. I've come up with the following (which I think reads a little better): "When two Diameter peers establish a transport connection, they MUST exchange the Capabilities Exchange messages, as specified in the peer state machine (see section 8.0). This message allows the discovery of a peer's identity and its capabilities (protocol version number, supported Diameter applications, etc.)" Thanks again, PatC From owner-aaa-wg@merit.edu Mon Jun 11 13:07:27 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14947 for ; Mon, 11 Jun 2001 13:07:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EDB7491290; Mon, 11 Jun 2001 13:07:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B945C91291; Mon, 11 Jun 2001 13:07:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A327591290 for ; Mon, 11 Jun 2001 13:07:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 13BDC5DDBC; Mon, 11 Jun 2001 13:07:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 36A325DD9E for ; Mon, 11 Jun 2001 13:07:52 -0400 (EDT) Received: (qmail 10267 invoked by uid 500); 11 Jun 2001 16:56:59 -0000 Date: Mon, 11 Jun 2001 09:56:59 -0700 From: Pat Calhoun To: Jacques Caron Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Downstream/upstream confusion Message-ID: <20010611095659.X17928@charizard.diameter.org> Mail-Followup-To: Jacques Caron , aaa-wg@merit.edu References: <4.3.2.7.2.20010611005402.00cc4620@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010611005402.00cc4620@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Mon, Jun 11, 2001 at 01:11:01AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk All, The current base protocol spec states that upstream is towards the home server, and downstream is towards the client. Do people see a need to invert the two, as Jacques suggests? PatC On Mon, Jun 11, 2001 at 01:11:01AM +0200, Jacques Caron wrote: > Submitter name: Jacques Caron > Submitter email address: jacques_m_caron@yahoo.com > Date first submitted: 11-Jun-2001 > Reference: > Document: Base > Comment type: E > Priority: 1 > Section: throughout > Rationale/Explanation of issue: > > The terms "upstream" and "downstream" are not used consistently. Even the > definitions seem contrary to logic: things usually flow from upstream to > downstream, so upstream should be towards the client, and downstream > towards the home server. > > Requested changes: > > In 1.3 Terminology, replace: > Downstream Server > Diameter Proxy servers identify a downstream server as one that is > providing routing services towards the Diameter client. > > with: > Downstream Server > Diameter Proxy servers identify a downstream server as one that is > providing routing services towards the home server for a > particular message. > > and replace: > Upstream Server > Diameter Proxy servers identify an upstream server as one that is > providing routing services towards the home server for a > particular message. > > with: > Upstream Server > Diameter Proxy servers identify an upstream server as one that is > providing routing services towards the Diameter client. > > In 2.5.2 Proxy Agents, replace: > Similarly to Relays, Proxy agents route Diameter messages using the > Diameter Routing Table. However, they differ since they modify > messages to implement policy enforcement. This requires that proxies > maintain the state of their downstream peers (e.g. access devices) to > enforce resource usage, provide admission control, and provisioning. > > with: > Similarly to Relays, Proxy agents route Diameter messages using the > Diameter Routing Table. However, they differ since they modify > messages to implement policy enforcement. This requires that proxies > maintain the state of their upstream peers (e.g. access devices) to > enforce resource usage, provide admission control, and provisioning. > > In 6.0 Capabilities Exchange, replace: > Since the CER/CEA messages cannot be proxied, it is still possible > that an upstream proxy receives a message for which it has no > available peers to handle the application that corresponds to the > Command-Code. In such instances, the Message-Reject-Answer message is > used (see Section 9.2.1) to inform the downstream to take action > (e.g. re-routing request to an alternate peer). > > With: > Since the CER/CEA messages cannot be proxied, it is still possible > that a downstream proxy receives a message for which it has no > available peers to handle the application that corresponds to the > Command-Code. In such instances, the Message-Reject-Answer message is > used (see Section 9.2.1) to inform the upstream to take action > (e.g. re-routing request to an alternate peer). > > In 9.0, Error Handling, replace: > Figure 4 provides an example of a message forwarded upstream by a > Diameter relay. When the message is received by Relay 2, and it > detects that it cannot forward the request to the home server, an MRA > message is returned with the Result-Code AVP set to > DIAMETER_UNABLE_TO_DELIVER. Given that this error falls within the > protocol error category, Relay 1 would take special action, and given > the error, attempt to route the message through its alternate Relay > 3. > > with: > Figure 4 provides an example of a message forwarded downstream by a > Diameter relay. When the message is received by Relay 2, and it > detects that it cannot forward the request to the home server, an MRA > message is returned with the Result-Code AVP set to > DIAMETER_UNABLE_TO_DELIVER. Given that this error falls within the > protocol error category, Relay 1 would take special action, and given > the error, attempt to route the message through its alternate Relay > 3. > > Alternatively, leave the definitions as they are (though I don't understand > them?) and fix down/upstream in 6.2 and 10.10. From owner-aaa-wg@merit.edu Mon Jun 11 13:48:32 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15872 for ; Mon, 11 Jun 2001 13:48:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 80E5291292; Mon, 11 Jun 2001 13:48:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5493C91293; Mon, 11 Jun 2001 13:48:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3652E91292 for ; Mon, 11 Jun 2001 13:48:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A31285DDD0; Mon, 11 Jun 2001 13:49:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 1DCEC5DD9E for ; Mon, 11 Jun 2001 13:49:04 -0400 (EDT) Received: (qmail 11473 invoked by uid 500); 11 Jun 2001 17:38:10 -0000 Date: Mon, 11 Jun 2001 10:38:10 -0700 From: Pat Calhoun To: Jacques Caron Cc: Patrice Calhoun , Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Support for multi-process Message-ID: <20010611103810.E17928@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Patrice Calhoun , Pat Calhoun , aaa-wg@merit.edu References: <"Your <4.3.2.7.2.20010611163129.00b95ed0@pop.mail.yahoo.com> <4.3.2.7.2.20010611183231.00bd18d0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010611183231.00bd18d0@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Mon, Jun 11, 2001 at 06:50:44PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Jun 11, 2001 at 06:50:44PM +0200, Jacques Caron wrote: > >Ah, then you are suggesting that both sides know that multiple processes are > >used, and be configured for each process by a common port number. This seems > >like alot of configuration to me :( > > Errrr? Whatever happens, if you have multiple processes on the same box, > they will have different port numbers, and their peers need to know that > (that's part of the Host descricptor thing)... Sorry, it appears as if I lost your train of thought. Let me try again. > > The only thing I say is: "if you want to make sure only one connection is > established, use the port number you're listening on as your source port > also". Indeed, that would need to be done on the processes on both sides of > the connection that is wished to be unique, but that is totally independent > from the fact that one or multiple processes are running on any given box. > > I just ran a very small test, which shows this: > > 1. I have a process listening for requests on port 1812 on the local box: > unix14: {121} netstat -anf inet | grep 1812 > tcp 0 0 *.1812 *.* LISTEN > > 2. I also have a process listening for requests on port 1812 on some remote > box. > > 3. I then connect from the local box (using source port 1812) to the remote > box (on port 1812 of course): > > unix14: {123} netstat -anf inet | grep 1812 > tcp 0 0 194.2.222.14.1812 194.150.27.98.1812 ESTABLISHED > tcp 0 0 *.1812 *.* LISTEN > > 4. If I try to connect from the remote box (port 1812) to the local box > (port 1812), it fails (Address already in use). But what if the remote box was periodically trying to connect to the local box? That would always fail with 'Address already in use', since you'd already bound a file descriptor on port 1812 for listening. So we need to listen for connections, and initiate connections as well. We need to allow for multiple connections to multiple peers, all listening on the same port. PatC From owner-aaa-wg@merit.edu Mon Jun 11 15:22:29 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17320 for ; Mon, 11 Jun 2001 15:22:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 459749129C; Mon, 11 Jun 2001 15:22:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 112629129E; Mon, 11 Jun 2001 15:22:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E90C99129C for ; Mon, 11 Jun 2001 15:22:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 765E35DDD7; Mon, 11 Jun 2001 15:23:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id D6DB25DD9E for ; Mon, 11 Jun 2001 15:23:01 -0400 (EDT) Received: (qmail 14554 invoked by uid 500); 11 Jun 2001 19:12:08 -0000 Date: Mon, 11 Jun 2001 12:12:07 -0700 From: Pat Calhoun To: Fredrik Johansson Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Proposed for 26, 38 and 48 Message-ID: <20010611121207.J17928@charizard.diameter.org> Mail-Followup-To: Fredrik Johansson , Pat Calhoun , aaa-wg@merit.edu References: <20010607153203.D1100@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from fredrik.johansson@ipunplugged.com on Fri, Jun 08, 2001 at 10:10:25AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Fri, Jun 08, 2001 at 10:10:25AM +0200, Fredrik Johansson wrote: > Hi, > > The Session-Binding AVP and the Session-Server-Failover AVP both suggests > the same thing. The former suggest that if it has a non-zero value the > Destination-Host AVP should NOT be present and the latter says that if the > former has a non-zero value it should try without the Destination-Host AVP. [proposed text deleted] Fredrik, I accept your proposed text, with a minor grammatical change. It will appear in version -06 of the base protocol, and I believe that we can now close this issue. Thanks, PatC From owner-aaa-wg@merit.edu Mon Jun 11 16:12:04 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18077 for ; Mon, 11 Jun 2001 16:11:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5D456912A0; Mon, 11 Jun 2001 16:12:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2ADC7912A1; Mon, 11 Jun 2001 16:12:03 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 067F2912A0 for ; Mon, 11 Jun 2001 16:12:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A66C45DDD7; Mon, 11 Jun 2001 16:12:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrc2s03g.nortelnetworks.com (unknown [47.103.122.66]) by segue.merit.edu (Postfix) with ESMTP id 2D6705DDDB for ; Mon, 11 Jun 2001 16:12:35 -0400 (EDT) Received: from zsc4s001.baynetworks.com (zsc4s001.baynetworks.com [134.177.3.62]) by zrc2s03g.nortelnetworks.com (8.9.3+Sun/8.9.1) with ESMTP id PAA07968 for ; Mon, 11 Jun 2001 15:13:27 -0500 (CDT) Received: from zsc4c000.us.nortel.com by zsc4s001.baynetworks.com; Mon, 11 Jun 2001 13:04:44 -0700 Received: from zbl6c016.corpeast.baynetworks.com ([132.245.205.66]) by zsc4c000.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MXAQQFK9; Mon, 11 Jun 2001 13:11:47 -0700 Received: from mitton.nortelnetworks.com (mitton.us.nortel.com [47.16.86.121]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KBYWGMCY; Mon, 11 Jun 2001 16:11:44 -0400 Message-Id: <4.3.2.7.2.20010611154446.03bcb200@ZBL6C016.corpeast.baynetworks.com> X-Sender: dmitton@ZBL6C016.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Jun 2001 16:14:13 -0400 To: Pat Calhoun , Jacques Caron From: "David Mitton" Subject: Re: [AAA-WG]: Support for multi-process Cc: Patrice Calhoun , Pat Calhoun , aaa-wg@merit.edu In-Reply-To: <20010611103810.E17928@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Orig: Sender: owner-aaa-wg@merit.edu Precedence: bulk At 6/11/01 01:38 PM -0400, Pat Calhoun wrote: >On Mon, Jun 11, 2001 at 06:50:44PM +0200, Jacques Caron wrote: > > >Ah, then you are suggesting that both sides know that multiple > processes are > > >used, and be configured for each process by a common port number. This > seems > > >like alot of configuration to me :( > > > > Errrr? Whatever happens, if you have multiple processes on the same box, > > they will have different port numbers, and their peers need to know that > > (that's part of the Host descricptor thing)... yes, if you want this difficult situation, you will have to figure out how to configure it. > > > 4. If I try to connect from the remote box (port 1812) to the local box > > (port 1812), it fails (Address already in use). > >But what if the remote box was periodically trying to connect to the local >box? That would always fail with 'Address already in use', since you'd >already >bound a file descriptor on port 1812 for listening. > >So we need to listen for connections, and initiate connections as well. We >need >to allow for multiple connections to multiple peers, all listening on the >same port. No can do. Only one process can be listening on a given port number at a time. When the listening process accepts the connection (at least on Unix) a new socket is created, and typically it is given a new unique ephemeral port number. The original port number is not needed, as the connection has been made. The listening process can spawn subprocesses or threads to handle that connection socket, but it still holds the listening well-known socket. If you need to run different server "instances" on the same system, they have to listen to connections with distinct socket numbers, (that's how IP knows where to deliver your packets) or you partion your implementation internally. So far, I thought the URI would include the ability to configure a non-default target (listening) port number which would be critical to doing this. Dave. Dave. ------------------------------------------------------------ David Mitton ESN: 248-4570 Advisor, Nortel Networks 978-288-4570 Wireless Solutions, IP Mobility Billerica, MA 01821 dmitton@nortelnetworks.com From owner-aaa-wg@merit.edu Mon Jun 11 16:22:16 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18273 for ; Mon, 11 Jun 2001 16:22:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1E86F912A1; Mon, 11 Jun 2001 16:22:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B33FE912A4; Mon, 11 Jun 2001 16:22:07 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3A70F912A1 for ; Mon, 11 Jun 2001 16:22:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E338C5DDDA; Mon, 11 Jun 2001 16:22:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 4428F5DDD7 for ; Mon, 11 Jun 2001 16:22:36 -0400 (EDT) Received: (qmail 17651 invoked by uid 500); 11 Jun 2001 20:10:58 -0000 Date: Mon, 11 Jun 2001 13:10:58 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 66: Server Discovery Message-ID: <20010611131058.M17928@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, Following the discussion some of us had last week, I have made slight changes to the proposed text for this issue. Please note section 3.3 below, where a reference is made to the fqdn field of the diameterIdentity sub-type. I also added A6s. PatC 2.6 Diameter Agent Discovery Allowing for dynamic Diameter agent discovery will make it possible for simpler and more robust deployment of AAA services. In order to promote interoperable implementations of Diameter agent discovery, the following mechanisms are described. These are based on existing IETF standards. There are two cases where Diameter agent discovery may be performed. The first is when a Diameter client needs to discover a first-hop Diameter agent. The second case is when a Diameter agent needs to discover another agent - for further handling of a Diameter operation. In both cases, the following 'search order' is recommended: 1. The Diameter implementation consults its list of static (manual) configured Diameter agent locations. These will be used if they exist and respond. 2. The Diameter implementation uses SLPv2 [28] to discover Diameter services. The Diameter service template [32] is included in Appendix A. It is recommended that SLPv2 security be deployed (this requires distributing keys to SLPv2 agents.) This is discussed further in Appendix A. SLPv2 will allow Diameter implementations to discover the location of Diameter agents in the local site, as well as their characteristics. Diameter agents with specific capabilities (say support for the Mobile IP application) can be requested, and only those will be discovered. 3. The Diameter implementation uses DNS to request the SRV RR [33] for the '_diameter._sctp' and/or '_diameter._tcp' server in a particular domain. The Diameter implementation has to know in advance which domain to look for an Diameter agent in. This could be deduced, for example, from the 'realm' in a NAI that an Diameter implementation needed to perform an Diameter operation on. 3.1 If the destination address is a numeric IP address, the requestor contacts the peer at the given address and the port number specified in the SRV record or, if not specified, the default port (TBD). 3.2 The results of the query or queries are merged and ordered based on priority. Then, the searching technique outlined in [46] is used to select servers in order. The requestor attempts to contact each peer in the order listed, at the port number specified in the SRV record. If none of the servers can be contacted, the requestor gives up. If there are no SRV records, DNS address records are used, as described below. 3.3 If the destination specifies a port number other than TBD or if there are no SRV records, the requestor queries the DNS server for address records for the destination address using the FQDN field of the DiameterIdentity derived AVP data format (see section 4.4). Address records include A RR's, AAAA RR's, A6 RR's or other similar records, chosen according to the requestor's network protocol capabilities. If the DNS server returns no address records, the requestor gives up. If there are address records, the same rules as in step 3.2 apply. Requestors MUST NOT cache query results except according to the rules in [47]. Diameter allows AAA peers to protect the integrity and privacy of communication as well as to perform end-point authentication. Still, it is prudent to employ DNS Security as a precaution when using DNS SRV RRs to look up the location of a Diameter agent. [34, 35, 36] From owner-aaa-wg@merit.edu Mon Jun 11 16:23:45 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18318 for ; Mon, 11 Jun 2001 16:23:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3CF4D912A3; Mon, 11 Jun 2001 16:23:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0C93E912A4; Mon, 11 Jun 2001 16:23:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 850E7912A3 for ; Mon, 11 Jun 2001 16:23:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 365165DDD9; Mon, 11 Jun 2001 16:24:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by segue.merit.edu (Postfix) with SMTP id ADCB25DDD7 for ; Mon, 11 Jun 2001 16:24:16 -0400 (EDT) Received: from pc25.paris-dc.fr.psi.com (HELO jc.yahoo.com) (212.81.116.25) by smtp.mail.vip.sc5.yahoo.com with SMTP; 11 Jun 2001 20:23:50 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010611221318.00c2a210@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Jun 2001 22:15:13 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Support for multi-process Cc: Patrice Calhoun , Pat Calhoun , aaa-wg@merit.edu In-Reply-To: <20010611103810.E17928@charizard.diameter.org> References: <4.3.2.7.2.20010611183231.00bd18d0@pop.mail.yahoo.com> <"Your <4.3.2.7.2.20010611163129.00b95ed0@pop.mail.yahoo.com> <4.3.2.7.2.20010611183231.00bd18d0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 19:38 11/06/01, Pat Calhoun wrote: >But what if the remote box was periodically trying to connect to the local >box? That would always fail with 'Address already in use', since you'd already >bound a file descriptor on port 1812 for listening. Nope, it won't fail. It will fail only if there is already a connection between the two machines. >So we need to listen for connections, and initiate connections as well. We >need >to allow for multiple connections to multiple peers, all listening on the >same port. Not a problem. Remember that the uniqueness requirement is on the tuple (local addr, local port, remote addr, remote port), not on (local addr, local port). Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Mon Jun 11 16:24:11 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18352 for ; Mon, 11 Jun 2001 16:24:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3D10C912A4; Mon, 11 Jun 2001 16:24:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 06B60912A5; Mon, 11 Jun 2001 16:24:07 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6ACCF912A4 for ; Mon, 11 Jun 2001 16:24:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1DF8E5DDDA; Mon, 11 Jun 2001 16:24:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id B87F35DDD7 for ; Mon, 11 Jun 2001 16:24:39 -0400 (EDT) Received: (qmail 17711 invoked by uid 500); 11 Jun 2001 20:13:45 -0000 Date: Mon, 11 Jun 2001 13:13:45 -0700 From: Pat Calhoun To: David Mitton Cc: Pat Calhoun , Jacques Caron , Patrice Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Support for multi-process Message-ID: <20010611131345.N17928@charizard.diameter.org> Mail-Followup-To: David Mitton , Pat Calhoun , Jacques Caron , Patrice Calhoun , aaa-wg@merit.edu References: <20010611103810.E17928@charizard.diameter.org> <4.3.2.7.2.20010611154446.03bcb200@ZBL6C016.corpeast.baynetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010611154446.03bcb200@ZBL6C016.corpeast.baynetworks.com>; from dmitton@nortelnetworks.com on Mon, Jun 11, 2001 at 04:14:13PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Jun 11, 2001 at 04:14:13PM -0400, David Mitton wrote: > >So we need to listen for connections, and initiate connections as well. We > >need > >to allow for multiple connections to multiple peers, all listening on the > >same port. > > No can do. Of course, that's been my point all along. > > Only one process can be listening on a given port number at a time. When > the listening process accepts the connection (at least on Unix) a new > socket is created, and typically it is given a new unique ephemeral port > number. The original port number is not needed, as the connection has been > made. Right, and this is where I got confused with Jacques e-mail that seemed to state that this is what he wanted to do. > > The listening process can spawn subprocesses or threads to handle that > connection socket, but it still holds the listening well-known socket. > > If you need to run different server "instances" on the same system, they > have to listen to connections with distinct socket numbers, (that's how IP > knows where to deliver your packets) or you partion your implementation > internally. > > So far, I thought the URI would include the ability to configure a > non-default target (listening) port number which would be critical to doing > this. It does, and these seem to be different issues. The primary issue here is how to get a state machine that works to solve the problem where multiple transport connections could exist. PatC From owner-aaa-wg@merit.edu Mon Jun 11 16:32:43 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18454 for ; Mon, 11 Jun 2001 16:32:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 25D2C912A5; Mon, 11 Jun 2001 16:32:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BD0AF912A6; Mon, 11 Jun 2001 16:32:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 97635912A5 for ; Mon, 11 Jun 2001 16:32:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3C7165DDD7; Mon, 11 Jun 2001 16:33:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115]) by segue.merit.edu (Postfix) with SMTP id E520F5DD92 for ; Mon, 11 Jun 2001 16:33:15 -0400 (EDT) Received: from pc25.paris-dc.fr.psi.com (HELO jc.yahoo.com) (212.81.116.25) by smtp.mail.vip.sc5.yahoo.com with SMTP; 11 Jun 2001 20:32:50 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010611222747.00c2d990@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Jun 2001 22:32:36 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 66: Server Discovery Cc: aaa-wg@merit.edu In-Reply-To: <20010611131058.M17928@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Pat, At 22:10 11/06/01, Pat Calhoun wrote: > 3.1 If the destination address is a numeric IP address, the > requestor contacts the peer at the given address and the > port number specified in the SRV record or, if not > specified, the default port (TBD). > > 3.2 The results of the query or queries are merged and ordered > based on priority. Then, the searching technique outlined in > [46] is used to select servers in order. The requestor > attempts to contact each peer in the order listed, at the > port number specified in the SRV record. If none of the > servers can be contacted, the requestor gives up. If there > are no SRV records, DNS address records are used, as > described below. In any of the above, a server should be able to contact the servers found only if they are in the peer table, right? Otherwise there is a problem with finding appropriate certificates. BTW, some clarification as to the relationship of the whole mechanism to the peer and/or routing table (and the forwarding and routing processes defined in 5.x) would be helpful. I.e. are these processes used to add stuff to the peer table, or to add stuff to the routing table, which then makes use of the pre-defined peer table? > 3.3 If the destination specifies a port number other than TBD or > if there are no SRV records, the requestor queries the DNS > server for address records for the destination address using > the FQDN field of the DiameterIdentity derived AVP data > format (see section 4.4). Address records include A RR's, > AAAA RR's, A6 RR's or other similar records, chosen > according to the requestor's network protocol capabilities. Hu? What does "the FQDN field of the DiameterIdentity derived AVP data format" mean? What exactly should be looked up? The Destination-Realm? The FQDN part of the Destination-Host? No comprendo mucho :-/ Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Mon Jun 11 16:47:06 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18651 for ; Mon, 11 Jun 2001 16:47:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 234CC912A6; Mon, 11 Jun 2001 16:47:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BBCE4912A7; Mon, 11 Jun 2001 16:47:07 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 504B3912A6 for ; Mon, 11 Jun 2001 16:47:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 008945DDD0; Mon, 11 Jun 2001 16:47:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) by segue.merit.edu (Postfix) with SMTP id AB00F5DD92 for ; Mon, 11 Jun 2001 16:47:39 -0400 (EDT) Received: from pc25.paris-dc.fr.psi.com (HELO jc.yahoo.com) (212.81.116.25) by smtp.mail.vip.sc5.yahoo.com with SMTP; 11 Jun 2001 20:47:13 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010611223312.00c66470@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Jun 2001 22:47:00 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Support for multi-process Cc: David Mitton , Pat Calhoun , Patrice Calhoun , aaa-wg@merit.edu In-Reply-To: <20010611131345.N17928@charizard.diameter.org> References: <4.3.2.7.2.20010611154446.03bcb200@ZBL6C016.corpeast.baynetworks.com> <20010611103810.E17928@charizard.diameter.org> <4.3.2.7.2.20010611154446.03bcb200@ZBL6C016.corpeast.baynetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk I think there is some confusion here... There are two different issues at hand: 1. enable multiple processes to run on the same machine 2. make sure there is only one connection between any two processes (or not, but that's another subjet) (1) requires that each process be assigned a distinct port or IP address. You cannot have two processes listening on port 1812. You could have one on 1812 and one on 1813, for instance (don't know which other protocol I just bumped into...). (2) requires either: - the use of SCTP which apparently solves the problem magically (don't know how and why, haven't read the whole spec yet, but it was stated in some previous e-mail). - the use of TCP with a complex state machine to make sure we tear down one of the two connections if two are established at the same time - the use of TCP with the same port number of listening and accepting, as I described. It is not a problem to have a process that: - listens and accepts connections on port 1812 - connects FROM port 1812 to other machines, possibly on port 1812 [replace 1812 with another port number for any other process running on the same box] On the other hand, a connection from port 1812 to another machine on port 1812 will fail if there is already a connection between these two machines using the same port(s). So, I can have: - process A1 on box A listening on port 1812 - process A2 on box A listening on port 1813 - process B1 on box B listening on port 1812 Let's say they are brought up in that order (A1, A2, B1), and we want a direct connection between each pair. The following happens: - A1 starts listening on A:1812 - A1 attempts to connect to A2 (A:1813) and B1 (B:1812) but fails (no one's listening) - A2 is started. - A2 starts listening on A:1813 - A2 attempts a connection to A:1812 (which succeeds) - A2 attempts a connection to B:1812 (which fails, no one is listening) [if A1 was to start a connection to A2 now, it would fail] - B1 is started - B1 starts listening on B:1812 - B1 attempts a connection to A:1812, which succeeds - B1 attempts a connection to A:1813, which succeeds also [if A1 or A2 were to start a connection B1 now, that would fail] So, we end up with a all three servers listening on their respective ports, and a connection established between A1 and A2, A1 and B1, A2 and B1, respectively. Exactly what we wanted. And no messy state machine. Of course, some bad TCP/sockets implementations might not support all this very well... To be checked [it worked perfectly on my good old FreeBSD boxes]. Hope it gets clearer now? Jacques. At 22:13 11/06/01, Pat Calhoun wrote: >On Mon, Jun 11, 2001 at 04:14:13PM -0400, David Mitton wrote: > > >So we need to listen for connections, and initiate connections as > well. We > > >need > > >to allow for multiple connections to multiple peers, all listening on the > > >same port. > > > > No can do. > >Of course, that's been my point all along. > > > > > Only one process can be listening on a given port number at a time. When > > the listening process accepts the connection (at least on Unix) a new > > socket is created, and typically it is given a new unique ephemeral port > > number. The original port number is not needed, as the connection has been > > made. > >Right, and this is where I got confused with Jacques e-mail that seemed to >state that this is what he wanted to do. > > > > > The listening process can spawn subprocesses or threads to handle that > > connection socket, but it still holds the listening well-known socket. > > > > If you need to run different server "instances" on the same system, they > > have to listen to connections with distinct socket numbers, (that's how IP > > knows where to deliver your packets) or you partion your implementation > > internally. > > > > So far, I thought the URI would include the ability to configure a > > non-default target (listening) port number which would be critical to > doing > > this. > >It does, and these seem to be different issues. The primary issue here is how >to get a state machine that works to solve the problem where multiple >transport connections could exist. > >PatC _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Mon Jun 11 16:48:09 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18708 for ; Mon, 11 Jun 2001 16:48:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3F095912A7; Mon, 11 Jun 2001 16:48:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 06A0E912A8; Mon, 11 Jun 2001 16:48:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D85FD912A7 for ; Mon, 11 Jun 2001 16:48:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 92D075DDD0; Mon, 11 Jun 2001 16:48:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (c000-h007.c000.snv.cp.net [209.228.32.71]) by segue.merit.edu (Postfix) with SMTP id F00185DD92 for ; Mon, 11 Jun 2001 16:48:41 -0400 (EDT) Received: (cpmta 4743 invoked from network); 11 Jun 2001 13:48:16 -0700 Received: from h121s86a16n47.user.nortelnetworks.com (HELO mitton.mitton.com) (47.16.86.121) by smtp.mitton.com (209.228.32.71) with SMTP; 11 Jun 2001 13:48:16 -0700 X-Sent: 11 Jun 2001 20:48:16 GMT Message-Id: <4.3.2.7.2.20010611161810.03b21a00@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Jun 2001 16:50:42 -0400 To: Jacques Caron , "Martin Julien (ECE)" From: David Mitton Subject: Re: [AAA-WG]: NASREQ Request-Type AVP??? Cc: "'aaa-wg@merit.edu'" In-Reply-To: <4.3.2.7.2.20010611105046.00c493f0@pop.mail.yahoo.com> References: <577066326047D41180AC00508B955DDA04D1A991@eestqnt104.es.eu. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 6/11/01 10:55 AM +0200, Jacques Caron wrote: >At 10:36 11/06/01, Martin Julien (ECE) wrote: >>Looking at the NASREQ Request-Type AVP, I would appreciate if >>someone could give me his interpretation of the following >>possible values for the Request-Type AVP. >> >> >> >> AUTHENTICATE_ONLY 1 >> The request being sent is for authentication only, and MUST >> contain the relevant authentication AVPs that are needed by the >> Diameter server to authenticate the user. >><< >> >>Since the specification says that it should not be permitted to >>authenticate-only a session, and then authorize-only the same session, >>I was wondering for what that value could really be useful? >>Should that Request-Type value be only used when answering a AA-Request >>Challenge? > >The nasreq draft indeed says in 3.1.1: > It is possible for a single session to be authorized only first, then > followed by an authentication request. However, the inverse SHOULD > NOT be permitted. > >I quite think that somebody meant the opposite (e.g. TAC+ to Diameter >gateway where authentication and authorization are two different steps, >done in that order). On cannot authorize a user which hasn't been >authenticated yet. well, yes you could. You could authorize anonymous users, or that they know the called phone number. And once you know more about them, revise that authorization. But I've never understood this text distinction either. But some argue that there is even some degenerate form of authentication buried in there. >The other possibility is that some authorization is granted first (e.g. >based on calling/called numbers to authorize a NAS to accept an ISDN >call), then authentication and authorization again (using PPP and some PPP >authentication method). But I'm not quite sure both would be linked to the >same session, actually, since it would be two different services? Not on most providers I know of. The authorization based on called/calling numbers is just incompletete, until the later information is available. All the overhead of the call is going to get factored into the billing for that user. Dave. ---------------------------------------------------- David Mitton 978-288-4570 Advisor, Nortel Networks david@mitton.com or dmitton@nortelnetworks.com From owner-aaa-wg@merit.edu Mon Jun 11 16:50:42 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18776 for ; Mon, 11 Jun 2001 16:50:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 58B77912A8; Mon, 11 Jun 2001 16:50:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 28564912A9; Mon, 11 Jun 2001 16:50:39 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 163D7912A8 for ; Mon, 11 Jun 2001 16:50:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C8AF35DDD0; Mon, 11 Jun 2001 16:51:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by segue.merit.edu (Postfix) with ESMTP id 2A1EC5DD92 for ; Mon, 11 Jun 2001 16:51:11 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (motgate4 2.1) with ESMTP id NAA17343 for ; Mon, 11 Jun 2001 13:50:45 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id NAA21239 for ; Mon, 11 Jun 2001 13:44:06 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Jun 2001 15:50:39 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECF32@IL27EXM10.cig.mot.com> From: Cain Brian-BCAIN1 To: "'Jacques Caron'" , Pat Calhoun Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Support for multi-process Date: Mon, 11 Jun 2001 15:50:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk > -----Original Message----- > From: Jacques Caron [mailto:jacques_m_caron@yahoo.com] > > At 19:38 11/06/01, Pat Calhoun wrote: > >But what if the remote box was periodically trying to > connect to the local > >box? That would always fail with 'Address already in use', > since you'd already > >bound a file descriptor on port 1812 for listening. > > Nope, it won't fail. It will fail only if there is already a > connection > between the two machines. I think that this is a less-popular usage of sockets, but it seems like it should certainly work. For locally initiated connections, some ephemeral port is usually used. But, like Jacques says, that's not how it has to be. I'm under the impression that you would have to enable an option like "SO_REUSEADDR", or something along those lines. That option (or whichever one it's supposed to be) should allow you to bind to a port that is already used in a listening socket. If there already is a connection with that particular Diameter Entity (presuming all entities follow the prescribed "make sure you're contacting other hosts from the same port you're listening on"), only then should the attempt to bind fail. I'd be curious as to what would happen in the "crossing SYN" case for TCP. Supposedly this would not be an issue for SCTP. ... > Not a problem. Remember that the uniqueness requirement is on > the tuple > (local addr, local port, remote addr, remote port), not on Don't forget transport protocol! > (local addr, > local port). From owner-aaa-wg@merit.edu Mon Jun 11 16:54:25 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18832 for ; Mon, 11 Jun 2001 16:54:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1654A912A9; Mon, 11 Jun 2001 16:54:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DE3D4912AA; Mon, 11 Jun 2001 16:54:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AD9AF912A9 for ; Mon, 11 Jun 2001 16:54:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6BCFB5DDD0; Mon, 11 Jun 2001 16:54:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 785CC5DD92 for ; Mon, 11 Jun 2001 16:54:50 -0400 (EDT) Received: (qmail 17944 invoked by uid 500); 11 Jun 2001 20:37:41 -0000 Date: Mon, 11 Jun 2001 13:37:41 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 66: Server Discovery Message-ID: <20010611133740.O17928@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <20010611131058.M17928@charizard.diameter.org> <4.3.2.7.2.20010611222747.00c2d990@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010611222747.00c2d990@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Mon, Jun 11, 2001 at 10:32:36PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Jun 11, 2001 at 10:32:36PM +0200, Jacques Caron wrote: > At 22:10 11/06/01, Pat Calhoun wrote: > > 3.1 If the destination address is a numeric IP address, the > > requestor contacts the peer at the given address and the > > port number specified in the SRV record or, if not > > specified, the default port (TBD). > > > > 3.2 The results of the query or queries are merged and ordered > > based on priority. Then, the searching technique outlined in > > [46] is used to select servers in order. The requestor > > attempts to contact each peer in the order listed, at the > > port number specified in the SRV record. If none of the > > servers can be contacted, the requestor gives up. If there > > are no SRV records, DNS address records are used, as > > described below. > > In any of the above, a server should be able to contact the servers found > only if they are in the peer table, right? Otherwise there is a problem > with finding appropriate certificates. There are alternate means of finding certificates. > > BTW, some clarification as to the relationship of the whole mechanism to > the peer and/or routing table (and the forwarding and routing processes > defined in 5.x) would be helpful. I.e. are these processes used to add > stuff to the peer table, or to add stuff to the routing table, which then > makes use of the pre-defined peer table? ok, let me see what I can do. > > > 3.3 If the destination specifies a port number other than TBD or > > if there are no SRV records, the requestor queries the DNS > > server for address records for the destination address using > > the FQDN field of the DiameterIdentity derived AVP data > > format (see section 4.4). Address records include A RR's, > > AAAA RR's, A6 RR's or other similar records, chosen > > according to the requestor's network protocol capabilities. > > Hu? What does "the FQDN field of the DiameterIdentity derived AVP data > format" mean? What exactly should be looked up? The Destination-Realm? The > FQDN part of the Destination-Host? Section 4.4 includes: DiameterIdentity The DiameterIdentity format is derived from the OctetString AVP Base Format. It uses the UTF-8 encoding and has the same requirements as the UTF8String. In addition, it must follow the Uniform Resource Identifiers (URI) syntax [29] rules specified below: Diameter-Identity = [scheme-name] fqdn [ port ] [ transport ] [legacy-protocol] scheme-name = "diameter://" ; If absent, the default is "diameter://" fqdn = Fully Qualified Host Name [...] I was talking about the fqdn portion of this, which is used in Destination-Host, Redirect-Host, etc. I do, however, now realize that FQDN should NOT be capitalized to reflect the text in section 4.4 > No comprendo mucho :-/ Make more sense? PatC From owner-aaa-wg@merit.edu Mon Jun 11 16:55:44 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18859 for ; Mon, 11 Jun 2001 16:55:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7561D912AA; Mon, 11 Jun 2001 16:55:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4D35F912AB; Mon, 11 Jun 2001 16:55:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DDFF7912AA for ; Mon, 11 Jun 2001 16:55:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9AFA95DDD7; Mon, 11 Jun 2001 16:56:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by segue.merit.edu (Postfix) with SMTP id 4EB315DDD0 for ; Mon, 11 Jun 2001 16:56:17 -0400 (EDT) Received: from pc25.paris-dc.fr.psi.com (HELO jc.yahoo.com) (212.81.116.25) by smtp.mail.vip.sc5.yahoo.com with SMTP; 11 Jun 2001 20:55:51 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010611225309.00c69b50@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Jun 2001 22:55:38 +0200 To: Cain Brian-BCAIN1 From: Jacques Caron Subject: RE: [AAA-WG]: Support for multi-process Cc: Pat Calhoun , aaa-wg@merit.edu In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B0ECF32@IL27EXM10.cig.mot.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 22:50 11/06/01, Cain Brian-BCAIN1 wrote: > > -----Original Message----- > > From: Jacques Caron [mailto:jacques_m_caron@yahoo.com] > > > > At 19:38 11/06/01, Pat Calhoun wrote: > > >But what if the remote box was periodically trying to > > connect to the local > > >box? That would always fail with 'Address already in use', > > since you'd already > > >bound a file descriptor on port 1812 for listening. > > > > Nope, it won't fail. It will fail only if there is already a > > connection > > between the two machines. > >I think that this is a less-popular usage of sockets, but it seems like it >should certainly work. For locally initiated connections, some ephemeral >port is usually used. But, like Jacques says, that's not how it has to >be. I'm under the impression that you would have to enable an option like >"SO_REUSEADDR", or something along those lines. That option (or whichever >one it's supposed to be) should allow you to bind to a port that is >already used in a listening socket. If there already is a connection with >that particular Diameter Entity (presuming all entities follow the >prescribed "make sure you're contacting other hosts from the same port >you're listening on"), only then should the attempt to bind fail. Indeed, SO_REUSEADDR and/or SO_REUSEPORT are quite useful :-) Still have to understand the exact distinction between those two, though. And it should be the attempt to connect, not to bind, that would fail. > Not a problem. Remember that the uniqueness requirement is on > > the tuple > > (local addr, local port, remote addr, remote port), not on > >Don't forget transport protocol! I was talking in the context of TCP of course :-) Other transport protocols might have different rules for uniqueness... Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Mon Jun 11 16:59:22 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18917 for ; Mon, 11 Jun 2001 16:59:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B5DFE912AB; Mon, 11 Jun 2001 16:59:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8B9CB912AC; Mon, 11 Jun 2001 16:59:27 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1891D912AB for ; Mon, 11 Jun 2001 16:59:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CB64E5DDD0; Mon, 11 Jun 2001 16:59:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp010.mail.yahoo.com (smtp010.mail.yahoo.com [216.136.173.30]) by segue.merit.edu (Postfix) with SMTP id 4FB635DD92 for ; Mon, 11 Jun 2001 16:59:58 -0400 (EDT) Received: from pc25.paris-dc.fr.psi.com (HELO jc.yahoo.com) (212.81.116.25) by smtp.mail.vip.sc5.yahoo.com with SMTP; 11 Jun 2001 20:59:32 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010611225623.00c66a60@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Jun 2001 22:59:22 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 66: Server Discovery Cc: Pat Calhoun , aaa-wg@merit.edu In-Reply-To: <20010611133740.O17928@charizard.diameter.org> References: <4.3.2.7.2.20010611222747.00c2d990@pop.mail.yahoo.com> <20010611131058.M17928@charizard.diameter.org> <4.3.2.7.2.20010611222747.00c2d990@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 22:37 11/06/01, Pat Calhoun wrote: > > > 3.3 If the destination specifies a port number other than TBD or > > > if there are no SRV records, the requestor queries the DNS > > > server for address records for the destination address using > > > the FQDN field of the DiameterIdentity derived AVP data > > > format (see section 4.4). Address records include A RR's, > > > AAAA RR's, A6 RR's or other similar records, chosen > > > according to the requestor's network protocol capabilities. > > > > Hu? What does "the FQDN field of the DiameterIdentity derived AVP data > > format" mean? What exactly should be looked up? The Destination-Realm? The > > FQDN part of the Destination-Host? [...] >I was talking about the fqdn portion of this, which is used in >Destination-Host, >Redirect-Host, etc. I had guessed so, but exactly which AVP are we talking about? Destination-Host? Then this is not really discovery, but pretty much direct use of the FQDN in there, not much different from case 1, is it? >I do, however, now realize that FQDN should NOT be capitalized to reflect the >text in section 4.4 I don't think that was the part that was a problem... > > No comprendo mucho :-/ > >Make more sense? Not yet :-( Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Mon Jun 11 17:08:18 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19110 for ; Mon, 11 Jun 2001 17:08:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 394C7912AD; Mon, 11 Jun 2001 17:08:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 00C40912AE; Mon, 11 Jun 2001 17:08:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D29EA912AD for ; Mon, 11 Jun 2001 17:08:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8B7065DDD0; Mon, 11 Jun 2001 17:08:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 36A195DD92 for ; Mon, 11 Jun 2001 17:08:45 -0400 (EDT) Received: (qmail 18353 invoked by uid 500); 11 Jun 2001 20:57:51 -0000 Date: Mon, 11 Jun 2001 13:57:51 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu, aboba@internaut.com Subject: Re: [AAA-WG]: Issue 66: Server Discovery Message-ID: <20010611135751.P17928@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu, aboba@internaut.com References: <4.3.2.7.2.20010611222747.00c2d990@pop.mail.yahoo.com> <20010611131058.M17928@charizard.diameter.org> <4.3.2.7.2.20010611222747.00c2d990@pop.mail.yahoo.com> <20010611133740.O17928@charizard.diameter.org> <4.3.2.7.2.20010611225623.00c66a60@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010611225623.00c66a60@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Mon, Jun 11, 2001 at 10:59:22PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Jun 11, 2001 at 10:59:22PM +0200, Jacques Caron wrote: > At 22:37 11/06/01, Pat Calhoun wrote: > > > > 3.3 If the destination specifies a port number other than TBD or > > > > if there are no SRV records, the requestor queries the DNS > > > > server for address records for the destination address using > > > > the FQDN field of the DiameterIdentity derived AVP data > > > > format (see section 4.4). Address records include A RR's, > > > > AAAA RR's, A6 RR's or other similar records, chosen > > > > according to the requestor's network protocol capabilities. > > > > > > Hu? What does "the FQDN field of the DiameterIdentity derived AVP data > > > format" mean? What exactly should be looked up? The Destination-Realm? The > > > FQDN part of the Destination-Host? > > [...] > > >I was talking about the fqdn portion of this, which is used in > >Destination-Host, > >Redirect-Host, etc. > > I had guessed so, but exactly which AVP are we talking about? > Destination-Host? Then this is not really discovery, but pretty much direct > use of the FQDN in there, not much different from case 1, is it? To be honest, I don't frankly get this anymore than you do, and I think I need to ask Bernard what he had in mind. If you are discovery servers, it implies you don't know who they are. If you have a host name, then use DNS. So, thinking about this some more, I don't get this either, and will punt to Bernard. Bernard? PatC From owner-aaa-wg@merit.edu Mon Jun 11 17:09:06 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19123 for ; Mon, 11 Jun 2001 17:09:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 59D55912AE; Mon, 11 Jun 2001 17:09:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2B83E912AF; Mon, 11 Jun 2001 17:09:15 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1354D912AE for ; Mon, 11 Jun 2001 17:09:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CAD805DDD0; Mon, 11 Jun 2001 17:09:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 4ED375DD92 for ; Mon, 11 Jun 2001 17:09:47 -0400 (EDT) Received: from heliopolis.eng.sun.com ([152.70.1.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21577; Mon, 11 Jun 2001 15:09:21 -0600 (MDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id OAA16863; Mon, 11 Jun 2001 14:09:21 -0700 (PDT) Message-Id: <200106112109.OAA16863@heliopolis.eng.sun.com> Date: Mon, 11 Jun 2001 14:09:21 -0700 (PDT) From: Jonathan Wood Reply-To: Jonathan Wood Subject: Re: [AAA-WG]: Support for multi-process To: pcalhoun@diameter.org, jacques_m_caron@yahoo.com Cc: dmitton@nortelnetworks.com, pcalhoun@nasnfs.eng.sun.com, aaa-wg@merit.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: CYhE2Myy73kMAGT9CUDqfg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-aaa-wg@merit.edu Precedence: bulk > >I think there is some confusion here... There are two different issues at hand: >1. enable multiple processes to run on the same machine >2. make sure there is only one connection between any two processes (or >not, but that's another subjet) > >(1) requires that each process be assigned a distinct port or IP address. >You cannot have two processes listening on port 1812. You could have one on >1812 and one on 1813, for instance (don't know which other protocol I just >bumped into...). > >(2) requires either: >- the use of SCTP which apparently solves the problem magically (don't know >how and why, haven't read the whole spec yet, but it was stated in some >previous e-mail). >- the use of TCP with a complex state machine to make sure we tear down one >of the two connections if two are established at the same time >- the use of TCP with the same port number of listening and accepting, as I >described. > I just checked the TCP spec on this (rfc793, section 3.4). TCP and SCTP both handle the situation in the same way, i.e. the two connections resolve into a single connection. Just to be absolutely clear: this only happens when the two connections are identical. For example, host A has IP address 192.168.100.100 and the local port 1812, and host B has IP address 192.168.200.200 and local port 1812. (Note that this means, in socket terms, both are listening on port 1812.) Now A and B then both try to connect() to each other from port 1812 to port 1812. These two connections are indistinguishable to both TCP and SCTP, and so *must* resolve into a single connection. If A or B had substitued any other port for their local port (like a transient port), there would be two different connections. So if you allow connecting from transient ports, then yes, you need to hack up the state machine to close one of the connections down. If you always connect from a well- known port, TCP and SCTP will take care of it for you. Jonathan From owner-aaa-wg@merit.edu Mon Jun 11 18:36:34 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20201 for ; Mon, 11 Jun 2001 18:36:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 55391912B0; Mon, 11 Jun 2001 18:36:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 24ED9912B1; Mon, 11 Jun 2001 18:36:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 10B05912B0 for ; Mon, 11 Jun 2001 18:36:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D4D4F5DDA2; Mon, 11 Jun 2001 18:37:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans-old.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 127635DD92 for ; Mon, 11 Jun 2001 18:37:02 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA19133; Mon, 11 Jun 2001 18:35:49 -0400 (EDT) Date: Mon, 11 Jun 2001 18:36:15 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: Jacques Caron Cc: Pat Calhoun , David Mitton , Patrice Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Support for multi-process In-Reply-To: <4.3.2.7.2.20010611223312.00c66470@pop.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Jacques, On Mon, 11 Jun 2001, Jacques Caron wrote: > It is not a problem to have a process that: > - listens and accepts connections on port 1812 > - connects FROM port 1812 to other machines, possibly on port 1812 > [replace 1812 with another port number for any other process running on the > same box] > From your example, it seemed that you could get the above to work. I have not had such luck. Maybe I need to go back to TCP 101 :). If I do the following pseudocode, s = socket(AF_INET, SOCK_STREAM, IP_PROTOCOL_TCP); s_addr = (AF_INET, 1812, 1.1.1.1); bind(s, (AF_INET, s_addr, sizeof(s_addr)); d_addr = (AF_INET, 1812, *); listen(s, 10); accept(s, d_addr); I now can't get another thread bind to (AF_INET, 1812, 1.1.1.1) so that I can request a connection to (AF_INET, 1812, 2.2.2.2). Is this possible? -mark From owner-aaa-wg@merit.edu Mon Jun 11 18:47:57 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20337 for ; Mon, 11 Jun 2001 18:47:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 51FEB912B1; Mon, 11 Jun 2001 18:48:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 136F5912B2; Mon, 11 Jun 2001 18:48:07 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EB55C912B1 for ; Mon, 11 Jun 2001 18:48:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BA32D5DDA2; Mon, 11 Jun 2001 18:48:39 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by segue.merit.edu (Postfix) with SMTP id 6F4BC5DD92 for ; Mon, 11 Jun 2001 18:48:39 -0400 (EDT) Received: from jc-mac.planete.net (HELO jc.yahoo.com) (194.2.222.120) by smtp.mail.vip.sc5.yahoo.com with SMTP; 11 Jun 2001 22:48:13 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010612003836.00bec3a0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Jun 2001 00:48:01 +0200 To: Mark Eklund From: Jacques Caron Subject: Re: [AAA-WG]: Support for multi-process Cc: Pat Calhoun , David Mitton , Patrice Calhoun , aaa-wg@merit.edu In-Reply-To: References: <4.3.2.7.2.20010611223312.00c66470@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Mark, You need to setsockopt SO_REUSEADDR and SO_REUSEPORT to on(1). Not sure you actually need both, but it works that way :-) Note that it needs to be done on both sockets (the one listening/accepting and the one connecting). I can send you some (very very very ugly) code I used for my tests if you want to try it out. Of course, all of this is true on a good BSD stack. Don't know how it might turn out on other stacks that might make too strong asumptions about TCP requirements for uniqueness. Jacques. At 00:36 12/06/01, Mark Eklund wrote: >Jacques, > >On Mon, 11 Jun 2001, Jacques Caron wrote: > > > It is not a problem to have a process that: > > - listens and accepts connections on port 1812 > > - connects FROM port 1812 to other machines, possibly on port 1812 > > [replace 1812 with another port number for any other process running on > the > > same box] > > > > From your example, it seemed that you could get the above to >work. I have not had such luck. Maybe I need to go back to TCP >101 :). If I do the following pseudocode, > >s = socket(AF_INET, SOCK_STREAM, IP_PROTOCOL_TCP); >s_addr = (AF_INET, 1812, 1.1.1.1); >bind(s, (AF_INET, s_addr, sizeof(s_addr)); >d_addr = (AF_INET, 1812, *); >listen(s, 10); >accept(s, d_addr); > >I now can't get another thread bind to (AF_INET, 1812, 1.1.1.1) >so that I can request a connection to (AF_INET, 1812, 2.2.2.2). > >Is this possible? > >-mark _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Mon Jun 11 19:43:58 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20762 for ; Mon, 11 Jun 2001 19:43:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6A4A8912B2; Mon, 11 Jun 2001 19:43:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 35D8C912B3; Mon, 11 Jun 2001 19:43:49 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EF4C9912B2 for ; Mon, 11 Jun 2001 19:43:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D2A275DDD6; Mon, 11 Jun 2001 19:44:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 57F325DD92 for ; Mon, 11 Jun 2001 19:44:21 -0400 (EDT) Received: from heliopolis.eng.sun.com ([152.70.1.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA07189; Mon, 11 Jun 2001 17:43:55 -0600 (MDT) Received: from sloth (dsl199-239.Eng.Sun.COM [129.146.199.239]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id QAA22342; Mon, 11 Jun 2001 16:43:54 -0700 (PDT) Message-Id: <200106112343.QAA22342@heliopolis.eng.sun.com> Date: Mon, 11 Jun 2001 16:43:54 -0700 (PDT) From: Jonathan Wood Reply-To: Jonathan Wood Subject: Re: [AAA-WG]: Support for multi-process To: meklund@cisco.com, jacques_m_caron@yahoo.com Cc: pcalhoun@diameter.org, dmitton@nortelnetworks.com, pcalhoun@nasnfs.eng.sun.com, aaa-wg@merit.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: lkr3/p91ISfSJKy6EqIisQ== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Sender: owner-aaa-wg@merit.edu Precedence: bulk Further investigation shows that my previous email was not entirely accurate :( INIT / SYN collision behavior for TCP and SCTP are as described, but generating the scenario is not as described - see below for more details. > > Mark, > > You need to setsockopt SO_REUSEADDR and SO_REUSEPORT to on(1). Not sure you > actually need both, but it works that way :-) Note that it needs to be done > on both sockets (the one listening/accepting and the one connecting). This won't work on many systems. Stevens Unix Networking Programming V1, section 7.5 has a good discussion on these options. In particular: "With TCP we are never able to start multiple servers that bind the same IP address and the same port: a completely duplicate binding." I just tried this on Solaris 8, and verified that it does indeed fail. Also SO_REUSEPORT does not exist on Solaris. Stevens notes that this option was introduced in BSD to allow completely duplicate bindings *when it makes sense*, i.e. for UDP multicast or broadcast. It looks like your BSD stack is allowing it for TCP, where it does not make sense. SCTP sockets have the same behavior as TCP here. The way I generate SCTP INIT collisions is to have two endpoints both *connect()* at the same time; neither is listening. (This is, of course, a race condition; I had to use a middlebox to delay the INIT packets so that they did actually cross paths.) Jonathan > > I can send you some (very very very ugly) code I used for my tests if you > want to try it out. > > Of course, all of this is true on a good BSD stack. Don't know how it might > turn out on other stacks that might make too strong asumptions about TCP > requirements for uniqueness. > > Jacques. > > At 00:36 12/06/01, Mark Eklund wrote: > >Jacques, > > > >On Mon, 11 Jun 2001, Jacques Caron wrote: > > > > > It is not a problem to have a process that: > > > - listens and accepts connections on port 1812 > > > - connects FROM port 1812 to other machines, possibly on port 1812 > > > [replace 1812 with another port number for any other process running on > > the > > > same box] > > > > > > > From your example, it seemed that you could get the above to > >work. I have not had such luck. Maybe I need to go back to TCP > >101 :). If I do the following pseudocode, > > > >s = socket(AF_INET, SOCK_STREAM, IP_PROTOCOL_TCP); > >s_addr = (AF_INET, 1812, 1.1.1.1); > >bind(s, (AF_INET, s_addr, sizeof(s_addr)); > >d_addr = (AF_INET, 1812, *); > >listen(s, 10); > >accept(s, d_addr); > > > >I now can't get another thread bind to (AF_INET, 1812, 1.1.1.1) > >so that I can request a connection to (AF_INET, 1812, 2.2.2.2). > > > >Is this possible? > > > >-mark > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > From owner-aaa-wg@merit.edu Mon Jun 11 19:48:44 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20832 for ; Mon, 11 Jun 2001 19:48:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 05DB5912B3; Mon, 11 Jun 2001 19:48:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C99EF912B4; Mon, 11 Jun 2001 19:48:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B5841912B3 for ; Mon, 11 Jun 2001 19:48:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9DDFA5DDD6; Mon, 11 Jun 2001 19:49:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 2930F5DD92 for ; Mon, 11 Jun 2001 19:49:25 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f5BNn0a00077 for ; Mon, 11 Jun 2001 18:49:00 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f5BNmxV11082 for ; Mon, 11 Jun 2001 18:48:59 -0500 (CDT) Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id SAA13942 for ; Mon, 11 Jun 2001 18:48:59 -0500 (CDT) Received: from ericsson.com (busam68.berkeley.us.am.ericsson.se [138.85.159.218]) by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id SAA21965 for ; Mon, 11 Jun 2001 18:48:56 -0500 (CDT) Message-ID: <3B255808.EC16EE40@ericsson.com> Date: Mon, 11 Jun 2001 16:45:12 -0700 From: Tony Johansson X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 77: Possibility for implicit termination of an Authentication or Authorization session. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, Here is a new issue. /Tony Issue 77: Possibility for implicit termination of an Authentication or Authorization session. Submitter name: Tony Johansson Submitter email address: tony.johansson@ericsson.com Date first submitted: 2001-06-11 Reference: Document: Base Comment type: T Priority: 1 Section: 10 Rationale/Explanation of issue: There may be cases where you don't need to store any session information in the AAA. For example, there may be cases where the access device will handle all seesion information. Thus, an access device may request authentication as a one time thing and no further messages would be needed between the access device and the AAA. Proposal: Perhaps a request from the access device SHOULD allow the Authorization-Lifetime (as a hint to the server). A value of zero implies that no state should be created, and no STR will be sent. A value of zero is a one-shot thing (auth once, never hear from me again). From owner-aaa-wg@merit.edu Mon Jun 11 19:59:04 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20906 for ; Mon, 11 Jun 2001 19:59:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3C121912B4; Mon, 11 Jun 2001 19:58:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 07A8A912B5; Mon, 11 Jun 2001 19:58:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C1145912B4 for ; Mon, 11 Jun 2001 19:58:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A7EE85DDD6; Mon, 11 Jun 2001 19:59:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by segue.merit.edu (Postfix) with SMTP id 277715DD92 for ; Mon, 11 Jun 2001 19:59:31 -0400 (EDT) Received: from jc-mac.planete.net (HELO jc.yahoo.com) (194.2.222.120) by smtp.mail.vip.sc5.yahoo.com with SMTP; 11 Jun 2001 23:59:05 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010612015334.00c1ba20@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Jun 2001 01:58:48 +0200 To: Jonathan Wood From: Jacques Caron Subject: Re: [AAA-WG]: Support for multi-process Cc: meklund@cisco.com, pcalhoun@diameter.org, dmitton@nortelnetworks.com, pcalhoun@nasnfs.eng.sun.com, aaa-wg@merit.edu In-Reply-To: <200106112343.QAA22342@heliopolis.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Mmmm.... I expected that indeed not all stacks would allow it, though I think it's more a limitation of the sockets implementation than of TCP itself? It is perfectly possible to have multiple sockets/TCP connections associated to the same (local addr, local port) pair (as in multiple connections that were accepted on a listening socket), and are differentiated by the (remote addr, remote port) pair, so I don't quite see why it shouldn't be possible (or wouldn't make sense) to also have an active connection from the same (local addr, local port) pair... I guess it wasn't felt as being useful. Too bad. It was worth a try :-/ And now back to our regular state machine programming... Jacques. At 01:43 12/06/01, Jonathan Wood wrote: >Further investigation shows that my previous email was >not entirely accurate :( INIT / SYN collision behavior >for TCP and SCTP are as described, but generating the >scenario is not as described - see below for more details. > > > > > Mark, > > > > You need to setsockopt SO_REUSEADDR and SO_REUSEPORT to on(1). Not sure > you > > actually need both, but it works that way :-) Note that it needs to be > done > > on both sockets (the one listening/accepting and the one connecting). > >This won't work on many systems. > >Stevens Unix Networking Programming V1, section 7.5 has a >good discussion on these options. In particular: > >"With TCP we are never able to start multiple servers >that bind the same IP address and the same port: a >completely duplicate binding." > >I just tried this on Solaris 8, and verified that it does >indeed fail. > >Also SO_REUSEPORT does not exist on Solaris. Stevens notes >that this option was introduced in BSD to allow completely >duplicate bindings *when it makes sense*, i.e. for UDP >multicast or broadcast. It looks like your BSD stack is >allowing it for TCP, where it does not make sense. > >SCTP sockets have the same behavior as TCP here. The way I >generate SCTP INIT collisions is to have two endpoints >both *connect()* at the same time; neither is listening. >(This is, of course, a race condition; I had to use a >middlebox to delay the INIT packets so that they did >actually cross paths.) > >Jonathan > > > > > I can send you some (very very very ugly) code I used for my tests if you > > want to try it out. > > > > Of course, all of this is true on a good BSD stack. Don't know how it > might > > turn out on other stacks that might make too strong asumptions about TCP > > requirements for uniqueness. > > > > Jacques. > > > > At 00:36 12/06/01, Mark Eklund wrote: > > >Jacques, > > > > > >On Mon, 11 Jun 2001, Jacques Caron wrote: > > > > > > > It is not a problem to have a process that: > > > > - listens and accepts connections on port 1812 > > > > - connects FROM port 1812 to other machines, possibly on port 1812 > > > > [replace 1812 with another port number for any other process > running on > > > the > > > > same box] > > > > > > > > > > From your example, it seemed that you could get the above to > > >work. I have not had such luck. Maybe I need to go back to TCP > > >101 :). If I do the following pseudocode, > > > > > >s = socket(AF_INET, SOCK_STREAM, IP_PROTOCOL_TCP); > > >s_addr = (AF_INET, 1812, 1.1.1.1); > > >bind(s, (AF_INET, s_addr, sizeof(s_addr)); > > >d_addr = (AF_INET, 1812, *); > > >listen(s, 10); > > >accept(s, d_addr); > > > > > >I now can't get another thread bind to (AF_INET, 1812, 1.1.1.1) > > >so that I can request a connection to (AF_INET, 1812, 2.2.2.2). > > > > > >Is this possible? > > > > > >-mark > > > > > > _________________________________________________________ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Mon Jun 11 21:01:11 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21518 for ; Mon, 11 Jun 2001 21:01:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CF4CF912B8; Mon, 11 Jun 2001 20:58:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A0C41912BB; Mon, 11 Jun 2001 20:58:02 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C70F1912B8 for ; Mon, 11 Jun 2001 20:57:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D736C5DDD6; Mon, 11 Jun 2001 20:58:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 84D3C5DD92 for ; Mon, 11 Jun 2001 20:58:32 -0400 (EDT) Received: (qmail 20535 invoked by uid 500); 12 Jun 2001 00:47:37 -0000 Date: Mon, 11 Jun 2001 17:47:37 -0700 From: Pat Calhoun To: Tony Johansson Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 77: Possibility for implicit termination of an Authentication or Authorization session. Message-ID: <20010611174737.D17928@charizard.diameter.org> Mail-Followup-To: Tony Johansson , aaa-wg@merit.edu References: <3B255808.EC16EE40@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B255808.EC16EE40@ericsson.com>; from tony.johansson@ericsson.com on Mon, Jun 11, 2001 at 04:45:12PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Tony, This works for me, and including a zero Authorization-Lifetime is a great way for an access device to signal that it doesn't expect to send additional messages to the home server. Of course, I *think* that some issues MAY arise if the home server decides that it wishes to maintain state, so a Result-Code value must also be created to allow the server to reject specifically this request (as opposed to some complicated Failed-AVP processing. Anyone object to this reasonable request? I can think of quite a few uses. PatC On Mon, Jun 11, 2001 at 04:45:12PM -0700, Tony Johansson wrote: > All, > > Here is a new issue. > > /Tony > > Issue 77: Possibility for implicit termination of an Authentication or > Authorization session. > Submitter name: Tony Johansson > Submitter email address: tony.johansson@ericsson.com > Date first submitted: 2001-06-11 > Reference: > Document: Base > Comment type: T > Priority: 1 > Section: 10 > Rationale/Explanation of issue: > There may be cases where you don't need to store any session information > in the AAA. For example, there may be cases where the access device will > handle all seesion information. Thus, an access device may request > authentication as a one time thing and no further messages would be > needed between the access device and the AAA. > > Proposal: > Perhaps a request from the access device SHOULD allow the > Authorization-Lifetime (as a hint to the server). A value of zero > implies that no state should be created, and no STR will be sent. A > value of zero is a one-shot thing (auth once, never hear from me again). > From owner-aaa-wg@merit.edu Mon Jun 11 21:28:34 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21742 for ; Mon, 11 Jun 2001 21:28:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4BE95912B9; Mon, 11 Jun 2001 21:28:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1F972912BA; Mon, 11 Jun 2001 21:28:31 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1DB9B912B9 for ; Mon, 11 Jun 2001 21:28:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2DFC25DDCD; Mon, 11 Jun 2001 21:29:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from tp.databus.com (p101-46.acedsl.com [160.79.101.46]) by segue.merit.edu (Postfix) with ESMTP id 83D095DD92 for ; Mon, 11 Jun 2001 21:29:03 -0400 (EDT) Received: (from barney@localhost) by tp.databus.com (8.11.3/8.11.3) id f5C1RKf94518; Mon, 11 Jun 2001 21:27:20 -0400 (EDT) (envelope-from barney) Date: Mon, 11 Jun 2001 21:27:19 -0400 From: Barney Wolff To: Jonathan Wood Cc: meklund@cisco.com, jacques_m_caron@yahoo.com, pcalhoun@diameter.org, dmitton@nortelnetworks.com, pcalhoun@nasnfs.eng.sun.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Support for multi-process Message-ID: <20010611212719.A94393@tp.databus.com> References: <200106112343.QAA22342@heliopolis.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106112343.QAA22342@heliopolis.eng.sun.com>; from Jonathan.Wood@Sun.COM on Mon, Jun 11, 2001 at 04:43:54PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk In defense of my favorite Unix, the only nonsensical case is two TCP sockets actually listening on the same addr/port. There's no reason to prevent two from bind()ing it, if SO_REUSEADDR is set on both. Barney Wolff On Mon, Jun 11, 2001 at 04:43:54PM -0700, Jonathan Wood wrote: > > Also SO_REUSEPORT does not exist on Solaris. Stevens notes > that this option was introduced in BSD to allow completely > duplicate bindings *when it makes sense*, i.e. for UDP > multicast or broadcast. It looks like your BSD stack is > allowing it for TCP, where it does not make sense. From owner-aaa-wg@merit.edu Tue Jun 12 04:43:56 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10957 for ; Tue, 12 Jun 2001 04:43:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B16E5912C3; Tue, 12 Jun 2001 04:43:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7ED26912C4; Tue, 12 Jun 2001 04:43:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2DF1F912C3 for ; Tue, 12 Jun 2001 04:43:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C0F0F5DDEB; Tue, 12 Jun 2001 04:44:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 791535DD8F for ; Tue, 12 Jun 2001 04:44:21 -0400 (EDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f5C8hrO15113 for ; Tue, 12 Jun 2001 10:43:53 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Jun 12 10:43:51 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 10:43:50 +0200 Message-ID: <577066326047D41180AC00508B955DDA04F5EFA3@eestqnt104.es.eu.ericsson.se> From: "Irene Martin Cabello (ECE)" To: "'Pat Calhoun'" , Tony Johansson Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 77: Possibility for implicit termination of an Authentication or Authorization session. Date: Tue, 12 Jun 2001 10:43:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk In the Base Protocol (chapter 10.4, Authorization Lifetime) is writen: "A value of zero means that no re-authorization is required". I thought this value of zero was useful when AAA does not require a re-authentication and/or re-authorization initiated from the access device, because the AAA will be in charge of initiating it by means of sending an unsolicited AA-Answer message with the Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH (former "AA-Challenge" message). But, according to your proposal, the value of zero implies that no session information will be stored in the AAA. Then my above assumption was wrong, but then my question is: when could be useful for the AAA to send an unsolicited re-authentication and/or re-authorization? I think always the access device must be in charge of requesting a re-authentication and/or re-authorization, and the AAA MUST clean up resources when the Authorization lifettime expires without re-authorization. Also, I thought that when an "authentication only" request message is received in the AAA, the AAA should validate the authentication but the AAA should not store any session information since authorization is not requested. Is this wrong? It would be very useful if it is clarified in NASREQ draft, when "authentication only" and "authorization only" should be allowed/rejected. Another question: when re-authorization is requested, the AAA should just extend the "life" of the session and return the Authorization Lifetime in the AA-Answer message, or should this message also include again the authorization AVPs provided in the first AA-Answer message? Thanks in advance for your answers, Irene > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Tuesday, June 12, 2001 2:48 AM > To: Tony Johansson > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Issue 77: Possibility for implicit > termination of > an Authentication or Authorization session. > > > Tony, > > This works for me, and including a zero > Authorization-Lifetime is a great way > for an access device to signal that it doesn't expect to send > additional messages to > the home server. Of course, I *think* that some issues MAY > arise if the home server > decides that it wishes to maintain state, so a Result-Code > value must also be > created to allow the server to reject specifically this > request (as opposed to some > complicated Failed-AVP processing. > > Anyone object to this reasonable request? I can think of > quite a few uses. > > PatC > On Mon, Jun 11, 2001 at 04:45:12PM -0700, Tony Johansson wrote: > > All, > > > > Here is a new issue. > > > > /Tony > > > > Issue 77: Possibility for implicit termination of an > Authentication or > > Authorization session. > > Submitter name: Tony Johansson > > Submitter email address: tony.johansson@ericsson.com > > Date first submitted: 2001-06-11 > > Reference: > > Document: Base > > Comment type: T > > Priority: 1 > > Section: 10 > > Rationale/Explanation of issue: > > There may be cases where you don't need to store any > session information > > in the AAA. For example, there may be cases where the > access device will > > handle all seesion information. Thus, an access device may request > > authentication as a one time thing and no further messages would be > > needed between the access device and the AAA. > > > > Proposal: > > Perhaps a request from the access device SHOULD allow the > > Authorization-Lifetime (as a hint to the server). A value of zero > > implies that no state should be created, and no STR will be sent. A > > value of zero is a one-shot thing (auth once, never hear > from me again). > > > From owner-aaa-wg@merit.edu Tue Jun 12 05:06:12 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11068 for ; Tue, 12 Jun 2001 05:06:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E75E7912C5; Tue, 12 Jun 2001 05:06:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B4CB3912C6; Tue, 12 Jun 2001 05:06:03 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8E9A1912C5 for ; Tue, 12 Jun 2001 05:06:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 385C15DDEB; Tue, 12 Jun 2001 05:06:37 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 460D25DD8F for ; Tue, 12 Jun 2001 05:06:34 -0400 (EDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f5C966O06373 for ; Tue, 12 Jun 2001 11:06:06 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Jun 12 11:06:05 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 11:06:04 +0200 Message-ID: <577066326047D41180AC00508B955DDA051E3F9E@eestqnt104.es.eu.ericsson.se> From: "Marta Morant-Artazkotz (ECE)" To: Pat Calhoun , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Proposed fixes for Issues 13, 18 and 30 Date: Tue, 12 Jun 2001 11:05:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi all, I am sorry about talking about this so late but I miss the old DSI-Event AVP value DIAMETER_REDIRECT_INDICATION (its value was 3001 in the draft -04) within the new Result-Code AVP values (the 3001 value means DIAMETER_INVALID_ROUTE_RECORD in the draft -05). Regards, Marta -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Friday, May 25, 2001 2:24 PM To: aaa-wg@merit.edu Subject: [AAA-WG]: Proposed fixes for Issues 13, 18 and 30 All, Below is the new text for section 9, which attempts to address the issues mentioned above. I would appreciate some feedback from folks on whether the text is consistent with their understanding of the outcome of the Interim meeting. Actual fixes: Issue 13: DSI is removed, and a new answer only message is used to report protocol errors. Protocol errors MAY be treated at each hop. The DSI-Events are moved to a new class within the Result-Code AVP. Issue 18: Error-Reporting-FQDN was a dup of Origin-FQDN, and therefore MUST only be included if a host is changing the result-code AVP, and is not the one whose identity is in the Origin-FQDN. Issue 30: Failed-AVP should be a grouped AVP, and include the offending AVP in it's group. Thanks, PatC ---- 9.0 Error Handling There are two different types of errors in Diameter; protocol and extensions. A protocol error is one that occurs at the base protocol level, and MAY require attention at each hop in a proxy environment (e.g. message routing error). Extension errors, on the other hand, are generally occur due to a problem with a function specified in a Diameter extension(e.g. user authentication, Missing AVP). Result-Code AVP values that are used to report protocol errors MUST be used in the Message-Reject-Answer command. Unlike most Diameter commands, the Message-Reject-Answer does not have a corresponding request. When a request message is received that causes a protocol error, the command code is changed to Message-Reject-Answer, and the Result-Code AVP is set to the appropriate protocol error value. As the answer is sent back towards the originator of the request, each proxy MAY take action on the message. Calhoun et al. expires October 2001 [Page 41] Internet-Draft May 2001 1. Request +---------+ Link Broken +-------------------------->|Diameter |----///----+ | +---------------------| | v +------+--+ | 2. MRA | Proxy 2 | +--------+ |Diameter |<-+ (Unable to Forward) +---------+ |Diameter| | | | Home | | Proxy 1 |--+ +---------+ | Server | +---------+ | 3. Request |Diameter | +--------+ +-------------------->| | ^ | Proxy 3 |-----------+ +---------+ Figure 1 - Example of Protocol Error causing MRA message Figure 1 provides an example of a message sent by a Diameter proxy towards a home server. When the message is received by Proxy 2, and it detects that it cannot forward the request to the home server, an MRA message is returned with the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER. Given that this error falls within the protocol error category, Proxy 1 would take special action, and given the error, attempt to route the message through its alternate proxy 3. +---------+ 1. Request +---------+ 2. Request +---------+ | Access |------------>|Diameter |------------>|Diameter | | | | | | Home | | Device |<------------| Proxy |<------------| Server | +---------+ 4. Answer +---------+ 3. Answer +---------+ (Missing AVP) (Missing AVP) Figure 2 - Example of Extension Error Answer message Figure 2 provides an example of a Diameter message that caused an extension error. When extension errors occur, the Diameter entity reporting the error clears the 'R' bit in the Command Flags, and adds the Result-Code AVP with the proper value. Extension errors do not require any proxy involvement, and therefore the message would be forwarded back to the originator of the request. There are certain Result-Code AVP extensions errors that require additional AVPs to be present in the answer, such as: - An unrecognized AVP is received with the 'M' bit (Mandatory bit) set, causes an answer to be sent with the Result-Code AVP set to DIAMETER_AVP_UNSUPPORTED, and the Failed-AVP AVP containing the offending AVP. - An AVP that is received with an unrecognized value causes an answer to be returned with the Result-Code AVP set to DIAMETER_INVALID_AVP_VALUE, with the Failed-AVP AVP containing the AVP causing the error. Calhoun et al. expires October 2001 [Page 42] Internet-Draft May 2001 - A command is received with an AVP that is ommitted, yet is mandatory according to the command's ABNF. The receiver issues an answer with the Result-Code set to DIAMETER_MISSING_AVP, and creates an AVP with the AVP Code and other fields set to the missing AVP's. The created AVP is then added to the Failed-AVP AVP. The Result-Code AVP contains additional errors conditions, and defines the expected behavior of each. 9.1 Result-Code AVP The Result-Code AVP (AVP Code 268) is of type Unsigned32 and indicates whether a particular request was completed successfully or whether an error occurred. All Diameter answer messages MUST include one Result-Code AVP. A non-successful Result-Code AVP (one containing a non 2xxx value) MUST include the Error-Reporting-Host AVP if the host setting the Result-Code AVP is different from the identity encoded in the Origin-Host AVP. The Result-Code data field contains an IANA-managed 32-bit address space representing errors (see section 16.4). Diameter provides the following classes of errors, all identified by the thousands digit: - 1xxx (Informational) - 2xxx (Success) - 3xxx (Protocol Errors) - 4xxx (Transient Failures) - 5xxx (Permanent Failure) A non-recognize class (one whose first digit is not defined in this section) MUST be handled as a permanent failure. 9.1.1 Informational Errors that fall within the Informational category are used to inform a requester that the request cannot be immediately satisfied and a further response will be issued in the near future. There are currently no errors that fall within this class. 9.1.2 Success Errors that fall within the Success category are used to inform a peer that a request has been successfully completed. DIAMETER_SUCCESS 2001 Calhoun et al. expires October 2001 [Page 43] Internet-Draft May 2001 The Request was successfully completed. 9.1.3 Protocol Errors Errors that fall within the Protocol Error category SHOULD be treated on a per-hop basis, and Diameter proxies MAY attempt to correct the error, if it is possible. Note that these errors MUST only be used in the Message-Rejected-Answer message, therefore a Diameter entity that wishes to return an error in this category MUST change the command code to Message-Rejected-Answer message. DIAMETER_INVALID_ROUTE_RECORD 3001 The last Route-Record AVP in the message is not set to the identity of the sender of the message. See Section 11.0 for more information. DIAMETER_COMMAND_UNSUPPORTED 3002 The Request contained a Command-Code that the receiver did not recognize or support. DIAMETER_UNABLE_TO_DELIVER 3003 The request could not be delivered to a host that handles the realm, and extension, requested at this time. DIAMETER_REALM_NOT_SERVED 3004 The intended realm of the offending message is unknown. DIAMETER_TOO_BUSY 3005 When returned, a Diameter node SHOULD attempt to sent the message to an alternate peer. DIAMETER_INVALID_CMS_DATA 3006 The Request did not contain a valid CMS-Data [11] AVP. DIAMETER_LOOP_DETECTED 3007 A Proxy or Redirect server detected a loop while trying to get the message to the Home Diameter server. The message MAY be sent to an alternate peer, if one is available, but the peer reporting the error has identified a configuration problem. DIAMETER_END_2_END_SECURITY 3008 A proxy has detected that end-to-end security has been applied to portions of the Diameter message, and the proxy does not allow this security mode since it needs to alter the message by applying some local policies. Calhoun et al. expires October 2001 [Page 44] Internet-Draft May 2001 9.1.4 Transient Failures Errors that fall within the transient failures category are used to inform a peer that the request could not be satisfied at the time it was received, but MAY be able to satisfy the request in the future. DIAMETER_AUTHENTICATION_REJECTED 4001 The authentication process for the user failed, most likely due to an invalid password used by the user. Further attempts MUST only be tried after prompting the user for a new password. DIAMETER_OUT_OF_SPACE 4002 A Diameter node received the accounting request but was unable to commit it to stable storage due to a temporary lack of space. 9.1.5 Permanent Failures Errors that fall within the permanent failures category are used to inform the peer that the request failed, and should not be attempted again. DIAMETER_USER_UNKNOWN 5001 A request was received for a user that is unknown, therefore authentication and/or authorization failed. DIAMETER_AVP_UNSUPPORTED 5002 The peer received a message that contained an AVP that is not recognized or supported and was marked with the Mandatory bit. A Diameter message with this error MUST contain one or more Failed-AVP AVP containing the AVPs that caused the failure. DIAMETER_UNKNOWN_SESSION_ID 5003 The request contained an unknown Session-Id. DIAMETER_AUTHORIZATION_REJECTED 5004 A request was received for which the user could not be authorized. This error could occur if the service requested is not permitted to the user. DIAMETER_INVALID_AVP_VALUE 5005 The request contained an AVP with an invalid value in its data portion. A Diameter message indicating this error MUST include the offending AVPs within a Failed-AVP AVP. DIAMETER_MISSING_AVP 5006 The request did not contain an AVP that is required by the Calhoun et al. expires October 2001 [Page 45] Internet-Draft May 2001 Command Code definition. If this value is sent in the Result- Code AVP, a Failed-AVP AVP SHOULD be included in the message. The data portion of the Failed-AVP MUST contain an AVP header containing the AVP Code and vendor-Id. DIAMETER_AUTHORIZATION_FAILED 5007 A request was received for which the user could not be authorized at this time. This error could occur when the user has already expended allowed resources, or is only permitted to access services within a time period. DIAMETER_CONTRADICTING_AVPS 5008 The Home Diameter server has detected AVPs in the request that contradicted each other, and is not willing to provide service to the user. One or more Failed-AVP AVPs MUST be present, containing the AVPs that contradicted each other. DIAMETER_AVP_NOT_ALLOWED 5009 A message was received with an AVP that MUST NOT be present. The Failed-AVP AVP MUST be included and contain the AVP Code of the offending AVP. DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5010 A message was received that included an AVP that appeared more often than permitted in the message definition. The Failed-AVP AVP MUST be included and contain the AVP Code of the offending AVP. DIAMETER_VENDOR_ID_UNSUPPORTED 5011 The Home Diameter server has detected vendor-specific AVPs in the message, and the vendor dictionary is not supported. One or more Failed-AVP MUST be present, containing the offending AVPs. DIAMETER_UNSUPPORTED_TRANSFORM 5012 A message was received that included an CMS-Data AVP [11] that made use of an unsupported transform. DIAMETER_NO_COMMON_EXTENSION 5013 This event is returned when a DRA message is received, and there are no common extensions supported between the peer. DIAMETER_UNSUPPORTED_VERSION 5014 This event is returned when a DRA message is received, and the Diameter message is unsupported. 9.2 Message-Reject-Answer Calhoun et al. expires October 2001 [Page 46] Internet-Draft May 2001 The Message-Reject-Answer (MRA), indicated by the Command-Code set to 282, and the Command Flags' 'R' bit cleared, is sent in response to a request that has caused a protocol error. Although the command code is different from the one found in the request, the same procedures used in issuing an answer message is followed. The Result-Code AVP MUST be present, and include a value in the "Protocol Error" category. Proxies receiving an MRA message MAY attempt to rectify the error reported, if possible. In the event that no proxy is able to correct the problem, the MRA will be returned to the originator of the request message. Message Format ::= < Diameter Header: 282, I > < Session-Id > { Origin-Host } { Origin-Realm } { Result-Code } { Destination-Host } * [ AVP ] 9.3 Error-Message AVP The Error-Message AVP (AVP Code 281) is of type OctetString. It is a human readable UTF-8 character encoded string. It MAY accompany a Result-Code AVP as a human readable error message. The Error-Message AVP is not intended to be useful in real-time, and SHOULD NOT be expected to be parsed by network entities. 9.4 Error-Reporting-Host AVP The Error-Reporting-Host AVP (AVP Code 294) is of type OctetString, encoded in the UTF-8 [24] format, according to the Diameter identity rules defined in section 2.6. This AVP contains the identity of the Diameter host that set the Result-Code AVP to a value other than 2001 (Success), only if the host setting the Result-Code is different from the one encoded in the Origin-Host AVP. This AVP is intended to be used for troubleshooting purposes, and MUST be set when the Result- Code AVP indicates a failure. 9.5 Failed-AVP AVP Calhoun et al. expires October 2001 [Page 47] Internet-Draft May 2001 The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides debugging information in cases where a request is rejected or not fully processed due to erroneous information in a specific AVP. The value of the Result-Code AVP will provide information on the reason for the Failed-AVP AVP. The possible reasons for this AVP are the presence of an improperly constructed AVP, an unsupported or unrecognized AVP, an invalid AVP value, the omission of a required AVP, the presence of an explicitly excluded AVP (see table 13.0), or the presence of two or more occurrences of an AVP which table 15.1 restricts to 0, 1, or 0-1 occurrences. A Diameter message MAY contain one Failed-AVP AVP, containing the entire AVP that could not be processed successfully. If the failure reason is omission of a required AVP, an AVP with the missing AVP code, the missing vendor id, and a zero filled payload of the minimum required length for the ommitted AVP will be added. AVP Format ::= < AVP Header: 279 > 1* {AVP} From owner-aaa-wg@merit.edu Tue Jun 12 09:46:35 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14941 for ; Tue, 12 Jun 2001 09:46:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 96114912C7; Tue, 12 Jun 2001 09:46:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 58B1B912C8; Tue, 12 Jun 2001 09:46:27 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C7317912C7 for ; Tue, 12 Jun 2001 09:46:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D4A575DDD5; Tue, 12 Jun 2001 09:46:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 303285DD8F for ; Tue, 12 Jun 2001 09:46:56 -0400 (EDT) Received: (qmail 24218 invoked by uid 500); 12 Jun 2001 13:35:58 -0000 Date: Tue, 12 Jun 2001 06:35:58 -0700 From: Pat Calhoun To: "Marta Morant-Artazkotz (ECE)" Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Proposed fixes for Issues 13, 18 and 30 Message-ID: <20010612063558.G17928@charizard.diameter.org> Mail-Followup-To: "Marta Morant-Artazkotz (ECE)" , Pat Calhoun , aaa-wg@merit.edu References: <577066326047D41180AC00508B955DDA051E3F9E@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <577066326047D41180AC00508B955DDA051E3F9E@eestqnt104.es.eu.ericsson.se>; from Marta.Morant-Artazkotz@ece.ericsson.se on Tue, Jun 12, 2001 at 11:05:58AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Jun 12, 2001 at 11:05:58AM +0200, Marta Morant-Artazkotz (ECE) wrote: > Hi all, > I am sorry about talking about this so late but I miss the old DSI-Event AVP value DIAMETER_REDIRECT_INDICATION (its value was 3001 in the draft -04) within the new Result-Code AVP values (the 3001 value means DIAMETER_INVALID_ROUTE_RECORD in the draft -05). Yes, this has been brought up, and will be in -06 :( PatC From owner-aaa-wg@merit.edu Tue Jun 12 09:54:52 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15124 for ; Tue, 12 Jun 2001 09:54:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C2516912C9; Tue, 12 Jun 2001 09:54:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 93D44912CA; Tue, 12 Jun 2001 09:54:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 77C1D912C9 for ; Tue, 12 Jun 2001 09:54:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8A82E5DDE6; Tue, 12 Jun 2001 09:55:26 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 35DB95DD8F for ; Tue, 12 Jun 2001 09:55:26 -0400 (EDT) Received: (qmail 24247 invoked by uid 500); 12 Jun 2001 13:44:27 -0000 Date: Tue, 12 Jun 2001 06:44:26 -0700 From: Pat Calhoun To: Jacques Caron Cc: "Martin Julien (ECE)" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: NASREQ Request-Type AVP??? Message-ID: <20010612064426.H17928@charizard.diameter.org> Mail-Followup-To: Jacques Caron , "Martin Julien (ECE)" , "'aaa-wg@merit.edu'" References: <577066326047D41180AC00508B955DDA04D1A991@eestqnt104.es.eu. ericsson.se> <4.3.2.7.2.20010611105046.00c493f0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010611105046.00c493f0@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Mon, Jun 11, 2001 at 10:55:43AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Jun 11, 2001 at 10:55:43AM +0200, Jacques Caron wrote: > At 10:36 11/06/01, Martin Julien (ECE) wrote: > >Hi, > > > >Looking at the NASREQ Request-Type AVP, I would appreciate if > >someone could give me his interpretation of the following > >possible values for the Request-Type AVP. > > > > >> > > AUTHENTICATE_ONLY 1 > > The request being sent is for authentication only, and MUST > > contain the relevant authentication AVPs that are needed by the > > Diameter server to authenticate the user. > ><< > > > >Since the specification says that it should not be permitted to > >authenticate-only a session, and then authorize-only the same session, > >I was wondering for what that value could really be useful? > >Should that Request-Type value be only used when answering a AA-Request > >Challenge? > > The nasreq draft indeed says in 3.1.1: > It is possible for a single session to be authorized only first, then > followed by an authentication request. However, the inverse SHOULD > NOT be permitted. $*@&!^@ I think that this sentence needs to be changed: If both authentication and authorization will be requested for a given session, the former SHOULD be done prior to the latter. It is still possible for authorization to be done without authentication. This covers: - Authentication first, followed by authorization (such as tacacs+) - authorize only (may I answer this phone call?) - authenticate only (well, I have no idea what you'd do this for :( PatC From owner-aaa-wg@merit.edu Tue Jun 12 10:09:42 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15632 for ; Tue, 12 Jun 2001 10:09:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 38AA8912CC; Tue, 12 Jun 2001 10:09:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0E35F912CE; Tue, 12 Jun 2001 10:09:46 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F06CF912CC for ; Tue, 12 Jun 2001 10:09:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 177335DDF0; Tue, 12 Jun 2001 10:10:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id BC9E65DDE6 for ; Tue, 12 Jun 2001 10:10:19 -0400 (EDT) Received: (qmail 24642 invoked by uid 500); 12 Jun 2001 13:57:28 -0000 Date: Tue, 12 Jun 2001 06:57:28 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 72: Downstream/upstream confusion Message-ID: <20010612065727.I17928@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Jacques, I've looked at the base protocol, and I cannot find any inconsistencies in the use of the terms downstream and upstream. In all cases, upstream implies towards the home server, and downstream is towards the access device. I have asked the list of folks think this needs to be changed, and there doesn't appear to be any consensus, so I am against changing it at this point. To me, something goes up before it goes down, so it seems logical to me that a request go up towards the home, and back down towards the access device. The only way this logic is broken is for unsolicited server-initiated messages, when things go down before they go up :( so looking at your proposed fixes. you seem to request that the terms be inversed, but your issue description implies that the terms are used inconsistently. Could you point to these areas, since a read through the document doesn't help me find them :( Thanks, PatC From owner-aaa-wg@merit.edu Tue Jun 12 10:21:25 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16095 for ; Tue, 12 Jun 2001 10:21:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3A480912CF; Tue, 12 Jun 2001 10:21:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 09BCA912D0; Tue, 12 Jun 2001 10:21:14 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EBFAB912CF for ; Tue, 12 Jun 2001 10:21:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 165165DDF0; Tue, 12 Jun 2001 10:21:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id B89B05DDE6 for ; Tue, 12 Jun 2001 10:21:48 -0400 (EDT) Received: (qmail 25464 invoked by uid 500); 12 Jun 2001 14:10:51 -0000 Date: Tue, 12 Jun 2001 07:10:51 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 53: What if the AAAL cannot reach the HA Message-ID: <20010612071051.K17928@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, I find the description of this particular issue somewhat misleading. I believe what is being requested here is the ability to NOT tie MIP so closely to Diameter, right? Here's what I mean. Currently the Diameter AMR includes the Registration Request, which is forwarded to the Home Agent in the HAR. The Home agent processes the embedded registration request, and replies with an HAA that includes the Registration Reply, and so on. What I believe this issue is asking for is the ability for the AMR to authenticate and authorize the user, and reply with an AMA. At that point, the FA can issue the Registration Request directly to the Home Agent. Of course, the reason why we had decided against this proposed in the beginning was because we wanted to reduce the number of round trips required to gain service, but there seems to be cases where this functionality is valuable. So, what I'd like to propose is a new success result code: DIAMETER_LIMITED_SUCCESS When returned, the request was successfully completed, but additional processing is required by the application in order to provide service to the user. and then in the Mobile IP application, we could add/change: An AMA message with the Result-Code AVP set to DIAMETER_SUCCESS MUST include the MIP-Home-Agent-Address, MIP-Home-Mobile-Node-Address and MIP-Reg-Reply AVPs. The MIP-Home-Agent-Address AVP contains the Home Agent assigned to the Mobile Node, while the MIP-Mobile-Node-Address AVP contains the home address that was assigned. An AMA message with the Result-Code AVP set to DIAMETER_LIMITED_SUCCESS MAY include the MIP-Home-Agent-Address AVP if a dynamically assigned home agent was requested by the mobile node. Upon receipt of this result code, the foreign agent MUST issue the Registration Request to the Home Agent in the manner described in [4]. Would this work? PatC From owner-aaa-wg@merit.edu Tue Jun 12 11:16:23 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17489 for ; Tue, 12 Jun 2001 11:16:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DFE9A912D2; Tue, 12 Jun 2001 11:15:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF748912D3; Tue, 12 Jun 2001 11:15:26 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4C77E912D2 for ; Tue, 12 Jun 2001 11:15:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6D0525DDAD; Tue, 12 Jun 2001 11:15:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (c000-h002.c000.snv.cp.net [209.228.32.66]) by segue.merit.edu (Postfix) with SMTP id CA9715DD9E for ; Tue, 12 Jun 2001 11:15:54 -0400 (EDT) Received: (cpmta 14939 invoked from network); 12 Jun 2001 08:15:27 -0700 Received: from h121s86a16n47.user.nortelnetworks.com (HELO mitton.mitton.com) (47.16.86.121) by smtp.mitton.com (209.228.32.66) with SMTP; 12 Jun 2001 08:15:27 -0700 X-Sent: 12 Jun 2001 15:15:27 GMT Message-Id: <4.3.2.7.2.20010612111245.00d53be0@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Jun 2001 11:17:52 -0400 To: Jonathan Wood , jacques_m_caron@yahoo.com From: David Mitton Subject: Re: [AAA-WG]: Support for multi-process Cc: aaa-wg@merit.edu In-Reply-To: <200106112109.OAA16863@heliopolis.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 6/11/01 02:09 PM -0700, Jonathan Wood wrote: > > > >I think there is some confusion here... There are two different issues > at hand: > >1. enable multiple processes to run on the same machine > >2. make sure there is only one connection between any two processes (or > >not, but that's another subjet) > > > >(1) requires that each process be assigned a distinct port or IP address. > >You cannot have two processes listening on port 1812. You could have one on > >1812 and one on 1813, for instance (don't know which other protocol I just > >bumped into...). > > > >(2) requires either: > >- the use of SCTP which apparently solves the problem magically (don't know > >how and why, haven't read the whole spec yet, but it was stated in some > >previous e-mail). > >- the use of TCP with a complex state machine to make sure we tear down one > >of the two connections if two are established at the same time > >- the use of TCP with the same port number of listening and accepting, as I > >described. > > > >I just checked the TCP spec on this (rfc793, section 3.4). >TCP and SCTP both handle the situation in the same way, i.e. >the two connections resolve into a single connection. > >Just to be absolutely clear: this only happens when the >two connections are identical. For example, host A has >IP address 192.168.100.100 and the local port 1812, and >host B has IP address 192.168.200.200 and local port 1812. >(Note that this means, in socket terms, both are listening >on port 1812.) Now A and B then both try to connect() to >each other from port 1812 to port 1812. These two connections >are indistinguishable to both TCP and SCTP, and so *must* >resolve into a single connection. > >If A or B had substitued any other port for their local >port (like a transient port), there would be two different >connections. > >So if you allow connecting from transient ports, then yes, >you need to hack up the state machine to close one of >the connections down. If you always connect from a well- >known port, TCP and SCTP will take care of it for you. There are no constraints on the value of the source port of the connection. It should be assumed to be an ephemeral port. The well-known port is in use for listening. A listening socket cannot make connections. This is how most TCP protocols work. Dave. ---------------------------------------------------- David Mitton 978-288-4570 Advisor, Nortel Networks david@mitton.com or dmitton@nortelnetworks.com From owner-aaa-wg@merit.edu Tue Jun 12 11:43:07 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17916 for ; Tue, 12 Jun 2001 11:43:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D3F61912D3; Tue, 12 Jun 2001 11:43:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A3627912D4; Tue, 12 Jun 2001 11:43:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7D2A4912D3 for ; Tue, 12 Jun 2001 11:43:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A7C6C5DDCC; Tue, 12 Jun 2001 11:43:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 8FC335DD9E for ; Tue, 12 Jun 2001 11:43:44 -0400 (EDT) Received: (qmail 28174 invoked by uid 500); 12 Jun 2001 15:32:45 -0000 Date: Tue, 12 Jun 2001 08:32:45 -0700 From: Pat Calhoun To: Mark Eklund , Jacques Caron , Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 70: Caching of redirects Message-ID: <20010612083245.L17928@charizard.diameter.org> Mail-Followup-To: Mark Eklund , Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <4.3.2.7.2.20010608190320.00d27260@pop.mail.yahoo.com> <20010608100626.K11643@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010608100626.K11643@charizard.diameter.org>; from pcalhoun@diameter.org on Fri, Jun 08, 2001 at 10:06:26AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Taking all of the comments on the list on this issue, I've come up with the following text. Comments appreciated, PatC ---- 5.10 Redirect-Host-Usage AVP The Redirect-Host-Usage AVP (AVP Code TBD) is of type Enumerated. This AVP MAY be present in Message-Reject-Answer messages that include the Result-Code AVP set to DIAMETER_REDIRECT_INDICATION. When present, this AVP dictates how the routing entry resulting from the MRA is to be used. The following values are supported: DONT_CACHE 0 The host specified in the Redirect-Host AVP should not be cached. This is the default value. ALL_REALM 1 All messages destined for the realm requested MAY be sent to the host specified in the Redirect-Host AVP. REALM_AND_APPLICATION 2 All messages for the application requested to the realm specified MAY be sent to the host specified in the Redirect- Host AVP. 5.11 Maximum-Redirect-Cache-Time AVP The Maximum-Redirect-Cache-Time AVP (AVP Code TBD) is of type Unsigned32. This AVP MUST be present in Message-Reject-Answer messages that include the Result-Code AVP set to DIAMETER_REDIRECT_INDICATION, and the Redirect-Host-Usage AVP set to a non-zero value. This AVP contains the maximum number of seconds the peer and route table entries, created as a result of the Redirect-Host, must be cached. From owner-aaa-wg@merit.edu Tue Jun 12 11:50:09 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18037 for ; Tue, 12 Jun 2001 11:50:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6C6D9912D4; Tue, 12 Jun 2001 11:50:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 31B42912D5; Tue, 12 Jun 2001 11:50:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 17B07912D4 for ; Tue, 12 Jun 2001 11:50:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 51D115DDAD; Tue, 12 Jun 2001 11:50:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id F2D815DD9E for ; Tue, 12 Jun 2001 11:50:37 -0400 (EDT) Received: (qmail 28196 invoked by uid 500); 12 Jun 2001 15:39:40 -0000 Date: Tue, 12 Jun 2001 08:39:40 -0700 From: Pat Calhoun To: Bernard Aboba Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 29: IPv6 AVPs Message-ID: <20010612083940.M17928@charizard.diameter.org> Mail-Followup-To: Bernard Aboba , Pat Calhoun , aaa-wg@merit.edu References: <20010605164453.R12278@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from aboba@internaut.com on Tue, Jun 05, 2001 at 11:43:47PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Jun 05, 2001 at 11:43:47PM -0700, Bernard Aboba wrote: > Actually, I think there are two more missing: Framed-IPv6-Pool and > Framed-Ipv6-Route. I'll have updated text for these later this week. Bernard, Here is the proposed text for the two new AVPs: 7.2.5.6 Framed-IPv6-Route AVP The Framed-IPv6-Route AVP (AVP Code TBD) is of type UTF8String, and contains the routing information to be configured for the user on the NAS. Zero or more such AVPs MAY be present in an authorization response. The string MUST contain an IPv6 address prefix followed by a slash and a decimal length specifier stating how many high order bits of the prefix should be used. That is followed by a space, a gateway address in hexadecimal notation, a space, and one or more metrics separated by spaces. For example: "2000:0:0:106::/64 2000::106:a00:20ff:fe99:a998 1". Whenever the gateway address is the IPv6 unspecified address the IP address of the user SHOULD be used as the gateway address, such as: "2000:0:0:106::/64 :: 1". 7.2.5.7 Framed-IPv6-Pool AVP The Framed-IP-Route AVP (AVP Code 22) is of type UTF8String, and contains the name of an assigned pool that SHOULD be used to assign an IPv6 prefix for the user. If the access device does not support multiple prefix pools, it SHOULD ignore this AVP. From owner-aaa-wg@merit.edu Tue Jun 12 11:51:37 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18083 for ; Tue, 12 Jun 2001 11:51:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 49C27912D5; Tue, 12 Jun 2001 11:51:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0F070912D6; Tue, 12 Jun 2001 11:51:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E9284912D5 for ; Tue, 12 Jun 2001 11:51:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 339CD5DDAD; Tue, 12 Jun 2001 11:52:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans-old.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 62F5D5DD9E for ; Tue, 12 Jun 2001 11:52:10 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA25352; Tue, 12 Jun 2001 11:50:59 -0400 (EDT) Date: Tue, 12 Jun 2001 11:51:25 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: Pat Calhoun Cc: Jacques Caron , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 70: Caching of redirects In-Reply-To: <20010612083245.L17928@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Pat, Looks good. One nit. On Tue, 12 Jun 2001, Pat Calhoun wrote: > Taking all of the comments on the list on this issue, I've come up with the > following text. > > Comments appreciated, > > PatC > ---- > > > 5.10 Redirect-Host-Usage AVP > > The Redirect-Host-Usage AVP (AVP Code TBD) is of type Enumerated. > This AVP MAY be present in Message-Reject-Answer messages that > include the Result-Code AVP set to DIAMETER_REDIRECT_INDICATION. > > When present, this AVP dictates how the routing entry resulting from > the MRA is to be used. The following values are supported: > > DONT_CACHE 0 > The host specified in the Redirect-Host AVP should not be > cached. This is the default value. > > ALL_REALM 1 > All messages destined for the realm requested MAY be sent to > the host specified in the Redirect-Host AVP. > > REALM_AND_APPLICATION 2 > All messages for the application requested to the realm > specified MAY be sent to the host specified in the Redirect- > Host AVP. > > > 5.11 Maximum-Redirect-Cache-Time AVP > > The Maximum-Redirect-Cache-Time AVP (AVP Code TBD) is of type > Unsigned32. This AVP MUST be present in Message-Reject-Answer > messages that include the Result-Code AVP set to > DIAMETER_REDIRECT_INDICATION, and the Redirect-Host-Usage AVP set to > a non-zero value. > > This AVP contains the maximum number of seconds the peer and route > table entries, created as a result of the Redirect-Host, must be > cached. Can we change the above "must" to a "will". -mark From owner-aaa-wg@merit.edu Tue Jun 12 12:23:02 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18626 for ; Tue, 12 Jun 2001 12:23:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 013B8912D9; Tue, 12 Jun 2001 12:21:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B4626912DC; Tue, 12 Jun 2001 12:21:56 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 613F6912D9 for ; Tue, 12 Jun 2001 12:21:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A5AD75DDEB; Tue, 12 Jun 2001 12:22:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 4FC345DDD4 for ; Tue, 12 Jun 2001 12:22:27 -0400 (EDT) Received: (qmail 28563 invoked by uid 500); 12 Jun 2001 16:11:29 -0000 Date: Tue, 12 Jun 2001 09:11:29 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 42: Session-Timeout inconsistent with RADIUS spec Message-ID: <20010612091129.O17928@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, The inconsistency identified was that RADIUS re-uses the Session-Timeout attribute in Access-Challenge messages to inform the access device how long it should wait for the user's response. In order to fix this issue, I propose adding the following text to the base protocol specification: 10.14 Multi-Round-Time-Out AVP The Multi-Round-Time-Out AVP (AVP Code TBD) is of type Unsigned32, and SHOULD be present in application-specific authorization answer messages whose Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH. This AVP contains the maximum number of seconds that the access device MUST provide the user in responding to an authentication request. And the following text to the protocol conversion section (9.x) in the NASREQ application specification. 9.1 RADIUS request forwarded as Diameter request [...] - If the Diameter Command-Code is set to AA-Answer and the Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH, the gateway must send a RADIUS Access-Challenge with the the Diameter Session-Id and the Origin-Host AVPs are saved in the RADIUS State attribute, with the prefix "Diameter/". This is necessary in order to ensure that the protocol gateway that will receive the subsequent RADIUS Access-Request will have access to the Session Identifier, and be able to set the Destination-Host to the correct value. If the Multi-Round-Time-Out AVP is present, the value of the AVP MUST be inserted in the RADIUS Session- Timeout AVP. [editor's note, new last sentence] 9.2 Diameter request forwarded as RADIUS request [...] - If the RADIUS code is set to Access-Challenge, a Diameter AA- Answer message is created with the Result-Code set to DIAMETER_MULTI_ROUND_AUTH. If the Session-Timeout AVP is present in the RADIUS message, its value is inserted in the Multi- Round-Time-Out AVP. [editor's note, new last sentence] Comments appreciated, PatC From owner-aaa-wg@merit.edu Tue Jun 12 12:37:22 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18938 for ; Tue, 12 Jun 2001 12:37:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D3D4B912DA; Tue, 12 Jun 2001 12:37:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9B1A0912DB; Tue, 12 Jun 2001 12:37:14 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4023A912DA for ; Tue, 12 Jun 2001 12:37:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 84C6B5DDCC; Tue, 12 Jun 2001 12:37:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 239F75DD9F for ; Tue, 12 Jun 2001 12:37:48 -0400 (EDT) Received: (qmail 28720 invoked by uid 500); 12 Jun 2001 16:26:50 -0000 Date: Tue, 12 Jun 2001 09:26:50 -0700 From: Pat Calhoun To: "Irene Martin Cabello (ECE)" Cc: "'Pat Calhoun'" , Tony Johansson , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 77: Possibility for implicit termination of an Authentication or Authorization session. Message-ID: <20010612092650.P17928@charizard.diameter.org> Mail-Followup-To: "Irene Martin Cabello (ECE)" , 'Pat Calhoun' , Tony Johansson , aaa-wg@merit.edu References: <577066326047D41180AC00508B955DDA04F5EFA3@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <577066326047D41180AC00508B955DDA04F5EFA3@eestqnt104.es.eu.ericsson.se>; from Irene.Martin-Cabello@ece.ericsson.se on Tue, Jun 12, 2001 at 10:43:42AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Jun 12, 2001 at 10:43:42AM +0200, Irene Martin Cabello (ECE) wrote: > In the Base Protocol (chapter 10.4, Authorization Lifetime) is writen: > "A value of zero means that no re-authorization is required". > I thought this value of zero was useful when AAA does not require a re-authentication > and/or re-authorization initiated from the access device, because the AAA will be in > charge of initiating it by means of sending an unsolicited AA-Answer message with the > Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH (former "AA-Challenge" message). I believe what is being said here is that applications that KNOW that servers do not maintain session state may not require the overhead of STR messages. These service would require a one-shot authorization and/or authentication request. Here is an example. An incoming call on a NAS generates an autorization request to the local server, on whether the call should be answered or not. If a successful answer is sent, the NAS answers the phone, and begins PPP, etc. If the existing state machine was used, the authorization request (may I answer the call?) would require an STR. So, without the change, we have the following: 1. Authorization Request 2. Authorization Answer 3. STR 4. STA 5. Authentication/Authorization (PPP) Request 6. Authentication/Authorization (PPP) Answer 7. STR 8. STA with the proposed fix, we would have: 1. Authorization Request 2. Authorization Answer 3. Authentication/Authorization (PPP) Request 4. Authentication/Authorization (PPP) Answer 5. STR 6. STA reducing the number of messages from 8 to 6, and this is just one such example. > > But, according to your proposal, the value of zero implies that no session information > will be stored in the AAA. Then my above assumption was wrong, but then my question is: > when could be useful for the AAA to send an unsolicited re-authentication and/or > re-authorization? I think always the access device must be in charge of requesting > a re-authentication and/or re-authorization, and the AAA MUST clean up resources when > the Authorization lifettime expires without re-authorization. I would claim that only stateful servers will ever issue re-auth messages towards the access device. So, if a request is received with an Authorization-Lifetime of zero (0), then the server can determine whether it is willing to accept this value or not. If it wishes to maintain state information, it could either return an error, or simply insert its own Authorization-Lifetime, which would cause the access device to send an STR when the session is complete. > > Also, I thought that when an "authentication only" request message is received in the > AAA, the AAA should validate the authentication but the AAA should not store any > session information since authorization is not requested. Is this wrong? No, this is true. > It would be very useful if it is clarified in NASREQ draft, when "authentication only" > and "authorization only" should be allowed/rejected. ok > Another question: when re-authorization is requested, the AAA should just extend the > "life" of the session and return the Authorization Lifetime in the AA-Answer message, > or should this message also include again the authorization AVPs provided in the > first AA-Answer message? I suspect it would make sense to send in a complete request, in case it hits a different Diameter server in the network. Thanks, PatC From owner-aaa-wg@merit.edu Tue Jun 12 12:38:24 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18975 for ; Tue, 12 Jun 2001 12:38:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 66751912DB; Tue, 12 Jun 2001 12:38:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3BF8C912DC; Tue, 12 Jun 2001 12:38:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C981B912DB for ; Tue, 12 Jun 2001 12:38:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1F1A45DD9F; Tue, 12 Jun 2001 12:38:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id 06F3D5DD9E for ; Tue, 12 Jun 2001 12:38:54 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.11.4/8.11.4) id f5CGaMi15805 for ; Tue, 12 Jun 2001 12:36:22 -0400 (EDT) X-Authentication-Warning: ahab.tic.siemens.ca: mail set sender to using -f Received: from mailman.innovation.siemens.ca(172.21.24.8) by ahab via smap (V2.1) id xma015801; Tue, 12 Jun 01 12:36:06 -0400 Received: (from mail@localhost) by mailman.innovation.siemens.ca (8.9.3/8.9.3) id MAA21176 for ; Tue, 12 Jun 2001 12:38:10 -0400 (EDT) Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1) id xma001263; Tue, 12 Jun 01 11:54:07 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Jun 2001 11:54:07 -0400 Message-ID: From: Balazs Czoma To: aaa-wg@merit.edu Subject: FW: [AAA-WG]: Issue 77: Possibility for implicit termination of an Authentication or Authorization session. Date: Tue, 12 Jun 2001 11:54:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk > -----Original Message----- > From: Irene Martin Cabello (ECE) > In the Base Protocol (chapter 10.4, Authorization Lifetime) > is writen: > "A value of zero means that no re-authorization is required". > I thought this value of zero was useful when AAA does not > require a re-authentication and/or re-authorization initiated > from the access device, because the AAA will be in charge of > initiating it by means of sending an unsolicited AA-Answer > message with the Result-Code AVP set to > DIAMETER_MULTI_ROUND_AUTH (former "AA-Challenge" message). > > But, according to your proposal, the value of zero implies > that no session information will be stored in the AAA. Then > my above assumption was wrong, but then my question is: when > could be useful for the AAA to send an unsolicited > re-authentication and/or re-authorization? I think always the > access device must be in charge of requesting a > re-authentication and/or re-authorization, and the AAA MUST > clean up resources when the Authorization lifettime expires > without re-authorization. I think there is a misunderstanding here: The server is the one who can tell if re-authorization is required. This last sentence in the draft chapter 10.4 should better be separated from the paragraph where the AVP provided by the client is discussed and stated that it is for the case when the server includes this AVP with zero value. If the client sends the AVP with zero value it can still have the meaning that was proposed by Tony which is a very useful idea for us too. Regards: Balazs ____________________________________________ Balazs Czoma Siemens Telecom Innovation Centre mailto:Balazs.Czoma@tic.siemens.ca ____________________________________________ From owner-aaa-wg@merit.edu Tue Jun 12 14:02:57 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21149 for ; Tue, 12 Jun 2001 14:02:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9C168912DE; Tue, 12 Jun 2001 14:02:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 676C3912DF; Tue, 12 Jun 2001 14:02:55 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4F781912DE for ; Tue, 12 Jun 2001 14:02:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B95EB5DDCE; Tue, 12 Jun 2001 14:03:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 679205DDCC for ; Tue, 12 Jun 2001 14:03:29 -0400 (EDT) Received: (qmail 31205 invoked by uid 500); 12 Jun 2001 17:52:31 -0000 Date: Tue, 12 Jun 2001 10:52:31 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 76: Destination-Realm & proxies/relays Message-ID: <20010612105231.X17928@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk In order to close issue 76, I'd like to propose the following text to replace what exists in section 3.0 in -05. Note that the change here is to add a new flag to the Diameter header, which is used to state that a message MAY be proxied. PatC ---- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R P r r r r r r| Command-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop-by-Hop Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End-to-End Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVPs ... +-+-+-+-+-+-+-+-+-+-+-+-+- Version This Version field MUST be set to 1 to indicate Diameter Version 1. Message Length The Message Length field is two octets and indicates the length of the Diameter message including the header fields. Command Flags The Command Flags field is eight bits. The following bits are assigned: R(equest) - If set, the message is a request. If cleared, the message is an answer. P(roxiable) - If set, the message MAY be proxied. If cleared, the message MUST be locally processed. r(eserved) - this flag bit is reserved for future use, and MUST be set to zero. I'd also have to remove the following sentence: 5.0 Diameter message processing [...] A message that MUST NOT be relayed, proxied or redirected MUST NOT include the Destination-Realm in its ABNF. [...] From owner-aaa-wg@merit.edu Tue Jun 12 15:43:45 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23288 for ; Tue, 12 Jun 2001 15:43:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 51776912E5; Tue, 12 Jun 2001 15:43:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1EEB4912E7; Tue, 12 Jun 2001 15:43:40 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ECD71912E5 for ; Tue, 12 Jun 2001 15:43:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7277A5DDF1; Tue, 12 Jun 2001 15:44:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id E86735DDF0 for ; Tue, 12 Jun 2001 15:44:13 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.11.4/8.11.4) id f5CJfec17662; Tue, 12 Jun 2001 15:41:40 -0400 (EDT) X-Authentication-Warning: ahab.tic.siemens.ca: mail set sender to using -f Received: from mailman.innovation.siemens.ca(172.21.24.8) by ahab via smap (V2.1) id xma017660; Tue, 12 Jun 01 15:41:34 -0400 Received: (from mail@localhost) by mailman.innovation.siemens.ca (8.9.3/8.9.3) id PAA20475; Tue, 12 Jun 2001 15:43:38 -0400 (EDT) Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1) id xma020386; Tue, 12 Jun 01 15:42:17 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Jun 2001 15:42:17 -0400 Message-ID: From: Yiwen Jiang To: "'Pat Calhoun'" Cc: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Issue 37: Home State Blob Date: Tue, 12 Jun 2001 15:42:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Pat, I went back to my minutes, and here it is about the home state blob... Sorry about the late response. 32. Home state blob need to be in the Diameter. PatC: Bernard said at least this must be supported in the Diameter: Allow the home return some state attribute. Paul: Not sure if we need to require NAS to keep state. It also has to do with reauthorizations, etc. If we allow re-auth to go to different home servers, we may allow the home server 1 to connect to home server 2 to pass information. PatC: So this is a new feature. Paul: Bring it as a question to the list. Hope this helps, Yiwen > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Tuesday, June 05, 2001 8:12 PM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Issue 37: Home State Blob > > > All, > > I am going through my notes, and I cannot figure out what > this issue was > all about. Since it was assigned to Paul, and I have yet to > receive any > text from Paul, I assume that either he also doesn't remember, or it > wasn't that important. > > Does anyone else that was at the interim meeting recall what > Issue 37 was > all about? > > PatC > From owner-aaa-wg@merit.edu Tue Jun 12 17:57:43 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25396 for ; Tue, 12 Jun 2001 17:57:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9A171912ED; Tue, 12 Jun 2001 17:57:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5EFFA912EF; Tue, 12 Jun 2001 17:57:39 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3AD5D912ED for ; Tue, 12 Jun 2001 17:57:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EE90C5DDCE; Tue, 12 Jun 2001 17:58:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by segue.merit.edu (Postfix) with ESMTP id 51B7C5DD8F for ; Tue, 12 Jun 2001 17:58:13 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (motgate4 2.1) with ESMTP id OAA18943 for ; Tue, 12 Jun 2001 14:57:45 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id OAA10989 for ; Tue, 12 Jun 2001 14:57:45 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 16:57:45 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECF36@IL27EXM10.cig.mot.com> From: Cain Brian-BCAIN1 To: "'David Mitton'" , Jonathan Wood , jacques_m_caron@yahoo.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Support for multi-process Date: Tue, 12 Jun 2001 16:54:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk > -----Original Message----- > From: David Mitton [mailto:david@mitton.com] ... > There are no constraints on the value of the source port of > the connection. > It should be assumed to be an ephemeral port. The well-known > port is in > use for listening. A listening socket cannot make connections. > > This is how most TCP protocols work. Okay, so it would seem that duplicate connections are not preventable, right? Or at least, not for the common denominator. So, given that, should we revert to Mark's latest offering for the state machine? (Or did I miss a "multiple transport connections are OK now" verdict?) Is my suggestion that implementations periodically check for duplicates unreasonable/difficult to implement/inefficient? -Brian From owner-aaa-wg@merit.edu Tue Jun 12 18:08:29 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25588 for ; Tue, 12 Jun 2001 18:08:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B1A09912F4; Tue, 12 Jun 2001 18:08:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3C91A912F5; Tue, 12 Jun 2001 18:08:31 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F2198912F4 for ; Tue, 12 Jun 2001 18:08:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B23645DDE2; Tue, 12 Jun 2001 18:09:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 6EA665DD8F for ; Tue, 12 Jun 2001 18:09:05 -0400 (EDT) Received: (qmail 7421 invoked by uid 500); 12 Jun 2001 21:58:06 -0000 Date: Tue, 12 Jun 2001 14:58:06 -0700 From: Pat Calhoun To: Jacques Caron Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Request & answer routing clarification Message-ID: <20010612145806.G17928@charizard.diameter.org> Mail-Followup-To: Jacques Caron , aaa-wg@merit.edu References: <4.3.2.7.2.20010611101130.00bfd900@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010611101130.00bfd900@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Mon, Jun 11, 2001 at 01:10:35PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Jun 11, 2001 at 01:10:35PM +0200, Jacques Caron wrote: [...] > It is necessary to clarify the use of Destination-Realm & Destination-Host > in Request routing. ok > If I finally got it right, Destination-Host is used only to target a > specific host within a number of servers serving a given realm. This is > achieved by sending to that host when said host is in the peer table, > otherwise Destination-Realm is used. When reading the draft, it looks like > it is used to talk directly from the client to the specified server. correct. > Requested change: > > Sorry, a bit long. The important changes are: > - added overview in 5.1, with 3 cases for Destination-Realm & Destination-Host > - added sections 5.1.1 & 5.1.2 about originated and sending a request > - separated request (5.1.x) and answer (5.2.x) processing & routing > - used "request" rather than message where it is needed to clarify things > - moved answer generation to 5.2 > - changed "domain" to "realm" in routing table > - added default routing table entry discussion ok. after finally going over your comments, I've pretty much accepted all of the changes, with some minor grammatical changes. Thanks, PatC From owner-aaa-wg@merit.edu Tue Jun 12 19:49:37 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26996 for ; Tue, 12 Jun 2001 19:49:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A087391208; Tue, 12 Jun 2001 19:49:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C6559120A; Tue, 12 Jun 2001 19:49:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 41A3391208 for ; Tue, 12 Jun 2001 19:49:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 18AB05DDE2; Tue, 12 Jun 2001 19:50:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id AC5B75DD8F for ; Tue, 12 Jun 2001 19:50:11 -0400 (EDT) Received: (qmail 14024 invoked by uid 500); 12 Jun 2001 23:34:00 -0000 Date: Tue, 12 Jun 2001 16:34:00 -0700 From: Pat Calhoun To: Cain Brian-BCAIN1 Cc: "'David Mitton'" , Jonathan Wood , jacques_m_caron@yahoo.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Support for multi-process Message-ID: <20010612163400.J17928@charizard.diameter.org> Mail-Followup-To: Cain Brian-BCAIN1 , 'David Mitton' , Jonathan Wood , jacques_m_caron@yahoo.com, aaa-wg@merit.edu References: <35DBB8B7AC89D4118E98009027B1009B0ECF36@IL27EXM10.cig.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B0ECF36@IL27EXM10.cig.mot.com>; from Brian.Cain@motorola.com on Tue, Jun 12, 2001 at 04:54:42PM -0500 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Jun 12, 2001 at 04:54:42PM -0500, Cain Brian-BCAIN1 wrote: > > -----Original Message----- > > From: David Mitton [mailto:david@mitton.com] > ... > > There are no constraints on the value of the source port of > > the connection. > > It should be assumed to be an ephemeral port. The well-known > > port is in > > use for listening. A listening socket cannot make connections. > > > > This is how most TCP protocols work. > > Okay, so it would seem that duplicate connections are not preventable, > right? Or at least, not for the common denominator. No, they are in fact preventable, by ensuring that the source port is NOT the same as the destination port. So, if we require that the connection NOT be established on the listening port, then we can ensure that both sides of the connection will create a separate connection. PatC From owner-aaa-wg@merit.edu Tue Jun 12 20:43:47 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27507 for ; Tue, 12 Jun 2001 20:43:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B928E9126E; Tue, 12 Jun 2001 20:43:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 785D9912F6; Tue, 12 Jun 2001 20:43:47 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 59EA39126E for ; Tue, 12 Jun 2001 20:43:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4FAFC5DDB7; Tue, 12 Jun 2001 20:44:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id C47FC5DD8F for ; Tue, 12 Jun 2001 20:44:21 -0400 (EDT) Received: (qmail 17176 invoked by uid 500); 13 Jun 2001 00:33:22 -0000 Date: Tue, 12 Jun 2001 17:33:22 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 67: How to deal with CER and CEA in the case of SCTP Message-ID: <20010612173322.P17928@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, Jonathan Wood's email confirmed that this problem exists also in TCP, and this issue stated that a fix must be implementated to allow the current state machine to work properly should a single connection be created as a result of two simultaneous connection requests with the same IP and port information. I would like to suggest that we fix this issue by stating that one cannot initiate a connection from the default Diameter listening port. This will ensure that processes that listen on the default port WILL NOT run into this problem, and no changes would be required on the state machine. Comments? PatC From owner-aaa-wg@merit.edu Tue Jun 12 23:26:24 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00782 for ; Tue, 12 Jun 2001 23:26:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 870C79120F; Tue, 12 Jun 2001 23:26:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 570E0912FC; Tue, 12 Jun 2001 23:26:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3A7CC9120F for ; Tue, 12 Jun 2001 23:26:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 57B0B5DDE5; Tue, 12 Jun 2001 23:26:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id BE3A55DDB5 for ; Tue, 12 Jun 2001 23:26:54 -0400 (EDT) Received: from gwzpc (rtp-dial-1-70.cisco.com [10.83.97.70]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id UAA22779; Tue, 12 Jun 2001 20:24:03 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Jari Arkko" , "Bernard Aboba" , "Pat Calhoun" Cc: Subject: RE: [AAA-WG]: Issue 59: e2e mandatory status Date: Tue, 12 Jun 2001 20:24:05 -0700 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) Importance: Normal In-Reply-To: <00fe01c0f2ae$37a27980$8a1b6e0a@arenanet.fi> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jari Arkko [mailto:jari.arkko@kolumbus.fi] writes: > > The interesting question is whether NASes MUST implement e2e > > security. This seems somewhat too harsh to me, because some are quite > > modest devices (e.g. Access Points selling for $250). Also, it is likely > > that proxies will frequently be the endpoint for e2e, not NASes, purely > > for the purpose of manageability (don't have to put certs on every NAS, > > etc.). So this might be a SHOULD. > > I support SHOULD. I have no big problem with this, as long as there is a discussion of the risks involved in relying upon an intermediary for "end-to-end" security placed in (at least) the Security Considerations" section. > > Jari > > > > From owner-aaa-wg@merit.edu Wed Jun 13 03:39:42 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17097 for ; Wed, 13 Jun 2001 03:39:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A3F9191210; Wed, 13 Jun 2001 03:39:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6DD73912FC; Wed, 13 Jun 2001 03:39:46 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 145D091210 for ; Wed, 13 Jun 2001 03:39:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 674C55DDB6; Wed, 13 Jun 2001 03:40:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115]) by segue.merit.edu (Postfix) with SMTP id D29CF5DDB5 for ; Wed, 13 Jun 2001 03:40:20 -0400 (EDT) Received: from pc114.etc.psi.com (HELO jc.yahoo.com) (195.94.40.114) by smtp.mail.vip.sc5.yahoo.com with SMTP; 13 Jun 2001 07:39:52 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010612201407.00bf8120@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Jun 2001 20:23:54 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 72: Downstream/upstream confusion Cc: aaa-wg@merit.edu In-Reply-To: <20010612065727.I17928@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Pat, Not sure I agree with the definition of up/downstream. For me the fact that we define that as "upstream" and "downstream" rather than "up" or "down" is a reference to a flow (like a river). And such flow normally goes from upstream to downstream (the terms are used in reference to the direction of "normal" requests). But the important thing is that everything is consistent. If you don't want to change the definitions for up/downstream, change the following: In 6.1 Application Identifiers: Diameter relay and proxy agents are responsible for finding a downstream server that supports the application of a particular message. If none can be found, a MRA message is returned with the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER. Should be upstream, then. And in 10.10 Inferring Session Termination from Origin-State-Id: When a Diameter server receives a Origin-State-Id that is greater than the Origin-State-Id previously received from the same issuer, it may assume that the issuer has lost state since the previous message and that all sessions that were active under the lower Origin-State- Id have been terminated. The Diameter server MAY clean up all session state associated with such lost sessions, and MAY also issues STRs for all such lost sessions that were authorized on downstream servers, to allow session state to be cleaned up globally. Should be upstream too, then. Jacques. At 15:57 12/06/01, Pat Calhoun wrote: >Jacques, > >I've looked at the base protocol, and I cannot find any inconsistencies in >the use of >the terms downstream and upstream. In all cases, upstream implies towards >the home >server, and downstream is towards the access device. > >I have asked the list of folks think this needs to be changed, and there >doesn't appear >to be any consensus, so I am against changing it at this point. > >To me, something goes up before it goes down, so it seems logical to me >that a request >go up towards the home, and back down towards the access device. The only >way this logic >is broken is for unsolicited server-initiated messages, when things go >down before they >go up :( > >so looking at your proposed fixes. you seem to request that the terms be >inversed, >but your issue description implies that the terms are used inconsistently. >Could >you point to these areas, since a read through the document doesn't help >me find >them :( > >Thanks, > >PatC _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Wed Jun 13 03:40:12 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17127 for ; Wed, 13 Jun 2001 03:40:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B29E7912FC; Wed, 13 Jun 2001 03:39:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 75BF1912FE; Wed, 13 Jun 2001 03:39:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3FFB3912FC for ; Wed, 13 Jun 2001 03:39:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B949B5DDB6; Wed, 13 Jun 2001 03:40:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115]) by segue.merit.edu (Postfix) with SMTP id 3ACEE5DDB5 for ; Wed, 13 Jun 2001 03:40:24 -0400 (EDT) Received: from pc114.etc.psi.com (HELO jc.yahoo.com) (195.94.40.114) by smtp.mail.vip.sc5.yahoo.com with SMTP; 13 Jun 2001 07:39:56 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010612202723.00bd1850@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Jun 2001 20:40:26 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 70: Caching of redirects Cc: Mark Eklund , Pat Calhoun , aaa-wg@merit.edu In-Reply-To: <20010612083245.L17928@charizard.diameter.org> References: <20010608100626.K11643@charizard.diameter.org> <4.3.2.7.2.20010608190320.00d27260@pop.mail.yahoo.com> <20010608100626.K11643@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Pat, Please see comments inline. At 17:32 12/06/01, Pat Calhoun wrote: >5.10 Redirect-Host-Usage AVP > > The Redirect-Host-Usage AVP (AVP Code TBD) is of type Enumerated. > This AVP MAY be present in Message-Reject-Answer messages that > include the Result-Code AVP set to DIAMETER_REDIRECT_INDICATION. > > When present, this AVP dictates how the routing entry resulting from > the MRA is to be used. The following values are supported: When present, this AVP dictates how the routing entry resulting from the MRA is to be cached for use in subsequent related requests. The following values are supported: > DONT_CACHE 0 > The host specified in the Redirect-Host AVP should not be > cached. This is the default value. ALL_SESSION 1 All messages within the same session, as defined by the same value of the Session-ID AVP MAY be sent to the host specified in the Redirect-Host AVP. [...though I should probably read whatever is the current state of discussion on Session-ID and Multi-Session-ID... Please fix as deemed appropriate] [shift the following two by one] > ALL_REALM 1 > All messages destined for the realm requested MAY be sent to > the host specified in the Redirect-Host AVP. > > REALM_AND_APPLICATION 2 > All messages for the application requested to the realm > specified MAY be sent to the host specified in the Redirect- > Host AVP. ALL_APPLICATION 4 All messages for the application requested MAY be sent to the host specified in the Redirect-Host AVP. [don't know what it would be used for, but it just seems logical to have] ALL_HOST 5 All messages that would be sent to the host that generated the MRA MAY be sent to the host specified in the Redirect-Host AVP. [Might be useful when a given server is about to be shut down for maintenance, for instance] An alternative way of doing things would be to have an AVP that would list a set of AVP codes that must match with the current one's to be sent to the same host. More complex, but way more tailorable to everybody's needs. >5.11 Maximum-Redirect-Cache-Time AVP > > The Maximum-Redirect-Cache-Time AVP (AVP Code TBD) is of type > Unsigned32. This AVP MUST be present in Message-Reject-Answer > messages that include the Result-Code AVP set to > DIAMETER_REDIRECT_INDICATION, and the Redirect-Host-Usage AVP set to > a non-zero value. Could change MUST to may, and then make cache expiration a purely local decision? > This AVP contains the maximum number of seconds the peer and route > table entries, created as a result of the Redirect-Host, must be > cached. must -> can/is allowed to? Probably also need to add something somewhere that states that all cache entries that send to a given host should be expired right away if the connection to said host goes down? Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Wed Jun 13 04:29:04 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17485 for ; Wed, 13 Jun 2001 04:29:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4A2CD912FE; Wed, 13 Jun 2001 04:29:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1BA1B912FF; Wed, 13 Jun 2001 04:29:00 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 07C05912FE for ; Wed, 13 Jun 2001 04:28:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6EC4F5DDF0; Wed, 13 Jun 2001 04:29:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id B7F835DDB5 for ; Wed, 13 Jun 2001 04:29:34 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f5D8TIb16384 for ; Wed, 13 Jun 2001 11:29:18 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 13 Jun 2001 11:28:57 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Wed, 13 Jun 2001 11:28:58 +0300 Message-ID: From: jaakko.rajaniemi@nokia.com To: pcalhoun@diameter.org, tony.johansson@ericsson.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 77: Possibility for implicit termination of an Authentication or Authorization session. Date: Wed, 13 Jun 2001 11:28:52 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, I also find this useful. A clarifying question still, is this only applicable for the case where the access device has set the Authorization-Lifetime to zero in the first authentication/authorization request or is it possible for a server to implicitely terminate any ongoing session by setting the Authorization-Lifetime to zero even without any hint from the access device? I assume that it is the first case. Correct? Br, Jaakko > -----Original Message----- > From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: 12 June, 2001 3:48 > To: Tony Johansson > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Issue 77: Possibility for implicit > termination of > an Authentication or Authorization session. > > > Tony, > > This works for me, and including a zero > Authorization-Lifetime is a great way > for an access device to signal that it doesn't expect to send > additional messages to > the home server. Of course, I *think* that some issues MAY > arise if the home server > decides that it wishes to maintain state, so a Result-Code > value must also be > created to allow the server to reject specifically this > request (as opposed to some > complicated Failed-AVP processing. > > Anyone object to this reasonable request? I can think of > quite a few uses. > > PatC > On Mon, Jun 11, 2001 at 04:45:12PM -0700, Tony Johansson wrote: > > All, > > > > Here is a new issue. > > > > /Tony > > > > Issue 77: Possibility for implicit termination of an > Authentication or > > Authorization session. > > Submitter name: Tony Johansson > > Submitter email address: tony.johansson@ericsson.com > > Date first submitted: 2001-06-11 > > Reference: > > Document: Base > > Comment type: T > > Priority: 1 > > Section: 10 > > Rationale/Explanation of issue: > > There may be cases where you don't need to store any > session information > > in the AAA. For example, there may be cases where the > access device will > > handle all seesion information. Thus, an access device may request > > authentication as a one time thing and no further messages would be > > needed between the access device and the AAA. > > > > Proposal: > > Perhaps a request from the access device SHOULD allow the > > Authorization-Lifetime (as a hint to the server). A value of zero > > implies that no state should be created, and no STR will be sent. A > > value of zero is a one-shot thing (auth once, never hear > from me again). > > > From owner-aaa-wg@merit.edu Wed Jun 13 09:45:13 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22969 for ; Wed, 13 Jun 2001 09:45:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C8FDC91212; Wed, 13 Jun 2001 09:45:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4780391301; Wed, 13 Jun 2001 09:45:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AD38591212 for ; Wed, 13 Jun 2001 09:45:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9A5A15DDBF; Wed, 13 Jun 2001 09:45:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by segue.merit.edu (Postfix) with SMTP id 4F1A65DD9B for ; Wed, 13 Jun 2001 09:45:45 -0400 (EDT) Received: from pc114.etc.psi.com (HELO jc.yahoo.com) (195.94.40.114) by smtp.mail.vip.sc5.yahoo.com with SMTP; 13 Jun 2001 13:45:17 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010613145722.00c065e0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 13 Jun 2001 15:42:34 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Support for multi-process Cc: Cain Brian-BCAIN1 , "'David Mitton'" , Jonathan Wood , aaa-wg@merit.edu In-Reply-To: <20010612163400.J17928@charizard.diameter.org> References: <35DBB8B7AC89D4118E98009027B1009B0ECF36@IL27EXM10.cig.mot.com> <35DBB8B7AC89D4118E98009027B1009B0ECF36@IL27EXM10.cig.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 01:34 13/06/01, Pat Calhoun wrote: >No, they are in fact preventable, by ensuring that the source port is NOT >the same as the destination port. So, if we require that the connection NOT >be established on the listening port, then we can ensure that both sides of >the connection will create a separate connection. Isn't that exactly what we're trying to avoid? Getting completely lost here :-( Please select the right one: 1. We want to make sure there is never more than one active connection between any two processes 2. We don't care if there are multiple active connections between any two processes 3. The problem is something completely different? As I understand it, we want (1) and the original problem was that the state machine uses/used IP addresses to detect duplicate connections. Just make it use the remote host identity (Host descriptor) received in the CER/CEA (the Host descriptor MUST be always the same for a given process). Don't know if that affects the state machine or not, though. BTW, I'm not sure we need such a complex state machine. Connecting to a peer and receiving a connection from a peer should be two totally distinct state machines (pretty basic in operation, one is: connect, send CER, wait for CEA, and the other is accept, wait for CER, send CEA -- plus of course error handling at all intermediate steps). Just add that upon receipt of the remote's Host descriptor (in a CEA in the first case, in the CER in the other), it should be compared against those we already have a connection to, and if there is a match, the connection established by the peer with the lexically greater host descriptor has to be shut down). I would add that having a single state machine for both is quite hard: how do you know a connection you receive actually goes into the same state machine as one you initiated until you received the Host descriptor? Another option (now that we ruled out the "use same port for listening and connecting" because socket implementations are just too dumb and don't accept a perfectly legitimate TCP case) would be to have each server establish an outgoing connection, and use that one for sending, while still listening on both. Stupid waste of resources (sockets/file descriptors...) though. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Wed Jun 13 09:54:04 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23206 for ; Wed, 13 Jun 2001 09:54:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 69ADE91303; Wed, 13 Jun 2001 09:54:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 32E8F91304; Wed, 13 Jun 2001 09:54:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DC6BA91303 for ; Wed, 13 Jun 2001 09:53:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BDC195DDBF; Wed, 13 Jun 2001 09:54:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 546285DD9B for ; Wed, 13 Jun 2001 09:54:36 -0400 (EDT) Received: (qmail 25163 invoked by uid 500); 13 Jun 2001 13:43:33 -0000 Date: Wed, 13 Jun 2001 06:43:33 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , Cain Brian-BCAIN1 , "'David Mitton'" , Jonathan Wood , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Support for multi-process Message-ID: <20010613064333.V17928@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , Cain Brian-BCAIN1 , 'David Mitton' , Jonathan Wood , aaa-wg@merit.edu References: <35DBB8B7AC89D4118E98009027B1009B0ECF36@IL27EXM10.cig.mot.com> <35DBB8B7AC89D4118E98009027B1009B0ECF36@IL27EXM10.cig.mot.com> <20010612163400.J17928@charizard.diameter.org> <4.3.2.7.2.20010613145722.00c065e0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010613145722.00c065e0@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Wed, Jun 13, 2001 at 03:42:34PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Jun 13, 2001 at 03:42:34PM +0200, Jacques Caron wrote: > At 01:34 13/06/01, Pat Calhoun wrote: > >No, they are in fact preventable, by ensuring that the source port is NOT > >the same as the destination port. So, if we require that the connection NOT > >be established on the listening port, then we can ensure that both sides of > >the connection will create a separate connection. > > Isn't that exactly what we're trying to avoid? We do want to avoid multiple connections, but we have identified that if all of the ports are the same, both sides will think that they've setup the connection, and this would either require: 1. additional massive state machine complications 2. change of CER/CEA message back to an indication-like message, or 3. Require that both sides issue CER, and CEA is just an ack and contains no capabilities. > Please select the right one: > > 1. We want to make sure there is never more than one active connection > between any two processes > 2. We don't care if there are multiple active connections between any two > processes > 3. The problem is something completely different? We want a single connection, and we want to be able to identify when multiple connections are active so we can close them. This is a separate issue from what I was talking about. > > As I understand it, we want (1) and the original problem was that the state > machine uses/used IP addresses to detect duplicate connections. Just make > it use the remote host identity (Host descriptor) received in the CER/CEA > (the Host descriptor MUST be always the same for a given process). Don't > know if that affects the state machine or not, though. According to Paul, the changes should be minimal. > > BTW, I'm not sure we need such a complex state machine. Connecting to a > peer and receiving a connection from a peer should be two totally distinct > state machines (pretty basic in operation, one is: connect, send CER, wait > for CEA, and the other is accept, wait for CER, send CEA -- plus of course > error handling at all intermediate steps). Just add that upon receipt of > the remote's Host descriptor (in a CEA in the first case, in the CER in the > other), it should be compared against those we already have a connection > to, and if there is a match, the connection established by the peer with > the lexically greater host descriptor has to be shut down). but you need to handle the cases where unexpected events occur while in intermediate (non-open) states. That's where the complexity occurs. I agree that we could simplify the SM by allowing all connections to move towards the open state, and close it when it reaches that point. That would reduce the number of interim states that need to check for existing connections, but you could *still* get into a race condition :( > > I would add that having a single state machine for both is quite hard: how > do you know a connection you receive actually goes into the same state > machine as one you initiated until you received the Host descriptor? well, either you initiate the connection, or you don't. It doesn't seem that hard to me :( > > Another option (now that we ruled out the "use same port for listening and > connecting" because socket implementations are just too dumb and don't > accept a perfectly legitimate TCP case) would be to have each server > establish an outgoing connection, and use that one for sending, while still > listening on both. Stupid waste of resources (sockets/file descriptors...) > though. I'd prefer a good solid state machine. Let's be honest here. I wrote the state machine in -05 is less than a day. This isn't black magic, or rocket science :) PatC From owner-aaa-wg@merit.edu Wed Jun 13 10:02:34 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23334 for ; Wed, 13 Jun 2001 10:02:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 933B691306; Wed, 13 Jun 2001 10:02:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 05D5B91308; Wed, 13 Jun 2001 10:02:34 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1ECE791305 for ; Wed, 13 Jun 2001 10:02:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1D7A85DD9B; Wed, 13 Jun 2001 10:03:00 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 8B8525DD8C for ; Wed, 13 Jun 2001 10:02:59 -0400 (EDT) Received: (qmail 25227 invoked by uid 500); 13 Jun 2001 13:51:57 -0000 Date: Wed, 13 Jun 2001 06:51:57 -0700 From: Pat Calhoun To: jaakko.rajaniemi@nokia.com Cc: pcalhoun@diameter.org, tony.johansson@ericsson.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 77: Possibility for implicit termination of an Authentication or Authorization session. Message-ID: <20010613065157.W17928@charizard.diameter.org> Mail-Followup-To: jaakko.rajaniemi@nokia.com, pcalhoun@diameter.org, tony.johansson@ericsson.com, aaa-wg@merit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jaakko.rajaniemi@nokia.com on Wed, Jun 13, 2001 at 11:28:52AM +0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Jun 13, 2001 at 11:28:52AM +0300, jaakko.rajaniemi@nokia.com wrote: > Hi, > > I also find this useful. A clarifying question still, is this only > applicable for the case where the access device has set the > Authorization-Lifetime to zero in the first authentication/authorization > request or is it possible for a server to implicitely terminate any ongoing > session by setting the Authorization-Lifetime to zero even without any hint > from the access device? I assume that it is the first case. Correct? Correct, and of course, the text would have the explicitely state this. Thanks for pointing this out, PatC > > Br, Jaakko > > > -----Original Message----- > > From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] > > Sent: 12 June, 2001 3:48 > > To: Tony Johansson > > Cc: aaa-wg@merit.edu > > Subject: Re: [AAA-WG]: Issue 77: Possibility for implicit > > termination of > > an Authentication or Authorization session. > > > > > > Tony, > > > > This works for me, and including a zero > > Authorization-Lifetime is a great way > > for an access device to signal that it doesn't expect to send > > additional messages to > > the home server. Of course, I *think* that some issues MAY > > arise if the home server > > decides that it wishes to maintain state, so a Result-Code > > value must also be > > created to allow the server to reject specifically this > > request (as opposed to some > > complicated Failed-AVP processing. > > > > Anyone object to this reasonable request? I can think of > > quite a few uses. > > > > PatC > > On Mon, Jun 11, 2001 at 04:45:12PM -0700, Tony Johansson wrote: > > > All, > > > > > > Here is a new issue. > > > > > > /Tony > > > > > > Issue 77: Possibility for implicit termination of an > > Authentication or > > > Authorization session. > > > Submitter name: Tony Johansson > > > Submitter email address: tony.johansson@ericsson.com > > > Date first submitted: 2001-06-11 > > > Reference: > > > Document: Base > > > Comment type: T > > > Priority: 1 > > > Section: 10 > > > Rationale/Explanation of issue: > > > There may be cases where you don't need to store any > > session information > > > in the AAA. For example, there may be cases where the > > access device will > > > handle all seesion information. Thus, an access device may request > > > authentication as a one time thing and no further messages would be > > > needed between the access device and the AAA. > > > > > > Proposal: > > > Perhaps a request from the access device SHOULD allow the > > > Authorization-Lifetime (as a hint to the server). A value of zero > > > implies that no state should be created, and no STR will be sent. A > > > value of zero is a one-shot thing (auth once, never hear > > from me again). > > > > > From owner-aaa-wg@merit.edu Wed Jun 13 10:33:45 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24022 for ; Wed, 13 Jun 2001 10:33:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 172F091308; Wed, 13 Jun 2001 10:33:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D27E59130A; Wed, 13 Jun 2001 10:33:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4AFF091308 for ; Wed, 13 Jun 2001 10:33:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5B6715DDF3; Wed, 13 Jun 2001 10:33:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 156D75DDB6 for ; Wed, 13 Jun 2001 10:33:54 -0400 (EDT) Received: (qmail 26788 invoked by uid 500); 13 Jun 2001 14:20:12 -0000 Date: Wed, 13 Jun 2001 07:20:12 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 72: Downstream/upstream confusion Message-ID: <20010613072012.Y17928@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <20010612065727.I17928@charizard.diameter.org> <4.3.2.7.2.20010612201407.00bf8120@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010612201407.00bf8120@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Tue, Jun 12, 2001 at 08:23:54PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Jun 12, 2001 at 08:23:54PM +0200, Jacques Caron wrote: > Not sure I agree with the definition of up/downstream. For me the fact that > we define that as "upstream" and "downstream" rather than "up" or "down" is > a reference to a flow (like a river). And such flow normally goes from > upstream to downstream (the terms are used in reference to the direction of > "normal" requests). We appear to be saying the same thing. Things do upstream, and then downstream. > > But the important thing is that everything is consistent. agreed. > If you don't want > to change the definitions for up/downstream, change the following: > > In 6.1 Application Identifiers: > > Diameter relay and proxy agents are responsible for finding a > downstream server that supports the application of a particular > message. If none can be found, a MRA message is returned with the > Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER. > > Should be upstream, then. correct. > > And in 10.10 Inferring Session Termination from Origin-State-Id: > > When a Diameter server receives a Origin-State-Id that is greater > than the Origin-State-Id previously received from the same issuer, it > may assume that the issuer has lost state since the previous message > and that all sessions that were active under the lower Origin-State- > Id have been terminated. The Diameter server MAY clean up all session > state associated with such lost sessions, and MAY also issues STRs > for all such lost sessions that were authorized on downstream > servers, to allow session state to be cleaned up globally. > > Should be upstream too, then. hmmmm.... this text comes from Paul, and I missed the problem here. First of all, this text implies that the server initiates an STR, when this is typically done by the access device. So, perhaps ASR is what was meant here. In which case downstream would be correct, but not "downstream servers", and instead "downstream clients". Paul?!? PatC From owner-aaa-wg@merit.edu Wed Jun 13 10:56:23 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24432 for ; Wed, 13 Jun 2001 10:56:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6E8AA91217; Wed, 13 Jun 2001 10:56:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 324A9912EB; Wed, 13 Jun 2001 10:56:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C6DC991217 for ; Wed, 13 Jun 2001 10:56:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BDB435DDB1; Wed, 13 Jun 2001 10:56:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by segue.merit.edu (Postfix) with SMTP id 3D4B85DD9B for ; Wed, 13 Jun 2001 10:56:58 -0400 (EDT) Received: from pc114.etc.psi.com (HELO jc.yahoo.com) (195.94.40.114) by smtp.mail.vip.sc5.yahoo.com with SMTP; 13 Jun 2001 14:56:26 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010613155901.00c11670@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 13 Jun 2001 16:55:57 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Support for multi-process Cc: Pat Calhoun , Cain Brian-BCAIN1 , "'David Mitton'" , Jonathan Wood , aaa-wg@merit.edu In-Reply-To: <20010613064333.V17928@charizard.diameter.org> References: <4.3.2.7.2.20010613145722.00c065e0@pop.mail.yahoo.com> <35DBB8B7AC89D4118E98009027B1009B0ECF36@IL27EXM10.cig.mot.com> <35DBB8B7AC89D4118E98009027B1009B0ECF36@IL27EXM10.cig.mot.com> <20010612163400.J17928@charizard.diameter.org> <4.3.2.7.2.20010613145722.00c065e0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 15:43 13/06/01, Pat Calhoun wrote: >On Wed, Jun 13, 2001 at 03:42:34PM +0200, Jacques Caron wrote: > > At 01:34 13/06/01, Pat Calhoun wrote: > > >No, they are in fact preventable, by ensuring that the source port is NOT > > >the same as the destination port. So, if we require that the > connection NOT > > >be established on the listening port, then we can ensure that both > sides of > > >the connection will create a separate connection. > > > > Isn't that exactly what we're trying to avoid? > >We do want to avoid multiple connections, but we have identified that if all >of the ports are the same, both sides will think that they've setup the >connection If you're referring to using the same port for listening and connecting, then the issue is mostly that most socket implementations just don't allow that. If they allowed it (as BSD stacks do with SO_REUSEPORT), then there could be only a single connection established, which would solve the problem. > > BTW, I'm not sure we need such a complex state machine. Connecting to a > > peer and receiving a connection from a peer should be two totally distinct > > state machines (pretty basic in operation, one is: connect, send CER, wait > > for CEA, and the other is accept, wait for CER, send CEA -- plus of course > > error handling at all intermediate steps). Just add that upon receipt of > > the remote's Host descriptor (in a CEA in the first case, in the CER in > the > > other), it should be compared against those we already have a connection > > to, and if there is a match, the connection established by the peer with > > the lexically greater host descriptor has to be shut down). > >but you need to handle the cases where unexpected events occur while in >intermediate (non-open) states. That's where the complexity occurs. I agree >that we could simplify the SM by allowing all connections to move towards the >open state, and close it when it reaches that point. That would reduce the >number of interim states that need to check for existing connections, but >you could *still* get into a race condition :( At any time you have an error (connect fails, timeout waiting for CER, connection dropped), shutdown the connection and go back to closed state. Still need some mechanism to introduce a delay before the next retry, though, not sure that's present anywhere in the current state machine or elsewhere in the draft? > > I would add that having a single state machine for both is quite hard: how > > do you know a connection you receive actually goes into the same state > > machine as one you initiated until you received the Host descriptor? > >well, either you initiate the connection, or you don't. It doesn't seem >that hard to me :( I meant to identify a connection that you receive as being associated to the same peer as one you already started establishing. Imagine host A has processes A1 and A2, and host B has process B1. B1 initiates a call to A1 and is somewhere in the state machine. A2 initiates a call to B1. How does B1 know this is a connection from A2 (which would be a R-Rcv-Conn-Req in state Closed) rather than from A1 (which would be a R-Rcv-Conn-Req in some other state of the machine associated to the connection to A1)? When B1 accepts the call, it only knows the IP of A, which is the same for A1 and A2. It will know it's a different host only when it receives a CER from A2. And if the only moment you can "match" two connections to the same host is when you receive the CER (or CEA), no problem, just do an election at that time and shutdown the connection that lost. > > Another option (now that we ruled out the "use same port for listening and > > connecting" because socket implementations are just too dumb and don't > > accept a perfectly legitimate TCP case) would be to have each server > > establish an outgoing connection, and use that one for sending, while > still > > listening on both. Stupid waste of resources (sockets/file descriptors...) > > though. > >I'd prefer a good solid state machine. Let's be honest here. I wrote the state >machine in -05 is less than a day. This isn't black magic, or rocket >science :) Nope. Here is my proposal: Initiating a connection state machine state event action next state ----------------------------------------------------------------- Closed Start Snd-Conn-Req Wait-Conn-Ack Wait-Conn-Ack Rcv-Conn-Ack Snd-CER Wait-CEA Rcv-Conn-Nack Cleanup Closed Timeout Error Closed Wait-CEA Rcv-CEA Process-CEA, Elect Elect Peer-Disc Disc Closed Timeout Error Closed Elect No-Elect Nothing Open Win-Elect Close other Open Lose-Elect Error Closed Open Send-Message Snd-Non-CER/CEA Open Rcv-Non-CER/CEA Process Open WatchDog-Timer Snd-DWR Open Rcv-DWA Process-DWA Open Stop Disc Closed Peer-Disc Disc Closed Rcv-CER/CEA Error Closed Receiving a connection state machine state event action next state ----------------------------------------------------------------- Closed Rcv-Conn-Req Snd-Conn-Ack Wait-CER Wait-CER Rcv-CER Process_CER, Elect Elect Timeout Error Closed Elect No-Elect Snd-CEA Open Win-Elect Close other, Open Snd-CEA Lose-Elect Error Closed Open Send-Message Snd-Non-CER/CEA Open Rcv-Non-CER/CEA Process Open WatchDog-Timer Snd-DWR Open Rcv-DWA Process-DWA Open Stop Snd-Disc Closed Peer-Disc Disc Closed Rcv-CER/CEA Error Closed No-Elect means no match was found. Win-Elect means this connection won. Lose-Elect means this connection lost. Election is based on Host received against Host local server would send. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Wed Jun 13 11:09:39 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24713 for ; Wed, 13 Jun 2001 11:09:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CB12B91216; Wed, 13 Jun 2001 11:09:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9F1179130C; Wed, 13 Jun 2001 11:09:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 59E9A91216 for ; Wed, 13 Jun 2001 11:09:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 79E335DDB1; Wed, 13 Jun 2001 11:10:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id B2FB05DDF4 for ; Wed, 13 Jun 2001 11:10:18 -0400 (EDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f5DFA4m07120 for ; Wed, 13 Jun 2001 18:10:04 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 13 Jun 2001 18:09:50 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Wed, 13 Jun 2001 18:09:50 +0300 Message-ID: <6D1A8E7871B9D211B3B00008C7490AA504E626ED@treis03nok> From: henry.haverinen@nokia.com To: pcalhoun@diameter.org, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 53: What if the AAAL cannot reach the HA Date: Wed, 13 Jun 2001 18:09:47 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk > What I believe this issue is asking for is the ability for > the AMR to authenticate > and authorize the user, and reply with an AMA. At that point, > the FA can issue the > Registration Request directly to the Home Agent. Of course, > the reason why we had > decided against this proposed in the beginning was because we > wanted to reduce the > number of round trips required to gain service, but there > seems to be cases where > this functionality is valuable. Pat, You are right - this is exactly the behaviour I was asking for with this issue. I believe the solution you proposed in your e-mail would work. It sure is good to have some explicit way of indicating that the FA needs to forward the request to the HA (such as the new result code you're proposing), rather than just deducing this based on the absence of the MIP-Reg-Reply AVP. Thanks, Henry From owner-aaa-wg@merit.edu Wed Jun 13 11:53:57 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25722 for ; Wed, 13 Jun 2001 11:53:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 82F9A9130E; Wed, 13 Jun 2001 11:54:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 544C99130F; Wed, 13 Jun 2001 11:54:03 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 15EAA9130E for ; Wed, 13 Jun 2001 11:54:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1DB315DDB6; Wed, 13 Jun 2001 11:54:39 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) by segue.merit.edu (Postfix) with SMTP id C6EA15DD9B for ; Wed, 13 Jun 2001 11:54:38 -0400 (EDT) Received: from pc114.etc.psi.com (HELO jc.yahoo.com) (195.94.40.114) by smtp.mail.vip.sc5.yahoo.com with SMTP; 13 Jun 2001 15:54:08 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010613174039.00c0c690@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 13 Jun 2001 17:50:26 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 72: Downstream/upstream confusion Cc: Pat Calhoun , aaa-wg@merit.edu In-Reply-To: <20010613072012.Y17928@charizard.diameter.org> References: <4.3.2.7.2.20010612201407.00bf8120@pop.mail.yahoo.com> <20010612065727.I17928@charizard.diameter.org> <4.3.2.7.2.20010612201407.00bf8120@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 16:20 13/06/01, Pat Calhoun wrote: >On Tue, Jun 12, 2001 at 08:23:54PM +0200, Jacques Caron wrote: > > Not sure I agree with the definition of up/downstream. For me the fact > that > > we define that as "upstream" and "downstream" rather than "up" or > "down" is > > a reference to a flow (like a river). And such flow normally goes from > > upstream to downstream (the terms are used in reference to the > direction of > > "normal" requests). > >We appear to be saying the same thing. Things do upstream, and then >downstream. Nope. I say things go FROM upstream TO downstream. In our case, upstream and downstream define relative locations, not directions :-) > > And in 10.10 Inferring Session Termination from Origin-State-Id: > > > > When a Diameter server receives a Origin-State-Id that is greater > > than the Origin-State-Id previously received from the same issuer, it > > may assume that the issuer has lost state since the previous message > > and that all sessions that were active under the lower Origin-State- > > Id have been terminated. The Diameter server MAY clean up all session > > state associated with such lost sessions, and MAY also issues STRs > > for all such lost sessions that were authorized on downstream > > servers, to allow session state to be cleaned up globally. > > > > Should be upstream too, then. > >hmmmm.... this text comes from Paul, and I missed the problem here. First of >all, this text implies that the server initiates an STR, when this is >typically >done by the access device. So, perhaps ASR is what was meant here. In which >case downstream would be correct, but not "downstream servers", and instead >"downstream clients". > >Paul?!? Well, since the server (or rather proxy in this case) just detected that the client rebooted, there is no need to terminate all sessions on the client... I think it's another issue of those famous STRs sent by proxies "on behalf" of the NASes erk erk erk ;-) Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Wed Jun 13 12:34:01 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26684 for ; Wed, 13 Jun 2001 12:34:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DAAA991218; Wed, 13 Jun 2001 12:34:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A697F91312; Wed, 13 Jun 2001 12:34:05 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 81D7591218 for ; Wed, 13 Jun 2001 12:34:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B299A5DDF9; Wed, 13 Jun 2001 12:34:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 012F65DDB6 for ; Wed, 13 Jun 2001 12:34:40 -0400 (EDT) Received: (qmail 28556 invoked by uid 500); 13 Jun 2001 16:23:38 -0000 Date: Wed, 13 Jun 2001 09:23:38 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 72: Downstream/upstream confusion Message-ID: <20010613092338.G17928@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <4.3.2.7.2.20010612201407.00bf8120@pop.mail.yahoo.com> <20010612065727.I17928@charizard.diameter.org> <4.3.2.7.2.20010612201407.00bf8120@pop.mail.yahoo.com> <20010613072012.Y17928@charizard.diameter.org> <4.3.2.7.2.20010613174039.00c0c690@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010613174039.00c0c690@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Wed, Jun 13, 2001 at 05:50:26PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Jun 13, 2001 at 05:50:26PM +0200, Jacques Caron wrote: > Nope. I say things go FROM upstream TO downstream. In our case, upstream > and downstream define relative locations, not directions :-) Ah, now I get your point. It depends upon where the message was originated, and the request is always upstream, and the answer is always downstream. Is this correct? > > > > And in 10.10 Inferring Session Termination from Origin-State-Id: > > > > > > When a Diameter server receives a Origin-State-Id that is greater > > > than the Origin-State-Id previously received from the same issuer, it > > > may assume that the issuer has lost state since the previous message > > > and that all sessions that were active under the lower Origin-State- > > > Id have been terminated. The Diameter server MAY clean up all session > > > state associated with such lost sessions, and MAY also issues STRs > > > for all such lost sessions that were authorized on downstream > > > servers, to allow session state to be cleaned up globally. > > > > > > Should be upstream too, then. > > > >hmmmm.... this text comes from Paul, and I missed the problem here. First of > >all, this text implies that the server initiates an STR, when this is > >typically > >done by the access device. So, perhaps ASR is what was meant here. In which > >case downstream would be correct, but not "downstream servers", and instead > >"downstream clients". > > > >Paul?!? > > Well, since the server (or rather proxy in this case) just detected that > the client rebooted, there is no need to terminate all sessions on the > client... I think it's another issue of those famous STRs sent by proxies > "on behalf" of the NASes erk erk erk ;-) That is some nastiness that the protocol shouldn't support, IMHO. Adding this complexity to proxies is really unnecessary, since the NAS would have to know anyways whether it should send an STR, and you may end up in a situation where both the NAS and a proxy send STRs. PatC From owner-aaa-wg@merit.edu Wed Jun 13 12:38:12 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26815 for ; Wed, 13 Jun 2001 12:38:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CD35291312; Wed, 13 Jun 2001 12:38:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9E8F891313; Wed, 13 Jun 2001 12:38:17 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7057991312 for ; Wed, 13 Jun 2001 12:38:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ADB8C5DDB6; Wed, 13 Jun 2001 12:38:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp010.mail.yahoo.com (smtp010.mail.yahoo.com [216.136.173.30]) by segue.merit.edu (Postfix) with SMTP id 6284D5DD9B for ; Wed, 13 Jun 2001 12:38:53 -0400 (EDT) Received: from pc114.etc.psi.com (HELO jc.yahoo.com) (195.94.40.114) by smtp.mail.vip.sc5.yahoo.com with SMTP; 13 Jun 2001 16:38:25 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010613183515.00c10a90@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 13 Jun 2001 18:37:48 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 72: Downstream/upstream confusion Cc: Pat Calhoun , aaa-wg@merit.edu In-Reply-To: <20010613092338.G17928@charizard.diameter.org> References: <4.3.2.7.2.20010613174039.00c0c690@pop.mail.yahoo.com> <4.3.2.7.2.20010612201407.00bf8120@pop.mail.yahoo.com> <20010612065727.I17928@charizard.diameter.org> <4.3.2.7.2.20010612201407.00bf8120@pop.mail.yahoo.com> <20010613072012.Y17928@charizard.diameter.org> <4.3.2.7.2.20010613174039.00c0c690@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 18:23 13/06/01, Pat Calhoun wrote: >On Wed, Jun 13, 2001 at 05:50:26PM +0200, Jacques Caron wrote: > > Nope. I say things go FROM upstream TO downstream. In our case, upstream > > and downstream define relative locations, not directions :-) > >Ah, now I get your point. It depends upon where the message was >originated, and the >request is always upstream, and the answer is always downstream. Is this >correct? The request follows the stream, and goes from upstream to downstream. The answer is a bit weird since it goes downstream to upstream (like a salmon that tries to go upstream to lay its eggs...) > > Well, since the server (or rather proxy in this case) just detected that > > the client rebooted, there is no need to terminate all sessions on the > > client... I think it's another issue of those famous STRs sent by proxies > > "on behalf" of the NASes erk erk erk ;-) > >That is some nastiness that the protocol shouldn't support, IMHO. Adding this >complexity to proxies is really unnecessary, since the NAS would have to know >anyways whether it should send an STR, and you may end up in a situation where >both the NAS and a proxy send STRs. If the NAS rebooted, it does not know anything about the previous sessions... The goal of the previous paragraph is to do some quick cleanup, i.e. be a bit more proactive on fixing the sessions that got lost than having the server wait for the next request from that client (which might be very far away in the future in a roaming environment). Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Wed Jun 13 12:43:09 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27015 for ; Wed, 13 Jun 2001 12:43:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CA6489121A; Wed, 13 Jun 2001 12:43:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9A52A91313; Wed, 13 Jun 2001 12:43:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7BC409121A for ; Wed, 13 Jun 2001 12:43:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B99355DDBF; Wed, 13 Jun 2001 12:43:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 22C8E5DDB6 for ; Wed, 13 Jun 2001 12:43:48 -0400 (EDT) Received: (qmail 28945 invoked by uid 500); 13 Jun 2001 16:31:13 -0000 Date: Wed, 13 Jun 2001 09:31:13 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 72: Downstream/upstream confusion Message-ID: <20010613093112.I17928@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <4.3.2.7.2.20010613174039.00c0c690@pop.mail.yahoo.com> <4.3.2.7.2.20010612201407.00bf8120@pop.mail.yahoo.com> <20010612065727.I17928@charizard.diameter.org> <4.3.2.7.2.20010612201407.00bf8120@pop.mail.yahoo.com> <20010613072012.Y17928@charizard.diameter.org> <4.3.2.7.2.20010613174039.00c0c690@pop.mail.yahoo.com> <20010613092338.G17928@charizard.diameter.org> <4.3.2.7.2.20010613183515.00c10a90@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010613183515.00c10a90@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Wed, Jun 13, 2001 at 06:37:48PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Jun 13, 2001 at 06:37:48PM +0200, Jacques Caron wrote: > At 18:23 13/06/01, Pat Calhoun wrote: > >On Wed, Jun 13, 2001 at 05:50:26PM +0200, Jacques Caron wrote: > > > Nope. I say things go FROM upstream TO downstream. In our case, upstream > > > and downstream define relative locations, not directions :-) > > > >Ah, now I get your point. It depends upon where the message was > >originated, and the > >request is always upstream, and the answer is always downstream. Is this > >correct? > > The request follows the stream, and goes from upstream to downstream. The > answer is a bit weird since it goes downstream to upstream (like a salmon > that tries to go upstream to lay its eggs...) hmmmm..... ok. I don't actually mind this since the text in the draft currently assumes that the message is from the access device towards the home, and this isn't true for server initiated messages. Therefore, I would be willing to make such a change, if the WG agreed. > > > > Well, since the server (or rather proxy in this case) just detected that > > > the client rebooted, there is no need to terminate all sessions on the > > > client... I think it's another issue of those famous STRs sent by proxies > > > "on behalf" of the NASes erk erk erk ;-) > > > >That is some nastiness that the protocol shouldn't support, IMHO. Adding this > >complexity to proxies is really unnecessary, since the NAS would have to know > >anyways whether it should send an STR, and you may end up in a situation where > >both the NAS and a proxy send STRs. > > If the NAS rebooted, it does not know anything about the previous > sessions... The goal of the previous paragraph is to do some quick cleanup, > i.e. be a bit more proactive on fixing the sessions that got lost than > having the server wait for the next request from that client (which might > be very far away in the future in a roaming environment). duh. sorry, I had forgotten that's what this was used for :( PatC From owner-aaa-wg@merit.edu Wed Jun 13 15:53:48 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00381 for ; Wed, 13 Jun 2001 15:53:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 445D391316; Wed, 13 Jun 2001 15:53:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0588E91318; Wed, 13 Jun 2001 15:53:35 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8E7B091316 for ; Wed, 13 Jun 2001 15:53:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E00785DDF3; Wed, 13 Jun 2001 15:54:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (c000-h001.c000.snv.cp.net [209.228.32.65]) by segue.merit.edu (Postfix) with SMTP id 3F0E55DDB0 for ; Wed, 13 Jun 2001 15:54:11 -0400 (EDT) Received: (cpmta 28713 invoked from network); 13 Jun 2001 12:53:42 -0700 Received: from h121s86a16n47.user.nortelnetworks.com (HELO mitton.mitton.com) (47.16.86.121) by smtp.mitton.com (209.228.32.65) with SMTP; 13 Jun 2001 12:53:42 -0700 X-Sent: 13 Jun 2001 19:53:42 GMT Message-Id: <4.3.2.7.2.20010613155243.046e7340@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 13 Jun 2001 15:56:07 -0400 To: Pat Calhoun , Cain Brian-BCAIN1 From: David Mitton Subject: Re: [AAA-WG]: Support for multi-process Cc: aaa-wg@merit.edu In-Reply-To: <20010612163400.J17928@charizard.diameter.org> References: <35DBB8B7AC89D4118E98009027B1009B0ECF36@IL27EXM10.cig.mot.com> <35DBB8B7AC89D4118E98009027B1009B0ECF36@IL27EXM10.cig.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 6/12/01 04:34 PM -0700, Pat Calhoun wrote: >On Tue, Jun 12, 2001 at 04:54:42PM -0500, Cain Brian-BCAIN1 wrote: > > > -----Original Message----- > > > From: David Mitton [mailto:david@mitton.com] > > ... > > > There are no constraints on the value of the source port of > > > the connection. > > > It should be assumed to be an ephemeral port. The well-known > > > port is in > > > use for listening. A listening socket cannot make connections. > > > > > > This is how most TCP protocols work. > > > > Okay, so it would seem that duplicate connections are not preventable, > > right? Or at least, not for the common denominator. > >No, they are in fact preventable, by ensuring that the source port is NOT >the same as the destination port. So, if we require that the connection NOT >be established on the listening port, then we can ensure that both sides of >the connection will create a separate connection. > >PatC The point I'm trying to make is that people are trying to make bad assumptions about port numbers relative to running server instances. I think we want to leave actual port values out of it and use the contents of the message as the server identifier. Dave. ---------------------------------------------------- David Mitton 978-288-4570 Advisor, Nortel Networks david@mitton.com or dmitton@nortelnetworks.com From owner-aaa-wg@merit.edu Wed Jun 13 16:08:47 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00824 for ; Wed, 13 Jun 2001 16:08:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3F06C91319; Wed, 13 Jun 2001 16:08:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0343F9131B; Wed, 13 Jun 2001 16:08:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D141691319 for ; Wed, 13 Jun 2001 16:08:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 354315DDF3; Wed, 13 Jun 2001 16:09:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by segue.merit.edu (Postfix) with ESMTP id C71175DDB0 for ; Wed, 13 Jun 2001 16:09:28 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5DK8nE05907 for ; Wed, 13 Jun 2001 16:08:49 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Wed, 13 Jun 2001 16:08:31 -0400 Received: from zbl6c016.corpeast.baynetworks.com ([132.245.205.66]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MZHTCTLT; Wed, 13 Jun 2001 16:08:33 -0400 Received: from mitton.nortelnetworks.com (mitton.us.nortel.com [47.16.86.121]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KBYWGNN7; Wed, 13 Jun 2001 16:08:27 -0400 Message-Id: <4.3.2.7.2.20010613155704.0462da90@ZBL6C016.corpeast.baynetworks.com> X-Sender: dmitton@ZBL6C016.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 13 Jun 2001 16:10:58 -0400 To: Jacques Caron , Pat Calhoun From: "David Mitton" Subject: Re: [AAA-WG]: Support for multi-process Cc: aaa-wg@merit.edu In-Reply-To: <4.3.2.7.2.20010613155901.00c11670@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Orig: Sender: owner-aaa-wg@merit.edu Precedence: bulk At 6/13/01 10:55 AM -0400, Jacques Caron wrote: >At 15:43 13/06/01, Pat Calhoun wrote: > >On Wed, Jun 13, 2001 at 03:42:34PM +0200, Jacques Caron wrote: > > > At 01:34 13/06/01, Pat Calhoun wrote: > > > >No, they are in fact preventable, by ensuring that the source port > is NOT > > > >the same as the destination port. So, if we require that the > > connection NOT > > > >be established on the listening port, then we can ensure that both > > sides of > > > >the connection will create a separate connection. > > > > > > Isn't that exactly what we're trying to avoid? > > > >We do want to avoid multiple connections, but we have identified that if > all > >of the ports are the same, both sides will think that they've setup the > >connection > >If you're referring to using the same port for listening and connecting, >then the issue is mostly that most socket implementations just don't allow >that. If they allowed it (as BSD stacks do with SO_REUSEPORT), then there >could be only a single connection established, which would solve the problem. It's just not done that way, give it up. > > > BTW, I'm not sure we need such a complex state machine. Connecting to a > > > peer and receiving a connection from a peer should be two totally > distinct > > > state machines (pretty basic in operation, one is: connect, send CER, > wait > > > for CEA, and the other is accept, wait for CER, send CEA -- plus of > course > > > error handling at all intermediate steps). Just add that upon receipt of > > > the remote's Host descriptor (in a CEA in the first case, in the CER in > > the > > > other), it should be compared against those we already have a connection > > > to, and if there is a match, the connection established by the peer with > > > the lexically greater host descriptor has to be shut down). > > > >but you need to handle the cases where unexpected events occur while in > >intermediate (non-open) states. That's where the complexity occurs. I agree > >that we could simplify the SM by allowing all connections to move > towards the > >open state, and close it when it reaches that point. That would reduce the > >number of interim states that need to check for existing connections, but > >you could *still* get into a race condition :( > >At any time you have an error (connect fails, timeout waiting for CER, >connection dropped), shutdown the connection and go back to closed state. >Still need some mechanism to introduce a delay before the next retry, >though, not sure that's present anywhere in the current state machine or >elsewhere in the draft? I'm not sure that a delay is required. > > > I would add that having a single state machine for both is quite > hard: how > > > do you know a connection you receive actually goes into the same state > > > machine as one you initiated until you received the Host descriptor? > > > >well, either you initiate the connection, or you don't. It doesn't seem > >that hard to me :( > >I meant to identify a connection that you receive as being associated to >the same peer as one you already started establishing. > >Imagine host A has processes A1 and A2, and host B has process B1. > >B1 initiates a call to A1 and is somewhere in the state machine. >A2 initiates a call to B1. How does B1 know this is a connection from A2 >(which would be a R-Rcv-Conn-Req in state Closed) rather than from A1 >(which would be a R-Rcv-Conn-Req in some other state of the machine >associated to the connection to A1)? When B1 accepts the call, it only >knows the IP of A, which is the same for A1 and A2. It will know it's a >different host only when it receives a CER from A2. > >And if the only moment you can "match" two connections to the same host is >when you receive the CER (or CEA), no problem, just do an election at that >time and shutdown the connection that lost. Yes. We've been here, done this. That's the idea. Initiator opens the connection, and sends the message, the listener looks at what he gets and proceeds. And the only time you need to perform the election process is if you have more than one connection. If you have no other connections up, it's pointless. And it seems it's true that we need to use information in the message to identify the client end, since there may be multiple separate servers running on the same IP addressed system using configured and/or ephemeral non-default port numbers. So what's the question? > > > Another option (now that we ruled out the "use same port for > listening and > > > connecting" because socket implementations are just too dumb and don't > > > accept a perfectly legitimate TCP case) would be to have each server > > > establish an outgoing connection, and use that one for sending, while > > still > > > listening on both. Stupid waste of resources (sockets/file > descriptors...) > > > though. > > > >I'd prefer a good solid state machine. Let's be honest here. I wrote the > state > >machine in -05 is less than a day. This isn't black magic, or rocket > >science :) > >Nope. Here is my proposal: Dave. ------------------------------------------------------------ David Mitton ESN: 248-4570 Advisor, Nortel Networks 978-288-4570 Wireless Solutions, IP Mobility Billerica, MA 01821 dmitton@nortelnetworks.com From owner-aaa-wg@merit.edu Wed Jun 13 16:29:26 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01126 for ; Wed, 13 Jun 2001 16:29:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A250091317; Wed, 13 Jun 2001 16:28:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 77B7E9131B; Wed, 13 Jun 2001 16:28:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0479591317 for ; Wed, 13 Jun 2001 16:28:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 735C45DDC1; Wed, 13 Jun 2001 16:29:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 5B7955DDB0 for ; Wed, 13 Jun 2001 16:29:06 -0400 (EDT) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 7942E79; Wed, 13 Jun 2001 16:28:48 -0400 (EDT) Message-ID: <3B27CCA8.87C1B7D6@Interlinknetworks.com> Date: Wed, 13 Jun 2001 16:27:20 -0400 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 29: IPv6 AVPs References: <20010605164453.R12278@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit See editorial corrections, below. Pat Calhoun wrote: > > All, > > This one was previously owned by Bernard, but we have no issue on it, so I've taken it > over, below, and am proposing text to close this one. > > PatC > ---- > Issue 29: IPv6 AVPs > Submitter name: Pat Calhoun > Submitter email address: pcalhoun@diameter.org > Date first submitted: 2001-06-05 > Reference: > Document: nasreq > Comment type: C > Priority: 1 > Section: 7.2.5 > Rationale/Explanation of issue: > > At the Interim Meeting, Bernard stated that two RADIUS ipv6 > attributes were missing from the NASREQ application, specifically > the Framed-Interface-Id, and the Framed-IPv6-Prefix. > > Proposed Text: > > 7.2.5.4 Framed-Interface-Id AVP > > The Framed-Interface-Id AVP (AVP Code TBD) is of type Unsigned64 and > contains the IPv6 interface identifier to be configured for the user. > It MAY be used in authorization requests as a hint to the server that > a specific interface id is desired, but the server is not required to > honor the hint in the corresponding response. > > 7.2.5.5 Framed-IPv6-Prefix AVP > > The Framed-Interface-Id AVP (AVP Code TBD) is of type Address and ^^^^^^^^^^^^^^^^^^^ Framed-IPv6-Prefix > contains the IPv6 prefix to be configured for the user. It MAY be > used in authorization requests as a hint to the server that a > specific interface id is desired, but the server is not required to ^^^^^^^^^^^^ IPv6 prefix > honor the hint in the corresponding response. -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-wg@merit.edu Wed Jun 13 16:33:24 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01193 for ; Wed, 13 Jun 2001 16:33:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B901C91323; Wed, 13 Jun 2001 16:31:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8E5F491322; Wed, 13 Jun 2001 16:31:10 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 98B9C9131E for ; Wed, 13 Jun 2001 16:31:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2D10B5DDC1; Wed, 13 Jun 2001 16:31:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 17EE35DDB0 for ; Wed, 13 Jun 2001 16:31:44 -0400 (EDT) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 1D12979; Wed, 13 Jun 2001 16:31:26 -0400 (EDT) Message-ID: <3B27CD45.78404CA8@Interlinknetworks.com> Date: Wed, 13 Jun 2001 16:29:57 -0400 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: Bernard Aboba , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 29: IPv6 AVPs References: <20010605164453.R12278@charizard.diameter.org> <20010612083940.M17928@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit See editorial corrections, below. Pat Calhoun wrote: > > On Tue, Jun 05, 2001 at 11:43:47PM -0700, Bernard Aboba wrote: > > Actually, I think there are two more missing: Framed-IPv6-Pool and > > Framed-Ipv6-Route. I'll have updated text for these later this week. > > Bernard, > > Here is the proposed text for the two new AVPs: > > 7.2.5.6 Framed-IPv6-Route AVP > > The Framed-IPv6-Route AVP (AVP Code TBD) is of type UTF8String, and > contains the routing information to be configured for the user on the > NAS. Zero or more such AVPs MAY be present in an authorization > response. > > The string MUST contain an IPv6 address prefix followed by a slash > and a decimal length specifier stating how many high order bits of > the prefix should be used. That is followed by a space, a gateway > address in hexadecimal notation, a space, and one or more metrics > separated by spaces. For example: > "2000:0:0:106::/64 2000::106:a00:20ff:fe99:a998 1". > > Whenever the gateway address is the IPv6 unspecified address the IP > address of the user SHOULD be used as the gateway address, such as: > "2000:0:0:106::/64 :: 1". > > 7.2.5.7 Framed-IPv6-Pool AVP > > The Framed-IP-Route AVP (AVP Code 22) is of type UTF8String, and ^^^^^^^^^^^^^^^ ^^ Framed-IP6-Pool [not 22] > contains the name of an assigned pool that SHOULD be used to assign > an IPv6 prefix for the user. If the access device does not support > multiple prefix pools, it SHOULD ignore this AVP. -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-wg@merit.edu Wed Jun 13 16:56:41 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01462 for ; Wed, 13 Jun 2001 16:56:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 07BF291223; Wed, 13 Jun 2001 16:56:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C7BA29131B; Wed, 13 Jun 2001 16:56:46 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A105391223 for ; Wed, 13 Jun 2001 16:56:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1AF365DDF3; Wed, 13 Jun 2001 16:57:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 083D35DDB0 for ; Wed, 13 Jun 2001 16:57:23 -0400 (EDT) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 1292079; Wed, 13 Jun 2001 16:57:05 -0400 (EDT) Message-ID: <3B27D348.E533EE02@Interlinknetworks.com> Date: Wed, 13 Jun 2001 16:55:36 -0400 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 42: Session-Timeout inconsistent with RADIUS spec References: <20010612091129.O17928@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit See editorial corrections below. Pat Calhoun wrote: > > All, > > The inconsistency identified was that RADIUS re-uses the Session-Timeout attribute > in Access-Challenge messages to inform the access device how long it should wait for > the user's response. In order to fix this issue, I propose adding the following text to > the base protocol specification: > > 10.14 Multi-Round-Time-Out AVP > > The Multi-Round-Time-Out AVP (AVP Code TBD) is of type Unsigned32, > and SHOULD be present in application-specific authorization answer > messages whose Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH. > This AVP contains the maximum number of seconds that the access > device MUST provide the user in responding to an authentication > request. > > And the following text to the protocol conversion section (9.x) in the NASREQ > application specification. > > 9.1 RADIUS request forwarded as Diameter request > > [...] > - If the Diameter Command-Code is set to AA-Answer and the > Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH, the gateway > must send a RADIUS Access-Challenge with the the Diameter xxxx > Session-Id and the Origin-Host AVPs are saved in the RADIUS xxxx > State attribute, with the prefix "Diameter/". This is necessary > in order to ensure that the protocol gateway that will receive > the subsequent RADIUS Access-Request will have access to the > Session Identifier, and be able to set the Destination-Host to > the correct value. If the Multi-Round-Time-Out AVP is present, > the value of the AVP MUST be inserted in the RADIUS Session- > Timeout AVP. > [editor's note, new last sentence] [reviewer's note, bad first sentence ;) ] > > 9.2 Diameter request forwarded as RADIUS request > > [...] > - If the RADIUS code is set to Access-Challenge, a Diameter AA- > Answer message is created with the Result-Code set to > DIAMETER_MULTI_ROUND_AUTH. If the Session-Timeout AVP is present > in the RADIUS message, its value is inserted in the Multi- > Round-Time-Out AVP. > [editor's note, new last sentence] > > Comments appreciated, > > PatC -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-wg@merit.edu Wed Jun 13 21:13:29 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04191 for ; Wed, 13 Jun 2001 21:13:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5581C912FA; Wed, 13 Jun 2001 21:13:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2505B912FB; Wed, 13 Jun 2001 21:13:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1510F912FA for ; Wed, 13 Jun 2001 21:13:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F40385DDA0; Wed, 13 Jun 2001 21:14:09 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 69AD05DD8F for ; Wed, 13 Jun 2001 21:14:09 -0400 (EDT) Received: from gwzpc (rtp-dial-1-239.cisco.com [10.83.97.239]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id SAA05631; Wed, 13 Jun 2001 18:13:06 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Pat Calhoun" Cc: Subject: RE: [AAA-WG]: Issue 70: Caching of redirects Date: Wed, 13 Jun 2001 18:13:05 -0700 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) Importance: Normal In-Reply-To: <20010612083245.L17928@charizard.diameter.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun [mailto:pcalhoun@diameter.org] writes: > Taking all of the comments on the list on this issue, I've come > up with the > following text. > > Comments appreciated, Works for me. > > PatC > ---- > > > 5.10 Redirect-Host-Usage AVP > > The Redirect-Host-Usage AVP (AVP Code TBD) is of type Enumerated. > This AVP MAY be present in Message-Reject-Answer messages that > include the Result-Code AVP set to DIAMETER_REDIRECT_INDICATION. > > When present, this AVP dictates how the routing entry resulting from > the MRA is to be used. The following values are supported: > > DONT_CACHE 0 > The host specified in the Redirect-Host AVP should not be > cached. This is the default value. > > ALL_REALM 1 > All messages destined for the realm requested MAY be sent to > the host specified in the Redirect-Host AVP. > > REALM_AND_APPLICATION 2 > All messages for the application requested to the realm > specified MAY be sent to the host specified in the Redirect- > Host AVP. > > > 5.11 Maximum-Redirect-Cache-Time AVP > > The Maximum-Redirect-Cache-Time AVP (AVP Code TBD) is of type > Unsigned32. This AVP MUST be present in Message-Reject-Answer > messages that include the Result-Code AVP set to > DIAMETER_REDIRECT_INDICATION, and the Redirect-Host-Usage AVP set to > a non-zero value. > > This AVP contains the maximum number of seconds the peer and route > table entries, created as a result of the Redirect-Host, must be > cached. > > From owner-aaa-wg@merit.edu Thu Jun 14 01:22:38 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09269 for ; Thu, 14 Jun 2001 01:22:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 57510912FB; Thu, 14 Jun 2001 01:22:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1C9E6912FD; Thu, 14 Jun 2001 01:22:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D63C4912FB for ; Thu, 14 Jun 2001 01:22:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 20FF15DDF9; Thu, 14 Jun 2001 01:23:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from redmailwall2.attws.com (redmailwall2.attws.com [199.108.253.116]) by segue.merit.edu (Postfix) with ESMTP id 8B8BC5DDB0 for ; Thu, 14 Jun 2001 01:23:20 -0400 (EDT) Received: from viruswall.entp.attws.com (viruswall.entp.attws.com [135.214.42.163]) by redmailwall2.attws.com (8.9.3/8.9.3) with ESMTP id WAA22755; Wed, 13 Jun 2001 22:20:19 -0700 (PDT) Received: from neastmail.neast.attws.com by viruswall.entp.attws.com (8.8.8+Sun/AT&T Wireless Services, Inc. V8 version 2) id WAA27168; Wed, 13 Jun 2001 22:22:19 -0700 (PDT) Received: from ner-msgbh.wireless.attws.com (ner-msgbh.wireless.attws.com [135.216.177.192]) by neastmail.neast.attws.com (8.8.8+Sun/8.8.8) with ESMTP id WAA15282; Wed, 13 Jun 2001 22:22:18 -0700 (PDT) Received: by ner-msgbh.wireless.attws.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Jun 2001 01:22:16 -0400 Message-ID: <0D3BDFD96647D211B43A00805F15E589050868D5@ner-msg03.wireless.attws.com> From: "Kobylarz, Thaddeus" To: "'Pat Calhoun'" , aaa-wg@merit.edu, "'3GPP_TSG_SA_WG5@LIST.ETSI.FR'" <3GPP_TSG_SA_WG5@LIST.ETSI.FR> Cc: "Molchan, John" , "Engelhart, Bob" Subject: RE: [AAA-WG]: Issue #33: Is API Considered Useful Date: Thu, 14 Jun 2001 01:22:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Pat, I hope its not too late to ask you to wait a little longer before discarding the "server initiated accounting poll" requirement. I don't see a need, but would like to get reactions from others in 3GPP SA5. Hence, I am concurrently sending this e-mail to them. Thad SA5 folks, especially CB participants, Please consider the attached e-mail and send your opinions to Pat. It is very important to provide opinions ASAP. Thanks, Thad -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Tuesday, June 05, 2001 9:57 AM To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue #33: Is API Considered Useful All, I spoke with Tom Hiller, the editor of the various 3GPP2 specs, and talked to him about P.R001, and the rather obscure requirement to allow for a server initiated accounting poll. He stated that if the feature wasn't discussed in P.S001, then it isn't a requirement, and P.R001 is a non-normative reference in P.S001 (it is informational only). So, it sounds as if we can get rid of this feature, but I would like to ask, one last time, whether people feel it is necessary for an accounting server to be able to issue a request to an access device to force it to send an accounting message. If so, then we will keep this feature, but if there is no demand..... out it goes. PatC From owner-aaa-wg@merit.edu Thu Jun 14 07:53:45 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25451 for ; Thu, 14 Jun 2001 07:53:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 15A9991227; Thu, 14 Jun 2001 07:53:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D1A2391320; Thu, 14 Jun 2001 07:53:39 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AAF3B91227 for ; Thu, 14 Jun 2001 07:53:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6DD145DDB0; Thu, 14 Jun 2001 07:54:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id CB1E15DD92 for ; Thu, 14 Jun 2001 07:54:16 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f5EBrlN01395; Thu, 14 Jun 2001 13:53:47 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f5EBrlE09145; Thu, 14 Jun 2001 14:53:47 +0300 (EET DST) Message-ID: <3B28A5CB.7C08F54C@lmf.ericsson.se> Date: Thu, 14 Jun 2001 14:53:47 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 64: e2e draft editorial issues References: <20010608072010.J4931@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun wrote: > > - 6.5, I think it is better to keep the OCSP-desire > > and the nonce together. > > I do not know what this means? A grouped AVP? btw, the current > draft is incorrect since it shows that the nonce and OSCP-Request > can occur multiple times in the DSAR, and it MUST NOT occur more > than once. The ABNF will be updated to reflect this. > > Jari, could you please expand on what you meant? This relates to the comment in 6.5 of the old draft. But the same thing exists also in the current draft, though it has now been provided separately, the OCSP-Nonce and the OCSP-Request AVPs. The issue is that we set OCSP-Request=3 and then provide also OCSP-Nonce, or if we could just set OCSP-Request=2 and the existence of OCSP-Nonce would indicate the need for fresh responses. It would seem that the latter approach requires a diameter implementation to make less checks (did he include OCSP-Nonce when OCSP-Request was 3? No? Bad peer...). However, this is very minor issue and I really don't care much either way. Jari From owner-aaa-wg@merit.edu Thu Jun 14 08:02:15 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25686 for ; Thu, 14 Jun 2001 08:02:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6D5F091321; Thu, 14 Jun 2001 07:59:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3CADD91322; Thu, 14 Jun 2001 07:59:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C3D2791321 for ; Thu, 14 Jun 2001 07:59:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 896045DDA7; Thu, 14 Jun 2001 08:00:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id B6C565DD92 for ; Thu, 14 Jun 2001 08:00:24 -0400 (EDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f5EBxuO06360 for ; Thu, 14 Jun 2001 13:59:56 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu Jun 14 13:59:54 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Jun 2001 13:59:55 +0200 Message-ID: <577066326047D41180AC00508B955DDA04D1A9AC@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Pat Calhoun'" , Jacques Caron Cc: "Martin Julien (ECE)" , "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: NASREQ Request-Type AVP??? Date: Thu, 14 Jun 2001 13:59:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA25686 See enclosed comments. > On Mon, Jun 11, 2001 at 10:55:43AM +0200, Jacques Caron wrote: > > At 10:36 11/06/01, Martin Julien (ECE) wrote: > > >Hi, > > > > > >Looking at the NASREQ Request-Type AVP, I would appreciate if > > >someone could give me his interpretation of the following > > >possible values for the Request-Type AVP. > > > > > > >> > > > AUTHENTICATE_ONLY 1 > > > The request being sent is for authentication > only, and MUST > > > contain the relevant authentication AVPs that > are needed by the > > > Diameter server to authenticate the user. > > ><< > > > > > >Since the specification says that it should not be permitted to > > >authenticate-only a session, and then authorize-only the > same session, > > >I was wondering for what that value could really be useful? > > >Should that Request-Type value be only used when answering > a AA-Request > > >Challenge? > > > > The nasreq draft indeed says in 3.1.1: > > It is possible for a single session to be authorized > only first, then > > followed by an authentication request. However, the > inverse SHOULD > > NOT be permitted. > > $*@&!^@ > > I think that this sentence needs to be changed: > > If both authentication and authorization will be requested > for a given session, > the former SHOULD be done prior to the latter. It is still > possible for > authorization to be done without authentication. > > This covers: > - Authentication first, followed by authorization (such as tacacs+) > - authorize only (may I answer this phone call?) > - authenticate only (well, I have no idea what you'd do this for :( > > PatC > Does it also mean that an authorization-only could be followed by an authentication-only? The thing is that I am wondering if an AAA server needs to keep a session opened for an authorization-only or not? For example, in the case that a request is received for authorization-only, which gets routed to a tunnel, is there any point of keeping a session in the AAA or not? I guess there is no point for accounting, neither authentication, am I right? By the way, when a AA-Request is received in a AAA server without a User-Name, but containing either a Called-Station-Id or a Calling-Station-Id, is it implicit that tunnelling should be defined in the receiving AAA node or not? The thing is that I am wondering if it is possible for a AAA proxy server to forward an AA-Request based on DNI or ANIS? Is it common practice? Since the specification considers that the allowed usage of those fields is outside its scope, I guess it does not have to be reserved for tunnel, but I´m not sure?? Regards, Martin From owner-aaa-wg@merit.edu Thu Jun 14 08:31:21 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26457 for ; Thu, 14 Jun 2001 08:31:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DEDB491322; Thu, 14 Jun 2001 08:30:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AE35491324; Thu, 14 Jun 2001 08:30:34 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 75CBF91322 for ; Thu, 14 Jun 2001 08:30:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 387705DDA7; Thu, 14 Jun 2001 08:31:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by segue.merit.edu (Postfix) with SMTP id B33E25DD92 for ; Thu, 14 Jun 2001 08:31:11 -0400 (EDT) Received: from pc114.etc.psi.com (HELO jc.yahoo.com) (195.94.40.114) by smtp.mail.vip.sc5.yahoo.com with SMTP; 14 Jun 2001 12:30:42 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010614142458.00cf1500@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 14 Jun 2001 14:28:27 +0200 To: "Martin Julien (ECE)" From: Jacques Caron Subject: RE: [AAA-WG]: NASREQ Request-Type AVP??? Cc: "'aaa-wg@merit.edu'" In-Reply-To: <577066326047D41180AC00508B955DDA04D1A9AC@eestqnt104.es.eu. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 13:59 14/06/01, Martin Julien (ECE) wrote: >Does it also mean that an authorization-only could be followed >by an authentication-only? It could happen (e.g. authorization on called/calling number to pick up the call, then PPP authentication, then PPP authorization (a la Tacacs+)). >The thing is that I am wondering if an AAA server >needs to keep a session opened for an authorization-only or not? >For example, in the case that a request is received for >authorization-only, which gets routed to a tunnel, is there any >point of keeping a session in the AAA or not? I guess there is >no point for accounting, neither authentication, am I right? In some cases you might have authorization-only (based on called/calling number), then accounting start, and later on accounting stop. So, yes, you need to maintain state in that case too. >By the way, when a AA-Request is received in a AAA server >without a User-Name, >but containing either a Called-Station-Id or a >Calling-Station-Id, is it >implicit that tunnelling should be defined in the receiving >AAA node or not? No comprendo. >The thing is that I am wondering if it is possible for a AAA >proxy server to >forward an AA-Request based on DNI or ANIS? Is it common practice? Yep. We need clarification on exactly which agents are allowed to infer a Destination-Realm to accomplish that. It's in my list of issues to open :-( Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Thu Jun 14 08:57:06 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27342 for ; Thu, 14 Jun 2001 08:57:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2BA6091325; Thu, 14 Jun 2001 08:57:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EF23C91326; Thu, 14 Jun 2001 08:57:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CD0D991325 for ; Thu, 14 Jun 2001 08:57:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AD9645DDB0; Thu, 14 Jun 2001 08:57:39 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115]) by segue.merit.edu (Postfix) with SMTP id 642315DDA7 for ; Thu, 14 Jun 2001 08:57:39 -0400 (EDT) Received: from pc114.etc.psi.com (HELO jc.yahoo.com) (195.94.40.114) by smtp.mail.vip.sc5.yahoo.com with SMTP; 14 Jun 2001 12:57:08 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010613200236.00c18b60@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 14 Jun 2001 14:56:27 +0200 To: aaa-wg@merit.edu From: Jacques Caron Subject: [AAA-WG]: [Issue] DiameterIdentity (host descriptor) matching & values Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Jacques Caron Submitter email address: jacques_m_caron@yahoo.com Date first submitted: 14-Jun-2001 Reference: Document: Base Comment type: T Priority: 2 Section: throughout, but clarification to be added in 2.7 Rationale/Explanation of issue: We need to clarify how two host descriptors are matched, e.g. in loop matching. Options are: - exact lexical match (strcmp) - expand (add defaults such as diameter://, :port, and ;transport=sctp), then exact lexical match (or match on protocol+name+port+transport) - expand name to IP addresses, and match on protocol+IP+port+transport (if name resolves to multiple IP addresses, any match between the two expansions is a match) First is possible only if any given process picks a unique identity at startup, sends it in Origin-Host AVPs in all messages (including CER/CEAs, which allows direct peers to learn that value), and uses that value in Record-Route AVPs, and if other hosts use that value only for other DiameterIdentity-based AVPs (such as Destination-Host). Note that this works since server always put their identity themselves in those AVPs. It would also work if a server can put a DiameterIdentity received in CER/CEA in an AVP. It cannot work when the DiameterIdentity comes from another source (e.g. from a configuration file listing peers). At the moment, I don't think there is any problem with that one. It might become a problem if we wanted to perform loop matching upon receipt of a Redirect-Host, rather than forward blindly and expect the next host to do the check. Requested changes: At the end of section 2.7, add: The port and protocol listed above are those that a node uses to listen for incoming connections. When a process listens on multiple different addresses or ports or using different protocols, it should select a single combination of those, and always use the same value as its identity for the lifetime of all connections to peers. This value should be sent in Origin-Host in CER/CEA and other messages, used in Route-Record AVPs, and any other AVPs containing DiameterIdentity. For the purposes of loop checking and other comparison purposes, two DiameterIdentity values match if they are lexically identical (i.e. the two strings are the same). Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Thu Jun 14 10:43:42 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01188 for ; Thu, 14 Jun 2001 10:43:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7B21491229; Thu, 14 Jun 2001 10:43:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4908C91326; Thu, 14 Jun 2001 10:43:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CE14E91229 for ; Thu, 14 Jun 2001 10:43:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A0A755DD93; Thu, 14 Jun 2001 10:44:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 589515DD8C for ; Thu, 14 Jun 2001 10:44:13 -0400 (EDT) Received: (qmail 12476 invoked by uid 500); 14 Jun 2001 14:33:07 -0000 Date: Thu, 14 Jun 2001 07:33:06 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 55: Server-Initiated re-auth Message-ID: <20010614073306.K17928@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, Here is an attempt at solving this particular issue. The proposed text below would appear in the base protocol. Comments appreciated, PatC ---- 10.15 Server-Initiated Re-Auth A Diameter server may initiate a re-authentication and/or re- authorization service for a particular session by issuing a Re-Auth- Request (RAR). For example, for pre-paid services, the Diameter server that originally authorized a session may need some confirmation that the user is still using the services. An access device that receives a RAR message with Session-Id equal to a currently active session MUST initiate a re-auth towards the user, if the service supports this particular feature. Each Diameter application MUST state whether service-initiated re-auth is supported, since some applications do not allow for access devices to prompt the user for re-auth. 10.15.1 Re-Auth-Request The Re-Auth-Request (RAR), indicated by the Command-Code set to TBD and the message flags' 'R' bit set, may be sent by any server to the access device that is providing session service, to request that the user be re-authenticated and/or re-authorized. Message Format ::= < Diameter Header: TBD, REQUEST > < Session-Id > { Origin-Host } { Origin-Realm } { Destination-Realm } { Destination-Host } [ Origin-State-Id ] * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] 10.15.2 Re-Auth-Answer The Re-Auth-Answer (RAA), indicated by the Command-Code set to TBD and the message flags' 'R' bit clear, is sent in response to the RAR. The Result-Code AVP MUST be present, and indicates the disposition of the request. A successful RAA message MUST be followed by an application-specific authentication and/or authorization message. Message Format ::= < Diameter Header: TBD > < Session-Id > { Result-Code } { Origin-Host } { Origin-Realm } { Destination-Host } [ Origin-State-Id ] * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] From owner-aaa-wg@merit.edu Thu Jun 14 10:57:42 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01558 for ; Thu, 14 Jun 2001 10:57:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3DB6691326; Thu, 14 Jun 2001 10:57:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0CE2491327; Thu, 14 Jun 2001 10:57:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D2EDA91326 for ; Thu, 14 Jun 2001 10:57:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DAFBD5DD92; Thu, 14 Jun 2001 10:58:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115]) by segue.merit.edu (Postfix) with SMTP id 60EB35DD8C for ; Thu, 14 Jun 2001 10:58:14 -0400 (EDT) Received: from pc114.etc.psi.com (HELO jc.yahoo.com) (195.94.40.114) by smtp.mail.vip.sc5.yahoo.com with SMTP; 14 Jun 2001 14:57:44 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010614164855.00bb76a0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 14 Jun 2001 16:56:35 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 55: Server-Initiated re-auth Cc: aaa-wg@merit.edu In-Reply-To: <20010614073306.K17928@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, I don't know if there was already discussion on this subject, but I'm rather for option 1 in the original issue description, i.e. get rid of it. If a server needs period re-auth, let them send an Authorization-Lifetime AVP. Or did I miss some important reason to keep it? Just my EUR 0.02. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Thu Jun 14 11:37:17 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02328 for ; Thu, 14 Jun 2001 11:37:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E10FB9132E; Thu, 14 Jun 2001 11:36:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B66DE9132C; Thu, 14 Jun 2001 11:36:07 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1A30191329 for ; Thu, 14 Jun 2001 11:36:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2A7545DDB5; Thu, 14 Jun 2001 11:36:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 766A65DDA7 for ; Thu, 14 Jun 2001 11:36:41 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id IAA03587; Thu, 14 Jun 2001 08:30:21 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Thu, 14 Jun 2001 08:30:21 -0700 (PDT) From: Bernard Aboba To: David Spence Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 29: IPv6 AVPs In-Reply-To: <3B27CD45.78404CA8@Interlinknetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > > contains the name of an assigned pool that SHOULD be used to assign > > an IPv6 prefix for the user. If the access device does not support > > multiple prefix pools, it SHOULD ignore this AVP. Glen Zorn has recommended that the SHOULD be changed to MUST, and I've updated the latest version to reflect this. From owner-aaa-wg@merit.edu Thu Jun 14 11:38:11 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02373 for ; Thu, 14 Jun 2001 11:38:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7A4C091329; Thu, 14 Jun 2001 11:38:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 498EA9132A; Thu, 14 Jun 2001 11:38:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 470EF91329 for ; Thu, 14 Jun 2001 11:38:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 59B125DDB5; Thu, 14 Jun 2001 11:38:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id A0C8D5DD93 for ; Thu, 14 Jun 2001 11:38:48 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id IAA03591; Thu, 14 Jun 2001 08:32:33 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Thu, 14 Jun 2001 08:32:33 -0700 (PDT) From: Bernard Aboba To: David Spence Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 29: IPv6 AVPs In-Reply-To: <3B27CCA8.87C1B7D6@Interlinknetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > > 7.2.5.5 Framed-IPv6-Prefix AVP > > > > The Framed-Interface-Id AVP (AVP Code TBD) is of type Address and > ^^^^^^^^^^^^^^^^^^^ > Framed-IPv6-Prefix > > > contains the IPv6 prefix to be configured for the user. It MAY be > > used in authorization requests as a hint to the server that a > > specific interface id is desired, but the server is not required to > ^^^^^^^^^^^^ > IPv6 prefix > > > honor the hint in the corresponding response. > Multiple prefix attributes can be sent, so I think you want to pluralize this. From owner-aaa-wg@merit.edu Thu Jun 14 12:22:42 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03423 for ; Thu, 14 Jun 2001 12:22:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2148991330; Thu, 14 Jun 2001 12:22:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E6B7591331; Thu, 14 Jun 2001 12:22:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 91FCD91330 for ; Thu, 14 Jun 2001 12:22:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B4A975DD93; Thu, 14 Jun 2001 12:23:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp014.mail.yahoo.com (smtp014.mail.yahoo.com [216.136.173.58]) by segue.merit.edu (Postfix) with SMTP id 3AD345DD8C for ; Thu, 14 Jun 2001 12:23:15 -0400 (EDT) Received: from pc114.etc.psi.com (HELO jc.yahoo.com) (195.94.40.114) by smtp.mail.vip.sc5.yahoo.com with SMTP; 14 Jun 2001 16:22:45 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010614181949.00bac6e0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 14 Jun 2001 18:21:34 +0200 To: aaa-wg@merit.edu From: Jacques Caron Subject: [AAA-WG]: [Issue] Error handling editorial changes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Jacques Caron Submitter email address: jacques_m_caron@yahoo.com Date first submitted: 13-Jun-2001 Reference: Document: Base Comment type: E Priority: 1 Section: throughout Rationale/Explanation of issue: Error handling - In 9.0, in the result-code AVPs that require Failed-AVPs, need a clarification whether this is done only by the home server, or by any proxy/relay on the way - In 9.0, what about errors regarding invalid length (packet or AVP)? Especially for AVPs, since it will be difficult to include a correctly formatted AVP if length is wrong anyway? - In 5.3.2/9.1, DIAMETER_REDIRECT_INDICATION is not defined. - clarify the difference between UNABLE_TO_DELIVER and NOT_SERVED? i.e. in which case is which sent? -- "I know the domain, but cannot reach any servers" vs "I don't know the domain". - any specific messages for DNS errors (transient such as timeouts, or permanent such as NXDOMAIN)? -- I'd prefer we not have any, buy if you feel it is necessary, please propose some text. - the difference between AUTHORIZATION_REJECTED and AUTHORIZATION_FAILED is, er, unclear. - NO_COMMON_APPLICATION and UNSUPPORTED_VERSION would be better off in Protocol errors? -- except that protocol errors MUST only be used in MRA... see the problem :) - protocol errors should be usable in any non-'P' messages - missing errors for message or AVP length errors - missing errors for unknown not-proxiable commands? - missing errors for incorrectly set proxiable/not-proxiable flag? - missing errors for unknown application - classification of transient/permanent/protocol errors to review I will send in some text asap. Comments/suggestions welcome. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Thu Jun 14 12:27:52 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03519 for ; Thu, 14 Jun 2001 12:27:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EDC2E91332; Thu, 14 Jun 2001 12:27:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C12B991333; Thu, 14 Jun 2001 12:27:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9B04691332 for ; Thu, 14 Jun 2001 12:27:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C03BB5DD93; Thu, 14 Jun 2001 12:28:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by segue.merit.edu (Postfix) with SMTP id 33CC05DD8C for ; Thu, 14 Jun 2001 12:28:15 -0400 (EDT) Received: from pc114.etc.psi.com (HELO jc.yahoo.com) (195.94.40.114) by smtp.mail.vip.sc5.yahoo.com with SMTP; 14 Jun 2001 16:27:45 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010613175522.00c604e0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 14 Jun 2001 18:24:08 +0200 To: aaa-wg@merit.edu From: Jacques Caron Subject: [AAA-WG]: [Issue] Editorial changes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Jacques Caron Submitter email address: jacques_m_caron@yahoo.com Date first submitted: 14-Jun-2001 Reference: Document: Base Comment type: E Priority: 2 Section: throughout Rationale/Explanation of issue: - in Definition of End-to-end identifier, included definition for locally consumed incorrect. Reference appropriate section. - 15.1.2 is not up to date (bit numbers) - 15.4 does not include protocol errors - In 10.3, update Session-ID format with full Diameter-Identity - All AVPs share same scope/numbering space (even inside a Grouped-AVP) - M AVP within a non-M grouped AVP - in 10.3 second paragraph, remove reference to multiple Session-IDs. This is just to formally open the issue. I will send in some text tomorrow. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Thu Jun 14 12:28:02 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03529 for ; Thu, 14 Jun 2001 12:28:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9048E91334; Thu, 14 Jun 2001 12:27:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5573C91333; Thu, 14 Jun 2001 12:27:41 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 223AD91334 for ; Thu, 14 Jun 2001 12:27:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 462B35DD93; Thu, 14 Jun 2001 12:28:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by segue.merit.edu (Postfix) with SMTP id C29E15DD8C for ; Thu, 14 Jun 2001 12:28:16 -0400 (EDT) Received: from pc114.etc.psi.com (HELO jc.yahoo.com) (195.94.40.114) by smtp.mail.vip.sc5.yahoo.com with SMTP; 14 Jun 2001 16:27:47 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010614173009.00be37d0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 14 Jun 2001 18:26:56 +0200 To: aaa-wg@merit.edu From: Jacques Caron Subject: [AAA-WG]: [Issue] Route-Record change Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Jacques Caron Submitter email address: jacques_m_caron@yahoo.com Date first submitted: 14-Jun-2001 Reference: Document: Base Comment type: T Priority: 2 Section: throughout Rationale/Explanation of issue: Change route-record to include the host which we received the request from rather than ourselves. - removes need for checking Route-Record matches on receipt - removes need to check Origin-Host for loops (or saves one hop in loops involving origin-host) Not 100% sure it is better, but it just feels so :-) Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Thu Jun 14 12:31:15 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03568 for ; Thu, 14 Jun 2001 12:31:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5C8CF91333; Thu, 14 Jun 2001 12:30:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 29DFC91335; Thu, 14 Jun 2001 12:30:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 07C7891333 for ; Thu, 14 Jun 2001 12:30:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2B2495DD92; Thu, 14 Jun 2001 12:31:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by segue.merit.edu (Postfix) with SMTP id A53085DD8C for ; Thu, 14 Jun 2001 12:31:14 -0400 (EDT) Received: from pc114.etc.psi.com (HELO jc.yahoo.com) (195.94.40.114) by smtp.mail.vip.sc5.yahoo.com with SMTP; 14 Jun 2001 16:30:45 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010614182718.00bee550@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 14 Jun 2001 18:27:52 +0200 To: aaa-wg@merit.edu From: Jacques Caron Subject: [AAA-WG]: [Issue] Reauthorization issues Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Jacques Caron Submitter email address: jacques_m_caron@yahoo.com Date first submitted: 14-Jun-2001 Reference: Document: Base Comment type: T Priority: 1 Section: throughout Rationale/Explanation of issue: Reauth clarifications: - In 10.7 (and elsewhere) clarify Authorization-Lifetime (means Reauth should be performed) and Session-Timeout. Resources should be liberated upon Session-Timeout only, not upon Authorization-Lifetime expiration. - Change name of Authorization-Lifetime to Reauthorization-Timeout - Authorization-Lifetime and Session-Timeout based from start of Session or from receipt of message (in reauth)? - In reauth, is it allowed to change authorization parameters (filters, IPs...)? Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Thu Jun 14 12:32:28 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03618 for ; Thu, 14 Jun 2001 12:32:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E85D991335; Thu, 14 Jun 2001 12:30:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E303391336; Thu, 14 Jun 2001 12:30:40 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BAE3E91335 for ; Thu, 14 Jun 2001 12:30:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DD59F5DD93; Thu, 14 Jun 2001 12:31:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by segue.merit.edu (Postfix) with SMTP id 6463F5DD8C for ; Thu, 14 Jun 2001 12:31:18 -0400 (EDT) Received: from pc114.etc.psi.com (HELO jc.yahoo.com) (195.94.40.114) by smtp.mail.vip.sc5.yahoo.com with SMTP; 14 Jun 2001 16:30:48 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010614182800.00c14420@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 14 Jun 2001 18:29:10 +0200 To: aaa-wg@merit.edu From: Jacques Caron Subject: [AAA-WG]: [Issue] Routing/forwarding clarifications Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Jacques Caron Submitter email address: jacques_m_caron@yahoo.com Date first submitted: 14-Jun-2001 Reference: Document: Base Comment type: T Priority: 1 Section: throughout Rationale/Explanation of issue: - If multiple hosts listed for a given realm (redirect, relay, proxy), use the same one for a given Session (either need to maintain Session state or to use some hash function based on Session-ID) unless error occurs (and then keep that one that works). - Clarify if connections to peers are supposed to be opened at startup, or when needed only. - Clarify relationship of server discovery (SLP, DNS A, DNS SRV...) with peer table and/or routing table. - move peer and routing table description earlier in the doc (somewhere in 2.5 or 2.6). - Clarify whether "on-demand" connections (e.g. Redirect-Host with certificate) should timeout. - refuse connection to oneself Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Thu Jun 14 12:54:42 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04028 for ; Thu, 14 Jun 2001 12:54:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DE3E191336; Thu, 14 Jun 2001 12:54:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A981191337; Thu, 14 Jun 2001 12:54:48 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 877F991336 for ; Thu, 14 Jun 2001 12:54:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B523D5DD92; Thu, 14 Jun 2001 12:55:26 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 296865DD8C for ; Thu, 14 Jun 2001 12:55:26 -0400 (EDT) Received: (qmail 13773 invoked by uid 500); 14 Jun 2001 16:44:19 -0000 Date: Thu, 14 Jun 2001 09:44:19 -0700 From: Pat Calhoun To: Bernard Aboba Cc: David Spence , Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 29: IPv6 AVPs Message-ID: <20010614094418.R17928@charizard.diameter.org> Mail-Followup-To: Bernard Aboba , David Spence , Pat Calhoun , aaa-wg@merit.edu References: <3B27CD45.78404CA8@Interlinknetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from aboba@internaut.com on Thu, Jun 14, 2001 at 08:30:21AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, Jun 14, 2001 at 08:30:21AM -0700, Bernard Aboba wrote: > > > contains the name of an assigned pool that SHOULD be used to assign > > > an IPv6 prefix for the user. If the access device does not support > > > multiple prefix pools, it SHOULD ignore this AVP. > > Glen Zorn has recommended that the SHOULD be changed to MUST, and I've > updated the latest version to reflect this. ok. btw, it is mandatory that I get the RADIUS attribute numbers before the NASREQ spec can be sent to the RFC editor. Is there anyway that you could send in the IANA request (alternatively, I can do it if you don't have time). Thanks, PatC From owner-aaa-wg@merit.edu Thu Jun 14 14:09:19 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06002 for ; Thu, 14 Jun 2001 14:09:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 271F591338; Thu, 14 Jun 2001 14:09:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EC95D91339; Thu, 14 Jun 2001 14:09:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9BE2891338 for ; Thu, 14 Jun 2001 14:09:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BDDBC5DD96; Thu, 14 Jun 2001 14:09:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from redmailwall2.attws.com (redmailwall2.attws.com [199.108.253.116]) by segue.merit.edu (Postfix) with ESMTP id 1F2255DD8C for ; Thu, 14 Jun 2001 14:09:51 -0400 (EDT) Received: from viruswall1.entp.attws.com (viruswall1.entp.attws.com [135.214.40.161]) by redmailwall2.attws.com (8.9.3/8.9.3) with ESMTP id LAA28734; Thu, 14 Jun 2001 11:06:47 -0700 (PDT) Received: from neastmail.neast.attws.com by viruswall1.entp.attws.com (8.8.8+Sun/AT&T Wireless Services, Inc. V8 version 2) id LAA20703; Thu, 14 Jun 2001 11:08:47 -0700 (PDT) Received: from ner-msgbh.wireless.attws.com (ner-msgbh.wireless.attws.com [135.216.177.192]) by neastmail.neast.attws.com (8.8.8+Sun/8.8.8) with ESMTP id LAA29534; Thu, 14 Jun 2001 11:08:45 -0700 (PDT) Received: by ner-msgbh.wireless.attws.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Jun 2001 14:08:43 -0400 Message-ID: <0D3BDFD96647D211B43A00805F15E589050868DA@ner-msg03.wireless.attws.com> From: "Kobylarz, Thaddeus" To: "'Pat Calhoun'" , aaa-wg@merit.edu, "'3GPP_TSG_SA_WG5@LIST.ETSI.FR'" <3GPP_TSG_SA_WG5@LIST.ETSI.FR> Cc: "Molchan, John" , "Engelhart, Bob" Subject: RE: [AAA-WG]: Issue 5: 3GPP2 Accounting Requirements Date: Thu, 14 Jun 2001 14:08:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Pat, I'm still trying to "catch-up" with my e-mail. Correlation of charges is very important and I would like to have the 3GPP SA5 folks think about the process you describe in the attached before it becomes final. I hope it's not too late to consider suggestions. My opinion is that the process is correct and have no comments. Others may have different conclusions. Thad SA5 folks, Please examine the process, described below, in dealing with correlation. If you have comments, please reply on the SA5 reflector and I will forward them to the AAA reflector. Again, time is of the essence. Please reply ASAP. Thanks, Thad -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Thursday, June 07, 2001 5:00 PM To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 5: 3GPP2 Accounting Requirements All, A few of us got together on the phone today to try to iron out some of the remaining issues, and I will be sending out how we propose to close any remaining issues (well, we haven't been through them all... yet). In this particular issue, the problem is how to do accounting record correlation when many accounting "subsessions" are needed. 3GPP2, btw, has a requirement for this, and have addressed this in a largely proprietary nature. We would prefer to detail how this should be done to ensure consistency across services. So, we agreed that the protocol already had the necessary components, but the lack of clarity was what caused this issue to be opened. Here is my proposed text to be included in the base protocol: 11.6 Correlation of Accounting Records The Diameter protocol's Session-Id AVP, which is globally unique (see section 10.3), is used during the authorization phase to identify a particular session. Services that do not require any authorization still use the Session-Id AVP to identify sessions. However, there are certain applications that require multiple accounting sub-sessions. Such applications would send messages with a constant Session-Id AVP, but a different Accounting-Session-Id AVP. In these cases, correlation is performed using the Session-Id. Furthermore, there are certain applications where a user receives service from different access devices (e.g. Mobile IP), each with their own unique Session-Id. In such cases, the Accounting-Multi- Session-Id AVP is used for correlation. During authorization, a server that determines that a request is for an existing session, SHOULD include the Accounting-Multi-Session-Id AVP, which the access device MUST include in all subsequent accounting messages. The Accounting-Multi-Session-Id AVP MAY include the value of the original Session-Id. It's contents are implementation specific, but MUST be globally unique across other Accounting-Multi-Session-Id, and MUST NOT change during the life of a session. Thanks, PatC From owner-aaa-wg@merit.edu Thu Jun 14 17:02:10 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09769 for ; Thu, 14 Jun 2001 17:02:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7742D9122D; Thu, 14 Jun 2001 17:02:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 494029122E; Thu, 14 Jun 2001 17:02:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CD9B09122D for ; Thu, 14 Jun 2001 17:02:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3C15D5DDD3; Thu, 14 Jun 2001 17:02:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by segue.merit.edu (Postfix) with ESMTP id 564D45DD8C for ; Thu, 14 Jun 2001 17:02:49 -0400 (EDT) Received: from jariws1 ([62.248.155.83]) by fep01-app.kolumbus.fi (InterMail vM.5.01.02.00 201-253-122-103-20001017) with SMTP id <20010614210219.QYRQ28442.fep01-app.kolumbus.fi@jariws1> for ; Fri, 15 Jun 2001 00:02:19 +0300 Message-ID: <00f401c0f515$52af1c60$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: References: Subject: [AAA-WG]: Possibly editorial issues in cms-sec Date: Fri, 15 Jun 2001 00:02:29 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter name: Jari Arkko Submitter email address: jari@arkko.com Date first submitted: 14-June-2001 Reference: Document: cmssec Comment type: editorial (?) Priority: 2 Section: 1 & 4 Proprietary Tag: C Rationale/Explanation of issue: - Figure 3 still uses ESSR term, should be DSAR. Search for more instances just to make sure there are none... - Last paragraph of 1.2, "Allowing the first hop agent to use establish the DSA" seems to have some strange wording? => "... to be used to establish ... "? - PDSA has the CMS-Signed-Data AVP which I believe shouldn't be there. The security is from the proxy to the home, so no signatures for the NAS in this case. Right? Same issue for PDSA and Expected-*-AVP. From owner-aaa-wg@merit.edu Thu Jun 14 17:12:25 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09879 for ; Thu, 14 Jun 2001 17:12:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B793091230; Thu, 14 Jun 2001 17:12:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8BA0A91231; Thu, 14 Jun 2001 17:12:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6CFB991230 for ; Thu, 14 Jun 2001 17:12:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E784A5DDD3; Thu, 14 Jun 2001 17:13:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by segue.merit.edu (Postfix) with ESMTP id 18ABE5DD8C for ; Thu, 14 Jun 2001 17:13:01 -0400 (EDT) Received: from jariws1 ([62.248.155.83]) by fep01-app.kolumbus.fi (InterMail vM.5.01.02.00 201-253-122-103-20001017) with SMTP id <20010614211231.QZVT28442.fep01-app.kolumbus.fi@jariws1> for ; Fri, 15 Jun 2001 00:12:31 +0300 Message-ID: <00ff01c0f516$bf9d0c00$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: References: <00f401c0f515$52af1c60$8a1b6e0a@arenanet.fi> Subject: [AAA-WG]: Issue 62: e2e unnecessary step via pkcs7-mime Date: Fri, 15 Jun 2001 00:12:41 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit There seems to be two uses of MIME in the spec, first in the beginning of 6.1 the AVPs are MIME-encoded. Then in the end of 6.1 the CMS-Encrypted-Data AVP is pkcs7-mime encoded. At the beginning of 6.1 we also have some explanation that S/MIME toolkits can be used unchanged. Is this the reason for going through MIME always, or are there others? Is the ability to put in multiple AVPs dependent on MIME multipart? Has someone actually verified that most S/MIME toolkits don't allow you direct CMS operations? Jari From owner-aaa-wg@merit.edu Thu Jun 14 17:20:47 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09954 for ; Thu, 14 Jun 2001 17:20:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1314E91231; Thu, 14 Jun 2001 17:20:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D517391339; Thu, 14 Jun 2001 17:20:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 87D5C91231 for ; Thu, 14 Jun 2001 17:20:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E4FC45DDDC; Thu, 14 Jun 2001 17:21:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by segue.merit.edu (Postfix) with ESMTP id 160265DD8C for ; Thu, 14 Jun 2001 17:21:21 -0400 (EDT) Received: from jariws1 ([62.248.155.83]) by fep02-app.kolumbus.fi (InterMail vM.5.01.02.00 201-253-122-103-20001017) with SMTP id <20010614212051.CZJF26891.fep02-app.kolumbus.fi@jariws1> for ; Fri, 15 Jun 2001 00:20:51 +0300 Message-ID: <010301c0f517$e976bde0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: References: <00f401c0f515$52af1c60$8a1b6e0a@arenanet.fi> Subject: [AAA-WG]: Cms-sec optimization for pdsr-case Date: Fri, 15 Jun 2001 00:21:01 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter name: Jari Arkko Submitter email address: jari@arkko.com Date first submitted: 14-June-2001 Reference: Document: cmssec Comment type: Technical Priority: 2 Section: 4.3 Rationale/Explanation of issue: If the DSAR-Target-Domain was optional instead of mandatory in PDSR, then a NAS could give the proxy full responsibility to handle the CMS security towards the home for all domains. Today, the NAS has to initiate a PDSR-PDSA pair for each new domain it sees. Even if the CMS security association already existed between the local domain's proxy and the home... after all, it is likely that an aggregation point would already have seen the domain. From owner-aaa-wg@merit.edu Thu Jun 14 17:58:54 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10433 for ; Thu, 14 Jun 2001 17:58:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DDA769133B; Thu, 14 Jun 2001 17:58:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A6D3E9133C; Thu, 14 Jun 2001 17:58:49 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 910A59133B for ; Thu, 14 Jun 2001 17:58:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F40865DDA5; Thu, 14 Jun 2001 17:59:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from gate.internaut.com (unknown [64.38.134.101]) by segue.merit.edu (Postfix) with ESMTP id 6BF395DD8C for ; Thu, 14 Jun 2001 17:59:27 -0400 (EDT) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f5ELgb329724 for ; Thu, 14 Jun 2001 14:42:37 -0700 From: "Bernard Aboba" To: "Aaa-Wg@Merit. Edu" Subject: [AAA-WG]: [Issue] EAP Support issues Date: Thu, 14 Jun 2001 14:58:58 -0700 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 14-June-2001 Reference: Document: NASREQ Comment type: T Priority: 1 Section: 4.0 Rationale/Explanation of issue: When using EAP, the NAS operates as a "pass through" and so NAS behavior is determined by the Diameter message type, *not* by the encapsulated EAP message. For example: a. It is not required that an Accept or Reject message contain an EAP-Message AVP. b. If an EAP-Message AVP is included, it is not required that it correspond to the message type. For example, an EAP-Failure can be encapsulated within an Access-Accept, and an EAP-Success can be encapsulated within an Access-Reject. To allow correct operation in these cases, the NAS behavior MUST be determined by the Diameter message type alone. This means that a Reject message must result in termination of the authentication conversation, an Accept message must result in allowing access, and a challenge results in continuing the conversation. How the success/failure is communicated to the user is a subject for RFC 2284 and potential updates (RFC 2284bis), and need not concern us in specifying the Diameter behavior. Note that there has been discussion as to whether an EAP-Success or EAP-Failure may be encapsulated within a Challenge message. I believe that the answer to this is NO. Reasoning: Success and Failure messages are not ACK'd. Therefore the client will not respond, and thus the NAS will not have material with which to send another Request, unless it manufactures something on its own, which goes against the "passthrough" spirit of EAP. Thus, from a AAA perspective, an encapsulated EAP-Success or Failure message ends the authentication conversation and thus MUST be encapsulated within a final message (Accept or Reject) It has also been asked whether multiple EAP methods may be used to conduct a single authentication. This is really an EAP issue, but with respect to AAA, I believe that the answer is that it is not possible to encapsulate multiple EAP Success or Failure messages within a single AAA conversation, because of the above reasoning. However, it would be possible for a AAA server to conduct a conversation of one type, then switch to another type, and finally, to send an EAP Success or EAP Failure message at the end, encapsulated within an Accept or Reject. Requested change: PPP-specific references to be removed (EAP can be used with IEEE 802 as well). Text to be added to Section 4.0 articulating the above. From owner-aaa-wg@merit.edu Thu Jun 14 18:19:49 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10735 for ; Thu, 14 Jun 2001 18:19:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3442391232; Thu, 14 Jun 2001 18:19:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 083F191233; Thu, 14 Jun 2001 18:19:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 784E191232 for ; Thu, 14 Jun 2001 18:19:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 15CCD5DDA5; Thu, 14 Jun 2001 18:20:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by segue.merit.edu (Postfix) with ESMTP id BC0ED5DD93 for ; Thu, 14 Jun 2001 18:20:21 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id PAA05473 for ; Thu, 14 Jun 2001 15:19:52 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id PAA26439 for ; Thu, 14 Jun 2001 15:13:14 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Jun 2001 17:19:51 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECF3A@IL27EXM10.cig.mot.com> From: Cain Brian-BCAIN1 To: "'Jacques Caron'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: [Issue] DiameterIdentity (host descriptor) matching & values Date: Thu, 14 Jun 2001 17:19:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk > -----Original Message----- > From: Jacques Caron [mailto:jacques_m_caron@yahoo.com] > ... > Rationale/Explanation of issue: > > We need to clarify how two host descriptors are matched, e.g. in loop > matching. Options are: 1. > - exact lexical match (strcmp) 2. > - expand (add defaults such as diameter://, :port, and > ;transport=sctp), > then exact lexical match (or match on protocol+name+port+transport) 3. > - expand name to IP addresses, and match on > protocol+IP+port+transport (if > name resolves to multiple IP addresses, any match between the two > expansions is a match) The way I've implemented it is pretty much along the lines of your second option. I have an independent match of each component, but the end result is the same as a string compare with defaults added. The first option is not in the spirit of the default values, IMO. I don't think I can provide a real good reason as to why the third option is bad, I think I just prefer the second. The third may provide the most absolute identitifiability, though. > First is possible only if any given process picks a unique ... > received in CER/CEA in an AVP. It cannot work when the > DiameterIdentity > comes from another source (e.g. from a configuration file > listing peers). Well, you would always get an identity from a peer once the connection was established anyways. If the identity they announce is different from the one you used to locate them, you can take whatever action necessary, but if the connection remains, the identity received from the peer should be authoritative. I was under the impression that the Diameter Identity was more of an entity-distinction tool than an entity-location tool. Not to say that it couldn't function as both, but maybe its primary service should be the former. ... > Requested changes: > > At the end of section 2.7, add: > The port and protocol listed above are those that a node uses to > listen for incoming connections. More explicit, I like it. > When a process listens on multiple different addresses or > ports or > using different > protocols, it should select a single combination of > those, and always > use the same value as its identity for the lifetime of all > connections to peers. This value should be sent in Origin-Host in > CER/CEA and other messages, used in Route-Record AVPs, > and any other > AVPs containing DiameterIdentity. WRT SCTP's use of multiple addresses, this text is in 6.7: (Doesn't correspond directly to what you're discussing, but it's related) "All source addresses that a Diameter node expects to use with SCTP [26] MUST be advertised in the CER and CEA messages by including a Host-IP-Address AVP for each address." > For the purposes of loop checking and other comparison > purposes, two > DiameterIdentity values match if they are lexically > identical (i.e. > the two strings are the same). As long as you insert the relevant default values for fields where necessary, ok. "diameter://host.abc.com" should definitely match "host.abc.com", don't you think? -Brian From owner-aaa-wg@merit.edu Thu Jun 14 19:25:58 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11225 for ; Thu, 14 Jun 2001 19:25:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6A58C91234; Thu, 14 Jun 2001 19:25:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3E52791237; Thu, 14 Jun 2001 19:25:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EF56D91234 for ; Thu, 14 Jun 2001 19:25:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7F5515DDA4; Thu, 14 Jun 2001 19:26:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 82CCC5DD93 for ; Thu, 14 Jun 2001 19:26:29 -0400 (EDT) Received: (qmail 21571 invoked by uid 500); 14 Jun 2001 23:15:21 -0000 Date: Thu, 14 Jun 2001 16:15:21 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Proposed fix for Issue 25: Support for multi-process Message-ID: <20010614161521.Z17928@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, Below is the proposed text to close this issue. Thanks to Paul Funk and Mark Eklund for this text. Comments appreciated, PatC ---- 8.0 Peer State Machine This section contains a finite state machine, that MUST be observed by all Diameter implementations. Each Diameter node MUST follow the state machine described below when communicating with each peer. Multiple actions are separated by commas, and may continue on succeeding lines as space requires. Similarly, state and next state may also span multiple lines as space requires. There may be at most one transport connection between any two peers over which Diameter messages may be passed. This state machine is intended to handle both the simple case, in which one peer initiates a connection to the other, and the complex case, in which each peer simultaneously initiates a connection to the other. In the complex case, an election occurs to determine which transport connection will survive. I- is used to represent the initiator (connecting) connection, while the R- is used to represent the responder (listening) connection. The lack of a prefix indicates that the event or action is the same regardless of the connection on which the event occurred. The stable states that a state machine may be in are Closed, I-Open and R-Open; all other states are intermediate. Note that I-Open and R-Open are equivalent except for whether the initiator or responder transport connection is used for communication. A CER message is always sent on the initiating connection immediately after the connection request is successfully completed. In the case of an election, one of the two connections will shut down. The responder connection will survive if the Origin-Host of the local Diameter entity is higher than that of the peer; the initiator connection will survive if the peer's Origin-Host is higher. All subsequent messages are sent on the surviving connection. Note that the results of an election on one peer are guaranteed to be the inverse of the results on the other. The state machine constrains only the behavior of a Diameter implementation as seen by Diameter peers through events on the wire. Any implementation that produces equivalent results is considered compliant. state event action next state ----------------------------------------------------------------- Closed Start I-Snd-Conn-Req Wait-Conn-Ack R-Conn-CER R-Accept, R-Open Process_CER, R-Snd-CEA Wait-Conn-Ack I-Rcv-Conn-Ack I-Snd-CER Wait-I-CEA I-Rcv-Conn-Nack Cleanup Closed R-Conn-CER R-Accept, Wait-Conn-Ack/ Process-CER Elect Timeout Error Closed Wait-I-CEA I-Rcv-CEA Process-CEA I-Open R-Conn-CER R-Accept, Wait-Returns Process_CER, Elect I-Peer-Disc I-Disc Closed I-Rcv-Non-CEA Error Closed Timeout Error Closed Wait-Conn-Ack/ I-Rcv-Conn-Ack I-Snd-CER,Elect Wait-Returns Elect I-Rcv-Conn-Nack R-Snd-CEA R-Open R-Peer-Disc R-Disc Wait-Conn-Ack R-Conn-CER R-Reject Wait-Conn-Ack/ Elect Timeout Error Closed Wait-Returns Win-Election I-Disc,R-Snd-CEA R-Open I-Peer-Disc I-Disc,R-Snd-CEA R-Open I-Rcv-CEA R-Disc I-Open R-Peer-Disc R-Disc Wait-I-CEA R-Conn-CER R-Reject Wait-Returns Timeout Error Closed R-Open Send-Message R-Snd-Message R-Open R-Rcv-Message Process R-Open WatchDog-Timer R-Snd-DWR R-Open R-Rcv-DWR Process-DWR, R-Open R-Snd-DWA R-Rcv-DWA Process-DWA R-Open R-Conn-CER R-Reject R-Open Stop R-Disc Closed R-Peer-Disc R-Disc Closed R-Rcv-CER Error Closed R-Rcv-CEA Error Closed I-Open Send-Message I-Snd-Message I-Open I-Rcv-Message Process I-Open WatchDog-Timer I-Snd-DWR I-Open I-Rcv-DWR Process-DWR, I-Open I-Snd-DWA I-Rcv-DWA Process-DWA I-Open R-Conn-CER R-Reject I-Open Stop I-Disc Closed I-Peer-Disc I-Disc Closed I-Rcv-CER Error Closed I-Rcv-CEA Error Closed 8.1 Incoming connections When a connection request is received from a Diameter peer, it is not, in the general case, possible to know the identity of that peer until a CER is received from it. This is because the identity of a Diameter peer is determined by host and port; and the source port of an incoming connection is arbitrary. Upon receipt of CER, the identity of the connecting peer can be uniquely determined from Origin-Host. For this reason, a Diameter peer must employ logic separate from the state machine to receive connection requests, accept them, and await CER. Once CER arrives on a new connection, the Origin-Host which identifies the peer is used to locate the state machine associated with that peer, and the new connection and CER are passed to the state machine as an R-Conn-CER event. The logic that handles incoming connections SHOULD close and discard the connection if any message other than CER arrives, or if an implementation-defined timeout occurs prior to receipt of CER. Because handling of incoming connections up to and including receipt of CER requires logic separate from that of any individual state machine associated with a particular peer, it is described separately in this section rather than in the state machine below. 8.2 Events Transitions and actions in the automaton are caused by events. In this section we will ignore the -I and -R prefix, since the actual event would be identical, but would occur on one of two possible connections. Start The Diameter application has signaled that a connection should be initiated with the peer. R-Conn-CER A new incoming connection and associated CER has arrived. Rcv-Conn-Ack A positive acknowledgement was received to a locally initiated transport connection. Rcv-Conn-Nack A negative acknowledgement was received to a locally initiated transport connection. Timeout An application-defined timer has expired while waiting for some event. Rcv-CER A CER message from the peer was received. Rcv-CEA A CEA message from the peer was received. Rcv-Non-CEA A message other than CEA from the peer was received. Peer-Disc A disconnection indication from the peer was received. Win-Election An election was held, and the local node was the winner. Send-Message A message is to be sent. Rcv-Message A message other than CER, CEA, DWR, or DWA was received. WatchDog-Timer The Watchdog timer expired, indicating that a DWR message is to be sent to the peer. Rcv-DWR A DWR message was received. Rcv-DWA A DWA message was received. Stop The Diameter application has signaled that a connection should be terminated (e.g., on system shutdown). 8.3 Actions Actions in the automaton are caused by events and typically indicate the transmission of packets and/or an action to be taken on the connection. In this section we will ignore the I- and R- prefix, since the actual action would be identical, but would occur on one of two possible connections. Snd-Conn-Req A transport connection is initiated with the peer. Accept The incoming connection associated with the R- Conn-CER is accepted as the responder connection. Reject The incoming connection associated with the R- Conn-CER is disconnected. Process-CER The CER associated with the R-Conn-CER is processed. Snd-Conn-Ack an acknowledgement is sent in response to a connect request, confirming that the transport layer connection is open. Snd-CER A CER message is sent to the peer. Snd-CEA A CEA message is sent to the peer. Cleanup If necessary, the connection is shutdown, and any local resources are freed. Error The transport layer connection is disconnected, either politely or abortively, in response to an error condition. Local resources are freed. Process-CEA A received CEA is processed. Disc The transport layer connection is disconnected, and local resources are freed. Elect An election occurs (see Section 8.4 for more information). Snd-Message A message is sent. Snd-DWR A DWR message is sent. Snd-DWA A DWA message is sent. Process-DWR The DWR message is serviced. Process-DWA The DWA message is serviced. Process A message is serviced. 8.4 The Election Process The election is performed on the responder. The responder compares the Origin-Host received in the CER sent by its peer with its own Origin-Host. If the local Diameter entity's Origin-Host is higher than the peer's, a Win-Election event is issued locally. The comparison proceeds by considering the shorter OctetString to be null-padded to the length of the longer, then performing an octet by octet unsigned comparison with the first octet being most significant. Hanging octets are assumed to have value 0x80, but dimpled octets are ignored. From owner-aaa-wg@merit.edu Thu Jun 14 19:31:13 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11321 for ; Thu, 14 Jun 2001 19:31:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4B1139123D; Thu, 14 Jun 2001 19:30:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1B15D9133C; Thu, 14 Jun 2001 19:30:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 642809123D for ; Thu, 14 Jun 2001 19:30:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E44A75DDA4; Thu, 14 Jun 2001 19:31:20 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 8C9B45DD93 for ; Thu, 14 Jun 2001 19:31:20 -0400 (EDT) Received: (qmail 21585 invoked by uid 500); 14 Jun 2001 23:20:12 -0000 Date: Thu, 14 Jun 2001 16:20:12 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Correction: Proposed fix for Issue 25: Support for multi-process Message-ID: <20010614162012.A17928@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu References: <20010614161521.Z17928@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010614161521.Z17928@charizard.diameter.org>; from pcalhoun@diameter.org on Thu, Jun 14, 2001 at 04:15:21PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, Jun 14, 2001 at 04:15:21PM -0700, Pat Calhoun wrote: hmmmm... I forgot one small, yet very important detail. Please see the text below. PatC ---- > 8.0 Peer State Machine > > This section contains a finite state machine, that MUST be observed > by all Diameter implementations. Each Diameter node MUST follow the > state machine described below when communicating with each peer. > Multiple actions are separated by commas, and may continue on > succeeding lines as space requires. Similarly, state and next state > may also span multiple lines as space requires. > > There may be at most one transport connection between any two peers > over which Diameter messages may be passed. This state machine is > intended to handle both the simple case, in which one peer initiates > a connection to the other, and the complex case, in which each peer > simultaneously initiates a connection to the other. In the complex > case, an election occurs to determine which transport connection will > survive. > [notice the last sentence here that I have added] There may be at most one transport connection between any two peers over which Diameter messages may be passed. This state machine is intended to handle both the simple case, in which one peer initiates a connection to the other, and the complex case, in which each peer simultaneously initiates a connection to the other. In the complex case, an election occurs to determine which transport connection will survive. It is important to note that the port on which a connection is initiated MUST NOT be the port Diameter listens for incoming connections. [...] From owner-aaa-wg@merit.edu Thu Jun 14 20:04:09 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11685 for ; Thu, 14 Jun 2001 20:04:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 70E3391237; Thu, 14 Jun 2001 20:04:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3CBE09133C; Thu, 14 Jun 2001 20:04:05 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EDCE291237 for ; Thu, 14 Jun 2001 20:04:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 89E745DDA4; Thu, 14 Jun 2001 20:04:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id F34695DD93 for ; Thu, 14 Jun 2001 20:04:42 -0400 (EDT) Received: (qmail 21640 invoked by uid 500); 14 Jun 2001 23:53:34 -0000 Date: Thu, 14 Jun 2001 16:53:34 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 59: e2e mandatory status Message-ID: <20010614165334.B17928@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, I'd like to propose adding the following text to section 2.0 of the base protocol spec. This is the consensus of a few of us that chatted today. The general idea is to allow for NASes (and cheap embedded devices) NOT to require the complexity of including CMS and related code. However, we agreed that servers, and aggregating servers (read proxies) MUSt support it. Relay and redirectors MAY support it, since they are typically either transparent, or not in the path of the messages. Comments welcome, PatC ---- Diameter clients SHOULD support the CMS security application [11], while servers and proxy agents MUST support it. Relay and Redirector agents MAY support the CMS security application. From owner-aaa-wg@merit.edu Thu Jun 14 20:06:49 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11721 for ; Thu, 14 Jun 2001 20:06:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1D3629133C; Thu, 14 Jun 2001 20:06:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA8549133D; Thu, 14 Jun 2001 20:06:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B88CF9133C for ; Thu, 14 Jun 2001 20:06:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 573BC5DDA4; Thu, 14 Jun 2001 20:07:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 1274D5DD93 for ; Thu, 14 Jun 2001 20:07:24 -0400 (EDT) Received: (qmail 21652 invoked by uid 500); 14 Jun 2001 23:56:16 -0000 Date: Thu, 14 Jun 2001 16:56:16 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 61: e2e cms and pki profiling Message-ID: <20010614165616.C17928@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, After chatting with a few folks today, we agreed that it made sense to wait until some operational experience was gained before we could decide what fields in an X.509 certificate should be present, and which ones aren't needed. So, I added the following sentence to the CMS draft, which I'd like to receive comments on: " Note that once operational experience has been gained, a future document may specify a restricted profile of [4] in order to simplify implementation." Thanks, PatC From owner-aaa-wg@merit.edu Fri Jun 15 08:25:10 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04954 for ; Fri, 15 Jun 2001 08:25:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B12A391245; Fri, 15 Jun 2001 08:25:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7ADED91246; Fri, 15 Jun 2001 08:25:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 585D091245 for ; Fri, 15 Jun 2001 08:25:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 13B495DEC9; Fri, 15 Jun 2001 08:25:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id B6A1E5DE8D for ; Fri, 15 Jun 2001 08:25:40 -0400 (EDT) Received: (qmail 24279 invoked by uid 500); 15 Jun 2001 12:14:30 -0000 Date: Fri, 15 Jun 2001 05:14:30 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 59: e2e mandatory status Message-ID: <20010615051430.I17928@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu References: <20010614165334.B17928@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010614165334.B17928@charizard.diameter.org>; from pcalhoun@diameter.org on Thu, Jun 14, 2001 at 04:53:34PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, Jun 14, 2001 at 04:53:34PM -0700, Pat Calhoun wrote: All, I've received some comments that my fix was not actually complete, and would like to propose new text. First, the missing item was that the CMS spec contains two features. The first is to protect AVPS via CMS, and the second is the message that an access device may send to request that an agent establish a security association with a server in a target realm. This latter part must be supported by access devices, as it is very simple, and doesn't require the complexity of CMS on the embedded device. This is the first time, though, that we define that a portion of a Diameter application needs to be supported, while another portion is optional, and begs the question on whether these should really be two separate applications. Anyways, here is the text: The CMS Diameter security application [11] contains two features: 1. A set of messages that allows a Diameter node to establish a security association, which is used to secure AVPs within a Diameter message, even though the message may traverse intermediate Diameter agents. A set of AVPs are also defined to sign and encrypt AVPs, as well as to transport certificates. This feature MUST be supported by Diameter server and proxy agents, SHOULD be supported by Diameter clients, and MAY be supported by relay and redirector agents. 2. A set of messages that allows a Diameter client to request that an agent establish a Diameter security association with a server in a specific realm. This feature MUST be supported by Diameter clients and Proxy agents, and MAY be supported by Diameter servers, relay and redirector agents. Thanks, PatC From owner-aaa-wg@merit.edu Fri Jun 15 08:58:57 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06076 for ; Fri, 15 Jun 2001 08:58:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9C42F91246; Fri, 15 Jun 2001 08:58:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6E0E591247; Fri, 15 Jun 2001 08:58:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3B57091246 for ; Fri, 15 Jun 2001 08:58:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E6D9E5DDCC; Fri, 15 Jun 2001 08:59:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 62F465DDC8 for ; Fri, 15 Jun 2001 08:59:31 -0400 (EDT) Received: (qmail 24906 invoked by uid 500); 15 Jun 2001 12:48:20 -0000 Date: Fri, 15 Jun 2001 05:48:20 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 74: Do not use Route-Record for answer routing Message-ID: <20010615054820.K17928@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, Following our chat yesterday, we agreed with this issue. Basically, this issue states that since each agent needs to maintain a list of pending messages (for failover purposes), the presence of the Route-Record in answer messages for routing purposes is superfluous. The list of pending messages could easily include the source of the request, and including the Route-Record AVP simply introduces the possibility for conflicting information. The following sections include the new text, and I would appreciate any comments. Thanks, PatC ---- 5.1.9 Relaying and Proxying Requests A relay or proxy agent MUST check for forwarding loops before forwarding requests. A loop is detected if the server finds its own address in a Route-Record AVP. When such an event occurs, the agent MUST answer with the Result-Code AVP set to DIAMETER_LOOP_DETECTED. A relay or proxy agent MUST append a Route-Record AVP that includes its identity to all requests forwarded. The last Route-Record AVP in all requests received MUST be validated, by ensuring that the host encoded in the AVP is the same as the peer the message was received from. The Hop-by-Hop identifier in the request is saved, and replaced with a locally unique value. The source of the request is also saved, which includes the IP address, port and protocol. Relay and Proxy agents MAY include the Proxy-Info AVP in requests if it requires access any local state information when the corresponding response is received. Alternatively, it MAY simply use local storage to store state information. The message is then forwarded to the next hop, as identified in the Domain Routing Table. Figure 6 provides an example of message routing using the procedures listed in these sections. (Origin-Host=nas.mno.net) (Origin-Host=nas.mno.net) (Origin-Realm=mno.net) (Origin-Realm=mno.net) (Destination-Realm=abc.com) (Destination-Realm=abc.com) (Route-Record=drl.mno.net) +------+ ------> +------+ ------> +------+ | | (Request) | | (Request) | | | NAS +-------------------+ DRL +-------------------+ HMS | | | | | | | +------+ <------ +------+ <------ +------+ mno.net (Answer) mno.net (Answer) abc.com (Origin-Host=hms.abc.com) (Origin-Host=hms.abc.com) (Origin-Realm=abc.com) (Origin-Realm=abc.com) Figure 6: Routing of Diameter messages 5.2 Diameter Answer Processing When an request is locally processed, the following procedures MUST be applied to create the associated answer, in addition to any additional procedures that MAY be discussed in the Diameter application defining the command: - The same Hop-by-Hop identifier in the request is used in the answer. - The local host's identity is encoded in the Origin-Host AVP. - The Destination-Host and Destination-Realm AVPs MUST NOT be present in the answer message. - The Result-Code AVP is added with its value indicating success or failure. - If the Session-Id is present in the request, it MUST be included in the answer. - Any Proxy-Info AVPs in the request MUST be added to the answer message, in the same order they were present in the request. [...] 5.2.2 Relaying and Proxying Answers If the answer is for a request which was proxied or relayed, the agent MUST restore the original value of the Diameter header's Hop- by-Hop Identifier field. If the last Proxy-Info AVP in the message is targeted to the local Diameter server, the AVP MUST be removed before the answer is forwarded. If a relay or proxy agent receives an answer with a Result-Code AVP indicating a failure, it MUST NOT modify the contents of the AVP. Any additional local errors detected SHOULD be logged, but not reflected in the Result-Code AVP. If the agent receives an answer message with a Result-Code AVP indicating success, and it wishes to modify the AVP to indicate an error, it MUST issue an STR on behalf of the access device. The agent MUST then send the answer to the host which it received the original request from. 5.3 Hiding Network Topology A Relay or Proxy agent routing messages outside of their administrative domain MAY need to hide the internal Diameter topology. This is done by removing all Route-Record AVPs in a request. [and additional changes to the tables in section 14, which I will not bother to list here] From owner-aaa-wg@merit.edu Fri Jun 15 10:01:10 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08690 for ; Fri, 15 Jun 2001 10:01:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C3F449124A; Fri, 15 Jun 2001 10:00:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 99D7F91344; Fri, 15 Jun 2001 10:00:28 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7E79A9124A for ; Fri, 15 Jun 2001 10:00:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 537EF5DDB2; Fri, 15 Jun 2001 10:01:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id C5E495DDAC for ; Fri, 15 Jun 2001 10:01:05 -0400 (EDT) Received: (qmail 25964 invoked by uid 500); 15 Jun 2001 13:49:54 -0000 Date: Fri, 15 Jun 2001 06:49:54 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 77: Possibility for implicit termination of an Authentication or Authorization Message-ID: <20010615064954.M17928@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, Below is the text that I would like to propose to close this issue. It is consistent with the discussions on the list so far. Thanks, PatC ---- 10.0 Diameter User Sessions [...] An access device MAY include an Authorization-Lifetime AVP with a value of zero to inform the Diameter server that the authorization requested will only occur once, and no further auth messages are to be sent with this particular session identifier. The Diameter server MAY accept the hint from the access device, or it MAY override the Authorization-Lifetime in the answer message with a non-zero value. By accepting an Authorization-Lifetime with a zero value, the Diameter server agrees that it will not receive a indication of session termination once service to the user is terminated, and therefore cannot maintain state for the session. Note that a zero Authorization-Lifetime MUST NOT be used in subsequent re- authorization messages. [editor's note: below I changed the two pending states to handle the case where a zero and non-zero authorization lifetime is included in the authorization message, and a new state called active to handle the case of a zero authorization-lifetime, which implies no STR. I don't particularly like Active as a name, but it is better than my previous attempt, which was limbo :) 10.1 Authorization Session State Machine [...] The following table contains the authorization session state machine. State Event Action New State ------------------------------------------------------------- [...] Pending Successful Service-Specific Grant Open Authorization answer Access received with non-zero Authorization-Lifetime Pending Successful Service-Specific Grant Active Authorization answer Access received with zero Authorization-Lifetime [...] Active Service to user is terminated Cleanup Closed [...] [editor's note: Below I modified the last sentence in the paragraph] 10.4 Authorization-Lifetime AVP [...] This AVP MAY be provided by the client as a hint of the maximum duration that it is willing to accept. However, the server DOES NOT have to observe the hint, and MAY return a value that is smaller than the hint. A value of zero means that no re-authorization is required, and no session termination message will be sent to the Diameter server. From owner-aaa-wg@merit.edu Fri Jun 15 10:12:02 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09419 for ; Fri, 15 Jun 2001 10:12:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9AA7A9124B; Fri, 15 Jun 2001 10:11:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6E8AB9124C; Fri, 15 Jun 2001 10:11:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3FD519124B for ; Fri, 15 Jun 2001 10:11:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0BF2C5DDB2; Fri, 15 Jun 2001 10:12:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id AD57C5DD96 for ; Fri, 15 Jun 2001 10:12:37 -0400 (EDT) Received: (qmail 26003 invoked by uid 500); 15 Jun 2001 14:01:26 -0000 Date: Fri, 15 Jun 2001 07:01:26 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 66: Server Discovery Message-ID: <20010615070126.N17928@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, Following a discussion with Bernard, I now understand what he wanted fixed in this particular issue. Please see the proposed text below, where the change is in sub-section 3.3. The new text simply states that if SVR records aren't found, then other record types are used. comments appreciated, PatC ---- 2.6 Diameter Agent Discovery [...] 3. The Diameter implementation uses DNS to request the SRV RR [33] for the '_diameter._sctp' and/or '_diameter._tcp' server in a particular domain. The Diameter implementation has to know in advance which domain to look for a Diameter agent in. This could be deduced, for example, from the 'realm' in a NAI that a Diameter implementation needed to perform a Diameter operation on. 3.1 If the destination address is a numeric IP address, the requestor contacts the peer at the given address and the port number specified in the SRV record or, if not specified, the default port (TBD). 3.2 The results of the query or queries are merged and ordered based on priority. Then, the searching technique outlined in [46] is used to select servers in order. The requestor attempts to contact each peer in the order listed, at the port number specified in the SRV record. If none of the servers can be contacted, the requestor gives up. If there are no SRV records, DNS address records are used, as described below. 3.3 If the destination specifies a port number other than TBD or if there are no SRV records, the requestor queries the DNS server for address records for the destination address '_diameter._sctp'.domain or '_diameter._tcp'.domain. Address records include A RR's, AAAA RR's, A6 RR's or other similar records, chosen according to the requestor's network protocol capabilities. If the DNS server returns no address records, the requestor gives up. If there are address records, the same rules as in step 3.2 apply. From owner-aaa-wg@merit.edu Fri Jun 15 10:31:11 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10443 for ; Fri, 15 Jun 2001 10:31:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3884F9124D; Fri, 15 Jun 2001 10:30:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 085FA91346; Fri, 15 Jun 2001 10:30:48 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 66ACA9124D for ; Fri, 15 Jun 2001 10:30:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2B9635DDAD; Fri, 15 Jun 2001 10:31:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 9A7065DD96 for ; Fri, 15 Jun 2001 10:31:26 -0400 (EDT) Received: (qmail 26044 invoked by uid 500); 15 Jun 2001 14:20:15 -0000 Date: Fri, 15 Jun 2001 07:20:15 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 37: Home State Blob Message-ID: <20010615072015.P17928@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, After a discussion yesterday, we were able to recover the original issue, and the following is the issue submission. I'd like comments on the proposed text. Thanks, PatC ---- Issue 37: Home State Blob Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: June 15 20001 Reference: Document: Base Comment Type: Technical Priority: 2 Section: new section 10.16 Rationale/Explanation of issue: The RADIUS protocol defines the Class attribute, which allows for home servers to return some state information to the NAS. The Class attribute must be present in subsequent messages for the session. Requested change: Add following text in section 10: 10.16 Class AVP The Class AVP (AVP Code 25) is of type OctetString and is used to by Diameter servers to return state information to the access device. When one or more Class AVPs are present in application-specific authorization answer messages, they MUST be present in subsequent re-authorization and accounting messages. Class AVPs found in a re- authorization answer message override the ones found in any previous authorization answer message. From owner-aaa-wg@merit.edu Fri Jun 15 10:50:18 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10953 for ; Fri, 15 Jun 2001 10:50:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B965E9124E; Fri, 15 Jun 2001 10:50:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8738691344; Fri, 15 Jun 2001 10:50:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3E13F9124E for ; Fri, 15 Jun 2001 10:50:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 26EC95DDCC; Fri, 15 Jun 2001 10:50:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59]) by segue.merit.edu (Postfix) with SMTP id A14345DDB2 for ; Fri, 15 Jun 2001 10:50:52 -0400 (EDT) Received: from pc114.etc.psi.com (HELO jc.yahoo.com) (195.94.40.114) by smtp.mail.vip.sc5.yahoo.com with SMTP; 15 Jun 2001 14:50:22 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010615162947.00bf3510@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 15 Jun 2001 16:47:02 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 66: Server Discovery Cc: aaa-wg@merit.edu In-Reply-To: <20010615070126.N17928@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, Stupid question: isn't all this redundant with the RFC2782? Shouldn't we rather just point there for the whole scheme (look up the SRV RRs, how selection is done, then fall back to A RRs) rather than partially duplicating the thing? Duplication always makes me nervous, it leads to inconsistencies a bit too often :-( Also, why does 3.3 below state that "if the port is other than TBD..."? The whole point of SRV RRs is to be able to specify alternate ports... And maybe part of issue 83 (Clarify relationship of server discovery (SLP, DNS A, DNS SRV...) with peer table and/or routing table) should actually be handled in this issue. I still don't know if the use of DNS is an extension to the routing table (map a realm to a peer, but the peer must already be in our peer table), or to the routing AND peer table (map a realm to a peer created on the fly). I would think it's the former, but that needs to be clarified. If it's the latter, we have the issue of establishing a security association between the two hosts... Jacques. At 16:01 15/06/01, Pat Calhoun wrote: >All, > >Following a discussion with Bernard, I now understand what he wanted >fixed in this particular issue. Please see the proposed text below, >where the change is in sub-section 3.3. The new text simply states that >if SVR records aren't found, then other record types are used. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Fri Jun 15 10:51:06 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10986 for ; Fri, 15 Jun 2001 10:51:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F215F91344; Fri, 15 Jun 2001 10:51:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C33AB91346; Fri, 15 Jun 2001 10:51:05 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AF9D991344 for ; Fri, 15 Jun 2001 10:51:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 969285DDCC; Fri, 15 Jun 2001 10:51:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id DF2565DDB2 for ; Fri, 15 Jun 2001 10:51:41 -0400 (EDT) Received: (qmail 26333 invoked by uid 500); 15 Jun 2001 14:36:43 -0000 Date: Fri, 15 Jun 2001 07:36:43 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 86: Diameter URI Changes Message-ID: <20010615073643.Q17928@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, Here is a new issue, which I am creating to propose changes to the URI as a result of a review. My thanks for Leslie Daigle for her review. Comments appreciated, PatC ---- Issue 86: Diameter URI Changes Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: June 15 ,2001 Reference: Document: base Comment type: Technical Priority: S Section: 4.4 Rationale/Explanation of issue: This issue contains changes that resulted from a review of our current URI. Proposed Text: DiameterIdentity The DiameterIdentity format is derived from the OctetString AVP Base Format. It uses the UTF-8 encoding and has the same requirements as the UTF8String. In addition, it must follow the Uniform Resource Identifiers (URI) syntax [29] rules specified below: Diameter-Identity = [scheme-name] fqdn [ port ] [ transport ] scheme-name = "aaa://" aaa-protocol "/" ; If absent, the default BASE for relative URI references ; is aaa://diameter/ aaa-protocol = ( "diameter" | "radius" | "tacacs+" ) fqdn = Fully Qualified Host Name port = ":" 1*DIGIT ; If absent, the default Diameter port (TBD) is assumed. transport = ";transport=" ( "tcp" | "sctp" | "udp") ; If absent, the default SCTP [26] protocol is assumed. ; UDP is ONLY used when the protocol is set to RADIUS The following are examples of valid Diameter host identities: host.abc.com;transport=tcp host.abc.com:6666;transport=tcp aaa://diameter/host.abc.com aaa://diameter/host.abc.com:6666 aaa://diameter/host.abc.com:6666;transport=tcp aaa://radius/host.abc.com:1813;transport=udp The first two forms are relative URI references, against the default base of aaa://diameter/ From owner-aaa-wg@merit.edu Fri Jun 15 10:57:33 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11086 for ; Fri, 15 Jun 2001 10:57:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A111991346; Fri, 15 Jun 2001 10:57:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 702E491347; Fri, 15 Jun 2001 10:57:28 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5475C91346 for ; Fri, 15 Jun 2001 10:57:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2A1675DDCE; Fri, 15 Jun 2001 10:58:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id BFD975DDB2 for ; Fri, 15 Jun 2001 10:58:07 -0400 (EDT) Received: (qmail 26754 invoked by uid 500); 15 Jun 2001 14:46:56 -0000 Date: Fri, 15 Jun 2001 07:46:56 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 66: Server Discovery Message-ID: <20010615074656.R17928@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <20010615070126.N17928@charizard.diameter.org> <4.3.2.7.2.20010615162947.00bf3510@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010615162947.00bf3510@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Fri, Jun 15, 2001 at 04:47:02PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Fri, Jun 15, 2001 at 04:47:02PM +0200, Jacques Caron wrote: > Hi, > > Stupid question: isn't all this redundant with the RFC2782? Shouldn't we > rather just point there for the whole scheme (look up the SRV RRs, how > selection is done, then fall back to A RRs) rather than partially > duplicating the thing? Duplication always makes me nervous, it leads to > inconsistencies a bit too often :-( Not at all. RFC 2782 is a generic mechanism for locating SRV records, and the text on this really enhances RFC 2782. The last section (3.3) is what to do if no SRV records are found. > > Also, why does 3.3 below state that "if the port is other than TBD..."? The > whole point of SRV RRs is to be able to specify alternate ports... Much of this text was stolen from SIP, and now that I re-read this again, I see that this is not required, and will be removed. > > And maybe part of issue 83 (Clarify relationship of server discovery (SLP, > DNS A, DNS SRV...) with > peer table and/or routing table) should actually be handled in this issue. Personally, I'd prefer to keep it as a separate issue. > I still don't know if the use of DNS is an extension to the routing table > (map a realm to a peer, but the peer must already be in our peer table), or > to the routing AND peer table (map a realm to a peer created on the fly). I > would think it's the former, but that needs to be clarified. If it's the > latter, we have the issue of establishing a security association between > the two hosts... of course. Would you like me to take a shot at fixing #83? Thanks, PatC From owner-aaa-wg@merit.edu Fri Jun 15 11:16:55 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11524 for ; Fri, 15 Jun 2001 11:16:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3743891348; Fri, 15 Jun 2001 11:16:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0458991349; Fri, 15 Jun 2001 11:16:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BC45F91348 for ; Fri, 15 Jun 2001 11:16:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 940D35DDCC; Fri, 15 Jun 2001 11:17:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115]) by segue.merit.edu (Postfix) with SMTP id 49DD15DDB2 for ; Fri, 15 Jun 2001 11:17:34 -0400 (EDT) Received: from pc114.etc.psi.com (HELO jc.yahoo.com) (195.94.40.114) by smtp.mail.vip.sc5.yahoo.com with SMTP; 15 Jun 2001 15:17:03 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010615170217.00beb4f0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 15 Jun 2001 17:15:02 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 66: Server Discovery Cc: Pat Calhoun , aaa-wg@merit.edu In-Reply-To: <20010615074656.R17928@charizard.diameter.org> References: <4.3.2.7.2.20010615162947.00bf3510@pop.mail.yahoo.com> <20010615070126.N17928@charizard.diameter.org> <4.3.2.7.2.20010615162947.00bf3510@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 16:46 15/06/01, Pat Calhoun wrote: >On Fri, Jun 15, 2001 at 04:47:02PM +0200, Jacques Caron wrote: > > Hi, > > > > Stupid question: isn't all this redundant with the RFC2782? Shouldn't we > > rather just point there for the whole scheme (look up the SRV RRs, how > > selection is done, then fall back to A RRs) rather than partially > > duplicating the thing? Duplication always makes me nervous, it leads to > > inconsistencies a bit too often :-( > >Not at all. RFC 2782 is a generic mechanism for locating SRV records, >and the text on this really enhances RFC 2782. The last section (3.3) is >what to do if no SRV records are found. From RFC2782: else Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A Indeed, they look up target, not _diameter.(_sctp|_tcp).target. Maybe they should change that :-) The stupid question is: do we actually need the A thing? I guess it's more of a backwards compatibility thing (e.g. to make sure that http://www.foobar.com/ goes to the A for www.foobar.com if there is no SRV RR for _http._tcp.www.foobar.com). Since Diameter doesn't quite need that... Of course there is the issue of older DNS servers that don't support SRV RRs, but since other stuff like DNSSEC is recommended... (and of course it helps in the very simple case of only one server for a given realm). >of course. Would you like me to take a shot at fixing #83? Just after I finish by e-mail on #75. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Fri Jun 15 11:36:36 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12025 for ; Fri, 15 Jun 2001 11:36:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7AC8591349; Fri, 15 Jun 2001 11:36:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 49E4F9134A; Fri, 15 Jun 2001 11:36:40 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1FF3691349 for ; Fri, 15 Jun 2001 11:36:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E98075DDCC; Fri, 15 Jun 2001 11:37:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id A47BF5DDB2 for ; Fri, 15 Jun 2001 11:37:19 -0400 (EDT) Received: (qmail 29504 invoked by uid 500); 15 Jun 2001 15:22:10 -0000 Date: Fri, 15 Jun 2001 08:22:10 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 66: Server Discovery Message-ID: <20010615082210.V17928@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <4.3.2.7.2.20010615162947.00bf3510@pop.mail.yahoo.com> <20010615070126.N17928@charizard.diameter.org> <4.3.2.7.2.20010615162947.00bf3510@pop.mail.yahoo.com> <20010615074656.R17928@charizard.diameter.org> <4.3.2.7.2.20010615170217.00beb4f0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010615170217.00beb4f0@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Fri, Jun 15, 2001 at 05:15:02PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Fri, Jun 15, 2001 at 05:15:02PM +0200, Jacques Caron wrote: > The stupid question is: do we actually need the A thing? I guess it's more > of a backwards compatibility thing (e.g. to make sure that > http://www.foobar.com/ goes to the A for www.foobar.com if there is no SRV > RR for _http._tcp.www.foobar.com). Since Diameter doesn't quite need > that... Of course there is the issue of older DNS servers that don't > support SRV RRs, but since other stuff like DNSSEC is recommended... (and > of course it helps in the very simple case of only one server for a given > realm). Bernard's main concern, is as you state, backward compatibility with old non-SRV compliant DNS servers. I'll let you right it out with him if you feel so inclined :) > >of course. Would you like me to take a shot at fixing #83? > > Just after I finish by e-mail on #75. Sorry, does that mean you want to try, or should I? Thanks, PatC From owner-aaa-wg@merit.edu Fri Jun 15 11:51:54 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12469 for ; Fri, 15 Jun 2001 11:51:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 042B29134B; Fri, 15 Jun 2001 11:51:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C972B9134C; Fri, 15 Jun 2001 11:51:48 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ADB749134B for ; Fri, 15 Jun 2001 11:51:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A3F655DDCE; Fri, 15 Jun 2001 11:52:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 0E2E85DDB2 for ; Fri, 15 Jun 2001 11:52:28 -0400 (EDT) Received: (qmail 31833 invoked by uid 500); 15 Jun 2001 15:35:40 -0000 Date: Fri, 15 Jun 2001 08:35:39 -0700 From: Pat Calhoun To: Bernard Aboba Cc: "Aaa-Wg@Merit. Edu" Subject: Re: [AAA-WG]: [Issue] EAP Support issues Message-ID: <20010615083539.Y17928@charizard.diameter.org> Mail-Followup-To: Bernard Aboba , "Aaa-Wg@Merit. Edu" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from aboba@internaut.com on Thu, Jun 14, 2001 at 02:58:58PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Bernard, This is a new issue. Is this intended to replace issue 51? What happens to 51? Thanks, PatC On Thu, Jun 14, 2001 at 02:58:58PM -0700, Bernard Aboba wrote: > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: 14-June-2001 > Reference: > Document: NASREQ > Comment type: T > Priority: 1 > Section: 4.0 > Rationale/Explanation of issue: > > When using EAP, the NAS operates as a "pass through" and so NAS > behavior is determined by the Diameter message type, *not* by the > encapsulated EAP message. > > For example: > > a. It is not required that an Accept or Reject message contain > an EAP-Message AVP. > b. If an EAP-Message AVP is included, it is not required that it > correspond to the message type. For example, an EAP-Failure can > be encapsulated within an Access-Accept, and an EAP-Success can > be encapsulated within an Access-Reject. > > To allow correct operation in these cases, the NAS behavior MUST > be determined by the Diameter message type alone. This means that a > Reject message must result in termination of the authentication > conversation, an Accept message must result in allowing > access, and a challenge results in continuing the conversation. > > How the success/failure is communicated to the user is > a subject for RFC 2284 and potential updates (RFC 2284bis), > and need not concern us in specifying the Diameter behavior. > > Note that there has been discussion as to whether an EAP-Success or > EAP-Failure may be encapsulated within a Challenge message. I believe > that the answer to this is NO. Reasoning: > > Success and Failure messages are not ACK'd. Therefore the client > will not respond, and thus the NAS will not have material with > which to send another Request, unless it manufactures something > on its own, which goes against the "passthrough" spirit of EAP. > > Thus, from a AAA perspective, an encapsulated EAP-Success or > Failure message ends the authentication conversation and thus > MUST be encapsulated within a final message (Accept or Reject) > > It has also been asked whether multiple EAP methods may be used > to conduct a single authentication. This is really an EAP issue, > but with respect to AAA, I believe that the answer is that it is > not possible to encapsulate multiple EAP Success or Failure messages within > a single AAA conversation, because of the above reasoning. However, > it would be possible for a AAA server to conduct a conversation of > one type, then switch to another type, and finally, to send an > EAP Success or EAP Failure message at the end, encapsulated within > an Accept or Reject. > > Requested change: > > PPP-specific references to be removed (EAP can be used with IEEE 802 as > well). > Text to be added to Section 4.0 articulating the above. > From owner-aaa-wg@merit.edu Fri Jun 15 12:25:36 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13914 for ; Fri, 15 Jun 2001 12:25:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 377C69124F; Fri, 15 Jun 2001 12:25:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 075ED91250; Fri, 15 Jun 2001 12:25:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DAF189124F for ; Fri, 15 Jun 2001 12:25:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D1BD55DDDC; Fri, 15 Jun 2001 12:26:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 5171E5DDB2 for ; Fri, 15 Jun 2001 12:26:13 -0400 (EDT) Received: (qmail 1630 invoked by uid 500); 15 Jun 2001 16:15:01 -0000 Date: Fri, 15 Jun 2001 09:15:01 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 78: DiameterIdentity (host descriptor) matching & values Message-ID: <20010615091501.C17928@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, Below is my proposed fix to close this issue. Comments appreciated, PatC ---- 4.4 Derived AVP Data Formats [editor's note: new text in the description following the port field, and added a new paragraph at the end] [...] DiameterIdentity The DiameterIdentity format is derived from the OctetString AVP Base Format. It uses the UTF-8 encoding and has the same requirements as the UTF8String. In addition, it must follow the Uniform Resource Identifiers (URI) syntax [29] rules specified below: Diameter-Identity = [scheme-name] fqdn [ port ] [ transport ] scheme-name = "aaa://" aaa-protocol "/" ; If absent, the default BASE for relative URI references ; is aaa://diameter/ aaa-protocol = ( "diameter" | "radius" | "tacacs+" ) fqdn = Fully Qualified Host Name port = ":" 1*DIGIT ; The port used to listen for incoming connections. ; If absent, the default Diameter port (TBD) is assumed. transport = ";transport=" ( "tcp" | "sctp" | "udp") ; If absent, the default SCTP [26] protocol is assumed. ; UDP is ONLY used when the protocol is set to RADIUS The following are examples of valid Diameter host identities: host.abc.com;transport=tcp host.abc.com:6666;transport=tcp aaa://diameter/host.abc.com aaa://diameter/host.abc.com:6666 aaa://diameter/host.abc.com:6666;transport=tcp aaa://radius/host.abc.com:1813;transport=udp The first two forms are relative URI references, against the default base of aaa://diameter/. When comparing AVPs of this format, it is necessary to add any absent fields with the default values prior to the comparison. For example, diameter-host.abc.com would be expanded to aaa://diameter/diameter-host.abc.com:TBD;protocol=sctp. [...] [editor's note: New last sentence] 5.4 Origin-Host AVP The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity, and MUST be present in all Diameter messages. This AVP identifies the endpoint which originated the Diameter message, i.e. the access device, home server, or broker. Relay agents MUST NOT modify this AVP. The same identity used in the CER or CEA's Origin-Host AVP MUST be used in all subsequent messages that include an AVP containing the Diameter node's identity. From owner-aaa-wg@merit.edu Fri Jun 15 12:43:24 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15350 for ; Fri, 15 Jun 2001 12:43:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 265A191350; Fri, 15 Jun 2001 12:42:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E5C4F9134F; Fri, 15 Jun 2001 12:42:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8F00891350 for ; Fri, 15 Jun 2001 12:42:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 900015DDDD; Fri, 15 Jun 2001 12:43:20 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by segue.merit.edu (Postfix) with SMTP id 0E2DB5DDDC for ; Fri, 15 Jun 2001 12:43:20 -0400 (EDT) Received: from pc114.etc.psi.com (HELO jc.yahoo.com) (195.94.40.114) by smtp.mail.vip.sc5.yahoo.com with SMTP; 15 Jun 2001 16:42:48 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010615182907.00bf49b0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 15 Jun 2001 18:42:34 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 78: DiameterIdentity (host descriptor) matching & values Cc: aaa-wg@merit.edu In-Reply-To: <20010615091501.C17928@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, I think you need to clarify that if the server is listening on multiple ports/IPs/protocols, it MUST select a single identity and use it all the time (e.g. it should not send different identities to different peers). Cf the text I proposed in the issue submission. And I don't think you actually need to add the missing parts if the DiameterIdentity is actually considered an opaque unique identifier (made unique by its syntax in the case of multiple processes on the same box) that should be string-matched. Mmmm... in fact it might be necessary when you try to look up a Redirect-Host in the peer table. [as an aside, that leads to another interesting issue: if A sends request to B, B responds "redirect to C", A doesn't find C in its peer table (B sends a name/port/protocol different from the one(s) A knows), A connects to C and sends CER, C recognizes A and disconnects, then C should still send a CEA on the connection before closing it so that A knows that it was the C it already know, and A needs to add to its peer table the name of C that B gave him] Actually, it might be good to clarify the two uses of the DiameterIdentity: - as a unique opaque identifier (like Session-Id) - as a way to designate a given Host (for the purposes of Redirect-Host, or in a peer/routing table config file) Jacques. At 18:15 15/06/01, Pat Calhoun wrote: >All, > >Below is my proposed fix to close this issue. > >Comments appreciated, > >PatC >---- >4.4 Derived AVP Data Formats > >[editor's note: new text in the description following the port field, >and added a new paragraph at the end] > >[...] > DiameterIdentity > The DiameterIdentity format is derived from the OctetString AVP > Base Format. It uses the UTF-8 encoding and has the same > requirements as the UTF8String. In addition, it must follow > the Uniform Resource Identifiers (URI) syntax [29] rules > specified below: > > Diameter-Identity = [scheme-name] fqdn [ port ] > [ transport ] > > scheme-name = "aaa://" aaa-protocol "/" > ; If absent, the default BASE for relative URI references > ; is aaa://diameter/ > > aaa-protocol = ( "diameter" | "radius" | "tacacs+" ) > > fqdn = Fully Qualified Host Name > > port = ":" 1*DIGIT > ; The port used to listen for incoming connections. > ; If absent, the default Diameter port (TBD) is assumed. > > transport = ";transport=" ( "tcp" | "sctp" | "udp") > ; If absent, the default SCTP [26] protocol is assumed. > ; UDP is ONLY used when the protocol is set to RADIUS > > The following are examples of valid Diameter host identities: > > host.abc.com;transport=tcp > host.abc.com:6666;transport=tcp > aaa://diameter/host.abc.com > aaa://diameter/host.abc.com:6666 > aaa://diameter/host.abc.com:6666;transport=tcp > aaa://radius/host.abc.com:1813;transport=udp > > The first two forms are relative URI references, against the default > base of aaa://diameter/. > > When comparing AVPs of this format, it is necessary to add any > absent > fields with the default values prior to the comparison. For example, > diameter-host.abc.com would be expanded to > aaa://diameter/diameter-host.abc.com:TBD;protocol=sctp. > >[...] > >[editor's note: New last sentence] > >5.4 Origin-Host AVP > > The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity, and > MUST be present in all Diameter messages. This AVP identifies the > endpoint which originated the Diameter message, i.e. the access > device, home server, or broker. Relay agents MUST NOT modify this > AVP. The same identity used in the CER or CEA's Origin-Host AVP MUST > be used in all subsequent messages that include an AVP containing the > Diameter node's identity. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Fri Jun 15 12:48:27 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15640 for ; Fri, 15 Jun 2001 12:48:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 404BB9134D; Fri, 15 Jun 2001 12:48:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 033209134E; Fri, 15 Jun 2001 12:48:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D179A9134D for ; Fri, 15 Jun 2001 12:48:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DE3A05DDDC; Fri, 15 Jun 2001 12:49:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp014.mail.yahoo.com (smtp014.mail.yahoo.com [216.136.173.58]) by segue.merit.edu (Postfix) with SMTP id 602F45DDB2 for ; Fri, 15 Jun 2001 12:49:04 -0400 (EDT) Received: from pc114.etc.psi.com (HELO jc.yahoo.com) (195.94.40.114) by smtp.mail.vip.sc5.yahoo.com with SMTP; 15 Jun 2001 16:48:32 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010615161513.00bf1e50@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 15 Jun 2001 18:48:17 +0200 To: aaa-wg@merit.edu From: Jacques Caron Subject: [AAA-WG]: Issue 75: Unsolicited server-to-client requests In-Reply-To: <4.3.2.7.2.20010611135318.00c93d00@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, Following yesterday's call, here are some of the problems raised around this issue, and some additional comments: Trying to have unsolicited requests from server to client follow exactly the same path as requests from client to server is a problem, since hosts or sessions may go down in between (an unsolicited request might come long after any "normal" request from the client, as opposed to answers which travel the same path back nearly immediately). So routing back should not try to match exactly the same path. I see the following options here: - in "regular" requests, include something other than route-records to give the path taken, but including alternatives (e.g. other server in a "cluster" setup), and use that to route the request. This gives us exact path re-use when possible (updating proxy state on the way), and an alternate path to ensure reachability (in that case we can't update state on the proxy which is unreachable, but since it is unreachable...) - use some other form of routing (realm-based, direct to client...), but force a "regular" request to be sent to the server so that everybody can update session state (like an STR after an ASR). It was also commented that there is no guarantee two similar requests will actually follow the same exact path, but I have an open issue on that one (#83). Realm-based routing is not very adapted to this kind of request: - a server knows it serves a realm, a NAS usually doesn't. - there is usually a limited number of servers for a given realm, while there might be very large numbers of NASes - realms are normally used to classify user domains, not machine domains (that's the purpose of DNS) Direct communication from home server to client is not always possible (there might not be direct IP connectivity between them, filters, NAT, anything...) To solve that problem, it would be possible for a proxy to add an AVP to a "regular" request stating where unsolicited requests for this session should go to this host which will relay it to destination. Additional question: should an unsolicited request always be associated to a specific session, or could there be "generic" requests to a NAS? I guess SNMP would be more adapted for the latter... I think that's about all the issues that were raised during the meeting on this subject. Let me know if I forgot anything. So, all in all, I see the following updated options (by decreasing order of personal preference): 1. When a client sends a request to a server, it includes information on how to establish a direct connection back (certificate...). If at some point there is a breach in IP reachability, the proxy/relay that acts as a gateway between the two routing domains includes an AVP stating that unsolicited requests should go to it rather than to the Origin-Host directly (possibly including certificate info of its own), and it will send it to the client. This can possibly happen multiple times, of course. It can also be used if a proxy wants to check/modify any request that is sent to a client. The AVP might contain multiple DiameterIdenties to provide redundancy. If the request causes a change in the state of the session, the client MUST send a regular request back to the server to update state in stateful proxies (unless all these proxies add the "get it through me" AVP, which might actually be the best solution). 2. Regular requests include AVPs that describe the path taken AND alternative servers for each. Server stores last received set of these AVPs for each session. When server needs to send a request to a client, it uses the contents of these AVPs to source-route the request (in a new AVP). If at any given point a host is down, use alternative for that hop. This is actually very close to #1 with every agent on the way saying "get it through me" and no need for additional connections than the existing ones. 3. Use Origin-Realm as Destination-Realm and Origin-Host as Destination-Host and use regular message routing. That probably implies defining distinct "NAS realms" and/or specific application IDs for these requests, as the agents handling those will probably not be the same ones as those handling regular "user realms". Once it gets to an agent in the NAS realm, Destination-Host is used to send to the appropriate NAS. If the request causes a change in the state of the session, the client MUST send a regular request back to the server to update state in stateful proxies. 4. When establishing a peering (i.e. CER/CEA exchange), include an "Alternative-Host" that can be used if this host goes down. All agents need to remember where they received the last client-to-server request for a given session from, and when they receive a server-to-client request for that session, they try to send it to that host, or to the alternate host if not possible. This means all agents become stateful (maintain a minimum of session state info). Comments/suggestions welcome. Let me know which option is preferred so I can propose some text. Jacques. At 14:08 11/06/01, Jacques Caron wrote: >Submitter name: Jacques Caron >Submitter email address: jacques_m_caron@yahoo.com >Date first submitted: 11-Jun-2001 >Reference: >Document: Base >Comment type: T >Priority: 2 >Section: 5.x >Rationale/Explanation of issue: > >The draft is unclear about how unsolicited server-to-client requests are >routed. It says Destination-Host should be used, but does not say anything >about Destination-Realm. > >I see the following options: >1. Use the Origin-Realm received in previous requests as the >Destination-Realm. >However, it raises the issue of asymmetrical routing, and thus proxies not >being able to track session state accurately > >2. Do some kind of source-based routing (saving the Route-Records from a >previous request and using that to route the unsolicited request to the >client). Is a problem with network topology hiding proxies. Those might be >forced to be stateful and save route-records on a per-session basis. > >3. Have the client send a certificate in the original request, so that >servers can then send unsolicited requests directly. It should then be >compulsory for the client to send requests towards the server to update >session state in the proxies if the server requests modifies state in any >way. Raises the issue of proxies that might want to "authorize" >server-to-client requests first, though. > >Comments, suggestions? > >Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Fri Jun 15 14:11:37 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20665 for ; Fri, 15 Jun 2001 14:11:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 248E091252; Fri, 15 Jun 2001 14:11:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E07E691253; Fri, 15 Jun 2001 14:11:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BDDE891252 for ; Fri, 15 Jun 2001 14:11:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E6F0D5DDE3; Fri, 15 Jun 2001 14:12:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 728675DDDE for ; Fri, 15 Jun 2001 14:12:12 -0400 (EDT) Received: (qmail 7965 invoked by uid 500); 15 Jun 2001 17:58:40 -0000 Date: Fri, 15 Jun 2001 10:58:39 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 78: DiameterIdentity (host descriptor) matching & values Message-ID: <20010615105839.V17928@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <20010615091501.C17928@charizard.diameter.org> <4.3.2.7.2.20010615182907.00bf49b0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010615182907.00bf49b0@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Fri, Jun 15, 2001 at 06:42:34PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Fri, Jun 15, 2001 at 06:42:34PM +0200, Jacques Caron wrote: > I think you need to clarify that if the server is listening on multiple > ports/IPs/protocols, it MUST select a single identity and use it all the > time (e.g. it should not send different identities to different peers). Cf > the text I proposed in the issue submission. well, the first part isn't take care of, but the last one is. I'll add the former. > > And I don't think you actually need to add the missing parts if the > DiameterIdentity is actually considered an opaque unique identifier (made > unique by its syntax in the case of multiple processes on the same box) > that should be string-matched. Mmmm... in fact it might be necessary when > you try to look up a Redirect-Host in the peer table. but if you have some local configuration, it MAY include the whole URI, without any shortcuts, so not expanding would cause problems. > > [as an aside, that leads to another interesting issue: if A sends request > to B, B responds "redirect to C", A doesn't find C in its peer table (B > sends a name/port/protocol different from the one(s) A knows), A connects > to C and sends CER, C recognizes A and disconnects, then C should still > send a CEA on the connection before closing it so that A knows that it was > the C it already know, and A needs to add to its peer table the name of C > that B gave him] You've lost me here as to what the problem actually is, other than the CEA is needed before you disconnect (I think that's what you are raising as an issue). > Actually, it might be good to clarify the two uses of the DiameterIdentity: > - as a unique opaque identifier (like Session-Id) So stating that it is unique on a given host is needed. > - as a way to designate a given Host (for the purposes of Redirect-Host, or > in a peer/routing table config file) I thought you opened another issue on this one, and would prefer to keep issues separate. PatC From owner-aaa-wg@merit.edu Fri Jun 15 14:12:26 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20724 for ; Fri, 15 Jun 2001 14:12:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EAD4F91253; Fri, 15 Jun 2001 14:12:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BA99C91254; Fri, 15 Jun 2001 14:12:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A007D91253 for ; Fri, 15 Jun 2001 14:12:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BAF9C5DDE3; Fri, 15 Jun 2001 14:13:00 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from tp.databus.com (p101-46.acedsl.com [160.79.101.46]) by segue.merit.edu (Postfix) with ESMTP id 2F93C5DDDE for ; Fri, 15 Jun 2001 14:13:00 -0400 (EDT) Received: (from barney@localhost) by tp.databus.com (8.11.3/8.11.3) id f5FICTi20570 for aaa-wg@merit.edu; Fri, 15 Jun 2001 14:12:29 -0400 (EDT) (envelope-from barney) Date: Fri, 15 Jun 2001 14:12:29 -0400 From: Barney Wolff To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 37: Home State Blob Message-ID: <20010615141229.A20528@tp.databus.com> References: <20010615072015.P17928@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010615072015.P17928@charizard.diameter.org>; from pcalhoun@diameter.org on Fri, Jun 15, 2001 at 07:20:15AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Would it not be reasonable to apply some limit on the total size of Class attributes? With 24-bit lengths, the client otherwise has to be prepared to store megabytes of state. Barney On Fri, Jun 15, 2001 at 07:20:15AM -0700, Pat Calhoun wrote: > All, > > After a discussion yesterday, we were able to recover the original issue, and the > following is the issue submission. I'd like comments on the proposed text. > > Thanks, > > PatC > ---- > > Issue 37: Home State Blob > Submitter name: Pat Calhoun > Submitter email address: pcalhoun@diameter.org > Date first submitted: June 15 20001 > Reference: > Document: Base > Comment Type: Technical > Priority: 2 > Section: new section 10.16 > Rationale/Explanation of issue: > The RADIUS protocol defines the Class attribute, which allows for home > servers to return some state information to the NAS. The Class attribute > must be present in subsequent messages for the session. > > Requested change: > Add following text in section 10: > 10.16 Class AVP > > The Class AVP (AVP Code 25) is of type OctetString and is used to by > Diameter servers to return state information to the access device. > When one or more Class AVPs are present in application-specific > authorization answer messages, they MUST be present in subsequent > re-authorization and accounting messages. Class AVPs found in a re- > authorization answer message override the ones found in any previous > authorization answer message. From owner-aaa-wg@merit.edu Fri Jun 15 14:30:00 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21636 for ; Fri, 15 Jun 2001 14:29:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 08DB691254; Fri, 15 Jun 2001 14:29:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C6B4991255; Fri, 15 Jun 2001 14:29:51 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9C16291254 for ; Fri, 15 Jun 2001 14:29:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B465C5DDE4; Fri, 15 Jun 2001 14:30:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id E0E945DDDE for ; Fri, 15 Jun 2001 14:30:30 -0400 (EDT) Received: (qmail 9416 invoked by uid 500); 15 Jun 2001 18:15:02 -0000 Date: Fri, 15 Jun 2001 11:15:02 -0700 From: Pat Calhoun To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 78: DiameterIdentity (host descriptor) matching & values Message-ID: <20010615111502.W17928@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <20010615091501.C17928@charizard.diameter.org> <4.3.2.7.2.20010615182907.00bf49b0@pop.mail.yahoo.com> <20010615105839.V17928@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010615105839.V17928@charizard.diameter.org>; from pcalhoun@diameter.org on Fri, Jun 15, 2001 at 10:58:39AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Fri, Jun 15, 2001 at 10:58:39AM -0700, Pat Calhoun wrote: > On Fri, Jun 15, 2001 at 06:42:34PM +0200, Jacques Caron wrote: > > I think you need to clarify that if the server is listening on multiple > > ports/IPs/protocols, it MUST select a single identity and use it all the > > time (e.g. it should not send different identities to different peers). Cf > > the text I proposed in the issue submission. > > well, the first part isn't take care of, but the last one is. I'll add > the former. > > > Actually, it might be good to clarify the two uses of the DiameterIdentity: > > - as a unique opaque identifier (like Session-Id) > So stating that it is unique on a given host is needed. how about: fqdn = Fully Qualified Host Name port = ":" 1*DIGIT ; One of the ports used to listen for incoming connections. ; If absent, the default Diameter port (TBD) is assumed. ; Since multiple Diameter processes on a single host cannot ; listen for incoming connections on the same port, the ; DiameterIdentity is guaranteed to be unique per host. transport = ";transport=" ( "tcp" | "sctp" | "udp") ; One of the transports used to listen for incoming ; connections. If absent, the default SCTP [26] protocol is ; assumed. UDP MUST NOT be used when the aaa-protocol field ; is set to diameter. PatC From owner-aaa-wg@merit.edu Fri Jun 15 14:48:10 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22734 for ; Fri, 15 Jun 2001 14:48:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6C70791255; Fri, 15 Jun 2001 14:48:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 362CF91256; Fri, 15 Jun 2001 14:48:10 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EF70291255 for ; Fri, 15 Jun 2001 14:48:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1B0095DDDE; Fri, 15 Jun 2001 14:48:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 871EF5DDB8 for ; Fri, 15 Jun 2001 14:48:49 -0400 (EDT) Received: (qmail 10011 invoked by uid 500); 15 Jun 2001 18:20:05 -0000 Date: Fri, 15 Jun 2001 11:20:05 -0700 From: Pat Calhoun To: Barney Wolff Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 37: Home State Blob Message-ID: <20010615112005.Y17928@charizard.diameter.org> Mail-Followup-To: Barney Wolff , aaa-wg@merit.edu References: <20010615072015.P17928@charizard.diameter.org> <20010615141229.A20528@tp.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010615141229.A20528@tp.databus.com>; from barney@databus.com on Fri, Jun 15, 2001 at 02:12:29PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Fri, Jun 15, 2001 at 02:12:29PM -0400, Barney Wolff wrote: > Would it not be reasonable to apply some limit on the total size > of Class attributes? With 24-bit lengths, the client otherwise > has to be prepared to store megabytes of state. well it would probably make sense to limit the size. Could we restrict it to the max size of a RADIUS attribute? That would make gateway functions much simpler, but would limit the Diameter protocol. Any other ideas of the max length? Thanks, PatC > > Barney > > On Fri, Jun 15, 2001 at 07:20:15AM -0700, Pat Calhoun wrote: > > All, > > > > After a discussion yesterday, we were able to recover the original issue, and the > > following is the issue submission. I'd like comments on the proposed text. > > > > Thanks, > > > > PatC > > ---- > > > > Issue 37: Home State Blob > > Submitter name: Pat Calhoun > > Submitter email address: pcalhoun@diameter.org > > Date first submitted: June 15 20001 > > Reference: > > Document: Base > > Comment Type: Technical > > Priority: 2 > > Section: new section 10.16 > > Rationale/Explanation of issue: > > The RADIUS protocol defines the Class attribute, which allows for home > > servers to return some state information to the NAS. The Class attribute > > must be present in subsequent messages for the session. > > > > Requested change: > > Add following text in section 10: > > 10.16 Class AVP > > > > The Class AVP (AVP Code 25) is of type OctetString and is used to by > > Diameter servers to return state information to the access device. > > When one or more Class AVPs are present in application-specific > > authorization answer messages, they MUST be present in subsequent > > re-authorization and accounting messages. Class AVPs found in a re- > > authorization answer message override the ones found in any previous > > authorization answer message. From owner-aaa-wg@merit.edu Fri Jun 15 14:52:48 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23059 for ; Fri, 15 Jun 2001 14:52:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1B49D91256; Fri, 15 Jun 2001 14:52:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D713B91257; Fri, 15 Jun 2001 14:52:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5D51891256 for ; Fri, 15 Jun 2001 14:52:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 855605DDDE; Fri, 15 Jun 2001 14:53:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 2ACE05DDB8 for ; Fri, 15 Jun 2001 14:53:22 -0400 (EDT) Received: (qmail 10700 invoked by uid 500); 15 Jun 2001 18:31:17 -0000 Date: Fri, 15 Jun 2001 11:31:17 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 84: Possibly editorial issues in cms-sec Message-ID: <20010615113117.A17928@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Jari, I agree with all of your editorial changes, fixed the document for the next revision, and will close this issue. Thanks, PatC From owner-aaa-wg@merit.edu Fri Jun 15 15:10:40 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24058 for ; Fri, 15 Jun 2001 15:10:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A044A91258; Fri, 15 Jun 2001 15:10:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 67F1B91259; Fri, 15 Jun 2001 15:10:35 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 55AEB91258 for ; Fri, 15 Jun 2001 15:10:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 807C85DDDE; Fri, 15 Jun 2001 15:11:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from tp.databus.com (p101-46.acedsl.com [160.79.101.46]) by segue.merit.edu (Postfix) with ESMTP id 9869B5DDB8 for ; Fri, 15 Jun 2001 15:11:14 -0400 (EDT) Received: (from barney@localhost) by tp.databus.com (8.11.3/8.11.3) id f5FJAi920949 for aaa-wg@merit.edu; Fri, 15 Jun 2001 15:10:44 -0400 (EDT) (envelope-from barney) Date: Fri, 15 Jun 2001 15:10:39 -0400 From: Barney Wolff To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 37: Home State Blob Message-ID: <20010615151039.A20847@tp.databus.com> References: <20010615072015.P17928@charizard.diameter.org> <20010615141229.A20528@tp.databus.com> <20010615112005.Y17928@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010615112005.Y17928@charizard.diameter.org>; from pcalhoun@diameter.org on Fri, Jun 15, 2001 at 11:20:05AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Even RADIUS allows multiple Class attributes, but is saved by the 4096-byte PDU limit. I'd be happy with 1024 as the total Class limit and would accept 512. Anything much more leads one to have to specify what the client MUST do if it cannot store the state. I've never actually tried to stess a NAS with lots of Class to see if I can crash it. Barney On Fri, Jun 15, 2001 at 11:20:05AM -0700, Pat Calhoun wrote: > On Fri, Jun 15, 2001 at 02:12:29PM -0400, Barney Wolff wrote: > > Would it not be reasonable to apply some limit on the total size > > of Class attributes? With 24-bit lengths, the client otherwise > > has to be prepared to store megabytes of state. > > well it would probably make sense to limit the size. Could we > restrict it to the max size of a RADIUS attribute? That would make > gateway functions much simpler, but would limit the Diameter protocol. > > Any other ideas of the max length? > > Thanks, > > PatC > > > > > Barney > > > > On Fri, Jun 15, 2001 at 07:20:15AM -0700, Pat Calhoun wrote: > > > All, > > > > > > After a discussion yesterday, we were able to recover the original issue, and the > > > following is the issue submission. I'd like comments on the proposed text. > > > > > > Thanks, > > > > > > PatC > > > ---- > > > > > > Issue 37: Home State Blob > > > Submitter name: Pat Calhoun > > > Submitter email address: pcalhoun@diameter.org > > > Date first submitted: June 15 20001 > > > Reference: > > > Document: Base > > > Comment Type: Technical > > > Priority: 2 > > > Section: new section 10.16 > > > Rationale/Explanation of issue: > > > The RADIUS protocol defines the Class attribute, which allows for home > > > servers to return some state information to the NAS. The Class attribute > > > must be present in subsequent messages for the session. > > > > > > Requested change: > > > Add following text in section 10: > > > 10.16 Class AVP > > > > > > The Class AVP (AVP Code 25) is of type OctetString and is used to by > > > Diameter servers to return state information to the access device. > > > When one or more Class AVPs are present in application-specific > > > authorization answer messages, they MUST be present in subsequent > > > re-authorization and accounting messages. Class AVPs found in a re- > > > authorization answer message override the ones found in any previous > > > authorization answer message. From owner-aaa-wg@merit.edu Fri Jun 15 17:27:43 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29923 for ; Fri, 15 Jun 2001 17:27:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5CFD29125B; Fri, 15 Jun 2001 17:27:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2CC169125C; Fri, 15 Jun 2001 17:27:47 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F23CA9125B for ; Fri, 15 Jun 2001 17:27:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 55AB75DD96; Fri, 15 Jun 2001 17:28:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (c000-h001.c000.snv.cp.net [209.228.32.65]) by segue.merit.edu (Postfix) with SMTP id F26895DD95 for ; Fri, 15 Jun 2001 17:28:26 -0400 (EDT) Received: (cpmta 19206 invoked from network); 15 Jun 2001 14:27:55 -0700 Received: from h121s86a16n47.user.nortelnetworks.com (HELO mitton.mitton.com) (47.16.86.121) by smtp.mitton.com (209.228.32.65) with SMTP; 15 Jun 2001 14:27:55 -0700 X-Sent: 15 Jun 2001 21:27:55 GMT Message-Id: <4.3.2.7.2.20010615172535.038a35f0@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 15 Jun 2001 17:30:35 -0400 To: From: David Mitton Subject: RE: [AAA-WG]: NASREQ Request-Type AVP??? In-Reply-To: <4.3.2.7.2.20010614142458.00cf1500@pop.mail.yahoo.com> References: <577066326047D41180AC00508B955DDA04D1A9AC@eestqnt104.es.eu. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 6/14/01 02:28 PM +0200, Jacques Caron wrote: >At 13:59 14/06/01, Martin Julien (ECE) wrote: >>Does it also mean that an authorization-only could be followed >>by an authentication-only? > >It could happen (e.g. authorization on called/calling number to pick up >the call, then PPP authentication, then PPP authorization (a la Tacacs+)). > >>The thing is that I am wondering if an AAA server >>needs to keep a session opened for an authorization-only or not? >>For example, in the case that a request is received for >>authorization-only, which gets routed to a tunnel, is there any >>point of keeping a session in the AAA or not? I guess there is >>no point for accounting, neither authentication, am I right? > >In some cases you might have authorization-only (based on called/calling >number), then accounting start, and later on accounting stop. So, yes, you >need to maintain state in that case too. > >>By the way, when a AA-Request is received in a AAA server >>without a User-Name, >>but containing either a Called-Station-Id or a >>Calling-Station-Id, is it >>implicit that tunnelling should be defined in the receiving >>AAA node or not? > >No comprendo. No. Tunneling service usually has no difference in the request. The server figures out that tunneling is the class of service to be given that user or port, and initiates it by the contents of the return message. >>The thing is that I am wondering if it is possible for a AAA >>proxy server to >>forward an AA-Request based on DNI or ANIS? Is it common practice? Yes, typically those doing Called or Calling-Number requests, have a configured table of Numbers to realms or servers. >Yep. We need clarification on exactly which agents are allowed to infer a >Destination-Realm to accomplish that. It's in my list of issues to open :-( Why does this need to be distinguished? Dave. ---------------------------------------------------- David Mitton 978-288-4570 Advisor, Nortel Networks david@mitton.com or dmitton@nortelnetworks.com From owner-aaa-wg@merit.edu Fri Jun 15 19:53:09 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01820 for ; Fri, 15 Jun 2001 19:53:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C261D9125D; Fri, 15 Jun 2001 19:53:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8C1719125E; Fri, 15 Jun 2001 19:53:03 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 75C4C9125D for ; Fri, 15 Jun 2001 19:53:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 103595DDB3; Fri, 15 Jun 2001 19:53:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 21EFE5DDA5 for ; Fri, 15 Jun 2001 19:53:43 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id QAA00743; Fri, 15 Jun 2001 16:47:34 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Fri, 15 Jun 2001 16:47:34 -0700 (PDT) From: Bernard Aboba To: Pat Calhoun Cc: "Aaa-Wg@Merit. Edu" Subject: Re: [AAA-WG]: [Issue] EAP Support issues In-Reply-To: <20010615083539.Y17928@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk I think it replaces issue 51, no? On Fri, 15 Jun 2001, Pat Calhoun wrote: > Bernard, > > This is a new issue. Is this intended to replace issue 51? What happens to 51? > > Thanks, > > PatC > On Thu, Jun 14, 2001 at 02:58:58PM -0700, Bernard Aboba wrote: > > Submitter name: Bernard Aboba > > Submitter email address: aboba@internaut.com > > Date first submitted: 14-June-2001 > > Reference: > > Document: NASREQ > > Comment type: T > > Priority: 1 > > Section: 4.0 > > Rationale/Explanation of issue: > > > > When using EAP, the NAS operates as a "pass through" and so NAS > > behavior is determined by the Diameter message type, *not* by the > > encapsulated EAP message. > > > > For example: > > > > a. It is not required that an Accept or Reject message contain > > an EAP-Message AVP. > > b. If an EAP-Message AVP is included, it is not required that it > > correspond to the message type. For example, an EAP-Failure can > > be encapsulated within an Access-Accept, and an EAP-Success can > > be encapsulated within an Access-Reject. > > > > To allow correct operation in these cases, the NAS behavior MUST > > be determined by the Diameter message type alone. This means that a > > Reject message must result in termination of the authentication > > conversation, an Accept message must result in allowing > > access, and a challenge results in continuing the conversation. > > > > How the success/failure is communicated to the user is > > a subject for RFC 2284 and potential updates (RFC 2284bis), > > and need not concern us in specifying the Diameter behavior. > > > > Note that there has been discussion as to whether an EAP-Success or > > EAP-Failure may be encapsulated within a Challenge message. I believe > > that the answer to this is NO. Reasoning: > > > > Success and Failure messages are not ACK'd. Therefore the client > > will not respond, and thus the NAS will not have material with > > which to send another Request, unless it manufactures something > > on its own, which goes against the "passthrough" spirit of EAP. > > > > Thus, from a AAA perspective, an encapsulated EAP-Success or > > Failure message ends the authentication conversation and thus > > MUST be encapsulated within a final message (Accept or Reject) > > > > It has also been asked whether multiple EAP methods may be used > > to conduct a single authentication. This is really an EAP issue, > > but with respect to AAA, I believe that the answer is that it is > > not possible to encapsulate multiple EAP Success or Failure messages within > > a single AAA conversation, because of the above reasoning. However, > > it would be possible for a AAA server to conduct a conversation of > > one type, then switch to another type, and finally, to send an > > EAP Success or EAP Failure message at the end, encapsulated within > > an Accept or Reject. > > > > Requested change: > > > > PPP-specific references to be removed (EAP can be used with IEEE 802 as > > well). > > Text to be added to Section 4.0 articulating the above. > > > From owner-aaa-wg@merit.edu Fri Jun 15 23:11:44 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05179 for ; Fri, 15 Jun 2001 23:11:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E0CB091262; Fri, 15 Jun 2001 23:11:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B08FD91263; Fri, 15 Jun 2001 23:11:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 85F5F91262 for ; Fri, 15 Jun 2001 23:11:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 65D3F5DD90; Fri, 15 Jun 2001 23:12:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id F14D75DD8D for ; Fri, 15 Jun 2001 23:12:16 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id XAA29476; Fri, 15 Jun 2001 23:02:07 -0400 (EDT) Message-Id: <4.1.20010615124249.01d20700@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 15 Jun 2001 22:49:31 -0400 To: Pat Calhoun , aaa-wg@merit.edu From: Paul Funk Subject: Re: [AAA-WG]: Issue 78: DiameterIdentity (host descriptor) matching & values In-Reply-To: <20010615091501.C17928@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-wg@merit.edu Precedence: bulk Pat, The format you proposed doesn't follow the rules for generic URI syntax (RFC 2396). The scheme is the part that precedes the first colon, and the segment that follows double slash is supposed to be the fqdn, so you can't have a scheme like: aaa://diameter since "diameter" would be interpreted as an fqdn according to the standard rules. Instead, how about: [scheme-name] fqdn [port] [protocol] [transport] for example: aaa://server.acme.com;protocol=diameter;transport=sctp This, of course, could be abbreviated to: server.acme.com Note also that URIs can normally contain either an fqdn or an IP address. I think we want to discourage the use of IP addresses. Perhaps a statement like the following: "Diameter implementations SHOULD (or MUST?) specify a host name in the fqdn, not an IP address. Use of IP address could complicate the expansion of URIs into a canonical form suitable for comparison." Paul At 09:15 AM 6/15/01 -0700, Pat Calhoun wrote: >All, > >Below is my proposed fix to close this issue. > >Comments appreciated, > >PatC >---- >4.4 Derived AVP Data Formats > >[editor's note: new text in the description following the port field, >and added a new paragraph at the end] > >[...] > DiameterIdentity > The DiameterIdentity format is derived from the OctetString AVP > Base Format. It uses the UTF-8 encoding and has the same > requirements as the UTF8String. In addition, it must follow > the Uniform Resource Identifiers (URI) syntax [29] rules > specified below: > > Diameter-Identity = [scheme-name] fqdn [ port ] > [ transport ] > > scheme-name = "aaa://" aaa-protocol "/" > ; If absent, the default BASE for relative URI references > ; is aaa://diameter/ > > aaa-protocol = ( "diameter" | "radius" | "tacacs+" ) > > fqdn = Fully Qualified Host Name > > port = ":" 1*DIGIT > ; The port used to listen for incoming connections. > ; If absent, the default Diameter port (TBD) is assumed. > > transport = ";transport=" ( "tcp" | "sctp" | "udp") > ; If absent, the default SCTP [26] protocol is assumed. > ; UDP is ONLY used when the protocol is set to RADIUS > > The following are examples of valid Diameter host identities: > > host.abc.com;transport=tcp > host.abc.com:6666;transport=tcp > aaa://diameter/host.abc.com > aaa://diameter/host.abc.com:6666 > aaa://diameter/host.abc.com:6666;transport=tcp > aaa://radius/host.abc.com:1813;transport=udp > > The first two forms are relative URI references, against the default > base of aaa://diameter/. > > When comparing AVPs of this format, it is necessary to add any absent > fields with the default values prior to the comparison. For example, > diameter-host.abc.com would be expanded to > aaa://diameter/diameter-host.abc.com:TBD;protocol=sctp. > >[...] > >[editor's note: New last sentence] > >5.4 Origin-Host AVP > > The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity, and > MUST be present in all Diameter messages. This AVP identifies the > endpoint which originated the Diameter message, i.e. the access > device, home server, or broker. Relay agents MUST NOT modify this > AVP. The same identity used in the CER or CEA's Origin-Host AVP MUST > be used in all subsequent messages that include an AVP containing the > Diameter node's identity. Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-wg@merit.edu Fri Jun 15 23:33:24 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05629 for ; Fri, 15 Jun 2001 23:33:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5B6D391264; Fri, 15 Jun 2001 23:33:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2522791265; Fri, 15 Jun 2001 23:33:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7E01791264 for ; Fri, 15 Jun 2001 23:33:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C5FFB5DD8D; Fri, 15 Jun 2001 23:33:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id 5E0FB5DDA6 for ; Fri, 15 Jun 2001 23:33:43 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id XAA29495; Fri, 15 Jun 2001 23:23:45 -0400 (EDT) Message-Id: <4.1.20010615225856.01cf3360@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 15 Jun 2001 23:11:10 -0400 To: Barney Wolff , Pat Calhoun , aaa-wg@merit.edu From: Paul Funk Subject: Re: [AAA-WG]: Issue 37: Home State Blob In-Reply-To: <20010615151039.A20847@tp.databus.com> References: <20010615112005.Y17928@charizard.diameter.org> <20010615072015.P17928@charizard.diameter.org> <20010615141229.A20528@tp.databus.com> <20010615112005.Y17928@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-wg@merit.edu Precedence: bulk I'd vote not to specify a maximum length. Maybe just a warning to be economical with the amount of Class information you burden the NAS with. A NAS implementation can define its own behavior if it doesn't have the memory to store the Class information; maybe it just drops the session. But it's unlikely in practice that Diameter servers will be overloading NASes with this kind of stuff, and it doesn't make sense to impose an arbitrary limit when there may be cases where a larger amount of Class information is necessary and the NAS is known to be able to handle it. Plus, what's a Diameter server supposed to do if it must send back a certain amount of Class information and it's over the limit? Reject? Paul At 03:10 PM 6/15/01 -0400, Barney Wolff wrote: >Even RADIUS allows multiple Class attributes, but is saved by the >4096-byte PDU limit. I'd be happy with 1024 as the total Class >limit and would accept 512. Anything much more leads one to have >to specify what the client MUST do if it cannot store the state. >I've never actually tried to stess a NAS with lots of Class to >see if I can crash it. >Barney > >On Fri, Jun 15, 2001 at 11:20:05AM -0700, Pat Calhoun wrote: >> On Fri, Jun 15, 2001 at 02:12:29PM -0400, Barney Wolff wrote: >> > Would it not be reasonable to apply some limit on the total size >> > of Class attributes? With 24-bit lengths, the client otherwise >> > has to be prepared to store megabytes of state. >> >> well it would probably make sense to limit the size. Could we >> restrict it to the max size of a RADIUS attribute? That would make >> gateway functions much simpler, but would limit the Diameter protocol. >> >> Any other ideas of the max length? >> >> Thanks, >> >> PatC >> >> > >> > Barney >> > >> > On Fri, Jun 15, 2001 at 07:20:15AM -0700, Pat Calhoun wrote: >> > > All, >> > > >> > > After a discussion yesterday, we were able to recover the original >issue, and the >> > > following is the issue submission. I'd like comments on the proposed >text. >> > > >> > > Thanks, >> > > >> > > PatC >> > > ---- >> > > >> > > Issue 37: Home State Blob >> > > Submitter name: Pat Calhoun >> > > Submitter email address: pcalhoun@diameter.org >> > > Date first submitted: June 15 20001 >> > > Reference: >> > > Document: Base >> > > Comment Type: Technical >> > > Priority: 2 >> > > Section: new section 10.16 >> > > Rationale/Explanation of issue: >> > > The RADIUS protocol defines the Class attribute, which allows for home >> > > servers to return some state information to the NAS. The Class attribute >> > > must be present in subsequent messages for the session. >> > > >> > > Requested change: >> > > Add following text in section 10: >> > > 10.16 Class AVP >> > > >> > > The Class AVP (AVP Code 25) is of type OctetString and is used to by >> > > Diameter servers to return state information to the access device. >> > > When one or more Class AVPs are present in application-specific >> > > authorization answer messages, they MUST be present in subsequent >> > > re-authorization and accounting messages. Class AVPs found in a re- >> > > authorization answer message override the ones found in any previous >> > > authorization answer message. Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-wg@merit.edu Sat Jun 16 07:46:08 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23108 for ; Sat, 16 Jun 2001 07:46:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D99B391268; Sat, 16 Jun 2001 07:45:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4584E9126A; Sat, 16 Jun 2001 07:45:28 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C27A091268 for ; Sat, 16 Jun 2001 07:45:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F42295DDA6; Sat, 16 Jun 2001 07:46:00 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by segue.merit.edu (Postfix) with SMTP id 774CB5DD9B for ; Sat, 16 Jun 2001 07:45:59 -0400 (EDT) Received: from ip117.zurich28.pub-ip.ch.psi.net (HELO jc.yahoo.com) (154.15.28.117) by smtp.mail.vip.sc5.yahoo.com with SMTP; 16 Jun 2001 11:45:11 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010615185617.00c34590@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 16 Jun 2001 13:36:08 +0200 To: aaa-wg@merit.edu From: Jacques Caron Subject: Re: [AAA-WG]: Issue 83: Routing/forwarding clarifications In-Reply-To: <4.3.2.7.2.20010614182800.00c14420@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, The following points need to be discussed before text can be proposed: - Clarify if connections to peers are supposed to be opened at startup, or when needed only. I would say at startup (so that the agent knows immediately if peers are up or down when a request needs to be sent, and to avoid long connection establishment -and thus forwarding- delays). On the other hand, a roaming consortium proxy might not want to keep hundreds of sessions up all the time. An aggregator proxy might not want to keep connections to each and every access device it serves all the time either (some access devices might have very low usage?). It's probably best to make it an administrative option? - Clarify relationship of server discovery (SLP, DNS A, DNS SRV...) with peer table and/or routing table. The issue is to know if the use of any of the "server discovery" methods (DNS, SLP...) is an extension to the routing table (map a realm to a peer, but the peer must already be in our peer table), or to the routing AND peer table (map a realm to a peer created on the fly), or just to the peer table. At least in the case of DNS, I think it's the former, but maybe people have reasons to believe otherwise? And in the case of SLP, I have no idea, not fluent with that one yet :-( Probably the second or third, but then shouldn't there be things like realms in the service template in Appendix A? In the first case, what if DNS resolves to a peer we don't have in our peer table? In the second and third case, what about security associations (can you put a certificate in DNS?) - Clarify whether "on-demand" connections (e.g. Redirect-Host with certificate) should timeout. This also applies to DNS/SLP-discovered servers, and if connections are established when needed only (cf first issue above). At the moment, we actually force all connections to stay established using the Watchdog messages, if I'm not mistaken? Let me know what you think so I can propose some text. I will also include some text for the rest of the items. Thanks, Jacques. At 18:29 14/06/01, Jacques Caron wrote: >Submitter name: Jacques Caron >Submitter email address: jacques_m_caron@yahoo.com >Date first submitted: 14-Jun-2001 >Reference: >Document: Base >Comment type: T >Priority: 1 >Section: throughout >Rationale/Explanation of issue: > >- If multiple hosts listed for a given realm (redirect, relay, proxy), use >the same one for a given Session (either need to maintain Session state or >to use some hash function based on Session-ID) unless error occurs (and >then keep that one that works). >- Clarify if connections to peers are supposed to be opened at startup, or >when needed only. >- Clarify relationship of server discovery (SLP, DNS A, DNS SRV...) with >peer table and/or routing table. >- move peer and routing table description earlier in the doc (somewhere in >2.5 or 2.6). >- Clarify whether "on-demand" connections (e.g. Redirect-Host with >certificate) should timeout. >- refuse connection to oneself > >Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Sat Jun 16 13:23:26 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25064 for ; Sat, 16 Jun 2001 13:23:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3D40691272; Sat, 16 Jun 2001 13:23:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0914C91273; Sat, 16 Jun 2001 13:23:14 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0900691272 for ; Sat, 16 Jun 2001 13:23:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E95F15DDA9; Sat, 16 Jun 2001 13:23:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from tp.databus.com (p101-46.acedsl.com [160.79.101.46]) by segue.merit.edu (Postfix) with ESMTP id 5FE965DD8D for ; Sat, 16 Jun 2001 13:23:56 -0400 (EDT) Received: (from barney@localhost) by tp.databus.com (8.11.3/8.11.3) id f5GHN6v28344; Sat, 16 Jun 2001 13:23:06 -0400 (EDT) (envelope-from barney) Date: Sat, 16 Jun 2001 13:23:01 -0400 From: Barney Wolff To: Paul Funk Cc: Barney Wolff , Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 37: Home State Blob Message-ID: <20010616132301.C28257@tp.databus.com> References: <20010615112005.Y17928@charizard.diameter.org> <20010615072015.P17928@charizard.diameter.org> <20010615141229.A20528@tp.databus.com> <20010615112005.Y17928@charizard.diameter.org> <20010615151039.A20847@tp.databus.com> <4.1.20010615225856.01cf3360@cairo.funk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.1.20010615225856.01cf3360@cairo.funk.com>; from paul@funk.com on Fri, Jun 15, 2001 at 11:11:10PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk The idea of a fixed limit is to guide the designers of the NAS and server. Without a limit, the NAS may accomodate a huge Class for one session and then be unable to handle even a minimal Class for another. The server needs to be able to count on a reasonably sized Class being accepted. In return, the server designer must not use a scheme that ever requires an unreasonably large Class. Barney On Fri, Jun 15, 2001 at 11:11:10PM -0400, Paul Funk wrote: > I'd vote not to specify a maximum length. Maybe just a warning to > be economical with the amount of Class information you burden > the NAS with. > > A NAS implementation can define its own behavior if it doesn't have > the memory to store the Class information; maybe it just drops the > session. But it's unlikely in practice that Diameter servers will be > overloading NASes with this kind of stuff, and it doesn't make sense > to impose an arbitrary limit when there may be cases where a > larger amount of Class information is necessary and the NAS is known > to be able to handle it. > > Plus, what's a Diameter server supposed to do if it must send back > a certain amount of Class information and it's over the limit? Reject? From owner-aaa-wg@merit.edu Sun Jun 17 08:51:14 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09530 for ; Sun, 17 Jun 2001 08:51:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3A59091281; Sun, 17 Jun 2001 08:51:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0A07091282; Sun, 17 Jun 2001 08:51:16 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CD92F91281 for ; Sun, 17 Jun 2001 08:51:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4B5915DDD6; Sun, 17 Jun 2001 08:52:00 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) by segue.merit.edu (Postfix) with SMTP id C01B65DDC9 for ; Sun, 17 Jun 2001 08:51:59 -0400 (EDT) Received: from ip104.zurich28.pub-ip.ch.psi.net (HELO jc.yahoo.com) (154.15.28.104) by smtp.mail.vip.sc5.yahoo.com with SMTP; 17 Jun 2001 12:51:20 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010617141155.00c89530@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 17 Jun 2001 14:34:11 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 78: DiameterIdentity (host descriptor) matching & values Cc: aaa-wg@merit.edu In-Reply-To: <20010615105839.V17928@charizard.diameter.org> References: <4.3.2.7.2.20010615182907.00bf49b0@pop.mail.yahoo.com> <20010615091501.C17928@charizard.diameter.org> <4.3.2.7.2.20010615182907.00bf49b0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 19:58 15/06/01, Pat Calhoun wrote: > > And I don't think you actually need to add the missing parts if the > > DiameterIdentity is actually considered an opaque unique identifier (made > > unique by its syntax in the case of multiple processes on the same box) > > that should be string-matched. Mmmm... in fact it might be necessary when > > you try to look up a Redirect-Host in the peer table. > >but if you have some local configuration, it MAY include the whole URI, >without any shortcuts, so not expanding would cause problems. That's valid only for matching Redirect-Hosts with existing sessions. But even in that case the match might not succeed. > > [as an aside, that leads to another interesting issue: if A sends request > > to B, B responds "redirect to C", A doesn't find C in its peer table (B > > sends a name/port/protocol different from the one(s) A knows), A connects > > to C and sends CER, C recognizes A and disconnects, then C should still > > send a CEA on the connection before closing it so that A knows that it was > > the C it already know, and A needs to add to its peer table the name of C > > that B gave him] > >You've lost me here as to what the problem actually is, other than the CEA >is needed before you disconnect (I think that's what you are raising as an >issue). That's an issue. The other issue is that there's a need to be able to associate multiple identities to a peer in the peer table, so that once A has discovered that the host B told it to redirect to is actually C (which A already knows and is connected to), it can use that information any other time that B tells it to redirect to it. Let's take an example: - diameter.isp1.net has a connection established to incoming.roaming.org and to diameter.isp2.net. - diameter.isp1.net sends a requests to incoming.roaming.org. - incoming.roaming.org replies to diameter.isp1.net: redirect to diameter.company.com. - diameter.isp1.net connects to diameter.company.com, which actually is diameter.isp2.net, but diameter.isp1.net doesn't know it (yet) - diameter.isp2.net receives the CER from diameter.isp1.net, and detects that there already is a connection [btw, imagine the first connection was established in the same direction: the election is a tie in this case...]. It sends back a CEA, and one of the two disconnects. - diameter.isp1.net know knows that diameter.company.com == diameter.isp2.net. Two things here: 1. it must send the request that it wanted to send to diameter.company.com to diameter.isp2.net. 2. it must store the fact that diameter.company.com == diameter.isp2.net somewhere, so that later redirects to diameter.company.com go directly to diameter.isp2.net. On a completely different note regarding the election process... What is to prevent a peer from sending a fake identity (knowing quite well that it is easy to force a win in an election) to get requests that are supposed to be going to another server? (even though using e2e security or things like EAP SRP would prevent much of the damage like stealing passwords etc, that still counts as a DoS attack). It might thus be necessary to at least check that the name given resolves to the IP address of the remote end of the connection. > > Actually, it might be good to clarify the two uses of the DiameterIdentity: > > - as a unique opaque identifier (like Session-Id) >So stating that it is unique on a given host is needed. Yup. > > - as a way to designate a given Host (for the purposes of > Redirect-Host, or > > in a peer/routing table config file) >I thought you opened another issue on this one, and would prefer to keep >issues separate. The issue here is just to state in the defintion of DiameterIdentity that there are two uses of it: one unique (which is opaque, and the format given here is only meant to make it unique; note that here strict string matching is enough), and one as an URI to point to another server (where it gets awfully more complex). It should be stated in 2.7, so there is no confusion later on. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Sun Jun 17 08:51:27 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09546 for ; Sun, 17 Jun 2001 08:51:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 89D4A91282; Sun, 17 Jun 2001 08:51:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4F45191285; Sun, 17 Jun 2001 08:51:28 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7BB6F91282 for ; Sun, 17 Jun 2001 08:51:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0E83C5DDD6; Sun, 17 Jun 2001 08:52:09 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) by segue.merit.edu (Postfix) with SMTP id B93AF5DDC9 for ; Sun, 17 Jun 2001 08:52:08 -0400 (EDT) Received: from ip104.zurich28.pub-ip.ch.psi.net (HELO jc.yahoo.com) (154.15.28.104) by smtp.mail.vip.sc5.yahoo.com with SMTP; 17 Jun 2001 12:51:31 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010617143437.00c7e4c0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 17 Jun 2001 14:42:48 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 78: DiameterIdentity (host descriptor) matching & values Cc: aaa-wg@merit.edu In-Reply-To: <20010615111502.W17928@charizard.diameter.org> References: <20010615105839.V17928@charizard.diameter.org> <20010615091501.C17928@charizard.diameter.org> <4.3.2.7.2.20010615182907.00bf49b0@pop.mail.yahoo.com> <20010615105839.V17928@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 20:15 15/06/01, Pat Calhoun wrote: >how about: > > fqdn = Fully Qualified Host Name > > port = ":" 1*DIGIT > ; One of the ports used to listen for incoming connections. > ; If absent, the default Diameter port (TBD) is assumed. > ; Since multiple Diameter processes on a single host cannot > ; listen for incoming connections on the same port, the > ; DiameterIdentity is guaranteed to be unique per host. I'd rather move that to a distinct paragraph after the definition, as it applies not just to the port, but to the combination of transport, address, and port (a process might be listening on multiple different addresses and/or using different transports). This is the text I had originally proposed in the issue submission: >The port and protocol listed above are those that a node uses to listen >for incoming connections. > >When a process listens on multiple different addresses or ports or using >different protocols, it should select a single combination of those, and >always use the same value as its identity for the lifetime of all >connections to peers. This value should be sent in Origin-Host in CER/CEA >and other messages, used in Route-Record AVPs, and any other AVPs >containing DiameterIdentity. However, there is an issue here with what I wrote in my previous post about checking that the host in the DiameterIdentity resolves correctly, in a scenario where a diameter proxy acts as a gateway between two routing domains. Imagine diameter-gw.private.net is a gateway between the public Internet and a private network (with private addressing), for the purpose of proxying diameter messages. It seems obvious that the gateway must present itself with a public name/address on the public side, and a private name/address on the private side. Which conflicts with the unique and constant identity... Damn. Security sure is a tricky issue :-( Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Mon Jun 18 03:42:39 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01738 for ; Mon, 18 Jun 2001 03:42:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6F68A91205; Mon, 18 Jun 2001 03:42:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3F6E791206; Mon, 18 Jun 2001 03:42:38 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4B6D991205 for ; Mon, 18 Jun 2001 03:42:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3C0F85DDEB; Mon, 18 Jun 2001 03:43:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 5A0835DDE9 for ; Mon, 18 Jun 2001 03:43:22 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA26604; Mon, 18 Jun 2001 00:42:46 -0700 (PDT) Received: from vayne (muc-isdn-18 [129.157.164.118]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id JAA25290; Mon, 18 Jun 2001 09:42:44 +0200 (MET DST) Date: Mon, 18 Jun 2001 09:54:40 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: [AAA-WG]: [Issue] DiameterIdentity (host descriptor) matching & values To: Jacques Caron Cc: aaa-wg@merit.edu In-Reply-To: "Your message with ID" <4.3.2.7.2.20010613200236.00c18b60@pop.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Submitter name: Jacques Caron > Submitter email address: jacques_m_caron@yahoo.com > Date first submitted: 14-Jun-2001 > Reference: > Document: Base > Comment type: T > Priority: 2 > Section: throughout, but clarification to be added in 2.7 > Rationale/Explanation of issue: > > We need to clarify how two host descriptors are matched, e.g. in loop > matching. Options are: > - exact lexical match (strcmp) > - expand (add defaults such as diameter://, :port, and ;transport=sctp), > then exact lexical match (or match on protocol+name+port+transport) Host names are case insensitive. > - expand name to IP addresses, and match on protocol+IP+port+transport (if > name resolves to multiple IP addresses, any match between the two > expansions is a match) The (set of) addresses that a name resolves to may not be the same each time - if some load balancing tricks are done. Why not match on the name? > For the purposes of loop checking and other comparison purposes, two > DiameterIdentity values match if they are lexically identical (i.e. > the two strings are the same). believe that case insensitive comparison should be done for elements in the DiameterIdentity to determine equality. Erik From owner-aaa-wg@merit.edu Mon Jun 18 04:25:23 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02026 for ; Mon, 18 Jun 2001 04:25:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 309F491208; Mon, 18 Jun 2001 04:25:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 02A7391209; Mon, 18 Jun 2001 04:25:16 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D00CF91208 for ; Mon, 18 Jun 2001 04:25:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D6E245DD9E; Mon, 18 Jun 2001 04:26:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 37FC25DD99 for ; Mon, 18 Jun 2001 04:26:01 -0400 (EDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f5I8PRO15175 for ; Mon, 18 Jun 2001 10:25:27 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Mon Jun 18 10:25:27 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Jun 2001 10:25:26 +0200 Message-ID: <577066326047D41180AC00508B955DDA04D1A9B3@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'David Mitton'" , Pat Calhoun , Jacques Caron Cc: aaa-wg@merit.edu, "Martin Julien (ECE)" Subject: RE: [AAA-WG]: Support for multi-process Date: Mon, 18 Jun 2001 10:25:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk See comments. > -----Original Message----- > From: David Mitton [mailto:dmitton@nortelnetworks.com] > Sent: Monday, June 11, 2001 10:14 PM > Only one process can be listening on a given port number at a > time. When > the listening process accepts the connection (at least on Unix) a new > socket is created, and typically it is given a new unique > ephemeral port > number. The original port number is not needed, as the > connection has been > made. > > The listening process can spawn subprocesses or threads to > handle that > connection socket, but it still holds the listening well-known socket. It seems to be still unclear how could 2 servers can connect with each other, especially in the case of multi-process support. I guess that it should be possible for 2 servers to establish several TCP connections using the same destination IP and port number, whenever the receiver can span the connections within its system properly. I understand that it is not desired when the receiver does not support that functionality, but then it simply has to reject the extra connections, or configure the initiating servers correctly. The thing is that I would prefer to have interoperability with such a feature, i.e. allowing servers to connect with each other with a number of permitted connections to the same IP and port number in order to allow such a possible configuration. We should also consider systems having a Load Balancer and a VIP, in which case it is possible to load balance the connections to several servers within the cluster, having only one IP and port number. Then, it is quite obvious that it would be nice to have several connections between 2 servers. In the actual draft, how should the initiating server be configured for doing so? Was the idea of supporting several processes on the same machine intended for the same Host identity or not? It seems that the only way it could work is by defining a different host identity for each of the server instance of the machine, am I right? > If you need to run different server "instances" on the same > system, they > have to listen to connections with distinct socket numbers, > (that's how IP > knows where to deliver your packets) or you partion your > implementation > internally. > > So far, I thought the URI would include the ability to configure a > non-default target (listening) port number which would be > critical to doing > this. > > Dave. Martin From owner-aaa-wg@merit.edu Mon Jun 18 09:35:48 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07250 for ; Mon, 18 Jun 2001 09:35:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 529D59120A; Mon, 18 Jun 2001 09:35:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1E8429120C; Mon, 18 Jun 2001 09:35:51 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0606B9120A for ; Mon, 18 Jun 2001 09:35:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7A6A85DDE9; Mon, 18 Jun 2001 09:36:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id DE01D5DDA9 for ; Mon, 18 Jun 2001 09:36:35 -0400 (EDT) Received: (qmail 2148 invoked by uid 500); 18 Jun 2001 13:25:11 -0000 Date: Mon, 18 Jun 2001 06:25:11 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 78: DiameterIdentity (host descriptor) matching & values Message-ID: <20010618062510.J17928@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <20010615105839.V17928@charizard.diameter.org> <20010615091501.C17928@charizard.diameter.org> <4.3.2.7.2.20010615182907.00bf49b0@pop.mail.yahoo.com> <20010615105839.V17928@charizard.diameter.org> <20010615111502.W17928@charizard.diameter.org> <4.3.2.7.2.20010617143437.00c7e4c0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010617143437.00c7e4c0@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Sun, Jun 17, 2001 at 02:42:48PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Sun, Jun 17, 2001 at 02:42:48PM +0200, Jacques Caron wrote: > At 20:15 15/06/01, Pat Calhoun wrote: > >how about: > > > > fqdn = Fully Qualified Host Name > > > > port = ":" 1*DIGIT > > ; One of the ports used to listen for incoming connections. > > ; If absent, the default Diameter port (TBD) is assumed. > > ; Since multiple Diameter processes on a single host cannot > > ; listen for incoming connections on the same port, the > > ; DiameterIdentity is guaranteed to be unique per host. > > I'd rather move that to a distinct paragraph after the definition, as it > applies not just to the port, but to the combination of transport, address, > and port (a process might be listening on multiple different addresses > and/or using different transports). done > > This is the text I had originally proposed in the issue submission: > >The port and protocol listed above are those that a node uses to listen > >for incoming connections. > > > >When a process listens on multiple different addresses or ports or using > >different protocols, it should select a single combination of those, and > >always use the same value as its identity for the lifetime of all > >connections to peers. This value should be sent in Origin-Host in CER/CEA > >and other messages, used in Route-Record AVPs, and any other AVPs > >containing DiameterIdentity. > > However, there is an issue here with what I wrote in my previous post about > checking that the host in the DiameterIdentity resolves correctly, in a > scenario where a diameter proxy acts as a gateway between two routing domains. > > Imagine diameter-gw.private.net is a gateway between the public Internet > and a private network (with private addressing), for the purpose of > proxying diameter messages. > > It seems obvious that the gateway must present itself with a public > name/address on the public side, and a private name/address on the private > side. Which conflicts with the unique and constant identity... > > Damn. Security sure is a tricky issue :-( There is nothing in the protocol that disallows a diameter node from advertising a different FQDN on different interfaces. The only rule is that once you've advertised yourself, you MUST use the same identity throughout the connection. PatC From owner-aaa-wg@merit.edu Mon Jun 18 09:37:25 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07313 for ; Mon, 18 Jun 2001 09:37:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 26C439120C; Mon, 18 Jun 2001 09:37:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E8D699120D; Mon, 18 Jun 2001 09:37:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B3ED29120C for ; Mon, 18 Jun 2001 09:37:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3CE445DDE9; Mon, 18 Jun 2001 09:38:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 9A5265DDA9 for ; Mon, 18 Jun 2001 09:38:17 -0400 (EDT) Received: (qmail 2164 invoked by uid 500); 18 Jun 2001 13:26:53 -0000 Date: Mon, 18 Jun 2001 06:26:53 -0700 From: Pat Calhoun To: Paul Funk Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 78: DiameterIdentity (host descriptor) matching & values Message-ID: <20010618062653.K17928@charizard.diameter.org> Mail-Followup-To: Paul Funk , Pat Calhoun , aaa-wg@merit.edu References: <20010615091501.C17928@charizard.diameter.org> <4.1.20010615124249.01d20700@cairo.funk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.1.20010615124249.01d20700@cairo.funk.com>; from paul@funk.com on Fri, Jun 15, 2001 at 10:49:31PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk The proposal that I sent out followed a review by the IESG's URI advisors. Let me see what they think about the following, and we'll take it from there. Thanks, PatC On Fri, Jun 15, 2001 at 10:49:31PM -0400, Paul Funk wrote: > Pat, > > The format you proposed doesn't follow the rules for generic URI syntax > (RFC 2396). The scheme is the part that precedes the first colon, and the > segment that follows double slash is supposed to be the fqdn, so you > can't have a scheme like: > > aaa://diameter > > since "diameter" would be interpreted as an fqdn according to the > standard rules. > > Instead, how about: > > [scheme-name] fqdn [port] [protocol] [transport] > > for example: > > aaa://server.acme.com;protocol=diameter;transport=sctp > > This, of course, could be abbreviated to: > > server.acme.com > > Note also that URIs can normally contain either an fqdn or an IP > address. I think we want to discourage the use of IP addresses. > Perhaps a statement like the following: > > "Diameter implementations SHOULD (or MUST?) specify a host > name in the fqdn, not an IP address. Use of IP address could > complicate the expansion of URIs into a canonical form > suitable for comparison." > > Paul > > At 09:15 AM 6/15/01 -0700, Pat Calhoun wrote: > >All, > > > >Below is my proposed fix to close this issue. > > > >Comments appreciated, > > > >PatC > >---- > >4.4 Derived AVP Data Formats > > > >[editor's note: new text in the description following the port field, > >and added a new paragraph at the end] > > > >[...] > > DiameterIdentity > > The DiameterIdentity format is derived from the OctetString AVP > > Base Format. It uses the UTF-8 encoding and has the same > > requirements as the UTF8String. In addition, it must follow > > the Uniform Resource Identifiers (URI) syntax [29] rules > > specified below: > > > > Diameter-Identity = [scheme-name] fqdn [ port ] > > [ transport ] > > > > scheme-name = "aaa://" aaa-protocol "/" > > ; If absent, the default BASE for relative URI references > > ; is aaa://diameter/ > > > > aaa-protocol = ( "diameter" | "radius" | "tacacs+" ) > > > > fqdn = Fully Qualified Host Name > > > > port = ":" 1*DIGIT > > ; The port used to listen for incoming connections. > > ; If absent, the default Diameter port (TBD) is assumed. > > > > transport = ";transport=" ( "tcp" | "sctp" | "udp") > > ; If absent, the default SCTP [26] protocol is assumed. > > ; UDP is ONLY used when the protocol is set to RADIUS > > > > The following are examples of valid Diameter host identities: > > > > host.abc.com;transport=tcp > > host.abc.com:6666;transport=tcp > > aaa://diameter/host.abc.com > > aaa://diameter/host.abc.com:6666 > > aaa://diameter/host.abc.com:6666;transport=tcp > > aaa://radius/host.abc.com:1813;transport=udp > > > > The first two forms are relative URI references, against the default > > base of aaa://diameter/. > > > > When comparing AVPs of this format, it is necessary to add any absent > > fields with the default values prior to the comparison. For example, > > diameter-host.abc.com would be expanded to > > aaa://diameter/diameter-host.abc.com:TBD;protocol=sctp. > > > >[...] > > > >[editor's note: New last sentence] > > > >5.4 Origin-Host AVP > > > > The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity, and > > MUST be present in all Diameter messages. This AVP identifies the > > endpoint which originated the Diameter message, i.e. the access > > device, home server, or broker. Relay agents MUST NOT modify this > > AVP. The same identity used in the CER or CEA's Origin-Host AVP MUST > > be used in all subsequent messages that include an AVP containing the > > Diameter node's identity. > > Paul Funk > Funk Software, Inc. > 617 497-6339 > paul@funk.com > From owner-aaa-wg@merit.edu Mon Jun 18 09:43:09 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07495 for ; Mon, 18 Jun 2001 09:43:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 458EE9120D; Mon, 18 Jun 2001 09:43:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 177A89120E; Mon, 18 Jun 2001 09:43:02 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E2E5F9120D for ; Mon, 18 Jun 2001 09:43:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6EFF45DDE9; Mon, 18 Jun 2001 09:43:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) by segue.merit.edu (Postfix) with SMTP id E8B0C5DDA9 for ; Mon, 18 Jun 2001 09:43:46 -0400 (EDT) Received: from pc25.paris-dc.fr.psi.com (HELO jc.yahoo.com) (212.81.116.25) by smtp.mail.vip.sc5.yahoo.com with SMTP; 18 Jun 2001 13:43:11 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010618154013.00c897a0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Jun 2001 15:42:54 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 78: DiameterIdentity (host descriptor) matching & values Cc: Pat Calhoun , aaa-wg@merit.edu In-Reply-To: <20010618062510.J17928@charizard.diameter.org> References: <4.3.2.7.2.20010617143437.00c7e4c0@pop.mail.yahoo.com> <20010615105839.V17928@charizard.diameter.org> <20010615091501.C17928@charizard.diameter.org> <4.3.2.7.2.20010615182907.00bf49b0@pop.mail.yahoo.com> <20010615105839.V17928@charizard.diameter.org> <20010615111502.W17928@charizard.diameter.org> <4.3.2.7.2.20010617143437.00c7e4c0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 15:25 18/06/01, Pat Calhoun wrote: >There is nothing in the protocol that disallows a diameter node from >advertising a different FQDN on different interfaces. The only rule is >that once you've advertised yourself, you MUST use the same identity >throughout the connection. It's not yet in there, but that was something that I raised earlier and that you said you would fix. If you don't, then there is a problem to detect multiple connections (or loops) in some cases. One option would be for a server to adverstise ALL its identities during CER/CEA exchange. And matching would be done on IP address+port+protocol, not string. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Mon Jun 18 09:56:39 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07954 for ; Mon, 18 Jun 2001 09:56:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CCAB39120E; Mon, 18 Jun 2001 09:56:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9A91B9120F; Mon, 18 Jun 2001 09:56:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5F8D29120E for ; Mon, 18 Jun 2001 09:56:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D33CD5DDE9; Mon, 18 Jun 2001 09:57:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 6B8C95DDC6 for ; Mon, 18 Jun 2001 09:57:18 -0400 (EDT) Received: (qmail 2459 invoked by uid 500); 18 Jun 2001 13:45:53 -0000 Date: Mon, 18 Jun 2001 06:45:53 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 78: DiameterIdentity (host descriptor) matching & values Message-ID: <20010618064553.N17928@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <4.3.2.7.2.20010617143437.00c7e4c0@pop.mail.yahoo.com> <20010615105839.V17928@charizard.diameter.org> <20010615091501.C17928@charizard.diameter.org> <4.3.2.7.2.20010615182907.00bf49b0@pop.mail.yahoo.com> <20010615105839.V17928@charizard.diameter.org> <20010615111502.W17928@charizard.diameter.org> <4.3.2.7.2.20010617143437.00c7e4c0@pop.mail.yahoo.com> <20010618062510.J17928@charizard.diameter.org> <4.3.2.7.2.20010618154013.00c897a0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010618154013.00c897a0@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Mon, Jun 18, 2001 at 03:42:54PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Jun 18, 2001 at 03:42:54PM +0200, Jacques Caron wrote: > At 15:25 18/06/01, Pat Calhoun wrote: > >There is nothing in the protocol that disallows a diameter node from > >advertising a different FQDN on different interfaces. The only rule is > >that once you've advertised yourself, you MUST use the same identity > >throughout the connection. > > It's not yet in there, but that was something that I raised earlier and > that you said you would fix. If you don't, then there is a problem to > detect multiple connections (or loops) in some cases. > > One option would be for a server to adverstise ALL its identities during > CER/CEA exchange. And matching would be done on IP address+port+protocol, > not string. Here's my preferred option (this is a fix for both issues you've raised in this thread): DiameterIdentity The DiameterIdentity format is derived from the OctetString AVP Base Format. It uses the UTF-8 encoding and has the same requirements as the UTF8String. In addition, it must follow the Uniform Resource Identifiers (URI) syntax [29] rules specified below: Diameter-Identity = [scheme-name] fqdn [ port ] [ transport ] scheme-name = "aaa://" aaa-protocol "/" ; If absent, the default BASE for relative URI references ; is aaa://diameter/ aaa-protocol = ( "diameter" | "radius" | "tacacs+" ) fqdn = Fully Qualified Host Name port = ":" 1*DIGIT ; One of the ports used to listen for incoming connections. ; If absent, the default Diameter port (TBD) is assumed. transport = ";transport=" ( "tcp" | "sctp" | "udp") ; One of the transports used to listen for incoming ; connections. If absent, the default SCTP [26] protocol is ; assumed. UDP MUST NOT be used when the aaa-protocol field ; is set to diameter. The following are examples of valid Diameter host identities: host.abc.com;transport=tcp host.abc.com:6666;transport=tcp aaa://diameter/host.abc.com aaa://diameter/host.abc.com:6666 aaa://diameter/host.abc.com:6666;transport=tcp aaa://radius/host.abc.com:1813;transport=udp The first two forms are relative URI references, against the default base of aaa://diameter/. Since multiple Diameter processes on a single host cannot listen for incoming connections on the same port on a given protocol, the DiameterIdentity is guaranteed to be unique per host. A Diameter node MAY advertise different identities on each connection, via the CER and CEA's Origin-Host AVP, but the same identity MUST be used throughout the duration of a connection. When comparing AVPs of this format, it is necessary to add any absent fields with the default values prior to the comparison. For example, diameter-host.abc.com would be expanded to aaa://diameter/diameter-host.abc.com:TBD;protocol=sctp. PatC From owner-aaa-wg@merit.edu Mon Jun 18 10:03:54 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08203 for ; Mon, 18 Jun 2001 10:03:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 96DE091210; Mon, 18 Jun 2001 10:03:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 68E3C91211; Mon, 18 Jun 2001 10:03:48 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3C10F91210 for ; Mon, 18 Jun 2001 10:03:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C0CAE5DDC6; Mon, 18 Jun 2001 10:04:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 479195DDA9 for ; Mon, 18 Jun 2001 10:04:33 -0400 (EDT) Received: (qmail 2504 invoked by uid 500); 18 Jun 2001 13:53:08 -0000 Date: Mon, 18 Jun 2001 06:53:08 -0700 From: Pat Calhoun To: Bernard Aboba Cc: Pat Calhoun , "Aaa-Wg@Merit. Edu" Subject: Re: [AAA-WG]: [Issue] EAP Support issues Message-ID: <20010618065308.Q17928@charizard.diameter.org> Mail-Followup-To: Bernard Aboba , Pat Calhoun , "Aaa-Wg@Merit. Edu" References: <20010615083539.Y17928@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from aboba@internaut.com on Fri, Jun 15, 2001 at 04:47:34PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Fri, Jun 15, 2001 at 04:47:34PM -0700, Bernard Aboba wrote: > I think it replaces issue 51, no? If we can get some confirmation from Henry, I will then close 51. Henry? PatC > > On Fri, 15 Jun 2001, Pat Calhoun wrote: > > > Bernard, > > > > This is a new issue. Is this intended to replace issue 51? What happens to 51? > > > > Thanks, > > > > PatC > > On Thu, Jun 14, 2001 at 02:58:58PM -0700, Bernard Aboba wrote: > > > Submitter name: Bernard Aboba > > > Submitter email address: aboba@internaut.com > > > Date first submitted: 14-June-2001 > > > Reference: > > > Document: NASREQ > > > Comment type: T > > > Priority: 1 > > > Section: 4.0 > > > Rationale/Explanation of issue: > > > > > > When using EAP, the NAS operates as a "pass through" and so NAS > > > behavior is determined by the Diameter message type, *not* by the > > > encapsulated EAP message. > > > > > > For example: > > > > > > a. It is not required that an Accept or Reject message contain > > > an EAP-Message AVP. > > > b. If an EAP-Message AVP is included, it is not required that it > > > correspond to the message type. For example, an EAP-Failure can > > > be encapsulated within an Access-Accept, and an EAP-Success can > > > be encapsulated within an Access-Reject. > > > > > > To allow correct operation in these cases, the NAS behavior MUST > > > be determined by the Diameter message type alone. This means that a > > > Reject message must result in termination of the authentication > > > conversation, an Accept message must result in allowing > > > access, and a challenge results in continuing the conversation. > > > > > > How the success/failure is communicated to the user is > > > a subject for RFC 2284 and potential updates (RFC 2284bis), > > > and need not concern us in specifying the Diameter behavior. > > > > > > Note that there has been discussion as to whether an EAP-Success or > > > EAP-Failure may be encapsulated within a Challenge message. I believe > > > that the answer to this is NO. Reasoning: > > > > > > Success and Failure messages are not ACK'd. Therefore the client > > > will not respond, and thus the NAS will not have material with > > > which to send another Request, unless it manufactures something > > > on its own, which goes against the "passthrough" spirit of EAP. > > > > > > Thus, from a AAA perspective, an encapsulated EAP-Success or > > > Failure message ends the authentication conversation and thus > > > MUST be encapsulated within a final message (Accept or Reject) > > > > > > It has also been asked whether multiple EAP methods may be used > > > to conduct a single authentication. This is really an EAP issue, > > > but with respect to AAA, I believe that the answer is that it is > > > not possible to encapsulate multiple EAP Success or Failure messages within > > > a single AAA conversation, because of the above reasoning. However, > > > it would be possible for a AAA server to conduct a conversation of > > > one type, then switch to another type, and finally, to send an > > > EAP Success or EAP Failure message at the end, encapsulated within > > > an Accept or Reject. > > > > > > Requested change: > > > > > > PPP-specific references to be removed (EAP can be used with IEEE 802 as > > > well). > > > Text to be added to Section 4.0 articulating the above. > > > > > > From owner-aaa-wg@merit.edu Mon Jun 18 10:06:39 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08256 for ; Mon, 18 Jun 2001 10:06:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C5CC391211; Mon, 18 Jun 2001 10:06:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 95C2691212; Mon, 18 Jun 2001 10:06:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 855FB91211 for ; Mon, 18 Jun 2001 10:06:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 181AB5DDEC; Mon, 18 Jun 2001 10:07:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by segue.merit.edu (Postfix) with SMTP id 8F46A5DDE9 for ; Mon, 18 Jun 2001 10:07:29 -0400 (EDT) Received: from pc25.paris-dc.fr.psi.com (HELO jc.yahoo.com) (212.81.116.25) by smtp.mail.vip.sc5.yahoo.com with SMTP; 18 Jun 2001 14:06:54 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010618155735.00c7fdd0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Jun 2001 16:06:44 +0200 To: aaa-wg@merit.edu From: Jacques Caron Subject: [AAA-WG]: [Issue] Move filter-rule AVP to base Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Jacques Caron Submitter email address: jacques_m_caron@yahoo.com Date first submitted: 14-Jun-2001 Reference: Document: Base, NASREQ, Mobile IP Comment type: E Priority: 2 Section: NASREQ/2.12, Mobile IP/4.10, Base/4.6 Rationale/Explanation of issue: The Filter-Rule AVP is present in both NASREQ and Mobile IP. It might be moved to base as one of the standard types and AVPs. Requested change: In base, add: 4.6 Standard AVPs Some AVPs are used in several different applications. To avoid duplication, these AVPs are defined here, even though they are not used in the base protocol. And add NASREQ/2.1.2 here as 4.6.1 Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Mon Jun 18 10:11:41 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08412 for ; Mon, 18 Jun 2001 10:11:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4787E91212; Mon, 18 Jun 2001 10:11:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1376B9126A; Mon, 18 Jun 2001 10:11:35 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F31DE91212 for ; Mon, 18 Jun 2001 10:11:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 886145DDC6; Mon, 18 Jun 2001 10:12:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 428C05DDA9 for ; Mon, 18 Jun 2001 10:12:21 -0400 (EDT) Received: (qmail 2535 invoked by uid 500); 18 Jun 2001 14:00:56 -0000 Date: Mon, 18 Jun 2001 07:00:56 -0700 From: Pat Calhoun To: Jacques Caron Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Move filter-rule AVP to base Message-ID: <20010618070056.R17928@charizard.diameter.org> Mail-Followup-To: Jacques Caron , aaa-wg@merit.edu References: <4.3.2.7.2.20010618155735.00c7fdd0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010618155735.00c7fdd0@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Mon, Jun 18, 2001 at 04:06:44PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk That was my preference, and folks decided that they didn't like it. Should we re-open this one? PatC On Mon, Jun 18, 2001 at 04:06:44PM +0200, Jacques Caron wrote: > Submitter name: Jacques Caron > Submitter email address: jacques_m_caron@yahoo.com > Date first submitted: 14-Jun-2001 > Reference: > Document: Base, NASREQ, Mobile IP > Comment type: E > Priority: 2 > Section: NASREQ/2.12, Mobile IP/4.10, Base/4.6 > Rationale/Explanation of issue: > > The Filter-Rule AVP is present in both NASREQ and Mobile IP. It might be > moved to base as one of the standard types and AVPs. > > Requested change: > > In base, add: > > 4.6 Standard AVPs > > Some AVPs are used in several different applications. To avoid > duplication, these > AVPs are defined here, even though they are not used in the base protocol. > > And add NASREQ/2.1.2 here as 4.6.1 > > Jacques. > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > From owner-aaa-wg@merit.edu Mon Jun 18 10:18:39 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08579 for ; Mon, 18 Jun 2001 10:18:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 64A5F9126A; Mon, 18 Jun 2001 10:18:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3891C9126E; Mon, 18 Jun 2001 10:18:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1A1229126A for ; Mon, 18 Jun 2001 10:18:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9C8F55DDC6; Mon, 18 Jun 2001 10:19:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by segue.merit.edu (Postfix) with SMTP id 21AB85DDA9 for ; Mon, 18 Jun 2001 10:19:29 -0400 (EDT) Received: from pc25.paris-dc.fr.psi.com (HELO jc.yahoo.com) (212.81.116.25) by smtp.mail.vip.sc5.yahoo.com with SMTP; 18 Jun 2001 14:18:54 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010618161610.00c32b40@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Jun 2001 16:17:44 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: [Issue] Move filter-rule AVP to base Cc: aaa-wg@merit.edu In-Reply-To: <20010618070056.R17928@charizard.diameter.org> References: <4.3.2.7.2.20010618155735.00c7fdd0@pop.mail.yahoo.com> <4.3.2.7.2.20010618155735.00c7fdd0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 16:00 18/06/01, Pat Calhoun wrote: >That was my preference, and folks decided that they didn't like it. Suspected that might have been the case, but didn't find mention of it in the issues list (was probably before the formal issues list was started). >Should we re-open this one? I think that with the introduction of the newer AVP subtypes (enums, identity...) we could at least move the syntax in the AVP types section? Jacques. >PatC >On Mon, Jun 18, 2001 at 04:06:44PM +0200, Jacques Caron wrote: > > Submitter name: Jacques Caron > > Submitter email address: jacques_m_caron@yahoo.com > > Date first submitted: 14-Jun-2001 > > Reference: > > Document: Base, NASREQ, Mobile IP > > Comment type: E > > Priority: 2 > > Section: NASREQ/2.12, Mobile IP/4.10, Base/4.6 > > Rationale/Explanation of issue: > > > > The Filter-Rule AVP is present in both NASREQ and Mobile IP. It might be > > moved to base as one of the standard types and AVPs. > > > > Requested change: > > > > In base, add: > > > > 4.6 Standard AVPs > > > > Some AVPs are used in several different applications. To avoid > > duplication, these > > AVPs are defined here, even though they are not used in the base > protocol. > > > > And add NASREQ/2.1.2 here as 4.6.1 > > > > Jacques. > > > > > > _________________________________________________________ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Mon Jun 18 10:20:47 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08639 for ; Mon, 18 Jun 2001 10:20:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E66F29126E; Mon, 18 Jun 2001 10:20:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B434091277; Mon, 18 Jun 2001 10:20:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 99D439126E for ; Mon, 18 Jun 2001 10:20:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2F6E25DDC6; Mon, 18 Jun 2001 10:21:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 7BBCC5DDA9 for ; Mon, 18 Jun 2001 10:21:28 -0400 (EDT) Received: (qmail 2570 invoked by uid 500); 18 Jun 2001 14:10:03 -0000 Date: Mon, 18 Jun 2001 07:10:03 -0700 From: Pat Calhoun To: Barney Wolff Cc: Paul Funk , Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 37: Home State Blob Message-ID: <20010618071003.S17928@charizard.diameter.org> Mail-Followup-To: Barney Wolff , Paul Funk , Pat Calhoun , aaa-wg@merit.edu References: <20010615112005.Y17928@charizard.diameter.org> <20010615072015.P17928@charizard.diameter.org> <20010615141229.A20528@tp.databus.com> <20010615112005.Y17928@charizard.diameter.org> <20010615151039.A20847@tp.databus.com> <4.1.20010615225856.01cf3360@cairo.funk.com> <20010616132301.C28257@tp.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010616132301.C28257@tp.databus.com>; from barney@databus.com on Sat, Jun 16, 2001 at 01:23:01PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Allright, given the discussions between Paul and Barney, would the following work? 10.16 Class AVP The Class AVP (AVP Code 25) is of type OctetString and is used to by Diameter servers to return state information to the access device. When one or more Class AVPs are present in application-specific authorization answer messages, they MUST be present in subsequent re-authorization and accounting messages. Class AVPs found in a re- authorization answer message override the ones found in any previous authorization answer message. Diameter server implementations SHOULD NOT return Class AVPs that require more than 4096 bytes of storage on the Diameter client. A Diameter client that receives Class AVPs whose size exceeds local available storage MUST terminate the session. On Sat, Jun 16, 2001 at 01:23:01PM -0400, Barney Wolff wrote: > The idea of a fixed limit is to guide the designers of the NAS and > server. Without a limit, the NAS may accomodate a huge Class for > one session and then be unable to handle even a minimal Class for > another. The server needs to be able to count on a reasonably > sized Class being accepted. In return, the server designer must > not use a scheme that ever requires an unreasonably large Class. > > Barney > > On Fri, Jun 15, 2001 at 11:11:10PM -0400, Paul Funk wrote: > > I'd vote not to specify a maximum length. Maybe just a warning to > > be economical with the amount of Class information you burden > > the NAS with. > > > > A NAS implementation can define its own behavior if it doesn't have > > the memory to store the Class information; maybe it just drops the > > session. But it's unlikely in practice that Diameter servers will be > > overloading NASes with this kind of stuff, and it doesn't make sense > > to impose an arbitrary limit when there may be cases where a > > larger amount of Class information is necessary and the NAS is known > > to be able to handle it. > > > > Plus, what's a Diameter server supposed to do if it must send back > > a certain amount of Class information and it's over the limit? Reject? From owner-aaa-wg@merit.edu Mon Jun 18 10:21:32 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08658 for ; Mon, 18 Jun 2001 10:21:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4440791277; Mon, 18 Jun 2001 10:21:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1415D91285; Mon, 18 Jun 2001 10:21:40 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F3E5D91277 for ; Mon, 18 Jun 2001 10:21:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8C2865DDC6; Mon, 18 Jun 2001 10:22:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 4259B5DDA9 for ; Mon, 18 Jun 2001 10:22:25 -0400 (EDT) Received: (qmail 2587 invoked by uid 500); 18 Jun 2001 14:11:00 -0000 Date: Mon, 18 Jun 2001 07:11:00 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Move filter-rule AVP to base Message-ID: <20010618071100.T17928@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <4.3.2.7.2.20010618155735.00c7fdd0@pop.mail.yahoo.com> <4.3.2.7.2.20010618155735.00c7fdd0@pop.mail.yahoo.com> <20010618070056.R17928@charizard.diameter.org> <4.3.2.7.2.20010618161610.00c32b40@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010618161610.00c32b40@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Mon, Jun 18, 2001 at 04:17:44PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Jun 18, 2001 at 04:17:44PM +0200, Jacques Caron wrote: > At 16:00 18/06/01, Pat Calhoun wrote: > >That was my preference, and folks decided that they didn't like it. > > Suspected that might have been the case, but didn't find mention of it in > the issues list (was probably before the formal issues list was started). > > >Should we re-open this one? > > I think that with the introduction of the newer AVP subtypes (enums, > identity...) we could at least move the syntax in the AVP types section? Adding it as a subtype is something I would certainly entertain. Others? PatC > > Jacques. > > >PatC > >On Mon, Jun 18, 2001 at 04:06:44PM +0200, Jacques Caron wrote: > > > Submitter name: Jacques Caron > > > Submitter email address: jacques_m_caron@yahoo.com > > > Date first submitted: 14-Jun-2001 > > > Reference: > > > Document: Base, NASREQ, Mobile IP > > > Comment type: E > > > Priority: 2 > > > Section: NASREQ/2.12, Mobile IP/4.10, Base/4.6 > > > Rationale/Explanation of issue: > > > > > > The Filter-Rule AVP is present in both NASREQ and Mobile IP. It might be > > > moved to base as one of the standard types and AVPs. > > > > > > Requested change: > > > > > > In base, add: > > > > > > 4.6 Standard AVPs > > > > > > Some AVPs are used in several different applications. To avoid > > > duplication, these > > > AVPs are defined here, even though they are not used in the base > > protocol. > > > > > > And add NASREQ/2.1.2 here as 4.6.1 > > > > > > Jacques. > > > > > > > > > _________________________________________________________ > > > Do You Yahoo!? > > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > From owner-aaa-wg@merit.edu Mon Jun 18 10:43:17 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09114 for ; Mon, 18 Jun 2001 10:43:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2B57891287; Mon, 18 Jun 2001 10:43:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E2E2891288; Mon, 18 Jun 2001 10:43:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AA45D91287 for ; Mon, 18 Jun 2001 10:43:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 42AD85DDE9; Mon, 18 Jun 2001 10:43:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 5300A5DDA9 for ; Mon, 18 Jun 2001 10:43:54 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f5IEjVh00304 for ; Mon, 18 Jun 2001 17:45:31 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 18 Jun 2001 17:43:14 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Mon, 18 Jun 2001 17:42:51 +0300 Message-ID: From: henry.haverinen@nokia.com To: pcalhoun@diameter.org, aboba@internaut.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: [Issue] EAP Support issues Date: Mon, 18 Jun 2001 17:42:50 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk > On Fri, Jun 15, 2001 at 04:47:34PM -0700, Bernard Aboba wrote: > > I think it replaces issue 51, no? > > If we can get some confirmation from Henry, I will then close 51. > > Henry? I agree with everything in Bernard's issue description. But I'd still like to include some text on roundtrip optimization. I don't think it can be entirely covered in the RFC2284bis document. Can we include something along these lines: If an EAP Request is encapsulated within an Access-Accept or Access-Reject, then the NAS MUST relay the encapsulated EAP Request to the peer. The NAS MUST retransmit the EAP Request to the peer until a Response packet with the same Identifier is received or an optional retry counter expires. The NAS MUST NOT send the received Response packet to the AAA server but it MUST discard the Response packet. On receipt of the Response packet, the NAS MAY manufacture an EAP-Success or an EAP-Failure (depending on the Diameter message type) and send it to the peer. Regards, Henry From owner-aaa-wg@merit.edu Mon Jun 18 10:46:31 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09246 for ; Mon, 18 Jun 2001 10:46:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CD11791201; Mon, 18 Jun 2001 10:46:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 87DE191209; Mon, 18 Jun 2001 10:46:31 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 368C191201 for ; Mon, 18 Jun 2001 10:46:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B39BB5DDA9; Mon, 18 Jun 2001 10:47:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by segue.merit.edu (Postfix) with SMTP id 385BA5DD9E for ; Mon, 18 Jun 2001 10:47:16 -0400 (EDT) Received: from pc25.paris-dc.fr.psi.com (HELO jc.yahoo.com) (212.81.116.25) by smtp.mail.vip.sc5.yahoo.com with SMTP; 18 Jun 2001 14:46:40 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010618164441.00c3dcc0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Jun 2001 16:46:28 +0200 To: henry.haverinen@nokia.com From: Jacques Caron Subject: RE: [AAA-WG]: [Issue] EAP Support issues Cc: pcalhoun@diameter.org, aboba@internaut.com, aaa-wg@merit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 16:42 18/06/01, henry.haverinen@nokia.com wrote: > If an EAP Request is encapsulated within an Access-Accept or > Access-Reject, then the NAS MUST relay the encapsulated EAP > Request to the peer. The NAS MUST retransmit the EAP Request > to the peer until a Response packet with the same Identifier is > received or an optional retry counter expires. The NAS MUST NOT > send the received Response packet to the AAA server but it MUST > discard the Response packet. On receipt of the Response packet, > the NAS MAY manufacture an EAP-Success or an EAP-Failure (depending > on the Diameter message type) and send it to the peer. This is contrary to IEEE 802.1X, which states that as soon as an Accept or Reject is received (whether it contains an EAP packet or not), a "canned" EAP Success or Failure should be sent to the peer. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Mon Jun 18 10:50:40 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09322 for ; Mon, 18 Jun 2001 10:50:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0BC7091209; Mon, 18 Jun 2001 10:50:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CFD9F91288; Mon, 18 Jun 2001 10:50:34 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C17D591209 for ; Mon, 18 Jun 2001 10:50:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5E9C15DDA9; Mon, 18 Jun 2001 10:51:20 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 6F0925DD9E for ; Mon, 18 Jun 2001 10:51:19 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f5IEr2h02872 for ; Mon, 18 Jun 2001 17:53:02 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 18 Jun 2001 17:50:43 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Mon, 18 Jun 2001 17:50:33 +0300 Message-ID: From: henry.haverinen@nokia.com To: jacques_m_caron@yahoo.com Cc: pcalhoun@diameter.org, aboba@internaut.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: [Issue] EAP Support issues Date: Mon, 18 Jun 2001 17:50:30 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Jacques, > This is contrary to IEEE 802.1X, which states that as soon as > an Accept or > Reject is received (whether it contains an EAP packet or > not), a "canned" > EAP Success or Failure should be sent to the peer. That is true, and I don't think we should change this in Radius. But I belive we can require different (optimized) behaviour in Diameter. Regards, Henry From owner-aaa-wg@merit.edu Mon Jun 18 10:56:09 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09457 for ; Mon, 18 Jun 2001 10:56:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CAB2091288; Mon, 18 Jun 2001 10:56:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9851291289; Mon, 18 Jun 2001 10:56:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8437F91288 for ; Mon, 18 Jun 2001 10:56:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1E5475DDE9; Mon, 18 Jun 2001 10:56:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 8BC2C5DDA9 for ; Mon, 18 Jun 2001 10:56:49 -0400 (EDT) Received: (qmail 3587 invoked by uid 500); 18 Jun 2001 14:45:24 -0000 Date: Mon, 18 Jun 2001 07:45:24 -0700 From: Pat Calhoun To: henry.haverinen@nokia.com Cc: jacques_m_caron@yahoo.com, pcalhoun@diameter.org, aboba@internaut.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] EAP Support issues Message-ID: <20010618074524.Z17928@charizard.diameter.org> Mail-Followup-To: henry.haverinen@nokia.com, jacques_m_caron@yahoo.com, pcalhoun@diameter.org, aboba@internaut.com, aaa-wg@merit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from henry.haverinen@nokia.com on Mon, Jun 18, 2001 at 05:50:30PM +0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Jun 18, 2001 at 05:50:30PM +0300, henry.haverinen@nokia.com wrote: > > Jacques, > > > This is contrary to IEEE 802.1X, which states that as soon as > > an Accept or > > Reject is received (whether it contains an EAP packet or > > not), a "canned" > > EAP Success or Failure should be sent to the peer. > > That is true, and I don't think we should change this in > Radius. But I belive we can require different (optimized) > behaviour in Diameter. But wouldn't this cause problems if one wanted to use Diameter in 802.1x nets? What about protocol translation? Compatibility is very important. PatC From owner-aaa-wg@merit.edu Mon Jun 18 11:03:02 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09692 for ; Mon, 18 Jun 2001 11:03:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 58CE991217; Mon, 18 Jun 2001 11:03:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 26CC491289; Mon, 18 Jun 2001 11:03:00 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1658091217 for ; Mon, 18 Jun 2001 11:02:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AB3B75DDA9; Mon, 18 Jun 2001 11:03:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zcars0m9.ca.nortel.com (h166s128a249n47.user.nortelnetworks.com [47.249.128.166]) by segue.merit.edu (Postfix) with ESMTP id 916685DD9E for ; Mon, 18 Jun 2001 11:03:40 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5IF2d019335 for ; Mon, 18 Jun 2001 11:02:39 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04e.ca.nortel.com; Mon, 18 Jun 2001 11:02:25 -0400 Received: from zbl6c016.corpeast.baynetworks.com ([132.245.205.66]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MZHTCXMB; Mon, 18 Jun 2001 11:02:25 -0400 Received: from mitton.nortelnetworks.com (mitton.us.nortel.com [47.16.86.121]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KBYWGPZ6; Mon, 18 Jun 2001 11:02:24 -0400 Message-Id: <4.3.2.7.2.20010618105201.03ecf820@ZBL6C016.corpeast.baynetworks.com> X-Sender: dmitton@ZBL6C016.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Jun 2001 11:05:06 -0400 To: "Martin Julien (ECE)" , "David Mitton" , Pat Calhoun , Jacques Caron From: "David Mitton" Subject: RE: [AAA-WG]: Support for multi-process Cc: aaa-wg@merit.edu, "Martin Julien (ECE)" In-Reply-To: <577066326047D41180AC00508B955DDA04D1A9B3@eestqnt104.es.eu. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Orig: Sender: owner-aaa-wg@merit.edu Precedence: bulk At 6/18/01 04:25 AM -0400, Martin Julien (ECE) wrote: >See comments. > > > -----Original Message----- > > From: David Mitton > [mailto:dmitton@nortelnetworks.com] > > Sent: Monday, June 11, 2001 10:14 PM > > > Only one process can be listening on a given port number at a > > time. When > > the listening process accepts the connection (at least on Unix) a new > > socket is created, and typically it is given a new unique > > ephemeral port > > number. The original port number is not needed, as the > > connection has been > > made. > > > > The listening process can spawn subprocesses or threads to > > handle that > > connection socket, but it still holds the listening well-known socket. > >It seems to be still unclear how could 2 servers can connect with each other, >especially in the case of multi-process support. I'm afraid I don't know what you are unclear on? >I guess that >it should be possible for 2 servers to establish several TCP connections >using the same destination IP and port number, whenever the receiver can span >the connections within its system properly. This is done all the time with any multi-user server. The classic example would be FTP or Web services. There are well known ports that all connections are directed to, and the server manages the multiple connections within the process framework of that OS and network stack. >I understand that it is not desired >when the receiver does not support that functionality, but then it simply has >to reject the extra connections, or configure the initiating servers >correctly. Servers should be written to handle more than one connection, where each connection is from a different peer. The only problem we are trying to address, is making sure that one set of peers has only one connection between them. >The thing is that I would prefer to have interoperability with such a >feature, >i.e. allowing servers to connect with each other with a number of permitted >connections to the same IP and port number in order to allow such a possible >configuration. We should also consider systems having a Load Balancer and >a VIP, >in which case it is possible to load balance the connections to several >servers within the cluster, having only one IP and port number. Then, it >is quite >obvious that it would be nice to have several connections between 2 servers. The IESG has said No. This violates the methods of network congestion control. Load balancing across different systems is not the same as multiple connections to the same system. >In the actual draft, how should the initiating server be configured for >doing so? lost me here... > >Was the idea of supporting several processes on the same machine intended >for the same Host identity or not? No. Typically running separate processes on the same machine is done for the purpose of hosting _different_ identities. An ISP or ASP may find it easier to build multiple infrastructures using the same code, but different configurations. Or he may have a couple of specific proxy agents that address different types of requests. >It seems that the only >way it could work is by defining a different host identity for each of the >server instance of the machine, am I right? bingo! > > If you need to run different server "instances" on the same > > system, they > > have to listen to connections with distinct socket numbers, > > (that's how IP > > knows where to deliver your packets) or you partion your > > implementation > > internally. > > > > So far, I thought the URI would include the ability to configure a > > non-default target (listening) port number which would be > > critical to doing > > this. > > > > Dave. > >Martin Dave. ------------------------------------------------------------ David Mitton ESN: 248-4570 Advisor, Nortel Networks 978-288-4570 Wireless Solutions, IP Mobility Billerica, MA 01821 dmitton@nortelnetworks.com From owner-aaa-wg@merit.edu Mon Jun 18 13:16:09 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13814 for ; Mon, 18 Jun 2001 13:16:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D2F2E9128B; Mon, 18 Jun 2001 13:15:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A48569128C; Mon, 18 Jun 2001 13:15:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4F8E39128B for ; Mon, 18 Jun 2001 13:15:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 07B185DDEC; Mon, 18 Jun 2001 13:16:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115]) by segue.merit.edu (Postfix) with SMTP id 7CC7C5DDDA for ; Mon, 18 Jun 2001 13:16:28 -0400 (EDT) Received: from pc25.paris-dc.fr.psi.com (HELO jc.yahoo.com) (212.81.116.25) by smtp.mail.vip.sc5.yahoo.com with SMTP; 18 Jun 2001 17:15:53 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010618161059.00d02100@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Jun 2001 19:15:38 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 78: DiameterIdentity (host descriptor) matching & values Cc: aaa-wg@merit.edu In-Reply-To: <20010618064553.N17928@charizard.diameter.org> References: <4.3.2.7.2.20010618154013.00c897a0@pop.mail.yahoo.com> <4.3.2.7.2.20010617143437.00c7e4c0@pop.mail.yahoo.com> <20010615105839.V17928@charizard.diameter.org> <20010615091501.C17928@charizard.diameter.org> <4.3.2.7.2.20010615182907.00bf49b0@pop.mail.yahoo.com> <20010615105839.V17928@charizard.diameter.org> <20010615111502.W17928@charizard.diameter.org> <4.3.2.7.2.20010617143437.00c7e4c0@pop.mail.yahoo.com> <20010618062510.J17928@charizard.diameter.org> <4.3.2.7.2.20010618154013.00c897a0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 15:45 18/06/01, Pat Calhoun wrote: > Since multiple Diameter processes on a single host cannot > listen for incoming connections on the same port on a given > protocol, the DiameterIdentity is guaranteed to be unique per > host. The "unique per host" seems weirdish to me. I think you mean "unique for any process" (in the sense "no two processes can have the same identity", not in the sense "a process can have only one identity"). > A Diameter node MAY advertise different identities on each > connection, via the CER and CEA's Origin-Host AVP, but the same > identity MUST be used throughout the duration of a connection. > > When comparing AVPs of this format, it is necessary to add any > absent fields with the default values prior to the comparison. > For example, diameter-host.abc.com would be expanded to > aaa://diameter/diameter-host.abc.com:TBD;protocol=sctp. Still think the identity must be the same accross all connections, not just contant on a single connection. Let's step back a minute and examine exactly the needs for the DiamenterIdentity: 1. Provide loop checking 2. Provide duplicate connection detection 3. Provide designation of a Redirect-Host 4. Be used in Configuration files (peer tables and routing tables). 5. Not be "spoofable". I think this resolves into the two cases I gave before: a. a unique opaque identifier, constant for a given process accross all interfaces and peers (this works for 1 and 2, and also for 3 if there is a requirement that a redirector only send out DiameterIdentities received from the hosts it redirects to) b. a general-purpose resolvable URI (for 4). BTW, for the purposes of collision detection, you can look at RFC1771 (BGP) section 4.1, BGP Identifier, which deals with the same issue: it MUST be the same accross all interaces and peers. a. and b. could actually be derived in two sections in the draft: (i) a Diameter URI section, that is used to fully describe a Diameter peer (for configuration files...). (ii) the DiameterIdentity AVP type, with uses the URI format since it provides uniqueness, with the added requirement of picking one single URI at startup, advertise it in CER/CEA messages, use it in Route-Record messages, and use only values received via CER/CEAs in redirects). The only problem is 5 (the unspoofability). I think the only option here is some certification mechanism that can ensure that a host is who he pretends to be (at the application layer, as opposed to at the IP layer, which is provided by IPsec -- maybe TLS can help here, I'm not familiar with it enough to say). Something like a CA-signed DiameterIdentity may be needed. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Mon Jun 18 13:23:44 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13977 for ; Mon, 18 Jun 2001 13:23:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DEA419128C; Mon, 18 Jun 2001 13:23:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AE4309128D; Mon, 18 Jun 2001 13:23:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5DCC49128C for ; Mon, 18 Jun 2001 13:23:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 30FBB5DDEB; Mon, 18 Jun 2001 13:24:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id CBA665DDDA for ; Mon, 18 Jun 2001 13:24:21 -0400 (EDT) Received: (qmail 5592 invoked by uid 500); 18 Jun 2001 17:12:56 -0000 Date: Mon, 18 Jun 2001 10:12:56 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 78: DiameterIdentity (host descriptor) matching & values Message-ID: <20010618101256.K17928@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <20010615105839.V17928@charizard.diameter.org> <20010615091501.C17928@charizard.diameter.org> <4.3.2.7.2.20010615182907.00bf49b0@pop.mail.yahoo.com> <20010615105839.V17928@charizard.diameter.org> <20010615111502.W17928@charizard.diameter.org> <4.3.2.7.2.20010617143437.00c7e4c0@pop.mail.yahoo.com> <20010618062510.J17928@charizard.diameter.org> <4.3.2.7.2.20010618154013.00c897a0@pop.mail.yahoo.com> <20010618064553.N17928@charizard.diameter.org> <4.3.2.7.2.20010618161059.00d02100@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010618161059.00d02100@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Mon, Jun 18, 2001 at 07:15:38PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Jun 18, 2001 at 07:15:38PM +0200, Jacques Caron wrote: > At 15:45 18/06/01, Pat Calhoun wrote: > > Since multiple Diameter processes on a single host cannot > > listen for incoming connections on the same port on a given > > protocol, the DiameterIdentity is guaranteed to be unique per > > host. > > The "unique per host" seems weirdish to me. I think you mean "unique for > any process" (in the sense "no two processes can have the same identity", > not in the sense "a process can have only one identity"). unique per host means that no two processes, threads, or any other programming technique, will allow two instances to advertise exactly the same thing. Unique for any process means that two different processes could advertise the same identity, and this would require that they somehow listen on the same port, of the same transport, which is not possible. > > > A Diameter node MAY advertise different identities on each > > connection, via the CER and CEA's Origin-Host AVP, but the same > > identity MUST be used throughout the duration of a connection. > > > > When comparing AVPs of this format, it is necessary to add any > > absent fields with the default values prior to the comparison. > > For example, diameter-host.abc.com would be expanded to > > aaa://diameter/diameter-host.abc.com:TBD;protocol=sctp. > > Still think the identity must be the same accross all connections, not just > contant on a single connection. > > Let's step back a minute and examine exactly the needs for the > DiamenterIdentity: > > 1. Provide loop checking > 2. Provide duplicate connection detection > 3. Provide designation of a Redirect-Host > 4. Be used in Configuration files (peer tables and routing tables). > 5. Not be "spoofable". > > I think this resolves into the two cases I gave before: > a. a unique opaque identifier, constant for a given process accross all > interfaces and peers (this works for 1 and 2, and also for 3 if there is a > requirement that a redirector only send out DiameterIdentities received > from the hosts it redirects to) > b. a general-purpose resolvable URI (for 4). > > BTW, for the purposes of collision detection, you can look at RFC1771 (BGP) > section 4.1, BGP Identifier, which deals with the same issue: it MUST be > the same accross all interaces and peers. > > a. and b. could actually be derived in two sections in the draft: > (i) a Diameter URI section, that is used to fully describe a Diameter peer > (for configuration files...). > (ii) the DiameterIdentity AVP type, with uses the URI format since it > provides uniqueness, with the added requirement of picking one single URI > at startup, advertise it in CER/CEA messages, use it in Route-Record > messages, and use only values received via CER/CEAs in redirects). ok, but let's be clear that a single identity per process (across all interfaces) *will* not work in the NAT case that you provided earlier. In these cases, a host would have different personalities based on whether the connection was established on the internal vs. external network. > > The only problem is 5 (the unspoofability). I think the only option here is > some certification mechanism that can ensure that a host is who he pretends > to be (at the application layer, as opposed to at the IP layer, which is > provided by IPsec -- maybe TLS can help here, I'm not familiar with it > enough to say). Something like a CA-signed DiameterIdentity may be needed. TLS will help here. PatC From owner-aaa-wg@merit.edu Mon Jun 18 13:42:49 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14557 for ; Mon, 18 Jun 2001 13:42:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CEF109128D; Mon, 18 Jun 2001 13:42:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A09789128E; Mon, 18 Jun 2001 13:42:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8A7A09128D for ; Mon, 18 Jun 2001 13:42:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 564F55DDB1; Mon, 18 Jun 2001 13:43:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 1138A5DDA9 for ; Mon, 18 Jun 2001 13:43:34 -0400 (EDT) Received: (qmail 5734 invoked by uid 500); 18 Jun 2001 17:30:37 -0000 Date: Mon, 18 Jun 2001 10:30:37 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 80: Editorial changes Message-ID: <20010618103037.N17928@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, In an attempt to close this issue, I'd like to propose the following text: - in Definition of End-to-end identifier, included definition for locally consumed incorrect. Reference appropriate section. The text now reads: " End-to-End Identifier Unlike the Hop-by-Hop Identifier, the End-to-End Identifier is used to detect duplicate messages, and relay agents MUST NOT modify this field. The sender of a request or answer message MUST insert a locally unique value in this field. The combination of the Origin-Host AVP and this field is used to detect duplicates. An Answer message which is received with a previously seen End- to-End Identifier, and is to be locally consumed (see Section 5.2) SHOULD be silently discarded.: - 15.1.2 is not up to date (bit numbers) yes, I had caught this one earlier, and the following text solves this one: "15.1.2 AVP Flags There are 8 bits in the AVP Flags field of the AVP header, defined in section 4.0. This document assigns bit 8 ('V'endor Specific), bit 7 ('M'andatory) and bit 6 ('P'rotected). The remaining bits should only be assigned via a Standards Action [12]." - 15.4 does not include protocol errors yup, this one too "15.4 Result-Code AVP Values As defined in Section 9.1, the Result-Code AVP (AVP Code 268) defines the values 1001, 2001-2002, 3001-3009, 4001-4003 and 5001-5015. All remaining values are available for assignment via IETF Consensus [12]." - In 10.3, update Session-ID format with full Diameter-Identity right, so how about the following: "10.3 Session-Id AVP [...] ;;[;] [...] Example, in which the standard port is used and there is no optional value: aaa://diameter/accesspoint7.acme.com;1876543210;523 or accesspoint7.acme.com;1876543210;523 Example, in which a non-standard port is used and there is an optional value: accesspoint7.acme.com:831;1876543210;523;mobile@200.1.1.88" - All AVPs share same scope/numbering space (even inside a Grouped-AVP) - M AVP within a non-M grouped AVP ok, how about: "4.5 Grouped AVP Values [...] The AVP Code numbering space of all AVPs included in a Grouped AVP is the same as for non-grouped AVPs. Further, if any of the AVPs encapsulated within a Grouped AVP has the 'M' (mandatory) bit set, the Grouped AVP itself MUST also include the 'M' bit set. - in 10.3 second paragraph, remove reference to multiple Session-IDs. ok. Thanks, PatC From owner-aaa-wg@merit.edu Mon Jun 18 17:52:42 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22056 for ; Mon, 18 Jun 2001 17:52:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 73C2D91222; Mon, 18 Jun 2001 17:52:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4BDF791223; Mon, 18 Jun 2001 17:52:42 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1D00891222 for ; Mon, 18 Jun 2001 17:52:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 353F75DDB6; Mon, 18 Jun 2001 17:53:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp010.mail.yahoo.com (smtp010.mail.yahoo.com [216.136.173.30]) by segue.merit.edu (Postfix) with SMTP id DEA5E5DD9E for ; Mon, 18 Jun 2001 17:53:27 -0400 (EDT) Received: from jc-mac.planete.net (HELO jc.yahoo.com) (194.2.222.120) by smtp.mail.vip.sc5.yahoo.com with SMTP; 18 Jun 2001 21:52:50 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010618234632.00bfbd80@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Jun 2001 23:50:22 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 78: DiameterIdentity (host descriptor) matching & values Cc: Pat Calhoun , aaa-wg@merit.edu In-Reply-To: <20010618101256.K17928@charizard.diameter.org> References: <4.3.2.7.2.20010618161059.00d02100@pop.mail.yahoo.com> <20010615105839.V17928@charizard.diameter.org> <20010615091501.C17928@charizard.diameter.org> <4.3.2.7.2.20010615182907.00bf49b0@pop.mail.yahoo.com> <20010615105839.V17928@charizard.diameter.org> <20010615111502.W17928@charizard.diameter.org> <4.3.2.7.2.20010617143437.00c7e4c0@pop.mail.yahoo.com> <20010618062510.J17928@charizard.diameter.org> <4.3.2.7.2.20010618154013.00c897a0@pop.mail.yahoo.com> <20010618064553.N17928@charizard.diameter.org> <4.3.2.7.2.20010618161059.00d02100@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 19:12 18/06/01, Pat Calhoun wrote: >On Mon, Jun 18, 2001 at 07:15:38PM +0200, Jacques Caron wrote: > > At 15:45 18/06/01, Pat Calhoun wrote: > > > Since multiple Diameter processes on a single host cannot > > > listen for incoming connections on the same port on a given > > > protocol, the DiameterIdentity is guaranteed to be unique per > > > host. > > > > The "unique per host" seems weirdish to me. I think you mean "unique for > > any process" (in the sense "no two processes can have the same identity", > > not in the sense "a process can have only one identity"). > >unique per host means that no two processes, threads, or any other programming >technique, will allow two instances to advertise exactly the same thing. >Unique >for any process means that two different processes could advertise the same >identity, and this would require that they somehow listen on the same port, >of the same transport, which is not possible. Why just "unique per host" and not simply "unique"? >ok, but let's be clear that a single identity per process (across all >interfaces) *will* not work in the NAT case that you provided earlier. In >these cases, a host would have different personalities based on whether >the connection was established on the internal vs. external network. It will work (really, consider it as a unique opaque identifier. It might be a random number, it would work the same) unless one wishes to check that the address provided matches back (a la reverse + forward DNS checking), which raises the issue below. > > The only problem is 5 (the unspoofability). I think the only option > here is > > some certification mechanism that can ensure that a host is who he > pretends > > to be (at the application layer, as opposed to at the IP layer, which is > > provided by IPsec -- maybe TLS can help here, I'm not familiar with it > > enough to say). Something like a CA-signed DiameterIdentity may be needed. > >TLS will help here. Looks like I have some more reading to stack up on my pile :-( Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Mon Jun 18 18:15:11 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22449 for ; Mon, 18 Jun 2001 18:15:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0D13091221; Mon, 18 Jun 2001 18:15:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B8C9791223; Mon, 18 Jun 2001 18:15:10 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1171491221 for ; Mon, 18 Jun 2001 18:15:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3A8BC5DDB6; Mon, 18 Jun 2001 18:15:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id AD1E55DD9E for ; Mon, 18 Jun 2001 18:15:55 -0400 (EDT) Received: (qmail 14037 invoked by uid 500); 18 Jun 2001 22:04:29 -0000 Date: Mon, 18 Jun 2001 15:04:29 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: New Drafts Available Message-ID: <20010618150429.B17928@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, The new set of drafts have been sent to the secretariat, and are also available on www.diameter.org. All of the changes to the spec can be found on the issues web site (www.diameter.org/issues.html), by looking under the closed issues, and looking for the spec name and version number (e.g. Base 06). The only change that was made that is not a result of an issue is a re-org of section 10. Given some new functionality that has been added in section 10 over the last few versions, the section became fragmented, and needed a renumbering. The text hasn't changed, but the ordering of the sections have. Enjoy, PatC From owner-aaa-wg@merit.edu Tue Jun 19 02:31:32 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13487 for ; Tue, 19 Jun 2001 02:31:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B034D91294; Tue, 19 Jun 2001 02:31:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7528991295; Tue, 19 Jun 2001 02:31:38 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 44A0991294 for ; Tue, 19 Jun 2001 02:31:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 10FB25DDC4; Tue, 19 Jun 2001 02:32:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 1A57A5DDA3 for ; Tue, 19 Jun 2001 02:32:24 -0400 (EDT) Received: from fredrikj (sierra.local.ipunplugged.com [192.168.4.88]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id IAA18177; Tue, 19 Jun 2001 08:33:42 +0200 From: "Fredrik Johansson" To: "Pat Calhoun" , Subject: RE: [AAA-WG]: Issue 80: Editorial changes Date: Tue, 19 Jun 2001 08:33:18 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20010618103037.N17928@charizard.diameter.org> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Shouldn't the End-to-End Identifier be a monotonically increased number as the hop-by-hop id, otherwise you'll have to keep a lot of IDs stored for every Origin-Host. " End-to-End Identifier Unlike the Hop-by-Hop Identifier, the End-to-End Identifier is used to detect duplicate messages, and relay agents MUST NOT modify this field. The sender of a request or answer message MUST insert a locally unique value in this field. The combination of the Origin-Host AVP and this field is used to detect duplicates. An Answer message which is received with a previously seen End- to-End Identifier, and is to be locally consumed (see Section 5.2) SHOULD be silently discarded. The End-to-End identifier is a monotonically increasing number, whose start value was randomly generated." /Fredrik >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >Pat Calhoun >Sent: den 18 juni 2001 19:31 >To: aaa-wg@merit.edu >Subject: [AAA-WG]: Issue 80: Editorial changes > > >All, > >In an attempt to close this issue, I'd like to propose the following text: > >- in Definition of End-to-end identifier, included definition for locally >consumed incorrect. Reference appropriate section. > >The text now reads: > >" End-to-End Identifier > Unlike the Hop-by-Hop Identifier, the End-to-End Identifier is > used to detect duplicate messages, and relay agents MUST NOT > modify this field. The sender of a request or answer message MUST > insert a locally unique value in this field. The combination of > the Origin-Host AVP and this field is used to detect duplicates. > An Answer message which is received with a previously seen End- > to-End Identifier, and is to be locally consumed (see Section 5.2) > SHOULD be silently discarded.: > >- 15.1.2 is not up to date (bit numbers) > >yes, I had caught this one earlier, and the following text solves this >one: > >"15.1.2 AVP Flags > > There are 8 bits in the AVP Flags field of the AVP header, defined in > section 4.0. This document assigns bit 8 ('V'endor Specific), bit 7 > ('M'andatory) and bit 6 ('P'rotected). The remaining bits should only > be assigned via a Standards Action [12]." > >- 15.4 does not include protocol errors > >yup, this one too > >"15.4 Result-Code AVP Values > > As defined in Section 9.1, the Result-Code AVP (AVP Code 268) defines > the values 1001, 2001-2002, 3001-3009, 4001-4003 and 5001-5015. > > All remaining values are available for assignment via IETF Consensus > [12]." > >- In 10.3, update Session-ID format with full Diameter-Identity > >right, so how about the following: > >"10.3 Session-Id AVP > > [...] > ;;[;] > > > [...] > Example, in which the standard port is used and there is no optional > value: > > aaa://diameter/accesspoint7.acme.com;1876543210;523 > or > accesspoint7.acme.com;1876543210;523 > > Example, in which a non-standard port is used and there is an > optional value: > > accesspoint7.acme.com:831;1876543210;523;mobile@200.1.1.88" > >- All AVPs share same scope/numbering space (even inside a Grouped-AVP) >- M AVP within a non-M grouped AVP > >ok, how about: > >"4.5 Grouped AVP Values > > [...] > The AVP Code numbering space of all AVPs included in a Grouped AVP is > the same as for non-grouped AVPs. Further, if any of the AVPs > encapsulated within a Grouped AVP has the 'M' (mandatory) bit set, > the Grouped AVP itself MUST also include the 'M' bit set. > >- in 10.3 second paragraph, remove reference to multiple Session-IDs. > >ok. > >Thanks, > >PatC From owner-aaa-wg@merit.edu Tue Jun 19 08:52:01 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA20065 for ; Tue, 19 Jun 2001 08:52:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A9B1791227; Tue, 19 Jun 2001 08:52:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 739FB91297; Tue, 19 Jun 2001 08:52:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5702191227 for ; Tue, 19 Jun 2001 08:52:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 97AB55DDE4; Tue, 19 Jun 2001 08:52:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 40D845DDDA for ; Tue, 19 Jun 2001 08:52:51 -0400 (EDT) Received: (qmail 23609 invoked by uid 500); 19 Jun 2001 12:41:22 -0000 Date: Tue, 19 Jun 2001 05:41:22 -0700 From: Pat Calhoun To: Fredrik Johansson Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 80: Editorial changes Message-ID: <20010619054121.H17928@charizard.diameter.org> Mail-Followup-To: Fredrik Johansson , Pat Calhoun , aaa-wg@merit.edu References: <20010618103037.N17928@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from fredrik.johansson@ipunplugged.com on Tue, Jun 19, 2001 at 08:33:18AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Jun 19, 2001 at 08:33:18AM +0200, Fredrik Johansson wrote: > Hi, > > Shouldn't the End-to-End Identifier be a monotonically increased number as > the hop-by-hop id, otherwise you'll have to keep a lot of IDs stored for > every Origin-Host. > > " End-to-End Identifier > Unlike the Hop-by-Hop Identifier, the End-to-End Identifier is > used to detect duplicate messages, and relay agents MUST NOT > modify this field. The sender of a request or answer message MUST > insert a locally unique value in this field. The combination of > the Origin-Host AVP and this field is used to detect duplicates. > An Answer message which is received with a previously seen End- > to-End Identifier, and is to be locally consumed (see Section 5.2) > SHOULD be silently discarded. The End-to-End identifier is a > monotonically increasing number, whose start value was randomly > generated." We could, but you cannot assume that packets will arrive in order, so your table of e2e ids will have holes in it. Perhaps short-term holes are better than long term ones, though. PatC From owner-aaa-wg@merit.edu Tue Jun 19 08:59:13 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA20267 for ; Tue, 19 Jun 2001 08:59:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7F46A91297; Tue, 19 Jun 2001 08:59:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 42C6E91298; Tue, 19 Jun 2001 08:59:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1A4C791297 for ; Tue, 19 Jun 2001 08:59:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 610C15DDED; Tue, 19 Jun 2001 08:59:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by segue.merit.edu (Postfix) with SMTP id 16E9A5DDDA for ; Tue, 19 Jun 2001 08:59:56 -0400 (EDT) Received: from jc-mac.planete.net (HELO jc.yahoo.com) (194.2.222.120) by smtp.mail.vip.sc5.yahoo.com with SMTP; 19 Jun 2001 12:59:19 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010619145527.00c16b00@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 19 Jun 2001 14:59:05 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 80: Editorial changes Cc: Fredrik Johansson , Pat Calhoun , aaa-wg@merit.edu In-Reply-To: <20010619054121.H17928@charizard.diameter.org> References: <20010618103037.N17928@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk We could use wording and code similar to that found in RFC2401 (IPsec)... Or we can just give a "lifetime" to End-to-End identifiers. I think the latter is probably better than the former, since in high traffic scenarios we could have a duplicate coming back loooong after (in terms of numbers of requests). Jacques. At 14:41 19/06/01, Pat Calhoun wrote: >On Tue, Jun 19, 2001 at 08:33:18AM +0200, Fredrik Johansson wrote: > > Hi, > > > > Shouldn't the End-to-End Identifier be a monotonically increased number as > > the hop-by-hop id, otherwise you'll have to keep a lot of IDs stored for > > every Origin-Host. > > > > " End-to-End Identifier > > Unlike the Hop-by-Hop Identifier, the End-to-End Identifier is > > used to detect duplicate messages, and relay agents MUST NOT > > modify this field. The sender of a request or answer message MUST > > insert a locally unique value in this field. The combination of > > the Origin-Host AVP and this field is used to detect duplicates. > > An Answer message which is received with a previously seen End- > > to-End Identifier, and is to be locally consumed (see Section 5.2) > > SHOULD be silently discarded. The End-to-End identifier is a > > monotonically increasing number, whose start value was randomly > > generated." > >We could, but you cannot assume that packets will arrive in order, so your >table of e2e ids will have holes in it. Perhaps short-term holes are better >than long term ones, though. > >PatC _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Tue Jun 19 09:51:54 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21493 for ; Tue, 19 Jun 2001 09:51:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 15DA19129C; Tue, 19 Jun 2001 09:51:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D9A4F9129D; Tue, 19 Jun 2001 09:51:56 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BF6E59129C for ; Tue, 19 Jun 2001 09:51:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 25DDB5DDFB; Tue, 19 Jun 2001 09:52:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 43B5A5DE07 for ; Tue, 19 Jun 2001 09:52:43 -0400 (EDT) Received: (qmail 24722 invoked by uid 500); 19 Jun 2001 13:41:13 -0000 Date: Tue, 19 Jun 2001 06:41:13 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , Fredrik Johansson , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 80: Editorial changes Message-ID: <20010619064113.J17928@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , Fredrik Johansson , aaa-wg@merit.edu References: <20010618103037.N17928@charizard.diameter.org> <20010619054121.H17928@charizard.diameter.org> <4.3.2.7.2.20010619145527.00c16b00@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010619145527.00c16b00@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Tue, Jun 19, 2001 at 02:59:05PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Jun 19, 2001 at 02:59:05PM +0200, Jacques Caron wrote: > We could use wording and code similar to that found in RFC2401 (IPsec)... > Or we can just give a "lifetime" to End-to-End identifiers. I think the > latter is probably better than the former, since in high traffic scenarios > we could have a duplicate coming back loooong after (in terms of numbers of > requests). and how would you assign a lifetime? On a very high density NAS, there will be many requests sent. So I see three alternatives: 1. As you state, something similar to RFC 2402, where a sliding window is used (see section 3.4.3 of RFC 2402 for more details). This is probably my preferred approach. We would have to state the window size, of course, and in my opinion a window of 128 is safer. 2. Not specify a method, and leave it to implementation (a few will like this too) 3. Specify that the list of identifiers must be maintained (what it is now), define how it is done, but allow for local optimizations. Again, my preference is #1 above. PatC > > Jacques. > > At 14:41 19/06/01, Pat Calhoun wrote: > >On Tue, Jun 19, 2001 at 08:33:18AM +0200, Fredrik Johansson wrote: > > > Hi, > > > > > > Shouldn't the End-to-End Identifier be a monotonically increased number as > > > the hop-by-hop id, otherwise you'll have to keep a lot of IDs stored for > > > every Origin-Host. > > > > > > " End-to-End Identifier > > > Unlike the Hop-by-Hop Identifier, the End-to-End Identifier is > > > used to detect duplicate messages, and relay agents MUST NOT > > > modify this field. The sender of a request or answer message MUST > > > insert a locally unique value in this field. The combination of > > > the Origin-Host AVP and this field is used to detect duplicates. > > > An Answer message which is received with a previously seen End- > > > to-End Identifier, and is to be locally consumed (see Section 5.2) > > > SHOULD be silently discarded. The End-to-End identifier is a > > > monotonically increasing number, whose start value was randomly > > > generated." > > > >We could, but you cannot assume that packets will arrive in order, so your > >table of e2e ids will have holes in it. Perhaps short-term holes are better > >than long term ones, though. > > > >PatC > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > From owner-aaa-wg@merit.edu Tue Jun 19 10:08:25 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21892 for ; Tue, 19 Jun 2001 10:08:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8AE469129F; Tue, 19 Jun 2001 10:08:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5EA09912A0; Tue, 19 Jun 2001 10:08:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 549999129F for ; Tue, 19 Jun 2001 10:08:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C60335DDFB; Tue, 19 Jun 2001 10:09:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id EB9E35DDF7 for ; Tue, 19 Jun 2001 10:09:07 -0400 (EDT) Received: (qmail 24829 invoked by uid 500); 19 Jun 2001 13:57:38 -0000 Date: Tue, 19 Jun 2001 06:57:38 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 59: e2e mandatory status Message-ID: <20010619065738.N17928@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, Can I close this issue with the text that I proposed earlier? Here is the text again for your convenience: The CMS Diameter security application [11] contains two features: 1. A set of messages that allows a Diameter node to establish a security association, which is used to secure AVPs within a Diameter message, even though the message may traverse intermediate Diameter agents. A set of AVPs are also defined to sign and encrypt AVPs, as well as to transport certificates. This feature MUST be supported by Diameter server and proxy agents, SHOULD be supported by Diameter clients, and MAY be supported by relay and redirector agents. 2. A set of messages, known as PDSR and PDSA, allows a Diameter client to request that an agent establish a Diameter security association with a server in a specific realm. This feature MUST be supported by Diameter clients and Proxy agents, and MAY be supported by Diameter servers, relay and redirector agents. PatC From owner-aaa-wg@merit.edu Tue Jun 19 10:11:15 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21930 for ; Tue, 19 Jun 2001 10:11:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3C4CE912A0; Tue, 19 Jun 2001 10:11:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0BF43912A1; Tue, 19 Jun 2001 10:11:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F207B912A0 for ; Tue, 19 Jun 2001 10:11:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6FEBA5DE01; Tue, 19 Jun 2001 10:11:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id DBECB5DDFE for ; Tue, 19 Jun 2001 10:11:56 -0400 (EDT) Received: (qmail 24875 invoked by uid 500); 19 Jun 2001 14:00:27 -0000 Date: Tue, 19 Jun 2001 07:00:27 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 78: DiameterIdentity (host descriptor) matching & values Message-ID: <20010619070027.O17928@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <4.3.2.7.2.20010615182907.00bf49b0@pop.mail.yahoo.com> <20010615105839.V17928@charizard.diameter.org> <20010615111502.W17928@charizard.diameter.org> <4.3.2.7.2.20010617143437.00c7e4c0@pop.mail.yahoo.com> <20010618062510.J17928@charizard.diameter.org> <4.3.2.7.2.20010618154013.00c897a0@pop.mail.yahoo.com> <20010618064553.N17928@charizard.diameter.org> <4.3.2.7.2.20010618161059.00d02100@pop.mail.yahoo.com> <20010618101256.K17928@charizard.diameter.org> <4.3.2.7.2.20010618234632.00bfbd80@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010618234632.00bfbd80@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Mon, Jun 18, 2001 at 11:50:22PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Jun 18, 2001 at 11:50:22PM +0200, Jacques Caron wrote: > At 19:12 18/06/01, Pat Calhoun wrote: > >On Mon, Jun 18, 2001 at 07:15:38PM +0200, Jacques Caron wrote: > > > At 15:45 18/06/01, Pat Calhoun wrote: > > > > Since multiple Diameter processes on a single host cannot > > > > listen for incoming connections on the same port on a given > > > > protocol, the DiameterIdentity is guaranteed to be unique per > > > > host. > > > > > > The "unique per host" seems weirdish to me. I think you mean "unique for > > > any process" (in the sense "no two processes can have the same identity", > > > not in the sense "a process can have only one identity"). > > > >unique per host means that no two processes, threads, or any other programming > >technique, will allow two instances to advertise exactly the same thing. > >Unique > >for any process means that two different processes could advertise the same > >identity, and this would require that they somehow listen on the same port, > >of the same transport, which is not possible. > > Why just "unique per host" and not simply "unique"? Does anyone else favor Jacques proposed of changing "unique per host" to "unique"? > > >ok, but let's be clear that a single identity per process (across all > >interfaces) *will* not work in the NAT case that you provided earlier. In > >these cases, a host would have different personalities based on whether > >the connection was established on the internal vs. external network. > > It will work (really, consider it as a unique opaque identifier. It might > be a random number, it would work the same) unless one wishes to check that > the address provided matches back (a la reverse + forward DNS checking), > which raises the issue below. sure, it could be random, but a port number is guaranteed to be unique, so why bother with a perhaps conflicting random number??? PatC From owner-aaa-wg@merit.edu Tue Jun 19 10:18:46 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22179 for ; Tue, 19 Jun 2001 10:18:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3D718912A1; Tue, 19 Jun 2001 10:18:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 02F16912A2; Tue, 19 Jun 2001 10:18:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EB14B912A1 for ; Tue, 19 Jun 2001 10:18:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6B55A5DE01; Tue, 19 Jun 2001 10:19:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 2402B5DDFE for ; Tue, 19 Jun 2001 10:19:31 -0400 (EDT) Received: (qmail 25564 invoked by uid 500); 19 Jun 2001 14:08:01 -0000 Date: Tue, 19 Jun 2001 07:08:01 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 79: Error handling editorial changes Message-ID: <20010619070801.P17928@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, I tried to address some of these in -06, but was unable to in some cases. Here are my comments on this issue: > - In 9.0, in the result-code AVPs that require Failed-AVPs, need a > clarification whether this is done only by the home server, or by any > proxy/relay on the way done > - In 9.0, what about errors regarding invalid length (packet or AVP)? > Especially for AVPs, since it will be difficult to include a correctly > formatted AVP if length is wrong anyway? done > - In 5.3.2/9.1, DIAMETER_REDIRECT_INDICATION is not defined. done > - clarify the difference between UNABLE_TO_DELIVER and NOT_SERVED? i.e. in > which case is which sent? -- "I know the domain, but cannot reach any > servers" vs "I don't know the domain". done > - any specific messages for DNS errors (transient such as timeouts, or > permanent such as NXDOMAIN)? -- I'd prefer we not have any, buy if you feel > it is necessary, please propose some text. don't think it is necessary, so let's agree to drop it. > - the difference between AUTHORIZATION_REJECTED and AUTHORIZATION_FAILED > is, er, unclear. done. AUTHORIZATION_FAILED was renamed to: DIAMETER_RESOURCES_EXCEEDED 5007 A request was received that cannot be authorized because the user has already expended allowed resources. An example of this error condition is a user that is restricted to one dial-up PPP port, attempts to establish a second PPP connection. > - NO_COMMON_APPLICATION and UNSUPPORTED_VERSION would be better off in > Protocol errors? -- except that protocol errors MUST only be used in MRA... > see the problem :) hmmmm..... well we have three options: 1. leave it as-is. 2. Move it to protocol errors, and a CER that fails would cause an MRA 3. Eliminate MRA, and just use error classes (as I've mentioned numerous times, this is my preferred approach!) > - protocol errors should be usable in any non-'P' messages this fails my parser check.... please try again :) > - missing errors for message or AVP length errors done. > - missing errors for unknown not-proxiable commands? how is this any different from DIAMETER_COMMAND_UNSUPPORTED? > - missing errors for incorrectly set proxiable/not-proxiable flag? ok, I suppose this could be added in -07 > - missing errors for unknown application hmmm..... this used to exist :( it will be added in -07 > - classification of transient/permanent/protocol errors to review no comprendo, as a wise man once said :) PatC From owner-aaa-wg@merit.edu Tue Jun 19 10:20:38 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22227 for ; Tue, 19 Jun 2001 10:20:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DEE44912A2; Tue, 19 Jun 2001 10:20:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A86C3912A3; Tue, 19 Jun 2001 10:20:42 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 98567912A2 for ; Tue, 19 Jun 2001 10:20:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 128305DE01; Tue, 19 Jun 2001 10:21:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 636765DDFE for ; Tue, 19 Jun 2001 10:21:29 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f5JEKrO06816; Tue, 19 Jun 2001 16:20:53 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f5JEKqE01373; Tue, 19 Jun 2001 17:20:52 +0300 (EET DST) Message-ID: <3B2F5FC4.71B73728@lmf.ericsson.se> Date: Tue, 19 Jun 2001 17:20:52 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 59: e2e mandatory status References: <20010619065738.N17928@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sounds reasonable to me. (One minor note perhaps is that I posted last week a proposal that we could perhaps make the PDSR-PDSA apply for all traffic rather than a single domain, releaving the NASes on an additional roundtrip for new domains. Perhaps this could be adopted at the same time, or we could treat it as a separate issue. In any case, it doesn't have fundamental implications so which ever way we decide is fine for me.) Jari -- Jari Arkko, Oy L M Ericsson Ab, 02420 Jorvas, Finland. Tel +358 9 2992480 Fax +358 9 2993052. GSM +358 40 5079256. E-Mail: Jari.Arkko@ericsson.com NEW, UPDATED PRIVATE WWW http://www.arkko.com. Standard disclaimers apply. From owner-aaa-wg@merit.edu Tue Jun 19 10:22:00 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22286 for ; Tue, 19 Jun 2001 10:21:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CDE63912A4; Tue, 19 Jun 2001 10:21:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9D7A1912A7; Tue, 19 Jun 2001 10:21:57 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 37B5F912A4 for ; Tue, 19 Jun 2001 10:21:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A23035DE01; Tue, 19 Jun 2001 10:22:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 1ED4D5DDFE for ; Tue, 19 Jun 2001 10:22:41 -0400 (EDT) Received: (qmail 25638 invoked by uid 500); 19 Jun 2001 14:11:11 -0000 Date: Tue, 19 Jun 2001 07:11:11 -0700 From: Pat Calhoun To: Jari Arkko Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 59: e2e mandatory status Message-ID: <20010619071111.R17928@charizard.diameter.org> Mail-Followup-To: Jari Arkko , Pat Calhoun , aaa-wg@merit.edu References: <20010619065738.N17928@charizard.diameter.org> <3B2F5FC4.71B73728@lmf.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B2F5FC4.71B73728@lmf.ericsson.se>; from Jari.Arkko@lmf.ericsson.se on Tue, Jun 19, 2001 at 05:20:52PM +0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Jun 19, 2001 at 05:20:52PM +0300, Jari Arkko wrote: > Sounds reasonable to me. (One minor note perhaps > is that I posted last week a proposal that we > could perhaps make the PDSR-PDSA apply for all > traffic rather than a single domain, releaving > the NASes on an additional roundtrip for new domains. > Perhaps this could be adopted at the same time, or > we could treat it as a separate issue. In any case, > it doesn't have fundamental implications so which > ever way we decide is fine for me.) right but that issue is covered by 85, but 59. PatC From owner-aaa-wg@merit.edu Tue Jun 19 10:22:02 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22285 for ; Tue, 19 Jun 2001 10:21:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3F075912A5; Tue, 19 Jun 2001 10:21:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0CCAF912A4; Tue, 19 Jun 2001 10:21:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 87B79912A6 for ; Tue, 19 Jun 2001 10:21:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 04B035DDFE; Tue, 19 Jun 2001 10:21:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from newman.frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 4AB675DE02 for ; Tue, 19 Jun 2001 10:21:53 -0400 (EDT) Received: (qmail 32131 invoked by uid 500); 19 Jun 2001 14:21:17 -0000 Date: Tue, 19 Jun 2001 09:21:16 -0500 From: David Frascone To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 78: DiameterIdentity (host descriptor) matching & values Message-ID: <20010619092116.A32094@newman.frascone.com> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <20010615105839.V17928@charizard.diameter.org> <20010615111502.W17928@charizard.diameter.org> <4.3.2.7.2.20010617143437.00c7e4c0@pop.mail.yahoo.com> <20010618062510.J17928@charizard.diameter.org> <4.3.2.7.2.20010618154013.00c897a0@pop.mail.yahoo.com> <20010618064553.N17928@charizard.diameter.org> <4.3.2.7.2.20010618161059.00d02100@pop.mail.yahoo.com> <20010618101256.K17928@charizard.diameter.org> <4.3.2.7.2.20010618234632.00bfbd80@pop.mail.yahoo.com> <20010619070027.O17928@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010619070027.O17928@charizard.diameter.org>; from pcalhoun@diameter.org on Tue, Jun 19, 2001 at 07:00:27AM -0700 X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Jun 19, 2001 at 07:00:27AM -0700, Pat Calhoun wrote: > On Mon, Jun 18, 2001 at 11:50:22PM +0200, Jacques Caron wrote: > > At 19:12 18/06/01, Pat Calhoun wrote: > > >On Mon, Jun 18, 2001 at 07:15:38PM +0200, Jacques Caron wrote: > > > > At 15:45 18/06/01, Pat Calhoun wrote: > > > > > Since multiple Diameter processes on a single host cannot > > > > > listen for incoming connections on the same port on a given > > > > > protocol, the DiameterIdentity is guaranteed to be unique per> > > > > host. > > > > > > > > The "unique per host" seems weirdish to me. I think you mean "unique for> > > > any process" (in the sense "no two processes can have the same identity", > > > > not in the sense "a process can have only one identity"). > > > > > >unique per host means that no two processes, threads, or any other programming > > >technique, will allow two instances to advertise exactly the same thing. > > >Unique > > >for any process means that two different processes could advertise the same> > >identity, and this would require that they somehow listen on the same port,> > >of the same transport, which is not possible. > > > > Why just "unique per host" and not simply "unique"? > > Does anyone else favor Jacques proposed of changing "unique per host" to "unique"? I'm against the change. "unique" implies that it is unique everywhere, which is impossible to implement. -Dave From owner-aaa-wg@merit.edu Tue Jun 19 10:29:16 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22539 for ; Tue, 19 Jun 2001 10:29:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 26A63912A6; Tue, 19 Jun 2001 10:29:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F08F5912A7; Tue, 19 Jun 2001 10:29:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D8541912A6 for ; Tue, 19 Jun 2001 10:29:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 597E75DE01; Tue, 19 Jun 2001 10:29:59 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 17F2B5DDFE for ; Tue, 19 Jun 2001 10:29:59 -0400 (EDT) Received: (qmail 25726 invoked by uid 500); 19 Jun 2001 14:18:29 -0000 Date: Tue, 19 Jun 2001 07:18:29 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 81: Route-Record change Message-ID: <20010619071829.T17928@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, This issue requests a change on how the Route-Record is used. Specifically, it is added by the receiver, instead of the sender. I see now reason to make this change, but am willing to be convinced otherwise, if people believe this is a reasonable request. Otherwise, I'd like to just shut it down. PatC From owner-aaa-wg@merit.edu Tue Jun 19 10:55:51 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23211 for ; Tue, 19 Jun 2001 10:55:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B50EC91229; Tue, 19 Jun 2001 10:55:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8B13F912A7; Tue, 19 Jun 2001 10:55:47 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5C48D91229 for ; Tue, 19 Jun 2001 10:55:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BF0E65DE01; Tue, 19 Jun 2001 10:56:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp014.mail.yahoo.com (smtp014.mail.yahoo.com [216.136.173.58]) by segue.merit.edu (Postfix) with SMTP id 74E005DDFC for ; Tue, 19 Jun 2001 10:56:34 -0400 (EDT) Received: from s146.dhcp212-198-137.noos.fr (HELO jc.yahoo.com) (212.198.137.146) by smtp.mail.vip.sc5.yahoo.com with SMTP; 19 Jun 2001 14:55:57 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010619164942.00c0a630@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 19 Jun 2001 16:54:16 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 78: DiameterIdentity (host descriptor) matching & values Cc: Pat Calhoun , aaa-wg@merit.edu In-Reply-To: <20010619070027.O17928@charizard.diameter.org> References: <4.3.2.7.2.20010618234632.00bfbd80@pop.mail.yahoo.com> <4.3.2.7.2.20010615182907.00bf49b0@pop.mail.yahoo.com> <20010615105839.V17928@charizard.diameter.org> <20010615111502.W17928@charizard.diameter.org> <4.3.2.7.2.20010617143437.00c7e4c0@pop.mail.yahoo.com> <20010618062510.J17928@charizard.diameter.org> <4.3.2.7.2.20010618154013.00c897a0@pop.mail.yahoo.com> <20010618064553.N17928@charizard.diameter.org> <4.3.2.7.2.20010618161059.00d02100@pop.mail.yahoo.com> <20010618101256.K17928@charizard.diameter.org> <4.3.2.7.2.20010618234632.00bfbd80@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 16:00 19/06/01, Pat Calhoun wrote: > > >ok, but let's be clear that a single identity per process (across all > > >interfaces) *will* not work in the NAT case that you provided earlier. In > > >these cases, a host would have different personalities based on whether > > >the connection was established on the internal vs. external network. > > > > It will work (really, consider it as a unique opaque identifier. It might > > be a random number, it would work the same) unless one wishes to check > that > > the address provided matches back (a la reverse + forward DNS checking), > > which raises the issue below. > >sure, it could be random, but a port number is guaranteed to be unique, so >why bother with a perhaps conflicting random number??? I didn't say we should use a random number. I was just pointing out the nature of the identifier: unique and opaque. Its uniqueness is derived from its syntax, but the syntax has no particular meaning otherwise in this context, so it is completely irrelevant whether the remote host "understands it". It would only be a problem if there was some way to actually check it, but since this will be done using crypto rather than IP addressing/routing, it's not an issue. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Tue Jun 19 11:01:09 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23347 for ; Tue, 19 Jun 2001 11:01:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 24CEB912A7; Tue, 19 Jun 2001 11:00:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E27AB912A8; Tue, 19 Jun 2001 11:00:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B3FB0912A7 for ; Tue, 19 Jun 2001 11:00:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 31CD35DDFB; Tue, 19 Jun 2001 11:01:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp010.mail.yahoo.com (smtp010.mail.yahoo.com [216.136.173.30]) by segue.merit.edu (Postfix) with SMTP id ACCDE5DDF7 for ; Tue, 19 Jun 2001 11:01:32 -0400 (EDT) Received: from s146.dhcp212-137.cybercable.fr (HELO jc.yahoo.com) (212.198.137.146) by smtp.mail.vip.sc5.yahoo.com with SMTP; 19 Jun 2001 15:00:54 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010619165708.00cbc7c0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 19 Jun 2001 16:58:29 +0200 To: David Frascone From: Jacques Caron Subject: Re: [AAA-WG]: Issue 78: DiameterIdentity (host descriptor) matching & values Cc: Pat Calhoun , aaa-wg@merit.edu In-Reply-To: <20010619092116.A32094@newman.frascone.com> References: <20010619070027.O17928@charizard.diameter.org> <20010615105839.V17928@charizard.diameter.org> <20010615111502.W17928@charizard.diameter.org> <4.3.2.7.2.20010617143437.00c7e4c0@pop.mail.yahoo.com> <20010618062510.J17928@charizard.diameter.org> <4.3.2.7.2.20010618154013.00c897a0@pop.mail.yahoo.com> <20010618064553.N17928@charizard.diameter.org> <4.3.2.7.2.20010618161059.00d02100@pop.mail.yahoo.com> <20010618101256.K17928@charizard.diameter.org> <4.3.2.7.2.20010618234632.00bfbd80@pop.mail.yahoo.com> <20010619070027.O17928@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 16:21 19/06/01, David Frascone wrote: >I'm against the change. "unique" implies that it is unique everywhere, which >is impossible to implement. It is unique if we assume the FQDN is unique for any given host. Indeed it might not be, but that's the original intent, otherwise the whole thing just doesn't work. The diameteridentity, as used in CER/CEA and Route-Record MUST be globally unique. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Tue Jun 19 11:08:18 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23546 for ; Tue, 19 Jun 2001 11:08:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D1FBF912A8; Tue, 19 Jun 2001 11:07:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 83455912A9; Tue, 19 Jun 2001 11:07:55 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 751E0912A8 for ; Tue, 19 Jun 2001 11:07:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 06FFC5DDFC; Tue, 19 Jun 2001 11:08:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id A7C545DDF7 for ; Tue, 19 Jun 2001 11:08:41 -0400 (EDT) Received: (qmail 25963 invoked by uid 500); 19 Jun 2001 14:50:27 -0000 Date: Tue, 19 Jun 2001 07:50:27 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 78: DiameterIdentity (host descriptor) matching & values Message-ID: <20010619075027.W17928@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <20010615111502.W17928@charizard.diameter.org> <4.3.2.7.2.20010617143437.00c7e4c0@pop.mail.yahoo.com> <20010618062510.J17928@charizard.diameter.org> <4.3.2.7.2.20010618154013.00c897a0@pop.mail.yahoo.com> <20010618064553.N17928@charizard.diameter.org> <4.3.2.7.2.20010618161059.00d02100@pop.mail.yahoo.com> <20010618101256.K17928@charizard.diameter.org> <4.3.2.7.2.20010618234632.00bfbd80@pop.mail.yahoo.com> <20010619070027.O17928@charizard.diameter.org> <4.3.2.7.2.20010619164942.00c0a630@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010619164942.00c0a630@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Tue, Jun 19, 2001 at 04:54:16PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Jun 19, 2001 at 04:54:16PM +0200, Jacques Caron wrote: > At 16:00 19/06/01, Pat Calhoun wrote: > >sure, it could be random, but a port number is guaranteed to be unique, so > >why bother with a perhaps conflicting random number??? > > I didn't say we should use a random number. I was just pointing out the > nature of the identifier: unique and opaque. Its uniqueness is derived from > its syntax, but the syntax has no particular meaning otherwise in this > context, so it is completely irrelevant whether the remote host > "understands it". It would only be a problem if there was some way to > actually check it, but since this will be done using crypto rather than IP > addressing/routing, it's not an issue. So I can close this one, right? PatC From owner-aaa-wg@merit.edu Tue Jun 19 11:08:22 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23556 for ; Tue, 19 Jun 2001 11:08:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 991D6912AA; Tue, 19 Jun 2001 11:07:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 66C8B912A9; Tue, 19 Jun 2001 11:07:59 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9523F912AA for ; Tue, 19 Jun 2001 11:07:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 16C6C5DDF7; Tue, 19 Jun 2001 11:08:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id ED0FA5DDFB for ; Tue, 19 Jun 2001 11:08:42 -0400 (EDT) Received: (qmail 26064 invoked by uid 500); 19 Jun 2001 14:52:09 -0000 Date: Tue, 19 Jun 2001 07:52:09 -0700 From: Pat Calhoun To: Jacques Caron Cc: David Frascone , Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 78: DiameterIdentity (host descriptor) matching & values Message-ID: <20010619075209.X17928@charizard.diameter.org> Mail-Followup-To: Jacques Caron , David Frascone , Pat Calhoun , aaa-wg@merit.edu References: <4.3.2.7.2.20010617143437.00c7e4c0@pop.mail.yahoo.com> <20010618062510.J17928@charizard.diameter.org> <4.3.2.7.2.20010618154013.00c897a0@pop.mail.yahoo.com> <20010618064553.N17928@charizard.diameter.org> <4.3.2.7.2.20010618161059.00d02100@pop.mail.yahoo.com> <20010618101256.K17928@charizard.diameter.org> <4.3.2.7.2.20010618234632.00bfbd80@pop.mail.yahoo.com> <20010619070027.O17928@charizard.diameter.org> <20010619092116.A32094@newman.frascone.com> <4.3.2.7.2.20010619165708.00cbc7c0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010619165708.00cbc7c0@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Tue, Jun 19, 2001 at 04:58:29PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Jun 19, 2001 at 04:58:29PM +0200, Jacques Caron wrote: > At 16:21 19/06/01, David Frascone wrote: > >I'm against the change. "unique" implies that it is unique everywhere, which > >is impossible to implement. > > It is unique if we assume the FQDN is unique for any given host. Indeed it > might not be, but that's the original intent, otherwise the whole thing > just doesn't work. The diameteridentity, as used in CER/CEA and > Route-Record MUST be globally unique. true an FQDN is unique, but some clustering or fault-torelant systems may employ clever schemes to make a multiple boxes look like a single one. So, unique (or even unique per host) is relative. :( PatC From owner-aaa-wg@merit.edu Tue Jun 19 11:11:54 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23751 for ; Tue, 19 Jun 2001 11:11:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 56FA9912A9; Tue, 19 Jun 2001 11:11:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 22890912AB; Tue, 19 Jun 2001 11:11:46 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 10799912A9 for ; Tue, 19 Jun 2001 11:11:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 940415DDFC; Tue, 19 Jun 2001 11:12:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 4EA205DDF7 for ; Tue, 19 Jun 2001 11:12:33 -0400 (EDT) Received: (qmail 26379 invoked by uid 500); 19 Jun 2001 15:01:03 -0000 Date: Tue, 19 Jun 2001 08:01:03 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 83: Routing/forwarding clarifications Message-ID: <20010619080103.Y17928@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Here's a few questions on this particular issue: > - If multiple hosts listed for a given realm (redirect, relay, proxy), use > the same one for a given Session (either need to maintain Session state or > to use some hash function based on Session-ID) unless error occurs (and > then keep that one that works). The transport draft already describes how primary/alternates are chosen. I don't think that the base protocol needs to discuss this as well. > - Clarify if connections to peers are supposed to be opened at startup, or > when needed only. Again, this is handled in the transport draft. > - Clarify relationship of server discovery (SLP, DNS A, DNS SRV...) with > peer table and/or routing table. ok, this *could* be done, but seems really implementation specific. How one adds a peer entry doesn't seem like it belongs, but let me look at the spec and see what I can do. > - move peer and routing table description earlier in the doc (somewhere in > 2.5 or 2.6). I think that describing the routing and peer tables before we've even discussed routing packets seems illogical to me :( > - Clarify whether "on-demand" connections (e.g. Redirect-Host with > certificate) should timeout. This is already in -06, right? > - refuse connection to oneself another one that begs the question as to whether it isn't obvious enough. PatC From owner-aaa-wg@merit.edu Tue Jun 19 11:19:57 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23933 for ; Tue, 19 Jun 2001 11:19:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B1374912AC; Tue, 19 Jun 2001 11:19:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7EC5B912AB; Tue, 19 Jun 2001 11:19:53 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2AB57912AC for ; Tue, 19 Jun 2001 11:19:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9338D5DE01; Tue, 19 Jun 2001 11:20:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 507355DDF7 for ; Tue, 19 Jun 2001 11:20:40 -0400 (EDT) Received: (qmail 26404 invoked by uid 500); 19 Jun 2001 15:09:10 -0000 Date: Tue, 19 Jun 2001 08:09:10 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 85: Cms-sec optimization for pdsr-case Message-ID: <20010619080910.Z17928@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, I would like to propose the following text to resolve this issue: 1.2 Establishing Security Relationship through proxy agents [...] An optimized approach also allows the PDSR to be sent by the access device without the DSAR-Target-Domain AVP. This message is used to inform the proxy that it MUST establish a Diameter security association for all realms it will be communicating with on behalf of the access device. PatC From owner-aaa-wg@merit.edu Tue Jun 19 11:38:44 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24444 for ; Tue, 19 Jun 2001 11:38:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BF62A912AB; Tue, 19 Jun 2001 11:38:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D004912B0; Tue, 19 Jun 2001 11:38:38 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 56521912AB for ; Tue, 19 Jun 2001 11:38:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D1F1A5DE01; Tue, 19 Jun 2001 11:39:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by segue.merit.edu (Postfix) with SMTP id 515A85DDF7 for ; Tue, 19 Jun 2001 11:39:25 -0400 (EDT) Received: from s146.dhcp212-137.cybercable.fr (HELO jc.yahoo.com) (212.198.137.146) by smtp.mail.vip.sc5.yahoo.com with SMTP; 19 Jun 2001 15:38:48 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010619173616.00bc48d0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 19 Jun 2001 17:36:36 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 87: Move filter-rule AVP to base Cc: aaa-wg@merit.edu In-Reply-To: <20010619082248.B17928@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk You may want to replace NAS by access device? Jacques. At 17:22 19/06/01, Pat Calhoun wrote: >All, > >Below is the proposed text, but I still haven't received any input on >whether this was an acceptable change. > >Thanks, > >PatC >---- >4.4 Derived AVP Data Formats > >[...] > FilterRule > The Filter-Rule format is derived from the OctetString AVP Base > Format. It uses the UTF-8 encoding and has the same > requirements as the UTF8String. Packets may be filtered based > on the following information that is associated with it: > > Direction (in or out) > Source and destination IP address (possibly masked) > Protocol > Source and destination port (lists or ranges) > TCP flags > IP fragment flag > IP options > ICMP types > > Rules for the appropriate direction are evaluated in order, > with the first matched rule terminating the evaluation. Each > packet is evaluated once. If no rule matches, the packet is > dropped if the last rule evaluated was a permit, and passed if > the last rule was a deny. > > The filters in the Filter-Rule AVP MUST follow the format: > > action dir proto from src to dst [options] > > action permit - Allow packets that match the rule. > deny - Drop packets that match the rule. > > dir "in" is from the terminal, "out" is to the > terminal. > > proto An IP protocol specified by number. The "ip" > keyword means any protocol will match. > > src and dst
[ports] > > The
may be specified as: > ipno An IPv4 or IPv6 number in dotted- > quad or canonical IPv6 form. Only > this exact IP number will match the > rule. > ipno/bits An IP number as above with a mask > width of the form 1.2.3.4/24. In > this case all IP numbers from > 1.2.3.0 to 1.2.3.255 will match. > The bit width MUST be valid for the > IP version and the IP number MUST > NOT have bits set beyond the mask. > > The sense of the match can be inverted by > preceding an address with the not modifier, > causing all other addresses to be matched > instead. This does not affect the selection of > port numbers. > > The keyword "any" is 0.0.0.0/0 or the IPv6 > equivalent. The keyword "assigned" is the > address or set of addresses assigned to the > terminal. The first rule SHOULD be "deny in > ip !assigned". > > With the TCP and UDP protocols, optional ports > may be specified as: > > {port|port-port}[,port[,...]] > > The `-' notation specifies a range of ports > (including boundaries). > > Fragmented packets which have a non-zero offset > (i.e. not the first fragment) will never match > a rule which has one or more port > specifications. See the frag option for > details on matching fragmented packets. > > options: > frag Match if the packet is a fragment and this is not > the first fragment of the datagram. frag may not > be used in conjunction with either tcpflags or > TCP/UDP port specifications. > > ipoptions spec > Match if the IP header contains the comma > separated list of options specified in spec. The > supported IP options are: > > ssrr (strict source route), lsrr (loose source > route), rr (record packet route) and ts > (timestamp). The absence of a particular option > may be denoted with a `!'. > > tcpoptions spec > Match if the TCP header contains the comma > separated list of options specified in spec. The > supported TCP options are: > > mss (maximum segment size), window (tcp window > advertisement), sack (selective ack), ts (rfc1323 > timestamp) and cc (rfc1644 t/tcp connection > count). The absence of a particular option may > be denoted with a `!'. > > established > TCP packets only. Match packets that have the RST > or ACK bits set. > > setup TCP packets only. Match packets that have the SYN > bit set but no ACK bit. > > tcpflags spec > TCP packets only. Match if the TCP header > contains the comma separated list of flags > specified in spec. The supported TCP flags are: > > fin, syn, rst, psh, ack and urg. The absence of a > particular flag may be denoted with a `!'. A rule > which contains a tcpflags specification can never > match a fragmented packet which has a non-zero > offset. See the frag option for details on > matching fragmented packets. > > icmptypes types > ICMP packets only. Match if the ICMP type is in > the list types. The list may be specified as any > combination of ranges or individual types > separated by commas. The supported ICMP types > are: > > echo reply (0), destination unreachable (3), > source quench (4), redirect (5), echo request > (8), router advertisement (9), router > solicitation (10), time-to-live exceeded (11), IP > header bad (12), timestamp request (13), > timestamp reply (14), information request (15), > information reply (16), address mask request (17) > and address mask reply (18). > > There is one kind of packet that the NAS MUST always discard, > that is an IP fragment with a fragment offset of one. This is > a valid packet, but it only has one use, to try to circumvent > firewalls. > > A NAS that is unable to interpret or apply a deny rule MUST > terminate the session. A NAS that is unable to interpret or > apply a permit rule MAY apply a more restrictive rule. A > NAS MAY apply deny rules of its own before the supplied > rules, for example to protect the NAS owner's > infrastructure. > > The rule syntax is a modified subset of ipfw(8) from FreeBSD, > and the ipfw.c code may provide a useful base for > implementations. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Tue Jun 19 11:44:53 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24592 for ; Tue, 19 Jun 2001 11:44:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 84D28912AF; Tue, 19 Jun 2001 11:33:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5487A912B0; Tue, 19 Jun 2001 11:33:31 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 36349912AF for ; Tue, 19 Jun 2001 11:33:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AFFB45DE01; Tue, 19 Jun 2001 11:34:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id DBF755DDF7 for ; Tue, 19 Jun 2001 11:34:17 -0400 (EDT) Received: (qmail 26513 invoked by uid 500); 19 Jun 2001 15:22:48 -0000 Date: Tue, 19 Jun 2001 08:22:48 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 87: Move filter-rule AVP to base Message-ID: <20010619082248.B17928@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, Below is the proposed text, but I still haven't received any input on whether this was an acceptable change. Thanks, PatC ---- 4.4 Derived AVP Data Formats [...] FilterRule The Filter-Rule format is derived from the OctetString AVP Base Format. It uses the UTF-8 encoding and has the same requirements as the UTF8String. Packets may be filtered based on the following information that is associated with it: Direction (in or out) Source and destination IP address (possibly masked) Protocol Source and destination port (lists or ranges) TCP flags IP fragment flag IP options ICMP types Rules for the appropriate direction are evaluated in order, with the first matched rule terminating the evaluation. Each packet is evaluated once. If no rule matches, the packet is dropped if the last rule evaluated was a permit, and passed if the last rule was a deny. The filters in the Filter-Rule AVP MUST follow the format: action dir proto from src to dst [options] action permit - Allow packets that match the rule. deny - Drop packets that match the rule. dir "in" is from the terminal, "out" is to the terminal. proto An IP protocol specified by number. The "ip" keyword means any protocol will match. src and dst
[ports] The
may be specified as: ipno An IPv4 or IPv6 number in dotted- quad or canonical IPv6 form. Only this exact IP number will match the rule. ipno/bits An IP number as above with a mask width of the form 1.2.3.4/24. In this case all IP numbers from 1.2.3.0 to 1.2.3.255 will match. The bit width MUST be valid for the IP version and the IP number MUST NOT have bits set beyond the mask. The sense of the match can be inverted by preceding an address with the not modifier, causing all other addresses to be matched instead. This does not affect the selection of port numbers. The keyword "any" is 0.0.0.0/0 or the IPv6 equivalent. The keyword "assigned" is the address or set of addresses assigned to the terminal. The first rule SHOULD be "deny in ip !assigned". With the TCP and UDP protocols, optional ports may be specified as: {port|port-port}[,port[,...]] The `-' notation specifies a range of ports (including boundaries). Fragmented packets which have a non-zero offset (i.e. not the first fragment) will never match a rule which has one or more port specifications. See the frag option for details on matching fragmented packets. options: frag Match if the packet is a fragment and this is not the first fragment of the datagram. frag may not be used in conjunction with either tcpflags or TCP/UDP port specifications. ipoptions spec Match if the IP header contains the comma separated list of options specified in spec. The supported IP options are: ssrr (strict source route), lsrr (loose source route), rr (record packet route) and ts (timestamp). The absence of a particular option may be denoted with a `!'. tcpoptions spec Match if the TCP header contains the comma separated list of options specified in spec. The supported TCP options are: mss (maximum segment size), window (tcp window advertisement), sack (selective ack), ts (rfc1323 timestamp) and cc (rfc1644 t/tcp connection count). The absence of a particular option may be denoted with a `!'. established TCP packets only. Match packets that have the RST or ACK bits set. setup TCP packets only. Match packets that have the SYN bit set but no ACK bit. tcpflags spec TCP packets only. Match if the TCP header contains the comma separated list of flags specified in spec. The supported TCP flags are: fin, syn, rst, psh, ack and urg. The absence of a particular flag may be denoted with a `!'. A rule which contains a tcpflags specification can never match a fragmented packet which has a non-zero offset. See the frag option for details on matching fragmented packets. icmptypes types ICMP packets only. Match if the ICMP type is in the list types. The list may be specified as any combination of ranges or individual types separated by commas. The supported ICMP types are: echo reply (0), destination unreachable (3), source quench (4), redirect (5), echo request (8), router advertisement (9), router solicitation (10), time-to-live exceeded (11), IP header bad (12), timestamp request (13), timestamp reply (14), information request (15), information reply (16), address mask request (17) and address mask reply (18). There is one kind of packet that the NAS MUST always discard, that is an IP fragment with a fragment offset of one. This is a valid packet, but it only has one use, to try to circumvent firewalls. A NAS that is unable to interpret or apply a deny rule MUST terminate the session. A NAS that is unable to interpret or apply a permit rule MAY apply a more restrictive rule. A NAS MAY apply deny rules of its own before the supplied rules, for example to protect the NAS owner's infrastructure. The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the ipfw.c code may provide a useful base for implementations. From owner-aaa-wg@merit.edu Tue Jun 19 12:05:03 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25048 for ; Tue, 19 Jun 2001 12:05:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EF643912B3; Tue, 19 Jun 2001 12:05:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B6DBD912B4; Tue, 19 Jun 2001 12:04:59 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A2BCB912B3 for ; Tue, 19 Jun 2001 12:04:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2CAFE5DE02; Tue, 19 Jun 2001 12:05:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by segue.merit.edu (Postfix) with ESMTP id B35CA5DE01 for ; Tue, 19 Jun 2001 12:05:46 -0400 (EDT) Received: from JSCHNIZL-W2K.cisco.com (rtp-vpn-70.cisco.com [10.82.192.70]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA06085; Tue, 19 Jun 2001 09:04:38 -0700 (PDT) Message-Id: <4.3.2.7.2.20010619114451.00b99ef0@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 19 Jun 2001 12:03:02 -0400 To: Pat Calhoun From: John Schnizlein Subject: Re: [AAA-WG]: Issue 87: Move filter-rule AVP to base Cc: aaa-wg@merit.edu In-Reply-To: <20010619082248.B17928@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-wg@merit.edu Precedence: bulk How much trouble would it be to include DiffServ Codepoints (DSCPs)? As long as this is going in the base, we might make it more general. John Additions to your specification included below: At 11:22 AM 6/19/2001, Pat Calhoun wrote: >Below is the proposed text, but I still haven't received >any input on whether this was an acceptable change. > >---- >4.4 Derived AVP Data Formats > >[...] > FilterRule > The Filter-Rule format is derived from the OctetString AVP Base > Format. It uses the UTF-8 encoding and has the same > requirements as the UTF8String. Packets may be filtered based > on the following information that is associated with it: > > Direction (in or out) > Source and destination IP address (possibly masked) > Protocol > Source and destination port (lists or ranges) > TCP flags > IP fragment flag > IP options DSCP values (no mask or range) > ICMP types > > Rules for the appropriate direction are evaluated in order, > with the first matched rule terminating the evaluation. Each > packet is evaluated once. If no rule matches, the packet is > dropped if the last rule evaluated was a permit, and passed if > the last rule was a deny. > > The filters in the Filter-Rule AVP MUST follow the format: > > action dir proto from src to dst [options] > > action permit - Allow packets that match the rule. > deny - Drop packets that match the rule. color DSCP meter rate color_under color_over > dir "in" is from the terminal, "out" is to the > terminal. > > proto An IP protocol specified by number. The "ip" > keyword means any protocol will match. > > src and dst
[ports] > > The
may be specified as: > ipno An IPv4 or IPv6 number in dotted- > quad or canonical IPv6 form. Only > this exact IP number will match the > rule. > ipno/bits An IP number as above with a mask > width of the form 1.2.3.4/24. In > this case all IP numbers from > 1.2.3.0 to 1.2.3.255 will match. > The bit width MUST be valid for the > IP version and the IP number MUST > NOT have bits set beyond the mask. > > The sense of the match can be inverted by > preceding an address with the not modifier, > causing all other addresses to be matched > instead. This does not affect the selection of > port numbers. > > The keyword "any" is 0.0.0.0/0 or the IPv6 > equivalent. The keyword "assigned" is the > address or set of addresses assigned to the > terminal. The first rule SHOULD be "deny in > ip !assigned". > > With the TCP and UDP protocols, optional ports > may be specified as: > > {port|port-port}[,port[,...]] > > The `-' notation specifies a range of ports > (including boundaries). > > Fragmented packets which have a non-zero offset > (i.e. not the first fragment) will never match > a rule which has one or more port > specifications. See the frag option for > details on matching fragmented packets. > > options: > frag Match if the packet is a fragment and this is not > the first fragment of the datagram. frag may not > be used in conjunction with either tcpflags or > TCP/UDP port specifications. > > ipoptions spec > Match if the IP header contains the comma > separated list of options specified in spec. The > supported IP options are: > > ssrr (strict source route), lsrr (loose source > route), rr (record packet route) and ts > (timestamp). The absence of a particular option > may be denoted with a `!'. > > tcpoptions spec > Match if the TCP header contains the comma > separated list of options specified in spec. The > supported TCP options are: > > mss (maximum segment size), window (tcp window > advertisement), sack (selective ack), ts (rfc1323 > timestamp) and cc (rfc1644 t/tcp connection > count). The absence of a particular option may > be denoted with a `!'. > > established > TCP packets only. Match packets that have the RST > or ACK bits set. > > setup TCP packets only. Match packets that have the SYN > bit set but no ACK bit. > > tcpflags spec > TCP packets only. Match if the TCP header > contains the comma separated list of flags > specified in spec. The supported TCP flags are: > > fin, syn, rst, psh, ack and urg. The absence of a > particular flag may be denoted with a `!'. A rule > which contains a tcpflags specification can never > match a fragmented packet which has a non-zero > offset. See the frag option for details on > matching fragmented packets. DSCP values as defined in RFC 2474. Exact matching of DSCP values is required (no masks or ranges). the "deny" can replace the color_under or color_over values in the meter action for rate-dependent packet drop. > icmptypes types > ICMP packets only. Match if the ICMP type is in > the list types. The list may be specified as any > combination of ranges or individual types > separated by commas. The supported ICMP types > are: > > echo reply (0), destination unreachable (3), > source quench (4), redirect (5), echo request > (8), router advertisement (9), router > solicitation (10), time-to-live exceeded (11), IP > header bad (12), timestamp request (13), > timestamp reply (14), information request (15), > information reply (16), address mask request (17) > and address mask reply (18). > > There is one kind of packet that the NAS MUST always discard, > that is an IP fragment with a fragment offset of one. This is > a valid packet, but it only has one use, to try to circumvent > firewalls. > > A NAS that is unable to interpret or apply a deny rule MUST > terminate the session. A NAS that is unable to interpret or > apply a permit rule MAY apply a more restrictive rule. A > NAS MAY apply deny rules of its own before the supplied > rules, for example to protect the NAS owner's > infrastructure. > > The rule syntax is a modified subset of ipfw(8) from FreeBSD, > and the ipfw.c code may provide a useful base for > implementations. From owner-aaa-wg@merit.edu Tue Jun 19 12:37:08 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26320 for ; Tue, 19 Jun 2001 12:37:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E19649129B; Tue, 19 Jun 2001 12:37:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A91CF912B7; Tue, 19 Jun 2001 12:37:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 86C799129B for ; Tue, 19 Jun 2001 12:37:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3271C5DDE9; Tue, 19 Jun 2001 12:37:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 336C25DDDA for ; Tue, 19 Jun 2001 12:37:55 -0400 (EDT) Received: (qmail 27791 invoked by uid 500); 19 Jun 2001 16:26:25 -0000 Date: Tue, 19 Jun 2001 09:26:25 -0700 From: Pat Calhoun To: John Schnizlein Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 87: Move filter-rule AVP to base Message-ID: <20010619092625.D17928@charizard.diameter.org> Mail-Followup-To: John Schnizlein , Pat Calhoun , aaa-wg@merit.edu References: <20010619082248.B17928@charizard.diameter.org> <4.3.2.7.2.20010619114451.00b99ef0@diablo.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010619114451.00b99ef0@diablo.cisco.com>; from jschnizl@cisco.com on Tue, Jun 19, 2001 at 12:03:02PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk I'm certainly not opposed to the change. The only caviat is the statement at the end regarding ipfw.c, and the change you've requested is probably not supported in that file. Anyone object to the change? Should I clearly state that DSCP is not handled by ipfw? patC On Tue, Jun 19, 2001 at 12:03:02PM -0400, John Schnizlein wrote: > How much trouble would it be to include DiffServ Codepoints (DSCPs)? > As long as this is going in the base, we might make it more general. > John > > Additions to your specification included below: > > At 11:22 AM 6/19/2001, Pat Calhoun wrote: > >Below is the proposed text, but I still haven't received > >any input on whether this was an acceptable change. > > > >---- > >4.4 Derived AVP Data Formats > > > >[...] > > FilterRule > > The Filter-Rule format is derived from the OctetString AVP Base > > Format. It uses the UTF-8 encoding and has the same > > requirements as the UTF8String. Packets may be filtered based > > on the following information that is associated with it: > > > > Direction (in or out) > > Source and destination IP address (possibly masked) > > Protocol > > Source and destination port (lists or ranges) > > TCP flags > > IP fragment flag > > IP options > > DSCP values (no mask or range) > > > ICMP types > > > > Rules for the appropriate direction are evaluated in order, > > with the first matched rule terminating the evaluation. Each > > packet is evaluated once. If no rule matches, the packet is > > dropped if the last rule evaluated was a permit, and passed if > > the last rule was a deny. > > > > The filters in the Filter-Rule AVP MUST follow the format: > > > > action dir proto from src to dst [options] > > > > action permit - Allow packets that match the rule. > > deny - Drop packets that match the rule. > > color DSCP > meter rate color_under color_over > > > > dir "in" is from the terminal, "out" is to the > > terminal. > > > > proto An IP protocol specified by number. The "ip" > > keyword means any protocol will match. > > > > src and dst
[ports] > > > > The
may be specified as: > > ipno An IPv4 or IPv6 number in dotted- > > quad or canonical IPv6 form. Only > > this exact IP number will match the > > rule. > > ipno/bits An IP number as above with a mask > > width of the form 1.2.3.4/24. In > > this case all IP numbers from > > 1.2.3.0 to 1.2.3.255 will match. > > The bit width MUST be valid for the > > IP version and the IP number MUST > > NOT have bits set beyond the mask. > > > > The sense of the match can be inverted by > > preceding an address with the not modifier, > > causing all other addresses to be matched > > instead. This does not affect the selection of > > port numbers. > > > > The keyword "any" is 0.0.0.0/0 or the IPv6 > > equivalent. The keyword "assigned" is the > > address or set of addresses assigned to the > > terminal. The first rule SHOULD be "deny in > > ip !assigned". > > > > With the TCP and UDP protocols, optional ports > > may be specified as: > > > > {port|port-port}[,port[,...]] > > > > The `-' notation specifies a range of ports > > (including boundaries). > > > > Fragmented packets which have a non-zero offset > > (i.e. not the first fragment) will never match > > a rule which has one or more port > > specifications. See the frag option for > > details on matching fragmented packets. > > > > options: > > frag Match if the packet is a fragment and this is not > > the first fragment of the datagram. frag may not > > be used in conjunction with either tcpflags or > > TCP/UDP port specifications. > > > > ipoptions spec > > Match if the IP header contains the comma > > separated list of options specified in spec. The > > supported IP options are: > > > > ssrr (strict source route), lsrr (loose source > > route), rr (record packet route) and ts > > (timestamp). The absence of a particular option > > may be denoted with a `!'. > > > > tcpoptions spec > > Match if the TCP header contains the comma > > separated list of options specified in spec. The > > supported TCP options are: > > > > mss (maximum segment size), window (tcp window > > advertisement), sack (selective ack), ts (rfc1323 > > timestamp) and cc (rfc1644 t/tcp connection > > count). The absence of a particular option may > > be denoted with a `!'. > > > > established > > TCP packets only. Match packets that have the RST > > or ACK bits set. > > > > setup TCP packets only. Match packets that have the SYN > > bit set but no ACK bit. > > > > tcpflags spec > > TCP packets only. Match if the TCP header > > contains the comma separated list of flags > > specified in spec. The supported TCP flags are: > > > > fin, syn, rst, psh, ack and urg. The absence of a > > particular flag may be denoted with a `!'. A rule > > which contains a tcpflags specification can never > > match a fragmented packet which has a non-zero > > offset. See the frag option for details on > > matching fragmented packets. > > DSCP values as defined in RFC 2474. Exact matching of > DSCP values is required (no masks or ranges). > the "deny" can replace the color_under or > color_over values in the meter action for > rate-dependent packet drop. > > > icmptypes types > > ICMP packets only. Match if the ICMP type is in > > the list types. The list may be specified as any > > combination of ranges or individual types > > separated by commas. The supported ICMP types > > are: > > > > echo reply (0), destination unreachable (3), > > source quench (4), redirect (5), echo request > > (8), router advertisement (9), router > > solicitation (10), time-to-live exceeded (11), IP > > header bad (12), timestamp request (13), > > timestamp reply (14), information request (15), > > information reply (16), address mask request (17) > > and address mask reply (18). > > > > There is one kind of packet that the NAS MUST always discard, > > that is an IP fragment with a fragment offset of one. This is > > a valid packet, but it only has one use, to try to circumvent > > firewalls. > > > > A NAS that is unable to interpret or apply a deny rule MUST > > terminate the session. A NAS that is unable to interpret or > > apply a permit rule MAY apply a more restrictive rule. A > > NAS MAY apply deny rules of its own before the supplied > > rules, for example to protect the NAS owner's > > infrastructure. > > > > The rule syntax is a modified subset of ipfw(8) from FreeBSD, > > and the ipfw.c code may provide a useful base for > > implementations. > From owner-aaa-wg@merit.edu Tue Jun 19 13:38:59 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28319 for ; Tue, 19 Jun 2001 13:38:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4B9CA912B6; Tue, 19 Jun 2001 13:39:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1F4A8912B7; Tue, 19 Jun 2001 13:39:03 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1D742912B6 for ; Tue, 19 Jun 2001 13:39:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C58F25DE25; Tue, 19 Jun 2001 13:39:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by segue.merit.edu (Postfix) with ESMTP id 3259B5DE15 for ; Tue, 19 Jun 2001 13:39:50 -0400 (EDT) Received: from JSCHNIZL-W2K.cisco.com (rtp-vpn-70.cisco.com [10.82.192.70]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA02718; Tue, 19 Jun 2001 10:38:41 -0700 (PDT) Message-Id: <4.3.2.7.2.20010619132444.00ba4548@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 19 Jun 2001 13:37:15 -0400 To: Pat Calhoun From: John Schnizlein Subject: Re: [AAA-WG]: Issue 87: Move filter-rule AVP to base Cc: aaa-wg@merit.edu In-Reply-To: <20010619092625.D17928@charizard.diameter.org> References: <4.3.2.7.2.20010619114451.00b99ef0@diablo.cisco.com> <20010619082248.B17928@charizard.diameter.org> <4.3.2.7.2.20010619114451.00b99ef0@diablo.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-wg@merit.edu Precedence: bulk Without looking, I assume there is no DSCP in FreeBSD's ipfw(8). But your text already said "modified subset". Only state explicitly that this filter option is not in ipfw(8) if you are prepared to fight its introduction there and/or revise your document when/if they realize that a single filter specification is better than the variety of different ones (just because there are different WGs). Now that you mention it, should a standards-track document include this sort of implementation suggestion? John At 12:26 PM 6/19/2001, Pat Calhoun wrote: >I'm certainly not opposed to the change. The only caviat is the >statement at the end regarding ipfw.c, and the change you've >requested is probably not supported in that file. >... >> > The rule syntax is a modified subset of ipfw(8) from FreeBSD, >> > and the ipfw.c code may provide a useful base for implementations. From owner-aaa-wg@merit.edu Tue Jun 19 13:42:11 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28455 for ; Tue, 19 Jun 2001 13:42:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DA13B912B7; Tue, 19 Jun 2001 13:42:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A7C10912B8; Tue, 19 Jun 2001 13:42:06 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 95992912B7 for ; Tue, 19 Jun 2001 13:42:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 528885DE2D; Tue, 19 Jun 2001 13:42:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id EBC0F5DE15 for ; Tue, 19 Jun 2001 13:42:53 -0400 (EDT) Received: (qmail 28682 invoked by uid 500); 19 Jun 2001 17:31:23 -0000 Date: Tue, 19 Jun 2001 10:31:23 -0700 From: Pat Calhoun To: John Schnizlein Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 87: Move filter-rule AVP to base Message-ID: <20010619103123.L17928@charizard.diameter.org> Mail-Followup-To: John Schnizlein , Pat Calhoun , aaa-wg@merit.edu References: <4.3.2.7.2.20010619114451.00b99ef0@diablo.cisco.com> <20010619082248.B17928@charizard.diameter.org> <4.3.2.7.2.20010619114451.00b99ef0@diablo.cisco.com> <20010619092625.D17928@charizard.diameter.org> <4.3.2.7.2.20010619132444.00ba4548@diablo.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010619132444.00ba4548@diablo.cisco.com>; from jschnizl@cisco.com on Tue, Jun 19, 2001 at 01:37:15PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Jun 19, 2001 at 01:37:15PM -0400, John Schnizlein wrote: > Without looking, I assume there is no DSCP in FreeBSD's ipfw(8). > But your text already said "modified subset". re-reading the text, you are correct. > > Only state explicitly that this filter option is not in ipfw(8) if you > are prepared to fight its introduction there and/or revise your document > when/if they realize that a single filter specification is better than > the variety of different ones (just because there are different WGs). > > Now that you mention it, should a standards-track document include this > sort of implementation suggestion? I don't think it hurts. PatC > > John > > At 12:26 PM 6/19/2001, Pat Calhoun wrote: > >I'm certainly not opposed to the change. The only caviat is the > >statement at the end regarding ipfw.c, and the change you've > >requested is probably not supported in that file. > >... > >> > The rule syntax is a modified subset of ipfw(8) from FreeBSD, > >> > and the ipfw.c code may provide a useful base for implementations. > From owner-aaa-wg@merit.edu Tue Jun 19 14:06:31 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29220 for ; Tue, 19 Jun 2001 14:06:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7C230912BA; Tue, 19 Jun 2001 14:06:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 475EA912BB; Tue, 19 Jun 2001 14:06:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 373E6912BA for ; Tue, 19 Jun 2001 14:06:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F23035DD9E; Tue, 19 Jun 2001 14:07:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id B023E5DD92 for ; Tue, 19 Jun 2001 14:07:23 -0400 (EDT) Received: (qmail 28808 invoked by uid 500); 19 Jun 2001 17:55:53 -0000 Date: Tue, 19 Jun 2001 10:55:53 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 51: EAP Roundtrips Message-ID: <20010619105553.N17928@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Henry, Could you please take a look at the text I just sent to the list to fix Issue 88, and tell me what changes would be required to handle 51. The fixes in 88 are a result of operational experience in 802/radius networks. The change in 51 is a proposed optimization, as I understand it, may break interoperability with 802 and radius networks. Is this correct? PatC From owner-aaa-wg@merit.edu Tue Jun 19 14:14:49 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29425 for ; Tue, 19 Jun 2001 14:14:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 42AA3912B8; Tue, 19 Jun 2001 14:02:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 10489912BA; Tue, 19 Jun 2001 14:02:48 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E6286912B8 for ; Tue, 19 Jun 2001 14:02:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 99F895DD9E; Tue, 19 Jun 2001 14:03:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id E29795DD92 for ; Tue, 19 Jun 2001 14:03:35 -0400 (EDT) Received: (qmail 28781 invoked by uid 500); 19 Jun 2001 17:52:05 -0000 Date: Tue, 19 Jun 2001 10:52:05 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 88: Proposed Text for EAP Support Issues Message-ID: <20010619105205.M17928@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, I hadn't really noticed how bad this section needed some rev'ing up :( I believe that I have address all of the concerns in this issue in the following text: 4.0 Extensible Authentication Protocol Support The Extensible Authentication Protocol (EAP), described in [25], provides a standard mechanism for support of extensible authentication methods. Through the use of EAP, support for a number of authentication schemes may be added, including smart and token cards, Kerberos, Public Key, One Time Passwords, and others. This section describes the Command-Codes values and AVPs that are required for an EAP payload to be encapsulated within the Diameter protocol. Since authentication occurs between the EAP client and its home Diameter server, end-to-end authentication is achieved, reducing the possibility for fraudulent authentication, such as replay and man-in-the-middle attacks. End-to-end authentication also provides for mutual (bi-directional) authentication, which is not possible with PAP and CHAP in a roaming PPP environment. The EAP conversation between the authenticating peer and the access device begins with the negotiation of EAP within a link layer, such as PPP or 802.1x. Once EAP has been negotiated, the access device will typically send to the Diameter server a Diameter-EAP-Request message with a NULL EAP-Payload AVP, signifying an EAP-Start. The Port number and the identity of the access device (e.g. Origin-Host or NAS-Identifier) MUST be included in the Diameter-EAP-Request message. If the Diameter home server supports EAP, it MUST respond with a Diameter-EAP-Answer message containing an EAP-Payload AVP that includes an encapsulated EAP payload [25], and the Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH, signifying that a subsequent request is expected. The EAP payload is forwarded by the access device to the EAP client. The initial Diameter-EAP-Answer in a multi-round exchange normally includes an EAP-Request/Identity, requesting the EAP client to identify itself. Upon receipt of the EAP client's EAP-Response [25], the access device will then issue a second Diameter-EAP-Request message, with the client's EAP payload encapsulated within the EAP- Payload AVP. A preferred approach is for the access device to issue the EAP- Request/Identity message to the EAP client, and forward the EAP- Response/Identity packet, encapsulated within the EAP-Payload AVP, as a Diameter-EAP-Request to the Diameter server. This alternative reduces the number of Diameter message round trips, and is compatible with roaming environments, since the Destination-Realm is needed by Diameter agents for routing purposes. Note that this alternative cannot be universally employed, as there are circumstances where a user's identity is not needed (such as when authorization occurs based on a calling or called phone number). The conversation continues until the Diameter server sends a Diameter-EAP-Answer with a Result-Code AVP indicating success or failure, and an optional EAP-Payload. The Result-Code AVP is used by the access device to determine whether service is to be provided to the EAP client. The access device MUST NOT rely on the contents of the optional EAP-Payload to determine whether service is to be provided. A Diameter-EAP-Answer message containing an EAP-Payload of type EAP- Success or EAP-Failure MUST NOT have the Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH. If authorization was requested, a successful Diameter-EAP-Answer MUST also include the appropriate authorization AVPs required for the service requested (see sections 2.0, 6.0 and 7.0). Unless the access device interprets the EAP-Response/Identity packet returned by the authenticating peer, it will not have access to the user's identity. Therefore, the Diameter Server SHOULD return the user's identity by inserting it in the User-Name attribute of subsequent Diameter-EAP-Answer packets. Without the user's identity, the Session-Id AVP MAY be used for accounting and billing, however operationally this MAY be very difficult to manage. A home Diameter server MAY request EAP re-authentication by issuing the Re-Auth-Request [2] message to the Diameter client. Should an EAP authentication session be interrupted due to a home server failure, the session MAY be directed to an alternate server, but the authentication session will have to be restarted from the beginning. If a response is received with the Result-Code set to DIAMETER_COMMAND_UNSUPPORTED [2], it is an indication that the Diameter server in the home domain does not support EAP. If possible, the access device MAY attempt to negotiate another authentication protocol, such as PAP or CHAP. An access device SHOULD be cautious when determining whether a less secure authentication protocol will be used, since this could be a result of a bidding down attack. [...] 4.2.1 Diameter-EAP-Request (DER) Command The Diameter-EAP-Request (DER) command, indicated by the Command-Code field set to 268 and the 'R' bit set in the Command Flags field, is sent by a Diameter client to a Diameter server and conveys an EAP- Response [25] from the EAP client. The Diameter-EAP-Request MUST contain one EAP-Payload AVP, which contains the actual EAP payload. An EAP-Payload AVP with no data MAY be sent to the Diameter server to initiate an EAP authentication session. The DER message MAY be the result of a multi-round authentication exchange, which occurs when the DEA is received with the Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH. A subsequent DER message MUST include any State AVPs that were present in the DEA. For re- authentication, it is recommended that the Identity request be skipped in order to reduce the number of authentication round trips. This is only possible when the user's identity is already known by the home Diameter server. Message Format ::= < Diameter Header: 268, REQ, PXY > < Session-Id > { Auth-Application-Id } { Origin-Host } { Origin-Realm } { Destination-Realm } { Service-Type } { EAP-Payload } [ Destination-Host ] [ Authorization-Lifetime ] [ Session-Timeout ] [ User-Name ] [ Idle-Timeout ] [ NAS-IP-Address ] [ NAS-Identifier ] [ State ] [ Origin-State-Id ] [ NAS-Key-Binding ] * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] 4.2.2 Diameter-EAP-Answer (DEA) Command The Diameter-EAP-Answer (DEA) message, indicated by the Command-Code field set to 268 and the 'R' bit cleared in the Command Flags field, is sent by the Diameter server to the client for one of the following reasons: 1) The message is part of a multi-round authentication exchange, and the server is expecting a subsequent Diameter-EAP-Request. This is indicated by setting the Result-Code to DIAMETER_MULTI_ROUND_AUTH, and MAY include zero or more State AVPs. 2) the EAP client has been successfully authenticated and authorized, in which case the message MUST include the Result- Code AVP indicating success, and SHOULD include an EAP-Payload of type EAP-Success. This event MUST cause the access device to provide service to the EAP client. 3) The EAP client has not been successfully authenticated and/or authorized, and the Result-Code AVP is set to indicate failure. This message MAY include an EAP-Payload, but this AVP is not used to determine whether service is to be provided. If the message from the Diameter client included a request for authorization, a successful response MUST include the authorization AVPs that are relevant to the service being provided. Message Format ::= < Diameter Header: 268, PXY > < Session-Id > { Auth-Application-Id } { Result-Code } { Origin-Host } { Origin-Realm } { Destination-Host } { Service-Type } [ Error-Reporting-Host ] [ EAP-Payload ] [ User-Name ] [ Idle-Timeout ] [ Authorization-Lifetime ] [ Session-Timeout ] [ Origin-State-Id ] * [ NAS-Session-Key ] * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] 4.3 EAP-Payload AVP The EAP-Payload AVP (AVP Code 402) is of type OctetString and is used to encapsulate the actual EAP payload [25] that is being exchanged between the EAP client and the home Diameter server. From owner-aaa-wg@merit.edu Tue Jun 19 14:16:24 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29478 for ; Tue, 19 Jun 2001 14:16:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8B884912BB; Tue, 19 Jun 2001 14:16:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 59364912BC; Tue, 19 Jun 2001 14:16:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2483E912BB for ; Tue, 19 Jun 2001 14:16:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CE0695DD9E; Tue, 19 Jun 2001 14:17:00 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 438405DDED for ; Tue, 19 Jun 2001 14:17:00 -0400 (EDT) Received: (qmail 28884 invoked by uid 500); 19 Jun 2001 18:05:30 -0000 Date: Tue, 19 Jun 2001 11:05:30 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 82: Reauthorization Issues Message-ID: <20010619110529.O17928@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, I have some comments on this issue. > - In 10.7 (and elsewhere) clarify Authorization-Lifetime (means Reauth > should be performed) and Session-Timeout. Resources should be liberated > upon Session-Timeout only, not upon Authorization-Lifetime expiration. but it is valid for an answer message to only include the Authorization-Lifetime, and not the Session-Timeout. > - Change name of Authorization-Lifetime to Reauthorization-Timeout I'm not particularly fond of this one. > - Authorization-Lifetime and Session-Timeout based from start of Session or > from receipt of message (in reauth)? ok, this should be clarified. Of course, I wonder what the right answer is. a couple of options: 1. a re-auth is expected after Authorization-Lifetime, and if no answer is received by Session-Timeout, resources are cleaned up. 2. Session-Timeout is the end of the session. The user is free to re-auth, but once session-timeout expires (from the beginning of the session), it's game over. > - In reauth, is it allowed to change authorization parameters (filters, > IPs...)? good question. perhaps some text stating that non-conflicting authorization information MAY be returned in re-auth messages. PatC From owner-aaa-wg@merit.edu Tue Jun 19 17:49:10 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05900 for ; Tue, 19 Jun 2001 17:49:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0F2D89122A; Tue, 19 Jun 2001 17:49:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D348B9122C; Tue, 19 Jun 2001 17:49:03 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AA7A29122A for ; Tue, 19 Jun 2001 17:49:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B95F05DDA7; Tue, 19 Jun 2001 17:49:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by segue.merit.edu (Postfix) with SMTP id 6F5505DD92 for ; Tue, 19 Jun 2001 17:49:51 -0400 (EDT) Received: from jc-mac.planete.net (HELO jc.yahoo.com) (194.2.222.120) by smtp.mail.vip.sc5.yahoo.com with SMTP; 19 Jun 2001 21:49:14 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010619205157.00b3f180@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 19 Jun 2001 23:49:01 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 82: Reauthorization Issues Cc: aaa-wg@merit.edu In-Reply-To: <20010619110529.O17928@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 20:05 19/06/01, Pat Calhoun wrote: >All, > >I have some comments on this issue. > > > - In 10.7 (and elsewhere) clarify Authorization-Lifetime (means Reauth > > should be performed) and Session-Timeout. Resources should be liberated > > upon Session-Timeout only, not upon Authorization-Lifetime expiration. > >but it is valid for an answer message to only include the >Authorization-Lifetime, >and not the Session-Timeout. The problem is that if Authorization-Lifetime is a trigger for a reauth request, then there should be some time between the start of the reauth and really freeing all associated resources. But there should be an absolute maximum to the session duration. I would say that if there is an Authorization-Lifetime, there should be a Session-Timeout too, with a value slightly higher. In other words, Authorization-Lifetime just means "ask for a reauth after n seconds". If that doesn't happen, then the session is dropped because of Session-Timeout, not because of Authorization-Lifetime (otherwise there is a duplicate in semantics). > > - Change name of Authorization-Lifetime to Reauthorization-Timeout > >I'm not particularly fond of this one. Depends on the exact semantics of the AVP as detailed above. > > - Authorization-Lifetime and Session-Timeout based from start of > Session or > > from receipt of message (in reauth)? > >ok, this should be clarified. Of course, I wonder what the right answer is. >a couple of options: > >1. a re-auth is expected after Authorization-Lifetime, and if no answer > is received by Session-Timeout, resources are cleaned up. That's what I think, but the issue is: - upon reauth, there should be a new Authorization-Lifetime & Session-Timeout. - from when are these counted? The original authorization, or the new one? >2. Session-Timeout is the end of the session. The user is free to re-auth, > but once session-timeout expires (from the beginning of the session), > it's game over. Don't quite see the difference (other than you don't mention Auth-Lifetime)? > > - In reauth, is it allowed to change authorization parameters (filters, > > IPs...)? > >good question. perhaps some text stating that non-conflicting authorization >information MAY be returned in re-auth messages. How do you define "non-conflicting"? A few "hints" on that... - it is quite useful to be able to change filters on the fly (e.g. a user starts with restricted filters, then something external makes us open the filters. Or the opposite, a user starts with full access, but then upon reauth we find out that he's out of credits, but we still want him/her to have access to a specific www site to buy some more, so we just close filters instead of just disconnecting the user) - some things like IP addresses are quite harder to change on the fly, at least in an PPP context. [which raises an interesting point, does Diameter have everything needed to centralize DHCP authorization?] Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Wed Jun 20 02:23:06 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA26587 for ; Wed, 20 Jun 2001 02:23:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0BCFE9122E; Wed, 20 Jun 2001 02:23:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C5C3C91230; Wed, 20 Jun 2001 02:23:02 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A526A9122E for ; Wed, 20 Jun 2001 02:23:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 53FA65DDDE; Wed, 20 Jun 2001 02:23:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id A03BD5DD91 for ; Wed, 20 Jun 2001 02:23:50 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id XAA08838; Tue, 19 Jun 2001 23:17:04 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 19 Jun 2001 23:17:04 -0700 (PDT) From: Bernard Aboba To: Jacques Caron Cc: henry.haverinen@nokia.com, pcalhoun@diameter.org, aaa-wg@merit.edu Subject: RE: [AAA-WG]: [Issue] EAP Support issues In-Reply-To: <4.3.2.7.2.20010618164441.00c3dcc0@pop.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Some more discussion on EAP issues. One question (which is really an EAP issue) is whether it is possible to authentication with several EAP methods, one after another, and if so, how this is done in AAA. 1. Serial reauths. With this technique, you do one EAP auth, send an EAP success, and then do another one. The re-auth can be NAS initiated, or server initiated. If NAS initiated, you need a way for the AAA server to tell the NAS "reauthenticate right away!". It has been suggested that this can be accomplished within RADIUS by setting Session-Time=0 and Termination-Action=Radius-Request. If server initiated (Diameter can do this, but RADIUS can't), then the server can send a Challenge to the NAS with an encapsulated EAP-Message attribute to start the next auth. The question with serial reauths is whether an EAP-Success can be encapsulated in a Challenge packet so that the NAS won't let the user have acess until the last auth Accept/EAP-Success is sent. Assuming that the re-auth is driven correctly (by NAS with Session-Time=0 or by server),allowing this might not be so bad after all. What do people think? 2. Multiple auths with one EAP-Success. It's been pointed out that an EAP conversation already involves multiple methods (Identity, MD5, etc.). So why can't the AAA server not send the EAP-Success, and start another EAP type instead? To the NAS this looks like one conversation, it won't be looking at the changing EAP types. When the last auth completes, an EAP-Success is sent. This technique requires no changes to AAA; but if we think this functionality is useful/necessary it might be worth pointing out that it can be done. I think that in some respects it is cleaner than method #1: the client is not fooled into thinking it has network access when it doesn't. Additional issue: * Is it possible to send Key attributes in an Access-Challenge so as to turn on encryption in the middle of an authentication conversation? I vote no on this since at least in PPP, you can't do ECP until you've finished LCP. If you want this, you can finish one auth, send a Success and keys, then do re-auth. So I think it's not necessary. From owner-aaa-wg@merit.edu Wed Jun 20 03:59:49 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA00384 for ; Wed, 20 Jun 2001 03:59:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CD2F791231; Wed, 20 Jun 2001 03:59:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9923991232; Wed, 20 Jun 2001 03:59:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6C44B91231 for ; Wed, 20 Jun 2001 03:59:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2B83C5DDA1; Wed, 20 Jun 2001 04:00:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id EA73B5DD8C for ; Wed, 20 Jun 2001 04:00:41 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f5K80KI11882 for ; Wed, 20 Jun 2001 11:00:20 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 20 Jun 2001 11:00:04 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Wed, 20 Jun 2001 11:00:04 +0300 Message-ID: From: jukka.aakula@nokia.com To: pcalhoun@diameter.org, aaa-wg@merit.edu Subject: RE: [AAA-WG]: [Issue] Proposed fix for Grouped AVP (Issue 11) Date: Wed, 20 Jun 2001 11:00:03 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, Why does the Grouped AVP not support the "alternatives" of ABNF ? Jukka Aakula From owner-aaa-wg@merit.edu Wed Jun 20 06:14:11 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01451 for ; Wed, 20 Jun 2001 06:14:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1FC0891232; Wed, 20 Jun 2001 06:14:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D39CD91233; Wed, 20 Jun 2001 06:14:06 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BF2E991232 for ; Wed, 20 Jun 2001 06:14:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C778D5DDED; Wed, 20 Jun 2001 06:14:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr [193.49.124.31]) by segue.merit.edu (Postfix) with SMTP id 4A5DA5DD8C for ; Wed, 20 Jun 2001 06:14:55 -0400 (EDT) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 12:13:23 +0200 Message-ID: From: NGUYEN Kim Anh Vu FTRD/DMR/ISS To: "'Pat Calhoun'" Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: New set of drafts posted Date: Wed, 20 Jun 2001 12:13:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Pat, Thank for the hard job, i have a stupid question regarding the message header It is indicated that the "message length" field is a two-octet fiels but on the figure i can see 3 octets Is this means that the version field has 2 octet ? Thank in advance BR Kim Nguyen -----Message d'origine----- De : Pat Calhoun [mailto:pcalhoun@diameter.org] Envoye : mardi 5 juin 2001 03:04 A : aaa-wg@merit.edu Objet : [AAA-WG]: New set of drafts posted All, In order to give people time to digest the changes that have been made to the Diameter drafts, I am sending a new version to the secretariat. The new versions, as usual, can be found at www.diameter.org. Please note that the E2E draft has changed name. After a security review, it was decided that End-to-End really wasn't an appropriate name, and has been called the CMS Security Application. Yes, extensions are now applications, as per Issue #54. I changed the issues web site considerable today. All of the closed issues are in a separate table, and the table shows the rev of the draft an issue was take care of. All open issues are in their own table. I am still waiting for a few issue description from folks, so I would appreciate if those people could send text. Enjoy, PatC From owner-aaa-wg@merit.edu Wed Jun 20 07:07:44 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02194 for ; Wed, 20 Jun 2001 07:07:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6847891233; Wed, 20 Jun 2001 07:07:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 34B0591234; Wed, 20 Jun 2001 07:07:40 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 075EC91233 for ; Wed, 20 Jun 2001 07:07:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 117115DDCD; Wed, 20 Jun 2001 07:08:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 5E1285DD8C for ; Wed, 20 Jun 2001 07:08:28 -0400 (EDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f5KB86324710 for ; Wed, 20 Jun 2001 14:08:06 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 20 Jun 2001 14:07:50 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Wed, 20 Jun 2001 14:07:50 +0300 Message-ID: From: henry.haverinen@nokia.com To: pcalhoun@diameter.org, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 51: EAP Roundtrips Date: Wed, 20 Jun 2001 14:07:48 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk > Could you please take a look at the text I just sent to the > list to fix Issue 88, > and tell me what changes would be required to handle 51. The > fixes in 88 are a > result of operational experience in 802/radius networks. The > change in 51 is a > proposed optimization, as I understand it, may break > interoperability with 802 > and radius networks. Is this correct? Pat, I included the changes below. It is true that the operation of the NAS and the Diameter server with this optimization would be different from the operation in Radius. But as Diameter is a new protocol, I don't see any problems in requiring Diameter nodes to implement new things. The current 802 documents refer to Radius, and if this optimization is adopted, then new Diameter-specific operation will be required in 802 nodes and PPP servers that implement Diameter. Interoperability with existing Radius networks may become an issue. It would be hard to do protocol translation from "optimized" Diameter to Radius, if the AAA server speaks Diameter and the NAS Radius (we'd need stateful translation). But it would be easy to translate from "unoptimized" Diameter to Radius. And if the AAA server speaks Radius and the NAS Diameter, then protocol translation to "unoptimized" Diameter would be easy to implement. Regards, Henry Proposed addition: A Diameter-EAP-Answer message with the Result-Code AVP indicating success or failure MAY contain an EAP-Payload of type EAP-Request. In this case the Diameter server does not expect any response to the EAP-Request. As usual, the NAS relies on the Result-Code AVP to determine whether service is to be provided. In any case, the NAS MUST relay the encapsulated EAP-Request to the peer. The NAS MUST retransmit the EAP Request to the peer until a Response packet with the same Identifier is received or an optional retry counter expires. The NAS MUST NOT send the received Response packet to the Diameter server but it MUST discard the Response packet. On receipt of the Response packet, the NAS MAY manufacture an EAP-Success or an EAP-Failure (depending on the Result-Code AVP in the Diameter-EAP-Anser message), and send it to the peer. From owner-aaa-wg@merit.edu Wed Jun 20 18:34:46 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25173 for ; Wed, 20 Jun 2001 18:34:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 788C491252; Wed, 20 Jun 2001 18:34:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4241991253; Wed, 20 Jun 2001 18:34:42 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3202F91252 for ; Wed, 20 Jun 2001 18:34:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 348005DD95; Wed, 20 Jun 2001 18:35:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by segue.merit.edu (Postfix) with ESMTP id B8AC35DD93 for ; Wed, 20 Jun 2001 18:35:31 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.92.13]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f5KMYvR18941 for ; Wed, 20 Jun 2001 17:34:57 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f5KMYst01028 for ; Wed, 20 Jun 2001 17:34:54 -0500 (CDT) Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA10859 for ; Wed, 20 Jun 2001 17:34:52 -0500 (CDT) Received: from ericsson.com (busam56.berkeley.us.am.ericsson.se [138.85.159.206]) by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id RAA00220 for ; Wed, 20 Jun 2001 17:34:45 -0500 (CDT) Message-ID: <3B312401.993C0678@ericsson.com> Date: Wed, 20 Jun 2001 15:30:25 -0700 From: Tony Johansson X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue #67: How to deal with CER and CEA in the case of SCTP References: <3B1E7A7D.3FF51B29@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, The new text in section 8.0 Peer Sate Machine supports both the behavior of SCTP and TCP under the condition that the port on which a connection is initiated MUST NOT be the port Diameter listens for incoming connections. Form all of the previous mail discussions I think we all agree that this is the correct assumption in the TCP case, but what about SCTP? In the SCTP case you can use the same port to initiate connections as well as listening for incoming connections. Under these circumstances, the normal operation of SCTP will guarantee you only get one transport layer connection, even if both sides start to initiate the connection at the same time, and there is no need for the I- and R- connection functionality currently defined in the state machine. The drawback in this situation is that SCTP may not be able to tell you whether or not you are deemed the initiator- it ONLY guarantees that you get ONE connection. So, to allow SCTP to use the same port, would unfortunately require some additional handling of the CER and CEA :(, because as soon as the transport connection is established both peers may ending up issuing CER. I'm not sure how far we should go on this issue. I don't have any problems to reject and close this issue #67 if I'm the only one who sees any utility in allowing incoming and outgoing SCTP connection requests to use the same port. However, if we do see some advantages in this, we only need some additional text that deals with the case that a peer receives a CER instead of an CEA, like the following. In the case Diameter is configured over SCTP to initiate and listen for connection requests on the same port, SCTP will not make use of the I- and R- states defined in the state machine. Under these circumstances, in the event that two peers attempt to connect at the same time, SCTP will automatically resolve the connection requests into a single connection, and both peers may issue CER. When both peers send the CER and then receive the CER from the other peer instead of a CEA, it MUST in these cases treat the received CER as a CEA. Comments, please. /Tony From owner-aaa-wg@merit.edu Wed Jun 20 18:49:17 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25367 for ; Wed, 20 Jun 2001 18:49:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EA52E91254; Wed, 20 Jun 2001 18:49:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B817491255; Wed, 20 Jun 2001 18:49:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A3C9B91254 for ; Wed, 20 Jun 2001 18:49:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ABDB55DDA7; Wed, 20 Jun 2001 18:50:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 20A475DD93 for ; Wed, 20 Jun 2001 18:50:02 -0400 (EDT) Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA02566 for ; Wed, 20 Jun 2001 15:49:23 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA19051 for ; Wed, 20 Jun 2001 15:49:21 -0700 (PDT) Message-Id: <200106202249.PAA19051@heliopolis.eng.sun.com> Date: Wed, 20 Jun 2001 15:49:21 -0700 (PDT) From: Jonathan Wood Reply-To: Jonathan Wood Subject: Re: [AAA-WG]: Issue #67: How to deal with CER and CEA in the case of SCTP To: aaa-wg@merit.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: JbqcZmEA9IKhNFcNn0UlTg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-aaa-wg@merit.edu Precedence: bulk Tony, The situation is actually the same for TCP and SCTP -- both will automatically merge two identical associations initiated at the same time, and both may have some implementations that permit listening and initiating connections from the same port, while others do not permit it. So I recommend forbidding listening and connecting from the same port under SCTP as well as TCP, and using the same resolution mechanism for SCTP as for TCP. Jonathan > >All, > >The new text in section 8.0 Peer Sate Machine supports both the behavior of >SCTP and TCP under the condition that the port on which a connection is >initiated MUST NOT be the port Diameter listens for incoming connections. > >Form all of the previous mail discussions I think we all agree that this is >the correct assumption in the TCP case, but what about SCTP? In the SCTP >case you can use the same port to initiate connections as well as listening >for incoming connections. Under these circumstances, the normal operation of >SCTP will guarantee you only get one transport layer connection, even if >both sides start to initiate the connection at the same time, and there is >no need for the I- and R- connection functionality currently defined in the >state machine. The drawback in this situation is that SCTP may not be able >to tell you whether or not you are deemed the initiator- it ONLY guarantees >that you get ONE connection. So, to allow SCTP to use the same port, would >unfortunately require some additional handling of the CER and CEA :(, >because as soon as the transport connection is established both peers may >ending up issuing CER. > >I'm not sure how far we should go on this issue. I don't have any problems >to reject and close this issue #67 if I'm the only one who sees any utility >in allowing incoming and outgoing SCTP connection requests to use the same >port. > >However, if we do see some advantages in this, we only need some additional >text that deals with the case that a peer receives a CER instead of an CEA, >like the following. > >In the case Diameter is configured over SCTP to initiate and listen for >connection requests on the same port, SCTP will not make use of the I- and >R- states defined in the state machine. Under these circumstances, in the >event that two peers attempt to connect at the same time, SCTP will >automatically resolve the connection requests into a single connection, and >both peers may issue CER. When both peers send the CER and then receive the >CER from the other peer instead of a CEA, it MUST in these cases treat the >received CER as a CEA. > >Comments, please. > >/Tony > > > From owner-aaa-wg@merit.edu Thu Jun 21 09:29:25 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27913 for ; Thu, 21 Jun 2001 09:29:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B338F91260; Thu, 21 Jun 2001 09:29:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7CEEA91261; Thu, 21 Jun 2001 09:29:31 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6692591260 for ; Thu, 21 Jun 2001 09:29:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 969245DDCE; Thu, 21 Jun 2001 09:30:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id B57AC5DD95 for ; Thu, 21 Jun 2001 09:30:16 -0400 (EDT) Received: (qmail 2131 invoked by uid 500); 21 Jun 2001 13:11:45 -0000 Date: Thu, 21 Jun 2001 06:11:45 -0700 From: Pat Calhoun To: henry.haverinen@nokia.com Cc: pcalhoun@diameter.org, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 51: EAP Roundtrips Message-ID: <20010621061145.D1322@charizard.diameter.org> Mail-Followup-To: henry.haverinen@nokia.com, pcalhoun@diameter.org, aaa-wg@merit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from henry.haverinen@nokia.com on Wed, Jun 20, 2001 at 02:07:48PM +0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Jun 20, 2001 at 02:07:48PM +0300, henry.haverinen@nokia.com wrote: > I included the changes below. > > It is true that the operation of the NAS and the Diameter > server with this optimization would be different from the > operation in Radius. But as Diameter is a new protocol, I don't > see any problems in requiring Diameter nodes to implement > new things. The current 802 documents refer to Radius, and if > this optimization is adopted, then new Diameter-specific > operation will be required in 802 nodes and PPP servers that > implement Diameter. > > Interoperability with existing Radius networks may become an > issue. It would be hard to do protocol translation from "optimized" > Diameter to Radius, if the AAA server speaks Diameter > and the NAS Radius (we'd need stateful translation). > But it would be easy to translate from "unoptimized" Diameter > to Radius. And if the AAA server speaks Radius and the NAS Diameter, > then protocol translation to "unoptimized" Diameter would be > easy to implement. but how would an 802.11 bridge talking optimized Diameter know that protocol translation is being done? There isn't a way to signal to an access device that this is happening, and would require additional protocol design. PatC > > Regards, > Henry > > Proposed addition: > > A Diameter-EAP-Answer message with the Result-Code AVP > indicating success or failure MAY contain an EAP-Payload of > type EAP-Request. In this case the Diameter server does not > expect any response to the EAP-Request. As usual, the NAS relies > on the Result-Code AVP to determine whether service is to be > provided. In any case, the NAS MUST relay the encapsulated EAP-Request > to the peer. The NAS MUST retransmit the EAP Request to the peer until > a Response packet with the same Identifier is received or an optional > retry counter expires. The NAS MUST NOT send the received Response packet > to the Diameter server but it MUST discard the Response packet. > On receipt of the Response packet, the NAS MAY manufacture an > EAP-Success or an EAP-Failure (depending on the Result-Code AVP > in the Diameter-EAP-Anser message), and send it to the peer. From owner-aaa-wg@merit.edu Thu Jun 21 09:36:43 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28289 for ; Thu, 21 Jun 2001 09:36:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CB12C91261; Thu, 21 Jun 2001 09:36:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 96C7D91262; Thu, 21 Jun 2001 09:36:48 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 889A591261 for ; Thu, 21 Jun 2001 09:36:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B4DB75DDCE; Thu, 21 Jun 2001 09:37:39 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 953BA5DD95 for ; Thu, 21 Jun 2001 09:37:34 -0400 (EDT) Received: (qmail 2875 invoked by uid 500); 21 Jun 2001 13:25:56 -0000 Date: Thu, 21 Jun 2001 06:25:56 -0700 From: Pat Calhoun To: NGUYEN Kim Anh Vu FTRD/DMR/ISS Cc: "'Pat Calhoun'" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: New set of drafts posted Message-ID: <20010621062556.F1322@charizard.diameter.org> Mail-Followup-To: NGUYEN Kim Anh Vu FTRD/DMR/ISS , 'Pat Calhoun' , aaa-wg@merit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from kimanhvu.nguyen@rd.francetelecom.fr on Wed, Jun 20, 2001 at 12:13:23PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Jun 20, 2001 at 12:13:23PM +0200, NGUYEN Kim Anh Vu FTRD/DMR/ISS wrote: > Hi Pat, > > Thank for the hard job, i have a stupid question regarding the message > header > It is indicated that the "message length" field is a two-octet fiels but on > the figure i can see 3 octets > Is this means that the version field has 2 octet ? an oversight on my part. PatC From owner-aaa-wg@merit.edu Thu Jun 21 17:14:53 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18042 for ; Thu, 21 Jun 2001 17:14:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F10AB91266; Thu, 21 Jun 2001 17:01:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B152E91267; Thu, 21 Jun 2001 17:01:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 51F2091266 for ; Thu, 21 Jun 2001 17:01:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0C4785DDAE; Thu, 21 Jun 2001 17:02:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by segue.merit.edu (Postfix) with ESMTP id 5D9D65DD97 for ; Thu, 21 Jun 2001 17:02:04 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (motgate3 2.1) with ESMTP id NAA27452 for ; Thu, 21 Jun 2001 13:54:41 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id NAA07997 for ; Thu, 21 Jun 2001 13:54:38 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 16:01:25 -0500 Message-ID: From: Thomas Panagiotis-PTHOMAS1 To: "'Pat Calhoun'" Cc: aaa-wg@merit.edu Subject: [AAA-WG]: MIP-MN-HA-Preferred-SPI in AA-Mobile-Node-Request ? Date: Thu, 21 Jun 2001 16:01:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Pat, Shouldn't the AA-Mobile-Node-Request in draft-ietf-aaa-diameter-mobileip-06.txt also include a MIP-MN-HA-Preferred-SPI AVP, to be sent to AAAH when the MN-HA Key Request From AAA subtype is present in the Registration Request? "2.1 AA-Mobile-Node-Request ... ::= < Diameter Header: 260, REQ, PXY > < Session-ID > { Auth-Application-Id } { User-Name } { Destination-Realm } { Origin-Host } { Origin-Realm } { MIP-Reg-Request } { MIP-MN-AAA-Auth } [ MIP-Mobile-Node-Address ] [ MIP-Home-Agent-Address ] [ MIP-Feature-Vector ] [ Authorization-Lifetime ] [ MIP-FA-MN-Preferred-SPI ] [ MIP-FA-HA-Preferred-SPI ] [ MIP-Previous-FA-Host ] [ MIP-Previous-FA-Addr ] [ MIP-FA-Challenge ] [ Destination-Host ] [ Origin-State-Id ] * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] ..." -Panos From owner-aaa-wg@merit.edu Thu Jun 21 18:58:45 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19699 for ; Thu, 21 Jun 2001 18:58:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BDCD39126B; Thu, 21 Jun 2001 18:58:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D9919126C; Thu, 21 Jun 2001 18:58:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6D1F29126B for ; Thu, 21 Jun 2001 18:58:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5238A5DDA6; Thu, 21 Jun 2001 18:59:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 10AAB5DD96 for ; Thu, 21 Jun 2001 18:59:42 -0400 (EDT) Received: (qmail 18767 invoked by uid 500); 21 Jun 2001 22:48:01 -0000 Date: Thu, 21 Jun 2001 15:48:01 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 51: EAP Roundtrips Message-ID: <20010621154801.H14828@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, A few of us had a call today, and we discussed this issue. We decided that since accepting this issue would cause interoperability problems with RADIUS implementations, it wasn't worth the cost. Unless strong objections are received, we will reject this issue. Thanks, PatC From owner-aaa-wg@merit.edu Thu Jun 21 19:01:15 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19748 for ; Thu, 21 Jun 2001 19:01:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0234E9126C; Thu, 21 Jun 2001 19:01:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A89399126D; Thu, 21 Jun 2001 19:01:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5C7E49126C for ; Thu, 21 Jun 2001 19:01:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 310D45DDA6; Thu, 21 Jun 2001 19:02:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id E330B5DD96 for ; Thu, 21 Jun 2001 19:02:03 -0400 (EDT) Received: (qmail 18792 invoked by uid 500); 21 Jun 2001 22:50:23 -0000 Date: Thu, 21 Jun 2001 15:50:23 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 67: How to deal with CER and CEA in the case of Message-ID: <20010621155023.I14828@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, In our call today, we decided to close this issue, since it will not occur with the current language in -06. Thanks, PatC From owner-aaa-wg@merit.edu Thu Jun 21 20:12:27 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20951 for ; Thu, 21 Jun 2001 20:12:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EBAB89122D; Thu, 21 Jun 2001 20:12:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BB9939126D; Thu, 21 Jun 2001 20:12:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8CBFF9122D for ; Thu, 21 Jun 2001 20:12:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8AEE75DDA6; Thu, 21 Jun 2001 20:13:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 2240B5DD96 for ; Thu, 21 Jun 2001 20:13:22 -0400 (EDT) Received: (qmail 20420 invoked by uid 500); 22 Jun 2001 00:01:41 -0000 Date: Thu, 21 Jun 2001 17:01:41 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 79: Error Handling Editorial Changes Message-ID: <20010621170141.L14828@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, during the call today, we agreed with Issue 79, that it wasn't necessary for a new command code (Message-Reject-Answer) to be used when a protocol error occurs. However, some folks wanted a simpler way to identify that a relay needs to process the message other than parsing through it looking for the Result-Code AVP. So, we decided that introducing the 'E' (error) bit in the header was a very fast and easy way for relays to identify that local processing of a message is necessary. Here is a portion of my proposed text (most of the changes is to replace the term Message-Reject-Answer with something that states that an answer is returned with the 'E' bit set). Comments appreciated, PatC ---- 3.0 Diameter Header A summary of the Diameter header format is shown below. The fields are transmitted in network byte order. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R P E r r r r r| Command-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop-by-Hop Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End-to-End Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVPs ... +-+-+-+-+-+-+-+-+-+-+-+-+- [...] Command Flags The Command Flags field is eight bits. The following bits are assigned: R(equest) - If set, the message is a request. If cleared, the message is an answer. P(roxiable) - If set, the message MAY be proxied. If cleared, the message MUST be locally processed. E(rror) - If set, the message contains a protocol error, and the message will not conform to the ABNF described for this command. This bit MUST NOT be set in request messages. See section x.x. r(eserved) - this flag bit is reserved for future use, and MUST be set to zero. [...] 3.2 Command Code ABNF specification [...] header = "< Diameter-Header:" command-id [r-bit] [p-bit] [e-bit] ">" [...] e-bit = ", ERR" ; If present, the 'E' bit in the Command ; Flags is set, indication that the answer ; message contains a Result-Code AVP in ; the "protocol error" class. [...] 9.2 Error Bit The 'E' (Error Bit) in the Diameter header is set when the request caused a protocol-related error (see section 9.1.3). When set, the answer message will not conform to the ABNF specification for the command, and will instead conform to the following ABNF: Message Format ::= < Diameter Header: code, ERR > < Session-Id > { Origin-Host } { Origin-Realm } { Result-Code } { Destination-Host } [ Origin-State-Id ] [ Error-Reporting-Host ] * [ AVP ] Note that the code used in the header is the same that the one found in the request message, but with the 'R' bit cleared and the 'E' bit set. Thanks, PatC From owner-aaa-wg@merit.edu Fri Jun 22 05:24:49 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA15026 for ; Fri, 22 Jun 2001 05:24:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E1BD291271; Fri, 22 Jun 2001 05:24:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A356691273; Fri, 22 Jun 2001 05:24:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2590191271 for ; Fri, 22 Jun 2001 05:24:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E49C35DD96; Fri, 22 Jun 2001 05:25:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by segue.merit.edu (Postfix) with SMTP id 9C6685DD8D for ; Fri, 22 Jun 2001 05:25:25 -0400 (EDT) Received: from s152.dhcp212-198-137.noos.fr (HELO jc.yahoo.com) (212.198.137.152) by smtp.mail.vip.sc5.yahoo.com with SMTP; 22 Jun 2001 09:24:42 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010622103947.00c721d0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Jun 2001 11:23:07 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 79: Error Handling Editorial Changes Cc: aaa-wg@merit.edu In-Reply-To: <20010621170141.L14828@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, I still think this is redundant with the 'P' bit. A message with 'R' clear and 'P' clear is a non-proxiable answer, and thus something for local processing. Then the combination of Command-Code and Result-Code will tell the proxy/relay whether it's a CEA or a protocol error. Also, I think it would be wise to specify which combinations of the flag bits are allowed, and what to do if an unallowed combination is received. As an aside, I would like just for the record [I'm afraid many might feel it's too late to make such radical changes :-(] to state that my favorite option would be to separate a lot more explicitly the "protocol" part from the "application" part (a bit like HTTP vs HTML or SMTP vs RFC822 e-mail, etc). I think we are still way too close to the Radius model where we just exchange messages on a link, and some happen to be local protocol things and others are end-to-end application things. This is not really good for the robustness and clarity of the protocol. This would apply to command-codes (e.g. CER, CEA, DWR, DWA vs AAA, AAR, etc.), error-codes, and AVPs (some AVPs are used for routing purposes, such as Destination-Host, Destination-Realm, Route-Record..., and are comparable to HTTP headers, while others are purely applicative, such as Framed-IP-Address, User-Name or EAP-Message, and closer to HTML tags). This would probably simplify a lot the ABNF, as all "Application" commands would not be encumbered with all the "protocol" AVPs, too. Note that though the changes are radical, it might not require to change that much text, so it could still be done pretty quickly. Let me know if anyone wants to pursue this [for some reason I doubt it :-(]. Jacques. At 02:01 22/06/01, Pat Calhoun wrote: >All, > >during the call today, we agreed with Issue 79, that it wasn't necessary for >a new command code (Message-Reject-Answer) to be used when a protocol error >occurs. However, some folks wanted a simpler way to identify that a relay >needs to process the message other than parsing through it looking for the >Result-Code AVP. So, we decided that introducing the 'E' (error) bit in the >header was a very fast and easy way for relays to identify that local >processing >of a message is necessary. > >Here is a portion of my proposed text (most of the changes is to replace the >term Message-Reject-Answer with something that states that an answer is >returned >with the 'E' bit set). > >Comments appreciated, > >PatC >---- > >3.0 Diameter Header > > A summary of the Diameter header format is shown below. The fields > are transmitted in network byte order. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Ver | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |R P E r r r r r| Command-Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor-ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Hop-by-Hop Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | End-to-End Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AVPs ... > +-+-+-+-+-+-+-+-+-+-+-+-+- > >[...] > Command Flags > The Command Flags field is eight bits. The following bits are > assigned: > > R(equest) - If set, the message is a request. If cleared, the > message is an answer. > P(roxiable) - If set, the message MAY be proxied. If cleared, > the message MUST be locally processed. > E(rror) - If set, the message contains a protocol error, > and the message will not conform to the ABNF > described for this command. This bit MUST NOT be > set in request messages. See section x.x. > r(eserved) - this flag bit is reserved for future use, and > MUST be set to zero. > >[...] >3.2 Command Code ABNF specification > >[...] > header = "< Diameter-Header:" command-id [r-bit] > [p-bit] [e-bit] ">" >[...] > e-bit = ", ERR" > ; If present, the 'E' bit in the Command > ; Flags is set, indication that the answer > ; message contains a Result-Code AVP in > ; the "protocol error" class. >[...] > >9.2 Error Bit > > The 'E' (Error Bit) in the Diameter header is set when the request > caused a protocol-related error (see section 9.1.3). When set, the > answer message will not conform to the ABNF specification for the > command, and will instead conform to the following ABNF: > > Message Format > > ::= < Diameter Header: code, ERR > > < Session-Id > > { Origin-Host } > { Origin-Realm } > { Result-Code } > { Destination-Host } > [ Origin-State-Id ] > [ Error-Reporting-Host ] > * [ AVP ] > > Note that the code used in the header is the same that the one found > in the request message, but with the 'R' bit cleared and the 'E' bit > set. > > >Thanks, > >PatC _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Fri Jun 22 06:59:47 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA15547 for ; Fri, 22 Jun 2001 06:59:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 765E491270; Fri, 22 Jun 2001 05:24:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4423491271; Fri, 22 Jun 2001 05:24:25 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EB2A591270 for ; Fri, 22 Jun 2001 05:24:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A1F725DD8D; Fri, 22 Jun 2001 05:25:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by segue.merit.edu (Postfix) with SMTP id 123685DD96 for ; Fri, 22 Jun 2001 05:25:17 -0400 (EDT) Received: from s152.dhcp212-198-137.noos.fr (HELO jc.yahoo.com) (212.198.137.152) by smtp.mail.vip.sc5.yahoo.com with SMTP; 22 Jun 2001 09:24:34 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010619210420.00c19180@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Jun 2001 11:23:56 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 88: Proposed Text for EAP Support Issues Cc: aaa-wg@merit.edu In-Reply-To: <20010619105205.M17928@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, Just two stupid questions... I hadn't noticed that EAP actually used different command-codes from regular AAA/AAR. In that case, maybe it should be an altogether different application? Another thing that came to mind while I was reading the Diameter Mobile IP draft this week-end, is there any (existent/planned) interaction between Mobile IP and EAP? Jacques. At 19:52 19/06/01, Pat Calhoun wrote: >All, > >I hadn't really noticed how bad this section needed some rev'ing up :( >I believe that I have address all of the concerns in this issue in >the following text: > >4.0 Extensible Authentication Protocol Support > > The Extensible Authentication Protocol (EAP), described in [25], > provides a standard mechanism for support of extensible > authentication methods. Through the use of EAP, support for a number > of authentication schemes may be added, including smart and token > cards, Kerberos, Public Key, One Time Passwords, and others. > > This section describes the Command-Codes values and AVPs that are > required for an EAP payload to be encapsulated within the Diameter > protocol. Since authentication occurs between the EAP client and its > home Diameter server, end-to-end authentication is achieved, reducing > the possibility for fraudulent authentication, such as replay and > man-in-the-middle attacks. End-to-end authentication also provides > for mutual (bi-directional) authentication, which is not possible > with PAP and CHAP in a roaming PPP environment. > > The EAP conversation between the authenticating peer and the access > device begins with the negotiation of EAP within a link layer, such > as PPP or 802.1x. Once EAP has been negotiated, the access device > will typically send to the Diameter server a Diameter-EAP-Request > message with a NULL EAP-Payload AVP, signifying an EAP-Start. The > Port number and the identity of the access device (e.g. Origin-Host > or NAS-Identifier) MUST be included in the Diameter-EAP-Request > message. > > If the Diameter home server supports EAP, it MUST respond with a > Diameter-EAP-Answer message containing an EAP-Payload AVP that > includes an encapsulated EAP payload [25], and the Result-Code AVP > set to DIAMETER_MULTI_ROUND_AUTH, signifying that a subsequent > request is expected. The EAP payload is forwarded by the access > device to the EAP client. > > The initial Diameter-EAP-Answer in a multi-round exchange normally > includes an EAP-Request/Identity, requesting the EAP client to > identify itself. Upon receipt of the EAP client's EAP-Response [25], > the access device will then issue a second Diameter-EAP-Request > message, with the client's EAP payload encapsulated within the EAP- > Payload AVP. > > A preferred approach is for the access device to issue the EAP- > Request/Identity message to the EAP client, and forward the EAP- > Response/Identity packet, encapsulated within the EAP-Payload AVP, as > a Diameter-EAP-Request to the Diameter server. This alternative > reduces the number of Diameter message round trips, and is compatible > with roaming environments, since the Destination-Realm is needed by > Diameter agents for routing purposes. Note that this alternative > cannot be universally employed, as there are circumstances where a > user's identity is not needed (such as when authorization occurs > based on a calling or called phone number). > > The conversation continues until the Diameter server sends a > Diameter-EAP-Answer with a Result-Code AVP indicating success or > failure, and an optional EAP-Payload. The Result-Code AVP is used by > the access device to determine whether service is to be provided to > the EAP client. The access device MUST NOT rely on the contents of > the optional EAP-Payload to determine whether service is to be > provided. > > A Diameter-EAP-Answer message containing an EAP-Payload of type EAP- > Success or EAP-Failure MUST NOT have the Result-Code AVP set to > DIAMETER_MULTI_ROUND_AUTH. > > If authorization was requested, a successful Diameter-EAP-Answer MUST > also include the appropriate authorization AVPs required for the > service requested (see sections 2.0, 6.0 and 7.0). > > Unless the access device interprets the EAP-Response/Identity packet > returned by the authenticating peer, it will not have access to the > user's identity. Therefore, the Diameter Server SHOULD return the > user's identity by inserting it in the User-Name attribute of > subsequent Diameter-EAP-Answer packets. Without the user's identity, > the Session-Id AVP MAY be used for accounting and billing, however > operationally this MAY be very difficult to manage. > > A home Diameter server MAY request EAP re-authentication by issuing > the Re-Auth-Request [2] message to the Diameter client. > > Should an EAP authentication session be interrupted due to a home > server failure, the session MAY be directed to an alternate server, > but the authentication session will have to be restarted from the > beginning. > > If a response is received with the Result-Code set to > DIAMETER_COMMAND_UNSUPPORTED [2], it is an indication that the > Diameter server in the home domain does not support EAP. If possible, > the access device MAY attempt to negotiate another authentication > protocol, such as PAP or CHAP. An access device SHOULD be cautious > when determining whether a less secure authentication protocol will > be used, since this could be a result of a bidding down attack. > > >[...] > >4.2.1 Diameter-EAP-Request (DER) Command > > The Diameter-EAP-Request (DER) command, indicated by the Command-Code > field set to 268 and the 'R' bit set in the Command Flags field, is > sent by a Diameter client to a Diameter server and conveys an EAP- > Response [25] from the EAP client. The Diameter-EAP-Request MUST > contain one EAP-Payload AVP, which contains the actual EAP payload. > An EAP-Payload AVP with no data MAY be sent to the Diameter server to > initiate an EAP authentication session. > > The DER message MAY be the result of a multi-round authentication > exchange, which occurs when the DEA is received with the Result-Code > AVP set to DIAMETER_MULTI_ROUND_AUTH. A subsequent DER message MUST > include any State AVPs that were present in the DEA. For re- > authentication, it is recommended that the Identity request be > skipped in order to reduce the number of authentication round trips. > This is only possible when the user's identity is already known by > the home Diameter server. > > > Message Format > > ::= < Diameter Header: 268, REQ, PXY > > < Session-Id > > { Auth-Application-Id } > { Origin-Host } > { Origin-Realm } > { Destination-Realm } > { Service-Type } > { EAP-Payload } > [ Destination-Host ] > [ Authorization-Lifetime ] > [ Session-Timeout ] > [ User-Name ] > [ Idle-Timeout ] > [ NAS-IP-Address ] > [ NAS-Identifier ] > [ State ] > [ Origin-State-Id ] > [ NAS-Key-Binding ] > * [ AVP ] > * [ Proxy-Info ] > * [ Route-Record ] > > >4.2.2 Diameter-EAP-Answer (DEA) Command > > The Diameter-EAP-Answer (DEA) message, indicated by the Command-Code > field set to 268 and the 'R' bit cleared in the Command Flags field, > is sent by the Diameter server to the client for one of the following > reasons: > > 1) The message is part of a multi-round authentication exchange, > and the server is expecting a subsequent Diameter-EAP-Request. > This is indicated by setting the Result-Code to > DIAMETER_MULTI_ROUND_AUTH, and MAY include zero or more State > AVPs. > 2) the EAP client has been successfully authenticated and > authorized, in which case the message MUST include the Result- > Code AVP indicating success, and SHOULD include an EAP-Payload > of type EAP-Success. This event MUST cause the access device > to provide service to the EAP client. > 3) The EAP client has not been successfully authenticated and/or > authorized, and the Result-Code AVP is set to indicate failure. > This message MAY include an EAP-Payload, but this AVP is not > used to determine whether service is to be provided. > > If the message from the Diameter client included a request for > authorization, a successful response MUST include the authorization > AVPs that are relevant to the service being provided. > > Message Format > > ::= < Diameter Header: 268, PXY > > < Session-Id > > { Auth-Application-Id } > { Result-Code } > { Origin-Host } > { Origin-Realm } > { Destination-Host } > { Service-Type } > [ Error-Reporting-Host ] > [ EAP-Payload ] > [ User-Name ] > [ Idle-Timeout ] > [ Authorization-Lifetime ] > [ Session-Timeout ] > [ Origin-State-Id ] > * [ NAS-Session-Key ] > * [ AVP ] > * [ Proxy-Info ] > * [ Route-Record ] > > >4.3 EAP-Payload AVP > > The EAP-Payload AVP (AVP Code 402) is of type OctetString and is used > to encapsulate the actual EAP payload [25] that is being exchanged > between the EAP client and the home Diameter server. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Fri Jun 22 12:29:42 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29383 for ; Fri, 22 Jun 2001 12:29:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AED059127A; Fri, 22 Jun 2001 12:22:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7C89C9127C; Fri, 22 Jun 2001 12:22:03 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 51F459127A for ; Fri, 22 Jun 2001 12:22:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9750C5DDD5; Fri, 22 Jun 2001 12:22:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id C5A8E5DDC7 for ; Fri, 22 Jun 2001 12:22:55 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f5MGMGN11001 for ; Fri, 22 Jun 2001 18:22:16 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Fri Jun 22 18:22:15 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Jun 2001 18:22:14 +0200 Message-ID: <577066326047D41180AC00508B955DDA04D1A9C4@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'aaa-wg@merit.edu'" , "'pcalhoun@diameter.org'" Cc: "Martin Julien (ECE)" Subject: [AAA-WG]: Comments on draft-mobileip-06 Date: Fri, 22 Jun 2001 18:22:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Pat, I have a few comments on the Mobile IPv4 Application draft-06. If you believe that some of those worth an official issue, then let me know. I must say that it is definitely the best MIP-app draft I've seen so far, and I'm quite happy about it. Thanks! 1) Section 1.2, on top of page 7, I was wondering if it would be better to use the DIAMETER_ERROR_AUTH_FAILURE defined in the MIP draft, or to re-use the one already defined in the Base draft? The one in the Base could possibly be more generic, what do you think? 2) Section 2.1, I guess we could mention that the MN-AAA Authentication Extension information is carried by the (MIP-MN-AAA-Auth AVP), and that the Foreign Agent Challenge Extension information by the (MIP-FA-Challenge AVP). 3) Section 2.1, I don't think the paragraph starting with "If the MIP-Previous-FA-Host AVP...." is still applicable in this draft. Can that AVP be useful at all in the current solution proposed in the draft? At least, I don't see how we could make use of that MIP-Previous-FA-Host AVP in the AAAH and the AAAF. Is it for future considerations? Furthermore, I thought we had agreed that the User-Name was not enough for the purpose of retrieving keys in the AAAF, but would rather require the User-Name, the Home-Address and the Home-Agent? 4) Section 2.1, in the message format, I am questionning the necessity of the MIP-Previous-FA-Host and MIP-Previous-FA-Addr AVPs. 5) Section 2.2, the command-code should be 260, instead of 261. 6) Section 2.2, in the message format, should the MIP-HA-to-FA-Key AVP be included as [], in the case where the the Multi-Round-Auth is used? 7) Section 2.3, could we add the [MIP-Feature-Vector] as a possible AVP of the HAR message, since I see it very useful in the case where the AAAF needs to allocate an Home Agent in the foreign domain? 8) Section 2.4, I don't think it is very clean, with regards to the specification, to expect that the HA will be responsible of forwarding the Session-Timeout, the Authorization-Lifetime, the MIP-FA-to-MN-Key and the MIP-FA-to-HA-Key AVPs in the HAA. When I see those attributes in the HAA, I always have to remind me that they are meaningless to the HAA, but only meaningful to make easier the conversion of the HAA into a AMA in the AAAH, which I consider not very useful anyway, since the AAAH still needs to check that they have been included properly. Well, my opinion is that we should remove them from there, since they are meaningless to the AAAH that receives the HAA. Also, note that the Session-Timeout AVP is {} in the HAA, but [] in the HAR, which seems inconsistent. What the HA is supposed to put in there if not received in the HAR? 9) Section 2.4, the Filter-Rule and the MIP-Foreign-Agent-Host AVPs should be removed from the message format. They are not useful at all. Maybe they could be in the message as *[AVP], which would mean that their presence is not a problem, but not useful neither. 10) Section 3.1, can the HA return the DIAMETER_ERROR_HA_NOT_AVAILABLE when the can not provide the HA service? In that case, the AAAH, or the AAAF, would be responsible for allocating an other HA, if it had allocated it previously. That is the only reason why I would see the DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE useful, since the AAAH changes the DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE into a DIAMETER_ERROR_HA_NOT_AVAILABLE when answering to the FA, as described in page 12. 11) If there is a problem in the HA or FA with the SPI generated by the AAAH or AAAF, how could that be reported? 12) Section 4.0, the Filter-Rule AVP should be referenced to section 4.11 instead of 4.10. It should also be of type UTF8String, instead of OctetString. The thing is that there are 2 sections 4.10, which should be corrected. Also, the MIP-Foreign-Agent-Host and MIP-Previous-FA-Host AVPs should be of type DiameterIdentity, instead of OctetString. 13) Section 4.7, the last paragraph, we should read "Only the AAAF may set the Foreign-Home-Agent-Available and Home-Agent-In-Foreign-Network flags to one." 14) Section 5.1, 4th par. last word, should be HAA instead of AMA. 15) Section 6.0, the MIP-Algorithm-Type and MIP-Replay-Mode AVPs should be of type Enumeratedm instead of Unsigned32. 16) Whenever no MIP-*-Preferred-SPI AVP is included in the AMR, can we assume that the SPI generated by the AAAH or AAAF can be completely random or not? Why can't the HA decide the SPI itself? Also, when a MIP-*-Preferred-SPI AVP is included in the AMR, I guess that the FA has chosen a value that what not already already by any of the SAs, right? The thing is that it might not know the HA yet, i.e. the SA. And as another mail in the ML, I've always been wondering if ever the preferred-HA-MN-SPI would be useful or not? From our last discussions on the subject, I thought it would be added, but it wasn't so clear. 17) Section 10.4 is no longer needed and should be completely deleted. 18) Section 6.2.7, should the SHA-1 algorithm be also added, as in the aaa-key-06 draft? BTW, would it be better that the values assigned to those algorithms match between the 2 drafts? The last comment also applies to the Replay-Mode. 19) Section 6.1, could you please explain to me what "The Mobile IP key described in [15] refers to the AAA SPI, which MUST be set to the value the AAAH shares with the Mobile Node." Are we talking about a pre-configured shared SPI, or a secret key? Can it dynamically change or not? It is not clear to me how the AAA SPI can help in creating the FA or HA Security Information. Could you please tell me more? Best Regards, Martin From owner-aaa-wg@merit.edu Fri Jun 22 13:44:51 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01740 for ; Fri, 22 Jun 2001 13:44:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9A6829127C; Fri, 22 Jun 2001 13:08:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 640DE9127D; Fri, 22 Jun 2001 13:08:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 57E829127C for ; Fri, 22 Jun 2001 13:08:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ABCC85DD96; Fri, 22 Jun 2001 13:09:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by segue.merit.edu (Postfix) with ESMTP id 6634E5DD8D for ; Fri, 22 Jun 2001 13:09:47 -0400 (EDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel1.hp.com (Postfix) with ESMTP id 8AA2611D3; Fri, 22 Jun 2001 10:09:26 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id KAA06090; Fri, 22 Jun 2001 10:11:01 -0700 (PDT) Date: Fri, 22 Jun 2001 10:11:01 -0700 (PDT) From: Joe Lau Message-Id: <200106221711.KAA06090@strtio1.cup.hp.com> To: Martin.Julien@ece.ericsson.se Subject: Re: [AAA-WG]: Comments on draft-mobileip-06 Cc: aaa-wg@merit.edu, pcalhoun@diameter.org Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, > I have a few comments on the Mobile IPv4 Application draft-06. Can someone tell me what is the difference between these two drafts: - titled "Diameter Mobile IPv4 Application" (this is not on the AAA WG) and - titled "Diameter Mobile IPv4 Extensions" (this is on the AAA WG) I am a bit confused. I know I am behind on reading the AAA mails. Thanks. Joe From owner-aaa-wg@merit.edu Fri Jun 22 14:29:55 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03498 for ; Fri, 22 Jun 2001 14:29:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3F1F69127F; Fri, 22 Jun 2001 14:16:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0CE3F91280; Fri, 22 Jun 2001 14:16:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B1DC89127F for ; Fri, 22 Jun 2001 14:16:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1EEAD5DD9F; Fri, 22 Jun 2001 14:17:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 208065DD92 for ; Fri, 22 Jun 2001 14:17:37 -0400 (EDT) Received: (qmail 23371 invoked by uid 500); 22 Jun 2001 18:05:53 -0000 Date: Fri, 22 Jun 2001 11:05:53 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 83: Routing/forwarding clarifications Message-ID: <20010622110552.R14828@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, This is a much bigger issue than it seems. During yesterday's conference call, we agreed with the items listed in this issue, but these raised another sub-issue, which is that an explicit disconnect message is necessary between peers. The reason being that if a node disconnects the transport connection for a valid reason (e.g. insufficient resources), the last thing it needs is the peer periodically attempting to re-connect. The way that the draft is written, with the resilience and failover text, this is precisely what a node is to do when a disconnect occurs. The issue listed the following, and my comments are included: > - If multiple hosts listed for a given realm (redirect, relay, proxy), use > the same one for a given Session (either need to maintain Session state or > to use some hash function based on Session-ID) unless error occurs (and > then keep that one that works). This issue is handled in the transport draft, and does not really need to be rehashed in the base spec. > - Clarify if connections to peers are supposed to be opened at startup, or > when needed only. a new section was created to discuss this issue. > - Clarify relationship of server discovery (SLP, DNS A, DNS SRV...) with > peer table and/or routing table. new text was added to the server discovery section. > - move peer and routing table description earlier in the doc (somewhere in > 2.5 or 2.6). we agreed with this. > - Clarify whether "on-demand" connections (e.g. Redirect-Host with > certificate) should timeout. this one is already taken care of in -06 > - refuse connection to oneself the group felt that this was an implementation issue, and must not be ruled out. Given the above changes, and the inclusion of the disconnect message, a rather minor re-org of the document was necessary. In addition to moving some sections around, I felt that the old sections 7 and 8 really had to do with dealing with Diameter peers, and all peer related topics should be in a single section, which is now section 6. I think this makes a whole lot of sense. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Here is the new table of contents (not shown here, but section 4 in the table of contents was not aligned properly and has been fixed): [...] 2.0 Protocol Overview 2.1 Transport 2.1.1 SCTP Guidelines 2.2 Securing Diameter Messages 2.3 Diameter Protocol Extensibility 2.3.1 Defining new AVP Values 2.3.2 Creating new AVPs 2.3.3 Creating a new Diameter Applications 2.3.4 Application authentication procedures 2.4 Diameter Application Compliance 2.5 Application Identifiers 2.6 Peer Table 2.7 Realm-Based Routing Table 2.8 Role of Diameter Agents 2.8.1 Relay Agents 2.8.2 Proxy Agents 2.8.3 Redirector Agents 2.8.4 Translation Agents [...] 5.0 Diameter message processing 5.1 Diameter request routing overview 5.1.1 Originating a Request 5.1.2 Sending a Request 5.1.3 Processing Local Requests 5.1.4 Request Forwarding 5.1.6 Request Routing 5.1.8 Redirecting requests 5.1.9 Relaying and Proxying Requests 5.2 Diameter Answer Processing 5.2.1 Processing received Answers 5.2.2 Relaying and Proxying Answers 5.3 Hiding Network Topology 5.4 Origin-Host AVP 5.5 Origin-Realm AVP 5.6 Destination-Host AVP 5.7 Destination-Realm AVP 5.8 Routing AVPs 5.8.1 Route-Record AVP 5.8.2 Proxy-Info AVP 5.8.3 Proxy-Host AVP 5.8.4 Proxy-State AVP 5.9 Auth-Application-Id AVP 5.10 Acct-Application-Id AVP 5.11 Vendor-Specific-Application-Id AVP 5.12 Redirect-Host AVP 5.13 Redirect-Host-Usage AVP 5.14 Redirect-Max-Cache-Time AVP 6.0 Diameter Peers 6.1 Connecting to Peers 6.2 Diameter Peer Discovery 6.3 Capabilities Negotiation 6.3.1 Capabilities-Exchange-Request 6.3.2 Capabilities-Exchange-Answer 6.3.3 Vendor-Id AVP 6.3.4 Firmware-Revision AVP 6.3.5 Host-IP-Address AVP 6.3.6 Supported-Vendor-Id AVP 6.3.7 Product-Name AVP 6.4 Disconnecting Peer connections 6.4.1 Disconnect-Peer-Request 6.4.2 Disconnect-Peer-Answer 6.4.3 Disconnect-Cause AVP 6.5 Transport Failure Detection 6.5.1 Device-Watchdog-Request 6.5.2 Device-Watchdog-Answer 6.5.3 Failover/Failback Procedures 6.6 Peer State Machine 6.6.1 Incoming connections 6.6.2 Events 6.6.3 Actions 6.6.4 The Election Process [...] ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I moved the peer and routing table up into section 2, as requested by this issue. Furthermore, the addition of some text in the section that discusses dynamic peer discovery (section 6.2) required the addition of new fields in the tables. Here is the next text: 2.6 Peer Table The Diameter Peer Table is used in message forwarding, and referenced by the Domain Routing Table. A Peer Table entry contains the following fields: [...] - Status. This is the state of the peer entry, and MUST match one of the values listed in section 6.6. - Role. This field specifies whether a peer is a primary, secondary or alternate. - Static or Dynamic. Specifies whether a peer entry was statically configured, or dynamically discovered. - Expiration time. Specifies the time which dynamically discovered peer table entries are to be either refreshed, or expired. [...] 2.7 Realm-Based Routing Table All Realm-Based routing lookups are performed against what is commonly known as the Domain Routing Table (see section 16.0). A Domain Routing Table Entry contains the following fields: [...] - Static or Dynamic. Specifies whether a route entry was statically configured, or dynamically discovered. - Expiration time. Specifies the time which dynamically discovered a route table entry expire. [...] ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Finally, there have been changes to section 6, which I list here. However, I do want to bring up the fact that there is one open issue. The state machine doesn't have a state for "suspect" peers, so the table in 6.1 shows "????" as the state. I believe that we need to have a state in the state machine for suspect peers. Paul, any ideas? 6.0 Diameter Peers This section describes how a Diameter nodes establish connections and communicate with peers. 6.1 Peer Connections Although a Diameter node may have many possible peers that it is able to communicate with, it may not be economical to have an established connection to all of them. At a minimum, a Diameter node SHOULD have an established connection with a primary and secondary peer, and MAY have additional connections, if it is deemed necessary. However, when a connection with either the primary or secondary peer becomes questionable, a connection to an alternate peer SHOULD be established. The questionable peer should then be removed from the primary/secondary list, and the new peer should be added to the list (see figure 6). +------------------------------+ +------------------------------+ | Peer | Status | Role | | Peer | Status | Role | +--------+---------+-----------+ +--------+---------+-----------+ | peer A | Open | Primary | | peer B | Open | Primary | | peer B | Open | secondary | | peer C | Open | secondary | | peer C | Closed | alternate | | peer A | ???? | alternate | +------------------------------+ +------------------------------+ A. prior to failure B. following failure +------------------------------+ +------------------------------+ | Peer | Status | Role | | Peer | Status | Role | +--------+---------+-----------+ +--------+---------+-----------+ | peer B | Open | Primary | | peer B | Open | Primary | | peer C | Open | secondary | | peer C | Open | secondary | | peer A | Open | alternate | | peer A | Closed | alternate | +------------------------------+ +------------------------------+ C1. Connection has stabilized C2. Connection was terminated Figure 6: Transitions of a Peer Table Figure 6 shows the sequence of changes made to a peer table following a network failure, causing the connection to peer A to become questionable. The following is a description of the steps. A. Peers A and B are the current primary and secondary, respectively. peer C is an alternate server, and no transport connection is established with it. B. The connection to peer A becomes questionable, causing a connection to be established with peer C. Peer B is moved to primary, peer C to secondary and peer A as an alternate. if the connection to A stabilizes, the next event is C1, otherwise C2. C1. Three successful watchdog messages have been exchanged with peer A, and the connection is considered stabilized. The connection remains open, but the peer is still considered as an alternate. C2. The connection with peer A was shutdown, and peer A's state is changed to disconnected. 6.2 Diameter Peer Discovery [...] A dynamically discovered peer causes an entry in the Peer Table (see section 2.6) to be created. Note that entries created via DNS MUST expire (or be refreshed) within the DNS TTL. If a peer is discovered outside of the local realm, a routing table entry (see Section 2.7) for the peer's realm is created. The routing table entry's expiration MUST match the peer's expiration value. 6.3 Capabilities Exchange [...] 6.4 Disconnecting Peer connections When a Diameter node disconnects one its transport connections, its peer cannot know the reason for the disconnect, and will most likely assume that a connectivity problem occured, or that the peer has rebooted. In these cases, the peer may periodically attempt to reconnect, as stated in section 2.1. In the event that the disconnect was a result of either a shortage of internal resources, or simply that the node in question has no intentions of forwarding any Diameter messages to the peer in the foreseeable future, a periodic connection request would not be welcomed. The Disconnection-Reason AVP contains the reason the Diameter node issued the Disconnect- Peer-Request message. The Disconnect-Peer-Request message is used by a Diameter node to inform its peer of its intent to disconnect the transport layer, and that the peer shouldn't reconnect unless it has a valid reason to do so (e.g. message to be forwarded). Upon receipt of the message, the Disconnect-Peer-Answer is returned, which SHOULD contain an error if messages have recently be forwarded, and are likely in flight, which would otherwise cause a race condition. The receiver of the Disconnect-Peer-Answer initiates the transport disconnect. 6.4.1 Disconnect-Peer-Request The Disconnect-Peer-Request (DPR), indicated by the Command-Code set to 282 and the Command Flags' 'R' bit set, is sent to a peer to inform its intentions to shutdown the transport connection. Message Format ::= < Diameter Header: 282, REQ > { Origin-Host } { Origin-Realm } { Destination-Host } { Disconnect-Cause } 6.4.2 Disconnect-Peer-Answer The Disconnect-Peer-Answer (DPA), indicated by the Command-Code set to 282 and the Command Flags' 'R' bit cleared, is sent as a response to the Disconnect-Peer-Request message. Upon receipt of this message, the transport connection is shutdown. Message Format ::= < Diameter Header: 282 > { Result-Code } { Origin-Host } { Origin-Realm } { Destination-Host } 6.4.3 Disconnect-Cause AVP The Disconnect-Cause AVP (AVP Code 273) is of type Enumerated. A Diameter node MUST include this AVP in the Disconnect-Peer-Request message to inform the peer of the reason for its intention to shutdown the transport connection. The following values are supported: REBOOTING 0 A scheduled reboot is imminent. BUSY 1 The peer's internal resources are constrained, and it has determined that the transport connection needs to be shutdown. DO_NOT_WANT_TO_TALK_TO_YOU 2 The peer has determined that it does not see a need for the transport connection to exist, since it does not expect any messages to be exchanged in the foreseeable future. [...] From owner-aaa-wg@merit.edu Fri Jun 22 14:37:34 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03914 for ; Fri, 22 Jun 2001 14:37:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8F4059127E; Fri, 22 Jun 2001 14:37:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5D05091280; Fri, 22 Jun 2001 14:37:29 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3E90D9127E for ; Fri, 22 Jun 2001 14:37:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BFEF05DDA4; Fri, 22 Jun 2001 14:38:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 3F90B5DD9F for ; Fri, 22 Jun 2001 14:38:22 -0400 (EDT) Received: (qmail 23396 invoked by uid 500); 22 Jun 2001 18:26:38 -0000 Date: Fri, 22 Jun 2001 11:26:38 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 81: Route-Record change Message-ID: <20010622112638.S14828@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Jacques, I have been trying to address this issue, and I cannot for the life of me, figure out how this is to be done. Your issue states that this removes checking for loops when a packet is received, but I believe that this is incorrect. I agree that including the peer's identity instead of your own could be valuable, and this is done upon receipt as opposed to prior to forwarding a message. However, loop checks much still be done, and it is better for the check to be done when it is received, as opposed to prior to sending (I think). Here's what I came up with, but it doesn't match your description of what needs to be changed: 5.1.3 Receiving Requests A relay or proxy agent MUST check for forwarding loops when receiving requests. A loop is detected if the server finds its own identity in a Route-Record AVP. When such an event occurs, the agent MUST answer with the Result-Code AVP set to DIAMETER_LOOP_DETECTED. [...] 5.1.10 Relaying and Proxying Requests A relay or proxy agent MUST append a Route-Record AVP to all requests forwarded. The AVP contains the identity of the peer the request was received from. From owner-aaa-wg@merit.edu Fri Jun 22 14:46:56 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04315 for ; Fri, 22 Jun 2001 14:46:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C45B591280; Fri, 22 Jun 2001 14:46:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 89D3191281; Fri, 22 Jun 2001 14:46:40 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5F60991280 for ; Fri, 22 Jun 2001 14:46:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CFC2F5DD9F; Fri, 22 Jun 2001 14:47:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id D812F5DD92 for ; Fri, 22 Jun 2001 14:47:32 -0400 (EDT) Received: (qmail 23430 invoked by uid 500); 22 Jun 2001 18:35:48 -0000 Date: Fri, 22 Jun 2001 11:35:48 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 79: Error Handling Editorial Changes Message-ID: <20010622113548.T14828@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <20010621170141.L14828@charizard.diameter.org> <4.3.2.7.2.20010622103947.00c721d0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010622103947.00c721d0@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Fri, Jun 22, 2001 at 11:23:07AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Fri, Jun 22, 2001 at 11:23:07AM +0200, Jacques Caron wrote: > Hi, > > I still think this is redundant with the 'P' bit. A message with 'R' clear > and 'P' clear is a non-proxiable answer, and thus something for local > processing. Then the combination of Command-Code and Result-Code will tell > the proxy/relay whether it's a CEA or a protocol error. 'P' and 'E' are different. A message with the 'E' bit set is still proxiable, but the 'E' bit is an alert to agents that they should attempt to take local action. However, if they cannot, they must proxy the answer. > > Also, I think it would be wise to specify which combinations of the flag > bits are allowed, and what to do if an unallowed combination is received. The text already does state this. The only rule is that the 'R' and the 'E' bits cannot be set at the same time. See the text in 'E'. So, if I understand your second comment, a new result code needs to be created that states that conflicting bits are set in the header? > > As an aside, I would like just for the record [I'm afraid many might feel > it's too late to make such radical changes :-(] to state that my favorite > option would be to separate a lot more explicitly the "protocol" part from > the "application" part (a bit like HTTP vs HTML or SMTP vs RFC822 e-mail, > etc). I think we are still way too close to the Radius model where we just > exchange messages on a link, and some happen to be local protocol things > and others are end-to-end application things. This is not really good for > the robustness and clarity of the protocol. hmmmm.... why does it feel like we are flip-flopping :( your comment has been noted.... moving on... > > This would apply to command-codes (e.g. CER, CEA, DWR, DWA vs AAA, AAR, > etc.), error-codes, and AVPs (some AVPs are used for routing purposes, such > as Destination-Host, Destination-Realm, Route-Record..., and are comparable > to HTTP headers, while others are purely applicative, such as > Framed-IP-Address, User-Name or EAP-Message, and closer to HTML tags). > > This would probably simplify a lot the ABNF, as all "Application" commands > would not be encumbered with all the "protocol" AVPs, too. it certainly is possible to create new avps that do exactly the same thing as those defined in the base, but I fail to see the logic in duplicate functionality. > > Note that though the changes are radical, it might not require to change > that much text, so it could still be done pretty quickly. Let me know if > anyone wants to pursue this [for some reason I doubt it :-(]. i doubt it, and would need additional clarifying information, like what exactly are we talking about here. PatC > > Jacques. > > At 02:01 22/06/01, Pat Calhoun wrote: > >All, > > > >during the call today, we agreed with Issue 79, that it wasn't necessary for > >a new command code (Message-Reject-Answer) to be used when a protocol error > >occurs. However, some folks wanted a simpler way to identify that a relay > >needs to process the message other than parsing through it looking for the > >Result-Code AVP. So, we decided that introducing the 'E' (error) bit in the > >header was a very fast and easy way for relays to identify that local > >processing > >of a message is necessary. > > > >Here is a portion of my proposed text (most of the changes is to replace the > >term Message-Reject-Answer with something that states that an answer is > >returned > >with the 'E' bit set). > > > >Comments appreciated, > > > >PatC > >---- > > > >3.0 Diameter Header > > > > A summary of the Diameter header format is shown below. The fields > > are transmitted in network byte order. > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Ver | Message Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |R P E r r r r r| Command-Code | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Vendor-ID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Hop-by-Hop Identifier | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | End-to-End Identifier | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | AVPs ... > > +-+-+-+-+-+-+-+-+-+-+-+-+- > > > >[...] > > Command Flags > > The Command Flags field is eight bits. The following bits are > > assigned: > > > > R(equest) - If set, the message is a request. If cleared, the > > message is an answer. > > P(roxiable) - If set, the message MAY be proxied. If cleared, > > the message MUST be locally processed. > > E(rror) - If set, the message contains a protocol error, > > and the message will not conform to the ABNF > > described for this command. This bit MUST NOT be > > set in request messages. See section x.x. > > r(eserved) - this flag bit is reserved for future use, and > > MUST be set to zero. > > > >[...] > >3.2 Command Code ABNF specification > > > >[...] > > header = "< Diameter-Header:" command-id [r-bit] > > [p-bit] [e-bit] ">" > >[...] > > e-bit = ", ERR" > > ; If present, the 'E' bit in the Command > > ; Flags is set, indication that the answer > > ; message contains a Result-Code AVP in > > ; the "protocol error" class. > >[...] > > > >9.2 Error Bit > > > > The 'E' (Error Bit) in the Diameter header is set when the request > > caused a protocol-related error (see section 9.1.3). When set, the > > answer message will not conform to the ABNF specification for the > > command, and will instead conform to the following ABNF: > > > > Message Format > > > > ::= < Diameter Header: code, ERR > > > < Session-Id > > > { Origin-Host } > > { Origin-Realm } > > { Result-Code } > > { Destination-Host } > > [ Origin-State-Id ] > > [ Error-Reporting-Host ] > > * [ AVP ] > > > > Note that the code used in the header is the same that the one found > > in the request message, but with the 'R' bit cleared and the 'E' bit > > set. > > > > > >Thanks, > > > >PatC > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > From owner-aaa-wg@merit.edu Fri Jun 22 15:01:14 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04934 for ; Fri, 22 Jun 2001 15:01:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A1ABB91281; Fri, 22 Jun 2001 15:00:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7768B91282; Fri, 22 Jun 2001 15:00:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5B2B491281 for ; Fri, 22 Jun 2001 15:00:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CF96A5DDA4; Fri, 22 Jun 2001 15:01:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 771E05DD92 for ; Fri, 22 Jun 2001 15:01:12 -0400 (EDT) Received: (qmail 23920 invoked by uid 500); 22 Jun 2001 18:49:27 -0000 Date: Fri, 22 Jun 2001 11:49:27 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 88: Proposed Text for EAP Support Issues Message-ID: <20010622114927.U14828@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <20010619105205.M17928@charizard.diameter.org> <4.3.2.7.2.20010619210420.00c19180@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010619210420.00c19180@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Fri, Jun 22, 2001 at 11:23:56AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Fri, Jun 22, 2001 at 11:23:56AM +0200, Jacques Caron wrote: > I hadn't noticed that EAP actually used different command-codes from > regular AAA/AAR. In that case, maybe it should be an altogether different > application? Although I do agree, the only issue I have is that both auth schemes end up using the same authorization avps, so there'd be a whole lot of duplication :( > > Another thing that came to mind while I was reading the Diameter Mobile IP > draft this week-end, is there any (existent/planned) interaction between > Mobile IP and EAP? no. PatC > > Jacques. > > At 19:52 19/06/01, Pat Calhoun wrote: > >All, > > > >I hadn't really noticed how bad this section needed some rev'ing up :( > >I believe that I have address all of the concerns in this issue in > >the following text: > > > >4.0 Extensible Authentication Protocol Support > > > > The Extensible Authentication Protocol (EAP), described in [25], > > provides a standard mechanism for support of extensible > > authentication methods. Through the use of EAP, support for a number > > of authentication schemes may be added, including smart and token > > cards, Kerberos, Public Key, One Time Passwords, and others. > > > > This section describes the Command-Codes values and AVPs that are > > required for an EAP payload to be encapsulated within the Diameter > > protocol. Since authentication occurs between the EAP client and its > > home Diameter server, end-to-end authentication is achieved, reducing > > the possibility for fraudulent authentication, such as replay and > > man-in-the-middle attacks. End-to-end authentication also provides > > for mutual (bi-directional) authentication, which is not possible > > with PAP and CHAP in a roaming PPP environment. > > > > The EAP conversation between the authenticating peer and the access > > device begins with the negotiation of EAP within a link layer, such > > as PPP or 802.1x. Once EAP has been negotiated, the access device > > will typically send to the Diameter server a Diameter-EAP-Request > > message with a NULL EAP-Payload AVP, signifying an EAP-Start. The > > Port number and the identity of the access device (e.g. Origin-Host > > or NAS-Identifier) MUST be included in the Diameter-EAP-Request > > message. > > > > If the Diameter home server supports EAP, it MUST respond with a > > Diameter-EAP-Answer message containing an EAP-Payload AVP that > > includes an encapsulated EAP payload [25], and the Result-Code AVP > > set to DIAMETER_MULTI_ROUND_AUTH, signifying that a subsequent > > request is expected. The EAP payload is forwarded by the access > > device to the EAP client. > > > > The initial Diameter-EAP-Answer in a multi-round exchange normally > > includes an EAP-Request/Identity, requesting the EAP client to > > identify itself. Upon receipt of the EAP client's EAP-Response [25], > > the access device will then issue a second Diameter-EAP-Request > > message, with the client's EAP payload encapsulated within the EAP- > > Payload AVP. > > > > A preferred approach is for the access device to issue the EAP- > > Request/Identity message to the EAP client, and forward the EAP- > > Response/Identity packet, encapsulated within the EAP-Payload AVP, as > > a Diameter-EAP-Request to the Diameter server. This alternative > > reduces the number of Diameter message round trips, and is compatible > > with roaming environments, since the Destination-Realm is needed by > > Diameter agents for routing purposes. Note that this alternative > > cannot be universally employed, as there are circumstances where a > > user's identity is not needed (such as when authorization occurs > > based on a calling or called phone number). > > > > The conversation continues until the Diameter server sends a > > Diameter-EAP-Answer with a Result-Code AVP indicating success or > > failure, and an optional EAP-Payload. The Result-Code AVP is used by > > the access device to determine whether service is to be provided to > > the EAP client. The access device MUST NOT rely on the contents of > > the optional EAP-Payload to determine whether service is to be > > provided. > > > > A Diameter-EAP-Answer message containing an EAP-Payload of type EAP- > > Success or EAP-Failure MUST NOT have the Result-Code AVP set to > > DIAMETER_MULTI_ROUND_AUTH. > > > > If authorization was requested, a successful Diameter-EAP-Answer MUST > > also include the appropriate authorization AVPs required for the > > service requested (see sections 2.0, 6.0 and 7.0). > > > > Unless the access device interprets the EAP-Response/Identity packet > > returned by the authenticating peer, it will not have access to the > > user's identity. Therefore, the Diameter Server SHOULD return the > > user's identity by inserting it in the User-Name attribute of > > subsequent Diameter-EAP-Answer packets. Without the user's identity, > > the Session-Id AVP MAY be used for accounting and billing, however > > operationally this MAY be very difficult to manage. > > > > A home Diameter server MAY request EAP re-authentication by issuing > > the Re-Auth-Request [2] message to the Diameter client. > > > > Should an EAP authentication session be interrupted due to a home > > server failure, the session MAY be directed to an alternate server, > > but the authentication session will have to be restarted from the > > beginning. > > > > If a response is received with the Result-Code set to > > DIAMETER_COMMAND_UNSUPPORTED [2], it is an indication that the > > Diameter server in the home domain does not support EAP. If possible, > > the access device MAY attempt to negotiate another authentication > > protocol, such as PAP or CHAP. An access device SHOULD be cautious > > when determining whether a less secure authentication protocol will > > be used, since this could be a result of a bidding down attack. > > > > > >[...] > > > >4.2.1 Diameter-EAP-Request (DER) Command > > > > The Diameter-EAP-Request (DER) command, indicated by the Command-Code > > field set to 268 and the 'R' bit set in the Command Flags field, is > > sent by a Diameter client to a Diameter server and conveys an EAP- > > Response [25] from the EAP client. The Diameter-EAP-Request MUST > > contain one EAP-Payload AVP, which contains the actual EAP payload. > > An EAP-Payload AVP with no data MAY be sent to the Diameter server to > > initiate an EAP authentication session. > > > > The DER message MAY be the result of a multi-round authentication > > exchange, which occurs when the DEA is received with the Result-Code > > AVP set to DIAMETER_MULTI_ROUND_AUTH. A subsequent DER message MUST > > include any State AVPs that were present in the DEA. For re- > > authentication, it is recommended that the Identity request be > > skipped in order to reduce the number of authentication round trips. > > This is only possible when the user's identity is already known by > > the home Diameter server. > > > > > > Message Format > > > > ::= < Diameter Header: 268, REQ, PXY > > > < Session-Id > > > { Auth-Application-Id } > > { Origin-Host } > > { Origin-Realm } > > { Destination-Realm } > > { Service-Type } > > { EAP-Payload } > > [ Destination-Host ] > > [ Authorization-Lifetime ] > > [ Session-Timeout ] > > [ User-Name ] > > [ Idle-Timeout ] > > [ NAS-IP-Address ] > > [ NAS-Identifier ] > > [ State ] > > [ Origin-State-Id ] > > [ NAS-Key-Binding ] > > * [ AVP ] > > * [ Proxy-Info ] > > * [ Route-Record ] > > > > > >4.2.2 Diameter-EAP-Answer (DEA) Command > > > > The Diameter-EAP-Answer (DEA) message, indicated by the Command-Code > > field set to 268 and the 'R' bit cleared in the Command Flags field, > > is sent by the Diameter server to the client for one of the following > > reasons: > > > > 1) The message is part of a multi-round authentication exchange, > > and the server is expecting a subsequent Diameter-EAP-Request. > > This is indicated by setting the Result-Code to > > DIAMETER_MULTI_ROUND_AUTH, and MAY include zero or more State > > AVPs. > > 2) the EAP client has been successfully authenticated and > > authorized, in which case the message MUST include the Result- > > Code AVP indicating success, and SHOULD include an EAP-Payload > > of type EAP-Success. This event MUST cause the access device > > to provide service to the EAP client. > > 3) The EAP client has not been successfully authenticated and/or > > authorized, and the Result-Code AVP is set to indicate failure. > > This message MAY include an EAP-Payload, but this AVP is not > > used to determine whether service is to be provided. > > > > If the message from the Diameter client included a request for > > authorization, a successful response MUST include the authorization > > AVPs that are relevant to the service being provided. > > > > Message Format > > > > ::= < Diameter Header: 268, PXY > > > < Session-Id > > > { Auth-Application-Id } > > { Result-Code } > > { Origin-Host } > > { Origin-Realm } > > { Destination-Host } > > { Service-Type } > > [ Error-Reporting-Host ] > > [ EAP-Payload ] > > [ User-Name ] > > [ Idle-Timeout ] > > [ Authorization-Lifetime ] > > [ Session-Timeout ] > > [ Origin-State-Id ] > > * [ NAS-Session-Key ] > > * [ AVP ] > > * [ Proxy-Info ] > > * [ Route-Record ] > > > > > >4.3 EAP-Payload AVP > > > > The EAP-Payload AVP (AVP Code 402) is of type OctetString and is used > > to encapsulate the actual EAP payload [25] that is being exchanged > > between the EAP client and the home Diameter server. > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > From owner-aaa-wg@merit.edu Fri Jun 22 15:14:38 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05549 for ; Fri, 22 Jun 2001 15:14:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4C49891282; Fri, 22 Jun 2001 15:14:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1BE9691283; Fri, 22 Jun 2001 15:14:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 03B3891282 for ; Fri, 22 Jun 2001 15:14:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7A6435DD9F; Fri, 22 Jun 2001 15:15:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from tp.databus.com (p101-46.acedsl.com [160.79.101.46]) by segue.merit.edu (Postfix) with ESMTP id 07E365DD92 for ; Fri, 22 Jun 2001 15:15:35 -0400 (EDT) Received: (from barney@localhost) by tp.databus.com (8.11.3/8.11.3) id f5MJEtT23537 for aaa-wg@merit.edu; Fri, 22 Jun 2001 15:14:55 -0400 (EDT) (envelope-from barney) Date: Fri, 22 Jun 2001 15:14:55 -0400 From: Barney Wolff To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 81: Route-Record change Message-ID: <20010622151455.A23431@tp.databus.com> References: <20010622112638.S14828@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010622112638.S14828@charizard.diameter.org>; from pcalhoun@diameter.org on Fri, Jun 22, 2001 at 11:26:38AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Pat, presumably actual loops will be very rare and only persist until a misconfiguration is corrected. Thus it does no harm at all, imho, to defer the check until one is about to forward the request. That way, the check is always done against ones own identity, with no risk of encoding differences leading to false negatives. It really should not take half a page to express the equality-comparison algorithm for Diameter identities, nor should one have to convert every item in the recorded route to canonical form to do the comparison. A server or any entity that is going to answer the request does not need to do the loop check, as there is no risk of the loop's being perpetuated. Barney On Fri, Jun 22, 2001 at 11:26:38AM -0700, Pat Calhoun wrote: > I agree that including the peer's identity instead of your own could be > valuable, and this is done upon receipt as opposed to prior to forwarding > a message. However, loop checks much still be done, and it is better for > the check to be done when it is received, as opposed to prior to sending > (I think). From owner-aaa-wg@merit.edu Fri Jun 22 17:28:07 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11909 for ; Fri, 22 Jun 2001 17:28:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DC2F091298; Fri, 22 Jun 2001 17:28:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A7BE191299; Fri, 22 Jun 2001 17:28:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7D40F91298 for ; Fri, 22 Jun 2001 17:28:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3B8B25DDCA; Fri, 22 Jun 2001 17:28:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id B09EA5DD92 for ; Fri, 22 Jun 2001 17:28:54 -0400 (EDT) Received: (qmail 27020 invoked by uid 500); 22 Jun 2001 21:16:54 -0000 Date: Fri, 22 Jun 2001 14:16:54 -0700 From: Pat Calhoun To: Thomas Panagiotis-PTHOMAS1 Cc: "'Pat Calhoun'" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: MIP-MN-HA-Preferred-SPI in AA-Mobile-Node-Request ? Message-ID: <20010622141654.F14828@charizard.diameter.org> Mail-Followup-To: Thomas Panagiotis-PTHOMAS1 , 'Pat Calhoun' , aaa-wg@merit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from panos.thomas@motorola.com on Thu, Jun 21, 2001 at 04:01:24PM -0500 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, Jun 21, 2001 at 04:01:24PM -0500, Thomas Panagiotis-PTHOMAS1 wrote: > Hi Pat, > > Shouldn't the AA-Mobile-Node-Request in > draft-ietf-aaa-diameter-mobileip-06.txt > also include a MIP-MN-HA-Preferred-SPI AVP, to be sent to AAAH when the > MN-HA > Key Request From AAA subtype is present in the Registration Request? yes, it should, and will in the next revision. PatC From owner-aaa-wg@merit.edu Fri Jun 22 17:55:16 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12686 for ; Fri, 22 Jun 2001 17:55:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 94C0691299; Fri, 22 Jun 2001 17:55:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3DC3F912B2; Fri, 22 Jun 2001 17:55:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DAD1C91299 for ; Fri, 22 Jun 2001 17:55:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 938F75DDCB; Fri, 22 Jun 2001 17:56:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id EC1385DD92 for ; Fri, 22 Jun 2001 17:56:03 -0400 (EDT) Received: (qmail 27537 invoked by uid 500); 22 Jun 2001 21:44:19 -0000 Date: Fri, 22 Jun 2001 14:44:19 -0700 From: Pat Calhoun To: "Martin Julien (ECE)" Cc: "'aaa-wg@merit.edu'" , "'pcalhoun@diameter.org'" Subject: [AAA-WG]: Re: Comments on draft-mobileip-06 Message-ID: <20010622144418.G14828@charizard.diameter.org> Mail-Followup-To: "Martin Julien (ECE)" , "'aaa-wg@merit.edu'" , "'pcalhoun@diameter.org'" References: <577066326047D41180AC00508B955DDA04D1A9C4@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <577066326047D41180AC00508B955DDA04D1A9C4@eestqnt104.es.eu.ericsson.se>; from Martin.Julien@ece.ericsson.se on Fri, Jun 22, 2001 at 06:22:09PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk > I have a few comments on the Mobile IPv4 Application draft-06. > If you believe that some of those worth an official issue, > then let me know. I must say that it is definitely the best MIP-app > draft I've seen so far, and I'm quite happy about it. Thanks! thank you! > > 1) Section 1.2, on top of page 7, I was wondering if it would be better > to use the DIAMETER_ERROR_AUTH_FAILURE defined in the MIP draft, > or to re-use the one already defined in the Base draft? The one in the > Base could possibly be more generic, what do you think? I agree, and an issue should be opened. btw, it would only be necessary to open a single issue emcompassing all of your editorial comments (reduces the work load on both you and me (the web page editor :) > 2) Section 2.1, I guess we could mention that the MN-AAA > Authentication Extension information is carried by the > (MIP-MN-AAA-Auth AVP), and that the Foreign Agent Challenge > Extension information by the (MIP-FA-Challenge AVP). that would be useful. > 3) Section 2.1, I don't think the paragraph starting with > "If the MIP-Previous-FA-Host AVP...." is still applicable > in this draft. Can that AVP be useful at all in the current > solution proposed in the draft? At least, I don't see how > we could make use of that MIP-Previous-FA-Host AVP in the > AAAH and the AAAF. Is it for future considerations? I am not sure. Others? > > Furthermore, I thought we had agreed that the User-Name > was not enough for the purpose of retrieving keys in the AAAF, > but would rather require the User-Name, the Home-Address and > the Home-Agent? That rings a bell. I may have missed that one. > > 4) Section 2.1, in the message format, I am questionning the > necessity of the MIP-Previous-FA-Host and MIP-Previous-FA-Addr AVPs. right, again, not sure. Perhaps this one should actually be a separate issue from the editorial ones. > > 5) Section 2.2, the command-code should be 260, instead of 261. > > 6) Section 2.2, in the message format, should the > MIP-HA-to-FA-Key AVP be included as [], in the case where the > the Multi-Round-Auth is used? hmmmm.... agreed. > > 7) Section 2.3, could we add the [MIP-Feature-Vector] as a possible > AVP of the HAR message, since I see it very useful in the case where > the AAAF needs to allocate an Home Agent in the foreign domain? yes, I agree. > > 8) Section 2.4, I don't think it is very clean, with regards to the > specification, to expect that the HA will be responsible of forwarding the > Session-Timeout, the Authorization-Lifetime, the MIP-FA-to-MN-Key and the > MIP-FA-to-HA-Key AVPs in the HAA. When I see those attributes in the HAA, > I always have to remind me that they are meaningless to the HAA, but only > meaningful to make easier the conversion of the HAA into a AMA in the AAAH, > which I consider not very useful anyway, since the AAAH still needs to check > that they have been included properly. Well, my opinion is that we should > remove them from there, since they are meaningless to the AAAH that receives > the HAA. ok. A few revisions of the base protocol base, less state was required on the AAAH. Nowadays, though, I agree that the AAAH can easily keep this state information (or add it to Proxy-State if it really wants to). > > Also, note that the Session-Timeout AVP is {} in the HAA, but [] in the HAR, > which seems inconsistent. What the HA is supposed to put in there if not > received in the HAR? oops > > 9) Section 2.4, the Filter-Rule and the MIP-Foreign-Agent-Host AVPs should > be removed from the message format. They are not useful at all. Maybe they > could be in the message as *[AVP], which would mean that their presence is > not a problem, but not useful neither. well, we could, but it is sort-of useful to the implementor to know what to expect in a message. I suspect that filters will unfortunately be more frequent than we want to admit :( > > 10) Section 3.1, can the HA return the DIAMETER_ERROR_HA_NOT_AVAILABLE > when the can not provide the HA service? In that case, the AAAH, or > the AAAF, would be responsible for allocating an other HA, if it had > allocated it previously. That is the only reason why I would see the > DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE useful, since the AAAH changes > the DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE into a > DIAMETER_ERROR_HA_NOT_AVAILABLE when answering to the FA, as described > in page 12. I would much prefer that DIAMETER_TOO_BUSY be returned by an HA to state that it cannot handle the request, and an alternative should be assigned. The error in question should only be used when a specific server is requested, and it cannot be assigned. > > 11) If there is a problem in the HA or FA with the SPI generated by > the AAAH or AAAF, how could that be reported? reported by whom? The HA? Or one of the AAA servers? > > 12) Section 4.0, the Filter-Rule AVP should be referenced to section > 4.11 instead of 4.10. It should also be of type UTF8String, instead of > OctetString. The thing is that there are 2 sections 4.10, which should > be corrected. Also, the MIP-Foreign-Agent-Host and MIP-Previous-FA-Host > AVPs should be of type DiameterIdentity, instead of OctetString. right, well Filter-Rule is now a sub-type, so this will change. The references, though, do need to be fixed. > > 13) Section 4.7, the last paragraph, we should read "Only the AAAF may > set the Foreign-Home-Agent-Available and Home-Agent-In-Foreign-Network > flags to one." right. > > 14) Section 5.1, 4th par. last word, should be HAA instead of AMA. correct. > > 15) Section 6.0, the MIP-Algorithm-Type and MIP-Replay-Mode AVPs should be > of type Enumeratedm instead of Unsigned32. correct. > > 16) Whenever no MIP-*-Preferred-SPI AVP is included in the AMR, can we > assume that the SPI generated by the AAAH or AAAF can be completely > random or not? Why can't the HA decide the SPI itself? There's no reason why, really :( > > Also, when a MIP-*-Preferred-SPI AVP is included in the AMR, I guess > that the FA has chosen a value that what not already already by any > of the SAs, right? The thing is that it might not know the HA yet, > i.e. the SA. > > And as another mail in the ML, I've always been wondering if ever the > preferred-HA-MN-SPI would be useful or not? From our last discussions > on the subject, I thought it would be added, but it wasn't so clear. right, and I've agreed with that comment just minutes ago :) > > 17) Section 10.4 is no longer needed and should be completely deleted. correct > > 18) Section 6.2.7, should the SHA-1 algorithm be also added, as in the > aaa-key-06 draft? BTW, would it be better that the values assigned to > those algorithms match between the 2 drafts? The last comment also > applies to the Replay-Mode. yes, but it really don't matter if there isn't a match. If you think it would be useful, include it in your issue. > > 19) Section 6.1, could you please explain to me what "The Mobile IP key > described in [15] refers to the AAA SPI, which MUST be set to the value > the AAAH shares with the Mobile Node." Are we talking about a > pre-configured shared SPI, or a secret key? Can it dynamically change > or not? It is not clear to me how the AAA SPI can help in creating the > FA or HA Security Information. Could you please tell me more? I'd love to explain it, but that would require that I first understand it :( I believe that what I had originally intended to state here is that the values created are used in a particular field of the MIP AAA key in [15]. This needs some major cleaning up. Thanks, PatC From owner-aaa-wg@merit.edu Fri Jun 22 18:08:45 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13112 for ; Fri, 22 Jun 2001 18:08:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EDA40912B2; Fri, 22 Jun 2001 18:08:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B932B912BC; Fri, 22 Jun 2001 18:08:42 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7E786912B2 for ; Fri, 22 Jun 2001 18:08:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3D7F05DDA4; Fri, 22 Jun 2001 18:09:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id A82E25DD92 for ; Fri, 22 Jun 2001 18:09:35 -0400 (EDT) Received: (qmail 27599 invoked by uid 500); 22 Jun 2001 21:57:50 -0000 Date: Fri, 22 Jun 2001 14:57:50 -0700 From: Pat Calhoun To: Joe Lau Cc: Martin.Julien@ece.ericsson.se, aaa-wg@merit.edu, pcalhoun@diameter.org Subject: Re: [AAA-WG]: Comments on draft-mobileip-06 Message-ID: <20010622145750.L14828@charizard.diameter.org> Mail-Followup-To: Joe Lau , Martin.Julien@ece.ericsson.se, aaa-wg@merit.edu, pcalhoun@diameter.org References: <200106221711.KAA06090@strtio1.cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106221711.KAA06090@strtio1.cup.hp.com>; from jlau@cup.hp.com on Fri, Jun 22, 2001 at 10:11:01AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Fri, Jun 22, 2001 at 10:11:01AM -0700, Joe Lau wrote: > Hi, > > > I have a few comments on the Mobile IPv4 Application draft-06. > > Can someone tell me what is the difference between these two drafts: > - > titled "Diameter Mobile IPv4 Application" > (this is not on the AAA WG) > and > - > titled "Diameter Mobile IPv4 Extensions" > (this is on the AAA WG) The version numbers are different (hence -06 is more recent than -04), and we decided that the use of Application is much more appropriate in this particular instance than would extension. So in short, just a new version of the old document. Hope this helps, PatC From owner-aaa-wg@merit.edu Fri Jun 22 18:19:50 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13451 for ; Fri, 22 Jun 2001 18:19:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 450A7912BE; Fri, 22 Jun 2001 18:19:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 08899912CB; Fri, 22 Jun 2001 18:19:31 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 47ABF912BE for ; Fri, 22 Jun 2001 18:19:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0F9A85DD92; Fri, 22 Jun 2001 18:20:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by segue.merit.edu (Postfix) with ESMTP id A2F4C5DDAC for ; Fri, 22 Jun 2001 18:20:21 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id PAA00516 for ; Fri, 22 Jun 2001 15:19:39 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id PAA12461 for ; Fri, 22 Jun 2001 15:19:38 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Jun 2001 17:19:38 -0500 Message-ID: From: Thomas Panagiotis-PTHOMAS1 To: "'Pat Calhoun'" , "Martin Julien (ECE)" Cc: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Re: Comments on draft-mobileip-06 Date: Fri, 22 Jun 2001 17:19:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk >> 3) Section 2.1, I don't think the paragraph starting with >> "If the MIP-Previous-FA-Host AVP...." is still applicable >> in this draft. Can that AVP be useful at all in the current >> solution proposed in the draft? At least, I don't see how >> we could make use of that MIP-Previous-FA-Host AVP in the >> AAAH and the AAAF. Is it for future considerations? > >I am not sure. Others? MIP/Fast interdomain handoffs? -Panos From owner-aaa-wg@merit.edu Sat Jun 23 05:48:31 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08839 for ; Sat, 23 Jun 2001 05:48:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 23F6391205; Sat, 23 Jun 2001 05:48:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D9E1C91206; Sat, 23 Jun 2001 05:48:38 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7029691205 for ; Sat, 23 Jun 2001 05:48:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1EB5D5DE15; Sat, 23 Jun 2001 05:49:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59]) by segue.merit.edu (Postfix) with SMTP id A09EE5DD92 for ; Sat, 23 Jun 2001 05:49:32 -0400 (EDT) Received: from s152.dhcp212-198-137.noos.fr (HELO jc.yahoo.com) (212.198.137.152) by smtp.mail.vip.sc5.yahoo.com with SMTP; 23 Jun 2001 09:48:49 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010623113501.00bea930@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 23 Jun 2001 11:37:54 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 81: Route-Record change Cc: aaa-wg@merit.edu In-Reply-To: <20010622112638.S14828@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 20:26 22/06/01, Pat Calhoun wrote: >Jacques, > >I have been trying to address this issue, and I cannot for the life of >me, figure out how this is to be done. Your issue states that this >removes checking for loops when a packet is received, but I believe >that this is incorrect. Nope, it says it removes the check that the last route-record must contain the same identity as that advertised by the host in a CER/CEA on that connection. Loop checking must still be done at some point. Either you check all the route record against your identity on reception, or you check against the peer you're going to send it to before sending. I think the former is better. >I agree that including the peer's identity instead of your own could be >valuable, and this is done upon receipt as opposed to prior to forwarding >a message. However, loop checks much still be done, and it is better for >the check to be done when it is received, as opposed to prior to sending >(I think). Yep. >Here's what I came up with, but it doesn't match your description of >what needs to be changed: > >5.1.3 Receiving Requests > > A relay or proxy agent MUST check for forwarding loops when receiving > requests. A loop is detected if the server finds its own identity in > a Route-Record AVP. When such an event occurs, the agent MUST answer > with the Result-Code AVP set to DIAMETER_LOOP_DETECTED. > >[...] > >5.1.10 Relaying and Proxying Requests > > A relay or proxy agent MUST append a Route-Record AVP to all requests > forwarded. The AVP contains the identity of the peer the request was > received from. Looks good to me. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Sat Jun 23 06:06:32 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08919 for ; Sat, 23 Jun 2001 06:06:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 499D091206; Sat, 23 Jun 2001 06:06:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1B8BD91208; Sat, 23 Jun 2001 06:06:27 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 93BDE91206 for ; Sat, 23 Jun 2001 06:06:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 42FA05DE15; Sat, 23 Jun 2001 06:07:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) by segue.merit.edu (Postfix) with SMTP id AAA2F5DD92 for ; Sat, 23 Jun 2001 06:07:20 -0400 (EDT) Received: from s152.dhcp212-198-137.noos.fr (HELO jc.yahoo.com) (212.198.137.152) by smtp.mail.vip.sc5.yahoo.com with SMTP; 23 Jun 2001 10:06:37 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010623113817.00c29ba0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 23 Jun 2001 12:01:58 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 79: Error Handling Editorial Changes Cc: Pat Calhoun , aaa-wg@merit.edu In-Reply-To: <20010622113548.T14828@charizard.diameter.org> References: <4.3.2.7.2.20010622103947.00c721d0@pop.mail.yahoo.com> <20010621170141.L14828@charizard.diameter.org> <4.3.2.7.2.20010622103947.00c721d0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 20:35 22/06/01, Pat Calhoun wrote: >On Fri, Jun 22, 2001 at 11:23:07AM +0200, Jacques Caron wrote: > > Hi, > > > > I still think this is redundant with the 'P' bit. A message with 'R' clear > > and 'P' clear is a non-proxiable answer, and thus something for local > > processing. Then the combination of Command-Code and Result-Code will tell > > the proxy/relay whether it's a CEA or a protocol error. > >'P' and 'E' are different. A message with the 'E' bit set is still >proxiable, but the 'E' bit is an alert to agents that they should attempt >to take local action. However, if they cannot, they must proxy the >answer. I think in both cases the messages calls for local action. In some cases, the local action might be to forward it further downstream... > > Also, I think it would be wise to specify which combinations of the flag > > bits are allowed, and what to do if an unallowed combination is received. > >The text already does state this. The only rule is that the 'R' and the 'E' >bits cannot be set at the same time. See the text in 'E'. What about P with the other ones? >So, if I understand your second comment, a new result code needs to be created >that states that conflicting bits are set in the header? Yep. > > This would probably simplify a lot the ABNF, as all "Application" commands > > would not be encumbered with all the "protocol" AVPs, too. > >it certainly is possible to create new avps that do exactly the same thing >as those defined in the base, but I fail to see the logic in duplicate >functionality. No, the idea is to separate them. I.e, no need to put all the "Route-Record", "Destination-Host", "Destination-Realm", "Proxy-State" and any other routing-related stuff in the ANBF for AAA/AAR. So you can change more easily all the routing part without having to touch all possible application commands. It makes it easier also for proxies/relays that have to understand some AVPs (e.g. Session-Timeout) to know which ones they're supposed to know how to handle or not. > > Note that though the changes are radical, it might not require to change > > that much text, so it could still be done pretty quickly. Let me know if > > anyone wants to pursue this [for some reason I doubt it :-(]. > >i doubt it, and would need additional clarifying information, like what >exactly >are we talking about here. Well, it's a matter of separating the Diameter protocol in two layers: one which takes care of communication over a local link, and one which is end-to-end communication. On a local link, one could exchange the following messages: - Capabilities-Advertisement - Device-Watchdog - Termination-Request - Protocol-Error - Application-C2S-Request - Application-S2C-Request - Aplication-Answer [C2S and S2C mean Client-to-Server and Server-to-client, respectively]. Each of those messages would contain AVPs related to their function, in a local context. The two Application-*-Requests would contain Destination-Realm/Host and Route-Record AVPs, and an "Application-Data" grouped AVP that would contain the actual end-to-end command and AVPs. Application-Answer could contain just that AVP. To make extension simpler, the local link command types should have a bit structure that makes it easy for an agent to understand what type of command is which. Note that for requests, I would also include the type of request (auth, accounting...), as proxies that maintain session state need to be able to interpret them. I'm trying to put all that into some clear text, I'll send it as soon as I can. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Sat Jun 23 06:06:52 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08940 for ; Sat, 23 Jun 2001 06:06:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 99515912C3; Sat, 23 Jun 2001 06:06:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 64B38912C4; Sat, 23 Jun 2001 06:06:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DAFD9912C3 for ; Sat, 23 Jun 2001 06:06:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9EF205DE15; Sat, 23 Jun 2001 06:07:37 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) by segue.merit.edu (Postfix) with SMTP id 2722D5DD92 for ; Sat, 23 Jun 2001 06:07:37 -0400 (EDT) Received: from s152.dhcp212-198-137.noos.fr (HELO jc.yahoo.com) (212.198.137.152) by smtp.mail.vip.sc5.yahoo.com with SMTP; 23 Jun 2001 10:06:55 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010623120351.00c0e2f0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 23 Jun 2001 12:05:57 +0200 To: Barney Wolff From: Jacques Caron Subject: Re: [AAA-WG]: Issue 81: Route-Record change Cc: aaa-wg@merit.edu In-Reply-To: <20010622151455.A23431@tp.databus.com> References: <20010622112638.S14828@charizard.diameter.org> <20010622112638.S14828@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 21:14 22/06/01, Barney Wolff wrote: >Pat, presumably actual loops will be very rare and only persist until >a misconfiguration is corrected. Thus it does no harm at all, imho, >to defer the check until one is about to forward the request. That >way, the check is always done against ones own identity, with no >risk of encoding differences leading to false negatives. It really >should not take half a page to express the equality-comparison >algorithm for Diameter identities, nor should one have to convert >every item in the recorded route to canonical form to do the comparison. Again, I think it should be stated that any DiameterIdentities used in all the loop-checking activities MUST be the value advertised in Origin-Host in CER/CEA, and should be treated as an opaque string. Then pure string matching (strcmp) would be enough. >A server or any entity that is going to answer the request does not >need to do the loop check, as there is no risk of the loop's being >perpetuated. There are issues with redirects, I think. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Sat Jun 23 06:06:57 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08953 for ; Sat, 23 Jun 2001 06:06:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A191A91208; Sat, 23 Jun 2001 06:06:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 69321912C4; Sat, 23 Jun 2001 06:06:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D016091208 for ; Sat, 23 Jun 2001 06:06:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 653675DE1C; Sat, 23 Jun 2001 06:07:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) by segue.merit.edu (Postfix) with SMTP id 803B75DD92 for ; Sat, 23 Jun 2001 06:07:33 -0400 (EDT) Received: from s152.dhcp212-198-137.noos.fr (HELO jc.yahoo.com) (212.198.137.152) by smtp.mail.vip.sc5.yahoo.com with SMTP; 23 Jun 2001 10:06:52 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010623120219.00c3e9e0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 23 Jun 2001 12:03:37 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 88: Proposed Text for EAP Support Issues Cc: Pat Calhoun , aaa-wg@merit.edu In-Reply-To: <20010622114927.U14828@charizard.diameter.org> References: <4.3.2.7.2.20010619210420.00c19180@pop.mail.yahoo.com> <20010619105205.M17928@charizard.diameter.org> <4.3.2.7.2.20010619210420.00c19180@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 20:49 22/06/01, Pat Calhoun wrote: >On Fri, Jun 22, 2001 at 11:23:56AM +0200, Jacques Caron wrote: > > I hadn't noticed that EAP actually used different command-codes from > > regular AAA/AAR. In that case, maybe it should be an altogether different > > application? > >Although I do agree, the only issue I have is that both auth schemes end up >using the same authorization avps, so there'd be a whole lot of duplication :( Nothing prevents two applications from sharing the same AVPs (quite the contrary actually). Note that I didn't say two drafts, just two applications (for capabilities advertisement purposes). > > Another thing that came to mind while I was reading the Diameter Mobile IP > > draft this week-end, is there any (existent/planned) interaction between > > Mobile IP and EAP? > >no. Interesting... Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Sat Jun 23 13:47:52 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14236 for ; Sat, 23 Jun 2001 13:47:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 548689120D; Sat, 23 Jun 2001 13:47:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 206A69120E; Sat, 23 Jun 2001 13:47:53 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BD2AE9120D for ; Sat, 23 Jun 2001 13:47:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 16DB05DDEB; Sat, 23 Jun 2001 13:48:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115]) by segue.merit.edu (Postfix) with SMTP id C16265DD92 for ; Sat, 23 Jun 2001 13:48:47 -0400 (EDT) Received: from s152.dhcp212-198-137.noos.fr (HELO jc.yahoo.com) (212.198.137.152) by smtp.mail.vip.sc5.yahoo.com with SMTP; 23 Jun 2001 17:48:01 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010623193025.00bdd9e0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 23 Jun 2001 19:47:40 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 83: Routing/forwarding clarifications Cc: aaa-wg@merit.edu In-Reply-To: <20010622110552.R14828@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, Good work. Some comments, though: - The reorg of the different sections looks good, but I would also move the new section 6 before section 5, actually. One starts by establishing connections to peers before routing packets around. BTW, another sub-issue (a bit related to the other discussion I started about separating more the protocol from the applications) is that protocol messages (such as CER, DWR, etc.) should either not be in the pending request list, or explicitly not sent to alternate peers in case of failure of a connection, of course... Actually, I think most protocol messages (local to a connection) don't need the ack (delivery is guaranteed by the underlying transport, unless the connection is lost and then the message doesn't make sense any more), so don't need the R/A paradigm, and don't need to be saved to the pending request queue. I really need to propose some text along the lines of that separation of protocol and applications... - in your description of the peer table, it looks too much like you only have one default realm and a set of peers (as would be the case on most NASes). There might be multiple different primary/backup peers for different realms, and a given peer might serve multiple realms and have different roles (primary/backup/etc.) for each realm. I think this information belongs in the routing table rather than in the peer table. - the concept of "questionable" or "suspect" peers with a reliable transport underneath is quite intriguing to me? - for all the stuff that is in the transport draft: I had understood that draft was actually just recommendations about what should be present in AAA protocols (and specifically Diameter), but that the AAA protocol definition was to include whatever is necessary to meet these recommandations? I'll probably have some more coming up once I digest the changes :-/ Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Sun Jun 24 18:50:42 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16643 for ; Sun, 24 Jun 2001 18:50:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6DF17912A8; Sun, 24 Jun 2001 18:48:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 274E5912AC; Sun, 24 Jun 2001 18:48:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 02ED7912A8 for ; Sun, 24 Jun 2001 18:48:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AC1D65DD94; Sun, 24 Jun 2001 18:49:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id 44D155DD8F for ; Sun, 24 Jun 2001 18:49:16 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id SAA11933; Sun, 24 Jun 2001 18:38:46 -0400 (EDT) Message-Id: <4.1.20010624172842.01d27250@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sun, 24 Jun 2001 18:26:08 -0400 To: Pat Calhoun , aaa-wg@merit.edu From: Paul Funk Subject: Re: [AAA-WG]: Issue 83: Routing/forwarding clarifications In-Reply-To: <20010622110552.R14828@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-wg@merit.edu Precedence: bulk Pat, At 11:05 AM 6/22/01 -0700, Pat Calhoun wrote: >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >Finally, there have been changes to section 6, which I list here. However, >I do want to bring up the fact that there is one open issue. The state >machine doesn't have a state for "suspect" peers, so the table in 6.1 >shows "????" as the state. I believe that we need to have a state >in the state machine for suspect peers. Paul, any ideas? I assume you mean by "suspect" peer one whose watchdog timer has finally elapsed without a response? If I remember correctly from the interim meeting, when the watchdog finally elapses without a response, we don't actually close the connection (since the transport will do that if it's truly broken); we just try to use alternate peers instead. (Is that right?) While there is text that describes Tw and when to reset the watchdog timer, there is no text that describes when you decide that the connection is suspect. To handle the entire watchdog algorithm in the state machine would lead to a lot of complexity. Instead, what if watchdogs were removed from the state machine and the "Transport Failure Detection" section were expanded to more fully describe the algorithm and when the connection is deemed suspect, how it can redeem itself, etc.? Another question that needs clarification: Once a connection becomes suspect, in addition to connecting to alternate peers, is the Diameter node expected to failover pending requests? Or is it supposed to do this only upon actual disconnect? Currently, the "Failover/Failback Procedures" section speaks of transport failures only. Paul Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-wg@merit.edu Mon Jun 25 04:04:00 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08507 for ; Mon, 25 Jun 2001 04:04:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8DED59122E; Mon, 25 Jun 2001 04:03:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 53B4991231; Mon, 25 Jun 2001 04:03:57 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 26EC19122E for ; Mon, 25 Jun 2001 04:03:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8069B5DDD3; Mon, 25 Jun 2001 04:04:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 8E0095DD8E for ; Mon, 25 Jun 2001 04:04:54 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f5P84AN20663 for ; Mon, 25 Jun 2001 10:04:11 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Jun 25 10:04:03 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 10:04:07 +0200 Message-ID: <577066326047D41180AC00508B955DDA04D1A9C6@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'aaa-wg@merit.edu'" , "'pcalhoun@diameter.org'" Cc: "Martin Julien (ECE)" Subject: [AAA-WG]: Issue 89: Editorial comments - Mobile-IP draft-06 Date: Mon, 25 Jun 2001 10:04:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Martin Julien Submitter email address: martin.julien@ericsson.com Date first submitted: 25-Jun-2001 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg01446.html Document: mobileip-06 Comment type: E Priority: 1 Section: 2.1, 2.2, 2.3, 2.4, 3.1, 4.0, 4.7, 5.1, 6.0, 10.4 Rationale/Explanation of issue: Requested change: > > 1) Section 1.2, on top of page 7, I was wondering if it would be better > > to use the DIAMETER_ERROR_AUTH_FAILURE defined in the MIP draft, > > or to re-use the one already defined in the Base draft? The one in the > > Base could possibly be more generic, what do you think? > > I agree, and an issue should be opened. I think it would make more sense, since there is already an authentication error in the Base that seems, at this point, only used for the NASREQ app. > > 2) Section 2.1, I guess we could mention that the MN-AAA > > Authentication Extension information is carried by the > > (MIP-MN-AAA-Auth AVP), and that the Foreign Agent Challenge > > Extension information by the (MIP-FA-Challenge AVP). > > that would be useful. > > > 5) Section 2.2, the command-code should be 260, instead of 261. > > > > 6) Section 2.2, in the message format, should the > > MIP-HA-to-FA-Key AVP be included as [], in the case where the > > the Multi-Round-Auth is used? > > hmmmm.... agreed. > > > 7) Section 2.3, could we add the [MIP-Feature-Vector] as a possible > > AVP of the HAR message, since I see it very useful in the case where > > the AAAF needs to allocate an Home Agent in the foreign domain? > > yes, I agree. > > > 8) Section 2.4, I don't think it is very clean, with regards to the > > specification, to expect that the HA will be responsible of > forwarding the > > Session-Timeout, the Authorization-Lifetime, the > MIP-FA-to-MN-Key and the > > MIP-FA-to-HA-Key AVPs in the HAA. When I see those attributes > in the HAA, > > I always have to remind me that they are meaningless to the > HAA, but only > > meaningful to make easier the conversion of the HAA into a AMA in the > AAAH, > > which I consider not very useful anyway, since the AAAH still needs to > check > > that they have been included properly. Well, my opinion is that > we should > > remove them from there, since they are meaningless to the AAAH that > receives > > the HAA. > > ok. A few revisions of the base protocol base, less state was required on > the AAAH. Nowadays, though, I agree that the AAAH can easily keep this > state information (or add it to Proxy-State if it really wants to). > > > Also, note that the Session-Timeout AVP is {} in the HAA, but [] in the > HAR, > > which seems inconsistent. What the HA is supposed to put in there if not > > received in the HAR? > > oops > > > 9) Section 2.4, the Filter-Rule and the MIP-Foreign-Agent-Host > AVPs should > > be removed from the message format. They are not useful at all. > Maybe they > > could be in the message as *[AVP], which would mean that their > presence is > > not a problem, but not useful neither. > > well, we could, but it is sort-of useful to the implementor to know what > to expect in a message. I suspect that filters will unfortunately be more > frequent than we want to admit :( Yes, but why is it useful in the HAA? Can the HA return a different Filter-Rule AVP than the one received in the HAR? If not, then I don't see any added value of having that AVP in the HAA. > > 10) Section 3.1, can the HA return the DIAMETER_ERROR_HA_NOT_AVAILABLE > > when the can not provide the HA service? In that case, the AAAH, or > > the AAAF, would be responsible for allocating an other HA, if it had > > allocated it previously. That is the only reason why I would see the > > DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE useful, since the AAAH changes > > the DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE into a > > DIAMETER_ERROR_HA_NOT_AVAILABLE when answering to the FA, as described > > in page 12. > > I would much prefer that DIAMETER_TOO_BUSY be returned by an HA to state > that it cannot handle the request, and an alternative should be assigned. > The error in question should only be used when a specific server is > requested, and it cannot be assigned. OK, then could we add your last sentence in the description of the error? > > 12) Section 4.0, the Filter-Rule AVP should be referenced to section > > 4.11 instead of 4.10. It should also be of type UTF8String, instead of > > OctetString. The thing is that there are 2 sections 4.10, which should > > be corrected. Also, the MIP-Foreign-Agent-Host and MIP-Previous-FA-Host > > AVPs should be of type DiameterIdentity, instead of OctetString. > > right, well Filter-Rule is now a sub-type, so this will change. The > references, though, do need to be fixed. > > > 13) Section 4.7, the last paragraph, we should read "Only the AAAF may > > set the Foreign-Home-Agent-Available and Home-Agent-In-Foreign-Network > > flags to one." > > right. > > > 14) Section 5.1, 4th par. last word, should be HAA instead of AMA. > > correct. > > > 15) Section 6.0, the MIP-Algorithm-Type and MIP-Replay-Mode > AVPs should be > > of type Enumeratedm instead of Unsigned32. > > correct. > > > 17) Section 10.4 is no longer needed and should be completely deleted. > > correct > > Thanks, > > PatC > From owner-aaa-wg@merit.edu Mon Jun 25 04:05:35 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08578 for ; Mon, 25 Jun 2001 04:05:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 059B791231; Mon, 25 Jun 2001 04:05:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C19F2912B1; Mon, 25 Jun 2001 04:05:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9AEB291231 for ; Mon, 25 Jun 2001 04:05:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 10C7F5DDA8; Mon, 25 Jun 2001 04:06:20 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from oden.exmandato.se (oden.exmandato.se [192.71.33.1]) by segue.merit.edu (Postfix) with ESMTP id 420115DD8E for ; Mon, 25 Jun 2001 04:06:19 -0400 (EDT) Received: from servicefactory.se (root@oden.exmandato.se [192.71.33.1]) by oden.exmandato.se (8.8.8/8.8.5) with ESMTP id KAA15173; Mon, 25 Jun 2001 10:05:31 +0200 (MET DST) Message-ID: <3B36F0CB.A4DF40BB@servicefactory.se> Date: Mon, 25 Jun 2001 10:05:31 +0200 From: jonas Organization: Service Factory X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 87: Move filter-rule AVP to base References: <20010619082248.B17928@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Where would directives about the use of NAT and state-full inspection of filter rules go? /jonas Pat Calhoun wrote: > > All, > > Below is the proposed text, but I still haven't received any input on > whether this was an acceptable change. > > Thanks, > > PatC > ---- > 4.4 Derived AVP Data Formats > > [...] > FilterRule > The Filter-Rule format is derived from the OctetString AVP Base > Format. It uses the UTF-8 encoding and has the same > requirements as the UTF8String. Packets may be filtered based > on the following information that is associated with it: > > Direction (in or out) > Source and destination IP address (possibly masked) > Protocol > Source and destination port (lists or ranges) > TCP flags > IP fragment flag > IP options > ICMP types > > Rules for the appropriate direction are evaluated in order, > with the first matched rule terminating the evaluation. Each > packet is evaluated once. If no rule matches, the packet is > dropped if the last rule evaluated was a permit, and passed if > the last rule was a deny. > > The filters in the Filter-Rule AVP MUST follow the format: > > action dir proto from src to dst [options] > > action permit - Allow packets that match the rule. > deny - Drop packets that match the rule. > > dir "in" is from the terminal, "out" is to the > terminal. > > proto An IP protocol specified by number. The "ip" > keyword means any protocol will match. > > src and dst
[ports] > > The
may be specified as: > ipno An IPv4 or IPv6 number in dotted- > quad or canonical IPv6 form. Only > this exact IP number will match the > rule. > ipno/bits An IP number as above with a mask > width of the form 1.2.3.4/24. In > this case all IP numbers from > 1.2.3.0 to 1.2.3.255 will match. > The bit width MUST be valid for the > IP version and the IP number MUST > NOT have bits set beyond the mask. > > The sense of the match can be inverted by > preceding an address with the not modifier, > causing all other addresses to be matched > instead. This does not affect the selection of > port numbers. > > The keyword "any" is 0.0.0.0/0 or the IPv6 > equivalent. The keyword "assigned" is the > address or set of addresses assigned to the > terminal. The first rule SHOULD be "deny in > ip !assigned". > > With the TCP and UDP protocols, optional ports > may be specified as: > > {port|port-port}[,port[,...]] > > The `-' notation specifies a range of ports > (including boundaries). > > Fragmented packets which have a non-zero offset > (i.e. not the first fragment) will never match > a rule which has one or more port > specifications. See the frag option for > details on matching fragmented packets. > > options: > frag Match if the packet is a fragment and this is not > the first fragment of the datagram. frag may not > be used in conjunction with either tcpflags or > TCP/UDP port specifications. > > ipoptions spec > Match if the IP header contains the comma > separated list of options specified in spec. The > supported IP options are: > > ssrr (strict source route), lsrr (loose source > route), rr (record packet route) and ts > (timestamp). The absence of a particular option > may be denoted with a `!'. > > tcpoptions spec > Match if the TCP header contains the comma > separated list of options specified in spec. The > supported TCP options are: > > mss (maximum segment size), window (tcp window > advertisement), sack (selective ack), ts (rfc1323 > timestamp) and cc (rfc1644 t/tcp connection > count). The absence of a particular option may > be denoted with a `!'. > > established > TCP packets only. Match packets that have the RST > or ACK bits set. > > setup TCP packets only. Match packets that have the SYN > bit set but no ACK bit. > > tcpflags spec > TCP packets only. Match if the TCP header > contains the comma separated list of flags > specified in spec. The supported TCP flags are: > > fin, syn, rst, psh, ack and urg. The absence of a > particular flag may be denoted with a `!'. A rule > which contains a tcpflags specification can never > match a fragmented packet which has a non-zero > offset. See the frag option for details on > matching fragmented packets. > > icmptypes types > ICMP packets only. Match if the ICMP type is in > the list types. The list may be specified as any > combination of ranges or individual types > separated by commas. The supported ICMP types > are: > > echo reply (0), destination unreachable (3), > source quench (4), redirect (5), echo request > (8), router advertisement (9), router > solicitation (10), time-to-live exceeded (11), IP > header bad (12), timestamp request (13), > timestamp reply (14), information request (15), > information reply (16), address mask request (17) > and address mask reply (18). > > There is one kind of packet that the NAS MUST always discard, > that is an IP fragment with a fragment offset of one. This is > a valid packet, but it only has one use, to try to circumvent > firewalls. > > A NAS that is unable to interpret or apply a deny rule MUST > terminate the session. A NAS that is unable to interpret or > apply a permit rule MAY apply a more restrictive rule. A > NAS MAY apply deny rules of its own before the supplied > rules, for example to protect the NAS owner's > infrastructure. > > The rule syntax is a modified subset of ipfw(8) from FreeBSD, > and the ipfw.c code may provide a useful base for > implementations. From owner-aaa-wg@merit.edu Mon Jun 25 04:05:50 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08593 for ; Mon, 25 Jun 2001 04:05:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 45109912B1; Mon, 25 Jun 2001 04:05:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E0F57912B3; Mon, 25 Jun 2001 04:05:34 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7B922912B1 for ; Mon, 25 Jun 2001 04:05:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E7C0B5DDA8; Mon, 25 Jun 2001 04:06:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 43A015DD8E for ; Mon, 25 Jun 2001 04:06:29 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f5P85kN22336 for ; Mon, 25 Jun 2001 10:05:46 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Mon Jun 25 10:05:27 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 10:05:27 +0200 Message-ID: <577066326047D41180AC00508B955DDA04D1A9C7@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'pcalhoun@diameter.org'" , "'aaa-wg@merit.edu'" Cc: "Martin Julien (ECE)" Subject: [AAA-WG]: Issue 90: MIP-Previous-XXX AVP Date: Mon, 25 Jun 2001 10:05:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Martin Julien Submitter email address: martin.julien@ericsson.com Date first submitted: 25-Jun-2001 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg01446.html Document: mobileip-06 Comment type: T Priority: 2 Section: 2.1, 4.5, 4.6, Rationale/Explanation of issue: Requested change: > > 3) Section 2.1, I don't think the paragraph starting with > > "If the MIP-Previous-FA-Host AVP...." is still applicable > > in this draft. Can that AVP be useful at all in the current > > solution proposed in the draft? At least, I don't see how > > we could make use of that MIP-Previous-FA-Host AVP in the > > AAAH and the AAAF. Is it for future considerations? > > I am not sure. Others? > Thomas Panagiotis commented: "MIP/Fast interdomain handoffs?" I agree that it could be useful for that, but in the actual draft, that is not supported, AFAIK. So, I think it should either be removed, since there is no clear defined use for it at this point, or be kept with some kind of explanations how it can be useful in the AAAF or AAAH. Based on the draft, the AAAF and AAAH already have access to the User-Name, the MIP-Home-Agent-Address and MIP-Mobile-Node-Address, which I think is enough to get access to the stored MN-FA and FA-HA keys, if needed in the AAAF. Of course that it means that the AAAF needs to be stateful, but is there any other way of handling this? One way we could be using the MIP-Previous-FA-Host AVP, would possibly be to make the AAAF stateless, which could possibly invoke the Session-Abort message towards the Previous-FA. Would it be a valid interpretation of that AVP or not? Does it make any sense? > > Furthermore, I thought we had agreed that the User-Name > > was not enough for the purpose of retrieving keys in the AAAF, > > but would rather require the User-Name, the Home-Address and > > the Home-Agent? > > That rings a bell. I may have missed that one. > > > 4) Section 2.1, in the message format, I am questionning the > > necessity of the MIP-Previous-FA-Host and MIP-Previous-FA-Addr AVPs. > > right, again, not sure. Perhaps this one should actually be a separate > issue from the editorial ones. > > > PatC > From owner-aaa-wg@merit.edu Mon Jun 25 05:10:06 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09243 for ; Mon, 25 Jun 2001 05:10:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8A817912B4; Mon, 25 Jun 2001 05:10:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 58117912B5; Mon, 25 Jun 2001 05:10:02 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1DB91912B4 for ; Mon, 25 Jun 2001 05:10:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6DDBB5DDA1; Mon, 25 Jun 2001 05:11:00 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 955B75DD8E for ; Mon, 25 Jun 2001 05:10:59 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f5P9AGN25825 for ; Mon, 25 Jun 2001 11:10:16 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Jun 25 11:10:11 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 11:10:15 +0200 Message-ID: <577066326047D41180AC00508B955DDA04D1A9C8@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'pcalhoun@diameter.org'" , "'aaa-wg@merit.edu'" Cc: "Martin Julien (ECE)" Subject: [AAA-WG]: Issue 91: MIP SPI Date: Mon, 25 Jun 2001 11:10:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Martin Julien Submitter email address: martin.julien@ericsson.com Date first submitted: 25-Jun-2001 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg01446.html Document: mobileip-06 Comment type: T Priority: S Section: Rationale/Explanation of issue: Requested change: > > 18) Section 6.2.7, should the SHA-1 algorithm be also added, as in the > > aaa-key-06 draft? BTW, would it be better that the values assigned to > > those algorithms match between the 2 drafts? The last comment also > > applies to the Replay-Mode. > > yes, but it really don't matter if there isn't a match. If you think it > would be useful, include it in your issue. Not really, it was only a comment. The thing is that since the values in the Diameter MIP-06 draft are based on the ones defined in the other document, I thought it would be better to keep the values consistent, but of course, it does not have to be like this, strictly speaking. > > 11) If there is a problem in the HA or FA with the SPI generated by > > the AAAH or AAAF, how could that be reported? > > reported by whom? The HA? Or one of the AAA servers? > > > 16) Whenever no MIP-*-Preferred-SPI AVP is included in the AMR, can we > > assume that the SPI generated by the AAAH or AAAF can be completely > > random or not? Why can't the HA decide the SPI itself? > > There's no reason why, really :( I'm still not quite sure to get the complete picture of how the SPI should be handled in the AAA servers. Are we expecting the AAA servers to use the standard 0-255 SPI defined by IANA?, or are the AAA servers expected to handle to concept of SA, which normally contains and defines their own SPI values? As defined in RFC 2002 (MIP): Mobility Security Association A collection of security contexts, between a pair of nodes, which may be applied to Mobile IP protocol messages exchanged between them. Each context indicates an authentication algorithm and mode (Section 5.1), a secret (a shared key, or appropriate public/private key pair), and a style of replay protection in use (Section 5.6). Security Parameter Index (SPI) An index identifying a security context between a pair of nodes among the contexts available in the Mobility Security Association. SPI values 0 through 255 are reserved and MUST NOT be used in any Mobility Security Association. I believe that MIP is using the standard CHAP_SPI, when using RADIUS, right? Should the Diameter server follow the same path or not? I guess not, since the key AVPs would not contain the MIP-SPI, the algo and the Replay-Mode, right? The thing is that if Diameter needs to support the concept of SA, then it seems to be difficult for the AAA server to select an SPI on behalf of the MN, the HA and the FA. Of course, the AAA can count on the Preferred-SPI from the FA and the MN, in which case the AAA simply agrees with the value. However, if there is no Preferred-SPI AVPs in the AMR, then the AAAH needs to generate them, at the risk that they might already be used in the SA defined between the MN and the HA, or between the HA and the FA, or between the FA and the MN. I think that it makes more sense for the HA to select the required SPI between the HA-MN and HA-FA, if no Preferred-SPI is included in the AMR. I guess that the MIP-Foreign-Agent-Host AVP could be useful for creating the SPI within the SA defined between the HA and the FA. > > Also, when a MIP-*-Preferred-SPI AVP is included in the AMR, I guess > > that the FA has chosen a value that what not already already by any > > of the SAs, right? The thing is that it might not know the HA yet, > > i.e. the SA. > > > > 19) Section 6.1, could you please explain to me what "The Mobile IP key > > described in [15] refers to the AAA SPI, which MUST be set to the value > > the AAAH shares with the Mobile Node." Are we talking about a > > pre-configured shared SPI, or a secret key? Can it dynamically change > > or not? It is not clear to me how the AAA SPI can help in creating the > > FA or HA Security Information. Could you please tell me more? > > I'd love to explain it, but that would require that I first > understand it :( > > I believe that what I had originally intended to state here is that the > values created are used in a particular field of the MIP AAA key in [15]. > This needs some major cleaning up. > > Thanks, > > PatC > From owner-aaa-wg@merit.edu Mon Jun 25 08:52:16 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13818 for ; Mon, 25 Jun 2001 08:52:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1E26891232; Mon, 25 Jun 2001 08:52:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D812191233; Mon, 25 Jun 2001 08:52:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B775691232 for ; Mon, 25 Jun 2001 08:52:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7BCB75DDD3; Mon, 25 Jun 2001 08:53:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id D82715DDA0 for ; Mon, 25 Jun 2001 08:53:18 -0400 (EDT) Received: (qmail 11666 invoked by uid 500); 25 Jun 2001 12:41:22 -0000 Date: Mon, 25 Jun 2001 05:41:22 -0700 From: Pat Calhoun To: jonas Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 87: Move filter-rule AVP to base Message-ID: <20010625054122.C14828@charizard.diameter.org> Mail-Followup-To: jonas , Pat Calhoun , aaa-wg@merit.edu References: <20010619082248.B17928@charizard.diameter.org> <3B36F0CB.A4DF40BB@servicefactory.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B36F0CB.A4DF40BB@servicefactory.se>; from jonas.bulow@servicefactory.se on Mon, Jun 25, 2001 at 10:05:31AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Jun 25, 2001 at 10:05:31AM +0200, jonas wrote: > Hi, > > Where would directives about the use of NAT and state-full inspection of > filter rules go? a separate AVP, IMHO. PatC From owner-aaa-wg@merit.edu Mon Jun 25 08:53:54 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13885 for ; Mon, 25 Jun 2001 08:53:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D9B9C91233; Mon, 25 Jun 2001 08:54:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8B9AC912B5; Mon, 25 Jun 2001 08:54:03 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7D42B91233 for ; Mon, 25 Jun 2001 08:54:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 497095DDD3; Mon, 25 Jun 2001 08:55:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id E7D0C5DDA0 for ; Mon, 25 Jun 2001 08:55:01 -0400 (EDT) Received: (qmail 11686 invoked by uid 500); 25 Jun 2001 12:43:05 -0000 Date: Mon, 25 Jun 2001 05:43:05 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 88: Proposed Text for EAP Support Issues Message-ID: <20010625054305.D14828@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <4.3.2.7.2.20010619210420.00c19180@pop.mail.yahoo.com> <20010619105205.M17928@charizard.diameter.org> <4.3.2.7.2.20010619210420.00c19180@pop.mail.yahoo.com> <20010622114927.U14828@charizard.diameter.org> <4.3.2.7.2.20010623120219.00c3e9e0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010623120219.00c3e9e0@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Sat, Jun 23, 2001 at 12:03:37PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Sat, Jun 23, 2001 at 12:03:37PM +0200, Jacques Caron wrote: > At 20:49 22/06/01, Pat Calhoun wrote: > >On Fri, Jun 22, 2001 at 11:23:56AM +0200, Jacques Caron wrote: > > > I hadn't noticed that EAP actually used different command-codes from > > > regular AAA/AAR. In that case, maybe it should be an altogether different > > > application? > > > >Although I do agree, the only issue I have is that both auth schemes end up > >using the same authorization avps, so there'd be a whole lot of duplication :( ah, I see. So 802.1x wouldn't have to support PAP/CHAP, and still conform to *part of* the spec. > > Nothing prevents two applications from sharing the same AVPs (quite the > contrary actually). Note that I didn't say two drafts, just two > applications (for capabilities advertisement purposes). > > > > Another thing that came to mind while I was reading the Diameter Mobile IP > > > draft this week-end, is there any (existent/planned) interaction between > > > Mobile IP and EAP? > > > >no. > > Interesting... mip has it's own auth scheme, and it doesn't fit the EAP model at all. PatC From owner-aaa-wg@merit.edu Mon Jun 25 08:56:36 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13972 for ; Mon, 25 Jun 2001 08:56:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BE546912B5; Mon, 25 Jun 2001 08:56:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 921A2912B6; Mon, 25 Jun 2001 08:56:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5361B912B5 for ; Mon, 25 Jun 2001 08:56:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 11B0F5DDD3; Mon, 25 Jun 2001 08:57:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 55F155DDA0 for ; Mon, 25 Jun 2001 08:57:31 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f5PCulN06149 for ; Mon, 25 Jun 2001 14:56:47 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Jun 25 14:56:46 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 14:56:45 +0200 Message-ID: <3DFC2DB418B2D211A1950008C7A4E1EA0EB465EF@eestqnt102> From: "Oscar Morales-Ruiz (ECE)" To: aaa-wg@merit.edu Subject: [AAA-WG]: Date: Mon, 25 Jun 2001 14:55:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi there, Maybe this issue was discussed in the past, but I would like to get a clear picture about the Request-Type AVP because I have no clue of the *real* behaviour of this AVP. The latest draft (06) claims that this AVP is used to determine the type of the request being transmitted. The allowed values are AUTHENTICATE_ONLY, AUTHORIZE_ONLY and AUTHORIZE_AUTHENTICATE. The point is that I was not able to get a clear picture of the possible (and allowed) combinations among those values: My assumptions are (correct me if I'm wrong): 1. It is possible for a NAS to issue an AUTHENTICATE_ONLY request and later on to issue AUTHORIZE_ONLY requests corresponding to the session previously authenticated. That means that the AAA Server should store information about the session when it is first authenticated and later on to authorize the authorization requests associated to that particular session. If subsequent AUTHENTICATE_ONLY messages are received for that particular session, those messages mean re-authentication requests. If subsequent AUTHORIZE_ONLY messages are received for that particular session, those messages mean re-authorization requests (and possibly authorization requests for those services not previously authorized). If subsequent AUTHORIZE_AUTHENTICATE messages are received for that particular session, those messages mean re-authentication plus re-authorization requests (and possibly new authorization requests for those services not previoulsy authorized). 2. It is possible to AUTHORIZE_AUTHENTICATE a session which means that the session is first authenticated and then the access to a particular service is authorised. Hence it is possible to receive AUTHENTICATE_ONLY messages which mean re-authentication for the existing session. It is also possible to receive AUTHORIZE_ONLY messages for that existing session which mean authorization requests for the existing session (and maybe re-authorization for those services previously authorized). If subsequent AUTHORIZE_AUTHENTICATE messages are received for that particular session, those messages mean re-authentication plus re-authorization requests. 3. Is it possible to receive an AUTHORIZE_ONLY message without a previous authentication request ?? I should say yes, but it is not clear to me :-(( I would like to get a clarification on this one. Cheers, Oscar. From owner-aaa-wg@merit.edu Mon Jun 25 09:12:59 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14504 for ; Mon, 25 Jun 2001 09:12:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A5C61912B6; Mon, 25 Jun 2001 09:12:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7154C912B7; Mon, 25 Jun 2001 09:12:55 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4AF5B912B6 for ; Mon, 25 Jun 2001 09:12:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0A2445DDAA; Mon, 25 Jun 2001 09:13:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) by segue.merit.edu (Postfix) with SMTP id B4AD15DDA0 for ; Mon, 25 Jun 2001 09:13:53 -0400 (EDT) Received: from s152.dhcp212-137.cybercable.fr (HELO jc.yahoo.com) (212.198.137.152) by smtp.mail.vip.sc5.yahoo.com with SMTP; 25 Jun 2001 13:13:08 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010625145911.00cb9e60@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 25 Jun 2001 15:12:23 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 88: Proposed Text for EAP Support Issues Cc: Pat Calhoun , aaa-wg@merit.edu In-Reply-To: <20010625054305.D14828@charizard.diameter.org> References: <4.3.2.7.2.20010623120219.00c3e9e0@pop.mail.yahoo.com> <4.3.2.7.2.20010619210420.00c19180@pop.mail.yahoo.com> <20010619105205.M17928@charizard.diameter.org> <4.3.2.7.2.20010619210420.00c19180@pop.mail.yahoo.com> <20010622114927.U14828@charizard.diameter.org> <4.3.2.7.2.20010623120219.00c3e9e0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 14:43 25/06/01, Pat Calhoun wrote: >On Sat, Jun 23, 2001 at 12:03:37PM +0200, Jacques Caron wrote: > > At 20:49 22/06/01, Pat Calhoun wrote: > > >On Fri, Jun 22, 2001 at 11:23:56AM +0200, Jacques Caron wrote: > > > > I hadn't noticed that EAP actually used different command-codes from > > > > regular AAA/AAR. In that case, maybe it should be an altogether > different > > > > application? > > > > > >Although I do agree, the only issue I have is that both auth schemes > end up > > >using the same authorization avps, so there'd be a whole lot of > duplication :( > >ah, I see. So 802.1x wouldn't have to support PAP/CHAP, and still conform to >*part of* the spec. Or, alternatively, a Radius-to-Diameter gateway serving Radius NASes that do not support EAP... Or a Diameter-to-Radius gateway in front of a Radius server that doesn't support EAP either. BTW, wouldn't it be possible to only have EAP in Diameter, and require clients to do EAP/PAP or EAP/CHAP conversion (the former being a problem since there is no clear-text auth in EAP, of course)? Not sure it would bring anything, just a bit of simplification for pure Diameter implementations maybe, PAP/CHAP being then considered just EAP methods like any others... Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Mon Jun 25 09:46:47 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15430 for ; Mon, 25 Jun 2001 09:46:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3E37A912B7; Mon, 25 Jun 2001 09:46:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0BD6F912B8; Mon, 25 Jun 2001 09:46:46 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D16F2912B7 for ; Mon, 25 Jun 2001 09:46:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B152C5DDD3; Mon, 25 Jun 2001 09:47:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 591935DDAA for ; Mon, 25 Jun 2001 09:47:45 -0400 (EDT) Received: (qmail 11809 invoked by uid 500); 25 Jun 2001 13:35:45 -0000 Date: Mon, 25 Jun 2001 06:35:45 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 88: Proposed Text for EAP Support Issues Message-ID: <20010625063545.E14828@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <4.3.2.7.2.20010623120219.00c3e9e0@pop.mail.yahoo.com> <4.3.2.7.2.20010619210420.00c19180@pop.mail.yahoo.com> <20010619105205.M17928@charizard.diameter.org> <4.3.2.7.2.20010619210420.00c19180@pop.mail.yahoo.com> <20010622114927.U14828@charizard.diameter.org> <4.3.2.7.2.20010623120219.00c3e9e0@pop.mail.yahoo.com> <20010625054305.D14828@charizard.diameter.org> <4.3.2.7.2.20010625145911.00cb9e60@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010625145911.00cb9e60@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Mon, Jun 25, 2001 at 03:12:23PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Jun 25, 2001 at 03:12:23PM +0200, Jacques Caron wrote: > Or, alternatively, a Radius-to-Diameter gateway serving Radius NASes that > do not support EAP... Or a Diameter-to-Radius gateway in front of a Radius > server that doesn't support EAP either. > > BTW, wouldn't it be possible to only have EAP in Diameter, and require > clients to do EAP/PAP or EAP/CHAP conversion (the former being a problem > since there is no clear-text auth in EAP, of course)? Not sure it would > bring anything, just a bit of simplification for pure Diameter > implementations maybe, PAP/CHAP being then considered just EAP methods like > any others... as you state, there is no PAP subtype for EAP. However, having the NAS initiate EAP, and simply carry CHAP within it does have the advantage of allowing the home server to authenticate the user, without the replay problems found in today's non-EAP networks. However, this breaks with traditional RADIUS servers, most of which don't support EAP :( so interoperability becomes an issue. PatC From owner-aaa-wg@merit.edu Mon Jun 25 09:52:02 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15659 for ; Mon, 25 Jun 2001 09:51:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AE867912B8; Mon, 25 Jun 2001 09:51:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 73FE6912B9; Mon, 25 Jun 2001 09:51:53 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 57B90912B8 for ; Mon, 25 Jun 2001 09:51:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2E0315DDAA; Mon, 25 Jun 2001 09:52:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 7DB4F5DD8C for ; Mon, 25 Jun 2001 09:52:51 -0400 (EDT) Received: (qmail 11831 invoked by uid 500); 25 Jun 2001 13:40:54 -0000 Date: Mon, 25 Jun 2001 06:40:54 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 79: Error Handling Editorial Changes Message-ID: <20010625064054.F14828@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <4.3.2.7.2.20010622103947.00c721d0@pop.mail.yahoo.com> <20010621170141.L14828@charizard.diameter.org> <4.3.2.7.2.20010622103947.00c721d0@pop.mail.yahoo.com> <20010622113548.T14828@charizard.diameter.org> <4.3.2.7.2.20010623113817.00c29ba0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010623113817.00c29ba0@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Sat, Jun 23, 2001 at 12:01:58PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Sat, Jun 23, 2001 at 12:01:58PM +0200, Jacques Caron wrote: > At 20:35 22/06/01, Pat Calhoun wrote: > >On Fri, Jun 22, 2001 at 11:23:07AM +0200, Jacques Caron wrote: > > > Hi, > > > > > > I still think this is redundant with the 'P' bit. A message with 'R' clear > > > and 'P' clear is a non-proxiable answer, and thus something for local > > > processing. Then the combination of Command-Code and Result-Code will tell > > > the proxy/relay whether it's a CEA or a protocol error. > > > >'P' and 'E' are different. A message with the 'E' bit set is still > >proxiable, but the 'E' bit is an alert to agents that they should attempt > >to take local action. However, if they cannot, they must proxy the > >answer. > > I think in both cases the messages calls for local action. In some cases, > the local action might be to forward it further downstream... Then let's call it additional local action. relaying, or proxying is always the case. This is a special message that the agent must treat with care. In certain cases, it may require that the request be forwarded to an alternate agent. When neither bits are set, normal fast path routing is done. > > > > Also, I think it would be wise to specify which combinations of the flag > > > bits are allowed, and what to do if an unallowed combination is received. > > > >The text already does state this. The only rule is that the 'R' and the 'E' > >bits cannot be set at the same time. See the text in 'E'. > > What about P with the other ones? that isn't a problem. > > >So, if I understand your second comment, a new result code needs to be created > >that states that conflicting bits are set in the header? > > Yep. ok. > > > > This would probably simplify a lot the ABNF, as all "Application" commands > > > would not be encumbered with all the "protocol" AVPs, too. > > > >it certainly is possible to create new avps that do exactly the same thing > >as those defined in the base, but I fail to see the logic in duplicate > >functionality. > > No, the idea is to separate them. I.e, no need to put all the > "Route-Record", "Destination-Host", "Destination-Realm", "Proxy-State" and > any other routing-related stuff in the ANBF for AAA/AAR. So you can change > more easily all the routing part without having to touch all possible > application commands. > > It makes it easier also for proxies/relays that have to understand some > AVPs (e.g. Session-Timeout) to know which ones they're supposed to know how > to handle or not. > > > > Note that though the changes are radical, it might not require to change > > > that much text, so it could still be done pretty quickly. Let me know if > > > anyone wants to pursue this [for some reason I doubt it :-(]. > > > >i doubt it, and would need additional clarifying information, like what > >exactly > >are we talking about here. > > Well, it's a matter of separating the Diameter protocol in two layers: one > which takes care of communication over a local link, and one which is > end-to-end communication. > > On a local link, one could exchange the following messages: > - Capabilities-Advertisement > - Device-Watchdog > - Termination-Request > - Protocol-Error > - Application-C2S-Request > - Application-S2C-Request > - Aplication-Answer > > [C2S and S2C mean Client-to-Server and Server-to-client, respectively]. > > Each of those messages would contain AVPs related to their function, in a > local context. The two Application-*-Requests would contain > Destination-Realm/Host and Route-Record AVPs, and an "Application-Data" > grouped AVP that would contain the actual end-to-end command and AVPs. > Application-Answer could contain just that AVP. > > To make extension simpler, the local link command types should have a bit > structure that makes it easy for an agent to understand what type of > command is which. Note that for requests, I would also include the type of > request (auth, accounting...), as proxies that maintain session state need > to be able to interpret them. > > I'm trying to put all that into some clear text, I'll send it as soon as I can. That a whole lotta changes so late in the game.... PatC From owner-aaa-wg@merit.edu Mon Jun 25 09:58:12 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15785 for ; Mon, 25 Jun 2001 09:58:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A4318912B9; Mon, 25 Jun 2001 09:58:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 77E78912BA; Mon, 25 Jun 2001 09:58:03 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7A14E912B9 for ; Mon, 25 Jun 2001 09:58:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4F14D5DDAA; Mon, 25 Jun 2001 09:59:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id BA9005DD8C for ; Mon, 25 Jun 2001 09:59:01 -0400 (EDT) Received: (qmail 32321 invoked by uid 500); 25 Jun 2001 13:58:11 -0000 Date: Mon, 25 Jun 2001 08:58:10 -0500 From: David Frascone To: aaa-wg@merit.edu Subject: [AAA-WG]: [Arek.Nowakowski@tic.siemens.ca: Question regarding AVPs address type] Message-ID: <20010625085810.Z9376@newman.frascone.com> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a very good question. I have never thought about it. What *should* a user supply when creating an address AVP? A pointer to a struct sockaddr_storage? I'm leaning this direction. I would also like to add some functionality to create struct sockaddr_storage objects from Diameter URI's. Opinions? -Dave ----- Forwarded message from Arek Nowakowski ----- Message-ID: <53D69AD06EFAD311842300A0C99B4F08D50D73@ticsmtp2.innovation.siemens.ca> From: Arek Nowakowski To: "'David Frascone'" Subject: Question regarding AVPs address type Date: Sun, 24 Jun 2001 14:03:58 -0400 Hello, When creating AVP type address, using AAACreateAVP function problem came up. Is it allowed to give the address data in the network byte order form? Does the input data have to be in a human readable form? Regards. Arek Nowakowski ----- End forwarded message ----- From owner-aaa-wg@merit.edu Mon Jun 25 10:01:16 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15878 for ; Mon, 25 Jun 2001 10:01:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3D2C2912BB; Mon, 25 Jun 2001 10:00:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BBC33912DE; Mon, 25 Jun 2001 10:00:25 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B45E4912BB for ; Mon, 25 Jun 2001 10:00:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 945985DDA8; Mon, 25 Jun 2001 10:01:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 1AC105DD8C for ; Mon, 25 Jun 2001 10:01:23 -0400 (EDT) Received: (qmail 11854 invoked by uid 500); 25 Jun 2001 13:49:26 -0000 Date: Mon, 25 Jun 2001 06:49:26 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 83: Routing/forwarding clarifications Message-ID: <20010625064926.G14828@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <20010622110552.R14828@charizard.diameter.org> <4.3.2.7.2.20010623193025.00bdd9e0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010623193025.00bdd9e0@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Sat, Jun 23, 2001 at 07:47:40PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Sat, Jun 23, 2001 at 07:47:40PM +0200, Jacques Caron wrote: > - The reorg of the different sections looks good, but I would also move the > new section 6 before section 5, actually. One starts by establishing > connections to peers before routing packets around. I was considering that when making the changes, but wasn't able to convince myself. I agree with making this change, and it will be done for the next revision. > > > BTW, another sub-issue (a bit related to the other discussion I started > about separating more the protocol from the applications) is that protocol > messages (such as CER, DWR, etc.) should either not be in the pending > request list, or explicitly not sent to alternate peers in case of failure > of a connection, of course... Actually, I think most protocol messages > (local to a connection) don't need the ack (delivery is guaranteed by the > underlying transport, unless the connection is lost and then the message > doesn't make sense any more), so don't need the R/A paradigm, and don't > need to be saved to the pending request queue. I really need to propose > some text along the lines of that separation of protocol and applications... actually, a request without the 'P' bit set doesn't get added to the pending message list. > > - in your description of the peer table, it looks too much like you only > have one default realm and a set of peers (as would be the case on most > NASes). There might be multiple different primary/backup peers for > different realms, and a given peer might serve multiple realms and have > different roles (primary/backup/etc.) for each realm. I think this > information belongs in the routing table rather than in the peer table. hmmm... they actually belong in both, but I am not sure how to put that down in ASCII. The basic issue is that for each realm, you want a primary/secondary, but the actual relationship is: /------- Peer Entry (Primary) Route Table Entry +----- \------- Peer Entry (Secondary) So, my thoughts is that a route table points to a set of peer entries. Each peer entry is marked with its role, and not the route table. Of course, an intermediate "shim" may be required between the route table and the peer entry, but this makes implementations a tad more complex. > - the concept of "questionable" or "suspect" peers with a reliable > transport underneath is quite intriguing to me? I am open to suggestions, but that's all I could think of at that time. I am certain you know what I mean, right? > > - for all the stuff that is in the transport draft: I had understood that > draft was actually just recommendations about what should be present in AAA > protocols (and specifically Diameter), but that the AAA protocol definition > was to include whatever is necessary to meet these recommandations? yes, but I believe that Bernard didn't necessarily want to dup unnecessarily. However, if you feel strongly that we can put a summary of what's in the transport draft (and perhaps reference the transport draft), then that would be acceptable to me. PatC From owner-aaa-wg@merit.edu Mon Jun 25 10:05:16 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15969 for ; Mon, 25 Jun 2001 10:05:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5287A91234; Mon, 25 Jun 2001 10:05:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1C676912DE; Mon, 25 Jun 2001 10:05:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1215991234 for ; Mon, 25 Jun 2001 10:05:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F024F5DDA8; Mon, 25 Jun 2001 10:06:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 50CB25DD8C for ; Mon, 25 Jun 2001 10:06:10 -0400 (EDT) Received: (qmail 11879 invoked by uid 500); 25 Jun 2001 13:54:13 -0000 Date: Mon, 25 Jun 2001 06:54:13 -0700 From: Pat Calhoun To: Paul Funk Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 83: Routing/forwarding clarifications Message-ID: <20010625065413.H14828@charizard.diameter.org> Mail-Followup-To: Paul Funk , Pat Calhoun , aaa-wg@merit.edu References: <20010622110552.R14828@charizard.diameter.org> <4.1.20010624172842.01d27250@cairo.funk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.1.20010624172842.01d27250@cairo.funk.com>; from paul@funk.com on Sun, Jun 24, 2001 at 06:26:08PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Sun, Jun 24, 2001 at 06:26:08PM -0400, Paul Funk wrote: > Pat, > > At 11:05 AM 6/22/01 -0700, Pat Calhoun wrote: > >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >Finally, there have been changes to section 6, which I list here. However, > >I do want to bring up the fact that there is one open issue. The state > >machine doesn't have a state for "suspect" peers, so the table in 6.1 > >shows "????" as the state. I believe that we need to have a state > >in the state machine for suspect peers. Paul, any ideas? > > I assume you mean by "suspect" peer one whose watchdog timer has > finally elapsed without a response? yes > > If I remember correctly from the interim meeting, when the watchdog > finally elapses without a response, we don't actually close the connection > (since the transport will do that if it's truly broken); we just try to use > alternate peers instead. (Is that right?) which is why I showed that a peer went into the "suspect" state, and eventually either goes back into the open, or the closed state. > > While there is text that describes Tw and when to reset the watchdog > timer, there is no text that describes when you decide that the connection > is suspect. right. > > To handle the entire watchdog algorithm in the state machine would > lead to a lot of complexity. Instead, what if watchdogs were removed > from the state machine and the "Transport Failure Detection" section were > expanded to more fully describe the algorithm and when the connection > is deemed suspect, how it can redeem itself, etc.? I had tried to make the changes to the state machine, but without relying on a counter in a control block, it makes for a rather nasty, and lengthy, change in the state machine. So, I agree that some text should be added somewhere else. However, it may be useful to add a single "suspect" state in the SM, and have text, as you state, that describes the counter. > > Another question that needs clarification: Once a connection becomes > suspect, in addition to connecting to alternate peers, is the Diameter > node expected to failover pending requests? Or is it supposed to do > this only upon actual disconnect? Currently, the "Failover/Failback > Procedures" section speaks of transport failures only. we've never discussed this one :( PatC From owner-aaa-wg@merit.edu Mon Jun 25 10:06:40 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15984 for ; Mon, 25 Jun 2001 10:06:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 42919912DE; Mon, 25 Jun 2001 10:06:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0FFD9912E0; Mon, 25 Jun 2001 10:06:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F02C9912DE for ; Mon, 25 Jun 2001 10:06:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C16AE5DDA8; Mon, 25 Jun 2001 10:07:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 0ADBB5DE3E for ; Mon, 25 Jun 2001 10:07:48 -0400 (EDT) Received: (qmail 11896 invoked by uid 500); 25 Jun 2001 13:55:51 -0000 Date: Mon, 25 Jun 2001 06:55:51 -0700 From: Pat Calhoun To: Jacques Caron Cc: Barney Wolff , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 81: Route-Record change Message-ID: <20010625065551.I14828@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Barney Wolff , aaa-wg@merit.edu References: <20010622112638.S14828@charizard.diameter.org> <20010622112638.S14828@charizard.diameter.org> <20010622151455.A23431@tp.databus.com> <4.3.2.7.2.20010623120351.00c0e2f0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010623120351.00c0e2f0@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Sat, Jun 23, 2001 at 12:05:57PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Sat, Jun 23, 2001 at 12:05:57PM +0200, Jacques Caron wrote: > At 21:14 22/06/01, Barney Wolff wrote: > >Pat, presumably actual loops will be very rare and only persist until > >a misconfiguration is corrected. Thus it does no harm at all, imho, > >to defer the check until one is about to forward the request. That > >way, the check is always done against ones own identity, with no > >risk of encoding differences leading to false negatives. It really > >should not take half a page to express the equality-comparison > >algorithm for Diameter identities, nor should one have to convert > >every item in the recorded route to canonical form to do the comparison. > > Again, I think it should be stated that any DiameterIdentities used in all > the loop-checking activities MUST be the value advertised in Origin-Host in > CER/CEA, and should be treated as an opaque string. Then pure string > matching (strcmp) would be enough. so you compare what a peer had advertised with the Route-Record AVPs in a message, effectively looking for loops for the peer? PatC From owner-aaa-wg@merit.edu Mon Jun 25 10:33:45 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16568 for ; Mon, 25 Jun 2001 10:33:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 71D2691235; Mon, 25 Jun 2001 10:33:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4BEE791236; Mon, 25 Jun 2001 10:33:42 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 55E4491235 for ; Mon, 25 Jun 2001 10:33:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3B1405DDA8; Mon, 25 Jun 2001 10:34:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 7D4535DD8C for ; Mon, 25 Jun 2001 10:34:40 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f5PEWx902801 for ; Mon, 25 Jun 2001 17:32:59 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 25 Jun 2001 17:33:53 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Mon, 25 Jun 2001 17:33:56 +0300 Message-ID: From: jaakko.rajaniemi@nokia.com To: aaa-wg@merit.edu Subject: [AAA-WG]: Securing Diameter Messages Date: Mon, 25 Jun 2001 17:33:49 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, I have a question regarding the section 2.2, "Securing Diameter Messages" of the base-06, which says that: "Diameter clients, such as Network Access Servers (NASes) and Foreign Agents MUST support IP Security [37], and MAY support TLS [38]. Diameter servers MUST support TLS, but the administrator MAY opt to configure IPSec instead of using TLS. Operating the Diameter protocol without any security mechanism is not recommended." Is it defined on purpose like this? To me it does not sound very rational to mandate clients to support IPsec and servers to support TLS. Mandating one protocol, e.g. IPsec if acceptable for everyone, would be reasonable. Also I think that some text may be needed to clarify the Diameter agents and their required support. I understood that there have been some concerns raised, probably in the May interim meeting, about the interoperability of SCTP with IPsec and TLS which may need to be taken into account in here. Br, Jaakko PS. Sorry if this should have been submitted as an issue. I can do that if it is needed. From owner-aaa-wg@merit.edu Mon Jun 25 10:34:44 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16642 for ; Mon, 25 Jun 2001 10:34:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 69FB591236; Mon, 25 Jun 2001 10:34:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 31D0F912E1; Mon, 25 Jun 2001 10:34:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 00F3B91236 for ; Mon, 25 Jun 2001 10:34:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E32535DD8C; Mon, 25 Jun 2001 10:35:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp014.mail.yahoo.com (smtp014.mail.yahoo.com [216.136.173.58]) by segue.merit.edu (Postfix) with SMTP id 603B55DDA8 for ; Mon, 25 Jun 2001 10:35:42 -0400 (EDT) Received: from s152.dhcp212-137.cybercable.fr (HELO jc.yahoo.com) (212.198.137.152) by smtp.mail.vip.sc5.yahoo.com with SMTP; 25 Jun 2001 14:34:55 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010625162342.00b1d410@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 25 Jun 2001 16:34:05 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 83: Routing/forwarding clarifications Cc: Pat Calhoun , aaa-wg@merit.edu In-Reply-To: <20010625064926.G14828@charizard.diameter.org> References: <4.3.2.7.2.20010623193025.00bdd9e0@pop.mail.yahoo.com> <20010622110552.R14828@charizard.diameter.org> <4.3.2.7.2.20010623193025.00bdd9e0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 15:49 25/06/01, Pat Calhoun wrote: > > BTW, another sub-issue (a bit related to the other discussion I started > > about separating more the protocol from the applications) is that protocol > > messages (such as CER, DWR, etc.) should either not be in the pending > > request list, or explicitly not sent to alternate peers in case of failure > > of a connection, of course... Actually, I think most protocol messages > > (local to a connection) don't need the ack (delivery is guaranteed by the > > underlying transport, unless the connection is lost and then the message > > doesn't make sense any more), so don't need the R/A paradigm, and don't > > need to be saved to the pending request queue. I really need to propose > > some text along the lines of that separation of protocol and > applications... > >actually, a request without the 'P' bit set doesn't get added to the pending >message list. Shouldn't indeed, but that's not what the draft says :-( > > - in your description of the peer table, it looks too much like you only > > have one default realm and a set of peers (as would be the case on most > > NASes). There might be multiple different primary/backup peers for > > different realms, and a given peer might serve multiple realms and have > > different roles (primary/backup/etc.) for each realm. I think this > > information belongs in the routing table rather than in the peer table. > >hmmm... they actually belong in both, but I am not sure how to put that down >in ASCII. The basic issue is that for each realm, you want a >primary/secondary, >but the actual relationship is: > > > /------- Peer Entry (Primary) > Route Table Entry +----- > \------- Peer Entry (Secondary) > >So, my thoughts is that a route table points to a set of peer entries. Each >peer entry is marked with its role, and not the route table. Of course, an >intermediate "shim" may be required between the route table and the peer >entry, but this makes implementations a tad more complex. I hard started to write "belongs in the routing table (or rather in the peer sub-table associated with each routing table entry)", but that looked a bit complex indeed. I see two ways of describing this: 1. each entry in the routing table has a realm, an application, a priority, an action, and a peer, given that multiple entries can have the same realm and/or application. 2. an entry in the routing table has a realm, an application, an action, and a pointer to a subtable. The said subtable has priorities and pointers to the actual peers. Now, that solves the requirements of data, but not what should be done with that, i.e. when should a connection actually be established or torn down... I start to see doubly-linked lists :-( > > - the concept of "questionable" or "suspect" peers with a reliable > > transport underneath is quite intriguing to me? > >I am open to suggestions, but that's all I could think of at that time. I >am certain you know what I mean, right? I have a rough idea, though depending on the relationship between the watchdog timer and whatever timers the underlying protocol uses might be interesting. > > - for all the stuff that is in the transport draft: I had understood that > > draft was actually just recommendations about what should be present in > AAA > > protocols (and specifically Diameter), but that the AAA protocol > definition > > was to include whatever is necessary to meet these recommandations? > >yes, but I believe that Bernard didn't necessarily want to dup unnecessarily. >However, if you feel strongly that we can put a summary of what's in the >transport draft (and perhaps reference the transport draft), then that would >be acceptable to me. The transport draft should at least be referenced if there is stuff in there that is a MUST for Diameter implementations :-) Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Mon Jun 25 10:43:33 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16849 for ; Mon, 25 Jun 2001 10:43:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 04085912F4; Mon, 25 Jun 2001 10:39:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1C8D5912E3; Mon, 25 Jun 2001 10:38:05 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6D30D912E9 for ; Mon, 25 Jun 2001 10:37:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 617EA5DDD3; Mon, 25 Jun 2001 10:38:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by segue.merit.edu (Postfix) with ESMTP id B89DF5DDCD for ; Mon, 25 Jun 2001 10:38:55 -0400 (EDT) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id QAA07575; Mon, 25 Jun 2001 16:38:11 +0200 (MET DST) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id QAA25160; Mon, 25 Jun 2001 16:38:06 +0200 (MET DST) Received: by MCHH246E with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 16:38:06 +0200 Message-ID: From: Tuexen Michael To: "'jaakko.rajaniemi@nokia.com'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Securing Diameter Messages Date: Mon, 25 Jun 2001 16:37:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Dear all, just to let you know: an ID describing the use of TLS on top of SCTP has been submitted to the TSVWG last Friday. Best regards Michael Michael Tuexen Tel.: +49 89 722 47210 Siemens AG Fax: +49 89 722 48212 ICN WN CS SE 5 E-mail: Michael.Tuexen@icn.siemens.de > -----Original Message----- > From: jaakko.rajaniemi@nokia.com [SMTP:jaakko.rajaniemi@nokia.com] > Sent: Monday, June 25, 2001 4:34 PM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Securing Diameter Messages > > Hi, > > I have a question regarding the section 2.2, "Securing Diameter Messages" of > the base-06, which says that: > > "Diameter clients, such as Network Access Servers (NASes) and Foreign Agents > MUST support IP Security [37], and MAY support TLS [38]. Diameter servers > MUST support TLS, but the administrator MAY opt to configure IPSec instead > of using TLS. Operating the Diameter protocol without any security mechanism > is not recommended." > > Is it defined on purpose like this? To me it does not sound very rational to > mandate clients to support IPsec and servers to support TLS. Mandating one > protocol, e.g. IPsec if acceptable for everyone, would be reasonable. Also I > think that some text may be needed to clarify the Diameter agents and their > required support. > > I understood that there have been some concerns raised, probably in the May > interim meeting, about the interoperability of SCTP with IPsec and TLS which > may need to be taken into account in here. > > Br, Jaakko > > PS. Sorry if this should have been submitted as an issue. I can do that if > it is needed. From owner-aaa-wg@merit.edu Mon Jun 25 10:47:23 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16929 for ; Mon, 25 Jun 2001 10:47:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E5939912E4; Mon, 25 Jun 2001 10:46:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A8C6891307; Mon, 25 Jun 2001 10:46:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5B8E1912E4 for ; Mon, 25 Jun 2001 10:46:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4D2A95DDCD; Mon, 25 Jun 2001 10:47:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59]) by segue.merit.edu (Postfix) with SMTP id C73A35DDA8 for ; Mon, 25 Jun 2001 10:47:15 -0400 (EDT) Received: from s152.dhcp212-137.cybercable.fr (HELO jc.yahoo.com) (212.198.137.152) by smtp.mail.vip.sc5.yahoo.com with SMTP; 25 Jun 2001 14:46:30 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010625164147.00bdad20@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 25 Jun 2001 16:44:32 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 81: Route-Record change Cc: Barney Wolff , aaa-wg@merit.edu In-Reply-To: <20010625065551.I14828@charizard.diameter.org> References: <4.3.2.7.2.20010623120351.00c0e2f0@pop.mail.yahoo.com> <20010622112638.S14828@charizard.diameter.org> <20010622112638.S14828@charizard.diameter.org> <20010622151455.A23431@tp.databus.com> <4.3.2.7.2.20010623120351.00c0e2f0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 15:55 25/06/01, Pat Calhoun wrote: >so you compare what a peer had advertised with the Route-Record AVPs in >a message, effectively looking for loops for the peer? No, you compare against your own identity, but insert what the peer advertised in a Route-Record AVP. [btw, order of the two above is dependent on whether you allow connections to yourself or not: if you do, then you need to insert then compare; if you don't, it doesn't matter] Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Mon Jun 25 10:47:42 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16953 for ; Mon, 25 Jun 2001 10:47:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6FA5391307; Mon, 25 Jun 2001 10:47:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 40F4A91302; Mon, 25 Jun 2001 10:47:27 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 34B78912E7 for ; Mon, 25 Jun 2001 10:47:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 29CAA5DDCD; Mon, 25 Jun 2001 10:48:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id C77D45DDA8 for ; Mon, 25 Jun 2001 10:48:22 -0400 (EDT) Received: (qmail 12527 invoked by uid 500); 25 Jun 2001 14:36:25 -0000 Date: Mon, 25 Jun 2001 07:36:25 -0700 From: Pat Calhoun To: jaakko.rajaniemi@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Securing Diameter Messages Message-ID: <20010625073625.M14828@charizard.diameter.org> Mail-Followup-To: jaakko.rajaniemi@nokia.com, aaa-wg@merit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jaakko.rajaniemi@nokia.com on Mon, Jun 25, 2001 at 05:33:49PM +0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Jun 25, 2001 at 05:33:49PM +0300, jaakko.rajaniemi@nokia.com wrote: > I have a question regarding the section 2.2, "Securing Diameter Messages" of > the base-06, which says that: > > "Diameter clients, such as Network Access Servers (NASes) and Foreign Agents > MUST support IP Security [37], and MAY support TLS [38]. Diameter servers > MUST support TLS, but the administrator MAY opt to configure IPSec instead > of using TLS. Operating the Diameter protocol without any security mechanism > is not recommended." > > Is it defined on purpose like this? To me it does not sound very rational to > mandate clients to support IPsec and servers to support TLS. Mandating one > protocol, e.g. IPsec if acceptable for everyone, would be reasonable. Also I > think that some text may be needed to clarify the Diameter agents and their > required support. both are supported for a reason. TLS provides validation of credentials at the app layer, which many folks thought they would need. IPSec doesn't allow an application to know that a message was secured, unless some interface to the policy manager exists. IPSec doesn't work through firewalls, which was a concern. However, IPSec is much more prevalent on access devices than is TLS, and therefore cannot be ignored. So we felt that both should be supported. > > I understood that there have been some concerns raised, probably in the May > interim meeting, about the interoperability of SCTP with IPsec and TLS which > may need to be taken into account in here. right and a group of folks will be submitting the SCTP/TLS extensions in the next week or so. PatC From owner-aaa-wg@merit.edu Mon Jun 25 13:49:49 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22447 for ; Mon, 25 Jun 2001 13:49:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F3D2A91238; Mon, 25 Jun 2001 13:49:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C3D7691239; Mon, 25 Jun 2001 13:49:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BB82291238 for ; Mon, 25 Jun 2001 13:49:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EA7FE5DDF7; Mon, 25 Jun 2001 13:50:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id 661AD5DDF9 for ; Mon, 25 Jun 2001 13:50:42 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id NAA13069; Mon, 25 Jun 2001 13:40:12 -0400 (EDT) Message-Id: <4.1.20010625112354.01d2a4b0@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 25 Jun 2001 13:27:35 -0400 To: Pat Calhoun From: Paul Funk Subject: Re: [AAA-WG]: Issue 83: Routing/forwarding clarifications Cc: aaa-wg@merit.edu In-Reply-To: <20010625065413.H14828@charizard.diameter.org> References: <4.1.20010624172842.01d27250@cairo.funk.com> <20010622110552.R14828@charizard.diameter.org> <4.1.20010624172842.01d27250@cairo.funk.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-wg@merit.edu Precedence: bulk Pat, At 06:54 AM 6/25/01 -0700, Pat Calhoun wrote: >On Sun, Jun 24, 2001 at 06:26:08PM -0400, Paul Funk wrote: >> To handle the entire watchdog algorithm in the state machine would >> lead to a lot of complexity. Instead, what if watchdogs were removed >> from the state machine and the "Transport Failure Detection" section were >> expanded to more fully describe the algorithm and when the connection >> is deemed suspect, how it can redeem itself, etc.? > >I had tried to make the changes to the state machine, but without relying on >a counter in a control block, it makes for a rather nasty, and lengthy, >change in the state machine. So, I agree that some text should be added >somewhere else. However, it may be useful to add a single "suspect" state >in the SM, and have text, as you state, that describes the counter. Since watchdog functionality doesn't affect whether a connection is open or closed, it really can be handled outside the peer state machine. All watchdog activities occur in the Open state, similar to application message handling. I think that we need to decide how specific we want to be in describing watchdog functionality. At the low end, we can simply say that a node may use DWR for early detection of failed or congested connections, must use jitter, must respond to DWR with DWA, but otherwise leave the algorithm to the implementation. At the high end, we could provide a separate watchdog state machine or pseudo-code, timer definitions, etc., to try to specify exact behavior. I favor the low end approach, leaving it up to implementations to determine when a connection is suspect. After all, exact adherence to a specific algorithm is not required for interoperability (as in the peer state machine). I also would favor reduction of the proposed "6.1 Peer Connections" section to something more simple. None of the elaborate tables and statuses and transitions affect interoperability. All that really needs to be stated is that a node need not connect to everyone it knows all at once, but may want to manage connections. For example, it may want to connect to only a subset of peers in a realm, take down unused connections, and connect to additional peers when existing connections are deemed suspect. Paul Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-wg@merit.edu Mon Jun 25 13:59:57 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22726 for ; Mon, 25 Jun 2001 13:59:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 54FAB91239; Mon, 25 Jun 2001 13:59:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2D0F39123B; Mon, 25 Jun 2001 13:59:59 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 107DA91239 for ; Mon, 25 Jun 2001 13:59:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 31E8B5DDF9; Mon, 25 Jun 2001 14:00:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from web10401.mail.yahoo.com (web10401.mail.yahoo.com [216.136.130.93]) by segue.merit.edu (Postfix) with SMTP id EA3AB5DDE9 for ; Mon, 25 Jun 2001 14:00:57 -0400 (EDT) Message-ID: <20010625180013.21443.qmail@web10401.mail.yahoo.com> Received: from [47.82.25.211] by web10401.mail.yahoo.com; Mon, 25 Jun 2001 11:00:13 PDT Date: Mon, 25 Jun 2001 11:00:13 -0700 (PDT) From: Mark Llacuna Subject: [AAA-WG]: Pre-posting query To: aaa-wg@merit.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi everyone, I would like to ask some RADIUS interoperability and compliance questions with rfc 2865/2866, but I'm not sure if this is the right place to do it. Could somebody please point me to the right mailing list or let me know if this is the correct one? Thanks! Mark __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-aaa-wg@merit.edu Mon Jun 25 15:14:08 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24514 for ; Mon, 25 Jun 2001 15:14:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E0FD8912EC; Mon, 25 Jun 2001 15:07:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F3F0891332; Mon, 25 Jun 2001 15:04:31 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1376291330 for ; Mon, 25 Jun 2001 14:59:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 56E5B5DE15; Mon, 25 Jun 2001 15:00:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 678185DDFA for ; Mon, 25 Jun 2001 15:00:47 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f5PJ0LI21573 for ; Mon, 25 Jun 2001 22:00:21 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 25 Jun 2001 22:00:03 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Mon, 25 Jun 2001 22:00:03 +0300 Message-ID: From: jaakko.rajaniemi@nokia.com To: aaa-wg@merit.edu Subject: [AAA-WG]: Some editorials on Base-06 Date: Mon, 25 Jun 2001 21:59:56 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, Mainly some editorial nits related to the Base-06: In the section 1.3, "Terminology", Session description, the last sentence "devices serving the same user." should be removed? In the section 2.5.3, "Redirector Agents", the 4th paragrapth, DRL instead of DLR. In the section 9.1.4, "Transient Failures", the error DIAMETER_UNSUPPORTED_VERSION 5013 describes that: "This error is returned when a CEA message is received, and the Diameter message is unsupported." Should this be instead "This error is returned when a CEA message is received, and the Diameter version is unsupported."? In this case the version field of the CEA message could indicate the highest Diameter base protocol version supported by the node. If this is not acceptable for the receiving node it terminates the connection. In the section 10.0, "Diameter User Sessions", 3rd paragraph, it says that "Note that the Authorization-Lifetime AVP implies how long the Diameter server is willing to pay for the services rendered, therefore a Diameter client SHOULD NOT expect payment for services rendered past the session expiration time." Should this be instead "...a Diameter client SHOULD NOT expect payment for services rendered past the Authorization-Lifetime expiration."? In the section 10.1, "Authorization Session State Machine", the state machine description, should SKR/SKA be replaced by Abort-Session-Request/Answer (ASR/ASA)? In the section 10.11, "Termination-Cause AVP", The error DIAMETER_ADMINISTRATIVE 4 describes that "The user was not granted access, or was disconnected, due to administrative reasons, such as the receipt of a Session-Kill-Request message." Session-Kill-Request should be replace by the Abort-Session-Request? Br, Jaakko From owner-aaa-wg@merit.edu Mon Jun 25 16:49:03 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26645 for ; Mon, 25 Jun 2001 16:49:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 79B3391242; Mon, 25 Jun 2001 16:49:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E0BA391243; Mon, 25 Jun 2001 16:49:00 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BC37891242 for ; Mon, 25 Jun 2001 16:48:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2248B5DDE9; Mon, 25 Jun 2001 16:50:00 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (c000-h001.c000.snv.cp.net [209.228.32.65]) by segue.merit.edu (Postfix) with SMTP id 79DDB5DDDA for ; Mon, 25 Jun 2001 16:49:59 -0400 (EDT) Received: (cpmta 3988 invoked from network); 25 Jun 2001 13:49:14 -0700 Received: from h121s86a16n47.user.nortelnetworks.com (HELO mitton.mitton.com) (47.16.86.121) by smtp.mitton.com (209.228.32.65) with SMTP; 25 Jun 2001 13:49:14 -0700 X-Sent: 25 Jun 2001 20:49:14 GMT Message-Id: <4.3.2.7.2.20010625163221.00b62f00@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 25 Jun 2001 16:50:20 -0400 To: Mark Llacuna , aaa-wg@merit.edu From: David Mitton Subject: Re: [AAA-WG]: Pre-posting query In-Reply-To: <20010625180013.21443.qmail@web10401.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 6/25/01 11:00 AM -0700, Mark Llacuna wrote: >Hi everyone, > >I would like to ask some RADIUS interoperability and >compliance questions with rfc 2865/2866, but I'm not >sure if this is the right place to do it. Could >somebody please point me to the right mailing list or >let me know if this is the correct one? > >Thanks! > >Mark Mark, this is not the right place. Unfortunately, I don't know of a good place to send you ietf-radius@livingston.com still worked as of 13 Jan 2001 Don't know if anyone is still listening. Dave. ---------------------------------------------------- David Mitton 978-288-4570 Advisor, Nortel Networks david@mitton.com or dmitton@nortelnetworks.com From owner-aaa-wg@merit.edu Mon Jun 25 17:08:29 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27118 for ; Mon, 25 Jun 2001 17:08:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E247C91245; Mon, 25 Jun 2001 17:08:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B21D991246; Mon, 25 Jun 2001 17:08:29 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1E64191245 for ; Mon, 25 Jun 2001 17:08:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 94A355DDF2; Mon, 25 Jun 2001 17:09:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 11D2A5DDE9 for ; Mon, 25 Jun 2001 17:09:27 -0400 (EDT) Received: from gwzpc (sjc-vpn-306.cisco.com [10.21.65.50]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id OAA25641; Mon, 25 Jun 2001 14:08:42 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Mark Llacuna" , Subject: RE: [AAA-WG]: Pre-posting query Date: Mon, 25 Jun 2001 14:08:32 -0700 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <20010625180013.21443.qmail@web10401.mail.yahoo.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Hi everyone, > > I would like to ask some RADIUS interoperability and > compliance questions with rfc 2865/2866, but I'm not > sure if this is the right place to do it. You can try ietf-radius@livingston.com (I think you have to join the list in order to post) but I'm not sure you'll get any answers. If they are RFC-related questions, you can always send email to the authors. > Could > somebody please point me to the right mailing list or > let me know if this is the correct one? > > Thanks! > > Mark > > > > __________________________________________________ > Do You Yahoo!? > Get personalized email addresses from Yahoo! Mail > http://personal.mail.yahoo.com/ > From owner-aaa-wg@merit.edu Mon Jun 25 20:15:46 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00489 for ; Mon, 25 Jun 2001 20:15:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 50BC391254; Mon, 25 Jun 2001 20:15:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1DFA591255; Mon, 25 Jun 2001 20:15:25 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 30F6491254 for ; Mon, 25 Jun 2001 20:15:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DEF485DDBC; Mon, 25 Jun 2001 20:16:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 8C5A45DD9E for ; Mon, 25 Jun 2001 20:16:21 -0400 (EDT) Received: (qmail 25047 invoked by uid 500); 26 Jun 2001 00:04:22 -0000 Date: Mon, 25 Jun 2001 17:04:22 -0700 From: Pat Calhoun To: Paul Funk Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 83: Routing/forwarding clarifications Message-ID: <20010625170422.E22915@charizard.diameter.org> Mail-Followup-To: Paul Funk , Pat Calhoun , aaa-wg@merit.edu References: <4.1.20010624172842.01d27250@cairo.funk.com> <20010622110552.R14828@charizard.diameter.org> <4.1.20010624172842.01d27250@cairo.funk.com> <20010625065413.H14828@charizard.diameter.org> <4.1.20010625112354.01d2a4b0@cairo.funk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.1.20010625112354.01d2a4b0@cairo.funk.com>; from paul@funk.com on Mon, Jun 25, 2001 at 01:27:35PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Jun 25, 2001 at 01:27:35PM -0400, Paul Funk wrote: > Since watchdog functionality doesn't affect whether a connection is open > or closed, it really can be handled outside the peer state machine. All > watchdog activities occur in the Open state, similar to application message > handling. > > I think that we need to decide how specific we want to be in describing > watchdog functionality. > > At the low end, we can simply say that a node may use DWR for early > detection of failed or congested connections, must use jitter, must respond > to DWR with DWA, but otherwise leave the algorithm to the implementation. > > At the high end, we could provide a separate watchdog state machine or > pseudo-code, timer definitions, etc., to try to specify exact behavior. > > I favor the low end approach, leaving it up to implementations to determine > when a connection is suspect. After all, exact adherence to a specific > algorithm is not required for interoperability (as in the peer state machine). I also favor the low end approach. > > I also would favor reduction of the proposed "6.1 Peer Connections" section > to something more simple. None of the elaborate tables and statuses and > transitions affect interoperability. All that really needs to be stated is > that a > node need not connect to everyone it knows all at once, but may want to > manage connections. For example, it may want to connect to only a subset of > peers in a realm, take down unused connections, and connect to additional > peers when existing connections are deemed suspect. that works for me. I added the table because I thought it would be beneficial to the reader (and we seem to want to detail as much as possible), but cutting the section down is something I would also like. patC From owner-aaa-wg@merit.edu Tue Jun 26 09:58:28 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07097 for ; Tue, 26 Jun 2001 09:58:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EA80391261; Tue, 26 Jun 2001 09:58:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B62D191301; Tue, 26 Jun 2001 09:58:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8DA7791261 for ; Tue, 26 Jun 2001 09:58:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 50D775DDEE; Tue, 26 Jun 2001 09:59:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id E94EA5DDCF for ; Tue, 26 Jun 2001 09:59:32 -0400 (EDT) Received: (qmail 32119 invoked by uid 500); 26 Jun 2001 13:47:31 -0000 Date: Tue, 26 Jun 2001 06:47:31 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 83: Routing/forwarding clarifications Message-ID: <20010626064731.K22915@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <4.3.2.7.2.20010623193025.00bdd9e0@pop.mail.yahoo.com> <20010622110552.R14828@charizard.diameter.org> <4.3.2.7.2.20010623193025.00bdd9e0@pop.mail.yahoo.com> <20010625064926.G14828@charizard.diameter.org> <4.3.2.7.2.20010625162342.00b1d410@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010625162342.00b1d410@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Mon, Jun 25, 2001 at 04:34:05PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Jun 25, 2001 at 04:34:05PM +0200, Jacques Caron wrote: > At 15:49 25/06/01, Pat Calhoun wrote: > > > BTW, another sub-issue (a bit related to the other discussion I started > > > about separating more the protocol from the applications) is that protocol > > > messages (such as CER, DWR, etc.) should either not be in the pending > > > request list, or explicitly not sent to alternate peers in case of failure > > > of a connection, of course... Actually, I think most protocol messages > > > (local to a connection) don't need the ack (delivery is guaranteed by the > > > underlying transport, unless the connection is lost and then the message > > > doesn't make sense any more), so don't need the R/A paradigm, and don't > > > need to be saved to the pending request queue. I really need to propose > > > some text along the lines of that separation of protocol and > > applications... > > > >actually, a request without the 'P' bit set doesn't get added to the pending > >message list. > > Shouldn't indeed, but that's not what the draft says :-( ok, in the process of making this change, I no longer agree with my previous statement. I think that it is required to receive, and process, the -Answer. For watchdog messages, receiving, and processing the -Answer is the difference between thinking that a peer is up, or not. Furthermore, an implementation may be looking at the watchdog's RTT to determine whether a peer is in good standing or not. So, I disagree with this change, but agree that some text must be added stating that certain messages MUST NOT be sent to an alternate. I'll look into this, and figure out the best approach. PatC From owner-aaa-wg@merit.edu Tue Jun 26 10:41:18 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14309 for ; Tue, 26 Jun 2001 10:41:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2E7F591262; Tue, 26 Jun 2001 10:41:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F067E91303; Tue, 26 Jun 2001 10:41:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6F07691262 for ; Tue, 26 Jun 2001 10:41:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3C9B95DDF5; Tue, 26 Jun 2001 10:42:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 96F8D5DDEE for ; Tue, 26 Jun 2001 10:42:11 -0400 (EDT) Received: (qmail 432 invoked by uid 500); 26 Jun 2001 14:29:13 -0000 Date: Tue, 26 Jun 2001 07:29:13 -0700 From: Pat Calhoun To: Paul Funk , Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 83: Routing/forwarding clarifications Message-ID: <20010626072913.Q22915@charizard.diameter.org> Mail-Followup-To: Paul Funk , Pat Calhoun , aaa-wg@merit.edu References: <4.1.20010624172842.01d27250@cairo.funk.com> <20010622110552.R14828@charizard.diameter.org> <4.1.20010624172842.01d27250@cairo.funk.com> <20010625065413.H14828@charizard.diameter.org> <4.1.20010625112354.01d2a4b0@cairo.funk.com> <20010625170422.E22915@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010625170422.E22915@charizard.diameter.org>; from pcalhoun@diameter.org on Mon, Jun 25, 2001 at 05:04:22PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Jun 25, 2001 at 05:04:22PM -0700, Pat Calhoun wrote: > On Mon, Jun 25, 2001 at 01:27:35PM -0400, Paul Funk wrote: > > Since watchdog functionality doesn't affect whether a connection is open > > or closed, it really can be handled outside the peer state machine. All > > watchdog activities occur in the Open state, similar to application message > > handling. > > > > I think that we need to decide how specific we want to be in describing > > watchdog functionality. > > > > At the low end, we can simply say that a node may use DWR for early > > detection of failed or congested connections, must use jitter, must respond > > to DWR with DWA, but otherwise leave the algorithm to the implementation. > > > > At the high end, we could provide a separate watchdog state machine or > > pseudo-code, timer definitions, etc., to try to specify exact behavior. > > > > I favor the low end approach, leaving it up to implementations to determine > > when a connection is suspect. After all, exact adherence to a specific > > algorithm is not required for interoperability (as in the peer state machine). > > I also favor the low end approach. > > > > > I also would favor reduction of the proposed "6.1 Peer Connections" section > > to something more simple. None of the elaborate tables and statuses and > > transitions affect interoperability. All that really needs to be stated is > > that a > > node need not connect to everyone it knows all at once, but may want to > > manage connections. For example, it may want to connect to only a subset of > > peers in a realm, take down unused connections, and connect to additional > > peers when existing connections are deemed suspect. > > that works for me. I added the table because I thought it would be beneficial > to the reader (and we seem to want to detail as much as possible), but cutting > the section down is something I would also like. Paul, how about the following text: 5.1 Peer Connections Although a Diameter node may have many possible peers that it is able to communicate with, it may not be economical to have an established connection to all of them. At a minimum, a Diameter node SHOULD have an established connection with a primary and secondary peer, and MAY have additional connections, if it is deemed necessary. When a peer is deemed suspect, which could occur for various reasons, including not receiving a DWA within an alloted timeframe, no new requests should be forwarded to the peer, but failover procedures are not invoked. When an active peer is moved to this mode, additional connections SHOULD be established to ensure that the necessary number of active connections exists. There are two ways that a peer is removed from the suspect peer list: 1. The peer is no longer reachable, causing the transport connection to be shutdown. The peer is moved to the closed state. 2. Three watchdog messages are exchanged with accepted round trip times, and the connection to the peer is considered stabilized. Thanks, PatC From owner-aaa-wg@merit.edu Tue Jun 26 10:48:43 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15665 for ; Tue, 26 Jun 2001 10:48:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A992191304; Tue, 26 Jun 2001 10:48:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 76D3E91305; Tue, 26 Jun 2001 10:48:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4CAE291304 for ; Tue, 26 Jun 2001 10:48:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 342E75DDEE; Tue, 26 Jun 2001 10:49:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id B54365DDCF for ; Tue, 26 Jun 2001 10:49:45 -0400 (EDT) Received: (qmail 594 invoked by uid 500); 26 Jun 2001 14:37:44 -0000 Date: Tue, 26 Jun 2001 07:37:44 -0700 From: Pat Calhoun To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 83: Routing/forwarding clarifications Message-ID: <20010626073744.S22915@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <4.3.2.7.2.20010623193025.00bdd9e0@pop.mail.yahoo.com> <20010622110552.R14828@charizard.diameter.org> <4.3.2.7.2.20010623193025.00bdd9e0@pop.mail.yahoo.com> <20010625064926.G14828@charizard.diameter.org> <4.3.2.7.2.20010625162342.00b1d410@pop.mail.yahoo.com> <20010626064731.K22915@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010626064731.K22915@charizard.diameter.org>; from pcalhoun@diameter.org on Tue, Jun 26, 2001 at 06:47:31AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Jun 26, 2001 at 06:47:31AM -0700, Pat Calhoun wrote: > > >actually, a request without the 'P' bit set doesn't get added to the pending > > >message list. > > > > Shouldn't indeed, but that's not what the draft says :-( > > ok, in the process of making this change, I no longer agree with my previous > statement. I think that it is required to receive, and process, the -Answer. > For watchdog messages, receiving, and processing the -Answer is the difference > between thinking that a peer is up, or not. Furthermore, an implementation may > be looking at the watchdog's RTT to determine whether a peer is in good standing > or not. > > So, I disagree with this change, but agree that some text must be added stating > that certain messages MUST NOT be sent to an alternate. > > I'll look into this, and figure out the best approach. Jacques, looking at how to make this change, I believe that the best approach is simply to add text to the relevant command definitions. Specifically, there are only three messages that fall within this category, and they are CER, DPR and DWR. Here is an example of the change (see last sentence): 5.3.1 Capabilities-Exchange-Request The Capabilities-Exchange-Request (CER), indicated by the Command- Code set to 257 and the Command Flags' 'R' bit set, is sent to inform a peer that a reboot has occurred. Upon detection of a transport failure, this message MUST NOT be sent to an alternate peer. Thanks, PatC From owner-aaa-wg@merit.edu Tue Jun 26 10:51:59 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16218 for ; Tue, 26 Jun 2001 10:51:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B864B91305; Tue, 26 Jun 2001 10:51:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F99091306; Tue, 26 Jun 2001 10:51:56 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5989191305 for ; Tue, 26 Jun 2001 10:51:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3F5715DDCF; Tue, 26 Jun 2001 10:52:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id D8CD45DD8E for ; Tue, 26 Jun 2001 10:52:56 -0400 (EDT) Received: (qmail 632 invoked by uid 500); 26 Jun 2001 14:40:55 -0000 Date: Tue, 26 Jun 2001 07:40:55 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 83: Routing/forwarding clarifications Message-ID: <20010626074055.T22915@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <4.3.2.7.2.20010623193025.00bdd9e0@pop.mail.yahoo.com> <20010622110552.R14828@charizard.diameter.org> <4.3.2.7.2.20010623193025.00bdd9e0@pop.mail.yahoo.com> <20010625064926.G14828@charizard.diameter.org> <4.3.2.7.2.20010625162342.00b1d410@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010625162342.00b1d410@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Mon, Jun 25, 2001 at 04:34:05PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk > >hmmm... they actually belong in both, but I am not sure how to put that down > >in ASCII. The basic issue is that for each realm, you want a > >primary/secondary, > >but the actual relationship is: > > > > > > /------- Peer Entry (Primary) > > Route Table Entry +----- > > \------- Peer Entry (Secondary) > > > >So, my thoughts is that a route table points to a set of peer entries. Each > >peer entry is marked with its role, and not the route table. Of course, an > >intermediate "shim" may be required between the route table and the peer > >entry, but this makes implementations a tad more complex. > > I hard started to write "belongs in the routing table (or rather in the > peer sub-table associated with each routing table entry)", but that looked > a bit complex indeed. > > I see two ways of describing this: > 1. each entry in the routing table has a realm, an application, a priority, > an action, and a peer, given that multiple entries can have the same realm > and/or application. > > 2. an entry in the routing table has a realm, an application, an action, > and a pointer to a subtable. The said subtable has priorities and pointers > to the actual peers. > > Now, that solves the requirements of data, but not what should be done with > that, i.e. when should a connection actually be established or torn > down... I start to see doubly-linked lists :-( There is no way around doubly-linked lists in this case. How about if a routing table entry has a pointer to the primary peer entry, secondary peer entry, and then additional pointers for alternates. That eliminates the need for a "shim", and duplicate data structures. PatC From owner-aaa-wg@merit.edu Tue Jun 26 13:25:55 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28121 for ; Tue, 26 Jun 2001 13:25:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 588C19131F; Tue, 26 Jun 2001 13:25:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F160E9131C; Tue, 26 Jun 2001 13:25:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8E61191318 for ; Tue, 26 Jun 2001 13:25:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A96845DD9C; Tue, 26 Jun 2001 13:26:59 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id 41B665DD8E for ; Tue, 26 Jun 2001 13:26:59 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id NAA14978; Tue, 26 Jun 2001 13:16:30 -0400 (EDT) Message-Id: <4.1.20010626130310.01d44a10@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 26 Jun 2001 13:03:50 -0400 To: Pat Calhoun , aaa-wg@merit.edu From: Paul Funk Subject: Re: [AAA-WG]: Issue 83: Routing/forwarding clarifications In-Reply-To: <20010626072913.Q22915@charizard.diameter.org> References: <20010625170422.E22915@charizard.diameter.org> <4.1.20010624172842.01d27250@cairo.funk.com> <20010622110552.R14828@charizard.diameter.org> <4.1.20010624172842.01d27250@cairo.funk.com> <20010625065413.H14828@charizard.diameter.org> <4.1.20010625112354.01d2a4b0@cairo.funk.com> <20010625170422.E22915@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-wg@merit.edu Precedence: bulk Pat, That's much better. Paul At 07:29 AM 6/26/01 -0700, Pat Calhoun wrote: >On Mon, Jun 25, 2001 at 05:04:22PM -0700, Pat Calhoun wrote: >> On Mon, Jun 25, 2001 at 01:27:35PM -0400, Paul Funk wrote: >> > Since watchdog functionality doesn't affect whether a connection is open >> > or closed, it really can be handled outside the peer state machine. All >> > watchdog activities occur in the Open state, similar to application >message >> > handling. >> > >> > I think that we need to decide how specific we want to be in describing >> > watchdog functionality. >> > >> > At the low end, we can simply say that a node may use DWR for early >> > detection of failed or congested connections, must use jitter, must >respond >> > to DWR with DWA, but otherwise leave the algorithm to the implementation. >> > >> > At the high end, we could provide a separate watchdog state machine or >> > pseudo-code, timer definitions, etc., to try to specify exact behavior. >> > >> > I favor the low end approach, leaving it up to implementations to >determine >> > when a connection is suspect. After all, exact adherence to a specific >> > algorithm is not required for interoperability (as in the peer state >machine). >> >> I also favor the low end approach. >> >> > >> > I also would favor reduction of the proposed "6.1 Peer Connections" >section >> > to something more simple. None of the elaborate tables and statuses and >> > transitions affect interoperability. All that really needs to be stated is >> > that a >> > node need not connect to everyone it knows all at once, but may want to >> > manage connections. For example, it may want to connect to only a subset >of >> > peers in a realm, take down unused connections, and connect to additional >> > peers when existing connections are deemed suspect. >> >> that works for me. I added the table because I thought it would be beneficial >> to the reader (and we seem to want to detail as much as possible), but >cutting >> the section down is something I would also like. > >Paul, how about the following text: > >5.1 Peer Connections > > Although a Diameter node may have many possible peers that it is able > to communicate with, it may not be economical to have an established > connection to all of them. At a minimum, a Diameter node SHOULD have > an established connection with a primary and secondary peer, and MAY > have additional connections, if it is deemed necessary. > > When a peer is deemed suspect, which could occur for various reasons, > including not receiving a DWA within an alloted timeframe, no new > requests should be forwarded to the peer, but failover procedures are > not invoked. When an active peer is moved to this mode, additional > connections SHOULD be established to ensure that the necessary number > of active connections exists. > > There are two ways that a peer is removed from the suspect peer list: > 1. The peer is no longer reachable, causing the transport > connection to be shutdown. The peer is moved to the closed > state. > 2. Three watchdog messages are exchanged with accepted round trip > times, and the connection to the peer is considered stabilized. > >Thanks, > >PatC Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-wg@merit.edu Tue Jun 26 15:40:09 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07263 for ; Tue, 26 Jun 2001 15:40:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 532169132C; Tue, 26 Jun 2001 15:40:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1A38991330; Tue, 26 Jun 2001 15:40:10 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E037B9132C for ; Tue, 26 Jun 2001 15:40:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 316025DE55; Tue, 26 Jun 2001 15:41:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 938075DE52 for ; Tue, 26 Jun 2001 15:41:10 -0400 (EDT) Received: (qmail 4500 invoked by uid 500); 26 Jun 2001 19:29:08 -0000 Date: Tue, 26 Jun 2001 12:29:08 -0700 From: Pat Calhoun To: jaakko.rajaniemi@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Some editorials on Base-06 Message-ID: <20010626122907.Y22915@charizard.diameter.org> Mail-Followup-To: jaakko.rajaniemi@nokia.com, aaa-wg@merit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jaakko.rajaniemi@nokia.com on Mon, Jun 25, 2001 at 09:59:56PM +0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Jun 25, 2001 at 09:59:56PM +0300, jaakko.rajaniemi@nokia.com wrote: > Hi, > > Mainly some editorial nits related to the Base-06: ok, I will open an issue for these, accept them, and close it. This is purely for tracking purposes. > > In the section 1.3, "Terminology", Session description, the last sentence > "devices serving the same user." should be removed? correct. > > In the section 2.5.3, "Redirector Agents", the 4th paragrapth, DRL instead > of DLR. yes. > > In the section 9.1.4, "Transient Failures", the error > DIAMETER_UNSUPPORTED_VERSION 5013 describes that: "This error is > returned when a CEA message is received, and the Diameter message is > unsupported." Should this be instead "This error is returned when a CEA > message is received, and the Diameter version is unsupported."? In this case > the version field of the CEA message could indicate the highest Diameter > base protocol version supported by the node. If this is not acceptable for > the receiving node it terminates the connection. yes the description is wrong, but I feel uncomfortable with your suggestion since it implies that an implementation supports all previous versions. I think that an implementation could just try to re-connect, and send a CER with a different supported version number. > > In the section 10.0, "Diameter User Sessions", 3rd paragraph, it says that > "Note that the Authorization-Lifetime AVP implies how long the Diameter > server is willing to pay for the services rendered, therefore a Diameter > client SHOULD NOT expect payment for services rendered past the session > expiration time." Should this be instead "...a Diameter client SHOULD NOT > expect payment for services rendered past the Authorization-Lifetime > expiration."? correct. > > In the section 10.1, "Authorization Session State Machine", the state > machine description, should SKR/SKA be replaced by > Abort-Session-Request/Answer (ASR/ASA)? yup. > > In the section 10.11, "Termination-Cause AVP", The error > DIAMETER_ADMINISTRATIVE 4 describes that "The user was not granted > access, or was disconnected, due to administrative reasons, such as the > receipt of a Session-Kill-Request message." Session-Kill-Request should be > replace by the Abort-Session-Request? Another one I missed :( Thanks, PatC From owner-aaa-wg@merit.edu Tue Jun 26 15:49:21 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08141 for ; Tue, 26 Jun 2001 15:49:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EC6C491334; Tue, 26 Jun 2001 15:49:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C1CD491338; Tue, 26 Jun 2001 15:49:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 56AE391334 for ; Tue, 26 Jun 2001 15:49:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A00115DE58; Tue, 26 Jun 2001 15:50:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 15E865DE19 for ; Tue, 26 Jun 2001 15:50:22 -0400 (EDT) Received: (qmail 4533 invoked by uid 500); 26 Jun 2001 19:38:19 -0000 Date: Tue, 26 Jun 2001 12:38:19 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: [Issue] Some editorials on Base-06 Message-ID: <20010626123819.Z22915@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Just to be formal, and be able to track changes. I am opening up this issue, but accepted all of the issues, and am closing it right away. Thanks, PatC ---- Issue 92: Some editorials on Base-06 Submitter name: Jaakko Rajaniemi Submitter email address: jaakko.rajaniemi@nokia.com Date first submitted: 26-Jun-2001 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg01476.html Document: base-06 Comment type: E Priority: S Section: Rationale/Explanation of issue: Editorial changes required in base protocol specification Requested change: > In the section 1.3, "Terminology", Session description, the last sentence > "devices serving the same user." should be removed? correct. > > In the section 2.5.3, "Redirector Agents", the 4th paragrapth, DRL instead > of DLR. yes. > > In the section 9.1.4, "Transient Failures", the error > DIAMETER_UNSUPPORTED_VERSION 5013 describes that: "This error is > returned when a CEA message is received, and the Diameter message is > unsupported." Should this be instead "This error is returned when a CEA > message is received, and the Diameter version is unsupported."? In this case > the version field of the CEA message could indicate the highest Diameter > base protocol version supported by the node. If this is not acceptable for > the receiving node it terminates the connection. yes the description is wrong, but I feel uncomfortable with your suggestion since it implies that an implementation supports all previous versions. I think that an implementation could just try to re-connect, and send a CER with a different supported version number. > > In the section 10.0, "Diameter User Sessions", 3rd paragraph, it says that > "Note that the Authorization-Lifetime AVP implies how long the Diameter > server is willing to pay for the services rendered, therefore a Diameter > client SHOULD NOT expect payment for services rendered past the session > expiration time." Should this be instead "...a Diameter client SHOULD NOT > expect payment for services rendered past the Authorization-Lifetime > expiration."? correct. > > In the section 10.1, "Authorization Session State Machine", the state > machine description, should SKR/SKA be replaced by > Abort-Session-Request/Answer (ASR/ASA)? yup. > > In the section 10.11, "Termination-Cause AVP", The error > DIAMETER_ADMINISTRATIVE 4 describes that "The user was not granted > access, or was disconnected, due to administrative reasons, such as the > receipt of a Session-Kill-Request message." Session-Kill-Request should be > replace by the Abort-Session-Request? Another one I missed :( From owner-aaa-wg@merit.edu Tue Jun 26 17:17:43 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19811 for ; Tue, 26 Jun 2001 17:17:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7290991345; Tue, 26 Jun 2001 17:15:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3FA499134C; Tue, 26 Jun 2001 17:15:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2198691345 for ; Tue, 26 Jun 2001 17:15:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 797FD5DE55; Tue, 26 Jun 2001 17:16:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id D9E9E5DE52 for ; Tue, 26 Jun 2001 17:16:07 -0400 (EDT) Received: (qmail 4813 invoked by uid 500); 26 Jun 2001 21:04:05 -0000 Date: Tue, 26 Jun 2001 14:04:05 -0700 From: Pat Calhoun To: "Martin Julien (ECE)" Cc: "'pcalhoun@diameter.org'" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Issue 90: MIP-Previous-XXX AVP Message-ID: <20010626140405.H22915@charizard.diameter.org> Mail-Followup-To: "Martin Julien (ECE)" , "'pcalhoun@diameter.org'" , "'aaa-wg@merit.edu'" References: <577066326047D41180AC00508B955DDA04D1A9C7@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <577066326047D41180AC00508B955DDA04D1A9C7@eestqnt104.es.eu.ericsson.se>; from Martin.Julien@ece.ericsson.se on Mon, Jun 25, 2001 at 10:05:27AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk I cannot really justify this AVP, and am willing to eliminate it. Any objections? PatC On Mon, Jun 25, 2001 at 10:05:27AM +0200, Martin Julien (ECE) wrote: > Submitter name: Martin Julien > Submitter email address: martin.julien@ericsson.com > Date first submitted: 25-Jun-2001 > Reference: http://www.merit.edu/mail.archives/aaa-wg/msg01446.html > Document: mobileip-06 > Comment type: T > Priority: 2 > Section: 2.1, 4.5, 4.6, > Rationale/Explanation of issue: > > Requested change: > > > > 3) Section 2.1, I don't think the paragraph starting with > > > "If the MIP-Previous-FA-Host AVP...." is still applicable > > > in this draft. Can that AVP be useful at all in the current > > > solution proposed in the draft? At least, I don't see how > > > we could make use of that MIP-Previous-FA-Host AVP in the > > > AAAH and the AAAF. Is it for future considerations? > > > > I am not sure. Others? > > > > Thomas Panagiotis commented: "MIP/Fast interdomain handoffs?" > > I agree that it could be useful for that, but in the actual draft, > that is not supported, AFAIK. So, I think it should either be removed, > since there is no clear defined use for it at this point, or be > kept with some kind of explanations how it can be useful in the > AAAF or AAAH. > > Based on the draft, the AAAF and AAAH already have > access to the User-Name, the MIP-Home-Agent-Address and > MIP-Mobile-Node-Address, which I think is enough to get access to > the stored MN-FA and FA-HA keys, if needed in the AAAF. Of course > that it means that the AAAF needs to be stateful, but is there any > other way of handling this? > > One way we could be using the MIP-Previous-FA-Host AVP, > would possibly be to make the AAAF stateless, which could possibly invoke > the Session-Abort message towards the Previous-FA. Would it be a > valid interpretation of that AVP or not? Does it make any sense? > > > > Furthermore, I thought we had agreed that the User-Name > > > was not enough for the purpose of retrieving keys in the AAAF, > > > but would rather require the User-Name, the Home-Address and > > > the Home-Agent? > > > > That rings a bell. I may have missed that one. > > > > > 4) Section 2.1, in the message format, I am questionning the > > > necessity of the MIP-Previous-FA-Host and MIP-Previous-FA-Addr AVPs. > > > > right, again, not sure. Perhaps this one should actually be a separate > > issue from the editorial ones. > > > > > > PatC > > > > From owner-aaa-wg@merit.edu Tue Jun 26 17:29:45 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21468 for ; Tue, 26 Jun 2001 17:29:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7EA439133E; Tue, 26 Jun 2001 16:57:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 31AE591341; Tue, 26 Jun 2001 16:57:02 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 29F409133E for ; Tue, 26 Jun 2001 16:56:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 889CB5DE55; Tue, 26 Jun 2001 16:57:59 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id B932A5DE05 for ; Tue, 26 Jun 2001 16:57:58 -0400 (EDT) Received: (qmail 4743 invoked by uid 500); 26 Jun 2001 20:45:56 -0000 Date: Tue, 26 Jun 2001 13:45:56 -0700 From: Pat Calhoun To: "Martin Julien (ECE)" Cc: "'pcalhoun@diameter.org'" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Issue 91: MIP SPI Message-ID: <20010626134555.D22915@charizard.diameter.org> Mail-Followup-To: "Martin Julien (ECE)" , "'pcalhoun@diameter.org'" , "'aaa-wg@merit.edu'" References: <577066326047D41180AC00508B955DDA04D1A9C8@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <577066326047D41180AC00508B955DDA04D1A9C8@eestqnt104.es.eu.ericsson.se>; from Martin.Julien@ece.ericsson.se on Mon, Jun 25, 2001 at 11:10:13AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Jun 25, 2001 at 11:10:13AM +0200, Martin Julien (ECE) wrote: > Submitter name: Martin Julien > Submitter email address: martin.julien@ericsson.com > Date first submitted: 25-Jun-2001 > Reference: http://www.merit.edu/mail.archives/aaa-wg/msg01446.html > Document: mobileip-06 > Comment type: T > Priority: S > Section: > Rationale/Explanation of issue: > > Requested change: > > > > 18) Section 6.2.7, should the SHA-1 algorithm be also added, as in the > > > aaa-key-06 draft? BTW, would it be better that the values assigned to > > > those algorithms match between the 2 drafts? The last comment also > > > applies to the Replay-Mode. > > > > yes, but it really don't matter if there isn't a match. If you think it > > would be useful, include it in your issue. > > Not really, it was only a comment. The thing is that since the values in > the Diameter MIP-06 draft are based on the ones defined in the other > document, I thought it would be better to keep the values consistent, > but of course, it does not have to be like this, strictly speaking. hmmmm... I should have read this closer :( SHA-1 is used to encrypt the session keys, as defined in the aaa-key-06 draft. The transforms listed in section 6.2.7 are used to generate the authenticator portion of the relevant authentication extension. So, no change is required. Sorry I missed that one when I first responded :( btw, -04 (I believe) was changed considerably, and I believe that your confusion is that you didn't catch all of the changes that occured from -03. > > > > 11) If there is a problem in the HA or FA with the SPI generated by > > > the AAAH or AAAF, how could that be reported? > > > > reported by whom? The HA? Or one of the AAA servers? > > > > > 16) Whenever no MIP-*-Preferred-SPI AVP is included in the AMR, can we > > > assume that the SPI generated by the AAAH or AAAF can be completely > > > random or not? Why can't the HA decide the SPI itself? > > > > There's no reason why, really :( > > I'm still not quite sure to get the complete picture of how the SPI should > be > handled in the AAA servers. Are we expecting the AAA servers to use the > standard 0-255 SPI defined by IANA?, or are the AAA servers expected to > handle to concept of SA, which normally contains and defines their own > SPI values? yes, the AAA creates the SPI values used for an SA. The SPI number provided in the *Preferred-SPI AVPs are recommendations from the Diameter agents on what values they'd like to see, to minimize the possibility of conflict. However, the SPI address space is 32bits long, and therefore clashes should be minimal. To address your other question, no we do not touch the reserved SPIs defined by IANA. > > As defined in RFC 2002 (MIP): > > Mobility Security Association > A collection of security contexts, between a pair > of nodes, which may be applied to Mobile IP protocol > messages exchanged between them. Each context indicates > an authentication algorithm and mode (Section 5.1), a > secret (a shared key, or appropriate public/private > key pair), and a style of replay protection in use > (Section 5.6). > > Security Parameter Index (SPI) > An index identifying a security context between a pair > of nodes among the contexts available in the Mobility > Security Association. SPI values 0 through 255 are > reserved and MUST NOT be used in any Mobility Security > Association. > > I believe that MIP is using the standard CHAP_SPI, when using RADIUS, right? CHAP_SPI is never used in key generation. That is for authentication of the MN-AAA Auth Ext. > Should the Diameter server follow the same path or not? I guess not, since > the key AVPs would not contain the MIP-SPI, the algo and the Replay-Mode, > right? The SPI generated for the key, which points to the algo and the replay mode, is completely separate from authenticator computation, so I do not understand the question. > > The thing is > that if Diameter needs to support the concept of SA, then it seems to > be difficult for the AAA server to select an SPI on behalf of the MN, the HA > and the FA. but the MN provides its preferred SPI in the Generalized Key Ext, and the FA provides its own in the MIP-FA-Preferred-SPI AVP. The Home Agent is the only sticky point, and if the AAAH picks one that causes a conflict on the HA, an error would be returned, which could include a new SPI, I suppose. The AAAH would then try again. I suppose this is what needs to be documented. > Of course, the AAA can count on the Preferred-SPI from the FA > and the MN, in which case the AAA simply agrees with the value. However, > if there is no Preferred-SPI AVPs in the AMR, then the AAAH needs to > generate > them, at the risk that they might already be used in the SA defined between > the MN and the HA, or between the HA and the FA, or between the FA and the > MN. > I think that it makes more sense for the HA to select the required SPI > between > the HA-MN and HA-FA, if no Preferred-SPI is included in the AMR. No, IMHO, if not Preferred-SPI is present, then no key is generated. So, perhaps some associated text in the Feature-Vector is needed? > > I guess that the MIP-Foreign-Agent-Host AVP could be useful for creating > the SPI within the SA defined between the HA and the FA. correct. > > > > Also, when a MIP-*-Preferred-SPI AVP is included in the AMR, I guess > > > that the FA has chosen a value that what not already already by any > > > of the SAs, right? The thing is that it might not know the HA yet, > > > i.e. the SA. > > > > > > 19) Section 6.1, could you please explain to me what "The Mobile IP key > > > described in [15] refers to the AAA SPI, which MUST be set to the value > > > the AAAH shares with the Mobile Node." Are we talking about a > > > pre-configured shared SPI, or a secret key? Can it dynamically change > > > or not? It is not clear to me how the AAA SPI can help in creating the > > > FA or HA Security Information. Could you please tell me more? > > > > I'd love to explain it, but that would require that I first > > understand it :( > > > > I believe that what I had originally intended to state here is that the > > values created are used in a particular field of the MIP AAA key in [15]. > > This needs some major cleaning up. I think what I meant to say was (proposed text): " The AVPs described in this section contain the values inserted in the Key Material field of the extensions defined in [15]. The Key Lifetime field is set to the same value as the one found in the Authorization-Lifetime AVP." PatC From owner-aaa-wg@merit.edu Tue Jun 26 18:26:42 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29931 for ; Tue, 26 Jun 2001 18:26:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AB6039134D; Tue, 26 Jun 2001 18:26:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 745E29134E; Tue, 26 Jun 2001 18:26:39 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 486D99134D for ; Tue, 26 Jun 2001 18:26:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B69FC5DE05; Tue, 26 Jun 2001 18:27:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 5CDD95DDB4 for ; Tue, 26 Jun 2001 18:27:40 -0400 (EDT) Received: (qmail 5876 invoked by uid 500); 26 Jun 2001 22:15:37 -0000 Date: Tue, 26 Jun 2001 15:15:37 -0700 From: Pat Calhoun To: "Martin Julien (ECE)" , "'pcalhoun@diameter.org'" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Issue 91: MIP SPI Message-ID: <20010626151537.J22915@charizard.diameter.org> Mail-Followup-To: "Martin Julien (ECE)" , "'pcalhoun@diameter.org'" , "'aaa-wg@merit.edu'" References: <577066326047D41180AC00508B955DDA04D1A9C8@eestqnt104.es.eu.ericsson.se> <20010626134555.D22915@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010626134555.D22915@charizard.diameter.org>; from pcalhoun@diameter.org on Tue, Jun 26, 2001 at 01:45:56PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Jun 26, 2001 at 01:45:56PM -0700, Pat Calhoun wrote: > On Mon, Jun 25, 2001 at 11:10:13AM +0200, Martin Julien (ECE) wrote: > > Submitter name: Martin Julien > > Submitter email address: martin.julien@ericsson.com > > Date first submitted: 25-Jun-2001 > > Reference: http://www.merit.edu/mail.archives/aaa-wg/msg01446.html > > Document: mobileip-06 > > Comment type: T > > Priority: S > > Section: > > Rationale/Explanation of issue: > > > > Requested change: > > > > > > 18) Section 6.2.7, should the SHA-1 algorithm be also added, as in the > > > > aaa-key-06 draft? BTW, would it be better that the values assigned to > > > > those algorithms match between the 2 drafts? The last comment also > > > > applies to the Replay-Mode. > > > > > > yes, but it really don't matter if there isn't a match. If you think it > > > would be useful, include it in your issue. > > > > Not really, it was only a comment. The thing is that since the values in > > the Diameter MIP-06 draft are based on the ones defined in the other > > document, I thought it would be better to keep the values consistent, > > but of course, it does not have to be like this, strictly speaking. > > hmmmm... I should have read this closer :( SHA-1 is used to encrypt the > session keys, as defined in the aaa-key-06 draft. The transforms listed > in section 6.2.7 are used to generate the authenticator portion of > the relevant authentication extension. > > So, no change is required. Sorry I missed that one when I first responded :( > No, I was right the first time, and wrong last time. You are correct, and SHA-1 is now added in the next release. PatC From owner-aaa-wg@merit.edu Tue Jun 26 18:57:42 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05215 for ; Tue, 26 Jun 2001 18:57:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3A44991350; Tue, 26 Jun 2001 18:55:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 01AF791352; Tue, 26 Jun 2001 18:55:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 94AEF91350 for ; Tue, 26 Jun 2001 18:55:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 265645DE50; Tue, 26 Jun 2001 18:56:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by segue.merit.edu (Postfix) with ESMTP id 803665DDB4 for ; Tue, 26 Jun 2001 18:56:21 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id PAA20247 for ; Tue, 26 Jun 2001 15:48:46 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id PAA18977 for ; Tue, 26 Jun 2001 15:55:35 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Jun 2001 17:55:35 -0500 Message-ID: From: Thomas Panagiotis-PTHOMAS1 To: "'Pat Calhoun'" , "Martin Julien (ECE)" Cc: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Issue 91: MIP SPI Date: Tue, 26 Jun 2001 17:55:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk > > > > 19) Section 6.1, could you please explain to me what "The Mobile IP key > > > > described in [15] refers to the AAA SPI, which MUST be set to the value > > > > the AAAH shares with the Mobile Node." Are we talking about a > > > > pre-configured shared SPI, or a secret key? Can it dynamically change > > > > or not? It is not clear to me how the AAA SPI can help in creating the > > > > FA or HA Security Information. Could you please tell me more? > > > > > > I'd love to explain it, but that would require that I first > > > understand it :( > > > > > > I believe that what I had originally intended to state here is that the > > > values created are used in a particular field of the MIP AAA key in [15]. > > > This needs some major cleaning up. > > I think what I meant to say was (proposed text): > > " The AVPs described in this section contain the values inserted in > the Key Material field of the extensions defined in [15]. The > Key Lifetime field is set to the same value as the one found > in the Authorization-Lifetime AVP." > > PatC I think we need to make explicit that AAAH generates the whole Subtype Data field, i.e. (lifetime|AAA SPI|FA(HA) SPI|Algorithm Identifier|Key Material), and not only the random value, which to me *is* the Key Material field. " The AVPs described in this section contain the Unsolicited MN-FA(HA) Key Material From AAA Subtype Data fields, as defined in [15]. ..." -Panos From owner-aaa-wg@merit.edu Tue Jun 26 19:39:50 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13696 for ; Tue, 26 Jun 2001 19:39:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0DBB291264; Tue, 26 Jun 2001 19:39:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CD9B591352; Tue, 26 Jun 2001 19:39:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9ADAD91264 for ; Tue, 26 Jun 2001 19:39:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 279575DE52; Tue, 26 Jun 2001 19:40:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id CDC925DDB4 for ; Tue, 26 Jun 2001 19:40:45 -0400 (EDT) Received: (qmail 7424 invoked by uid 500); 26 Jun 2001 23:28:42 -0000 Date: Tue, 26 Jun 2001 16:28:42 -0700 From: Pat Calhoun To: Thomas Panagiotis-PTHOMAS1 Cc: "'Pat Calhoun'" , "Martin Julien (ECE)" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Issue 91: MIP SPI Message-ID: <20010626162842.L22915@charizard.diameter.org> Mail-Followup-To: Thomas Panagiotis-PTHOMAS1 , 'Pat Calhoun' , "Martin Julien (ECE)" , "'aaa-wg@merit.edu'" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from panos.thomas@motorola.com on Tue, Jun 26, 2001 at 05:55:35PM -0500 Sender: owner-aaa-wg@merit.edu Precedence: bulk > I think we need to make explicit that AAAH generates the whole Subtype Data > field, i.e. (lifetime|AAA SPI|FA(HA) SPI|Algorithm Identifier|Key Material), > and not only the random value, which to me *is* the Key Material field. > > " The AVPs described in this section contain the Unsolicited MN-FA(HA) > Key Material From AAA Subtype Data fields, as defined in [15]. I need a vacation :( you are correct, and I guess I am very confused today. Here is the correct proposed text: " The AVPs described in this section contain the subtype data of the extensions defined in [15]. The Key Lifetime field of the subtype data is set to the same value as the Authorization-Lifetime AVP found in the message. The Key Material field of the subtype contains the random value used in the generation of the MIP-Session-Key AVP of the MIP-FA-to-MN-Key or MIP-HA-to-MN-Key Grouped AVPs." Thanks for catching that one, PatC From owner-aaa-wg@merit.edu Wed Jun 27 17:46:09 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00374 for ; Wed, 27 Jun 2001 17:46:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 28DAA91282; Wed, 27 Jun 2001 17:45:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E076091283; Wed, 27 Jun 2001 17:45:25 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A7CA991282 for ; Wed, 27 Jun 2001 17:45:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 10B085DDBA; Wed, 27 Jun 2001 17:46:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id B40CE5DD8D for ; Wed, 27 Jun 2001 17:46:27 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id OAA24081; Wed, 27 Jun 2001 14:39:00 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 27 Jun 2001 14:39:00 -0700 (PDT) From: Bernard Aboba To: Pat Calhoun Cc: david@mitton.com, aaa-wg@merit.edu Subject: [AAA-WG]: Reviewed of proposed EAP text In-Reply-To: <20010627133433.Z22915@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > 4.0 Extensible Authentication Protocol Support > > The Extensible Authentication Protocol (EAP), described in [25], > provides a standard mechanism for support of extensible > authentication methods. Through the use of EAP, support for a number > of authentication schemes may be added, including smart and token > cards, Kerberos, Public Key, One Time Passwords, and others. > > This section describes the Command-Codes values and AVPs that are > required for an EAP payload to be encapsulated within the Diameter > protocol. Since authentication occurs between the EAP client and its > home Diameter server, end-to-end authentication is achieved, reducing > the possibility for fraudulent authentication, such as replay and > man-in-the-middle attacks. End-to-end authentication also provides > for mutual (bi-directional) authentication, which is not possible > with PAP and CHAP in a roaming PPP environment. > > The EAP conversation between the authenticating peer and the access > device begins with the negotiation of EAP within a link layer, such > as PPP or 802.1x. Actually, EAP isn't negotiated in 802.1X. So I'd just say "initiation of EAP". > Once EAP has been negotiated, the access device substitute "intitiated" > will typically send to the Diameter server a Diameter-EAP-Request > message with a NULL EAP-Payload AVP, signifying an EAP-Start. The > Port number and the identity of the access device (e.g. Origin-Host > or NAS-Identifier) MUST be included in the Diameter-EAP-Request > message. > > If the Diameter home server supports EAP, it MUST respond with a > Diameter-EAP-Answer message containing an EAP-Payload AVP that > includes an encapsulated EAP payload [25], and the Result-Code AVP > set to DIAMETER_MULTI_ROUND_AUTH, signifying that a subsequent > request is expected. The EAP payload is forwarded by the access > device to the EAP client. > > The initial Diameter-EAP-Answer in a multi-round exchange normally > includes an EAP-Request/Identity, requesting the EAP client to > identify itself. Upon receipt of the EAP client's EAP-Response [25], > the access device will then issue a second Diameter-EAP-Request > message, with the client's EAP payload encapsulated within the EAP- > Payload AVP. > > A preferred approach is for the access device to issue the EAP- > Request/Identity message to the EAP client, and forward the EAP- > Response/Identity packet, encapsulated within the EAP-Payload AVP, as > a Diameter-EAP-Request to the Diameter server. This alternative > reduces the number of Diameter message round trips, and is compatible > with roaming environments, since the Destination-Realm is needed by > Diameter agents for routing purposes. Note that this alternative > cannot be universally employed, as there are circumstances where a > user's identity is not needed (such as when authorization occurs > based on a calling or called phone number). Actually, in this case doesn't the called or calling phone number end up in the User-Name AVP? > > The conversation continues until the Diameter server sends a > Diameter-EAP-Answer with a Result-Code AVP indicating success or > failure, and an optional EAP-Payload. The Result-Code AVP is used by > the access device to determine whether service is to be provided to > the EAP client. The access device MUST NOT rely on the contents of > the optional EAP-Payload to determine whether service is to be > provided. Good. > > A Diameter-EAP-Answer message containing an EAP-Payload of type EAP- > Success or EAP-Failure MUST NOT have the Result-Code AVP set to > DIAMETER_MULTI_ROUND_AUTH. > Good. > If authorization was requested, a successful Diameter-EAP-Answer MUST > also include the appropriate authorization AVPs required for the > service requested (see sections 2.0, 6.0 and 7.0). > Can a Diameter message with Result-Code = DIAMETER_MULTI_ROUND_AUTH also contain such AVPs? I would not prohibit this, necessarily. > Unless the access device interprets the EAP-Response/Identity packet > returned by the authenticating peer, it will not have access to the > user's identity. Therefore, the Diameter Server SHOULD return the > user's identity by inserting it in the User-Name attribute of > subsequent Diameter-EAP-Answer packets. Without the user's identity, > the Session-Id AVP MAY be used for accounting and billing, however > operationally this MAY be very difficult to manage. > > A home Diameter server MAY request EAP re-authentication by issuing > the Re-Auth-Request [2] message to the Diameter client. > > Should an EAP authentication session be interrupted due to a home > server failure, the session MAY be directed to an alternate server, > but the authentication session will have to be restarted from the > beginning. > > If a response is received with the Result-Code set to > DIAMETER_COMMAND_UNSUPPORTED [2], it is an indication that the > Diameter server in the home domain does not support EAP. If possible, > the access device MAY attempt to negotiate another authentication > protocol, such as PAP or CHAP. An access device SHOULD be cautious > when determining whether a less secure authentication protocol will > be used, since this could be a result of a bidding down attack. > > > 4.1 Alternative uses > > Currently the conversation between the backend authentication server > and the Diameter server is proprietary because of lack of > standardization. In order to increase standardization and provide > interoperability between Diameter vendors and backend security > vendors, it is recommended that Diameter-encapsulated EAP be used for > this conversation. > > This has the advantage of allowing the Diameter server to support EAP > without the need for authentication-specific code within the Diameter > server. Authentication-specific code can then reside on a backend > authentication server instead. > > In the case where Diameter-encapsulated EAP is used in a conversation > between a Diameter server and a backend authentication server, the > latter will typically return an Diameter-EAP-Answer/EAP-Payload/EAP- > Success message without inclusion of the expected authorization AVPs > required in a successful response. This means that the Diameter > server MUST add these attributes prior to sending an Diameter-EAP- > Answer/EAP-Payload/EAP-Success message to the access device. > > 4.2 Command-Codes Values > > This section defines new Command-Code [2] values that MUST be > supported by all Diameter implementations conforming to this > specification. The following Command Codes are defined in this > section: > > Command-Name Abbrev. Code Reference > -------------------------------------------------------- > Diameter-EAP-Answer DEA 268 4.2.2 > Diameter-EAP-Request DER 268 4.2.1 > > > > 4.2.1 Diameter-EAP-Request (DER) Command > > The Diameter-EAP-Request (DER) command, indicated by the Command-Code > field set to 268 and the 'R' bit set in the Command Flags field, is > sent by a Diameter client to a Diameter server and conveys an EAP- > Response [25] from the EAP client. The Diameter-EAP-Request MUST > contain one EAP-Payload AVP, which contains the actual EAP payload. > An EAP-Payload AVP with no data MAY be sent to the Diameter server to > initiate an EAP authentication session. > > The DER message MAY be the result of a multi-round authentication > exchange, which occurs when the DEA is received with the Result-Code > AVP set to DIAMETER_MULTI_ROUND_AUTH. A subsequent DER message MUST > include any State AVPs that were present in the DEA. For re- > authentication, it is recommended that the Identity request be > skipped in order to reduce the number of authentication round trips. > This is only possible when the user's identity is already known by > the home Diameter server. > > > Message Format > > ::= < Diameter Header: 268, REQ, PXY > > < Session-Id > > { Auth-Application-Id } > { Origin-Host } > { Origin-Realm } > { Destination-Realm } > { Service-Type } > { EAP-Payload } > [ Destination-Host ] > [ Authorization-Lifetime ] > [ Session-Timeout ] > [ User-Name ] > [ Idle-Timeout ] > [ NAS-IP-Address ] > [ NAS-Identifier ] > [ State ] > [ Origin-State-Id ] > [ NAS-Key-Binding ] > * [ AVP ] > * [ Proxy-Info ] > * [ Route-Record ] > This reminds me. Is there an accounting AVP that includes the EAP authentication type? I think we need one. > > 4.2.2 Diameter-EAP-Answer (DEA) Command > > The Diameter-EAP-Answer (DEA) message, indicated by the Command-Code > field set to 268 and the 'R' bit cleared in the Command Flags field, > is sent by the Diameter server to the client for one of the following > reasons: > > 1) The message is part of a multi-round authentication exchange, > and the server is expecting a subsequent Diameter-EAP-Request. > This is indicated by setting the Result-Code to > DIAMETER_MULTI_ROUND_AUTH, and MAY include zero or more State > AVPs. > 2) the EAP client has been successfully authenticated and > authorized, in which case the message MUST include the Result- > Code AVP indicating success, and SHOULD include an EAP-Payload > of type EAP-Success. This event MUST cause the access device > to provide service to the EAP client. Would delete the word "authorized", since EAP doesn't do authorization per se. I think it is reasonable that a successful auth SHOULD include an EAP-Success -- otherwise the AAA server would be granting access to someone that the EAP module said was not authentic. > 3) The EAP client has not been successfully authenticated and/or > authorized, and the Result-Code AVP is set to indicate failure. > This message MAY include an EAP-Payload, but this AVP is not > used to determine whether service is to be provided. I would say that it SHOULD include an EAP-Payload. We don't want to encourage people not to include such a payload because the absence of one will result in an IEEE 802.1X timeout. > > If the message from the Diameter client included a request for > authorization, a successful response MUST include the authorization > AVPs that are relevant to the service being provided. > > Message Format > > ::= < Diameter Header: 268, PXY > > < Session-Id > > { Auth-Application-Id } > { Result-Code } > { Origin-Host } > { Origin-Realm } > { Destination-Host } > { Service-Type } > [ Error-Reporting-Host ] > [ EAP-Payload ] > [ User-Name ] > [ Idle-Timeout ] > [ Authorization-Lifetime ] > [ Session-Timeout ] > [ Origin-State-Id ] > * [ NAS-Session-Key ] > * [ AVP ] > * [ Proxy-Info ] > * [ Route-Record ] > > > 4.3 EAP-Payload AVP > > The EAP-Payload AVP (AVP Code 402) is of type OctetString and is used > to encapsulate the actual EAP payload [25] that is being exchanged > between the EAP client and the home Diameter server. > From owner-aaa-wg@merit.edu Wed Jun 27 18:10:01 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16973 for ; Wed, 27 Jun 2001 18:10:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3B24E91284; Wed, 27 Jun 2001 18:09:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 08BB791298; Wed, 27 Jun 2001 18:09:56 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BE15D91284 for ; Wed, 27 Jun 2001 18:09:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2258F5DDB4; Wed, 27 Jun 2001 18:11:00 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id EDADC5DD8D for ; Wed, 27 Jun 2001 18:10:58 -0400 (EDT) Received: (qmail 27252 invoked by uid 500); 27 Jun 2001 21:58:50 -0000 Date: Wed, 27 Jun 2001 14:58:50 -0700 From: Pat Calhoun To: Bernard Aboba Cc: Pat Calhoun , david@mitton.com, aaa-wg@merit.edu Subject: [AAA-WG]: Re: Reviewed of proposed EAP text Message-ID: <20010627145850.B22915@charizard.diameter.org> Mail-Followup-To: Bernard Aboba , Pat Calhoun , david@mitton.com, aaa-wg@merit.edu References: <20010627133433.Z22915@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from aboba@internaut.com on Wed, Jun 27, 2001 at 02:39:00PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Thanks for the review. Comments below. > > A preferred approach is for the access device to issue the EAP- > > Request/Identity message to the EAP client, and forward the EAP- > > Response/Identity packet, encapsulated within the EAP-Payload AVP, as > > a Diameter-EAP-Request to the Diameter server. This alternative > > reduces the number of Diameter message round trips, and is compatible > > with roaming environments, since the Destination-Realm is needed by > > Diameter agents for routing purposes. Note that this alternative > > cannot be universally employed, as there are circumstances where a > > user's identity is not needed (such as when authorization occurs > > based on a calling or called phone number). > > Actually, in this case doesn't the called or calling phone number end up > in the User-Name AVP? not in Diameter. The User-Name isn't mandatory, as it is in RADIUS. > > If authorization was requested, a successful Diameter-EAP-Answer MUST > > also include the appropriate authorization AVPs required for the > > service requested (see sections 2.0, 6.0 and 7.0). > > > > Can a Diameter message with Result-Code = DIAMETER_MULTI_ROUND_AUTH > also contain such AVPs? I would not prohibit this, necessarily. ok. > This reminds me. Is there an accounting AVP that includes the EAP > authentication type? I think we need one. ok > > > > > 4.2.2 Diameter-EAP-Answer (DEA) Command > > > > The Diameter-EAP-Answer (DEA) message, indicated by the Command-Code > > field set to 268 and the 'R' bit cleared in the Command Flags field, > > is sent by the Diameter server to the client for one of the following > > reasons: > > > > 1) The message is part of a multi-round authentication exchange, > > and the server is expecting a subsequent Diameter-EAP-Request. > > This is indicated by setting the Result-Code to > > DIAMETER_MULTI_ROUND_AUTH, and MAY include zero or more State > > AVPs. > > 2) the EAP client has been successfully authenticated and > > authorized, in which case the message MUST include the Result- > > Code AVP indicating success, and SHOULD include an EAP-Payload > > of type EAP-Success. This event MUST cause the access device > > to provide service to the EAP client. > > Would delete the word "authorized", since EAP doesn't do authorization > per se. I think it is reasonable that a successful auth SHOULD include an > EAP-Success -- otherwise the AAA server would be granting access to > someone that the EAP module said was not authentic. in EAP terms no, but in Diameter terms, the user was both authenticated, and authorized for service. The above text doesn't speak directly about the EAP message, but the Diameter answer message. So, I think leaving the authorized is fine. > > > 3) The EAP client has not been successfully authenticated and/or > > authorized, and the Result-Code AVP is set to indicate failure. > > This message MAY include an EAP-Payload, but this AVP is not > > used to determine whether service is to be provided. > > I would say that it SHOULD include an EAP-Payload. We don't want to > encourage people not to include such a payload because the absence of one > will result in an IEEE 802.1X timeout. ok Thanks for the comments. Were there any additional issues that weren't covered with the new text? Can I close this issue? Thanks, PatC From owner-aaa-wg@merit.edu Wed Jun 27 19:43:53 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18280 for ; Wed, 27 Jun 2001 19:43:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D176A912B2; Wed, 27 Jun 2001 19:43:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9CFE8912BD; Wed, 27 Jun 2001 19:43:48 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8CF60912B2 for ; Wed, 27 Jun 2001 19:43:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0BF945DDA4; Wed, 27 Jun 2001 19:44:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 5980C5DD8D for ; Wed, 27 Jun 2001 19:44:51 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id QAA24246; Wed, 27 Jun 2001 16:37:24 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 27 Jun 2001 16:37:23 -0700 (PDT) From: Bernard Aboba To: Pat Calhoun Cc: david@mitton.com, aaa-wg@merit.edu Subject: [AAA-WG]: Re: Reviewed of proposed EAP text In-Reply-To: <20010627145850.B22915@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk >Can we close this issue? From my perspective, yes. Anyone else in the WG have comments on this? From owner-aaa-wg@merit.edu Thu Jun 28 04:56:50 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09549 for ; Thu, 28 Jun 2001 04:56:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5D213912C1; Thu, 28 Jun 2001 04:56:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 24766912C2; Thu, 28 Jun 2001 04:56:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C43E5912C1 for ; Thu, 28 Jun 2001 04:56:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 077335DDCC; Thu, 28 Jun 2001 04:58:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 20E5C5DDCB for ; Thu, 28 Jun 2001 04:58:00 -0400 (EDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f5S8vCO09736 for ; Thu, 28 Jun 2001 10:57:13 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Jun 28 10:57:10 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 10:57:10 +0200 Message-ID: <577066326047D41180AC00508B955DDA04D1A9D8@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Pat Calhoun'" , "Martin Julien (ECE)" Cc: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Issue 91: MIP SPI Date: Thu, 28 Jun 2001 10:52:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk See comments. > > > > 11) If there is a problem in the HA or FA with the SPI > generated by > > > > the AAAH or AAAF, how could that be reported? > > > > > > reported by whom? The HA? Or one of the AAA servers? > > > > > > > 16) Whenever no MIP-*-Preferred-SPI AVP is included in > the AMR, can we > > > > assume that the SPI generated by the AAAH or AAAF can > be completely > > > > random or not? Why can't the HA decide the SPI itself? > > > > > > There's no reason why, really :( > > > > I'm still not quite sure to get the complete picture of how > the SPI should > > be > > handled in the AAA servers. Are we expecting the AAA > servers to use the > > standard 0-255 SPI defined by IANA?, or are the AAA servers > expected to > > handle to concept of SA, which normally contains and > defines their own > > SPI values? > > yes, the AAA creates the SPI values used for an SA. The SPI > number provided > in the *Preferred-SPI AVPs are recommendations from the > Diameter agents on > what values they'd like to see, to minimize the possibility > of conflict. > However, the SPI address space is 32bits long, and therefore > clashes should > be minimal. So, if I understand correctly, you are suggesting that the AAA re-use the Preferred-SPI received in the AMR, right? In the case, they are not received, then the AAA should generate a random 32bits long SPI outside the range of the reserved SPI by IANA, right? The problem here is that we are assuming that we are lucky enough to not re-use an already defined SPI between the HA-FA, HA-MN and FA-MN. I must admit that the chance is not great, but still there, unnecessarily. > To address your other question, no we do not touch the > reserved SPIs defined by > IANA. OK, then the SPI MUST be outside the range of pre-defined SPIs from IANA. Can you make that clear in the draft? > > The thing is > > that if Diameter needs to support the concept of SA, then > it seems to > > be difficult for the AAA server to select an SPI on behalf > of the MN, the HA > > and the FA. > > but the MN provides its preferred SPI in the Generalized Key > Ext, and the FA > provides its own in the MIP-FA-Preferred-SPI AVP. The Home > Agent is the only > sticky point, and if the AAAH picks one that causes a > conflict on the HA, an > error would be returned, which could include a new SPI, I > suppose. The AAAH > would then try again. I suppose this is what needs to be documented. Yes, that's my point. How can we inform the AAA that the chosen SPI is already in use? The easy solution would be to leave that selection of the SPIs to the HA, since the AAA does not really care about it. In fact, the AAA can still put everything it requires for security, in terms of algorithms, replay-mode, key material, but should not care about the SPI. That would mean that the HA would become responsible for looking at the Registration message, extract the Preferred-SPI itself from the MN, and select the SPI and create a new one. The thing is that the HA is the one that owns the SA with the MN and the FA, right? I don't see the point for the AAA to take a chance by chosing one that can possibly not be a valid one for the HA's SAs? That means that HA would be responsible of the SPI field of the "Unsolicited MN-HA Key from AAA Subtype" and the "Unsolicited MN-FA Key from AAA Subtype". The Preferred-SPI AVPs would become obsolete, since the HA could extract directly that information from the Registration message. Furthermore, the FA does not need to suggest an SPI, since the HA would know the SPI available for the SA with the FA, if it receives the MIP-Foreign-Agent-Host AVP. The HA would need to return the selected SPIs for the FA-HA and the FA-MN Session key AVPs, so that the AAA can return them to the FA in a secured manner, if required. Does that make sense or not? > > Of course, the AAA can count on the Preferred-SPI from the FA > > and the MN, in which case the AAA simply agrees with the > value. However, > > if there is no Preferred-SPI AVPs in the AMR, then the AAAH needs to > > generate > > them, at the risk that they might already be used in the SA > defined between > > the MN and the HA, or between the HA and the FA, or between > the FA and the > > MN. > > I think that it makes more sense for the HA to select the > required SPI > > between > > the HA-MN and HA-FA, if no Preferred-SPI is included in the AMR. > > No, IMHO, if not Preferred-SPI is present, then no key is > generated. So, > perhaps some associated text in the Feature-Vector is needed? That seems to contradicts what you were saying earlier about the need for the AAA to generate new SPIs, right?, or am I understanding you wrong? > PatC > Martin From owner-aaa-wg@merit.edu Thu Jun 28 05:39:36 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09944 for ; Thu, 28 Jun 2001 05:39:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4310091378; Thu, 28 Jun 2001 05:39:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1434C9137A; Thu, 28 Jun 2001 05:39:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D0B9991378 for ; Thu, 28 Jun 2001 05:39:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1B93A5DDCC; Thu, 28 Jun 2001 05:40:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 69D755DDCB for ; Thu, 28 Jun 2001 05:40:35 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f5S9dlN05731 for ; Thu, 28 Jun 2001 11:39:47 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Jun 28 11:39:43 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 11:39:44 +0200 Message-ID: <577066326047D41180AC00508B955DDA04D1A9D9@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Jacques Caron'" , Pat Calhoun Cc: aaa-wg@merit.edu, "Martin Julien (ECE)" Subject: RE: [AAA-WG]: Issue 82: Reauthorization Issues Date: Thu, 28 Jun 2001 11:35:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk See comments. > > > - In 10.7 (and elsewhere) clarify Authorization-Lifetime > (means Reauth > > > should be performed) and Session-Timeout. Resources > should be liberated > > > upon Session-Timeout only, not upon > Authorization-Lifetime expiration. > > > >but it is valid for an answer message to only include the > >Authorization-Lifetime, > >and not the Session-Timeout. > > The problem is that if Authorization-Lifetime is a trigger > for a reauth > request, then there should be some time between the start of > the reauth and > really freeing all associated resources. But there should be > an absolute > maximum to the session duration. > > I would say that if there is an Authorization-Lifetime, there > should be a > Session-Timeout too, with a value slightly higher. In other words, > Authorization-Lifetime just means "ask for a reauth after n > seconds". If > that doesn't happen, then the session is dropped because of > Session-Timeout, not because of Authorization-Lifetime > (otherwise there is > a duplicate in semantics). A Diameter client must send a re-auth message at the Authorization-Lifetime expiration, and free all resources if it can not get a re-auth answer before the Session Time-out expiration. Is it what the Session Time-out AVP is supposed to be used for in the answer?, or is it left to the client itself to take the proper action when it can not get a re-auth answer? A Diameter Home server, informs the client of the Authorization-Lifetime, which means that the client should re-auth before the expiration of the Authorization-Lifetime, right? Should it send the re-auth at the expiration of the Authorization-Lifetime?, or slightly before? MUST the AAAH release resources or not, when the Authorization-Lifetime has expired? What seems to make sense to me, is that the client should send the re-auth message at the Authorization-Lifetime, while the AAAH server expects a re-auth to be received from the client before the Session-Time-out expires. That would mean that the AAAH would only free resources once the Session-Time-out has expired in the AAAH server. The Session-Timeout should be reset after the re-auth request is re-authorized by the server. I don't really see the point of having a Session-timeout that disconnect a client independently of authorization. A problem we are having right now with the actual specification, is that if a AAA Home release a session based on the Authorization-Lifetime expiration, because the client is late sending the re-auth, what should the AAA Home do when it receives it? Since there is no difference in the AA-Request for initial authentication+Authorization, then I guess the AAA Home would authenticate+Authorize and return a new IP address and authorization AVPs, right? That is a problem. So, if we release the session only after the Session-Timeout, it reduces the risk of receiving a late re-auth message, but it still remains. Should we have an additionnal information in the AA-Request informing the AAA Home that the client is asking either for an initial auth, or a re-auth? > > > - Change name of Authorization-Lifetime to Reauthorization-Timeout > > > >I'm not particularly fond of this one. > > Depends on the exact semantics of the AVP as detailed above. I agree. > > > - Authorization-Lifetime and Session-Timeout based from start of > > Session or > > > from receipt of message (in reauth)? > > > >ok, this should be clarified. Of course, I wonder what the > right answer is. > >a couple of options: > > > >1. a re-auth is expected after Authorization-Lifetime, and > if no answer > > is received by Session-Timeout, resources are cleaned up. > > That's what I think, but the issue is: > - upon reauth, there should be a new Authorization-Lifetime & > Session-Timeout. > - from when are these counted? The original authorization, or > the new one? > > >2. Session-Timeout is the end of the session. The user is > free to re-auth, > > but once session-timeout expires (from the beginning of > the session), > > it's game over. > > Don't quite see the difference (other than you don't mention > Auth-Lifetime)? > > > > - In reauth, is it allowed to change authorization > parameters (filters, > > > IPs...)? > > > >good question. perhaps some text stating that > non-conflicting authorization > >information MAY be returned in re-auth messages. > > How do you define "non-conflicting"? A few "hints" on that... > - it is quite useful to be able to change filters on the fly > (e.g. a user > starts with restricted filters, then something external makes > us open the > filters. Or the opposite, a user starts with full access, but > then upon > reauth we find out that he's out of credits, but we still > want him/her to > have access to a specific www site to buy some more, so we just close > filters instead of just disconnecting the user) > - some things like IP addresses are quite harder to change on > the fly, at > least in an PPP context. Good question! Should the AAA make a distinction between authorization and re-authorization? > [which raises an interesting point, does Diameter have > everything needed to > centralize DHCP authorization?] What do you mean? Should the client connects directly to DHCP?, or should the AAA returns an equivalent DHCP information to the client? I think that Mobile-IP WG went through the same discussion. > > Jacques. > From owner-aaa-wg@merit.edu Thu Jun 28 09:44:15 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09312 for ; Thu, 28 Jun 2001 09:44:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 83D8891206; Thu, 28 Jun 2001 09:44:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4FC6591208; Thu, 28 Jun 2001 09:44:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 24EDF91206 for ; Thu, 28 Jun 2001 09:44:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B2F525DDDD; Thu, 28 Jun 2001 09:45:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 0812F5DDCB for ; Thu, 28 Jun 2001 09:45:22 -0400 (EDT) Received: (qmail 32272 invoked by uid 500); 28 Jun 2001 13:33:04 -0000 Date: Thu, 28 Jun 2001 06:33:04 -0700 From: Pat Calhoun To: "Martin Julien (ECE)" Cc: "'Pat Calhoun'" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Issue 91: MIP SPI Message-ID: <20010628063304.I22915@charizard.diameter.org> Mail-Followup-To: "Martin Julien (ECE)" , 'Pat Calhoun' , "'aaa-wg@merit.edu'" References: <577066326047D41180AC00508B955DDA04D1A9D8@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <577066326047D41180AC00508B955DDA04D1A9D8@eestqnt104.es.eu.ericsson.se>; from Martin.Julien@ece.ericsson.se on Thu, Jun 28, 2001 at 10:52:27AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, Jun 28, 2001 at 10:52:27AM +0200, Martin Julien (ECE) wrote: > See comments. > > > > > > 11) If there is a problem in the HA or FA with the SPI > > generated by > > > > > the AAAH or AAAF, how could that be reported? > > > > > > > > reported by whom? The HA? Or one of the AAA servers? > > > > > > > > > 16) Whenever no MIP-*-Preferred-SPI AVP is included in > > the AMR, can we > > > > > assume that the SPI generated by the AAAH or AAAF can > > be completely > > > > > random or not? Why can't the HA decide the SPI itself? > > > > > > > > There's no reason why, really :( > > > > > > I'm still not quite sure to get the complete picture of how > > the SPI should > > > be > > > handled in the AAA servers. Are we expecting the AAA > > servers to use the > > > standard 0-255 SPI defined by IANA?, or are the AAA servers > > expected to > > > handle to concept of SA, which normally contains and > > defines their own > > > SPI values? > > > > yes, the AAA creates the SPI values used for an SA. The SPI > > number provided > > in the *Preferred-SPI AVPs are recommendations from the > > Diameter agents on > > what values they'd like to see, to minimize the possibility > > of conflict. > > However, the SPI address space is 32bits long, and therefore > > clashes should > > be minimal. > > So, if I understand correctly, you are suggesting that the AAA > re-use the Preferred-SPI received in the AMR, right? In the case, > they are not received, then the AAA should generate a random > 32bits long SPI outside the range of the reserved SPI by IANA, right? correct > > The problem here is that we are assuming that we are lucky enough to > not re-use an already defined SPI between the HA-FA, HA-MN and FA-MN. > I must admit that the chance is not great, but still there, unnecessarily. Well, we have to play a probability game here, but with 2^32, the chances are quite small, even more so if one actually binds the SPI to the destination address. > > > To address your other question, no we do not touch the > > reserved SPIs defined by > > IANA. > > OK, then the SPI MUST be outside the range of pre-defined SPIs > from IANA. Can you make that clear in the draft? ok. > > > > The thing is > > > that if Diameter needs to support the concept of SA, then > > it seems to > > > be difficult for the AAA server to select an SPI on behalf > > of the MN, the HA > > > and the FA. > > > > but the MN provides its preferred SPI in the Generalized Key > > Ext, and the FA > > provides its own in the MIP-FA-Preferred-SPI AVP. The Home > > Agent is the only > > sticky point, and if the AAAH picks one that causes a > > conflict on the HA, an > > error would be returned, which could include a new SPI, I > > suppose. The AAAH > > would then try again. I suppose this is what needs to be documented. > > Yes, that's my point. How can we inform the AAA that the chosen SPI > is already in use? > > The easy solution would be to leave that selection of the SPIs to > the HA, since the AAA does not really care about it. In fact, the AAA > can still put everything it requires for security, in terms of algorithms, > replay-mode, key material, but should not care about the SPI. That would > mean that the HA would become responsible for looking at the Registration > message, extract the Preferred-SPI itself from the MN, and select the SPI and create > a new one. The thing is that the HA is the one that owns the SA with the > MN and the FA, right? I don't see the point for the AAA to take a chance > by chosing one that can possibly not be a valid one for the HA's SAs? This is a possibility. > > That means that HA would be responsible of the SPI field of the > "Unsolicited MN-HA Key from AAA Subtype" and the "Unsolicited MN-FA Key > from AAA Subtype". The Preferred-SPI AVPs would become obsolete, since > the HA could extract directly that information from the Registration > message. Furthermore, the FA does not need to suggest an SPI, since the > HA would know the SPI available for the SA with the FA, if it receives > the MIP-Foreign-Agent-Host AVP. The HA would need to return the selected > SPIs for the FA-HA and the FA-MN Session key AVPs, so that the AAA can return > them to the FA in a secured manner, if required. > > Does that make sense or not? ok, so the Diameter draft could state that the AAAH still inserts an SPI, but the HA is allowed to override that value if it is deemed necessary. Would this work? > > > > Of course, the AAA can count on the Preferred-SPI from the FA > > > and the MN, in which case the AAA simply agrees with the > > value. However, > > > if there is no Preferred-SPI AVPs in the AMR, then the AAAH needs to > > > generate > > > them, at the risk that they might already be used in the SA > > defined between > > > the MN and the HA, or between the HA and the FA, or between > > the FA and the > > > MN. > > > I think that it makes more sense for the HA to select the > > required SPI > > > between > > > the HA-MN and HA-FA, if no Preferred-SPI is included in the AMR. > > > > No, IMHO, if not Preferred-SPI is present, then no key is > > generated. So, > > perhaps some associated text in the Feature-Vector is needed? > > That seems to contradicts what you were saying earlier about the > need for the AAA to generate new SPIs, right?, or am I understanding > you wrong? Not sure. I think that the Preferred-SPIs MUST be present for key request, since the SPIs are present in the MIP Key Request extension, so it is trivial for an FA to include these values in the Diameter message. I think that we should mandate that the FA include these values. What do you think? PatC From owner-aaa-wg@merit.edu Thu Jun 28 11:26:56 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22039 for ; Thu, 28 Jun 2001 11:26:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8B53E9137B; Thu, 28 Jun 2001 11:26:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E7FC9137C; Thu, 28 Jun 2001 11:26:51 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4EF739137B for ; Thu, 28 Jun 2001 11:26:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0E6DA5DDE5; Thu, 28 Jun 2001 11:27:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id EDA835DDE3 for ; Thu, 28 Jun 2001 11:27:55 -0400 (EDT) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 3CBBE79; Thu, 28 Jun 2001 11:27:20 -0400 (EDT) Message-ID: <3B3AA903.5ECB646@Interlinknetworks.com> Date: Wed, 27 Jun 2001 21:48:19 -0600 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: Jonathan Wood , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Comments on draft-ietf-aaa-transport-03.txt References: <200106042347.QAA11186@heliopolis.eng.sun.com> <20010604200739.T22616@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun wrote: > > On Mon, Jun 04, 2001 at 04:47:45PM -0700, Jonathan Wood wrote: > > > > > > > > Should read "The AAA client SHOULD wait for the transport layer > > > > to report connection" success, but MAY chose to bound this wait > > > > time by the watchdog interval, Tw." > > > > > > > > The intent is to let the transport layer decide when a connection > > > > attempt has failed (TCP and SCTP both retransmit and back off > > > > connection attempts). However, in some cases, the RTO can > > > > grow quite large, which means it may take minutes for the > > > > transport to decide that a connection attempt has failed. The > > > > second half of the sentence, "but MAY chose ..." gives the > > > > AAA layer a way out of this, by limiting the wait time to > > > > something more reasonable. > > > > > > > > Let me know if you still think it needs fixing. > > > s/bound/bind/ > > > > Hmm my Websters agrees with 'bound'. How about > > s/bound/limit > > and be done with it? > Deal! > > PatC Argh! "...bound this wait time by the watchdog interval..." was just fine. Now the draft reads "...limit this wait time by the watchdog interval..". I think you bound by, but you limit to. So the text should read: "...limit this wait time to the watchdog interval..." Meanwhile, the real problem with that sentence remains uncorrected: s/chose/choose Sheesh! -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-wg@merit.edu Thu Jun 28 11:32:09 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25828 for ; Thu, 28 Jun 2001 11:32:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 63C1B91207; Thu, 28 Jun 2001 11:32:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A89919137C; Thu, 28 Jun 2001 11:32:10 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8C0CD91207 for ; Thu, 28 Jun 2001 11:32:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 572B15DDCC; Thu, 28 Jun 2001 11:33:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 10E4B5DDE3 for ; Thu, 28 Jun 2001 11:33:15 -0400 (EDT) Received: (qmail 4536 invoked by uid 500); 28 Jun 2001 15:21:04 -0000 Date: Thu, 28 Jun 2001 08:21:04 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 62: e2e unnecessary step via pkcs7-mime Message-ID: <20010628082104.P22915@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, I discussed this issue with Stephen Farrell, and the reason why this step is done is to use existing S/MIME toolkits. Removing this step would require that one either write the code, or use a toolkit with a lower layer set of APIs. So, this issue is rejected. PatC From owner-aaa-wg@merit.edu Thu Jun 28 12:29:44 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07290 for ; Thu, 28 Jun 2001 12:29:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E2D559137D; Thu, 28 Jun 2001 12:29:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B1F219137E; Thu, 28 Jun 2001 12:29:40 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 984019137D for ; Thu, 28 Jun 2001 12:29:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 560AF5DDE7; Thu, 28 Jun 2001 12:30:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 65F6B5DDE4 for ; Thu, 28 Jun 2001 12:30:44 -0400 (EDT) Received: from fredrikj (sierra.local.ipunplugged.com [192.168.4.88]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id SAA32319 for ; Thu, 28 Jun 2001 18:31:40 +0200 From: "Fredrik Johansson" To: "AAA Listan" Subject: [AAA-WG]: Issue 93. End-to-End identifier Date: Thu, 28 Jun 2001 18:31:23 +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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter name: Fredrik Johansson Submitter email address: fredrik@ipunplugged.com Date first submitted: 28-Jun-2001 Reference: Document: base-06 Comment type: T Priority: S Section: 3.0, Rationale/Explanation of issue: The end-to-end identifier is not monotonically increasing, thus it requires a server to save all identifers on a per host basis to be able to see if the message has been received before. Some describing text is also missing on how a server should treat a message that it has received before. Requested change: Make the e-2-e identifier monotonically increasing and suggest that the server stores the identifiers in the same manner as done in AH (section 3.4.3 in RFC 2402) but with a suggested value of 128 as default window. Also, add some text describing what a server should do when the e-2-e identifier has been seen before. e.g. discard it or reply with the same answer as last time. /Fredrik From owner-aaa-wg@merit.edu Thu Jun 28 12:34:43 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10738 for ; Thu, 28 Jun 2001 12:34:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3A00C9137E; Thu, 28 Jun 2001 12:34:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 115309137F; Thu, 28 Jun 2001 12:34:38 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EDB429137E for ; Thu, 28 Jun 2001 12:34:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BC2D95DDE7; Thu, 28 Jun 2001 12:35:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp014.mail.yahoo.com (smtp014.mail.yahoo.com [216.136.173.58]) by segue.merit.edu (Postfix) with SMTP id 40F495DDE4 for ; Thu, 28 Jun 2001 12:35:43 -0400 (EDT) Received: from pc225.etc.psi.com (HELO jc.yahoo.com) (195.94.40.225) by smtp.mail.vip.sc5.yahoo.com with SMTP; 28 Jun 2001 16:34:55 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010628183249.00cadb60@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Jun 2001 18:34:42 +0200 To: "Fredrik Johansson" From: Jacques Caron Subject: Re: [AAA-WG]: Issue 93. End-to-End identifier Cc: "AAA Listan" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 18:31 28/06/01, Fredrik Johansson wrote: >Also, add some text describing what a server should do when the e-2-e >identifier has been seen before. e.g. discard it or reply with the same >answer as last time. Should reply with the same answer, not discard it. The only issue is that it should not do the same processing again, if that has "consequences" on anything (e.g. not store an accounting record a second time). Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Thu Jun 28 13:29:34 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17658 for ; Thu, 28 Jun 2001 13:29:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8ECBE91209; Thu, 28 Jun 2001 13:29:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 508BA9137F; Thu, 28 Jun 2001 13:29:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4842C91209 for ; Thu, 28 Jun 2001 13:29:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3071C5DDE7; Thu, 28 Jun 2001 13:30:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.72.74]) by segue.merit.edu (Postfix) with ESMTP id 5E4575DD99 for ; Thu, 28 Jun 2001 13:30:34 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA06621; Thu, 28 Jun 2001 13:29:06 -0400 (EDT) Date: Thu, 28 Jun 2001 13:29:50 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: Jacques Caron Cc: Fredrik Johansson , AAA Listan Subject: Re: [AAA-WG]: Issue 93. End-to-End identifier In-Reply-To: <4.3.2.7.2.20010628183249.00cadb60@pop.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, 28 Jun 2001, Jacques Caron wrote: > At 18:31 28/06/01, Fredrik Johansson wrote: > >Also, add some text describing what a server should do when the e-2-e > >identifier has been seen before. e.g. discard it or reply with the same > >answer as last time. > > Should reply with the same answer, not discard it. The only issue is that > it should not do the same processing again, if that has "consequences" on > anything (e.g. not store an accounting record a second time). So, am I interpreting this right? A server that serves 100 clients and has a window of 128 will have to remember how it replied for 12800 packets? What if it receives something below the window? Do you just drop the packet, or make up a best guess for the reply? -mark > > Jacques. > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > From owner-aaa-wg@merit.edu Thu Jun 28 14:45:37 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12255 for ; Thu, 28 Jun 2001 14:45:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8C3C891210; Thu, 28 Jun 2001 14:45:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 561859120E; Thu, 28 Jun 2001 14:45:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C939B91210 for ; Thu, 28 Jun 2001 14:45:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C84B05DE06; Thu, 28 Jun 2001 14:46:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id 0E8265DDE7 for ; Thu, 28 Jun 2001 14:46:23 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id OAA19002; Thu, 28 Jun 2001 14:31:03 -0400 (EDT) Message-Id: <4.1.20010628135244.01be6a40@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 28 Jun 2001 14:18:28 -0400 To: "Fredrik Johansson" , Mark Eklund , Jacques Caron From: Paul Funk Subject: Re: [AAA-WG]: Issue 93. End-to-End identifier Cc: aaa-wg@merit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-wg@merit.edu Precedence: bulk Fredrik, I think there's some misunderstanding as to how the End-To-End Identifier is used. The End-To-End Identifiers are, by definition, not hop-by-hop, so there's no guarantee that a server will receive them in any particular sequence. A server may get messages wildly out of order from the same client, because they are routed through different proxies. My understanding of how it's supposed to be used is this: A server would keep a cache of answers by Origin-Host + End-To-End Identifier. If a new request arrives that's already in the cache, instead of processing the request normally, it just sends back the same answer. How to manage (or whether to even provide) such a cache would be implementation dependent. The problem this solves is that if a proxy goes down, pending requests will be rerouted to another proxy. The home server will thus receive two identical requests in unknown order; that is, it can't tell which request came over the good path and which came over the bad. Therefore it should respond to both identically. I do think that the language for End-To-End-Identifier should mirror more closely the language for Hop-By-Hop Identifier, to indicate that it is typically randomly initialized and incremented, etc. But it need not be monotonically increased and there can't be a window. Paul At 06:31 PM 6/28/01 +0200, Fredrik Johansson wrote: >Submitter name: Fredrik Johansson >Submitter email address: fredrik@ipunplugged.com >Date first submitted: 28-Jun-2001 >Reference: >Document: base-06 >Comment type: T >Priority: S >Section: 3.0, >Rationale/Explanation of issue: > >The end-to-end identifier is not monotonically increasing, thus it requires >a server to save all identifers on a per host basis to be able to see if the >message has been received before. Some describing text is also missing on >how a server should treat a message that it has received before. > >Requested change: > >Make the e-2-e identifier monotonically increasing and suggest that the >server stores the identifiers in the same manner as done in AH (section >3.4.3 in RFC 2402) but with a suggested value of 128 as default window. > >Also, add some text describing what a server should do when the e-2-e >identifier has been seen before. e.g. discard it or reply with the same >answer as last time. > >/Fredrik Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-wg@merit.edu Thu Jun 28 17:36:18 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04464 for ; Thu, 28 Jun 2001 17:36:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5C4F591218; Thu, 28 Jun 2001 17:36:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2835F9121A; Thu, 28 Jun 2001 17:36:14 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 13C5291218 for ; Thu, 28 Jun 2001 17:36:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5A2E35DDCC; Thu, 28 Jun 2001 17:37:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 5E2ED5DDB1 for ; Thu, 28 Jun 2001 17:37:18 -0400 (EDT) Received: (qmail 16943 invoked by uid 500); 28 Jun 2001 21:25:06 -0000 Date: Thu, 28 Jun 2001 14:25:06 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 87: Move filter-rule AVP to base Message-ID: <20010628142506.Q22915@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, Here is the proposed text for Issue 87. The main difference here is support for QoS filters. Comments appreciated, PatC ---- FilterRule The FilterRule format is derived from the OctetString AVP Base Format. It uses the UTF-8 encoding and has the same requirements as the UTF8String. Packets may be filtered based on the following information that is associated with it: Direction (in or out) Source and destination IP address (possibly masked) Protocol Source and destination port (lists or ranges) TCP flags IP fragment flag IP options DSCP values (no mask or range) ICMP types Rules for the appropriate direction are evaluated in order, with the first matched rule terminating the evaluation. Each packet is evaluated once. If no rule matches, the packet is dropped if the last rule evaluated was a permit, and passed if the last rule was a deny. The filters in the Filter-Rule AVP MUST follow the format: action dir proto from src to dst [options] action permit - Allow packets that match the rule. deny - Drop packets that match the rule. tag - Mark packet with a specific DSCP [49]. The DSCP option MUST be included. meter - Meter traffic. The metering options MUST be included. dir "in" is from the terminal, "out" is to the terminal. proto An IP protocol specified by number. The "ip" keyword means any protocol will match. src and dst
[ports] The
may be specified as: ipno An IPv4 or IPv6 number in dotted- quad or canonical IPv6 form. Only this exact IP number will match the rule. ipno/bits An IP number as above with a mask width of the form 1.2.3.4/24. In this case all IP numbers from 1.2.3.0 to 1.2.3.255 will match. The bit width MUST be valid for the IP version and the IP number MUST NOT have bits set beyond the mask. The sense of the match can be inverted by preceding an address with the not modifier, causing all other addresses to be matched instead. This does not affect the selection of port numbers. The keyword "any" is 0.0.0.0/0 or the IPv6 equivalent. The keyword "assigned" is the address or set of addresses assigned to the terminal. The first rule SHOULD be "deny in ip !assigned". With the TCP and UDP protocols, optional ports may be specified as: {port|port-port}[,port[,...]] The `-' notation specifies a range of ports (including boundaries). Fragmented packets which have a non-zero offset (i.e. not the first fragment) will never match a rule which has one or more port specifications. See the frag option for details on matching fragmented packets. options: frag Match if the packet is a fragment and this is not the first fragment of the datagram. frag may not be used in conjunction with either tcpflags or TCP/UDP port specifications. ipoptions spec Match if the IP header contains the comma separated list of options specified in spec. The supported IP options are: ssrr (strict source route), lsrr (loose source route), rr (record packet route) and ts (timestamp). The absence of a particular option may be denoted with a `!'. tcpoptions spec Match if the TCP header contains the comma separated list of options specified in spec. The supported TCP options are: mss (maximum segment size), window (tcp window advertisement), sack (selective ack), ts (rfc1323 timestamp) and cc (rfc1644 t/tcp connection count). The absence of a particular option may be denoted with a `!'. established TCP packets only. Match packets that have the RST or ACK bits set. setup TCP packets only. Match packets that have the SYN bit set but no ACK bit. tcpflags spec TCP packets only. Match if the TCP header contains the comma separated list of flags specified in spec. The supported TCP flags are: fin, syn, rst, psh, ack and urg. The absence of a particular flag may be denoted with a `!'. A rule which contains a tcpflags specification can never match a fragmented packet which has a non-zero offset. See the frag option for details on matching fragmented packets. DSCP color values as defined in [49]. Exact matching of DSCP values is required (no masks or ranges). the "deny" can replace the color_under or color_over values in the meter action for rate- dependent packet drop. metering The metering option provides Assured Forwarding, as defined in [50], and MUST be present if the action is set to meter. The rate option is the throughput, in bits per second, which is used by the access device to mark packets. Traffic above the rate is marked with the color_over codepoint, while traffic under the rate is marked with the color_under codepoint. The color_under and color_over options contain the drop preferences, and MUST conform to the recommended codepoint keywords described in [50] (e.g. AF13). The metering option also supports the strict limit on traffic required by Expedited Forwarding, as defined in [51]. The color_over option may contain the keyword "drop" to prevent forwarding of traffic that exceeds the rate parameter. icmptypes types ICMP packets only. Match if the ICMP type is in the list types. The list may be specified as any combination of ranges or individual types separated by commas. The supported ICMP types are: echo reply (0), destination unreachable (3), source quench (4), redirect (5), echo request (8), router advertisement (9), router solicitation (10), time-to-live exceeded (11), IP header bad (12), timestamp request (13), timestamp reply (14), information request (15), information reply (16), address mask request (17) and address mask reply (18). There is one kind of packet that the access device MUST always discard, that is an IP fragment with a fragment offset of one. This is a valid packet, but it only has one use, to try to circumvent firewalls. An access device that is unable to interpret or apply a deny rule MUST terminate the session. An access device that is unable to interpret or apply a permit rule MAY apply a more restrictive rule. An access device MAY apply deny rules of its own before the supplied rules, for example to protect the access device owner's infrastructure. The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the ipfw.c code may provide a useful base for implementations. [...] [49] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers," RFC 2474, December 1998. [50] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured For- warding PHB Group," RFC 2597, June 1999. [51] V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forwarding PHB", RFC 2598, June 1999. From owner-aaa-wg@merit.edu Thu Jun 28 19:39:36 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22943 for ; Thu, 28 Jun 2001 19:39:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2617591288; Thu, 28 Jun 2001 19:39:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EDE1391289; Thu, 28 Jun 2001 19:39:29 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F01E191288 for ; Thu, 28 Jun 2001 19:39:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5D8A75DE0B; Thu, 28 Jun 2001 19:40:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from tp.databus.com (p101-46.acedsl.com [160.79.101.46]) by segue.merit.edu (Postfix) with ESMTP id B945C5DE06 for ; Thu, 28 Jun 2001 19:40:34 -0400 (EDT) Received: (from barney@localhost) by tp.databus.com (8.11.4/8.11.4) id f5SNdlD58221 for aaa-wg@merit.edu; Thu, 28 Jun 2001 19:39:47 -0400 (EDT) (envelope-from barney) Date: Thu, 28 Jun 2001 19:39:43 -0400 From: Barney Wolff To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 87: Move filter-rule AVP to base Message-ID: <20010628193943.A58185@tp.databus.com> References: <20010628142506.Q22915@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010628142506.Q22915@charizard.diameter.org>; from pcalhoun@diameter.org on Thu, Jun 28, 2001 at 02:25:06PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Now that fancy metering features have been added, we must specify the behavior of the access device if it does not support such advanced functionality. Barney From owner-aaa-wg@merit.edu Thu Jun 28 20:14:09 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16959 for ; Thu, 28 Jun 2001 20:14:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AE0539121F; Thu, 28 Jun 2001 20:14:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 800A391222; Thu, 28 Jun 2001 20:14:14 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5F65B9121F for ; Thu, 28 Jun 2001 20:14:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BE4005DE10; Thu, 28 Jun 2001 20:15:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 38C5A5DDB6 for ; Thu, 28 Jun 2001 20:15:19 -0400 (EDT) Received: (qmail 19074 invoked by uid 500); 29 Jun 2001 00:03:06 -0000 Date: Thu, 28 Jun 2001 17:03:06 -0700 From: Pat Calhoun To: Barney Wolff Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 87: Move filter-rule AVP to base Message-ID: <20010628170306.W22915@charizard.diameter.org> Mail-Followup-To: Barney Wolff , aaa-wg@merit.edu References: <20010628142506.Q22915@charizard.diameter.org> <20010628193943.A58185@tp.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010628193943.A58185@tp.databus.com>; from barney@databus.com on Thu, Jun 28, 2001 at 07:39:43PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, Jun 28, 2001 at 07:39:43PM -0400, Barney Wolff wrote: > Now that fancy metering features have been added, we must specify > the behavior of the access device if it does not support such > advanced functionality. I'm not sure we do. The RFCs referenced go out of their way to define how metering is done. I see no reason why the AAA WG needs to worry about that (just like we don't discuss how tunneling is done). PatC From owner-aaa-wg@merit.edu Thu Jun 28 20:37:26 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA03461 for ; Thu, 28 Jun 2001 20:37:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9AD4391221; Thu, 28 Jun 2001 20:37:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6EE92912C6; Thu, 28 Jun 2001 20:37:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5443A91221 for ; Thu, 28 Jun 2001 20:37:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D1E6C5DE13; Thu, 28 Jun 2001 20:38:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 2DAB55DDB6 for ; Thu, 28 Jun 2001 20:38:38 -0400 (EDT) Received: (qmail 19136 invoked by uid 500); 29 Jun 2001 00:26:25 -0000 Date: Thu, 28 Jun 2001 17:26:25 -0700 From: Pat Calhoun To: "Martin Julien (ECE)" , "'Pat Calhoun'" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Issue 91: MIP SPI Message-ID: <20010628172625.X22915@charizard.diameter.org> Mail-Followup-To: "Martin Julien (ECE)" , 'Pat Calhoun' , "'aaa-wg@merit.edu'" References: <577066326047D41180AC00508B955DDA04D1A9D8@eestqnt104.es.eu.ericsson.se> <20010628063304.I22915@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010628063304.I22915@charizard.diameter.org>; from pcalhoun@diameter.org on Thu, Jun 28, 2001 at 06:33:04AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk > > So, if I understand correctly, you are suggesting that the AAA > > re-use the Preferred-SPI received in the AMR, right? In the case, > > they are not received, then the AAA should generate a random > > 32bits long SPI outside the range of the reserved SPI by IANA, right? > > correct > > > > > The problem here is that we are assuming that we are lucky enough to > > not re-use an already defined SPI between the HA-FA, HA-MN and FA-MN. > > I must admit that the chance is not great, but still there, unnecessarily. > > Well, we have to play a probability game here, but with 2^32, the chances > are quite small, even more so if one actually binds the SPI to the destination > address. > > > > > > To address your other question, no we do not touch the > > > reserved SPIs defined by > > > IANA. > > > > OK, then the SPI MUST be outside the range of pre-defined SPIs > > from IANA. Can you make that clear in the draft? > > ok. I have added a sentence to the end of the paragraph below: 6.2.5 MIP-Peer-SPI AVP The MIP-Peer-SPI AVP (AVP Code 342) is of type Unsigned32, and contains the Security Parameter Index to use to reference the key in the associated MIP-Session-Key AVP. The SPI created MUST NOT be a value between zero (0) and 255, which is the reserved namespace defined in [4]. > > That means that HA would be responsible of the SPI field of the > > "Unsolicited MN-HA Key from AAA Subtype" and the "Unsolicited MN-FA Key > > from AAA Subtype". The Preferred-SPI AVPs would become obsolete, since > > the HA could extract directly that information from the Registration > > message. Furthermore, the FA does not need to suggest an SPI, since the > > HA would know the SPI available for the SA with the FA, if it receives > > the MIP-Foreign-Agent-Host AVP. The HA would need to return the selected > > SPIs for the FA-HA and the FA-MN Session key AVPs, so that the AAA can return > > them to the FA in a secured manner, if required. > > > > Does that make sense or not? > > ok, so the Diameter draft could state that the AAAH still inserts an SPI, but > the HA is allowed to override that value if it is deemed necessary. Would this > work? But if the HA doesn't like the SPI assigned for the FA-HA, how could it change the SPI and inform the AAAH? I believe that if the HA could simply refuse the request with an error such as "BAD SPI", and include the Peer-SPI in an AVP, then the AAAH could try again with a new SPI. This would lead to multiple round trips between the AAAH and the HA when such an error occurs, but again, the probability is quite low, considering we have 2^32 to play with (and SPIs are bound to destination addresses). > > That seems to contradicts what you were saying earlier about the > > need for the AAA to generate new SPIs, right?, or am I understanding > > you wrong? > > Not sure. I think that the Preferred-SPIs MUST be present for key request, > since the SPIs are present in the MIP Key Request extension, so it is > trivial for an FA to include these values in the Diameter message. I think > that we should mandate that the FA include these values. What do you think? I have added sentences to the end of all of the following paragraphs: 4.7 MIP-Feature-Vector AVP [...] Whenever the Foreign Agent sets either the Mobile-Node-Home-Address- Requested flag or the Home-Agent-Request flag to one, it MUST set the MN-HA-Key-Request flag to one. The MN-HA-Key-Request flag is also set to one if the mobile node includes a Generalized MN-HA Key Request [15] extension, with the subtype set to AAA. If set, the MIP-MN-HA- Preferred-SPI AVP MUST be present. If the mobile node includes a Generalized MN-FA Key Request [15] extension with the AAA subtype in its Registration Request, the Foreign Agent sets the MN-FA-Key-Request flag to one in the MIP- Feature-Vector AVP. If set, the MIP-FA-MN-Preferred-SPI AVP MUST be present. [...] If the Foreign Agent's local policy allows it to receive AAA Session Keys, and it does not have any existing keys with the Home Agent, it MAY set the FA-HA-Key-Request flag. If set, the MIP-FA-HA-Preferred- SPI AVP MUST be present. and just for clarity, I have added a sentence to the end of the paragraph: 6.5 MIP-MN-HA-Preferred-SPI AVP The MIP-MN-HA-Preferred-SPI AVP (AVP Code 323) is of type Unsigned32 and is sent in the AA-Mobile-Node-Request by the Foreign Agent. The AVP contains the SPI that the Mobile Node would prefer to have assigned by the AAAH in the MIP-MN-to-HA-Key AVP, taken from the Generalized MN-HA Key Request [15] extension. Is this better? PatC From owner-aaa-wg@merit.edu Thu Jun 28 21:25:11 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA07067 for ; Thu, 28 Jun 2001 21:25:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 94E46912C5; Thu, 28 Jun 2001 21:25:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6E1829128D; Thu, 28 Jun 2001 21:25:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 868949128C for ; Thu, 28 Jun 2001 21:25:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C43335DE1A; Thu, 28 Jun 2001 21:26:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from tp.databus.com (p101-46.acedsl.com [160.79.101.46]) by segue.merit.edu (Postfix) with ESMTP id 991F55DE06 for ; Thu, 28 Jun 2001 21:26:10 -0400 (EDT) Received: (from barney@localhost) by tp.databus.com (8.11.4/8.11.4) id f5T1PNU58966 for aaa-wg@merit.edu; Thu, 28 Jun 2001 21:25:23 -0400 (EDT) (envelope-from barney) Date: Thu, 28 Jun 2001 21:25:19 -0400 From: Barney Wolff To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 87: Move filter-rule AVP to base Message-ID: <20010628212519.A58869@tp.databus.com> References: <20010628142506.Q22915@charizard.diameter.org> <20010628193943.A58185@tp.databus.com> <20010628170306.W22915@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010628170306.W22915@charizard.diameter.org>; from pcalhoun@diameter.org on Thu, Jun 28, 2001 at 05:03:06PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk I'm confused. You mean that support for those two RFCs is now mandatory? For all access devices or only those that support Diameter? If not, then what should the access device do with a filter rule that instructs it to meter? We've said what to do if you can't exactly implement a drop or permit filter rule, how is this different? Barney On Thu, Jun 28, 2001 at 05:03:06PM -0700, Pat Calhoun wrote: > On Thu, Jun 28, 2001 at 07:39:43PM -0400, Barney Wolff wrote: > > Now that fancy metering features have been added, we must specify > > the behavior of the access device if it does not support such > > advanced functionality. > > I'm not sure we do. The RFCs referenced go out of their way to > define how metering is done. I see no reason why the AAA WG needs > to worry about that (just like we don't discuss how tunneling is > done). > > PatC From owner-aaa-wg@merit.edu Fri Jun 29 01:45:17 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA09741 for ; Fri, 29 Jun 2001 01:45:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7CF989128F; Fri, 29 Jun 2001 01:44:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4C73B912CD; Fri, 29 Jun 2001 01:44:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 588289128F for ; Fri, 29 Jun 2001 01:44:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4961E5DE30; Fri, 29 Jun 2001 01:45:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 9B2825DE2E for ; Fri, 29 Jun 2001 01:45:35 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id WAA26117; Thu, 28 Jun 2001 22:37:56 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Thu, 28 Jun 2001 22:37:56 -0700 (PDT) From: Bernard Aboba To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 87: Move filter-rule AVP to base In-Reply-To: <20010628142506.Q22915@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk A comment. I think you also need to accomodate Layer 2 filters based on MAC address, Ethertype, etc. Remember, AAA is now implemented on otherwise purely Layer 2 devices. From owner-aaa-wg@merit.edu Fri Jun 29 01:49:31 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA12563 for ; Fri, 29 Jun 2001 01:49:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 38E6A91290; Fri, 29 Jun 2001 01:49:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0E6E4912C8; Fri, 29 Jun 2001 01:49:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0A85E91290 for ; Fri, 29 Jun 2001 01:49:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F0C555DE2E; Fri, 29 Jun 2001 01:50:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 1EED15DDBB for ; Fri, 29 Jun 2001 01:50:38 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id WAA26124; Thu, 28 Jun 2001 22:42:55 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Thu, 28 Jun 2001 22:42:55 -0700 (PDT) From: Bernard Aboba To: David Spence Cc: Pat Calhoun , Jonathan Wood , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Comments on draft-ietf-aaa-transport-03.txt In-Reply-To: <3B3AA903.5ECB646@Interlinknetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk File an issue on this and include the recommended text. Anyone else with an issue to file on transport-04, please get them in ASAP, so I can make the changes by the deadline. From owner-aaa-wg@merit.edu Fri Jun 29 03:13:06 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA17168 for ; Fri, 29 Jun 2001 03:13:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EEFF491225; Fri, 29 Jun 2001 03:13:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B0D43912C9; Fri, 29 Jun 2001 03:13:00 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D59F591225 for ; Fri, 29 Jun 2001 03:12:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C756E5DE79; Fri, 29 Jun 2001 03:14:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id E84995DE77 for ; Fri, 29 Jun 2001 03:14:04 -0400 (EDT) Received: from fredrikj (sierra.local.ipunplugged.com [192.168.4.88]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id JAA11191; Fri, 29 Jun 2001 09:14:47 +0200 From: "Fredrik Johansson" To: "Paul Funk" , "Mark Eklund" , "Jacques Caron" Cc: Subject: RE: [AAA-WG]: Issue 93. End-to-End identifier Date: Fri, 29 Jun 2001 09:14:30 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <4.1.20010628135244.01be6a40@cairo.funk.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Paul, see comments below /Fredrik >-----Original Message----- >From: Paul Funk [mailto:paul@funk.com] >Sent: den 28 juni 2001 20:18 >To: Fredrik Johansson; Mark Eklund; Jacques Caron >Cc: aaa-wg@merit.edu >Subject: Re: [AAA-WG]: Issue 93. End-to-End identifier > > >Fredrik, > >I think there's some misunderstanding as to how the End-To-End Identifier >is used. > >The End-To-End Identifiers are, by definition, not hop-by-hop, so >there's no >guarantee that a server will receive them in any particular >sequence. A server >may get messages wildly out of order from the same client, because >they are >routed through different proxies. I'm aware that the e2e identifier is from the origin host and that it can not be guaranteed to be received in order, that's why I believe that it would be easier to keep a caching window of monotonically increased numbers (you can even make the implementation smart and store sequences of received e2e identifiers in the window). If the identifier is monotonically increasing it makes it easier to maintain the window. By keeping a window you limit the number of e2e identifiers that you need to save, if you receive something the the left of the window you have to try to figure out if it can be a new request (wrap around on the identifier) or if it's a old request. A new one is ofcourse processed and a old is discarded. > >My understanding of how it's supposed to be used is this: A server would >keep a cache of answers by Origin-Host + End-To-End Identifier. If a >new request arrives that's already in the cache, instead of processing the >request normally, it just sends back the same answer. How to manage >(or whether to even provide) such a cache would be implementation >dependent. By host I mean Origin-Host. Why do you have to send back the same answer, if it something you already processed once you'll have sent an answer. And since we have reliable transport we should be able to assume that it reaches the Origin-host of the request. The windowing mechanism can be made implementation specific, however a monotonically increased identifier makes it easier to optimize such a solution. Is it reasonable to save all answers for all clients for all e2e identifiers?!? That'll take alot of memory > >The problem this solves is that if a proxy goes down, pending >requests will >be rerouted to another proxy. The home server will thus receive >two identical >requests in unknown order; that is, it can't tell which request >came over the >good path and which came over the bad. Therefore it should respond to both >identically. > >I do think that the language for End-To-End-Identifier should mirror more >closely the language for Hop-By-Hop Identifier, to indicate that it is >typically randomly initialized and incremented, etc. But it need not be >monotonically increased and there can't be a window. Ok, there doesn't have to be a window, but somehow you probably would like to limit the amount of memory taken in your implementation and a window would do that. > >Paul > > >At 06:31 PM 6/28/01 +0200, Fredrik Johansson wrote: >>Submitter name: Fredrik Johansson >>Submitter email address: fredrik@ipunplugged.com >>Date first submitted: 28-Jun-2001 >>Reference: >>Document: base-06 >>Comment type: T >>Priority: S >>Section: 3.0, >>Rationale/Explanation of issue: >> >>The end-to-end identifier is not monotonically increasing, thus >it requires >>a server to save all identifers on a per host basis to be able to >see if the >>message has been received before. Some describing text is also missing on >>how a server should treat a message that it has received before. >> >>Requested change: >> >>Make the e-2-e identifier monotonically increasing and suggest that the >>server stores the identifiers in the same manner as done in AH (section >>3.4.3 in RFC 2402) but with a suggested value of 128 as default window. >> >>Also, add some text describing what a server should do when the e-2-e >>identifier has been seen before. e.g. discard it or reply with the same >>answer as last time. >> >>/Fredrik > >Paul Funk >Funk Software, Inc. >617 497-6339 >paul@funk.com From owner-aaa-wg@merit.edu Fri Jun 29 03:17:34 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20283 for ; Fri, 29 Jun 2001 03:17:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4305E91291; Fri, 29 Jun 2001 03:17:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0C948912C9; Fri, 29 Jun 2001 03:17:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D63DB91291 for ; Fri, 29 Jun 2001 03:17:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CFB035DE2E; Fri, 29 Jun 2001 03:18:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id E42A65DDB6 for ; Fri, 29 Jun 2001 03:18:41 -0400 (EDT) Received: from fredrikj (sierra.local.ipunplugged.com [192.168.4.88]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id JAA11276; Fri, 29 Jun 2001 09:19:31 +0200 From: "Fredrik Johansson" To: "Mark Eklund" , "Jacques Caron" Cc: "AAA Listan" Subject: RE: [AAA-WG]: Issue 93. End-to-End identifier Date: Fri, 29 Jun 2001 09:19:15 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > >On Thu, 28 Jun 2001, Jacques Caron wrote: > >> At 18:31 28/06/01, Fredrik Johansson wrote: >> >Also, add some text describing what a server should do when the e-2-e >> >identifier has been seen before. e.g. discard it or reply with the same >> >answer as last time. >> >> Should reply with the same answer, not discard it. The only >issue is that >> it should not do the same processing again, if that has >"consequences" on >> anything (e.g. not store an accounting record a second time). > >So, am I interpreting this right? A server that serves 100 >clients and has a window of 128 will have to remember how it >replied for 12800 packets? Sound like alot of answers to save, I'm not sure (probably don't understand, so someone please enlighten me) why you have to reply with the same answer. If it's an request you already answered to why just not drop it? > >What if it receives something below the window? Do you just >drop the packet, or make up a best guess for the reply? I guess you have to try to figure out if it can be a wrap around in the e2e identifier or if it's an old one. No matter how you define the e2e identifier (monotonically increased or just increased) you will have to take care of the wrap around. With a monotonically increased identifier you'll encounter the problem less often. /Fredrik > >-mark > >> >> Jacques. >> >> >> _________________________________________________________ >> Do You Yahoo!? >> Get your free @yahoo.com address at http://mail.yahoo.com >> > From owner-aaa-wg@merit.edu Fri Jun 29 03:59:03 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18974 for ; Fri, 29 Jun 2001 03:59:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0499A91292; Fri, 29 Jun 2001 03:59:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C44D7912C9; Fri, 29 Jun 2001 03:59:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A405191292 for ; Fri, 29 Jun 2001 03:59:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 551CE5DE33; Fri, 29 Jun 2001 04:00:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 4465B5DE30 for ; Fri, 29 Jun 2001 04:00:11 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f5T7xMN23364 for ; Fri, 29 Jun 2001 09:59:22 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Fri Jun 29 09:59:22 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Jun 2001 09:59:20 +0200 Message-ID: <577066326047D41180AC00508B955DDA04D1A9E4@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Pat Calhoun'" , "Martin Julien (ECE)" Cc: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Issue 91: MIP SPI Date: Fri, 29 Jun 2001 09:59:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk > > The easy solution would be to leave that selection of the SPIs to > > the HA, since the AAA does not really care about it. In > fact, the AAA > > can still put everything it requires for security, in terms > of algorithms, > > replay-mode, key material, but should not care about the > SPI. That would > > mean that the HA would become responsible for looking at > the Registration > > message, extract the Preferred-SPI itself from the MN, and > select the SPI and create > > a new one. The thing is that the HA is the one that owns > the SA with the > > MN and the HA, right? I don't see the point for the AAA to > take a chance > > by chosing one that can possibly not be a valid one for the > HA's SAs? > > This is a possibility. > And that is my favorite option. The HA would select a SPI for the MN-HA SA and the FA-HA SA. The thing is that it is not so easy for the FA to suggest a Preferred HA-FA SPI, since it might not know the HA yet, since it needs to be allocated by the AAAH. The HA-FA SPI, allocated by the HA, could be returned in the HAA, to inform the AAAH about it, so that it can include it in the FA-HA Key AVP destined to the FA. In that example, there is no need for a Preferred HA-FA SPI, neither for a Preferred HA-MN SPI, right? The FA would then be responsible for allocating the SPI of the SA between the FA and the MN. In the AMR, the FA would include the allocated FA-MN SPI for the AAAF to keep the SPI value, in case it supports returning an existing set of Session keys a new FA, when the MN is roaming. In that example, there is no need for a Preferred MN-FA SPI, right? > > That means that HA would be responsible of the SPI field of the > > "Unsolicited MN-HA Key from AAA Subtype" and the > "Unsolicited MN-FA Key > > from AAA Subtype". The Preferred-SPI AVPs would become > obsolete, since > > the HA could extract directly that information from the > Registration > > message. Furthermore, the FA does not need to suggest an > SPI, since the > > HA would know the SPI available for the SA with the FA, if > it receives > > the MIP-Foreign-Agent-Host AVP. The HA would need to return > the selected > > SPIs for the FA-HA and the FA-MN Session key AVPs, so that > the AAA can return > > them to the FA in a secured manner, if required. > > > > Does that make sense or not? > > ok, so the Diameter draft could state that the AAAH still > inserts an SPI, but > the HA is allowed to override that value if it is deemed > necessary. Would this > work? I think so, but I still do not see the need for the AAAH to be involved at all in that allocation, not even in forwarding the Preferred-SPI. > > > > Of course, the AAA can count on the Preferred-SPI from the FA > > > > and the MN, in which case the AAA simply agrees with the > > > value. However, > > > > if there is no Preferred-SPI AVPs in the AMR, then the > AAAH needs to > > > > generate > > > > them, at the risk that they might already be used in the SA > > > defined between > > > > the MN and the HA, or between the HA and the FA, or between > > > the FA and the > > > > MN. > > > > I think that it makes more sense for the HA to select the > > > required SPI > > > > between > > > > the HA-MN and HA-FA, if no Preferred-SPI is included in the AMR. > > > > > > No, IMHO, if not Preferred-SPI is present, then no key is > > > generated. So, > > > perhaps some associated text in the Feature-Vector is needed? > > > > That seems to contradicts what you were saying earlier about the > > need for the AAA to generate new SPIs, right?, or am I understanding > > you wrong? > > Not sure. I think that the Preferred-SPIs MUST be present for > key request, > since the SPIs are present in the MIP Key Request extension, so it is > trivial for an FA to include these values in the Diameter > message. I think > that we should mandate that the FA include these values. What > do you think? But maybe not the HA-FA SPI, in the case where you do not know the HA yet? > > PatC > It depends if you agree with me that the Preferred-SPI AVPs are not required. I think we could use them, but since I don't see them very useful, I think it would simplify the protocol to remove them and use an alternative solution, which can never be wrong. Maybe you're thinking of something I have not realized yet, though? Martin From owner-aaa-wg@merit.edu Fri Jun 29 05:16:26 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA12065 for ; Fri, 29 Jun 2001 05:16:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9B6B7912CA; Fri, 29 Jun 2001 05:16:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D4728912C9; Fri, 29 Jun 2001 05:16:25 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3A119912CB for ; Fri, 29 Jun 2001 05:16:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6887E5DDBF; Fri, 29 Jun 2001 05:17:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by segue.merit.edu (Postfix) with SMTP id E37F75DD92 for ; Fri, 29 Jun 2001 05:17:24 -0400 (EDT) Received: from pc225.etc.psi.com (HELO jc.yahoo.com) (195.94.40.225) by smtp.mail.vip.sc5.yahoo.com with SMTP; 29 Jun 2001 09:16:35 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010629111116.00c63380@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 29 Jun 2001 11:12:30 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 87: Move filter-rule AVP to base Cc: Barney Wolff , aaa-wg@merit.edu In-Reply-To: <20010628170306.W22915@charizard.diameter.org> References: <20010628193943.A58185@tp.databus.com> <20010628142506.Q22915@charizard.diameter.org> <20010628193943.A58185@tp.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Mmmm... Stupid question: if a device receives an 'M'-AVP it doesn't know, it sends back an error. Shouldn't there be an error also if a device receives an 'M'-AVP it doesn't *understand*, i.e. it knows the AVP but doesn't understand its contents/format? Jacques. At 02:03 29/06/01, Pat Calhoun wrote: >On Thu, Jun 28, 2001 at 07:39:43PM -0400, Barney Wolff wrote: > > Now that fancy metering features have been added, we must specify > > the behavior of the access device if it does not support such > > advanced functionality. > >I'm not sure we do. The RFCs referenced go out of their way to >define how metering is done. I see no reason why the AAA WG needs >to worry about that (just like we don't discuss how tunneling is >done). > >PatC _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Fri Jun 29 05:41:14 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29184 for ; Fri, 29 Jun 2001 05:41:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E00B3912C9; Fri, 29 Jun 2001 05:41:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B386E912CB; Fri, 29 Jun 2001 05:41:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9165A912C9 for ; Fri, 29 Jun 2001 05:41:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BD5DC5DDC1; Fri, 29 Jun 2001 05:42:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp010.mail.yahoo.com (smtp010.mail.yahoo.com [216.136.173.30]) by segue.merit.edu (Postfix) with SMTP id 37B2E5DDBF for ; Fri, 29 Jun 2001 05:42:25 -0400 (EDT) Received: from pc225.etc.psi.com (HELO jc.yahoo.com) (195.94.40.225) by smtp.mail.vip.sc5.yahoo.com with SMTP; 29 Jun 2001 09:41:36 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010629111235.00c507f0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 29 Jun 2001 11:36:45 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 87: Move filter-rule AVP to base Cc: aaa-wg@merit.edu In-Reply-To: <20010628142506.Q22915@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, Nice. Shouldn't the rate in the "meter" action also include burst/exess burst (e.g. Bc/Be) to perfectly define the rate? Also you might want to include a simple "permit" (with no color or anything). Also, I'm not sure all the QoS stuff actually belongs there. In many cases, one wants QoS based on a filter-set, not a single filter-rule. Maybe keeping the original FilterRule syntax, but then adding a specific QoSRule syntax that refences a set of FilterRules to then perform the metering would be better? This would require to have a way to identify filters (= sets of FilterRules), and to specify which are used for filtering, and which are used for other (QoS) purposes. Alternatively, you might want to include a "meter number" in the metering rules, so that multiple rules can use the same meter (token bucket) to measure multiple types of traffic... Also, if we're into QoS, what about traffic-shaping? BTW, how are multiple rules specified? Multiple AVPs, or multiple rules within the same AVP (separated with \n maybe)? This isn't clear in the description. Good luck! Jacques. At 23:25 28/06/01, Pat Calhoun wrote: >All, > >Here is the proposed text for Issue 87. The main difference here is support >for QoS filters. > >Comments appreciated, > >PatC >---- > > FilterRule > The FilterRule format is derived from the OctetString AVP Base > Format. It uses the UTF-8 encoding and has the same > requirements as the UTF8String. Packets may be filtered based > on the following information that is associated with it: > > Direction (in or out) > Source and destination IP address (possibly masked) > Protocol > Source and destination port (lists or ranges) > TCP flags > IP fragment flag > IP options > DSCP values (no mask or range) > ICMP types > > Rules for the appropriate direction are evaluated in order, > with the first matched rule terminating the evaluation. Each > packet is evaluated once. If no rule matches, the packet is > dropped if the last rule evaluated was a permit, and passed if > the last rule was a deny. > > The filters in the Filter-Rule AVP MUST follow the format: > > action dir proto from src to dst [options] > > action permit - Allow packets that match the rule. > deny - Drop packets that match the rule. > tag - Mark packet with a specific DSCP [49]. > The DSCP option MUST be included. > meter - Meter traffic. The metering options > MUST be included. > > dir "in" is from the terminal, "out" is to the > terminal. > > proto An IP protocol specified by number. The "ip" > keyword means any protocol will match. > > src and dst
[ports] > > The
may be specified as: > ipno An IPv4 or IPv6 number in dotted- > quad or canonical IPv6 form. Only > this exact IP number will match the > rule. > ipno/bits An IP number as above with a mask > width of the form 1.2.3.4/24. In > this case all IP numbers from > 1.2.3.0 to 1.2.3.255 will match. > The bit width MUST be valid for the > IP version and the IP number MUST > NOT have bits set beyond the mask. > > The sense of the match can be inverted by > preceding an address with the not modifier, > causing all other addresses to be matched > instead. This does not affect the selection of > port numbers. > > The keyword "any" is 0.0.0.0/0 or the IPv6 > equivalent. The keyword "assigned" is the > address or set of addresses assigned to the > terminal. The first rule SHOULD be "deny in > ip !assigned". > > With the TCP and UDP protocols, optional ports > may be specified as: > > {port|port-port}[,port[,...]] > > The `-' notation specifies a range of ports > (including boundaries). > > Fragmented packets which have a non-zero offset > (i.e. not the first fragment) will never match > a rule which has one or more port > specifications. See the frag option for > details on matching fragmented packets. > > options: > frag Match if the packet is a fragment and this is not > the first fragment of the datagram. frag may not > be used in conjunction with either tcpflags or > TCP/UDP port specifications. > > ipoptions spec > Match if the IP header contains the comma > separated list of options specified in spec. The > supported IP options are: > > ssrr (strict source route), lsrr (loose source > route), rr (record packet route) and ts > (timestamp). The absence of a particular option > may be denoted with a `!'. > > tcpoptions spec > Match if the TCP header contains the comma > separated list of options specified in spec. The > supported TCP options are: > > mss (maximum segment size), window (tcp window > advertisement), sack (selective ack), ts (rfc1323 > timestamp) and cc (rfc1644 t/tcp connection > count). The absence of a particular option may > be denoted with a `!'. > > established > TCP packets only. Match packets that have the RST > or ACK bits set. > > setup TCP packets only. Match packets that have the SYN > bit set but no ACK bit. > > tcpflags spec > TCP packets only. Match if the TCP header > contains the comma separated list of flags > specified in spec. The supported TCP flags are: > > fin, syn, rst, psh, ack and urg. The absence of a > particular flag may be denoted with a `!'. A rule > which contains a tcpflags specification can never > match a fragmented packet which has a non-zero > offset. See the frag option for details on > matching fragmented packets. > > DSCP > color values as defined in [49]. Exact matching > of DSCP values is required (no masks or ranges). > the "deny" can replace the color_under or > color_over values in the meter action for rate- > dependent packet drop. > > metering > The metering option provides Assured Forwarding, > as defined in [50], and MUST be present if the > action is set to meter. The rate option is the > throughput, in bits per second, which is used by > the access device to mark packets. Traffic above > the rate is marked with the color_over codepoint, > while traffic under the rate is marked with the > color_under codepoint. The color_under and > color_over options contain the drop preferences, > and MUST conform to the recommended codepoint > keywords described in [50] (e.g. AF13). > > The metering option also supports the strict > limit on traffic required by Expedited > Forwarding, as defined in [51]. The color_over > option may contain the keyword "drop" to prevent > forwarding of traffic that exceeds the rate > parameter. > > icmptypes types > ICMP packets only. Match if the ICMP type is in > the list types. The list may be specified as any > combination of ranges or individual types > separated by commas. The supported ICMP types > are: > > echo reply (0), destination unreachable (3), > source quench (4), redirect (5), echo request > (8), router advertisement (9), router > solicitation (10), time-to-live exceeded (11), IP > header bad (12), timestamp request (13), > timestamp reply (14), information request (15), > information reply (16), address mask request (17) > and address mask reply (18). > > There is one kind of packet that the access device MUST always > discard, that is an IP fragment with a fragment offset of one. > This is a valid packet, but it only has one use, to try to > circumvent firewalls. > > An access device that is unable to interpret or apply a deny > rule MUST terminate the session. An access device that is > unable to interpret or apply a permit rule MAY apply a more > restrictive rule. An access device MAY apply deny rules of > its own before the supplied rules, for example to protect > the access device owner's infrastructure. > > The rule syntax is a modified subset of ipfw(8) from FreeBSD, > and the ipfw.c code may provide a useful base for > implementations. > >[...] > [49] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the > Differentiated Services Field (DS Field) in the IPv4 and IPv6 > Headers," RFC 2474, December 1998. > > [50] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured For- > warding PHB Group," RFC 2597, June 1999. > > [51] V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forwarding > PHB", RFC 2598, June 1999. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Fri Jun 29 05:56:22 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09806 for ; Fri, 29 Jun 2001 05:56:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1CD47912CB; Fri, 29 Jun 2001 05:56:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E6839912CC; Fri, 29 Jun 2001 05:56:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C45AE912CB for ; Fri, 29 Jun 2001 05:56:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 00BF85DDFD; Fri, 29 Jun 2001 05:57:26 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by segue.merit.edu (Postfix) with SMTP id 7A8C05DDC1 for ; Fri, 29 Jun 2001 05:57:25 -0400 (EDT) Received: from pc225.etc.psi.com (HELO jc.yahoo.com) (195.94.40.225) by smtp.mail.vip.sc5.yahoo.com with SMTP; 29 Jun 2001 09:56:36 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010629114112.00cbb5c0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 29 Jun 2001 11:54:41 +0200 To: "Fredrik Johansson" From: Jacques Caron Subject: RE: [AAA-WG]: Issue 93. End-to-End identifier Cc: "Mark Eklund" , "AAA Listan" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 09:19 29/06/01, Fredrik Johansson wrote: >Sound like alot of answers to save, I'm not sure (probably don't understand, >so someone please enlighten me) why you have to reply with the same answer. >If it's an request you already answered to why just not drop it? In your previous mail, you said "since we have reliable transport we should be able to assume that it reaches the Origin-host of the request". That is not true: we have reliable hop-by-hop transport, not reliable end-to-end transport (the end-to-end reliability is provided by Diameter's Request/Answer mechanism, not the transport). If a link/host goes down between the request and the answer (not very plausible given the times we're talking about, but it might happen), then the answer is lost. At some point, somebody will send the request on an alternate path, and the server will receive it again. It should know that it's a request it already got, and act accordingly. Actually, it is important that any actions it takes that do have an effect (e.g. storing accounting) are not taken again, and it seems obvious it needs to answer the same thing, but this could be "reconstructed" rather than cached. BTW, all of this really raises having a "Diameter transport" part that would really be like TCP over multiple TCP hops :-) Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Fri Jun 29 09:09:21 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20314 for ; Fri, 29 Jun 2001 09:09:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AC5AC912CC; Fri, 29 Jun 2001 09:08:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 79C7E912CD; Fri, 29 Jun 2001 09:08:41 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 51905912CC for ; Fri, 29 Jun 2001 09:08:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C2B235DE1E; Fri, 29 Jun 2001 09:09:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id AF9635DDFD for ; Fri, 29 Jun 2001 09:09:46 -0400 (EDT) Received: (qmail 23973 invoked by uid 500); 29 Jun 2001 12:57:30 -0000 Date: Fri, 29 Jun 2001 05:57:30 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 87: Move filter-rule AVP to base Message-ID: <20010629055730.C23402@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <20010628142506.Q22915@charizard.diameter.org> <4.3.2.7.2.20010629111235.00c507f0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010629111235.00c507f0@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Fri, Jun 29, 2001 at 11:36:45AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Fri, Jun 29, 2001 at 11:36:45AM +0200, Jacques Caron wrote: > Hi, > > Nice. Shouldn't the rate in the "meter" action also include burst/exess > burst (e.g. Bc/Be) to perfectly define the rate? Also you might want to > include a simple "permit" (with no color or anything). > > Also, I'm not sure all the QoS stuff actually belongs there. In many cases, > one wants QoS based on a filter-set, not a single filter-rule. > > Maybe keeping the original FilterRule syntax, but then adding a specific > QoSRule syntax that refences a set of FilterRules to then perform the > metering would be better? This would require to have a way to identify > filters (= sets of FilterRules), and to specify which are used for > filtering, and which are used for other (QoS) purposes. > > Alternatively, you might want to include a "meter number" in the metering > rules, so that multiple rules can use the same meter (token bucket) to > measure multiple types of traffic... > > Also, if we're into QoS, what about traffic-shaping? ok, let me discuss these issues with John. Now that I've read Barney's comment, I agree that perhaps moving these out of FilterRule, and into QoSFilterRule (and perhaps renaming FilterRule to IPFilterRule) would be a good thing. This would allow an access device to reject an AVP of type QosFilterRule, if it didn't support traffic metering. Also, following Bernard's comment, it may also make sense to create the L2FilterRule type as well. Do folks generally agree with this? > > BTW, how are multiple rules specified? Multiple AVPs, or multiple rules > within the same AVP (separated with \n maybe)? This isn't clear in the > description. multiple AVPs. I'll make sure that this is clarified. > > Good luck! Why do I feel like I'll need it :( PatC > > Jacques. > > At 23:25 28/06/01, Pat Calhoun wrote: > >All, > > > >Here is the proposed text for Issue 87. The main difference here is support > >for QoS filters. > > > >Comments appreciated, > > > >PatC > >---- > > > > FilterRule > > The FilterRule format is derived from the OctetString AVP Base > > Format. It uses the UTF-8 encoding and has the same > > requirements as the UTF8String. Packets may be filtered based > > on the following information that is associated with it: > > > > Direction (in or out) > > Source and destination IP address (possibly masked) > > Protocol > > Source and destination port (lists or ranges) > > TCP flags > > IP fragment flag > > IP options > > DSCP values (no mask or range) > > ICMP types > > > > Rules for the appropriate direction are evaluated in order, > > with the first matched rule terminating the evaluation. Each > > packet is evaluated once. If no rule matches, the packet is > > dropped if the last rule evaluated was a permit, and passed if > > the last rule was a deny. > > > > The filters in the Filter-Rule AVP MUST follow the format: > > > > action dir proto from src to dst [options] > > > > action permit - Allow packets that match the rule. > > deny - Drop packets that match the rule. > > tag - Mark packet with a specific DSCP [49]. > > The DSCP option MUST be included. > > meter - Meter traffic. The metering options > > MUST be included. > > > > dir "in" is from the terminal, "out" is to the > > terminal. > > > > proto An IP protocol specified by number. The "ip" > > keyword means any protocol will match. > > > > src and dst
[ports] > > > > The
may be specified as: > > ipno An IPv4 or IPv6 number in dotted- > > quad or canonical IPv6 form. Only > > this exact IP number will match the > > rule. > > ipno/bits An IP number as above with a mask > > width of the form 1.2.3.4/24. In > > this case all IP numbers from > > 1.2.3.0 to 1.2.3.255 will match. > > The bit width MUST be valid for the > > IP version and the IP number MUST > > NOT have bits set beyond the mask. > > > > The sense of the match can be inverted by > > preceding an address with the not modifier, > > causing all other addresses to be matched > > instead. This does not affect the selection of > > port numbers. > > > > The keyword "any" is 0.0.0.0/0 or the IPv6 > > equivalent. The keyword "assigned" is the > > address or set of addresses assigned to the > > terminal. The first rule SHOULD be "deny in > > ip !assigned". > > > > With the TCP and UDP protocols, optional ports > > may be specified as: > > > > {port|port-port}[,port[,...]] > > > > The `-' notation specifies a range of ports > > (including boundaries). > > > > Fragmented packets which have a non-zero offset > > (i.e. not the first fragment) will never match > > a rule which has one or more port > > specifications. See the frag option for > > details on matching fragmented packets. > > > > options: > > frag Match if the packet is a fragment and this is not > > the first fragment of the datagram. frag may not > > be used in conjunction with either tcpflags or > > TCP/UDP port specifications. > > > > ipoptions spec > > Match if the IP header contains the comma > > separated list of options specified in spec. The > > supported IP options are: > > > > ssrr (strict source route), lsrr (loose source > > route), rr (record packet route) and ts > > (timestamp). The absence of a particular option > > may be denoted with a `!'. > > > > tcpoptions spec > > Match if the TCP header contains the comma > > separated list of options specified in spec. The > > supported TCP options are: > > > > mss (maximum segment size), window (tcp window > > advertisement), sack (selective ack), ts (rfc1323 > > timestamp) and cc (rfc1644 t/tcp connection > > count). The absence of a particular option may > > be denoted with a `!'. > > > > established > > TCP packets only. Match packets that have the RST > > or ACK bits set. > > > > setup TCP packets only. Match packets that have the SYN > > bit set but no ACK bit. > > > > tcpflags spec > > TCP packets only. Match if the TCP header > > contains the comma separated list of flags > > specified in spec. The supported TCP flags are: > > > > fin, syn, rst, psh, ack and urg. The absence of a > > particular flag may be denoted with a `!'. A rule > > which contains a tcpflags specification can never > > match a fragmented packet which has a non-zero > > offset. See the frag option for details on > > matching fragmented packets. > > > > DSCP > > color values as defined in [49]. Exact matching > > of DSCP values is required (no masks or ranges). > > the "deny" can replace the color_under or > > color_over values in the meter action for rate- > > dependent packet drop. > > > > metering > > The metering option provides Assured Forwarding, > > as defined in [50], and MUST be present if the > > action is set to meter. The rate option is the > > throughput, in bits per second, which is used by > > the access device to mark packets. Traffic above > > the rate is marked with the color_over codepoint, > > while traffic under the rate is marked with the > > color_under codepoint. The color_under and > > color_over options contain the drop preferences, > > and MUST conform to the recommended codepoint > > keywords described in [50] (e.g. AF13). > > > > The metering option also supports the strict > > limit on traffic required by Expedited > > Forwarding, as defined in [51]. The color_over > > option may contain the keyword "drop" to prevent > > forwarding of traffic that exceeds the rate > > parameter. > > > > icmptypes types > > ICMP packets only. Match if the ICMP type is in > > the list types. The list may be specified as any > > combination of ranges or individual types > > separated by commas. The supported ICMP types > > are: > > > > echo reply (0), destination unreachable (3), > > source quench (4), redirect (5), echo request > > (8), router advertisement (9), router > > solicitation (10), time-to-live exceeded (11), IP > > header bad (12), timestamp request (13), > > timestamp reply (14), information request (15), > > information reply (16), address mask request (17) > > and address mask reply (18). > > > > There is one kind of packet that the access device MUST always > > discard, that is an IP fragment with a fragment offset of one. > > This is a valid packet, but it only has one use, to try to > > circumvent firewalls. > > > > An access device that is unable to interpret or apply a deny > > rule MUST terminate the session. An access device that is > > unable to interpret or apply a permit rule MAY apply a more > > restrictive rule. An access device MAY apply deny rules of > > its own before the supplied rules, for example to protect > > the access device owner's infrastructure. > > > > The rule syntax is a modified subset of ipfw(8) from FreeBSD, > > and the ipfw.c code may provide a useful base for > > implementations. > > > >[...] > > [49] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the > > Differentiated Services Field (DS Field) in the IPv4 and IPv6 > > Headers," RFC 2474, December 1998. > > > > [50] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured For- > > warding PHB Group," RFC 2597, June 1999. > > > > [51] V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forwarding > > PHB", RFC 2598, June 1999. > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > From owner-aaa-wg@merit.edu Fri Jun 29 09:14:55 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24217 for ; Fri, 29 Jun 2001 09:14:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AAF6E912CD; Fri, 29 Jun 2001 09:14:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 74509912CE; Fri, 29 Jun 2001 09:14:49 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 502BB912CD for ; Fri, 29 Jun 2001 09:14:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BF8455DE17; Fri, 29 Jun 2001 09:15:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 9A57E5DDFD for ; Fri, 29 Jun 2001 09:15:54 -0400 (EDT) Received: (qmail 24018 invoked by uid 500); 29 Jun 2001 13:03:39 -0000 Date: Fri, 29 Jun 2001 06:03:39 -0700 From: Pat Calhoun To: Fredrik Johansson Cc: Mark Eklund , Jacques Caron , AAA Listan Subject: Re: [AAA-WG]: Issue 93. End-to-End identifier Message-ID: <20010629060339.E23402@charizard.diameter.org> Mail-Followup-To: Fredrik Johansson , Mark Eklund , Jacques Caron , AAA Listan References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from fredrik.johansson@ipunplugged.com on Fri, Jun 29, 2001 at 09:19:15AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Fri, Jun 29, 2001 at 09:19:15AM +0200, Fredrik Johansson wrote: > > > >On Thu, 28 Jun 2001, Jacques Caron wrote: > > > >> At 18:31 28/06/01, Fredrik Johansson wrote: > >> >Also, add some text describing what a server should do when the e-2-e > >> >identifier has been seen before. e.g. discard it or reply with the same > >> >answer as last time. > >> > >> Should reply with the same answer, not discard it. The only > >issue is that > >> it should not do the same processing again, if that has > >"consequences" on > >> anything (e.g. not store an accounting record a second time). > > > >So, am I interpreting this right? A server that serves 100 > >clients and has a window of 128 will have to remember how it > >replied for 12800 packets? > > Sound like alot of answers to save, I'm not sure (probably don't understand, > so someone please enlighten me) why you have to reply with the same answer. > If it's an request you already answered to why just not drop it? because if you've received the request again, chances are the answer got lost (perhaps a proxy or relay became unreachable). So, you need to send the answer again, and have two choices: 1. process the request, but make sure that the dup request doesn't cause the user to be allocated additional resources (e.g. two concurrent sessions) 2. queue all answers for n seconds. Simply return answers when a dup request is received. > > > > >What if it receives something below the window? Do you just > >drop the packet, or make up a best guess for the reply? > > I guess you have to try to figure out if it can be a wrap around in the e2e > identifier or if it's an old one. No matter how you define the e2e > identifier (monotonically increased or just increased) you will have to take > care of the wrap around. With a monotonically increased identifier you'll > encounter the problem less often. the e2e I-D still has 2^128 possible values, so that alot of requests. If we want a windowing system, then monotonically increasing is the only way, but random (and unique within the last 128 requests) works too. Seems that the former may be simpler to implement. PatC From owner-aaa-wg@merit.edu Fri Jun 29 10:30:53 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13099 for ; Fri, 29 Jun 2001 10:30:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D9AFE912D1; Fri, 29 Jun 2001 10:30:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A50C5912D3; Fri, 29 Jun 2001 10:30:48 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 82E27912D1 for ; Fri, 29 Jun 2001 10:30:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1DD0C5DDC4; Fri, 29 Jun 2001 10:31:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 3976E5DDA9 for ; Fri, 29 Jun 2001 10:31:54 -0400 (EDT) Received: from fredrikj (sierra.local.ipunplugged.com [192.168.4.88]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id QAA20740; Fri, 29 Jun 2001 16:32:38 +0200 From: "Fredrik Johansson" To: "Pat Calhoun" Cc: "Mark Eklund" , "Jacques Caron" , "AAA Listan" Subject: RE: [AAA-WG]: Issue 93. End-to-End identifier Date: Fri, 29 Jun 2001 16:32:22 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20010629060339.E23402@charizard.diameter.org> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >-----Original Message----- >From: Pat Calhoun [mailto:pcalhoun@diameter.org] >Sent: den 29 juni 2001 15:04 >To: Fredrik Johansson >Cc: Mark Eklund; Jacques Caron; AAA Listan >Subject: Re: [AAA-WG]: Issue 93. End-to-End identifier > > >On Fri, Jun 29, 2001 at 09:19:15AM +0200, Fredrik Johansson wrote: >> > >> >On Thu, 28 Jun 2001, Jacques Caron wrote: >> > >> >> At 18:31 28/06/01, Fredrik Johansson wrote: >> >> >Also, add some text describing what a server should do when the e-2-e >> >> >identifier has been seen before. e.g. discard it or reply >with the same >> >> >answer as last time. >> >> >> >> Should reply with the same answer, not discard it. The only >> >issue is that >> >> it should not do the same processing again, if that has >> >"consequences" on >> >> anything (e.g. not store an accounting record a second time). >> > >> >So, am I interpreting this right? A server that serves 100 >> >clients and has a window of 128 will have to remember how it >> >replied for 12800 packets? >> >> Sound like alot of answers to save, I'm not sure (probably don't >understand, >> so someone please enlighten me) why you have to reply with the >same answer. >> If it's an request you already answered to why just not drop it? > >because if you've received the request again, chances are the answer got >lost (perhaps a proxy or relay became unreachable). So, you need >to send the >answer again, and have two choices: > >1. process the request, but make sure that the dup request doesn't cause > the user to be allocated additional resources (e.g. two >concurrent sessions) >2. queue all answers for n seconds. Simply return answers when a >dup request is > received. Ok, I'm convinced :-) > >> >> > >> >What if it receives something below the window? Do you just >> >drop the packet, or make up a best guess for the reply? >> >> I guess you have to try to figure out if it can be a wrap around >in the e2e >> identifier or if it's an old one. No matter how you define the e2e >> identifier (monotonically increased or just increased) you will >have to take >> care of the wrap around. With a monotonically increased identifier you'll >> encounter the problem less often. > >the e2e I-D still has 2^128 possible values, so that alot of >requests. If we >want a windowing system, then monotonically increasing is the only way, but >random (and unique within the last 128 requests) works too. Seems that the >former may be simpler to implement. Ok, so can we agree on a monotonically increased identifier, then it is up to the implementor if you want to use the windowing technique or not. /Fredrik > >PatC From owner-aaa-wg@merit.edu Fri Jun 29 12:24:07 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17389 for ; Fri, 29 Jun 2001 12:24:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9FC2F9129D; Fri, 29 Jun 2001 12:24:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 778839129E; Fri, 29 Jun 2001 12:24:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5B43F9129D for ; Fri, 29 Jun 2001 12:24:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 285F45DDF0; Fri, 29 Jun 2001 12:25:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id 9E0895DDCB for ; Fri, 29 Jun 2001 12:25:14 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id MAA20485; Fri, 29 Jun 2001 12:14:16 -0400 (EDT) Message-Id: <4.1.20010629113441.01bda140@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 29 Jun 2001 12:01:35 -0400 To: "Fredrik Johansson" , "Pat Calhoun" From: Paul Funk Subject: RE: [AAA-WG]: Issue 93. End-to-End identifier Cc: "Mark Eklund" , "Jacques Caron" , "AAA Listan" In-Reply-To: References: <20010629060339.E23402@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-wg@merit.edu Precedence: bulk The problem with a window for End-To-End Identifier is that any individual server will not get sequential requests from a client. The client talks to many servers, and a home server may receive two sequential requests from the same client with End-To-End Identifiers that are not sequential, not by a long shot, because that client was talking to other servers in between. So a window can't possibly work. Paul At 04:32 PM 6/29/01 +0200, Fredrik Johansson wrote: > > >>-----Original Message----- >>From: Pat Calhoun [mailto:pcalhoun@diameter.org] >>Sent: den 29 juni 2001 15:04 >>To: Fredrik Johansson >>Cc: Mark Eklund; Jacques Caron; AAA Listan >>Subject: Re: [AAA-WG]: Issue 93. End-to-End identifier >> >> >>On Fri, Jun 29, 2001 at 09:19:15AM +0200, Fredrik Johansson wrote: >>> > >>> >On Thu, 28 Jun 2001, Jacques Caron wrote: >>> > >>> >> At 18:31 28/06/01, Fredrik Johansson wrote: >>> >> >Also, add some text describing what a server should do when the e-2-e >>> >> >identifier has been seen before. e.g. discard it or reply >>with the same >>> >> >answer as last time. >>> >> >>> >> Should reply with the same answer, not discard it. The only >>> >issue is that >>> >> it should not do the same processing again, if that has >>> >"consequences" on >>> >> anything (e.g. not store an accounting record a second time). >>> > >>> >So, am I interpreting this right? A server that serves 100 >>> >clients and has a window of 128 will have to remember how it >>> >replied for 12800 packets? >>> >>> Sound like alot of answers to save, I'm not sure (probably don't >>understand, >>> so someone please enlighten me) why you have to reply with the >>same answer. >>> If it's an request you already answered to why just not drop it? >> >>because if you've received the request again, chances are the answer got >>lost (perhaps a proxy or relay became unreachable). So, you need >>to send the >>answer again, and have two choices: >> >>1. process the request, but make sure that the dup request doesn't cause >> the user to be allocated additional resources (e.g. two >>concurrent sessions) >>2. queue all answers for n seconds. Simply return answers when a >>dup request is >> received. > >Ok, I'm convinced :-) > >> >>> >>> > >>> >What if it receives something below the window? Do you just >>> >drop the packet, or make up a best guess for the reply? >>> >>> I guess you have to try to figure out if it can be a wrap around >>in the e2e >>> identifier or if it's an old one. No matter how you define the e2e >>> identifier (monotonically increased or just increased) you will >>have to take >>> care of the wrap around. With a monotonically increased identifier you'll >>> encounter the problem less often. >> >>the e2e I-D still has 2^128 possible values, so that alot of >>requests. If we >>want a windowing system, then monotonically increasing is the only way, but >>random (and unique within the last 128 requests) works too. Seems that the >>former may be simpler to implement. > >Ok, so can we agree on a monotonically increased identifier, then it is up >to the implementor if you want to use the windowing technique or not. > >/Fredrik >> >>PatC Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-wg@merit.edu Fri Jun 29 12:33:19 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18004 for ; Fri, 29 Jun 2001 12:33:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 502CC91294; Fri, 29 Jun 2001 12:33:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 21D329129E; Fri, 29 Jun 2001 12:33:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E35D591294 for ; Fri, 29 Jun 2001 12:33:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AEAAE5DDD5; Fri, 29 Jun 2001 12:34:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 5209C5DDCB for ; Fri, 29 Jun 2001 12:34:25 -0400 (EDT) Received: (qmail 26657 invoked by uid 500); 29 Jun 2001 16:22:06 -0000 Date: Fri, 29 Jun 2001 09:22:06 -0700 From: Pat Calhoun To: Paul Funk Cc: Fredrik Johansson , Pat Calhoun , Mark Eklund , Jacques Caron , AAA Listan Subject: Re: [AAA-WG]: Issue 93. End-to-End identifier Message-ID: <20010629092206.E25503@charizard.diameter.org> Mail-Followup-To: Paul Funk , Fredrik Johansson , Pat Calhoun , Mark Eklund , Jacques Caron , AAA Listan References: <20010629060339.E23402@charizard.diameter.org> <4.1.20010629113441.01bda140@cairo.funk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.1.20010629113441.01bda140@cairo.funk.com>; from paul@funk.com on Fri, Jun 29, 2001 at 12:01:35PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Fri, Jun 29, 2001 at 12:01:35PM -0400, Paul Funk wrote: > The problem with a window for End-To-End Identifier is that any individual > server will not get sequential requests from a client. The client talks to > many servers, and a home server may receive two sequential requests from > the same client with End-To-End Identifiers that are not sequential, not by a > long shot, because that client was talking to other servers in between. So a > window can't possibly work. you are correct. PatC > > Paul > > At 04:32 PM 6/29/01 +0200, Fredrik Johansson wrote: > > > > > >>-----Original Message----- > >>From: Pat Calhoun [mailto:pcalhoun@diameter.org] > >>Sent: den 29 juni 2001 15:04 > >>To: Fredrik Johansson > >>Cc: Mark Eklund; Jacques Caron; AAA Listan > >>Subject: Re: [AAA-WG]: Issue 93. End-to-End identifier > >> > >> > >>On Fri, Jun 29, 2001 at 09:19:15AM +0200, Fredrik Johansson wrote: > >>> > > >>> >On Thu, 28 Jun 2001, Jacques Caron wrote: > >>> > > >>> >> At 18:31 28/06/01, Fredrik Johansson wrote: > >>> >> >Also, add some text describing what a server should do when the e-2-e > >>> >> >identifier has been seen before. e.g. discard it or reply > >>with the same > >>> >> >answer as last time. > >>> >> > >>> >> Should reply with the same answer, not discard it. The only > >>> >issue is that > >>> >> it should not do the same processing again, if that has > >>> >"consequences" on > >>> >> anything (e.g. not store an accounting record a second time). > >>> > > >>> >So, am I interpreting this right? A server that serves 100 > >>> >clients and has a window of 128 will have to remember how it > >>> >replied for 12800 packets? > >>> > >>> Sound like alot of answers to save, I'm not sure (probably don't > >>understand, > >>> so someone please enlighten me) why you have to reply with the > >>same answer. > >>> If it's an request you already answered to why just not drop it? > >> > >>because if you've received the request again, chances are the answer got > >>lost (perhaps a proxy or relay became unreachable). So, you need > >>to send the > >>answer again, and have two choices: > >> > >>1. process the request, but make sure that the dup request doesn't cause > >> the user to be allocated additional resources (e.g. two > >>concurrent sessions) > >>2. queue all answers for n seconds. Simply return answers when a > >>dup request is > >> received. > > > >Ok, I'm convinced :-) > > > >> > >>> > >>> > > >>> >What if it receives something below the window? Do you just > >>> >drop the packet, or make up a best guess for the reply? > >>> > >>> I guess you have to try to figure out if it can be a wrap around > >>in the e2e > >>> identifier or if it's an old one. No matter how you define the e2e > >>> identifier (monotonically increased or just increased) you will > >>have to take > >>> care of the wrap around. With a monotonically increased identifier you'll > >>> encounter the problem less often. > >> > >>the e2e I-D still has 2^128 possible values, so that alot of > >>requests. If we > >>want a windowing system, then monotonically increasing is the only way, but > >>random (and unique within the last 128 requests) works too. Seems that the > >>former may be simpler to implement. > > > >Ok, so can we agree on a monotonically increased identifier, then it is up > >to the implementor if you want to use the windowing technique or not. > > > >/Fredrik > >> > >>PatC > > Paul Funk > Funk Software, Inc. > 617 497-6339 > paul@funk.com > From owner-aaa-wg@merit.edu Fri Jun 29 17:12:15 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25370 for ; Fri, 29 Jun 2001 17:12:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 23C88912DD; Fri, 29 Jun 2001 17:12:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E7586912DF; Fri, 29 Jun 2001 17:12:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E5AD5912DD for ; Fri, 29 Jun 2001 17:12:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1635B5DDDE; Fri, 29 Jun 2001 17:13:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id F16D55DD9D for ; Fri, 29 Jun 2001 17:13:20 -0400 (EDT) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id C5A3F7A for ; Fri, 29 Jun 2001 17:12:43 -0400 (EDT) Message-ID: <3B3CEEDE.2BE1B7A9@Interlinknetworks.com> Date: Fri, 29 Jun 2001 17:10:54 -0400 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: AAA Working Group Subject: [AAA-WG]: [issue] Typographical change to sec. 3.2 of draft-ietf-aaa-transport-04.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Subject: [issue] Typographical change to sec. 3.2 of draft-ietf-aaa-transport-04.txt Submitter name: David Spence Submitter email address: DSpence@Interlinknetworks.com Date first submitted: June 29, 2001 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg01498.html Document: draft-ietf-aaa-transport-04.txt Comment type: E Priority: 1 Section: 3.2 Rationale/Explanation of issue: The following paragraph contains a typographical error and an instance of awkward wording. [3] After the the expiration of two watchdog timers without a response, the AAA client SHOULD cause a transport reset or close to be done on the connection. While the connection is in the closed state, the AAA client MUST NOT attempt to send further watchdog messages on the connection. However, after the connection is closed, the AAA client continues to periodically attempt to re-open the connection. The AAA client SHOULD wait for the transport layer to report connection failure before attempting again, but MAY chose to limit ^^^^^ ^^^^^ choose bound this wait time by the watchdog interval, Tw. If the connection is successfully opened, then the watchdog message is sent. Once three watchdog messages have been sent and responded to, the connection is returned to service, and transactions are once again sent over it. Connection validation via receipt of multiple watchdogs is not required when a connection is initially brought up -- in this case, the connection can immediately be put into service. Requested change: Change as indicated or alternatively, fix the awkward wording by replacing the phrase "...to limit this wait time by the watchdog interval..." with the phrase "...to limit this wait time not to exceed the watchdog interval...". -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-wg@merit.edu Sat Jun 30 12:46:19 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23794 for ; Sat, 30 Jun 2001 12:46:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 01D1391230; Sat, 30 Jun 2001 12:46:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C401591231; Sat, 30 Jun 2001 12:46:17 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 426C591230 for ; Sat, 30 Jun 2001 12:46:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EA2F55DD91; Sat, 30 Jun 2001 12:47:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 656695DD8C for ; Sat, 30 Jun 2001 12:47:23 -0400 (EDT) Received: (qmail 3343 invoked by uid 500); 30 Jun 2001 16:35:03 -0000 Date: Sat, 30 Jun 2001 09:35:03 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: My Availability Message-ID: <20010630093502.A30270@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, I will not be reachable until 7/9. I have a couple of issues that I have been working on text, but I need to refine them before sending them out. I expect to have text for most issues on 7/9, and hope to be able to close all issues by 7/13. While I am gone, I would encourage folks to discuss: Issue 75 - I'm not sure that we have an agreed upon method of solving this issue. Issue 90 - The proposal is to split up the FilterRule into IPFilterRule and QoSFilterRule (and possibly adding L2FilterRule). I have NO text for L2FilterRule, so if someone could propose some text, that would allow us to close this issue quicker. If folks have any comments on the QoSFilterRule, please go ahead and propose it. I'd like to incorporate all comments upon my return into the base draft. Thanks, PatC From owner-aaa-wg@merit.edu Sat Jun 30 19:31:25 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26559 for ; Sat, 30 Jun 2001 19:31:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 21C8391233; Sat, 30 Jun 2001 19:30:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E5DAD91235; Sat, 30 Jun 2001 19:30:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C53D691233 for ; Sat, 30 Jun 2001 19:30:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 03E085DDA0; Sat, 30 Jun 2001 19:31:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 9A0395DD9E for ; Sat, 30 Jun 2001 19:31:42 -0400 (EDT) Received: (qmail 5498 invoked by uid 500); 30 Jun 2001 23:19:21 -0000 Date: Sat, 30 Jun 2001 16:19:21 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 86: Diameter URI changes Message-ID: <20010630161921.F5195@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, Comments on the list have required that the URI format change. The following is the proposed text DiameterIdentity The DiameterIdentity format is derived from the OctetString AVP Base Format. It uses the UTF-8 encoding and has the same requirements as the UTF8String. In addition, it must follow the Uniform Resource Identifiers (URI) syntax [29] rules specified below: Diameter-Identity = fqdn [ port ] [ transport ] [ protocol ] aaa-protocol = ( "diameter" | "radius" | "tacacs+" ) protocol = ";protocol=" aaa-protocol ; If absent, the default AAA protocol is diameter. fqdn = Fully Qualified Host Name port = ":" 1*DIGIT ; One of the ports used to listen for incoming connections. ; If absent, the default Diameter port (TBD) is assumed. transport = ";transport=" ( "tcp" | "sctp" | "udp" ) ; One of the transports used to listen for incoming ; connections. If absent, the default SCTP [26] protocol is ; assumed. UDP MUST NOT be used when the aaa-protocol field ; is set to diameter. The following are examples of valid Diameter host identities: host.abc.com;transport=tcp host.abc.com:6666;transport=tcp aaa://host.abc.com;protocol=diameter aaa://host.abc.com:6666;protocol=diameter aaa://host.abc.com:6666;transport=tcp;protocol=diameter aaa://host.abc.com:1813;transport=udp;protocol=radius Thanks, PatC From owner-aaa-wg@merit.edu Sat Jun 30 19:37:35 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26583 for ; Sat, 30 Jun 2001 19:37:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1FE3891235; Sat, 30 Jun 2001 19:37:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EC0D391236; Sat, 30 Jun 2001 19:37:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DBAD791235 for ; Sat, 30 Jun 2001 19:37:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 125D45DDA2; Sat, 30 Jun 2001 19:38:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 840BE5DDA0 for ; Sat, 30 Jun 2001 19:38:39 -0400 (EDT) Received: (qmail 5548 invoked by uid 500); 30 Jun 2001 23:26:18 -0000 Date: Sat, 30 Jun 2001 16:26:18 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 16: Redirect Server Certificates Message-ID: <20010630162618.H5195@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, I would like to propose how to resolve this issue. Essentially, what this issue is all about is the ability for a redirect server to return certificates for all hosts in a domain. However, there were some folks that wanted all servers to share the same certificate, since it is not know to which server a request will be destined. So, to solve this problem, I propose adding the following methods in the cms draft: 1. it is possible for a redirect server to return a cert per server in the domain. 2. it is possible for the fqdn of all servers in the domain to have their identity encoded in the altSubjectName of the cert. So, many servers would be encoded in the cert. Are folks comfortable with this approach? PatC From owner-aaa-wg@merit.edu Sat Jun 30 19:55:55 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26754 for ; Sat, 30 Jun 2001 19:55:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7596491236; Sat, 30 Jun 2001 19:56:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 478C991237; Sat, 30 Jun 2001 19:56:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2CFED91236 for ; Sat, 30 Jun 2001 19:56:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7481B5DDA0; Sat, 30 Jun 2001 19:57:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 2C6C25DD9E for ; Sat, 30 Jun 2001 19:57:09 -0400 (EDT) Received: (qmail 5635 invoked by uid 500); 30 Jun 2001 23:44:47 -0000 Date: Sat, 30 Jun 2001 16:44:47 -0700 From: Pat Calhoun To: Paul Funk , Fredrik Johansson , Pat Calhoun , Mark Eklund , Jacques Caron , AAA Listan Subject: Re: [AAA-WG]: Issue 93. End-to-End identifier Message-ID: <20010630164447.L5195@charizard.diameter.org> Mail-Followup-To: Paul Funk , Fredrik Johansson , Pat Calhoun , Mark Eklund , Jacques Caron , AAA Listan References: <20010629060339.E23402@charizard.diameter.org> <20010629092206.E25503@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010629092206.E25503@charizard.diameter.org>; from pcalhoun@diameter.org on Fri, Jun 29, 2001 at 09:22:06AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk so is the only solution to make this value pseudo-random, and make sure that no two packets can be sent with the same id within a period of time, or just make it monotonically increasing, and not worry about windowing? PatC On Fri, Jun 29, 2001 at 09:22:06AM -0700, Pat Calhoun wrote: > On Fri, Jun 29, 2001 at 12:01:35PM -0400, Paul Funk wrote: > > The problem with a window for End-To-End Identifier is that any individual > > server will not get sequential requests from a client. The client talks to > > many servers, and a home server may receive two sequential requests from > > the same client with End-To-End Identifiers that are not sequential, not by a > > long shot, because that client was talking to other servers in between. So a > > window can't possibly work. > > you are correct. > > PatC > > > > Paul > > > > At 04:32 PM 6/29/01 +0200, Fredrik Johansson wrote: > > > > > > > > >>-----Original Message----- > > >>From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > >>Sent: den 29 juni 2001 15:04 > > >>To: Fredrik Johansson > > >>Cc: Mark Eklund; Jacques Caron; AAA Listan > > >>Subject: Re: [AAA-WG]: Issue 93. End-to-End identifier > > >> > > >> > > >>On Fri, Jun 29, 2001 at 09:19:15AM +0200, Fredrik Johansson wrote: > > >>> > > > >>> >On Thu, 28 Jun 2001, Jacques Caron wrote: > > >>> > > > >>> >> At 18:31 28/06/01, Fredrik Johansson wrote: > > >>> >> >Also, add some text describing what a server should do when the e-2-e > > >>> >> >identifier has been seen before. e.g. discard it or reply > > >>with the same > > >>> >> >answer as last time. > > >>> >> > > >>> >> Should reply with the same answer, not discard it. The only > > >>> >issue is that > > >>> >> it should not do the same processing again, if that has > > >>> >"consequences" on > > >>> >> anything (e.g. not store an accounting record a second time). > > >>> > > > >>> >So, am I interpreting this right? A server that serves 100 > > >>> >clients and has a window of 128 will have to remember how it > > >>> >replied for 12800 packets? > > >>> > > >>> Sound like alot of answers to save, I'm not sure (probably don't > > >>understand, > > >>> so someone please enlighten me) why you have to reply with the > > >>same answer. > > >>> If it's an request you already answered to why just not drop it? > > >> > > >>because if you've received the request again, chances are the answer got > > >>lost (perhaps a proxy or relay became unreachable). So, you need > > >>to send the > > >>answer again, and have two choices: > > >> > > >>1. process the request, but make sure that the dup request doesn't cause > > >> the user to be allocated additional resources (e.g. two > > >>concurrent sessions) > > >>2. queue all answers for n seconds. Simply return answers when a > > >>dup request is > > >> received. > > > > > >Ok, I'm convinced :-) > > > > > >> > > >>> > > >>> > > > >>> >What if it receives something below the window? Do you just > > >>> >drop the packet, or make up a best guess for the reply? > > >>> > > >>> I guess you have to try to figure out if it can be a wrap around > > >>in the e2e > > >>> identifier or if it's an old one. No matter how you define the e2e > > >>> identifier (monotonically increased or just increased) you will > > >>have to take > > >>> care of the wrap around. With a monotonically increased identifier you'll > > >>> encounter the problem less often. > > >> > > >>the e2e I-D still has 2^128 possible values, so that alot of > > >>requests. If we > > >>want a windowing system, then monotonically increasing is the only way, but > > >>random (and unique within the last 128 requests) works too. Seems that the > > >>former may be simpler to implement. > > > > > >Ok, so can we agree on a monotonically increased identifier, then it is up > > >to the implementor if you want to use the windowing technique or not. > > > > > >/Fredrik > > >> > > >>PatC > > > > Paul Funk > > Funk Software, Inc. > > 617 497-6339 > > paul@funk.com > > From owner-aaa-wg@merit.edu Sat Jun 30 19:59:54 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26800 for ; Sat, 30 Jun 2001 19:59:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3E18391234; Sat, 30 Jun 2001 19:51:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 121DB91236; Sat, 30 Jun 2001 19:51:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F1D1591234 for ; Sat, 30 Jun 2001 19:51:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4568D5DDA0; Sat, 30 Jun 2001 19:52:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 442B35DD9E for ; Sat, 30 Jun 2001 19:52:18 -0400 (EDT) Received: (qmail 5585 invoked by uid 500); 30 Jun 2001 23:39:56 -0000 Date: Sat, 30 Jun 2001 16:39:56 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 87: Move filter-rule AVP to base Message-ID: <20010630163956.I5195@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, Below is the proposed text for this issue. Comments appreciated, but proposed text even more :) Thanks, PatC ---- IPFilterRule The IPFilterRule format is derived from the OctetString AVP Base Format. It uses the UTF-8 encoding and has the same requirements as the UTF8String. Packets may be filtered based on the following information that is associated with it: Direction (in or out) Source and destination IP address (possibly masked) Protocol Source and destination port (lists or ranges) TCP flags IP fragment flag IP options ICMP types Rules for the appropriate direction are evaluated in order, with the first matched rule terminating the evaluation. Each packet is evaluated once. If no rule matches, the packet is dropped if the last rule evaluated was a permit, and passed if the last rule was a deny. IPFilterRule filters MUST follow the format: action dir proto from src to dst [options] action permit - Allow packets that match the rule. deny - Drop packets that match the rule. dir "in" is from the terminal, "out" is to the terminal. proto An IP protocol specified by number. The "ip" keyword means any protocol will match. src and dst
[ports] The
may be specified as: ipno An IPv4 or IPv6 number in dotted- quad or canonical IPv6 form. Only this exact IP number will match the rule. ipno/bits An IP number as above with a mask width of the form 1.2.3.4/24. In this case all IP numbers from Calhoun et al. expires December 2001 [Page 34] Internet-Draft June 2001 1.2.3.0 to 1.2.3.255 will match. The bit width MUST be valid for the IP version and the IP number MUST NOT have bits set beyond the mask. The sense of the match can be inverted by preceding an address with the not modifier, causing all other addresses to be matched instead. This does not affect the selection of port numbers. The keyword "any" is 0.0.0.0/0 or the IPv6 equivalent. The keyword "assigned" is the address or set of addresses assigned to the terminal. The first rule SHOULD be "deny in ip !assigned". With the TCP, UDP and SCTP protocols, optional ports may be specified as: {port|port-port}[,port[,...]] The `-' notation specifies a range of ports (including boundaries). Fragmented packets which have a non-zero offset (i.e. not the first fragment) will never match a rule which has one or more port specifications. See the frag option for details on matching fragmented packets. options: frag Match if the packet is a fragment and this is not the first fragment of the datagram. frag may not be used in conjunction with either tcpflags or TCP/UDP port specifications. ipoptions spec Match if the IP header contains the comma separated list of options specified in spec. The supported IP options are: ssrr (strict source route), lsrr (loose source route), rr (record packet route) and ts (timestamp). The absence of a particular option may be denoted with a `!'. tcpoptions spec Calhoun et al. expires December 2001 [Page 35] Internet-Draft June 2001 Match if the TCP header contains the comma separated list of options specified in spec. The supported TCP options are: mss (maximum segment size), window (tcp window advertisement), sack (selective ack), ts (rfc1323 timestamp) and cc (rfc1644 t/tcp connection count). The absence of a particular option may be denoted with a `!'. established TCP packets only. Match packets that have the RST or ACK bits set. setup TCP packets only. Match packets that have the SYN bit set but no ACK bit. tcpflags spec TCP packets only. Match if the TCP header contains the comma separated list of flags specified in spec. The supported TCP flags are: fin, syn, rst, psh, ack and urg. The absence of a particular flag may be denoted with a `!'. A rule which contains a tcpflags specification can never match a fragmented packet which has a non-zero offset. See the frag option for details on matching fragmented packets. icmptypes types ICMP packets only. Match if the ICMP type is in the list types. The list may be specified as any combination of ranges or individual types separated by commas. The supported ICMP types are: echo reply (0), destination unreachable (3), source quench (4), redirect (5), echo request (8), router advertisement (9), router solicitation (10), time-to-live exceeded (11), IP header bad (12), timestamp request (13), timestamp reply (14), information request (15), information reply (16), address mask request (17) and address mask reply (18). There is one kind of packet that the access device MUST always discard, that is an IP fragment with a fragment offset of one. This is a valid packet, but it only has one use, to try to Calhoun et al. expires December 2001 [Page 36] Internet-Draft June 2001 circumvent firewalls. An access device that is unable to interpret or apply a deny rule MUST terminate the session. An access device that is unable to interpret or apply a permit rule MAY apply a more restrictive rule. An access device MAY apply deny rules of its own before the supplied rules, for example to protect the access device owner's infrastructure. The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the ipfw.c code may provide a useful base for implementations. QoSFilterRule The QosFilterRule format is derived from the OctetString AVP Base Format. It uses the UTF-8 encoding and has the same requirements as the UTF8String. Packets may be marked or metered based on the following information that is associated with it: Direction (in or out) Source and destination IP address (possibly masked) Protocol Source and destination port (lists or ranges) DSCP values (no mask or range) Rules for the appropriate direction are evaluated in order, with the first matched rule terminating the evaluation. Each packet is evaluated once. If no rule matches, the packet is treated as best effort. QoSFilterRule filters MUST follow the format: action dir proto from src to dst [options] tag - Mark packet with a specific DSCP [49]. The DSCP option MUST be included. meter - Meter traffic. The metering options MUST be included. dir "in" is from the terminal, "out" is to the terminal. proto An IP protocol specified by number. The "ip" keyword means any protocol will match. src and dst
[ports] Calhoun et al. expires December 2001 [Page 37] Internet-Draft June 2001 The
may be specified as: ipno An IPv4 or IPv6 number in dotted- quad or canonical IPv6 form. Only this exact IP number will match the rule. ipno/bits An IP number as above with a mask width of the form 1.2.3.4/24. In this case all IP numbers from 1.2.3.0 to 1.2.3.255 will match. The bit width MUST be valid for the IP version and the IP number MUST NOT have bits set beyond the mask. The sense of the match can be inverted by preceding an address with the not modifier, causing all other addresses to be matched instead. This does not affect the selection of port numbers. The keyword "any" is 0.0.0.0/0 or the IPv6 equivalent. The keyword "assigned" is the address or set of addresses assigned to the terminal. The first rule SHOULD be "deny in ip !assigned". With the TCP, UDP and SCTP protocols, optional ports may be specified as: {port|port-port}[,port[,...]] The `-' notation specifies a range of ports (including boundaries). options: DSCP color values as defined in [49]. Exact matching of DSCP values is required (no masks or ranges). the "deny" can replace the color_under or color_over values in the meter action for rate- dependent packet drop. Calhoun et al. expires December 2001 [Page 38] Internet-Draft June 2001 metering The metering option provides Assured Forwarding, as defined in [50], and MUST be present if the action is set to meter. The rate option is the throughput, in bits per second, which is used by the access device to mark packets. Traffic above the rate is marked with the color_over codepoint, while traffic under the rate is marked with the color_under codepoint. The color_under and color_over options contain the drop preferences, and MUST conform to the recommended codepoint keywords described in [50] (e.g. AF13). The metering option also supports the strict limit on traffic required by Expedited Forwarding, as defined in [51]. The color_over option may contain the keyword "drop" to prevent forwarding of traffic that exceeds the rate parameter. The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the ipfw.c code may provide a useful base for implementations. From owner-aaa-wg@merit.edu Sat Jun 30 22:03:03 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28540 for ; Sat, 30 Jun 2001 22:03:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1458691237; Sat, 30 Jun 2001 22:03:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CE4B491238; Sat, 30 Jun 2001 22:03:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B9D9291237 for ; Sat, 30 Jun 2001 22:03:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 355345DDA0; Sat, 30 Jun 2001 22:04:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id BEECC5DD9E for ; Sat, 30 Jun 2001 22:04:13 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id VAA22269; Sat, 30 Jun 2001 21:52:54 -0400 (EDT) Message-Id: <4.1.20010630210708.01d55230@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sat, 30 Jun 2001 21:40:16 -0400 To: Pat Calhoun , Fredrik Johansson , Pat Calhoun , Mark Eklund , Jacques Caron , AAA Listan From: Paul Funk Subject: Re: [AAA-WG]: Issue 93. End-to-End identifier In-Reply-To: <20010630164447.L5195@charizard.diameter.org> References: <20010629092206.E25503@charizard.diameter.org> <20010629060339.E23402@charizard.diameter.org> <20010629092206.E25503@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-wg@merit.edu Precedence: bulk Pat, I think the text that describes how to generate Hop-By-Hop Identifier and End-To-End Identifier should be the same -- that is, an identifier should be locally unique for the long enough past the lifetime of a transaction to prevent any ambiguity. How this is done is up to the sender, and there is no requirement that the numbers be increasing, though the obvious way to achieve this is to initialize the value in an intelligent way on reboot and increment from then on. The identifier can be initialized randomly at reboot, but there is always the risk that identifiers from before and after reboots could clash. That's okay for Hop-By-Hop Identifiers, because when the connection goes down all the pending transactions are dropped anyway. With End-To-End Identifier, it's more problematic; the only way the server can disambiguate two equal identifiers is by consulting Origin-State-Id, but that is not a required attribute. Here's an algorithm for generating an initial value for an identifier that guarantees uniqueness across reboot: Initialize the high order 12 bits of the identifier to the low order 12 bits of the current time, and initialize the low order 20 bits of the identifier to 0. This is guaranteed to produce unique identifiers across reboots provided that: 1 the device takes longer than a second to reboot 2 no transaction is kicking around for longer than an hour or so (2 ^ 12 seconds) 3 the transaction rate (the rate at which the identifier is incremented) is no greater than a million per second (2 ^ 20). Paul At 04:44 PM 6/30/01 -0700, Pat Calhoun wrote: >so is the only solution to make this value pseudo-random, and make sure that no >two packets can be sent with the same id within a period of time, or just >make it >monotonically increasing, and not worry about windowing? > >PatC >On Fri, Jun 29, 2001 at 09:22:06AM -0700, Pat Calhoun wrote: >> On Fri, Jun 29, 2001 at 12:01:35PM -0400, Paul Funk wrote: >> > The problem with a window for End-To-End Identifier is that any individual >> > server will not get sequential requests from a client. The client talks to >> > many servers, and a home server may receive two sequential requests from >> > the same client with End-To-End Identifiers that are not sequential, not >by a >> > long shot, because that client was talking to other servers in between. >So a >> > window can't possibly work. >> >> you are correct. >> >> PatC >> > >> > Paul >> > >> > At 04:32 PM 6/29/01 +0200, Fredrik Johansson wrote: >> > > >> > > >> > >>-----Original Message----- >> > >>From: Pat Calhoun [mailto:pcalhoun@diameter.org] >> > >>Sent: den 29 juni 2001 15:04 >> > >>To: Fredrik Johansson >> > >>Cc: Mark Eklund; Jacques Caron; AAA Listan >> > >>Subject: Re: [AAA-WG]: Issue 93. End-to-End identifier >> > >> >> > >> >> > >>On Fri, Jun 29, 2001 at 09:19:15AM +0200, Fredrik Johansson wrote: >> > >>> > >> > >>> >On Thu, 28 Jun 2001, Jacques Caron wrote: >> > >>> > >> > >>> >> At 18:31 28/06/01, Fredrik Johansson wrote: >> > >>> >> >Also, add some text describing what a server should do when the >e-2-e >> > >>> >> >identifier has been seen before. e.g. discard it or reply >> > >>with the same >> > >>> >> >answer as last time. >> > >>> >> >> > >>> >> Should reply with the same answer, not discard it. The only >> > >>> >issue is that >> > >>> >> it should not do the same processing again, if that has >> > >>> >"consequences" on >> > >>> >> anything (e.g. not store an accounting record a second time). >> > >>> > >> > >>> >So, am I interpreting this right? A server that serves 100 >> > >>> >clients and has a window of 128 will have to remember how it >> > >>> >replied for 12800 packets? >> > >>> >> > >>> Sound like alot of answers to save, I'm not sure (probably don't >> > >>understand, >> > >>> so someone please enlighten me) why you have to reply with the >> > >>same answer. >> > >>> If it's an request you already answered to why just not drop it? >> > >> >> > >>because if you've received the request again, chances are the answer got >> > >>lost (perhaps a proxy or relay became unreachable). So, you need >> > >>to send the >> > >>answer again, and have two choices: >> > >> >> > >>1. process the request, but make sure that the dup request doesn't cause >> > >> the user to be allocated additional resources (e.g. two >> > >>concurrent sessions) >> > >>2. queue all answers for n seconds. Simply return answers when a >> > >>dup request is >> > >> received. >> > > >> > >Ok, I'm convinced :-) >> > > >> > >> >> > >>> >> > >>> > >> > >>> >What if it receives something below the window? Do you just >> > >>> >drop the packet, or make up a best guess for the reply? >> > >>> >> > >>> I guess you have to try to figure out if it can be a wrap around >> > >>in the e2e >> > >>> identifier or if it's an old one. No matter how you define the e2e >> > >>> identifier (monotonically increased or just increased) you will >> > >>have to take >> > >>> care of the wrap around. With a monotonically increased identifier >you'll >> > >>> encounter the problem less often. >> > >> >> > >>the e2e I-D still has 2^128 possible values, so that alot of >> > >>requests. If we >> > >>want a windowing system, then monotonically increasing is the only >way, but >> > >>random (and unique within the last 128 requests) works too. Seems that >the >> > >>former may be simpler to implement. >> > > >> > >Ok, so can we agree on a monotonically increased identifier, then it is up >> > >to the implementor if you want to use the windowing technique or not. >> > > >> > >/Fredrik >> > >> >> > >>PatC >> > >> > Paul Funk >> > Funk Software, Inc. >> > 617 497-6339 >> > paul@funk.com >> > Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com