Subject: Re: [Hipsec] WGLCs: 4423bis and 5201bis

From: Miika Komu <[email-masked]>
Date: Tue, 16 Oct 2012 22:00:20 +0300

Hi,

On 09/23/2012 06:35 PM, René Hummen wrote:
> Hi all,
>
> I had a close look at draft-ietf-hip-rfc5201-bis-09 and found some
> technical as well as editorial issues that I consider worth discussing
> and fixing. Please note that especially the technical issues regarding
> the used packet space may not be considered problematic in case of
> everyday Internet connections. However, resource-constrained
> environments as targeted by RPL, 6LowPAN, CoAP, and HIP DEX have hard
> payload limits. Here, a few bytes of additional packet size can
> determine whether packets need to be fragmented or not. Therefore, I
> think, we should also consider these scenarios in the basic HIP
> specification that is shared by all HIP variants.
>
> I structured my feedback into different topics highlight by ###.
>
>
> Technical issues:
> ------------------------
>
> ### R1 Counter ###
>
> 4.1.4.  HIP Replay Protection
> "The R1 counter SHOULD NOT roll over."
>
> No explanation is given what implementors should do when a roll over
> occurs.

Did you notice that the same section continues with:

    Upon conclusion of an active HIP association with another host, the
    R1 generation counter associated with the peer host SHOULD be
    flushed.  A local policy MAY override the default flushing of R1
    counters on a per-HIT basis.  The reason for recommending the
    flushing of this counter is that there may be hosts where the R1
    generation counter (occasionally) decreases; e.g., due to hardware
    failure.

Then, later we have in section 6.16. Handling State Loss:

    In the case of system crash and unanticipated state loss, the system
    SHOULD delete the corresponding HIP state, including the keying
    material.  That is, the state SHOULD NOT be stored on stable storage.
    If the implementation does drop the state (as RECOMMENDED), it MUST
    also drop the peer's R1 generation counter value, unless a local
    policy explicitly defines that the value of that particular host is
    stored.  An implementation MUST NOT store R1 generation counters by
    default, but storing R1 generation counter values, if done, MUST be
    configured by explicit HITs.

> I suggest to add the following text:
>
> "If a roll over is detected, the associated HIs SHOULD be removed and
> new ones should be generated."
>
> Note, however, that such a change would also invalidate ACLs and HI-IP
> lookup information based on the original HIs.

I believe a responder could be tricked into exhausting it's counter 
values by a malign initiator? This is bad because changing the identity 
would affect all host associations, not only the one with the malign 
initiator?

> ### HIP Checksum ###
>
> 5.1.1.  Checksum
>
> What is the reason for using the IP-based pseudo-headers here? If I am
> not overlooking something, non-HIP-aware NATs on the communication
> path effectively break the HIP checksum. I know that this is the way
> how TCP/IP pseudo-headers are defined. Still, I suggest to only
> checksum the HIP header and the HIP parameters to avoid problems in
> the future and to maintain layer separation. What happens if HIP is
> used in non-IP environments?

I have never liked the pseudo-header concept myself either but I think 
it's mandated by IPv4 and optional in IPv6 (for instance, with UDP). For 
instance, RFC5770 overrides that HIP checksum should be zero when the 
HIP control packet is encapsulated in UDP:

http://tools.ietf.org/html/rfc5770

5.1. HIP Control Packets:

The HIP header and parameters follow the conventions of [RFC5201] with 
the exception that the HIP header checksum MUST be zero.

Authors, can we get rid of the pseudo header or are we stuck with it? Or 
can we make it optional (like with UDP and IPv6)?

I think we can live with it but, at least, it would be useful to mention 
that the checksum MAY be zero depending on the underlying encapsulation 
as specified by further extensions.

> ### Decreasing the per-packet overhead ###
>
> 4.1.2.  Puzzle Exchange
> "Using the Opaque data field in the PUZZLE (see Section 5.2.4), in an
> ECHO_REQUEST_SIGNED (see Section 5.2.20) or in an
> ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.21), the Responder
> can include some data in R1 that the Initiator MUST copy unmodified in
> the corresponding I2 packet."
>
> 5.2.4.  PUZZLE
> "The Opaque and Random #I field are not covered by the HIP_SIGNATURE_2
> parameter."
>
> Especially in resource-constrained environments such as targeted by
> HIP DEX, each byte that needs to be transmitted is valuable (from a
> power perspective) and may lead to fragmentation at the lower layers.
> Hence, I suggest removing the 2 bytes of opaque value from the PUZZLE
> parameter and to add +2 to the type number (resulting in 259) for the
> new PUZZLE type. If the Responder has to transfer state in an unsigned
> fashion, we already provide the ECHO_REQUEST_UNSIGNED parameter for
> this purpose. Furthermore, the opaque value does not seem to be
> necessary, as HIPL currently does not use it.

