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

From: Jouni Korhonen <[email-masked]>
Date: Fri, 9 Aug 2013 15:02:28 +0300

Folks,

Based on the discussion in Berlin we are ready to start another
adoption call for the solution for fragmentation of RADIUS packets.

This email starts a two week consensus call on adopting:

 Filename:         draft-perez-radext-radius-fragmentation
 Revision:         06
 Title:            Support of fragmentation of RADIUS packets
 Creation date:    2013-07-02

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

- Jouni & Mauricio

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 19 Aug 2013 10:11:19 +0300

A friendly reminder !

---

From: Stefan Winter <[email-masked]>
Date: Wed, 21 Aug 2013 09:37:21 +0200

Hello,

I support adoption of this document as an immediate solution to a
real-world problem.

As stated on the mic in Berlin, a more long-term solution would be to
modify the RADIUS protocol to allow more than 4096 bytes, and to
transmit over a transport which does not need to resort to UDP
fragmentation, i.e. over TCP (with or without TLS). I understand that
work to that end is ongoing, but not submitted as an I-D yet. When that
work has happened, it may be that the the work done in this draft will
eventually become obsolete; but that's not a reason not to adopt it at
this point.

I've reviewed -06 and have a few nits.

1. Introduction
===============
You state: "As noted in that document [RFC6158], the practical
   limit on RADIUS packet sizes is governed by the Path MTU (PMTU),
   which may be significantly smaller than 4096 octets."

I wouldn't phrase it in such a harsh way. A packet with
PMTU < packet size <= 4096
will lead to UDP fragmentation, sure. But that's not the end of the
world. The consequence of it is that you have to make sure you are using
sane network equipment which can handle that condition. When that is the
case, the practical limit remains the 4096 boundary.

In eduroam, we firs thought that we'll have to limit ourselves to the
PMTU in an attempt of duck-and-cover, but in the long run, the only sane
thing to do was to document that UDP frag support is required, and to
shout loudly at operators if we found their equipment not to do it properly.

In that light, I see your draft as useful (only) in cases where the data
to be transmitted is actually >4096 bytes; for anything below my answer
would be "fix your equipment!".

In the second bullet, you state that the approach "is not usable". As
you explain later in the paragraph, it *is*. It is only very clumsy;
some deployments might put enough effort into their setup to get it to
work that way. So for this item, I'd rather like to see you state that
it is not very practical for most deployments, as opposed to unusable.

Your draft is from 2 July, when RADIUS Extensions was already RFC6929;
you still mention its draft. Please update the reference.

2. Scope
========
I have trouble parsing the third and fourth para here. First you state
that CoA does not need to be fragmented. Then in the next para there
seems to be a mechanism that is about: if it is needed anyway, then
here's an alternative to do it; the alternative involves sending an
Access-Request.

I don't understand how this goes together. If it's not needed, it's not
needed - and no alternative needs to be specified.

I guess the core of my confusion is the sentence "Implementations
supporting this specification may not be able to change authorization
data for a particular session." Why (they do support fragmentation, but
not for this particular session)? And if they can't, why is that a
fragmentation problem?

I also don't get how the roles are here. A CoA client is often the
RADIUS server; the CoA Server is the NAS.

In that paragraph, "implementations" seems to be a CoA Server/NAS -
because you require such an implementation to send a CoA NAK.
If that's true, I wonder why fragmentation would occur; the bulk of the
authorization change payload data is sent from the CoA client (RADIUS
server) to the CoA Server (NAS). The return is either an ACK or a NAK,
but according to RFC5176's Table of Attributes, their content is
extremely limited in size.

3. Overview
===========
As stated above, IMHO your definition of "size limit" should really be
exactly 4096 bytes; not the min(PMTU,4096).

I also continue my long-standing comment about hazardous unknowns again:
You state

  "The number of
   attributes encoded in a particular chunk depends on the size limit,
   the size of each attribute, the number of proxies between client and
   server, and the overhead for fragmentation signalling attributes."

The size limit, size of attributes, and size of fragmentation overhead
signalling are known and can be calculated.

The "number of proxies between client and server" is UNknown and CANNOT
be considered in the chunk size calculation. Even if Proxy-State-Len is
able to figure out how many Proxy-State space is needed, it will still
be a whacky assumption because those proxies could decide they need to
add *more* bytes than just a Proxy-State attribute; they could add or
delete more VSAs or arbitrary other attributes. There is no way for an
implementation of your draft to know that. I know that sections 5 and 7
speak about this. I just want to reiterate that this is a rather
dangerous/necessarily-clumsy area of the spec. E.g. Proxy-State-Len
might fail its discovery if the packet size is not monotonically
increasing from proxy to proxy.

