Reviewing IPv6

Latest RFC for IP Version 6 Addressing Architecture, RFC4291
Unique Local IPv6 Unicast Addresses, RFC4193
Neighbor Discovery, RFC4861 Stateless Address Autoconfiguration, RFC4862

Some useful addressing info to know.

2.4.  Address Type Identification

The type of an IPv6 address is identified by the high-order bits of
the address, as follows:

Address type         Binary prefix        IPv6 notation   Section
------------         -------------        -------------   -------
Unspecified          00...0  (128 bits)   ::/128          2.5.2
Loopback             00...1  (128 bits)   ::1/128         2.5.3
Multicast            11111111             FF00::/8        2.7
Link-Local unicast   1111111010           FE80::/10       2.5.6
Global Unicast       (everything else)

2.5.4.  Global Unicast Addresses

The general format for IPv6 Global Unicast addresses is as follows:

|         n bits         |   m bits  |       128-n-m bits         |
+------------------------+-----------+----------------------------+
| global routing prefix  | subnet ID |       interface ID         |
+------------------------+-----------+----------------------------+

2.5.5.  IPv6 Addresses with Embedded IPv4 Addresses

Two types of IPv6 addresses are defined that carry an IPv4 address in
the low-order 32 bits of the address.  These are the "IPv4-Compatible
IPv6 address" and the "IPv4-mapped IPv6 address".

2.5.5.1.  IPv4-Compatible IPv6 Address(deprecated)

The "IPv4-Compatible IPv6 address" was defined to assist in the IPv6
transition.  The format of the "IPv4-Compatible IPv6 address" is as
follows:

|                80 bits               | 16 |      32 bits        |
+--------------------------------------+--------------------------+
|0000..............................0000|0000|    IPv4 address     |
+--------------------------------------+----+---------------------+

2.5.5.2.  IPv4-Mapped IPv6 Address

A second type of IPv6 address that holds an embedded IPv4 address is
defined.  This address type is used to represent the addresses of
IPv4 nodes as IPv6 addresses.  The format of the "IPv4-mapped IPv6
address" is as follows:



|                80 bits               | 16 |      32 bits        |
+--------------------------------------+--------------------------+
|0000..............................0000|FFFF|    IPv4 address     |
+--------------------------------------+----+---------------------+

2.5.6.  Link-Local IPv6 Unicast Addresses

Link-Local addresses are for use on a single link.  Link-Local
addresses have the following format:

|   10     |
|  bits    |         54 bits         |          64 bits           |
+----------+-------------------------+----------------------------+
|1111111010|           0             |       interface ID         |
+----------+-------------------------+----------------------------+

2.5.7.  Site-Local IPv6 Unicast Addresses

Site-Local addresses were originally designed to be used for
addressing inside of a site without the need for a global prefix.
Site-local addresses are now deprecated as defined in [SLDEP].

Site-Local addresses have the following format:

|   10     |
|  bits    |         54 bits         |         64 bits            |
+----------+-------------------------+----------------------------+
|1111111011|        subnet ID        |       interface ID         |
+----------+-------------------------+----------------------------+

2.6.  Anycast Addresses

An IPv6 anycast address is an address that is assigned to more than
one interface (typically belonging to different nodes), with the
property that a packet sent to an anycast address is routed to the
"nearest" interface having that address, according to the routing
protocols' measure of distance.

2.7.  Multicast Addresses

An IPv6 multicast address is an identifier for a group of interfaces
(typically on different nodes).  An interface may belong to any
number of multicast groups.  Multicast addresses have the following
format:

|   8    |  4 |  4 |                  112 bits                   |
+------ -+----+----+---------------------------------------------+
|11111111|flgs|scop|                  group ID                   |
+--------+----+----+---------------------------------------------+

binary 11111111 at the start of the address identifies the address
as being a multicast address.

+-+-+-+-+
flgs is a set of 4 flags:     |0|R|P|T|
+-+-+-+-+

The high-order flag is reserved, and must be initialized to 0.

T = 0 indicates a permanently-assigned ("well-known") multicast
address, assigned by the Internet Assigned Numbers Authority
(IANA).

T = 1 indicates a non-permanently-assigned ("transient" or
"dynamically" assigned) multicast address.

The P flag's definition and usage can be found in [RFC3306].

The R flag's definition and usage can be found in [RFC3956].

scop is a 4-bit multicast scope value used to limit the scope of
the multicast group.  The values are as follows:

