DH19 > DH16

Forum zum Thema allgemeinen Fragen zu VPN

Moderator: Lancom-Systems Moderatoren

Antworten
beki
Moderator
Moderator
Beiträge: 109
Registriert: 16 Jan 2017, 13:09
Wohnort: DKB/BY/DE

DH19 > DH16

Beitrag von beki »

Wie bringt man denn dem LANCOM bei dass DH19 besser als DH16 ist? Mein strongswan (Android) schlägt die Gruppen "19 20 21 28 29 30 15 16 14 2" vor, und das LCOS erlaubt die Gruppen "16 19" (per Konfiguration), und sucht aber 16 aus.

Aus dem VPN-Debug-Trace:
+Config DH transform(s): 16 19
+Received DH transform(s): 19 20 21 28 29 30 15 16 14 2
+Best intersection: 16
Ich würde hier schwer erwarten dass DH19 eine höhere Prio hat als DH16.

<Fehlinformation>Dass für strongswan 19 besser ist als 20 ... besser ist als 30 liegt am geringen Sicherheitsgewinn aber krass erhöhten Rechenaufwand (der Trade-Off stimmt nicht mehr).</Fehlinformation> LANCOM kann natürlich auch derartige Priorisierungen vornehmen und sagen dass DH16 besser ist als DH19.

Nun ist es aber mein Geschmack dass sich das Android und das LCOS sofort auf DH19 einigen sollen. Dazu müsste ich dem LANCOM beibringen dass es DH19 über DH16 bevorzugen soll. Geht das?

(Nein, ich möchte nicht die DEFAULT-Zeile in der Encryption-Tabelle auf alleine DH19 einschränken, da andere Road-Warriors DH19 womöglich nicht unterstützen.)
GrandDixence
Beiträge: 1060
Registriert: 19 Aug 2014, 22:41

Re: DH19 > DH16

Beitrag von GrandDixence »

Zum Verständnis meiner nachfolgenden Antwort bitte BSI TR 02102-3 Kapitel 3.2.4 "Empfohlene Gruppen für den Diffie-Hellman-Schlüsselaustausch" konsultieren:

https://www.bsi.bund.de/DE/Publikatione ... x_htm.html

Das Verfahren für den Diffie-Hellman-Schlüsselaustausch mit der IANA-Nummer 19 (oben mit DH19 bezeichnet) wird von den heute erhältlichen, offiziellen LCOS-Versionen nicht unterstützt. Möglicherweise wird das Verfahren mit der IANA-Nr. 19 in einer neueren, in Zukunft kommenden LCOS-Version unterstützt. Nur die unter:

https://www.lancom-systems.de/docs/LCOS ... 6_2_2.html

aufgelisteten Verfahren für den Diffie-Hellman-Schlüsselaustausch werden vom LANCOM-Gerät für IKEv2/IPSEC unterstützt und können konfiguriert werden.

Alle Verfahren für den Diffie-Hellman-Schlüsselaustausch auf Basis elliptischer Kurven (IANA-Nr. 19, 20, 21, 28, 29 und 30, TLS-Pendant: "ECDHE_") sind bei gleicher Sicherheit deutlich schneller als die Verfahren für den Diffie-Hellman-Schlüsselaustausch auf Basis von diskreten Logarithmen (IANA-Nr. 14, 15, 16 und 24 => TLS-Pendant: "DHE_").

Die Verfahren mit der Bezeichnung "DH2" und "DH5" gelten als unsicher und sollten aus Sicherheitsgründen nicht verwendet werden!

https://de.wikipedia.org/wiki/Diffie-He ... laustausch

https://www.heise.de/security/artikel/K ... 21002.html

https://www.golem.de/news/verschluessel ... 01457.html
beki
Moderator
Moderator
Beiträge: 109
Registriert: 16 Jan 2017, 13:09
Wohnort: DKB/BY/DE

Re: DH19 > DH16

Beitrag von beki »

