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

From: <[email-masked]>
Date: Sun, 3 Feb 2013 16:33:12 +0000

Hi Alejandro,

In order to maintain deal with RADIUS clients and servers that do not support fragmentation, it would be cleaner to use RADIUS capability negotiations (draft-halwasia-radext-capability-negotiation) to negotiate use of More-Data-Pending attribute.  This would
allow all RADIUS messages to use More-Data-Pending attribute for fragmentation with no exception.

Yoshihiro Ohba

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alejandro Perez Mendez
Sent: Wednesday, January 30, 2013 5:46 PM
To: [email-masked]
Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.txt

Hello Yoshi, Rafa,

see some comments inline:

Dear all,

we have received additional comments from Yoshihiro Ohba (many thanks) that we share with you.

Please, see some comments inline.

"Here is my review of draft-perez-radext-radius-fragmentation-04.

Section 1:

"Each RADIUS packet can transport several RADIUS attributes, to convey

the necessary information to the other peer, up to a maximum size of 4

KB of total data (including RADIUS packet headers)."

[YO] I suggest to replace "4 KB" with "4096 bytes" throughout the

document since "KB" can mean 4000 bytes in some cases.

[Rafa] OK.

"A reference-based mechanism is also proposed in [RFC6158], where

attributes can be obtained through an out-of-band protocol."

[YO} Meaning of this sentence is unclear. Does this mean RADIUS

attributes are obtained through some other protocol instead of RADIUS?

Or does this mean the actual format of the Value field of a RADIUS

Attribute is defined in other protocol specification? In the latter

case, it should be also mentioned that RADIUS-EAP is categorized as the

mechanism defined in RFC 6158.

[Rafa] It is referring the value of the attributes can be obtained by other protocol instead of RADIUS. This is coming from a previous comment related with SAML transport. Instead of transporting the real SAML messages an URL is set as attribute value. We can try to clarify a little bit more.

"However, there are no proposals to deal with fragmentation at a packet

level, when the total size exceeds the 4 KB limit imposed by the RADIUS

specification."

[YO] Meaning of "at a packet level" is unclear. Suggested change:

"However, there are no proposals to fragement a large-sized RADIUS

packet into multiple small-sized RADIUS packets, where the length of the

original (unfragmented) RADIUS packet exceeds the 4096-octet limit

imposed by the RADIUS specification."

[Rafa] This sounds good.

Section 2:

[YO] I am not sure if "T" flag is needed. In other words, it should be

possible to change [I-D.ietf-radext-radius-extensions] to simply allow a

fragment with the M-flag cleared not to be included in a non-last chunk.

[Rafa]

Yes, that may be possible. It is worth noting that we wanted to keep unmodified any existing I-D by the time being. Moreover, [I-D.ietf-radext-radius-extensions] has not considered that fragmentation at packet level may occur for obvious reasons. Moreover, that I-D is in a mature state now.

In any case, we may ask authors of [I-D.ietf-radext-radius-extensions].

Section 3.3:

[YO] Access-Accept fragmentation scheme looks odd compared to

Access-Request and Access-Challenge fragmentation schemes. There are

several questions related to this: (1) Why multiple chunks of

Access-Accept cannot be sent without having an Access-Challange to be

sent in between? (2) Why an Access-Accept cannot contain a

More-Data-Pending attribute instead of using a new service type value?

(3) How can a large attributue that is allowed to appear in an

Access-Accept but not allowed to appear in Access-Challenge be fragmented?

[Rafa]

1) We wanted to be symmetric in the design, where Access-Request/Access-Challenge exchange is used somehow for fragmentation support. In any case, we have also considered the usage of Access-Accept with Service-Type[AddAuth] so until all the attributes in the whole RADIUS Access-Accept are finally sent the exchange will be Access-Request/Access-Accept (Service-Type[AddAuth]), while the last one is simply Access-Request/Access-Accept. This mode of operation would solve your question 3).

2) I think that may be also possible. In any case, I think Alan or Alex can elaborate a little bit a more about the usage of Service-Type[AddAuth].

3) Precisely, trying to answer this question we just came up with the solution in 1). What do you think?

