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

[Mirja Kühlewind <[e-mail]>]

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?

> 
>> 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.

>> 
>> 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.

Mirja