Re: [IPsec] Other documents to upgrade to internet standard

[Yaron Sheffer]

Hi Tero,

On 2013-11-06 02:23, Tero Kivinen wrote:

While we are working on the ESP, AH, IKEv2, and Architecture
documents, I think we should do also the easy ones:

- RFC2451 "The ESP CBC-Mode Cipher Algorithms"


This is nominally a generic document, but it's really about a list of 
specific algorithms, none of which is in wide use today (we are trying 
to phase out 3DES and in general 64-bit block algorithms). This document 
is not referenced by RFC 4303. So I don't think we should upgrade it.



- RFC3526 "More Modular Exponential (MODP) Diffie-Hellman groups for
   Internet Key Exchange"


Yes, probably. Although crypto recommendations are time-dependent, this 
RFC describes the actual algorithms and not just their use in IKE.


Do we have enough implementations of EC groups to progress RFC 5903? I 
realize that NSA RFCs are not that popular nowadays...



- RFC3948 "UDP Encapsulation of IPsec ESP Packets"


Definitely.



None of them has Errata, and they are all widely used, so we should
just upgrade them on in place (i.e. no need to get new RFC).


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] AD VPN: discussion kick off

[Stephen Kent]

Manish,

Steve,

To answer your question, the SPD entries are not already there, they 
are created as the result of a message exchange between the two 
spokes; it's the spokes that choose the policy, not the hub. If the 
SPDs were already there, every IPSec node in the network would need to 
know about all the networks in the overall topology apriori -- to 
solve this is one of the main drivers of the whole exercise. This 
becomes even more complex if the hosts (not necessarily an IPSec node) 
acquire address dynamically and/or are mobile.
So the spokes, while connected through the hub, exchange messages to 
cause SPD entries to be created. What protocol is used to do this?


Steve

p.s. please use the correct (vs.the Cisco-preferred?) spelling, i.e., 
IPsec, vs. IPSec.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Other documents to upgrade to internet standard

[Tero Kivinen]

While we are working on the ESP, AH, IKEv2, and Architecture
documents, I think we should do also the easy ones:

- RFC2451 "The ESP CBC-Mode Cipher Algorithms"
- RFC3526 "More Modular Exponential (MODP) Diffie-Hellman groups for
  Internet Key Exchange"
- RFC3948 "UDP Encapsulation of IPsec ESP Packets"

None of them has Errata, and they are all widely used, so we should
just upgrade them on in place (i.e. no need to get new RFC). 
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Query regarding Qos with IKE

[Michael Richardson]

Tero Kivinen  wrote:
> Michael Richardson writes:
>> For a given IPsec SA, they want to overwrite/force/set the DSCP to a
>> particular value.  It will not depend upon the traffic goes into it
>> (but, the SPD selectors may quite specificly pick the traffic).

> If I think RFC4301 already requires that. I.e. it requires
> implementations to be able to map DSCP values to suitable value. If
> the sender knows how to pick up suitable DSCP values and they are then
> tunneled through the IPsec tunnel, then the receiving GW can use those
> to map those values to the suitable values for the other domain.

Yes, I did quote the part of 4301 that mandates that it be settable.

> I am missing how does the trasmitting this information from SGW to SGW
> affect the IPsec processing? I do not think we should use IKE as
> transmitting all kind of stuff that other end might be interested in.

It does not affect any processing. Who said that it did?

The question is, how does the UE know what DSCP to put on the ESP packet?
Yes, it could come from another protocol, but which?  IKE already did the
authentication, and so already established what entity is asking for service.
One might statically configure things, but if the UE moves around the exact
DSCP might change.  

As David Black pointed out, there might be Diffserv boundaries.  In that
case, the UE has to put the DSCP appropriate for the network the UE is
attached to, and for things to work, there either has to be DSCP rewriting
occuring at the diffserv boundary. But, all that matters is that the UE put
the DSCP in, the network takes care of the rest.h
The gateway might know where the diffserv boundaries are by special
knowledge, but there is no reason to need to tell the UE about it.

-- 
Michael Richardson , Sandelman Software Works 




pgp0bitwXOlPT.pgp
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] AD VPN: discussion kick off

[Yoav Nir]

On Nov 5, 2013, at 1:45 PM, Paul Wouters  wrote:

> On Tue, 5 Nov 2013, Manish Kumar (manishkr) wrote:
> 
>> "I don't like that DMVPN does not let http traffic continue to travel via
>> HQ's
>> virus/trojan/netnanny while RTP takes the shortcut."
>> 
>> While I do appreciate that the following could represent a valid used
>> case, it would be inaccurate to say DMVPN doesn't allow this. It does
>> allow but not using the IPSec tools; the protocol programming the
>> forwarding layer(could be policy based) controls what goes via the hub as
>> opposed to what goes on the shortcut tunnel. Also, I would see this more
>> as a path selection problem more than 'the kind of security treatment a
>> certain class of traffic needs' - it's another matter that different paths
>> provide different security services/treatment. Since, the network topology
>> information and hence the path that a class of traffic may take is not
>> privy to IKE/IPSec, it's only appropriate that a protocol aware about this
>> takes this call. This is the reason I don't concur with your other comment
>> about doing this in IKE.
> 
> Couldn't that policy be exposed in IKE using traffic selectors for port
> 80 or 443? In all of the three proposed solutions?

