While I agree with you in general, I think that IKE has its own peculiarity,
that makes things a bit different.
There is a difference between IPv6 and IPv4. In IPv6 one can assume,
that packets below 1280 bytes will not be fragmented en route. This leaves
enough room
to make IKE level fragmentati
Consider the situation when IKE responder is under attack
via IP fragmentation (no matter which - poisoning attack or memory
exhausting attack). In any case responder will not be able to reply.
After some (short) timeout initiator will try to apply IKE Fragmentation.
Then, if those new messages ar
Lou,
Thanks, again answer inline :-).
Mike.
Mike Sullenberger, DSE
m...@cisco.com .:|:.:|:.
Customer Advocacy CISCO
> -Original Message-
> From: Lou Berger [mailto:lber...@labn.net]
> Sent: Thursday, October 24, 2013 8:57 AM
> To: Mike Sullenberger (mls)
> Cc: IPs
On 10/27/2013 10:41 PM, Valery Smyslov wrote:
Always setting DF bit in this case will probably increase the delay
before IKE SA is set up (as more probes will need to be done).
Except that if you continue to allow IP fragmentation, you can't claim
your solution is robust to IP fragment poison
On 10/27/2013 11:20 PM, Yoav Nir wrote:
I guess the idea is that if the packet is still bigger than the PMTU,
then the IKE host gets back a "fragmentation needed" ICMP, and the IKE
daemon learns of that and resends packets with appropriately small size.
There are some issues with this:
You p
OK, you convinced me. 576 is the right value to recommend for initiator. Not
sure if for responder it's also preferable to use 576, or to go with the idea
in 2.5.1 of using the fragment size from the request.
Yoav
-Original Message-
From: Tero Kivinen [mailto:kivi...@iki.fi]
Sent: Mond
Yoav Nir writes:
> 3. While the TCP stack has access to these ICMP packets and the
> PMTU that they convey, a userspace IKE daemon usually doesn't. See
> [1] for how people suggest doing it in C#.
Actually for example our code tries to get ICMP messages for IKE
packets, mostly so that we can ma
I have reviewed this draft again.
I tihnk we should add bit more in to the introduction. I.e explain the
common case for this protocol is to fragment exactly ONE message pair
(IKE_AUTH), and those messages are most commonly around 500-3000 bytes
long.
For example to do proper PMTU for sending exa
Pekka Riikonen writes:
>
> The ASN.1 used here are the same ASN.1 which is used in the
> AlgorithmIdentifier of the PKIX (Section 4.1.1.2 of [RFC5280]). The
>
> It should specify encoding rules, even though it references RFC5280. So
> this could say something like:
>
> The ASN.1 u
Valery Smyslov writes:
> > And you can always retry when you notice that you get authentication
> > error after using private key, provided you have multiple types of
> > keys.
>
> In general you can't if it is responder who selected wrong key.
That is something I realized on our way home, but i
10 matches
Mail list logo