It might be worthwhile to consider if stacking of fragmentation is
possible with your draft; i.e. if a proxy receives a chunk, can it use
the fragmentation draft to split that incoming packet into chunks on its
own again? Can the receiver make sense of that double-fragging? I didn't
wrap my head around your draft enough to be able to answer that question
myself at this point :-)

In the paragraph about the "Extended Type" attributes you introduce a
new flag to support chunking. I'm not convinced this is necessary. Sure,
RFC6929 requires that all fragments of Long-Extended need to be
consecutive, in the same packet, and be in-order. But that is not
necessarily something you need to consider; your draft requires to
re-assemble the chunks before treating the combined result as packet "as
usual". So long as the Long-Extended checks are performed after the
re-assembly has been done, all is fine on that layer.

4.1 Pre-authz
=============
For the last exchange, you incorrectly state
"It generates the appropriate response, which can be either
Access-Accept or Access-Reject."

It may also be an Access-Challenge; imagine a big fragmented packet, out
of which one attribute is EAP-Message which starts an EAP conversation.

6. Allowed size
===============
It might be worthwhile to calculate how much actual fragmented data will
be transmittable with 20 such roundtrips, and the maximum possible overhead.

I think it would be (4096-517)*19+(4096-517+253) in the worst case (one
round-trip's User-Name is actually part of the payload, and not a
repetition.

9.1 Legacy proxies
==================
There is an implicit assumption in the draft that proxies make their
routing decisions based on User-Name; that's the reason why User-Name
always gets repeated in every chunk.

The whole fragmentation along unmodified proxies will break if the proxy
uses other attributes for its forwarding decisions, say the SSID part of
Called-Station-Id.

I don't know how common that is; but your draft should at least
explicitly state that User-Name is the (only) attribute that proxies can
use to make their forwarding decisions. You may also want to discuss
replacing or augmenting the attribute repetition for other attributes as
needed; but that increases the complexity of your draft significantly.

Actually, now that I think of it, I have heard of (few) eduroam SP
RADIUS proxies which decide based on the SSID whether the incoming
request is for eduroam (proxy to their national eduroam server) or for
something else (proxy elsewhere). So that use case is not completely
theoretical.

Greetings,

Stefan Winter

On 09.08.2013 14:02, Jouni Korhonen wrote:
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext
> 

-- 
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

---

From: Alan DeKok <[email-masked]>
Date: Wed, 21 Aug 2013 08:10:36 -0400

Some short responses.

  The PMTU / 4096 octet problem is one which I think should be supported
by the draft.  Telling operators to "fix their equipment" works in some
cases.  In others, it's useful to be able to fragment at sizes which are
*known* to work.

  Fragmentation in this draft is only for authorization (Access-Request
/ Access-Accept).  CoA can be done via sending a CoA with "Service-Type
= Additional-Authorization".  The client should then do fragmentation as
per the draft.  It's just too much to add fragmentation in multiple
places in the protocol.

  Additional fragmentation in proxies can be done.  But it likely
involves re-assembly and subsequent re-sending / re-fragmentation of the
entire data.  Doing "on the fly" additional fragmentation is just too
hard (IMHO).

  We need a new flag for extended-type attributes.  Each Access-Request
 / Access-Accept packet MUST be a perfect RADIUS packet in and of
itself.  Some proxies MAY support RFC 6929, and will toss the packet if
it isn't formatted correctly.  i.e. if the attribute fragments "fall
off" the end of a packet.

  Fragmentation doesn't work with Access-Challenge.  There was a lot of
discussion between the draft authors about this.  The fragmentation is
*only* for authorization.  And it carries *only* authorization data, not
authentication data.  Think of it as pausing an existing RADIUS
conversation, and inserting a "fragmented data" exchange.

  We're assuming that proxy decisions are made via User-Name.  If it's
done via anything else... well... sorry, but it won't work.  There are
trade-offs which have to be made.

  And eduroam proxying via SSID is just weird.  Isn't the SSID for
eduroam just "EDUROAM"?

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 21 Aug 2013 08:36:33 -0400

>>>>> "Stefan" == Stefan Winter <[email-masked]> writes:

    Stefan> Hello, I support adoption of this document as an immediate
    Stefan> solution to a real-world problem.

    Stefan> As stated on the mic in Berlin, a more long-term solution
    Stefan> would be to modify the RADIUS protocol to allow more than
    Stefan> 4096 bytes, and to transmit over a transport which does not
    Stefan> need to resort to UDP fragmentation, i.e. over TCP (with or
    Stefan> without TLS). I understand that work to that end is ongoing,
    Stefan> but not submitted as an I-D yet. When that work has
    Stefan> happened, it may be that the the work done in this draft
    Stefan> will eventually become obsolete; but that's not a reason not
    Stefan> to adopt it at this point.

I will be submitting such a draft by the next IETF.

I actually think this work is an important part of the long-term picture
because I think there cre cases where RADIUS UDP is important and
probably cases where proxy transparency is critical in the long-term.
There are definitely cases where proxy-transparency is critical in the
short-term.

So, I support adoption, but I also support permitting longer packets
over TLS and to the extent practical TCP.

(TLS has the nice property of being experimental at this point and while
interoperability with the existing implementations for 4k packets is a
requirement, I think we have more flexibility than we do for UDP).

---

From: Peter Deacon <[email-masked]>
Date: Wed, 21 Aug 2013 06:32:38 -0700 (Pacific Daylight Time)

> work to that end is ongoing, but not submitted as an I-D yet. When that

This is supported by my existing I-D. 
draft-deacon-radext-extended-request-01

regards,
Peter

---

From: Stefan Winter <[email-masked]>
Date: Wed, 21 Aug 2013 15:44:55 +0200

Hi,

> cases.  In others, it's useful to be able to fragment at sizes which are

I don't have particularly hard feelings about this; so if there's use
for it, the text can also stay as it is.

> per the draft.  It's just too much to add fragmentation in multiple

That's how I understood the first two paras in the document. The third
one seemed to deal with the CoA-ACK/NAK replies, but there I got lost
why these would need to be fragmented.

> entire data.  Doing "on the fly" additional fragmentation is just too

So it would suffice to state that chunks are not supposed to be
fragmented as-is; they need to be re-assembled into the long packet, and
then that needs to be chunked again.

> off" the end of a packet.

That doesn't seem right. If a proxy supports RFC6929, but not the
fragmentation draft, it will not know that the T flag exists and can't
react accordingly. It will see an M flag and some gibberish in the
Reserved field (which RFC6929 says should simply be ignored). It will
observe that the M flag requirements are violated and has every right to
drop the packet.

> conversation, and inserting a "fragmented data" exchange.

That's understood; I didn't want Access-Challenge packets to be
fragmented. My concern was that an initial (long) Access-Request needs
to be fragmented, but that upon completing its reassembly, the server
side finds that it is in the middle of an exchange which requires
Access-Challenge as a subsequent packet. It must be possible to finalise
the fragmented packet reassambly not just with an Accept or Reject; it
may need to be a Challenge to complete the subsequent authentication
that is done after the pre-authz.

>   And eduroam proxying via SSID is just weird.  Isn't the SSID for

Sure it is. But you may be participating in more than one consortium
with your hotspot.

Imagine a single access point which is part of "eduroam" and "S-Mobile";
and emits both SSIDs. Both consortia use RADIUS auth; the access point
is dumb and only knows "its" authentication server.

At that point, the RADIUS server which gets the AP's packet needs to
realise: if a user tried to log into the eduroam SSID, I'll proxy the
packet to eduroam infrastructure; if the user tried S-Mobile, I'll proxy
to their infrastructure.

That's real life (but not on very many sites, as far as I can see).

"Sorry" may well be the appropriate answer. But that answer should be
written explicitly into the draft.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Peter Deacon <[email-masked]>
Date: Wed, 21 Aug 2013 11:05:16 -0700 (Pacific Daylight Time)

> adoption call for the solution for fragmentation of RADIUS packets.

I would support this draft with narrower scope as interim solution 
addressing a specific use.

Have some concerns with draft as a general solution:

Section 2.

RFC5176 dynamic auth clients are not necessarily always RADIUS servers. 
We have production systems where CoA client and RADIUS server are separate 
with separate roles.  Seeing value in maintaining separation I do not 
favor Additional-Authorization.

Accounting proposal is not atomic and depends on assumptions about type of 
content.  (e.g long attribute not able to fit within 4096 byte limit 
cannot be transmitted)

Proposed 'T' bit in extended long attributes means existing systems 
supporting extended attributes may require enhancement to pass needed 
data.  Despite 'SHOULD' language from RFC6929 I do not believe it 
reasonable expectation proxy systems able to understand an attribute known 
to be broke would elect to forward such an attribute anyway.

General.

Attribute proxy not possible without proxy server modification to support 
draft.

Existing proxy servers not supporting draft may lose ability to 
understand/enforce policy when attribute fragmentation is used.

Section 5.

A policy of limiting large RADIUS UDP packets to MTU would about triple 
number of round trips needed to convey same information.

Section 10.

Message-Authenticator does not offer replay protection.  Recommend text 
"This signature prevents forging to the limits of the existing security."

regards,
Peter

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 22 Aug 2013 09:24:11 +0200

Hi Stefan,

thanks for the thorough review. Let me try to complete Alan's answers.

> be considered in the chunk size calculation.

Actually, they are known by the Server, but unknown by the Client. When 
the server is the one fragmenting information, that information is accurate.

> Even if Proxy-State-Len is
> implementation of your draft to know that.

That's right. Proxy-State-Len provides an approximation to that value. A 
Client will probably adjust chunk size as if Proxy-State-Len would be 
higher. I agree that being conservative is the best.
This calculation mechanisms does not solve all the problems, but IMHO 
offers more information that using plain RADIUS, where the Client cannot 
even guess.

> I know that sections 5 and 7

I agree. This attribute tries to help deciding. A Client may keep 
sending 1KB chunks no matter what the Proxy-State-Len says. In the worse 
case, you have plain RADIUS (i.e. chunk size fixed on configuration files).

> wrap my head around your draft enough to be able to answer that question

No, please :).

