2011年12月27日 星期二

Telecom ETF

Telecom ETFs: The Telecommunications Sector Rides The Internet Wave (NYSE:IYZ, NYSE:VOX, NYSE:XTL, NYSE:IXP, NYSE:TTH, NYSE:WMH, NYSE:IST, NYSE:FCQ) | ETF DAILY NEWS

  • iShares DJ U.S. Telecommunications (NYSE:IYZ) is the largest telecom ETF and probably the most well-known.
  • Vanguard Telecommunications Services (NYSE:VOX) is my current favorite for this sector. VOX has broad coverage and is also the lowest-cost telecom ETF.
  • SPDR S&P Telecom (NYSE:XTL) is fairly new, launched only in January 2011. XTL is the only ETF from this sector that doesn’t use a traditional capitalization-weighted strategy. Instead, it is equal-weighted, giving more exposure to some of the smaller telecom stocks.
  • iShares S&P Global Telecommunications (NYSE:IXP) is a good solution if you want telecom exposure covering the entire globe, including the U.S.

ETF Watch: Does Value Exist in Telecom ETFs? (IYZ, VOX, IXP, TTH) - 24/7 Wall St.

Telecom ETF | IYZ, VOX, PRFQ, PTE, IXP, DGG | ETF MarketPro

Will Tax Hikes Slam Telecom ETFs? (IYZ, VOX, PTE) | ETF DAILY NEWS

2011年12月26日 星期一

Disease equilibration

綠角財經筆記: A Splendid Exchange讀後感---貿易黑死病


這個過程叫Disease equilibration。




作者以澳洲在1950年人為引進Myxoma Virus撲殺野兔的例子。當時是立竿見影,兔子死亡率高達99%以上。但到了1957年,致死率剩25%。

這個Disease equilibration的過程,約需要5-6代的時間。兔子一代較短,人的生命週期較長,5到6代約需要100到150年的時間。

當舊世界的人們,歷經傳染病的摧殘,終於完成Disease equilibration後。歐洲人對疾病的耐受力,是比槍炮更有威力的爭戰工具。與其接觸的美洲原住民,因為沒有抵抗力,死傷枕藉。


Required to build from git
apt-get install git gcc automake autoconf libtool pkg-config gettext perl python flex bison gperf lcov doxygen
git clean -xfd; ./autogen.sh;

sudo echo ;./configure --prefix=/ && make && sudo make install

strongSwan - IPsec for Linux

IKEv2 Cipher Suites

strongSwan - UML Testing

strongSwan - UML Readme

1. Starting up the UML testing environment
2. Running the automated tests
3. Manual testing

strongSwan - Documentation

strongSwan - InstallationDocumentation

strongSwan - UML Testresults for strongSwan 4.x
(A LOT OF configuration samples)
Test ikev1/esp-alg-aes-gcm
Test ikev1/net2net-psk

strongSwan - KernelModules

strongSwan 5: How to create your own private VPN | Zeitgeist

IpsecStandards - strongSwan

IPSec key management utilities that support AES-GCM

strongSwan: Yes
strongSwan - IKEv2CipherSuites - strongSwan - IKEv2/IPsec VPN for Linux, Android, FreeBSD, Mac OS X

Openswan: Yes?
[Openswan dev] Does OpenSwan support AES-GCM and AES-GMAC???
(AES GCM or CCM???)

[Openswan Users] AES GCM 256

racoon2: No
I cannot found any string "gcm" definition in the latest code (racoon2-20100526a).
Re: AES CTR, CCM, GCM in IPSec with KINK

ipsec-tools/racoon: No
'Re: [Ipsec-tools-devel] Does Linux support AES-GCM and AES-GMAC???' - MARC

ESP_Preferences - The Wireshark Wiki

ESP_Preferences - The Wireshark Wiki
RFC4106: The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)

2011年12月25日 星期日

Full tunnel vs split tunnel

Full VPN Tunnel

Split tunnel setup
As shown in the figure below, the split tunnel is used where application data travels over the VPN tunnel setup to the HQ.

In this mode, the desktop has direct access to the Internet. In a small store setup, while the split tunnel provides application access over VPN tunnel, Internet access is not controlled. The only solution here is to add additional software components or an external firewall to limit access.

To overcome this problem, the full tunnel mode is used.

