OpenBGPd and ipv6 peering

I'm writing  this post on my experiences with a  ipv6/OpenBGP peering setup  that I threw up  on my  VPS host.


This was done on a virtual  pfSense host,  but I had to disable my  pf filter since I had problems installing the  ipv6 pf rules.

e.g ( disable pf )

pfctl -d 

IMHO: The pf rule should have worked, but I believe pfsense 2.0.1 was removing or ignoring the rule.


Here's the bgp cfg under /usr/local/etc/ for pfsense2.0.1+openbgpd;

AS 5XXX
fib-update no
listen on 2607:f2f8:xxx::2

neighbor  2607:f2f8:xxx:1 {
descr "IPV6"
announce none
remote-as 25xxx
local address 2607:f2f8:xxx::2
softreconfig in yes
}

And here's  a few bgpctl show outputs;


-->

[2.0.1-RELEASE][admin@ares]/tmp(140): bgpctl show ip bgp inet6 memory

RDE memory statistics

     91867 IPv4 unicast network entries using 3.5M of memory

         1 IPv6 unicast network entries using 56B of memory    <-- IPv6 single prefix learn but still researching with my VPS hosting

    183734 rib entries using 11.2M of memory

    183735 prefix entries using 11.2M of memory

     15401 BGP path attribute entries using 1.8M of memory

     14065 BGP AS-PATH attribute entries using 755K of memory,

                     and holding 15401 references

      1509 BGP attributes entries using 58.9K of memory

                     and holding 2763 references

      1508 BGP attributes using 11.8K of memory

RIB using 28.5M of memory_ 

and  neighborship;

bgpctl show neighbor IPV6

BGP neighbor is 2607:f2f8:xxx::1, remote AS 25xxx

 Description: IPV6

  BGP version 4, remote router-id 10.0.1.0

  BGP state = Established, up for 00:02:40

  Last read 00:00:11, holdtime 90s, keepalive interval 30s

  Neighbor capabilities:

    Multiprotocol extensions: IPv6 unicast

    Route Refresh

  Message statistics:

                  Sent       Received 

  Opens                    1          1

  Notifications            0          0

  Updates                  0          1

  Keepalives               6          6

  Route Refresh            0          0

  Total                    7          8

  Update statistics:

                  Sent       Received 

  Updates                  0          1

  Withdraws                0          0

  Local host:     2607:f2f8:xx::2, Local port:    179

  Remote host:    2607:f2f8:xxx::1, Remote port: 39925

 and more output;

 

bgpctl show fib  inet6  bgp

flags: * = valid, B = BGP, C = Connected, S = Static

       N = BGP Nexthop reachable via this route

       r = reject route, b = blackhole route

flags prio destination          gateway

 I believe my VPS provider hasn't finished his cfg,  so my FIB does not show anything.

BTW: I'm not announcing anything to them at this time over this setup, nor do I have any Ipv6 assignments to announce as of this time.

Next project will be to get my pfsense box rebuilt & with 2.0.2. And start using  ipv6 out of my  virtual hosted environment and possible over a Ipv6 over Ipv4 tunnel terminated on the firewall.

Ken Felix
Freelance Network/Security Engineer
kfelix ----at----- hyperfeed ---dot----com

    ^     ^
=(  0 @ )=
       O
       ~

Debating a switch exam question ( you got to love cisco )

My weekly Cisco rant 

( certifications, and some of  the stupid questions  cisco presents ! )

 
Here's a link to a site that I just did  a exam topic refresher & for the 642-813  exam that I'm about to take.

https://learningnetwork.cisco.com/community/certifications/ccnp/switch?tab=practice




 Here's the offending question ( #8 )

 

And my selection

|

 

 

The above was a question on one of the review sets of questions,  and my marked answer  "using the Type field in the Ethernet header" was  wrong. Really?

Comon cisco, how about providing some better answers.

Okay let's look at the other answers;

using 802.1q ToS bits ( btw this what they suggested was right, and  the reason of my rant )
implementing DCSP at layer3 ( definitely right since DSCP is  included in layer 3 only )
implementing DCSP at layer 2 ( wrong no DSCP in layer2  )

Okay so answer number #1 was wrong according to the exam, but answer #2 was what they expected & claimed was right. But is that really right?


1st  off  with the ToS bits, there's no such thing as ToS ( type of service ) or any bits in 802.1q or any thing that says ToS in regards to 802.1q tagging.  

With CoS  ( class of service ),  yes,  but with  ToS  no such beast &  it's miss leading and bad wording.

Cisco here's a clue, here's a Ethernet Header ;


Frame 10 (105 bytes on wire, 105 bytes captured)
    Arrival Time: May 15, 2013 23:27:30.659288000
    [Time delta from previous captured frame: 0.000002000 seconds]
    [Time delta from previous displayed frame: 0.000002000 seconds]
    [Time since reference or first frame: 0.000067000 seconds]
    Frame Number: 10
    Frame Length: 105 bytes
    Capture Length: 105 bytes
    [Frame is marked: False]
    [Protocols in frame: eth:vlan:ip:gre:ip:tcp:ssl]
Ethernet II, Src: 40:55:39:2f:11:a9 (40:55:39:2f:11:a9), Dst: Force10N_57:1c:a3 (00:01:e8:57:1c:a3)
    Destination: Force10N_57:1c:a3 (00:01:e8:57:1c:a3)
        Address: Force10N_57:1c:a3 (00:01:e8:57:1c:a3)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Source: 40:55:39:2f:11:a9 (40:55:39:2f:11:a9)
        Address: 40:55:39:2f:11:a9 (40:55:39:2f:11:a9)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: 802.1Q Virtual LAN (0x8100)
802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 203
    000. .... .... .... = Priority: 0
    ...0 .... .... .... = CFI: 0
    .... 0000 1100 1011 = ID: 203
    Type: IP (0x0800)

 Notice, no ToS field in that layer2 802.1q frame. Just ain't happening :)


The 1st answer that I selected,  was based on the Ether.Type of a 802.1q  tagged framed would be present in the header to indicated it's  tagged, and then inspection of the CoS value could be inspected. I bold that type and the priority field for 802.1p ( aka CoS )

This how a switch knows tagging is involved & to  determine if any the priority of the frame. Btw that Ether.Type would be 0x8100  where as a regular ipv4 Ether.Type would be 0x0800.

So going by we have no ToS bits in etherytype 0x8100 , or as matter fact even a standard ethernet frame, this should be a wrong answer imho. I'm going to reference wikipedia  and what they say about ToS & CoS

http://en.wikipedia.org/wiki/Type_of_service
http://en.wikipedia.org/wiki/IEEE_P802.1p


The question is badly worded & we should really expect more Cisco

Ken Felix
Freelance Network/Security Engineer
kfelix -----at----- hyperfeed ----com----

        ^      ^
==(   O   O )==
            ~
         

Encryption and MAIL concerns wth SMTPs

Somebody read my GPG post from earlier, and sent me a private email on why we should use  PGP/GPG for mail vrs using SMTPs.  They had concerns on how secured their mail system really was.

SMTPs, mean Simple Mail Transport Protocol ( Secured )  & it's secured via  SSL/TLS and similar to how  HTTPs works.

Will I  giving you some pros on why PGP encryption of your mail & by the sender/recipient is way better. But let's look at this digrams and it should be clear.

VRS

Okay as you can clearly see, with PGP and encryption of  the mail body ( content ) we can ensure security from  end-2-end from  the 2 graphical images.

Other advantages;

•           no dependencies on Mail Gateways or any mail-hops that might not use security

•           you control the level of encryption 

•           Established level of security for each message between sender +recipient 

                    ( i.e you could use different  keys and encryption  per message or recipient )

•           data is secured while in transient or even  at rest

•           mail-storage  or archival and mail is still fully secured 

                                ( no risk for orgs that archive for multiple years )

•           easy to apply digital signature to ensure data integrity and no tampering

So the bottom line; relying purely on SMTPs , and it's transparent means of encryption,  is  no means to ensure  100% security  within a mail delivery system.

This message is endorse my Ken Felix

Ken Felix
Freelance Network/Security Engineer
kfelix    ----at---- hyperfeed ---dot----com

CCIE RS schedulding

My luck using cisco CCIE lab payment or processing website is plain horrible. I never seen so may issues in something that should be so ........simple.

I was issued a voucher from my last attempt,  and  now that I'm ready to schedule, the  payment site provided no input for my voucher, and then no error code. It still acted like I  need to enter payment information like  such as a CreditCard.

My goal is to get back to RTP in July and take my 2nd attempt or is it my 2rd attempt ( my 2nd attempt back Jan was filled with technical issues in the t-shoot section )

My experience from that exam, has encourage me to do more personal  t-shoot labs and go over information with pertaining to troubleshooting, since that 1st 2hours is the most stressful part of the CCIE  lab.

I'm still trying to build a local group of CCIE/RS lab guys/gals that want to share  knowledge, craft some labs, and provide  pointers. But that hasn't been going to well in my efforts with getting good committed persons to join.

On this lab attempt, I'm going to try something different;

• fly on a weekend like sat ( tentatively July 13 )
• study full day  sunday @ hotel  & then  get a good nigh sleep
• take my lab on monday ( get my number :) )
• fly back Monday or Tuesday

On my 2nd attempt, I did NOT get any sleep,  even tho I've been b4 and knew what to expect. I think I hit the bed at 11:30ish and if I got more than 2hours of sleep, than I would be lying.

In my recent studies, I've placed more focus on the following;

•  on layer2 MST, STP issues
•  root-guard
•  redistribution to/from EIGRP 
•  PFRouting
•  and other misc services ( ssh port # changes, ntp services, tac_plus cfg, GRE tunneling, ipv4  tunneling with ipv6 ,etc.......)

Trying to reduce any surprised that might come and nail the 3+ pt exhibits & get my  CCIE RS # :)

     ^   ^
= ( 0  0 ) =
        @
         

Ken Felix
Freelance Network/Security Engineer
kfelix ---at--- hyperfeed --dot--- com

Cipher.types & CBC vrs CTR speed bakeoff

CBC vrs CTR, 3des vrs AES  , so many choices are you confused ?


In crypto and dealing with  plain.text--2--cipher.text, we are challenged into what mode to use and what cipher type to use.

All encryption function trys to accomplish the same the goal. We take some type of  plain.text  and encrypted it.  And then on the opposite end, we  take the  cipher.text and de-encrypted it back to plain.text using the same cipher and encryption method.

Both CBC ( Cipher Block Chaining ) vrs  CTR ( Counter Mode ),  provides differences, some minor in overall performance, and the functions and how it process a block of data is different. In this post we will use a simple bash script with a while function, execute a ssh transfer & than  measure  the performance numbers between the 2 mode. You can go farther and compare the difference between ciphers , which we will do a simple and quick test.

e.g
3des vrs aes128 
aes128 vrs 192 
aes 192 vrs 256
and so on ...........


1st I wanted to make reference to another  blogger on his thoughts with cryptography  and with regards to these modes. His blog has some very good information about the 2 differences between CBC and CTR modes.

http://johnx.blogspot.com/2010/10/aes-cbc-or-aes-ctr-mode.html


In our example, we will compare  various ciphers & modes, while  using ssh. We will try to keep all variable the same , by not relying on any disk-io, and while using the "loopback" interface to rule out any network related issues, and as to not askew our data results. All tests results produced here was on a relatively idle host and all cpu being available for the benchmark.

The goal for establishing  a benchmark, is to take  a equal set number of samples,  and  by using the 95th percentile and/or averaging. This would be our based number for cipher xyz and it's  effective transfer rate.

A few thoughts before we continue,  "why would we care on any performance number or gains ?"


Will I would use a teaching , that  my Dad taught me many, many decades ago,

I was walking along a street and seen a penny on the sidewalk. I didn't pick it up since it was only 1 penny. My dad asked me ; "why ?"

I told him it was  just only 0.01cents,  and it was not going to get me much if anything.

He's come back was; "yes it's only 0.01ct now, but want if you found 99 more pennies tomorrow?"

So in  encryption we need to look at it in the same method, any savings and over a course of time or duration, can make a big difference in the long run.

1st here's the script that we would use to execute our transfer of data for the samples that we will use in simple graphing and representation.

#!/bin/bash
#
#
E=100
#
COUNTER=0

while [ $COUNTER -lt $E ] ;
do
  echo " Testing Cipher Block Chaining Mode "
  dd if=/dev/zero bs=1m count=50 | ssh -i ~kenfelix1/.ssh/id_rsa.pub -o "Compression no" -c aes128-cbc 127.0.0.1 cat - > /dev/null
  sleep 1;
   let COUNTER=COUNTER+1

done
#
#
#

#  and for the  ctr mode we would use the following
#
#
#
while [ $COUNTER -lt $E ] ;

do
  echo " Testing  Counter Block Mode "
  dd if=/dev/zero bs=1m count=50 | ssh -i ~kenfelix1/.ssh/id_rsa.pub -o "Compression no" -c aes128-ctr 127.0.0.1 cat - > /dev/null
  sleep 1;
   let COUNTER=COUNTER+1

done



This above script will take 50megs of data (all zeros ) and transfer them thru ssh using the cipher  selected. We will not use any compression,  and to speed things up,  I'm  using my authorized_keys, so I will not be prompt for login information. The variable "E" will be the number of samples that we would execute.

The data that's being sent will generate a output similar to the following;

50+0 records in
50+0 records out
52428800 bytes transferred in 4.220085 secs (12423636 bytes/sec)

So the output of the bytes /per-second , will now be  extracted and using excel  or some other method, we will remove the top 5 and average the reminding  values or just use the 95th percentile to measure out the achieved transfer rate.

This style of testing,  is more accurate if we using more samples and/or long data sizes. You will easily find that your performance  rates will vary by the type of cipher used.

(e.g)

Arcfour for example is typically faster than  blowfish or AES

while 3des CBC is typically a bad performer

The difference for cipher types that use both cbc and ctr could vary based on the system and cpu



Once you find a cipher combo that provides the best performance, you could  set your sshd config to allow just that  cipher

e.g

cat /etc/ssh_config | grep iphers
#   Ciphers
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
# ken's  cipher pick
Ciphers aes128-ctr
#

And if you want your local client machine to use that cipher as it's Default and all of the time you could do the following;



e.g

echo "Ciphers aes128-ctr > ~./.ssh/ssh_config

Here's example of how  you test for comparison data. I test the following ciphers plus arcfour128.

In the above files we found out that 3des-cbc was the worst performer. All testing was done a on macbookair and the outcome would be greatly effected by cpu types.

graph data:

I advise you to play with cipher types regardless if it's  for SSH, Website ( SSL/TLS)  or IPSEC/SSL vpn, and conduct your own benchmark & with traffic transfers to find the best  preferred cipher and  mode type.

NOTE: SSH v1 is horrible with transfer rates

Ken Felix
Freelance Network & Security Engineer
kfelix ***at*** hyperfeed ***dot** com

    ^    ^
=( O O ) =
       o
       ~

BGP capabilities

In this blog we will talk about the BGP capabilities. If you have ever noticed any bgp neighbors show outputs, you might have seen something of the following;

(show  ip bgp neighbor  cisco IOS )

    Neighbor capabilities:

    Route refresh: advertised and received(new)

    Four-octets ASN Capability: advertised and received

    Address family IPv4 Unicast: advertised and received

    Multisession Capability:  and received

Within a BGP speaker  start-up, their's a negotiation stage done at the bgp open request. A few things happens here.

• Both peers will announce their AS
• capabilities 
• ( 4byte ASN support, route-refresh, multiprotocol support for any SAFI, graceful-restart, and any private use values )

Note: IANA maintains the common assigned capabilities codes and range for reserves and for-private-use

One thing to keep in mind, not all BGP speakers supports all well-known capabilities,  that  why we negotiate and announce what we support at the bgp open.

During this open message,  these capabilities will be sent and possible ack &  received via the peers. If a cisco router for example send & receives a capabilities, it will flag it as received & negotiated.

NOTE:  For any 4byte ASN enabled routers, they announce a  AS23456 to the peer since it does not know yet if the neighbor is 2byte ASN or 4byte ASN aware ( a classic chicken and egg scenario )

Let’s look at a  BGP_OPEN messages between a pair or routers;

      Type: OPEN Message (1)
        Version: 4
        My AS: 65002
        Hold time: 90
        BGP identifier: 192.0.1.1
        Optional parameters length: 16 bytes
        Optional parameters
            Capabilities Advertisement (8 bytes)
                Parameter type: Capabilities (2)
                Parameter length: 6 bytes
                Multiprotocol extensions capability (6 bytes)
                    Capability code: Multiprotocol extensions capability (1)
                    Capability length: 4 bytes
                    Capability value
                        Address family identifier: IPv4 (1)
                        Reserved: 1 byte
                        Subsequent address family identifier: Unicast (1)
            Capabilities Advertisement (4 bytes)
                Parameter type: Capabilities (2)
                Parameter length: 2 bytes
                Route refresh capability (2 bytes)
                    Capability code: Route refresh capability (128)
                    Capability length: 0 bytes
            Capabilities Advertisement (4 bytes)
                Parameter type: Capabilities (2)
                Parameter length: 2 bytes
                Route refresh capability (2 bytes)
                    Capability code: Route refresh capability (2)
                    Capability length: 0 bytes

 and

       Type: OPEN Message (1)
        Version: 4
        My AS: 65001
        Hold time: 90
        BGP identifier: 192.0.2.2
        Optional parameters length: 16 bytes
        Optional parameters
            Capabilities Advertisement (8 bytes)
                Parameter type: Capabilities (2)
                Parameter length: 6 bytes
                Multiprotocol extensions capability (6 bytes)
                    Capability code: Multiprotocol extensions capability (1)
                    Capability length: 4 bytes
                    Capability value
                        Address family identifier: IPv4 (1)
                        Reserved: 1 byte
                        Subsequent address family identifier: Unicast (1)
            Capabilities Advertisement (4 bytes)
                Parameter type: Capabilities (2)
                Parameter length: 2 bytes
                Route refresh capability (2 bytes)
                    Capability code: Route refresh capability (128)
                    Capability length: 0 bytes
            Capabilities Advertisement (4 bytes)
                Parameter type: Capabilities (2)
                Parameter length: 2 bytes
                Route refresh capability (2 bytes)
                    Capability code: Route refresh capability (2)
                    Capability length: 0 bytes

and here's a BGP_OPEN from a  BGPspeaker that supports 4byte ASNs ( notice the BOLD  sections )


Border Gateway Protocol - OPEN Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 61
    Type: OPEN Message (1)
    Version: 4
    My AS: 23456
    Hold Time: 180
    BGP Identifier: 192.XX.219.1 (192.XX.219.1)
    Optional Parameters Length: 32
    Optional Parameters
        Optional Parameter: Capability
            Parameter Type: Capability (2)
            Parameter Length: 6
            Capability: Multiprotocol extensions capability
                Type: Multiprotocol extensions capability (1)
                Length: 4
                AFI: IPv4 (1)
                Reserved: 00
                SAFI: Unicast (1)
        Optional Parameter: Capability
            Parameter Type: Capability (2)
            Parameter Length: 6
            Capability: Multiprotocol extensions capability
                Type: Multiprotocol extensions capability (1)
                Length: 4
                AFI: IPv6 (2)
                Reserved: 00
                SAFI: Unicast (1)
        Optional Parameter: Capability
            Parameter Type: Capability (2)
            Parameter Length: 2
            Capability: Route refresh capability
                Type: Route refresh capability (128)
                Length: 0
        Optional Parameter: Capability
            Parameter Type: Capability (2)
            Parameter Length: 2
            Capability: Route refresh capability
                Type: Route refresh capability (2)
                Length: 0
        Optional Parameter: Capability
            Parameter Type: Capability (2)
            Parameter Length: 6
            Capability: Support for 4-octet AS number capability
                Type: Support for 4-octet AS number capability (65)
                Length: 4
                AS Number: 65540

As you can see these these peers provided a few details between each other during the negotiation process. Sometimes ( rarely ) do we get into problems with the negotiation, and have to take direct action to ease the negotiation process along. 

Per the rfc5492 { http://tools.ietf.org/html/rfc5492 }

[START QUOTE]

   A BGP speaker that supports a particular capability may use this
   capability with its peer after the speaker determines (as described
   above) that the peer supports this capability.  Simply put, a given
   capability can be used on a peering if that capability has been
   advertised by both peers.  If either peer has not advertised it, the
   capability cannot be used.

   A BGP speaker determines that its peer doesn't support capabilities
   advertisement if, in response to an OPEN message that carries the
   Capabilities Optional Parameter, the speaker receives a NOTIFICATION
   message with the Error Subcode set to Unsupported Optional Parameter.
   (This is a consequence of the base BGP-4 specification [RFC4271] and
   not a new requirement.)  In this case, the speaker SHOULD attempt to
   re-establish a BGP connection with the peer without sending to the
   peer the Capabilities Optional Parameter. 

[END QUOTE] 

 I bold out some key issues above, that comes up with this process. And some times this feature and function does  not work. So if you have negotiation issues, you can use a "dont capability negotiation" for that peer.

(cisco configuration )

config t
   router bgp 65501
      neighbor  1.1.1.1 remote-as 65502
      neighbor  1.1.1.1 description "my problematic upstream that can;'t negotiate correctly"
      neighbor  1.1.1.1 dont-capability-negotiate 
end


Here's a show bgp neighbor output from OpenBGP for a bgp peer of mine running FreeBSD that peer's with an older cisco device.


# bgpctl show neighbor
BGP neighbor is 174.136.xxx.1, remote AS 25795
 Description: MyUPLINK
  BGP version 4, remote router-id 10.0.0.1
  BGP state = Established, up for 05w1d17h
  Last read 00:00:18, holdtime 90s, keepalive interval 30s
  Neighbor capabilities:
    Multiprotocol extensions: IPv4 unicast
    Route Refresh
  Message statistics:
                  Sent       Received 
  Opens                    3          3
  Notifications            2          0
  Updates                  4    1255318
  Keepalives          200198     157689
  Route Refresh            0          0
  Total               200207    1413010

  Update statistics:
                  Sent       Received 
  Updates                  8    2049608
  Withdraws                0     799229

  Local host:       174.136.xxx.2, Local port:  30780
  Remote host:      174.136.xxx.1, Remote port:   179

Most show commands will show you the capabilities negotiated between peers. So remember to  use the show commands or tshark/wireshark if you have BGP issues & trying  to get 2 peers to establish a session

Ken Felix
Freelance Network/Security Engineer
kfelix /at/  hyperfeed  /./ com

      ^   ^
=(  O  O ) =
        o
        ~