Re: [Hipsec] More about LSIs

Tim Shepard wrote:
> I believe there is another option:

Unfortunately that is not enough. As I tried to explain in my example, there is a possibility that you assign an LSI, and later you need to use the exactly same bit pattern as an IPv4 address. Even if you had a LSI database, you would have a conflict and ambiquity.

> But IIRC the real answer is that LSI's are a local issue, which means

Not quite. LSIs are not completely local, but they are communicated to the peer, and the peer must be able to recognize the LSIs as their own identity in any legacy IPv4 protocol payload that carries IPv4 addresses. That includes FTP, SIP, and a number of other protocols.

> This means that you have to be prepared to accept any sort of LSI that

Unfortunately there are applications that will send those, in the application level payloads. Applications in your end will process whatever they receive, and issue system calls using those. Thus, you have to recognize in the kernel the LSIs, and be able to tell that they actually mean you.

Anyway, assigning a /8 for LSIs make the implentation much easier. You can define firewall rules them, you can define IPsec policies for them, etc.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek

I'll use 1.0.0.0/8 in the draft, as Andrew suggested. I'll also add some text that clarifies that you just drop your negotiation and try again if you get an LSI that is unacceptable.

--Pekka Nikander