Full tunnel setup
In the full tunnel mode, the Secure VPN client configuration and setup is the same as before, but with one key change: all traffic from the desktop goes over the VPN tunnel.

In the full tunnel mode, since all traffic goes over the VPN tunnel, both application data and Internet access packets land up at the VPN concentrator at the HQ.

2011年12月20日 星期二

netcat (nc)

nc -s -p 2000 -l
nc -s 2000


5.5.3 任意啟動 TCP/UDP 封包的埠口連線: nc, netcat



-i interface: interface to listen on.
-n: disable name lookups.
-t: don't print timestamps.
-s0 (or -s 0): use the max "snaplen"—capture full packets (default in recent versions of tcpdump).
-xx: dump data and link-layer header in hex
-XX: dump data and link-layer header in hex+ascii
-vvv: more verbose.

Filter Expression
port 25 and not host
icmp or arp or udp
vlan 3 and ether src host aa:bb:cc:dd:ee:ff
arp or udp port 53
icmp and \(dst host mrorange or dst host mrbrown\)

tcpdump fu | Linux Journal

Aloe Blacc - I Need A Dollar

Aloe Blacc - I Need A Dollar

I need a dollar dollar, a dollar is what I need
hey hey
Well I need a dollar dollar, a dollar is what I need
hey hey
And I said I need dollar dollar, a dollar is what I need
And if I share with you my story would you share your dollar with me

Bad times are comin and I reap what I don't sow
hey hey
Well let me tell you somthin all that glitters ain't gold
hey hey
It's been a long old trouble long old troublesome road
And I'm looking for somebody come and help me carry this load

I need a dollar dollar, a dollar is what I need
hey hey
Well I need a dollar dollar, a dollar is what I need
Well I don't know if I'm walking on solid ground
Cause everything around me is falling down
And all I want - is for someone - to help me

I had a job but the boss man let me go
He said
I'm sorry but I won't be needing your help no more
I said
Please mister boss man I need this job more than you know
But he gave me my last paycheck and he sent me on out the door

Well I need a dollar dollar, a dollar is what I need
hey hey
Said I need a dollar dollar, a dollar is what I need
hey hey
And I need a dollar dollar, a dollar is what I need
And if I share with you my story would you share your dollar with me
Well i don't know if i'm walking on solid ground
Cause everything around me is crumbling down
And all I want is for someone to help me

What in the world am I gonna to do tomorrow
is there someone whose dollar that I can borrow
Who can help me take away my sorrow
Maybe its inside the bottle
Maybe its inside the bottle
I had some good old buddy his names is whiskey and wine
hey hey
And for my good old buddy i spent my last dime
hey hey
My wine is good to me it helps me pass the time
and my good old buddy whiskey keeps me warmer than the sunshine
Hey Hey
Your mama may have, bless the child that's got his own
Hey Hey
if god has plans for me i hope it aint - written in stone
Hey Hey
because i've been working working myself down to the bone
and i swear on grandpas grave I'll be paid when i come home
Hey Hey

Well I need a dollar dollar, a dollar is what I need
hey hey
Said need a dollar dollar, a dollar is what I need
hey hey
Well I need a dollar dollar, a dollar is what I need hey hey
And if I share with you my story would you share your dollar with me
come on share your dollar with me
go ahead share your dollar with me
come on share your dollar give me your dollar
share your dollar with me
come on share your dollar with me

2011年12月19日 星期一

"badges" of achievement for electronics, science and engineering

Iron on Patches : Adafruit Industries, Unique & fun DIY electronics and kits

Magic Blue Smoke Monster - Skill badge, iron-on patch

"Failure is only the opportunity to begin again more intelligently" - Henry Ford

Sometimes you need celebrate mistakes. Adafruit offers a fun and exciting "badges" of achievement for electronics, science and engineering. We believe everyone should be able to be rewarded for learning a useful skill, a badge is just one of the many ways to show and share.

This is the "I learned something, the magic blue smoke monster showed me" badge for use at classrooms, workshops, Maker Faires, TechShops and around the world to reward beginners on their skill building journey!

This beautiful badge is made in the USA.

The badge is skillfully designed and sturdily made to last a life time, the backing is iron-on but the badge can also be sewn on.

