Re: draft-nordmark-multi6-threats-01.txt

[Erik Nordmark <Erik.Nordmark@sun.com>]

[Sorry for the delay in responding. I think this is still relevant to
our discussion, at least we need to understand how to make the "granularity"
section say what we want it to say.]

> >  If they do believe that they are having confidential
> > communication with Santa Claus but they are instead communicating
> > (with confidentiality) with me then there was an attack on 
> > confidentiality.
> 
> But even if it is a non confidential communication, if i think that i 
> am communicating with santa, but i am communicating with someone else, 
> this is a problem

We're not discussing the importance of preventing redirect attacks here.
The issue is/was how we describe it at the highest level.

> Ok, it is clear to me now. The RST example was helpful for me, perhaps 
> adding it may help others.

I'll add it.

> For instance, you can think a solution where each connection is handled 
> independently, and has its own security, So attackers have to redirect 
> each connection independently, no matter the direction the connection 
> is established. Examples of this are solutions that make TCP to support 
> multiple addresses per connection.

Yes, but it is hard to see how such an approach would apply to UDP.
And I think applying such a TCP solution to http traffic would be insane
due to the performance impact of doing more work for every short connection.
Even so, since there are long-lived http connections, I think it would
be bad to remove the ability for them to benefit from multihoming.
So you'd definitely need a MAST type approach here were the signalling
can be deferred until you can guess that the connection will be long lived
enough to benefit from the multihoming state being established.
 
> Next, you have solutions that explicitly handle different directions of 
> communication separately. This means that all incoming communications 
> from a given endpoint share the same set of locators, and an attack 
> will affect established and future incoming communication evenly. the 
> same for outgoing communications. I guess that an example of this would 
> be wimp. This makes sense, imho because as you mention in the draft, 
> the initiator role and the responder role are different in terms of 
> identity requirement. In many cases the identity of the initiator is 
> not very important, the only relevant issue is that it remains the same 
> that had initiated the communication. OTOH, the receiver identity is 
> always important since the initiator wants to communicate with a 
> certain host.

Hmm - perhaps "incoming" and "outgoing" is being overloaded when we take
WIMP into account. I view WIMPs use of ephemeral IDs as a separate step
of creating an identity on the fly which is conceptually separate
from that node initiating communication by sending a UDP packet
or a TCP SYN.
But perhaps I'm confused...

> Finally, some solutions handle all the communications together, 
> incoming and outgoing. Such solutions (like noid, sim) require heavier 
> security features in all communications, since no matter whether the 
> communication requires identity validation or not, this feature is 
> provided
> 
> That is why i see that the issue to be about the scope of the binding 
> information.
> We need some security mechanisms to negotiate the binding between a set 
> of locators and the identifier used by ULP
> The point is the scope of this binding.
> This binding can affect only a a given communication
> this binding can affect all the incoming (or outgoing) communications
> this binding can affect all the communications with a given endpoint.
> 
> As the binding affects more communications, the security required for 
> the mechanism to set up the binding would be stronger, imho

You seem to be basing this on the assumption that each communication provides
a fixed security quantum and it is the sum of these quanta over all all
communication that matters.

That doesn't make sense to me, since I don't think things are that uniform.
For example, the communication which a sensor initiates to report a fire has 
higher security requirements (for instance, needs higher DoS resistance)
than periodic temperature readings from the same sensor (that might be used
to fine tune the air conditioning settings).

I care a lot more about the security when accessing my bank than when
accessing a news site.
Thus not all communication have the same security requirements.
Hence assuming a fixed security "contribution" per communication
doesn't make sense to me.
 
> i think this is a good point.
> When considering per connection solutions, the time is naturally 
> limited to the lifetime of the connection. The problem is when you 
> attempt to use the binding information for more than a single 
> connection (or when the mechanism resides in a layer that has no 
> knowledge of the connections) In this case, you need a garbage 
> collection mechanisms, to delete the bindings that are no longer being 
> used. As you mention, the presence of this information when it is no 
> longer needed for the communication is a liability, and would make 
> sense to delete asap

I don't think I said it was a liability; when applications perform
repetitive connections over a short time period there is a great
benefit in being able to retain the multihoming state
across those connections. Likewise if multiple parallel
connections seem to be useful to some applications.

My take is why per-connection TCP solutions are simpler than a common,
connection indepdent solution, is two-fold:
 - the identifier space is effectively different. TCP cares about the 5-tuple
   indentifying the connection and as a result, connection redirection,
   but it doesn't need to care whether multiple peers are claiming to
   use the same 128-bit identifier as long as the connections are uniquely
   identified by the 5-tuple.
 - state setup and taredown can be bound to the open and close handshakes of
   the protocol.

The first point is interesting to compare to ephemeral IDs. For many TCP 
applications the initiator's port number floats that is the 5-tuple
connection identifier will be ephemeral as a result; even if the variation
is less than 16 bits.
This means that one can perhaps be less concerned about premeditated
redirection?


> > Yes, for the responding end.
> > The interesting thing I tried to bring out is that for the
> > end that has the ephemeral ID, you can skirt around the premediated
> > attacks (assuming the solution has a robust way to pick a new ID when
> > one is in use/stolen).
> 
> Yes and the cool thing is that the node that has an ephemeral id does 
> no need a stable one when he is acting as an initiator, so providing it 
> to him would require additional security without any benefits (which 
> doesn't seems a reasonable tradeoff :-)

Yes, if you somehow know that the application will not try to use that
ID on a longer timescale whether for identity comparison, callbacks or
referrals.

> But imho in the case of ephemeral ids, you are not really proving id 
> ownership, because the identity is meaningless!

It is meaningless on a longer timescale and for the applications, but it might 
be critical to be able to redirect existing communication to use a different 
locator. Thus you can view this as a first-come first-serve ID claim protocol
with any given peer; once a node has claimed an ID at the peer it
can use that ID to affect the locators that are used to reach it.

> So you don't really have to prove id ownership because it is irrelevant
> The important point in this scenario is that the the communication is 
> always with the same endpoint.

Exactly, which I why I say there is an ID in this case.



> Ok, i agree that i should be more precise about this point.
> Perhaps the important issue in this case is that a given endpoint is 
> authorized to use a given locator (i think G. Montenegro used this 
> expression about locators a while ago)
> 
> So we need to provide identity ownership proofs and locator usage 
> authorization proofs in order to make this work
> 
> So, assuming the above taxonomy of means to provide identity ownership 
> proof, the mechanisms to provide locator usage authorization proof 
> would be:
> 
> - return routability: i.e. if an endpoint is capable of receiving 
> packets at a given locator, it is because he is authorized to do so
> - third trusted party: a third party establishes that a given identity 
> is authorized to use a given set of locators (for instance the DNS)

Yes. I'll try to add this into the appendix.

  Erik