Subject: [Hipsec] feature interactions of HIP and IPsec

From: [email-masked] (Jari Arkko)
Date: Wed Nov 12 09:55:02 2003

Stephen and Eric,

In the HIP BOF you expressed a worry of how HIP and IPsec
would work together, and whether there'd be some negative
impacts to the correct operation of traditional IPsec if HIP
were adopted.  The purpose of this e-mail is to dwell a bit
deeper into this subject and try to see if there is indeed
a problem. My preliminary conclusion is that there is no
problem.

But let me first ask a clarification regarding your concerns.
I am unsure which problem you had in mind:

     a) Opportunistic security is inherently bad,
        and you should not bring it to IPsec.

     b) The simultaneous use of HIP and traditional
        IPsec in the same host leads to problems,
        even if the intention is not to use them
        for the same packets.

     c) It is not possible to use HIP and traditional
        IPsec for the same packets. That is, one must
        choose between "security" (ie traditional IPsec
        and all the security configurations) and the
        nice features offered by HIP.

If you are worried about point  a), I don't know what
to say.  Not everyone needs to have a managed security
mechanism, and they still want to move around.

It sounded a bit like some people in the meeting were
worried about point c).  Perhaps you were too.  Let me
argue that we should not demand that much from the
protocols, HIP may not help you in *all* situations.
If you are running traditional IPsec, you should
stick to it.  If you need mobility or multihoming in
that situation, perhaps you should re-establish your
SAs upon movements, or use MOBIKE.

But I think the main issue that people should
pay attention to is point b).  If I add the HIP feature
to my host, the VPN that I already have should not break.
If the administrator has configured a certain trusted peer
for some traffic, HIP should not open a hole for others to
send such traffic.  However, this does not appear to be a
problem in HIP.  Here's why: it is possible to implement
HIP in such a way that HIP operates still under the usual
IPsec policy rules, and the SPD gets to decide what is done
with each packet.  (That's how the Ericsson Research
implementation works.)

There's one thing that a HIP-enabled implementation must be
able to do, and that is the selection of the right key
management protocol.  For a given policy entry, the kernel
must be able to tell whether it should talk to the IKE daemon
or the HIP daemon.  If we require this -- and that requirement
can be put in the HIP specifications -- the rest is easy.
HIP's policy entries can be put last in the policy data base,
meaning that the configured security always takes precedence.

I also think that HIP operates within the normal 2401 rules.
The only possible extension of 2401/2406 rules that I can see
is BEET mode, but that seems more like a separate component than
a core part of HIP.

