[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re[4]: Networking Model for Crypto-services [was] Re[2]:
Perry,
>Paul_Lambert-P15452@email.mot.com says:
>> What if an IPSP encapsulated packet is originated from a system that
>> is not running IP? This is not in the scope of our IETF
>> specification,
>
>Solving the problem for the internet is a hard enough problem, in my
>opinion. We should be concentrating on that.
I agree totally.
>> The mapping of "Red" to "Black" addresses is an interesting issue.
>
>Not the least of which because ordinary TCP/IP applications work
>poorly in conditions in which addresses are mapped. Application level
>firewalls have to take considerable pains to conceal this mapping -- I
>doubt that we can solve such a problem here.
>
>> There are many mapping combinations, and most can and have been made
>> to work. In the IPSP specification we should provide a
>> recommendation on this topic.
>
>Given the complexity of this problem -- how would you get FTP to work
>in such an environment? -- I suggest that we swiftly beat a retreat
>from the question of address mapping.
Yes, let's retreat for now.
>> Back to addressing, I propose that we decouple the lower layer IP
>> address from the processing of the IPSP encapsulation. If we do
>> this, any of the addressing models can be made to work.
>
>Would this mean that endpoints would have to process SAIDs without any
>notion of what host a given IPSP packet came from? This would be a new
>twist on the proposal as made thus far.
My proposal needs to be worded more precisely. I object to the use of lower
layer protocol information in the cryptographic processing (like IV extension).
This does not mean that an IPSP entity does not have knowledge of an incoming
packets claimed origin.
Paul