Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt

From: Pekka Savola <[email-masked]>
Date: Sat, 1 Dec 2001 13:49:59 +0200 (EET)

On Thu, 29 Nov 2001 [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
> 	Title		: Minimum IPv6 Functionality for a Cellular Host
> 	Author(s)	: J. Arkko et al.
> 	Filename	: draft-manyfolks-ipv6-cellular-host-02.txt
> 	Pages		: 26
> 	Date		: 27-Nov-01
> 	
> As an increasing number of cellular hosts are being connected to the
> Internet, IPv6 becomes necessary. Examples of such hosts are GPRS,
> UMTS, and CDMA2000 terminals. Standardization organizations are also
> making IPv6 mandatory in their newest specifications, such as the IP
> multimedia terminals specified for UMTS. However, the concept of
> IPv6 covers many aspects, numerous RFCs, a number of different
> situations, and is also partly still evolving.

The draft says:

--8<--
4.1 Mobility Support in IPv6
[...]
   The basic functionality of a Correspondent Node, i.e. process the
   Home Address Option, MUST be supported by all hosts. (Note: at the
   time this Internet Draft has been written, the Home Address Option
   is defined only in the MIPv6 Internet Draft, not an RFC, and the
   security implications of the Home Address Option are being studied
   by the Mobile IP Working Group. The group is considering whether the
   option should continue to be understood by all nodes, or only those
   involved in Route Optimization functionality with a MN. Depending on
   the results of this discussion, we should either mandate the support
   of the option here for all cellular hosts, or only those capable of
   Route Optimization.)
[...]
--8<--

"basic functionality of a CN" has not been defined explicitly, IMO.

The requirement that Home Address Option MUST be processed is nothing new; 
it's a requirement for every IPv6 node as currently being specified.

Therefore, the requirement here must be stated more clearly.  One could
gather one of the basic funtionalities of a CN would be to be able to
process incoming Binding Updates.  What's your stand on this?

Instead of saying basic functionality, say which functionality in the main
sentence.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Jari Arkko" <[email-masked]>
Date: Sat, 1 Dec 2001 16:54:44 +0200

> "basic functionality of a CN" has not been defined explicitly, IMO.

Yes. Thanks for pointing this out. We should clarify the issue in the draft.
The intention was to say that  Home Address Option processing is
mandatory on all nodes, while Route Optimization functionality is not
(mipv6 draft -15 says: "Mobile IPv6 defines four new IPv6 destination
options, including one that MUST be supported in packets received by
any node, whether mobile or stationary.").

> it's a requirement for every IPv6 node as currently being specified.

Right, and this was what we've stated in earlier versions of the draft. A
note was, however, added to the latest version of our draft to indicate
that the Mobile IP WG is presently discussing what to do with the Home
Address Option and whether there are security issues in that as well
(as there were other security issues in the Binding Update Option).

But frankly - as someone who wants to deploy zillions of these
devices soon - we are somewhat unsure how to proceed regarding
this issue. Since I know you Pekka were involved in the Home Address
Option discussion, perhaps you could comment on where do you think
the WG goes? Will it disallow the option unless accompanied by a
Binding Cache Entry established securely earlier? Will it throw away
the option and start to use tunneling? Or decide that there is no
security issue? Or perhaps we can't yet say for sure?

Jari

---

From: Pekka Savola <[email-masked]>
Date: Sat, 1 Dec 2001 17:33:23 +0200 (EET)

> security issue? Or perhaps we can't yet say for sure?

It's too early to say how this will be tackled, but I think the risk of
completely unauthenticated Home Address options will be too high; it seems
probable it will have to restricted in some form or the other.  But it's
rather early yet.  Next revision of secreqs draft will add Home Address
option and Routing Header issues for consideration.  It seems likely the
wording will be "harsher" on the issue than before.

---

From: Jim Bound <[email-masked]>
Date: Sun, 2 Dec 2001 22:42:15 -0500 (EST)

Jari,

This is pretty simple really.  Any app server as CN should support the
binding update and the mobile node should support the binding update.
Many of us are shipping it soon and it works.  AAA will be used for
security till the IETF gets done analyzing this and if we have not
deployed zillion of nodes vendors will look at it.  If they have then the
IETF timed out.

Lets move on.  The draft should recommend using the binding update and
route optimization.  Or do this as industry exercise and not as standards
exercise.

regards,
/jim

---

From: Jim Bound <[email-masked]>
Date: Sun, 2 Dec 2001 22:49:08 -0500 (EST)

Pekka,

I completely disagree with you.  The entire notion of worrying about the
home agent address is overrated.  The reason is what most people will be
doing is not needed to be secure anymore than when you call a friend on
the telephone and tell them your bringing some beer over for the tele
show.  This is what I believe 90% of the devices will be used for and on
private cell networks not on the Big Internet.  

/jim

---

From: Pekka Savola <[email-masked]>
Date: Mon, 3 Dec 2001 11:02:15 +0200 (EET)

> private cell networks not on the Big Internet.  

The issue is about Home Address Option, not Home Agent address.  Damn the 
abbreviations :-).  Or did you still mean Home Address?  If so, I 
recommend you read, at least cursorily:

http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-security-01.txt

Thanks.

---

From: Jim Bound <[email-masked]>
Date: Mon, 3 Dec 2001 09:00:56 -0500 (EST)

Pekka,

> http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-security-01.txt

Actually I mean't both the Home Address Option and the BU ---> and
referencing them as MN BU Processing.  Sorry.

But yes I read the above and 
draft-arkko-mipv6-bu-security-01.txt

I understand what your concerns are but as you say in your introduction
"under some circumtances and the Big I" this can be a problem.

I believe we need to develop security mechanisms for many parts of IPv6. 
But I believe enhanced security extensions must be done out-of-band not
integral to the base protocol spec.  MIPv6 and other specs have specified
IPsec and IPsec will be on all implementations for IPv6 this coming year
from vendors that are shipping real IPv6 products.  As far as PKI as Jari
states in his draft its not realistic to think we can build a global PKI
infrastructure. 

IPv4 is dying now quickly and a huge fog is developing around the Internet
and affecting private enterprise.  Private enterprise will not put up with
the IPv4 band-aids much longer.  Its affecting business and the evolution
of their networks and applications development.  End-2-End is required for
private enterprise because now everything runs over the network or IP
stack however you want to view it.  IPv4 is completely broken.  It is
unacceptable because of the lack of address space and the bandaids like
translation, VPNs, etc... 

I hinted at the solution for out of band and that is AAA.  What that means
is we have to now use AAA to secure a MN to its location of
communications.  Will this have a performance hit.  Yes of course. But its
better than waiting for all of us in the standards arena to discuss and
analyze this for the next three years.

THere is profit, jobs, and lots of good enconomic proliferation that can
happen worldwide because of wireless computing.  That is not going to
happen with IPv4 it can't and its impossible without a huge green non E2E
fog. 

We must continue to work on finding the best security we can for MIPv6
parts and I support that and will add that to my products as we
develop solutions.  Your points are all good.  I think a new RT HDR may be
fine, thats why we put the extensibility of headers for IPv6 in the first
place.  

Also IPsec will work for say a specific network bandwidth locale.  Simply
because PKI on that scale will work.  AAA will work too.

What I advocate and always have is move the protocol specs forward with
base mechanisms to support the most aggressive attacks.  MIPv6 has done
that with IPsec and IPsec in general does that too.  If the packet is
IPsec'd at each hop it gives some general security.  Thats enough to move
the protocol specs at least to PS.  MIPv6 should have been PS at draft 13.

THen we use spiral engineering to continue to improve upon the protocol
and additional security mechanisms.  This permits us to deliver timely
specs to the market and our biggest customer which is private enterprise.

Most vendors in this community make their profit from private enterprise
not the Internet.  And those that are classified as Internet usually are
running private enterprise network services for a fee (telcos and ISPs).

As far as securing my MN from bad guys I believe in caveat-emptor in the
first place.  If you transfer your money without being secure your stupid
and should loose your money.

As far as nerd criminals attacking CNs via BUs well AAA fixes that and if
IPsec is used.  Plus we will begin to see soon law enforcement mechanisms
for private enterprise to catch these people and implementing very strong
penalities for such acts at least in the U.S.

thanks,
/jim

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 3 Dec 2001 15:45:17 +0100 (CET)

> security issue? Or perhaps we can't yet say for sure?

I'm very concerned that the current assumptions around security for
the Home Address Option is based on a poorer understanding of
security, DDoS, reflectors, etc that we (including myself as co-chair
of Mobile-IP) had a few years back.

Thus I, including with an IESG member hat on, currently think that allowing 
Home Address Options to be processed as currently described is asking
for problems and that we need better security in this area.

One *possible* solution to this is to only accept packets with a HAOpt
when there is a matching binding cache entry for the sender, but
there might be other solutions as well.
But I'd sure like to see closure around the requirements document in
the Mobile IP WG on this point.

Note that this issue is independent of how to information contained
in the HAOpt is carried - whether as a HAOpt in the Destination Options
header or as a tunneling header. But thinking of it as a form of 
(restricted) tunneling has helped me understand the security implications of
it.

  Erik

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 03 Dec 2001 11:24:22 -0800

hi,

> (as there were other security issues in the Binding Update Option).

The above sentence needs to be put in a certain perspective. 
I think it is wrong it say the Mobile IP WG is wholeheartedly 
discussing this issue. It is more like that this issue has been 
forced upon the Mobile IP WG (like certain other security issues 
it was never meant to solve). And most people (who worked on 
Mobile IPv6 implementations for years) dont take part in these 
discussions either. We implementors (I can speak for a few people) 
were quite happy with Home address option, BU option and 
IPSec (we made it work with Mobile IPv6), until things started 
going wrong from December 2000 IETF onwards.

regards
Vijay

---

From: Pekka Savola <[email-masked]>
Date: Mon, 3 Dec 2001 23:31:32 +0200 (EET)

> going wrong from December 2000 IETF onwards.

<semi-rant>

Wouldn't it be nice if one would be allowed to specify insecure behaviour,
and in addition, making it a MUST implement (HAO) or a SHOULD (BU) for
every IPv6 node?  Without regard for consequences?  "Stationary nodes are 
not our problem.. they aren't mobile"?

Some might say: feel free to break MIPv6 -- it's your baby after all --
but don't break IPv6 in the process too, please.

</rant>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Dec 2001 09:52:23 +0100

Vijay,

Vijay Devarapalli wrote:
...
> it was never meant to solve). 

