ipfw table add problem

[Mark Andrews]

In message <5293EBD6.8010009 at 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 at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org