GrandDixence hat geschrieben:Alle Verfahren für den Diffie-Hellman-Schlüsselaustausch auf Basis elliptischer Kurven (IANA-Nr. 19, 20, 21, 28, 29 und 30, TLS-Pendant: "ECDHE_") sind bei gleicher Sicherheit deutlich schneller als die Verfahren für den Diffie-Hellman-Schlüsselaustausch auf Basis von diskreten Logarithmen (=> TLS-Pendant: "DHE_"):
Achso! Danke für den Hinweis, das wusste ich nicht! Also gute Gründe diese neuen Verfahren einzusetzen. Und dann entschuldige ich mich dass ich Misinformation gestreut habe!
GrandDixence hat geschrieben:Das Verfahren für den Diffie-Hellman-Schlüsselaustausch mit der IANA-Nummer 19 (oben mit DH19 bezeichnet) wird von den heute erhältlichen, offiziellen LCOS-Versionen nicht unterstützt.
Ja, ne. LCOS 10.12RC1 unterstützt diese Verfahren. Den Ausschnitt aus dem VPN-Debug-Trace, den ich eingefügt habe, habe ich nicht etwa gefälscht... Da sagt das LCOS ganz klar dass Gruppe 19 als erlaubt konfiguriert ist.

Code: Alles auswählen

07/20/2017 20:32:13 schlimmchen on torvalds in /Setup/VPN/IKEv2/Encryption
> set ?

Possible input for columns in table 'Encryption':
[  1] Name                    : 16 chars from ABCDEFGHIJKLMNOPQRSTUVWXYZ@{|}~!$%&'()+-,/:;<=>?[\]^_.0123456789
[  2] DH-Groups               : Bitmask: DH30 (32), DH29 (64), DH28 (128), DH21 (256), DH20 (512), DH19 (1024), DH16 (1), DH15 (2), DH14 (4), DH5 (8), DH2 (16)
[  3] PFS                     : No (0), Yes (1)
[  4] IKE-SA-Cipher-List      : Bitmask: AES-CBC-256 (1), AES-CBC-192 (2), AES-CBC-128 (4), 3DES (8), AES-GCM-256 (16), AES-GCM-192 (32), AES-GCM-128 (64)
[  5] IKE-SA-Integ-Alg-List   : Bitmask: SHA-512 (1), SHA-384 (2), SHA-256 (4), SHA1 (8), MD5 (16)
[  6] Child-SA-Cipher-List    : Bitmask: AES-CBC-256 (1), AES-CBC-192 (2), AES-CBC-128 (4), 3DES (8), AES-GCM-256 (16), AES-GCM-192 (32), AES-GCM-128 (64)
[  7] Child-SA-Integ-Alg-List : Bitmask: SHA-512 (1), SHA-384 (2), SHA-256 (4), SHA1 (8), MD5 (16)
Siehe auch ftp://ftp.lancom.de/Documentation/Relea ... RC1-DE.pdf bzw. ftp://ftp.lancom.de/Documentation/Relea ... RC1-EN.pdf

Daher sehe ich meine Frage als durchaus gerechtfertigt (ich hab den Eindruck du wolltest meine Frage dadurch obsolet machen dass du erklärst dass das LCOS diese Verfahren sowieso nicht unterstützt).
GrandDixence
Beiträge: 1060
Registriert: 19 Aug 2014, 22:41

Re: DH19 > DH16

Beitrag von GrandDixence »

Für den Einsatz der StrongSwan Android App siehe bitte auch:

http://www.lancom-forum.de/aktuelle-lan ... 16074.html
GrandDixence
Beiträge: 1060
Registriert: 19 Aug 2014, 22:41

Re: DH19 > DH16

Beitrag von GrandDixence »

Wahrscheinlich bevorzugt das LANCOM-Gerät als VPN-Server das Verfahren für den Diffie-Hellman-Schlüsselaustausch, zu welchem vom VPN-Client bereits im IKE_SA_INIT-REQUEST Telegramm (IKE-Telegramm Nr. 1 beim VPN-Tunnelaufbau) der "öffentliche Diffie-Hellman-Key-Exchange-Faktor KEi" im "KE Payload" mitgeliefert wird. Dieses Verhalten beschleunigt den VPN-Tunnelaufbau. Zum Beispiel:

Code: Alles auswählen

[VPN-IKE] 2016/09/03 20:26:40,999  => Telegramm Nr. 1
Received packet:
IKE 2.0 Header:
Source/Port         : 178.197.237.50:27805
Destination/Port    : 77.58.186.26:500
VLAN-ID             : 0
HW switch port      : 0
Routing-tag         : 0
Com-channel         : 2
Loopback            : NO
| Initiator cookie  : AC D2 3C 87 D8 1D D2 8A
| Responder cookie  : 00 00 00 00 00 00 00 00
| Next Payload      : SA
| Version           : 2.0
| Exchange type     : IKE_SA_INIT
| Flags             : 0x08   Initiator
| Msg-ID            : 0
| Length            : 624 Bytes
SA Payload
| Next Payload      : KE
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 136 Bytes
| PROPOSAL Payload
| | Next Payload    : PROPOSAL
| | Reserved        : 0x00
| | Length          : 44 Bytes
| | Proposal number : 1
| | Protocol ID     : IPSEC_IKE
| | SPI size        : 0
| | #Transforms     : 4
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 12 Bytes
| | | Transform Type: ENCR
| | | Reserved2     : 0x00
| | | Transform ID  : AES_CBC
| | | Attribute 0
| | | | Type        : Basic, KEYLENGTH
| | | | Value       : 256
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: INTEG
| | | Reserved2     : 0x00
| | | Transform ID  : SHA1
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: PRF
| | | Reserved2     : 0x00
| | | Transform ID  : PRF-HMAC-SHA1
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : NONE
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: DH
| | | Reserved2     : 0x00
| | | Transform ID  : 14
| | | Attributes    : NONE
| PROPOSAL Payload
| | Next Payload    : PROPOSAL
| | Reserved        : 0x00
| | Length          : 44 Bytes
| | Proposal number : 2
| | Protocol ID     : IPSEC_IKE
| | SPI size        : 0
| | #Transforms     : 4
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 12 Bytes
| | | Transform Type: ENCR
| | | Reserved2     : 0x00
| | | Transform ID  : AES_CBC
| | | Attribute 0
| | | | Type        : Basic, KEYLENGTH
| | | | Value       : 256
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: INTEG
| | | Reserved2     : 0x00
| | | Transform ID  : SHA-256
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: PRF
| | | Reserved2     : 0x00
| | | Transform ID  : PRF-HMAC-SHA-256
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : NONE
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: DH
| | | Reserved2     : 0x00
| | | Transform ID  : 14
| | | Attributes    : NONE
| PROPOSAL Payload
| | Next Payload    : NONE
| | Reserved        : 0x00
| | Length          : 44 Bytes
| | Proposal number : 3
| | Protocol ID     : IPSEC_IKE
| | SPI size        : 0
| | #Transforms     : 4
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 12 Bytes
| | | Transform Type: ENCR
| | | Reserved2     : 0x00
| | | Transform ID  : AES_CBC
| | | Attribute 0
| | | | Type        : Basic, KEYLENGTH
| | | | Value       : 256
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: INTEG
| | | Reserved2     : 0x00
| | | Transform ID  : SHA-384
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: PRF
| | | Reserved2     : 0x00
| | | Transform ID  : PRF-HMAC-SHA-384
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : NONE
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: DH
| | | Reserved2     : 0x00
| | | Transform ID  : 14
| | | Attributes    : NONE
KE Payload
| Next Payload      : NONCE
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 264 Bytes
| DH Group          : 14
| Reserved2         : 0x0000
| DH-Key(2048 bits) : DB DE 36 1B 27 58 B8 DC 05 24 D6 98 42 8F 66 82
|                     72 37 67 F4 84 12 7C 48 C2 89 CC 18 F0 28 93 74
|                     94 AC E4 53 DC 63 C6 8A C1 C7 1D 8B DE 8E 1F E0
|                     2C 41 30 7B 09 79 70 56 6B 2A CB 57 60 41 26 C6
|                     11 C3 C5 D3 7F 97 53 D8 8F A3 D1 27 5D A6 E6 CD
|                     B5 93 33 AD AD 2A BE 1A 8B B7 7C DA F6 FE AA 03
|                     E4 01 40 62 27 5A 95 2A 94 A5 96 E7 10 96 B7 D5
|                     F3 61 C8 35 34 5C 63 59 A2 60 09 E9 FB 82 D9 AE
|                     16 4E A9 BB C4 4B A5 1A 55 56 7E 6B 80 27 20 3A
|                     43 F9 B8 BF AA 18 8B 2A 03 07 F2 14 84 50 56 6F
|                     B0 59 5E 0E EC FE 66 52 7D 7F C3 52 B5 49 7F 8F
|                     15 C2 83 A6 3E 12 22 5C A6 07 0E 3B 51 2F 62 AB
|                     04 C5 57 8C C3 4F 05 77 98 0B 9B 90 51 C2 F1 AE
|                     EB 20 AD 57 12 BA C1 C7 AB 11 6F 21 62 7E 48 C6
|                     1B B6 E6 A1 6B C9 6F 9A 2B 2A 85 2A F3 A7 0C 81
|                     C4 D0 E1 CC 9A 35 60 3E 39 DF 13 18 86 F5 6E ED
NONCE Payload
beki
Moderator
Moderator
Beiträge: 109
Registriert: 16 Jan 2017, 13:09
Wohnort: DKB/BY/DE

