[strongSwan-dev] Stroke message limit and big traffic selectors

[Emeric POUPON]

Hello,

No idea about this issue? I guess proposing so many traffic selectors does not make that much sense then?

Regards,

Emeric

----- Mail original -----
De: "Emeric POUPON" <emeric.poupon at stormshield.eu>
À: dev at lists.strongswan.org
Envoyé: Mardi 9 Décembre 2014 14:23:42
Objet: [strongSwan-dev] Stroke message limit and big traffic selectors

Hello,

I have a question about the stroke message (stroke_msg_t) and traffics selectors

I tried to set up a connection involving a lot of comma separated IPv6 traffic selectors.
The connection is properly parsed by starter, but the stroke_msg_t is too small to contain both leftsubnet and rightsubnet tokens (STROKE_BUF_LEN is too small: 2048)

If the token is not set, its value silently fallbacks to the '::/0' selector, which is definately not what I want!
If both tokens are not set, it's even worse since I end up with a '::/0' === '::/0' policy.

I think it would be safer to set the STROKE_BUF_LEN to a bigger value and to allocate the stroke_msg_t on the heap in starterstroke.c
What do you think?

I have another question: is there a limit of traffic selectors that can be presented by a peer? The RFC says the number of selectors is encoded on a byte, but I don't really know if 255 traffic selectors in a proposal makes much sense?

Best Regards,

Emeric










_______________________________________________
Dev mailing list
Dev at lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/dev