Subject: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-14.txt

From: [email-masked]
Date: Mon, 24 Nov 2008 09:15:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF.

	Title           : Diameter Base Protocol
	Author(s)       : V. Fajardo, et al.
	Filename        : draft-ietf-dime-rfc3588bis-14.txt
	Pages           : 160
	Date            : 2008-11-24

The Diameter base protocol is intended to provide an Authentication,
Authorization and Accounting (AAA) framework for applications such as
network access or IP mobility.  Diameter is also intended to work in
both local Authentication, Authorization & Accounting and roaming
situations.  This document specifies the message format, transport,
error reporting, accounting and security services to be used by all
Diameter applications.  The Diameter base application needs to be
supported by all Diameter implementations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-14.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 24 Nov 2008 12:31:02 -0500

Changes in this revision includes proposed resolution to most of the 
open issues discussed last week in ietf-73:

- Removal of the MAY column for the M-bit. Although this has been in bis 
since rev-12, consensus has been reached in ietf73 to make the changes 
permanent.

- Cleanup of peer discovery mechanism. The new scheme now uses SRV 
lookups as a fallback from NAPTR. It also clarifies/cleanup text on the 
fallback scheme.

- Downgraded SCTP support on servers from MUST to SHOULD.

- Fixed Sec 6.12 and align default values of redirect usage and 
auth-session state

As of this revision, there is only one open issue remaining for bis. 
This pertains to securing inband-security info of CER/CEA. The proposals 
for item will be treated in a separate thread and changes will be 
incorporated in the next rev of bis.

regards,
victor

> ------------------------------------------------------------------------
>

---

From: Mark Jones <[email-masked]>
Date: Mon, 24 Nov 2008 15:09:33 -0500

Hi Victor,

<snip>
> - Fixed Sec 6.12 and align default values of redirect usage and

I see that the Auth-Session-State default is now "NO_STATE_MAINTAINED". I know a couple of 3GPP applications that explicitly set Auth-Session-State to NO_STATE_MAINTAINED but aren't other derivative applications assuming that state is maintained? So don't we break a lot of implementations with this change?

For the record, I originally raised this issue to fix the contradiction between sections 6.12 and 6.13 regarding Redirect-Host-Usage.  Even if you don't agree with my suggestion that Redirect-Host-Usage default should be ALL_SESSION, we still don't need to impact Auth-Session-State to resolve that contradiction.

Regards
Mark

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 24 Nov 2008 12:54:17 -0800

Mark Jones [mailto://[email-masked]] writes:

> I see that the Auth-Session-State default is now "NO_STATE_MAINTAINED".
> I know a couple of 3GPP applications that explicitly set Auth-Session-
> State to NO_STATE_MAINTAINED but aren't other derivative applications
> assuming that state is maintained? 

Not sure what a "derivative application" is...

> So don't we break a lot of
> implementations with this change?

Isn't it more like drawing attention to their brokenness; if they assume
things like this, I'd say that they are broken already.

> 
> For the record, I originally raised this issue to fix the contradiction
> between sections 6.12 and 6.13 regarding Redirect-Host-Usage.  Even if
> you don't agree with my suggestion that Redirect-Host-Usage default
> should be ALL_SESSION, we still don't need to impact Auth-Session-State
> to resolve that contradiction.
> 
> Regards
> Mark
>

---

From: Mark Jones <[email-masked]>
Date: Mon, 24 Nov 2008 16:34:31 -0500

Hi Glen,

> -----Original Message-----
> From: Glen Zorn [mailto:[email-masked]]
> Sent: November 24, 2008 15:54
> To: Mark Jones; 'Victor Fajardo'
> Cc: [email-masked]
> Subject: RE: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-14.txt
>

s/derivative application/Diameter application/

> things like this, I'd say that they are broken already.

Why are they broken? RFC3588 states that in the absense of an Auth-Session-State AVP "session state is maintained". 3588bis now says session state is NOT maintained if no Auth-Session-State is present.

---

From: Mark Jones <[email-masked]>
Date: Mon, 24 Nov 2008 17:06:55 -0500

I've had some offline discussions with Victor on this and we came to the conclusions that the Auth-Session-State default should be changed back to STATE_MAINTAINED to avoid impacting existing implementations.

This leaves two options to fix the Redirect-Host-Usage contradiction in rfc3588bis-13:
        (a) default is ALL_SESSION; minor change to section 6.13
        (b) default is DONT_CACHE; minor change to section 6.12

In the interests of advancing 3588bis (and noting total lack of WG interest), I can accept fix (b).

Regards
Mark

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Mark Jones
> Sent: November 24, 2008 15:10
> To: Victor Fajardo
> Cc: [email-masked]
> Subject: Re: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-14.txt
>
> Hi Victor,
>
> <snip>
> I see that the Auth-Session-State default is now
> "NO_STATE_MAINTAINED". I know a couple of 3GPP applications
> that explicitly set Auth-Session-State to NO_STATE_MAINTAINED
> but aren't other derivative applications assuming that state
> is maintained? So don't we break a lot of implementations
> with this change?
>
> For the record, I originally raised this issue to fix the
> contradiction between sections 6.12 and 6.13 regarding
> Redirect-Host-Usage.  Even if you don't agree with my
> suggestion that Redirect-Host-Usage default should be
> ALL_SESSION, we still don't need to impact Auth-Session-State

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 24 Nov 2008 14:43:11 -0800

Mark Jones [mailto:[email-masked]] writes:

...

> > "NO_STATE_MAINTAINED".
> Why are they broken? RFC3588 states that in the absense of an Auth-
> Session-State AVP "session state is maintained". 

Right, my bad.

> 3588bis now says
> session state is NOT maintained if no Auth-Session-State is present.

Not exactly: the only place I can find where behavior in the absence of the
Auth-Session-State AVP is described is in 
section 8.1, paragraph 2:

   There are four different authorization session state machines
   supported in the Diameter base protocol.  The first two describe a
   session in which the server is maintaining session state, indicated
   by the value of the Auth-Session-State AVP (or its absence).  One
   describes the session from a client perspective, the other from a
   server perspective.  The second two state machines are used when the
   server does not maintain session state.  Here again, one describes
   the session from a client perspective, the other from a server
   perspective.

It seems to me that the only thing that has actually changed is the location
of the sentence "This is the default value." in the AVP description (which
doesn't seem to really mean anything anyway).

...

---

From: Stefan Winter <[email-masked]>
Date: Tue, 25 Nov 2008 09:26:35 +0100

Hi Victor,

> lookups as a fallback from NAPTR. It also clarifies/cleanup text on
> the fallback scheme.

Thanks, the text looks good to me!

Greetings,

Stefan Winter

> This pertains to securing inband-security info of CER/CEA. The
> proposals for item will be treated in a separate thread and changes
> will be incorporated in the next rev of bis.
>
> regards,
> victor
>
>

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473