[prev in list] [next in list] [prev in thread] [next in thread]
List: ipsec
Subject: Re: [IPsec] Proposals for IPsec Compression Mode for ESP Header Compression (EHC)
From: "Tobias Guggemos" <guggemos () nm ! ifi ! lmu ! de>
Date: 2018-10-27 9:31:48
Message-ID: 001501d46dd7$e33f7510$a9be5f30$ () nm ! ifi ! lmu ! de
[Download RAW message or body]
This is a multipart message in MIME format.
--===============6465303792836765832==
Content-Language: de
Content-Type: multipart/signed; protocol="application/pgp-signature";
micalg=pgp-sha256; boundary="=-=vDveqvQQbIBDpo=-="
This is a multipart message in MIME format.
[Attachment #2 (multipart/alternative)]
Hey Valery,
Thanks for your thoughts.
The idea was to keep the notification of the support of compression separated from \
the notification how the compression is actually performed.
However, you're perfectly right, it is not necessary and I'm perfectly fine with not \
defining this new notify payload for IKEv2.
Regards
Tobias
Von: Valery Smyslov <smyslov.ietf@gmail.com>
Gesendet: Donnerstag, 25. Oktober 2018 10:42
An: 'Tobias Guggemos' <guggemos@nm.ifi.lmu.de>; 'IPsecME WG' <ipsec@ietf.org>
Betreff: RE: [IPsec] Proposals for IPsec Compression Mode for ESP Header Compression \
(EHC)
Hi Tobias,
unless I missed something, I think USE_COMPRESSED_MODE notify is superfluous
and is not needed. As far as I understand, you negotiate EHC parameters per IPsec SA \
basis,
so if they are negotiated successfully, then compression is used for this SA.
If you need separate SA for the traffic that cannot be compressed, then negotiate
it separately without EHC_STRATEGY_SUPPORTED notification. You may create
as many IPsec SAs with the same Traffic Selectors as you like. Am I missing \
something?
Regards,
Valery.
From: IPsec [mailto:ipsec-bounces@ietf.org <mailto:ipsec-bounces@ietf.org> ] On \
Behalf Of Tobias Guggemos
Sent: Thursday, October 18, 2018 1:57 PM
To: IPsecME WG
Subject: [IPsec] Proposals for IPsec Compression Mode for ESP Header Compression \
(EHC)
Hey all,
ESP Header Compression (EHC, [1]) defines a set of rules how to compress ESP for \
specific scenarios, e.g. IoT and [2] describes how to negotiate this rules with \
IKEv2.
Due to some suggestions we defined a new IPsec mode (COMPRESSION_MODE), which is \
necessary in order to prevent decompression failures in certain maybe unforeseen \
situation (e.g. IP fragmentation, or the use UDP options).
With the new mode, the sender can decide to send certain packets "uncompressed" if \
the receiver may not be able to decompress properly.. The sender notifies the \
receiver by using a different SA and thus a different SPI.
We believe this is more clean than defining something like a "compressed" bit in the \
ESP packet..
That's why we also thought about how to negotiate this new mode with IKEv2.
We believe that a clean way to negotiate this new mode is with a new Notify Payload, \
namely "USE_COMPRESSED_MODE".
The question is, do we need an explicit agreement of the COMPRESSED_MODE or is the \
negotiation of using EHC [1] enough to figure out that the two peers have to use \
COMPRESSED_MODE anyways?
More specifically here are the following possibilities
A) Negotiating 2 IPsec SAs with EHC parameters and specifying. with USE_COMPRESS_MODE \
the SA that compress payload (using EHC). The other SA *without* USE_COMPRESS_ MODE \
will not proceed to compression. In other words, EHC is activated if and only if \
USE_COMPRESS_MODE is active for the SA.
B) Negotiation of 2 IPsec SAs. One with EHC parameters which assumes compression is \
requested and one without EHC in which case no compression is performed.
During the last IETF we had a brief discussion in the meeting which we would like to \
bring to the list now.
We're looking forward to any opinions or suggestions.
Regards
Tobias
[1] https://tools.ietf.org/html/draft-mglt-ipsecme-diet-esp-06 \
<https://tools.ietf.org/html/draft-mglt-ipsecme-diet-esp-06>
[2] https://tools.ietf.org/html/draft-mglt-ipsecme-ikev2-diet-esp-extension-01 \
<https://tools.ietf.org/html/draft-mglt-ipsecme-ikev2-diet-esp-extension-01>
--
_ _ _ _ _ _ Tobias Guggemos M.Sc.
|\/| |\ | |\/| Institut für Informatik / Dept. of CS
| | | \| | | Ludwig-Maximilians-Universität München
======= TEAM ======= Oettingenstr. 67, 80538 Munich, Germany
Room E 010, Phone +49-89-2180-9209
Munich Network Management Team Email: guggemos@nm.ifi.lmu.de \
<mailto:guggemos@nm.ifi.lmu.de>
Muenchner Netz-Management Team http://www.nm.ifi.lmu.de/~guggemos \
<http://www.nm.ifi.lmu.de/~guggemos>
[Attachment #5 (text/html)]
<html xmlns:v="urn:schemas-microsoft-com:vml" \
xmlns:o="urn:schemas-microsoft-com:office:office" \
xmlns:w="urn:schemas-microsoft-com:office:word" \
xmlns:x="urn:schemas-microsoft-com:office:excel" \
xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" \
xmlns="http://www.w3.org/TR/REC-html40"><head><meta name=Generator content="Microsoft \
Word 15 (filtered medium)"><style><!-- /* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.E-MailFormatvorlage18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.E-MailFormatvorlage19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#44546A;}
span.E-MailFormatvorlage20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.E-MailFormatvorlage21
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
..MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=DE link="#0563C1" \
vlink="#954F72"><div class=WordSection1><p class=MsoNormal><span lang=EN-US \
style='color:#1F497D'>Hey Valery,<o:p></o:p></span></p><p class=MsoNormal><span \
lang=EN-US style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span \
lang=EN-US style='color:#1F497D'>Thanks for your thoughts.<o:p></o:p></span></p><p \
class=MsoNormal><span lang=EN-US style='color:#1F497D'>The idea was to keep the \
notification of the support of compression separated from the notification how the \
compression is actually performed.<o:p></o:p></span></p><p class=MsoNormal><span \
lang=EN-US style='color:#1F497D'>However, you're perfectly right, it is not necessary \
and I'm perfectly fine with not defining this new notify payload for \
IKEv2.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US \
style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US \
style='color:#1F497D'>Regards<o:p></o:p></span></p><p class=MsoNormal><span \
lang=EN-US style='color:#1F497D'>Tobias<o:p></o:p></span></p><p class=MsoNormal><span \
lang=EN-US style='color:#1F497D'><o:p> </o:p></span></p><div \
style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'><div><div \
style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p \
class=MsoNormal><b><span style='mso-fareast-language:DE'>Von:</span></b><span \
style='mso-fareast-language:DE'> Valery Smyslov <smyslov.ietf@gmail..com> \
<br><b>Gesendet:</b> Donnerstag, 25. </span><span lang=EN-US \
style='mso-fareast-language:DE'>Oktober 2018 10:42<br><b>An:</b> 'Tobias Guggemos' \
<guggemos@nm.ifi.lmu.de>; 'IPsecME WG' \
<ipsec@ietf.org><br><b>Betreff:</b> RE: [IPsec] Proposals for IPsec Compression \
Mode for ESP Header Compression (EHC)<o:p></o:p></span></p></div></div><p \
class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span \
lang=EN-US style='font-size:14.0pt;color:#44546A'>Hi Tobias,<o:p></o:p></span></p><p \
class=MsoNormal><span lang=EN-US \
style='font-size:14.0pt;color:#44546A'><o:p> </o:p></span></p><p \
class=MsoNormal><span lang=EN-US style='font-size:14.0pt;color:#44546A'>unless I \
missed something, I think USE_COMPRESSED_MODE notify is superfluous \
<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US \
style='font-size:14.0pt;color:#44546A'>and is not needed. As far as I understand, you \
negotiate EHC parameters per IPsec SA basis,<o:p></o:p></span></p><p \
class=MsoNormal><span lang=EN-US style='font-size:14.0pt;color:#44546A'>so if they \
are negotiated successfully, then compression is used for this \
SA.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US \
style='font-size:14.0pt;color:#44546A'>If you need separate SA for the traffic that \
cannot be compressed, then negotiate<o:p></o:p></span></p><p class=MsoNormal><span \
lang=EN-US style='font-size:14.0pt;color:#44546A'>it separately without \
EHC_STRATEGY_SUPPORTED notification. You may create<o:p></o:p></span></p><p \
class=MsoNormal><span lang=EN-US style='font-size:14.0pt;color:#44546A'>as many IPsec \
SAs with the same Traffic Selectors as you like. Am I missing \
something?<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US \
style='font-size:14.0pt;color:#44546A'><o:p> </o:p></span></p><p \
class=MsoNormal><span lang=EN-US \
style='font-size:14.0pt;color:#44546A'>Regards,<o:p></o:p></span></p><p \
class=MsoNormal><span lang=EN-US \
style='font-size:14.0pt;color:#44546A'>Valery.<o:p></o:p></span></p><p \
class=MsoNormal><span lang=EN-US \
style='font-size:14.0pt;color:#44546A'><o:p> </o:p></span></p><div \
style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'><div><div \
style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p \
class=MsoNormal><b><span lang=EN-US \
style='font-size:10.0pt;font-family:"Tahoma",sans-serif;mso-fareast-language:RU'>From:</span></b><span \
lang=EN-US style='font-size:10.0pt;font-family:"Tahoma",sans-serif;mso-fareast-language:RU'> \
IPsec [</span><a href="mailto:ipsec-bounces@ietf.org"><span lang=EN-US \
style='font-size:10.0pt;font-family:"Tahoma",sans-serif;mso-fareast-language:RU'>mailto:ipsec-bounces@ietf.org</span></a><span \
lang=EN-US style='font-size:10.0pt;font-family:"Tahoma",sans-serif;mso-fareast-language:RU'>] \
<b>On Behalf Of </b>Tobias Guggemos<br><b>Sent:</b> Thursday, October 18, 2018 1:57 \
PM<br><b>To:</b> IPsecME WG<br><b>Subject:</b> [IPsec] Proposals for IPsec \
Compression Mode for ESP Header Compression (EHC)<o:p></o:p></span></p></div></div><p \
class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span \
lang=EN-US>Hey all,<o:p></o:p></span></p><p class=MsoNormal><span \
lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>ESP Header \
Compression (EHC, [1]) defines a set of rules how to compress ESP for specific \
scenarios, e.g. IoT and [2] describes how to negotiate this rules with \
IKEv2.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>Due to some \
suggestions we defined a new IPsec mode (COMPRESSION_MODE), which is necessary in \
order to prevent decompression failures in certain maybe unforeseen situation (e.g. \
IP fragmentation, or the use UDP options).<o:p></o:p></span></p><p \
class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span \
lang=EN-US>With the new mode, the sender can decide to send certain packets \
"uncompressed" if the receiver may not be able to decompress properly. The sender \
notifies the receiver by using a different SA and thus a different \
SPI.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>We believe this is more \
clean than defining something like a "compressed" bit in the ESP packet.. \
<o:p></o:p></span></p><p class=MsoNormal><span \
lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>That's why \
we also thought about how to negotiate this new mode with \
IKEv2.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>We believe that a \
clean way to negotiate this new mode is with a new Notify Payload, namely \
"USE_COMPRESSED_MODE".<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>The \
question is, do we need an explicit agreement of the COMPRESSED_MODE or is the \
negotiation of using EHC [1] enough to figure out that the two peers have to use \
COMPRESSED_MODE anyways?<o:p></o:p></span></p><p class=MsoNormal><span \
lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>More \
specifically here are the following possibilities<o:p></o:p></span></p><p \
class=MsoNormal><span lang=EN-US>A) Negotiating 2 IPsec SAs with EHC parameters and \
specifying. with USE_COMPRESS_MODE the SA that compress payload (using EHC). The \
other SA *<b>without</b>* USE_COMPRESS_ MODE will not proceed to compression. In \
other words, EHC is activated if and only if USE_COMPRESS_MODE is active for the \
SA.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>B) Negotiation of 2 \
IPsec SAs. One with EHC parameters which assumes compression is requested and one \
without EHC in which case no compression is performed.<o:p></o:p></span></p><p \
class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span \
lang=EN-US>During the last IETF we had a brief discussion in the meeting which we \
would like to bring to the list now.<o:p></o:p></span></p><p class=MsoNormal><span \
lang=EN-US>We're looking forward to any opinions or \
suggestions.<o:p></o:p></span></p><p class=MsoNormal><span \
lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span \
lang=EN-US>Regards<o:p></o:p></span></p><p class=MsoNormal><span \
lang=EN-US>Tobias<o:p></o:p></span></p><p class=MsoNormal><span \
lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>[1] \
</span><a href="https://tools.ietf.org/html/draft-mglt-ipsecme-diet-esp-06"><span \
lang=EN-US>https://tools.ietf.org/html/draft-mglt-ipsecme-diet-esp-06</span></a> \
<span lang=EN-US><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>[2] \
</span><a href="https://tools.ietf.org/html/draft-mglt-ipsecme-ikev2-diet-esp-extension-01"><span \
lang=EN-US>https://tools.ietf.org/html/draft-mglt-ipsecme-ikev2-diet-esp-extension-01</span></a><span \
lang=EN-US><o:p></o:p></span></p><p class=MsoNormal><span \
lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US \
style='font-family:"Courier New"'><o:p> </o:p></span></p><p \
class=MsoNormal><span style='font-family:"Courier New"'>-- <o:p></o:p></span></p><p \
class=MsoNormal><span style='font-family:"Courier \
New"'> _ _ _ _ \
_ _ Tobias Guggemos \
M.Sc.<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Courier \
New"'> |\/| |\ | \
|\/| Institut für Informatik / \
Dept. of CS<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Courier \
New"'> | | | \| | \
| \
Ludwig-Maximilians-Universität München<o:p></o:p></span></p><p \
class=MsoNormal><span style='font-family:"Courier \
New"'> ======= TEAM \
======= Oettingenstr. </span><span lang=EN-US \
style='font-family:"Courier New"'>67, 80538 Munich, Germany<o:p></o:p></span></p><p \
class=MsoNormal><span lang=EN-US style='font-family:"Courier \
New"'> &n \
bsp; \
Room E 010, Phone +49-89-2180-9209 <o:p></o:p></span></p><p class=MsoNormal><span \
lang=EN-US style='font-family:"Courier New"'>Munich Network Management \
Team Email: </span><a href="mailto:guggemos@nm.ifi.lmu.de"><span \
lang=EN-US style='font-family:"Courier New"'>guggemos@nm.ifi.lmu.de</span></a><span \
lang=EN-US style='font-family:"Courier New"'> <o:p></o:p></span></p><p \
class=MsoNormal><span style='font-family:"Courier New"'>Muenchner Netz-Management \
Team </span><a href="http://www.nm.ifi.lmu.de/~guggemos"><span \
style='font-family:"Courier New"'>http://www.nm.ifi.lmu.de/~guggemos</span></a><span \
style='font-family:"Courier New"'> <o:p></o:p></span></p><p \
class=MsoNormal><o:p> </o:p></p></div></div></div></body></html>
[Attachment #6 (unknown)]
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEyFCRjitB0A1IDrryyEcVbMgzVZ8FAlvUMHwACgkQyEcVbMgz
VZ/W4gf/TYR7YNvpoC2UdaW5ottlNpqArKyb9rS9ylV9aV/MZPnYFMzoZxgckYMl
6MIhptwp+/mCzESJ+PpnF+b1ahZPTHr4JDEYZDuoksQzrtA1n3Ruh3mrs6Bde4cl
ndAyxmxFNznoA+Sm+w0f2Gr25d4YwbK18aJLxzjKMEIHDZDvIFFknPim6HsFmdqd
UZcHNIU4JGGfS7+pajtE2uZeBdl8dBIcdgOlhd1Qe9HO1Kb6inMxYEXqQZThfaDV
wsbGBK/RyE6cI6CMuMAvTE51PbMdXrUpYa/+qBM8hTMe3Bw0qw2+uXoR5ovy/Nv2
m6Q7Y/RbEaDXiwu51qWs/j1rDFa9oQ==
=Y20R
-----END PGP SIGNATURE-----
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--===============6465303792836765832==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic