Locator/ID Separation Protocol Security (LISP-SEC)
draft-ietf-lisp-sec-29

[Ballot comment]
My DISCUSSes were addressed in version 28/29

Old DISCUSSES:

Note I support the DISCUSSes and COMMENTS of Roman and Murray, and John's comments, and I won't repeat those issues in this review.


#1

The document keeps talking about generating OTK's which are One Time Key's,
and then "securely transports" these. If we have such a secure transport,
why can't this same mechanism be used by the Map-Server for the Map-Request
and Map-Reply message security instead of OTKs?

Possibly I am not understanding the full architecture? An ascii art diagram
would be useful at the beginning of the document.

This all kind of tastes like Kerberos/GSSAPI. Couldn't that be used instead?

Why not just use mTLS between all parties and get rid of all the custom crypto
with OTK's ?

#2

  LISP-SEC deployments SHOULD use AUTH-HMAC-SHA-
  256-128 HMAC function, unless older implementations using AUTH-HMAC-
  SHA-1-96 are present in the same deployment

It makes be sad that 1 older device downgrades the usable algorithm for
all nodes. Would it be possible to change the protocol slightly so those
with sha2 support could use this and only the sha1-only node uses the
old algorithm?

#3

  or by enabling DTLS [RFC9147] between the ITR and the Map-Resolver.

Should this clarify that the DTLS connection should be mutually authenticated?
eg both peers must identify themselves to the other, unlike the more common
(D)TLS connections where only the client authenticates the server. This applies
to multiple locations where it says DTLS can be used.

#4

The Registry "LISP-SEC Authentication Data HMAC ID" seems to really be
conveying a _preference_. Should this be reflected in the name of the
registry? Additionally, can we leave value 0 as Reserved, and make NOPREF
the value 1, etc.

The "Key Wrap Functions" registry specifies 0 as Reserved, but then
associated a KEY WRAP and KDF with this value. That is, it combines
a "Reserved" with a "NULL wrap" entry. These two should be clearly
split - eg reserve 0  with Key wrap and KDf set to "N/A", and if
needed create a "null-wrap-null if an entry is needed with key wrap
and kdf set to "none".

The "Key Derivation Functions" also mixes up NOPREF and Reserved.



COMMENTS:


#1

      This ITR-OTK is included
      into the Encapsulated Control Message (ECM) that contains the
      Map-Request sent to the Map-Resolver, and encrypted.

Is it "encrypted and included"? Or included and the entire ECM encrypted?
I can't parse the "and encrypted" here.

NITS:

Personal pet peeve:  I dislike using +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
and prefer +------+---------+ style lines as it far less distracting and
christmas tree like.

[Ballot comment]
Thanks for dealing with my IANA-related DISCUSS issues.

I concur with John; this was generally well-done and easy to understand.  Nice work.  A couple of suggestions:

In Section 6.1 has:

  E: ETR-Cant-Sign bit.  This bit is set to 1 to signal ...

I think you mean "If this bit is set to 1, it signals ..." or something similar.  Taken literally, the current text means you always set it to 1, but I don't think that's what you meant to say.

I think the fifth paragraph of Section 6.4 is missing a period or something.  I found it hard to parse toward the end.

[Ballot discuss]
Note I support the DISCUSSes and COMMENTS of Roman and Murray, and John's comments, and I won't repeat those issues in this review.


#1

The document keeps talking about generating OTK's which are One Time Key's,
and then "securely transports" these. If we have such a secure transport,
why can't this same mechanism be used by the Map-Server for the Map-Request
and Map-Reply message security instead of OTKs?

Possibly I am not understanding the full architecture? An ascii art diagram
would be useful at the beginning of the document.

This all kind of tastes like Kerberos/GSSAPI. Couldn't that be used instead?

Why not just use mTLS between all parties and get rid of all the custom crypto
with OTK's ?

#2

  LISP-SEC deployments SHOULD use AUTH-HMAC-SHA-
  256-128 HMAC function, unless older implementations using AUTH-HMAC-
  SHA-1-96 are present in the same deployment

It makes be sad that 1 older device downgrades the usable algorithm for
all nodes. Would it be possible to change the protocol slightly so those
with sha2 support could use this and only the sha1-only node uses the
old algorithm?

#3

  or by enabling DTLS [RFC9147] between the ITR and the Map-Resolver.

Should this clarify that the DTLS connection should be mutually authenticated?
eg both peers must identify themselves to the other, unlike the more common
(D)TLS connections where only the client authenticates the server. This applies
to multiple locations where it says DTLS can be used.

#4

The Registry "LISP-SEC Authentication Data HMAC ID" seems to really be
conveying a _preference_. Should this be reflected in the name of the
registry? Additionally, can we leave value 0 as Reserved, and make NOPREF
the value 1, etc.

The "Key Wrap Functions" registry specifies 0 as Reserved, but then
associated a KEY WRAP and KDF with this value. That is, it combines
a "Reserved" with a "NULL wrap" entry. These two should be clearly
split - eg reserve 0  with Key wrap and KDf set to "N/A", and if
needed create a "null-wrap-null if an entry is needed with key wrap
and kdf set to "none".

The "Key Derivation Functions" also mixes up NOPREF and Reserved.

[Ballot comment]

#1

      This ITR-OTK is included
      into the Encapsulated Control Message (ECM) that contains the
      Map-Request sent to the Map-Resolver, and encrypted.

Is it "encrypted and included"? Or included and the entire ECM encrypted?
I can't parse the "and encrypted" here.

NITS:

Personal pet peeve:  I dislike using +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
and prefer +------+---------+ style lines as it far less distracting and
christmas tree like.

