Subject: [radext] Ben Campbell's Discuss on draft-ietf-radext-coa-proxy-06: (with DISCUSS and COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 15 Aug 2018 12:55:09 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-radext-coa-proxy-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-radext-coa-proxy/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(This is a procedural DISCUSS. Hopefully it can be resolved easily, but I do
think it needs to be resolved prior to publication..)

This draft is standards track, yet it primarily serves to extend RFC 5176. That
RFC is informational. The shepherd writeup argues that this is okay because it
seems like 5176 should have been standards track. But the applicability
statement RFC 5176 explains why it was informational, and the reasons seem
convincing. Therefore I do not think it is appropriate to publish this draft as
Standards Track. I think it would be fine to progress it as Informational (or
even Experimental) if it included an applicability statement explaining why in
order to avoid the appearance of a standard masquerading as an Informational
RFC.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for a readable and understandable drafts. I have some additional
comments that do not rise to the level of a DISCUSS

Substantive Comments:

- I support Adam's DISCUSS point concerning the security properties of
Operator-NAS-Identifier. But I will let that play out in Adam's thread.

§3.1 and §3,3: Do the normative changes to Access-Request and
Accounting-Request mean that this draft needs to update documents other than
just RFC 5176?

Editorial Comments:

- The abstract and introduction explain how this draft updates 5176, which is
good. However, they avoid using the explicit term-of-art "Updates RFC 5176".
Doing so would help make things more explicit. (The RFC style guide recommends
doing this at least in the abstract.)

- Please expand PPTP and L2TP on first mention.

§3.1: I suspect some of the normative keywords in this section refer to
previously existing requirements rather than new requirements. If  so, they
should not be capitalized except in literal quotes.

§6: I think it would be helpful to mention the discussion in §4.3 in the
security considerations.

§7: It would be helpful for the IANA considerations to briefly summarize the
new attributes, so that a reader that started out reading the IANA
considerations doesn't have to flip back to §3.3 just to find out what they are.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 15 Aug 2018 21:14:26 -0400

On Aug 15, 2018, at 3:55 PM, Ben Campbell <[email-masked]> wrote:
> Standards Track.

  We may choose Informational for this document, because it has a normative dependency on RFC 5176.

  But I don't see how those two last sentences are related.  The argument which is convincing for 5176 is not applicable to this document.  So conflating the two applicability statements is simply not appropriate.

  i.e. the issues highlighted in Section 1.1 of RFC 5176 do not apply to this document.  Any applicability statement here would be *false* if it repeated (or even normatively referenced) the discussion in RFC 5176.

> I think it would be fine to progress it as Informational (or
> even Experimental)

  If it's Experimental, then any possible subsequent Standards track document would run into the same problem: 5176 is Informational.

  And if we're being realistic... I think we're past the point where we can expect RADIUS Information or Experimental documents to progress to Standards track.  I can't for the life of me think of a single RADIUS document which has progressed from Informational or Experimental to Proposed Standard.  And, the RADIUS WG is on the verge of shutting down, with no new work envisioned.

  And if 20+ years isn't enough to make RFC 2866 (RADIUS accounting) a Proposed Standard, then I suspect no further progress will be made in the next 20 years.

> if it included an applicability statement explaining why in

  "This document is Informational because it updates RFC 5176, which is itself Informational.  None of the applicability statements in Section 1.1 of RFC 5176 apply to this document."

  The document does not provide for normative changes to Access-Request or Accounting-Request packets.  As with other RFCs that define new RADIUS attributes (e.g. 5580), it does not update RFC 2865 or 2866.

  i.e. simply carrying a new attribute is not a normative change to those packets.

> doing this at least in the abstract.)

  Fixed.

> - Please expand PPTP and L2TP on first mention.

  Fixed.

> should not be capitalized except in literal quotes.

  The normative keywords do not refer to previously existing requirements.

> §6: I think it would be helpful to mention the discussion in §4.3 in the

  Sure.

> considerations doesn't have to flip back to §3.3 just to find out what they are.

  The latest draft has the updates.  IANA has the allocation ready, and it has been reviewed.

  Alan DeKok.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 15 Aug 2018 21:43:58 -0500

>   But I don't see how those two last sentences are related.  The argument which is convincing for 5176 is not applicable to this document.  So conflating the two applicability statements is simply…

Yes ... but you can't use this document at all without using 5176, and 5176
can't be standards-track as it discusses.  This is basically a
philosophical question of whether we can require strict compliance for just
a part of or an extension to a protocol that itself is not as strictly
defined.

-Benjamin

---

From: Ben Campbell <[email-masked]>
Date: Wed, 15 Aug 2018 23:05:40 -0500

> On Aug 15, 2018, at 8:14 PM, Alan DeKok <[email-masked]> wrote:
> 

What I had in mind was just a statement to the effect that, while this extension includes normative language, it is informational because it is based on RFC 5176, which is also informational.

However, I do not understand your point that the applicability statement from 5176 does not apply to this draft. It basically says that 5176 is informational because CoA has (or had) issues (security, architectural, etc) that made it inappropriate for standards track. Since this draft is fundamentally based on 5176, it seems like it would inherit those issues. Or do you think all those issues have been mitigated, either by this draft or others? (The answer is probably academic, in that it addresses the question about whether 5176 _should_ still be informational, which doesn’t change the fact that it _is_.)

---

