Subject: [lisp] Please Review 6830bis and 6833bis

From: Luigi Iannone <[email-masked]>
Date: Sat, 11 Mar 2017 10:27:13 +0100

Hi All,

this is just a reminder about the high priority items in our charter:

"the first (and high priority) work item of the LISP Working
Group is to develop a standard-track solution based on the completed
Experimental RFCs and the experience gained from early deployments.”

This means that we need to make progress on the two documents 6830bis and 6833bis.
Albert and Dino did  an excellent job in writing these two document and are now waiting for our feedback.

Please review the document and send feedback to the mailing list or come to the mic in the next meeting (which is just 2 weeks away).

Ciao

Luigi & Joel

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 12 Mar 2017 05:32:34 -0700

> Please review the document and send feedback to the mailing list or come to the mic in the next meeting (which is just 2 weeks away).

Since we have the opportunity to make minor changes, I would like to ask the working group about Map-Reply Action Values. Currently the spec says this:

 ACT:  This 3-bit field describes Negative Map-Reply actions.  In any
      other message type, these bits are set to 0 and ignored on
      receipt.  These bits are used only when the 'Locator Count' field
      is set to 0.  The action bits are encoded only in Map-Reply
      messages.  The actions defined are used by an ITR or PITR when a
      destination EID matches a negative Map-Cache entry.  Unassigned
      values should cause a Map-Cache entry to be created, and when
      packets match this negative cache entry, they will be dropped.
      The current assigned values are:

      (0) No-Action:  The map-cache is kept alive, and no packet
          encapsulation occurs.

      (1) Natively-Forward:  The packet is not encapsulated or dropped
          but natively forwarded.

      (2) Send-Map-Request:  The packet invokes sending a Map-Request.

      (3) Drop:  A packet that matches this map-cache entry is dropped.
          An ICMP Destination Unreachable message SHOULD be sent.

I would like to propose we add these:

      (4) Policy-Denied: The Map-Request for the target-id is being policy 
          denied and the Map-Reply with this action value contains an empty 
          RLOC-set.

      (5) Authentication-Failure: The Map-Request for the target-id fails an 
          authentication check so the Map-Reply contains an empty RLOC-set.

Please let me know what you think.

Thanks,
Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 12 Mar 2017 14:16:34 -0400

<participant
Given taht the only error code field we have in the map reply is the ACT 
field, I see why you want values for ACT to represent these meanings.
As a minor point, the two new replies need to specify what the action 
should be for each of them.
The bigger problem is that it is not clear that "policy-denied" always 
goes with one of the existing 4 actions.  (I have trouble constructing a 
policy-denied:Send-Map_Request, but I can see cases for the other three.)

In contrast, since in the authentication failure case the responding ETR 
has no idea who the ITR is, "No-Action" seems the right behavior.

Yours,
Joel
</participant>

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 12 Mar 2017 18:19:25 -0700

> <participant
> Given taht the only error code field we have in the map reply is the ACT field, I see why you want values for ACT to represent these meanings.

Right. It can be used to give additional information about the mapping database lookup.

> As a minor point, the two new replies need to specify what the action should be for each of them.

Sure, I can right that text. It is obvious but does need to be spec’ed. It means that the ITR/PITR will drop packets since there is no RLOC-set. And follow the typical map-cache maintenance procedures for refreshing entries.

> The bigger problem is that it is not clear that "policy-denied" always goes with one of the existing 4 actions. 

The “Action” field is a bit of instruction that the mapping database lookup system provides.

>  (I have trouble constructing a policy-denied:Send-Map_Request, but I can see cases for the other three.)

Here is an example:

(1) Dino (an xTR) registers an EID.
(2) The registration policy indicates that Joel (an xTR) can only talk to me on weekends.
(3) On Monday an EID behind you requests to talk to an EID behind me. The mapping systems returns to Joel the RLOC-set “Dino” and you can encap to me.
(4) If that EID is sending the the EID behind me tonight, the mapping system returns an empty RLOC-set with Action “policy-denied”.
(5) You can cache this fact in your map-cache and obviously have no where to encap to since an RLOC-set was not returned.

So, in a nutshell, this is a {source, destination} based access-list that is enforced in the mapping system versus implemented in the data-plane in the encapsulator.

> In contrast, since in the authentication failure case the responding ETR has no idea who the ITR is, "No-Action" seems the right behavior.

“No-Action” is a default action type when there is no other error reason to return. Hence the desire to return more specific reasons for lookup failure or instructions the ITR should do on lookup success.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 12 Mar 2017 21:30:12 -0400

Dino, I am missing something.
If, as we both seem to be saying, the "policy-denied" response can go 
with any of the existing actions, how is the receiver to know which is 
intended by the responder?

Yours,
Joel