0  reserved
1  Interface-Local scope
2  Link-Local scope
3  reserved
4  Admin-Local scope
5  Site-Local scope
6  (unassigned)
7  (unassigned)
8  Organization-Local scope
9  (unassigned)
A  (unassigned)
B  (unassigned)
C  (unassigned)
D  (unassigned)
E  Global scope
F  reserved

Interface-Local scope spans only a single interface on a node
and is useful only for loopback transmission of multicast.

Link-Local multicast scope spans the same topological region as
the corresponding unicast scope.

Admin-Local scope is the smallest scope that must be
administratively configured, i.e., not automatically derived
from physical connectivity or other, non-multicast-related
configuration.

Site-Local scope is intended to span a single site.

Organization-Local scope is intended to span multiple sites
belonging to a single organization.

scopes labeled "(unassigned)" are available for administrators
to define additional multicast regions.

group ID identifies the multicast group, either permanent or
transient, within the given scope.  Additional definitions of the
multicast group ID field structure are provided in [RFC3306].

   The "meaning" of a permanently-assigned multicast address is
independent of the scope value.  For example, if the "NTP servers
group" is assigned a permanent multicast address with a group ID of
101 (hex), then

FF01:0:0:0:0:0:0:101 means all NTP servers on the same interface
(i.e., the same node) as the sender.

FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as the
sender.

FF05:0:0:0:0:0:0:101 means all NTP servers in the same site as the
sender.

FF0E:0:0:0:0:0:0:101 means all NTP servers in the Internet.

Non-permanently-assigned multicast addresses are meaningful only
within a given scope.  For example, a group identified by the non-
permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one
site bears no relationship to a group using the same address at a
different site, nor to a non-permanent group using the same group ID
with a different scope, nor to a permanent group with the same group
ID.

Multicast addresses must not be used as source addresses in IPv6
packets or appear in any Routing header.

Routers must not forward any multicast packets beyond of the scope
indicated by the scop field in the destination multicast address.

Nodes must not originate a packet to a multicast address whose scop
field contains the reserved value 0; if such a packet is received, it
must be silently dropped.  Nodes should not originate a packet to a
multicast address whose scop field contains the reserved value F; if
such a packet is sent or received, it must be treated the same as
packets destined to a global (scop E) multicast address.

2.7.1.  Pre-Defined Multicast Addresses

The following well-known multicast addresses are pre-defined.  The
group IDs defined in this section are defined for explicit scope
values.

Use of these group IDs for any other scope values, with the T flag
equal to 0, is not allowed.



Reserved Multicast Addresses:   FF00:0:0:0:0:0:0:0
FF01:0:0:0:0:0:0:0
FF02:0:0:0:0:0:0:0
FF03:0:0:0:0:0:0:0
FF04:0:0:0:0:0:0:0
FF05:0:0:0:0:0:0:0
FF06:0:0:0:0:0:0:0
FF07:0:0:0:0:0:0:0
FF08:0:0:0:0:0:0:0
FF09:0:0:0:0:0:0:0
FF0A:0:0:0:0:0:0:0
FF0B:0:0:0:0:0:0:0
FF0C:0:0:0:0:0:0:0
FF0D:0:0:0:0:0:0:0
FF0E:0:0:0:0:0:0:0
FF0F:0:0:0:0:0:0:0

The above multicast addresses are reserved and shall never be
assigned to any multicast group.

All Nodes Addresses:    FF01:0:0:0:0:0:0:1
FF02:0:0:0:0:0:0:1

The above multicast addresses identify the group of all IPv6 nodes,
within scope 1 (interface-local) or 2 (link-local).

All Routers Addresses:   FF01:0:0:0:0:0:0:2
FF02:0:0:0:0:0:0:2
FF05:0:0:0:0:0:0:2

The above multicast addresses identify the group of all IPv6 routers,
within scope 1 (interface-local), 2 (link-local), or 5 (site-local).

Solicited-Node Address:  FF02:0:0:0:0:1:FFXX:XXXX

Solicited-Node multicast address are computed as a function of a
node's unicast and anycast addresses.  A Solicited-Node multicast
address is formed by taking the low-order 24 bits of an address
(unicast or anycast) and appending those bits to the prefix
FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the
range

FF02:0:0:0:0:1:FF00:0000

to

FF02:0:0:0:0:1:FFFF:FFFF

For example, the Solicited-Node multicast address corresponding to
the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C.  IPv6
addresses that differ only in the high-order bits (e.g., due to
multiple high-order prefixes associated with different aggregations)
will map to the same Solicited-Node address, thereby reducing the
number of multicast addresses a node must join.