> re-assembly has been done, all is fine on that layer.

It will not be an Access-Challenge, as the Access-Request of a pre-authz 
exchange does not contain any authentication attribute (e.g. 
EAP-Messsage). It only contains authorization related information, thus 
suitable responses are Access-Accept (i.e. I correctly received and 
understood your data), or Access-Reject (i.e. data not understood or not 
valid).

In previous versions of the draft it was possible to do what you said, 
but we decided to simplify to avoid a lot of troubles if mixing with 
authentication exchanges.

> 6. Allowed size

Well, the draft also states to set the limit in a few tens of kilooctets 
20. That is, whatever is reached first. Nonetheless, this are 
recommendations, but it will be a configuration decision, not sure if it 
is really important to state in the draft.

Best regards,
Alejandro
> 1 Legacy proxies

---

From: Stefan Winter <[email-masked]>
Date: Thu, 22 Aug 2013 09:53:08 +0200

Hi,

> the server is the one fragmenting information, that information is accurate.

It doesn't know; it's an estimation which is hopefully rather accurate
these days because many sane implementations of forwarding server do add
Proxy-State; but they are not at all obliged to.

RFC2865, 2.3 "Proxy" states:

The forwarding server MAY add one Proxy-State attribute to the
      packet.  (It MUST NOT add more than one.)