I'm not quite sure what you are getting at here, but it's the
responsibility of every WG to solve all the security issues
associated with its own work; security is not a kind of
icing added afterwards to the cake. And if a security problem
is discovered late, it still has to be solved, even if that
means starting again. Security isn't optional in the IETF.

Regards
   Brian

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 04 Dec 2001 10:33:51 -0800

Brian E Carpenter wrote:
> ..

For one, it has been asked to solve key distribution between
two hosts in the Internet without using any infrastructure
(dont assume PKI, AAA, etc...). Mobile IP WG has been told 
that MIPv6 will not move ahead without solving this. and 
everyone knows it is a very hard problem.

There are many more, but it will sound like a rant. I will
stop with this. My only intention was to put a statement into
a certain perspective.

regards
Vijay

---

From: Michael Thomas <[email-masked]>
Date: Tue, 4 Dec 2001 10:43:39 -0800 (PST)

> stop with this. My only intention was to put a statement into

This is akin to wanting to design a 200 story
building, but not wanting to be held accountable
for its structural integrity. Any-any tunneling is
a hard problem, and anything that wants to propose
its use needs to deal with *all* of its
complexities. The alternative is to not take on
the task if it's too hard. There is nowhere else
where this will or should be solved.

	   Mike

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 05 Dec 2001 08:41:00 -0800

