Subject: [lisp] Map-Regiister Key-ID field

From: Dino Farinacci <[email-masked]>
Date: Wed, 26 Apr 2017 11:03:05 -0700

In draft-ietf-lisp-rfc6833bis-03.txt, the Map-Register has a field called “Key ID”:

The description for the Key ID in the spec is a bit vague and a comment was made about its vagueness:

The Key ID codepoints are based on a registry and documented in draft-ietf-lisp-rfc6830:

I believe the original intent of the Key-ID field was to ease an seamless transition from one key to another. But the draft only specs an algorithm-ID in this field.

I would like to propose the following:

(1) Break up the 16-bit field into 2 8-bit fields:

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Key ID    |     Alg ID    |  Authentication Data Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(2) Change section 21.4 to “LISP Algorithm ID Numbers”.

(3) Document in draft-ietf-lisp-rfc6833bis how the Key ID is used and change the description above for Key ID to Alg ID.

The use-case is the following:

When a Mapping Service Provider (MSP) decides it needs to rekey the security association between xTRs that register for a particular site, it does so by adding a new key while also using the old key in lieu of xTRs being updated with the new key.

Here is an example:

MS1 map-server state: LISP site “site1": key-id: 0, password “site1-pw”
ETR1 xTR state: map-server: MS1, key-id: 0, password “site1-pw”
ETR2 xTR state: map-server: MS1, key-id: 0, password “site1-pw”

At this point ETR1 and ETR2 register with key-id 0 using password "site1-pw". Then the map-server wants to rekey for “site1”, so its new state is:

MS1 map-server state: LISP site “site1": key-id: 0, password “site1-pw”
                      LISP site “site1": key-id: 1, password “site1-site1-pw”

While the state of ETR1 and ETR2 does not change but registrations are accepted by MS1. Then, let’s say ETR2 is changed to:

ETR2 xTR state: map-server: MS1, key-id: 1, password “site1-site1-pw”

At this point both registrations from ETR1 and ETR2 are accepted. Once all all xTRs have key-id 0 removed, the map-server can remove key-id 0 from its acceptance list and only accepts registrations for key-id 1.

If there are no objections, I can send a draft change for this issue. Comments welcome.

Thanks,
Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 27 Apr 2017 04:37:33 -0400

This looks workable.

I think the wording needs adjustment.  As written, it assumes a certain 
relationship in how the keys for the security association between the 
ETR and the Map Server are define (the Mapping System Provider decides 
to change the keys.)  In practice, key change may be driven by either 
party, and the key collaboration is outside of our scope.  When they 
have decided to migrate to supporting new keys, the key-id usage, as 
described, allows for a smooth transition.

Yours,
Joel

On 4/26/17 2:03 PM, Dino Farinacci wrote:
> I believe the original intent of the Key-ID field was to ease an
> seamless transition from one key to another. But the draft only specs an
> algorithm-ID in this field.
>
> (3) Document in draft-ietf-lisp-rfc6833bis how the Key ID is used and
> change the description above for Key ID to Alg ID.
>
> When a Mapping Service Provider (MSP) decides it needs to rekey the
> security association between xTRs that register for a particular site,
> it does so by adding a new key while also using the old key in lieu of
> xTRs being updated with the new key.
>
> Here is an example:
>
> At this point ETR1 and ETR2 register with key-id 0 using password
> "site1-pw". Then the map-server wants to rekey for “site1”, so its new
> state is:
>
> While the state of ETR1 and ETR2 does not change but registrations are
> accepted by MS1. Then, let’s say ETR2 is changed to:
>
> At this point both registrations from ETR1 and ETR2 are accepted. Once
> all all xTRs have key-id 0 removed, the map-server can remove key-id 0
> from its acceptance list and only accepts registrations for key-id 1.
>
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 27 Apr 2017 10:43:59 -0700

Thanks for the quick reply.

> I think the wording needs adjustment.  As written, it assumes a certain relationship in how the keys for

Yes, that was the impetutus for the proposed change.

>  the security association between the ETR and the Map Server are define (the Mapping System Provider 

That is correct.

> decides to change the keys.)  In practice, key change may be driven by either party, and the key collaboration is outside of our scope.  When they have decided to migrate to supporting new keys, the key-id usage, as described, allows for a smooth transition.

Right. I think that a provider will tend to control the key change than the subscriber. Because the subscriber is being given access to a service. But yes, in theory, either side could change where maybe the map-server is using two key-ids because one xTR wanted to change their key and other xTRs did not. For whatever reason.

I’ll draft up text and send to the list.

Dino