Re: [Hipsec] more comments on draft-ietf-hip-rfc5201-bis-04

["Ahrenholz, Jeffrey M" <[e-mail]>]

> checksum fails; instead, it MUST silently drop the packet." If we MUST
> silently drop a packet, why do we have NOTIFY type 26,
> "CHECKSUM_FAILED"? (Debugging?)
> 
> Hmmm good question. This was already that way in RFC5201-bis. I think
> we have three options here:
> 
> a) go for "SHOULD silently drop".
> Implementors could use the notify if they have a good reason to do so.
> 
> b) remove the NOTIFY type 26
> 
> c) state that is for debugging purposes only and sending notifies for
> malformed checksums MUST be turned off by default.
> 
> I don't have a strong preference on either of the solutions. Any
> comments from the group?

(c) seems like a good solution


> > Section 6.11 item 4: this says the association is considered broken
> if an
> > UPDATE is not ACKed, but one circumstance where the association is
> NOT broken
> > would be when a host is informing its peer of its current address
> list
> > (without changing the current preferred locators used.) In that case,
> the
> > association may continue happily without going to CLOSING.
> >
> 
> Well, the payload channel might be still functional in that case.
> However, the missing ACK on the control channel is certainly a sign
> that something is wrong with the HIP association.
> I think if the problem persists (sender of the update keeps
> retransmitting the update with the seq and receiver does not
> acknowledge it) it indicates that the HIP channel is broken.
> Trying to re-establish the connection (by first closing it and then
> doing another BEX (because user data is still coming) might be the best
> choice here.
> Am I missing something here?

I guess I was thinking the SEQ/ACK mechanism was not always required. But yes, if every UPDATE requires a SEQ and ACKs have gone missing, this is probably the best thing to do (close the association).

> All parameter descriptions are given in bytes. I think going to bits in
> that single case would confuse people, don't you think? On the other
> hand, security-related discussions (as for hash functions, etc.) mostly
> refer to bits in literature. So I wouldn't want to change that here
> either.
> We could try to untangle a bit by not reusing the quantity n as bit and
> bytes, though. We could just refer to RHASH_len/8 bytes for I and J:

OK, yes. My comment was how "n" referred to both bits and bytes here; using RHASH_len/8 does untangle that a bit.

-Jeff