From a carrier side, I have seen that there are quite a few CPEs in

But it is possible to configure chap without a chap password... right? the jungle misconfigured in this way. The issue is that some terminators see chap offered and then assume (probably quite rightly) that they can proceed with chap. Once they get to the stage where the far end does not offer a valid challenge they might drop the session. Other terminators (like cisco) will probably quite happily continue on to try PAP instead. On 27 April 2010 21:48, Philip D'Ath wrote:

If you don't have CHAP configured, it does not offer CHAP in the negotiation.  I have confirmed this myself.

What happens is the Telecom terminator (mostly seems to happen in the South Island) commences CHAP authentication.  This is wrong.  It should not do this if it is not offered in the IPCP exchange.

So you can either configure CHAP as an additional authentication method, or tell the router to refuse it.

-----Original Message----- From: nznog-bounces(a)list.waikato.ac.nz [mailto:nznog-bounces(a)list.waikato.ac.nz] On Behalf Of Anton Smith Sent: Wednesday, 28 April 2010 12:49 a.m. To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Xtra BBA Issue with Cisco 877

Hi, I've come across this myself recently:

I think that you might also find that the issue is that the cisco doesn't have a chap password configured, yet during negotiation it originally states that it can do chap. After which everything falls apart (quite strange behaviour actually - if the chap password is not configured it shouldn't state it can do chap for that connection).

Regards, Anton

Hi Philip, Twice in this thread you have talked about the CPE offering CHAP as an authentication in the IPCP 'exchange'. This is strange, because IPCP is an NCP, so does not run until after the Authentication phase. Typically, the authentication protocol to use is negotiated during LCP, which is before the Authentication phase. Perhaps you mean LCP? You've also said that the telecom box attempts to start CHAP. That would certainly be strange behaviour if you had not CONFACKed CHAP as the authentication protocol. Are you sure you are not sending a CONFACK for CHAP? Can you send through some logs showing this? That would be a pretty big bug in the PPP implementation on the far end, and I'd be very surprised if that hadn't been discovered and fixed a very long time ago. I suspect what you are really seeing is the Telecom box CONFREQing for CHAP, and you CONFACK it because CHAP is enabled by default. It may seem strange that Cisco routers CONFACK for CHAP when no CHAP password appears to be configured, however Cisco peers can have different passwords per authenticator - in the challenge message there is a Name field, and Cisco routers look in their internal password database (username <blah> password 0 <blah>) for the appropriate password to use for that CHAP session, matching the presented Name to the username. The CHAP username that is presented by Cisco peers is by default the local hostname. Because the username is known, and the password is not known if it exists until CHAP starts, it isn't entirely unreasonable that CHAP is CONFACKed unless explicitly denied. Generally, most Cisco peers are configured with "ppp chap password <blah>" which avoids needing to know the Name that the authenticator is going to present ahead of time. I guess you might want to file a bug/feature request with Cisco suggesting that CHAP is not CONFACKed unless "ppp authentication chap callin" is used, however that would change default behaviour of the PPP stack, so it might be hard to get done. Anyway, in my view this problem is on the local end of the link, not the Telecom end. I hope that clears up the problem you guys are seeing. Anton, LCP negotiates one authentication protocol to use, prior to the Authentication phase. If Authentication with the negotiated authentication protocol fails, PPP will not go back to LCP to ask for something else, the link will be torn down. Perhaps it would be a good idea to alternately try CHAP and PAP each time the link comes up, but that would be an implementation feature. Also CHAP passwords must be at least 1 character, so it's not possible to configured a blank password. On 30/04/2010, at 8:11 AM, Philip D'Ath wrote:

What's the point of configuring the CPE with the wrong CHAP username and password? At best, that will only perpetuate mis-configurations.

In this case, the issue is that CHAP is *not* offered, yet the carrier is proceeding to start a CHAP authentication session. If the CPE does not offer it in the IPCP exchange, then the carrier should not be trying to use it.

-----Original Message----- From: Anton Smith [mailto:anton(a)huge.geek.nz] Sent: Thursday, 29 April 2010 10:42 p.m. To: Philip D'Ath Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Xtra BBA Issue with Cisco 877

But it is possible to configure chap without a chap password... right?

From a carrier side, I have seen that there are quite a few CPEs in the jungle misconfigured in this way.

The issue is that some terminators see chap offered and then assume (probably quite rightly) that they can proceed with chap. Once they get to the stage where the far end does not offer a valid challenge they might drop the session.

Other terminators (like cisco) will probably quite happily continue on to try PAP instead.

On 27 April 2010 21:48, Philip D'Ath wrote:

...

If you don't have CHAP configured, it does not offer CHAP in the negotiation. I have confirmed this myself.

What happens is the Telecom terminator (mostly seems to happen in the South Island) commences CHAP authentication. This is wrong. It should not do this if it is not offered in the IPCP exchange.

So you can either configure CHAP as an additional authentication method, or tell the router to refuse it.

-----Original Message----- From: nznog-bounces(a)list.waikato.ac.nz [mailto:nznog-bounces(a)list.waikato.ac.nz] On Behalf Of Anton Smith Sent: Wednesday, 28 April 2010 12:49 a.m. To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Xtra BBA Issue with Cisco 877

Hi, I've come across this myself recently:

I think that you might also find that the issue is that the cisco doesn't have a chap password configured, yet during negotiation it originally states that it can do chap. After which everything falls apart (quite strange behaviour actually - if the chap password is not configured it shouldn't state it can do chap for that connection).

Regards, Anton

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

!DSPAM:22,4bd9e7e771242624047322!

On 30/04/2010, at 10:19 AM, Philip D'Ath wrote:

You are correct, LCP. However the Cisco CPE is *not* offering to do CHAP.

The Cisco CPE should not offer any authentication, it should only be sending authentication options in CONFACK or CONFNAK messages (unless you want bidirectional auth, which I assume you don't).

100% sure that CONFACK CHAP is not being sent.

Respectfully, I don't believe this, I'd have to see logs.

It only started happening about three months ago. Only on Telecom Xtra connections. And only in some regions (I would hazard a guess to say it is only happening in the South Island, but would need to look at those who have requested help).

I do not believe there is a bug in the Cisco implementation with regard to this. It is doing exactly what it is meant to be doing.

What I might do, for your own interest, is send a debug output off-list next time I run into one.

I would suggest that you also send such a debug to Telecom if there is a problem so that they can fix it. Feel free to send it to me if you want a second opinion first though! -- Nathan Ward