Not really. In DMVPN the only selectors are {Gw-IP, GW-IP, Proto=47}, because 
everything goes through a GRE tunnel. 

In draft-mao it's IPsec tunnels, but they still use universal selectors and 
selecting traffic through a routing protocol. 

In both cases you can get what you're looking for if you have routing based on 
port. It's only in draft-sathyanarayan that you can do that with IPsec traffic 
selectors.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] AD VPN: discussion kick off

[Manish Kumar (manishkr)]

Steve,

To answer your question, the SPD entries are not already there, they are 
created as the result of a message exchange between the two spokes; it's the 
spokes that choose the policy, not the hub. If the SPDs were already there, 
every IPSec node in the network would need to know about all the networks in 
the overall topology apriori – to solve this is one of the main drivers of the 
whole exercise. This becomes even more complex if the hosts (not necessarily an 
IPSec node) acquire address dynamically and/or are mobile.

Thanks,
Manish

From: Stephen Kent mailto:k...@bbn.com>>
Date: Wednesday, 6 November 2013 3:51 AM
To: Mike Sullenberger mailto:m...@cisco.com>>, ipsec 
mailto:ipsec@ietf.org>>
Subject: Re: [IPsec] AD VPN: discussion kick off

Mike,

Thanks for the responses to my comments, including ones from yesterday's 
meeting.
Steve,

Sorry, I wasn’t clear on our use of IPsec. We definitely use both the 
authentication and encryption capabilities of IPsec. We do the following when 
bringing up a new tunnel.

  1.  Trigger ISAKMP/IKEv2/IPsec with an SPD of (LocalPeer IP, RemotePeer IP, 
GRE).
  2.  ISAKMP/IKEv2 authenticates the peers, creates the IKE SAs and the 
IPsec/Child encryption SAs.
  3.  IPsec signals it has authenticated and encryption is ready, the GRE 
tunnel is activated.
  4.  NHRP registration (for spoke-hub) or resolution reply (for final phase of 
spoke-spoke) are sent over the tunnel.
  5.  Routing is brought up over the spoke-hub tunnels.

If a shortcut between two spokes is available, as advised by a hub, that 
requires an SDP entry. Did that entry preexist in the spoke, or was it 
provisioned by a hub in some fashion? If it existed in the spoke, initially, 
"normal" IPsec operation would cause traffic to that spoke to trigger formation 
of an SA to that destination. Can you clarify?
 As for scaling, we already have DMVPN networks of 1+ nodes and looking at 
building networks of 4+ nodes.
In many cases customers have multiple subnets behind each node, therefore with 
just IPsec I would need to have multiple SAs/encryption between the same two 
nodes, even if you are only doing subnet to subnet SPDs.  Take the case of two 
nodes that each have 4 subnets. I could need as many as 16 SAs to cover all 
cases.  Or even a simpler case between a host (1 local address) and a node at a 
data center (say 20 subnets), I would need up to 20 SAs to cover this.  In many 
of our networks we are asked to support at least 5 (sometimes 10) subnets per 
spoke location.
That's a helpful clarification. It does not appear to be the sort of 
environment that initially seemed to be the focus of this work, e.g., road 
warriors calling home or home/satellite offices for a moderate size enterprise.
 As far as IPv4 and IPv6 support, you are correct it would only double the 
number of SAs needed, assuming that there are the same number of subnets for 
IPv4 and IPv6.  From what I have seen IPv6 tends to increase the number of 
subnets.
I'm glad we're on the same page here.
 For end-to-end encryption, take the case where a spoke node is a host.  Then 
initially the spoke/host will connect to one or more hubs (we recommend at 
least 2 for redundancy).  Communication between two such connected hosts would 
be through the hub and would be two hops (Host1 encrypt-decrypt Hub 
encrypt-decrypt Host2). Once the shortcut tunnel is setup then communication 
would be direct between the hosts (Host1 encrypt-decrypt Host2).
see my question re the shortcut SPD entries.

Steve
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] AD VPN: discussion kick off

[Stephen Kent]

Manish,

Hi Stephen,

Thanks for your inputs  vis-a-vis  4301/2/3. I concur that IPSec is 
not just about encryption but don't quite buy into what somebody 
spelled out during the meeting as 'IPSec is an access control 
mechanism that also provides other security services'; IMO, strict 
access control is more a firewall functionality. RFC 4301 spells out 
the access control rationale as
"IPsec includes a specification for minimal firewall functionality, 
since that is an essential aspect of access control at the IP layer... 
The IPsec firewall function makes use of the 
cryptographically-enforced authentication and integrity provided for 
all IPsec traffic to offer better access control than could be 
obtained through use of a firewall (one not privy to IPsec internal 
parameters) plus separate cryptographic protection."


You cited one of several sentences that mention access control in 4301, 
in Section 2.1.  Other quotes, very close to the one you chose, make a 
stronger case for access control as an important element of IPsec:


   The set of

