How should LCP handle invalid option length?

I'd like input on how LCP should process a particular "class" of
invalid packet. Specifically, how should LCP process a configure
request where:

-an LCP configuration option is received where that option by
definition has a specific length, and
-the received config option length is > than the defined option length,
and
-the received config option length is < the received LCP information
field length.

These conditions mean an invalid option was received (the opt. len. was
bad). However, the "bad" option length is less than the info len...
SO... there MAY be other options remaining in the received LCP pkt.

I'm particulary curious if LCP should use the "bad length" to skip past
the invalid config option and continue processing further config
options. Using an invalid length doesn't seem wise to me, but I don't
think the spec. (RFC 1661) is clear on this particular case (where more
info bytes present after this invalid length option if this option's
length IS used).

Should LCP attempt to process more config options at the point in the
pkt as indicted if the bad option length is used?

If the answer is no, then the conf req should be NAK'd, ignoring other
options that MAY be present, where the NAK contains the option that
contained the invalid length. Correct?

If the answer is yes, then a NAK may be sent, depending on what's found
in the remaining LCP infomation bytes. If, after skipping the option
with the invalid length, another invalid option is found, should the
LCP conf req be REJECTED? Or, should a NAK be sent for the option first
detected to have the invalid length?

Mark

In article <1161629189.126158.274500@i42g2000cwa.googlegroups.com>,
Mark <mlawdawg@comcast.net> wrote:[color=blue]
>I'd like input on how LCP should process a particular "class" of
>invalid packet. Specifically, how should LCP process a configure
>request where:
>
>-an LCP configuration option is received where that option by
>definition has a specific length, and
>-the received config option length is > than the defined option length,[/color]

I suppose it would depend on WHICH option and whether or not such option
COULD be conceived to use a larger option value? Could you be more
specific?
[color=blue]
>and
>-the received config option length is < the received LCP information
>field length.[/color]

In this case, option parsing would continue with the byte following the
last option byte of the current option.
[color=blue]
>These conditions mean an invalid option was received (the opt. len. was
>bad). However, the "bad" option length is less than the info len...
>SO... there MAY be other options remaining in the received LCP pkt.[/color]

By trying to parse through the options, you afford yourself and your peer
the hopeful ability to negotiate away the possibly bogus option(s).
[color=blue]
>I'm particulary curious if LCP should use the "bad length" to skip past
>the invalid config option and continue processing further config
>options. Using an invalid length doesn't seem wise to me, but I don't
>think the spec. (RFC 1661) is clear on this particular case (where more
>info bytes present after this invalid length option if this option's
>length IS used).[/color]

Just parse the options without regard to their "defined length", and let
your LCP option handler decide what lengths it thinks a specific option
should be. Your basic "Control Protocol option parser" should not try
to take into account what it thinks the option length should be.
[color=blue]
>Should LCP attempt to process more config options at the point in the
>pkt as indicted if the bad option length is used?[/color]

Yes. If nothing else, you can LCP-Config-Nak or LCP-Config-Reject the
bad option(s) once you've parse the entire LCP packet.
[color=blue]
>If the answer is no, then the conf req should be NAK'd, ignoring other
>options that MAY be present, where the NAK contains the option that
>contained the invalid length. Correct?[/color]

You don't NAK the entire LCP-Configure-Request, only specific options from
within the LCP-Configure-Request.
[color=blue]
>If the answer is yes, then a NAK may be sent, depending on what's found
>in the remaining LCP infomation bytes. If, after skipping the option
>with the invalid length, another invalid option is found, should the
>LCP conf req be REJECTED?[/color]

Again, you only NAK or REJECT options, not the entire packet.
[color=blue]
>Or, should a NAK be sent for the option first
>detected to have the invalid length?[/color]

You parse through the entire packet, collecting all options. If there are
options you don't support at all, you send an LCP-Configure-Reject with
all the options you found that you don't support. Now you should only
have options that you support, even if not in their exact form as presented
in the LCP-Configure-Request, in which case you send a LCP-Configure-Nak
with all the options you support but don't like the supplied values for
the options (including option whose length and data look bogus to you).
Once you NAK all the options you support but don't like the current values
for, you should get a LCP-Configure-Request with a bunch of options that
looks good to both you and your peer (unless one or both of you are
broken?).

If you give us a packet dump for your scenario, we might be able to
provide better insight as to why the peer would present apparently
bogus options??

Patrick
=========== For PPP Protocol Analysis, check out PacketView Pro! ===========
Patrick Klos Email: [email]patrick@klos.com[/email]
Klos Technologies, Inc. Web: [url]http://www.klos.com/[/url]
============================================================================

[email]pklos@osmium.mv.net[/email] (Patrick Klos) writes:[color=blue][color=green]
> >-an LCP configuration option is received where that option by
> >definition has a specific length, and
> >-the received config option length is > than the defined option length,[/color]
>
> I suppose it would depend on WHICH option and whether or not such option
> COULD be conceived to use a larger option value? Could you be more
> specific?[/color]

Indeed. There are some options (particularly for CCP negotiation)
where this is known to happen. There are others where it really ought
not happen ever.

There are at least two schools of thought on this:

- One has it that you should try as hard as possible to make sense
out of what your peer has sent you. "Be liberal in what you
accept." This gives you the best chance of interoperability with
slightly out-of-spec implementations.

- The other says that if you detect that the peer has bugs, you're
better off shutting down the link and refusing access. You
shouldn't allow bug-ridden systems to attach to your network, and
fixing the bugs is preferred over accepting garbage.

The best answer is probably a mixture of both, depending on the
specifics of the case.

I'm almost certain there's a book somewhere that discusses these sorts
of implementation details. ;-}

--
James Carlson, KISS Network <james.d.carlson@sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

James Carlson <james.d.carlson@sun.com> writes:
[color=blue]
>pklos@osmium.mv.net (Patrick Klos) writes:[color=green][color=darkred]
>> >-an LCP configuration option is received where that option by
>> >definition has a specific length, and
>> >-the received config option length is > than the defined option length,[/color]
>>
>> I suppose it would depend on WHICH option and whether or not such option
>> COULD be conceived to use a larger option value? Could you be more
>> specific?[/color][/color]
[color=blue]
>Indeed. There are some options (particularly for CCP negotiation)
>where this is known to happen. There are others where it really ought
>not happen ever.[/color]
[color=blue]
>There are at least two schools of thought on this:[/color]
[color=blue]
> - One has it that you should try as hard as possible to make sense
> out of what your peer has sent you. "Be liberal in what you
> accept." This gives you the best chance of interoperability with
> slightly out-of-spec implementations.[/color]
[color=blue]
> - The other says that if you detect that the peer has bugs, you're
> better off shutting down the link and refusing access. You
> shouldn't allow bug-ridden systems to attach to your network, and
> fixing the bugs is preferred over accepting garbage.[/color]
[color=blue]
>The best answer is probably a mixture of both, depending on the
>specifics of the case.[/color]
[color=blue]
>I'm almost certain there's a book somewhere that discusses these sorts
>of implementation details. ;-}[/color]

Coy aren't you. You could at least help him find it. The author of this
book is listed below.

[color=blue]
>--
>James Carlson, KISS Network <james.d.carlson@sun.com>
>Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
>MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677[/color]