[Ballot discuss]
Sections 8.1 through 8.5 all create registries with "Specification Required" rules.  RFC 8126 says this about "Specification Required":

  As with Expert Review (Section 4.5), clear guidance to the designated
  expert should be provided when defining the registry, and thorough
  understanding of Section 5 is important.

Only Section 8.5 includes any such guidance.  Is none needed for the other four?  Also, I'm having trouble understanding the advice that Section 8.5 does give.

[Ballot comment]
I concur with John; this was generally well-done and easy to understand.  Nice work.  A couple of suggestions:

In Section 6.1 has:

  E: ETR-Cant-Sign bit.  This bit is set to 1 to signal ...

I think you mean "If this bit is set to 1, it signals ..." or something similar.  Taken literally, the current text means you always set it to 1, but I don't think that's what you meant to say.

I think the fifth paragraph of Section 6.4 is missing a period or something.  I found it hard to parse toward the end.

[Ballot discuss]
** Since originally scheduled for the telechat in version -26, thank you for adding the following text about preferring HMAC-SHA256 for new deployments in -27:

  The HMAC
  function AUTH-HMAC-SHA-256-128 [RFC6234] MUST be supported in LISP-
  SEC implementations.  LISP-SEC deployments SHOULD use AUTH-HMAC-SHA-
  256-128 HMAC function, unless older implementations using AUTH-HMAC-
  SHA-1-96 are present in the same deployment [RFC2104].

Could this same approach be applied for the algorithms set by KDF ID.  Specifically:

-- Section 6.9 says:

  The key derivation function
  HKDF-SHA1-128 [RFC5869] MUST be supported.
...
  However, since HKDF-SHA1-128 is mandatory to implement, the process
  will eventually converge.


Could it say something to the effect of:

The key derivation function HKDF-SHA256 MUST be supported in LISP-SEC implementations.  LISP-SEC deployments SHOULD use the HKDF-SHA256 HKDF function, unless older implementations using HKDF-SHA1-128 are present in the same deployment.

However, since HKDF-SHA1-128 and HKDF-SHA256 are supported, the process will eventually converge.

-- Section 8.5.  Add HKDF-SHA256 to the "LISP-SEC Authentication Data Key
  Derivation Function ID" registry

[Ballot comment]
Thank you to Alexey Melnikov for the SECDIR review.

** Section 4.
  In this
  way the ETR can maliciously redirect traffic directed to a large
  number of hosts.

Does the number of impact host matter so much as the generic ability to redirect traffic?  I’m imagining that a “surgical” or targeted attack might be equally interesting – for example, if there was a particular services on a given prefix that an attacker wanted to redirect.

** Section 5.

  Those trust relationships are used to securely
  distribute, as described in Section 8.4, ...

Is Section 8.4, really the right reference here?

** Section 6.5
  Implementations of this specification MUST support OTK Wrapping ID
  AES-KEY-WRAP-128+HKDF-SHA256 that specifies the use of the HKDF-
  SHA256 Key Derivation Function specified in [RFC4868]

RFC4868 doesn’t define a HKDF with SHA256.  Do you mean RFC5869?  Same issue in Section 8.4 (IANA table)

** Section 6.5
  4.  The per-message encryption key is computed as:

      *  per-msg-key = KDF( nonce + s + PSK[Key ID] )
      where the nonce is the value in the Nonce field of the Map-
      Request, 's' is the string "OTK-Key-Wrap", and the operation'+'
      just indicates string concatenation.

HKDFs typically take one more input, L, the output size.  Since this is tied to a particular key wrap the options are more constrained.  AES-KEY-WRAP-128 can have both a 128-bit and 192-bit KEK, please explicitly state the expected output size.

** Section 7.4

  As an example, in certain closed and controlled deployments, it is
  possible that the threat associated with an on-path attacker between
  the xTR and the Mapping System is very low, and after careful
  consideration it may be decided to allow a NULL key wrapping
  algorithm while carrying the OTKs between the xTR and the Mapping
  System.

Wouldn’t this violate:
-- Section 6.4, “ITR-OTK confidentiality and integrity protection MUST be provided in the path between the ITR and the Map-Resolver”

-- Section 6.4, “If the NULL-KEY-WRAP-128 algorithm (see Section 8.4) is selected and no other encryption mechanism (e.g.  DTLS) is enabled,
in the path between the ITR and the Map-Resolver, the Map-Request MUST be dropped and an appropriate log action SHOULD be taken”

-- Section 6.5, “MS-OTK confidentiality and integrity protection MUST be provided in    the path between the Map-Server and the ETR.”

** Section 7.7.  Recommend adding that when DTLS is used it confirmed to RFC7525, or even better would be draft-ietf-uta-rfc7525bis.

** Editorial
-- Section 6.2.  Typo. s/authetification/authentication/

-- Section 6.3.  Typo. s/Extentions/Extensions/

[Ballot comment]
# ART AD Review of draft-ietf-lisp-sec-26

cc @fpalombini

Thank you for the work on this document.

I only have a couple of very minor comments, easy to fix - feel free to take them or leave them.

Francesca

## Comments

### DTLS reference

Please add a reference to RFC 9147 on the first occurrence of DTLS in the text.

### + undefined

Section 6.5:
```
      *  per-msg-key = KDF( nonce + s + PSK[Key ID] )
```
It should be explicitly stated in the text what operations "+" denotes in this specification.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
# Éric Vyncke, INT AD, review of # Éric Vyncke, INT AD, review of draft-ietf-lisp-sec-26
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Luigi Iannone for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

I hope that this helps to improve the document,

Regards,

-éric

## COMMENTS

### Section 5, trusts relationships