So your server in the end may see less Proxy-State than there were
proxies. This is mostly irrelevant to your draft, because if that proxy
didn't add Proxy-State, then is also doesn't consume space in the packet.

OTOH, if that proxy decided that it wants to add other attributes
besides Proxy-State, then that proxy *will* have an impact. For extra
fun, consider that a proxy may not feel the urge to add an attribute in
the request, but does so in the reply. That makes for an asynchronous MTU!

This begs the question: if a fragmentation-draft-unaware proxy receives
a chunk close to 4096, and decides it wants to add an arbitrary
attribute on its own, and cannot -> bad luck, discard?

I also just found another gem regarding Proxy-State that I wasn't aware
of until now: a forwarding server may truncate the Proxy-State values it
found from earlier proxies, and only send its new one further on. It
merely needs to remember the content of the earlier ones, to add them
back in the reply. I'm speaking of this text in the same section:

"  The forwarding server MAY
   include the Proxy-State attributes in the access-request when it
   forwards the request, or MAY omit them in the forwarded request.  If
   the forwarding server omits the Proxy-State attributes in the
   forwarded access-request, it MUST attach them to the response before
   sending it to the client."

This would totally break your proxy detection. I am not aware of anyone
implementing this though.

> offers more information that using plain RADIUS, where the Client cannot

Your 7.1 point 3 does not explicitly mention that the client should
leave some leeway. You might want to add a sentence to that effect.

>> wrap my head around your draft enough to be able to answer that question

Okay :-) Alan's response kind of gave a hint already: reassemble the
whole packet, add your attributes, chunk it.

The question of frag-unaware proxies remains; their only choice is to
discard if they can't fit in their attributes.

> authentication exchanges.

That's not what your example does: The packet in 4.1 contains a
"User-Password" attribute.

Maybe that's a leftover from an earlier rev?

> is really important to state in the draft.

My point is that you could give implementers or even deployers some
hints regarding "what they get" for specific values. Just stating: when
using the default 20 roundtrips maximum ceiling, the amount of data that
can be transferred is between x Bytes (lowest overhead) and y Bytes
(highest overhead).

It makes life easier for people who want or need to judge whether the
default value is good enough for their implementation or deployment.
It's just a suggestion for readability / comprehensability of the draft
anyway.

Greetings,

Stefan

Tel: +352 424409 1
Fax: +352 422473

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 22 Aug 2013 09:56:22 +0200

> why these would need to be fragmented.

We will improve that paragraph, to make it clearer.

> then that needs to be chunked again.

We could add that sentence if it serves to clarify further that aspect.

> observe that the M flag requirements are violated and has every right to