security services offered includes access control, connectionless

integrity, data origin authentication, detection and rejection of

replays (a form of partial sequence integrity), confidentiality (via

encryption), and limited traffic flow confidentiality.

and

   The IPsec firewall function makes use of the

cryptographically-enforced authentication and integrity provided for

all IPsec traffic to offer better access control than could be

obtained through use of a firewall (one not privy to IPsec internal

parameters) plus separate cryptographic protection.


This second quote notes that a separate firewall, operating at the 
Internet layer, is

NOT as secure as the one integrated into IPsec.

I know that we might have ruffled a few feathers wrt making the SPD 
relatively trivial but let's get down to some details as far as the 
comparison goes. The first ADVPN proposal does talk about the shortcut 
suggester possibly including traffic selectors in the shortcut 
exchange. While this seems to give the notion of the ability to 
provide SA granularity, the source of such information is a third 
party (even though both peers have an active connection with this 
third party) and doesn't quite stand up to the very reason of 
including access control in IPSec (The IPsec firewall function makes 
use of the cryptographically-enforced authentication and integrity 
provided for all IPsec traffic to offer better access control than 
could be obtained through use of a firewall (one not privy to IPsec 
internal parameters) plus separate cryptographic protection.) - this 
is a case of the information not even privy to the same device, leave 
alone the same layer in the same device.
OK, this paragraph shows that you do understand the importance of the 
internal firewall in an IPsec implementation. I'm not asserting that 
ADVPN is better or worse in this regard. I just happened to be alerted 
to the issue by the DMVPN message from Mike. I'm equally disappointed 
with any proposal that essentially eliminates the access control feature 
;-) .


Steve
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] AD VPN: discussion kick off

[Stephen Kent]

Mike,

Thanks for the responses to my comments, including ones from yesterday's 
meeting.

Steve,
Sorry, I wasn't clear on our use of IPsec. We definitely use both the 
authentication and encryption capabilities of IPsec. We do the 
following when bringing up a new tunnel.


 1. Trigger ISAKMP/IKEv2/IPsec with an SPD of (LocalPeer IP,
RemotePeer IP, GRE).
 2. ISAKMP/IKEv2 authenticates the peers, creates the IKE SAs and the
IPsec/Child encryption SAs.
 3. IPsec signals it has authenticated and encryption is ready, the
GRE tunnel is activated.
 4. NHRP registration (for spoke-hub) or resolution reply (for final
phase of spoke-spoke) are sent over the tunnel.
 5. Routing is brought up over the spoke-hub tunnels.

If a shortcut between two spokes is available, as advised by a hub, that 
requires an SDP entry. Did that entry preexist in the spoke, or was it 
provisioned by a hub in some fashion? If it existed in the spoke, 
initially, "normal" IPsec operation would cause traffic to that spoke to 
trigger formation of an SA to that destination. Can you clarify?
As for scaling, we already have DMVPN networks of 1+ nodes and 
looking at building networks of 4+ nodes.
In many cases customers have multiple subnets behind each node, 
therefore with just IPsec I would need to have multiple SAs/encryption 
between the same two nodes, even if you are only doing subnet to 
subnet SPDs.  Take the case of two nodes that each have 4 subnets. I 
could need as many as 16 SAs to cover all cases.  Or even a simpler 
case between a host (1 local address) and a node at a data center (say 
20 subnets), I would need up to 20 SAs to cover this.  In many of our 
networks we are asked to support at least 5 (sometimes 10) subnets per 
spoke location.
That's a helpful clarification. It does not appear to be the sort of 
environment that initially seemed to be the focus of this work, e.g., 
road warriors calling home or home/satellite offices for a moderate size 
enterprise.
As far as IPv4 and IPv6 support, you are correct it would only double 
the number of SAs needed, assuming that there are the same number of 
subnets for IPv4 and IPv6.  From what I have seen IPv6 tends to 
increase the number of subnets.

I'm glad we're on the same page here.
For end-to-end encryption, take the case where a spoke node is a 
host.  Then initially the spoke/host will connect to one or more hubs 
(we recommend at least 2 for redundancy). Communication between two 
such connected hosts would be through the hub and would be two hops 
(Host1 encrypt-decrypt Hub encrypt-decrypt Host2). Once the shortcut 
tunnel is setup then communication would be direct between the hosts 
(Host1 encrypt-decrypt Host2).

see my question re the shortcut SPD entries.

Steve
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] AD VPN: discussion kick off

[Paul Wouters]

On Tue, 5 Nov 2013, Manish Kumar (manishkr) wrote:


"I don't like that DMVPN does not let http traffic continue to travel via
HQ's
virus/trojan/netnanny while RTP takes the shortcut."

While I do appreciate that the following could represent a valid used
case, it would be inaccurate to say DMVPN doesn't allow this. It does
allow but not using the IPSec tools; the protocol programming the
forwarding layer(could be policy based) controls what goes via the hub as
opposed to what goes on the shortcut tunnel. Also, I would see this more
as a path selection problem more than 'the kind of security treatment a
certain class of traffic needs' - it's another matter that different paths
provide different security services/treatment. Since, the network topology
information and hence the path that a class of traffic may take is not
privy to IKE/IPSec, it's only appropriate that a protocol aware about this
takes this call. This is the reason I don't concur with your other comment
about doing this in IKE.


