Re: [cti-cybox] IP Address Notation (or: I Love CIDR When It's Talking About More Than One IP Address)

["Kirillov, Ivan A." <ikirillov@mitre.org>]

>My preference would definitely be for ABNF (for field-level
>validation) but we should use the same approach for all the standards.
>Anybody strongly *opposed* to ABNF?

My only qualm with ABNF is that it’s not supported in JSON Schema for field-level validation; only regexes can be used [0].

[0] http://spacetelescope.github.io/understanding-json-schema/reference/regular_expressions.html

Regards,


Ivan



On 1/21/16, 4:24 AM, "Trey Darley" <trey@soltra.com> wrote:

>On 18.01.2016 12:01:40, Mark Davidson wrote:
>>
>> Would it make sense to start a spec type document so that these
>> conversations can be tracked there? IMO something like the twigs
>> document but for CybOX (or even do these in the twigs document, then
>> decide the tearline between STIX/CybOX later on would be fine). Just
>> so long as we have text that we are continually updating as progress
>> toward a spec I think we will be in good shape.
>> 
>
>Excellent feedback, Mark, spot-on! Ivan and I are currently discussing
>how we can most effectively pivot from Github wiki pages focused on
>proposals around specific issues to something more like a
>comprehensive draft spec. Both the STIX and TAXII SCs have set a good
>example for us to follow; the major outstanding question is how to
>deal with the nascent cti-common schema/library for constructs that
>span multiple CTI standards.
>
>
>> Note2: I’m making this comment off of
>> https://github.com/CybOXProject/schemas/wiki/CybOX-3.0:-Address-Object-Refactoring#ipv4-address-object---option-1.
>> If that’s not the right one, my comment should still be applicable
>> to whatever we’re doing.
>> 
>> Presuming we go with the optional /32, I would offer this text as a start:
>> 
>> Field Name: ipv4_address
>> Type: string
>> Description: An IP address or CIDR block denoting either a single IP
>> address or a range of IP addresses, respectively. The accept syntax
>> defines a required IP address (e.g., 1.2.3.4) with an optional
>> subnet mask (e.g., /32). Omitted subnet masks MUST be interpreted as
>> “/32”.
>> 
>
>Thanks for the draft normative text, Mark! (Ivan and I appreciate all
>the help we can get!)
>
>> 
>> Accept syntax: (Are we doing ABNF or regex for this? The regex for
>> IPs / CIDR blocks is kind of ugly:
>> http://blog.markhatton.co.uk/2011/03/15/regular-expressions-for-ip-addresses-cidr-ranges-and-hostnames/)
>> 
>
>My preference would definitely be for ABNF (for field-level
>validation) but we should use the same approach for all the standards.
>Anybody strongly *opposed* to ABNF?
>
>-- 
>Cheers,
>Trey
>--
>Trey Darley
>Senior Security Engineer
>4DAA 0A88 34BC 27C9 FD2B  A97E D3C6 5C74 0FB7 E430
>Soltra | An FS-ISAC & DTCC Company
>www.soltra.com
>--
>"It is always possible to add another level of indirection." --RFC 1925