Re: [secdir] secdir review of draft-ietf-lisp-lcaf-15

Dino Farinacci <> Sun, 25 September 2016 22:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 11F8112B02F; Sun, 25 Sep 2016 15:15:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.288
X-Spam-Status: No, score=-1.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_HTML_ATTACH=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ia-qz06TJ_NV; Sun, 25 Sep 2016 15:15:05 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 18CD812B01F; Sun, 25 Sep 2016 15:15:05 -0700 (PDT)
Received: by with SMTP id oz2so56069555pac.2; Sun, 25 Sep 2016 15:15:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=QLg4BVl5h93mOJhpow6pj7/91TzCZJ/WMt2YMinI5j0=; b=pRZlZsNF/+5i9tldwbUbVFl5PgRxosedOQOsCVRacjX+TYFs1CWdy6gDwlaUSnV/ym Jpiue3tRjeWRC4li4tpVM0jr+AuxScKXC7suGmkTCBSwEastuFSzXirTMStTxDcGL3pS 79IwGmZ9tHFNEsbbbM3oQ5HKBKCsCVrhHlxdGGxeSx6urq58iIp0JpzzB/30FjRxVMF4 i65d9D3v+7Z4ky0Rm93Dh3Bsd66IV4kOsUU2b2KqQZimAqeHBxPpMU8NNqEU9gTxLMK0 YSDglD4s5m+DWCaOA7zQYjlr+2FZuVtDazCC9Tdmiq024IU+mfUfFJFgg/Yenbt9WwqK wNuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=QLg4BVl5h93mOJhpow6pj7/91TzCZJ/WMt2YMinI5j0=; b=jpE3TrQSj/ZoLjr4MxBC+Pu5Fxprma1SyA1sXbT96Yx6GQxKImtnD9BtJiTrvSksH/ 0BiOFWqXgYCEKSqDw/zH5UX7eC8sJBHcjpg7WtICKUdPqi5hSjlbmSYpgBXeBeA/r3bF UlxmnR6gP0Cii/MaIcKwiShZVk+GVcmmX794mBGV+UEsvpam647iu/ipKqNv9DqHQHMy ggJWZc9Kf9FvVlqpfVZfS2Bdjm599frnI/X0E5m5MP53NhAxHALizCISPCli8OtPIVJD l9anR/ItY6cDQF/hIWlVGtnnnEfb1GRWYLUqTWmTH/JarwR1yecyYLVlOIVvSytd5hFq 2CDA==
X-Gm-Message-State: AA6/9Rl+ZXwd85YNdYLod/tJPG4jN4q9fsMloAQvq3QWNL36Vmzp4j104b1PJTwVLCCilw==
X-Received: by with SMTP id sa4mr11054842pac.176.1474841704696; Sun, 25 Sep 2016 15:15:04 -0700 (PDT)
Received: from ?IPv6:2601:646:8d01:89f0:7958:5e82:524d:c6d5? ([2601:646:8d01:89f0:7958:5e82:524d:c6d5]) by with ESMTPSA id p128sm25691595pfg.38.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 25 Sep 2016 15:15:03 -0700 (PDT)
Content-Type: multipart/mixed; boundary="Apple-Mail=_C7271863-ADC2-4658-B35F-55679EB2C47D"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Dino Farinacci <>
In-Reply-To: <>
Date: Sun, 25 Sep 2016 15:15:02 -0700
Message-Id: <>
References: <>
To: David Mandelberg <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc: Dino Farinacci <>, The IESG <>,,
Subject: Re: [secdir] secdir review of draft-ietf-lisp-lcaf-15
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 25 Sep 2016 22:15:12 -0000

> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security
> area directors.  Document editors and WG chairs should treat these
> comments just like any other last call comments.

Thanks a lot for your comments. See responses inline.

> I found one issue in various parts of the document (described below),
> but I'm not sure it's relevant to security. If it is, then I think this
> document is Almost Ready. If not, then I think this document is Ready
> With Nits.
> There are multiple places in the document where it's possible to encode
> semantically equivalent information in multiple ways, despite the word
> "canonical" being in the title of the document. Is there anything that
> relies on these addresses being canonical for security purposes?

No not for security purposes. There are multiple ways because we allow some nesting of information as well as allow for compatibility for older implementations that can’t parse some AFIs and LCAFs but is required to parse the AFI-List LCAF type.

> Multiple places in the document (sections 4.1, 4.5, and 4.8) specify
> mask lengths, but do not specify that the masked out bits MUST be set to
> zero.

Hmm, by definition, a mask-length of say 24 if a mask of 0xffffff00. And in 4.1:

  IID mask-len:  if the AFI is set to 0, then this format is not
      encoding an extended EID-prefix but rather an instance-ID range
      where the 'IID mask-len' indicates the number of high-order bits
      used in the Instance ID field for the range.

It is clear that the high-order bits are used that cover the mask-length and the low-order bits are ignored. Is this not clear to you? Would you want me to say the high-order bits are added with a mask and the bits not covered by the mask are set to 0?

> Section 4.4: The description of RTR RLOC Address gives two different
> ways to encode an address with zero RTRs.

Correct. Since a list of RTRs can be encoded, you could have this encoding (which is valid and needs to be dealt with, hence the language):

afi=1, IPv4 RTR
afi=0, nothing follows
afi=2, IPv6 RTR

The above is a list of 2 RTRs but encoded with 3 entries.

> Section 4.10.5: If I understand the compatibility mode correctly, this
> explicitly creates a second way to encode a semantically identical address.

Right, if an implementation does not support the Geo-Coordinates LCAF encoding but wants to encapsulate to the RLOC encoded, it knows how to skip over the Geo-Coordinates section and get to an AFI encoded address that it knows how to parse and use.

> Section 5.4: There are many different ways to encode equivalent JSON
> data here.

Maybe, but can you be more clear. I don’t think it is a bug. Do you?

> Section 6 (Security Considerations): There is no discussion of these
> addresses being canonical, and what other systems might or might not
> rely on these addresses being canonical.

In this respect “canonical” is relative to how LISP defines to encode both simple AFI encoded addresses or more complex/flexible addresses that accompany information.

> I also have some questions/nits:
> Section 3: Shouldn't the LCAF sort-key of {afi, LCAF-Type} also include
> the RLOC-address or LCAF payload?

It cannot because each LCAF-Type has a complex set of attributes. Sometimes a list of RLOCs.

> Section 4.3: Altitude is described as a signed integer, but this
> document doesn't specify the encoding. I assume it's two's complement,
> but that should probably be made explicit.

Yes, I have fixed the text.

> Section 4.7: The Key Count description talks about "Key sections," but
> doesn't say which fields are part of the key section (and can thus be
> repeated). I have a guess which fields are part of the key section, but
> it's not entirely clear.

I added some text to clarify this.

> Section 4.7: The Key Algorithm description doesn't point to a registry
> of valid values or otherwise say how to interpret values in that field.

We have put that in a use-case document. This Security Key LCAF is used by 2 use-cases. It is used for LISP-DDT and for lisp-crypto. In the lisp-crypto document we have a registry for cipher suites used.

> -- 
> David Eric Mandelberg / dseomn

See enclosed a -16 txt file and rfcdiff.html file.

Thanks again,