Subject: [Hipsec] Indicating Reply Requested and renaming NES?

From: [email-masked] (Henderson, Thomas R)
Date: Thu Dec 11 12:12:01 2003

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]]
> Sent: Wednesday, December 10, 2003 1:05 AM
> To: [email-masked]
> Subject: [Hipsec] Indicating Reply Requested and renaming NES?
>=20
>=20
> As I am working on the revised Mobility and Multi-homing
> scheme, I have come to a tentative conclusion that it might
> be good to introduce a new HIP control or alternatively
> take one bit from the packet Type field into use.  I would
> also like to rename the "New SPI" (NES) packet into a more
> generic "Update" (UPD) packet, since it looks like a good
> candidate for various kinds of updates, not just SA updates
> but also readdressing updates and probably other kinds of
> updates in the future.  Furthermore, if we decide to rename
> the NES packet into a UPD packet, we can also rename the
> NES_INFO parameter into a NES parameter, just for simplicity.

I would support NES->UPD change

>=20
> New control option
> ------------------
>=20
> The currently defined controls are the following:
>    C - CER packets follow
>    E - Use 64-bit ESP sequence numbers
>    A - The sender's HIT is anonymous
> (Actually the E control should be part of the ESP
> transform parameter and not a control, but that is a
> different issue.)

Agreed on the E-bit.  We could put a control field
in the ESP_TRANSFORM, or else define an ESP64_TRANSFORM
Type code.  I would vote for the former.  Incidentally,=20
16-bits is probably overkill for Suite-IDs in HIP_TRANSFORM=20
and ESP_TRANSFORM.

>=20
> I would now like to include a new control
>    R - A reply is requested
>=20
> This control would always be set in I1, R2, and I2, and
> (almost) never in R2.  However, it looks like that it
> would be fairly useful in NES and BOS, at least.

A couple of questions/comments:
i) what are the specific semantics of the bit?  "Must ack"?
Is it implied that the packet will be retransmitted if
the reply does not arrive?  Do we need another "ack" bit
that conveys "this is the reply that you requested"?  Do we
then need to make sure that the protocol operates in
"stop and wait" ARQ mode to avoid ambiguities?

ii) in most of your examples, it is understood from the
packet type definition that a reply is requested.  Why
have this bit and then have to define rules for e.g.
handling an I2 with the R bit off?

iii) should we have a more general facility (e.g. packet
type and defined ARQ semantics) for UPDATE/UPDATE_ACK that=20
could be used by NES parameters and whatever else is=20
desired in the future?

>=20
> I also think that having a generic update utility with
> different kinds of parameters (NES, REA, etc) that
> indicate what is to be updated creates a more orthogonal
> micro- architecture within the actual protocol.  The
> obvious counter-argument is, of course, that such
> orthogonality and generality may create unnecessary
> complexity.  However, in this specific case I don't see
> that much more complexity.  Indeed, a well written
> implementation may become less complex since it may
> require less code for handling various cases.

sounds like iii) above.  Are you in favor of this, then,
instead of R-bit or in addition to R-bit?

>=20
> Both of the schemes have the added benefit that it would
> allow sending I1s just to tell one's HIT (a kind of minimal
> BOS without the actual HI or signature), or maybe to send
> those R1s that are sent in response to unknown SPIs with
> the reply requested bit off?
>=20
> Especially the ability to send I1s with no reply requested
> might be beneficial for delayed HIP context setup; a feature
> that seems useful from multi6 point of view.

why not instead make BOS parameters optional?=20

Tom

=20

---

From: [email-masked] (Pekka Nikander)
Date: Fri Dec 12 03:30:03 2003

>> I would

Good.  Are you OK also with the parameter name change?

Any other opinions anyone?  Any more supporters?

> Type code.  I would vote for the former.  Incidentally,
> 16-bits is probably overkill for Suite-IDs in HIP_TRANSFORM
> and ESP_TRANSFORM.

Petri, could you provide us with sample text of how
the draft would be changed?

> "stop and wait" ARQ mode to avoid ambiguities?

Good questions.  I didn't think that far.  Thanks.

Now considering this, I think that the "the packet will
be retransmitted if not replied" sounds good.  This could
even be integrated with an explicit retransmission counter
in the packet.  We already have retransmission counters in
the state machine side.  Including the field into the packets
(even outside of signature) might help with protocol
robustness.  Unfortunately I have too little generic protocol
design experience so that I could tell how useful that
would be.