Magic smoke - Wikipedia, the free encyclopedia. http://www.blogger.com/img/blank.gif
Magic smoke (also called factory smoke or blue smoke) is smoke produced by malfunctioning electronic circuits. The origins of the magic smoke have become a running in-joke that started among electrical engineers and technicians before it was more recently adopted by computer programmers. The actual origin of blue smoke is the black plastic epoxy material that is used to package most common semiconductor devices such as transistors and integrated circuits, which produces a bluish coloured smoke during combustion. Smoke from other components that do not use this epoxy may vary in colour, but still be identified as the same phenomenon for purposes of the joke.

2011年12月16日 星期五

Aloe Blacc - Green Lights (Official Video HD) - YouTube

Aloe Blacc - Green Lights (Official Video HD) - YouTube

Something special happened today
I got green lights all the way
With no big red sign to stop me
No traffic jam delay

See I was driving over the moon
In my big hot air balloon
Floating high up into the darkness
I hope I'll get there soon

There's so many things to do
So many people I need to talk to
And they've all been waiting for me
Well I got to make it through

Something special happened today
I got green lights all the way
With no big red sign to stop me
No traffic jam delay

Think my stars will rather be green
You have no idea what it means
But to a man who's always traveling
Who's seen the things that I've seen

I don't know what's yet to come
Not sure of anything that I've done
Really makes that much of a difference
Well I hope it has for some

Something special happened today
I got Green lights all the way
With no big red sign to stop me
No traffic jam delay

Well I was driving over the moon
In my big hot air balloon
Floating high up in the darkness
I promise that I'll make it to you very soon

Something special happened today

Linux XFRM and IPSec


IPsec overview | The Linux Foundation

Adding policies and states from user space:
Handling addition of policies is done by:
xfrm_add_policy() ( net/xfrm/xfrm_user.c)
Handling addition of statees is done by:
xfrm_add_sa() ( net/xfrm/xfrm_user.c)
Handling creation of spi (using randomness) is done by
xfrm_alloc_userspi() ( net/xfrm/xfrm_user.c)
xfrm_lookup() invocation:

Linux Kernel Security Overview

Linux Kernel Networking
network_overview | The Linux Foundation

Research on IPSec VPN Under Framework of XFRM Based on Linux
xfrm_policy{}表示IPSec SP,xfrm_state{}表示IPSec SA ;xfrm_state{}通过xfrm_templ{}和xfrm_ policy{}关联;SPD由xfrm_policy{}结构链组成,SAD由xfrm_state{}结构链组成。

Does Linux support AES-GCM and AES-GMAC???
- To IPsec SA identifier, RFC 4106 says:
8.3. Phase 2 Identifier

For IKE Phase 2 negotiations, IANA has assigned three ESP Transform
Identifiers for AES-GCM with an eight-byte explicit IV:

18 for AES-GCM with an 8 octet ICV;
19 for AES-GCM with a 12 octet ICV; and
20 for AES-GCM with a 16 octet ICV.

- To PF_KEY cipher type:

Linux pfkeyv2 seems to have:
#define SADB_X_EALG_AES_GCM_ICV12 19
#define SADB_X_EALG_AES_GCM_ICV16 20

2011年12月13日 星期二

Finding what branch/tag a commit came from

git branch --contains <CommitID>
git tag --contains <CommitID>

$ git branch --contains 3f80fbff5f1
* master
$ git tag --contains 3f80fbff5f1

grit - Git: Finding what branch a commit came from - Stack Overflow

2011年12月12日 星期一

BASH: How do I clear Bash's cache of paths to executables?

BASH cached the searched path of the executables??!! , WTF....

# xxx.sh
xxx.sh: command not found
# touch /bin/xxx.sh
# chmod +x /bin/xxx.sh
# xxx.sh
# rm /bin/xxx.sh
# xxx.sh
bash: /bin/xxx.sh: No such file or directory

How do I clear Bash's cache of paths to executables?
bash does cache the full path to a command.
To clear the entire cache:
hash -r
Or just one entry:
hash -d svnsync
More info in help hash and man bash .

2011年12月7日 星期三


[wiki] NAT traversal and IPsec

[wiki] NAT-T

NAT-T (NAT traversal in the IKE) is a method of enabling IPsec-protected IP datagrams to pass through network address translation (NAT). RFC 3947 defines the negotiation during the Internet key exchange (IKE) phase and RFC 3948 defines the UDP encapsulation.

