Subject: FW: inconsistency in RFC 5176

From: "Murtaza Chiba (mchiba)" <[email-masked]>
Date: Wed, 13 Feb 2008 18:21:48 -0800

-----Original Message-----
From: Alfred HÎnes [mailto:[email-masked]] 
Sent: Wednesday, February 13, 2008 5:51 PM
To: Murtaza Chiba (mchiba); Gopal Dommety (gdommety); Mark Eklund (meklund); [email-masked]
Cc: [email-masked]
Subject: inconsistency in RFC 5176

Hello,
after studying the recently published RFC 5176 (RADIUS Dyn.Auth.) authored by you, I stumbled over an apparent serious inconsistency in Section 3.5 of that memo.

The first clause there (on page 16) says:

3.5.  Error-Cause

   Description

      It is possible that a Dynamic Authorization Server cannot honor
      Disconnect-Request or CoA-Request packets for some reason.  The
      Error-Cause Attribute provides more detail on the cause of the
|     problem.  It MAY be included within CoA-NAK and Disconnect-NAK
|     packets.

The last sentence is consistent with the tables in Section 3.6 (pages 20..22) that also exclude the use of the Error-Clause Attribute for the CoA-ACK and Disconnect-ACK messages/packets.

But surprisingly, the text in the "Value" clause in Section 3.5, from the bottom of page 16 until page 18 repeatedly deals with inclusion or non-inclusion of the Error-Clause Attribute into the CoA-ACK and Disconnect-ACK messages/packets.  Some of these sentences are only confusing, but those that state applicability of the Error-Clause Attribute contradict the intent ot the other parts of the memo.

Please check.

I suggest that this issue should be resolved by RFC Errata Notes invalidating/removing all phrases in the "Value" clause that mention CoA-ACK and Disconnect-ACK.

Kind regards,
  Alfred HÎnes.

P.S.: Due to inappropriate blackholing of DNS requests, apparently
      caused by packet filtering based on *sorce* port somewhere
      in Redmont, I cannot send a copy of this message to your
      co-author Bernard Aboba.  Please arrange to forward to him
      a copy of this message -- thanks in advance.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 14 Feb 2008 15:06:30 -0800

There is no contradiction here.   Section 3.5 says:

"Values 200-299 represent successful completion, so that these
 values may only be sent within CoA-ACK or Disconnect-ACK packets
 and MUST NOT be sent within a CoA-NAK or Disconnect-NAK packet."

There are only two values in the range 200-299 which are defined:

      201    Residual Session Context Removed
      202    Invalid EAP Packet (Ignored)

Error 202 is explicitly prohibited for use by RFC 5176 implementations:

      "Invalid EAP Packet (Ignored)" is a non-fatal error that MUST NOT
      be sent by implementations of this specification.

Error 201 is also not currently defined for use with RFC 5176 since it
refers to removal of key context, not modification or disconnection of
sessions.

Therefore,  Section 3.5 and 3.6 are in agreement.

> after studying the recently published RFC 5176 (RADIUS Dyn.Auth.) authored 
> by you, I stumbled over an apparent serious inconsistency in Section 3.5 
> of that memo.
>
> The last sentence is consistent with the tables in Section 3.6 (pages 
> 20..22) that also exclude the use of the Error-Clause Attribute for the 
> CoA-ACK and Disconnect-ACK messages/packets.
>
> But surprisingly, the text in the "Value" clause in Section 3.5, from the 
> bottom of page 16 until page 18 repeatedly deals with inclusion or 
> non-inclusion of the Error-Clause Attribute into the CoA-ACK and 
> Disconnect-ACK messages/packets.  Some of these sentences are only 
> confusing, but those that state applicability of the Error-Clause 
> Attribute contradict the intent ot the other parts of the memo.
>
> Please check.
>
> I suggest that this issue should be resolved by RFC Errata Notes 
> invalidating/removing all phrases in the "Value" clause that mention 
> CoA-ACK and Disconnect-ACK.
>
>
> Kind regards,
>  Alfred HÎnes.
>

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 15 Feb 2008 12:19:27 +0700

Bernard Aboba <> scribbled on Friday, February 15, 2008 6:07 AM:

> values may only be sent within CoA-ACK or Disconnect-ACK packets  and
> MUST NOT be sent within a CoA-NAK or Disconnect-NAK packet."  
> 
>       "Invalid EAP Packet (Ignored)" is a non-fatal error that MUST
>       NOT be sent by implementations of this specification.
> 
> Error 201 is also not currently defined for use with RFC 5176 since
> it refers to removal of key context, not modification or
> disconnection of sessions.  
> 

Thanks, Bernard, I was just about to respond in that very fashion,
except that the table headed "Disconnect Messages" in section 3.6
completely disallows the use of the Error-Cause Attribute in
Disconnect-ACK messages, while section 3.5 says; 

      "Residual Session Context Removed" is sent in response to a
      Disconnect-Request if one or more user sessions are no longer
      active, but residual session context was found and successfully
      removed.  This value is only sent within a Disconnect-ACK and MUST
      NOT be sent within a CoA-ACK, Disconnect-NAK, or CoA-NAK.

It seems that the table is in error to me.  BTW, I can't find anything
in the document that says that Error 201 is currently undefined; what am
I missing?

...

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 15 Feb 2008 07:11:58 -0800

Error 201 is defined.  However, RFC 5716 only defines to  how modify authorizations
or delete current sessions.  Presumably if a session were not active, then current
implementations would return a Disconnect-NAK or CoA-NAK, rather than a
Disconnect-ACK with Error-Code value 201. 

> From: [email-masked]
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: inconsistency in RFC 5176
> Date: Fri, 15 Feb 2008 12:19:27 +0700
>

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 16 Feb 2008 00:12:19 +0700

Error 201 is defined.  However, RFC 5716 only defines to  how modify
authorizations
or delete current sessions.  Presumably if a session were not active,
then current
implementations would return a Disconnect-NAK or CoA-NAK, rather than a
Disconnect-ACK with Error-Code value 201.  
 
OK, but shouldn't the Error-Cause attribute still be allowed in the
table?