Subject: [radext] Adoption call for draft-perez-radext-radius-fragmentation-05

From: Jouni Korhonen <[email-masked]>
Date: Sat, 9 Feb 2013 00:53:07 +0200

Folks,

This email starts a two week consensus call on adopting:

  Filename:         draft-perez-radext-radius-fragmentation
  Revision:         05
  Title:            Support of fragmentation of RADIUS packets
  Creation date:    2013-02-08
  Number of pages:  27

Express your concerns or support by 23rd Feb on the mailing list.

- Jouni & Mauricio

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 11 Feb 2013 08:50:17 -0800

I am against adopting this document, because the problem is not well stated, the requirements for a solution (such as backward compatibility) are not identified and potential alternative solutions are not identified.   In particular:

a. The document states that there are no other proposals for solving the problem.  In fact, recommended solutions are described in RFC 6158 Section 3.1 - and requirements are also outlined there.  

b. The document gives examples of SAML assertions and JSON tokens as reasons why the limit needs to be extended.  As noted in RFC 6158 Section 3.1, other mechanisms (such as names and URLs) can be used to handle those cases. 

c. The document does not adequately describe how backward compatibility is handled in various cases.  For example, a RADIUS client may be talking to a RADIUS proxy that supports the extension, but the RADIUS server may not; or the RADIUS client could be talking to a legacy RADIUS proxy, but the server may support the extension.  The document does not describe  how these different cases are detected.  Instead, it seems to assume that the extension is supported uniformly.  

> From: [email-masked]
> Date: Sat, 9 Feb 2013 00:53:07 +0200
> To: [email-masked]
> CC: [email-masked]
> Subject: [radext] Adoption call for	draft-perez-radext-radius-fragmentation-05
> 
> Folks,
> 
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: Alan DeKok <[email-masked]>
Date: Mon, 11 Feb 2013 14:30:36 -0500

Bernard Aboba wrote:
> I am against adopting this document, because the problem is not well
> stated, the requirements for a solution (such as backward compatibility)
> are not identified and potential alternative solutions are not
> identified.   In particular:
> 
> a. The document states that there are no other proposals for solving the
> problem.  In fact, recommended solutions are described in RFC 6158
> Section 3.1 - and requirements are also outlined there. 

  I'll deal with that section by section.

3.1 1)  doesn't talk about pre-authentication data sent from the NAS to
a server.  This data doesn't fit into 4K packets.  Leveraging EAP
(request / challenge) to send the data isn't feasible.  EAP already
fills packets to PMTU, and not all authentications use EAP.

  As is noted for NAS-Filter-Rule, sending large amounts of data server
to NAS is a problem.  This draft addresses that problem.

  The rest of the comments apply (CoA, Accounting, etc.)  The
fragmentation draft doesn't propose changing that.

  2) Using names rather than values works for many use-cases.  Where the
data is more dynamic (e.g. SAML authorization), that is difficult or
impossible to pre-provision "named" policies.  They need to be dynamic.

  Similar comments apply for dynamic NAS-Filter-Rules.

  3) PMTU discovery doesn't work that well, as noted in 6158.

> b. The document gives examples of SAML assertions and JSON tokens as
> reasons why the limit needs to be extended.  As noted in RFC 6158
> Section 3.1, other mechanisms (such as names and URLs) can be used to
> handle those cases.

  Names are problematic for reasons noted above.  6158 doesn't appear to
reference URLs, so far as I can find.  URLs were discussed on the RADEXT
list prior to publication.

  I think URLs would be a good solution, if they can be (a) dynamically
created, (b) have contents dynamically updated. (c) securely accessed,
and (d) accessed from remote systems.

  Satisfying all of those constraints is hard.  A working solution is to
leverage RADIUS.

> c. The document does not adequately describe how backward compatibility
> is handled in various cases.  For example, a RADIUS client may be
> talking to a RADIUS proxy that supports the extension, but the RADIUS
> server may not; or the RADIUS client could be talking to a legacy RADIUS
> proxy, but the server may support the extension.  The document does not
> describe  how these different cases are detected.  Instead, it seems to
> assume that the extension is supported uniformly. 

  The document could be clearer.

  One of the major goals for this proposal is to be transparent to
