Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt

From: "Jim Schaad" <[email-masked]>
Date: Sat, 3 Mar 2012 13:47:06 -0800

I have some comments on the draft.  However first let me say that I know next to nothing about RADIX having only briefly read it a couple of times and having not yet worked with it to any extent.

1.  I think a discussion is in order about the issues of packing a radius message full in the presence of proxy intermediaries which might need room for adding and removing routing materials.  I don't know how many proxies are keep local state as oppose to just filling up the message with Proxy-State items and thus need space on the way back.  Also a discussion of removal and re-insertion of the T flag might be needed if the proxy fully assembles the message and then relays it in pieces.

2.   The Overview in section 2 does not discuss the fact that a new set of state items might also added to the message.  This changes the limit of how many bytes can be placed into the fragmented packets.

3. nit - in para #3 of overview you use the word truncated and truncation.  I think a better word set might be partitioned and partitioning.  Also ensure that fragmentation is used strictly for the process in radius-extensions.  I have not found any cases yet were it is not but will try and remember to look.

4.  I am not sure if positioning of the more-data-pending packet is significant.  The introduction says it comes last but nothing to that effect is said in section 3.  

5.   Section 6 implies that the order of items in a set of fragmented packets might need to be changed based on the ability of items to be in the packet.  For example if the Access-Accept packet had been = Data1[M], Data2[M]...Data 10, User-Name, Service-Type[X], Framed-IP-Address the order would need to be changed in the original partitioning.  This should be mentioned someplace other than just in the "examples" section.  It implies that a general use piece of code to do this will need to have the table built in, and potentially extended as new items are added, rather than just being coded correctly in the specific packet type code.

6.  What if any indications does a server have that the client will be able to deal with the partitioned message other than it will either fail or get confused depending on what set of attributes are in the first packet and what it needs and feels it can ignore.

---

From: Alan DeKok <[email-masked]>
Date: Sun, 04 Mar 2012 08:10:04 +0100

> I have some comments on the draft.  However first let me say that I know next to nothing about RADIX having only briefly read it a couple of times and having not yet worked with it to any extent.

  Reviews are always welcome.

> 1.  I think a discussion is in order about the issues of packing a radius message full in the presence of proxy intermediaries which might need room for adding and removing routing materials.  I do…

  The simplest way to address that is to artificially lower the RADIUS
maximum packet size, as seen by the client.

> 2.   The Overview in section 2 does not discuss the fact that a new set of state items might also added to the message.  This changes the limit of how many bytes can be placed into the fragmented p…

  Yes.

> 5.   Section 6 implies that the order of items in a set of fragmented packets might need to be changed based on the ability of items to be in the packet.  For example if the Access-Accept packet ha…

  Attribute ordering is explicitly *not* required in RADIUS.

> 6.  What if any indications does a server have that the client will be able to deal with the partitioned message other than it will either fail or get confused depending on what set of attributes a…

  That's an open area for discussion.  RADIUS doesn't have capability
negotiation, so it's hard to do.

  Alan DeKok.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Mon, 05 Mar 2012 09:02:33 +0100

> maximum packet size, as seen by the client.

Additionally, regarding the T flag removal/re-insertion comment, proxies 
are not allowed to perform RADIUS fragmentation on forwarded packets. It 
is a process performed end-to-end the RADIUS client and server.

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 8 Mar 2012 20:54:03 -0800

> 
> > 1.  I think a discussion is in order about the issues of packing a
radius
> message full in the presence of proxy intermediaries which might need room
> for adding and removing routing materials.  I don't know how many proxies
> are keep local state as oppose to just filling up the message with
Proxy-State
> items and thus need space on the way back.  Also a discussion of removal
> and re-insertion of the T flag might be needed if the proxy fully
assembles
> the message and then relays it in pieces.
> 
maximum
> packet size, as seen by the client.
> 

Would this also be a way to deal with restrictions on the size seen by the
server?  I.e. you also need to make the server deal with smaller packets as
well.