This alternative sounds good to me. However, I think there may be still some advantages of using Service-Type instead of (or in addition to) More-Data-Pending for Access-Accept packets.

If the NAS/RP does not know anything about fragmentation (i.e. does not support this draft), it may take the first Access-Accept chunk, ignore the More-Data-Pending attribute (it is unknown for it), and process it as a complete packet. As no additional round-trip is mandatory after an Access-Accept packet, it may be problematic as it is possible that part of the obligations from the AS to the NAS (e.g. FW policies) are not enforced.

However, RFC 2865 says that (in relation to Access-Accept packets):

A NAS is not

      required to implement all of these service types, and MUST treat

      unknown or unsupported Service-Types as though an Access-Reject

      had been received instead

Therefore, if the NAS does not understand Service-Type=AdditionalAuthorization, the Access-Accept packet will be interpreted as an Access-Reject one, which seems to be the most reasonable approach.

This sort of problems seem to not be critical with Access-Challenge packets, as the NAS is expected to generate a new Access-Request packet afterwards, and the AS can detect whether fragmentation was supported.

Regards,
Alejandro

Section 8:

[YO] Security Considerations section is too short. Security mechansims

that are needed for secure operation of the proposed fragmentation

mechanism needs to be described in this section.

[Rafa] Yes this section will be improved. Jim also raised comments about it.

Section 9:

[YO] I don't think the following statement is true: "This document has

no actions for IANA." because Section 6 defines new attributes.

[Rafa] Correct. This needs to be fixed.

Best Regards,

Yoshihiro Ohba

"

Best regards.

-------------------------------------------------------

Rafael Marin Lopez, PhD

Dept. Information and Communications Engineering (DIIC)

Faculty of Computer Science-University of Murcia

30100 Murcia - Spain

Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]<mailto:[email-masked]>

-------------------------------------------------------

_______________________________________________

radext mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/radext

---

From: Sam Hartman <[email-masked]>
Date: Sun, 03 Feb 2013 11:47:48 -0500

>>>>>   <[email-masked]> writes:

    > Hi Alejandro, In order to maintain deal with RADIUS clients and
    > servers that do not support fragmentation, it would be cleaner to
    > use RADIUS capability negotiations
    > (draft-halwasia-radext-capability-negotiation) to negotiate use of
    > More-Data-Pending attribute.  This would

How widely implemented in that?

---

From: Alan DeKok <[email-masked]>
Date: Sun, 03 Feb 2013 11:51:30 -0500

> How widely implemented in that?

  Not at all.

  It's still in the preliminary discussion phase.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sun, 03 Feb 2013 12:02:18 -0500

[email-masked] wrote:
> In order to maintain deal with RADIUS clients and servers that do not
> support fragmentation, it would be cleaner to use RADIUS capability
> negotiations (draft-halwasia-radext-capability-negotiation) to negotiate
> use of More-Data-Pending attribute.  This would

  The existence of a More-Data-Pending in an Access-Request indicates
that the client supports fragmentation.  Servers which do not understand
that attribute will return an Access-Accept / Reject instead of an
Access-Challenge.  The client will realize that it has not sent all of
the data it wants to send, and will terminate the users session.

  A server supporting fragmentation will start off by sending an
Access-Accept with Service-Type = Additional-Authorization.  Clients not
supporting fragmentation will not recognize the Service-Type, and under
RFC 2865 Section 5.6, treat it as Access-Reject.

  There is no need for capability negotiation here.  If a client needs
to send a lot of data, it either sends all of the data, or terminates
the users session.  If a server needs to send a lot of data, it either
sends all of the data, or sends a Service-Type which causes the client
to terminate the users session.

  It would be *nice* to know this prior to terminating the session.
Simply rejecting the user unexpectedly is safe, but unfriendly.

  Any capability negotiation here is a user interface problem.  It helps
the user or administrator understand why a session was terminated.  It
doesn't help the RADIUS client or server.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Sun, 03 Feb 2013 13:04:25 -0500

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

    >> How widely implemented in that?

    Alan>   Not at all.

    Alan>   It's still in the preliminary discussion phase.

