Re: [multipathtcp] High-level design decisions /architecture

philip.eardley@bt.com escribió:
>
> Security
>
> ======
>
>     * exchange a token in the initial SYN for the MPTCP connection,
>       and include the token when subflows /paths are added to the
>       connection
>           o [Question: Is the same token used whether the sender or
>             receiver (of the MPTCP connection) adds the subflow? Is
>             the same technique used for removing subflows? And closing
>             connections, ie DATA FIN?]
>

I have been thinking about alternatives mechanisms that without 
requiring heavy crypto would remove the threats from passive on path 
attackers that can laucnhh attacks to the token based security (and 
require the attacker to actively change the traffic in order to launch 
the attack). I think this could be worth considering since the work 
required by the
I haven't been able to write an ID about that just yet, but i was hoping 
to do something in the few next weeks.

Regards, marcelo

>          o
>
>
>
>
>     * security mechanisms will not interfere with end-to-end
>       authentication etc and will be compatible with legacy middleboxes
>
> Modularity
>
> ========
>
> · the architecture has 2 components, multipath scheduler & path 
> manager – meaning that improved /different modules of each can be 
> slotted in
>
> o [Comment: it is unclear from the Architecture i-d how the congestion 
> control & protocol i-ds map to these components; some of the text 
> (strangely?) appears in a section about implementation]
>
> o [Question: what are the mechanisms for evolvability? How is it 
> negotiated which new module (for congestion control or path manager) 
> to use?]
>
> o [Question: this would seem to imply we need to define an interface 
> between the modules?]
>
> · there is a default path manager module, meaning it is the MUST 
> fall-back option
>
> o [Comment: the charter restricts us - the path manager we work on 
> will distinguish paths by multiple addresses]
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp
>   