Release Note для Cisco Cisco Packet Data Gateway (PDG)

 



 

Access Control via Blacklist or Whitelist – A blacklist or block list is a basic access control mechanism that 

allows everyone access, except for the members of the black list. The opposite is a whitelist, which denies 
access to everybody except for members of the white list. You can implement either a blacklist or whitelist; 
both listing techniques cannot be implemented simultaneously on a security gateway. 



 

PSK Support for Remote Secrets – StarOS also allows the operator to configure a remote secret list that 

contains PSKs based on remote ID types. The remote secret list can contain up to 1000 entries; only one 
remote secret list is supported per system. The remote secret list bound to a crypto map and/or crypto template. 



 

CA Certificate Chaining – Certificate chaining, also known as hierarchical CA cross certification, is a method 

by which an entity is authorized by walking a sequence of intermediate As up to the trust-point CA. An 
intermediate CA is a certification authority under a root CA, which is a self-signed authority. StarOS only 
supports X.509 Certificate encoding when sending certificates with a maximum certificate chain length of 4. 
The length of the certificate chain is defined as the number of all certificates in the chain, including the entity 
and intermediate CA certificates, but excluding the trust anchor certificate. 



 

IKEv2 RFC 5996 Compliance – Staros IKEv2 has been enhanced to comply with RFC 5996 – Internet Key 

Exchange Protocol Version 2 (IKEv2). RFC 5996 introduces two new notification payloads using which 
certain conditions of the sender can be notified to the receiver. The IANA assigned numbers for these payloads 
are as follows: 



 

TEMPORARY_FAILURE – IANA Assigned Number = 43 



 

CHILD_SA_NOT_FOUND – IANA Assigned Number = 44 



 

Rekey Traffic Overlap – To assure interrupt-free traffic IKE SA and IPSec SAs have to be “rekeyed”. By 

definition, rekeying is the creation of new SA to take the place of expiring SA well before the SA expires. RFC 
5996 describes the procedure for IKEv2 rekeying with minimal traffic loss. During the rekeying, both initiator 
and responder maintain both SAs for some duration during which they can receive (inbound) on both SAs. The 
inbound traffic on the old SA stops only after each node unambiguously knows that the peer is ready to start 
sending on the new SA (switch outbound to new SA).  



 

CRL Fetching – Certificate Revocation Lists are issued periodically by the CA. This list contains the serial 

number of all the certificates that are revoked. An operator can verify the status of a certificate using a CRL. A 
CRL can be fetched via LDAPv3 from a CRL issuer (Trusted by CA). When configured, this function also re-
fetches the CRL once it expires in the cache. If the CRL is obtained from a CRL Distribution Point (CDP), 
StarOS defers the CRL fetch until the tunnel is established. 



 

Reverse DNS Lookup for Peer IP – A CLI command enables a DNS reverse look up from the IKE peer IP 

address to the hostname. A DNS query is sent to obtain the IKE Peer name from DNS Server. The IP address-
to-host name mapping appears when displaying the statistics. 

For additional information refer to 

 , the System 

Administration Guide and StarOS IP Security Reference. 

This section identifies system features modified in release 15.0. 

BGP is employed with Interchassis Session Recovery (ICSR) configurations linked via Service Redundancy Protocol 
(SRP). By default an ICSR failover is triggered when all BGP peers within a context are down.  

Optionally, you can configure SRP peer groups within a context. ICSR failover would then occur if all peers within a 
group fail. This option is useful in deployments in which a combination of IPv4 and IPv6 peers are spread across 
multiple paired VLANs, and IPv4 or IPv6 connectivity is lost by all members of a peer group.