Couldn't that policy be exposed in IKE using traffic selectors for port
80 or 443? In all of the three proposed solutions?

Paul
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] AD VPN: discussion kick off

[Manish Kumar (manishkr)]

Michael,

"I don't like that DMVPN does not let http traffic continue to travel via
HQ's
virus/trojan/netnanny while RTP takes the shortcut."

While I do appreciate that the following could represent a valid used
case, it would be inaccurate to say DMVPN doesn't allow this. It does
allow but not using the IPSec tools; the protocol programming the
forwarding layer(could be policy based) controls what goes via the hub as
opposed to what goes on the shortcut tunnel. Also, I would see this more
as a path selection problem more than 'the kind of security treatment a
certain class of traffic needs' - it's another matter that different paths
provide different security services/treatment. Since, the network topology
information and hence the path that a class of traffic may take is not
privy to IKE/IPSec, it's only appropriate that a protocol aware about this
takes this call. This is the reason I don't concur with your other comment
about doing this in IKE.

Cheers,
Manish


On 03/11/13 12:47 AM, "Michael Richardson"  wrote:

>
>{Sorry about that, the email configuration my tablet had a \n in a header
>that did not belong}
>
>I have read all three proposals, although I missed the Q&A in Berlin.
>I am looking forward to further Q&A in Berlin.
>
>When I read the NBMA protocol (DMVPN, I think) version what I saw was a
>very
>brilliant hack that managed to take two code bases (IPsec and ATM) that
>were
>likely already present in that vendor's firmware and connect them.
>Likely,
>it took only a few weeks of brilliant hacking, and it was ready for
>customer use.
>
>I find that this solution for anyone else involves the most amount of new
>code,
>and I think it will the most difficult to support on various mobile and
>laptop 
>platforms as it requires new encapsulation modes.
>
>draft-mao-ipsecme is architecturally the closest to me, and I like the ADS
>idea: it seems that it be implemented without any new kernel code, and I
>think that if we are trying  to get remote warrior and branch office RTP
>traffic to take a more direct route, then  eliminating the need for a more
>network plumbing, and just doing things in IKE is the right answer.  (%)
>
>I don't like having a new protocol: I want it in IKE.  While it can and
>should run inside the tunnel, I don't see why adding a new port to my IKE
>daemon makes my life easier.
>
>I *do* like the way that DMVPN uses probe packets to discover the end
>points of 
>the shorter routes, and I would look forward to including that mechanism
>somehow.  I don't know how to do that without hacks to the data plane,
>which
>I'd like to avoid.  I can imagine some ways to do this with a traceroute
>process, but it seems kludgy and brittle. (really, that's still dataplane,
>but it's using an existing mechanism)
>
>I don't like that DMVPN does not let http traffic continue to travel via
>HQ's
>virus/trojan/netnanny while RTP takes the shortcut.
>
>
>(%)- the plumbing might need a way to sample 5-tuple flows to see if there
>is traffic that should be shortcut. However, various schemes to put more
>specific SPD entries in that cause key requests might accomplish this
>without  
>new kernel code.
>
>--
>Michael Richardson
>-on the road-
>
>-- 
>Michael Richardson , Sandelman Software Works
>
>

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] AD VPN: discussion kick off

[Manish Kumar (manishkr)]

Hi Stephen,

Thanks for your inputs  vis-a-vis  4301/2/3. I concur that IPSec is not just 
about encryption but don't quite buy into what somebody spelled out during the 
meeting as 'IPSec is an access control mechanism that also provides other 
security services'; IMO, strict access control is more a firewall 
functionality. RFC 4301 spells out the access control rationale as
"IPsec includes a specification for minimal firewall functionality, since that 
is an essential aspect of access control at the IP layer… The IPsec firewall 
function makes use of the cryptographically-enforced authentication and 
integrity provided for all IPsec traffic to offer better access control than 
could be obtained through use of a firewall (one not privy to IPsec internal 
parameters) plus separate cryptographic protection."

I know that we might have ruffled a few feathers wrt making the SPD relatively 
trivial but let's get down to some details as far as the comparison goes. The 
first ADVPN proposal does talk about the shortcut suggester possibly including 
traffic selectors in the shortcut exchange. While this seems to give the notion 
of the ability to provide SA granularity, the source of such information is a 
third party (even though both peers have an active connection with this third 
party) and doesn't quite stand up to the very reason of including access 
control in IPSec (The IPsec firewall function makes use of the 
cryptographically-enforced authentication and integrity provided for all IPsec 
traffic to offer better access control than could be obtained through use of a 
firewall (one not privy to IPsec internal parameters) plus separate 
cryptographic protection.) - this is a case of the information not even privy 
to the same device, leave alone the same layer in the same device.