maybe HIPL should start using it. AFAIK, the echo requests are optional, 
so I think having the puzzle opaque field is good from the view point of 
extra security. At least puzzle nonces can be used for puzzle indexing:

4.1.2. Puzzle Exchange:

    Using the Opaque data field in the PUZZLE (Section 5.2.4), in an
    ECHO_REQUEST_SIGNED (Section 5.2.19) or in an ECHO_REQUEST_UNSIGNED
    parameter (Section 5.2.20), the Responder can include some data in R1
    that the Initiator must copy unmodified in the corresponding I2
    packet.  The Responder can generate the Opaque data in various ways;
    e.g., using encryption or hashing with some secret, the sent I, and
    possibly other related data.  Using the same secret, the received I
    (from the I2), and the other related data (if any), the Receiver can
    verify that it has itself sent the I to the Initiator.  The Responder
    MUST periodically change such a used secret.

Have you considered this?

Or maybe it's better to skip just the ECHO REQUESTS in constrained 
environments?

Have you calculated that the 2 bytes are really makes a real difference 
in practice for fragmentation with 6lowpan?

Power perspective has been discussed at least in the link below but care 
to elaborate?

http://www.cs.helsinki.fi/u/gurtov/papers/hip_dex.pdf

> 5.2.5.  SOLUTION
>
> Here, I suggest removing 1 byte of reserved space and the 2 byte,
> echoed opaque value for the same reason presented above. The type
> number could be moved to 323 (SOLUTION + 2). If we need to modify the
> puzzle parameter for some reason in the future, I suggest to design a
> new parameter instead of using the reserved field. That is how new
> semantics are handled for any other parameter as well (see MAC_X).

I am not really objecting to your change but it would helpful to 
understand the real need and see some numbers (with ECC HIP) behind your 
suggestions. IEEE 802.15.4 payload size is between 72–116. Here's some 
numbers:

http://www.cs.helsinki.fi/u/gurtov/papers/hip-medical.pdf

While DEX MTU is considerably smaller, HIP BEX payload size with 
ECDH+ECDSA is reported (in bytes) as follows:

* 40 (I1)
* 916 (R1)
* 644 (I2)
* 108 (R2)

So, the main problem is the R1 and I2 that are fragmented and their 
"tail" (modulo) size is as follows (first number with 72 and the second 
with 116 payload size):

* R1: 52 / 104
* I2: 68 / 639

As the tail is a bit large, I think saving few bytes does not seem worth 
the extra trouble but it would helpful if somebody could verify my figures?

Some people have also argued that the puzzle concept is not that useful 
at all and we could get rid of it (hence, we would save more MTU this 
way). We'd still need the I and J for the keymaterial in some other 
parameter though (like the echo request).

> 5.2.3.  R1_COUNTER
> "It SHOULD be included in the R1 (in which case, it is covered by the
> signature), and if present in the R1, it MUST be echoed (including the
> Reserved field verbatim) by the Initiator in the I2 packet."
 >
> Similar to the SOLUTION parameter, I suggest removing the 4 bytes of
> reserved space from the R1 counter parameter and to add +2 to the type
> number (resulting in 131) for the new R1_COUNTER type.

This comes at the cost of losing some future compatibility. Assuming my 
figures are correct, this does not save enough bytes?

> I understand that these changes break parameter compatibility with
> existing v1 implementations. However, I do not consider a new
> parameter layout problematic as the semantics won't change
> considerably allowing for code re-use in most cases.

We have the version bit, so changing things for HIPv2 is fine as long as 
the header remains intact. This brings into my mind that I guess we 
can't save bits by applying compression to the HITs a'la 6lowpan, but 
have people considered if the following optimizations would be worth the 
trouble:

* delta encoding
* removal of parameter padding

Thanks for great comments Rene!