Hello Brian,

Brian E Carpenter wrote:
> icing added afterwards to the cake.

If I understand the point, it was that Mobile IP has been asked to
solve security problems that, in other instances, would have been
more properly solved separately.  For instance, even though one
might require security for address autoconfiguration, one might
still allow DHCP to go to Proposed Standard without requiring the
dhc working group to devise a key distribution protocol.  It is
my belief that for the purposes of initial deployments of Mobile
IPv6, we could go forward with the protocol without finishing the
key distribution protocol first, and allow the needed security
associations to be created in any reasonable way (perhaps by
proprietary protocols) until an open standard could be created.

>                             And if a security problem

I don't think anyone would contend otherwise, certainly not me.

Regards,
Charlie P.

---

From: "Jari T. Malinen" <[email-masked]>
Date: Tue, 04 Dec 2001 21:55:42 -0800

For people not to get wrong impression, there is nothing unsolvable
in the remaining issues on the table in mobileip wg for Mobile IPv6.
All issues raised have so far been analyzed in concerns drafts,
and sets of solutions proposed. The question currently is more
to conclude the selection process among the proposed solutions.

One issue on the table is the scalability of key distribution in
infrastructureless case. Changing tunneling format is an orthogonal
issue to this and I have not understood what so far unsolvable
would such a change achieve. Proposals by people working in security
providing "weak authentication"  e.g. based on return routability,
have appeared and been under scrutiny.