existing proxies.  The only systems needing to implement the draft at
the ones which either generate, or consume the "large" data being
fragmented.  The intermediate proxies just pass everything through
unchanged.

  If the proxies want to examine the contents of the "large" data, then
they need to re-assemble it.  But the fragmentation proposal has been
tested with unaware proxies, and it works fine.

  I think the take-aware here is that the document could use updates
with respect to problem statement, clarification of terminology,
use-cases, and text which addresses the 6158 concerns.

  A simple version of the problem statement is this.  One RADIUS system
needs to send large amounts of data to another RADIUS system.  The
RADIUS system administrators may not have access to the firewall, web
server, routers, or any other application server.  They do have access
to RADIUS.  So it makes a certain amount of sense to transfer the data
over RADIUS.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 11 Feb 2013 13:20:29 -0800

Thanks, Alan.  Your explanations below make a lot of sense.  Unfortunately, they are not in the document :(

Given that there are potentially multiple competing approaches, I think it is important for the requirements and problem statement to be clearly laid out, and for proposed solutions to describe how they address the requirements.  Before these pre-requisites have been completed, it seems premature to me to call for adoption of a particular solution. 

> Date: Mon, 11 Feb 2013 14:30:36 -0500
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [radext] Adoption call for	draft-perez-radext-radius-fragmentation-05
> 
> Bernard Aboba wrote:

---

From: Sam Hartman <[email-masked]>
Date: Tue, 12 Feb 2013 08:08:57 -0500

>>>>> "Bernard" == Bernard Aboba <[email-masked]> writes:

Bernard, I understand that you're concerned because you want us to make
sure we adopt a solution that actually meets our needs.  I appreciate
that concern.  I am concerned though because I've found that the
requirements process you are outlining tends to add significant value
and tends to be a very heavy-weight process.  So, I'd like to propose a
balance below that I think will allow your concern to be addressed
without introducing as much delay as the approach you recommend.

    Bernard> Given that there are potentially multiple competing
    Bernard> approaches, I think it is important for the requirements
    Bernard> and problem statement to be clearly laid out, and for
    Bernard> proposed solutions to describe how they address the
    Bernard> requirements.  Before these pre-requisites have been
    Bernard> completed, it seems premature to me to call for adoption of
    Bernard> a particular solution.

I am in favor of discussion on the list  of requirements and
 advantages/disadvantages of various proposals.

I am strongly against including requirements text in a draft that the Wg
adopts or in attempting to come to consensus within the WG on these
requirements.  My experience is that trying to do tends to slow down
work and is often used as a process approach for delaying/blocking
proposals.
It's my experience that having the requirements discussion is quite
valuable, but that it's easier to gain consensus on wether to do  the
work than it is to gain consensus on the requirements. The consensus on
the requirements is not actually necessary.

So, I think that  Alan's response--discussing the rationale on the
list--is the right one.

I would not object if Bernard or someone else wanted to write up an
informational document capturing that discussion. I recommend that
rather than attempting to gain consensus on such a document we simply
document the various positions that emerge.  I would not support
delaying adopting drafts or publishing solution on completion of such an
informational document.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 12 Feb 2013 09:28:25 -0500

I support adopting the previous version of this draft
(draft-perez-radext-radius-fragmentation-04) and would support adopting
the current version (draft-perez-radext-radius-fragmentation-05) if a
mechanism was added for fragmented information in access-request prior
to authentication.  That is, I disagree with one of the changes the
authors made between 04 and 05.

--Sam

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Fri, 22 Feb 2013 12:46:49 +0100

> authors made between 04 and 05.

Hi Sam,

we have been discussing this aspect internally, and we have concluded 
that the support of fragmentation prior to authentication will be 
re-incorporated into the next version of the document, though it will be 
noted that it may have the potential to allow DoS attacks.

Best regards,
Alejandro