[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: use of client IDs
>
> Pyda,
>
> > Trusting a peer node is different from figuring out whether a
> > packet should be tunneled to the peer or not. You cannot make
> > the assumption that your routing table will tell you whether or
> > not a packet should be tunneled to a peer, because you may not
> > be running routing protocols on top of the tunnels.
>
> I think it is important to note that, as the architecture doc
> describes, there are logically separate SPDs for inbound and
> outbound traffic.
>
> If A is establishing an IPSEC SA to B, then B could have a policy
> that says "accept (source IP address) 0.0.0.0 on an SA from A"
> because it has already established a trust relationship with A and
> can rely on A to apply its own outbound policy on the SA. Now B
> could have an outbound policy which says, for example, "send packets
> destined to 1.1.1.0/24 and 1.1.2.0/24 to A ", but this is separate
> from the inbound policy. Having a finer granularity inbound policy
> on B, which explicitly lists the subnets allowed to source
> traffic is something that I think should be allowed, but not
> required, because to do this requires, in effect, a policy exchange
> protocol, so that B can verify the policy defined in the incoming
> protocol message, with the policy defined in its SPD.
>
> Bryan
>
Bryan,
A couple of clarifications (at least for myself) to note:
1. In a quick mode, SA proposals and optional ID/policy payload
are exchanged in one swoop. So, there is no question of trust
relationship being established ahead of policy exchange.
However, I do believe, that in the current documentation, the
unstated assumption is that for a tunnel mode, the ID of IKE
is same as the ID of the VPN node for which SA negotiation is
in progress. Hence, the ID payload accompanying SA proposal is
actually the policy. In that context, what you say about
trust being established prior to policy exchange is correct.
2. Next, the issue of policy direction.
During SA negotiation, IKE client for A sends proposals to B.
The SA that is represented by these proposals are for inbound
data packets to A.
Shouldnt the policy that accompanies SA also be in the same
direction as the SA? I.e., I believ, the policy description sent
by A should in fact be applicable for the inbound packets to A.
(and, not the outbound as your message above seems to imply).
3. Lastly, the policy (the description of which may be relegated to
IPsecond) cannot be limited to just the source side or the
destination side. It has to be a combination of both.
Ex: It may not be sufficent to say, a certain SA should be
applied to packets directed to an address (say, 172.168.1.1).
Rather, it may be desirable to be able to state that a certain
SA should be applied to packets from a set of addresses (say,
175.18/16) to an address (say, 172.168.1.1).
Have a nice day.
cheers,
suresh
Follow-Ups:
References: