Security over UDP

[Ka...@bmw.de]

Hi!
The efforts towards the UDP binding include to provide minimal security over UDP differentiating between plain text, signed and encrypted payload. To do so, we currently need Security Params at least including a flag signaling the security property in use. There are several alternatives that we would like to discuss.

When an (Etch over UDP over) IP packet looks like this:
Request:	IP | UDP | Etch Header | Function Identifier | Message ID | Params
Response:	IP | UDP | Etch Header | Function Identifier | in_replyTo | Message ID | Params

Adding security parameters could be done like this:

- Alternative A:
      IP | UDP | Security Params | Etch Header | Function Identifier | Message ID | Params
Where we added the Security Params as a "Security Header" before the Etch Header.
Pros:  We can sign/encrypt everything after the Etch Header.
Cons: Architectural issues concerning all bindings.

- Alternative B:
      IP | UDP | Etch Header* | Function Identifier | Message ID | Params
Where the existing "Etch signature" field within the modified Etch Header* signals the same, thus differentiating between three different "Etch signature" values. Is this possible? Is this a good idea at all?
Pros: No additional fields.
Cons: ?

- Alternative C:
      IP | UDP | Etch Header | Function Identifier | Message ID | Security Params | Params
Pros: full downwards compatible, Etch will discard unknown fields (right?)
Cons: We can only sign/encrypt the Params, not the Function and Message IDs.


Hoping for discussions, preferences and hints. Thanks in advance!


Best regards,
Kay Weckemann
BMW Group
Research and Technology