Mobileip wg has done a big job analyzing security concerns in
Mobile IPv6, and like Brian has requested below, the work to solve
these issues has taken place in the actual working group in question.

Solutions independent of work done elsewhere, ipsec included,
have emerged allowing among other things, decoupling of binding
security association maintenance and message authentication code
placement from the inflexibilities of ipsec, where no mobility
concerns are addressed, e.g. support of IPv6 extension header
protection policies in SA database access, or support for weak
authentication.

A lot of implementation experience already exists for most features
in the current design, and much ongoing work has happened to show
feasibility of the remaining issues. IMHO, the issue of a full
redesign for Mobile IPv6 is moot and existence of Mobile IPv6 in
the draft in the topic line is well founded.

BR,

-Jari

---

From: Michael Thomas <[email-masked]>
Date: Wed, 5 Dec 2001 10:34:43 -0800 (PST)

Jari,

I agree that the tunnel format is orthogonal to
the security question. I think that what Pekka and
others have been pointing out is that the HAO is,
in fact, another form of bits-on-the-wire
optimized tunnel, much like the routing header.
While the actual way you encode these tunnels is
orthogonal as you point out, I think that what has
been neglected is the security considerations of
the HAO qua tunnel, until Pekka brought this up.
It's still a good observation. 

What I gather that Steve is bringing up is that
maybe we wouldn't have been lulled about the
possible dangers of the HAO for so long if it had
been more obvious that the HAO was a tunnel, and
that maybe this would be better to solve once and
for all. I think that idea has some merit, because
creating any-any tunnels may well have other uses
beyond mobile IP.

	    Mike

---

From: "Jari T. Malinen" <[email-masked]>
Date: Wed, 05 Dec 2001 14:55:02 -0800

Mike,

>  > One issue on the table in mobileip is the scalability of key distribution in

I am not sure we understand orthogonality the same way,
what I meant was that the only real issue with HAO is how
to protect it end-to-end always. There is no improvement
in this respect if we change HAO to a new extension header.
The security issue is not HAO-specific, we need to protect
any header carrying the HAddr against cases brought up by
Pekka.

> creating any-any tunnels may well have other uses

As said, a nice idea. However, the case of ignoring HAO
is not true; before PKI was not considered globally scalable
it was possible to say we can always use IPsec to protect
even the HAO, which is an immutable dst.opt.

Hence, once a "weak authentication" method is chosen it
is again possible to always protect HAO (as well as even a
nicer tunneling header). We still need a MAC field for that and
for this there is an easy way. To conclude, dst.hdr is in RFC,
the new proposal an individual draft so I'd say it could be
something to consider for a second generation of Mobile IPv6,
perhaps.

BR,

-Jari

---

From: "Jari Arkko" <[email-masked]>
Date: Fri, 7 Dec 2001 22:03:23 +0200

> To conclude, dst.hdr is in RFC,

Just a clarifying question to make sure I have correctly understood
the current situation with the HAO: the DO header is in the basic
IPv6 RFCs. However, the format of a specific DO that can be
used to carry the Home Address, HAO, is defined in the MIPv6
I-D. I'm asking this because we'd very much like to publish the
cellular host draft as an RFC soon, and in order to require the
use of the HAO we need not just a resolution to the security
worries, but also a reference to some RFC that defines the HAO.
Unless I'm mistaken, we currently don't have such an RFC anywhere.
Or?

Jari

---

From: "Jari T. Malinen" <[email-masked]>
Date: Fri, 07 Dec 2001 16:45:32 -0800

> Unless I'm mistaken, we currently don't have such an RFC anywhere.

True, though Mobile IPv6 seems to have a process and timetable to
achieve the same goal and also be in last stages of the process.

HAO was presented to ipng as a mandatory feature before IPv6 was
finalized and it was designed to fill a missing piece of IPv6
functionality to support mobility. At that time it was endorsed
by the ipng wg and it ended up in the MIPv6 draft. It has been
pretty stable ever since. The only reason it is not yet in RFC is
due to non-HAO-format related issues.

BR,

-Jari

---

From: Pekka Savola <[email-masked]>
Date: Sat, 8 Dec 2001 09:06:37 +0200 (EET)

> due to non-HAO-format related issues.

Btw,

One interesting detail of HAO is that its processing isn't defined 
anywhere.