In conclusion, provided that the HIP specifications
state the one additional requirement of allowing KMP selection,
I don't think there are any implications for traditional
IPsec usage. On the other hand, we also have to realize that
some people may want to implement HIP without implementing IPsec,
and just use ESP without the rest of IPsec.  (That is how Andrew
McGregor's user level Python implementation works.) I'm not
sure whether that type of implementation can be made to work
with existing IPsec in the host. Then again, such implementations
should probably be targeted to situations where there is no
IPsec in the host at all yet.

Comments?

--Jari

---

From: [email-masked] (Andrew McGregor)
Date: Wed Nov 12 10:16:00 2003

-----BEGIN PGP SIGNED MESSAGE-----

> IPsec in the host at all yet.

PyHIP is presently targeted to Linux 2.4 systems without IPSec of any kind, 
and so presently it has no facilities for cooperating with IPSec (and 
indeed implements a BEET mode ESP itself).  However there is no reason it 
can't use the SPD and kernel SAs and ESP, in which case it would be the 
same as any other HIP daemon that does that.

In general, the issues are KMP selection and SPI selection to avoid 
collisions.  Neither is insuperable, and I agree that HIP should have some 
wording about these.

Andrew

- --------
Andrew McGregor
Director, Scientific Advisor
IndraNet Technologies Ltd
http://www.indranet.co.nz/
Office: +64 3 3656485
Mobile: +64 21 898856

---

From: [email-masked] (Robert Moskowitz)
Date: Wed Nov 12 10:55:01 2003

>        nice features offered by HIP.

The interesting scenario is IPsec over HIP.  This is to support a mobile 
host connecting to a corporate VPN.

2401 fully defines multiple encrypting layers.  Sometimes members of the 
workgroup complained about this, and SteveK defended it admirably.  Now it 
shows yet another advantage.

Of course there are two ways to implement this scenario:

IPsec over HIP
IPinIP over HIP

But this is just ruminations while listing to discussions on 802.1af 
(general link security encapsulation!)

Back to listening to Allyn.....

---

From: [email-masked] (Stephen Kent)
Date: Wed Nov 12 12:10:03 2003

>a problem. My preliminary conclusion is that there is no

I did not say there was a problem per se. Pekka, in the HOP BOF, said 
that he wanted to use ESP with HIP, but that the processing required 
did not match that described in 2401, or what is likely to be in 
2401bis. Thus I noted that if HIP uses the ESP syntax, but does not 
follow the processing model described in 2401/bis, then the result is 
not IPsec.  Pekka agreed with that characterization in the HIP BOF, 
but later seemed to be uncomfortable when I repeated the same 
observation in the IPsec WG meeting.

>        and you should not bring it to IPsec.

IPsec offers access control as an intrinsic feature. However, an 
admin (e.g., a user for a single user host that employs Ipsec) is 
free to configure the SPD to permit SA establishment with any peer, 
and to allow any traffic to traverse such an SA. So, in the extreme, 
one can locally choose to override the access control features of 
IPsec.  Does this match your definition of "opportunistic security?" 
If, so, then there is no inherent conflict.

>        even if the intention is not to use them

One of Pekka's slides in the HIP BOF called for processing packets 
using a mix of tunnel and transport mode features. this clearly 
conflicts with 2401/bis and so I do see a possible problem, but only 
based on his characterization of the required processing, not based 
on any analysis I have performed.

>        nice features offered by HIP.

These are all your words, not mine, and so I will not respond to this 
begged question. (In case you are not familiar with the phrase 
begging the question, I refer you to the canonical example; "have you 
stopped beating your wife?")

>mechanism, and they still want to move around.

the term "managed security?" is vague and generally inaccurate in 
this context. What I assume you are referring to is access control. 
But, as I noted above, although access control is an intrinsic 
function of IPsec, the SPD can be configured to largely disable the 
function. However, a product that does not support the full access 
controls required in 2401/bis, is not IPsec compliant.

>SAs upon movements, or use MOBIKE.

OK.

>with each packet.  (That's how the Ericsson Research

Fine.

>meaning that the configured security always takes precedence.

Sounds possible from an SPD management perspective.

>is BEET mode, but that seems more like a separate component than

I can't tell what is the core part of HIP, so I can't comment on this 
observation.

>IPsec in the host at all yet.

If one wants to use ESP syntax outside of the 2401-defined semantics, 
then there is a possible problem because we would have the same ID 
assigned to what are really two different protocols, based on the 
different in semantics between HIP and IPsec, IF there is a real 
processing distinction. That is probably not acceptable in the IETF.

Steve

---

From: [email-masked] (Jari Arkko)
Date: Wed Nov 12 13:37:01 2003

Stephen Kent wrote:

> IPsec offers access control as an intrinsic feature. However, an admin 
> (e.g., a user for a single user host that employs Ipsec) is free to 
> configure the SPD to permit SA establishment with any peer, and to allow 
> any traffic to traverse such an SA. So, in the extreme, one can locally 
> choose to override the access control features of IPsec.  Does this 
> match your definition of "opportunistic security?" If, so, then there is 
> no inherent conflict.

I think that means roughly it, yes.

> begged question. (In case you are not familiar with the phrase begging 
> the question, I refer you to the canonical example; "have you stopped 
> beating your wife?")

I'm sorry, I didn't mean it to be taken that way. I was just
trying to contrast what is provided by the two things, and
ask about the desire to get both at the same time. And yes,
I should have had quotes on "nice features" too...

> the term "managed security?" is vague and generally inaccurate in this 
> context. What I assume you are referring to is access control. But, as I 
> noted above, although access control is an intrinsic function of IPsec, 
> the SPD can be configured to largely disable the function. However, a 

Right.

> product that does not support the full access controls required in 
> 2401/bis, is not IPsec compliant.

I agree.

>> SAs upon movements, or use MOBIKE.

Great!

> Sounds possible from an SPD management perspective.

Ok. Good. It looks like we agree on the basic technical
requirement, then.

> processing distinction.

I agree that a processing distinction could be problematic, but
as Andrew noted in his e-mail, he believes that he can have
co-existence of both and abide by the 2401 requirements in a
future version. So perhaps this isn't a practical problem
even for this type of HIP implementation.

--Jari

---

From: [email-masked] (Andrew McGregor)
Date: Wed Nov 12 13:51:02 2003

-----BEGIN PGP SIGNED MESSAGE-----

- --On Wednesday, November 12, 2003 12:08:09 PM -0500 Stephen Kent 
<[email-masked]> wrote:

> that he wanted to use ESP with HIP, but that the processing required did
> not match that described in 2401, or what is likely to be in 2401bis.
> Thus I noted that if HIP uses the ESP syntax, but does not follow the
> processing model described in 2401/bis, then the result is not IPsec.
> Pekka agreed with that characterization in the HIP BOF, but later seemed
> to be uncomfortable when I repeated the same observation in the IPsec WG
> meeting.

There had been some conversations in the mean time.

> One of Pekka's slides in the HIP BOF called for processing packets using
> a mix of tunnel and transport mode features. this clearly conflicts with
> 2401/bis and so I do see a possible problem, but only based on his
> characterization of the required processing, not based on any analysis I
> have performed.

There is no reason to assume that HIP and any other KMP cannot coexist. 
Yes, the KMP implementations do need to have some feature to avoid SPI 
value collisions, and the SPD must support selection of the correct KMP for 
any flow, but these are almost trivial *and both are specified to be 
subject to local policy in IPsec*.

Actually, BEET mode does not appear to conflict with the IPsec RFCs and 
drafts; see below.

> processing distinction. That is probably not acceptable in the IETF.

I can't find anything in BEET mode or HIP that is inconsistent with 2401, 
2401bis, 2406 or the new ESP draft.  These are remarkably silent on how to 
deal with the specific step in transport mode processing covered by the 
BEET draft, and one could regard BEET merely as a richer and more complete 
specification of transport mode.  Note: transport mode.  BEET is closer in 
semantics to transport mode, whatever the language in the draft.

Current practice use of transport mode can be exactly duplicated by a BEET 
SA with a particular pseudoheader set in the SA.  Extra processing steps 
will take place, but the result will be the same.  IKE or IKEv2 running on 
a system with BEET would install that pseudoheader, and interoperate with 
non-BEET systems by so doing.  HIP or MOBIKE could (indeed, must) use other 
pseudoheaders (MOBIKE only some of the time), but that is an issue for 
those KMPs.

In other words, there does not seem to be a problem.

Andrew

- --------
Andrew McGregor

---

From: [email-masked] (Stephen Kent)
Date: Wed Nov 12 14:10:02 2003

Jari,

>>If one wants to use ESP syntax outside of the 2401-defined 
>>semantics, then there is a possible problem because we would have 
>>the same ID assigned to what are really two different protocols, 
>>based on the different in semantics between HIP and IPsec, IF there 
>>is a real processing distinction.
>

I think the preferable approach here is to describe how processing 
for traffic on a HIP-based SA differs from what 2401bis requires for 
an IKE-based or manually configured SA, if there is a difference. If 
we can describe the processing, then we will know if there is a 
difference, as has been suggested. This is a more satisfying 
approach, for me, rather than the existence of an implementation that 
appears to be able to handle both.  After all, the output of IETF WGs 
are standards, not implementations.

Steve

---

From: [email-masked] (Jari Arkko)
Date: Wed Nov 12 14:11:00 2003

Steve,

> I think the preferable approach here is to describe how processing for 
> traffic on a HIP-based SA differs from what 2401bis requires for an 
> IKE-based or manually configured SA, if there is a difference. If we can 
> describe the processing, then we will know if there is a difference, as 
> has been suggested. This is a more satisfying approach, for me, rather 
> than the existence of an implementation that appears to be able to 
> handle both.  After all, the output of IETF WGs are standards, not 
> implementations.

That makes sense.

(Perhaps two different descriptions, one for HIP and one for
BEET.)

--Jari

---

From: [email-masked] (Pekka Nikander)
Date: Wed Nov 12 14:21:00 2003

Stephen,

It looks like that I get very often confused when I talk to you.
My current, perhaps faulty understanding of this phenomenon is
that apparently we are having very different assumptions of what
is "security" or "IPsec" or a number of other key terms.  (I do
not imply that my understanding of the terms is right; on the
contary, my understanding is probably quite flawed.  I am just
noting that your and mine understanding of the terms seem to be
different, and therefore I quite often get confused).

Now, due to that confusion I apparently enter a very defensive mode
while speaking with you, especially publicly, and consequently
sometimes expressing my thoughts in a way that can be very easily
misunderstood.  Secondly, since English is not my native tongue,
I am most probably missing lots of nuances of what different everyday
terms mean, and therefore use language that may appear to be very
very sloppy from your point of view.

With these caveats, I'd like to to express some concerns about
the discussion that took place at the BOF.

> ... Pekka, in the HOP BOF, said 

The processing that is required by HIP does not need rfc2401 or
2401bis.  Specifically, the current HIP processing model implements
only a small fraction of the 2401/bis policy model.  Hence, the HIP 
processing model does not match 2401/bis in the sense that it is only
a small subset.

Another issue is that it is very easy to implement the HIP processing
model with an 2401 compliant IPsec policy engine.  Indeed, that is
what we have done.  We control the HIP ESP usage with a plain, vanilla
unmodified IPsec policy engine as implemented in KAME.

As far as I understood, what Jari tried to argue is that it is possible
to create 2401/bis compatible policies that allow HIP and IPsec to
co-exist in a single host.  Since I am not an expert in 2401/bis,
I can't really say whether that is true or not, but I have no reason
to doubt what Jari says.

> processing model described in 2401/bis, then the result is not IPsec.

And I agreed with you, under my perhaps misled understanding that
the term "IPsec" implies implementing *all* of 2401/bis processing
model, including all selectors, which HIP does not require (or support).

On the other hand, there does not seem to be anything that prevents
HIP and IPsec from co-existing in a single machine and sharing a
single 2401/bis conformant policy engine.

> to be uncomfortable when I repeated the same observation in the IPsec WG 

Quite a lot depends on what you mean with IPsec, and I have to admit
that I still don't quite understand how you define IPsec, exactly.
An observation that I tried to make at the IPsec WG is that, to me,
it looks like that not everybody even in the IPsec WG agree with
your definition of IPsec.

> a mix of tunnel and transport mode features. This clearly conflicts with 

As I have dicussed in length in the BEET draft, that processing can
be implemented as a part of the ESP SA processing (as we have done),
or it can be implemented separately.  There are a number of security
and implementation level benefits from integrating the functions
jointly at the SA, but there is no inherent reason why the HIT <-> IP
translation cannot be implemented separately.  This is all discussed
in the BEET draft, partially thanks to the critisism that you offered
on the initial BEET ideas at San Francisco IETF.

> processing distinction. That is probably not acceptable in the IETF.

I don't see here any real difficulty for anything but perhaps
firewalls that want to control ESP usage.  That case is being
discussed in the HIP architecture draft.  It appears that the
current HIP protocol design allows an HIP and ESP aware firewall
to have much stricter control on ESP use than a firewall who
must rely on IKE exchanges.

If there are other concerns which make these two usages so
different that they create a potential issue, I really would like
to hear the specifics of those concerns.

--Pekka Nikander

---

From: [email-masked] (Stephen Kent)
Date: Wed Nov 12 14:44:01 2003

>semantics to transport mode, whatever the language in the draft.

2401 and 2401bis are the definitive descriptions for how transport 
mode processing is performed, so I am very suspicious of this 
assertion :-)

>pseudoheaders (MOBIKE only some of the time), but that is an issue for

if extra processing steps take place within the IPsec boundary, then 
this is a change to IPsec (to accommodate HIP functionality). if the 
steps take place outside the boundary, then it is not a change to 
IPsec. In the latter case, the offered security services may differ, 
but that's not unique to HIP. For example, if one chooses to employ 
IP-in-IP tunneling before submitting a packet to IPsec, then one 
gives up the opportunity to perform access control at fine 
granularity, because IPsec is not going to look at the transport 
layer protocol that is now buried in the tunneled packet that was 
handed to it.

Steve

---

From: [email-masked] (Andrew McGregor)
Date: Wed Nov 12 15:45:00 2003

-----BEGIN PGP SIGNED MESSAGE-----

- --On Wednesday, November 12, 2003 03:11:58 PM -0500 Stephen Kent 
<[email-masked]> wrote:

>> 2401bis, 2406 or the new ESP draft.  These are remarkably silent on how
>> to deal with the specific step in transport mode processing covered by
>> the BEET draft, and one could regard BEET merely as a richer and more
>> complete specification of transport mode.  Note: transport mode.  BEET
>> is closer in semantics to transport mode, whatever the language in the
>> draft.
>
> 2401 and 2401bis are the definitive descriptions for how transport mode
> processing is performed, so I am very suspicious of this assertion :-)

I was surprised, but 2401/bis are silent about the content of the 
pseudoheader used by upper layers to calculate their checksums, and also 
about the apparent addresses seen by upper layers (the latter is less 
surprising).  This is how BEET differs, where it comes down to it.

I presume the idea is to merely insert the ESP header and transform the 
tail of the packet, in which case the pseudoheader has standard content, 
but *it is not specified in 2401/bis*.  Therefore, although the obvious 
place to store the variables is the SA, and although this happens in the 
IPsec packet processing path in some implementations, BEET requires no 
changes to 2401/bis.

>> Current practice use of transport mode can be exactly duplicated by a
>> BEET SA with a particular pseudoheader set in the SA.  Extra processing
>> steps will take place, but the result will be the same.  IKE or IKEv2
>> running on a system with BEET would install that pseudoheader, and
>> interoperate with non-BEET systems by so doing.  HIP or MOBIKE could
>> (indeed, must) use other pseudoheaders (MOBIKE only some of the time),
>> but that is an issue for those KMPs.
>
> if extra processing steps take place within the IPsec boundary, then this
> is a change to IPsec (to accommodate HIP functionality). if the steps
> take place outside the boundary, then it is not a change to IPsec. In the
> latter case, the offered security services may differ, but that's not
> unique to HIP. For example, if one chooses to employ IP-in-IP tunneling
> before submitting a packet to IPsec, then one gives up the opportunity to
> perform access control at fine granularity, because IPsec is not going to
> look at the transport layer protocol that is now buried in the tunneled
> packet that was handed to it.
>
> Steve

Agreed.  It appears to be a matter of opinion where these steps take place, 
since the HIP implementations can do it in the socket API, in something 
akin to a NAT module and in the ESP processing.  All three have been 
implemented, and interoperate.  Clearly two of those are outside of IPsec.

Andrew

- --------
Andrew McGregor

---

From: [email-masked] (Stephen Kent)
Date: Wed Nov 12 16:52:01 2003

>surprising).  This is how BEET differs, where it comes down to it.

IPsec does not see a pseudo header, in general. Remember, many IPsec 
implementations are in security gateways or BITW implementations. 
These implementations see packets with real headers, not pseudo 
headers. So, in order to provide a uniform description of IPsec 
processing, we always express it in terms of receiving a packet with 
an IP header, that otherwise could just be sent to a layer 2 
interface.  That's why there is no reference to pseudo headers in 
IPsec. It is not an oversight, it is an intentional choice of the 
interface defined for IPsec.

>IPsec packet processing path in some implementations, BEET requires no

see comments about why any reference to a pseudo header is 
inappropriate in  this context.

>implemented, and interoperate.  Clearly two of those are outside of IPsec.

Consider the comments above re what the interface is to IPsec, then 
decide where HIP fits.

Steve

---

From: [email-masked] (Stephen Kent)
Date: Wed Nov 12 16:52:04 2003

>the discussion that took place at the BOF.

Pekka,

I appreciate the fact that you are not a native speaker of English, 
and since you speak much better Engligh that I do Finnish, I can't 
complain on that basis. I, more than most folks, place a great deal 
of emphasis on trying to be precise in writing and speaking, since 
that helps avoid confusion. I assure you that I criticize many native 
English speakers for being inarticulate in technical matters. I do so 
because ultimately, such imprecision in communication wastes everyone 
time, leads to unnecessary confusion, etc. So, please don't feel that 
I am picking on you, personally, when I am critical of communication 
problems.

>
>>... Pekka, in the HOP BOF, said that he wanted to use ESP with HIP, 
>>but that the processing required did not match that described in 
>>2401, or what is likely to be in 2401bis.
>

OK, that's seems like a clear statement. But, the implication is that 
ESP, when used in  this context, is not the same protocol as when 
used in the IPsec context. Since a protocol is not just syntax, but 
also the processing performed prior to transmission and after 
reception, I think this is a fair statement.

>unmodified IPsec policy engine as implemented in KAME.

I don't know how to interpret this statement.

>I can't really say whether that is true or not, but I have no reason

Again, I have some problem interpreting this. What Jari said is that 
if one wants to employ HIP and make sure that it does not cause 
security problems by overriding the (presumably more restrictive) 
access control policies typically associated with IPsec use, then one 
can put the SPD entries that refer to HIP traffic at the end of the 
SPD. That mechanistic description of co-existence does not answer the 
question of whether use of ESP syntax with HIP is different from ESP 
with IPsec.

>
>>Thus I noted that if HIP uses the ESP syntax, but does not follow 
>>the processing model described in 2401/bis, then the result is not 
>>IPsec.
>

The term IPsec DOES imply compliance with ALL of the 2401.bis 
processing. You were wight.

>single 2401/bis conformant policy engine.

If by policy engine your mean SPD, that may be true. That may be an 
interesting capability, but it does not address the question of 
whether ESP-HIP and ESP-IPsec are the same protocol, which is what I 
think we are discussing right now.

>
>>Pekka agreed with that characterization in the HIP BOF, but later 
>>seemed to be uncomfortable when I repeated the same observation in 
>>the IPsec WG meeting.
>

RFC 2401 is the IPsec architecture document. It defines what IPsec 
is. The protocols AH and ESP are used by IPsec to provide certain 
secruity services. However, because there is considerable overlap in 
how one processes AH and ESP, we chose to not define all of these 
protocol in the RFCs that describe the syntax of each. Rather, we put 
the common processing in 2401. Thus, one ought not talk about 
implementing ESP outside of the IPsec context defined by 2401. Note 
that there are pointers in AH and ESP to 2401, indicating that these 
protocols are not completely described in the individual RFCs.

>>using a mix of tunnel and transport mode features. This clearly 
>>conflicts with 2401/bis and so I do see a possible problem, but 
>>only based on his characterization of the required processing, not 
>>based on any analysis I have performed.
>

If you have to change ANY code in an IPsec implementation to support 
HIP, then its not IPsec anymore. If you can implement the requisite 
processing before the packet is handed to IPsec, then no problem.

>>is a real processing distinction. That is probably not acceptable 
>>in the IETF.
>

I have not explored specific ramifications of having two different 
protocols that share the same protocol number, but I am comfortable 
saying that the IETF does not endorse such use. So, that's why we 
need to decide whether ESP is different in any way when used with HIP 
vs. IPsec.

Steve

---

From: [email-masked] (Andrew McGregor)
Date: Wed Nov 12 20:16:00 2003

-----BEGIN PGP SIGNED MESSAGE-----

> ESP, when used in  this context, is not the same protocol as when used in
> the IPsec context. Since a protocol is not just syntax, but also the
> processing performed prior to transmission and after reception, I think
> this is a fair statement.
>
> Again, I have some problem interpreting this. What Jari said is that if
> one wants to employ HIP and make sure that it does not cause security
> problems by overriding the (presumably more restrictive) access control
> policies typically associated with IPsec use, then one can put the SPD
> entries that refer to HIP traffic at the end of the SPD. That mechanistic
> description of co-existence does not answer the question of whether use
> of ESP syntax with HIP is different from ESP with IPsec.
>
>>
> The term IPsec DOES imply compliance with ALL of the 2401.bis processing.
> You were wight.
>
> interesting capability, but it does not address the question of whether
> ESP-HIP and ESP-IPsec are the same protocol, which is what I think we are
> discussing right now.

They could be, depending on if a supplementary RFC describing either a 
slightly augmented ESP or a slightly different HIP were published.

> If you have to change ANY code in an IPsec implementation to support HIP,
> then its not IPsec anymore. If you can implement the requisite processing
> before the packet is handed to IPsec, then no problem.

You *can* implement it separately, but often it is much more efficient to 
do it within the ESP implementation.  The behaviour observed from outside 
the stack is the same, excluding efficiency issues.

Andrew

- --------
Andrew McGregor

---

From: [email-masked] (Andrew McGregor)
Date: Wed Nov 12 20:23:04 2003

-----BEGIN PGP SIGNED MESSAGE-----

- --On Wednesday, November 12, 2003 04:45:46 PM -0500 Stephen Kent 
<[email-masked]> wrote:

> implementations are in security gateways or BITW implementations. These
> implementations see packets with real headers, not pseudo headers. So, in
> order to provide a uniform description of IPsec processing, we always
> express it in terms of receiving a packet with an IP header, that
> otherwise could just be sent to a layer 2 interface.  That's why there is
> no reference to pseudo headers in IPsec. It is not an oversight, it is an
> intentional choice of the interface defined for IPsec.

Ah.  Ok, that makes sense.  Well, pseudoheader fields or actual header 
fields, the description is almost the same.

> Consider the comments above re what the interface is to IPsec, then

Well, one could describe the HIP processing as a kind of packet mangler in 
the path before entering IPsec transport mode; I had that for a while in my 
implementation, even.  So, if logically it's that, but implementors for 
efficiency alter ESP, where do we stand, in your opinion?

Andrew

- --------
Andrew McGregor

---

From: [email-masked] (Michael Richardson)
Date: Wed Nov 12 21:12:00 2003

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Stephen" == Stephen Kent <[email-masked]> writes:

    Stephen> IPsec does not see a pseudo header, in general. Remember, many
    Stephen> IPsec implementations are in security gateways or BITW
    Stephen> implementations.  

  The "H" in HIP is for "HOST"
  BITW/BITS do not apply.
   
  I see no requirement that all features be implementable by a BITW. 
  
] Collecting stories about my dad: http://www.sandelman.ca/cjr/ |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [

---

From: [email-masked] (Robert Moskowitz)
Date: Thu Nov 13 11:00:02 2003

>   I see no requirement that all features be implementable by a BITW.

There is the Proxy model.  This is not quite BITW.

I only roughed out the Proxy model, to support an orginization wanting HIP 
for external use, and not fully upgraded.  The Proxy is a bit more than the 
active NAT.

Arguement can be made to not do this (it actually owns the HIs, 
yikes!).  But it is in the HIP model.

---

From: [email-masked] (Stephen Kent)
Date: Fri Nov 14 09:19:01 2003

>efficiency alter ESP, where do we stand, in your opinion?

If one can describe HIP processing as an activity that takes place 
prior to IPsec processing, then we probably don't have a problem. 
This would be true even if, as you note, people choose to implement 
this processing within the IPsec boundary.  Look at the revised 
processing model figures I presented at this week's IPsec WG meeting 
to see if you think the separation in question is feasible.

Steve

---

From: [email-masked] (Stephen Kent)
Date: Fri Nov 14 09:39:00 2003

>   I see no requirement that all features be implementable by a BITW.

Mike,

Does this means that HIP is to be employed ONLY when BOTH peers are 
native host implementations?

Steve

---

From: [email-masked] (Stephen Kent)
Date: Fri Nov 14 09:39:04 2003