A node is required to compute and join (on the appropriate interface)
the associated Solicited-Node multicast addresses for all unicast and
anycast addresses that have been configured for the node's interfaces
(manually or automatically).

2.8.  A Node's Required Addresses

A host is required to recognize the following addresses as
identifying itself:

o Its required Link-Local address for each interface.

o Any additional Unicast and Anycast addresses that have been
configured for the node's interfaces (manually or
automatically).

o The loopback address.

o The All-Nodes multicast addresses defined in Section 2.7.1.

o The Solicited-Node multicast address for each of its unicast and
anycast addresses.

o Multicast addresses of all other groups to which the node
belongs.

A router is required to recognize all addresses that a host is
required to recognize, plus the following addresses as identifying
itself:

o The Subnet-Router Anycast addresses for all interfaces for which
it is configured to act as a router.

o All other Anycast addresses with which the router has been
configured.

o The All-Routers multicast addresses defined in Section 2.7.1.

Juniper Network Connect upgraded from 6.x to 7.x

 

Notice my SSLVPN client is upgraded today, but seems the newer version has some issue with it.

It will not be loaded completely and stuck in a page with error status, added the VPN link into trusted sites list under IE setting and it fixed the problem.

Internet Option –> Security –> Trusted sites –> Sites –> Add –> Close. Then reload the page and it fly.

VitalQIP DHCP configuration convention

Address types

1. Static



2. Dynamic (used for dynamic assignment pool)



3. Reserved

Object Classes

1. Router (i.e.. default-gw or standby ip of HSRP. There should be only one per subnet, otherwise you will see multiple networks available from windows network configuration)



2. Switch (i.e.. Vlan IP of MDF, IDF switches)



3. WAP (wireless AP)



4. PC/Workstation (general nodes of dhcp client)



5. Other (IP Phones)



6. Server

Status

Status depends on the Address types you choose when defining the scope.

1. Unused (scope to be defined)



2. Static (fixed config of IP address)



3. Dynamic





1. Manual-BOOTP



2. Automatic-BOOTP



3. Manual-DHCP (IP+MAC binding)



4. Automatic-DHCP (Permanent lease)



5. Dynamic-DHCP (Limited lease)

 

RFC2131 - DHCP allocation types

DHCP supports three mechanisms for IP address allocation.  In "automatic allocation", DHCP assigns a permanent IP address to a client.  

In "dynamic allocation", DHCP assigns an IP address to a client for a limited period of time (or until the client explicitly relinquishes the address).  

In "manual allocation", a client's IP address is assigned by the network administrator, and DHCP is used simply to convey the assigned address to the client.  A particular network will use one or more of these mechanisms, depending on the policies of the network administrator.

WCCP on ASA

Guidelines and Limitations

Supported WCCP Features

The following WCCPv2 features are supported with the adaptive security appliance:

•Redirection of multiple TCP/UDP port-destined traffic.

•Authentication for cache engines in a service group.

Unsupported WCCP Features

The following WCCPv2 features are not supported with the adaptive security appliance:

•Multiple routers in a service group is not supported. Multiple Cache Engines in a service group is still supported.

•Multicast WCCP is not supported.

•The Layer 2 redirect method is not supported; only GRE encapsulation is supported.

•WCCP source address spoofing is not supported.

•WAAS devices are not supported.

WCCP Interaction With Other Features

In the adaptive security appliance implementation of WCCP, the following applies as to how the protocol interacts with other configurable features:

•Cut-through proxy will not work in combination with WCCP.

•An ingress access list entry always takes higher priority over WCCP. For example, if an access list does not permit a client to communicate with a server then traffic will not be redirected to a cache engine. Both ingress interface access lists and egress interface access lists will be applied.

•TCP intercept, authorization, URL filtering, inspect engines, and IPS features are not applied to a redirected flow of traffic.

•When a cache engine cannot service a request and packet is returned, or when a cache miss happens on a cache engine and it requests data from a web server, then the contents of the traffic flow will be subject to all the other configured features of the adaptive security appliance.

•In failover, WCCP redirect tables are not replicated to standby units. After a failover, packets will not be redirected until the tables are rebuilt. Sessions redirected prior to failover will likely be reset by the web server.

•If you have two WCCP services and they use two different redirection ACLs that overlap and match the same packets (with a deny or a permit action), the packets behave according to the first service-group found and installed rules. The packets are not passed thorugh all service-groups.

 

Reference: http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/conns_wccp.html

回顧我的 2010

 

還剩一個禮拜就要結束 2010 了, 記得年初訂的新年新希望是 "Live in a better life, in both spritual and physical”, 到底實現了多少呢? 現在來回顧一下吧!

1. 養成一個禮拜游泳1~2次的習慣了, 目前已經可以游到 1.5KM 了, 希望能繼續保持這個好習慣, 對抒解身心壓力有很大的幫助。 這個運動也比較温和, 對步入中年的我還算滿適合的。游泳池畔多的是 50 或 60 幾歲的長輩。
   
2. 找了很多原文的故事書講給馬小尼聽:
   有 Roald Dhal 三本書, 從 Fantastic Mr. Fox -> Charlie and Chocklate Factory ->  BFG。 一開始是因為已經找不到適合的床邊故事講給她聽, 連一旁的老婆也聽的津津有味。 這三本書都有對應的電影版本, 看到她看電影時那種驚喜連連的反應, 心裏覺得有很大的成就感。最近幫她準備的是全套的神奇樹屋, 雖然發現她還是不太能接受中英摻雜的說故事方式, 不過中英文合併的印刷方式讓我覺得滿值得的, 希望她大一點時也能對她的英文閱讀能力幫上忙。
   
3. 今年通過的認證項目
   Fri, 29 Oct 2010 at 09:30
   642-515: Securing Networks with ASA Advanced
   
   Sat, 9 Oct 2010 at 10:30
   642-524: Securing Networks with ASA Foundation
   
   Sat, 3 Jul 2010 at 11:00
   642-504: Securing Networks with Cisco Routers and Switches
   
   Sat, 16 Jan 2010 at 17:00
   VCP410: VMware Certified Professional on vSphere 4
   
   還差一科 IPS 就可以完成 CCSP了, 不過最近確有一點後繼無力的感覺, 部份原因是工作變的比較忙碌了, 另外一個原因我想應該是我自己對考試這件事和職涯發展的關聯性的質疑吧? 非得要考試才能證明自己學習的成果和能力嗎? 在 SI 時, 已經習慣用考試來增加自己對職場生存的安全感和自我肯定的這種觀念似乎還沒完全改過來。考試這件事真的會吃掉很多時間, 學習帶來的成就感似乎不太能填補失去的時間。哎..... 還有 IE 的 recertify 在後面等著呢。有心卻無力指的是不是就是這種感覺呢?
   
4. 聖誕夜的驚喜
   這應該是我今年最大的驚喜吧!
   禮拜五下班回家, 一如往常的會塞車。電話鈴嚮了, 馬小尼用語帶興奮的口氣對我說: "爹地~ 媽咪有準備聖誔大餐哦~, 我有準備禮物要送給你和媽咪哦"。啊, 不是向我要禮物, 而是準備禮物給我們哦?
   
   回到家後, 看到家門口的這張紙, 真的讓我覺得很有趣。門口貼著一張白紙, 上面用注音符號寫著"今天有聖誕大餐", 住對面的鄰居看到了也說:"你女兒好可愛哦"!!  對不起哦~ 真是不巧, 老是讓您看到她可愛又乖巧的一面..... :P
   
   
   傳說中的聖誕大餐, 媽咪~ 真是辛苦你囉
   

我和老婆的禮物, 按摩券和做家事券, 感動的累~


全家人一起快樂的吃頓飯才是最大的幸福。 馬小尼, 你又讓我感覺到你的成長了。繼續給我更多的驚喜吧~

看完這篇, 我承認我太小看 MPF 了。

 

It is much more sophisticated than what I was thinking.

Thanks for the great article from Petr.

http://blog.ine.com/2009/04/19/understanding-modular-policy-framework/

 

Action are applied in the following sequence within MPF.

1. QoS input policing. Applies to traffic entering the firewall, enforces traffic rate. Configured using the command police input| under the policy-map.
2. TCP normalization. TCP and UDP connection limits and timeouts, and TCP sequence number randomization. Performs TCP connection modification and monitoring to enforce security settings. Confiugured using the command set connection and a pre-configured tcp-map with the advanced TCP parameters.
3. CSC (if installed). Content security.
4. Application inspection (multiple types). The core of the stateful firewall. Parses traffic streams and detects application protocols and their commands. Allows enforcing per-application security policies. The command to apply inspection is inspect {protocol-name}. Could be fine-tuned using inspection policy-maps.
5. IPS (if installed). Intrusion prevention – allows the firewall to work as an inline IPS.
6. QoS output policing. Applies to traffic leaving the firewall, enforces specified rate. The command is police output
7. QoS interface priority queue. Services traffic using the interface-level low-latency queue. Configured using the command priority. Could not be applied along with policing feature.
8. QoS traffic shaping, hierarchical priority queue. Mutually exclusive with any other interface-level QoS features. Traffic shaping could be only applied under class-default
   