If you look at MIPv6 draft, the only thing it says about this (AFAICS) is 
a note in security considerations that it could be implemented like 
swapping the addresses.

I have brought this up in mobile-ip@ but there wasn't any response...

---

From: Michael Thomas <[email-masked]>
Date: Sun, 9 Dec 2001 11:55:26 -0800 (PST)

> any header carrying the HAddr against cases brought up by

   Right. I think we're saying the same thing.

 > something to consider for a second generation of Mobile IPv6,

   I'm afraid that there's more to this than that.
   One of the implications of Pekka's observation is
   that the binding cache is no longer a cache. That
   is, you cannot evict the cache entry and still
   function properly. The reason is not the CoA and
   RH which will clearly still work, but the HAO. If
   you drop the cache entry, the CN will see a HAO
   which it doesn't know whether to believe and thus
   would have to drop (or send a binding solicit,
   etc). This bothers me quite a bit as going from
   soft state to hard state should never be taken
   lightly.

		Mike

---

From: "Jari T. Malinen" <[email-masked]>
Date: Sun, 09 Dec 2001 14:49:45 -0800

Pekka,

The HAO issue you mention can arguably be considered an implementation
issue, taken care by the note in the MIPv6 draft. However, it should be
mandatory. I'll discuss this below. I'll also cross-post this note to
the mobile-ip since you asked it there without anybody answering.

> a note in security considerations that it could be implemented like

This issue of HAO processing was supposed to be covered by the note you
refer to. On my opinion it is a very important note and should have had
more emphasis, but according to some other implementors, discussed (also)
in the ETSI Bakeoff 1 year back, there was some issue of read-only buffers
in somebody's implementation which kept the formulation as it is now. Or
maybe I remember it incorrectly, I did not quite understand motivation for
the concern then.

There is a subtle transparency issue involved in this note. MIPv6 provides
transparency by letting applications see the packet as if coming from the
home address. In implementation this is at least considered to mean that
when an application reads the IP source address from the socket, it is
the home address. This implementation detail is not verbosely explained
since it should be obvious to implementors what application transparency
(from changes of the CoA) means in this respect.

The processing order both sending and receiving need to be such that the
transparency is obtained, e.g. for an SCTP INIT packet to have an IPv6
option which can be the home address with exactly the same machinery
used with non-HAO packets. Any other protocol when using HAddr for
communication need to experience the same degree of transparency.

But, when processing other headers beyond HAO in an implementation,
transparency should also mean they see the home address in IP source just
like in a non-MIPv6 data packet. For example, when constructing an AH,
and the note is followed, we observe the swapping happens at HAO processing
in the receiving end before AH processing. If the expressed transparency
principle would be followed in IPsec integration to the fullest, this would
mean the receiving AH processing sees HAddr in IP source. When following in
AH ICV computation the rule of having the authenticated data as seen by the
receiver after processing, it should take into account this swap (swap the
addresses in the ICV computation copy of a to-be sent packet to reflect the
same swap at the receiving end's HAO processing).

Hence, on my opinion, the note should be elevated to be something mandatory.
This would fully implement the transparency principle. It requires no message
format or interface changes to IPsec, only for it to follow its existing principle
of making authenticated packet look like one seen by the receiver (to reflect the
swap of CoA and HAddr in case of HOA option in a to-be sent packet when doing the
ICV generation).

Some called this note just an implementation detail, to me there is more to it,
it gives a processing rule needed for clean implementation of transparency.
Now there may be implementations with tricks to avoid this processing when
assuming IPsec implementation is untouchable to the latest bit (the swap can't
be done until all IPsec implementations agree, since otherwise we'll get wrong
MAC value from the other end not doing the swap when this end follows the rule)..
Hence, this is more of an issue of harmonizing protocol engineering implementation
rules for inter-protocol interworking than an actual security issue.

> I have brought this up in mobile-ip@ but there wasn't any response...

Hope this gives one answer. I also hope implementors seeing this otherwise would
express their concerns now. I'd say it also points there is a siginficant body
of experimentation done with current components of MIPv6, HAO included. Changing its
format now would mean a long re-rehearsal to get to the same state of experience.
Possible, but this should be taken into account when deciding so.

BR,

-Jari

---

From: "Jari T. Malinen" <[email-masked]>
Date: Sun, 09 Dec 2001 17:12:45 -0800

Mike,

>    soft state to hard state should never be taken

Hmm, if there is a way to set up weak authentication state
in an initialization, it can also be done again, even after
expiration. However, this concerns the properties of
weak authentication where you may not have a proof
of identity the way of strong authentication (e.g.,
you may need to "believe" the first HAO).

A point here was that once weak authentication was
considered required, that became the issue, not
the format.

BR,

-Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 10 Dec 2001 05:37:41 +0200

> you may need to "believe" the first HAO).

