Re: [lisp] John Scudder's Discuss on draft-ietf-lisp-sec-26: (with DISCUSS)

[John Scudder <[e-mail]>]

Hi Luigi,

I’m going to update my ballot and clear the DISCUSS, thanks for the conversation. You can reply to the below comments if you like, but I don’t insist, I take the point that the WG has taken an informed decision to build a solution with suboptimal performance for compatibility reasons. You didn’t say this, but possibly the WG is assuming configuration will almost always prevent these cases from happening because deployments will be homogenous (or at least under a common, and competent, administration).

> On Jun 15, 2022, at 11:01 AM, Luigi Iannone <[e-mail]> wrote:
...
> Yes, but …
> 
> There are two scenarios to consider:
> 1. The Map-Server is acting as proxy for the requested mapping.
> 2. The Map-Server does not act as proxy for the requested server.
> 
> Case 1.
> 
> If the Map-Server is acting as proxy, then it is entitled to reply with a Map-Reply on behalf of the ETRs registering the mapping. In this case it could (as you suggests) send back a Map-Reply proposing a different KDF ID, this is already in the specs.
> The next question IMO is what do you put in the reply itself? According to specifications if the mapping exists you send it back. In LISP there is no message “please ask again”. This is the part that generates overhead.

Again, since the ITR is going to throw the message away anyway, the answer could be “who cares what you put in there”. I mean, presumably you’d put in whatever the minimal set of bytes is to make the reply not be considered malformed in some other way, but beyond that, it doesn’t matter.

> Case 2.
> 
> This is similar, just that now is the ETR that is replying. Same question as in previous case, what to put in the reply? Beside, the ETR is not aware that the Map-Server changed the KDF-ID, because there is no trace in the packet.

Is there something in the protocol (other than perhaps some MUSTs in a spec document, that could be updated by a new spec document, such as the current one) that would prevent the Map-Server from proxying back the reply (your Case 1) even in the case where it hasn’t been properly designated as a proxy? The logic would go something like:

If the Map-Server is changing the KDF ID, proxy back a bare-bones message as in Case 1,
Else
	If the Map-Server is a proxy, do the proxy thing,
	Else forward to ETR

Assuming the protocol doesn’t have some feature that prevents this, the rationale behind the Map-Server doing this is pretty easy: it knows a priori that the work the ETR is going to do will all be wasted and the only field that the ITR will act on is the one the Map-Server is inserting.

> Your suggestion is basically to send back something else. The LISP-SEC-ECM is a wrapper, it has to encapsulate a LISP Control Message, so you in order to work you need to define a new message or just put the Map-Reply.

As discussed above my speculation is that you could shove in a minimal (probably predefined) string of bytes as the so-called “LISP Control Message”, since you know a priori those bytes will never be used or even inspected (at least, that’s what “MUST discard” means to me).

> The current draft uses the second option.
> 
> I am not arguing which solution is better, I am just trying to clarify the design choice that has been made by the authors and the WG.
> (As an input for your telecast tomorrow)

I appreciate your taking the time.

—John