[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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?
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.
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...
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...
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.
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.
> 4.1 NAS-Filter-Rule Attribute
Can it happen that the text is too long for a RADIUS
attribute?
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.
- 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.
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...
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.
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?
--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/>