Re: [radext] Extended IDs

["Brian Weis (bew)" <[e-mail]>]

I’ve read through the latest versions of both drafts, and I do prefer the approach taken in draft-chen-radext-identifier-attr.

From a protocol perspective, the two approaches do not seem very far apart to me. They both seem to do the following. (1) Define a new per-connection attribute as part of a Status-Server message. (2) Specify that a client chooses when to use a larger identifier. (3) Specify that when the server recognizes the “new extended field”, then it is obligated to return the original values of both identity field and the “new extended field”. (4) The server need not have any knowledge as to how the “new extended field” is determined.  (5) If the server does not recognize the new attribute, it ignores it. So in neither case do that the mechanism seem to unduly modify RADIUS.

It seems to me that the real difference comes down to how the “new extended field” is carried — either in the new per-connection attribute, or by overloading the Request Identifier. I appreciate the arguments in draft-dekok that indicate that there should not be a problem with overloading, but because overloading protocol fields can carry unexpected risks my preference is to adopt the explicit approach in draft-chen. With the same thought process I’m a little worried about defining "behavior previously left open to implementation interpretation” (as mentioned in Section 2.1 of draft-dekok). I cannot disagree that it “should" be OK, but the lack of certainly does add some risk.

However, I also believe that there is a lot of good background and explanatory text in draft-dekok that is valuable and if the working group takes draft-chen as the base then some of this would be valuable to bring that into the draft. This might address some of the concerns that draft-chen is under-specified.

Thanks,
Brian

> On Nov 28, 2017, at 5:54 AM, Stefan Winter <[e-mail]> wrote:
> 
> Hello,
> 
>> thanks all for raising the awareness of these two drafts.
>> 
>> 
>> I think it would be good if all remaining readers of this list who care
>> enough now take some time to read both drafts and make up their mind on
>> what the preferred approach is.
>> 
>> 
>> In approx. two weeks' time I will start a call for adoption on both
>> drafts, and hopefully there are enough responses to make the exercise
>> meaningful. If so, the one with more votes wins.
> 
> Now that was a relaxed "two weeks" delay. My apologies, I've been on and
> off work for a while, with substantial backlogs.
> 
> This email starts a two week call for adoption of at most one of the
> following two drafts:
> 
> * draft-chen-radext-identifier-attr-02
> * draft-dekok-radext-request-authenticator-02
> 
> Since the two drafts treat the same topic, at most one can be selected
> to serve as the basis for future work.
> 
> In your reply to this call for adoption, please indicate which of the
> two drafts you think should be adopted. You can of course also indicate
> that none of the two are fit for purpose. The only thing you really
> shouldn't do is to vote for both; that wouldn't help the discussion move on.
> 
> Please reply by 12 dec 2017 2400 UTC.
> 
> Greetings,
> 
> Stefan Winter
> 
> -- 
> Stefan WINTER
> Ingenieur de Recherche
> Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
> 2, avenue de l'Université
> L-4365 Esch-sur-Alzette
> 
> Tel: [phone]
> Fax: [phone]
> 
> PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me
> 
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
> 
> <0x8A39DC66.asc>_______________________________________________
> radext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/radext

-- 
Brian Weis
Security, CSG, Cisco Systems
Telephone: [phone]
Email: [e-mail]