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

[Trey Darley <trey@soltra.com>]

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

Attachment: signature.asc
Description: PGP signature