Matthew Grooms wrote:
> I have a few quick questions about inter-operating with racoons IKE
> fragmentation option. First of all, does anyone know of an paper that
> describes this as a draft or a standard? I can't seem to google it.
> Anyhow, when racoon uses a Fragmentation vendor id that includes
> the 4 byte capabilities value appended, I get this in the log output ...
> received broken Microsoft ID: FRAGMENTATION
> ... and racoon _will_ perform fragmentation.
> But when only the vendor hash itself is received without the capability
> value, I get this in the log output ...
> received Vendor ID: FRAGMENTATION
> ... and racoon _will_not_ perform fragmentation nor will it reply with a
> "FRAGMENTATION" vendor id of its own.
> The first log message looks a lot more like an error to me than the
> second one does. Is this the desired effect? Should fragmentation work
> in both cases? Is there a non "broken-microsoft-id" method to coax
> racoon into performing ike fragmentation? Is this just really confusing
> log output?
> Thanks in advance,
I have other questions/comments to add to the mix. When reviewing
the fragmentation code logic, I am a bit confused how it is intended to
operate with respect the the man page.
ike_frag (on | off);
Enable receiver-side IKE fragmentation, if racoon(8) has
been built with this feature. This extension is there to
work around broken firewalls that do not work with frag-
mented UDP packets. IKE fragmentation is always enabled
on the sender-side, and it is used if the peer advertises
itself as IKE fragmentation capable.
I assume, that receiver side means that you are the entity that is
receiving the isakmp packet ( not necessarily the responder ). But the
two variables used to control the use of fragmentation and the way they
are being manipulated does not make sense to me.
For example, it looks like the rmconf->ike_frag variable is set to 1
only if the "ike_frag = on" is present in the racoon.conf file. But this
variable is only checked before sending a fragment vendor id when acting
as an initiator. So the "ike_frag = on" in the racoon.conf file really
determines whether or not fragmentation will be negotiated. If racoon is
acting as an initiator and the vendor id is omitted, the responder would
interpret this as unsupported. The other variable iph1->frag is always
initialized to 0 and then set to 1 when the fragmentation vendor id
payload is seen ( + capabilities, see previous post above ) from the
remote peer. This matches the man page and makes sense since it only
seems to control whether or not a packet may be fragmented in the send path.
Also, the "ike_frag = on" is stated as controlling "receiver side
ike-fragmentation". Any packet ( except the first, see below ) that has
the first payload marked as a fragment is passed from isakmp_main to
frag_handler to rebuild a complete packet and then back to isakmp_main.
But the rmconf->ike_frag variable is not referenced anywhere in this
receive path that I can see.
Maybe this is just an out of date man page, but there seems to be a bug
as well. When a remote initiator fragments the first packet in an
exchange, racoon will never be able to handle a fragmented payload
because isakmp_main calls isakmp_ph1begin_r before the ike message can
be reassembled by frag_handler. For main mode this is not that big of a
deal unless the initiator has an ungodly amount of sa + proposal +
transforms in its initial packet. But for aggressive mode, the only
packet that an initiator would likely need to fragment is the first one.
Racoon logs this debug info in its logfile ...
2006-03-13 16:21:10: INFO: respond new phase 1 negotiation:
2006-03-13 16:21:10: INFO: begin Aggressive mode.
2006-03-13 16:21:10: DEBUG: begin.
2006-03-13 16:21:10: DEBUG: seen nptype=132(ike frag)
2006-03-13 16:21:10: DEBUG: succeed.
2006-03-13 16:21:10: ERROR: received invalid next payload type 132,
2006-03-13 16:21:10: ERROR: failed to process packet.
All this is in reference to the CVS branch. If someone can clarify the
intended behavior for me, I can try to come up with a patch to correct
any of the issues I raised that are deemed 'actual bugs'.