[03:53:22] --- evbergen has joined
[03:53:32] <evbergen> Testing
[09:41:06] --- sharonchisholm has joined
[09:43:16] --- j.schoenwaelder@jabber.eecs.iu-bremen.de has joined
[09:47:27] --- Dave Nelson has joined
[09:47:51] <Dave Nelson> Good morning.
[09:51:09] <evbergen> Good morning
[09:51:25] --- Barney has joined
[09:54:00] --- sharonchisholm has left
[09:57:06] <evbergen> Does anyone have confirmation of audio working?
[09:57:39] <Barney> i get a ticking with an occasional cough in the background
[09:58:12] --- sharonchisholm has joined
[09:58:14] <Barney> hi dave, read you fine
[09:58:19] <evbergen> Dave, that's great.
[10:00:39] --- Thierry has joined
[10:02:31] <sharonchisholm> I'm jabber scribed (sorry for the spelling ahead of time)
[10:02:55] <sharonchisholm> agenda bashing
[10:03:04] --- bert has joined
[10:03:17] <sharonchisholm> talking about milestone revisions
[10:03:25] <sharonchisholm> milestones lagging
[10:03:30] <sharonchisholm> some stuff done
[10:03:41] <sharonchisholm> set new milestones for outstanding things
[10:03:48] <sharonchisholm> intent is to manage to dates
[10:04:04] <sharonchisholm> now on the charter page
[10:04:13] <sharonchisholm> we shall focus today on more near-term things
[10:04:24] <sharonchisholm> Document status ... 4th slide
[10:04:51] <sharonchisholm> published a couple of RFCs
[10:05:29] <sharonchisholm> One in IESG review, some completed AD review, some completed WG LC and some pre-work
[10:05:59] <sharonchisholm> these might soon become working group items
[10:06:16] <sharonchisholm> first one radius digest authentication
[10:06:43] <sharonchisholm> slides in meeting materials ... also on bernard's website
[10:06:46] --- Fang has joined
[10:07:32] <sharonchisholm> now up with wolfgang and digest-auth
[10:07:41] <sharonchisholm> issues ... not as minor as he hoped
[10:07:58] <sharonchisholm> client configuration ... solution is in -07: manual configuration
[10:08:24] <sharonchisholm> Added a section ...
[10:08:46] <sharonchisholm> Want to reduce round trip times ... best thing to do is to do manual configuration
[10:08:54] <sharonchisholm> Nonce Replay ...
[10:09:17] <sharonchisholm> client gets hijacked
[10:09:32] <sharonchisholm> several options
[10:09:50] <sharonchisholm> remove radius client nonce generation ... (option 1) ... rejected in Vancouver
[10:10:08] <sharonchisholm> Dave - followup ... existing requirement from someone for this feature
[10:10:17] <sharonchisholm> Answer - yes, 3GPP2
[10:10:57] <sharonchisholm> Other chair - this came from a couple of places ( including sam)
[10:11:10] <sharonchisholm> Glenn - if you can't remove this feature, then you should tell people to avoid it.
[10:11:18] <sharonchisholm> Option 2 - rejected by Glenn
[10:11:29] <sharonchisholm> So, just skip it. ...
[10:11:39] <sharonchisholm> Option 3 - embed time-stamp into nonce
[10:11:55] <sharonchisholm> problem is that you ca n't really do re-transmisions with this mechanisms
[10:12:24] <sharonchisholm> other chair - requiring timesyncs has been a problem in other documents ... not sure it will work here as well
[10:12:42] <sharonchisholm> their is a section of the radius rfc is that you can't retransmit if attributes change
[10:12:57] <sharonchisholm> plus, how long is your delay between client and server
[10:13:09] <sharonchisholm> if your window is too small, you might get into some storms ....
[10:13:13] <sharonchisholm> don't think will work
[10:13:26] <sharonchisholm> option 4 - used in 07 is to use sequence number, not a timestamp
[10:13:33] <sharonchisholm> sequence number per radius client
[10:13:44] <sharonchisholm> does not protect the first packet though
[10:14:02] <sharonchisholm> radius client needs to store, even during reboot.
[10:14:14] <sharonchisholm> need a window
[10:14:33] <evbergen> question: is that secret in slide 9 shared between hops or between endpoints?
[10:14:35] <sharonchisholm> allows the client to store every 100th sequence number instead of every one
[10:14:40] --- HannesTschofenig has joined
[10:15:05] <sharonchisholm> Glenn - not going to complain about state on the server. don't have a problem with that. They already keep state in a lot of cases. I think that window is kind of big though
[10:15:22] <sharonchisholm> Glenn - can you make the window small enoguh to add security and still have the protocol function
[10:15:28] <sharonchisholm> this was just an estimate
[10:15:58] <sharonchisholm> Bernard - higher level comment. not sure they were asking for this. More that you should do server stuff, not the client
[10:16:19] <sharonchisholm> Glenn - i wanted you to take out client nonce all together
[10:16:28] <sharonchisholm> these thigns may not be backwards compatible
[10:16:48] <sharonchisholm> glenn - hope the people from 3GPP2 think seriously about this. If we need to do this, but a warning not to
[10:17:23] <sharonchisholm> David S. - when we wrote it originally, we added nonce client not to do with 3GPP2, it was an optimiaztion. Happy to remove the nonce.
[10:17:33] <sharonchisholm> Bernard - would like to ask the working group
[10:17:49] <sharonchisholm> bernard - remove the sequence number stuff, or remove the nonce itself. what does the working group think?
[10:17:59] <sharonchisholm> Bernard - sequence number hands
[10:18:22] <sharonchisholm> Bernard - reverting? Removing sequence number and replace with disclaimers (recommend server nonce generation instead)?
[10:18:23] <Barney> yes, remove seq #
[10:18:29] <sharonchisholm> hands (a few)
[10:18:39] <sharonchisholm> No one for the other option
[10:18:45] <sharonchisholm> for step one
[10:18:48] <sharonchisholm> second question
[10:18:58] <sharonchisholm> how many people are comfortable with removing altogether
[10:18:58] <sharonchisholm> one
[10:19:00] <Barney> yes, remove client nonce
[10:19:04] <sharonchisholm> how many people want to keep it on
[10:19:06] <sharonchisholm> in
[10:19:07] <sharonchisholm> none
[10:19:12] <sharonchisholm> verify on the list
[10:19:28] <sharonchisholm> Dave - there are people who are not here who wanted it
[10:19:42] <sharonchisholm> person - if on the list people can explain why they want it
[10:20:06] <sharonchisholm> Bernard - send message to list indicating which issues you believe are closed.
[10:20:45] <sharonchisholm> John M - can't remember if I received an email asking me if I was happy with the resolution. My issue is clear for the record
[10:21:03] <sharonchisholm> bernard <list of people he sent the issue close confirmation email to>
[10:21:23] <sharonchisholm> ------------------
[10:21:43] <sharonchisholm> Dynamic authorization MIBs
[10:21:53] <sharonchisholm> Quick overview ....
[10:21:58] <sharonchisholm> each are at -03
[10:22:09] <sharonchisholm> wg last call completed last november
[10:22:15] <sharonchisholm> issues solved in -03 from Jan
[10:22:31] <sharonchisholm> then some additional comments from Juergen and Dave ...
[10:22:40] <sharonchisholm> counter discontinuities ... have a resolution
[10:22:44] <sharonchisholm> going to add a timestamp ...
[10:23:05] <sharonchisholm> -04 is done, but missed the deadlline
[10:23:19] <sharonchisholm> so, do we need to do a version -05?
[10:23:36] <sharonchisholm> dave - bert indicated that with MIBs it was cleaner to submit a new version
[10:23:52] <sharonchisholm> bert - yes, I agree. If you know what the changes should be, you can submit it today
[10:24:02] <sharonchisholm> ok. we shall submit version 5 this week
[10:24:14] <sharonchisholm> bert - yes this in AD review.
[10:24:21] <sharonchisholm> bernard - this is informational
[10:24:43] --- Ralph has joined
[10:24:46] <sharonchisholm> bert - if it is information, when we get the new document, we will look at the issues and then it can go to IESG review
[10:25:05] <sharonchisholm> dave - it would be good if the proposed text goes to the mailing list first to ensure people are happy with it
[10:25:14] --- adekok has joined
[10:25:16] <sharonchisholm> ok. good. i will do it like that
[10:25:20] <sharonchisholm> --------------------
[10:25:33] --- jonathan.buschmann has joined
[10:25:40] <sharonchisholm> status of RADIUS MIBs (Dave Nelson)
[10:25:47] <sharonchisholm> comments from AD review
[10:25:56] <sharonchisholm> issues 182 and 177 (item 2)
[10:26:06] <sharonchisholm> boilerplate ...
[10:26:10] --- jonathan.buschmann has left
[10:26:25] <sharonchisholm> description of which InetAddress TC format ...
[10:26:26] --- Thierry has left
[10:26:32] <sharonchisholm> what a zero means ...
[10:26:40] <sharonchisholm> changes to compliance section.
[10:26:58] <sharonchisholm> ipv4/ipv6 ....
[10:27:10] --- jnob has joined
[10:27:12] <sharonchisholm> check references ...
[10:27:37] <sharonchisholm> new object to contain timestamp for the last discontinuity
[10:28:03] <sharonchisholm> otherwise it is tied to sysuptime, which is not sufficient
[10:28:14] <sharonchisholm> next steps - revised drafts
[10:28:24] <sharonchisholm> any questiosn?
[10:28:29] <sharonchisholm> ok. thanks
[10:28:39] <sharonchisholm> ----------------
[10:28:41] --- xrtc has joined
[10:29:05] <sharonchisholm> radext-vlan; filter rules; redirection
[10:29:15] <sharonchisholm> mauricio
[10:29:22] --- jnob has left
[10:29:31] <sharonchisholm> the IEEE draft got split into three drafts
[10:29:44] <sharonchisholm> bernard lead on first;
[10:29:47] <sharonchisholm> he is leading on second
[10:29:53] --- Ralph has left
[10:29:55] <sharonchisholm> joe s is lead on the third
[10:30:16] <sharonchisholm> filter rules has been contensious, and it is blocking everything.
[10:30:22] <sharonchisholm> this should unblock things
[10:30:32] <sharonchisholm> allows a staged delivery
[10:31:00] <sharonchisholm> attribute summary of where things landed in the three drafts
[10:31:41] <sharonchisholm> VLAN status
[10:31:47] <sharonchisholm> completed wg last call last week
[10:31:53] <sharonchisholm> one open issue 180
[10:31:57] <sharonchisholm> mis-use of data types
[10:32:13] <sharonchisholm> there is strawman posted -01
[10:32:24] <sharonchisholm> after this meeting, we will send in
[10:32:36] <sharonchisholm> Issue 180: what is the data type for the two attributes
[10:32:49] <sharonchisholm> egress-vlanid
[10:33:05] <sharonchisholm> vlan-priority-table really a string?
[10:33:15] <sharonchisholm> vlan flag really a flag
[10:34:02] <sharonchisholm> philosophical debate on the mailing list as to whehter these are actually mis-used
[10:34:13] <sharonchisholm> use design guidelines draft to work out best practices
[10:34:21] <sharonchisholm> this draft doesn't make things uglier then the past
[10:34:45] <sharonchisholm> bernard - on the name of vlan flag detail ... we are willing to accept integer for vlan id
[10:34:58] <sharonchisholm> bernard - the priority table as a string, people can live with
[10:35:13] <sharonchisholm> bernard - then the name of the last field. lots of problems.
[10:35:24] <sharonchisholm> bernard - vlan tag flag.
[10:35:32] <sharonchisholm> bernard - having a contest for the name
[10:35:50] <sharonchisholm> (free cookies for the prize?)
[10:36:18] <sharonchisholm> bernard - don't know if anyone has a preference. would like to get out of this room with some idea?
[10:36:20] --- bert has left: Replaced by new connection
[10:36:22] --- bert has joined
[10:36:29] <sharonchisholm> good since this is trivial and not a major problem
[10:36:43] <evbergen> evbergen: if it's packet in integer anyway, so I don't see how ASCII would help
[10:36:50] <evbergen> s/packet/packed/
[10:36:56] <sharonchisholm> Dave - it is asco 31 and ascii 32 so that is string one and two
[10:37:18] <sharonchisholm> Bernard - 1 foo and 2 foo
[10:37:39] <sharonchisholm> Berard - if it is integer, then you would have to figure out what the value is in type it in
[10:37:58] --- Jelte Jansen has joined
[10:38:06] <sharonchisholm> originally it was just 0 and 1 ... but to type 0 and 1 in ascii is difficult, so we resolved to change to 31 and 32
[10:38:21] <sharonchisholm> person - thanks for the explanation ...
[10:38:32] <sharonchisholm> person - tag indication (when forced to name the field)
[10:38:43] <sharonchisholm> Glenn - like tag indicator name
[10:38:59] <evbergen> "tagging flag"?
[10:39:03] <sharonchisholm> Glenn - doni't want to be too cryptic ... could call it the vlan enabled in this case <something>
[10:39:17] <sharonchisholm> glenn - vlan tagging enabled or not field
[10:39:26] <sharonchisholm> straw poll
[10:39:28] <sharonchisholm> show of hands
[10:39:35] <sharonchisholm> who likes tag indicator?
[10:39:36] <sharonchisholm> hands
[10:39:42] <sharonchisholm> 8-10.
[10:39:46] <sharonchisholm> tag indicators it is
[10:40:02] <sharonchisholm> next slide
[10:40:20] <sharonchisholm> next steps ... resolved issue 180 ... then new version ... then sent to IESG
[10:40:24] <sharonchisholm> second draft - filter
[10:40:40] <sharonchisholm> lots of contension ...
[10:40:52] <sharonchisholm> how to treat this filter attribute since diameter has something similar
[10:41:06] <sharonchisholm> wanted to be nice to the diamter and call the radius one the same thing
[10:41:12] <sharonchisholm> this has been confuding
[10:41:27] <sharonchisholm> want to change name to NAS Traffic rule
[10:42:03] <sharonchisholm> berard - think this is positive step forward ... but I i got a ping from 3GPP for a filter which is the same as diameter
[10:42:13] <sharonchisholm> bernard - then say you can't have more then one
[10:43:21] <sharonchisholm> Dave N - don't think naming was the major issues. the issue i see is that if radius has a different filter to accomplish the same thing ... give charter for forward compatibility to diameter ... what we have for syntax ... if would be unfair if diameter could not handle it. This is more then just the name. it is whether the content is the same
[10:43:46] <sharonchisholm> yes, first, i wanted to remove confusion with renaming. But, good point on how we move forward. Avoid dialect wards
[10:43:49] <sharonchisholm> wars
[10:44:03] <sharonchisholm> Diameter Compatibility
[10:44:32] <sharonchisholm> beyond changing name ... have a lock-step. been in communication with diameter folks. we continue to progress, but give them opportunity to comment
[10:44:51] <sharonchisholm> this will allow us to share a common dialect between the two communities
[10:45:03] <sharonchisholm> whenever diameter gets updated, we evaluate it as well
[10:45:23] <sharonchisholm> Bernard - mechaninically how would this work. is this is a feature of 4XXX?
[10:45:57] <sharonchisholm> John - we will discuss this in the working group and find out ... 3GPP wants some diameter feature to be available for rad-ext. need to support both in each protocol
[10:46:25] <sharonchisholm> john - in getting diameter to draft standard. If we need to revist proposed standard, that's fine
[10:46:47] <sharonchisholm> Bernard - the thing that defines syntax ... it is 4005, where you could look at implemenations
[10:47:01] <sharonchisholm> John - if we go to draft standard, we could remove the syntax from the base
[10:47:26] <sharonchisholm> what I want from the rad-ext if there is any feedback to start going lock-step with diamteter?
[10:47:36] <sharonchisholm> Glenn - not sure I understand the necessity
[10:47:52] <sharonchisholm> Glenn - last I checked ... radius/diamter were required to do attribute translation in any case
[10:48:13] <sharonchisholm> Glenn - don't see a huge problem here so long as the semantics are compatible
[10:48:29] <sharonchisholm> on the face, no technical issues, it is more the issue Dave raised on having two dialects
[10:48:45] <sharonchisholm> Glenn - doesn't matter. You need to translate anyways.
[10:49:15] <sharonchisholm> Dave - Glenn is right, there is an existing function that does translation. But identity is easier to perform if the syntax aligns
[10:50:15] <sharonchisholm> Glenn - that is the problem ... it is not possible to go both ways with diameter and radius. You cannot to express something in diamter syntax in radius (or it would be bad to do this). Diameter has lots of space. we don't have that in radius. pretending we can, would be wrong
[10:50:30] <adekok> do we have statistics as to distribution of message sizes in diameter practice?
[10:50:30] <sharonchisholm> Glenn - semantically they should align. syntactically they shouldn't
[10:50:56] <evbergen> adekok: I agree that would still be interesting
[10:51:04] <sharonchisholm> John - originally going to agree with aligning. Responing to Glenn ... semantically align ... then we would need some text around translation
[10:51:19] <sharonchisholm> Bernard < chanelling statics question from jabber>
[10:52:21] <sharonchisholm> Glenn - thinks it is irrelevant ... could say <stuff about size> .. if you want to base the development of the protocol on those in-the-moment-statistics, you will break the protocol. If you rely on the fact that they don't need to be bigger then X, then you hurt the protocol
[10:52:35] <sharonchisholm> Q - is there a plan to have a clean translation
[10:53:03] <sharonchisholm> John - topic for diameter working group ... would like the general guidelines document.
[10:53:18] <sharonchisholm> John - for this attribute, there should be a paragraph or two for this attribute.
[10:53:23] <sharonchisholm> but not for all attributes
[10:53:49] <sharonchisholm> Glenn - there are instructions for translating in nasrad 2005. that is where the most general instructions are.
[10:54:00] <sharonchisholm> Glenn - agree that this draft should have its own instructions
[10:54:06] <sharonchisholm> Open issues
[10:54:48] <sharonchisholm> accounting, filter rules accounting, nits, diameter interoperability, handling unparseable rules ...
[10:55:18] <sharonchisholm> Bernard - accounting issue overlaps with things like ipfix .... you set the filters and then you get counters back ...
[10:55:26] <sharonchisholm> Bernard - somethign with the ADs
[10:55:34] <sharonchisholm> Bert - <something off Mike>
[10:55:42] <sharonchisholm> -------------
[10:55:45] <sharonchisholm> Delegated pre-fix
[10:56:19] <sharonchisholm> ralph Driums
[10:56:24] <sharonchisholm> Droms
[10:56:44] <sharonchisholm> status update
[10:57:03] <sharonchisholm> attribute design to carry a prefix from a radius server to a dhcp v6
[10:58:02] <sharonchisholm> accepted as a wg item
[10:58:23] <sharonchisholm> took out references to framed ipv6 prefix
[10:59:22] <sharonchisholm> does not meet requiremnets of rfc 2875
[10:59:28] <sharonchisholm> 2865
[10:59:43] <sharonchisholm> need additional reviews of the document
[11:00:02] <sharonchisholm> bernard - my understanding was that we had wroking group consensus that the format was OK.
[11:00:23] <sharonchisholm> bernard - please read this . it is short.
[11:00:47] <sharonchisholm> q - the usage scenarious of wimax ... the is prefix assigned in roaming?
[11:01:01] <sharonchisholm> not roaming, but home network on wireline. working with cablelabs
[11:01:18] <sharonchisholm> get customer prefix from backend to CPE router
[11:01:31] <sharonchisholm> q - might be potential use for this in Wipax 3Gpp2
[11:01:54] <sharonchisholm> this attribute could be used anytime you want to prefix stored in radius and tranfered DHCPv6
[11:02:03] <sharonchisholm> -------------------------
[11:02:36] <sharonchisholm> -02
[11:02:51] <sharonchisholm> Radius attributes already defined in RFC 2072
[11:02:53] <sharonchisholm> 4072
[11:03:11] <sharonchisholm> issues
[11:03:26] <sharonchisholm> minimum attribute length of EAP-key-name
[11:03:35] <sharonchisholm> not legal in radius
[11:03:45] <sharonchisholm> how does a server decide to send peer-id or server-id
[11:04:01] <sharonchisholm> can't just dump in nas
[11:04:22] <sharonchisholm> extended attributes might shed some light on it
[11:04:31] <sharonchisholm> q - the mobility domain id.
[11:05:03] <sharonchisholm> 802.11r ... fast transition server ... if you see this advertised then you can roam between them and get fast handoff
[11:05:15] <sharonchisholm> q - for accounting or handoff?
[11:05:25] <sharonchisholm> it isn't useful for handoff
[11:05:33] <sharonchisholm> assumed it was mainly for accounting
[11:05:44] <sharonchisholm> it would be useful to get comments from 11R folks
[11:06:01] <sharonchisholm> q - just to be clear ... already an attribute ...
[11:06:04] <sharonchisholm> not location ....
[11:06:34] <sharonchisholm> Nancy - in 11R, there is the notion of the mobility domain id, so we wouldn't have to go back to the aaa server.
[11:06:45] <sharonchisholm> nancy - more for accounting then for the handoff
[11:06:53] <sharonchisholm> nancy - this might be worthwile
[11:07:05] <sharonchisholm> -----
[11:07:29] <sharonchisholm> attribute guidelines
[11:07:36] <sharonchisholm> Greg Weber
[11:07:40] <evbergen> no audio?
[11:07:46] <sharonchisholm> three drafts
[11:08:06] <sharonchisholm> (still no audio?)
[11:08:19] <evbergen> (it's back)
[11:08:35] <sharonchisholm> milestone is oct 06 completion
[11:09:46] <sharonchisholm> (more status stuff)
[11:10:15] <sharonchisholm> bernard - also diameter vsa one which looks like wolf draft?
[11:10:21] <sharonchisholm> have not look closely at that yet. want to
[11:10:47] <sharonchisholm> have people read the drafts?
[11:10:57] <sharonchisholm> 6 or so hands
[11:11:08] <sharonchisholm> (that was if you read one of the drafts, not all)
[11:11:26] <sharonchisholm> Dave - june deadline for wg last call on this needs to be met. Let's get more motivated
[11:11:46] <sharonchisholm> Bernard - if your draft will get gated by this, then you must read it
[11:12:18] <sharonchisholm> Q - other drafts with dependencies on the guidelines ... at all levels ... if you have nested attributes, so you need to follow at at all levels?
[11:12:39] <sharonchisholm> bernard - wg issue. if the working group doesn't think everything needs to be enforced, then they should be removed from the draft
[11:12:46] <sharonchisholm> thinking of the documet as strategic
[11:13:34] <sharonchisholm> Glenn - same sort of puzzlement as to how an existing draft can be held up by this. once you decide what they guidelines are you should follow, but you don't have to stop all work until you have guidelines
[11:13:41] <sharonchisholm> that hasn't happened yet
[11:14:00] <sharonchisholm> Glenn - my understanding is that the reason there is pressure to get this out is that it is holding up work
[11:14:14] <sharonchisholm> Glenn - doesn't really matter so long as they get done and make sense.
[11:14:27] <sharonchisholm> Bernard - waste a lot of time arguing about these guidelines
[11:15:33] <sharonchisholm> Dave - agree we have not delayed any work as a result of this. Have registed comments. This guidelines was one of the first guidelines of the group intentionally. Yes, it is stragegic moving forward. will be used as a too. There is work in our body that will bennefit from it
[11:16:21] <sharonchisholm> Dave - while we are the experts creating the guidelines. Don't apply guidelines to just to the folks that come after us. If we are going to create guidelines we should apply them to our own work, or we look like hypocrits(sp)
[11:17:16] <sharonchisholm> Dan R - want it to move forward. Don't want other documents to move forward with things that move forward contrary to the guidelines. In MIB world we have CLRs (crappy little rules), which don't always add value
[11:17:32] <evbergen> Q: Following the Chair's split of the guidelines and the extended attribute, would it be useful to make the distinction between the guidelines that apply to the complex data types (which we won't have until the extended attribute work is done) and the others?
[11:17:36] <sharonchisholm> Glenn - I should clarify that i was not suggesting it not valuale to get this done
[11:18:27] <sharonchisholm> Glenn- have three drafts in expert review. I was naive in believing that experts meant experts in radius. they didn't appear to be. I think ..
[11:18:38] <sharonchisholm> Bernard - this was an RFC process thing
[11:18:56] --- Thierry has joined
[11:19:05] <sharonchisholm> data model - divergence between standard and vendor space
[11:19:19] <sharonchisholm> fun with visio
[11:19:41] <sharonchisholm> scope - backwards compatibility ...
[11:19:54] <sharonchisholm> wants feedback on new section 7 .... actual guidelines
[11:20:19] <sharonchisholm> guidelines for guidelines
[11:21:41] <sharonchisholm> bernard - (non-wg chair-ish) in 2865 ... require quite a few attributes that don't fit ... are we trying to roll back the clock ... do we understand what the issue is?
[11:22:10] <sharonchisholm> bernard - we have had some discussion on what the underling problm ... being unable to describe <missed it >
[11:22:18] <sharonchisholm> bernard - compound thing
[11:22:36] <sharonchisholm> bernard - being able to type things in as a string
[11:23:24] <sharonchisholm> bernard - registerying my dislike of this recommendation. Ok the have compound likes if it is always used a unit. So long as it never has to be parsed
[11:23:50] <sharonchisholm> objecting ... just because a grouping is required, does not mean you hve to support extended attributes
[11:23:56] <Barney> response to Bernard - human disl\play counts too
[11:23:58] <evbergen> (I wholeheartedly agree with Bernard)
[11:24:21] <sharonchisholm> bernard - might you need in a policy statement that if you need access individual things ...
[11:24:55] <sharonchisholm> Dave - doing comments from jabber room
[11:25:23] <Barney> yes, i meant to disagree
[11:25:33] <sharonchisholm> q - impacting client/server versus intermediator ... do you make the distinction
[11:25:35] <sharonchisholm> yes
[11:25:55] <sharonchisholm> Ralph D - didn't read the entire draft. we ran into something similar in dcp
[11:26:43] <sharonchisholm> ralph - compoung things that are not parsed by the server ... we run into that. One issue with DHCP server is an issue is the user interface into them. There are some hex strings ... that can be parsed. Customers would prefer the correct user interface stuff
[11:26:59] <sharonchisholm> Bernard - you have compound attributes in DHCP ... how do you handle them
[11:27:35] <sharonchisholm> Ralph - we have not had a formal discussion. adhoc discussions. if someone comes up with something ... if it is too differernt, there is pushback
[11:28:01] <sharonchisholm> Ralph - the ui people have not revolted
[11:28:21] <sharonchisholm> integer 64 ... use extended attribute
[11:28:24] <sharonchisholm> not a string
[11:28:40] <sharonchisholm> bernard - do you grandfather old types or force them to use something new
[11:28:56] <evbergen> I think integer64 should use normal RADIUS attrs
[11:29:00] <evbergen> just like any scalar value
[11:29:07] <evbergen> compound or long values are different
[11:29:15] <sharonchisholm> further recommendations ....
[11:29:26] <sharonchisholm> VSE ... would recommnd against using them
[11:29:33] <adekok> I could only find 64-bit fields (bit/byte-arrays) in the RFC's. No 64-bit *integer* counters.
[11:29:52] <sharonchisholm> (some off mike comments)
[11:30:02] --- jsalowey has joined
[11:30:15] <sharonchisholm> 3575 is IANA conventions
[11:30:20] <sharonchisholm> Dave M - thank you
[11:30:55] <sharonchisholm> message lengths must not exceed the current boundaries
[11:31:18] <sharonchisholm> variable length stuff bad
[11:31:30] <evbergen> alan: There's no incompatibility created; syntactically, the attribute number determines the type of the value. RADIUS is perfectly forward compatible with respect to data typing.
[11:32:15] <sharonchisholm> Glenn - one slipped by me. The per-attribute encyrption other than defined in radius extensions. There wasn't much actually defined in standards.
[11:32:24] <sharonchisholm> Glenn - that would be bad.
[11:32:42] <evbergen> Remark: tunnel-password style encryption also used by MPPE-Send-Keys, used by *ALL* WPA deployments today.
[11:32:54] <sharonchisholm> actually, more related to per-attribute more so than the encryption. Protect the entire traffic, not specific attributes
[11:33:12] <sharonchisholm> Glenn - ip address authentication, but not authenticating client/server themselves
[11:33:21] <sharonchisholm> Glenn - doomed. completely doomed
[11:33:33] <sharonchisholm> Glenn - in the case of hijacking
[11:33:48] <adekok> Glen's right. Also, it's difficult for the application to determine whether or not the data is encrypted with IPSec.
[11:33:51] <sharonchisholm> security has to be application layer
[11:33:57] <adekok> Yes!
[11:34:26] <sharonchisholm> sounds like you are objecting to the current security practice, rather then what is in the draft
[11:34:51] <sharonchisholm> Glenn - need something like TLS or need per-attribute encyrption. taking one of those out here
[11:35:10] <sharonchisholm> currently procluded by the charter to create new security mechanisms
[11:35:17] <sharonchisholm> bernard - no, this is going further
[11:36:02] <sharonchisholm> Dave h - intent was not to indicate that per-attribute encryption other then old stuff was precluded .... when it says 'other then radius standards', it was asumming crypto agility
[11:36:31] <sharonchisholm> Bernard - is this is statement that says we screwed up on the old stuff, so don't use it, or is it saying evening if we did something better, don't use it
[11:36:41] <sharonchisholm> Glenn - sounds like we are saying don't use it every
[11:37:06] <sharonchisholm> Glenn - user/password attribute method is like what we should do
[11:37:18] <evbergen> alan/glen: Agreed completely. TLS is already out due to charter (no new transports), so, IPSec not at apps layer, so effectively, attribute encryption can only be the weak md5/shared secret/authenticator based thing.
[11:37:37] <sharonchisholm> Bernard - if security recommendation, if there are problems iwh the following thigns, don't use them. If you are going to use this, do something credible
[11:37:43] <adekok> evbergen: FYI, radiator has radsec, addresses a lot of issues.
[11:37:50] <sharonchisholm> Bernard - more a security considerations then design guideline
[11:37:57] <evbergen> adekok: radsec, is that radius over tls/tcp?
[11:38:03] <sharonchisholm> then everyone can use a different way to protect them
[11:38:14] <sharonchisholm> bernard - if we do the thing stuff, then we could have a guidline
[11:38:18] <adekok> evbergen: yes. I'll take it offline..
[11:38:42] <sharonchisholm> Bert (as AD-sub) - question on last bullet. is this like what we agreed to a couple of years ago. where has it been discussed.
[11:38:44] <sharonchisholm> here
[11:38:59] <sharonchisholm> Bert - may want to check with IESG early. this was a tough discussion a couple years back
[11:39:22] <sharonchisholm> bert - sound like SDOs can use whatever they want, but need framework
[11:40:14] <sharonchisholm> Berard - for MIBs, people can do their own MIBs without coming here. With Radius extentions, they have to. It's a bottlebeck. Get to Radius doctors
[11:40:41] <sharonchisholm> Bernard - allowing them to do the work so long as they follow the guidelines
[11:41:07] <sharonchisholm> Dave h - needs some wordsmithing. Want people to do work as if it will fit instead of doing odd encodings
[11:41:17] <sharonchisholm> Bert - so not nullifying work from years ago
[11:41:49] <sharonchisholm> Glenn - vendor speciufic number space seems to have worked ok. Certainly some attributes from SDOs are bizare, but they have not crowded out the standard space
[11:41:59] <sharonchisholm> Glenn - if it isn't broken, why fix?
[11:42:05] <sharonchisholm> sound like we don't want to do this
[11:42:20] <sharonchisholm> q - if ipsec is not the right way to encrypt attributes ... what is the right way
[11:42:46] <sharonchisholm> with TLS it enables more application layer stuff
[11:42:55] <sharonchisholm> let's not rathole on that
[11:43:06] <sharonchisholm> Dave h - you are over time
[11:43:20] <sharonchisholm> Dave - negative 15 minutes left
[11:43:46] <sharonchisholm> From Wolff draft - four distrinct types of syntax
[11:44:41] <sharonchisholm> criteria for evaluating extended attribute format
[11:46:26] <sharonchisholm> advantages of diameter-based encoding
[11:46:58] <sharonchisholm> diameter avp header
[11:48:03] <sharonchisholm> Issues addressed by Wolff draft
[11:48:45] <sharonchisholm> questions
[11:48:54] <sharonchisholm> extended attributes in access-reject?
[11:49:01] <sharonchisholm> range of diameter code points/
[11:49:29] <sharonchisholm> ------------------
[11:49:31] <evbergen> VSAs are allowed in access rejects, if we want vendors to use extended attributes, then those should be allowed too
[11:49:59] <sharonchisholm> a proposal for extended radius attributes
[11:50:17] <sharonchisholm> why an extended attribute? (part of the charter)
[11:50:56] <sharonchisholm> 253 is too short
[11:51:08] <sharonchisholm> <zipping through slides>
[11:51:32] <sharonchisholm> value data types
[11:52:04] <evbergen> Glen, that's meta about attr, not meta about value
[11:52:16] <sharonchisholm> where we disagree ... diameter versus tagging-based argument
[11:52:32] <adekok> evbergen: Nope. RFC 2865 has "0" for VSA's in the table in 5.44
[11:52:35] <sharonchisholm> skip ahead to ascii art
[11:53:04] <sharonchisholm> back to wisper example
[11:53:16] <sharonchisholm> tag, child tag
[11:53:22] <sharonchisholm> overload things into strings
[11:54:28] <sharonchisholm> (I think overloading things into strings is generally evil, but I'm sure y'all have your reasons)
[11:54:48] <evbergen> (I didn't hear that completely?)
[11:54:58] <sharonchisholm> q - back to the WISPR example
[11:55:11] <sharonchisholm> q - hierachtical or flat? The guidelines mandate it?
[11:55:21] <sharonchisholm> hierachthical.
[11:55:33] <sharonchisholm> q - even existing drafts should follow this?
[11:55:40] <sharonchisholm> that is the issue we talking about earlier
[11:55:46] <sharonchisholm> do you like it or not?
[11:55:47] <evbergen> Only use ext-attr if needed: longer or structured data
[11:56:06] <sharonchisholm> q - nested structure is fine. following a specific format is another question
[11:56:36] <sharonchisholm> q - have to move on with existing drafts. what is the guidance from the working group. Should they redo their work? Or is this from now on
[11:57:02] <sharonchisholm> There is obviously a timing issue. if we complete this by June, the the later stuff will have lots of time.
[11:57:11] <sharonchisholm> If this drags on, then not so much
[11:57:30] <sharonchisholm> Bernard - only adopt a rule you can live with. Don't adopt and then look for exceptions
[11:58:13] <sharonchisholm> Dave m - actually moved at this time to try and figure out what the wg charter actually is
[11:58:30] <sharonchisholm> Dave m - one hand - guidelines to radius developers out there. the other things is creeping functionality
[11:58:39] <sharonchisholm> Dave m - put diamter functionality into radius
[11:58:58] <sharonchisholm> Dave m - those two goals would want us to do things separetly
[11:59:11] <sharonchisholm> we have separate documents
[11:59:39] <Barney> wolff draft is NOT intended to allow arbitrary Diameter stuff, but to format RADIUS stuff
[11:59:48] <sharonchisholm> Dave m - I think we should take some of the ideas and turn them into something that solves problems I will discuss later
[12:00:22] <sharonchisholm> Dave h - MIB are reviewe using guidelines. we want something similar and quickly
[12:00:25] <sharonchisholm> ------------------
[12:00:27] <sharonchisholm> Issues and Fixes
[12:00:36] <sharonchisholm> -02
[12:01:20] <sharonchisholm> open issues 107, 142, 146
[12:01:45] <sharonchisholm> statistics errors in MIBs
[12:01:56] <sharonchisholm> How many people have read the document
[12:02:01] <sharonchisholm> the chair and one other person
[12:02:04] <evbergen> read it too
[12:02:13] <sharonchisholm> need more input.
[12:02:16] <sharonchisholm> let's move on.
[12:02:18] <sharonchisholm> -------------------
[12:02:43] <sharonchisholm> Diameter NASreq and radius compatibility (Dave Mitton)
[12:03:08] <sharonchisholm> presented this draft in previous meeting ... recently resubmitted with minor changes
[12:03:18] <sharonchisholm> not going to go through all the slides
[12:03:43] <sharonchisholm> in RFC 4005, section 9, which discusses translation, there are some VSA issues which were not solved there
[12:03:55] <sharonchisholm> this group needs to take this item on if they want solutions
[12:04:06] <sharonchisholm> He can't defined what radius is
[12:04:24] <sharonchisholm> 4005 is what it is. Could be fixed in Diameter group
[12:04:52] <sharonchisholm> problem with VSA is only a suggestion. Not even a recommendation. Diamter has huge code spaces. Lots of divergence.
[12:04:58] <sharonchisholm> <pretty picture>
[12:05:17] <sharonchisholm> Goals - bidirectional communication
[12:05:35] <sharonchisholm> previous presenters brought up some interesting issues
[12:05:44] <sharonchisholm> opportunities to merge all this work together.
[12:05:52] <sharonchisholm> slide 8
[12:06:22] <sharonchisholm> radius vsa -> diamter AVP .... just drop the stuff in
[12:07:20] <sharonchisholm> Diameter Vendor Attributes -> Radius VSA
[12:07:28] <sharonchisholm> (error in slide 10)
[12:08:02] <sharonchisholm> slide 11
[12:08:19] <sharonchisholm> slide 12
[12:08:33] <sharonchisholm> generic avp to radius attribute
[12:08:41] <sharonchisholm> slide 13
[12:08:56] --- j.schoenwaelder@jabber.eecs.iu-bremen.de has left
[12:09:18] <sharonchisholm> if we want to take something like this. we need a document and to coordinate with diameter
[12:09:38] <sharonchisholm> Glenn - one little problem.
[12:09:42] <sharonchisholm> there are lots of problems
[12:09:46] <evbergen> Dave M: I think my draft provides a superset of what you want to do?
[12:10:33] <sharonchisholm> Glenn - when you talk about putting stuff into diamter attributes, this kind of works. You can fit lots of radius packets into a single diameter avp.
[12:10:47] <sharonchisholm> Glenn - working on a way to send very large radius message right now
[12:11:13] <sharonchisholm> Glenn - think it is a major problem. I single diamter AVP can't fit into a single radius packet. only have 4096
[12:11:38] <sharonchisholm> Glenn - in conjucntion to this. figure out how to send diamter avp in radius, which will require multiple messages
[12:11:41] <sharonchisholm> charter issues
[12:11:52] <sharonchisholm> Glenn - i think you can do it without adding a new message, so perhaps not
[12:11:57] <sharonchisholm> Glenn - still thinking about it
[12:12:06] <sharonchisholm> -----------------
[12:12:07] <sharonchisholm> Pre-paid
[12:12:09] <Barney> That there are some Diamter messages that cannot be translated to RADIUS because of length does NOT inply that no Diamter AVP can be encapsulated in RADIUS.
[12:12:28] <sharonchisholm> -10
[12:12:41] <sharonchisholm> Aligned with Diameter credit control
[12:13:00] <sharonchisholm> balance check; price equity
[12:13:07] <sharonchisholm> detailed example message flows
[12:13:59] <sharonchisholm> high level description of translation agent betwee radius prepaid and diamter credit-control for scenarios
[12:14:37] <sharonchisholm> Glenn - I read this new draft .. it seems that removing authorize only decreased the quality of the document. it hurt interoperability. I would put that back in
[12:14:49] <sharonchisholm> in the issues fixes thing ... it was taken out
[12:15:07] <sharonchisholm> Glenn - it says that you need <somthing> in <something> ... We would have a state attribute
[12:16:09] <sharonchisholm> Bernard - the issue is that radius historically has not authentication in the access request. You can DOS the radius server. That is why authorize-only was a no-no. You needed to be able to tie back to something or re-authenticate
[12:16:17] <sharonchisholm> radius guideline draft alignment
[12:17:08] <sharonchisholm> radius pp versus diameter-cc
[12:17:55] <sharonchisholm> open issues
[12:18:11] <sharonchisholm> translation between Radius prepaid and diamter credit control
[12:18:41] <sharonchisholm> Next steps - what we should we do with this draft?
[12:18:54] <sharonchisholm> wimax has a commitment for this draft
[12:18:59] <sharonchisholm> nwg accounting
[12:19:22] <sharonchisholm> bernard - our process is to start a pre-working group review
[12:19:45] <sharonchisholm> Glenn - nothing to do with this draft ... for my information ... not sure what the point of a pre-working group review thing is
[12:20:03] <sharonchisholm> Glenn - it seem that the working group is wroking on it .... I don't understand
[12:20:11] <sharonchisholm> Berard - it gets people to read it
[12:20:11] --- jsalowey has left: Disconnected
[12:20:20] <sharonchisholm> Bernard - we now have this requirement for 5 reviews
[12:20:40] <sharonchisholm> Bernard - if we can't get 5 people to review, we don't want it
[12:20:56] <sharonchisholm> Bernard - trying to get people to read the document .... any ideas
[12:21:05] <sharonchisholm> Glenn - we may tuitions and assign us reading
[12:21:12] <sharonchisholm> bernard - no that doesn't work in university
[12:21:23] <evbergen> reduce size and complexity by 90 %
[12:21:39] <sharonchisholm> (if people care about the problem, wouldn't they read it, so if they don't rea dit .....)
[12:22:05] <xrtc> why is prepaid a charter item, then?
[12:22:57] <sharonchisholm> Dan (private citizen) - this is a procedure for this particular working group
[12:23:21] <sharonchisholm> Dan - believe in principle it is good. We are not dealing with infinite resources. Not at any level (IESG, RFC)
[12:23:39] <sharonchisholm> Dan - having working group sending more stuff to standards strack isn't good
[12:23:47] <sharonchisholm> Dan - testing interest is goo
[12:23:49] <sharonchisholm> good
[12:23:51] <sharonchisholm> ------------------
[12:23:59] <sharonchisholm> Carrying Location Objects in RADIUS
[12:24:18] <sharonchisholm> status update
[12:24:57] <sharonchisholm> open issues
[12:25:04] <sharonchisholm> attribute format
[12:25:46] <sharonchisholm> questions?
[12:25:55] <sharonchisholm> -----------------------
[12:26:10] <evbergen> timing: can you wait for a completed design for structured attributes?
[12:26:16] <sharonchisholm> Bernard - I have a comment ... don't seem to be converging fast enough on this document
[12:26:34] <sharonchisholm> Bernard- this is needed. People want it done. The present way of doing things doesn't seem to work
[12:26:48] <sharonchisholm> Bernard - how do we finish this no later then the next
[12:27:00] <sharonchisholm> Bernard doesn't want to be in this room talking about this in the next ietf
[12:27:11] <sharonchisholm> (technically, he'll be in Montreal talking about it)
[12:28:03] <sharonchisholm> Dave h - along the lines we had discussed for complex attributes ... opaque ones and those where they do. Because this is an attribute with multiple fields
[12:28:13] <sharonchisholm> Dave h - is this one of those attributes that will be opaque
[12:28:22] <sharonchisholm> Dave h - the answer to that question will help
[12:28:32] <sharonchisholm> Bernard - I think it does have to be picked apart
[12:28:46] <sharonchisholm> Bernard - then this implies that the sub attribute structure does not work
[12:28:57] <sharonchisholm> Bernard - location-based authentication is used
[12:29:06] <sharonchisholm> Bernard - I think it needs to be picked apart
[12:29:08] <evbergen> I agree that location has to be parseable at the policy level
[12:29:24] <evbergen> It would be a good candidate for using either separate attributes, or subattributes.
[12:29:44] <sharonchisholm> Q - another class of token blobs ..
[12:29:52] <sharonchisholm> Q - carried by different things
[12:30:02] --- xrtc has left
[12:30:14] <sharonchisholm> Bernard - DHCP ... wish he was here
[12:30:28] <sharonchisholm> Bernard - i think here we need to parse it
[12:30:29] <adekok> Q: is the format defined *only* here in this document, or is it taken from a normitive reference? The authors have been asked on radext, and haven't responded. The answer to that wil make a difference to how this document moves forward
[12:31:17] <sharonchisholm> <channeling jabber>
[12:31:31] <sharonchisholm> Yes, it is defined elsewhere
[12:31:45] <adekok> that addresse sthe pcking issue
[12:31:47] <sharonchisholm> Dave h - what are the next steps on this
[12:31:58] <adekok> ... packing
[12:32:13] <sharonchisholm> Bernard - get people who will implement to read it
[12:32:28] <sharonchisholm> Bernard - location and radius people don't tend to get together
[12:32:44] <sharonchisholm> Dave h - if not last comments ... we are done
[12:32:52] <sharonchisholm> Dave h - blue sheets ... blue sheets
[12:32:55] <sharonchisholm> Done
[12:32:58] <Barney> Thanks Sharon!
[12:33:01] --- Fang has left
[12:33:03] <evbergen> Thanks!
[12:33:17] --- adekok has left
[12:33:23] --- sharonchisholm has left
[12:34:13] --- Barney has left
[12:36:01] <evbergen> Can we use this session to continue an informal discussion of the issues presented, or is that a bad idea?
[12:37:03] <evbergen> (it seems a non-starter)
[12:37:12] <evbergen> Ok, bye folks
[12:37:30] --- evbergen has left
[12:37:51] --- Dave Nelson has left
[12:42:01] --- Thierry has left
[12:48:25] --- HannesTschofenig has left
[12:58:33] --- Jelte Jansen has left
[14:19:07] --- bert has left
[16:45:54] --- gdweber has joined
[16:46:22] --- gdweber has left