An IP packet is modified while passing through a network address translator device in a manner that is incompatible with Internet Protocol Security (IPsec). NAT-T protects the original IPsec encoded packet by encapsulating it with another layer of UDP and IP headers.

How Does NAT-T work with IPSec?

RFC3947: Negotiation of NAT-Traversal in the IKE
(It seems NATT "MUST" use UDP dport 4500)
(Both data and IKE message after first Phase 1 negotiation could use UDP dport 4500)
3. Phase 1
The detection of support for NAT-Traversal and detection of NAT along the path between the two IKE peers occurs in IKE [RFC2409] Phase 1.

3.1. Detecting Support of NAT-Traversal
3.2. Detecting the Presence of NAT

4. Changing to New Ports
In Main Mode, the initiator MUST change ports when sending the ID payload if there is NAT between the hosts. The initiator MUST set both UDP source and destination ports to 4500. All subsequent packets sent to this peer (including informational notifications) MUST be sent on port 4500. In addition, the IKE data MUST be prepended with a non-ESP marker allowing for demultiplexing of traffic, as defined in [RFC3948].

Thus, the IKE packet now looks like this:

IP UDP(4500,4500) <non-ESP marker> HDR*, IDii, [CERT, ] SIG_I

This assumes authentication using signatures. The 4 bytes of non-ESP marker are defined in the [RFC3948].


The responder MUST respond with all subsequent IKE packets to this peer by using UDP(4500,Y).

Similarly, if the responder has to rekey the Phase 1 SA, then the rekey negotiation MUST be started by using UDP(4500,Y). Any implementation that supports NAT traversal MUST support negotiations that begin on port 4500. If a negotiation starts on port 4500, then it doesn't need to change anywhere else in the exchange.

RFC3948: UDP Encapsulation of IPsec ESP Packets
2.1. UDP-Encapsulated ESP Header Format
The UDP header is a standard [RFC0768] header, where
o the Source Port and Destination Port MUST be the same as that used by IKE traffic,
o the IPv4 UDP Checksum SHOULD be transmitted as a zero value, and
o receivers MUST NOT depend on the UDP checksum being a zero value.

The SPI field in the ESP header MUST NOT be a zero value.

2.2. IKE Header Format for Port 4500
The UDP header is a standard [RFC0768] header and is used as defined in [RFC3947]. This document does not set any new requirements for the checksum handling of an IKE packet.

A Non-ESP Marker is 4 zero-valued bytes aligning with the SPI field of an ESP packet.

IPsec and NAT Traversal - System Administration Guide: IP Services

Linux Kernel 2.6 using KAME-tools -- NAT-Traversal

Openswan / NATTraversal

2011年12月6日 星期二

SA bundle

RFC 2401: Security Architecture for the Internet Protocol

4.3 Combining Security Associations

The IP datagrams transmitted over an individual SA are afforded protection by exactly one security protocol, either AH or ESP, but not both. Sometimes a security policy may call for a combination of services for a particular traffic flow that is not achievable with a single SA. In such instances it will be necessary to employ multiple SAs to implement the required security policy. The term "security association bundle" or "SA bundle" is applied to a sequence of SAs through which traffic must be processed to satisfy a security policy. The order of the sequence is defined by the policy. (Note that the SAs that comprise a bundle may terminate at different endpoints. For example, one SA may extend between a mobile host and a security gateway and a second, nested SA may extend to a host behind the gateway.)

Security associations may be combined into bundles in two ways: transport adjacency and iterated tunneling.
  • Transport adjacency refers to applying more than one security protocol to the same IP datagram, without invoking tunneling. This approach to combining AH and ESP allows for only one level of combination; further nesting yields no added benefit (assuming use of adequately strong algorithms in each protocol) since the processing is performed at one IPsec instance at the (ultimate) destination.
  • Iterated tunneling refers to the application of multiple layers of security protocols effected through IP tunneling. This approach allows for multiple levels of nesting, since each tunnel can originate or terminate at a different IPsec site along the path. No special treatment is expected for ISAKMP traffic at intermediate security gateways other than what can be specified through appropriate SPD entries (See Case 3 in Section 4.5)
