[Softwires] Review of the draft-ietf-softwire-security-requirements-01.txt

[Tero Kivinen <[e-mail]>]

>               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].
-- 
[e-mail]

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