Probably you are right. Indeed we have repeatedly discuss about that 
flag's utility, but we decided that having it will not harm anyone. 
However, it makes specification slightly complexer, and if it is not 
really useful, I agree it should be just removed.

> that is done after the pre-authz.

Nope, the first Access-Request packet of an Authentication conversation 
is supposed to not need to be fragmented, as authentication mechanisms 
(e.g. RADIUS-EAP) already deal with packet size. If a Client generates a 
large Access-Request packet with EAP-Message, would be most probably to 
the inclusion of additional authorization attributes, and then, a 
pre-authz exchange is the way to go.

> written explicitly into the draft.

We need to clearly state that, so far, proxying is only supported by 
means of User-Name attribute. Although I guess that's allowing a 
different attribute could be something configurable.

Best regards,
Alejandro

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 22 Aug 2013 10:10:53 +0200

> Proxy-State; but they are not at all obliged to.

I meant, when the server is sending chunks, it will know exactly how 
much space it needs to leave for sending back the received Proxy-State 
attributes, isn't it. (I will say otherwise below, after knowing more 
about proxy state behaviour :D)

> attribute on its own, and cannot -> bad luck, discard?
Exactly, just like it happens today with RADIUS.

> implementing this though.

Oh, I did not know either. This would complicate things, as the packet 
may grow arbitrarily between the Client and the Server, without any of 
them knowing that. That makes even more important to leave a "safety" 
margin.

> leave some leeway. You might want to add a sentence to that effect.

Sure. It should be stated.

> discard if they can't fit in their attributes.

Well, that's right.

> Maybe that's a leftover from an earlier rev?

Sure, it should be removed. Thanks!

> It's just a suggestion for readability / comprehensability of the draft

You are right, but in this particular portion of the text, 20 roundtrips 
means exactly that, 20 roundtrips. We also added a byte-based limit: "a 
few tens of kilooctets".
Probably that limit should be more specific, like 15 kilooctets, or 32. 
Anyway, if you think it would increase readability, it won't harm :).

Best regards,
Alejandro

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 22 Aug 2013 10:19:57 +0200

Hello Peter,

thanks for the comments. See some responses below.

El 21/08/13 20:05, Peter Deacon escribió:
> RFC5176 dynamic auth clients are not necessarily always RADIUS 
> servers. We have production systems where CoA client and RADIUS server 
> are separate with separate roles.  Seeing value in maintaining 
> separation I do not favor Additional-Authorization.
>
> Accounting proposal is not atomic and depends on assumptions about 
> type of content.  (e.g long attribute not able to fit within 4096 byte 
> limit cannot be transmitted)

I probably misunderstood your comment. We do not deal with CoA or 
Accounting exchanges. They are left the way they are.

> reasonable expectation proxy systems able to understand an attribute 
> known to be broke would elect to forward such an attribute anyway.

umm, you are probably right. Let's see what Alan says about this.

>
> General.
>
> Attribute proxy not possible without proxy server modification to 
> support draft.
>

According to your previous comment, that would be partially true, but 
only when the proxy supports RFC6929.

>
> Section 5.
>
> A policy of limiting large RADIUS UDP packets to MTU would about 
> triple number of round trips needed to convey same information.

That's probably right. You are able to send the data, but you have to 
pay a price. Compromise is the key here.

>
> Section 10.
>
> Message-Authenticator does not offer replay protection.  Recommend 
> text "This signature prevents forging to the limits of the existing 
> security."

Thanks, we will update the text accordingly.

Regards,
Alejandro

---

From: Alan DeKok <[email-masked]>
Date: Thu, 22 Aug 2013 09:14:27 -0400

Peter Deacon wrote:
> We have production systems where CoA client and RADIUS server are
> separate with separate roles.  Seeing value in maintaining separation I
> do not favor Additional-Authorization.

  There is a network connecting the machines.  The RADIUS server can
proxy Access-Requests to the maching hosting the CoA information.

> Accounting proposal is not atomic and depends on assumptions about type
> of content.  (e.g long attribute not able to fit within 4096 byte limit
> cannot be transmitted)

  There has been no demonstrated need for large accounting packets.

> known to be broke would elect to forward such an attribute anyway.

  There are no deployed proxies which implement 6929.  The
implementations could support the "T" bit before this document is
finalized.  Nothing prevents implementations from adding new,
non-standardized functionality.

> Attribute proxy not possible without proxy server modification to

  The only issue is the T bit.  No other proxy modifications are required.

> understand/enforce policy when attribute fragmentation is used.

  Tough.  Existing proxy servers which don't implement RFC 6929 won't
understand / enforce policies when RFC 6929 attributes are used.

  This argument is, IMHO, ridiculous.  If we are to believe it at face
