Minutes for MPTCP at IETF-interim-2010-mptcp-1
minutes-interim-2010-mptcp-1-00
| Meeting Minutes | Multipath TCP (mptcp) WG | |
|---|---|---|
| Title | Minutes for MPTCP at IETF-interim-2010-mptcp-1 | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2011-12-01 |
minutes-interim-2010-mptcp-1-00
MPTCP interim meeting / 12.14.2010 16:00 - 17:50 GMT
-----------------------------------------------------
Chairs: Philip Eardley, Yoshifumi Nishida
Notetakes: Costin Raiciu, John Leslie
--------------------------------------------------------------------
Slide P4: Scope
Mark Handely:
Perhaps we could solve on subsequent subfolws not as said on the slide
Alan Ford:
You're quite right, but not worth getting bogged down
Phil Eardely:
Any more comment on these high-level goals?
Olivier Bonaventure:
We should have precise definition of capabilities we assume.
Otherwise, we won't understand what our system is secure against.
Alan:
this related to your email on thursday, relating to blind and listen + spoof attackers
also time-shifted attacks within inject
Marcelo Bagnulo:
we should also consider a post attack detection capability.
this is where some solutions differ. It allows original parties to detect the
attack took place or not. maybe the attacker in the initial connection set
can introduce new locators that if the original parties can detectors.
this is another dimension worth considering.
Olivier:
detection is important. What do we need to detect? When?
Marcelo:
suppose a mitm changes the crypto material. To remain undetected he must remain online
and change everything. if the original parties can talk directly they can easily realize
there was a problem.
Alan:
difference btw an attacker and a misdirected packet? where a shared address behind nat
MMarcelo:
suppose you want to attack by hash-change, if original parties talk privately, they can
detect hash-change
Marcelo:
attack a hash chain; need to replace the hash chain completely -
they can realize there was an attack. If you use a token only, you cannot tell
there was an attack.
Mark:
if packets reach host unchanged, different from MITM... but also consider DoS blocking
real packets while injecting own packets
Marcelo:
we can protect against most things we can imagine, but at what complexity cost.
is it worth the trouble?
Olivier:
IMHO must be secure against blind attackers, if we can do no more than that,
we need to say so clearly
Mark:
TLS on top. should be able to use in all environments where you'd use plain TCP,
otherwise you can't turn on by default
Mark:
what is the difference btw the passive + spoof attacker and the mitm?
not so big with a dos you can prevent the source to receive.
Olivier:
in practice there may be a difference
Marcelo:
not really, not convinced
Olivier:
mptcp must be secure against blind at least; not necesarily that need to do more.
Mark:
it's not reasonable to use tls on top. You should be able to use with high confidence
in the same environments you could use tcp.
Olivier:
we don't have such a solution yet
--------------------------------------------------------------
Slide P10: current (-02) proposal
Marcelo:
in the join in the -02 proposal you use 4 packets; mh proposed a way to reduce this
to three packets.
Alan:
it is possible, yes.
Marcelo:
it's desirable to have three-way handshake
Alan:
would have to consider option space, but it is feasible
--------------------------------------------------------------
Slide P11: First Question
Alan:
what does HMAC add anything? is this significant improvement?
we still have sequence-number gleaning issue.
Mark:
depends on your usage modes: if we postulate initial setup over 3G + many wifis,
it could add a lot
Marcelo:
significant reduction in window of vulnerability. also, quite cheap.
Andrew Macdonald:
agree with marcelo it reduces time and space of vulnerability
Alan:
any other opinions? we agree this is adding something
-------------------------------
Slide P12: Hash Chains Proposal
Alan:
should mean we no longer have initial vulnerability, but introduces other issues
Marcelo:
don't understand, you can't solve MITH of initial setup only solves for passive attackers:
active attackers aren't solved
Alan:
this one protects against active attackers on subsequents. but of course MITM is still
impossible to protect
Alan:
non-reversible hash, sender declares previous value in chain, receiver can verify H[n]
is the successor of H[n-1]. meaningless to any passive listeners
----------------------------------------------
Slide P15: Hash Chains #2
Marcelo:
not sure I agree... NAT-compatible requires ability to change address.
protecting against address change breaks NAT compatibility...
an attacker will be able to put any address he wants...
Alan:
agree he could put whatever address he wants in SYN and/or SYN/ACK;
but the ACK has to get back
Marcelo:
you cannot prevent time-shifted attack by active listener
Alan:
he can pass the packets, but can't move the connection elsewhere; but he must remain on path
Marcelo:
suppose I'm on path and see new subflow
Alan:
yes, you can bounce packets somewhere else. but I don't believe we're trying to protect
against that. only thing you could do would require including HMAC? on all subsequent packets
Mark:
he can't move the connection elsewhere
Marcelo:
he can change the source address
Mark:
he needs to remain on path
Marcelo:
only during the control info setup
Mark:
how can he leave
Marcelo:
suppose i am on path. i change the source address of the new subflow being established.
Costin Raiciu:
we're doing our best to protect control information, but data is still vulnerable.
no point in this much complexity unless we can add protection to data; HMAC does help us
in the wifi case; why wouldn't we use something like this to encrypt?
Marcelo:
hash-chain allows detection of attack; with HMAC he can replace hash-chain
Andrew:
that's rather limited
Alan:
it is impossible to tell the difference in practice - can we reliably detect an attack?
Marcelo:
significant additional complexity. cannot protect completely
Mark:
how do you handle other cases. can you re-use hash-chains
Marcelo:
what happens if you run out of hashes
Mark:
in case of race condition what does a receiver do with JOINS using same hash?
Andrew:
yes you only do one subflow at a time.
Olivier:
christoph's proposal may be interesting to consider
Marcelo
there are solutions that can give you additional security only in some scenarios.
For instance: use initial subflow to check subflow setup.
Olivier:
we need a formal description of the attacker capabilities.
how do we deal with functional constraints?
Costin:
we need to also think about the constraints of mptcp and the attacker capabilities.
E.g. break before make & christoph's proposal, nats & active attackers
Mark:
in ipv6 we could increase security
Marcelo
in ipv6 solution space is completely different; much better solutions. e.g. CGAs
Mark:
can we do different solutions for v4 and v6? will the iesg allow that?
Marcelo:
it should. that's what mip does.
Mark:
we're at transport level, not IP layer... also we could see single TCP running
both v4 and v6 paths
Marcelo:
this should be acceptable to IESG as this is also what SCTP does. they also requested
that we can code keys for better security. but we are discussing here just the default
worst case
Yoshifumi Nishida:
I'm not in favor of using hash in SYN.
Alan:
at the moment hostB would have to calculate immediately at SYN.
This is an open issue how we might delay that.
------------------------------------------------------------
slide: P19 What other solutions are there?
Alan:
charter says "basic security". we don't want "perfect" solution, but should be
sufficiently agile to insert better solutions later
Mark:
attacker can race, on response can spoof a MP_VERIFY (after spoofing SYN/ACK)
Alan:
sounds plausible, if that is the case MP_VERIFY is no more secure, would mean
we don't have a solution
Mark:
what about the combined hmac + hash chains?
Andrew:
amount of information you have to carry on initial SYN/ACK
Alan:
a lot of complexity, a few holes remain
Costin:
what about diffie hellman? how much more do we get compared to hmac?
Alan:
still vulnerable to race attack
Mark:
not vulnerable, but how to protect ?
Alan:
computationally expensive
Costin:
same security as HMAC except requires active attackers
Alan:
let's phrase it differently, does HMAC meet our needs
Marcelo:
need to support alternatives (e.g. IPv6, encryption) as upgrades
Andrew:
there are other ways available, this gives basic working point.
another benefit, SYN-cookie easier to imagine
Marcelo:
how much is left on other protocol issues?
Alan:
not much. we need to design-in algorithm-agility, rest is fairly solid.
Marcelo:
let's decide on something, not worth delaying protocol spec
Alan:
security area not terribly impressed. but nobody said something was broken.
Marcelo:
I don't see a problem with security area
Phil:
does anyone want to speak against "emerging consensus"
Alan:
this should be the baseline; agility is key for future extensions.
Marcelo:
completely agree with that. Ask IESG whether we should also work on an additional mechanism.
Phil:
capture consensus, get it on the list, and make sure there is agreement on the list.
We should still be on track to finish by march. Will ask for extension to charter
to do stronger security, if deemed necessary.
It'd be worth trying to summarize this in a page or two, why we arrived at this conclusion.
Marcelo:
The security director will review the threats ID. we will know before this hits the
security director.
Phil:
it would be great if this document reached the security director and security working group.
Marcelo:
let me know if something is missing from threats draft
Olivier:
implementation issue: not reasonable to assume unlimited subflows.indication of limit
to number of subflows. should be part of protocol so that endpoint can simply reject
subflow requests
Costin:
what's the point instead of just refusing extra SYNs?
Olivier:
e.g. initial 3G, second SYN over wifi, then reject any others (unless something closes);
this would require attacker capable of listening on both media. option to signal the limit.
Costin:
if you assume unlimited subflows, vulnerabilities increase. who decides?
can simply drop the SYN unless there's a benefit from the other end knowing
Phil: that needs more discussion on the list