RE: comments on draft-lior-radius-redirection-00.txt

[Avi Lior <avi@bridgewatersystems.com>]

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net]
> Sent: Thursday, June 03, 2004 5:59 AM
> To: 'radiusext@ops.ietf.org'; Avi Lior; Adrangi, Farid
> Subject: comments on draft-lior-radius-redirection-00.txt
> 
> 
> 
> Hi Avi, Farid,
> 
> I have read your draft, and found it generally well
> written. The function it describes is useful. As usual, I do
> have some comments:
> 
> Management:
> ===========
> 
> I'm not sure which RADEXT proposed charter workitem
> this falls under. WLAN attributes? Prepaid? None?

Initially this was brought up for WLAN but it is also needed for Prepaid.

> Substantial:
> ============
> 
> > 6. Security Considerations
> > 
> >    TBD
> 
> This type of considerations may have to be revised
> before the IESG approves them ;-) You may want to
> mention at least the following:
> 
> - Basic attribute transport has the same security
>    issues as any attribute transport over RADIUS,
>    refer to the security considerations of the
>    base RFC.
> 
> - Limitations of filtering schemes. For instance, situations
>    where the client and some other node in the
>    internet conspire to hide some traffic under some protocol
>    where its in reality something else.

Understood.  There are probably others.  We are looking for help here.
 
> >    Redirection refers to an action taken by the NAS to redirect the
> >    user's traffic to an alternate location. Redirecting traffic in
> >    mid-session will most probably break some applications. However,
> >    Redirection at the start of a Service will most certainly work.
> 
> I may be missing something here. But I don't understand
> what you mean by "application" in this context. An IP
> application, or some specific AAA configuration? I'm pretty 
> sure some IP applications break even with redirection at the 
> start of the service...

An application could be HTTP HTML for example. SIP is another etc...

Your comment is correct some Applications do break.  The intent is to get a
signal that the user is doing something and react to it.  We are not trying
to maintain the application.

> 
> >    because their account has no more funds. The user's
> Service Provider
> >    instructs the NAS to block all traffic, and redirect any port 80
> >    traffic to the Service Provider's Prepaid Portal. Upon detecting
> > that
> 
> This is probably the only possible model we can have, but
> you should point out the limitations. It works only if this is person 
> and he or she uses the web application. Otherwise, your IP connection 
> mysteriously dies...

Well not necessarily.  It could be another flow other than HTML.  And we can
notify the user using other means.  For example, it we could notify a user
using SMS messaging when we detect that they are doing FTP.
 
> > 3.1.2 Mid-session Redirection
> > 
> >    Redirection of traffic using tunnel mid-session involves
> sending the
> >    tunnel attributes as per RFC2868 [5] to the NAS using
> >    Change-of-Authorization (COA) packet. The operation is
> described in
> >    RFC3576 [8]. Careful attention should be paid to the
> security issues
> >    in RFC3576.
> > 
> >    Note that if the session is already tunneled (eg.
> Mobile-IP) then the
> >    COA packet with a new tunnel specification can be sent
> to the NAS or
> >    alternatively the redirection can occur at the tunnel
> endpoint (the
> >    Home Agent) using any one of these methods.
> 
> It isn't clear to me that mid-session tunnel establisment is
> always possible. For instance, what if we are terminating PPP 
> at the NAS, and then suddenly the home network requests the 
> session to be moved on top of L2TP? I think that would have 
> to imply either (a) context transfer of PPP session to 
> another location (!) or (b) tearing down the PPP session and 
> renegging and authenticating everything.

In some cases that maybe true.  But the intent is not to solve all the
problems.  As a minimum, the user's will notice something has gone wrong and
will fire up their browser.

> >    There is one kind of packet that the access device MUST always
> >    discard, that is an IP fragment with a fragment offset
> of one. This
> >    is a valid packet, but it only has one use, to try to circumvent
> >    firewalls.
> 
> I'm pretty sure there are other attack-only packets. I
> suspect the definition of those packets belongs to another document.

Perhaps.  This is a cut and paste from Diameter.

 
>  > 4.1 NAS-Filter-Rule Attribute
> 
> Can it happen that the text is too long for a RADIUS attribute?

It could and we would just extend the value across to the next attribute.
This is common practice in RADIUS.

Because you can have more than one attribute, the only thing to watch out
for is that the extended attribute MUST not start with one of the "action"
keywords.
  
> Diameter Compatibility Issues:
> ==============================
> 
> - Section 1 could perhaps talk about what functions
>    exist in Diameter, how that compares to this specification,
>    and point to the section that talks about the translation.

Okay

> - Add a section on the translation. If you need help,
>    I can provide some text, but I think you know what
>    needs to be done.

Understood.

> >    As pointed out by NASREQ the use Filter-Id is not
> roaming friendly
> >    and it is recommended that instead one should use
> >    NAS-Filter-Rule(400) AVP. For this reason, this document
> introduces
> >    NAS-Filter-Rule(TBD) to RADIUS.
> 
> This seems to be a case where we add a new attribute to
> RADIUS where there already exists a Diameter AVP in Diameter 
> AVP code space. That is fine otherwise, but a system that 
> works according to the NASREQ translation rules would map the 
> new RADIUS attribute to the corresponding RADIUS code space 
> AVP in Diameter, rather than using the existing Diameter AVP, 
> making interoperability hard. This can be solved by having 
> the translation agent treat this attribute as a special case, 
> but it is not as nice is one could hope for. If anyone has 
> good suggestions how to solve this, let me know...

I predict that this will happen again and again.  Actually anytime that
someone developes a Diameter Application before the corresponding RADIUS one
we may run into this problem.
 
> Editorial:
> ==========
> 
> >    The text conforms to the following specification (taken
> from Diameter
> >    IPFilterRule Type):
> 
> Just as an editorial thing, I wonder if a reference to
> RFC 3588 would work better here. Then if there's a
> future extension of the filter rules some day, we could
> track those better.

Okay

> > 8. Open Issues
> 
> Delete.
> 
> >    An implementation is not compliant if it fails to
> satisfy one or more
> >    of the must or must not requirements for the protocols
> it implements.
> >    An implementation that satisfies all the must, must not,
> should and
> >    should not requirements for its protocols is said to be
> >    "unconditionally compliant"; one that satisfies all the
> must and must
> >    not requirements but not all the should or should not
> requirements
> >    for its protocols is said to be "conditionally compliant".
> 
> Capitalization of keywords?
> 
> >    Today this capability is supported in RADIUS
> >    and is configurable during service establishment and
> mid-service via
> >    the Filter-Id(11) attribute.
> 
> I would prefer seeing Filter-Id [Ref], ie. pointer to the spec rather 
> than the number. But maybe its just me...
> 
> >    As pointed out by NASREQ the use Filter-Id is not
> roaming friendly
> >    and it is recommended that instead one should use
> >    NAS-Filter-Rule(400) AVP. For this reason, this document
> introduces
> >    NAS-Filter-Rule(TBD) to RADIUS.
> 
> Maybe "As pointed out in [some reference] the use Filter-Id is not 
> roaming friendly due to the need to have a globally agreed filter 
> lists. Diameter NASREQ [Diameter NASREQ] defines the
> NAS-Filter-Rule(400) AVP for this reason. This document
> introduces the corresponding AVP to RADIUS.
> 
> > 4.3 Redirection-Rule
> 
> Is there some duplication with the filter format
> definion here vs. Section 4.1?

Redirection rule very much looks the same in many ways to Filter-Rule.

> --Jari
> 

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>