OK.
Because of the abfab dependency I'd strongly prefer that whatever we do
for radius fragmentation depend on drafts that have at least reached the
wglc stage. So, for example the dependency on radius-extensions doesn't
bother me at all, but a dependency on another draft that has neither
wide implementation nor has been adopted  would concern me
significantly.

I also agree with Alan's comments about why negotiation is not a strict
requirement.

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 3 Feb 2013 10:46:36 -0800

This behavior should probably  be in the document.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Alan DeKok
> Sent: Sunday, February 03, 2013 9:02 AM
> To: [email-masked]
> Cc: [email-masked]
> > negotiations (draft-halwasia-radext-capability-negotiation) to
> > negotiate use of More-Data-Pending attribute.  This would allow all
> > RADIUS messages to use More-Data-Pending attribute for fragmentation
> > with no exception.
> 
>   The existence of a More-Data-Pending in an Access-Request indicates that
> the client supports fragmentation.  Servers which do not understand that
> attribute will return an Access-Accept / Reject instead of an Access-
> Challenge.  The client will realize that it has not sent all of the data
it wants to
> send, and will terminate the users session.
> 
Access-Accept
> with Service-Type = Additional-Authorization.  Clients not supporting
> fragmentation will not recognize the Service-Type, and under RFC 2865
> Section 5.6, treat it as Access-Reject.
> 
>   There is no need for capability negotiation here.  If a client needs to
send a
> lot of data, it either sends all of the data, or terminates the users
session.  If a
> server needs to send a lot of data, it either sends all of the data, or
sends a
> Service-Type which causes the client to terminate the users session.
> 
the user
> or administrator understand why a session was terminated.  It doesn't help
> the RADIUS client or server.
> 
>   Alan DeKok.
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Mon, 04 Feb 2013 09:12:03 +0100

El 03/02/13 17:33, [email-masked] escribió:
> negotiate use of More-Data-Pending attribute.  This would
>

That would be an option. But I would rather do not depend on other 
drafts, specially not WG draft. We may need some capability negotiation 
within the fragmentation mechanisms.

Regards,
Alejandro

> Yoshihiro Ohba
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Alejandro Perez Mendez
> *Sent:* Wednesday, January 30, 2013 5:46 PM
> *To:* [email-masked]
> *Subject:* Re: [abfab] [radext] New Version Notification for 
> draft-perez-radext-radius-fragmentation-04.txt
>
> Hello Yoshi, Rafa,
>
> This alternative sounds good to me. However, I think there may be 
> still some advantages of using Service-Type instead of (or in addition 
> to) More-Data-Pending for Access-Accept packets.
>
> If the NAS/RP does not know anything about fragmentation (i.e. does 
> not support this draft), it may take the first Access-Accept chunk, 
> ignore the More-Data-Pending attribute (it is unknown for it), and 
> process it as a complete packet. As no additional round-trip is 
> mandatory after an Access-Accept packet, it may be problematic as it 
> is possible that part of the obligations from the AS to the NAS (e.g. 
> FW policies) are not enforced.
>
> Therefore, if the NAS does not understand 
> Service-Type=AdditionalAuthorization, the Access-Accept packet will be 
> interpreted as an Access-Reject one, which seems to be the most 
> reasonable approach.
>
> This sort of problems seem to not be critical with Access-Challenge 
> packets, as the NAS is expected to generate a new Access-Request 
> packet afterwards, and the AS can detect whether fragmentation was 
> supported.
>
> Regards,
> Alejandro
>
>
> Section 8:
>   
> Telf: +34868888501 Fax: +34868884151 e-mail:[email-masked]  <mailto:[email-masked]>
> [email-masked]  <mailto:[email-masked]>

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Mon, 04 Feb 2013 09:19:30 +0100

El 03/02/13 18:02, Alan DeKok escribió:
> Access-Challenge.

Why? I assumed they will ignore the MDP attribute, and generate a 
Challenge if they understand the chunk as a valid Access-Request.

 From RFC 2865

    A RADIUS server MAY ignore Attributes with an unknown Type.

> The client will realize that it has not sent all of
> Access-Accept with Service-Type = Additional-Authorization.

What if the server wants to send a fragmented Challenge *before* sending 
the Access-Accept? Then, it will send the More-Data-Pending attribute, 
not the Service-Type = AddAuth. Again, the client may ignore the unknown 
attribute and try to decode the chunk as a "regular" Access-Challenge.

