understanding the configure reject code - PPP

This is a discussion on understanding the configure reject code - PPP ; Hello, I would be glad if anyone helps me on understanding the configure reject code of the PPP negotiations. Consider a peer sending a configure request packet with options, say, 1, 2, 3, 5, 7, 8 (I gave this options, ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: understanding the configure reject code

  1. understanding the configure reject code

    Hello,
    I would be glad if anyone helps me on understanding the configure
    reject code of the PPP negotiations.
    Consider a peer sending a configure request packet with options, say,
    1, 2, 3, 5, 7, 8 (I gave this options, since they are generally
    negotiated). And consider the other peer replying this with a
    configure reject of all the options requested. As far as I learned,
    when an option is rejected the default will be handled for that
    option. In this case, for the options 1, 2, 7, and 8 I can understand
    what handling default means. For option 1, it means 1500 bytes of
    packet size, for option 2 all the control characters will be escaped
    and for options 7 and 8 no compression will be considered. For option
    3, Carlson states that it is meaningless to reject this option to
    switch to the other authentication protocol. He says it is useful to
    nak the unimplemented protocol to make the peer to switch to the other
    implemented one.
    My question is that; what will be considered when the requested option
    5 is rejected? It is told in the RFC 1661 that zero is inserted when
    this option is needed to be used. As far as I understood from this,
    none of the configuration packets exchanged will be checked for the
    uniqueness of the magic number and there will be a risk of the
    existence of a looped-back link in the case, when this option is
    rejected.

  2. Re: understanding the configure reject code

    x_mckay_x@yahoo.com (McKay) writes:
    > I would be glad if anyone helps me on understanding the configure
    > reject code of the PPP negotiations.
    > Consider a peer sending a configure request packet with options, say,
    > 1, 2, 3, 5, 7, 8 (I gave this options, since they are generally
    > negotiated). And consider the other peer replying this with a
    > configure reject of all the options requested.


    OK.

    > As far as I learned,
    > when an option is rejected the default will be handled for that
    > option.


    That's correct.

    > In this case, for the options 1, 2, 7, and 8 I can understand
    > what handling default means. For option 1, it means 1500 bytes of
    > packet size, for option 2 all the control characters will be escaped
    > and for options 7 and 8 no compression will be considered. For option
    > 3, Carlson states that it is meaningless to reject this option to
    > switch to the other authentication protocol.


    It's _incorrect_ to reject the Authentication Protocol option if you
    actually want to change the authentication protocol (you should
    instead send LCP Configure-Nak and request some other protocol).
    However, *some* really awful implementations reject it anyway in that
    particular case, so a _good_ implementation needs to be prepared to
    handle LCP Configure-Reject in this one case as meaning "please try
    another one."

    > He says it is useful to
    > nak the unimplemented protocol to make the peer to switch to the other
    > implemented one.


    Yes. The only reason you *should* send LCP Configure-Reject in
    response to the LCP Authentication Protocol option is if you simply
    refuse to authenticate yourself at all -- i.e., you either have no
    implemented protocols you can use to do so, or you have no
    credentials.

    > My question is that; what will be considered when the requested option
    > 5 is rejected?


    That's the Magic-Number option. Good implementations don't reject it.

    > It is told in the RFC 1661 that zero is inserted when
    > this option is needed to be used.


    That's correct. You can consider 0 to be the default.

    > As far as I understood from this,
    > none of the configuration packets exchanged will be checked for the
    > uniqueness of the magic number and there will be a risk of the
    > existence of a looped-back link in the case, when this option is
    > rejected.


    Not really. If the peer doesn't implement the Magic-Number option,
    and thus sends Configure-Reject back to you, then you know for certain
    that you're not talking to yourself when you see Configure-Reject. If
    you were, you'd never have seen that reject, since you know you
    implement it, and you wouldn't reject it.

    The one case this does leave open is if the link becomes looped-back
    later. That's very unlikely and very hard to detect (except by LCP
    Echo-Request). The Magic-Number option is *mostly* there to protect
    the initial handshake, since it's so often the case that the peer
    isn't running PPP at all, but is rather blindly echoing back all the
    bytes you send it.

    --
    James Carlson, IP Systems Group
    Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

  3. Re: understanding the configure reject code

    Thank you very much...

+ Reply to Thread