[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: about draft-ietf-shim6-proto-01.txt

marcelo bagnulo braun wrote:



In section 5.4  R1 Message Format
It may make sense to allow the responder to include the locator set in the R1 message, so that the initiator can acknowledge the reception of the locator set (otherwise, the locator set of the responder is sent in R2 which remains unacknowledged). 


This isn't a problem AFAICT. If the initiator doesn't receive R2 it will
retransmit I2. The ULP packets from responder to initiator can still
flow, since they haven't failed over to use an alternate locator pair
yet.



right


 Worst case would be a packet loss when we want to switch to
alternate locators immediately as part of the context establishment
(when the responder might start sending payload messages before the
initiator has received the lost R2.)
yes, but this would also be covered by the context loss recovery mechanism that is being considered, right? i mean, the peer could reestablish the context with an alternative locators (and the same ulids) 

Not clear actually.
If the initiator hasn't received R2, it still has a context for its context tag (the one it sent in I1 and I2). The payload packets will have that context tag. The initiator just doesn't have the peer context tag and the peer's locator list yet. So perhaps the reception of a data packet need to verify that the shim context state in "ESTABLISHED" (reminds me that we need to write down the state machine) in which case it would capture that it hasn't received the R2 yet. 


actually this depends on what is being signed.
one possiblity is that the responder signs the locator list (without any context specific information). In this case, the responder doesn't need to sign the locator list each time it sends a R1, resulting in less processing. the questions that are open here are reply attacks and if we need to sign also the locator list version...
You would be subject to replay attacks of that signed list if you don't include something live in the signature (the context tag, a nonce, or something else)
but this would imply that a host would need to keep track of all the locators that once were available for the context, which would potentially imply a much larger memory consumption than it would require to just keep track of the current locator list 

Yep.


Or, we bite the bullet and have a larger context tag and ignore the
source locator in the lookup.

But in both cases we have an issue with injection of bad Update
messages. What prevents the on-path attacker from injecting such a
message and replacing the CGA parameter set with something, which when
verified, will fail the verification?
nothing, but in this case we can detect that the message was false and keep the last locator list that was verified
If we want to allow lazy verification where a host doesn't verify a locator until it is about to use it to send to, then the whole list might never be verified. I don't know if this makes sense with HBA or CGA locators - presumably for those the verification is just as cheap to do for the whole list at once as doing it for one locator at a time. 


I think this problem is quite interesting indeed
to summarize:
Threats involved in accepting packet from unverified sources (this apply both to using only the context tag to demux and to defer locator list validation until we need to send packets to the locator)
1- time shifted packet injection attack. This would allow an attacker that were once on path and learned the context tag, to inject packets as into a communication associated with a shim context. The difference with current (non-shim) environment is that today the attacker needs to use a topologically correct address to be able to spoof the source address and inject packets into a communication. In the new context with the shim, the attacker doesn't even need to by pass ingress filters since it can simply send with its own source address and the shim will replace it with the ULID used in the shim context. 

Yes, if the attacker has seen the context tag it could do that.
2- Stalled locator list. (DoS attack) An attacker can update the locator list with a new list of invalid locators, so that the victim won't be able to accept any packets (if the source address is verified) 


others threats?

Possible solutions:
- use only the context tag for demux: deal with issue #2 but not with issue #1 - keep a record of all previous locators: deal with issue #2 but not with issue #1 (higher memory consumption) - verify the locator list using hba/cga: deals with both of them, but imposes cpu consumption up front (even if we never need the alternative locators)
Yes, the last one implies that even communication never fails we impose the overhead of verifying the locators in the list. 




   CGA Signature:

      A variable-length field containing a PKCS#1 v1.5 signature,
      constructed by using the sender's private key over the following
      sequence of octets:

      1. The 128-bit CGA Message Type tag [CGA] value for SHIM6, 0x4A
         30 5662 4858 574B 3655 416F 506A 6D48.  (The tag value has been
         generated randomly by the editor of this specification.).

      2. The Locator List Generation value of the correspondent Locator
         List Option.

      3. The subset of locators included in the correspondent Locator
         List Option which validation method is set to CGA. The locators
         MUST be included in the order they are listed in the Locator
         List Option.


Added.


   This document defines a new 128-bit value under the CGA Message Type
   [CGA] namespace, 0x4A30 5662 4858 574B 3655 416F 506A 6D48.


Added




my thoughts were more simpler than that... :-)
I was considering the case where the shim context is establsihed upfront, before the communication is established. For instance, suppose a host that knows that it usually establishes communications with other peer and that it wants to establish a shim session up front for upcoming communications... Not sure we want to do that, but i think that several times we considered the possibility that the shim session is established upfront (for instance when considering using shim for dealing with initial contact failures)
I somehow lost track of what you wanted to change/add to the document for this. 

   Erik