Subject: Summary of WG review of "RADIUS over TCP" document

From: Bernard Aboba <[email-masked]>
Date: Wed, 10 Dec 2008 22:02:34 -0800

A call for review of the "RADIUS over TCP" document was issued on November 4, 2008
(see http://ops.ietf.org/lists/radiusext/2008/msg00731.html) and concluded on 
November 19, 2008. 
 
Based on the response to the call for review, the document is accepted as a 
RADEXT WG work item, and should be resubmitted as draft-ietf-radext-tcp-transport-00.txt.
 
Note that a number of transport issues were raised during the IETF 73 discussion
of this document, by Magnus Westerlund (Transport AD) and others.   It is
therefore recommended that this document receive an early review by the
Transport Directorate.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 11 Dec 2008 10:54:18 +0100

I suggest that by the time the document reaches WGLC a specific request
be sent by the chairs to the Transport Directorate for an early review. 
 
Dan

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bernard Aboba
	Sent: Thursday, December 11, 2008 8:03 AM
	To: [email-masked]
	Subject: Summary of WG review of "RADIUS over TCP" document

	A call for review of the "RADIUS over TCP" document was issued
on November 4, 2008
	(see http://ops.ietf.org/lists/radiusext/2008/msg00731.html) and
concluded on 
	November 19, 2008. 
	 
	Based on the response to the call for review, the document is
accepted as a 
	RADEXT WG work item, and should be resubmitted as
draft-ietf-radext-tcp-transport-00.txt.
	 
	Note that a number of transport issues were raised during the
IETF 73 discussion
	of this document, by Magnus Westerlund (Transport AD) and
others.   It is
	therefore recommended that this document receive an early review
by the
	Transport Directorate.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 11 Dec 2008 11:46:38 +0100

> draft-ietf-radext-tcp-transport-00.txt.

  I have submitted the document with the following changes from
draft-dekok-tcp-transport-00.txt:

 - IPR statements updated
 - name in page footers corrected
 - updated reference from status-server-00 to status-server-02
 - Submission && expiry dates changed

  No changes have been made to the body of the text.  WG reviews will be
integrated into a -01 version of the document.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 11 Dec 2008 08:16:42 -0800

Based on the discussion at IETF 73, the following issues have been filed against the document:

Issue 291
    Pending
    Technical

	UDP/TCP Translation
    Alan 
	DeKok

    Issue 292
    Pending
    Technical

	Applicability
    Alan 
	DeKok

    Issue 293
    Pending
    Technical

	Watchdog Timer
    Alan 
	DeKok

    Issue 294
    No Discussion
    Technical

	Document Status
    Bernard 
	Aboba

    Issue 295
    Pending
    Technical

	Head of Line Blocking
    Alan 
	DeKok
Rather than waiting until WG last call, my suggestion would be to engage a Transport Directorate adviser to
assist with resolution of these issues.  I have sent an email to the tsv-dir mailing list to solicit a volunteer. 

Subject: RE: Summary of WG review of "RADIUS over TCP" document
Date: Thu, 11 Dec 2008 10:54:18 +0100
From: [email-masked]
To: [email-masked]; [email-masked]

I 
suggest that by the time the document reaches WGLC a specific request be sent by 
the chairs to the Transport Directorate for an early review. 

Dan

  
  From: [email-masked] 
  [mailto:[email-masked]] On Behalf Of Bernard 
  Aboba
Sent: Thursday, December 11, 2008 8:03 AM
To: 
  [email-masked]
Subject: Summary of WG review of "RADIUS over 
  TCP" document

  A call for review of the "RADIUS over TCP" document was issued on 
  November 4, 2008
(see http://ops.ietf.org/lists/radiusext/2008/msg00731.html) 
  and concluded on 
November 19, 2008. 
 
Based on the response to 
  the call for review, the document is accepted as a 
RADEXT WG work item, 
  and should be resubmitted as 
  draft-ietf-radext-tcp-transport-00.txt.
 
Note that a number of 
  transport issues were raised during the IETF 73 discussion
of this 
  document, by Magnus Westerlund (Transport AD) and others.   It 
  is
therefore recommended that this document receive an 
  early review by the
Transport 
Directorate.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 16 Dec 2008 15:34:30 +0100

Bernard Aboba wrote:
> Issue 291 	Pending 	Technical 	UDP/TCP Translation
> <http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20291>
> Alan DeKok

  I've updated the document with text as suggested by Bernard.

> Issue 292 	Pending 	Technical 	Applicability
> <http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20292>
> Alan DeKok 

  I have updated the document as per review, and consolidated the
multiple applicability sections into one.  The document now also says
that using bare TCP is NOT RECOMMENDED.

> Issue 293 	Pending 	Technical 	Watchdog Timer
> <http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20293>
> Alan DeKok

  I would prefer to leave the discussion of Status-Server && RADIUS ID
use in this document.  The traditional use of Status-Server is over UDP,
and therefore does not have the issues presented here.  (i.e. suggestion
to reserve one RADIUS ID per TCP connection for Status-Server.)

  Since this document is discussing non-traditional TCP transport issues
related to Status-Server, this document appears to be the best place for
this discussion.

> Issue 294 	No Discussion 	Technical 	Document Status
> <http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20294>
> Bernard Aboba

  I have updated the document status to be "Experimental", to be in line
with the RadSec document, which is also experimental.

> Issue 295 	Pending 	Technical 	Head of Line Blocking
> <http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20295>
> Alan DeKok <mailto:[email-masked]>

  This issue appears to be substantially similar, if not ientical, to
Issue 291.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 16 Dec 2008 08:55:32 -0800

> to reserve one RADIUS ID per TCP connection for Status-Server.)

Why should the ID be unique regardless of packet code when run
over reliable transport, but not UDP?  This suggests that the ID is
being processed differently for unreliable vs. reliable transport, which
seems odd.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 17 Dec 2008 15:23:14 +0100

> being processed differently for unreliable vs. reliable transport, which

  With UDP, there is no "connection" from client to server.  So any
Status-Server checks are sent from any client port.  This removes much
of the problem of reserving one ID: the client just opens another source
port.

  If it uses the same source port for Status-Server as for
Access-Request, then it would need to ensure that the ID allocated to
Status-Server is unused by any Access-Request.

  With TCP, there is a connection between client and server.  The
watchdog timer algorithm in RFC 3539 is defined per *connection*.  So an
ID has to be reserved, because the client can't open a new connection to
test if an existing connection is still alive.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 17 Dec 2008 09:22:31 -0800

> Status-Server is unused by any Access-Request.

The problem is not so much with the Status-Server/Access-Request ID
conflict, as with the potential conflict of Access-Accept IDs, correct? 

> test if an existing connection is still alive.

Ah.  I understand now.  Let's talk about the implications of this on a separate
thread.  Some of the above logic might be worth putting into the document.