Re: [Spud] Authentication and packet reflection [was: Re: Questions based on draft-trammell-spud-req-00]

[Tom Herbert <[e-mail]>]

On Tue, Aug 11, 2015 at 10:37 AM, Mirja Kühlewind
<[e-mail]> wrote:
> Hi Tom,
>
> just two comments below:
>
>>> 3) Tradeoffs in integrity protection
>>> ---
>>> a) Should SPUD provide support to use the authentication mechanism of the overlying transport for SPUD information provided by an endpoint to check the authenticity and integrity when the information arrive at the other endpoint?
>>> —> Yes, if supported by the overlying protocol
>>>
>> Yes, but this seems independent of the overlying protocol. We should
>> be able to secure the SPUD bits as needed regardless of overlay or
>> underlay.
>
> That means, you would like to provide key exchange mechanisms in SPUD?
>
The end points do need a key exchange, if they are already doing TLS
for encrypting the payload maybe that can be leveraged. IIRC QUIC
headers are authenticated but cleartext, and payload is always
encrypted, so they may have already solved this...

>>
>>> b) How can packet-mangling (middleboxes changing accidental or intentionally information provided by others, both middblebox and endpoints) by on-path ndes be detected?
>>> -> Lying can potentially be detected if information can be verify over a different mechanism. However it might not be possible to detect who provided these wrong information. Off-path devices would need to know the tube id to provide wrong information which may be unlikely.
>>>
>> Authenticating the header should be an option in cases where we want
>> to prevent any packet-mangling.
>
> If you already have a trust relationship which the other end, that’s easy but that only helps for information provided from end-points. However you might not be able to provide authenticated information from a middlebox. And sometimes it might even been on purpose that one middlebox should be able to overwrite the information form another middlebox, e.g. if the shortest time-out on the path is requested.
>
Right, but there's also fields in the headers which should be declared
immutable in the path-- which likely includes the session ID and cmd.
We should be able to get integrity and end to end authentication of
those. If mutable fields are also present, then some options are:

- Define a mechanism to indicate those fields are excluded from
authentication and integrity check
- Place mutable fields outside of the headers. For instance,
middleboxes can respond directly to the source instead of modifying
packets inflight and relying on reflection
- Middlebox encapsulates in another header so it can set any fields as
desired, but receiver will need to untangle that

>>>
>>> f) Should middlebox information be reflected over the receiver or can they also be send directly to the sender (and might take a different route)?
>>> -> Maybe there should be a possibility to sent directly to the sender; for unidirectional flows the receiver may not have a bearer flow to carry the message back and thus would generate spud-only packets which maybe quite a bit overhead. However reflection over the receiver should be preferred.
>>>
>> Middleboxes often have a locality associated with them, e.g. home
>> router, enterprise firewall. In such cases, it seems like returning
>> information directly is a better use of resources and limits the
>> exposure of the data. For example, if your firewall wants to provide
>> the client with it's connection timeout, it can send that back
>> directly rather than forwarding this to some server halfway around the
>> world and expecting the them to properly reflect the information when
>> they should not care about this. To the server this is just extra work
>> and extra memory that needs to be allocated for each flow (possibly
>> millions of them).
>
> For time-outs I rather would like to see a mechanism where this information is reflected over the receiver because what you are actually looking for it not the time-out of your local firewall (you might already know that over a different channel) but the minimum time-out of all middleboxes on the path. Otherwise if you just request the time-out, every (Spud-aware) middlebox on the path would need to send you a separate reply. Of course the middlebox with the smallest time-out might not be spud-aware but that’s different problem.
>
How big of problem is this likely to be? How many middleboxes do you
foresee in paths that will be maintaining flow state with timeouts?

Also, see my comment about keep-alivess, I'm hoping we can get a
better solution which eliminates the need for knowing timeouts and
sending keep-alives in the first place!

Tom

> Mirja
>
>
>
>