Subject: [Softwires] Softwires Mesh Security Discussion with Sam Hartman

From: "Chris Metz \(chmetz\)" <[email-masked]>
Date: Fri, 14 Apr 2006 11:15:52 -0400

Softwire Mesh Security Discussion with Sam Hartman
 
Date: 3/23/06
 
Attendees: Sam Hartman (Security AD), Mark Townsley (Internet AD), David
Ward (Softwires WG Chair), Alain Durand (Softwires
WG Chair), Simon Barber (Cisco), Chris Metz (Cisco)
 
Sam H. remarks:
 
- IPsec connections in a mesh topology is hard to do
 
- Need to apply IPsec authentication/encryption on a selective basis.
That is have PE nodes announce reachability (prefixes, next_hops) and an
option for security applied to all or a group of prefixes
 
- Automated key management in this softwire mesh scenario is necessary
per RFC4107
 
http://www.ietf.org/rfc/rfc4107.txt?number=4107
<BLOCKED::http://www.ietf.org/rfc/rfc4107.txt?number=4107> 
 
- Must have a reasonable, interoperable profile. Example is RFC3193
http://www.ietf.org/rfc/rfc3193.txt?number=3193
<BLOCKED::http://www.ietf.org/rfc/rfc3193.txt?number=3193> 
 
- make it easy and practical 
 
- can go with static IPsec configuration and then there is no dependency
on BGP
 
- suggestion: include 160-bit hash of certificate in Tunnel SAFI. Is
160-bits too big for BGP to carry? David W said it is not a problem.

David Ward summary of how this would work:
 
a) AFBRs advertise (self-signed) 160-bit hash of a certificate in Tunnel
SAFI to every other AFBR
 
b) IKE signaling ensues and inter-AFBR IPsec protected softwire is built
 
c) AFBRs advertise reachability to prefixes reachable thru the
IPsec-protected softwire

Mark Townsley Question: How granular should the protection be?
Discussion followed and it can range from all prefixes reachable thru
AFBR to those associated by VPN and/or route target. Sam H suggested
finer granularity of what to protect might make profiling more
difficult.
 
Simon Barber observed that security requirement depended on where
topology is as to what should be protected. Sam H followed up that it
depends on WHAT is transported over the topology.

Discussion on IPsec profile and whether it should be included in
softwire solution document or separate document. Consensus was to make
it
a separate document.
 
David Ward observation: profile likely to be same for L2VPN, L3VPN and
softwires mesh cases
 
Additional ad-hoc comments:
 
- Normative reference: Security analysis for Softwires
 
http://mirror.switch.ch/ftp/mirror/internet-drafts/draft-yamamoto-v6tc-s
ecurity-considerations-01.txt
<BLOCKED::http://mirror.switch.ch/ftp/mirror/internet-drafts/draft-yamam
oto-v6tc-security-considerations-01.txt> 
 
- check BCP61 to analyze softwire security for operation over the
Internet
 
ftp://ftp.rfc-editor.org/in-notes/rfc3365.txt
<BLOCKED::ftp://ftp.rfc-editor.org/in-notes/rfc3365.txt> 
 
- can also use PKI to obtain certificates rather then self-signed model
but goal is not to rely on PKI.
 
Brief hub-spoke discussion followed:
 
- send normative references to security group
 
- hub-spoke auto-discovery must be secure from the start. Should not be
hard to do.
 
- Mark Townsley observation: cannot rely on tunnel security if
end-to-end security is desired. One reason is that it is a transition
tunnel and it might
disappear some day.
 
Chris 

 

_______________________________________________
Softwires mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/softwires

---

From: "Florent Parent" <[email-masked]>
Date: Mon, 17 Apr 2006 19:20:31 -0400

Chris, thanks for the summary. Comments below.
Florent

...
>
> - can go with static IPsec configuration and then there is no dependency on
> BGP
>

What do you mean by static IPSec configuration? SPD entries
identifying every peers in the mesh?

> c) AFBRs advertise reachability to prefixes reachable thru the

Trying to understand the role of the 160-bit hash:  IKE is used to in
b) to authenticate and setup the SA according to a pre-configured SPD,
I assume. So the 160-bit hash send in a) is used for what? Validate
that the received certificate during IKE phase1 (because it is
self-signed)? Also, I assume that the hash advertised in a) is not
protected?

...

> David Ward observation: profile likely to be same for L2VPN, L3VPN and

David, any document pointers from L?VPN groups?