This section mentions 'trust relationships', but do not explain how those are created ? A forward reference would be welcome (e.g., to section 7.5 but even this is rather weak).

### Section 5, decrypting something that was not encrypted
```
  1.  The ITR, upon needing to transmit a Map-Request message,
      generates and stores an OTK (ITR-OTK).  This ITR-OTK is included
      into the Encapsulated Control Message (ECM) that contains the
      Map-Request sent to the Map-Resolver.
```

Based on the text following this bullet, should the ITR-OTK also be encrypted (as it is decrypted in step 2) ?

### Section 7.5

Are the shared keys per ITR Map-resolver pair or are they shared by *ALL* ITR and the Map-resolver(s). It is probably the former as the latter would be a huge threat of impersonation among ITR. Should there be some text about this ?

### Performance impact of LISP-SEC

Did the authors have an estimate on the performance impact (crypto operations, increased size of the messages) of LISP-SEC? Should there be a section about this potential impact ?


## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
I generally found this a well-written and pleasant to read document. Thanks for the conversation around my earlier DISCUSS. I have a number of additional questions, comments, and suggestions, below.

1. In §6.4,

  The ITR MAY use the KDF ID field to indicate the recommended KDF
  algorithm, according to local policy. 
 
I guess the use of MAY is there because the ITR could also put 0 in that field which we are later told (five paragraphs down) means "no preference" (and not literally no KDF at all, as a plain reading of the string "NONE" in Table 6 would imply).

A few questions and suggestions arise from this:

a. If the ITR puts 0 in that field, and the Map-Server updates it, how should this text in §6.9 be interpreted?

                      If the KDF ID in the Map-Reply does not match the
  KDF ID requested in the Map-Request, the ITR MUST discard the Map-
  Reply
 
I guess the ITR didn't "request" any particular KDF ID when it sent 0, so I guess I can disregard the text I've quoted -- but it's not very clear. Certainly a plain field comparison without special-casing 0 would fail this test. I think there should be some update to clarify this case.

b. But what happens if the Map-Server puts in a KDF ID for a KDF the ITR doesn't support, even if the ITR did send 0? I presume that even though the ITR said "no preference" it still can't process the packet, so it has to discard the Map-Reply just as if it had gotten back a genuinely non-matching KDF ID. If this is so, I think there should be some update to clarify.

c. It seems like the string "No Preference" would be better than "NONE" in Table 6, similar for Table 4.

Similar comments apply to "The Requested HMAC ID field contains the suggested HMAC algorithm" (§6.4) and "If the EID HMAC ID field does not match the Requested HMAC ID" (§6.9).

2. Related to the previous, in Section 6.4, there are two fairly widely separated paragraphs:

  The ITR MAY use the KDF ID field to indicate the recommended KDF
  algorithm, according to local policy.  The Map-Server can overwrite
  the KDF ID if it does not support the KDF ID recommended by the ITR
  (see Section 6.7).

And

  The KDF ID field specifies the suggested key derivation function to
  be used by the Map-Server to derive the MS-OTK.  A KDF Value of NONE
  (0) may be used to specify that the ITR has no preferred KDF ID.

I think it would be better if these were combined, as they seem to be redundant and in any case cover the same subject.

3. For each of the fields whose value is taken from an IANA registry, I think it would be helpful to reference the registry where the field is defined, for example in Section 6.1,

      KDF ID: Identifier of the Key Derivation Function used to derive
      the MS-OTK.  Refer to Section 6.7 for more details.

Could be

      KDF ID: Identifier of the Key Derivation Function used to derive
      the MS-OTK.  Permitted values are registered in the Key
      Derivation Function registry (see Section 8.5). Refer to
      Section 6.7 for more details.

Similarly for all five registries defined here and their respective fields.

4. In §6.5,

  It's important to note that, to prevent ETR's overclaiming attacks,
  the ITR/Map-Resolver pre-shared secret MUST be different from the
  Map-Server/ETR pre-shared secret.

This is a bit picky, but wouldn’t “independent from” be more accurate? Strictly speaking to guarantee that it be different, they’d have to collude (to check for uniqueness), which is exactly what you want to prevent, right?

5. In §6.9, this paragraph is problematic in a few ways,

  In response to an encapsulated Map-Request that has the S-bit set, an
  ITR MUST receive a Map-Reply with the S-bit set, that includes an
  EID-AD and a PKT-AD.  If the Map-Reply does not include both ADs, the
  ITR MUST discard it.  In response to a Protected Map-Request, an ITR
  expects a Map-Reply with the S-bit set to 1 including an EID-AD and a
  PKT-AD.  The ITR MUST discard the Map-Reply otherwise.

The MUST in the second line is misused -- you aren't telling the ITR what it MUST do, you're expressing an expectation that if the other entities are forming their messages per-spec, the Map-Reply will be formed as you state. You already have more actionable language later in the paragraph to cover this case, the "MUST discard" part.

Beyond that, the paragraph is redundant, it says everything twice. If you throw away the redundant text, I think the problem I'm complaining of goes away, for example you could cut it down to:

  In response to a Protected Map-Request, an ITR
  expects a Map-Reply with the S-bit set to 1 including an EID-AD and a
  PKT-AD.  The ITR MUST discard the Map-Reply otherwise.

6. In §6.9, the phrase "the first opportunity it needs to" is used several times, for example,

  If the EID HMAC ID field does not match the Requested HMAC ID the ITR
  MUST discard the Map-Reply and send, at the first opportunity it
  needs to, a new Map-Request with a different Requested HMAC ID field,
  according to ITR's local policy. 
 
