Issue 100: Security Considerations Submitter name: Alan DeKok Submitter email address: aland@ox.org Date first submitted: July 11, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00524.html Document: IEEE802-00 Comment type: T Priority: S Section: 7.3 Rationale/Explanation of issue:
The last sentence of section 7 has strong new requirements on RADIUS
The last sentence of section 7 is also the last section of the
document, and says:
In addition, the same RADIUS shared secret MUST NOT used for both
IEEE 802.1X authentication and PAP authentication.
It's a little surprising to have a requirement with such a large
impact as the last sentence in the document, with no further
discussion.
This requirement means that it may be impossible for implementations
to call themselves "unconditionally compliant". Since RADIUS servers
cannot control the authentication methods used by a NAS, there is no
way for an implementation to know if a particular shared secret is
used for IEEE 802.1X or PAP authentication.
When a RADIUS server is proxying requests from one or more NASes to
a home server, it may not have a choice about how many shared secrets
it uses. In order to satisfy the MUST in section 7.3, the proxying
server MUST send packets from two different IP addresses. This
configuration may not be possible in many deployments.In addition, 802.1X devices may pass through EAP for user authentication, but also implement device administrator authentication via RADIUS. Implementers should be guided as to how to implement administrator authentication without breaking the security of user authentication. Requested change: 1. Change the MUST to a SHOULD. 2. Add the following suggested text: Implementers are strongly cautioned to treat the preceding SHOULD as a MUST. Issues with the RADIUS protocol prevent the above requirement from being a MUST in all deployments. If the device supports administrator authentication via RADIUS, that authentication MUST NOT use PAP. That is, a device such as an access point that implements IEEE 802.1X authentication MUST NOT send a User-Password attribute in any Access-Request packet. Another authentication method MUST be used, though we do not suggest one here. RADIUS server implementations that proxy both PAP and IEEE 802.1X authentication to another RADIUS server SHOULD use multiple source IP addresses for the proxied packets. Where this configuration is used, the implementation MUST NOT use the same source IP address for both IEEE 802.1X authentication and for PAP authentication. In those deployments, the same RADIUS shared secret MUST NOT used for both IEEE 802.1X authentication and PAP authentication.
[Mauricio Sanchez]
One could say that the cat is out of the bag. Section 7 was taken mostly from existing RFCs, in particular RFC3580. The specific sentence your issue relates to already exists verbatim in RFC3580 section 5.3. My proposal is to change the last sentence in section 7 to: "For IEEE 802.X environments, best practices outlined in [RFC3580] mandate the use of different RADIUS shared secrets for IEEE 802.1X authentication and PAP authentication." An normative reference will also need to be added to RFC3580 in section 8.1.
[Bernard Aboba]
A bit about the intention of the cited sentence in [RFC3580]. Section 5.3 relates to known plaintext attacks against PAP, where the attacker attempts to authenticate to a NAS and then collects the User-Password attribute sent by the RADIUS client, in order to derive the keystream used for attribute hiding. This attack is easy to mount because RFC 2865 does not require that the RADIUS Access-Request be integrity protected. Since the User-Password keystream is a function of the Shared Secret and the Request Authenticator, a user's password should be considered compromised if the Request Authenticator (User-Password) repeats on any NAS utilizing a given RADIUS shared secret. In order to prevent this attack, RFC 2865 requires the Request Authenticator to be globally and temporally unique, but not all NASes satisfy this requirement. For example, a NAS can attempt to satisfy the global uniqueness property by utilizing the IP address in the high order bits of the RA and then utilizing a pseudo-random number in the low order bits. However, not all NAS devices have sufficient entropy to produce high quality pseudo-random numbers. If in addition, the same RADIUS shared secret is used on for more than one NAS, the chance of compromise increases significantly. Once an attacker has compromised user passwords, they can gain access to all media which utilize those credentials, enabling known plaintext attacks on other hidden attributes such as Tunnel-Password and MPPE-Keys. These other hidden attributes cannot be attacked by an unauthenticated attacker because these attributes are only sent in an Access-Accept, which implies a successful authentication. So the attacker must first obtain access to compromised passwords before trying this more difficult attack. However, once this attacks collects sufficient keystream material, if the RA + salt ever repeats on a NAS utilizing a given shared secret, then the EAP MSK or Tunnel-Password is compromised. As a result, Section 5.3 is attempting to discourage the use of PAP and the potential cascading vulnerablities that this can cause. If PAP cannot be deprecated entirely, then it is best if its use is isolated to accounts that have limited access rights. Also, EAP made a conscious decision not to support PAP, so re-introduction of PAP support into EAP is undesirable. If these principles are followed, it possible to limit the use of PAP without forcing a RADIUS proxy to utilize a different IP address for PAP and EAP authentication.
Proposed Resolution: Discuss
Issue 101: WG Last Call Review Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: July 14, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00527.html Document: IEEE802-00 Comment type: T Priority: 1 Section: Various Rationale/Explanation of issue:
Overall impression: NAS/QoS-Filter-Rule part is quite messy,
other parts are reasonably OK. I'll send my comments about
NAS-Filter-Rule in a separate email.
1) Section 1.1 contains some unnecessary terminology that is not
used anywhere later in the document: "Access Point (AP)",
"Association", "Port Access Entity (PAE)", "Station (STA)"
2) Section 2.2: "If accounting is enabled on the NAS, it MUST
generate an Accounting-Request (Stop) message upon session
termination."
So the NAS must send a Stop message, even though it has not sent
a Start message for this session yet? RFC 2866 seems suggest
that a session always has a Start message before Stop, but does
not seem to outright prohibit sending a stand-alone Stop
message. Is this a common practice, or are there any problems
associated with it?
3) Section 3.1: 802.1Q does not use the abbreviation "VLANID"
but rather "VID". Should this document also follow that
convention? (but maybe VLANID is more understandable)
4) Section 3.1: "Padding bits SHOULD be 0 (zero)." Why "SHOULD"
instead of "MUST"? (according to RFC 2119, it would mean there
are valid reasons to send something else in some circumstances?)
(This same issue occurs also in Section 4.2.)
5) Section 3.3: If VLAN-Name has basically the same meaning as
Egress-VLANID, IMHO their names should reflect this. Perhaps
"Egress-VLAN-Name"?
6) Section 3.3: Using "START OF HEADING" (0x01) and "START OF
TEXT" (0x02) control characters to indicate tagged/untagged
might make it unnecessarily difficult to enter this attribute
in a management interface... maybe something like 0x74/0x75
("t"/"u") or 0x31/0x32 ("1"/"2") would be easier?
7) Section 3.3: Probably should have reference to UTF-8? [RFC3629]
8) Section 3.4: "The table, expressed as an 8 octet string, maps
the incoming priority (if one exists - the default is 0) into
one of seven regenerated priorities." If the regenerated
priority is an integer in range 0-7, should that be "eight
regenerated priorities"?
9) A comment about the bit figures in Section 3 and 4.
Currently, all the figures are basically identical: they contain
the RADIUS Type and Length fields, plus one other field
(variably called either "Integer", "String" or "Text").
The contents of this field are then described in English.
I think it would be much more understandable if the figure also
showed the structure. For instance, instead of this (Section 3.1),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Integer
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer(cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
this would IMHO be more readable:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Tag Option | (zero)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(zero) | VLANID (12 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(Note that I'm not proposing changing the attribute formats at all --
so no changes to any software --, just how they are presented in the
document. And we can keep all the zero padding there if we want...)
10) Section 5: If the semantics of Acct-EAP-Auth-Method are
identical to Diameter EAP (as Section 4.2 claims), then it can
also be included in Access-Accept messages. (Or if it can't,
then the semantics are not identical, and need to be described
in this document.)
11) Section 7: It looks like this security considerations
section was just copied from somewhere without much thought for
how well it actually applies to this document. Most of the text
looks redundant to me; we don't need to describe how to use
IPsec with RADIUS in every document that defines a new RADIUS
attribute.
On the other hand, there's exactly zero discussion about new
threats caused by the attributes defined in _this_ document.
And to me it looks like there are new attacks that e.g. a
malicious or compromised RADIUS server or proxy could do with
these attributes (compared to the situation where NAS does not
support these attributes). At least Egress-VLANID,
Ingress-Filters and NAS-Filter-Rule have some pretty obvious
possibilities for abuse... (and maybe some non-obvious as well)
12) References: Both 802.1Q and .1D look normative to me, but
RFC1321 and 802.11i probably are just informative.
13) References: Document cites [DiamEAP] and [NASREQ], but
they're not included in the references section. Both are
normative.[Paul Congdon]
Here are some proposed resolutions to Pasi's Issue 101 WG review
comments:
Overall impression: NAS/QoS-Filter-Rule part is quite messy, other parts
are reasonably OK. I'll send my comments about NAS-Filter-Rule in a
separate email.
1) Section 1.1 contains some unnecessary terminology that is not used
anywhere later in the document: "Access Point (AP)", "Association",
"Port Access Entity (PAE)", "Station (STA)"
[pc] - agreed, to be removed.
2) Section 2.2: "If accounting is enabled on the NAS, it MUST generate
an Accounting-Request (Stop) message upon session termination."
So the NAS must send a Stop message, even though it has not sent a Start
message for this session yet? RFC 2866 seems suggest that a session
always has a Start message before Stop, but does not seem to outright
prohibit sending a stand-alone Stop message. Is this a common practice,
or are there any problems associated with it?
[pc] I believe that this should not cause any problem, but to be honest,
we could use some input from others. I'm aware of some implementations
that send a start and then immediately follow with a stop, but this
could be more resource intensive than needed. The stop without a start
would either be ignored by the server or appropriately acknowledge the
termination of the session that didn't start. This could be useful for
diagnostic purposes. I'd love to hear from other Radius vendors as to
whether this would be a problem or not. Again, my assumption is that it
isn't.
3) Section 3.1: 802.1Q does not use the abbreviation "VLANID"
but rather "VID". Should this document also follow that convention?
(but maybe VLANID is more understandable)
[pc] Yes, 802.1Q most often uses VID for VLAN Identifier. It sometimes
uses VLAN ID (with a space). However, RFC 3580 uses VLANID and since
this document is most likely used in conjunction with RFC 3580, I
suggest we just leave VLANID as is.
4) Section 3.1: "Padding bits SHOULD be 0 (zero)." Why "SHOULD"
instead of "MUST"? (according to RFC 2119, it would mean there are valid
reasons to send something else in some circumstances?) (This same issue
occurs also in Section 4.2.)
[pc] This can be changed to MUST. The desired behavior, IMO, is to
require the bits to be set to 0, but not require them to be checked on
receipt. The simple MUST or SHOULD wording doesn't really reflect this,
so it is probably best that we make this a MUST. Agree to change this
SHOULD to a MUST here and in 4.2
5) Section 3.3: If VLAN-Name has basically the same meaning as
Egress-VLANID, IMHO their names should reflect this. Perhaps
"Egress-VLAN-Name"?
[pc] Sure, no objection. Change the name of the VLAN-Name attribute to
Egress-VLAN-Name everywhere in the document.
6) Section 3.3: Using "START OF HEADING" (0x01) and "START OF TEXT"
(0x02) control characters to indicate tagged/untagged might make it
unnecessarily difficult to enter this attribute in a management
interface... maybe something like 0x74/0x75
("t"/"u") or 0x31/0x32 ("1"/"2") would be easier?
[pc] We were trying to get Egress-VLANID and (now called)
Egress-VLAN-Name to have as similar a format as possible. While
Egress-VLAN-Name could be made to be an all text type of management
interface, Egress-VLANID can not. The VLANID is a simple 12-bit number
and won't map well to the keyboard input optimization no matter what we
do, so some form of special formatting for the management interface will
be required to support these two attributes. Also, tagged and untagged
are the only flags we need today, but perhaps this field would need to
be extended someday (e.g. 802.1ad support), and using more bits to
represent the two values needed today would seems to be wasteful. I
propose no change here.
7) Section 3.3: Probably should have reference to UTF-8? [RFC3629]
[pc] yes, Add a reference to [RFC3629] here and then a formal reference
in section 8.
8) Section 3.4: "The table, expressed as an 8 octet string, maps the
incoming priority (if one exists - the default is 0) into one of seven
regenerated priorities." If the regenerated priority is an integer in
range 0-7, should that be "eight regenerated priorities"?
[pc] yes, change to "eight regenerated priorities"
9) A comment about the bit figures in Section 3 and 4.
Currently, all the figures are basically identical: they contain the
RADIUS Type and Length fields, plus one other field (variably called
either "Integer", "String" or "Text").
The contents of this field are then described in English.
I think it would be much more understandable if the figure also showed
the structure. For instance, instead of this (Section 3.1),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Integer
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer(cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
this would IMHO be more readable:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Tag Option | (zero)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(zero) | VLANID (12 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(Note that I'm not proposing changing the attribute formats at all -- so
no changes to any software --, just how they are presented in the
document. And we can keep all the zero padding there if we want...)
[pc] To make this clean and follow your recommendation I believe it has
significant structural changes to the document. Most of the attributes
do not have diagrams at all. There would need to be a lot of new ASCII
art added and it would be difficult for string based fields like
NAS-Filter-Rule to accommodate this. If we put all the internal field
names in the base attribute diagram along with Type and Length, it would
seem that we would need to describe each of the other fields
individually rather than indicating how to format the Integer, Text or
String portion. I'd rather keep the bulk of the attribute sections
intact and only provide a diagram describing how to format the Integer,
Text or String porition - as is done in 3.1. We could certainly make
3.2, 3.3 and 3.4 more consistent with 3.1 and add a diagram on how to
format the Integer, Text and/or String component. Would this work?
10) Section 5: If the semantics of Acct-EAP-Auth-Method are identical to
Diameter EAP (as Section 4.2 claims), then it can also be included in
Access-Accept messages. (Or if it can't, then the semantics are not
identical, and need to be described in this document.)
[pc] agreed, but I believe this attribute is going to be removed from
the draft per issue 114.
11) Section 7: It looks like this security considerations section was
just copied from somewhere without much thought for how well it actually
applies to this document. Most of the text looks redundant to me; we
don't need to describe how to use IPsec with RADIUS in every document
that defines a new RADIUS attribute.
On the other hand, there's exactly zero discussion about new threats
caused by the attributes defined in _this_ document.
And to me it looks like there are new attacks that e.g. a malicious or
compromised RADIUS server or proxy could do with these attributes
(compared to the situation where NAS does not support these attributes).
At least Egress-VLANID, Ingress-Filters and NAS-Filter-Rule have some
pretty obvious possibilities for abuse... (and maybe some non-obvious as
well)
[pc] Yes, much of this text was copied from 3580, but short of trying to
imagine all the things that could happen if a RADIUS server is
comprimized, I'm not sure what else to put here. We could puts some
words here about how modified settings of things like Ingress-Filters or
Filter-Rules could change the expected behavior, but the discussion
would not be exhaustive. I thought the point of this section was to
document what the vulnerabilities are, not how they might be used. For
example, the scheme is vulnerable to packet modification attacks, but
we can't document what might happen with every possible modification of
a packet. Please provide some more explanation or examples of what you
are looking for here.
12) References: Both 802.1Q and .1D look normative to me, but
RFC1321 and 802.11i probably are just informative.
[pc] agreed. Swap these reference locations.
13) References: Document cites [DiamEAP] and [NASREQ], but they're not
included in the references section. Both are normative.
[pc] agreed. Add these references.> No, the text was intended as a replacement of what's already there.
>
> The existing text is IMHO unnecessary because it doesn't
> describe any security considerations of _this_ document. I
> don't think we need to repeat what's already said in RFC 2865
> and 3579 in every document that defines a new RADIUS
> attribute: we just need to describe what new security
> considerations this document has (in addition to those
> already adequately described in 2865/3579).
>
I agree that we shouldn't repeat text from the other documents, but I do
believe some of the security considerations documented in these other
documents may still apply. I'd like to at least leave the introductory
paragraph, followed by your text. The security section would then look
as follows:
7. Security Considerations
Since this document describes the use of RADIUS for purposes of
authentication, authorization, and accounting in IEEE 802.1X-
enabled networks, it is vulnerable to all of the threats that are
present in other RADIUS applications. For a discussion of these
threats, see [RFC2607], [RFC3162], [RFC3579], and [RFC3580].
This documents specifies new attributes that can be included
in existing RADIUS messages. These messages are protected
using existing security mechanisms; see [RFC2865] and
[RFC3576] for a more detailed description and related security
considerations.
The security mechanisms in [RFC2865] and [RFC3576] are
primarily concerned with an outside attacker who modifies
messages in transit or inserts new messages. They do not
prevent an authorized RADIUS server or proxy from inserting
attributes with a malicious purpose in message it sends.
An attacker who compromises an authorized RADIUS server or
proxy can use the attributes defined in this document to
influence the behavior of the NAS in ways that previously may
not have been possible. For example, modifications to the
VLAN-related attributes may cause the NAS to permit access to
other VLANs that were intended. To give another example,
inserting suitable redirection rules to the NAS-Filter-Rule
attribute may allow the attacker to eavesdrop or modify
packets sent by a legitimate client.
In general, the NAS cannot know whether the attribute values
it receives from an authenticated and authorized server are
well-intentioned or malicious, and thus it is not possible to
completely protect against attacks by compromised nodes. In
some cases, the extent of the possible attacks can be limited
by performing more fine-grained authorization checks at the NAS.
For instance, a NAS could be configured to accept only certain
VLAN IDs from a certain RADIUS server/proxy, or not to accept
any redirection rules if it is known they are not used in
this environment.[Pasi Eronen]
paul.congdon@hp.com wrote:
> [pc] Here are some proposed resolutions to Pasi's Issue 101 WG
> review comments:
I'm happy with most of these proposals; see comments below
for the rest...
> 6) Section 3.3: Using "START OF HEADING" (0x01) and "START OF
> TEXT" (0x02) control characters to indicate tagged/untagged
> might make it unnecessarily difficult to enter this attribute
> in a management interface... maybe something like 0x74/0x75
> ("t"/"u") or 0x31/0x32 ("1"/"2") would be easier?
>
> [pc] We were trying to get Egress-VLANID and (now called)
> Egress-VLAN-Name to have as similar a format as possible.
> While Egress-VLAN-Name could be made to be an all text type of
> management interface, Egress-VLANID can not. The VLANID is a
> simple 12-bit number and won't map well to the keyboard input
> optimization no matter what we do, so some form of special
> formatting for the management interface will be required to
> support these two attributes. Also, tagged and untagged are
> the only flags we need today, but perhaps this field would
> need to be extended someday (e.g. 802.1ad support), and using
> more bits to represent the two values needed today would seems
> to be wasteful. I propose no change here.
Egress-VLANID doesn't necessarily need any special code in the
management interface if it supports entering hexadecimal numbers
(e.g. tagged VID 6 could be entered as 0x01000006).
And VLAN-Name attribute already uses 8 bits to represent these
two values; changing that from 0x01/0x02 to, say, 0x31/0x32
wouldn't use anything more... (and would not prevent us from
defining value values later any more than 0x01/0x02 does)
> 9) A comment about the bit figures in Section 3 and 4.
> Currently, all the figures are basically identical: they
> contain the RADIUS Type and Length fields, plus one other
> field (variably called either "Integer", "String" or "Text").
> The contents of this field are then described in English.
>
> I think it would be much more understandable if the figure also showed
> the structure. For instance, instead of this (Section 3.1),
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type | Length | Integer
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Integer(cont.) |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> this would IMHO be more readable:
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type | Length | Tag Option | (zero)
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> (zero) | VLANID (12 bits) |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> (Note that I'm not proposing changing the attribute formats at
> all -- so no changes to any software --, just how they are
> presented in the document. And we can keep all the zero
> padding there if we want...)
>
> [pc] To make this clean and follow your recommendation I
> believe it has significant structural changes to the document.
> Most of the attributes do not have diagrams at all. There
> would need to be a lot of new ASCII art added and it would be
> difficult for string based fields like NAS-Filter-Rule to
> accommodate this. If we put all the internal field names in
> the base attribute diagram along with Type and Length, it
> would seem that we would need to describe each of the other
> fields individually rather than indicating how to format the
> Integer, Text or String portion. I'd rather keep the bulk of
> the attribute sections intact and only provide a diagram
> describing how to format the Integer, Text or String porition
> - as is done in 3.1. We could certainly make 3.2, 3.3 and 3.4
> more consistent with 3.1 and add a diagram on how to format
> the Integer, Text and/or String component. Would this work?
I don't think significant changes are needed; basically, only
a couple of small changes would clarify the document significantly.
The most important ones would IMHO be:
- combining the two figures in 3.1
- fixing the figure in 4.1 (explicitly show that the attribute
contains both a 64-bit counter and a string according to
NAS-Filter-Rule; calling the counter a part of the string
is misleading, since it doesn't even consist of printable
characters...)
- Add figure to section 3.3 (explicitly showing that the
attribute contains two different items)
> 11) Section 7: It looks like this security considerations
> section was just copied from somewhere without much thought
> for how well it actually applies to this document. Most of the
> text looks redundant to me; we don't need to describe how to
> use IPsec with RADIUS in every document that defines a new
> RADIUS attribute.
>
> On the other hand, there's exactly zero discussion about new
> threats caused by the attributes defined in _this_ document.
> And to me it looks like there are new attacks that e.g. a
> malicious or compromised RADIUS server or proxy could do with
> these attributes (compared to the situation where NAS does not
> support these attributes). At least Egress-VLANID,
> Ingress-Filters and NAS-Filter-Rule have some pretty obvious
> possibilities for abuse... (and maybe some non-obvious as
> well)
>
> [pc] Yes, much of this text was copied from 3580, but short of
> trying to imagine all the things that could happen if a RADIUS
> server is comprimized, I'm not sure what else to put here. We
> could puts some words here about how modified settings of
> things like Ingress-Filters or Filter-Rules could change the
> expected behavior, but the discussion would not be exhaustive.
> I thought the point of this section was to document what the
> vulnerabilities are, not how they might be used. For example,
> the scheme is vulnerable to packet modification attacks, but
> we can't document what might happen with every possible
> modification of a packet. Please provide some more
> explanation or examples of what you are looking for here.
There's no need to imagine all things that could happen if a
RADIUS server is compromised, but it is IMHO necessary to at
least briefly discuss how implementing _this_ document changes
the existing situation.
Maybe something like this:
This documents specifies new attributes that can be included
in existing RADIUS messages. These messages are protected
using existing security mechanisms; see [RFC2865] and
[RFC3576] for a more detailed description and related security
considerations.
The security mechanisms in [RFC2865] and [RFC3576] are
primarily concerned with an outside attacker who modifies
messages in transit or inserts new messages. They do not
prevent an authorized RADIUS server or proxy from inserting
attributes with a malicious purpose in messagse it sends.
An attacker who compromises an authorized RADIUS server or
proxy can use the attributes defined in this document to
influence the behavior of the NAS in ways that previously may
not have been possible. For example, modifications to the
VLAN-related attributes may cause the NAS to permit access to
other VLANs that were intended. To give another example,
inserting suitable redirection rules to the NAS-Filter-Rule
attribute may allow the attacker to eavesdrop or modify
packets sent by a legitimate client.
In general, the NAS cannot know whether the attribute values
it receives from an authenticated and authorized server are
well-intentioned or malicious, and thus it is not possible to
completely protect against attacks by compromised nodes. In
some cases, the extent of the possible attacks can be limited
by performing more fine-grained authorization checks at the NAS.
For instance, a NAS could be configured to accept only certain
VLAN IDs from a certain RADIUS server/proxy, or not to accept
any redirection rules if it is known they are not used in
this environment.[Paul Congdon]
I deleted some stuff to focus on the three items:
>
> Egress-VLANID doesn't necessarily need any special code in
> the management interface if it supports entering hexadecimal
> numbers (e.g. tagged VID 6 could be entered as 0x01000006).
>
> And VLAN-Name attribute already uses 8 bits to represent
> these two values; changing that from 0x01/0x02 to, say,
> 0x31/0x32 wouldn't use anything more... (and would not
> prevent us from defining value values later any more than
> 0x01/0x02 does)
Ok. I'd still like to keep the attributes as similar as possible, so I
propose we also change the value of tagged and untagged to 0x31 and 0x32
in the Egress-VLANID attribute as well. Thus, your example above of
tagged VID 6 would be entered as 0x31000006.
>
> I don't think significant changes are needed; basically, only
> a couple of small changes would clarify the document significantly.
> The most important ones would IMHO be:
>
> - combining the two figures in 3.1
>
> - fixing the figure in 4.1 (explicitly show that the attribute
> contains both a 64-bit counter and a string according to
> NAS-Filter-Rule; calling the counter a part of the string
> is misleading, since it doesn't even consist of printable
> characters...)
>
> - Add figure to section 3.3 (explicitly showing that the
> attribute contains two different items)
>
Ok, this isn't too bad, we can make these specific changes.
>
> There's no need to imagine all things that could happen if a
> RADIUS server is compromised, but it is IMHO necessary to at
> least briefly discuss how implementing _this_ document
> changes the existing situation.
>
> Maybe something like this:
>
I'm assuming the text you provided would be in addition to what is
already there? Below, I've merged your text into the existing text as
an entirely new Security section.
How about the following:
7. Security Considerations
Since this document describes the use of RADIUS for purposes of
authentication, authorization, and accounting in IEEE 802.1X-
enabled networks, it is vulnerable to all of the threats that are
present in other RADIUS applications. For a discussion of these
threats, see [RFC2607], [RFC2865], [RFC3162], [RFC3576],
[RFC3579], and [RFC3580].
Vulnerabilities include:
Packet modification or forgery
Dictionary attacks
Known plaintext attacks
Compromised RADIUS Server or Proxy
7.1. Packet Modification or Forgery
As noted in [RFC3580], when used with IEEE 802.1X, all RADIUS
packets MUST be authenticated and integrity protected. In
addition, as described in [RFC3579], Section 4.2:
To address the security vulnerabilities of RADIUS/EAP,
implementations of this specification SHOULD support IPsec
[RFC2401] along with IKE [RFC2409] for key management. IPsec
ESP [RFC2406] with non-null transform SHOULD be supported, and
IPsec ESP with a non-null encryption transform and
authentication support SHOULD be used to provide per-packet
confidentiality, authentication, integrity and replay
protection. IKE SHOULD be used for key management.
7.2. Dictionary Attacks
As discussed in [RFC3579] Section 4.3.3, the RADIUS shared secret
is vulnerable to offline dictionary attack, based on capture of
the Response Authenticator or Message-Authenticator attribute. In
order to decrease the level of vulnerability, [RFC2865], Section 3
recommends:
The secret (password shared between the client and the RADIUS
server) SHOULD be at least as large and unguessable as a well-
chosen password. It is preferred that the secret be at least
16 octets.
In addition, the risk of an offline dictionary attack can be
further mitigated by employing IPsec ESP with non-null
transform in order to encrypt the RADIUS conversation, as
described in [RFC3579], Section 4.2.
7.3. Known Plaintext Attacks
Since IEEE 802.1X is based on EAP, which does not support PAP, the
RADIUS User-Password attribute is not used to carry hidden user
passwords. The hiding mechanism utilizes MD5, defined in
[RFC1321], in order to generate a key stream based on the RADIUS
shared secret and the Request Authenticator. Where PAP is in
use, it is possible to collect key streams corresponding to a
given Request Authenticator value, by capturing RADIUS
conversations corresponding to a PAP authentication attempt using
a known password. Since the User-Password is known, the key stream
corresponding to a given Request Authenticator can be determined
and stored.
The vulnerability is described in detail in [RFC3579], Section
4.3.4. Even though IEEE 802.1X Authenticators do not support PAP
authentication, a security vulnerability can still exist where the
same RADIUS shared secret is used for hiding User-Password as well
as other attributes. This can occur, for example, if the same
RADIUS proxy handles authentication requests for both IEEE 802.1X
(which may hide the Tunnel-Password, MS-MPPE-Send-Key and MS-MPPE-
Recv-Key attributes) and GPRS (which may hide the User-Password
attribute).
The threat can be mitigated by protecting RADIUS with IPsec ESP
with non-null transform, as described in [RFC3579], Section 4.2.
In addition, the same RADIUS shared secret MUST NOT used for both
IEEE 802.1X authentication and PAP authentication.
7.4 Compromised RADIUS Server or Proxy
This documents specifies new attributes that can be included
in existing RADIUS messages. These messages are protected
using existing security mechanisms; see [RFC2865] and
[RFC3576] for a more detailed description and related security
considerations.
The security mechanisms in [RFC2865] and [RFC3576] are
primarily concerned with an outside attacker who modifies
messages in transit or inserts new messages. They do not
prevent an authorized RADIUS server or proxy from inserting
attributes with a malicious purpose in message it sends.
An attacker who compromises an authorized RADIUS server or
proxy can use the attributes defined in this document to
influence the behavior of the NAS in ways that previously may
not have been possible. For example, modifications to the
VLAN-related attributes may cause the NAS to permit access to
other VLANs that were intended. To give another example,
inserting suitable redirection rules to the NAS-Filter-Rule
attribute may allow the attacker to eavesdrop or modify
packets sent by a legitimate client.
In general, the NAS cannot know whether the attribute values
it receives from an authenticated and authorized server are
well-intentioned or malicious, and thus it is not possible to
completely protect against attacks by compromised nodes. In
some cases, the extent of the possible attacks can be limited
by performing more fine-grained authorization checks at the NAS.
For instance, a NAS could be configured to accept only certain
VLAN IDs from a certain RADIUS server/proxy, or not to accept
any redirection rules if it is known they are not used in
this environment.[Pasi Eronen]
> I'm assuming the text you provided would be in addition to what is > already there? Below, I've merged your text into the > existing text as an entirely new Security section. No, the text was intended as a replacement of what's already there. The existing text is IMHO unnecessary because it doesn't describe any security considerations of _this_ document. I don't think we need to repeat what's already said in RFC 2865 and 3579 in every document that defines a new RADIUS attribute: we just need to describe what new security considerations this document has (in addition to those already adequately described in 2865/3579).
[Paul Congdon]
I think we are converging. Would love to hear from others if this is
acceptable...
> >
> > I'm assuming the text you provided would be in addition to what is
> > already there? Below, I've merged your text into the
> existing text
> > as an entirely new Security section.
>
> No, the text was intended as a replacement of what's already there.
>
> The existing text is IMHO unnecessary because it doesn't
> describe any security considerations of _this_ document. I
> don't think we need to repeat what's already said in RFC 2865
> and 3579 in every document that defines a new RADIUS
> attribute: we just need to describe what new security
> considerations this document has (in addition to those
> already adequately described in 2865/3579).
>
I agree that we shouldn't repeat text from the other documents, but I do
believe some of the security considerations documented in these other
documents may still apply. I'd like to at least leave the introductory
paragraph, followed by your text. The security section would then look
as follows:
7. Security Considerations
Since this document describes the use of RADIUS for purposes of
authentication, authorization, and accounting in IEEE 802.1X-
enabled networks, it is vulnerable to all of the threats that are
present in other RADIUS applications. For a discussion of these
threats, see [RFC2607], [RFC3162], [RFC3579], and [RFC3580].
This documents specifies new attributes that can be included
in existing RADIUS messages. These messages are protected
using existing security mechanisms; see [RFC2865] and
[RFC3576] for a more detailed description and related security
considerations.
The security mechanisms in [RFC2865] and [RFC3576] are
primarily concerned with an outside attacker who modifies
messages in transit or inserts new messages. They do not
prevent an authorized RADIUS server or proxy from inserting
attributes with a malicious purpose in message it sends.
An attacker who compromises an authorized RADIUS server or
proxy can use the attributes defined in this document to
influence the behavior of the NAS in ways that previously may
not have been possible. For example, modifications to the
VLAN-related attributes may cause the NAS to permit access to
other VLANs that were intended. To give another example,
inserting suitable redirection rules to the NAS-Filter-Rule
attribute may allow the attacker to eavesdrop or modify
packets sent by a legitimate client.
In general, the NAS cannot know whether the attribute values
it receives from an authenticated and authorized server are
well-intentioned or malicious, and thus it is not possible to
completely protect against attacks by compromised nodes. In
some cases, the extent of the possible attacks can be limited
by performing more fine-grained authorization checks at the NAS.
For instance, a NAS could be configured to accept only certain
VLAN IDs from a certain RADIUS server/proxy, or not to accept
any redirection rules if it is known they are not used in
this environment.[Emile Bergen] That text looks very good. [Bernard Aboba] Yes, I think the text is fine. [Pasi Eronen] This looks OK to me.
Proposed Resolution: Accept
Issue 102: NAS/QoS Filter Rule Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: July 14, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00526.html Document: IEEE802-00 Comment type: T Priority: 1 Section: Various Rationale/Explanation of issue:
1) Section 3.5 is currently quite difficult to follow since it
mixes L2, IP, tunneling and HTTP redirect rules... It's not
always even clear when some element is just a name for a rule
(like "ipno") and when it's a literal string (like "from").
So some editing work is needed here. Maybe describing the L2,
IP filtering, IP tunneling and HTTP rules one-by-one
(instead of mixing their descriptions) would make this more
understandable.
(The IPFilterRule description in RFC3588 isn't nearly as
complicated as this, since it doesn't have the L2, tunneling
or HTTP rules.)
2) Or would using ABNF be of any help? Here's a first sketch
(probably buggy..)
rule = flush-rule /
l2-filter-rule /
ip-filter-rule /
ip-tunnel-rule /
http-redirect-rule
flush-rule = "flush"
l2-filter-rule = ("permit" / "deny") " " ("in" / "out" / "inout")
" " l2-filter [" Cnt"]
l2-filter = l2-proto " from " l2-address " to " l2-address
l2-filter =/ l2-rmon-str
l2-proto = "l2:ether2" [":0x" 1*4HEXDIG]
l2-rmon-str = "l2:" 1*DIGIT *("." 1*DIGIT)
l2-address = ["!"] (macaddr / (macaddr "/" mask) / "any")
macaddr = 2HEXDIG 5("-" 2HEXDIG)
mask = 1*2DIGIT
ip-filter-rule = ("permit" / "deny") " " ("in" / "out" / "inout")
" " ip-filter
ip-filter = ("ip" / ip-proto)
" from " ip-address [" " ip-ports]
" to " ip-address [" " ip-ports]
*(" " ip-option)
ip-proto = 1*3DIGIT
ip-address = ["!"] (ipv4-address ["/" bits] /
ipv6-address ["/" bits] /
"any" /
"assigned")
ipv4-address = 1*3DIGIT 3("." 1*3DIGIT)
ipv6-address = ;; TODO
bits = 1*3DIGIT
ip-ports = ip-port *("," ip-port)
ip-port = 1*5DIGIT / (1*5DIGIT "-" 1*5DIGIT)
ip-option = "Cnt"
ip-option = "frag"
ip-option =/ "ipoptions " ["!"] ipopt *("," ["!"] ipopt)
ip-option =/ "tcpoptions " ["!"] tcpopt *("," ["!"] tcpopt)
ip-option =/ "established"
ip-option =/ "setup"
ip-option =/ "tcpflags " ["!"] tcpflag *("," ["!"] tcpflag)
ip-option =/ "icmptypes " icmptype *("," icmptype)
ipopt = "ssrr" / "lsrr" / "rr" / "ts"
tcpopt = "mss" / "window" / "sack" / "ts" / "cc"
tcpflag = "fin" / "syn" / "rst" / "psh" / "ack" / "urg"
icmptype = 1*3DIGIT
icmptype =/ 1*3DIGIT "-" 1*3DIGIT
icmptype =/ ;; TODO (names)
ip-tunnel-rule = "tunnel " tunnel-id " in " ip-filter
tunnel-id = ;; TODO
http-redirect-rule = "redirect " [redir-cnt " "]
redir-url " in " ip-filter
redir-cnt = 1*DIGIT
redir-url = ;; TODO
(Ok, maybe this is not so clear either... but at least it's
unambiguous when something is just a rule name and when it's
a literal string )
3) Example of "macaddr/mask": The example should use some other
width than /24 to make it clearer how the counting works. Also,
the example given is an invalid one, since it does not meet the
"The MAC address MUST NOT have bits set beyond the mask"
requirement. Suggested change: use 00-10-A4-23-00-00/32 as the
example.
4) Description of "ipno/bits" says "the IP number MUST NOT have
bits set beyond the mask", but the example given, "1.2.3.4/24",
does not follow this. Suggested change: use 192.0.2.0/24 as the
example.
5) Description of tunnel_id: according to RFC 2868, there are no
restrictions on the format of the Tunnel-Assignment-ID.
Currently it's not clear if the NAS-Filter-Rule syntax supports
correctly parsing arbitrary IDs (what happens if the ID
includes spaces, for instance?)
6) Near the end of Section 3.5: The "concise syntax statements"
don't exactly match the definitions earlier. I catched
at least these:
- IP rule is missing "[ports]" before "to"
- IP rule is missing "|" after "redirect"
- HTTP redirect rule is missing the "proto" part after the direction
- HTTP redirect rule does not have "[ports]"
7) The document does not seem to describe what HTTP filter rules
are or how they work (HTTP redirect rules are explained, but not
HTTP filter rules).
8) The document allows an IP tunnel rule with direction "out",
but does not describe what such a rule means (the description
seems to apply only to rules with direction "in")
9) Currently the text says "A flush rule MUST appear before all
other rule types." I first read this to mean that a flush rule
must always be present, but I guess that was not what was
meant. Furthermore, it's not easy to parse the ordering
requirements.
Suggested change: Rewrite that paragraph to "Furthermore, if the
list contains different types of rules, they MUST appear in the
following order: flush rules, base encapsulation filter rules,
IP tunnel rules, HTTP redirect rules, IP filter rules, and HTTP
filter rules."
10) The document should explain why different types of rules must
be given in exactly that order. Placing L2 rules before IP is
understandable, but for some of the other cases it's not totally
obvious why other orderings need to be forbidden.
11) The document should have some examples of NAS filter rules,
preferably showing most of the different features at least once.
12) The document should somewhere describe the differences to
Diameter's NAS-Filter-Rule syntax.
13) If the NAS just concatenates all the NAS-Filter-Rule (or
QoS-Filter-Rule) attributes together to overcome the 255-byte
attribute length limit, then boundaries between individual rules
are lost. This is not necessarily a big problem, as it looks
like the syntax can be unambiguously parsed anyway, but should
be mentioned explicitly (alternatively, we could delimit the
individual rules somehow).[Paul Congdon]
[pc] Comments on Pasi's issue 102...
1) Section 3.5 is currently quite difficult to follow since it mixes L2,
IP, tunneling and HTTP redirect rules... It's not always even clear when
some element is just a name for a rule (like "ipno") and when it's a
literal string (like "from").
So some editing work is needed here. Maybe describing the L2, IP
filtering, IP tunneling and HTTP rules one-by-one (instead of mixing
their descriptions) would make this more understandable.
(The IPFilterRule description in RFC3588 isn't nearly as complicated as
this, since it doesn't have the L2, tunneling or HTTP rules.)
[pc] ok, assuming the rest of the discussion addresses this first point.
2) Or would using ABNF be of any help? Here's a first sketch (probably
buggy..)
rule = flush-rule /
l2-filter-rule /
ip-filter-rule /
ip-tunnel-rule /
http-redirect-rule
flush-rule = "flush"
l2-filter-rule = ("permit" / "deny") " " ("in" / "out" / "inout")
" " l2-filter [" Cnt"]
l2-filter = l2-proto " from " l2-address " to " l2-address
l2-filter =/ l2-rmon-str
l2-proto = "l2:ether2" [":0x" 1*4HEXDIG]
l2-rmon-str = "l2:" 1*DIGIT *("." 1*DIGIT)
l2-address = ["!"] (macaddr / (macaddr "/" mask) / "any")
macaddr = 2HEXDIG 5("-" 2HEXDIG)
mask = 1*2DIGIT
ip-filter-rule = ("permit" / "deny") " " ("in" / "out" / "inout")
" " ip-filter
ip-filter = ("ip" / ip-proto)
" from " ip-address [" " ip-ports]
" to " ip-address [" " ip-ports]
*(" " ip-option)
ip-proto = 1*3DIGIT
ip-address = ["!"] (ipv4-address ["/" bits] /
ipv6-address ["/" bits] /
"any" /
"assigned")
ipv4-address = 1*3DIGIT 3("." 1*3DIGIT)
ipv6-address = ;; TODO
bits = 1*3DIGIT
ip-ports = ip-port *("," ip-port)
ip-port = 1*5DIGIT / (1*5DIGIT "-" 1*5DIGIT)
ip-option = "Cnt"
ip-option = "frag"
ip-option =/ "ipoptions " ["!"] ipopt *("," ["!"] ipopt)
ip-option =/ "tcpoptions " ["!"] tcpopt *("," ["!"] tcpopt)
ip-option =/ "established"
ip-option =/ "setup"
ip-option =/ "tcpflags " ["!"] tcpflag *("," ["!"] tcpflag)
ip-option =/ "icmptypes " icmptype *("," icmptype)
ipopt = "ssrr" / "lsrr" / "rr" / "ts"
tcpopt = "mss" / "window" / "sack" / "ts" / "cc"
tcpflag = "fin" / "syn" / "rst" / "psh" / "ack" / "urg"
icmptype = 1*3DIGIT
icmptype =/ 1*3DIGIT "-" 1*3DIGIT
icmptype =/ ;; TODO (names)
ip-tunnel-rule = "tunnel " tunnel-id " in " ip-filter
tunnel-id = ;; TODO
http-redirect-rule = "redirect " [redir-cnt " "]
redir-url " in " ip-filter
redir-cnt = 1*DIGIT
redir-url = ;; TODO
(Ok, maybe this is not so clear either... but at least it's unambiguous
when something is just a rule name and when it's a literal string )
[pc] We can insert this if we can complete the TODO parts above. Do we
insert it before the current description or completely replace what is
there with just the ABNF? I'm assuming this would be inserted in front
of the current descriptions and we would leave the existing text with
fixes discussed below. Can you help complete the TODOs or provide a
good reference guide on ABNF somewhere?
3) Example of "macaddr/mask": The example should use some other width
than /24 to make it clearer how the counting works. Also, the example
given is an invalid one, since it does not meet the "The MAC address
MUST NOT have bits set beyond the mask"
requirement. Suggested change: use 00-10-A4-23-00-00/32 as the example.
[pc] accept suggestion
4) Description of "ipno/bits" says "the IP number MUST NOT have bits set
beyond the mask", but the example given, "1.2.3.4/24", does not follow
this. Suggested change: use 192.0.2.0/24 as the example.
[pc] accept suggestion, maybe change the first 0 to something else to
further disambiguate.
5) Description of tunnel_id: according to RFC 2868, there are no
restrictions on the format of the Tunnel-Assignment-ID.
Currently it's not clear if the NAS-Filter-Rule syntax supports
correctly parsing arbitrary IDs (what happens if the ID includes spaces,
for instance?)
[pc] Good observation. This needs fixing. Seems like we have two
choices; put restrictions on the usage of Tunnel-Assignment-ID so that
the strings are parse-able (not really a good idea), or encapsulate the
string in quotes when used in the rule. Since there are no restrictions
on the format of the string used in Tunnel-Assignment-ID we MUST provide
a way to parse it as a single element in the entire attribute string.
Of course, the Tunnel-Assignment-ID could itself contain quotes, so we
will also need to describe some escaping function before including them
in the rule. The escaping function would be: For all occurrence of "
replace with \" and for all occurrence of \ replace with \\. While this
is a little ugly, I think it is the only course of action.
6) Near the end of Section 3.5: The "concise syntax statements"
don't exactly match the definitions earlier. I catched at least these:
- IP rule is missing "[ports]" before "to"
- IP rule is missing "|" after "redirect"
- HTTP redirect rule is missing the "proto" part after the direction
- HTTP redirect rule does not have "[ports]"
[pc] agreed, fix these and double check the rest..
7) The document does not seem to describe what HTTP filter rules are or
how they work (HTTP redirect rules are explained, but not HTTP filter
rules).
[pc] There really aren't specific HTTP filter rules per-se. We don't
filter based upon HTTP content, but it is possible to filter all HTTP
traffic using normal IP filter rules. The text is a little unclear at
the end of the section that indicates there are 'redirect' and 'filter'
rules. Seems like we need to discuss redirect rules separately from
filter rules. There are really two types of redirect rules; tunnel and
http, and two filter rules; L2 and IP.
8) The document allows an IP tunnel rule with direction "out", but does
not describe what such a rule means (the description seems to apply only
to rules with direction "in")
[pc] Avi has written a great description of how the tunnel facility
works and how the directions apply. I've attached a version of this
document - perhaps Avi has something more recent? We probably want to
consider how parts of his document are incorporated into an annex or
some part of the document to make this clear.
9) Currently the text says "A flush rule MUST appear before all other
rule types." I first read this to mean that a flush rule must always be
present, but I guess that was not what was meant. Furthermore, it's not
easy to parse the ordering requirements.
Suggested change: Rewrite that paragraph to "Furthermore, if the list
contains different types of rules, they MUST appear in the following
order: flush rules, base encapsulation filter rules, IP tunnel rules,
HTTP redirect rules, IP filter rules, and HTTP filter rules."
[pc] Agreed. This is better than my suggestion to change this part of
the text to, "Base encapsulation filter rules MUST appear after a flush
rule (if present) and before IP tunnel,..."
10) The document should explain why different types of rules must be
given in exactly that order. Placing L2 rules before IP is
understandable, but for some of the other cases it's not totally obvious
why other orderings need to be forbidden.
[pc] We had considerable discussion about this early on in the document
development. If my memory serves me correctly, we decided upon this
order to maximize interoperability and to address the fact that it
didn't make sense to filter out packets before putting them into the
tunnel. Perhaps others can recall more detail - sorry.
11) The document should have some examples of NAS filter rules,
preferably showing most of the different features at least once.
[pc] agreed.
12) The document should somewhere describe the differences to Diameter's
NAS-Filter-Rule syntax.
[pc] agreed this relates to Bernard's comment as well. Text to be
developed.
13) If the NAS just concatenates all the NAS-Filter-Rule (or
QoS-Filter-Rule) attributes together to overcome the 255-byte attribute
length limit, then boundaries between individual rules are lost. This is
not necessarily a big problem, as it looks like the syntax can be
unambiguously parsed anyway, but should be mentioned explicitly
(alternatively, we could delimit the individual rules somehow).
[pc] yes, this should not be a problem and implementations will split
the string in different ways, but if they are following the rules of
fragmentation and reassembly properly there is no issue. We really
don't need to say anything here as this is part of standard attribute
parsing. No action proposed.Today when we create a tunnel we tunnel all the traffic through that tunnel.
There is no way to specify which flows should be tunneled and which flows should
not.
There is a need to support a method to select which flows to direct to a tunnel.
This concept is not new. Certain advanced VPN products allows us to select which
traffic should be routed to the VPN and which should not.
As well, in certain cases it maybe useful to have multiple tunnels. The tunnels
may have a different end points; or there maybe multiple tunnels but each tunnel
utilizes different technology. It maybe useful to direct certain flows to these
different tunnels.
We will describe a method for directing certain traffic flows to a tunnel; then
we will look at how to support multiple tunnels. We will also look at how to
apply this dynamcially.
This proposal will greatly clean up how hotlining is done and will be useful
beyond just hotlining.
NOTE: this discussion is for simple-ip not mobile-ip.
Tunneling specification for RADIUS is provided by RF2868.
We use NAS-Filter-Rule to specify what traffic to direct into the tunnel. The
syntax is as per NAS-Filter-Rule but with the following (mostly all the same):
action is tunnel (new)
Direction (in|out|inout) (inout is new)
Source and destination IP address (possibly masked)
Protocol
Source and destination port (lists or ranges)
TCP flags
IP fragment flag
IP options
ICMP types
Note direction: 'in' is from the terminal 'out' is to the terminal
As indicated, a couple of new things here, the rest is the same: New action
called 'tunnel' which can take a tunnel-id as a parameter when we have more then
one possible tunnels. We have added 'inout' to support bidirection to allow us
to specify whether the direction of the flows. This is an optimization -- if it
wasn't there you could use two rules, one with direction 'in' the other with
direction 'out'.
NOTE ON NOTATION
================
------> Flow in one direction
<-----> Flow in two directions
======> Flow in a tunnel in one direction
<=====> and in both direction
TEP Tunnel Endpoint
Directing flows to a single tunnel.
===================================
RADIUS server that wants all traffic that flows between the Mobile and
destination X will issue an Access-Accept that contains: The specification for
the tunnel using the attributes defined by RFC 2868 and an NAS-Filter-rule.
The NAS-Filter-rule will look like:
tunnel inout from assigned to 123.456.34.0
This will cause all traffic that flows between the the Mobile and the
destination (123.456..34.0) to be tunneled over the specified tunnel.
+-------+ +------+ +------+ +------+
| | | | |Tunnel| | |
|Mobile +<---------->+ NAS +<=======>+ End +<----->+Destin|
| | | | |Point | | |
+-------+ +------+ +------+ +------+
The direction attribute is important because it controls how information is
routed. The following will demonstrate how traffic is routed. In all these
diagrams time is increasing as we proceed down the page. As well, there is only
one tunnel.
When direction is out:
Mobile NAS TEP DESTINATION
| | | |
|---------->|========>|--------->|
| | | |
|<----------|<-------------------| (flows directly to NAS)
| | | |
The out bound traffic gets placed in the tunnel to the TEP and then the TEP
forwards the traffic to the Destination. The flow from the destination to the
mobile is routed directly to the mobile via the NAS. The NAS just passes it to
the mobile. The Home network would use this capability if it was only interested
in metering or seeing the outbound traffic from the Mobile.
When direction is in:
Mobile NAS TEP DESTINATION
| | | |
|---------->|------------------->| (flows directly to Destin)
| | | |
| +--|<-------------------| (flows directly to NAS)
| | | | |
| +--|========>|--+ |
| | | | |
|<----------|<========|--+ |
| | | |
| | | |
Outgoing traffic from the mobile gets to the NAS and is passed to the
Destination. Traffic from the destination gets to the NAS and the NAS redirects
the traffic to the tunnel to the TEP. The TEP then sends it back into the tunnel
to the NAS and the NAS forwards the traffic to the Mobile. The Home
When direction is inout:
Mobile NAS TEP DESTINATION
| | | |
|---------->|========>|--------->|
| | | |
| +--|<-------------------| (flows directly to NAS)
| | | | |
| +--|========>|--+ |
| | | | |
|<----------|<========|--+ |
| | | |
This combines the two diagrams together. Output from the Mobile reaches the NAS
and gets directed into the tunnel to the TEP. The TEP forwards the flow to the
Destination. When the Destination sends data to the Mobile it reaches the NAS,
the NAS redirects it to the TEP via the Tunnel. The TEP sends it back to the NAS
via the tunnel and the NAS forwards it to the Mobile.
Inout is useful when the home network wants to examine both incoming and
outgoing traffic.
Note that the above schemes flows the data through the TEP in stealth. That is,
neither the Mobile or the Destination know that the traffic has been redirected.
Also note that there maybe other scenarios as when the TEP acts like a NAT.
If the TEP is acting like a NAT, then we have:
Mobile NAS TEP/NAT DESTINATION
| | | |
|---------->|========>|--------->|
| | | |
|<----------|<========|<---------|
The mobile establishes a connection to the Destination but the TEP acting as
NAT, transforms the request source address (as NATs do) such that the
Destination sees the Source address of the incoming traffic from the Mobile as
TEP/NAT. Therefore any replies from the Destination are sent to the TEP/NAT.
Direction rule of 'in' is important. Direction set to 'out' won't work and
'inout' doesn't matter.
The TEP/NAT then forwards all traffic to the tunnel to the NAS. The NAS (as in
the cases above) always forwards any egressing traffic from the tunnel to the
Mobile.
Therefore, from the point of view of the NAS, it does not care whether the TEP
is transparent or has NAT like behavior, traffic egress a tunnel at the NAT gets
forwarded to the Mobile.
Multiple tunnels
================
As mentioned sometime we want to have different tunnels. The tunnels are either
terminating at different places or they use different technology and some flows
are more suited for some tunnels etc...
RFC 2868 allows for specifying more then one tunnel:
If the RADIUS server returns attributes describing multiple tunnels
then the tunnels SHOULD be interpreted by the tunnel initiator as
alternatives and the server SHOULD include an instance of the
Tunnel-Preference Attribute in the set of Attributes pertaining to
each alternative tunnel.
2868 allows us to specify multiple tunnels but only one tunnel is constructed.
We want a different behavior. That is, we want to have multiple of these tunnels
established.
A NAS filter rule that can identify a tunnel would allow us to bind NAS-Filter
rules to tunnels. For example:
tunnel 5 inout from assigned to 123.456.789.0
Means if the rule matches the flow direct that flow to tunnel 5.
RFC 2868 allows us to label tunnels in two ways. If more then one tunnel
specification is in an Access-Accept then each one needs to be tagged with an
id. There are two options for using assigning an id to a tunnel. One is to use
the Tunnel-Preference attribute the other is the Tunnel-Assignment-ID. Reusing
these will break could break functionality and therefore I propose that we
define a new attribute called tunnel-id.
Note that there is a third possibility and that is to use the TAG as an
identifier. The only problem with a TAG is that the TAG is only valid within an
Access-Accept. TAG value may be different in subsequent COA messages.
Backwards compatibility
=======================
How does a NAS know what to do? That is when it sees multiple tunnel
specification in an Access-Accept, what does it do? Does it instantiate one of
the tunnels as per 2868 or does establish multiple tunnels and bind the Filter
rules to them as per this RFC.
One way forward is that if there is at least one NAS-Filter-Rule with an
action of tunnel then all the tunnels are subject to having flow specifiers
(that is are to behave as per this RFC if it is supported).
Note that if we introduce a new attribute such as tunnel-id to the tunnel
specification then we can use that to tell the NAS that the tunnel specification
is a tunnel that interoperates with NAS Filter-Rules.
If we ever got into a situation where both Tunnel type are present, that is
Tunnels bound to NAS-FIlter rule and the 'old' tyle tunnel then, traffic that
matches the rule will be directed to a specified tunnel and all other traffic
will fall into the 'old' style tunnel. This works neatly.
Dynamic Behavior
================
Instructing the NAS to tunnel traffic dynamically is useful. As well to add a
flow to a tunnel or remove a flow from a tunnel dymanically is also useful.
The toughest challange is to install a redirection via tunneling to a flow that
already exists.
Say the Mobile is already established a tunnel to the a destination. We want to
install the tunnel such that the communication is not interrupted between the
Mobile and the destination. That scenario is the same as shown earlier (and
appears below)
Useing a fitler rule:
tunnel x inout from assigned to 123.456.34.0
Mobile NAS TEP DESTINATION
Before COA message: Mobile and Des communicate directly through the NAS
| | | |
|<--------->|<--------|--------->|
| | | |
After COA Message: Tne NAS passed information to the tunnel in both
directions.
x
|---------->|========>|--------->|
| | | |
| +--|<--------|----------|
| | | x | |
| +--|========>|--+ |
| | x | | |
|<----------|<========|--+ |
| | | |
Summary:
========
It is possible with slight modification to achieve redirection both statically
and dynamically using existing technology in the NAS.
This is useful not only for Hotlining but also for other purposes.
With respect to holtining , where we are only interested to know that the user
is invoking a particular service we would just use NAS-Filter-Rule with a action
= tunnel and direction out.
The only issue is that while we can remove the rules etc dynamically by sending
a flush there is no way to remove a tunnel that has been installed dynamically.
This is probably not a problem since once all the rules are removed nothing will
flow through that tunnel. However, it may be possible to state that once the
rules that redirect traffic to a tunnel are removed then the NAS may close the
tunnel.
Also note that this scheme can use L2 and L3 type packets.
Finally, this feature seems to interoperate with the old style tunnels as
defined by 2868.[Pasi Eronen]
Whatever we do, we should avoid having multiple descriptions that are in conflict with each other (currently we have two, and they don't completely match). ABNF is described in RFC 2234. > 4) Description of "ipno/bits" says "the IP number MUST NOT have > bits set beyond the mask", but the example given, "1.2.3.4/24", > does not follow this. Suggested change: use 192.0.2.0/24 as the > example. > > [pc] accept suggestion, maybe change the first 0 to something > else to further disambiguate. No, we should use 192.0.2.0/24 since it's the block reserved for documentation use (RFC 3330). > 8) The document allows an IP tunnel rule with direction "out", > but does not describe what such a rule means (the description > seems to apply only to rules with direction "in") > > [pc] Avi has written a great description of how the tunnel facility > works and how the directions apply. I've attached a version of this > document - perhaps Avi has something more recent? We probably want to > consider how parts of his document are incorporated into an annex or > some part of the document to make this clear. Thanks, this explained things (but something along those lines needs to be included in the document). > 10) The document should explain why different types of rules > must be given in exactly that order. Placing L2 rules before IP > is understandable, but for some of the other cases it's not > totally obvious why other orderings need to be forbidden. > > [pc] We had considerable discussion about this early on in the > document development. If my memory serves me correctly, we > decided upon this order to maximize interoperability and to > address the fact that it didn't make sense to filter out > packets before putting them into the tunnel. Perhaps others > can recall more detail - sorry. Well, I think it could make sense in theory (e.g., first filter out some bad traffic using "deny" rules, then put all the rest to a tunnel)... but I'm OK with leaving in these restrictions. > 13) If the NAS just concatenates all the NAS-Filter-Rule (or > QoS-Filter-Rule) attributes together to overcome the 255-byte > attribute length limit, then boundaries between individual > rules are lost. This is not necessarily a big problem, as it > looks like the syntax can be unambiguously parsed anyway, but > should be mentioned explicitly (alternatively, we could delimit > the individual rules somehow). > > [pc] yes, this should not be a problem and implementations will > split the string in different ways, but if they are following > the rules of fragmentation and reassembly properly there is no > issue. We really don't need to say anything here as this is > part of standard attribute parsing. No action proposed. There would be an issue if the grammar allowed ambiguous parsings. For instance, if we had ICMP types "no" and "notunnel" (which we don't), the following string could be parsed in two different ways (where exactly does the first rule end and second rule start?) "deny in 1 from assigned to any icmptypes source quench,notunnel permit in ip from assigned to any" I don't think we have any such cases currently (running the grammar through some kind of parser generator tool might verify this...), but it means that extending the syntax later has to be done with great care. It also means that saying "A NAS that is unable to interpret or apply a deny rule MUST terminate the session" is probably a bad idea, since it seems to imply that ignoring a "permit" rule the NAS cannot interpret is allowed... but if the NAS cannot interpret the rule, it cannot really know where one rule ends and the next rule starts.
[Paul Congdon]
Since these rules govern access policies, it is believed that a strong hammer is better than simply ignoring things that aren't understood or implemented. These should apply equally for permit rules or deny rules. If the NAS can't interpret the rule, it can't enforce the desired policy either and still MUST terminate the session, so if it gets lost parsing things, this rule should also apply.
[Pasi Eronen] I agree
[Paul Congdon] I agree that we need to make sure parsing is unambiguous. I suppose we need a line feed at the end of each rule and perhaps this needs to be escaped as well for the tunnel-assignment-ID issue. [Pasi Eronen]
Yes, I also think that having an unambiguous "rule end" (or "rule separator") character (LF, NUL, or something) would simplify the parsing... It would be even nicer if the escape mechanism for tunnel-assignment-ID would "hide" these characters somehow. Perhaps we should use "percent-hex-hex" escaping like URIs? (e.g. NUL would turn to "%00", not backslash+NUL).
[Mauricio]
This is a recap of status for Issue 102 (raised by Pasi Eronen), which consists of a number of sub-issues. We believe all issues have acceptable action recommendations and unless we hear otherwise, the action noted will be taken. 102-1 Description: Section 3.5 is currently quite difficult to follow since it mixes L2, IP, tunneling and HTTP redirect rules... It's not always even clear when some element is just a name for a rule (like "ipno") and when it's a literal string (like "from"). So some editing work is needed here. Maybe describing the L2, IP filtering, IP tunneling and HTTP rules one-by-one(instead of mixing their descriptions) would make this moreunderstandable. (The IPFilterRule description in RFC3588 isn't nearly ascomplicated as this, since it doesn't have the L2, tunneling or HTTP rules.) Discussion: 9/23 - Paul Congdon suggests that this issue be solved through description of nas-filter-rule using ABNF. No additional discussion generated on this sub-issue. Action: Replace current 'nas-filter-rule' description that uses non-standard syntax language to use ABNF. --------------------------------------------------- 102-2 Description: Use ABNF to describe 'nas-filter-rule' Discussion: 9/23 - Paul accepts Posi's suggestion to use ABNF and questions whether it should replace existing non-standard syntax description or appended to it. 9/26 - Posi says that regardless of the way, multiple syntax descriptions should not be in conflict. No additional discussion. Action: Replace current 'nas-filter-rule' description that uses non-standard syntax language to use ABNF. --------------------------------------------------- 102-3 Description: Example of "macaddr/mask": The example should use some other width than /24 to make it clearer how the counting works. Also, the example given is an invalid one, since it does not meet the "The MAC address MUST NOT have bits set beyond the mask" requirement. Suggested change: use 00-10-A4-23-00-00/32 as the example. Discussion: 9/23 - Paul accepts suggestion to change example. Action: Change example to use 00-10-A4-23-00-00/32 --------------------------------------------------- 102-4 Description: Description of "ipno/bits" says "the IP number MUST NOT have bits set beyond the mask", but the example given, "1.2.3.4/24", does not follow this. Suggested change: use 192.0.2.0/24 as the example. Discussion: 9/23 - Paul accepts suggestion to change example. Also suggests a different addres example. 9/26 - Pasi asserts RFC3330 mandates given address example. Action: Change example to use 192.0.2.0/24 . --------------------------------------------------- 102-5 Description: Description of tunnel_id: according to RFC 2868, there are no restrictions on the format of the Tunnel-Assignment-ID. Currently it's not clear if the NAS-Filter-Rule syntax supports correctly parsing arbitrary IDs (what happens if the ID includes spaces, for instance?) Discussion: 9/23 - Paul suggests use of escaping function, since there are no restrictions on the format of the string used in Tunnel-Assignment-ID we MUST provide a way to parse it as a single element in the entire attribute string. Of course, the Tunnel-Assignment-ID could itself contain quotes, so we will also need to describe some escaping function before including them in the rule. The escaping function would be: For all occurrence of " replace with \" and for all occurrence of \ replace with \\. Action: Modify paragraph describing role of 'tunnel-id' parameter for nas-filter-rule as follows: "A tunnel id. When the 'tunnel' rule matches, traffic is redirected over the tunnel with the specified tunnel_id. Traffic can only be redirected to or from named tunnels that have been established per [RFC2868] and named using the Tunnel-Assignment-ID attribute described therein. The tunnel id MUST be encapsulated in double quotes and use the following escape functions in case the tunnel id itself contains any quotes: For all occurances of " replace with \" For all occurances of \ replace with \\ Example: A tunnel with the name of tunnel "ppp1" would be specified as "tunnel /"pp1/"" within the rule." ------------------------------------------------------ 102-6 Description: Near the end of Section 3.5: The "concise syntax statements" don't exactly match the definitions earlier. I catched at least these: - IP rule is missing "[ports]" before "to" - IP rule is missing "|" after "redirect" - HTTP redirect rule is missing the "proto" part after the direction - HTTP redirect rule does not have "[ports]" Discussion: 9/23 - Paul accepts change Action: Per sub-issue 102-2 the description of nas-filter-rule will be using ABNF. The need for concise syntax statements no longer exists and will be removed from document. ------------------------------------------------------ 102-7 Description: The document does not seem to describe what HTTP filter rules are or how they work (HTTP redirect rules are explained, but not HTTP filter rules). Discussion: 9/23 - Paul agrees better description necessary. 12/2 - Mauricio responds with new text proposal to list. Action: Replace existing HTTP filter description with new text proposed on 12/2. ------------------------------------------------------ 102-8 Description: The document allows an IP tunnel rule with direction "out", but does not describe what such a rule means (the description seems to apply only to rules with direction "in") Discussion: 9/23 - Paul posted Avi's tunneling document 9/26 - Posi found the document useful 11/18 - Mauricio asked Posi for guidance on what to add to the document from Avi's document. 11/22 - Posi suggest inclusion of a portion of Avi's tunneling document as an Appendix to draft 12/13 - Paul posts to radext email list new proposed text for appendix A. Action: Add Paul's suggested text from 12/13 to appendix A. ------------------------------------------------------ 102-9 Description: Currently the text says "A flush rule MUST appear before all other rule types." I first read this to mean that a flush rule must always be present, but I guess that was not what was meant. Furthermore, it's not easy to parse the ordering requirements. Rewrite that paragraph to "Furthermore, if the list contains different types of rules, they MUST appear in the following order: flush rules, base encapsulation filter rules, IP tunnel rules, HTTP redirect rules, IP filter rules, and HTTP filter rules." Discussion: 9/23 - Paul accepts change. Action: Replace paragraph in question with Pasi's suggested text. ------------------------------------------------------ 102-10 Description: The document should explain why different types of rules must be given in exactly that order. Placing L2 rules before IP is understandable, but for some of the other cases it's not totally obvious why other orderings need to be forbidden. Discussion: 9/23 - Paul asserts proposed ordering rules are to maxium interoperability 9/26 - Pasi accepts Action: None ------------------------------------------------------ 102-11 Description: The document should have some examples of NAS filter rules, preferably showing most of the different features at least once. Discussion: 9/23 - Paul accepts Pasi's recommendation. Action: Add several example of NAS filter rules per Pasi's recommendation. ------------------------------------------------------ 102-12 Description: The document should somewhere describe the differences to Diameter's NAS-Filter-Rule syntax. Discussion: 9/23 - Paul accepts Pasi's recommendation Action: Add paragraph to description section detailing differences to Diameter's NAS-Filter-Rule ------------------------------------------------------ 102-13 Description: If the NAS just concatenates all the NAS-Filter-Rule (or QoS-Filter-Rule) attributes together to overcome the 255-byte attribute length limit, then boundaries between individual rules are lost. Parsing may be ambiguous. Discussion: 9/23 - Paul asserts that this should not be a problem. No action proposed. 9/26 - Pasi states that dependancies exist on grammer to be parsable in non-ambigous manner. Current grammer seems to have no opportunities for ambiguity. 9/26 - Paul agrees it would be nice to have a rule delimeter 9/26 - Pasi agrees with Paul. Pasi goes on to suggest usage of a rule delimeter field. Action: Add rule delimeter to filter syntax.
Proposed Resolution: Accept
Issue 103: Multi-Address NASes Submitter name: David Nelson Submitter email address: dnelson@enterasys.com Date first submitted: July 20, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00548.html Document: FIXES-00 Comment type: T Priority: 1 Section: Various Rationale/Explanation of issue:
A sub-portion of the Issue 87 discussion is being filed as a new and separate Issue. The relevant portion of that discussion, contributed by Bernard Aboba, follows. "However, this does bring up another issue, which is how the RADIUS server identifies the NAS if it is more than one hop away. NASes can have more than one IPv6 address and this makes it possible for a NAS to put a linkscope address in the NAS-IPv6-Address field. If the proxy is on the same link as the RADIUS client, the RADIUS server could receive a packet with a NAS-IPv6-Address as a linklocal address. The same issue can occur with IPv4 Link Local, and of course a NAS can have more than one IPv4 and IPv6 address. One potential suggestion might be to use the NAS-Identifier attribute in such a situation so as to avoid having to configure the RADIUS server with all potential NAS addresses."
Requested change: Proposed changes to the document. "One potential suggestion might be to use the NAS-Identifier attribute in such a situation so as to avoid having to configure the RADIUS server with all potential NAS addresses." "There are a number of situations in which a NAS may have multiple IP addresses. IPv4/IPv6 dual stack operation is one example, but it is also possible for a NAS to have multiple IPv6 or IPv4 addresses. A NAS that is a member of multiple VLANs would have an IPv4 address for each VLAN. A NAS also can have multiple IPv6 or IPv4 addresses on a single interface. [RFC2865] Section 5.44 states that only a single NAS-IP-Address attribute may be included in an Access-Request, and that it may not be included in other messages (Challenge, Reject, Accept). Similarly, [RFC3162] Section 3 provides the same restrictions for NAS-IPv6-Address. Since RADIUS only looks at the packet source address to determine the appropriate shared secret, if a NAS sends packets from different source addresses, then the RADIUS server needs to have a shared secret for each address. My recommendation is that RADIUS clients with multiple addresses SHOULD use the NAS-Identifier attribute instead of NAS-IPv4-Address or NAS-IPv6-Address."
Proposed Resolution: Discuss
Issue 104: Mismatch in Digest-Domain Submitter name: Hideo Morishita Submitter email address: manmos@stellar@co.jp Date first submitted: July 22, 2005 Reference: Document: DIGEST-03 Comment type: E Priority: S Section: 3.17, 5 Rationale/Explanation of issue:
3.17 Digest-Domain attribute Description . . . protection space (see [RFC2617], section 3.2.1). RADIUS servers MAY send one or more attributes of this type in Access- ^^^^^^^^^^^ Challenge messages. This attribute MUST only be used in Access-Challenge messages. but 5. Table of Attributes +-------------------------+-----+-----+--------+--------+-----------+ | Attribute | # | Req | Accept | Reject | Challenge | +-------------------------+-----+-----+--------+--------+-----------+ . . . | Digest-Domain | TBD | 0 | 0 | 0 | 0-1 |
Proposed Resolution: Accept
Issue 105: IANA Registration Submitter name: Dan Romascanu Submitter email address: dromasca@avaya.com Date first submitted: July 28, 2005 Reference: Document: RFC3576MIBs-01 Comment type: T Priority: S Section: Various Rationale/Explanation of issue:
Both draft-ietf-radext-dynauth-client-mib-01.txt and
draft-ietf-radext-dynauth-server-mib-01.txt define
radiusDynamicAuthorization as
radiusDynamicAuthorization OBJECT IDENTIFIER ::= { mib-2 xxx }
And then define the respective MODULE-IDENTITY under
radiusDynamicAuthorization.
Defining the same node in two separate documents seems odd, although it
is IANA who is in charge with the xxx allocation. Also, this results in
smilint protesting with a level 4 warning:
Warning: module-identity-registration (level 4)
Message: uncontrolled MODULE-IDENTITY registration
Description: The identities of IETF MIB modules should be registered
below
mib-2, transmission, or snmpModules so that the
registration space can be controlled by IANA.
I wonder what are the good reasons to break this 'should'
recommendation. Proposed Resolution: Discuss
Issue 106: Vendor Specific Values Submitter name: Dave Nelson Submitter email address: dnelson@enterasys.com Date first submitted: July 26, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00582.html Document: RADIUS Design Guidelines Comment type: 'T'echnical Priority: '1' Should fix Section: (new) Rationale/Explanation of issue: In addition to the well-documented Vendor Specific Attributes (VSA), implementation practice has extended to Vendor Specific Values (VSV) of IETF Standard RADIUS Attributes. A snippet from a RADEXT list thread: See: http://www.freeradius.org/cgi-bin/cvsweb.cgi/radiusd/share/dictionary.bay?rev=1.5&content-type=text/x-cvsweb-markup Look for "Service-Type". Vendor-specific values are of the form ((vendor-id << 16) | num), One of the RFC's refers to this practice, but I can't recall which right now. Requested change: Describe the practice. Include recommendations for or against the practice, and standardize the recommend method of encoding, if the practice is encouraged.
[Alan DeKok]
After a bit of searching, RFC 2882, section 2.2.1 documents this.
I would recommend using the practice, and documenting the encoding
as defined above.
Proposed text:
In addition to Vendor-Specific Attributes (VSA's), it is useful for
vendors to define custom values for previously defined attributes.
These values may be called Vendor-Specific Values (VSV's). This
practice is encouraged, as it avoids overloading of existing values.
Given a choice between re-using an existing value in a context where
it may not be directly applicable, or defining a VSV, vendors SHOULD
define a new VSV.
A summary of the Vendor-Specific Value format is shown below. The
fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id | Vendor-Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id
2 octets of the SMI Network Management Private Enterprise Code
of the Vendor in network byte order, as defined in the "Assigned
Numbers" RFC [6].
Vendor-Value
2 octets defining the vendor-specific value.
VSV's MUST be defined only for attributes of type "integer", and
then only where the existing standards define one or more values for
the attribute.
Note that the Vendor-Id is defined here as a 16-bit number, where it
is defined as a 32-bit number in the Vendor-Specific attribute. This
choice may not be the best one, and is driven by the limitations of
the 32-bit integer field.> These values may be called Vendor-Specific Values (VSV's). 2882 uses Vendor-Specific Enumerations (VSE's). We should use that here.
[David Nelson]
RFC 2882 is certainly a fact-based document. It reports existing deployment behaviors. Its abstract reads: Abstract This document describes current practices implemented in NAS products that go beyond the scope of the RADIUS RFCs 2138, 2139 [1,2]. The purpose of this effort is to give examples that show the need for addressing and standardizing these types of ad-hoc functions. Since many of these features require a matching server support component, the ability to deploy and manage interoperable NAS and AAA server products is severely hindered. These practices are documented here to show functions that are obviously desired in developing future AAA protocols for NAS deployment. IMHO, we should be careful about inferring any desired or implied level of standardization of any of the practices reported in 2882. If there is no good reason to the contrary, then following existing convention may be a good thing. OTOH, the fact that one or more vendors chose to implement a needed (or desired) function in a particular fashion should not set a binding precedent on the RADEXT WG. These extensions, in all likelihood, received no IETF review, or even third party review, prior to their implementation and deployment. We should look at these "ad hoc" extensions with a critical eye.
[Alan DeKok]
Absolutely. I have no objections to the use of VSE's, but I do have conditions on their use. Use and design of VSE's SHOULD follow from a standards process. Otherwise, existing standards are re-used in situations where they may not be appropriate. I view VSE's as a minor shortcoming in the original RADIUS spec. We have VSA's, so it isn't a large leap to standardize *some* form of VSE's.
[Bernard Aboba]
I think there is a basic issue with tackling this in the Issues & Fixes document. Self-allocation of VSVs is a revision of RFC 3575 (RADIUS IANA Allocations Policy) and therefore would need to be a standards track document, which the Issues & Fixes document is not. RFC 3575 defines that attribute values can be allocated via designated expert, with the exception of Service-Type, which requires IETF Consensus. All allocations require a specification. The allocation of Service-Type values was tightened because when it was FCFS it had been used (by IEEE 802.11F) to define new RADIUS commands outside the IETF process.
Proposed Resolution: Discuss
Issue 107: Interim Accounting Interval Submitter name: Saikrishnan Submitter email address: saig@cisco.com Date first submitted: July 14, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00528.html Document: FIXES-00 Comment type: 'T'echnical Priority: '1' Should fix Section: (new) Rationale/Explanation of issue:
In section 2.1 of RFC 2869, it is mentioned that the interim-accounting-interval coming from the RADIUS server is superceded by the local config on the NAS. Pl. find below the snippet. ----- 2.1. RADIUS support for Interim Accounting Updates When a user is authenticated, a RADIUS server issues an Access-Accept in response to a successful Access-Request. If the server wishes to receive interim accounting messages for the given user it must include the Acct-Interim-Interval RADIUS attribute in the message, which indicates the interval in seconds between interim messages. It is also possible to statically configure an interim value on the NAS itself. Note that a locally configured value on the NAS MUST override the value found in an Access-Accept. ---- But in terms of priority it makes more sense for the finer granularity config overriding the global config. For instance, if you want to apply an umbrella policy that all the sessions are done periodic accounting every 30 mins but for Jane's session, we need to do periodic accounting every 45 mins, the only way for provisioning this is by adding 45' to Jane's user profile. But the RFC MUSTs it out. I am copying the authors for clarification. Please note that in all the other attributes in Cisco IOS, the PER-USER attribute (the attribute defined in the user profile) overrides what is configured globally on the box. At minimum, this should be left for implementation. Pl. let me know if I am missing something.
[Bernard Aboba]
The Interim Accounting Interval is often set in order to ensure against loss of income by billing systems. So I can understand why there is concern if an Interim-Accounting-Interval attribute sent by a RADIUS server would be ignored by the NAS. Although I do not recall the conversations that lead to this paragraph being inserted, I think the concern may relate to inappropriately small values being sent by a RADIUS server. For example, if the implementation has a setting for "minimum Interim-Accounting-Interval" then I would say that this should not be overridden by a smaller value, but could be overridden by a larger one. However, if the nature of the implementation setting is "use value X by default, but allow the RADIUS server to override it" I don't understand why that should be prohibited.
[Barney Wolff]
I think the issue is whose policy shall apply, when the RADIUS server and NAS are under different administrative control. Setting the value in the NAS is the equivalent of overriding whatever value is set by the server in the proxy that (presumably) should exist between the NAS and the server in this case. > However, if the nature of the implementation setting is "use value X by > default, but allow the RADIUS server to override it" I don't understand > why that should be prohibited. One can always speculate on why values would be configured directly in the NAS if the proxy is under the same administration. Perhaps the thinking was that some NASes may be intelligent enough to pick the right server based on NAI or other info without an intervening proxy. In that case configuration of values on the NAS is the equivalent of doing so in a virtual proxy, and, since a proxy can always override attribute values, the NAS settings win. A definite choice, even if "wrong", is probably better than uncertainty in cases like this.
[Murtaza Chiba]
That's an interesting point. In wholesale environments sometimes the wholesaler wants to control specific config bits such as compression, for instance. For compression it would be undesirable for a retailer to turn it on for users as it significantly degrades the performance and hence would affect subscribers for other retailers as well. In this case too a smaller interim value would presumably chew up more resources, so I agree with Bernard that retailers should be able to change the interval time on a per user basis as long as they are not increasing the frequency of updates beyond a configured threshold.
[Nagi Reddy Jonnala]
This is really a valid question that one comes across many times and I also support Bernard's view point here. I would like to add the below as well. RFC-2869 text: "It is also possible to statically configure an interim value on the NAS itself. Note that a locally configured value on the NAS MUST override the value found in an Access-Accept. This scheme does not break backward interoperability since a RADIUS server not supporting this extension will simply not add the new Attribute. NASes not supporting this extension will ignore the Attribute." I'm not sure if the wording "NAS MUST override the value found in Access-Accept" exists in the view of not to break backward Compatibility. I don't think there would be any backward compatibility issues if the NAS honors the Radius server interim interval request (assuming that it can honor based on some locally configured value like minimum Interim interval). IMO, it is worth documenting it somewhere.
[Alan DeKok]
The following is proposed text to resolve ISSUE 107. If there are no
comments, the text will be included in the next revision of the document.
---
S.s.s. Interim-Accounting-Interval
[RFC2869] Section 2.1 states:
It is also possible to statically configure an interim value on
the NAS itself. Note that a locally configured value on the NAS
MUST override the value found in an Access-Accept.
This requirement may be phrased too strongly. It is conceivable that
a NAS implementation has a setting for a "minimum" value of Interim-
Accounting-Interval, based on resource constraints in the NAS, and
network loading in the local environment of the NAS. In such cases,
the value administratively provisioned in the NAS should not be over-
ridden by a smaller value from an Access-Accept massage. The NAS's
value could be over-ridden by a larger one, however. The intent is
that the NAS sends accounting information at fixed intervals, short
enough such that the potential loss of billable revenue is limited,
but also that the accounting updates are infrequent enough such that
the NAS is not overloaded.
[Bernard Aboba]
I think this resolution is generally OK. Change "massage" to "message".Also change "NAS is not overloaded" to "NAS, network and RADIUS server are not overloaded".
[Alan DeKok] I have no objection to those comments.
Proposed Resolution: Accept
Issue 108: redir_cnt not included as a method of redirection removal Submitter name: Paul Congdon Submitter email address: paul.congdon@hp.com Date first submitted: August 10, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00625.html Document: IEEE802-00 Comment type: T Priority: S Section: A.2.e, pg. 27, last paragraph Rationale/Explanation of issue:
This section talks about how the redirection process can be disabled. Since we added the redir_cnt parameter to the rule we should include it as a mechanism for disabling redirection. Also it isn't clear if a new session is created when the redir_cnt value becomes zero. If a new session is created, then the accounting records should also be sent. I will propose that we insert a paragraph before the last paragraph in this clause so the accounting scheme will remain intact.
Requested change:
Insert a paragraph before the last paragraph that describes the redir_cnt scheme. Suggest something like the following words: "When HTTP redirection is established via a NAS-Filter-Rule (TBD) it also possible to have HTTP redirection automatically removed by including a redir_cnt parameter along with the rule. The rule will be removed from the active rule set when the rule matches redir_cnt number of times. When the rule is removed, HTTP redirection will also be removed."
Proposed Resolution: Discuss
Issue 109: HTTP NAS-Filter-Rules Always Assume Port 80
Submitter name: Paul Congdon
Submitter email address: paul.congdon@hp.com
Date first submitted: 08-10-2005
Reference: http://ops.ietf.org/lists/radiusext/2005/msg00626.html
Document: IEEE802-00
Comment type: T
Priority: S
Section: 3.5
Rationale/Explanation of issue:
There appears to be no way to augment the HTTP rules with a port number
if we want to attempt to match HTTP traffic on something other than port
80. This is likely useful in enterprise environments where proxies may
be used and browsers are configured to use something other than port 80.
Seems like we should add the ports options seen in the IP filter to the
HTTP rule.
Requested change:
Add the {port/port-port}[,ports[,...]] option that appears in the IP
rule to the HTTP rule as well.Proposed Resolution: Discuss
Issue 110: Compliance and Coherence Submitter name: Greg Weber Submitter email address: gdweber@cisco.com Date first submitted: August 10, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00636.html Document: IEEE802-00 Comment type: T Priority: S Section: 1.2, 3.5 Rationale/Explanation of issue: 1) Compliance vs. Functional Coherence
Most of the RADIUS RFCs tend to address a single functional area, e.g. IPv6 attributes, EAP, tunneling, etc. This is good because RFCs tend to become checkmarks on RFPs or customer requirements. This documents seems to combine functionality that is only related to IEEE 802 (VLANs) and things that are independent of access type. For example, filtering and redirection can apply equally usefully to PPP-based L2 connections. If I'm a vendor of PPPoA-based DSL termination NASes, I can't claim compliance to this potential RFC unless I support all the VLAN oriented attributes because the compliance language in section 1.2 requires an all or nothing approach to compliance. Can the authors clarify why the NAS-Filter-Rule/QoS-Filter-Rule attributes are combined with the 802 specific attributes?
I would think these should be addressed via separate documents. 2) Compliance vs. Optional Functionality I did not understand how the "options" in section 3.5 relate to the compliance language in section 1.2. If I do not support the "Cnt" option for counting rule hits, can I still claim compliance with this document? Are these optionally specified or optionally supported?
[Paul Congdon]
Greg has made the following comment on the 802 attributes draft: >1) Compliance vs. Functional Coherence >Most of the RADIUS RFCs tend to address a single functional area, e.g. >IPv6 attributes, EAP, tunneling, etc. This is good because RFCs tend >to become checkmarks on RFPs or customer requirements. This documents >seems to combine functionality that is only related to IEEE 802 (VLANs) >and things that are independent of access type. For example, filtering >and redirection can apply equally usefully to PPP-based L2 connections. >If I'm a vendor of PPPoA-based DSL termination NASes, I can't claim >compliance to this potential RFC unless I support all the VLAN oriented >attributes because the compliance language in section 1.2 requires an >all or nothing approach to compliance. Can the authors clarify why the >NAS-Filter-Rule/QoS-Filter-Rule attributes are combined with the 802 >specific attributes? > >I would think these should be addressed via separate documents. Throughout the history of this document we have included, excluded, added and removed various attributes to get the scope of the document just right. We have been balancing the tradeoff of getting a reasonable focused set of attributes in a single document without creating a slew of attribute documents to run through the process. Also, we are addressing the needs and requests of other SDOs for completing the work on this set of attributes in a timely manner. I believe we can (and perhaps have) address the issue of compliance to the spec by indicating in the front matter how NAS devices that do not support media that provides the functionality controlled by the attributes in the spec are supposed to behave. We already have statements in the spec (section 2.2) that say if you can't support the functionality requested by the attributes you MUST treat an Access-Accept as an Reject. This should be sufficient to allow non VLAN devices to use this spec and still create an environment with predictable behavior.
Proposed Resolution: Discuss
Issue 111: Accounting Submitter name: Greg Weber Submitter email address: gdweber@cisco.com Date first submitted: August 10, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00636.html Document: IEEE802-00 Comment type: T Priority: S Section: A.3 Rationale/Explanation of issue:
The accounting requirements do not seem to be fully treated by the draft. Section A.3 has a MUST requirement related to accounting. I would think that MUST requirements should be treated by the text, not in an appendix. Why does redirection require a STOP/START pair? Can't this information be conveyed via an INTERIM record for the same session? If the Service- Type is not changing, I'd think that an INTERIM would suffice.
[Paul Congdon]
At IETF-64 we reviewed this issue. There did not seem to be any objection to having compliance statements in the Annex given that this Annex is where the context for the statements is developed. Also, since a new session is created, as stated in the draft, there is no need to use INTERM messages.
Proposed Resolution: Discuss
Issue 112: NAS-Filter-Rule Confusion Submitter name: Greg Weber Submitter email address: gdweber@cisco.com Date first submitted: August 10, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00636.html Document: IEEE802-00 Comment type: T Priority: S Section: 3.5 Rationale/Explanation of issue:
I could not understand some parts of the specification; I guess Pasi has already commented on this. In particular, the proto spec: proto <l2:<ether2[:val]|rmon_str>> type[:val]|ipprot|ip|http> there are not an equal number of "<" and ">" and the "type[:val]" part is not described. The "ipprot" does not provide for a value part.
Proposed Resolution: Discuss
Issue 113: Attribute Concatenation Submitter name: Greg Weber Submitter email address: gdweber@cisco.com Date first submitted: August 10, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00636.html Document: IEEE802-00 Comment type: T Priority: S Section: 3.6 Rationale/Explanation of issue:
I didn't understand how the language in section 3.6 about concatenating QoS-Filter-Rule(s) works. If these are simply concatenated, how does an implementation distinguish between multiple 'small' QoS-Filter-Rules and a single larger attribute? What if I want to send one QoS-Filter-Rule which spans 253, followed by one which does not?
[Paul Congdon]
Responding to Greg's issue 113... >I didn't understand how the language in section 3.6 about concatenating >QoS-Filter-Rule(s) works. If these are simply concatenated, how does >an implementation distinguish between multiple 'small' QoS-Filter-Rules >and a single larger attribute? What if I want to send one >QoS-Filter-Rule which spans 253, followed by one which does not? Actually I believe the editorial note needs to be removed since there is text just after the note that explains the problem. As you know, Diameter attributes may be larger than what will fit in the Radius attribute so we need to support fragmentation and reassembly in the general sense. The assumption with concatenation is that you are building a 'list' of QoS-Filter-Rules, just like you are building a 'list' of NAS-Filter-Rules. So, as the text states, if there are multiple QoS-Filter-Rules, you simply concatenate them together (whether they are multiple little rules or one large split rule) and treat them as a 'list' The proposed resolution to this comment is to remove the editorial note. If this is not acceptable, please propose some new text in this section which helps clarify things for you - provided I've made that clear.
[Glen Zorn] Actually, Diameter AVPs can be larger than a RADIUS _message_. If you really want to support fragmentation and reassembly in the general sense, then you need to deal with that, too.
[Paul Congdon]
I probably should have been more clear about using the words 'general sense'. All we are talking about is the string in the Qos-Filter-Rule that might be too large to fit in the current Radius version of the attribute. I am under the assumption that handling this type of scenario is common practice in Radius/Diameter proxies and that is has been documented in a previous RFC, but perhaps I'm wrong on this.
[Glen Zorn]
OK, I'm a bit confused here: is this Qos-Filter-Rule generated by a RADIUS server, a Diameter peer or either?
[Paul Congdon]
It is generated by a RADIUS server and is a RADIUS attribute. We are simply leveraging the format and syntax of the rule string.
[Paul Congdon]
I still think the existing text explains the issue and solution fairly
clearly:
The Text field contains a QoS filter, utilizing the syntax
defined for the QoSFilterRule derived data type defined in
[RFC3588], Section 4.3. Note that this definition contained an
error, so that the complete syntax is described in the
definition of the QoS-Filter-Rule AVP, defined in [NASREQ].
The RADIUS server can return multiple QoS-Filter-Rule
attributes in an Access-Accept or CoA-Request packet. Where
more than one QoS-Filter-Rule Rule attribute is included, it is
assumed that the attributes are to be concatenated to form a
single QOS filter.
Whereas the maximum allowable message size in [NASREQ] is
greater than RADIUS' maximum allowable message size, it is
assumed that QOS filters that exceed RADIUS' allowable message
size will be broken into multiple QoS-Filter-Rule attributes by
the RADIUS server and concatenated back into a single QOS
filter by the NAS.
As per the requirements of RFC 2865, Section 2.3, if multiple
QoS-Filter-Rule attributes are contained within an Access-
Request or Access-Accept packet, they MUST be maintained in
order. The attributes MUST be consecutive attributes in the
packet. RADIUS proxies MUST NOT reorder QoS-Filter-Rule
attributes. [Glen Zorn]
But this makes no sense to me at all. Do you mean "Whereas the maximum allowable AVP size in [NASREQ] is greater than RADIUS' maximum allowable attribute size, it is assumed that QOS filters that exceed RADIUS' allowable attribute size will be broken into multiple QoS-Filter-Rule attributes by the RADIUS server and concatenated back into a single QOS filter by the NAS"?
[Paul Congdon]
Yes. We can use this text as a replacement if you agree with this.
Taking Glen's suggested text, I'd like to close this issue out with the
following proposed text for the Text field in section 3.6. Please let
me know if this will work.
Text
The Text field contains a QoS filter, utilizing the syntax
defined for the QoSFilterRule derived data type defined in
[RFC3588], Section 4.3. Note that this definition contained
an error, so that the complete syntax is described in the
definition of the QoS-Filter-Rule AVP, defined in [NASREQ].
The RADIUS server can return multiple QoS-Filter-Rule
attributes in an Access-Accept or CoA-Request packet. Where
more than one QoS-Filter-Rule Rule attribute is included, it
is assumed that the attributes are to be concatenated to form
a single QOS filter.
Whereas the maximum allowable AVP size in [NASREQ] is greater
than RADIUS' maximum allowable attribute size, it is assumed
that QOS filters that exceed RADIUS' allowable attribute size
will be broken into multiple QoS-Filter-Rule attributes by
the RADIUS server and concatenated back into a single QOS
filter by the NAS.
As per the requirements of RFC 2865, Section 2.3, if multiple
QoS-Filter-Rule attributes are contained within an Access-
Request or Access-Accept packet, they MUST be maintained in
order. The attributes MUST be consecutive attributes in the
packet. RADIUS proxies MUST NOT reorder QoS-Filter-Rule
attributes. [Emile Bergen]
I think the relevant section of RFC 2865 is Section 5, and it states: If multiple Attributes with the same Type are present, the order of Attributes with the same Type MUST be preserved by any proxies. The order of Attributes of different Types is not required to be preserved. A RADIUS server or client MUST NOT have any dependencies on the order of attributes of different types. A RADIUS server or client MUST NOT require attributes of the same type to be contiguous. So I see two issues. 1: the conflict between the "consecutive attributes" requirement and the last sentence of the text quoted above, and 2. it would probably be clearer if the reference pointed to Section 5 (Attributes) instead of section 2.3 (Proxy behaviour).
[Glen Zorn]
Are you _sure_ that you want to use this {QoS-Filter-Rule} syntax? It's awfully verbose.
Even if you really do want to use it, I would suggest that you reproduce it
(or rather, adapt it to use w/RADIUS) in this document, rather than incorporating
it by reference. There are several problems with the Diameter definitions,
not least of which is that the definition of the QoS-Filter-Rule AVP depends
upon the definition of IPFilterRule which is derived from OctetString which
doesn't exist in RADIUS.
I still am puzzled by the reference to Diameter. As I mentioned earlier, it
is not possible to fit a maximum sized QOS-Filter-Rule AVP into a single
RADIUS message, never mind a set of RADIUS attributes. So why even talk
about it? I also think that it would be a very good idea to specify a maximum
length for QOS filter rules themselves. Also, if a filter is made up of filter
rules, it makes sense that rules can be concatenated to form a filter; however,
the paragraph above offers no guidance the case where a rule doesn't fit into a
QoS-Filter-Rule attribute.[Paul Congdon]
Yes, what is important is that the order is maintained, not that the
attributes are consecutive. Since this sentence is in direct conflict
with 2865, we need to remove it. Also I agree that Section 5 appears to
be the better reference. The last paragraph should read:
As per the requirements of RFC 2865, Section 5, if multiple
QoS-Filter-Rule attributes are contained within an Access-
Request or Access-Accept packet, they MUST be maintained in
order. RADIUS proxies MUST NOT reorder QoS-Filter-Rule
attributes.
I'm still working on a response to the rest of Glen's comments...[Bernard Aboba] Since QoS-Filter-Rule has been removed, this issue is closed.
Proposed Resolution: Accept
Issue 114: WGLC Review Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: August 10, 2005 Reference: Document: IEEE802-00 Comment type: T Priority: S Section: Various Rationale/Explanation of issue:
Accounting I do not understand the purpose of the accounting functionality in the draft. The focus of this document is VLAN attribute, priority and filtering. How does Acct-EAP-Auth-Method fit into that? I think this is a leftover WLAN attribute which should be removed. Acct-NAS-Filter-Rule attribute. The purpose of this attribute is to keep count of hits on filter rules. This duplicates functionality under development in other WGs such as IPFIX, and so I'd question whether this is appropriate functionality for RADIUS accounting. Overview I do not understand the purpose of Section 2, Overview. Most of it seems like it could be deleted without losing anything. " As described in the Introduction section, it may be desirable to a control user's access to network resources (e.g. the Internet) with greater standardized explicitness than what current RADIUS attributes provide. In this section we will examine these requirements in more detail. " What is "standardized explicitness?" The filtering functionality defined in this document is no more granular than what is already supported in the Filter-ID attribute. So this sentence seems inaccurate. " Besides IEEE 802.1X networks, there is a corollary need within Internet Service Provider (ISP) environments for standardized authorization attributes." What is an IEEE 802.1X network? Do you mean an IEEE 802 network? RADIUS has supported authorization attributes for a long time, this sentence makes it seem like this is the first time that authorization attributes have been defined in RADIUS. Also, mixing ISPs and IEEE 802 functionality in the same document is a symptom of a deeper problem which Greg Weber has brought up -- it is not clear what devices need to do in order to comply with the document, if compliance is even possible. " From time to time, an ISP requires to restrict a user's access to the Internet and redirect their traffic to an alternate location. For example, the user maybe on a prepaid plan and all the resources have been used up." Since this implies that the document is actually aimed at prepaid, I think you need a reference here. The ability to block user's traffic is required at service initiation and once service has been established. These capabilities must also be available across access technologies and various business scenarios. For example, the ability to block and redirect traffic is required for TCP users, cell phone users, WiFi users. As well, this capability must work whether the user is in their home network or roaming in a visited network which may or may not have a direct roaming relationship with the user's home network. This seems like a list of requirements that this document was supposed to satisfy. However, I would question whether in fact these requirements are legitimate. This documented started out focussed on IEEE 802 functionality -- how did it somehow morph into a document relating to prepaid, portals, etc.? " Blocking access refers to setting up access control rules at the NAS such that when the user initiates IP traffic, the NAS examines the set of rules associated with the service granted to the user. These rules determine what traffic is allowed to proceed through the NAS and what traffic will be blocked. Today this capability is supported in RADIUS and is configurable during service establishment and mid-service via the Filter-Id(11) attribute. To use Filter-Id to control access to network resources the rules need to be configured apriori at each NAS. Filter-Id(11) is used in an Access-Accept to specify the name of the filter rule(s) to apply to this session. To effect a change mid-service (dynamically), the Filter-Id(11) is included in a Change-of- Authorization (COA) packet as described in [RFC3676]. Upon receiving the Filter-Id(11) the NAS starts to apply the rules specified by the Filter-Id(11)." I'm not sure why this document needs to discuss Filter-ID, which is not defined here. "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(TBD) AVP. For this reason, this document introduces NAS-Filter-Rule(TBD) to RADIUS." What does "roaming friendly" mean? Filter-ID has been used in roaming for many years by cooperating parties. Perhaps the issue is requiring pre-established filters to be set on the NAS? This paragraph appears to be deprecating an existing RADIUS attribute without a clear justification.
[Mauricio]
I see this accounting attribute as adding basic audit capability to the authorization policy expressed through the NAS-Filter-Rule attribute. Surely you would agree that performing accounting/audit functions is well within scope of RADIUS. Accounting records already have data counts for session use, so why not have filter hit counts along with them? A straightforward use case is an administrator that has a (strict) filter policy for which he/she wishes to be notified anytime a user tries to pass unauthorized traffic through the NAS. Errant users could then be sanctioned in the future.
Proposed Resolution: Discuss
Issue 115: WG Last Call Comments Submitter name: David Nelson Submitter email address: dnelson@enterasys.com Date first submitted: August 11, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00640.html Document: IEEE802-00 Comment type: T Priority: 1 Section: 1, 1.1, 2, 2.1, 3.5, 4.1 Rationale/Explanation of issue:
Section 1: Better phrasing. Requested changes: (1) Within the confines of RADIUS authentication, authorization, and accounting (AAA) environments, there is a general dearth of standardized RADIUS attributes to limit user access using dynamic VLANs, filters or redirection. Could we change "a general dearth of" to "a requirement for"? It sounds more positive. (2) IEEE 802.1X-2004 [IEEE8021X] provides "network port authentication" for IEEE 802 [IEEE802] media, including Ethernet [IEEE8023], Token Ring and 802.11 wireless LANs [IEEE80211i]. Remove this sentence as it appears in the second paragraph as well. Section 1.1: The following definitions are not used in the draft: Access Point Association Station Requested change: Please delete them. Section 2: Better phrasing. Requested changes: (1) The first paragraph is awkwardly worded. Perhaps the following would be an improvement. In this section we provide an elaboration of the requirements briefly described in the Introduction. (2) For example, the user maybe on a prepaid plan and all the resources have been used up. Change "maybe" to "may be" and "resources have" to "credit balance has". (3) For example, the ability to block and redirect traffic is required for TCP users, cell phone users, WiFi users. Change "TCP users" to "IP users". (4) Change: 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(TBD) AVP. For this reason, this document introduces NAS-Filter-Rule(TBD) to RADIUS. To: As pointed out by [NASREQ] the use Filter-Id is not roaming friendly and it is recommended that instead one should adapt the Diameter NAS-Filter-Rule AVP as a RADIUS NAS-Filter-Rule(TBD) attribute. Section 2.1: This section seems out of place. 2.1 Capability Advertisement RADIUS does not currently define a method by which a NAS can advertise its capabilities and in many instances, it would be desirable for the home network to know what capabilities are supported by the NAS to ensure proper operational behavior. The attributes defined in this document are intended to be used to enforce policy by the NAS. If a NAS does not recognize these attributes it will most likely ignore them and the desired policy will not be enforced. A method for the NAS advertising the capability to support these attributes would help the RADIUS server understand if the intended policies can be enforced. As a result, the attributes in this document, in particular NAS-Filter- Rule(TBD), can benefit from capability advertisement, if available. Requested changes: Should this entire section perhaps be part of the Security Considerations? Section 3.5: Clarification of the text. Requested changes: Furthermore, the concatenated filter list must abide to the following rules of precedence and ordering: 1) A flush rule MUST appear before all other rule types. Change "A flush rule" to "A flush rule, when present,". 2) Base encapsulation filter rules MUST appear after a flush rule and before IP tunnel, HTTP redirect, IP filter, and/or HTTP filter rules. Change "a flush rule" to "any flush rule". dir "in" is from the terminal, "out" is to the terminal, "inout" is from and to the terminal. The term "terminal" is not defined in the draft. I suspect it identifies the network entity which contains the IEEE 802.1X Supplicant function, but this should perhaps be clarified. General comment: I'd much rather that we use ABNF to define the NAS-Filter-Rule formal syntax, however I'm not prepared to submit that text just now. :-) Section 4.1 4.1. Acct-NAS-Filter-Rule The first eight octets of this string are used for a 64-bit value of the rule counter. The remaining octets are used to specify which filter rule the counter value is for. The rule specification MUST conform to the syntax rules specified for NAS-Filter-Rule[TODO]. [TODO] indicates an open action item. Requested changes: Provide the [TODO].
[David Nelson]
All the items included in RADEXT Issues 115 and 116 have been resolved
in the draft-ietf-radext-ieee802-01.txt revision, with the exception of:
The term "terminal" is not defined in the draft. I suspect
it identifies the network entity which contains the IEEE
802.1X Supplicant function, but this should perhaps be
clarified.
This issue still exists in the -01 draft, in Section 2.5.[Mauricio Sanchez]
Yes, this is known. On 1/10/06 I wrote in response to your issue: "[ms] This sentence comes by way of the IPFilterRule description found in Diameter [RFC3588]. What would you suggest we do for RADIUS? Is terminal not a globally known term in RADIUS, if not, is there any? Perhaps can you suggest a definition to add to the terminology section. " I await your response.
[David Nelson]
Ah. Brain fade... Terminal may have been a well understood term in the days when RADIU