[Ipsec] Comments to draft-declercq-l3vpn-ce-based-as-00.txt

[Tero Kivinen <kivinen@xxxxxx>]

This document really should expand CE when it is used first time in
the abstract... 

> 13. QoS, SLA
> 
>    In addition to the VPN service (reachability and security) from the
>    SP, the VPN customer may want to acquire QoS features for its VPN.
>    Dependent on the business scenario, the SLA will be provided by the
>    VPN SP or by the Network Provider.
> 
>    Note that the fact that customer IP packets are encapsulated (and
>    possibly encrypted) at the CE devices has an impact on the QoS
>    treatment of the IP packets: QoS-related information inside the
>    customer IP packets may become invisible.
> 
>    An eventual translation of QoS-related fields (e.g. DSCP) in the
>    inner IP header to QoS-related fields in the outer IP headers need to
>    be done at the CE-level and configured as such by the SP. Also the
>    'policing' rules (e.g. certain customers not being allowed to use
>    certain QoS values, etc.) need to be configured by the SP in the CE
>    devices. The security infrastructure of the CE device must prevent
>    the customer from messing with this provider-controlled
>    configuration.
> 
>    The CE-CE tunneling applied in Provider Provisioned CE-based IPsec
>    VPNs easily meets the DSCP transparency requirements of [REQS].

Note, that if packets having different QoS parameters are put inside
one IPsec SA tunnel, and the packets are really processed differently
by the network, this may cause the responder to drop all low priority
packets as the high priority packets which have passed those low
priority packets in the network have already made replay window to go
too far. I.e. low priority packets might take too long to travel
inside the network so that when they finally end to the destination
the destination cannot process them as they are outside the replay
protection window.

The solution to this in the RFC 4301 IPsec Security Architecture is to
create multiple IPsec SAs between the nodes and send only traffic
having similar QoS parameters to one SA.

This does affect the scalability (i.e. section 12) as it raises the
number of IPsec SAs, but each of those IPsec SA can share the same IKE
SA and interface, routing information etc.

I think something about this should be mentioned in the section 13.

See section 4.1 (last paragraph of the page 13) of the RFC 4301 for
more information.

Other comments:

> 14.4 Security
> 
>    The security aspects of the VPN management system are extremely
>    important.
> 
>    De SP's management system itself needs to be secured against
     ^^
???

>    misconfiguration, intrusion and denial-of-service attacks.
> 
>    De management protocol that is used to remotely provision the CE
     ^^
???

>    devices needs to provide for mutual authentication, encryption of the
>    transported data, etc.

The references section does not have normative / informative
references split, and I think it should have referenses at least to
IPsec architecture RFC 4301, and IKEv2 RFC 4306.
-- 
kivinen@xxxxxxxxxxxxxxx

_______________________________________________
Ipsec mailing list
Ipsec@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ipsec