Feature	Interface-Level Direction	Global Policy Direction	Flow-aware feature
QoS Input Policing	Ingress	Ingress
TCP Normalization, Connection Limits, ISN randomization	Bidirectional	Ingress	Yes
CSC	Bidirectional	Ingress	Yes
Application Inspection	Bidirectional	Ingress	Yes
IPS	Bidirectional	Ingress	Yes
QoS Output Policing	Egress	Egress
QoS Interface-Level PQ	Egress	Egress
QoS Shaping, Hierarchical PQ	Egress	N/A

Feature Incompatibilities

As you remember, you can apply multiple actions under the same class. Some actions just can’t go together. Here is the list of the limitations:

1) You can’t combine policing and interface-level priority queuing for the same class.
2) You can’t configure shaping in global policy map.
3) You can only shape ALL traffic leaving the interface, i.e. you can only shape under class-default.
4) You cannot configure two inspect actions under the same class with except to default-inspection-traffic class.

 

Application priorities:

1. CTIQBE
2. DNS
3. FTP
4. GTP
5. H323
6. HTTP
7. ICMP
8. ICMP error
9. ILS
10. MGCP
11. NetBIOS
12. PPTP
13. Sun RPC
14. RSH
15. RTSP
16. SIP
17. Skinny
18. SMTP
19. SNMP
20. SQL*Net
21. TFTP
22. XDMCP
23. DCERPC
24. Instant Messaging

Here is the list of basic points about MPF:

1) Service policies could be applied globally or per-interface.

2) A packet flow can match multiple classes.

2.1) In case if two ore more classes specify the same feature, firewall applies the deterministic procedure to resolve the conflict.

2.3) In the classes specify different features, they are combined, provided that the features could be used together.

3) Many firewall features are aware of stateful traffic flows.

4) The order that the features are applied is fixed and does not depend on the order of classes in the policy-maps.

ASA – Command Authorization

 

There are three ways to fulfill this.

• using enable command
• using locally defined username and password
• using AAA defined username and password with AAA server

 

Using enable command for authorization

Create different enable password for desired privilege level.

ASA-Roy(config)# enable password level9 level 9
ASA-Roy(config)# enable password level11 level 11

Adjust the commands’ privilege level.
In this example, level9 can show access-list and level 11 can configure access-list.

ASA-Roy(config)# privilege show level 9 mode exec command access-list
ASA-Roy(config)# privilege configure level 11 command access-list

It is important to be careful that ‘parent’ command should be adjust accordingly also, otherwise you will not be able to use the command even if it is configured correctly.
For example, you need to enable ‘configure terminal’ for privilege 11 otherwise you will not be able to enter global configuration mode to issue the ‘access-list’ command.

Enable command authorization and make sure your are NOT enable the “enable authentication” command thru AAA or LOCAL.

ASA-Roy(config)# aaa authorization command LOCAL
ASA-Roy(config)# no aaa authentication enable console LOCAL
or
ASA-Roy(config)# no aaa authentication enable console AAA_Method

If you do, you will get the following error message when you try to issue ‘enable privilege_level’ command.

ASA-Roy> sh curpriv
Username : admin_asa
Current privilege level : 1
Current Mode/s : P_UNPR
ASA-Roy> enable 9
Enabling to privilege levels is not allowed when configured for
AAA authentication. Use 'enable' only.

 

Using local user for command authorization

ASA-Roy(config)# aaa authentication enable console LOCAL
ASA-Roy(config)# username level9 password level9 privilege 9
ASA-Roy(config)# username level11 password level11 privilege 11

User Access Verification

Password:
Type help or '?' for a list of available commands.
ASA-Roy> enable
Username: level11
Password: *******
ASA-Roy# sh curpriv
Username : level11
Current privilege level : 11
Current Mode/s : P_PRIV

 

Using external AAA server for command authorization

aaa authorization command AAA_GROUP LOCAL
ASA-Roy# sh run aaa-
aaa-server AAA_GROUP protocol tacacs+
aaa-server AAA_GROUP (inside) host 1.1.1.1
key *****

ACS Screenshot