---

From: Miika Komu <[email-masked]>
Date: Tue, 16 Oct 2012 22:21:27 +0300

Hi,

> "tail" (modulo) size is as follows (first number with 72 and the second

(with R2 the modulo is 107 when MTU is 72)

DEX figures were reported as follows:

* 40 (I1)
* 92 (R1)
* 148 (I2)
* 102 (R2)

So I think we should be should be able to shrink packet size at least 20 
or preferably 30 bytes to reduce the number of fragments and make all 
this worthwhile just for DEX:

* R1: 20 / fits
* I2: 146 / 32
* R2: 30 / fits

But I am getting tired and perhaps I got something wrong.

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 16 Oct 2012 20:36:06 -0700

> it's mandated by IPv4 and optional in IPv6 (for instance, with UDP).

For UDP, it is the reverse of the above (optional for IPv4, mandatory for IPv6).  

> For instance, RFC5770 overrides that HIP checksum should be zero when
> the HIP control packet is encapsulated in UDP:
> 

Yes, but UDP checksum covers IPv6 header in that case.  There is also a proposal to zero the UDP checksum in other UDP tunnel situations:
http://tools.ietf.org/html/draft-ietf-6man-udpzero-06

but I haven't seen it proposed for non-tunnel situations.

> Authors, can we get rid of the pseudo header or are we stuck with it?
> Or can we make it optional (like with UDP and IPv6)?
> 
> I think we can live with it but, at least, it would be useful to
> mention that the checksum MAY be zero depending on the underlying
> encapsulation as specified by further extensions.

I am hesitant to be a trailblazer in removing the IPv6 header integrity checking.  I'd rather add a note such as you suggest (if underlying transport provides necessary integrity check, as specified in other documents).

- Tom

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 16 Oct 2012 20:43:59 -0700

This is a brief summary of what I believe to be the remaining open issues after WGLC.

RFC 4423: 

- I raised some issues in a review, still not addressed in the recent -05 version:

  -- section 13 incomplete
  -- no mention of revocation
  -- need better summary of multicast

I'll try to propose some text to Robert.

- Sasu Tarkoma published some observations (10 October) which may lead to further editorial changes 

- Gonzalo asks whether to go for PS or Information; response to this seemed mixed or neutral

RFC 5201:

- Rene Hummen raised some issues on 23 Sept.  The non-editorial ones:

  -- R1 counter roll over
  -- HIP checksum using pseudoheader
  -- Decreasing overhead with some format changes

The above issues (especially the last two) seem to be still under discussion.

Are there other open issues that I'm forgetting?  

- Tom

---

From: Miika Komu <[email-masked]>
Date: Wed, 17 Oct 2012 12:52:49 +0300

Hi,

On 10/17/2012 06:36 AM, Henderson, Thomas R wrote:

>> The HIP header and parameters follow the conventions of [RFC5201]
>> with the exception that the HIP header checksum MUST be zero.
>>
>> Authors, can we get rid of the pseudo header or are we stuck with
>> it? Or can we make it optional (like with UDP and IPv6)?
>>
> I am hesitant to be a trailblazer in removing the IPv6 header
> integrity checking.  I'd rather add a note such as you suggest (if
> underlying transport provides necessary integrity check, as specified
> in other documents).

I am fine with just adding such a note.

---

From: René Hummen <[email-masked]>
Date: Wed, 17 Oct 2012 15:04:31 +0200

Hi,
>    generation counter (occasionally) decreases; e.g., due to hardware

Yes, but this describes the behavior of the peer, not of the host sending the R1 counter value. Hence, this does not mention how to deal with roll overs.

Still, how does this text (same section) apply if the peer does not store the R1 generation counter?

   "Initiators are protected against R1 replays  by a monotonically increasing "R1 generation counter" included in the R1."

>    configured by explicit HITs.

Ok, so a system crash effectively resets the generation counter without expiring the HI. However, what about the case when the peer really uses the generation counter for replay protection purposes? This will possibly break connectivity for a long time...

> would affect all host associations, not only the one with the malign 

Your described vulnerability strongly depends on how a system maintains puzzle generations:
   "Implementations MUST accept puzzles from the current generation and MAY accept puzzles from earlier generations. A system's local counter MUST be incremented at least as often as every time old R1s cease to be valid."