value, it means we cannot implement ANY new feature in RADIUS.  Because
existing proxies won't be able to enforce policies for those new features.

  If you want to shut down all progress in RADEXT, just say so.  There's
no need to repeatedly bring up specious arguments.

> number of round trips needed to convey same information.

  Some systems don't support UDP fragmentation, and drop all fragmented
UDP packets.  So one alternative is to have *no* RADIUS traffic go
through the network.

  You may think that's better.  I don't.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 22 Aug 2013 09:18:40 -0400

> observe that the M flag requirements are violated and has every right to

  Yes.  That presumes (a) everyone implements RFC 6929, and (b) those
implementations get deployed to proxies.

  I don't think either will happen for a while.  That limits the
problems with this approach.

> packet to eduroam infrastructure; if the user tried S-Mobile, I'll proxy

  I think initially the idea is to have fragmentation from server to
server.  i.e. few (if any) APs will be implementing it.  So the issue
becomes less relevant.

  A server local to the AP can track a users session, including SSID.
And then make proxy decisions based on that.  The proxies in the wider
network will *not* know about the site's SSID, and will *not* be basing
proxy decisions on it.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Thu, 22 Aug 2013 09:48:08 -0700 (Pacific Daylight Time)

> proxy Access-Requests to the maching hosting the CoA information.

Speaking for myself this is problematic.  Dynamic auth clients are just 
clients with no capability to act as RADIUS server.  They only manage a 
subset of possible authorization parameters not capable of full response.

The argument is not whether it is possible to coordinate rather value in 
maintaining separation.  If transport limits are lifted rather than 
supporting adoption of this draft none of these "workarounds" are 
necessary.

>  There has been no demonstrated need for large accounting packets.

If authors see no value recommend removing associated references from 
draft.

>  There are no deployed proxies which implement 6929.  The

Incorrect

> non-standardized functionality.

If modification is necessary I see no value in supporting this draft vs 
solutions addressing underlying transport limit.  The whole point was that 
it work with existing systems unmodified.

>  The only issue is the T bit.  No other proxy modifications are required.

I apologize for any confusion.  By attribute proxy I mean forwarding 
requests based on attributes other than User-Name.

> existing proxies won't be able to enforce policies for those new 

My understanding is both existing and new attributes may be conveyed using 
the fragmentation mechanism.  Existing attributes may end up being 
transmitted in separate requests where previously they would have to occur 
in the same request.

>  You may think that's better.  I don't.

This is an edge problem within most operators administrative control to 
effect.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Thu, 22 Aug 2013 19:17:18 -0400

> subset of possible authorization parameters not capable of full response.

  Would it be possible to change them?  After all, implementing any
draft requires changes to existing systems.

  As with anything RADIUS, no proposal will be perfect.  There may be
some situations where the proposal doesn't match existing practices.
e.g. multiple clients behind a NAT.  The solution isn't to give on the
proposal and walk away.  The solution may be to say that certain
situations are simply not supported.

> supporting adoption of this draft none of these "workarounds" are

  Write a draft proposing to lift the transport limits for UDP.  Make it
 handle all of the existing situations.  e.g. "my upstream equipment
doesn't deal with fragmented UDP packets, therefore I absolutely oppose
raising the transport limits".

  When you replace one imperfect proposal with another imperfect
proposal because the first one is imperfect... I just find it unproductive.

> requests based on attributes other than User-Name.

  See my response to Stefan.

  Are there roaming federations which proxy based on anything *other*
than User-Name?  If so, I'm unaware of them.

  What you do in your own network is your issue.  However, the draft
could be clearer, and state that private networks need to do something
so that the fragmentation proxy works.

> My understanding is both existing and new attributes may be conveyed
> using the fragmentation mechanism.  Existing attributes may end up being
> transmitted in separate requests where previously they would have to
> occur in the same request.

  Yes.  This does not address my counter-argument.

> [ re: UDP fragmentation]

  Maybe.  Do a search for "SIP UDP fragmentation", and you'll see many
complaints.  The summary is that fragmented UDP packets are not
generally supported across the Internet.  An operator may be able to fix
their own equipment.  They do *not* have the capability to fix someone
else's equipment.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Thu, 22 Aug 2013 17:12:45 -0700 (Pacific Daylight Time)

> Accounting exchanges. They are left the way they are.

Hi Alejandro,

>From section 2 "scope of this document".  Perhaps it might be best to 
simply address what is supported and remove extraneous references to what 
is not changed (CoA and Accounting).  Specifically:

"  Instead, the
    CoA client MUST send a CoA-Request packet containing session
    identification attributes, along with Service-Type = Additional-
    Authorization, and a State attribute.  Implementations not supporting
    fragmentation will respond with a CoA-NAK, and an Error-Cause of
    Unsupported-Service.

    Implementations supporting this specification may not be able to
    change authorization data for a particular session.  In that case,
    they MUST respond with a CoA-NAK, as above.  Otherwise, the
    implementation MUST start fragmentation via Access-Request, using the
    methods defined here."