Let's say, the shortcut suggester passes on an information in the shortcut 
exchange to the two peers about the selectors (X->Y) to be used for the 
shortcut while selectors (X'->Y') be still allowed through the spoke-hub-spoke 
path. It's entirely upto the peers (shortcut partners) to choose what to do 
with that; well, the draft prescribes that the shortcut partners should use 
this but when we are talking about multi-vendor, multiple administrative 
domains, how do we trust that the shortcut partners do that. We must realise 
that the role of the suggester/hub is more advisory in nature; it can only 
advise not enforce. The problem is a system wide design problem not one to be 
sorted out just between two nodes (and IKE is intrinsically designed to operate 
in a peer-to-peer model), so e.g. even if policies prescribe (as obtained from 
the shortcut exchange) that a certain traffic be routed via the hub, once the 
two peers(shortcut partners) have all the authentication information for each 
other, they might give a damn and say we don't care, lets bypass the policy and 
use the shortcut for everything leaving the hub in dark. Unlike a traditional 
IPSec case, where each peer could enforce specific access control policies 
(e.g. if the peer you negotiated an SA with sends a traffic using an SA which 
was not supposed to be used for that traffic, you could simply drop it post 
decryption), the hub can't enforce such policies – it can dictate what doesn't 
pass through it but not what MUST pass through it, which is what the common 
requirement is.

What all this effectively means is if really need to enforce access-control 
policies, it has to be agreed between the spokes/shortcut partners, not 
prescribed by the hub. IPSec typically deals with a case where the SPD is in 
place apriori based on which SAs are negotiated but here we end up with a case 
where the SPDs need to be negotiated and agreed upon as well !!! In that sense, 
I would say DMVPN still provides better access control – it already determines 
what portion of the network should use the shortcut depends on the 
address/subnet sent in NHRP resolution reply. This is used to install shortcut 
routes and/or policy based routes and the same can be used to also install an 
ACL if we suspect the peer to play foul. It's another matter that this is not 
as part of IPSec access control directly. This is on top of the 
route/forwarding policy based tunnel selection.

- Manish

From: Stephen Kent mailto:k...@bbn.com>>
Date: Tuesday, 5 November 2013 3:27 AM
To: Mike Sullenberger mailto:m...@cisco.com>>, Michael 
Richardson mailto:mcr+i...@sandelman.ca>>
Cc: "Stephen Lynn (stlynn)" mailto:stl...@cisco.com>>, 
"draft-detienne-dm...@tools.ietf.org"
 
mailto:draft-detienne-dm...@tools.ietf.org>>,
 Mark Comeadow mailto:mcome...@cisco.com>>, "Michael 
Guilford (mguilfor)" mailto:mguil...@cisco.com>>, IPsecme 
WG mailto:ipsec@ietf.org>>
Subject: Re: [IPsec] AD VPN: discussion kick off
Resent-From: 
mailto:draft-alias-boun...@tools.ietf.org>>
Resent-To: Frederic Detienne mailto:f...@cisco.com>>, Manish 
Kumar mailto:manis...@cisco.com>>, Mike

Re: [IPsec] AD VPN: discussion kick off

[Mike Sullenberger (mls)]

Steve,

Sorry, I wasn't clear on our use of IPsec. We definitely use both the 
authentication and encryption capabilities of IPsec. We do the following when 
bringing up a new tunnel.
1.  Trigger ISAKMP/IKEv2/IPsec with an SPD of (LocalPeer IP, RemotePeer IP, 
GRE).
2.  ISAKMP/IKEv2 authenticates the peers, creates the IKE SAs and the 
IPsec/Child encryption SAs.
3.  IPsec signals it has authenticated and encryption is ready, the GRE 
tunnel is activated.
4.  NHRP registration (for spoke-hub) or resolution reply (for final phase 
of spoke-spoke) are sent over the tunnel.
5.  Routing is brought up over the spoke-hub tunnels.
Also to be clear there are NO packets, control or data plan, that are 
transferred between the peers outside of the GRE/IPsec encrypted tunnel, except 
for ISAKMP/IKEv2.  On a router/FW in the middle it would only "see" UDP 
500/4500 and ESP (IP 50) packets. Note, you can also use AH, but we generally 
recommend not to use AH and AH breaks NAT support.

As for scaling, we already have DMVPN networks of 1+ nodes and looking at 
building networks of 4+ nodes.
In many cases customers have multiple subnets behind each node, therefore with 
just IPsec I would need to have multiple SAs/encryption between the same two 
nodes, even if you are only doing subnet to subnet SPDs.  Take the case of two 
nodes that each have 4 subnets. I could need as many as 16 SAs to cover all 
cases.  Or even a simpler case between a host (1 local address) and a node at a 
data center (say 20 subnets), I would need up to 20 SAs to cover this.  In many 
of our networks we are asked to support at least 5 (sometimes 10) subnets per 
spoke location.

As far as IPv4 and IPv6 support, you are correct it would only double the 
number of SAs needed, assuming that there are the same number of subnets for 
IPv4 and IPv6.  From what I have seen IPv6 tends to increase the number of 
subnets.

For end-to-end encryption, take the case where a spoke node is a host.  Then 
initially the spoke/host will connect to one or more hubs (we recommend at 
least 2 for redundancy).  Communication between two such connected hosts would 
be through the hub and would be two hops (Host1 encrypt-decrypt Hub 
encrypt-decrypt Host2). Once the shortcut tunnel is setup then communication 
would be direct between the hosts (Host1 encrypt-decrypt Host2).