I don't understand the "needs to" part, I suspect there is some nuance going on here, of trying to shoehorn LISP-SEC into the control plane in some backward-compatible way, but if so the chosen language is too subtle to be unambiguous.

To try to work through some of the possibilities --

- Leaving out the entire clause "at the first opportunity it needs to" would be clear. It would mean that the ITR is supposed to retry right away. Which seems fine, but is probably not what you're going for (else why have that clause at all).

- Leaving out the words "it needs to" would be the same as the above.

- So, maybe what's being said here is something like, "we expect that an event on the ITR will trigger it to retry anyway, and we're just piggybacking onto that event"?

If that's right, I guess what the ITR is expected to do is something like:

- When it needs to look up a given EID, launch a Map-Request.
- If it gets back a Map-Reply with a different HMAC ID or KDF ID from what it sent (except, maybe not in the case where it sent 0, see my earlier question), do something like keep a notation in a local cache, that says "next time you send a Map-Request for this EID, try this other KDF ID".
- Presumably in the mean time it might have dropped some packets destined to that EID, depending on other details of the deployment.
- At some point it needs to look up that EID again (maybe because it has another packet to deliver) and before launching a new Map-Request it consults its cache and says "aha, I need to use a HMAC ID/KDF ID other than my default one".

The fact that I'm guessing about all this suggests that the spec may not be clear enough on these points. (Or that I'm not reading carefully enough, of course, in which case please point me to the parts I've missed that make it clear.)

7. Nit, §6.9,

  [I-D.ietf-lisp-rfc6833bis] allows ETRs to send Solicited-Map-Requests

Should be "Solicit", not "Solicited".

8. In §6.9,

                                          If an ITR accepts Map-Replies
  piggybacked in Map-Requests and its content is not already present in
  its EID-to-RLOC cache, it MUST send a Map-Request over the mapping
  system in order to verify its content with a secured Map-Reply.
 
Does this mean,

a. The piggybacked Map-Reply will be put into use immediately by the ITR, but a verification will be initiated with a secured Map-Reply? How long is the piggybacked one to be used? What happens if the secured transaction never completes? If this is the intention, it needs to be clarified and probably also discussed in the Security Considerations, because it's not hard to imagine an attacker abusing it. Or is it,