Jim

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 8 Mar 2012 20:55:32 -0800

> -----Original Message-----
> From: Alejandro Perez Mendez [mailto:[email-masked]]
> Sent: Monday, March 05, 2012 12:03 AM
> To: Alan DeKok
> Cc: Jim Schaad; [email-masked]; [email-masked]
> Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-
> radius-fragmentation-01.txt
> 
> 
> 
> >> I have some comments on the draft.  However first let me say that I know
> next to nothing about RADIX having only briefly read it a couple of times and
> having not yet worked with it to any extent.
> >> 1.  I think a discussion is in order about the issues of packing a radius
> are keep local state as oppose to just filling up the message with Proxy-State
> and re-insertion of the T flag might be needed if the proxy fully assembles
> >    The simplest way to address that is to artificially lower the
> > RADIUS maximum packet size, as seen by the client.
> 
> Additionally, regarding the T flag removal/re-insertion comment, proxies are
> not allowed to perform RADIUS fragmentation on forwarded packets. It is a
> process performed end-to-end the RADIUS client and server.
> 

What happens for proxies that, for some reason - want to re-write the contents of packets.  For ABFAB I am specifically thinking of changing or mapping attributes in SAML assertions.

> >
> >> 2.   The Overview in section 2 does not discuss the fact that a new set of
> state items might also added to the message.  This changes the limit of how
> many bytes can be placed into the fragmented packets.
> >    Yes.
> >
> >> 3. nit - in para #3 of overview you use the word truncated and truncation.
> I think a better word set might be partitioned and partitioning.  Also ensure
> that fragmentation is used strictly for the process in radius-extensions.  I
> have not found any cases yet were it is not but will try and remember to
> look.
> >>
> >> 4.  I am not sure if positioning of the more-data-pending packet is
> significant.  The introduction says it comes last but nothing to that effect is
> said in section 3.
> >>
> >> 5.   Section 6 implies that the order of items in a set of fragmented packets
> might need to be changed based on the ability of items to be in the packet.
> For example if the Access-Accept packet had been = Data1[M],
> Data2[M]...Data 10, User-Name, Service-Type[X], Framed-IP-Address the
> order would need to be changed in the original partitioning.  This should be
> mentioned someplace other than just in the "examples" section.  It implies
> that a general use piece of code to do this will need to have the table built in,
> and potentially extended as new items are added, rather than just being
> coded correctly in the specific packet type code.
> >> 6.  What if any indications does a server have that the client will be able to
> deal with the partitioned message other than it will either fail or get confused
> depending on what set of attributes are in the first packet and what it needs
> and feels it can ignore.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 09 Mar 2012 09:15:30 +0100

> server?  I.e. you also need to make the server deal with smaller packets as

  Yes.  Servers already do this for EAP authentication.  If they see a
Framed-MTU, they ensure that the EAP packet will fit into that MTU.
This gives a secondary result that the size of the RADIUS packet is limited.

  Alan DeKok.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Fri, 09 Mar 2012 12:56:01 +0100

> What happens for proxies that, for some reason - want to re-write the contents of packets.  For ABFAB I am specifically thinking of changing or mapping attributes in SAML assertions.

I don't think a RADIUS proxy should change anything at a SAML level, but 
I may be wrong. Specially, if the assertion is singed by the IdP, that 
would be impossible at it would invalidate the signature.

Anyway, other alternatives to deliver large authorization data, like 
providing a URL where the RP can download the assertion later, have 
exactly the same issue: proxies cannot modify the contents of the assertion.

Regards,
Alejandro

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 9 Mar 2012 09:26:01 -0800