Thanks,

Mike.

[X]
Mike Sullenberger, DSE
m...@cisco.com.:|:.:|:.
Customer Advocacy  CISCO



From: Stephen Kent [mailto:k...@bbn.com]
Sent: Monday, November 04, 2013 1:57 PM
To: Mike Sullenberger (mls); Michael Richardson
Cc: Stephen Lynn (stlynn); draft-detienne-dm...@tools.ietf.org; Mark Comeadow 
(mcomeado); Michael Guilford (mguilfor); IPsecme WG
Subject: Re: [IPsec] AD VPN: discussion kick off

Mike,

A couple of your comments caught my attention, as an author of 4301, 02, and 
03. I admit to not having read the DMVPN proposal, so my comments are based 
only on your message, which argues why DMVPN is the preferred solution.

IPsec encryption layer.  In this layer ISAKMP/IKEv2/IPsec is the correct 
standard protocol to use.  This is what IPsec does really well, encrypt 
traffic. The layers above greatly simplifies IPsec's job by presenting to it 
the tunnel to encrypt instead of all of the individual protocols/subnets/flows 
that are within the tunnel.  The IPsec selectors are now for the tunnel, which 
makes path redundancy and load-balancing  doable. IPsec doesn't deal well with 
the same set of selectors to encrypt traffic to more than one peer.  With DMVPN 
this is handled at the routing/forwarding and GRE tunnel layers.
IPsec is not just about encryption, although the DMVPN proposal may relegate it 
to that. IPsec provides access control, and, typically, authentication.  Does 
DMVPN preserve the access control features of IPsec, or are users now relying 
on a hub to do this, or what?

 ...  With 10s of thousands of nodes and perhaps 100s of thousands of 
network/subnets reachable via the VPN the number of IPsec selectors across the 
VPN would get completely out of hand, especially if each different pair of 
subnets (selector) requires a separate encryption, between the same two nodes.
More properly, a separate SA, and only if the folks who manage policies at each 
end of the SA decide to provide fine-grained access control for the traffic 
flows. It was not clear to me that the problem statement for this work 
envisioned VPNs of the scale you mention. Also, the comments above are a bit 
confusing. Both end points and security gateways are "nodes" wrt IPsec, in the 
general sense. I can create a selector that secures traffic from my node (and 
point of subnet) to all hosts on a subnet, irrespective of how many are present 
there.

This doesn't even count the fact that in order to run IPv4 and IPv6 between the 
same two nodes you have to use at least double the number of selectors.
At least? Under what circumstances would the number grow by mo

Re: [IPsec] AD VPN: discussion kick off

[Frederic Detienne (fdetienn)]

Hi Stephen,

please find some answers inline.

On 04 Nov 2013, at 22:57, Stephen Kent  wrote:

> Mike,
> 
> A couple of your comments caught my attention, as an author of 4301, 02, and 
> 03. I admit to not having read the DMVPN proposal, so my comments are based 
> only on your message, which argues why DMVPN is the preferred solution.
>> IPsec encryption layer.  In this layer ISAKMP/IKEv2/IPsec is the correct 
>> standard protocol to use.  This is what IPsec does really well, encrypt 
>> traffic. The layers above greatly simplifies IPsec's job by presenting to it 
>> the tunnel to encrypt instead of all of the individual 
>> protocols/subnets/flows that are within the tunnel.  The IPsec selectors are 
>> now for the tunnel, which makes path redundancy and load-balancing  doable. 
>> IPsec doesn't deal well with the same set of selectors to encrypt traffic to 
>> more than one peer.  With DMVPN this is handled at the routing/forwarding 
>> and GRE tunnel layers.
> IPsec is not just about encryption, although the DMVPN proposal may relegate 
> it to   that. IPsec provides access control, and, typically, 
> authentication.  Does DMVPN preserve the access control features of IPsec, or 
> are users now relying on a hub to do this, or what?

The proposal relies on everything IKE and IPsec do today. All the cryptography 
and authentication/authorization mechanisms remain between hub&spokes as well 
as between spokes.

All the access control features of IPsec and IKE remain untouched.

NHRP only facilitates the network and peer discovery.


>>  ...  With 10s of thousands of nodes and perhaps 100s of thousands of 
>> network/subnets reachable via the VPN the number of IPsec selectors across 
>> the VPN would get completely out of hand, especially if each different pair 
>> of subnets (selector) requires a separate encryption, between the same two 
>> nodes. 
> More properly, a separate SA, and only if the folks who manage policies at 
> each end of the SA decide to provide fine-grained access control for the 
> traffic flows. It was not clear to me that the problem statement for this 
> work envisioned VPNs of the scale you mention. Also, the comments above are a 
> bit confusing. Both end points and security gateways are "nodes" wrt IPsec, 
> in the general sense. I can create a selector that secures traffic from my 
> node (and point of subnet) to all hosts on a subnet, irrespective of how many 
> are present there.  
>> This doesn’t even count the fact that in order to run IPv4 and IPv6 between 
>> the same two nodes you have to use at least double the number of selectors.
> At least? Under what circumstances would the number grow by more than a 
> factor of two?

