Subject: [Dime] Reg the Failed-AVP in CEA, DWA and DPA

From: "naveen sarma" <[email-masked]>
Date: Tue, 26 Jun 2007 18:03:34 +0530

Hi all,

Can anyone explain the significance of the Failed-AVP in the CEA message.
It is not mentioned in the RFC 3588 or 3588 4-bis, that if CER decoding
fails, CEA should be sent with 'E' bit set with the corresponding failed
AVP.

Have one more question regarding the Failed-AVP in the DWA, DPA signatures;
Its like *[Failed-AVP].  In the RFC 3588 or 3588 4-bis, its not mentioned
when the base protocol need to set the Failed-AVP in the DWA, DPA messages?

One more point is the probable action of an invalid Disconnect-Cause AVP
value received in the DPR is not mentioned in the 3588 or 3588 4-bis.  In
such cases, does the base protocol need to retain the connection and send
the DPA with 'E' bit set?

Regards,
Naveen.
_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: Victor Fajardo <[email-masked]>
Date: Tue, 26 Jun 2007 12:46:22 -0400

Hi Naveen,

> Hi all,
>  
> Can anyone explain the significance of the Failed-AVP in the CEA 
> message.  It is not mentioned in the RFC 3588 or 3588 4-bis, that if 
> CER decoding fails, CEA should be sent with 'E' bit set with the 
> corresponding failed AVP.
>
> Have one more question regarding the Failed-AVP in the DWA, DPA 
> signatures; Its like *[Failed-AVP].  In the RFC 3588 or 3588 4-bis, 
> its not mentioned when the base protocol need to set the Failed-AVP in 
> the DWA, DPA messages?

It seems Sec 7. and 7.2 already covers this. Is there something unclear 
in those sections ?

victor

>  
> One more point is the probable action of an invalid Disconnect-Cause 
> AVP value received in the DPR is not mentioned in the 3588 or 3588 
> 4-bis.  In such cases, does the base protocol need to retain the 
> connection and send the DPA with 'E' bit set? 
>  
> Regards,
> Naveen.
> ------------------------------------------------------------------------
>

---

From: "naveen sarma" <[email-masked]>
Date: Wed, 27 Jun 2007 12:03:16 +0530

Just forwarding to group...

---------- Forwarded message ----------
From: naveen sarma <[email-masked]>
Date: Jun 27, 2007 12:01 PM
Subject: Re: [Dime] Reg the Failed-AVP in CEA, DWA and DPA
To: Victor Fajardo <[email-masked]>

Hi Victor,

The sections 7 and 7.2 discussed possible cases of using the Failed AVP in
the protocol as well as application specific messages; with a phrase "In
case there are multiple errors, the Diameter node MUST report only the first
error it encountered (detected possibly in some implementation dependent
order)."

There are couple of points here:

1.  Consider a scenario like if the CER is received from a known
peer without the Host-Ip-Address AVP, which is not correct as per the ABNF
signature.  In this case, the receiver of CER will stop validating the whole
CER message, because of the first error.

In such case does the receiver of the CER needs to send CEA with Result-Code
AVP set to DIAMETER_MISSING_AVP and Failed-AVP as Host-Ip-Address AVP (or)
the CER is to be silently discarded and close the transport connection. This
point is not clear in the RFC 3588 or 3588 4-bis.  Can this be treated as
base protocol implementation specific?  If so there will be a problem in the
interop.

Even if the CEA has to be sent with the Failed-AVP, the receiver will always
fills the first encountered error.  So is the ABNF signature of CEA with
*[Failed-AVP] correct?  Since the Failed-AVP cannot be more than one, can we
make it [Failed-AVP]?

2.  The point that is not clear in the specs is that whether the receiver of
the DWR and DPR needs to validate the Origin-Host and Origin-Realm AVP
values?  Since the messages are received from the established transport
connection or from a peer with which capabilities are exchanged, can the
receiver simply by-pass the validation of these AVPs values.

If the receiver can by-pass the validation, there is no relevance of these
AVPs in the corresponding ABNF signatures.  If not, the specs can clearly
mention what action does the receiver need to take if the validation fails.

Can i know what the base protocol needs to do when the disconnect cause in
the DPR is not valid also?

Thanks & Regards,
Naveen

-- 
Yours
Naveen.

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 27 Jun 2007 08:48:54 -0400