There are 3 basic cases of iterated tunneling -- support is required only for cases 2 and 3.:
  1. both endpoints for the SAs are the same -- The inner and outer tunnels could each be either AH or ESP, though it is unlikely that Host 1 would specify both to be the same, i.e., AH inside of AH or ESP inside of ESP.
  2. one endpoint of the SAs is the same -- The inner and uter tunnels could each be either AH or ESP.
  3. neither endpoint is the same -- The inner and outer tunnels could each be either AH or ESP.

Data networks: routing, security ... - Tony Kenyon - Google Books

Section 10.5. Combining Security Associations

22.4.4 Combining IPSec protocols

Question on SA Bundle
Note that, SPD defines the security protocols such as ESP, AH. In a given SPD policy, you can have both ESP and AH together. This results into two SAs. Typically, IPSEC informs IKE to get the keys for both of them together. once IKE gets the keys, it can inform IPSEC packet processing to create the SA bundle with two SAs.

Since, IKE negotiates both together, if one SA life time expires, other SAs in the SA Bundle can be removed. That means either all SAs in the SA bundle exist or none exist

When writing 2401 we thought it might be possible to provide the ability to link together a number of SAs into a bundle, similar to what you describe in #1 above. However, in reality, IKE v1 was not able to negotiate a general notion of bundling, specifically a way to link new SAs to existing SAs. Thus, in practice the only bundles that occur arise when one negotiates both AH and ESP in a single IKE negotiaiton.

As we revise 2401, I anticipate clarifying this, and essentially doing away with the notion of bundles. I have not see a strong need for them in list discussions, nor does IKE v2 have support for adding SAs to a bundle.

