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

"Ahrenholz, Jeffrey M" <> Fri, 11 February 2011 15:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2EE363A69CC for <>; Fri, 11 Feb 2011 07:25:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qDh2VidCuVu2 for <>; Fri, 11 Feb 2011 07:25:44 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1D6823A69B2 for <>; Fri, 11 Feb 2011 07:25:44 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p1BFPrxE014281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Feb 2011 09:25:53 -0600 (CST)
Received: from (localhost []) by (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p1BFPqAS000618; Fri, 11 Feb 2011 09:25:52 -0600 (CST)
Received: from ( []) by (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p1BFPqVq000586 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 11 Feb 2011 09:25:52 -0600 (CST)
Received: from ([]) by ([]) with mapi; Fri, 11 Feb 2011 07:25:52 -0800
From: "Ahrenholz, Jeffrey M" <>
To: Tobias Heer <>
Date: Fri, 11 Feb 2011 07:25:51 -0800
Thread-Topic: [Hipsec] more comments on draft-ietf-hip-rfc5201-bis-04
Thread-Index: AcvJ3jJJMWUi0LS5QxWyBioAmWXkygAH7YgQ
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [Hipsec] more comments on draft-ietf-hip-rfc5201-bis-04
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 Feb 2011 15:25:45 -0000

> 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.