[TriLUG] spoofing mac addresses

[Aaron Joyner]

> Cisco lumps
> this into their "fix-up" options in some of their hardware for example.

That makes me think of their "fixup smtp" option in the PIX firewalls.  
Also known as "break esmtp", which virtually everything speaks these 
days.  So sad.

But on a lighter note, yeah Ryan is right.  It's a pain to work around 
these things, but the reason for them is often reasonable.  In the case 
of VOIP protocols, they're trading everything off in an attempt to 
reduce latency and overhead (since they're sending so many tiny 
packets, overhead is often 50-80% of the connection stream).  
Unfortunately, that doesn't necessarily behoove them in the long run.

Aaron J.

On Aug 12, 2004, at 2:42 PM, Ryan Leathers wrote:

> Well behaved protocols keep L3 info at L3 and L4 info at L4 and so on. 
>  Not
> so well behaved protocols don't share the same fidelity.  Session
> information in the payload rather than in the header is a tough bugger 
> when
> you toss NAT in the mix.  Ya it can be done, but its a pain.  Cisco 
> lumps
> this into their "fix-up" options in some of their hardware for example.
>
> -----Original Message-----
> From: Aaron Joyner [mailto:aaron at joyner.ws]
> Sent: Thursday, August 12, 2004 2:12 PM
> To: Triangle Linux Users Group discussion list
> Subject: Re: [TriLUG] spoofing mac addresses
>
>
> What precisely is the problem with NATing SIP connections?  Is it that
> SIP is port-less, some other protocol, not TCP? (gre perhaps?)  If
> that's the case, a kernel module akin to the ip_conntrack_ftp would be
> capable of handling the translations necessary (although different from
> what conntrack_ftp does, it could tie into the iptables implementation
> in a similar manner, I'd think).  I haven't really looked into this
> very thoroughly, but would be interested in knowing more about the
> limitations.  Perhaps we can brain-storm it at the meeting tonight if
> you're coming, Jon?
>
> Aaron J.
>
>
> On Aug 12, 2004, at 10:26 AM, Jon Carnes wrote:
>
>> On Thu, 2004-08-12 at 09:57, Reginald Reed wrote:
>>> Another way to do this is for your code to "be the IP stack" 
>>> bypassing
>>> the kernel IP stack altogether.  Using libnet and libpcap, you
>>> basically roll your own packets to send and anything received, you
>>> filter based on what you're looking for (combo of IP address and
>>> destination MAC, etc) and process accordingly.  This is pretty easy
>>> for UDP, TCP adds a few challenges.  My team his written several
>>> internal tools that use this method to scale traffic generation and
>>> network simulation stuff using Python (with wrapped libnet and 
>>> libpcap
>>> functions).
>>>
>>> --Reggie
>>
>> Interesting... This would give you the ability to write a Voice Proxy
>> Firewall for dealing with phones behind NAT'ed firewalls. The current
>> price for such software is $4k to $12k.
>>
>> It would be great to see an open source version of one of these (or a
>> cheaper version that ran on Linux).
>>
>> Jon Carnes
>>
>> -- 
>> TriLUG mailing list        :
>> http://www.trilug.org/mailman/listinfo/trilug
>> TriLUG Organizational FAQ  : http://trilug.org/faq/
>> TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
>> TriLUG PGP Keyring         : http://trilug.org/~chrish/trilug.asc
>
> -- 
> TriLUG mailing list        : 
> http://www.trilug.org/mailman/listinfo/trilug
> TriLUG Organizational FAQ  : http://trilug.org/faq/
> TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
> TriLUG PGP Keyring         : http://trilug.org/~chrish/trilug.asc
> -- 
> TriLUG mailing list        : 
> http://www.trilug.org/mailman/listinfo/trilug
> TriLUG Organizational FAQ  : http://trilug.org/faq/
> TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
> TriLUG PGP Keyring         : http://trilug.org/~chrish/trilug.asc