On 3/12/17 9:19 PM, Dino Farinacci wrote:
>> <participant Given taht the only error code field we have in the
>> map reply is the ACT field, I see why you want values for ACT to
>> represent these meanings.
>
> Sure, I can right that text. It is obvious but does need to be
> spec’ed. It means that the ITR/PITR will drop packets since there is
> no RLOC-set. And follow the typical map-cache maintenance procedures
> for refreshing entries.
>
>> The bigger problem is that it is not clear that "policy-denied"
>> always goes with one of the existing 4 actions.
>
> (1) Dino (an xTR) registers an EID. (2) The registration policy
> indicates that Joel (an xTR) can only talk to me on weekends. (3) On
> Monday an EID behind you requests to talk to an EID behind me. The
> mapping systems returns to Joel the RLOC-set “Dino” and you can encap
> to me. (4) If that EID is sending the the EID behind me tonight, the
> mapping system returns an empty RLOC-set with Action
> “policy-denied”. (5) You can cache this fact in your map-cache and
> obviously have no where to encap to since an RLOC-set was not
> returned.
>
> So, in a nutshell, this is a {source, destination} based access-list
> that is enforced in the mapping system versus implemented in the
> data-plane in the encapsulator.
>
>> In contrast, since in the authentication failure case the
>> responding ETR has no idea who the ITR is, "No-Action" seems the
>> right behavior.
>
> “No-Action” is a default action type when there is no other error
> reason to return. Hence the desire to return more specific reasons
> for lookup failure or instructions the ITR should do on lookup
> success.
>
> Dino
>
>
>

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 12 Mar 2017 18:45:45 -0700

> If, as we both seem to be saying, the "policy-denied" response can go with any of the existing actions, how is the receiver to know which is intended by the responder?

I don’t think it does. Let’s look at each existing action:

>   (0) No-Action

This action code comes with a RLOC-set and tells an ITR to encapsulate to RLOCs in the RLOC-set. This is certainly not denying anything.

>   (1) Natively-Forward

This is an action code that tells the ITR that the EID it requested is not in the mapping system and could be a non-EID and the address is routable in the underlay. This is certainly not denying anything.

>   (2) Send-Map-Request

This action code could be returned when overlapping EID-prefixes are registered to the mapping system. This is an instruction from the Map-Replier (either from an ETR or a map-server) that a longest match lookup that matches this entry should invoke a Map-Request.

>   (3) Drop

This action code is telling the ITR to drop packets, but has no specific reason for doing so.

The two new action codes I am proposing (and if others think there could be more, please suggest them):

(4) Policy-Denied

An access-list violation is denied and the requestor must not get the RLOC-set due to the policy configured in the ETR or Map-Server.

(5) Authentication-Failure

Whatever authentication mechanism that is being used, the verifier has decided the Map-Requester cannot get access to the registered database-mapping.

I believe, based on how I describe it above, they are all discrete.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 12 Mar 2017 21:59:40 -0400

<just to be clear, still hatless, jsut trying to understand as a
participant>

It looks to me like Policy_Denied and Authentication-Failure are error 
codes, not dispositions.  They presumably go with the "Drop" action (as 
is the defined behavior for any ACT which is not understood.

Given that the action is the same as Drop, it seems safe, but odd, to 
use different action codes.  Is there a difference in the action at the 
receiver?

If there is no difference, would it not make sense to encode this 
information in some other field?  It seems to be for diagnositirc 
purposes, not action.

Yours,
Joel

On 3/12/17 9:45 PM, Dino Farinacci wrote:
>> Dino, I am missing something. If, as we both seem to be saying, the
>> "policy-denied" response can go with any of the existing actions,
>> how is the receiver to know which is intended by the responder?
>
> This action code comes with a RLOC-set and tells an ITR to
> encapsulate to RLOCs in the RLOC-set. This is certainly not denying
> anything.
>
>> (1) Natively-Forward
>
> This is an action code that tells the ITR that the EID it requested
> is not in the mapping system and could be a non-EID and the address
> is routable in the underlay. This is certainly not denying anything.
>
>> (2) Send-Map-Request
>
> This action code could be returned when overlapping EID-prefixes are
> registered to the mapping system. This is an instruction from the
> Map-Replier (either from an ETR or a map-server) that a longest match
> lookup that matches this entry should invoke a Map-Request.
>
>> (3) Drop
>
> An access-list violation is denied and the requestor must not get the
> RLOC-set due to the policy configured in the ETR or Map-Server.
>
> Whatever authentication mechanism that is being used, the verifier
> has decided the Map-Requester cannot get access to the registered
> database-mapping.
>

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 12 Mar 2017 19:01:32 -0700

> It looks to me like Policy_Denied and Authentication-Failure are error codes, not dispositions.  They presumably go with the "Drop" action (as is the defined behavior for any ACT which is not understood.

Sure, we could name each of them:

Drop - no reason
Drop - policy-denied
Drop - authentication-failure

Would that be better?

> Given that the action is the same as Drop, it seems safe, but odd, to use different action codes.  Is there a difference in the action at the receiver?

No, not really.

> If there is no difference, would it not make sense to encode this information in some other field?  It seems to be for diagnositirc purposes, not action.

What about above?

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 13 Mar 2017 11:16:13 -0700

Joel had some comments. We agreed (he as a participant) to the following text:

———

   (3) Drop/No-Reason:  A packet that matches this map-cache entry is dropped.
       An ICMP Destination Unreachable message SHOULD be sent.

   (4) Drop/Policy-Denied: A packet that matches this map-cache entry is dropped.
       The reason for the Drop action is that a Map-Request for the target-EID is
       being policy denied by either an xTR or the mapping system.

   (5) Drop/Authentication-Failure: A packet that matches this map-cache entry is dropped.
       The reason for the Drop action is that a Map-Request for the target-EID fails
       an authentication verification-check by either an xTR or the mapping system.

———

Note the changes where “Drop” -> “Drop/No-Reason” and the addition of (4) and (5).

Thanks,
Dino

> On Mar 12, 2017, at 5:32 AM, Dino Farinacci <[email-masked]> wrote:
>