> only when the proxy supports RFC6929.

Thinking about a case where there is a fragmented "Pre-authorization" 
request.  Attributes normally sent with Access-Request could be scattered 
about in different Access-Requests requests?

I'm a little confused with "authentication" terminology normally during 
Access-Request there are attributes which provide context to 
authentication and then attributes which perform authentication.

Attributes normally in Access-Request that are not passwords or EAPs is 
essentially "Pre-authorization" or is there another separation?

>From section 2

" Specifically, its scope is limited to the exchange of authorization
    data, as other exchanges do not require of such a mechanism.  In
    particular, authentication exchanges have already been defined to
    overcome this limitation"

Is this still true in -06?

For example am I allowed to send NAS-Id in first request and a 
NAS-Port-Type attribute in subsequent message where they are later 
combined by RADIUS server?  If so just as an example what happens if an 
old proxy server is doing something that depends on both of these items 
being present?  If just one is present there could be behavior it misses?

regards,
Peter

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Fri, 23 Aug 2013 13:27:09 +0200

El 23/08/13 02:12, Peter Deacon escribió:
>>> servers. We have production systems where CoA client and RADIUS 
>>> server are separate with separate roles.  Seeing value in 
>>> maintaining separation I do not favor Additional-Authorization.
>
>>> type of content.  (e.g long attribute not able to fit within 4096 
>>> byte limit cannot be transmitted)
>
> simply address what is supported and remove extraneous references to 
> what is not changed (CoA and Accounting). Specifically:
>
> "  Instead, the

The purpose of that text is to explain why we do not deal with CoA or 
Accounting, that is, why they do not need of a fragmentation solution. 
Removing them would provoke other people to ask why we do not support them.

>>> supporting extended attributes may require enhancement to pass 
>>> needed data. Despite 'SHOULD' language from RFC6929 I do not believe 
>>> it reasonable expectation proxy systems able to understand an 
>>> attribute known to be broke would elect to forward such an attribute 
>>> anyway.
>
> request.  Attributes normally sent with Access-Request could be 
> scattered about in different Access-Requests requests?
>
> I'm a little confused with "authentication" terminology normally 
> during Access-Request there are attributes which provide context to 
> Attributes normally in Access-Request that are not passwords or EAPs 
> is essentially "Pre-authorization" or is there another separation?

They are completely different exchanges, composed by different packets. 
Let me picture it.

Let's imagine the following exchange where, in addition to the usual 
authentication exchange (that is, RADIUS-EAP), the NAS wants to send a 
SAML request to the AS, that will be replied after the User has been 
authenticated. SAML messages could exceed the 4096 limit.

User ----- EAP-Identity ---> NAS (triggers a RADIUS conversation)

Pre-authorization exchange: NAS needs to send authz data to AS prior 
authentication. This is actually carried out by a series of 
Access-Request/Access-Accept exchanges.
NAS  ----- SAML request ---> AS

Authentication exchange: typical RADIUS-EAP exchange. No changes at all.
NAS  ----- EAP-Identity ---> AS
NAS  <----     EAP      ---> AS
NAS  <---- Access-Accept---- AS

Post authorization exchange: AS needs to send authz data to NAS after 
authentication. This is actually carried out by a series of 
Access-Accept/Access-Request exchanges.
NAS  <---- SAML Response---- AS

All these exchanges are tied together by the use of the State attribute.
I hope this clarifies the concepts
> Is this still true in -06?

That paragraph just states that current existing authentication 
exchanges (e.g. RADIUS-EAP) already deal with fragmentation issues. 
That's why we do not interfere.

> combined by RADIUS server?  If so just as an example what happens if 
> an old proxy server is doing something that depends on both of these 
> items being present?  If just one is present there could be behavior 
> it misses?

Alan provided an answer to this in relation to Stefan's comments: We're 
assuming that proxy decisions are made via User-Name.

Regards,
Alejandro

---

From: Stefan Winter <[email-masked]>
Date: Fri, 23 Aug 2013 14:01:17 +0200

Hi,

> implementations get deployed to proxies.

Most RADIUS servers are versaitle enough to act as server and proxy;
Radiator has hinted towards 6929 support soon, and I believe your
FreeRADIUS is a reference implementation of it since a long time. Both
can proxy, and both are in wide-spread use.

I think the issue is not artificial; it may well bite a deployment in
its backside.

That's not the end of the world though; simply adding a sentence in the
draft such a case exists and that deployments need to take care that
their deployed implementation(s) don't stumble over this.

