[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Unsupported DOI attributes and values
In the discussion of IPsec-ECN interactions in Oslo,
a concern was raised about how to deal with implementations
that don't support negotiating the new SA attribute.
The suggestion was made that any proposal that includes
the new attribute be accompanied by one that does not,
so that an implementation that does not support the
new attribute can select a proposal that does not
contain it.
OTOH, the DOI (RFC 2407) says:
4.5.3 Attribute Negotiation
If an implementation receives a defined IPSEC DOI attribute (or
attribute value) which it does not support, an ATTRIBUTES-NOT-SUPPORT
SHOULD be sent and the security association setup MUST be aborted,
unless the attribute value is in the reserved range.
This appears to require that detection of an unsupported attribute or value
causes the entire SA negotiation to fail. This seems less than ideal,
as it means that any use of an attribute or value unsupported by the
recipient fails to create an SA, at which point one has to figure
out why and formulate new proposals that don't contain the offending
attribute or value. At best this is inefficient, and could lead to
lack of interoperability as I haven't found any guidance in the RFCs
as to how to formulate such new proposals.
Surely, receipt of proposals containing unsupported attributes and
values happens in practice -- what are IPsec implementations actually
doing when this happens?
If there's a concern about answering this question on the list,
feel free to email me directly, and I'll summarize the results
without identifying who's doing what.
Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA 01748
+1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909
black_david@emc.com
---------------------------------------------------
Follow-Ups: