How should LCP handle invalid option length? - PPP

This is a discussion on How should LCP handle invalid option length? - PPP ; 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 ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: How should LCP handle invalid option length?

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


  2. Re: How should LCP handle invalid option length?

    In article <1161629189.126158.274500@i42g2000cwa.googlegroups. com>,
    Mark wrote:
    >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,


    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?

    >and
    >-the received config option length is < the received LCP information
    >field length.


    In this case, option parsing would continue with the byte following the
    last option byte of the current option.

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


    By trying to parse through the options, you afford yourself and your peer
    the hopeful ability to negotiate away the possibly bogus option(s).

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


    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.

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


    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.

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


    You don't NAK the entire LCP-Configure-Request, only specific options from
    within the LCP-Configure-Request.

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


    Again, you only NAK or REJECT options, not the entire packet.

    >Or, should a NAK be sent for the option first
    >detected to have the invalid length?


    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: patrick@klos.com
    Klos Technologies, Inc. Web: http://www.klos.com/
    ================================================== ==========================

  3. Re: How should LCP handle invalid option length?

    pklos@osmium.mv.net (Patrick Klos) writes:
    > >-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,

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


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

  4. Re: How should LCP handle invalid option length?

    James Carlson writes:

    >pklos@osmium.mv.net (Patrick Klos) writes:
    >> >-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,

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


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


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


    >--
    >James Carlson, KISS Network
    >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


+ Reply to Thread