Pål Dammvik writes:
> Think I have discovered a small inconsistency in RFC 7296 with
> regards to the actions a node shall take if it received ESP packets
> with an unknown SPI.

Those cases are not exactly same. I.e., the section 1.5 explictly
talks about receiving ESP packet with unknown SPI. The section 2.21.4
talks about errors outside the context of an IKE request, and gives
one example of such case, which happens to be the ESP messages on
nonexisting SPI.

On the hand, I am not sure if there are any other errors outside of
IKE request than invalid SPIs...

> To me these statement are a bit confusing, is it a SHOULD or MAY to initiate
> an INFORMATIONAL exchange when receiving ESP packets with unknown SPI?
> (assuming an IKE SA is established).

Note, that SHOULD includes MAY. I.e., if some text says you SHOULD do
something, and other text say you MAY do that, they are not
conflicting, the MAY is included as part of SHOULD.

So when you implement the SHOULD you also happen to implement the MAY
too... 

> In my humble opinion section 2.21.4 should be updated to say MAY but I might
> have missed something 

We did discussed about this in 2008-2010 before publishing RFC5996.
The section 2.21 got written at that point, as we wanted to expand the
text covering the error cases.

Then I did point out before publication that the text is bit confusing
and that sections 1.5 and 2.21.4 should be combined, as we same rules
in two different places. The editor responded that he didn't want to
do that big change in that late phases [2].

[1] https://trac.ietf.org/trac/ipsecme/ticket/26
[2] https://www.ietf.org/mail-archive/web/ipsec/current/msg05669.html

When we were making RFC7296 we could have combined those two sections
but never got to do that even then.

Anyways I think SHOULD is good there, as those messages are rate
limited, and sending information to the other end that you are sending
me stuff, I do not know anything about is good thing, as then it can
do some actions to fix things. 
-- 
[email protected]

_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to