I'm afraid Mike's right here. Of course the weak authentication
can be rerun, but before it is rerun, many packets have gone
to /dev/null because the MN kept sending route optimized stuff
with HAOs, and the CN through them away because of the security
issue.

Jari

---

From: Pekka Savola <[email-masked]>
Date: Mon, 10 Dec 2001 07:47:28 +0200 (EET)

> the mobile-ip since you asked it there without anybody answering.

My gripe here is the location: IMO, it must be noted in the *main
sections* of the draft how home addresses are supposed to be used (e.g. it
substitutes the source address in some implementation-dependent way for
example X.x, maintaining connections even though the source address would
change). This is taken as granted, like everybody would already know what
Home Address is supposed to achieve.  Security Considerations seems like a
completely wrong place to specify the behaviour.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 10 Dec 2001 06:14:56 +0100 (CET)

Jari,

No version of draft-ietf-mobileip-ipv6-nn.txt has required that the HAOpt
be protected in all cases - the requirement has only been to protect
it (automatically) when the packet also containts a BU option.
Thus this issue has nothing to global PKI or not - IMHO it was
a poor understanding, partly by myself as a WG co-chair at the time,
of the type of attacks that have since become more common and how the
HAOpt could be used to facilitate such attacks.

  Erik

---

From: "Jari T. Malinen" <[email-masked]>
Date: Mon, 10 Dec 2001 09:51:47 -0800

> with HAOs, and the CN through them away because of the security

Ah, let me clarify. Currently the way you describe of implementing
MN is allowed because HAOs in the MIPv6 draft itself are not required
to be protected. Here the question is what if we _did_ have the fix
of always protecting the HAO, and with weak authentication.

I was thinking the other way to implement MN, to send a CN BU in
good time before lifetime expires (soft timeout before hard one),
even without receiving a BR. Once actual lifetime of BU in BUL is
expired (hard timeout), MN knows it needs to re-start. Hence it
also can know not to send those HAOs. I am not sure how hard state
this is, the credentials would expire by hard timeout after communication
is terminated. For robustness, there is BR, losing a BU would not
break it since CN would send BR before hard timeout in CN side.

True, this would require using BU when using HAO (if
a chosen weak authentication uses BU for its operation). But,
having seen something like this (timeout behavior) in action,
why not use it?

BR,

-Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 10 Dec 2001 23:12:19 +0200

> break it since CN would send BR before hard timeout in CN side.

Ok. This sounds possible. But at least we need to add rules somewhere
that this needs to be done.

Jari

---

From: Francis Dupont <[email-masked]>
Date: Thu, 13 Dec 2001 04:14:34 +0100

In your previous mail you wrote:

   We implementors (I can speak for a few people) 
   were quite happy with Home address option, BU option and 
   IPSec (we made it work with Mobile IPv6), until things started 
   going wrong from December 2000 IETF onwards.
   
=> I fully support Vijay's opinion (and we had firewall persons
in our group).

Thanks

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Thu, 13 Dec 2001 04:36:55 +0100

(about home address option definition (formal & behavior))
   I have brought this up in mobile-ip@ but there wasn't any response...
   
=> this is not really true, there were many complains about the lack
of good description of the home address option, e.g, something better
than you can get in the sec-reqts 6.8.3 (:-)...

Regards

PS: the processing is described in the security requirements section
because of AH...

---

From: Pekka Savola <[email-masked]>
Date: Thu, 13 Dec 2001 15:14:50 +0200 (EET)

> => I fully support Vijay's opinion (and we had firewall persons

And these firewall persons were probably stateful (by themselves or by
connection to AAA system) firewall evangelists?

---

From: Francis Dupont <[email-masked]>
Date: Thu, 13 Dec 2001 17:26:05 +0100

=> by themselves: they are proud to offer one of the first firewalls
with portmap/rpcbind spoofing (i.e. the firewall looks at the port
negociated by portmap/rpcbind and opens a little door for it).
As I already said, IMHO stateful firewalls do a better job than
stateless firewalls (and I prefer to have *no* firewall on the network
I use, specially no firewall managed by another person :-).
We are leaving the mailing list scope...

Regards