> Sent: Friday, March 09, 2012 3:56 AM
> To: Jim Schaad
> Cc: 'Alan DeKok'; [email-masked]; [email-masked]
> El 09/03/12 05:55, Jim Schaad escribi :
> >
> >> Subject: Re: [abfab] FYI: New Version Notification for
> >> draft-perez-radext- radius-fragmentation-01.txt
> >>
> >>
> >>
> >> El 04/03/12 08:10, Alan DeKok escribi :
> >>> Jim Schaad wrote:
> >> next to nothing about RADIX having only briefly read it a couple of
> >> times and having not yet worked with it to any extent.
> >> message full in the presence of proxy intermediaries which might need
> >> room for adding and removing routing materials.  I don't know how
> >> many proxies are keep local state as oppose to just filling up the
> >> message with Proxy-State items and thus need space on the way back.
> >> Also a discussion of removal and re-insertion of the T flag might be
> >> needed if the proxy fully assembles the message and then relays it in
> pieces.
> >> Additionally, regarding the T flag removal/re-insertion comment,
> >> proxies are not allowed to perform RADIUS fragmentation on forwarded
> >> packets. It is a process performed end-to-end the RADIUS client and
> server.
> >>
> > What happens for proxies that, for some reason - want to re-write the
> contents of packets.  For ABFAB I am specifically thinking of changing or
> mapping attributes in SAML assertions.
> 
> I don't think a RADIUS proxy should change anything at a SAML level, but I
> may be wrong. Specially, if the assertion is singed by the IdP, that would be
> impossible at it would invalidate the signature.

If you look at draft-ietf-abfab-aaa-saml - this is exactly the case that is imagined.  The attributes need to be re-written as they change domains.  The signature is assumed to be checked by the IdP system and RADIUS is then responsible for keeping the integrity in transit.  There is no reason to suppose that the relying party is going to know who the signer of the SAML statement would be and therefore would not be able to establish the trust without the AAA infrastructure.

Jim

> 
> Anyway, other alternatives to deliver large authorization data, like providing
> a URL where the RP can download the assertion later, have exactly the same
> issue: proxies cannot modify the contents of the assertion.
> 
> Regards,
> Alejandro
> 
> >
> >> state items might also added to the message.  This changes the limit
> >> of how many bytes can be placed into the fragmented packets.
> >>>     Yes.
> >>>
> >> I think a better word set might be partitioned and partitioning.
> >> Also ensure that fragmentation is used strictly for the process in
> >> radius-extensions.  I have not found any cases yet were it is not but
> >> will try and remember to look.
> >> significant.  The introduction says it comes last but nothing to that
> >> effect is said in section 3.
> >> order would need to be changed in the original partitioning.  This
> >> should be mentioned someplace other than just in the "examples"
> >> section.  It implies that a general use piece of code to do this will
> >> need to have the table built in, and potentially extended as new
> >> items are added, rather than just being coded correctly in the specific
> packet type code.
> >> deal with the partitioned message other than it will either fail or
> >> get confused depending on what set of attributes are in the first
> >> packet and what it needs and feels it can ignore.
> >>>     That's an open area for discussion.  RADIUS doesn't have
> >>> capability negotiation, so it's hard to do.
> >>>
> >>>     Alan DeKok.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Sat, 10 Mar 2012 19:25:34 +0100

> If you look at draft-ietf-abfab-aaa-saml - this is exactly the case that is imagined.  The attributes need to be re-written as they change domains.

