[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: matching GW addr to ID payload (fwd)
Mike Carney wrote:
> > Hi,
> >
> > Tylor Allison wrote:
> >
> > > I have a question that I hope some of you out there can help me answer.
> > > The scenario is this: Say I have a host machine using IKE/IPSEC which has
> > > multiple aliases for the same interface (or multiple interfaces routable
> > > to the same remote peer). When I start a IKE negotiation to the remote peer
> > > the IKE implementation does not have control over which interface address
> > > gets inserted in the UDP packet. If I wish to use an IPV4 address in the
> > > identity payload, my IKE implementation will choose the IPV4 address to use
> > > in the ID payload based on the IKE implementations configured policy.
> > >
> > > My question is, what happens if the IPV4 address selected in the ID payload
> > > does not match the actual source address contained in the packet?
> > > I know for
> > > the pre-shared key case, this won't (or shouldn't) work (at least for Phase
> > > 1 using Main Mode), since the actual remote address used to send the packet
> > > is used to determine the pre-shared key used to authenticate the session.
>
> This is the question at hand ...
>
> > > But how should this be handled for signature based authentication? If the
> > > IPV4 address specified in the identity payload matches the IP address in
> > > the subjectAltName extension of the cert used for sig authentication and
> > > this matches the IKE local policy, does it need to match the actual
> > > address received from the packet?
>
> Any suggestions?
>
> > >
> > > And what if there is no ip address in the subject-alt name? Is it then
> > > a requirement that the actual gateway match the IPV4_ADDR identity?
> > >
> > > How would implementations out there handle this scenario? Has anyone
> > > else thought of how to handle multiple interface aliases so that ISAKMP
> > > does "the right thing".
> >
> > This problem can be solved if you use identification other than
> > IP address, in case of signature authentication mode.
>
> No fair changing the problem to one that is easier to solve :)
>
> >
> > In case of preshared key authentication, while configuring the
> > IKE policy, one should know the source IP adress and inform
> > other end.
> >
>
> Who should know the source IP address?
>
> Consider the case of a box with multiple network interface cards and
> perhaps aliased IP address on some of those interfaces. The route to
> the remote peer is what determines the interface used to send the UDP packets
> that are sent by ISAKMP. The OS uses some heuristic to determine the
> aliase IP that is used to set the source address of packets from a
> given interface.
>
> Both the route and aliase choice are subject to change.
>
> I admit this is somewhat of a rare case as most VPN gateways
> have but a single IP address for all of the VPN traffic. But in
> our implementation it is a situation we must consider.
I agree that this situation certainly happens, that is the reason
why we use signature authentication in these cases so that
other end need not know your gateway IP address. You can
still use preshared authentication, but only aggressive mode
is possible ( This is similar to remote access cases where
the IP address is not known ).
I understand this is some sort work around. I also would like
to hear other people comments on this subject.
Regards
Srini
>
>
> Regards,
> Michael Carney
>
> > >
> > >
> > > Thanks in advance.
> > >
> > > ---
> > > Tylor Allison tylor_allison@securecomputing.com
> > > Secure Computing Corporation
> >
> > Regards
> > Srini
> >
> >
References: