[IPsec] Question: Inconsistent statements about what the node shall do when receving ESP packets with unknown SPI.

[Pål Dammvik]

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.
In section 1.5 it’s stated:

“In the first case, if the receiving node has an active IKE SA to the IP 
address from whence the packet came, it MAY send an INVALID_SPI notification of 
the wayward packet over that IKE SA in an INFORMATIONAL exchange.”

The works “In the first case” refers to a case where the node received an ESP 
packet with unknown SPI.

Thus in this case it’s a MAY statement to initiate the INFORMATIONAL exchange.

In section 2.21.4 it’s stated:

“If an error occurs outside the context of an IKE request (e.g., the node is 
getting ESP messages on a nonexistent SPI), the node SHOULD initiate an 
INFORMATIONAL exchange with a Notify payload describing the problem.”

So in this case it’s a SHOULD statement to initiate the INFORMATIONAL exchange.

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).

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




___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Milestones changed for ipsecme WG

[IETF Secretariat]

Changed milestone "IETF Last Call on Split-DNS Configuration for IKEv2", set
due date to April 2018 from February 2017.

Changed milestone "IETF Last Call on Implicit IV in IPsec", set due date to
April 2018 from February 2017.

Changed milestone "IETF Last Call on partially quantum resistant IKEv2", set
due date to May 2018 from June 2017, added draft-ietf-ipsecme-qr-ikev2 to
milestone.

URL: https://datatracker.ietf.org/wg/ipsecme/about/

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Question: Inconsistent statements about what the node shall do when receving ESP packets with unknown SPI.

[Tero Kivinen]

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. 
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec