Thanks for the thorough review, My comments in line as [Hu Jun]
-----Original Message-----
From: Idr <[email protected]> On Behalf Of Paul Wouters
Sent: Wednesday, July 24, 2019 8:39 AM
To: [email protected]
Cc: [email protected] WG <[email protected]>
Subject: [Idr] Review of draft-hujun-idr-bgp-ipsec-00
Hi,
Note that I am an IPsec person and not a routing expert.
The document's idea looks fine to me. It is using BGP messages to provision
IKEv2 so that IPsec tunnels can be setup to protect packets as best as
possible. That's great :)
And unlike most proposals the IPsec WG sees, this document does not try to
replace IKEv2 with its own smarter Key Exchange protocol, so that's a double
plus :)
[Hu Jun] indeed, IKEv2 is a field proven mature/secure protocol, there is
really no need to re-invent a new way for key exchanging
Thanks for reaching out to the ipsec WG, we really appreciate the chance to
read drafts that use IPsec to give advise.
Below are some of my comments and questions I have:
- Configuring large number of tunnels is error prone and not scalable
* Only true to some extend
* See AutoVPN, DMVPM, NHRP+IKE
* Still, this provisioning system seems to fit your eco system. It's as
simple as it can be and
does not seem to introduce any new complexity or risks.
[Hu Jun] All kinds of tunnel mechanism are used in large IP network where BGP
is heavily used, that's why ietf-idr-tunnel-encaps introduce a unified
mechanism for BGP to signal different type of tunnel config; my draft is just
extension of it to support IPsec tunnel; and I intentionally keep the changes
to BGP small and no change to IPsec, for easier adaption;
- What is "color"?
[Hu Jun] "color" is a general term used in routing to represent a set of rules
or match criteria; for example color "red" means set-1 of rules, "yellow" means
a set-2 of rules; in my draft, color sub-TLV is used to signal a set of IPsec
config that are not explicitly signaled by other BGP sub-TLVs (like
local/remote traffic selector prefix, public routing instance) ;
Following is an example:
Color "red" maps to following IPsec config:
- certificate auth
- trust anchor CA-1
- ike-transform: sha256/aes-gcm-256/DH-Grp 15
- IKE_SA lifetime: 1 day
- esp-transform: sha256/aes-gcm-256/Pfs-Grp 15
- CHILD_SA lifetime: 2 hours
- ESN: yes
- ... etc
Color "yellow" maps to following IPsec config:
- certificate auth
- trust anchor CA-2
- ike-transform: sha128/aes-gcm-128/DH-Grp 15
- IKE_SA lifetime: 1 day
- esp-transform: sha128/aes-gcm-128/Pfs-Grp 15
- CHILD_SA lifetime: 2 hours
- ESN: No
- ... etc
- Section 3, step 4:
When a router need to forward a packet along a path is determined
by a BGP UPDATE which has a tunnel encapsulation attribute that
contains one or more IPsec TLV, and router decides use IPsec
based on local policy,
Required vs Optional IPsec issue. If only one end has "required" and the other
end has "optional" then unencrypted packets will be dropped. Seeing IPsec
tunnel TLV should probably mean it is mandatory to setup a tunnel?
[Hu Jun] A router could include multiple different tunnel type TLV in a BGP
update, which means there could be multiple tunnel type options for a given
route; and a receiver of such route might chose one of them based on local
policy; this behavior is specified in section 5 of draft-ietf-idr-tunnel-encaps
It can be done as "optional" but then the IPsec/kernel mechanisms cannot
trigger an IKE/IPsec negotiation and this protocol needs to be responsible for
not just configuring IKEv2/IPsec but also for bringing up the tunnels when
needed.
[Hu Jun] yes, if the system decides to use IPsec tunnel to reach a route (based
on local policy), it needs to first to check if there is already an existing
CHILD_SA it could use, if not, system needs to use IKEv2 to create one
- Section 3, step 6:
- signaling IPsec configuration
Call it IPsec provisioning ?
[Hu Jun] I don't have strong opinion on this, provision is also fine to me;
- Examples are using less prefered and slower algorithms
* Change AES-CBC-256 with SHA-384. to AES-GCM-256 or CHACHA20_POLY1305
* Change NULL-SHA256 to NULL-AES-GMAC
[Hu Jun] ok, I will make the change
- 1/128 and 2/128 ?
For 1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled
Unicast), these NLRI has embedded label, which cause the payload
packet can't be encapsulated in ESP packet,
I don't understand why 1/128 or 2/128 are special ?
[Hu Jun] because these routes include a MPLS label, so by default, a router are
supposed to add a MPLS label to the payload packet; but IPsec (ESP) only
supports IP packet as payload, so label can't be included during ESP
encryption/encapsulation; that's why a value 2 of Embedded Label Handling
Sub-TLV is used to signal ignoring the MPLS label during ESP processing
Open questions:
- If the IKEv2 protocol fails, what happens with packets? Release in clear or
drop?
Is this something the BGP should configure/provision ? If not, it should
state
which of the two is expected
[Hu Jun] This depends if there is any other tunnels (signaled via other tunnel
encap TLV in BGP update) could be used; if there is, then use another one based
on local policy; if not, then drop the packet as no route available
- If a router R1 and R2 have an ipsec tunnel for some traffic, and R1
crashes/reboots,
how do things recover? R2 will send packets and might not know something is
wrong, unless
it is configured for liveness. What happens when R1 comes back up? If all
BGP routes
are taken away via another mechanism, then I guess R2 would simply delete
its tunnel.
[Hu Jun] there need to some keepalive mechanism to detect if tunnel is up or
not; this is not specific to IPsec, all stateful tunnel need such mechanism;
for IPsec, DPD is one option; another faster option would be running BFD over
IPsec tunnel; after R2 detects tunnel is down, it has following options:
1. if there is another type of tunnel could use (as described as above), then
use that tunnel
2. try re-create the tunnel for a few times, if still can't create the tunnel,
use other tunnel if available
Such case is also described in section 5 of draft-ietf-idr-tunnel-encaps
- Performance: if routes are large (eg 0/128) then very few tunnels would cover
lots of
routes. In general, having more parallel smaller CHILD SA's outperforms a
single or two
CHILD SA's by far. This could introduce performance issues.
[Hu Jun] agree, and user could freely choose between a few CHILD_SA or many
CHILD_SA based on traffic selector sub-TLV BGP signals
- Some IPsec options not mentioned could prevent a tunnel from being setup,
such as
whether to use Extended Sequence Numbers (ESN), or Perfect Forward Secrecry
(PFS).
Some of these could be locked down in the document (PFS=yes) but things like
ESN
really depend on the bandwidth of the tunnel.
[Hu Jun] as mentioned above, all IPsec config that is not explicit signaled by
a sub-TLV, is indirectly signal by color
- Maybe some advise on replay-window size would be good. Larger is better but
takes more
memory. Matters mostly for highspeed links.
[Hu Jun] this sound more like a general IPsec optimization suggestion; kind
orthogonal to the draft
Paul
_______________________________________________
Idr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
