Subject: [radext] WGLC for draft-ietf-radext-radius-extensions-06

From: jouni korhonen <[email-masked]>
Date: Sat, 29 Sep 2012 12:10:52 +0300

Folks,

This email starts a two week WGLC (the third in row) for "Remote Authentication Dial In
User Service (RADIUS) Protocol Extensions" I-D (draft-ietf-radext-radius-extensions-06).
The WGLC ends 13-Oct-2012. Send your comments to the mailer and please also use the Issue
Tracker. No comments would this time also imply that everybody agrees with the content.

- Jouni & Mauricio

---

From: Leaf yeh <[email-masked]>
Date: Sat, 29 Sep 2012 09:40:49 +0000

Just for a check, would this WG draft like to add a section for the new data type, Sting in URN format, proposed in draft-winter-radext-fancyaccounting-02?

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of jouni korhonen
Sent: Saturday, September 29, 2012 5:11 PM
To: [email-masked]
Cc: [email-masked]; Alan DeKok
Subject: [radext] WGLC for draft-ietf-radext-radius-extensions-06

Folks,

- Jouni & Mauricio
_______________________________________________
radext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/radext

---

From: Sam Hartman <[email-masked]>
Date: Sat, 29 Sep 2012 08:14:16 -0400

>>>>> "Leaf" == Leaf yeh <[email-masked]> writes:

    Leaf> Just for a check, would this WG draft like to add a section
    Leaf> for the new data type, Sting in URN format, proposed in
    Leaf> draft-winter-radext-fancyaccounting-02?  Best Regards, Leaf

I'd prefer to get this draft approved sooner rather than later and
believe now is not the time for adding things to it that can be handled
in other drafts.

--Sam

---

From: Peter Deacon <[email-masked]>
Date: Sat, 29 Sep 2012 10:47:06 -0700 (Pacific Daylight Time)

> Tracker. No comments would this time also imply that everybody agrees with the content.

As mentioned on list in detail earlier I am still concerned with mechanism 
for fragmentation of long attributes (3.5,3.6) especially when combined 
with VSAs (4.5,4.6)

The risk of (silent) data corruption due to handling order of attributes 
in a way permitted by existing RFCs seems to be higher than necessary.

Have previously offered what I believe to be simple ideas to mitigate:

Prevent extensions compliant systems from interacting with RADIUS RFC 
compliant intermediaries not supporting extensions.

Fragment VSAs at the VSA Value field to prevent any opportunity for 
another attributes Value field to select Vendor and Vendor Type.

Use reserved field as sequence number to better detect missing or out of 
order attributes.  Checking and setting could be made optional such that 
systems finding it too difficult to increment a counter need not be 
adversely effected.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Sun, 30 Sep 2012 09:02:18 +0200

Peter Deacon wrote:
> As mentioned on list in detail earlier I am still concerned with
> mechanism for fragmentation of long attributes (3.5,3.6) especially when
> combined with VSAs (4.5,4.6)
> 

  I'm not sure I agree.

> compliant intermediaries not supporting extensions.

  I don't understand that.  Existing systems which are RFC compliant and
*not* supporting extensions won't be affected by them.  The extensions
attributes use previously undefined numbers.  RFC compliant systems
don't touch unassigned attributes.

> another attributes Value field to select Vendor and Vendor Type.

  That is a problem if, and only if, non-RFC compliant systems re-use
unassigned values AND mangle them.  While that can happen, I think it
can be detectable in practice.

> systems finding it too difficult to increment a counter need not be

  Sequence numbers are possible.  I think the previous consensus was
that they didn't make much difference.

  Alan DeKok.

---

From: Avi Lior <[email-masked]>
Date: Sun, 30 Sep 2012 14:23:03 -0400

I agree with Alan.

As well, to sequence numbers,  I don't see any need for them.

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Mon, 1 Oct 2012 01:43:42 +0000

I am in favor of advancing with this document.

Thanks,
Gaurav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of jouni korhonen
Sent: Saturday, September 29, 2012 2:41 PM
To: [email-masked]
Cc: [email-masked]; Alan DeKok
Subject: [radext] WGLC for draft-ietf-radext-radius-extensions-06

Folks,

This email starts a two week WGLC (the third in row) for "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions" I-D (draft-ietf-radext-radius-extensions-06).
The WGLC ends 13-Oct-2012. Send your comments to the mailer and please also use the Issue Tracker. No comments would this time also imply that everybody agrees with the content.

- Jouni & Mauricio

---

From: Peter Deacon <[email-masked]>
Date: Sun, 30 Sep 2012 21:21:24 -0700 (Pacific Daylight Time)

> As well, to sequence numbers,  I don't see any need for them.

Attribute ordering in RFC compliant systems not supporting extensions is 
only a recommendation.

The possible consequences of assuming order can be severe (silent 
corruption and control over vendor id, vendor type and vendor value 
fields)

I don't think it is prudent to ignore this when a complete solution for 
RADIUS packets containing single long attributes and less than complete 
when more than one long attribute are present is trivial.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Mon, 01 Oct 2012 08:33:15 +0200

> Attribute ordering in RFC compliant systems not supporting extensions is

  And implemented by all RADIUS servers I'm aware of.

> corruption and control over vendor id, vendor type and vendor value fields)
> 

  Sequence numbers aren't trivial.

  My $0.02 is that a simpler solution would be to use one "reserved" bit
as a "start" flag.  The first fragment has "start" set.  All others don't.

  If you see a first fragment *without* the "start" bit set, you know
someone screwed up, and you ignore all subsequent fragments of the same
type.  You might even want to toss the packet entirely as non-compliant.

  That soles the problem with minimal changes to the draft.  My guess is
that it could be added in only a few sentences.

  Alan DeKok.