I don't see any part of the draft where it is stated the attributes 
*need* to be re-written. Indeed, it says nothing about proxies (or I 
couldn't find it). Nevertheless, some parts of draft-ietf-abfab-aaa-saml 
need to be modified as the fragmentation draft moves forward.

> The signature is assumed to be checked by the IdP system and RADIUS is then responsible for keeping the integrity in transit.  There is no reason to suppose that the relying party is going to know who the signer of the SAML statement would be and therefore would not be able to establish the trust without the AAA infrastructure.

Although as you say, trust can be leveraged on the AAA infrastructure, 
and the use of signatures can be avoided (using a single trust model), 
IMO nothing should preclude using them if desired by the parties. If 
intermediate proxies modify assertions, this would be impossible.

Regards,
Alejandro

---

From: Josh Howlett <[email-masked]>
Date: Sat, 10 Mar 2012 19:55:00 +0000

On 10/03/2012 18:25, "Alejandro Perez Mendez" <[email-masked]> wrote:

>> If you look at draft-ietf-abfab-aaa-saml - this is exactly the case
>>that is imagined.  The attributes need to be re-written as they change
>>domains.
>
>*need* to be re-written.

Yes, the draft is silent in this respect. This is a deployment question.

>Indeed, it says nothing about proxies (or I
>couldn't find it).

It doesn't (nor should it).

> Nevertheless, some parts of draft-ietf-abfab-aaa-saml

I'll be doing that on Monday :-/

Josh.

Janet is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG

---

From: Sam Hartman <[email-masked]>
Date: Sun, 11 Mar 2012 14:50:24 -0400

I do think we want to deal with a case where it's a proxy rather than
the home AAA server adding an assertion.
The case of a proxy modifying an assertion can be simplified to a proxy
choosing to read an assertion and then isse a new assertion based in
input from the data.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Sun, 11 Mar 2012 21:16:52 +0100

> the home AAA server adding an assertion.

Assuming the original packet has not fragmentation, I think this case is 
straightforward.

> choosing to read an assertion and then isse a new assertion based in

The problem with this case is that the intermediate proxy will need to 
perform a conversation with the RADIUS client (i.e. sending 
Acess-Challenge packets) to obtain all the fragments of the packet. 
Then, the proxy have to reconstruct the assertion, modify it and then 
start a new conversation with the RADIUS server sending the new fragments.

I think it is possible, but that may be a lot of state to hold for a proxy.

Anyway, what's the idea behind having a proxy modifying an assertion? 
Wouldn't be the assertion losing its meaning as the originator of the 
assertion (i.e. the IdP) has no control over the asserted information 
along the path? IMO, one thing is assuming integrity is assured by the 
trust on the AAA infrastructure and thus, digital signature is not 
required, and another is abusing of that fact by introducing 
intermediary elements that can modify the asserted data out of the 
control of the IdP.

Regards,
Alejandro

---

From: Sam Hartman <[email-masked]>
Date: Sun, 11 Mar 2012 16:55:20 -0400

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

    Alejandro> The problem with this case is that the intermediate proxy
    Alejandro> will need to perform a conversation with the RADIUS
    Alejandro> client (i.e. sending Acess-Challenge packets) to obtain
    Alejandro> all the fragments of the packet. Then, the proxy have to
    Alejandro> reconstruct the assertion, modify it and then start a new
    Alejandro> conversation with the RADIUS server sending the new
    Alejandro> fragments.

    Alejandro> I think it is possible, but that may be a lot of state to
    Alejandro> hold for a proxy.

I'm confused because I thought the proxy would end up having to first
have a conversation with the RADIUS server.
Do you have server and client reversed?
If not, would you help me better understand what's going on?

Is the proxy's state required any more than the state a server needs to
retain for its outstanding fragmented requests?

--Sam

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Mon, 12 Mar 2012 00:10:41 +0100

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

My mistake, sorry. I was initially thinking on a client-initiated 
conversation (e.g. SAML Authn Request). It would be as you say.

> retain for its outstanding fragmented requests?

No, it should be the same. But it would be more than usually required 
for a proxy (they usually receive, send and forget). Anyway, I'm not 
sure that is actually a big issue. I was just asking if it was.

Regards,
Alejandro

---

From: Sam Hartman <[email-masked]>
Date: Mon, 12 Mar 2012 08:00:25 -0400

>> Is the proxy's state required any more than the state a server
    >> needs to retain for its outstanding fragmented requests?

    Alejandro> No, it should be the same. But it would be more than
    Alejandro> usually required for a proxy (they usually receive, send
    Alejandro> and forget). Anyway, I'm not sure that is actually a big
    Alejandro> issue. I was just asking if it was.

I'm greatful that you're trying to explore this issue because I think it
gets at the core of Jim's question. 
I don't know if the state required is too much. Here are my thoughts:

1) It makes rewriting SAML requests significantly more effort than
rewriting RADIUS attributes.  That said, there are a number of ways
(needing a SAML library, possibly needing to resign or strip signatures)
where a SAML rewrite is harder for a RADIUS server than a RADIUS
rewrite.
However this increases state not just adding new libraries.

2) It wouldn't surprise me if proxies near an RP handled similar volumes
of requests as home servers or proxies near an IDP.