Bundle is just a set of IPSEC transformations (and SA's) that are specified to be applied to a packet that maches a particular selector. The same component SA can be used in different "bundles".

That's about all that "bundle" means to me. Unfortunately, IKEv1 thinks/requires more strict "bundle" concept. It cannot negotiate individual SA's belonging to same "bundle" separately, or share SA's between bundles.

Key management should negotiate SA's individually.
(which means Key management SA bundle at once)

interpretation of SA bundle.
(I'm somehow confused by this thread)
> Do you say that each attributes of multiple proposal with same number
> MUST have same transport mode ?

The encapsulation is applied to the SAs as a whole. So, yes.

See section 2.1 of RFC 2408. Here's what you're doing when you have multiple proposal payloads with the same number in a single SA payload:
Protection Suite: A protection suite is a list of the security services that must be applied by various security protocols. For example, a protection suite may consist of DES encryption in IP ESP, and keyed MD5 in IP AH. All of the protections in a suite must be treated as a single unit. This is necessary because security services in different security protocols can have subtle interactions, and the effects of a suite must be analyzed and verified as a whole.

"All of the protections in a suite must be treated as a single unit."

In other words, the group of SAs that make up the suite live and die as a unit, and have encapsulation applied as a single logical unit.

2011年12月5日 星期一

Network Information System (NIS/YP)

Network Information System (NIS/YP)

[Chapter 19] 19.4 Sun's Network Information Service (NIS)

火箭爐(Rocket Stove)

省能火箭爐 搞定 環保野炊


高效柴爐DIY - 101跑步農莊! - Yahoo!奇摩部落格



自然谷環境教育基地 -- 荒野保護協會環境信託: 節能減碳 -- 火箭爐



無煙無燻更節能火箭爐-綺文與吉仁二代火箭爐 @ 自給自足 永續生活 :: 痞客邦 PIXNET ::

IP Payload Compression Protocol (IPComp)


RFC 3173: IP Payload Compression Protocol (IPComp)

[wiki] IP Payload Compression Protocol

In networking IP Payload Compression Protocol, or IPComp, is a low level compression protocol for IP datagrams defined in RFC 3173.[1] The intent is to reduce the size of data transmitted over congested or slow network connections, thereby increasing the speed of such networks without losing data. According to the RFC requirements, compression must be done before fragmenting or encrypting the packet. It further states that each datagram must be compressed independently so it can be decompressed even if received out of order. This is important because it allows IPComp to work with both TCP and UDP network communications.


AES-GCM (crypto+auth)

[wiki] Galois/Counter Mode

a mode of operation for symmetric key cryptographic block ciphers that has been widely adopted because of its efficiency and performance. GCM throughput rates for state of the art, high speed communication channels can be achieved with reasonable hardware resources [1]. It is an authenticated encryption algorithm designed to provide both data authenticity (integrity) and confidentiality. GCM mode is defined for block ciphers with a block size of 128 bits. GMAC is an authentication-only variant of the GCM which can be used as an incremental message authentication code. Both GCM and GMAC can accept initialization vectors of arbitrary length.

AES-GCM (Galois Counter Mode) core for FPGA (Xilinx, Altera, Actel) and ASIC - Helion Technology
AES-GCM is an authenticated encryption algorithm designed to provide both authentication and privacy. Developed by David A McGrew and John Viega, it uses universal hashing over a binary Galois field to provide authenticated encryption.

GCM was designed originally as a way of supporting very high data rates, since it can take advantage of pipelining and parallel processing techniques to bypass the normal limits imposed by feedback MAC algorithms. This allows authenticated encryption at data rates of many tens of Gbps, permitting high grade encryption and authentication on systems which previously could not be fully protected. More recently GCM is being specified for use in lower rate applications due to its ease of use and scalability.

AES-GCM is specified for use in a number of recent standards; for example it is one of the options specified by the IEEE 1619 group for securing data-at-rest stored on tape media. In networking, it is the security algorithm specified for use in MACsec (802.1AE), and in the ANSI Fibre Channel Security Protocols (FC-SP).

AES-GCM Functions
The Galois/Counter Mode (GCM) is a mode of operation of the AES algorithm. GCM [NIST SP 800-38D] uses a variation of the Counter mode of operation for encryption. GCM assures authenticity of the confidential data (of up to about 64 GB per invocation) using a universal hash function defined over a binary finite field (the Galois field).

GCM can also provide authentication assurance for additional data (of practically unlimited length per invocation) that is not encrypted. If the GCM input contains only data that is not to be encrypted, the resulting specialization of GCM, called GMAC, is simply an authentication mode for the input data.

[wiki] Finite field (aka Galois field)

RFC 5288: AES-GCM Cipher suites
AES-GCM is an authenticated encryption with associated data (AEAD) cipher

The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)

AES-GMAC (auth)
Advanced Encryption Standard Galois Message Authentication Code (AES-GMAC)

RFC4543: The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH

Re: AES-GMAC as a hash

AES-XCBC, aka CBC-MAC (auth)
[wiki] CBC-MAC
cipher block chaining message authentication code (CBC-MAC), is a technique for constructing a message authentication code from a block cipher.

[wiki] CMAC
CMAC (Cipher-based MAC)[1] is a block cipher-based message authentication code algorithm.

The core of the CMAC algorithm is a variation of CBC-MAC that Black and Rogaway proposed and analyzed under the name XCBC[2] and submitted to NIST.[3] The XCBC algorithm efficiently addresses the security deficiencies of CBC-MAC, but requires three keys. Iwata and Kurosawa proposed an improvement of XCBC and named the resulting algorithm One-Key CBC-MAC (OMAC) in their papers.[4][5] They later submitted OMAC1[6], a refinement of OMAC, and additional security analysis.[7] The OMAC algorithm reduces the amount of key material required for XCBC. CMAC is equivalent to OMAC1.

RFC4434: The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)

RFC3566: The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec


Block ciphers (security summary)

Cryptographic hash functions and message authentication codes (MACs)

2011年12月4日 星期日

Traffic Flow Confidentiality (TFC)

Traffic Flow Confidentiality (TFC)
to hide/masquerade the traffic pattern to prevent statistical traffic analysis attacks.

RFC 4303 - IP Encapsulating Security Payload (ESP)

2.7. Traffic Flow Confidentiality (TFC) Padding
As noted above, the Padding field is limited to 255 bytes in length. This generally will not be adequate to hide traffic characteristics relative to traffic flow confidentiality requirements. An optional field, within the payload data, is provided specifically to address the TFC requirement.
An IPsec implementation SHOULD be capable of padding traffic by adding bytes after the end of the Payload Data, prior to the beginning of the Padding field. However, this padding (hereafter referred to as TFC padding) can be added only if the Payload Data field contains a specification of the length of the IP datagram. This is always true in tunnel mode, and may be true in transport mode depending on whether the next layer protocol (e.g., IP, UDP, ICMP) contains explicit length information. This length information will enable the receiver to discard the TFC padding, because the true length of the Payload Data will be known. (ESP trailer fields are located by counting back from the end of the ESP packet.) Accordingly, if TFC padding is added, the field containing the specification of the length of the IP datagram MUST NOT be modified to reflect this padding. No requirements for the value of this padding are established by this standard.

In principle, existing IPsec implementations could have made use of this capability previously, in a transparent fashion. However, because receivers may not have been prepared to deal with this padding, the SA management protocol MUST negotiate this service prior to a transmitter employing it, to ensure backward compatibility. Combined with the convention described in Section 2.6 above, about the use of protocol ID 59, an ESP implementation is capable of generating dummy and real packets that exhibit much greater length variability, in support of TFC.
Implementations SHOULD provide local management controls to enable the use of this capability on a per-SA basis. The controls should allow the user to specify if this feature is to be used and also provide parametric controls for the feature.

Re: ESP's use of dummy packets?

TfcProject – Discreet

pfkeyv2.h in tfcproject/trunk/ipsec-tools-0.6.6/src/include-glibc/net – Discreet

Traffic masking in IPsec: architecture and implementation

basic TFC mechanisms can be categorized as follows:
− Packet forming (padding, fragmentation, etc.);
− Packet timing (queuing and de-queuing);
− Dummy packet management (generation and discarding).

TFC Control Algorithms


the simplest and most straightforward algorithm consists in embedding the SA’s traffic in a CBR traffic pattern (with packets of constant size and a constant packet inter-arrival time). Such algorithm is ideal in the level of protection, it has a low complexity, but it also introduces serious performance drawbacks both in limiting the throughput and in filling the network with padding and dummy packets.

It is worth noting here that besides CBR, any traffic pattern that is independent of the original traffic flowing in the SA has the same properties. Algorithms can also generate traffic independent patterns using stochastic processes (modifying packet size, timing, or both). Other control algorithms are the adaptive ones, where the output pattern depends on properties of the original flow. Some examples are random size padding, random introduced delay, or a rate adaptive CBR.

Traffic Flow Confidentiality in IPsec: Protocol and Implementation
It can combine the TFC basic mechanisms arbitrarily:
CBR (Continuous Bit rate),
random padding,
random delay algorithms
Queue congestion Reactive algorithm (still experimental)

A User Space application allows to configure TFC SA parameters
Delay Algorithm
Packets Length
Bit Rate

ESP Traffic Flow Confidentiality
traffic-flow confidentiality (TFC)

2011年12月1日 星期四

GNU Debugger (GDB)

CROSS is the prefix of your cross-compiler, e.g. for mips64-linux-gnu-gcc, CROSS=mips64-linux-gnu
(Add the path to your cross-compiler to $PATH)


wget http://ftp.gnu.org/gnu/gdb/gdb-7.6.1.tar.bz2

tar xf gdb-7.6.1.tar.bz2
cd gdb-7.6.1/
mkdir build-mips
cd build-mips/

../configure --target=$(CROSS} --prefix=$(pwd)/install
make install

GDB: The GNU Project Debugger


Debugging with GDB (入門篇)


GDB Cheat Sheet - GDB Cheat Sheet.pdf

tools - How to handle stripped binaries with GDB? No source, no symbols and GDB only shows addresses? - Reverse Engineering Stack Exchange

gdb backtrace to file • Andreas Schneider
# alias bt='echo 0 | gdb -batch-silent -ex "run" -ex "set logging overwrite on" -ex "set logging file gdb.bt" -ex "set logging on" -ex "set pagination off" -ex "handle SIG33 pass nostop noprint" -ex "echo backtrace:\n" -ex "backtrace full" -ex "echo \n\nregisters:\n" -ex "info registers" -ex "echo \n\ncurrent instructions:\n" -ex "x/16i \$pc" -ex "echo \n\nthreads backtrace:\n" -ex "thread apply all backtrace" -ex "set logging off" -ex "quit" --args'

# bt $crashing_application
fcamel 技術隨手記: 用 python gdb 客製化 backtrace 的結果

GDB complaint "Error opening terminal: xterm." while using "-tui" or GDB command "layout"
export TERMINFO=/lib/terminfo
Question #207761 : Questions : GCC ARM Embedded