I don't think we need an ACK bit.  In the case of the
base exchange, the packet sequence is clear enough.  In
the case of UPD/BOS/..., the parameters include an ID that
must be present in the reply.

But is this good design?  Should we have some complexity
in the base header, maybe including a packet ID?  Then
we would not need to have IDs in the parameters.

> handling an I2 with the R bit off?

I would not define what to do with I2 with the bit off.
That would not be I2, it would be I2' or something,
not defined now.  It would just open up a possibility
for a (perhaps unnecessary) future extension.

> type and defined ARQ semantics) for UPDATE/UPDATE_ACK that
> could be used by NES parameters and whatever else is
> desired in the future?

Rethinking the issue, this might be the best approach.
I.e. forget the idea about a generic R-bit, and just
once more redesign the rekeying procedure, this time
with a generic UPDATE packet.

I guess there would be several flavors of the UPD
packet:

   - initial, unidirectional, no reply requested
   - initial, reply requested
   - reply, no further replies needed
   - reply, a further reply needed

We clearly would need a kind of transaction ID
(assinged in the initial packet and used later),
and a reply requested bit.  Anything else?

I would imagine each transaction would form a
stop-and-wait protocol, with the possibility of
running several transactions in parallel.

> instead of R-bit or in addition to R-bit?

I guess I'm still exploring possibilities.  Right now
a generic UPDATe and no R seems best.  But I still
don't really know.  Right now I should do other things
but ponder this.  :-)

I guess I'll write a proposal for a generic UPDATE,
possibly to be included into -09, and send it to
the list.  Maybe today, maybe next week.

--Pekka Nikander

---

From: [email-masked] (Julien Laganier)
Date: Fri Dec 12 07:52:01 2003

> Any other opinions anyone?  Any more supporters?

I support this change too.

> > 16-bits is probably overkill for Suite-IDs in HIP_TRANSFORM

I'd prefer the former too; it avoids to create one more TLV type.

> we would not need to have IDs in the parameters.

What do you guys think of combining the transaction ID (as used by NES) and 
the birthday counter into the same base header field? They seem to have a 
pretty much similar semantic.

Thus, one would normally reply with the same ID as the one contained in the 
packet triggering the reply, and increment it in case of loss or updating of 
a HIP association state, or when updating SA's.

Furthermore, birthday and cookie are now packed together within a single  
BIRTHDAY_COOKIE parameter and I can't really see the relation between 
birthday and cookie. 

AFAICS, it gives the opportunity to use some sort of birthday check on 
transaction ID in all packets that needs it (NES and R1 amongst the others).

Thoughts?

> for a (perhaps unnecessary) future extension.

I like the idea to keep the base protocol as much flexible as possible. As 
long as it doesn't introduce a huge amount of complexity I think it's worth 
keeping the extension door open, even on packets that doesn't apparently need 
it.

<snip>

> and a reply requested bit.  Anything else?

This looks like very much like the birthday counter...

Thanks,

--julien

---

From: [email-masked] (Pekka Nikander)
Date: Tue Dec 16 10:17:01 2003

>> in the packet.  ...
>> I don't think we need an ACK bit.  ...

> pretty much similar semantic.

I have to admit that I have never quite understood all the
issues behind the Birthday counter.  It would be good if
Bob would have time to clarify that.  However, remembering that
caveat, to me the idea sounds good.  Besides, 64 bits looks like
a big enough counter that it will never roll over during the
lifetime of the protocol.  That is, we will have a new protocol
version before the birthday counter rolls over.  (But can we
reset the birthday counter when the protocol number is incremented?
Probably yes, if we act proactively enough now.)

> a HIP association state, or when updating SA's.

Is it that simple?  Don't we have birthday counters at both ends?
I think we couldn't increment the peer's birthday counter (transaction
id).

Hmm.  Maybe we could combine the low order bits from the birthday
counter (say 24 low order bits) with a short within-transaction
counter that is incremented on all resends?

Hmmmmm.  This all sounds so much of how to design generic
reliable protocols that I really should not open my mouth here.
We really should get someone with proper protocol design
experience -- I don't have that outside of crypto protocols.

> BIRTHDAY_COOKIE parameter and I can't really see the relation between

Good point.

