Re: [cti-cybox] Network Connection Object TCP Extension

Not necessarily the whole header right now, but we need to leave things so they can be extended if the community wants them to in the future. I guess the point is that we need to think about the future to some degree, allowing for future expansion, not locking things down now and removing the chance for future enhancements like this.

On 31/08/2016 10:44, "Jordan, Bret" <bret.jordan@bluecoat.com> wrote:

Do we really want to rebuild or capture the entire IP/TCP header in CybOX? Does that really make sense when there are other solutions that arguably do this much better? I think CybOX should capture the high level things that are important that meet the 80-90% use case and leave those other nitty-gritty things for another solution.

I could see this network connection just having a hex encoded libpcap or libpcap-ng data blob if you really wanted to to capture the packet, datagram, or frame headers.

Thanks,

Bret

Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

On Aug 30, 2016, at 15:45, Terry MacDonald <terry.macdonald@cosive.com> wrote:

I think we should keep them apart, but maybe with additional TCP fields in them like mss, tos, maybe even a boolean field for fragmented, and maybe a list of TCP options in there too.
Cheers
Terry MacDonald
Cosive

On 31/08/2016 08:46, "Jordan, Bret" <bret.jordan@bluecoat.com> wrote:
Given that the 90-95+% use case for the network connection object will be TCP and UDP, the src/dst port information was moved to the base object instead of having a UDP extension and a TCP extension. However, when this was done two fields were left in the new somewhat errant TCP extension. Namely the src/dst "flags"

I would propose that it does not make sense to have this TCP extension with just 2 properties that are flags, when the port information was merged down to the base object.

So I see two proposals to this issue:

1) We also merge down the TCP flags and leave them as optional, similarly to what we did with the port information.

2) We rename the TCP Extension to be TCP/UDP Extension and put the port information back in it.

Thanks,

Bret

Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

cti-cybox message