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 <[email protected]> > 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? > > > > > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
