> Softwire Security Analysis and
Requirements
>
draft-ietf-softwire-security-requirements-01
...
> 1. Introduction
...
> The Softwire protocol itself does not implement full
security
> protection mechanism in the control plane and data
plane and
> vulnerable for potential security attacks. Thus,
the Softwire MUST
The text above is a bit unclear. What are the potential
security
attacks, where are they described etc. Reference here would
be good
thing (i.e. to the relevant section in this document or some
other
document). Also I also think there is some words missing
from the
sentence.
> 3. Hubs and Spokes Security Guidelines
> 3.1 Deployment Scenarios
...
> However, the host device may not always have direct
access to its
> home carrier network, to which the user has
subscribed. For example,
> the softwire initiator in the laptop PC can access
various access
> networks such as Wi-Fi hot-spots, visited office
network. This is
> the nomadic case, which the Softwire SHOULD
support., the following
> three use cases should be considered:
Something missing from there.
> 3.3 Softwire Security Threat Scenarios
...
> Threat analysis done for other protocols L2TP using
IPsec [RFC3193],
^
> PANA [RFC4016], NSIS [RFC4081],
[I-D.rpsec-routing-threats] are
> applicable here as well and should be used as
reference.
probably should be "other protocols, such as L2TP using
IPsec ...".
> 3.4 Softwire Security Guidelines
...
> 3. The Softwire MUST BE able to mutually
authenticate the initiator
...
> 4. The Softwire signaling communication between the
client and the
> concentrator MUST BE protected against
eavesdropping and spoofing
s/MUST BE/MUST be/g.
> 9. Softwire security MUST meet the key management
requirements of
> the IPsec protocol suite. IKE SHOULD be
supported for
> authentication, security association
negotiation, and key
> management
I think this should refer to IKEv2 specifically, not as IKE
in
general.
> 3.5 Guidelines for Usage of Security Protection
Mechanism
>
> The Softwire security requirements state that
control and/or data
> plane must be able to provide full payload security
when desired
> [I-D.softwire-problem-statement, section 2.11.2].
[RFC3193]
> discusses how L2TP can use IPsec to provide tunnel
authentication,
> privacy protection, integrity checking and replay
protection.
I think the RFC3193 is written in the quite IKEv1 centric
way, and a
new document describing "Securing L2TP using IPsec and
IKEv2" is
needed. The things done in the RFC3193 describing how to
create SAs
using IKEv1 is mostly obsolete, and can be done in a better
way in the
IKEv2. For example there is no need make those multiple
different
phase 2 exchanges when server wants to change address or
port of the
L2TP connection. Instead the initiator could propose TSr in
such way
that it leaves the port numbers open for the responder to
select.
To support for server to using different IP address could
also be
supported either with MOBIKE or with some more text
describing what to
do in that situation (i.e. if using transport mode, then
there is text
that needs to be added, for tunnel mode it works already if
TSr
proposed by initiator is wide enough to allow responder to
select
another address).
> 3.5.2.3 IPsec authentication
>
> Authentication using shared secrets can be used when
the number of
> softwire initiators is small. When the number of SI
increases,
> shared secrets becomes difficult to manage.
Public-key digital
> signature or key encryption authentication with
certificates is
> preferable [RFC3193, 4.1].
This section should probably have MUST NOT for the group
shared keys.
We do not really want to use group shared keys ever, but
someone will
try that anyways, so better forbid them here too...
> 3.5.5.1 IPv6 over IPv4 Softwire with L2TPv2 example
>
> In this example, the softwire initiator and
concentrator are denoted
> with IPv4 addresses IPv4-SI and IPv4-SC
respectively.
>
>
> Next Layer
> src dst Protocol
Action
> ----- ------ ----------
--------
"Next Layer" header has wrong indention.
> IPV4-SI IPV4-SC ESP
BYPASS
> IPV4-SI IPV4-SC IKE
BYPASS
> IPv4-SI IPV4-SC UDP, src 1701, dst 1701
PROTECT(ESP,transport)
> IPv4-SC IPv4-SI UDP, src * , dst 1701
PROTECT(ESP,transport)
If we are using IKEv2 then some of these can be different.
In IKEv2
and RFC4301 architecture you can use the PPF flag to do some
things or
more exactly define that in the server side selectes the
port number
during the CREATE_CHILD_SA exchange and puts that in the
TSr.
Also the IKE should probably be expanded to include port
4500
(IPSEC-NAT-T).
I am also not sure I understand all of these filters,
especially why
there is IPv4 only there, but in the IPv4 over IPv6 there is
mixed
IPv4 and IPv6 addresses etc.
>
> Next Layer
> src dst Protocol
Action
> ----- ------ ----------
--------
> * IPV4-SC ESP
BYPASS
> * IPV4-SC IKE
BYPASS
> * IPV4-SC UDP, src * , dst 1701
PROTECT(ESP,transport)
>
>
>
> 3.5.5.2 IPv4 over IPv6 Softwire with example
>
> In this example, the softwire initiator and
concentrator are denoted
> with IPv6 addresses IPv6-SI and IPv6-SC
respectively.
>
>
> Next Layer
> src dst Protocol
Action
> ----- ------ ----------
--------
> IPV6-SI IPV6-SC ESP
BYPASS
> IPV6-SI IPV6-SC IKE
BYPASS
> IPv4-SI IPV6-SC UDP, src 1701, dst 1701
PROTECT(ESP,transport)
This lines seems to be wrong, usually you cannot put IPv4
and IPv6
addresses in the same packet...
> IPv4-SC IPv4-SI UDP, src * , dst 1701
PROTECT(ESP,transport)
>
>
>
> Next Layer
> src dst Protocol
Action
> ----- ------ ----------
--------
> * IPV6-SC ESP
BYPASS
> * IPV6-SC IKE
BYPASS
> * IPV6-SC UDP, src * , dst 1701
PROTECT(ESP,transport)
I think those SPD examples need some more work...
> 4. Mesh Security Guidelines
...
> 4.1 Deployment Scenario
...
> BGP speakers can inject bogus routing information,
either by
> masquerading as any other legitimate BGP speaker, or
by distributing
> unauthorized routing information as themselves. The
damage due to
> this bogus information is limited rather than eBGP
case but cannot be
> ignored.
I think some words are missing there again.
> 4.3 Softwire Security Threat Scenarios
>
> In terms of Softwire mesh solution, the security
threats are common
> to those of PPVPN. [RFC4111] But in this document,
the security
> threats on PE-PE are specifically discussed.
>
Some text missing again.
> 4.5 Guidelines for Usage of Security Protection
Mechanism
...
> 4.5.1 Security Protection Mechanism for Control Plane
...
> A BGP implementation MUST support the authentication
mechanism
> specified in RFC 2385. The authentication provided
by this mechanism
> could be done on a peer-peer basis.
>
> The mechanism defined in RFC 2385 is based on a
one-way hash function
> (MD5) and use of a secret key. The key is shared
between peer
> routers and is used to generate 16-byte message
authentication code
> values that are not readily computed by an attacker
who does not have
> access to the key.
I do not think this draft should mandate support of the
TCP-MD5 as it
is not secure enough. I think protecting BGP with IPsec
would be much
better option, especially when we are now talking about the
new
protocol which do not have existing implementations out
there.
> 4.5.1.1 TCP MD5
>
> The mandatory-to-support mechanism of TCP MD5 will
counter message
> insertion, deletion, and modification,
man-in-the-middle and denial
> of service attacks from outsiders. The use of TCP
MD5 does not
I am not sure that TCP MD5 protects against any of those
things
anymore. The MD5 attacks are getting so good that I wouldn't
be
suprised to find out that they can be used to attack TCP MD5
to do all
kind of attacks on it.
At least some kind of warning should be here, and preferably
simply
say that for softwires the TCP MD5 MUST NOT be used, but
mandate
support for IPsec or something stronger.
> 4.5.1.2 IPsec
...
> Use of TCP MD5 counters the message insertion,
deletion, and
> modification attacks, as well as man-in-the-middle
attacks by
> outsiders. If routing data confidentiality is
desired, the use of
> IPsec ESP could provide that service. But routing
data
> confidentiality is not a goal of BGP.
>
> IPsec, transport mode is used to protect BGP session
between peers.
> If eavesdropping attack against the data plane is
identified as a
> threat, ESP can be used to provide confidentiality
(encryption),
> integrity and authentication for the BGP session.
Where
> eavesdropping is not a threat, ESP without
confidentiality or AH may
> be used.
RFC4301 defines AH as MAY, so I think it might be better
here to say
that only ESP is used. AH also does not work through NATs,
which means
that AH cannot fulfill the requirement set in section 3.5.1
which says
softwire must support NAT traversal.
> To provide replay protection, automated key
management system using
> IKE must be used. IKE main mode can be used using
shared secrets for
> authentication when the number of BGP peers is
small. When the
> number of BGP peers is large managing the shared
secrets on all peers
> does not scale. In this scenario, public-key
digital signature or
> key encryption authentication in IKE should be used,
assuming that
> the peers have the necessary computation available.
This should probably explicitly mention IKEv2 instead of
refering to
IKE in general. This means also updating the IKEv1 terms
like main
mode to the terms used in the IKEv2, because using IKEv1
terms where
meaning IKEv2 just causes confusion.
> 4.5.1.3 Secure BGP
...
> The S-BGP countermeasures use IPsec, Public Key
Infrastructure (PKI)
> technology,a nd a new BGP path attribute
("attestations") to ensure
^^^^^
> the authenticity and integrity of BGP communication
on a point-to-
> point basis, and to validate BGP routing UPDATE's on
a source to
> destination basis[I-D.clynn-s-bgp-protocol].
Typo.
> To implement the secure BGP, Secure Origin BGP
(soBGP) and Pretty
> Secure BGP (psBGP) are also proposed. The detail
comparison was made
> in[Wan05].
--
kivinen safenet-inc.com
_______________________________________________
Softwires mailing list
Softwiresietf.org
http
s://www1.ietf.org/mailman/listinfo/softwires
|