Date: Tue, 26 Nov 2013 11:39:40 +1100 From: Mark Andrews <marka@isc.org> To: Michael Butler <imb@protected-networks.net> Cc: freebsd-stable@freebsd.org Subject: Re: ipfw table add problem Message-ID: <20131126003941.1ACD9AD41B4@rock.dv.isc.org> In-Reply-To: Your message of "Mon, 25 Nov 2013 19:31:18 -0500." <5293EBD6.8010009@protected-networks.net> References: <CAAcX-AGDZbFn5RmhLBBn2PPWRPcsFUnea5MgTc7nuXGD8Ge53A@mail.gmail.com> <52911993.8010108@ipfw.ru> <CAAcX-AEt_i8RUfmMy6WLnER0X=uLk5A1=oj911k-nyMJEghRLw@mail.gmail.com> <529259DE.2040701@FreeBSD.org> <20131125152238.S78756@sola.nimnet.asn.au> <1385391778.1220.4.camel@revolution.hippie.lan> <20131126001806.27951AD3DBF@rock.dv.isc.org> <5293EBD6.8010009@protected-networks.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <5293EBD6.8010009@protected-networks.net>, Michael Butler writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/25/13 19:18, Mark Andrews wrote: > > > > In message <1385391778.1220.4.camel@revolution.hippie.lan>, Ian Lepore writes: > >> On Mon, 2013-11-25 at 15:30 +1100, Ian Smith wrote: > >>> On Sun, 24 Nov 2013 23:56:14 +0400, Alexander V. Chernikov wrote: > >>> > On 24.11.2013 19:43, =D6zkan KIRIK wrote: > >>> > > Hi, > >>> > > = > >> > >>> > > I tested patch. This patch solves, ipfw table 1 add 4899 > >>> > Ok. So I'll commit this fix soon. > >>> > > = > >> > >>> > > But, ipfw table 1 add 10.2.3.01 works incorrectly. > >>> > > output is below. > >>> > > # ./ipfw table 1 flush > >>> > > # ./ipfw table 1 add 10.2.3.01 > >>> > inet_pton() does not recognize this as valid IPv4 address, so it is > >>> > treated as usigned unteger key. It looks like this behavior is mention= > >> ed > >>> > in STANDARDS section. > >>> > > # ./ipfw table 1 list > >>> > > 0.0.0.10/32 0 > >>> = > >> > >>> I'm wondering if "so don't do that" is really sufficient to deal with = > >> > >>> this? If it's not recognised as a valid address, shouldn't it fail to = > >> > >>> add anything, with a complaint? I don't see how a string containing = > >> > >>> dots can be seen as a valid unsigned integer? > >> > >> It's still not clear to me that inet_pton() is doing the right thing. > >> Per the rfc cited earlier in the thread, it's not supposed to interpret > >> the digits as octal or hex -- they are specifically declared to be > >> decimal numbers. There's nothing invalid about "01" as a decimal > >> number. The fact that many of us have a C-programming background and > >> tend to think of leading-zero as implying octal doesn't change that. > > > > But it does result in unexpected results when there is code that > > does treat 070 as 56 not 70. Rejecting ambigious input is a good > > thing. Part of what inet_pton() was trying to do was to get rid > > of the ambiguity in address inputs by tightening up the specification. > > > > 10.2.3.70 is not ambigious > > 10.2.3.070 is ambigious > > > > When the "STANDARDS" section of the inet_pton() man page explicitly > defines the interpretation to be decimal, its rejection of a leading > zero or misinterpretation as octal defies that definition. It does not > say "decimal except when a leading zero is present". > > As long as the input string can be be properly interpreted as a decimal > number, it should be. > > Misinterpreting "10.2.3.01" as "0.0.0.10/32" without so much as a > warning from either inet_pton() or ipfw is an egregious breach of POLA, When inet_pton() implementations have been rejecting leading zero's since they were first written their can't be a POLA. There can be a difference but not a POLA. To make is now accept a leading zero would be a POLA as there is code that depends on leading zeros being rejected by it. > imb > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.15 (FreeBSD) > > iEYEARECAAYFAlKT69YACgkQQv9rrgRC1JKNKgCgj4WOaZ4neyDEdkbVyVDqoKbz > vf8AnRV3uv/LCzO+OjXiIGA6S8eGQqAm > =tjly > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131126003941.1ACD9AD41B4>