> transaction ID in all packets that needs it (NES and R1 amongst the 

Sounds great.

Should we include the birthday field in the base protocol header
so that it is included in all HIP packets?

> keeping the extension door open, even on packets that doesn't 

Agreed.

--Pekka Nikander

---

From: [email-masked] (Pekka Nikander)
Date: Thu Dec 18 08:47:01 2003

[Responding to oneself is not nice, but I realize
that HIP is not the first priority to everyone :-)
and that people are leaving for holidays.]

>> pretty much similar semantic.

After some more thinking, I think that the birthday counter and
transaction ID are pretty different things, even though they may
look like the same, and even though it may be good to bind them
together.

The birthday is basically a value assigned to an incarnation
of a HIP association.  That is, whenever two hosts create an
HIP association, or resynchronize an association, they set their
birthday values and stick to those for the duration of the
association.  That may be years.

The transaction ID, on the other hand, is basically a value
used to link together requests and replies.  This function
could be extended to give sequence numbers to all HIP packets,
making possible packet loss explicit.  That I tried to make
in my previous proposal, but the solution wasn't of almost
any good.

Now, the purpose of the birthday value is to protect the hosts
from replay attacks where the attacker simulates loss of
state at one of the hosts.  Here we have now a problem, as
it is possible for an attacker to make a host to increment
the birthday value and get an R1 with an incremented
birthday value.  Since the R1 does not have the peer's HIT,
it can be sent to any peer, triggering it to perform I2
computation.

The purpose of the transaction ID, on the other hand, is to
prevent reply attacks using earlier messages captured (during
the current incarnation of the HIP SA).  Hence, the birthday
value protects the hosts from simulated state loss, and the
transaction ID protects the host from captured and replayed
packets.

I think that these two functions should be kept separate, but I
agree that somehow linking them might increase security.  That
is, if a reply contained both the birthday value (or low order
bits of it) and a transaction ID, that would make naive replay
attacks slightly harder.

Right now I'm inclined towards the following conclusions:

  - We should replace the R1, when sent on response to ESP,
    with a RESYNC packet.  That would contain the R1 puzzle
    plus (some part of) the ESP packet that triggered it.
    A vanilla R1 should be only sent in response to an I1.

    Since the Initiator knows when it has sent an I1 and when
    it has sent an ESP packet using a given SPI and SA, this
    should plug the problem of simulated state loss, provided
    that the Initiator can check that the included portion of
    the ESP packet was indeed sent by it.  How that is done,
    exactly, seems to require some more thinking.

  - It looks like a good idea to add explicit sequence numbers
    into the base HIP header.  The sending sequence number could
    simply be a few low order bits (maybe 8), since the HIP
    association is terminated anyway after some number of
    control packets have been sent unanswered.  The reply
    sequence number must be larger, however, and probably should
    include low order bits of the birthday, to prevent replay
    attacks.  (The birthday bits are not really needed, since
    the KEYMAT is different, but if they can be easily included,
    they provide some minimal added robustness against the case
    where the network reorders packets during resynchronization.)

Comments?

--Pekka Nikander

---

From: [email-masked] (Jukka Ylitalo)
Date: Thu Dec 18 09:39:01 2003

>    A vanilla R1 should be only sent in response to an I1.

Sounds nice. Currently, when a host reboots and receives ESP packets with
unknown SPIs, it replies with  some of its R1s. However, a host may have
several HIs and it does not know which of them it should use. Instead,
if we reply with this new RESYNC packet containing the received SPI number,
the peer is able to map the RESYNC packet into its existing state always.

>    exactly, seems to require some more thinking.

Hmm. The original ESP sender, host A, could reply to the RESYNC
with RESYNC-REPLY message (a variant of NES). The RESYNC-REPLY
message would contain current SPI-A,  ESP sequence number that is expected
from B, and a piggybacked ESP message going to B.  Host B mirrors the
whole received RESYNC-REPLY message including piggybacked ESP
message. However, it  changes the  SPI-B to SPI-A and the ESP sequence 
number
before sending the message back to A. Finally, A verifies the integrity of
the ESP message using its own SA. We have to be careful with the SPI
values due to the HIP aware middle-boxes. What do you think?

> --Pekka Nikander
br, Jukka

-- 
Jukka Ylitalo                      Tel: +358 9 299 2622
NomadicLab, Ericsson Research      Fax: +358 9 299 3535
Oy L M Ericsson Ab                 Mobile: +358 400 615 821
FIN-02420 Jorvas, Finland          E-mail: [email-masked]

---

