[Sis-csi] Emergency Commanding (was IP Header Compression)

[Scott,Keith L.]

This is really a discussion of emergency command mechanisms, so I've
re-titled the thread.

Here's the deal:

1)  If one injects a correlator somewhere after the demodulator and
before the network stack to look for a 'magic' set of bits, then there
will always be the chance that that particular set of bits, no matter
how long or with whatever inter-message timing requirements, will show
up in the data.

2)  If the 'magic bits' are in the form of a particular ipproto or app
(UDP dest port #) then you depend on having at least the bottom part of
the networking stack working.  This extends the failure mode from the
radio to whatever is housing the stack.

3)  You wanted security?  Reasonable security and 'ability to support
very short emergency commands' seem to me to be mutex.  I'd be happy to
be shown to be wrong here.


Choosing IPIDs as the magic bits is (IMHO) particularly problematic
because:
  o They are (supposed to be) monotonically increasing and hence WILL
hit the magic pattern, it's just a matter of time.
  o If you restrict to a particular set of source addresses and go
messing with the networking stacks of these 'special' boxes to preclude
certain IPIDs, you've sort of blown the model of using COTS software.
May as well pay the extra 8 bytes at this point and go to UDP src/dst
ports.


In CCSDS, a separate virtual channel can be used for emergency
commanding which:
  o Gets the size of the command way down.
  o Maintains robustness due to the channel coding (keeps the bits from
being clobbered)


Our problem is that we want to operate over a possibly heterogeneous
concatenation of links, some of which may be CCSDS and some not.  I
think this means two things:
  1. For data links that can support very small emergency commands, we
should understand how those would be invoked and what they constraints
these mechanisms impose on 'our' network-and-above traffic.

  2. To support end-to-end emergency commanding (i.e. multi-hop over
the network), we've already bought off on the network stacks of the
various systems working.  Either there's a 'command' process at the
penultimate node that can be addressed and instructed to send a data
link layer message to the emergency commandee, or we have to rely on
the commandee's network stack to be up enough at least to get a UDP
datagram (maybe header only).

		--keith


>-----Original Message-----
>From: Wesley Eddy [mailto:weddy at grc.nasa.gov] 
>Sent: Friday, September 09, 2005 8:26 AM
>To: Howard Weiss
>Cc: Scott,Keith L.; Keith.Hogie at gsfc.nasa.gov; 
>dave.israel at nasa.gov; sis-csi at mailman.ccsds.org
>Subject: Re: [Sis-csi] IP Header Compression
>
>On Fri, Sep 09, 2005 at 07:59:51AM -0400, Howard Weiss wrote:
>> Or isn't seen because those bits were missed or clobbered.
>
>
>Any of the other bits (ports, options, protocol ids) that were 
>mentioned
>could get missed or clobbered too, so I don't see how that's relevant.
>The difference that actually makes the IP identification more robust
is
>that there aren't things that change it in-transit like there are with
>all of those other fields (on the "real" Internet at least).
>
> 
>> Scott,Keith L. wrote:
>> 
>> >Until that ipid happened to show up in somebody's data stream!
>
>
>How does it show up in the data stream?  It's used for fragment
>reassembly and is chosen at the liberty of the sending host.  
>So as long
>as senders know that certain IDs are set aside for emergency commands,
>there's no real problem.  The only issue is when senders that 
>don't know
>accidentally pick one of the IDs (1/2^16 chance per ID set aside), but
>this is easily mitigated by also restricting the valid source address
>field values for such commands.
>
>-Wes
>
>-- 
>Wesley M. Eddy
>Verizon FNS / NASA GRC
>http://roland.grc.nasa.gov/~weddy
>