Re: DH19 > DH16

Beitrag von beki »

Genau das will ich -- den Verbindungsaufbau beschleunigen indem ich mir das Invalid-KE-Payload spare weil es eine andere DH Gruppe sein muss laut Konfiguration. Natürlich unter der Annahme dass mir als Administrator die vom Client gewählte DH Gruppe grundsätzlich als brauchbar erscheint.

Das Android strongswan schickt im ersten IKE Paket den KE Payload mit DH19, und dennoch wünscht das LANCOM DH16, wenn ich DH16 im DEFAULT-Encryption-Profil zulasse und verursacht damit den Wechsel auf DH16 (und verlangsamt den Verbindungsaufbau).

Den IKE-SA-Init-Request hänge ich an (da mega lang).
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
GrandDixence
Beiträge: 1060
Registriert: 19 Aug 2014, 22:41

Re: DH19 > DH16

Beitrag von GrandDixence »

Bitte den vollständigen VPN-Trace des VPN-Tunnelaufbaus veröffentlichen:

Code: Alles auswählen

trace + vpn
trace + vpn-debug 
Ich sehe den Grund nicht, wieso das LANCOM-Gerät mit LCOS v10.12RC1 das Diffie-Hellman-Schlüsselverfahren mit der IANA-Nr. 16 statt Nr. 19 wählt und diese Wahl dem VPN-Client im IKE_SA_INIT-RESPONSE Telegramm (IKE-Telegramm Nr. 2 beim VPN-Tunnelaufbau) kommuniziert.

=> In einer Entwicklungsversion wie der LCOS v10.12RC1 dürfen noch Programmierfehler enthalten sein...
GrandDixence
Beiträge: 1060
Registriert: 19 Aug 2014, 22:41

Re: DH19 > DH16

Beitrag von GrandDixence »

Mit der folgenden LANCOM-Konfiguration sollte es mit den (im ZIP-Archiv ersichtlichen) Vorschlägen/Proposals aus IKE_SA_INIT-REQUEST klappen:

Code: Alles auswählen

[  2] DH-Groups               : Bitmask: DH19 (1024)
[  3] PFS                     : Yes (1)
[  4] IKE-SA-Cipher-List      : Bitmask: AES-GCM-128 (64)
[  5] IKE-SA-Integ-Alg-List   : Bitmask: SHA-256 (4)
[  6] Child-SA-Cipher-List    : Bitmask: AES-GCM-128 (64)
[  7] Child-SA-Integ-Alg-List : Bitmask: SHA-256 (4)
Bei der Wahl von:

Code: Alles auswählen

[  2] DH-Groups               : Bitmask: DH19 (1024)
sei aber noch auf die Sicherheitsbedenken bei der Wahl der NIST-Kurven (IANA-Nr. 19, 20, 21) verwiesen:

https://www.heise.de/security/artikel/K ... kelseite=5