Furthermore, should the latter sentence be rephrased as follows for higher clarity?
   "A system's puzzle generation counter MUST be incremented at least as often as old puzzle values cease to be valid."

BR,
René

--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: +49 241 80 21429
web: http://www.comsys.rwth-aachen.de/team/rene-hummen/

---

From: Miika Komu <[email-masked]>
Date: Thu, 18 Oct 2012 12:42:42 +0300

Hi,

> Yes, but this describes the behavior of the peer, not of the host sending the R1 counter value. Hence, this does not mention how to deal with roll overs.

You're right, this is an open issue.

Authors, I find this text a bit tricky to read because does not use the 
absolute terms of "Initiator" and "Responder". I suggest improving the 
text unless the R1 generation counter is used for e.g. UPDATE. The same 
applies to section 6.16. (Handling State Loss).

>     "Initiators are protected against R1 replays  by a monotonically increasing "R1 generation counter" included in the R1."

I assume that you mean initiator with peer? I think it's in the best 
interest of the initiator to store it as it improves security. If it 
doesn't and always accepts it, then the communications is less secure.

If you mean the responder, I think it can opt out and not send the R1 
generation counter at all, since it's optional. If it does send the 
generation counter, it MUST store the counter.

> Ok, so a system crash effectively resets the generation counter without expiring the HI. However, what about the case when the peer really uses the generation counter for replay protection purposes…

There's several editorial issues with this text:
* As said earlier, please use Initiator and Responder terms for clarity 
avoid ambiguity with relative terms?
* The last sentence is in conflict with section 6.8: "The system MUST 
store the received R1 generation counter for future reference"
* It is unclear if the stable storage applies to R1 counters or not.

Particularly, I think the authors should break down the crashing cases 
separately:

1. Initiator crashes: it should reset the stored counter and accept any 
new values from Responders.
2. Responder crashes: it should start with a new counter value. 
Initiating hosts with previous contact with the Responder may experience 
some delay until the Host Association at the Initiator expires and it 
resets the counter value.
3. Both crash. The previous case combined; no issue here.

4.1.2. Puzzle Exchange:

    It is RECOMMENDED that the Responder generates a new puzzle and new
    R1s once every few minutes

I take my comment back; the counter is liked to puzzle generation which, 
in turn, is recommended to be periodical rather than based on the number 
of iniatiators. So, the roll over is bound to time.

>     "A system's puzzle generation counter MUST be incremented at least as often as old puzzle values cease to be valid."

Fine by me.

---

From: Miika Komu <[email-masked]>
Date: Thu, 18 Oct 2012 12:50:50 +0300

Hi,

On 10/18/2012 12:42 PM, Miika Komu wrote:
>> Yes, but this describes the behavior of the peer, not of the host
>> sending the R1 counter value. Hence, this does not mention how to deal
>> with roll overs.
>

I think the whole R1 counter concept is a bit cumbersome because it is 
buried into local policy issues and the roll over is problematic. I 
would suggest removing the R1 counter and simply mandating the Responder 
to send ECHO_REQUEST_SIGNED and the Initiator to send it in I2. Since 
the nonce is fresh and signed, it should provide replay protection even 
against a man-in-the-middle attacker.

Opinions?

---

From: Miika Komu <[email-masked]>
Date: Thu, 18 Oct 2012 15:32:32 +0300

Hi,

> parameter though (like the echo request).

forget about this, after a walk along the memory lane with Tom, Bob and 
Pin, the puzzle is useful and we should stick to it. It allows the 
responder to delay an initiator without introducing any 
initiator-specific state at the responder.

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 18 Oct 2012 17:09:35 -0400

>    -- no mention of revocation

I am working on the next revision and have some revocation text. I will 
try and post that here tomorrow.

> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec
>

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 18 Oct 2012 17:12:38 -0400

On 10/18/2012 05:50 AM, Miika Komu wrote:
> would suggest removing the R1 counter and simply mandating the 
> Responder to send ECHO_REQUEST_SIGNED and the Initiator to send it in 
> I2. Since the nonce is fresh and signed, it should provide replay 
> protection even against a man-in-the-middle attacker.
>
> Opinions?

I am using R1 counter for AES-CTR in HIP encryption in DEX for the CTR 
offset.  You are pointing out how this MAY be a problem.  Got to block 
time out to work through this.