> Clients not

That's true for Access-Accept, not for Access-Challenge packets.

> Simply rejecting the user unexpectedly is safe, but unfriendly.

I agree with this.

> doesn't help the RADIUS client or server.
And also agree with this.

---

From: <[email-masked]>
Date: Mon, 4 Feb 2013 12:01:08 +0000

I suggest to investigate all corner cases before making a decision on a particular mechanism.  The corner cases are:

(a)    Client supports fragmentation and server does not support fragmentation
(a-1) Access-Request is fragmented
(a-2) Access-Challenge is fragmented
(a-3) Access-Accept is fragmented

(b)   Client does not support fragmentation and server supports fragmentation

(b-1) Access-Request is fragmented

(b-2) Access-Challenge is fragmented

(b-3) Access-Accept is fragmented

Yoshihiro Ohba

From: Alejandro Perez Mendez [mailto:[email-masked]]
Sent: Monday, February 04, 2013 5:12 PM
To: ohba yoshihiro(大場 義洋 ○ＲＤＣ□ＮＳＬ)
Cc: [email-masked]
Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.txt

El 03/02/13 17:33, [email-masked]<mailto:[email-masked]> escribió:
Hi Alejandro,

That would be an option. But I would rather do not depend on other drafts, specially not WG draft. We may need some capability negotiation within the fragmentation mechanisms.

Regards,
Alejandro

Yoshihiro Ohba

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Alejandro Perez Mendez
Sent: Wednesday, January 30, 2013 5:46 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.txt

Hello Yoshi, Rafa,

Dear all,

Section 1:

[Rafa] OK.

specification."

[Rafa] This sounds good.

Section 2:

[Rafa]

Section 3.3:

[Rafa]

A NAS is not

Regards,
Alejandro

Section 8:

Section 9:

Best Regards,

Yoshihiro Ohba

"

Best regards.

Rafael Marin Lopez, PhD

30100 Murcia - Spain

radext mailing list

---

From: Sam Hartman <[email-masked]>
Date: Mon, 04 Feb 2013 07:06:43 -0500

> I suggest to investigate all corner cases before making a decision
    > on a particular mechanism.  The corner cases are:

Sounds reasonable.

    > (b) Client does not support fragmentation and server supports
In case b-1 (access-request fragmentation)

I'm confused. How is the access-request fragmented if a client doesn't
support fragmentation?

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Mon, 04 Feb 2013 13:33:57 +0100

El 04/02/13 13:01, [email-masked] escribió:
>
> I suggest to investigate all corner cases before making a decision on 
> a particular mechanism.  The corner cases are:
>
> (a)Client supports fragmentation and server does not support fragmentation
>

Client includes More-Data-Pending attribute. As the Server does not 
understand it, the Server ignores the attribute and tries to reply to 
the Access-Request if it makes sense to it. If the reply is an 
Access-Accept/Access-Reject, the client will notice right away. However, 
if the reply is an Access-Challenge packet, they client may have 
problems distinguishing it from an Access-Challenge packet that request 
more fragments. Including the More-Data-Pending attribute in the 
Challenge may solve this situation, serving as acknowledgement of 
fragmentation.

> (a-3) Access-Accept is fragmented

Not possible.

> (b)Client does not support fragmentation and server supports fragmentation
>

Not possible

> (b-2) Access-Challenge is fragmented

Similarly to case a-1, the client may ignore the More-Data-Pending and 
treat the first chunk as a regular Access-Challenge. In that case, the 
client will generate an Access-Request packet with the required 
information (depends on the received Challenge). The server may have 
problems to distinguish this Request from one requesting more data.

> (b-3) Access-Accept is fragmented

This problem is solved by the use of 
Service-Type=Additional-Authorization. If the client does not understand 
this value, the packet is interpreted as an Access-Reject, and the 
client will not make wrong decisions.

Regards,
Alejandro