BSI TR 02102-3 Kapitel 3.2.4, Hinweis 2 und 4
beki
Moderator
Moderator
Beiträge: 109
Registriert: 16 Jan 2017, 13:09
Wohnort: DKB/BY/DE

Re: DH19 > DH16

Beitrag von beki »

GrandDixence hat geschrieben:=> In einer Entwicklungsversion wie der LCOS v10.12RC1 dürfen noch Programmierfehler enthalten sein...
Ich habe auch nichts Gegenteiliges behauptet und insbesondere nicht behauptet, dass es sich um einen Programmierfehler handelt! Wenn es eine interne Präferenzenliste gibt in der DH16 bevorzugt wird, dann ist das eine Entscheidung und kein Programmierfehler.

Ich frage nach einer Möglichkeit das LANCOM so zu konfigurieren, dass es DH19 über DH16 bevorzugt, bzw. nach einer Möglichkeit im Allgemeinen Einfluss darauf zu nehmen, welcher Wert aus der Schnittmenge von angebotenen und akzeptierten Werten bevorzugt wird.

Gerne hänge ich den gesamten Trace an (VPN-Debug, VPN-Status und VPN-IKE gemischt). Achtung: Der Verbindungsaufbau schlägt hier fehl, weil das LANCOM DH16 vorgibt, auf DH16 gewechselt wird und sich nach der Authentifizierung herausstellt dass für den nun bekannten Client nur DH19 zugelassen ist. Die relevanten Teile der Konfig habe ich ebenfalls angehangen.

Info: Wenn ich für DEFAULT DH16 nicht zulasse, dann wird die Verbindung (schnell) mit DH19 aufgebaut. Wenn ich für PHONE (also den konkreten Client) DH16 zulasse, dann wird die Verbindung (langsam, also mit INVALID_KE_PAYLOAD) mit DH16 aufgebaut.

EDIT:
GrandDixence hat geschrieben:Mit der folgenden LANCOM-Konfiguration sollte es mit den (im ZIP-Archiv ersichtlichen) Vorschlägen/Proposals aus IKE_SA_INIT-REQUEST klappen:
Jain. Nur wenn ich ausschließlich DH19 für /setup/VPN/IKEv2/Encryption/DEFAULT zulasse, was nicht Sinn der Übung ist. Ich will nicht für alle Roadwarriors DH19 erzwingen, sondern nur für jene die es auch können.

Im Übrigen hab ich auch kein Problem damit, die Verbindung aufzubauen... Darum geht es nicht! Es geht um die Diskussion dass man dem LANCOM die Präferenzen unter den DH Gruppen nicht beibringen zu können scheint.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
GrandDixence
Beiträge: 1060
Registriert: 19 Aug 2014, 22:41

Re: DH19 > DH16

Beitrag von GrandDixence »

Wie aus den Zeilen:

Code: Alles auswählen

Looking for payload IKE_SA (33)...Found 1 payload.
  +Config   ENCR  transform(s): AES-CBC-256
  +Received ENCR  transform(s): AES-CBC-128 AES-CBC-192 AES-CBC-256 3DES
  +Best intersection: AES-CBC-256
  +Config   PRF   transform(s): PRF-HMAC-SHA-512 PRF-HMAC-SHA-384 PRF-HMAC-SHA-256
  +Received PRF   transform(s): PRF-HMAC-SHA-256 PRF-HMAC-SHA-384 PRF-HMAC-SHA-512 PRF-HMAC-MD5 PRF-HMAC-SHA1
  +Best intersection: PRF-HMAC-SHA-512
  +Config   INTEG transform(s): HMAC-SHA-512 HMAC-SHA-384 HMAC-SHA-256
  +Received INTEG transform(s): HMAC-SHA-256 HMAC-SHA-384 HMAC-SHA-512 HMAC-MD5 HMAC-SHA1
  +Best intersection: HMAC-SHA-512
  +Config   DH    transform(s): 16 19
  +Received DH    transform(s): 19 20 21 28 29 30 15 16 14 2
  +Best intersection: 16