3) In a proxy fabric deployment it wouldn't surprise me if proxies in
the middle of a federation handle significantly more volume than proxies
near the edges.

4) In the Moonshot deployment we're hoping to avoid proxy fabric and use
trust router, so we're hoping that any proxy-like entities in the middle
will not see individual requests. I think implicit in that is an
assumption that attributes of individual requests will not need to be
rewritten in the middle.

5) The effort required for this sort of rewrite is very similar to the
effort required to map from SAML and other authorization languages to
Kerberos in the gss-preauth/eap-preauth cases on the RP's KDC.

In conclusion, I'd be happy if we had more data on use cases and
performance requirements for proxy rewriting.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Mon, 12 Mar 2012 16:46:36 +0100

> assumption that attributes of individual requests will not need to be
That's exactly my point. The more important question is: do we really 
need SAML rewrite at AAA proxies? I don't see the point, specially if 
that can happen in any point of the path.

Regards,
Alejandro

---

From: Sam Hartman <[email-masked]>
Date: Mon, 12 Mar 2012 11:55:37 -0400

Well, I think you may well need SAML rewrite at AAA proxies if you don't
have something like Kerberos.

Attribute remapping at organizational boundaries seems like something
people will want.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Mon, 12 Mar 2012 17:07:25 +0100

> Attribute remapping at organizational boundaries seems like something

But that does not happen at the intermediary AAA proxies, as they are 
not interested on the information being transmitted. It should happend 
at both ends of the communication, or at a close point. And likely it 
will happend once at much for each assertion. Am I wrong?

Regards,
Alejandro

---

From: Sam Hartman <[email-masked]>
Date: Mon, 12 Mar 2012 12:42:45 -0400

>> Well, I think you may well need SAML rewrite at AAA proxies if
    >> you don't have something like Kerberos.
    >> 
    >> Attribute remapping at organizational boundaries seems like
    >> something people will want.

    Alejandro> But that does not happen at the intermediary AAA proxies,
    Alejandro> as they are not interested on the information being
    Alejandro> transmitted. It should happend at both ends of the
    Alejandro> communication, or at a close point. And likely it will
    Alejandro> happend once at much for each assertion. Am I wrong?

Right.
I don't think that core proxies need to be involved in rewrite.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 12 Mar 2012 16:28:08 -0700

Remapping of attributes is something that Plasma is going to want.  

I don't know that this is restricted to just on at either end.  I think that it may possibly happen any time you cross any type of federation boundary.  How attributes are portrayed and represented and if they have any significance is going to depend on the federation agreement.  I think that on will generally be uninterested in the proxies that occur inside of a federation.  

When looking at what Moonshot is doing, I think that the trust router will skip right to the cross-boundary federation proxies that will need to potentially do the re-writing and thus it is an issue for all such proxy agents.

Also I think that the re-writes will be done in both directions.  If you do a query from the RP to the IdP, then the attributes you are asking for change as you cross the federation boundaries.  And the response of the query needs to be modified as it comes back so that the RP can understand what is happening.  While it would be ideal if this only happens at the end points, I fully expect in any type of complex federation it would happen in the middle as well.

Jim

> Sent: Monday, March 12, 2012 9:07 AM
> To: Sam Hartman
> Cc: Josh Howlett; Jim Schaad; [email-masked]
> > Well, I think you may well need SAML rewrite at AAA proxies if you
> > don't have something like Kerberos.
> >
> But that does not happen at the intermediary AAA proxies, as they are not
> interested on the information being transmitted. It should happend at both
> ends of the communication, or at a close point. And likely it will happend
> once at much for each assertion. Am I wrong?
> 
> Regards,
> Alejandro

---

From: Sam Hartman <[email-masked]>
Date: Mon, 12 Mar 2012 19:46:12 -0400

>>>>> "Jim" == Jim Schaad <[email-masked]> writes:

OK.  So, I think we need to figure out what the performance
characteristics are and whether your proxies can afford to hold the sort
of state we're talking about.

In the trust router model you definitely can skip to boundary proxies
that "need" to be men-in-the-middle.

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 14 Mar 2012 20:20:31 -0700

Alan,

Do you have any data which we could start getting some data about how
proxies are currently used.

1.  How many places are there were we see transitions from Diameter to
RADIUS or vice versa?  These would be places where we already have a
situation where messages might need to be fragmented because of the
different sizes of packets.

2.  Are you aware of any places where information needs to be translated as
they go past proxies in the manner we are talking about where things cross
federation boundaries and the data needs to be either validated or modified
to fit how the federation thinks about the data?

3.  How much routing data is placed into packets today in semi-complex
arrangements by proxies?  How many of them cache the data locally for the
return trip rather than just append data to the message?

Jim

> From: Sam Hartman [mailto:[email-masked]]
> Sent: Monday, March 12, 2012 4:46 PM
> To: Jim Schaad
> Cc: 'Alejandro Perez Mendez'; 'Josh Howlett'; [email-masked]
characteristics
> are and whether your proxies can afford to hold the sort of state we're
> talking about.
> 
> In the trust router model you definitely can skip to boundary proxies that
> "need" to be men-in-the-middle.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 15 Mar 2012 07:56:49 -0400

> proxies are currently used.

  I have opinions, but getting *public* data is difficult.

> different sizes of packets.

  I don't see many RADIUS to Diameter gateways.

> to fit how the federation thinks about the data?

  Yes.  Many roaming providers go through integrators.  Those
integrators take care of mangling packets back & forth.  This is one of
the value-adds of the integrator.  They present a uniform RADIUS
framework to the home servers, by normalizing the weird things produced
by each roaming / WiFi operator.

> return trip rather than just append data to the message?

  There is no routing data in packets.  I'm not sure what your question
even means.

  RADIUS is a request/response protocol.  A proxy simply ties together a
request/response on the incoming side to a request/response on the
outgoing side.  It keeps track of the relationship in its internal
memory.  This information doesn't go into packets.

  There *is* a Proxy-State attribute in RADIUS.  But it's pretty much
useless.  It can be used to detect routing loops (100 Proxy-State is
bad).  I know all of the RADIUS servers I've worked with since 1997
don't do anything with it.

  Alan DeKok.

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 15 Mar 2012 09:16:46 -0700

Alan, Thanks for the response

> From: Alan DeKok [mailto:[email-masked]]
> Sent: Thursday, March 15, 2012 4:57 AM
> To: Jim Schaad
> Cc: 'Sam Hartman'; 'Alejandro Perez Mendez'; 'Josh Howlett';
[email-masked]
> > 2.  Are you aware of any places where information needs to be
> > translated as they go past proxies in the manner we are talking about
> > where things cross federation boundaries and the data needs to be
> > either validated or modified to fit how the federation thinks about the
> data?
> 
>   Yes.  Many roaming providers go through integrators.  Those integrators
> take care of mangling packets back & forth.  This is one of the value-adds
of
> the integrator.  They present a uniform RADIUS framework to the home
> servers, by normalizing the weird things produced by each roaming / WiFi
> operator.

Do these integrators end up with lots of local state for each set of packets
going back and forth?  Do they end up carrying state between packets?