At 9:30 -0700 11/13/03, Robert Moskowitz wrote:
>I only roughed out the Proxy model, to support an orginization 
>wanting HIP for external use, and not fully upgraded.  The Proxy is 
>a bit more than the active NAT.
>

When you guys agree on the scope of applicability for HIP, get back 
to me and we can continue this discussion.

Steve

---

From: [email-masked] (Pekka Nikander)
Date: Fri Nov 14 10:06:00 2003

Stephen,

> native host implementations?

Yes.  That is the current model.

The proxy model that Bob Moskowitz mentioned would extend HIP
to a case where HIP is employed between a native host
implementation and a HIP proxy.  In that case I guess the
HIP proxy could be compared to the IPsec Security Gateway
concept (or is it called BITW?).

Making an exact comparison is impossible since people have
very different ideas of the potential processing model of a
HIP proxy.  It looks likely that a HIP proxy would more
resemble a Mobile IP home agent than an IPsec Security Gateway.

The HIP proxy concept was part of the proposed work item #6
at the BOF.

--Pekka Nikander

---

From: [email-masked] (Michael Richardson)
Date: Fri Nov 14 18:18:01 2003

-----BEGIN PGP SIGNED MESSAGE-----

    >> I see no requirement that all features be implementable by a BITW.

    Stephen> Does this means that HIP is to be employed ONLY when BOTH peers
    Stephen> are native host implementations?

  I can't see any reason to build or specify a BITW IPv6 mobility via HIP box.
  Maybe someone else can, but I don't see the point. The HITs need to be
strongly associated with the TCP.

  Sure, NCP was implemented outboard for a decade. Was TCP/IP? Rarely.
  Things progress - BITW seems like a stepping stone. Eventually, you don't
need it anymore.

---

From: [email-masked] (Robert Moskowitz)
Date: Sun Nov 16 00:26:00 2003

>concept (or is it called BITW?).

I should point out that I only came up with the Proxy model when I was 
challenged about it.

'Is it possible for...'

'Well, yes.  Here is how.  I don't think it is a good idea, as the Proxy 
owns the identity....'

If we never implement the proxy model, I will not complain.  Not one 
bit.  Not over the wire or over the air!

>_______________________________________________
>Hipsec mailing list
>[email-masked]
>http://honor.trusecure.com/mailman/listinfo/hipsec