On 10/25/14 11:28 PM, Marc Binderberger wrote:
For my comment about IPSEC/AH:
One question is whether the higher assurance is just for the VNI or for the
whole encapsulated frame. Using something like ESP/AH takes us down the
path of protecting the whole frame, which might be overkill.
agree. My (naive?) idea was to let AH in the NVO3 case only cover the
underlay IP header, the NVO3 header and maybe the tenant frame header
(IPv4/v6 or the Ethernet header). Honestly, have to re-read the specs if
there is a way to chieve this. It would protect all the information needed
when decapsulating the NVO3 overlay. The tenant frame protection I would
leave to a separate AH/ESP step before the overlay encap and after decap.
Marc,
AFAIK all the use of AH/ESP assume that it protects to the end of the
payload.
I guess one could define a variant - in the same way that UDP-lite is a
variant of UDP - but it would require adding a "protected length" field
somewhere.
As I tried to clarify in my response to Tom the meta-data discussion in the
IETF was mostly about vendor-specific service meta-data, but perhaps this
term is being used for more general extensibility?
that's how I was thinking about it. This may work as long as the encap/decap
entity - which can be a NIC, switch/router etc. - does not need to understand
what the meta-data means and can just add/remove it as opaque data.
Depending on the semantics it might be hard to add data - e.g., if the
data requires performing some computation on the packet.
The goal should be to at least be able to silently ignore received
meta-data.
I think there should be ways to add better assurance (checksum, keyed
hashes) for the NVO3 header. But perhaps that can be in fixed fields in a
fixed length header.
You mean the usual fields of "auth type", "key id" and such, typically part
of an authentication TLV, should be part of the NVO3 header from the
beginning? Nothing optional but build-in from the start?
Yes if the WG feels strongly about security it could define those fields
in as fixed fields from day 1. Whether the fields are used would be a
function of whether the security pieces are enabled - if not it would
waste some bandwidth.
My point is that this is an option which results in a fixed header
length with features that can be selectively enabled. Optional features
doesn't have to imply variable header length.
In terms of the overall architecture there is a desire to carry some
service meta-data with frames. The sfc WG is thinking about doing that
using a separate NSH header.
Even if we only cover IPv4, IPv6 and Ethernet as payload we need some
protocol or next-header field, IMHO. This could cover e.g. NSH as well.
Saying this, one could then also define a next-header value for OAM instead
of having a OAM (aka RA) flag - and let the hardware trigger on the value
instead of a flag.
Nevertheless, I think a reserved field for flags is a good idea if we have
the room in the NVO3 header.
Good point. If the OAM packets only need to be treated differently by
the decapsulating node then a payload type would suffice.
I don't know whether some of the cases (now discussed in Lime) assume
that a transit node can easily see which packets are OAM packets.
Erik
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