Would it be unreasonable or unnecessary for them to do the packet
re-assembly and then re-send that would be required by the fragmentation
draft?

> > arrangements by proxies?  How many of them cache the data locally for
> > the return trip rather than just append data to the message?
> 
even
> means.
> outgoing side.  It keeps track of the relationship in its internal memory.
This
> information doesn't go into packets.
> 
useless.
> It can be used to detect routing loops (100 Proxy-State is bad).  I know
all of
> the RADIUS servers I've worked with since 1997 don't do anything with it.
> 

My mistake - I assumed that the in memory state that was being cached was
being cached into the Proxy-State attribute rather than being stored on the
proxy itself.  This would allow for a "state-less" proxy to be created.  

Jim

---

From: Alan DeKok <[email-masked]>
Date: Thu, 15 Mar 2012 15:33:22 -0400

> going back and forth?  Do they end up carrying state between packets?

  The only state is (a) per packet for proxying, and (b) per session for
accounting.

  The session state enables the same rewriting to be done for each
accounting packet.

> re-assembly and then re-send that would be required by the fragmentation

  I don't think re-assembly is required by the fragmentation draft.  I
would strongly avoid requiring such reassembly.  Implementing it could
require major changes to the proxies.

  The re-writing done by current proxies is fairly minimal.  So it
should have minimal effect on the fragments as suggested by the draft.

> proxy itself.  This would allow for a "state-less" proxy to be created.  

  That isn't done, and likely wouldn't work.  There's a history of
RADIUS proxies mangling Proxy-State, for no good reason.  As a result,
most modern implementations don't depend on it.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 15 Mar 2012 16:04:41 -0400

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

    Alan>   I don't think re-assembly is required by the fragmentation
    Alan> draft.  I would strongly avoid requiring such reassembly.
    Alan> Implementing it could require major changes to the proxies.

    Alan>   The re-writing done by current proxies is fairly minimal.
    Alan> So it should have minimal effect on the fragments as suggested
    Alan> by the draft.

so, I think you may be missing what Jim is asking about.  Jim is talking
about a proxy that wants to radically change the SAML assertion being
carried.  We think the only way to do that is for the proxy to act as a
client, grab the entire SAML assertion using the fragmentation protocol,
then originate an assertion of its own that it fragments and passes
along.

--Sam

---

From: Alan DeKok <[email-masked]>
Date: Thu, 15 Mar 2012 16:31:25 -0400

> then originate an assertion of its own that it fragments and passes

  Yeah... It's possible, but I'm scared of that.

  It involves changing the design assumptions of many servers.  Proxying
would no longer be an event / packet-driven mechanism.  Instead, the
inputs and outputs would be largely decoupled.

  It could also greatly latencies in the network.  What happens when you
have 2-3 layers of proxies, and each wants to change the SAML
assertions?  Instead of one client-server latency, you'd have 3 times
that, due to the sequential nature of the proxying.

  My take is that proxies which do re-writes SHOULD pro-actively request
the authorization data.  This would mean watching the Access-Accept for
a "more authorization" flag, and the immediately requesting the
authorization data.  That data would be cached locally.

  When the client requests the authorization data, any response would be
delayed until all of the data was available.  Then, the re-write would
occur, and the response sent.

  This design simplifies the proxy implementation.  Instead of having to
juggle multiple packets, it just sends back a cached response.  Since
servers already send back canned responses, we know that the design works.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 15 Mar 2012 16:42:47 -0400

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

    Alan>   My take is that proxies which do re-writes SHOULD
    Alan> pro-actively request the authorization data.  This would mean
    Alan> watching the Access-Accept for a "more authorization" flag,
    Alan> and the immediately requesting the authorization data.  That
    Alan> data would be cached locally.

    Alan>   When the client requests the authorization data, any
    Alan> response would be delayed until all of the data was available.
    Alan> Then, the re-write would occur, and the response sent.

    Alan>   This design simplifies the proxy implementation.  Instead of
    Alan> having to juggle multiple packets, it just sends back a cached
    Alan> response.  Since servers already send back canned responses,
    Alan> we know that the design works.

