Subject: [lisp] Stephen Farrell's Discuss on draft-ietf-lisp-lcaf-17: (with DISCUSS)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 13 Oct 2016 06:05:11 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-lisp-lcaf-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-lcaf/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I basically support Alexey's discuss position and Ben's
comment but with a bit more detail below.

- section 3: I don't see how you can produce a canonical
order of the LCAF encodings if two can contain e.g. the
same values other than different URLs, since there is no
canonical way to order URLs (or JSON structures etc.)
without a lot more specification.

- 4.3: I agree with Ben's comment. You ought include some
text here to the effect that this information can be
privacy senseitive and to recommend not sending or
storing it in such cases.

- 4.4: there are also potential privacy issues here if
this could be used to identify traffic that is from one
specific host behind a NAT. A similar privacy warning
should be included.

- 4.7: Sorry, when is key material sent in a message? How
is that protected? (Key ids are fine, but not key values)

- 4.10.2: The same privacy issues apply here as for 4.3
and 4.4, if the MAC address maps to e.g.  a portable
device carried by a person.

- 4.10.3 and all of section 5: What are these for?  I
don't see the sense in defining these if there is no well
defined way to use them. Any of these might have
undesirable security and/or privacy characteristics.

- Section 6: There are security considerations.  See
above.

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 14 Oct 2016 06:21:21 -0700

> comment but with a bit more detail below.

Thanks for your comments Stephen.

> without a lot more specification.

We want to define an order so if an implementation parses, say Type 4, it can optimize to know that Types 1-3 will not come after Type 4. We can achieve that with this text:

  [RFC6830] states RLOC records are sorted when encoded in control
  messages so the locator-set has consistent order across all xTRs for
  a given EID.  The sort order is based on sort-key {afi, RLOC-
  address}. When an RLOC is LCAF encoded, the sort-key is {afi, LCAF-
  Type}. Therefore, when a locator-set has a mix of AFI records and
  LCAF records, they are ordered from smallest to largest AFI value.

> storing it in such cases.

I did that for the next revision.

> specific host behind a NAT. A similar privacy warning

It does not identify any host.

> is that protected? (Key ids are fine, but not key values)

That is documented in the two use-case references.

> device carried by a person.

In this case, the MAC address can be a host/person. I put a refernece to the Security Considersations section that references RFC6280/BCP160.

> undesirable security and/or privacy characteristics.

We have use-cases for them. And they are being documented in both other working group and individual contributed drafts.

> - Section 6: There are security considerations.  See

I added text per Ben’s comments.

Thanks,
Dino

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 14 Oct 2016 06:21:48 -0700

Thanks,
Dino