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.
WIMP uses different type of id for initiators and for receivers: - for initiators, the id is randomly created - for receivers, the id=hash(FQDN)
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