Re: [rohc] Last call comments for ROHCoIPsec: draft-ietf-rohc-hcoipsec, draft-ietf-rohc-ikev2-extensions-hcoipsec, draft-ietf-rohc-ipsec-extensions-hcoipsec

Emre Ertekin <emreertekin.ietf@gmail.com> Fri, 25 September 2009 13:24 UTC

Return-Path: <emreertekin.ietf@gmail.com>
X-Original-To: rohc@core3.amsl.com
Delivered-To: rohc@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 614E03A67F8; Fri, 25 Sep 2009 06:24:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level:
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqWurVSzhu8z; Fri, 25 Sep 2009 06:24:45 -0700 (PDT)
Received: from mail-yx0-f174.google.com (mail-yx0-f174.google.com [209.85.210.174]) by core3.amsl.com (Postfix) with ESMTP id 713903A687D; Fri, 25 Sep 2009 06:24:45 -0700 (PDT)
Received: by yxe4 with SMTP id 4so3075048yxe.32 for <multiple recipients>; Fri, 25 Sep 2009 06:25:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=8xhfiqqCwyO3DlJ+Z+CswCk98ZRVLbSgrQKmE0CTCk0=; b=Cao+Y1XREvP9lNJ1gUWQhMslkomXrQ7KLsNSgMsL4YD1pXv1hJYhR6afXWlImH1hyb 0C3wjr8YESh4EgeQl/vVHfvqF7nCAvzY439gMbJuJ2DbpHiQDeUaPAK18myoOCHR4fTv pe3gC0+MFC3TCpTWYdt8wvOCPcN16LRCLyPhQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=OWO6aGeCsTyR9EIh2Fe2nx5VUuzWCGW+D/UmEeHQtQV2N3li1OIv4r2//Io4f+Vr/t zmRjQ3R8n3ZpjKO358bHlrCQDFptYtAZR9X/NqmQsY/+C8XoyktpAMKJvg6DiVSVm87p FNK7o/qWS0MYe19ECacLMR8JThtjGCz62Y2As=
MIME-Version: 1.0
Received: by 10.101.131.17 with SMTP id i17mr203724ann.30.1253885152959; Fri, 25 Sep 2009 06:25:52 -0700 (PDT)
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773C0965263C@NOK-EUMSG-01.mgdnok.nokia.com>
References: <e13d6ad60909202013q406f98e3w2ed4f9a896f3d9de@mail.gmail.com> <808FD6E27AD4884E94820BC333B2DB773C0965263C@NOK-EUMSG-01.mgdnok.nokia.com>
Date: Fri, 25 Sep 2009 06:25:52 -0700
Message-ID: <e13d6ad60909250625l55f478ybcac65add11ec745@mail.gmail.com>
From: Emre Ertekin <emreertekin.ietf@gmail.com>
To: Pasi.Eronen@nokia.com
Content-Type: text/plain; charset="ISO-8859-1"
Cc: rohc@ietf.org, ietf@ietf.org
Subject: Re: [rohc] Last call comments for ROHCoIPsec: draft-ietf-rohc-hcoipsec, draft-ietf-rohc-ikev2-extensions-hcoipsec, draft-ietf-rohc-ipsec-extensions-hcoipsec
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Robust Header Compression <rohc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rohc>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Sep 2009 13:24:46 -0000

Hi Pasi,

> > > 4) None of the drafts have any RFC 2119 keywords
> > > (MUST/SHOULD/etc).  They SHOULD use those to make it less
> > > ambiguous what is the required behavior (and what is optional) to
> > > claim compliance with these drafts.
> >
> > OK, we will take a run through the IKEv2 and IPsec extensions drafts
> > to account for these keywords.  Not the framework draft though, since
> > the draft is intended to be informational.
>
> Being "Informational" (vs. Proposed Standard) RFC has nothing to do
> with
> the question -- many Informational RFCs do use RFC 2119 keywords, and
> there's nothing special about that.
>
> To me, it looks like the framework draft has normative statements
> (things implementations are required or recommended to do in order
> to get interoperability), too, so 2119 keywords would be appropriate
> (and actually, it could be Standards Track, too).

OK.  I just meant that the framework draft was intended to be guidance
for ROHCOIPsec implementers.  However, since you think there are
benefits to including these keywords, I'll update the draft to include
them.

> > > 6) ikev2-extensions, Section 2.1.2, says "The key for this
> Integrity
> > > Algorithm is computed using the same method as is used to compute
> > > IPsec's Integrity Algorithm key ([IKEV2], Section 2.17)."  I don't
> > > think this is sufficient to get interoperable implementations; more
> > > details are needed.
> >
> > Could you clarify why this is not sufficient?
>
> If it's computed using exactly the same method as the IPsec Integrity
> Algorithm Key, it would be the *same* key, and that's certainly not
> the intent here.
>
> Perhaps something like "The keys (one for each direction) for this
> Integrity Algorithm are derived from the IKEv2 KEYMAT (see [IKEV2],
> Section 2.17). For the purposes of this key derivation, ROHC is
> considered to be an IPsec protocol."?

Sounds good to me.

BR,
Emre