From: [email-masked] (Pekka Nikander)
Date: Fri Dec 19 05:54:00 2003

Jukka,

> values due to the HIP aware middle-boxes. What do you think?

I don't see why we need this complicated mechanism.
Can't the rebooted host simply include the R1 parameters
and the (beginning of) the ESP packet into the RESYNCH
packet?  You don't need to sign or anything the ESP part,
just sign the R1 part as in R1.  Why do you need an explicit
RESYNC-REPLY packet?

The hard part I was referring to is to find out whether
the host really sent the ESP packet included into the
RESYNCH packet.  There is no obvious way of doing this,
since the hosts do not store the ESP packets they send.

So, what was your reason for this complicated three
message sequence?  And what are those SPI-A and SPI-B?
Maybe I was unclear in my original message?  I'm sorry
to say but I'm really confused.

--Pekka

---

From: [email-masked] (Julien Laganier)
Date: Fri Dec 19 12:35:01 2003

> and that people are leaving for holidays.]

[Responding so late isn't nice either, but Xmas takes a lot of time... 
I Apologize]

> bits of it) and a transaction ID, that would make naive replay

Thanks for this insight ! It's now clear to me that birthday and 
transaction ID are clearly two separates function, and should 
consequently be kept separate.

About a possible linking between the two, perhaps we can initialize a 
transaction ID to the low order bits of the association's birthday, 
thus garantying that a given NES exchange (or whatever packet round 
trip) is truly bind to a given HIP association (via the association 
birthday's low order bits).

>     A vanilla R1 should be only sent in response to an I1.

Agree.

>     exactly, seems to require some more thinking.

One way to bind the ESP packet chunk to an HIP SA might be to check 
the ESP Sequence Number (SN) included in it against the current ESP 
SA SN. Ideally the current ESP SN should be a few more than the SN 
included in the returned ESP chunk (because there's only one RTT). 

Perhaps  the protocol can defines an anti replay window against 
returned ESP SN (in RESYNC packets), but I dunno how many packets 
long it should be.

This is, in essence, equivalent to include the ESP SN in some HIP 
parameters... 

>     where the network reorders packets during resynchronization.)

I'm not sure we need a sending _and_ a reply SN, but I guess I'm 
missing something; My understanding is that the SN is used by a peer 
to link together request and replies, so if a peer receive a request 
stamped with SN_i, it replies with a reply stamped with SN_i+1; And 
while reXmit, a peer increment by 1 the SN it used the last time 
(i.e., sending packet with SN SN_i, and reXmit with SN_i+1)

Having that being said, I'm in favor of adding SN in the base header, 
and furthermore to initialize the SN to the birthday counter of the 
initial sending party (as stated above).

[I'm leaving for two weeks of vacation, so I apologize in advance for 
my unresponsiveness. However I wish you all a very good christmas and 
a happy new year]

Thanks,

--julien

---

From: [email-masked] (Jukka Ylitalo)
Date: Mon Dec 29 02:37:01 2003

Pekka Nikander wrote:

>> message. However, it  changes the  SPI-B to SPI-A and the ESP 
>> sequence number

Hi Pekka,

You are right. My initial proposal was complex and it didn't explain my 
thoughts. 

Basically, it is good to avoid the signature checking at the Initiator's 
end-point when
it receives resynch-R1.  I may be wrong, but I belive that a malicious 
node may send a storm
of resync-R1s.  The R1 receiver must always verify the signature in R1 
to be sure that the peer has rebooted. Therefore, a malicious node may 
course a CPU DoS attack and consume CPU power at the initiator's 
end-point. (A buzy server may receive a storm of resync-R1s. It must 
either drop the resync-R1s, or verify them.)

One way to avoid the attack is to make a Return Routability test to 
check, using symmetric cryptography, that the peer has really rebooted. 
If the RR test fails the resync-R1 receiver
should believe that the peer has rebooted.     

[May be I have not understood the problem well enough, but I presented 
anyway
this viewpoint.]

--Jukka

---

From: [email-masked] (Pekka Nikander)
Date: Mon Dec 29 02:52:00 2003

Jukka,

> You are right. My initial proposal was complex and it didn't explain 
> my thoughts.
> Basically, it is good to avoid the signature checking at the 
> Initiator's end-point when
> of resync-R1s.

Yes, I agree, and you are right.

> The R1 receiver must always verify the signature in R1 to be sure that 
> the peer has rebooted. Therefore, a malicious node may course a CPU 
> DoS attack and consume CPU power at the initiator's end-point. (A buzy 
> server may receive a storm of resync-R1s. It must either drop the 
> resync-R1s, or verify them.)