ersichtlich, versucht das LANCOM-Gerät immer die Methode mit dem höheren Sicherheitsniveau zu verwenden. Für den Diffie-Hellman-Schlüsselaustausch bevorzugt/wählt das LANCOM-Gerät das Verfahren mit der IANA-Nr. 16, da dieses ein besseres Sicherheitsniveau bietet als das Verfahren mit der IANA-Nr. 19.

Aktuell ist der Einsatz von 3 Sicherheitsniveau empfehlenswert:

Code: Alles auswählen

Sicherheitsniveau  | symmetr. | Hash    | asymmetrisch (RSA/DH)     | ECC asymmetrisch (ECDH)
-------------------+----------+---------+---------------------------+----------------------------------
256 Bit            | AES-256  | SHA-512 | 15360 Bit (nicht möglich) | 512 (IANA-Nr. 21 und 30)
192 Bit            | AES-192  | SHA-384 |  7680 Bit (nicht möglich) | 384 (IANA-Nr. 20 und 29)
128 Bit            | AES-128  | SHA-256 |  3072 Bit (IANA-Nr. 15)   | 256 (IANA-Nr. 19 und 28)


Das Diffie-Hellman-Schlüsselaustausch-Verfahren mit der IANA-Nr. 16 (asymmetrisches DH mit 4096 Bit => Bezeichnung: DH16) entspricht einem Sicherheitsniveau x:

192 Bit > x > 128 Bit

Siehe auch:

https://www.heise.de/security/meldung/O ... 03493.html
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: DH19 > DH16

Beitrag von Jirka »

Hallo GrandDixence,
GrandDixence hat geschrieben:Alle Verfahren für den Diffie-Hellman-Schlüsselaustausch auf Basis elliptischer Kurven (IANA-Nr. 19, [...]) sind bei gleicher Sicherheit deutlich schneller als die Verfahren für den Diffie-Hellman-Schlüsselaustausch auf Basis von diskreten Logarithmen (IANA-Nr. [...] 16 [...]).
GrandDixence hat geschrieben:Wie aus den Zeilen [...] ersichtlich, versucht das LANCOM-Gerät immer die Methode mit dem höheren Sicherheitsniveau zu verwenden. Für den Diffie-Hellman-Schlüsselaustausch bevorzugt/wählt das LANCOM-Gerät das Verfahren mit der IANA-Nr. 16, da dieses ein besseres Sicherheitsniveau bietet als das Verfahren mit der IANA-Nr. 19.
ja, was denn nun?

Viele Grüße,
Jirka
MariusP
Beiträge: 1036
Registriert: 10 Okt 2011, 14:29

Re: DH19 > DH16

Beitrag von MariusP »

Hi,
Soweit ich weis liegt dies an der Anordnung der Bitmaskwerte.
Wenn ihr auf der Konsole im IKEv2/Encryption Menu "set ?" eingebt seht ihr die Anordnung der Werte.
Die Defaults und deren Anordung werden nur selten geändert, damit die Kunden sich nicht zu häufig auf ein neues Verhalten einstellen müssen.
Gruß
Erst wenn der letzte Baum gerodet, der letzte Fluss vergiftet, der letzte Fisch gefangen ist, werdet Ihr merken, dass man Geld nicht essen kann.

Ein Optimist, mit entäuschten Idealen, hat ein besseres Leben als ein Pessimist der sich bestätigt fühlt.
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: DH19 > DH16

Beitrag von Jirka »

Hallo Marius,
MariusP hat geschrieben:Soweit ich weis liegt dies an der Anordnung der Bitmaskwerte.
hmm, meinst Du?! Die sind doch schön absteigend sortiert:

Code: Alles auswählen

Possible input for columns in table 'Encryption':
[  2] DH-Groups: Bitmask: DH30 (32), DH29 (64), DH28 (128), DH21 (256), DH20 (512), DH19 (1024), DH16 (1), DH15 (2), DH14 (4), DH5 (8), DH2 (16)
Oder meinst Du jetzt, dass die entsprechenden Ziffernwerte (deren Kombination dann den Bitmask-Wert ergibt) eine Sortierung vorgeben? Das wäre dann aber weit hergeholt oder tatsächlich ein Bug, wenn die Werte eine Priorität abbilden.

Viele Grüße,
Jirka
Antworten