I have found comp in TLS, RFC 3749, so HIP's ESP is the only one missing
compression. How did I miss that? It should have been included in 7402
as an option within ESP.
I will figure out a way to get it into some RFC, but perhaps a little
hashing out how it would work is called for first:
IPCOMP parameter is a list. The parameter number is higher than ESP;
something like 4111.
RFC 3173 defines the Compression Parameter Index as 2 bytes, so that
would be the size of the values in the list.
R1 would have a list of supported IPCOMP algorithms.
I2 would have the selected algorithm, or a value of ZERO if none.
R2 would have the confirmed value.
NOTIFY could be used to set up IPCOMP (or change it) at a later time.
Comments?
On 03/09/2016 10:20 AM, Robert Moskowitz wrote:
Why did we not create a parameter to negotiate IPCOMP (currently RFC
3173)?
In IKEv2 it is negotiated in NOTIFY messages, not the basic exchange
and becomes part of the daughter SA(s).
On contrained networks, IPCOMP could well be of value. Also if HIP is
used to establish the SAs for SSE (draft-moskowitz-sse-02.txt) and the
SSE payload is XML, then IPCOMP (or some variant tbd) may be a good
thing.
So....
Again, why no IPCOMP parameter?
IPCOMP parameter handled like ESP parameter or like in IKEv2?
How to add an IPCOMP parameter? If I write a draft for a Generic
Protocol Compression, I can include a section that defines an
IPCOMP/GPCOMP parameter. Or I can add it to DEX (don' want to add
that at this point, EC25519 fits, IPCOMP is expanding the protocol).
Comments?
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
