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

>> 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.
>

Disclaimer: i am not advocating for this type of solution, i am just 
considering the different levels of threats introduced by one or other 
approach

> Yes, but it is hard to see how such an approach would apply to UDP.

UDP is not connection oriented, so this per connection type of solution 
needs to be implemented at a level who is connection aware. imho in the 
UDP case, you will need to implement it at the app layer

> 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.

i agree with all your points. However, as is stated above, my point 
here is just about the differences in security/threats between per 
connection security and per direction security and per endpoint 
security

>
>> 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)

Note that a single endpoint can be both intitator and receiver, so it 
will have multiple ids of different types

So, imho identities in wimp are closely related to who has initiated 
the communication i.e. initiator and receiver

>
>> 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 was not my intention. i am assuming that it is worse that an 
attacker hijacks all the present and future communications than just 
hijacking a single connection. So, a single communication requires less 
security than all the present and future communications in one 
direction which in turns requires less security that all present and 
future communication communications in both directions.

I mean, if a single communication is at stake the solution needs less 
security than when all the communications are at stake.

>
> 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 guess that different apps will have different security requirements. 
However, i am considering the default scenario here. I mean the multi6 
solution will provide some default level of security based on some 
security tools used by the solution.
If a particular communication requires additional security, it will 
obtain it by special means (TLS for instance)

>> 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.

and stealing a connection does not imply stealing other (future and 
present) connections

>  - 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.

indeed.
however, because multi6 layer located mechanisms are not connection 
aware, they cannot limit the scope of the id to a single connection

> This means that one can perhaps be less concerned about premeditated
> redirection?

yes.
imho, we can be less concerned about redirection in general, becuase 
redirection attack will only affect a single connection, and the 
ephemeral nature of the id imples that future communication may use a 
different id

>
>
>>> 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.

yes, this is more accurate

regards, marcelo

>
>> 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
>
>