[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: multiple payloads via "ID_LIST"
> This may be an issue but is it a problem? Do your customers actually
>want to do this? (As opposed to just wanting to raise it "as an issue"). By
>doing IPSec on such a network aggregation point you're saying that all those
>hundred+ networks share the same policy and are not mutually suspicious.
>This seems unrealistic to me. Does this aggregations point's IPSec peer also
>have a hundred+ disjoint, non-combinable networks behind it?
>
> Can you explain what it is these people are trying to do?
Loosely speaking, the scenario is a large company with lots of branch
offices located throughout the country (or world), and one (or more)
large central offices. They want to run their private network (and
private data) over the public "capital-I" Internet, rather than spending
lots of money for leased lines. Their IP network has grown by bits and
pieces over time, such that they don't have one nice, neat, organized IP
address space, but rather lots of little address spaces, possibly obtained
from a wide variety of geographically-dispersed ISPs. Renumbering is not
an acceptable solution.
For better or worse, they want to do it with a star configuration, with
tunnels from the branch offices all going to the central office, and with
branch-to-branch communications all going through the CO rather than directly
to one another. This isn't necessarily the way I'd configure things if I
were the one doing the network planning, but I'm not. They have their
reasons for wanting to go with the star - perhaps to ease network monitoring,
perhaps to enforce additional controls on the allowable traffic. Whatever.
It's their network, so I'm not going to dictate their policy; if I tried,
they'd find another vendor who will provide them what they want.
Because it's all the same company, they're not going to be mutually
suspicious of one another (again, for better or worse), and they want
just one policy as far as encryption strength, rekey parameters, etc. goes.
This shouldn't be an unfamiliar situation; the only difference perhaps is
the scale. Again, as Roy said, we may see it as a "nice to have", but in
the eyes of some of these customers, it's a "must have". In their eyes,
there are definite issues with scaling otherwise. I'd much rather go with
a standard solution so that we can all interoperate, but I'll do what I have
to do...
-Shawn Mamros
E-mail to: smamros@BayNetworks.com