How do I setup a PPP dialer to present empty credentials?

dtbullock · ‎09-08-2011

I am trying to copy a setup from a Nortel IAX100 where the carrier provides two ATM PVC's over ADSL - one for voice (VoIP) and one for data (IP). Relevant lines from the backup of the IAX's configuration include the following for the PPP authentication over the voice circuit:

<wan_8_32>

</wan_8_32>

<pppsrv_8_32>

<ppp_conId1 userName="" password="" serviceName="" idleTimeout="0" ipExt="disable" auth="auto" useStaticIpAddr="0" localIpAddr="255.255.255.255" />

</pppsrv_8_32>

The null username and password for the PPP connection have me a bit stumped. Does the PPP connection not use any authenetication at all? (Is that possible/likely? How could I deubg it?) Or does does the IAX100 supply a chap/pap response with null credentails? (If so, how would I duplicate that using an instruction to a dialer interface?

I am configuring an 877 with 12.4T and advanced IP services.

Can anyone familiar with PPPoE and multiple ATM circuits help me along my path?

thanks,

David.

Peter Paluch · ‎09-08-2011

David,

The most probable explanation here is that the IAX is not requesting for any authentication, and does not actually expect any credentials to be sent to it.

This is verified very easily - simply configure your 877 with the PPPoE client and Dialer interface with no authentication whatsoever. If the connection does not come up, please perform these debugs and post them here:

debug ppp negotiation

debug ppp authentication

Best regards,

Peter

dtbullock · ‎09-08-2011

Great Peter, I will schedule some downtime and give that a try.

thanks,

David.

dtbullock · ‎09-09-2011

Thanks for your help. Using the debugs I was able to establish that the authenticator (ie. the ISP's router) sent a PPP CONFREQ asking my peer to use PAP authentication. I was able to add the following to my int dial:

ppp authentication pap callin

ppp pap sent-username foo password foo

Happily, even though I couldn't use the "ppp pap sent-username" to specify a null or empty username or password, the remote authenticator was happy with "foo", and gave me an IP address!

Richard Burts · ‎09-09-2011

David

Thanks for posting that you have solved the issue and what the solution was. This is very interesting and helpful. And it is especially gratifying that you solved your own problem.

+5 to you for this good information.

HTH

Rick

HTH

Rick

Peter Paluch · ‎09-09-2011

Hi David,

Very good thinking!

One issue, though: you do not need the ppp authentication pap callin command. That may, under circumstances, require that the IAX (or the ISP) authenticates to you, i.e. a completely opposite direction of authentication. That would undoubtedly fail, as the ISPs usually do not authenticate themselves to their customers.

If possible, please remove the ppp authentication pap callin command from your configuration - contrary to the popular belief, it is not used to authenticate via PAP to the other side but rather to request that the remote side authenticates to us using PAP.

You may be interested in reading this discussion as well:

https://supportforums.cisco.com/message/3424916#3424916

Best regards,

Peter

Alexander Maroukian · ‎09-09-2011

Hi David, Peter,

This thread is interesting to me and wanted to add my 2 cents. Please correct me if I am wrong.

Peter mentioned "callin" option in ppp authentication pap callin command,this is interesting to me.

It is correct that client does not need ppp authentication pap callin but if you setup for some reason other ppp connections or you have some security concerns you are using it.

In PPP we have unidirectional and bi-directional authentication. The "callin" keyword is added just because you want to make undirectional authentication and actually says you are calling. If it is not added the caller will require request for authentication (AUTH-REQ) from the other side. Of course if ISP or the other router is trying to call you then your router will require authentication this is the default behavior because it says require AUTH-REQ when you treat the connection as callin not when you call out.

Regards,

Alex

Peter Paluch · ‎09-10-2011

Hello Alex,

Thank you very much for joining the discussion!

The "callin" keyword is added just because you want to make undirectional authentication and actually says you are calling.

I believe this is not entirely correct.

The precise effect of the callin keyword is to make the ppp authentication pap/chap command apply only if the remote side initiates the PPP connection to us and not if we initiate the PPP connection to the other side. It is thus concerned with the "direction" of the PPP session - whether it is an incoming, callin connection, or an outgoing, callout connection. In essence, the callin (or its complementary keyword callout) make the authentication conditional - to take place only if the call is initiated in a particular direction. They do not change the direction of the authentication itself, however - they only change when and if the authentication will take place. The direction of the authentication itself will still be the same - the remote per will have to prove its identity to us.

Obviously, on dialed interfaces like analog modems or ISDN BRI, a router could both make a call (callout) or accept a call (callin). With fixed serial lines and PPP-over-whatever, the concept of callout or callin is much more blurred, and here, a so-called "default PPP direction" is used. On fixed serial interfaces, the PPP direction is considered as "dedicated" without any notion of a particular direction, and the callin/callout keywords have no effect: the remote side will always have to authenticate to us - obviously failing the authentication if the remote side is not prepared for that.

For PPPoE in particular, the default PPP direction is callout. Hence, on these interfaces, specifying the callin keyword means that the entire ppp authentication pap callin command will be inactive, as the connection is by default treated as callout.

It can be argued that using the callin keyword may add to the security of the device, as it will require authentication from the remote party if it "somehow" manages to call in. However, at the same time, because we are not using ordinary dial technologies anymore, the concept of dialling in/dialling out is very vague, as I explained earlier, and actually may lead to complications when establishing the PPP session. Therefore, my recommendation here is to avoid using this kind of command (ppp authentication pap callin) on interfaces that actually do not need to authenticate the other party - or be aware of all these issues.

The most important thing that I am fighting, however, is the idea that "this command allows us to prove our identity to the other party using PAP", or in other words, "in order to prove our identity to the remote party using PAP, we have to configure this command". That idea seems to be widely spread - and totally incorrect. We cannot impose our preferred authentication method on the other party when authenticating ourselves to the remote side - we can only agree or disagree to authenticate to the remote party using a particular protocol.

Best regards,

Peter

Alexander Maroukian · ‎09-10-2011

Hello Peter,

You have said what I mean but more precisely and detailed. Nice explanation, thank you.

You are right the ppp authentication command does not affect the ability to authenticate your router to the remote side, again I agree with you.

Best regards,

Alex

johnlloyd_13 · ‎09-10-2011

hi peter,

i second the motion. after that very interesting discussion of the 'callin' keyword. you broke the myth of our PPP setup thanks to you sir! i was able to verify it using one of our site (hoping not to fail, else i need to go onsite) that very weekend.

837#sh run int d0

Building configuration...

Current configuration : 208 bytes

!

interface Dialer0

ip address negotiated

encapsulation ppp

dialer pool 1

ppp authentication pap callin

ppp pap sent-username password

end

837#reload in 10

Reload scheduled for 00:32:40 SGT Sun Aug 28 2011 (in 10 minutes) by john on vty0 (203.x.x.x)

Proceed with reload? [confirm]

837#

***

*** --- SHUTDOWN in 0:10:00 ---

***

837#conf t

Enter configuration commands, one per line. End with CNTL/Z.

837(config)#int d0

837(config-if)#no ppp authentication pap callin

837(config-if)#do sh run int d0

Building configuration...

Current configuration : 177 bytes

!

interface Dialer0

ip address negotiated

encapsulation ppp

dialer pool 1

ppp pap sent-username password

end

837(config-if)#end

837#reload cancel

837#

***

*** --- SHUTDOWN ABORTED ---

***

837#reload

Proceed with reload? [confirm]

Connection to 202.x.x.x closed by foreign host.

>telnet 202.x.x.x

Trying 202.x.x.x...

Connected to 202.x.x.x.

Escape character is '^]'.

837>ena

Password:

837#sh run int d0

Building configuration...

Current configuration : 177 bytes

!

interface Dialer0

ip address negotiated

encapsulation ppp

dialer pool 1

ppp pap sent-username password

end

dtbullock · ‎09-10-2011

Resources I referred to included:

dtbullock · ‎09-10-2011

Hey guys, my understanding of the callin argument to ppp authentication is that it says "only bother authenticating the remote peer if it called me". It does not say anything about whether I need to authenticate to the remote peer or not ... that is decided by them.

In the debug ppp negotiation output, it clearly is an outbound call:

Vi4 PPP: Treating connection as a callout

If I configure my dialer with simply:

ppp authentication pap

ppp pap sent-username foo password foo

then when I send my first outbound CONFREQ, I say "hey, authenticate yourself with PAP":

Vi4 LCP: O CONFREQ [Closed] id 1 len 14

Vi4 LCP: AuthProto PAP (0x0304C023)

Vi4 LCP: MagicNumber 0x2C2857C0 (0x05062C2857C0)

Vi4 LCP: I CONFREQ [REQsent] id 129 len 18

Vi4 LCP: MRU 1492 (0x010405D4)

Vi4 LCP: AuthProto PAP (0x0304C023)

Vi4 LCP: MagicNumber 0x73FE221B (0x050673FE221B)

However, if I don't care about authenticating the peer I'm calling:

ppp authentication pap callin

ppp pap sent-username foo password foo

then I attempt to dictate less to the peer:

Vi3 LCP: O CONFREQ [Closed] id 1 len 10

Vi3 LCP: MagicNumber 0x24D3F426 (0x050624D3F426)

Vi3 LCP: I CONFREQ [REQsent] id 220 len 18

Vi3 LCP: MRU 1492 (0x010405D4)

Vi3 LCP: AuthProto PAP (0x0304C023)

Vi3 LCP: MagicNumber 0x3DCE5388 (0x05063DCE5388)

Yes, the "directionality" of PPP language is a headache!