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!
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