Hi naveen,
>  
> The sections 7 and 7.2 discussed possible cases of using the Failed 
> AVP in the protocol as well as application specific messages; with a 
> phrase "In case there are multiple errors, the Diameter node MUST 
> report only the first error it encountered (detected possibly in some 
> implementation dependent order)."
>  
> peer without the Host-Ip-Address AVP, which is not correct as per the 
> ABNF signature.  In this case, the receiver of CER will stop 
> validating the whole CER message, because of the first error.
>  
> In such case does the receiver of the CER needs to send CEA with 
> Result-Code AVP set to DIAMETER_MISSING_AVP and Failed-AVP as 
> Host-Ip-Address AVP (or) the CER is to be silently discarded and close 
> the transport connection. This point is not clear in the RFC 3588 or 
> 3588 4-bis.  Can this be treated as base protocol implementation 
> specific?  If so there will be a problem in the interop.

The first scenario you mentioned is probably more appropriate since the 
capability exchange does not specify anything that overrides the default 
error handling in sec 7. Sending an error answer is useful for debugging 
a connection. Also, AFAIK the bis only mentions silently discarding a 
CER from an unknown peer.

>  
> 2.  The point that is not clear in the specs is that whether the 
> receiver of the DWR and DPR needs to validate the Origin-Host and 
> Origin-Realm AVP values?  Since the messages are received from the 
> established transport connection or from a peer with which 
> capabilities are exchanged, can the receiver simply by-pass the 
> validation of these AVPs values.

Its probably up to your implementation if you want to skip value 
validation for these AVPs.

>  
> If the receiver can by-pass the validation, there is no relevance of 
> these AVPs in the corresponding ABNF signatures.  If not, the 
> specs can clearly mention what action does the receiver need to take 
> if the validation fails.
>  
> Can i know what the base protocol needs to do when the disconnect 
> cause in the DPR is not valid also?

Following the same error handling rules in sec 7 with INVALID_AVP_VALUE 
seems useful in this case. BTW, the peer fsm forces the receiver of the 
DPR to close the connection and move to closed state regardless.

-- victor

---

From: "naveen sarma" <[email-masked]>
Date: Thu, 28 Jun 2007 00:24:03 +0530

Hi Victor,

I just want to know few things...

> validation for these AVPs.

Naveen >>> If this is implementation specific, and no usage as far as the
base protocol is concerned, i see no usage of these AVPs in the signatures.
Is there any other usage?

> DPR to close the connection and move to closed state regardless.

Naveen >>> In such case does the receiver need to attempt the re-connection
or not?

-- victor

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 27 Jun 2007 16:22:20 -0400

Hi naveen,
> Naveen >>> If this is implementation specific, and no usage as far 
> as the base protocol is concerned, i see no usage of these AVPs in the 
> signatures.  Is there any other usage?

The use is when implementations does the right thing and validate the 
value for the AVPs. Its up to your implementation if it wants to do the 
right thing.

> Naveen >>> In such case does the receiver need to attempt the 
> re-connection or not?

This is a policy decision from your implementation/deployment.

--victor

---

From: "harish raghuveer" <[email-masked]>
Date: Thu, 28 Jun 2007 20:31:13 +0530

CC'ing to mailing list. I am in favor of closing the connection in case of
invalid DPR. :-)

cheers,
Harish

On 6/28/07, Victor Fajardo <[email-masked]> wrote:
>
> Hi,
> >
> > I feel that the peer FSM should not close the connection and move to
> > closed state if the Origin-Host and Origin-Realm is incorrect in
> > DPR. If we do this, how do we know if the DPR originated at the
> > 'legal' or 'valid' transport end-point (if there is no end-to-end
> > security as well)?
>
> It is also possible that if a peer receives a DPR with an invalid value
> for origin-host and/or origin-realm, it sends a an answer with an error
> then close the connection. This is a lot safer than waiting for a DPR
> with a correct value on an already open transport connection. An invalid
> DPR can only mean that the peer is already malfunctioning or doing some
> malicious attack; in both cases, how can we trust it to eventually send
> a valid DPR. Besides, that peer is already implying that it wants to
> close the connection (even though its not very good at it) ... so why
> waste resources and keep an open connection waiting for the peer to
> correct itself. BTW, this will not involved end-to-end security, only
> peer based security.
>
> >
> > If the validation of these AVPs is 'optional' then they should
> > be 'informational' AVPs rather than 'mandatory AVPs' in all the
> > messages other than CER/CEA.
>
> I would dis-agree. First, it is there for a reason. Second, you will be
> breaking a many many existing implementations that is actually able to
> follow the spec properly.
>
> regards,
> victor
>
>

-- 
Harish R Prabhu
Ph:98457-34737 (M)