> server.  i.e. few (if any) APs will be implementing it.  So the issue

Aha! I had the impression that authz exchanges in the ABFAB world go all
the way from/to the RADIUS client that does the whole GSS EAP magic. And
that this is the equivalent of an "AP" in the non-network-access use case.

> network will *not* know about the site's SSID, and will *not* be basing

That's something I can live with. Again, documenting in the draft that
User-Name is the only proxying criterion would be enough for me then.
Maybe a second one explaining that client to first-server is not in
scope/has complexities that can make the use of this draft hard/unsuitable.

Greetings,

Stefan

Tel: +352 424409 1
Fax: +352 422473

---

From: Sam Hartman <[email-masked]>
Date: Fri, 23 Aug 2013 08:29:14 -0400

>>>>> "Alejandro" == Alejandro Perez Mendez <[email-masked]> writes:

    Alejandro> El 23/08/13 02:12, Peter Deacon escribió:
    >>> Hello Peter, thanks for the comments. See some responses below.
    >> 
    >>>>> Based on the discussion in Berlin we are ready to start
    >>>>> another adoption call for the solution for fragmentation of
    >>>>> RADIUS packets.
    >> 
    >>>> I would support this draft with narrower scope as interim
    >>>> solution addressing a specific use.
    >> 
    >>>> Section 2.  RFC5176 dynamic auth clients are not necessarily
    >>>> always RADIUS servers. We have production systems where CoA
    >>>> client and RADIUS server are separate with separate roles.
    >>>> Seeing value in maintaining separation I do not favor
    >>>> Additional-Authorization.
    >> 
    >>>> Accounting proposal is not atomic and depends on assumptions
    >>>> about type of content.  (e.g long attribute not able to fit
    >>>> within 4096 byte limit cannot be transmitted)
    >> 
    >>> I probably misunderstood your comment. We do not deal with CoA
    >>> or Accounting exchanges. They are left the way they are.
    >> 
    >> Hi Alejandro,
    >> 
    >> From section 2 "scope of this document".  Perhaps it might be
    >> best to simply address what is supported and remove extraneous
    >> references to what is not changed (CoA and
    >> Accounting). Specifically:
    >> 
    >> " Instead, the CoA client MUST send a CoA-Request packet
    >> containing session identification attributes, along with
    >> Service-Type = Additional- Authorization, and a State attribute.
    >> Implementations not supporting fragmentation will respond with a
    >> CoA-NAK, and an Error-Cause of Unsupported-Service.
    >> 
    >> change authorization data for a particular session.  In that
    >> case, they MUST respond with a CoA-NAK, as above.  Otherwise, the
    >> implementation MUST start fragmentation via Access-Request, using
    >> the methods defined here."
    >> 

    Alejandro> The purpose of that text is to explain why we do not deal
    Alejandro> with CoA or Accounting, that is, why they do not need of
    Alejandro> a fragmentation solution. Removing them would provoke
    Alejandro> other people to ask why we do not support them.

I support retaining the section 2 text.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 23 Aug 2013 08:41:01 -0400

> their deployed implementation(s) don't stumble over this.

  Yes.  Even if there are deployed proxies which implement 6929, there
are no attributes which use the 6929 format.  So there's a bit of time
to upgrade the systems.

> that this is the equivalent of an "AP" in the non-network-access use case.

  In the abfab world, they may go to the client, which can be a
commodity system with user logins, web browser, etc.  i.e. a capable system.

  I don't recall seeing a demand for APs or switches to implement the
fragmentation draft.

> scope/has complexities that can make the use of this draft hard/unsuitable.

  Yes.  We'll do that.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 24 Aug 2013 10:06:47 -0400

> Proxy-State; but they are not at all obliged to.

  From what I've seen, Proxy-State has little or no value.  FreeRADIUS
adds it because there's a suggestion to do so.  But it doesn't do
anything with Proxy-State.

> attribute on its own, and cannot -> bad luck, discard?

  Pretty much.  Or, to *not* add the attribute.

> back in the reply. I'm speaking of this text in the same section:

  Yes.  I'm not aware of anyone who does that, though.

> discard if they can't fit in their attributes.

  Yes.  That's a reason to either not re-write packets in a proxy, or to
keep the maximum packet size "small", to leave room for proxy re-writing.

  Alan DeKok.

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 26 Aug 2013 10:35:56 +0300

Folks,

We got some support and none going against the adoption. There were
already some very detailed discussion on aspects people want to see
changed in the document, which is a really good start.

We will take draft-perez-radext-radius-fragmentation-06 as the _basis_
for the WG solution. Now the WG needs to come up with text that everybody
agrees with. whether we need further documents on fragmentation, e.g. as
a generic long term solution is to be seen and discussed.

- Jouni & Mauricio