That certainly sounds like an improvement.
Assuming someone were looking at that design for rewriting SAML
assertions, how scared would you be?

---

From: Alan DeKok <[email-masked]>
Date: Thu, 15 Mar 2012 16:49:37 -0400

> assertions, how scared would you be?

  A lot less.  It's a lot more manageable.

  Alan DeKok.

---

From: Gabriel López <[email-masked]>
Date: Fri, 16 Mar 2012 08:30:29 +0100

I agree with Alan,

I would like to know a representative use case where SAML assertions
have to be rewritten by intermediate proxys
It is not only a problem of delay, and deployment complexity. It a
problem of semantic about SAML assertion. The question is: What kind of
attributes will be placed in the assertion that need to be rewriteen? As
far I know SAML assertion should carry on information about the end user
(information about the network should be transported in RADIUS
attributes) so I don't see what is the purpose of rewriting that.

Best regards, Gabi.

El 15/03/12 21:31, Alan DeKok escribió:
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

-- 
----------------------------------------------------------------
Gabriel Lpez Milln
Departamento de Ingeniera de la Informacin y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: [email-masked]

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Fri, 16 Mar 2012 13:38:12 +0100

> servers already send back canned responses, we know that the design works.

I do not see how this simplifies the flow. The number of messages are 
exactly the same, and there seem to not be much difference on the amount 
of state to be hold either. As I understand, the only difference is the 
pro-active nature of the request by the proxy.

What's the difference of doing that pro-actively or just waiting until 
the Access-Request from the client requesting the authorization data 
passed through the proxy?

Regards,
Alejandro

---

From: Alan DeKok <[email-masked]>
Date: Fri, 16 Mar 2012 08:48:56 -0400

> pro-active nature of the request by the proxy.

  The issue is that the proxy needs to have ALL of the SAML data before
it can rewrite ANY of it.  Since the SAML data is spread over multiple
packets, the current near-stateless approach won't work.

  i.e. current proxies apply the same rewrite rules to every packet.
They don't change packet N+1 of a stream based on data seen in packet N.

> passed through the proxy?

  Latency.  When a client sends the first "get more data" packet, the
proxy CANNOT respond until it has ALL of the SAML data from the home
server.  This may take a large number of round trips.  During those
round trips, the client is waiting for a response to ONE packet.  The
client will think that the proxy is unresponsive, or just very slow.

  Also, current proxy implementations are largely event-driven.  They
receive a packet from a client, proxy it, receive the response, and send
that to the client.  Changing the implementation is hard.  Changing it
so that the event loop becomes "receive one packet, send many many
packets" can be challenging.

  An explicitly decoupled approach can be simpler.  I wouldn't say it's
a requirement.  I would say it would be my preferred implementation.

  Alan DeKok.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Fri, 16 Mar 2012 14:01:45 +0100

> They don't change packet N+1 of a stream based on data seen in packet N.

Sure, I got that part :)

> client will think that the proxy is unresponsive, or just very slow.

So, basically we are saving some time, so when the client requests the 
data, the proxy may already have been received some fragments (may be 
not all) from the server. This reduces latency, but depending on the 
number of fragments, the client may need to wait anyway and think the 
proxy is unresponsive.

> packets" can be challenging.

Yes, but that should be done pro-actively or re-actively, either way. 
The only difference is what is triggering the several roundtrip exchange 
to retrive the data. In the pro-active mode is the presence of the 
Authorize-Only service type, indicating that *probably* the client will 
request for authorization data. In the re-active mode, the trigger is 
the actual Access-Request from the client requesting the data. Am I wrong?

> a requirement.  I would say it would be my preferred implementation.

That's something I don't really know, as I never implemented a RADIUS 
server. If you say so, I'm completely confident :)

Regards,
Alejandro