MTU on PE and CE router

If the PE MTU is set on the main interface, but not the sub-interface, do we match the CE’s MTU to that of the PE’s main interface OR leave the CE un-configured/defaulted?

Example:

SiteCstNum1#show configuration | begin GigabitEthernet2/1/0
interface GigabitEthernet2/1/0
description **NNI** SiteCstNum1 to SiteCstNum8 1.8.2.1 via CPA BW: 1000000 CKT: CKTNUMBER01 ###
mtu 2048 <--- MTU set on main interface
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
load-interval 30
carrier-delay msec 120
no negotiation auto
!
interface GigabitEthernet2/1/0.19
description GigabitEthernet2/1/0.19 Ethernet VLAN-Id=19 : Provisioned By SYSTEM-IP: Service Request Id# = IDNUMBER1 (SiteCstNum1_CKTNUMBER1-VPN1) No MTU set on sub-int – do we match CE with main int, or leave CE defaulted?
encapsulation dot1Q 19
ip vrf forwarding VRF:VPNName1
ip address 252.277.46.53 255.255.255.252
ip access-group 101 in
no ip redirects
no ip proxy-arp
no snmp trap link-status
service-policy input DSCP_CE2PE_ETM_G=8000
service-policy output DSCP_PE2CE_940K_6Q
!
interface GigabitEthernet2/1/0.31
description GigabitEthernet2/1/0.31 Ethernet VLAN-Id=31 : Provisioned By SYSTEM-IP: Service Request Id# = IDNUMBER2 (SiteCstNum2_CKTNUMBER2-VPN1)
encapsulation dot1Q 31
ip vrf forwarding VRF:VPNName2
ip address 160.152.255.225 255.255.255.252
ip access-group 101 in
no ip redirects
no ip proxy-arp
ip mtu 1500
no snmp trap link-status
service-policy input DSCP_CE2PE_ETM_G=1024000
service-policy output DSCP_PE2CE_C1_17000K_6Q
!
interface GigabitEthernet2/1/0.103
description GigabitEthernet2/1/0.103 Ethernet VLAN-Id=103 : Provisioned By SYSTEM-IP: Service Request Id# = IDNUMBER3 (SiteCstNum3_CKTNUMBER3-VPN1)
encapsulation dot1Q 103
ip vrf forwarding VRF:VPNName3
ip address 252.73.78.33 255.255.255.252
ip access-group 101 in
no ip redirects
no ip proxy-arp
ip mtu 1500
no snmp trap link-status
service-policy input DSCP_CE2PE_ETM_G=8000
service-policy output DSCP_PE2CE_1880K_6Q
!

Since the logical interfaces/sub-interfaces take on the physical interface's properties, we'd be matching with the physical interface for the CE interface MTU setting.

Note: The IP's are fictitious. No proprietary information leaked out or any customer-owned router was harmed.

Bufferoverruns: Just some high-level ramblings on it

While working for TrendMicro, I came across a book in the sleeping quarters (hahahahahahahahahahahahahaaha!!!!), and I think now I know why the books were placed there. Heck, this brings back memories.

Anyway, I loved reading that book. It was also some sort of bible for me.

I really liked how the author discussed on buffer overruns. From then on, I discussed overruns or overflows to peers with so much passion!

[Stack Overruns: http://en.wikipedia.org/wiki/Stack_buffer_overflow]
This seems to eb the contemporary overflow we know - putting in too much into the memory stack that's meant to be the data input of the program but declared to handle only a certain amount.

How does this exploit work? Easy, programmers noticed that even though their executables were experiencing a "The instruction at 0x54545454 referrenced memory at 0x54545454. The memory could not be read." problem, playing around with the input gives you this idea that you can have the system jump to a certain memory location and execute the code in there by knowing exactly what type of input to feed the program to jump to the location.

Brilliant, eh?! Wow! Just amazing!

Check this out: http://www.securityfocus.com/advisories/4254

That's just a one-byte exploit! As Wikipedia explains (http://en.wikipedia.org/wiki/Off-by-one_error), this happens when you iterate and the programmer is not aware of the starting points - you go off by one more or one less. Look up the Fenceport error example. It's really good!

Well, remember this one as well: memory is generally partitioned into 2 parts, namely, the Executable and Non-executable parts. Most exploits try to run the code found under the Non-executable part that they got into your system. Most systems right now have this distinction between what's executable and non-executable.

How? It's a different topic!

[Heap Overruns: www.w00w00.org/files/articles/heaptut.txt]
Heap data is like a linked-list data, allocated during the start of the program; which some refer as dynamic malloc. Heap overruns are like Stack overruns, just that the malloc isn't static.

Making use of heaps to store data may lead you to say that a Heap overrun is not posible as memory is dynamically allocated. Imagine a program that goes bonkers and you used heap malloc instead of static. The problem first start with you just accepting the fact that heap overruns aren't really a big deal. A malicious programmer could get debugger and try to trace problems with the program. He'll get to the root cause with a little persistence - say the first or second arguement on the code you made has problems when the input is just too big for it. He'll eventually find the problem with the heap. If he gets to know the location of the buffer that caused the problem he can pass in any value and it'll get written to any point in the process space of the application of his choosing - the goal is to get a malicious code to be executed by that exploited program. Please refer here: www.blackhat.com/presentations/win-usa-02/halvarflake-winsec02.ppt.

Check these out ,too:
http://www.infosecwriters.com/texts.php?op=display&id=134

There are toher coding problems leading to a buffer overrun like Array indexing errors, Format string bugs, and Unicode and ANSI buffer size mismatches.

[How to basically safe-guard from a buffer overrun?]
Write solid code! Or maybe invent HeapGuard. ^___^