I am not sure I understand your comment. Here is what we are trying to say: 
Assuming two nodes A and B hosting subnets A1, A2 and B1, B2 respectively (A* 
and B* not summarizable), the selectors between A and B have a form

A1-B1
A1-B2
A2-B1
A2-B2

yielding up to A# x B# selectors. There can be thousands of A* and B*.

Can you elaborate please ?


>> Routing protocols are already designed to scale to 100s of thousands and 
>> even millions of routes. So with DMVPN the forwarding and GRE tunneling of 
>> both IPv4 and IPv6 is handled within a single GRE tunnel and IPsec selector.
> So, the proposal simplifies use of IPsec by limiting the granularity at which 
> SAs may be created? Does it also cause each SA to terminate at a hub, so that 
> the security services are no longer e-t-e?  In the context of the perpass 
> discussions, this seems like a questionable design decision.

Each SA is established between the spokes and the entire IKE/IPsec negotiation 
takes place between the spokes. The hub does not act as a broker.

thanks,

fred

>  
> Steve

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Query regarding Qos with IKE

[Tero Kivinen]

Michael Richardson writes:
> For a given IPsec SA, they want to overwrite/force/set the DSCP to a
> particular value.  It will not depend upon the traffic goes into it
> (but, the SPD selectors may quite specificly pick the traffic).

If I think RFC4301 already requires that. I.e. it requires
implementations to be able to map DSCP values to suitable value. If
the sender knows how to pick up suitable DSCP values and they are then
tunneled through the IPsec tunnel, then the receiving GW can use those
to map those values to the suitable values for the other domain.

As the IPsec processing is not affected by that mapping, there is no
point of negotiating it in the IKE. The DSCP can be used as classifier
which selects which packets are put to which SA, and this is required
because of the reordering problems, and this is already handled in the
IPsec.

I am missing how does the trasmitting this information from SGW to SGW
affect the IPsec processing? I do not think we should use IKE as
transmitting all kind of stuff that other end might be interested in.
It is better to use some protocol suitable for it. For example our
configuration payload tries to send only minimal set of parameters
which affect the IPsec processing (yes, there are some extra there
like DNS, and NBNS), and rest of the configuration parameters should
be gotten from the DHCP server (whose address is sent inside the
configuration payload).
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Query regarding Qos with IKE

[Praveen Sathyanarayan]

Hi Paul,

Extracts from 4301: Section 4.1


Distribution of traffic among these
   parallel SAs to support QoS is locally determined by the sender and
   is not negotiated by IKE.  The receiver MUST process the packets from
   the different SAs without prejudice.  These requirements apply to
   both transport and tunnel mode SAs.  In the case of tunnel mode SAs,
   the DSCP values in question appear in the inner IP header.  In
   transport mode, the DSCP value might change en route, but this should
   not cause problems with respect to IPsec processing since the value
   is not employed for SA selection and MUST NOT be checked as part of
   SA/packet validation.  However, if significant re-ordering of packets
   occurs in an SA, e.g., as a result of changes to DSCP values en
   route, this may trigger packet discarding by a receiver due to
   application of the anti-replay mechanism.



DISCUSSION: Although the DSCP , Gro02 and Explicit
   Congestion Notification (ECN)  fields are not "selectors",
   as that term in used in this architecture, the sender will need a
   mechanism to direct packets with a given (set of) DSCP values to the
   appropriate SA.  This mechanism might be termed a "classifier".



[PRAVEEN] Does this answers your question? Looks like it was intentionally
not negotiated in IKE. And it looks like implementation decision on when
to negotiate multiple child SAs and how senders makes decision to put
which packet in which SA.

‹ Praveen 


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Query regarding Qos with IKE

[Michael Richardson]

Yoav Nir  wrote:
> Is what you're looking for multiple DS for the same selectors, or just a 
single
> DS for each set of selectors, that is determined by the AC?

For a given IPsec SA, they want to overwrite/force/set the DSCP to a
particular value.  It will not depend upon the traffic goes into it
(but, the SPD selectors may quite specificly pick the traffic).

-- 
Michael Richardson , Sandelman Software Works 




pgpMgR0C5d7B3.pgp
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Query regarding Qos with IKE

[Michael Richardson]

Black, David  wrote:
> Be careful ? if the IPsec SA or tunnel crosses diffserv domains, the 
outer DSCP
> won?t have the same meaning at both ends.

True, but let's no boil any oceans here.

> The initial solution looks like it?s single-domain ? access concentrator 
to
> client on a single network.  Nonetheless, the solution needs to be 
designed for
> at least a couple of things beyond one DSCP and one domain, even if they 
won?t
> be used initially:

Yes.

> - Detect Diffserv domain crossing that makes DSCP not usable by client

How could one do this?

> - Multiple DSCPs are involved, e.g., AF drop precedence with multiple 
DSCPs is
> being used with rate-based traffic shaping.

