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

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 03 Jan 2006 20:23:25 -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.

I think you are right.  I don't see a reason to immediate
retransmission of request for the error message regardless of the
reason of the error.  We can simply remove the sentence in question.

> 
> >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.

Yes, and the above remedy should resolve the DoS caused by a bug.

> 
> >   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.

OK, how about changing to:

"
When an error message is sent unprotected (i.e., no MAC AVP) and the
lower-layer is insecure, the error message MUST be processed such that
the receiver does not change its state.
"

(I think that by not changing state error will persist with the PANA
session not making any progress, which will finally trigger an action
to terminate the session, so we don't need the "unless ..." clause.)

Yoshihiro Ohba

> 
> _______________________________________________
> Pana mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pana
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________
> 

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