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

>From the Security discussion it seems:

- the WG needs to describe /analyse threats as soon as possible. Do people think that http://www.ietf.org/id/draft-bagnulo-mptcp-threat-00.txt is a reasonable starting point for this?
- until the threat analysis doc has progressed a bit, it is too early to agree on the security mechanism. We will have to wait & see whether we can decide this in Feb/March.

phil

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]
> Sent: 02 November 2009 19:28
> To: Eardley,PL,Philip,DEE1 R
> Cc: multipathtcp@ietf.org
> Subject: 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
> >