Subject: Re: [pcp] option overflow/truncated option

From: "Dan Wing" <[email-masked]>
Date: Mon, 3 Oct 2011 14:21:11 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Francis Dupont
> Sent: Sunday, September 04, 2011 8:33 AM
> To: [email-masked]
> Subject: [pcp] option overflow/truncated option
> 
> Another formal question about a case I could name truncated option
> or option overflow (BTW this alternative is a part of the question :-):
>  - a request includes an option with length N (so on 4*(N+1) octets)
>  - the request truncates the option to less than 4*(N+1) octets or
>   with other words the request parsing goes after the end of the
>   request when it deals with the option
>  - BTW it is not part of the option processing but before, i.e.,
>   the response should not depend on the particular truncated /
>   overflowing option
>  - there is a similar issue about option headers but the 4 octet
>   alignment constraint should make impossible to exercise the
>   corresponding check code (BTW this doesn't mean the check is
>   optional :-)
>  - we have the choice between MALFORMED_OPTION and MALFORMED_REQUEST,
>   in fact it is a matter of taste between the error is in the option
>   or the error is in the request, IMHO both are valid...

How is this:

        If an invalid option
        length is encountered (e.g., option length extends beyond the 
        length of the PCP OpCode itself), the error MALFORMED_OPTION SHOULD
        be returned (rather than MALFORMED_REQUEST), as that helps the
        client better understand how the packet was malformed.</t>

-d

> Thanks
> 
> [email-masked]
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: Francis Dupont <[email-masked]>
Date: Tue, 04 Oct 2011 09:43:30 +0200

In your previous mail you wrote:

   How is this:
   
           If an invalid option
   
=> fine with this, thanks!