Subject: [Dime] CER/CEA on an open connection

From: Anders Kristensen <[email-masked]>
Date: Mon, 13 Mar 2006 09:49:49 -0500

In its description of the peer state machine RFC 3588 goes out of its 
way to allow CER requests on an already open connection (section 5.6). 
Is the intention that either party can re-advertise its set of 
capabilities at any time? This raises some questions. For example, if 
TLS was not listed as supported in the first CER/CEA but is now, is it 
possible to carry out a TLS handshake after the exchange of non-CER/CEA 
traffic? What if no response is received for a "non-initial" CER (but 
other traffic, including DWR/DEA, continues to be exchanged), should the 
connection be reset?

I wonder if the ability to exchange capabilities on an open connection 
is widely supported and whether it is really useful enough to warrant it 
being part of the spec. Should probably be part of the base protocol 
test suite if it is.

Anders

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

---

From: Timothy Smith <[email-masked]>
Date: Mon, 13 Mar 2006 10:15:22 -0500

Hi Anders,

I think there is a valid need for re-advertising capabilities. 
Applications may come and go over time.  So this gives a means for an 
application to join an existing connection without having to bring it down 
and disrupt other applications that might already be using that 
connection.  But I think the questions you raised are valid with regard to 
the definition of this renegotiation.

It is subtle, but renegotiation is really defining an additional state in 
the state machine.  If a CER is sent on an already negotiated connection, 
you have entered a new "Open-but-waiting_CEA" state.  The questions that 
you raise should be addressed in that new state.

I think it is a good function, but agree that it needs to be better 
defined.

Best Regards,
Timothy Smith

[email-masked]
(919) 254-4723

Anders Kristensen <[email-masked]> 
03/13/2006 09:49 AM

To
[email-masked]
cc

Subject
[Dime] CER/CEA on an open connection

Anders

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 13 Mar 2006 10:39:36 -0500

Hi,

> application to join an existing connection without having to bring it 
> down and disrupt other applications that might already be using that 
> connection.  But I think the questions you raised are valid with 
> regard to the definition of this renegotiation.
>
> It is subtle, but renegotiation is really defining an additional state 
> in the state machine.  If a CER is sent on an already negotiated 
> connection, you have entered a new "Open-but-waiting_CEA" state.  The 
> questions that you raise should be addressed in that new state.

I agree, but i think renegotiation should be limited to app id support 
and not the transport type (i.e. TLS) as it is now.

my 2 cents.

victor

> *Anders Kristensen <[email-masked]>*
>
> 03/13/2006 09:49 AM
>
> 	
> To
> 	[email-masked]
> cc
> 	
> Subject
>------------------------------------------------------------------------
>

---

From: <[email-masked]>
Date: Sat, 18 Mar 2006 20:51:56 +0200

Hmm, it seems to me that if we have to fix the state machine, that might
be a significant change as it would affect people implementations.
Would specifying the renegotiation be something that people are
interested in?
 
John

	Hi Anders, 
	
	I think there is a valid need for re-advertising capabilities.
Applications may come and go over time.  So this gives a means for an
application to join an existing connection without having to bring it
down and disrupt other applications that might already be using that
connection.  But I think the questions you raised are valid with regard
to the definition of this renegotiation. 
	
	It is subtle, but renegotiation is really defining an additional
state in the state machine.  If a CER is sent on an already negotiated
connection, you have entered a new "Open-but-waiting_CEA" state.  The
questions that you raise should be addressed in that new state. 
	
	I think it is a good function, but agree that it needs to be
better defined. 
	
	Best Regards, 
	Timothy Smith 
	
	[email-masked]
	(919) 254-4723

	

03/13/2006 09:49 AM 

To
[email-masked] 
cc
Subject

	In its description of the peer state machine RFC 3588 goes out
of its 
	way to allow CER requests on an already open connection (section
5.6). 
	Is the intention that either party can re-advertise its set of 
	capabilities at any time? This raises some questions. For
example, if 
	TLS was not listed as supported in the first CER/CEA but is now,
is it 
	possible to carry out a TLS handshake after the exchange of
non-CER/CEA 
	traffic? What if no response is received for a "non-initial" CER
(but 
	other traffic, including DWR/DEA, continues to be exchanged),
should the 
	connection be reset?
	
	I wonder if the ability to exchange capabilities on an open
connection 
	is widely supported and whether it is really useful enough to
warrant it 
	being part of the spec. Should probably be part of the base
protocol 
	test suite if it is.
	
	Anders

---

From: Victor Fajardo <[email-masked]>
Date: Sat, 18 Mar 2006 22:32:16 -0500

Comments inline:

> Hmm, it seems to me that if we have to fix the state machine, that 
> might be a significant change as it would affect people 
> implementations.   Would specifying the renegotiation be something 
> that people are interested in?

It seems renegotiation has a valid point. To minimize the change in 
current implementations maybe we can add text that describes 
optional(??) functionality:

1. limiting scope of renegotiation to app id support
2. sender of the cer wishes to add or remove app support with peer. if 
removal of an app results in no common app, the connection should be 
closed. This event need not be represented in the fsm since 2nd 
paragraph in sec 5.3 already describes the behavior.
3. current stateful session affected by a removable will remain active 
until the session or the application itself ends. also applies to 
proxies. does not apply to stateless sessions, proxies or relays.

hope this is helpful. regards,
victor

>      Applications may come and go over time.  So this gives a means
>     for an application to join an existing connection without having
>     to bring it down and disrupt other applications that might already
>     be using that connection.  But I think the questions you raised
>     are valid with regard to the definition of this renegotiation.
>
>     state in the state machine.  If a CER is sent on an already
>     negotiated connection, you have entered a new
>     "Open-but-waiting_CEA" state.  The questions that you raise should
>     be addressed in that new state.
>

---

From: Anders Kristensen <[email-masked]>
Date: Sun, 19 Mar 2006 11:25:51 -0500

A simple alternative to renegotiation would be for nodes to terminate 
and reestablish connections. Not desirable but given that this is 
probably a rarely needed feature perhaps it could be acceptable.

OTOH, if renegotiation is limited to changing supported applications as 
proposed by Victor and Timothy, then that seems manageable.

More inline...

> paragraph in sec 5.3 already describes the behavior.

I think that in this case the guy removing support for the one shared 
app should not send the CER but instead just terminate the connection. 
(Possibly sending new Disconnect-Cause, say NO_SHARED_APP.)

> proxies. does not apply to stateless sessions, proxies or relays.

We might want to specify a new non-2xxx result-code that the recipient 
of an invalid "subsequent" CER can respond with. Invalid here meaning 
that the CER differs from the CER/CEA originally sent by the peer in 
aspects other than supported applications, e.g. different security or 
different Origin-Host/Origin-Realm values. Of course the CER can be 
rejected for other reasons, e.g. missing or illegal AVPs etc.

We'll have to determine what happens with the connection in the case 
where the CER is rejected. One option is to say that it stays open in 
the state it was in prior to the failed CER. Both parties are then free 
to terminate it themselves if they feel like it.

Anders

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 20 Mar 2006 08:39:49 -0500

Comments inline.

> -----Original Message-----
> From: Anders Kristensen [mailto:[email-masked]]
> Sent: Sunday, March 19, 2006 11:26 AM
> To: Victor Fajardo
> Cc: [email-masked]
> Subject: Re: [Dime] CER/CEA on an open connection
>
>
[TOLGA]This IMO is a nice solution. That type of capability may really be
usefull for cases where messages are exchanged between two nodes for
different application types. That one application goes down/comes up should
not affect the message exchange for the other application application.

OTOH, one also could argue that for multiple application support, nodes
could be visible with different Diameter identities, but to provide a decent
solution for the generic case, I would think renegotiation of supported
application is important.

[..snip..]
> > proxies. does not apply to stateless sessions, proxies or relays.
[TOLGA]That type of graceful shutdown could be useful but I am not sure
whether it is equivalent to advertising application support. I can see that
both type of operations may be usefull:
a) Application logic is down -for some reason-, there is no way of
continuing existing sessions.
b) Application will be put down for maintainence. One would like to have a
graceful shutdown.

For a), I would expect DIAMETER_APPLICATION_UNSUPPORTED to be returned for
incoming messages for that application type. It still would be good to send
a CER, where the unavailability of the appllication is implied.

For b), CER could be used but I would think it is a good idea to have a new
AVP for it, e.g.
Application-Shutdown ::= < AVP Header XYZ >
             *[ Auth-Application-Id ]
             *[ Acct-Application-Id ]
             *[Vendor-Specific-Application-Id ]

This would allow us to distinguish clearly between immediate and graceful
shutdown cases.

BTW, I hope we also can do something about consolidating Application-Id AVPs
in the future -I mean generally-.

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 20 Mar 2006 09:29:03 -0500

> probably a rarely needed feature perhaps it could be acceptable.

this has less impact to existing implementations but a bit disruptive.

>> 2. sender of the cer wishes to add or remove app support with peer. 
>> if removal of an app results in no common app, the connection should 
>> be closed. This event need not be represented in the fsm since 2nd 

i agree.

>
>> 3. current stateful session affected by a removable will remain 
>> active until the session or the application itself ends. also applies 
>> to proxies. does not apply to stateless sessions, proxies or relays.
>
>

i agree. i'm leaning more towards an error condition regarding differing 
origin-host/realm for subsequent CER.

> the state it was in prior to the failed CER. Both parties are then 
> free to terminate it themselves if they feel like it.

should we add a stricter behavior to this scenario ? we may leave a 
routing hole if the sender of the CER can no longer maintain an 
application it wishes to remove even if the opposing peer cannot comply 
(CEA with error code).  The oppsing peer may think that the other peer 
still supports that app since the connection is still open.

regards,
victor