From: Alan DeKok <[email-masked]>
Date: Thu, 16 Aug 2018 07:08:42 -0400

> What I had in mind was just a statement to the effect that, while this extension includes normative language, it is informational because it is based on RFC 5176, which is also informational.

  That makes sense.

> However, I do not understand your point that the applicability statement from 5176 does not apply to this draft. It b
> asically says that 5176 is informational because CoA has (or had) issues (security, architectural, etc) that made it inappropriate for standards track. Since this draft is fundamentally based on 5176, it seems like it would inherit those issues.

  Perhaps this is a matter of semantics.

  On one hand, any spec built on 5176 inherits it's properties, good or bad.  On the other hand, it would be inappropriate for the coa-proxy draft to have the same applicability text as 5176.  i.e. saying "this document is informational, because implementations of this document have issues".  That statement is simply false.

> Or do you think all those issues have been mitigated, either by this draft or others? (The answer is probably academic, in that it addresses the question about whether 5176 _should_ still be informational, which doesn’t change the fact that it _is_.)

  I think those issues are largely illusory, or have been mitigated since 5176 was published.  Since there is a complex topic, let me explain by quoting Section 1.1 of RFC 5176, and commenting on it:

  ...  While fixes are recommended,
   they cannot be made mandatory since this would be incompatible with
   existing implementations.

  I think we've moved on in the 10 years since that draft was published.  At this point, if implementations are insecure, it is entirely appropriate to mark them as non-compatible.

  RFC 5176 was *not* simply documenting a pre-existing proprietary protocol.  It was developed in the IETF, based on RFC 3576, which was also developed within the IETF.  The "compatibility with existing implementations" issue is a polite statement that there was no WG consensus to make it standards track.

  i.e. the vendors with incompatible / insecure implementations did not want their products to me marked as such.

   Existing implementations of this protocol do not support
   authorization checks, so that an ISP sharing a NAS with another ISP
   could disconnect or change authorizations for another ISP's users.

  That's called "trusting people you work with".  The cos-proxy document makes it clear that there are limited technical means to address abuses by trusted parties. The limited security of RADIUS is the root cause of this problem.  However, 20+ years of practice in roman environments shows that this trust is warranted.  Abuses have been negligible, or non-existent.

  The coa-proxy specification mandates not only reverse path checks, but *additional* checks not mentioned in 5176.  That would seem to mitigate the above security issues.

   Existing implementations utilize per-packet authentication and
   integrity protection algorithms with known weaknesses [MD5Attack].

 That statement is describing a fundamental property of RADIUS.  i.e. it could be applied to every single RADIUS specification, resulting in *zero* standards-track RADIUS specifications.

  i.e. I think it's safe to ignore that rationale as a reason for making the document Informational.

   Existing implementations lack replay protection.

 That statement is also describing a fundamental property of RADIUS.

   The approach taken with CoA commands in existing implementations
   results in a semantic ambiguity.  Existing implementations of the
   CoA-Request identify the affected session, as well as supply the
   authorization changes.  Since RADIUS Attributes included within
   existing implementations of the CoA-Request can be used for session
   identification or authorization change, it may not be clear which
   function a given attribute is serving.

  That statement is still true, and there was much discussion in the WG about it.  The WG refused even to make recommendations here, because vendors refused to have a spec that marked their implementations as incompatible.

  In practice, this ambiguity is not much of a problem.  The vendor documents what is needed, and RADIUS clients send it.

  In short, the reasons given in Section 1.1 of RFC 5176 are illusory in practice.  Or, they're a fundamental part of the RADIUS protocol, and applicable to all RADIUS specifications.

  Further, even if those reasons *are* true, issues of "compatibility with existing implementations" do not apply to the coa-proxy draft, because there are few existing implementations of it.  (i.e. FreeRADIUS, which does do sane things...)  On top of that, the coa-proxy draft leverages existing implementations... whatever they are.  And those implementations (while perhaps ambiguous) manifestly work.

  As such, IMHO, the applicability statement of RFC 5176 can be ignored in it's entirety.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 16 Aug 2018 07:11:23 -0400

Hmm... typos.  "roaming" environments.  not "roman" ones.  Among others.  I trust the reader will read past the typos to infer the intent.

> On Aug 16, 2018, at 7:08 AM, Alan DeKok <[email-masked]> wrote:
> 
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: Ben Campbell <[email-masked]>
Date: Mon, 20 Aug 2018 16:45:19 -0500

>  The document does not provide for normative changes to Access-Request or Accounting-Request packets.  As with other RFCs that define new RADIUS attributes (e.g. 5580), it does not update RFC 2865…

Just to be clear, I was thinking about actual normative text, not just the adding of a new attribute. The first paragraph of §3.1 says:

" When a Visited Network proxies an Access-Request or Accounting-Request packet outside of its network, it SHOULD include an Operator-Name attribute in the packet, as discussed in Section 4.1 of[RFC5580]”

The SHOULD is a new normative requirement that relates to Access-Request of Accounting-Request. I can accept that we are talking about “proxies that implement this extension”, if that is the intent. But if the intent was that proxies in general SHOULD do this, that seems different.

Thanks,

Ben.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 20 Aug 2018 17:50:42 -0400

> On Aug 20, 2018, at 5:45 PM, Ben Campbell <[email-masked]> wrote:
> 

  The intent was that the quoted sentence applied to implementations of this document.  Not to all RADIUS proxies, even if they didn't implement this spec.

  Alan DeKok.