b. The piggybacked Map-Reply is not permitted to be used until it has been verified by a secured Map-Reply? It would be considerably less problematic in terms of security analysis (it's functionally almost the same as the operation of LISP-SEC without piggybacked replies) but less optimal of course.

In either case the spec needs to be clarified.

9. There are four places in §6.9.1 where you say "a log action MUST be taken". I wonder if these unintentionally open a resource exhaustion attack vector, since an attacker might be able to cause an ITR to log like crazy, and logging is often an expensive operation. I guess it depends on just how nuanced you expect the implementor to be in construing what a "log action" is -- if I decide to construe "log action" to implicitly include "with rate limiting" then that's potentially fine, but if I'm a naive implementor and just syslog every time the spec tells me to take a log action, I may be setting myself up as a soft target.

Maybe SHOULD instead of MUST would be a middle ground?

10. By the way, none of the "Receiving a Map-Reply" text talks about other checks. For example, before doing any of the checks specified in §6.9 one might imagine an implementation would first confirm it's even expecting this Map-Reply (presumably looking for a matching unfulfilled Map-Request), and throw it away if not. I briefly looked to see if that's in rfc6833bis but without success. Is the assumption that the checks in §6.9 are performed after other checks that are specified in the base control plane?

11. In §7.6, Replay Attacks, you say

  In case of replayed Map-Request, the Map-Server, Map-Resolver and ETR
  will have to do a LISP-SEC computation.  This is equivalent, in terms
  of resources, to a valid LISP-SEC computation and an attacker does
  not obtain any benefit, since the corresponding Map-Reply is
  discarded as previously explained.

How does the attaker "not obtain any benefit"? Suppose the benefit the attacker is trying to obtain, is to DoS the mapping system or ETR -- aren't they able to use these replayed Map-Requests to force these entities to do work?

12. In §7.7 you say

  DTLS [RFC9147] SHOULD be used to provide communication privacy and to
  prevent eavesdropping, tampering, or message forgery to the messages
  exchanged between the ITR, Map-Resolver, Map-Server, and ETR, unless
  the OTK is encrypted in another way, e.g. using a pre-shared secret.

Elsewhere in the spec this is a MUST, for example §6.5:

  2.  If the NULL-KEY-WRAP-128 algorithm (see Section 8.4) is selected
      and DTLS is not enabled, the Map-Request MUST be dropped and an
      appropriate log action SHOULD be taken.

Probably in §7.7 you should similarly say MUST, then?

13. There are many Specification Required registries that don't have guidance to designated experts, as requested by RFC 8126 §4.5 (which is referenced by RFC 8126 §4.6, which says Specification Required is just a fancy version of Expert Review). Likewise there's no field for change controller. Please consider adding these.

[Ballot discuss]
I generally found this a well-written and pleasant to read document. I do have some additional comments on it and tomorrow I'll update the comments section of my ballot to reflect them, but wanted to post the DISCUSS portion tonight.

I would like to understand the motivation behind what seems to me to be a curious inconsistency.

On the one hand, §6.7 and §6.7.1 mention that

  While processing the Map-Request, the Map-Server can overwrite the
  KDF ID field if it does not support the KDF ID recommended by the
  ITR.

and similar for the HMAC ID. They then go on to detail all the other work the Map-Server does to create a well-formed Map-Reply (if replying directly) or Map-Request (if sending the message to an ETR to take action). This seemed fine, until I got to §6.9, which told me that after the Map-Server (and often, ETR) went to all that work to create those messages...

                      If the KDF ID in the Map-Reply does not match the
  KDF ID requested in the Map-Request, the ITR MUST discard the Map-
  Reply

and similar for the HMAC ID.

Why did you tell the Map-Server to spend cycles and bandwidth doing the work to produce a fully-formed Map-Reply in this case where you know the ITR is just going to discard the result? Why doesn't the Map-Server simply send a bare-bones "I don't support your algorithm, here's the one I do like" message?

[Ballot discuss]
I generally found this a well-written and pleasant to read document. I do have some additional comments on it and tomorrow I'll update the comments section of my ballot to reflect them, but wanted to post the DISCUSS portion tonight.

I would like to understand the motivation behind what seems to me to be a curious inconsistency. I was surprised, when I reached §6.9, to find out that an ITR MUST discard a Map-Reply whose HMAC ID or KDF ID don't match what the ITR sent. As I understand it, this is used as a form of algorithm negotiation. That much I get (although it's surprising there's no text telling the ITR to remember the negotiated algorithm for future reference). What I don't get, is why §6.7 and §6.7.1 tell the Map-Server to go to the trouble of creating a full, properly-formed Map-Reply (quite possibly involving the ETR too in the process) in the case where it doesn't support the HMAC or KDF recommended by the ITR. In such a case the Map-Server *knows* the ITR will discard the Map-Reply. So why waste cycles and bandwidth sending anything other than a bare-bones, "I don't support your algorithm, here's the one I like" message?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-lisp-sec-26. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are five actions which we must complete.

In each of the five actions, a new registry is to be created on the Locator/ID Separation Protocol (LISP) Parameters registry page located at:

https://www.iana.org/assignments/lisp-parameters/

First, a new registry will be created called the ECM Authentication Data Type registry. Values will be from 0-255 inclusive. The new registry will be managed via Specification Required as defined in RFC8126. There are two initial values in the new registry; values 2-255 are unassigned.

Name: Reserved
Number: 0
Reference: [ RFC-to-be ]

Name: LISP-SEC-ECM-EXT
Number: 1
Reference: [ RFC-to-be ]

Second, a new registry will be created called the Map-Reply Authentication Data Type registry. Values will be from 0-255 inclusive. The new registry will be managed via Specification Required as defined in RFC8126. There are two initial values in the new registry; values 2-255 are unassigned.

Name: Reserved
Number: 0
Reference: [ RFC-to-be ]

Name: LISP-SEC-MR-EXT
Number: 1
Reference: [ RFC-to-be ]

Third, a new registry will be created called the LISP-SEC Authentication Data HMAC ID registry. Values will be from 0-65535 inclusive. The new registry will be managed via Specification Required as defined in RFC8126. There are three initial values in the new registry; values 3-65535 are unassigned.

Name: NONE
Number: 0
Reference: [ RFC-to-be ]

Name: AUTH-HMAC-SHA-1-96
Number: 1
Reference: [ RFC2104 ]

Name: AUTH-HMAC-SHA-256-128
Number: 2
Reference: [ RFC6234 ]

Fourth, a new registry will be created called the LISP-SEC Authentication Data Key Wrap ID registry. Values will be from 0-65535 inclusive. The new registry will be managed via Specification Required as defined in RFC8126. There are three initial values in the new registry; values 3-65535 are unassigned.

Name: Reserved
Number: 0
KEY WRAP: None
KDF: None

Name: NULL-KEY-WRAP-128
Number: 1
KEY WRAP: [ RFC-to-be ]
KDF: None

Name: AES-KEY-WRAP-128+HKDF-SHA256
Number: 2
KEY WRAP: [ RFC3394 ]
KDF: [ RFC4868 ]

--> IANA Question: Should the last two fields in this new registry be labeled "KEY WRAP Reference" and "KDF Reference?"

Fifth, a new registry will be created called the LISP-SEC Authentication Data Key Derivation Function ID registry. Values will be from 0-65535 inclusive. The new registry will be managed via Specification Required as defined in RFC8126. There are two initial values in the new registry; values 2-65535 are unassigned.

Name: NONE
Number: 0
Reference: [ RFC-to-be ]

Name: HKDF-SHA1-128
Number: 1
Reference: [ RFC5869 ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

Michelle Thangtamsatid
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-06-08):

From: The IESG
To: IETF-Announce
CC: Luigi Iannone , aretana.ietf@gmail.com, draft-ietf-lisp-sec@ietf.org, ggx@gigix.net, lisp-chairs@ietf.org, lisp@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (LISP-Security (LISP-SEC)) to Proposed Standard


The IESG has received a request from the Locator/ID Separation Protocol WG
(lisp) to consider the following document: - 'LISP-Security (LISP-SEC)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-06-08. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This memo specifies LISP-SEC, a set of security mechanisms that
  provides origin authentication, integrity and anti-replay protection
  to LISP's EID-to-RLOC mapping data conveyed via the mapping lookup
  process.  LISP-SEC also enables verification of authorization on EID-
  prefix claims in Map-Reply messages.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lisp-sec/



No IPR declarations have been submitted directly on this I-D.


The document contains this normative downward reference.
See RFC 3967 for additional information:
    rfc7835: Locator/ID Separation Protocol (LISP) Threat Analysis (Informational - Internet Engineering Task Force (IETF))

draft-ietf-lisp-sec-25.txt Document Write-up

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up.


(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

    This document is targeting publication as Proposed Standard.
    The document introduces security features, for the LISP main
      specification, which are mandatory to implement when LISP is
      deployed in an open environment like the Internet.
      Because the documents with the main LISP specification are
      published as Proposed Standard, this document of the same type.
      The RFC type is clearly marked in the title page header.



(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

      This document describes a security mechanism aiming at
      providing origin authentication, integrity and anti-replay protection
      to LISP map lookup process. In addition, it provides protection against
      prefix over-claiming attacks, ensuring that the sender of a
      Map-Reply providing the mapping for a certain EID-prefix is
      entitled to do so according to what is registered in the
      associated Map-Server. The whole mechanism is based on
      One-Time-Keys (OTK) used to compute Keyed-Hashing Message
      Authentication (HMAC). The mechanism is mandatory to implement in public
      deployments of LISP.


Working Group Summary:

      The document has been around since 2011, and has been discussed
      several times. From the beginning, there was strong support, because
      the WG felt that the having a mechanism to protect the map lookup
      process was really important in order to make possible have public
      deployments that cannot be easily attacked.
      The support of the document has been always present, while the
      document evolved. The discussion in the WG mainly focused
      on clearly identify what the proposed mechanism protect or which level
      of security it provides.
    The version of the document that was approved during WG Last
      Call is -12. The document went through the usual IETF process and was
      even scheduled to be discussed in the IESG telechat. However, at that
      time the document was "experimental". At the same time, there where the
      new LISP specification documents that were advancing as Proposed
      Standard. The security review of these new documents concluded that LISP
      public deployments, like in the Internet, MUST implement LISP-SEC.
      So the document was sent back in order to put it in the standard track
      and make sure that it is consistent with the new specifications. This
      work has been done and generated a few revisions due to the security
      review. Early this year (2021), publication has been requested for the
      main LISP specifications and this document will complete the set of
      specifications.

Document Quality:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

    There is a strong interest in LISP-SEC especially by potential
      LISP adopters because protecting the map lookup process is key to
      have a robust system where mapping information cannot be tempered.
      Even further, LISP-SEC is mandatory to implement in public LISP
      deployments.

Personnel:

Who is the Document Shepherd?

      Luigi Iannone


Who is the Responsible Area Director?

      Alvaro Retana



(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.


      I reviewed carefully revision -23 of the document. I had few editorial issues that have been fixed in the follow-up revisions by the authors. The text is sufficiently clear and understandable.
        Back when LISP-SEC past WG Last Call, I have checked the mailinglist and meeting minutes and publication WG consensus has been reached appropriately. During the revision work up to the latest version fo the document the WG has been updated regularly on the advances. No discontent or objection to the modification has been ever shown.
      I checked the ID nits (output provided  on point 11)
      and everything is clear with the exception of a warning due to
        the notation used in the document which the idnits tools mistakenly considers being a citation.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

        As the document shepherd I have no concerns.



(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

        I do not think that a additional specific review is needed (other than
        the usual ones).



(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

      I have no specific concerns or issues to point out.



(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?

        All authors have made conforming IPR disclosure.



(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

      No IPR disclosures have been filed.



(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

        There has been clear strong consensus behind this document,
      showing that the WG as a whole understands and agree with it.



(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

      Nobody did show discontent nor threatened an appeal.



(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

idnits 2.17.00 (12 Aug 2021)

/tmp/idnits14237/draft-ietf-lisp-sec-25.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- The document date (8 December 2021) is 6 days in the past.  Is this
    intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  == Missing Reference: 'Key ID' is mentioned on line 620, but not defined


    Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--).

    Run idnits with the --verbose option for more detailed information about
    the items above.
--------------------------------------------------------------------------------




(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

      No formal review is required.



(13) Have all references within this document been identified as
either normative or informative?

        Only normative references are present. They are clearly
        identified as such.



(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

      There are no normative references in unclear state.



(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

      There are no downward normative references.



(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

      No existing RFC's status will change due to the publication
      of this document.



(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226).

      This document instruct IANA to create five different registries,
        namely:
        - ECM AD Type Registry, with values ranging from 0 to 255.
        - Map-Reply AD Type Registry, with values ranging from 0 to 255.
        - HMAC Functions, with values ranging from 0 to 65535.
        - Key Wrap Functions, with values ranging from 0 to 65535.
        - Key Derivation Functions, with values ranging from 0 to 65535.
        Initial content for all of the above registries is well identified and
        future allocations is requested to be assigned according to the
        "Specification Required" policy defined in RFC5226.



(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

      No expert review is required.



(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

      The document does not contain anything written in a formal
      language, hence, no validation and/or check has been
      performed.

draft-ietf-lisp-sec-25.txt Document Write-up

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up.


(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

    This document is targeting publication as Proposed Standard.
    The document introduces security features, for the LISP main
      specification, which are mandatory to implement when LISP is
      deployed in an open environment like the Internet.
      Because the documents with the main LISP specification are
      published as Proposed Standard, this document of the same type.
      The RFC type is clearly marked in the title page header.



(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

      This document describes a security mechanism aiming at
      providing origin authentication, integrity and anti-replay protection
      to LISP map lookup process. In addition, it provides protection against
      prefix over-claiming attacks, ensuring that the sender of a
      Map-Reply providing the mapping for a certain EID-prefix is
      entitled to do so according to what is registered in the
      associated Map-Server. The whole mechanism is based on
      One-Time-Keys (OTK) used to compute Keyed-Hashing Message
      Authentication (HMAC). The mechanism is mandatory to implement in public
      deployments of LISP.


Working Group Summary:

      The document has been around since 2011, and has been discussed
      several times. From the beginning, there was strong support, because
      the WG felt that the having a mechanism to protect the map lookup
      process was really important in order to make possible have public
      deployments that cannot be easily attacked.
      The support of the document has been always present, while the
      document evolved. The discussion in the WG mainly focused
      on clearly identify what the proposed mechanism protect or which level
      of security it provides.
    The version of the document that was approved during WG Last
      Call is -12. The document went through the usual IETF process and was
      even scheduled to be discussed in the IESG telechat. However, at that
      time the document was "experimental". At the same time, there where the
      new LISP specification documents that were advancing as Proposed
      Standard. The security review of these new documents concluded that LISP
      public deployments, like in the Internet, MUST implement LISP-SEC.
      So the document was sent back in order to put it in the standard track
      and make sure that it is consistent with the new specifications. This
      work has been done and generated a few revisions due to the security
      review. Early this year (2021), publication has been requested for the
      main LISP specifications and this document will complete the set of
      specifications.

Document Quality:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

    There is a strong interest in LISP-SEC especially by potential
      LISP adopters because protecting the map lookup process is key to
      have a robust system where mapping information cannot be tempered.
      Even further, LISP-SEC is mandatory to implement in public LISP
      deployments.

Personnel:

Who is the Document Shepherd?

      Luigi Iannone


Who is the Responsible Area Director?

      Alvaro Retana



(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.


      I reviewed carefully revision -23 of the document. I had few editorial issues that have been fixed in the follow-up revisions by the authors. The text is sufficiently clear and understandable.
        Back when LISP-SEC past WG Last Call, I have checked the mailinglist and meeting minutes and publication WG consensus has been reached appropriately. During the revision work up to the latest version fo the document the WG has been updated regularly on the advances. No discontent or objection to the modification has been ever shown.
      I checked the ID nits (output provided  on point 11)
      and everything is clear with the exception of a warning due to
        the notation used in the document which the idnits tools mistakenly considers being a citation.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

        As the document shepherd I have no concerns.



(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

        I do not think that a additional specific review is needed (other than
        the usual ones).



(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

      I have no specific concerns or issues to point out.



(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?

        All authors have made conforming IPR disclosure.



(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

      No IPR disclosures have been filed.



(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

        There has been clear strong consensus behind this document,
      showing that the WG as a whole understands and agree with it.



(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

      Nobody did show discontent nor threatened an appeal.



(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

idnits 2.17.00 (12 Aug 2021)

/tmp/idnits14237/draft-ietf-lisp-sec-25.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- The document date (8 December 2021) is 6 days in the past.  Is this
    intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  == Missing Reference: 'Key ID' is mentioned on line 620, but not defined


    Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--).

    Run idnits with the --verbose option for more detailed information about
    the items above.
--------------------------------------------------------------------------------




(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

      No formal review is required.



(13) Have all references within this document been identified as
either normative or informative?

        Only normative references are present. They are clearly
        identified as such.



(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

      There are no normative references in unclear state.



(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

      There are no downward normative references.



(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

      No existing RFC's status will change due to the publication
      of this document.



(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226).

      This document instruct IANA to create five different registries,
        namely:
        - ECM AD Type Registry, with values ranging from 0 to 255.
        - Map-Reply AD Type Registry, with values ranging from 0 to 255.
        - HMAC Functions, with values ranging from 0 to 65535.
        - Key Wrap Functions, with values ranging from 0 to 65535.
        - Key Derivation Functions, with values ranging from 0 to 65535.
        Initial content for all of the above registries is well identified and
        future allocations is requested to be assigned according to the
        "Specification Required" policy defined in RFC5226.



(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

      No expert review is required.



(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

      The document does not contain anything written in a formal
      language, hence, no validation and/or check has been
      performed.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-lisp-sec-13. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Services Operator understands that, upon approval of this document, there are five actions which we must complete.

IANA Question --> Section 7 of the current document requests the creation of five new registries. Where should these new registries be located? Should they be added to an existing registry page? If not, do they belong in an existing category at http://www.iana.org/protocols?

First, a new registry is to be created called the ECM Authentication Data Type registry. The registry will be located based on an answer to the IANA Question above. The registry will be managed via Specification Required as defined in RFC 8126. The registry is made up of values from 0-255. There are initial registrations in the new registry as follows:

Name Value Reference
----------------+-------------------+----------------
Reserved 0 [ RFC-to-be ]
LISP-SEC-ECM-EXT 1 [ RFC-to-be ]
Unassigned 2-255

Second, a new registry is to be created called the Map-Reply Authentication Data Type registry. The registry will be located based on an answer to the IANA Question above. The registry will be managed via Specification Required as defined in RFC 8126. The registry is made up of values from 0-255. There are initial registrations in the new registry as follows:

Name Value Reference
----------------+-------------------+----------------
Reserved 0 [ RFC-to-be ]
LISP-SEC-MR-EXT 1 [ RFC-to-be ]
Unassigned 2-255

Third, a new registry is to be created called the LISP-SEC Authentication Data HMAC ID registry. The registry will be located based on an answer to the IANA Question above. The registry will be managed via Specification Required as defined in RFC 8126. The registry is made up of values from 0-65535. There are initial registrations in the new registry as follows:

Name Number Reference
-----------------------------------------------------
NONE 0 [ RFC-to-be ]
AUTH-HMAC-SHA-1-96 1 [RFC2104]
AUTH-HMAC-SHA-256-128 2 [RFC6234]
Unassigned 3-65535

Fourth, a new registry is to be created called the LISP-SEC Authentication Data Key Wrap ID registry. The registry will be located based on an answer to the IANA Question above. The registry will be managed via Specification Required as defined in RFC 8126. The registry is made up of values from 0-65535. There are initial registrations in the new registry as follows:

Name Number Reference
-----------------------------------------------------
Reserved 0 [ RFC-to-be ]
NULL-KEY-WRAP-128 1 [ RFC-to-be ]
AES-KEY-WRAP-128 2 [RFC3394]
Unassigned 3-65535

Fifth, a new registry is to be created called the LISP-SEC Authentication Data Key Derivation Function ID registry. The registry will be located based on an answer to the IANA Question above. The registry will be managed via Specification Required as defined in RFC 8126. The registry is made up of values from 0-65535. There are initial registrations in the new registry as follows:

Name Number Reference
-----------------------------------------------------
NONE 0 [ RFC-to-be ]
HKDF-SHA1-128 1 [RFC5869]
Unassigned 2-65535

The IANA Services Operator understands that these five actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.


Thank you,

Sabrina Tanamal
IANA Services Specialist

The following Last Call announcement was sent out (ends 2017-10-04):

From: The IESG
To: IETF-Announce
CC: draft-ietf-lisp-sec@ietf.org, lisp@ietf.org, db3546@att.com, lisp-chairs@ietf.org, Luigi Iannone , ggx@gigix.net
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (LISP-Security (LISP-SEC)) to Experimental RFC


The IESG has received a request from the Locator/ID Separation Protocol WG
(lisp) to consider the following document: - 'LISP-Security (LISP-SEC)'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-10-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This memo specifies LISP-SEC, a set of security mechanisms that
  provides origin authentication, integrity and anti-replay protection
  to LISP's EID-to-RLOC mapping data conveyed via mapping lookup
  process.  LISP-SEC also enables verification of authorization on EID-
  prefix claims in Map-Reply messages.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lisp-sec/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-lisp-sec/ballot/


No IPR declarations have been submitted directly on this I-D.

draft-ietf-lisp-sec-12.txt Document Write-up

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up.


(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

    This document is targeting publication as an Experimental RFC.
    It is the proper type of RFC since it introduces a
      security mechanism to provide origin authentication,
      integrity and anti-replay protection in the LISP (Locator/ID Separation
      Protocol (LISP) mapping lookup process, whose RFCs have already
      Experimental status.
    The RFC type is clearly marked in the title page header.



(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

      This document describes a security mechanism aiming at
      providing origin authentication, integrity and anti-replay protection
      to LISP map lookup process. In addition, it provides protection against
      prefix over-claiming attacks, ensuring that the sender of a
      Map-Reply providing the mapping for a certain EID-prefix is
      entitled to do so according to what is registered in the
      associated Map-Server. The whole mechanism is based on
      One-Time-Keys (OTK) used to compute Keyed-Hashing Message
      Authentication (HMAC).


Working Group Summary:

      The document has been around since 2011, and has been discussed
      several times. From the beginning, there was strong support, because
      the WG felt that the having a mechanism to protect the map lookup
      process was really important in order to make possible have public
      deployments that cannot be easily attacked.
      The support of the document has been always present, while the
      document evolved. The discussion in the WG mainly focused
      on clearly identify what the proposed mechanism protect or which level
      of security it provides.
    The version of the document that was approved during WG Last
      Call is -12.

Document Quality:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

    There is a strong interest in LISP-Sec, especially by potential
      LISP adopters because protecting the map lookup process is key to
      have a robust system where mapping information cannot be tempered.


Personnel:

Who is the Document Shepherd?

      Luigi Iannone


Who is the Responsible Area Director?

      Deborah Brungard .



(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.


      I reviewed carefully the document. The text is sufficiently
        clear and understandable.
        I have checked the mailinglist and meeting minutes and
        publication WG consensus has been reached appropriately.
      I checked the ID nits (output provided  on point 11)
      and everything is clear with the exception of a warning due to
        the fact that the publication date of -12 document is in 2016.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

        As the document shepherd I have no concerns.



(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

        I do not think that a additional specific review is needed.



(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

      I have no specific concerns or issues to point out.



(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?

        All authors have made conforming IPR disclosure.



(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

      No IPR disclosures have been filed.



(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

        There has been clear strong consensus behind this document,
      showing that the WG as a whole understands and agree with it.



(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

      Nobody did show discontent nor threatened an appeal.



(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.
idnits 2.14.01  /var/www/.idnits

tmp/draft-ietf-lisp-sec-12.txt:
  Attempted to download rfc0102 state...
  Failure fetching the file, proceeding without it.
  Attempted to download rfc0103 state...
  Failure fetching the file, proceeding without it.
  Attempted to download rfc0200 state...
  Failure fetching the file, proceeding without it.
  Attempted to download rfc0203 state...
  Failure fetching the file, proceeding without it.

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
    match the current year

  -- The document date (November 16, 2016) is 127 days in the past.  Is this
    intentional?


  Checking references for intended status: Experimental
  ----------------------------------------------------------------------------

    No issues found here.

    Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--).



(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

      No formal review is required.



(13) Have all references within this document been identified as
either normative or informative?

        Only normative references are present. They are clearly
        identified as such.



(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

      There are no normative references in unclear state.



(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

      There are no downward normative references.



(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

      No existing RFC's status will change due to the publication
      of this document.



(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226).

      This document instruct IANA to create five different registries,
        namely:
        - ECM AD Type Registry, with values ranging from 0 to 255.
        - Map-Reply AD Type Registry, with values ranging from 0 to 255.
        - HMAC Functions, with values ranging from 0 to 65535.
        - Key Wrap Functions, with values ranging from 0 to 65535.
        - Key Derivation Functions, with values ranging from 0 to 65535.
        Initial content for all of the above registries is well identified and
        future allocations is requested to be assigned according to the
        "Specification Required" policy defined in RFC5226.



(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

      No expert review is required.



(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

      The document does not contain anything written in a formal
      language, hence, no validation and/or check has been
      performed.