Hi,
On Fri, 5 Mar 2021 19:07:45 +0000
Ryan Freeman <ryan.free...@uniserveteam.com> wrote:
> Full disclosure: this took place over the course of about a month, and
> I've done my best to include the relevant info..
>
> Unsure if this is really a bug, and I don't have a real diff for a fix, just a
> work-around, so misc it is.
>
> This is done with OpenBSD 6.8-stable, syspatch 001 through 012 installed.
> We considered trying -current, but noticed no activity in the npppd tree
> that might make a difference.
>
> 'old' and 'new' equipment types from upstream are both Juniper, though
> unsure of exact models. Old should be Juniper ERX of some type, new
> I only know this from packet capture: Juniper Networks/Unisphere(4874).
>
> I work for a small ISP and we are exploring the use of npppd(8) for
> termination of L2TP with incumbent for xDSL connections.
>
> Working with the provider, their 'old' equipment works fine[1], however,
> the 'new' network would always cause these errors upon receipt of Proxy AVP:
>
> Feb 5 14:13:13 edge9 npppd[86416]: l2tpd ctrl=2359 call=2685 Received bad
> ICCN: Attribute value is too long PROXY_AUTHEN_CHALLENGE 33 > 24
> Feb 5 14:13:13 edge9 npppd[86416]: l2tpd ctrl=2359 call=2685 SendCDN
> result=ERROR_CODE/2 error=WRONG_LENGTH/2 messsage=none
>
> Looking at RFC 2661, I can't actually figure where a limit of 24 is imposed,
> though I was tricked as I counted the bits on top of their chart which does
>
> From RFC 2661, "Proxy Authen Challenge (ICCN)" near page 37:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Challenge... (arbitrary number of octets) |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Looking at npppd's l2tp_subr.h where the error above comes from:
>
> #define AVP_MAXLEN_CHECK(_avp, _maxlen) \
> do { \
> if ((_avp)->length > (_maxlen) + 6) { \
> snprintf(emes, sizeof(emes), \
> "Attribute value is too long %s %d > %d", \
> avp_attr_type_string((_avp)->attr_type), \
> (_avp)->length - 6, (int)(_maxlen)); \
> goto size_check_failed; \
> } \
> } while (/* CONSTCOND */0)
>
> I drew wild conclusions that perhaps 24 + 6, which lines up with counting
> the bits on the RFC chart above, is how the limit was chosen.
Yes. The limit is come from MAX_CHALLENGE_LENGTH in ppp.h.
85 #define MAX_CHALLENGE_LENGTH 24
In RFC 2661,
This AVP MUST be present for Proxy Authen Types 2 and 5. The
Challenge field contains the CHAP challenge presented to the
client by the LAC.
Proxy Authen Challenge AVP is for "Proxy Authen Types 2 and 5".
Proxy Authen Type (ICCN)
(snip)
Defined Authen Type values are:
0 - Reserved
1 - Textual username/password exchange
2 - PPP CHAP
3 - PPP PAP
4 - No Authentication
5 - Microsoft CHAP Version 1 (MSCHAPv1)
It's for CHAP or MSCHAPv1. If MD5 is selected for PPP CHAP, the
challenge length for CHAP is 16 octet. The challenge for MSCHAPv1 is
also 8 octet, but npppd doesn't support MSCHAv1 anyway. So 24 must be
enough for RFC 2661.
I'd like to see the packet capture of ICCN from Juniper to see what is
happening. (what authen type is used.)
> After many more days of packet captures and head scratching, I specifically
> saw that in the RADIUS packet, within the Attribute Value Pairs, it was
> CHAP-Challenge, type 60, that was overflowing this size check.
>
> On to RFC 2865, page 59: https://tools.ietf.org/html/rfc2865#page-59
>
> 0 1 2
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> | Type | Length | String...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>
> Aha, this chart actually hits exactly 24. Still no mention of a hard
> size limit, the only thing it dictates is:
This is unrelated. It's 24 *bits*.
> Length
> >= 7
>
> Ultimately we managed to get this working by simply omitting the size check
> as such:
>
> Index: l2tp/l2tp_call.c
> ===================================================================
> RCS file: /cvs/src/usr.sbin/npppd/l2tp/l2tp_call.c,v
> retrieving revision 1.19
> diff -u -p -r1.19 l2tp_call.c
> --- l2tp/l2tp_call.c 5 Dec 2015 16:10:31 -0000 1.19
> +++ l2tp/l2tp_call.c 5 Mar 2021 17:46:12 -0000
> @@ -546,7 +546,8 @@ l2tp_call_recv_ICCN(l2tp_call *_this, u_
> dpi->last_recv_lcp.ldata = avp_attr_length(avp);
> break;
> case L2TP_AVP_TYPE_PROXY_AUTHEN_CHALLENGE:
> - AVP_MAXLEN_CHECK(avp, sizeof(dpi->auth_chall));
> + /* XXX: disable to try and skirt 'too long' errors */
> + /* AVP_MAXLEN_CHECK(avp, sizeof(dpi->auth_chall)); */
> memcpy(dpi->auth_chall, avp->attr_value,
> avp_attr_length(avp));
> dpi->lauth_chall = avp_attr_length(avp);
>
> We've been running this modified npppd for a week now, our upstream is happy
> that they can continue phasing out their 'old' gear, and our endusers are
Do you mean that the endusers can connect with the above diff?
> Neither myself nor my colleague can figure out how '24' is chosen for _maxlen,
> but as this finally got us moving forward, wanted to share what we had and see
> if we are on the right track.
diff --git a/usr.sbin/npppd/npppd/ppp.h b/usr.sbin/npppd/npppd/ppp.h
index 1bb8bfc6cf3..219b47c6172 100644
--- a/usr.sbin/npppd/npppd/ppp.h
+++ b/usr.sbin/npppd/npppd/ppp.h
@@ -82,7 +82,7 @@
#define MAX_USERNAME_LENGTH 256
#define MAX_PASSWORD_LENGTH 256
-#define MAX_CHALLENGE_LENGTH 24
+#define MAX_CHALLENGE_LENGTH 256
#define INADDR_IPCP_OBEY_REMOTE_REQ 0x00000000L
is better if it works.
> I am thinking that we would want a maximum length set there still, but perhaps
> it can be pushed up? I've seen many of those error types, all seem to stay
> below 100:
>
> Feb 8 11:42:53 edge9 npppd[86416]: l2tpd ctrl=5477 call=32713 Received bad
> ICCN: Attribute value is too long PROXY_AUTHEN_CHALLENGE 40 > 24
> Feb 8 11:42:53 edge9 npppd[86416]: l2tpd ctrl=5477 call=32713 SendCDN
> result=ERROR_CODE/2 error=WRONG_LENGTH/2 messsage=none
> Feb 8 11:42:54 edge9 npppd[86416]: l2tpd ctrl=5477 call=29504 Received bad
> ICCN: Attribute value is too long PROXY_AUTHEN_CHALLENGE 62 > 24
> Feb 8 11:42:54 edge9 npppd[86416]: l2tpd ctrl=5477 call=29504 SendCDN
> result=ERROR_CODE/2 error=WRONG_LENGTH/2 messsage=none
> Feb 8 11:43:01 edge9 npppd[86416]: l2tpd ctrl=5477 call=31527 Received bad
> ICCN: Attribute value is too long PROXY_AUTHEN_CHALLENGE 46 > 24
> Feb 8 11:43:01 edge9 npppd[86416]: l2tpd ctrl=5477 call=31527 SendCDN
> result=ERROR_CODE/2 error=WRONG_LENGTH/2 messsage=none
> Feb 8 11:43:06 edge9 npppd[86416]: l2tpd ctrl=5477 call=1626 Received bad
> ICCN: Attribute value is too long PROXY_AUTHEN_CHALLENGE 63 > 24
> Feb 8 11:43:06 edge9 npppd[86416]: l2tpd ctrl=5477 call=1626 SendCDN
> result=ERROR_CODE/2 error=WRONG_LENGTH/2 messsage=none
>
> [1] at some point over the course of debugging, I did notice that this
> error would /sometimes/ print on the connections from the 'old' equipment,
> but would continue to work anyway:
>
> Mar 5 10:21:44 edge9 npppd[35209]: ppp id=4108 layer=chap proto=unknown
> "Proxy Authen Challenge" is too long.
>
> This now also prints on all the 'new equipment' successful connections since
> disabling the AVP_MAXLEN_CHECK.
--
YASUOKA Masahiko http://yasuoka.net/~yasuoka/
mailto:yasu...@yasuoka.net mobile:090-8801-1637
