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

RE: New multi6 draft: WIMP

Hi Jukka,

I am trying to understand your draft, and i have some questions about some
points that you perhaps can help me with.

1. About the Context establishement exchange (section 3.4)
I fail to see what you mean when you state that the responder remains
stateless.
I mean, the responder has to generate the temrporary hash chain. This hash
chain has to be specific to this particular host pair context, right? (this
is what it is stated in section 3.3 about generating reverse hash chains)
So, this means that when the responder receives an INIT message it has to
generate a new hash chain (or reserve a pre computed hash chain for this
initiated context establishement), would this be correct?. If so, the
responder has to at least store a state that is that this hash chain is
reserved and cannot be used for a future INIT, right?

If so, wouldn't this imply that an attacker sending INIT messages could
force the responder to gnerate hash chains, sort of DoS attack? I ask this
because, if i understand correctly, this is what you are trying to prevent,
but i just fail to see how you actually prevent it :-(

The you state that:
"The initiator replies to the CC message with a context check reply
   message (CCR) and proves that it was reachable at the specific
   location by disclosing the anchor value."

I don't really agree with this... I think that the initiator can prove that
he is reachable by inlcuding the HMAC_CC value in the CCR message, and not
by disclosing the anchor value.

I mean, the anchor value would prove that the initiator is the same that the
one who sent the INIT message, but if the RESPONDER is stateless, the
responder has no information about the INIT message received, .
I guess that the important is to inlude the HMAC_CC and since the responder
has the H0_R it can verify that the HMAC__CC was generated by himself (the
responder)

(i am probably missing something here....)


after you mention that:

"The anchor value of the initiator hash chain
   binds the INIT and CCR messages together, and in this way the
   responder is able to verify that messages are coming from the same
   host. "

again if the responder is stateless, he has no knowledge about the INIT
message by the time he receives the CCR message, so what does it means that
it can verify that both messages come from the same host?

2. Re-addressing exchange

First, a simple question: the re-addressing exchange can be initiated by the
responder? (i think so, but i couldn't find it stated clearly in the draft)

Second, i am really having a hard time to understand how the key masks and
the key pieces work and how you can verify which of the locators are
reachable. I guess that part of the reasons is because my own comprehension
problems, but the fact that part of the explanation is contained in section
3.5 and that the rest is contained in section 6.12, where the packet format
is explained, is not helping me much :-(
Could you provide me a simpel example, with for instance a REA message
conatining 3 new locators, and detail which would be the AC1, AC2 and AC3
messages, how they are generated and which would be the ACR message (and its
generation)?
Sorry to ask this, but i am really stuck here...

3. After that a REA message is received, and some of the locators are
verified, which locator is used for following packets?
Do you use the address contained in the source address field of last
received packets?

Thanks, marcelo




> -----Mensaje original-----
> De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En
> nombre de Jukka Ylitalo
> Enviado el: jueves, 29 de enero de 2004 10:09
> Para: multi6@ops.ietf.org
> Asunto: New multi6 draft: WIMP
>
>
> (uh oh, the previous email was incorrectly aligned)
>
> Hi,
>
> We have submitted a new multi6 draft to I-D directory. The draft
> defines a Weak Identifier Multihoming Protocol (WIMP), and we
> wrote it in order to see how opportunistic/weak authentication
> methods could
> be used to solve the multi6 problem.
>
> WIMP is one of those protocols that introduce a new protocol layer
> between IP and upper layers. Our approach uses some very basic
> cryptograpahic funtions (reverse hash chains and secret splitting) in
> order to have light and (hopefully) simple solution. The protocol
> is not buller broof from security point of view, however, it intends
> to be secure enough and easy to implement.
>
> We hope it will stimulate discussion on various solution to
> multi6 problem.
>
> See more details from the draft itself, available in:
>
> http://www.hip4inter.net/multi6/draft-ylitalo-multi6-wimp-00.txt
>
> Thanks, Jukka Ylitalo
>
>
>