[Oisf-users] UDP reassambly behaviour

[Michel SABORDE]

I'll share a pcap later in the day.
But to clarify my request, i'm not talking about IP fragments, i'm talking
about UDP datagrams not being reassamble.
If you receive consecutively 2 UDP datagrams from the same quadruplet (ip
dest / ip source / port dest / port source ), you can usually consider
them part of the same UDP "session" (even though it's weird to talk about
"session" with UDP), it is what happen when you put an UDP socket in
connected mode.

I hope it makes more sense now :)

Michel
2012/6/20 Victor Julien <victor at inliniac.net>

> On 06/18/2012 11:14 AM, Michel SABORDE wrote:
> > Hi everyone,
> >
> > I set up an alert on UDP to match content:"bad.html"; as i did before
> > with TCP and i discovered a strange behaviour that may be normal ...
> > I send all my datagrams from the same ip dest/ip source/port dest/port
> > source.
> > If one datagram contains the payload "bad.html" the alert will be
> > triggered but if you send two datagrams in a row which contains "bad."
> > and "html", no alert will  be triggered because i think, correct me if
> > i'm wrong, that Suricata does not reassemble UDP datagrams.
> > I know that UDP datagrams may not be received, or may be received in a
> > different order but i think that it would be a nice feature anyway.
> > I tried Snort and it does that kind of datagrams reassambly.
>
> Our IP defragmentation is done on the IP packet level, so irregardless
> of what protocol is used. Can you share a pcap?
>
> --
> ---------------------------------------------
> Victor Julien
> http://www.inliniac.net/
> PGP: http://www.inliniac.net/victorjulien.asc
> ---------------------------------------------
>
> _______________________________________________
> Oisf-users mailing list
> Oisf-users at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20120620/60f88520/attachment-0002.html>