I don't think that they need multiple DSCPs.
I think that they simply want to ask the UE to use a particular code point.

It seems like a very simple Notification would work fine, and I think that
the people doing this are in control of the IKE/IPsec stack on the UE, and
the IKE/IPsec stack on the peer, with the intervening network under their
influence, but not their control. 

-- 
]   Never tell me the odds! | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works| network architect  [ 
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[ 



pgp76Mwuy2TMo.pgp
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Query regarding Qos with IKE

[Black, David]

Be careful - if the IPsec SA or tunnel crosses diffserv domains, the outer DSCP 
won't have the same meaning at both ends.

The initial solution looks like it's single-domain - access concentrator to 
client on a single network.  Nonetheless, the solution needs to be designed for 
at least a couple of things beyond one DSCP and one domain, even if they won't 
be used initially:

- Detect Diffserv domain crossing that makes DSCP not usable by client
(e.g., transit over a second network happens between the client and access 
concentrator).
- Multiple DSCPs are involved, e.g., AF drop precedence with multiple DSCPs is 
being used with rate-based traffic shaping.

These don't have to fully work in the first solution, but the design needs to 
have some means to detect the first and accommodate the second in the future.  
I would suggest looking at extending IKEv2's configuration support as a 
possible approach - see Section 3.15 in RFC 5996.

Thanks,
--David (an author of RFCs 2474, 2475 and 2983)

From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Paul 
Simon
Sent: Tuesday, November 05, 2013 1:54 AM
To: Yoav Nir
Cc: ; Michael Richardson
Subject: Re: [IPsec] Query regarding Qos with IKE

Hi,

I am looking for both the solutions.

But lets take the simpler case first, "single DS for each set of selectors".
In this simple case as well, the DS should be negotiated (communicated ) from 
UE to Network Element and back from Network Element to UE before using the DS.
Is it possible some way ?

My requirement is that both the end points agree on the DS before it is getting 
used.

Thanks,
Paul


On Tue, Nov 5, 2013 at 12:15 PM, Yoav Nir 
mailto:y...@checkpoint.com>> wrote:
Is what you're looking for multiple DS for the same selectors, or just a single 
DS for each set of selectors, that is determined by the AC?

On Nov 4, 2013, at 10:34 PM, Paul Simon 
mailto:paulsimo...@gmail.com>> wrote:


As indicated by Richardson [ The "network" (i.e. the access
concentrator) needs to tell the UE located at the client/device what DS to
use on that network. ]

This is exactly I need. The UE tells the network element what is the desired 
Qos that UE is willing to use for an SA and Network in turn replies to UE what 
Qos can really be used. (because finally it is the network which decides what 
characteristics the traffic can hold).

So as I understand currently Qos cannot be indicated through IKE messages and 
it has to be done through some application level protocols.

But since the Qos based traffic is gaining more importance these days, it would 
be better if we can accommodate Qos as one of the parameter in IKE negotiation 
messages.

Thanks,
Paul


On Tue, Nov 5, 2013 at 5:04 AM, Yoav Nir 
mailto:y...@checkpoint.com>> wrote:
Like I said, Paul can submit an I-D.

But if the UE applies the diffserv to the clear packet, 4301 says that these 
attributes are copied to the ESP packet. There has to be some handshake at the 
application layer to pass this information, no?  And you really need to do this 
for the clear packet anyways, because it needs to be handled with QoS at the 
provider network too. If you do it in the app layer, it doesn't require any 
modifications to IKE.

Yoav

On Nov 4, 2013, at 3:18 PM, Michael Richardson 
mailto:mcr%2bi...@sandelman.ca>> wrote:

>
> Yoav Nir mailto:y...@checkpoint.com>> wrote:
>> There are currently no attributes in IKE to negotiate QoS.
>
>> The reason for that text in 5996 is the issue of IPsec packet
>> re-ordering. If we use the same SA for packets with different QoS
>> characteristics, then the QoS could then re-order them. This means that
>> replay protection would drop legitimate packets simply because they
>> arrived late. To avoid this, the sender may use several SAs so as to
>> send packets with different QoS characteristics in different
>> tunnels. This requires no negotiation of QoS characteristics between
>> the peers, only negotiation of enough SAs for all the different QoS
>> classes.
>
>> If I'm missing something, and there is a need to negotiate this, you
>> can always submit an I-D.
>
> I think you are missing the point.
>
> Paul said:
>> We are having a requirement to have Qos per CHILD SA inside one IKE SA or to
>> have Qos per IKE SA. Is it possible to communicate the Qos in IKE handshake ?
>> Or else how can we achieve to use different Qos, atleast per IKE SA.
>
> so, you'd see that actually he wants to have multiple CHILD SAs already.
> The point is that the packets coming into the tunnel may not be marked in any
> particular way, and the "network" (as Paul calls it. I assume he means
> some more specific LTE element) needs to inform the UE what markings to use.
>
> 4301, section 5.1.2 includes:
>> Another will allow the outer DS field to be mapped to a
>> fixed value, which MAY be configured on a per-SA basis. (The value
>> might really be fixed for all traffic outbound from a device, but
>> per-SA granularity allows that as well.) This configura