Re: IPCOMP support in HIP

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
>