Well, the purpose for including a portion of the ESP packet is
to include a kind of RR check into the procedure.  The
to-be-Initiator sends an ESP packet, and gets back an
resynch-R1.  It checks that the resynch-R1 contains (a portion)
of the ESP packet it has recently sent.

The only problem I see is the way of checking that the
ESP packet has been recently sent.  The SPI and replay
protection fields probably help, but the details need
to be worked out.

> check, using symmetric cryptography, that the peer has really 
> rebooted. If the RR test fails the resync-R1 receiver

I don't see how symmetric crypto helps here.  You don't
have any shared state since the other host has
(assumedly) rebooted.  Hence, what you can use is simple RR.
Including the ESP packet into the resynch-R1 creates
a simple RR test.

But maybe I am missing something?

--Pekka

---

From: [email-masked] (Jukka Ylitalo)
Date: Mon Dec 29 05:24:03 2003

> protection fields probably help, but the details need

Right.  Buffering every outgoing ESP packet is not a feasible solution.
One alternative would be to implement a reply protection window mechanism
also for outgoing ESP packets. (The window's right end would be at the 
latest
outgoing sequence number.)  Whenever, the to-be-initiator receives 
resynch-R1,
it may verify the sequence number of the included ESP message, using the
outgoing replay protection window. The problems arises, when the reply
protection window left end is advanced too fast.

Another alternative is to  buffer every x:th outgoing ESP sequence number,
and store it in the HIP context. The problem arises at the other end-point.
In other words, How the responder knows, which of the incoming ESP 
message it should
include into the resync-R1 message? The to-be-initiator should "tag" the 
special
ESP messages.

The responder could use the lowest order bit of the SPI number for tagging.
That is, every SA would be identified with two SPIs with different low 
order bit.
The to-be-initiator sends every x:th packet with "tagged" SPI. When,
the responder receives the SPI with low order bit 1, it replies with 
resync-R1.
However, this approach would require changes in the IPSec implementation.

Another alternative would be to use an extra "reboot" SA between the hosts.
The to-be-initiator should send every x:th messages using the "reboot" SA.
The "reboot" SAs would be identified with SPIs with low order bit 1. Normal
SPIs would contain low order bit 0.

(I believe, that there are several other, and probably better solutions.)

> But maybe I am missing something?

Yes, you are rigth. What I meant, is that the resync-R1 receiver should 
not have to sign
anything.  The resync-R1 receiver should use HMAC to protect the RR 
test, instead of using signatures. If the authentic responder has not 
rebooted and has a context, the authentic responder is able to verify 
the RR packet and reply to it.  However, by sending a storm of 
resync-R1s, the malicious node may cause extra RR-tests and extra 
traffic.  Finally, I prefer more your original
resynch-R1 proposal.

> --Pekka
-- Jukka

---

From: [email-masked] (Pekka Nikander)
Date: Mon Dec 29 07:05:01 2003

Julien,

> birthday's low order bits).

I don't immediately see what's the benefit of initiating the
sequence number from the birthday.  Would you please explain?

> included in the returned ESP chunk (because there's only one RTT).

Agree.  But I still fail to see the details.  Maybe I need to
write code.

> returned ESP SN (in RESYNC packets), but I dunno how many packets

Yes.  Probably as large as the underlying ESP replay window.

> This is, in essence, equivalent to include the ESP SN in some HIP

Good observation.  OTOH, including the (beginning) of an ESP
packet has a couple of benefits:
   - its easier, you just blindly copy bytes
   - it gives the receiver the some extra possibilities, e.g.,
     to check also the IV in addition to the SN, or something
     similar.  The receiver can even decrypt the beginning of
     the encrypted portion, and use some data from there.

> (i.e., sending packet with SN SN_i, and reXmit with SN_i+1)

I don't believe that all HIP exchanges will happen in lock-step
fashion.  There will be multiple transactions going on at the
same time, especially when you have multiple mobile interfaces.

Hence, both parties need to have separate sequence numbers, and
the relevant replies need to include the complete sequence
number of the packet that they refer to.

> my unresponsiveness. However I wish you all a very good christmas and

[I wish you will have had a nice and refreshing vacation by the
time you come to read this.]

--Pekka