Re: [radext] Extended IDs

["Naiming Shen (naiming)" <[e-mail]>]

Hi Astrid,

When you say draft-chin-radext-identifier-attr requires all proxies to
explicitly support this and test all the software; what do you think of
draft-dekok-radext-request-authticator would do to the proxy servers?
the connection is hop by hop, each hop has to support the new
mechanism in order to have nas-proxy-home_server working
with the extended-id in all the mechanisms. Just because the
draft-dekok-radext-request-authticator does not explain how to
do that, does not mean it can have the original software working
unchanged:-) We are talking about the feeling of half-baked;-)

Cheers,
- Naiming

> On Nov 28, 2017, at 12:18 PM, Astrid Smith <[e-mail]> wrote:
> 
> Hello,
> 
> I prefer the option laid out in
> draft-dekok-radext-request-authenticator-02, due to deficiencies in
> the other proposal (draft-chen-radext-identifier-attr-02).
> 
> I'm concerned about the extended Code field it defines: How should
> implementations treat messages where this Code differs from the Code
> in the RADIUS header?  The precedence is poorly defined and liable to
> cause issues.
> 
> The proposal also requires all proxies to explicitly support (by
> parsing and passing through, or by stripping) the Identifier
> Attribute; this requires protocol users to upgrade and test all the
> software in their RADIUS deployment before any clients may safely
> attempt to use the attribute.
> 
> It feels half-baked.
> 
> The request-authenticator proposal appears safe to deploy without
> upgrading the software of any proxies in the network.  As a maintainer
> of a RADIUS proxy I prefer this, and I suspect my customers would
> agree :)
> 
> -- 
> astrid smith     -------------------
> --<[ c y b e r  |  s o f t w a r e  |  e n g i n e e r ]>--
>    ------------                     ------------------
> 
> 
> 
> On Tue, Nov 28, 2017 at 02:54:32PM +0100, Stefan Winter 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
> 
> _______________________________________________
> radext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/radext