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

[Luigi Iannone <[e-mail]>]

Hi John,

AFAICT the reason is very simple, LISP-SEC has been designed to secure existing LISP control plane messages, not to add new messages.
So it is able to protect the Map-Request and Map-Reply messages flowing around but it never generates any LISP-SEC specific message.
The action you are suggesting at the end of your discuss needs a new message, which is not inline with the design decision taken for this draft.
Yes, it is a non optimal solution from a resource perspective, but has the advantage to be very neat considering that you are just protecting the LISP control plane, not modifying it. 

Ciao

L.


> On 15 Jun 2022, at 04:17, John Scudder via Datatracker <[e-mail]> wrote:
> 
> John Scudder has entered the following ballot position for
> draft-ietf-lisp-sec-26: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lisp-sec/
> 
> 
> 
> ----------------------------------------------------------------------
> 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?
> 
> 
> 
> 
>