> Yoshihiro Ohba
>
> *From:*Alejandro Perez Mendez [mailto:[email-masked]]
> *Sent:* Monday, February 04, 2013 5:12 PM
> *To:* ohba yoshihiro(大場義洋○ＲＤＣ□ＮＳＬ)
> *Cc:* [email-masked]
> El 03/02/13 17:33, [email-masked] 
> <mailto:[email-masked]> escribió:
>
>     Hi Alejandro,
>
>     In order to maintain deal with RADIUS clients and servers that do
>     not support fragmentation, it would be cleaner to use RADIUS
>     capability negotiations
> drafts, specially not WG draft. We may need some capability 
> negotiation within the fragmentation mechanisms.
>
> Regards,
> Alejandro
>
>
> Yoshihiro Ohba
>
> *From:[email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] *On Behalf Of *Alejandro Perez Mendez
> *To:* [email-masked] <mailto:[email-masked]>

---

From: Alan DeKok <[email-masked]>
Date: Mon, 04 Feb 2013 07:39:25 -0500

> Challenge if they understand the chunk as a valid Access-Request.

  The server might return a challenge.  But any response from the server
will *not* implement fragmentation.  That's the point.

> the Access-Accept?

  My $0.02 is that it's probably a bad idea.  Changing the semantics of
existing authentication methods is hard.  For example, most 802.1X
implementations assume that the final EAP-Success is in the
Access-Accept.  If it's in an earlier challenge... who knows what will
break.

> Then, it will send the More-Data-Pending attribute,

  Which is likely to contain *no* useful information for the client.  So
the client has an Access-Challenge it didn't expect.  It can do nothing
but reject the user, and close the session.  This is a different error
than "unknown Service-Type Additional-Authorization".

  Having the server send an unknown Service-Type is a known quantity.
It is easy to debug, and easy to check.

  Alan DeKok.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Mon, 04 Feb 2013 13:48:55 +0100

> will *not* implement fragmentation.  That's the point.

That's sure.

> Access-Accept.  If it's in an earlier challenge... who knows what will

I think I didn't explained myself correctly. I'm not suggesting 
modifying existing authentication methods. EAP-Success will still appear 
only in Access-Accept packets. Just imagine the situation where the 
Server wants to include an attribute X in one of the Access-Challenge 
packets, and that by introducing that attribute X, the packet becomes 
too big. That's the case I'm thinking of. Maybe that's an impossible 
situation, I don't know.

Let my give an example. A server wants (for whatever reason) to include 
an attribute X on every packet it sends to the Client. That includes 
every Access-Challenge belonging to a RADIUS-EAP authentication. If this 
attribute X is big enough, the packet will need to be fragmented. This 
is happening before Access-Accept.

Regards,
Alejandro

---

From: Alan DeKok <[email-masked]>
Date: Mon, 04 Feb 2013 07:55:30 -0500

[email-masked] wrote:
> I suggest to investigate all corner cases before making a decision on a
> particular mechanism.  The corner cases are:
>

  This is possible.

> (a-3) Access-Accept is fragmented

  These scenarios are not possible.

  The draft talks about fragmenting *data*.  The various packet types
are transports used to carry data.  Saying that an "Access-Request is
fragmented" is meaningless.  Packets aren't fragmented.

  If a client wants to send large amounts of data to the server, it
needs to use Access-Requests to do so.  It will signal support for
fragmentation, as Alejandro said.  The server will either ack that (via
an attribute in a packet), or will ignore it.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 04 Feb 2013 07:58:44 -0500

> too big. That's the case I'm thinking of. Maybe that's an impossible

  Authorization data from the server needs to wait until after
authentication is complete.  I'm not sure of any use-case for sending
large amounts of non-authentication traffic from the server to the client.

  I would suggest that such a use-case is highly insecure.

  Alan DeKok.

---

From: <[email-masked]>
Date: Mon, 4 Feb 2013 16:42:30 +0000

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Monday, February 04, 2013 9:07 PM
To: ohba yoshihiro
Cc: [email-masked]; [email-masked]
Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.txt

Sounds reasonable.

    > (b) Client does not support fragmentation and server supports In case b-1 (access-request fragmentation)

I'm confused. How is the access-request fragmented if a client doesn't support fragmentation?

[YO] You are right, and people already correctly indicated "Not possible" in some of the cases including b-1.

Yoshihiro  Ohba