On 06 Nov 2013, at 17:09, Stephen Kent <k...@bbn.com> wrote:
> Manish,
>> Steve,
>>
>> NHRP is used to resolve the remote peer which serves/owns the address we're
>> interested in. The information in this resolution culminates in the creation
>> of SPD.
> So the NHRP interaction creates a new SPD entry as a side effect? This entry
> is
> more specific re selector values (for IP addresses), and that causes traffic
> to trigger
> an IKE SA for the shortcut route, and then child SAs are created, right?
NHRP create a new SPD entry that protects GRE between two spokes. It also
creates a new GRE tunnel (or a new tunnel endpoint) to that same spoke.
NHRP finally creates a prefix in the routing table or a policy that forces the
traffic into that new tunnel.
> I presume this is new functionality for NHRP (given te age of that RFC), and
> is viewed as
> an external management interface to IPsec, for SDP maintenance. Is it safe to
> assume that
> the SPD selectors are the same for every NHRP-triggered SA pair? Since (I
> believe) that NHRP
> doesn't care about higher layer protocols, and since the SA is transport mode
> and
> encapsulating GRE, that means that no transport protocol/port access controls
> are imposed on
> the SA, right?
The selectors are GRE-hostA-hostB and are traffic agnostic.
NHRP installs policies that decide the traffic needs to be forwarded (and given
to a particular SA).
I.e. instead of having IPsec determine the peer after matching specific
selectors, the peer is first selected based on a policy (routing table, policy
route…) and the traffic is then protect with the generic GRE traffic selector
leading to host-B.
NHRP alone only cares about network prefixes and not traffic types. When we
reach to use cases, we tend to revert to policy routing that would provide the
granularity you are talking about.
> Is there a corresponding management mechanism, tied to NHRP, to cause these
> SAs to
> terminate, or do you rely on the SA lifetime values to time out these
> shortcut SAs?
> How are these values managed?
Both IPsec and NHRP have hold timers. We refresh the entries if they have been
used before expiration.
The IPsec/IKE SA's can be torn down for the same reasons a classical IKE/IPsec
session can be torn down (eg. peer certificate expiry, explicit administrative
control, receiving of a delete-notify, liveness checks …)
It is sufficient for one of the entries (NHRP or SA) to disappear to take down
the other entries. E.g. if the IPsec SA is deleted, the corresponding tunnel or
tunnel endpoint is torn down, the NHRP entries are deleted and the forwarding
policies are removed.
regards,
fred
> Steve
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
