Hello Hui.
On Monday 10 March 2008, Hui Deng wrote:
>
> We propose to use IKE to neogitate IPsec protected GRE key based
> tunnel as the below:
> http://tools.ietf.org/html/draft-ma-softwire-ipsec-gre-demultiplexing
>-ps-00 http://tools.ietf.org/html/draft-wu-l3vpn-ipsec-gre-00
>
> Please help to give us some comments on it,
Attached are two SECDIR reviews I did of these documents in case that is
of interest to int-area folks.
Best,
--julien
--- Begin Message ---
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.
I found it misleadling that the document is entitled "A method of using
IPsec to setup GRE tunnel" while its abstract states that "This
document describes a method of using IPsec signaling (i.e, IKE) to
setup a GRE tunnel." AFAICT, the document does not, at least in its
current incarnation, define a method to setup GRE tunnel based on
IPsec.
Currently the document simply proposes to use the GRE key [RFC2890]
within IPsec Traffic Selectors. The document is also limited to IPsec
transport mode thus ruling out access control features of IPsec tunnel
mode, i.e. SPD/SAD lookups based on fields of tunneled packets -- they
are not possible since GRE encapsulates IP packets before they are
passed to IPsec.
Thus if authors do not plan to effectively provide a method to setup GRE
tunnel based on IPsec signalling, then the document title and abstract
should be changed, e.g. "Using a GRE key within IPsec Traffic Selectors
for IPsec Transport Mode".
If, on the contrary, authors do plan to provide a method to setup GRE
tunnel based on IPsec signalling, then I think this is more than what
they propose. IPsec as defined per RFC4301 does setup tunnel only in
tunnel mode. Thus what the title refers to would imply that the
document defines a new flavor of IPsec tunnel mode based on GRE, where
SAD/SPD lookups occurs on inner packets (before tunneling), and where
IKE is used to negotiate GRE keys to be used.
Orthogonal to what scheme/model the authors want to document (GRE tunnel
mode vs. GRE key Traffic Selector), it would be good that an
explanation is given as to why that is the scheme/model chosen,
especially in terms of countermeasures to attacks possible under a
threat model that shall be made explicit. Or, as a corrolary, try to
answer to the following: why can't a single SA be used to protect all
traffic going in b/w two given GRE tunnel endpoints?
[ Non-security related: I also don't understand the story about half GRE
key, where does it come from? AFAICS RFC2890 has no notion of such half
key. Is it something specific to L3VPN? ]
Finally the first sentence of the Security Considerations section is
factually incorrect:
IPsec GRE tunnel inherits all the security features of IPsec, which
includes mutual authentication, encrytion, integrity and anti-replay
protection. Additionally, with the port selector capability on GRE
Key, the IPsec GRE tunnel can provide better access control and
differentiated security protection than an ordinary GRE tunnel
protected by IPsec transport mode.
A central feature of IPsec is access control. As transport mode applied
to tunneling, the IPsec GRE tunnel weakens the access control features
that would be present if IPsec was used in tunnel mode, i.e. SPD/SAD
lookups based on fields of inner packets. Thus I'd like the first
sentence to make it clear that IPsec GRE tunnel inherits security
features of IPsec *transport* mode applied to *tunneling*, and point
out to RFC4301 for weaknesses of such usage of IPsec.
--julien
--- End Message ---
--- Begin Message ---
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.
As a security related problem statement, the document should talk more
about security. Currently it only listes usage scenarios without
detailing the security motivation, which is what a security related
problem statement should be all about IMHO.
Section 1. Introduction states:
However there exists scenarios where multiple IPsec SAs are needed to
protect the GRE tunnel between the same pair of PEs. This documents
descirbes several scenarios where multiple IPsec SAs are needed to
protect GRE tunnels between the same pair. And currently there is no
mechanism for IPsec to demultiplexing GRE encapsulated packets. And
solution for IPsec SA to demultiplexing GRE encapsulated packets is
proposed.
Yet the the description of the scenarios poorly explains why multiple
IPsec SAs are needed.
After reading the document it is far from clear that it is needed to
provide different security services based on the GRE key.
In all the scenarios you decribe there's two ways to decide which
security services to apply to a given packet:
- either, as you propose, you assign the packet to a GRE tunnel/key
(based on forwarding decision, policy routing, whatever) and then the
choice of security services to apply is dictated by the GRE key present
as traffic selector in the IPsec SPD. Let's call that the "split"
model. Or,
- you pump the packet in the IPsec stack, and the choice of security
services to apply is dictated by the IPsec SPD alone. Let's call that
the "integrated" model.
I'm arguing that, security wise, the integrated model is better. No
system administrator is perfect. If you put all the security policy in
one place it is less error prone that to have it distributed in between
two databases (GRE key assignment database vs. SPD) since the
configuration split increase the odds of manipulation errors,
non-coordination, etc. It is also bad that the GRE configuration that
doesn't seem that security related turns out to be the place where the
security policy is really in place, since then the SPD operates only on
consequences of the GRE configuration.
It seems to me that the only point in using GRE in the context of IPsec
is to cope with overlapping addressing space, e.g. RFC1918 addresses.
If that's the case a simpler solution would be for the IPsec
implementation to support per-interface SPD, as was the case with
RFC2401. If that is not sufficient, that is the role of a problem
statement to explain why it is not...
I also think that the point of discriminating multicast vs. unicast is
moot since multicast traffic is sent to a multicast address and that
can simply be used in a Traffic Selector.
Finally the document claims that it is better to have multiple SA rather
than one SA to protect different VPNs since the compromise of one SA
doesn't affect all VPNs, yet it doesn't explain how that SA would be
compromised, and why the other SAs wouldn't be compromised as well if
one SA could be. That should be rationalized.
--julien
--- End Message ---
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
