[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FWD: Re: Encapsulation vs options
>From: US1RMC::"kent@BBN.COM" "Steve Kent" 7-DEC-1992 16:51
>Subj: Re: Encapsulation vs options
>
>Donald,
> I've worked on the development of encapsulating, network and
>transport layer cryptographic protocols off and on for the last 14
>years. ...
Steve,
I'm sure that you and and others on this list are more knowledgeable
and experienced than I am. That's one reason that I feel I can
present new ideas and suggest changes with confidence that I will be
corrected if I'm off base.
>... If we place such protocols in routers, so that they can
>protect whole subnets, then it is helpful to be able to direct packets
>to a specific router when more than one router serves a subnet
>(multi-homed subnet). This removes some of the functionality provided
>by IP in terms of quick response to a failed router, but it simplifies
>key management among the routers. That is a large part of the
>motivation. Also, should an encrypted packet be fragmented by a
>(non-crypto) router, it helps to have all of the fragments come
>together at the same crypto-router. That is easily achieved if the
>packets are addressed (using an outer IP address via encapsulation) to
>a crypto-router vs. the true endpoint (behind the crypto-router).
I'm not sure how much detail to go into this if host-to-host security
is going to be tackled first; however, I think I understand why you
would want to provide security at the subnet level, to, for example,
avoid the burden and possible administrative problems in having
security software and keys floating around on lots of single user
desk-top machines. So lets say I have hosts 01 through 99 that are
hooked to the outside work through routers A, B, C, D, and E. I think
I also understand why it would be convenient to have crypto stuff
concentrated into one of these routers, say C. This makes some things
simpler, including fragment re-assembly (which I had not though enough
about).
However, it seems like it makes other things harder. How does host 17
know that it needs to send outgoing traffic through C? In fact, in
the general production/ubiquitous-security case, the crypto traffic
from the various hosts has to be spread over these multiple routers so
how are the true network level source/destination pairs (before
encapsulation) associated with routers? If you just use general
routing, what happens when that changes? How do all the routers know
to direct incoming traffic purporting to relate to a particular
ultimate source/destination address pair to router C (or the
appropriate router in the general case)? If they don't, can't someone
just forge the plain text packets that C send to host 17 and spoof
things if their traffic happens to be routed via A, B, D, or E?
> Fragmentation also provides a motivation for an encapsulating
>security protocol when the protocol is implemented at routers. An IP
>datagram may be fragmented prior to encryption and after encryption,
>and it is essential to know which fragments are which (pre vs. post
>encryption). So, an encapsulating network layer security protocol
>facilitates resolution of this problem as well.
This is a good argument for encapsulation at the subnet level. I
don't see this as an argument against an option at the host level
other than that, obviously, having both encapsulation and an option is
more complex than having only one mechanism. However, as I pointed
out in one earlier message, you could use IP in IP encapsulation with
a security option at each level, not that I claimed this was
particularly attractive.
>Steve
Donald