Subject: [Pana] pana-pana Issue232: Error handling

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 27 Dec 2005 12:03:34 -0500

>5.11  Error Handling
>
>   A PANA-Error-Request message MAY be sent by either the PaC or the
PAA
>
>
>
>   when a badly formed PANA message is received or in case of other
>   errors.  The receiver of this request MUST respond with a
PANA-Error-
>   Answer message.  If the cause of this error message was a request
>   message, then the request MAY be retransmitted immediately without
>   waiting for its retransmission timer to go off.  
>
If one side has a perpetually broken request message, it sounds like 
this behaviour allows for very rapid exchange of a (broken) request, 
followed immediately by an error message, followed immediately by 
another (broken) request, etc. This could be a DOS attack on the PaC, 
PAA, and network.

>If the cause of the
>   error was a response message, the receiver of the PANA-Error-Request
>   message SHOULD NOT resend the same response until it receives the
>   next request.
>
>   Erroneous PANA messages may be exploited by adversaries to launch
DoS
>   attacks on the victims.  Unless the PaC or PAA rate-limits the
>   generated PANA-Error-Request messages it may be overburdened by
>   having to respond to bogus messages.  Limiting the number of error
>   notifications sent to a given peer during a (configurable) period of
>   time may be useful.
>  
>
This may not just be from an adversary, as I mention above, a legitimate

client with a bug could end up DOSing the network, particularly given 
the immediate retransmission upon receipt of an error generated by a bad

request.

>   When an error message is sent unprotected (i.e., no MAC AVP) and the
>   lower-layer is insecure, the error message is treated as an
>   informational message.  The receiver of such an error message MUST
>   NOT change its state unless the error persists and the PANA session
>   is not making any progress.
>  
>
"error persists and the PANA session is not making any progress" is not 
an actionable instruction for a programmer. "treated as an informational

message" doesn't mean much either. It sounds like you are trying to walk

a fence between trusting and not trusting the message. You have to pick 
one way or another, don't leave it up to the coder to guess what to do.

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana