[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lartc
Subject:    [LARTC] Mangling TOS, or Precedence/SecurityOpts/Compartment?
From:       karl () klxsystems ! net
Date:       2005-10-29 0:16:24
Message-ID: 2290.66.125.65.130.1130545006.squirrel () www ! klxsystems ! net
[Download RAW message or body]

Hi there LARTC,

We are running a set of three systems for semiconductor technology, and
would like to finalize our work in getting them to interoperate properly,
but have run into some issues that touch on the very fabric of TCP/IP
expertise.

Iptables has already been used to solve "part of this", can we somehow use
Diffserv capabilities to acheive the aims of modfiying packets such that
the "invisible" machine stays "invisible"?:

The three systems consist of:
System #1:
Chip fabrication “tool” running std. TCP Server, using port 5000

System #2:
Controller machine,  running standard TCP Client, using port 5000

System #3:
“Invisible” Analysis machine running Fedora Core 4, and analysis software

To see the drawing:
http://www.klxsystems.net/pics/Analysis.html

The Tool Server” and the “Controller Machine” typically only communicate
with one another over a standard tcp connection, in single mode.

For the purposes of analysis, a third “Invisible” Analysis machine is
placed between Systems #1 and 2, and is cabled as shown in Figure 1, it
has two Ethernet ports, and in general acts like a “bridge” in that it
possesses a “Bypass Card”, which allows the Tool Server and the Controller
Machine to pass traffic through it’s two Ethernet ports.

One of the features of the Bypass card it contains, is that it physically
shunts the copper Ethernet connections together when, say, power is cut.

It runs in an “unshunted” format when conducting “Analysis”, and shunts
the copper back together when it “hangs up”  It’s purpose is to sit
BETWEEN the Tool and Controller machines, and intercept data they are
exchanging, for analysis used to effect better performance, and then “hang
up” by shunting the connection, and thus allowing the two main machines
(Tool/Controller) to keep “talking” as they were prior to the “analysis”
machine intervening.

Our problem:

We need to seamlessly start and stop the second TCP Client connection the
Analysis machine “invisibly” creates/ terminates.

The issue has been one of TCP/IP sequence numbers, “how to get them to
stay the same”, and not “drop” the connection per RFC 798.  Using dsniff
or other sequence number guessing isn’t an option.

One option for part of this might be to use PF rules to allow a change of
the source ip address of the packets going from the analysis machine
towards the tool server.

Or to change the “precedence/securityopts/compartment” fields by using PF
as well.

(I posted to the PF list to ask about the details of commands/ flags/
features, but some of this is beyond PF) -is there diffserv/iproute
functionality that would help with the below question from an openbsd
networking standpoint?

Perhaps it's yet another list someone might know of, or one of the gods
here will have some input from on high.

Question: how do we get the Analysis machine to invisibly connect, and
disconnect, without violating RFC 798?

There are several RFC’s that point to Differentiated Service field
manipulations, using tools like iproute2, but those never went into ways
to actually MODIFY the “Precedence, Security Option, and/or Compartment”
fields in an IP header from what we could tell.

The RFC that led us to this information stated:

With the advent of DiffServ, intermediate nodes may modify the
Differentiated Services Codepoint (DSCP) [RFC2474] of the IP header to
indicate the desired Per-hop Behavior (PHB) [RFC2475, RFC2597,
RFC2598]. The DSCP includes the three bits formerly known as the
precedence field.  Because any modification to those three bits will be
considered illegal by endpoints that are precedence-aware, they may cause
failures in establishing connections, or may cause
established connections to be reset.

Any suggestions if iproute, iptables, or other technologies would
facilitate this complex type of transaction?

We understand that modifying the TOS can be done at the application level,
as stated by RFC 2873, but these other fields, it’s still vague as to what
we can utilize.

-karlski
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[prev in list] [next in list] [prev in thread] [next in thread]