Subject: Re: I-D ACTION:draft-okabe-ipv6-lcna-minreq-00.txt

From: Pekka Savola <[email-masked]>
Date: Sat, 17 Nov 2001 15:05:56 +0200 (EET)

The cork is already off the bottle so here I go too :-)

On Fri, 16 Nov 2001 [email-masked] wrote:
> As the always-on network is becoming popular, lots of nodes, not
> only ordinary PCs but also various information appliances such as
> sensors, home appliances, AV equipments, are to be connected to the
> Internet.

Note: there isn't much discussion on certain MIPv6-mandated subjects, like 
Home Address Option processing.  One will have to clarify this; however 
MIPv6 is under much discussion as right now so the situation could change.

--8<--
3.3 Neighbor Discovery for IP Version 6 (IPv6) (RFC2461) [22]
    Because of IPv6 minimum host definition, the following functions for 
    routers can be omitted.  
    
    - Sending router advertise messages 
    - Receiving router solicitation messages 
    - Sending redirect messages 
--8<--

I don't think it's a good idea to suggest router solicitations can be 
omitted.  MinRtrAdvInterval could be rather large, and it might take very 
long to get the next periodical advertiment.  RS is not such a complex 
matter.

--8<--
4.1 Consideration of security for LCNAs
    [...]
    
    Currently, there are several issues that prevents from realizing
    security even if IPsec minimum specification is implemented. The
    first issue is the network environment. In order to deploy minimum
    hosts on current network environment, we cannot neglect existing
    IPv4 networks. So, we have to assume NAT or IPv4/IPv6 translators
    between the minimum host and the correspondent host. Current IPsec
    cannot handle such a situation, which means the effectiveness of
    security mechanism relying upon IPsec is very limited.    
--8<--    

The draft didn't want to discuss transition issues (2.2), now you bring 
them up anyway.  I think it's very safe to assume that IPv6 space the 
application seems is fully global without NAT's or anything.  

Further, I'm not sure whether there actually much need to be able to use 
IPSEC (or any connections) past the translator.  A picture:

Internet --- ISP router --- Home Router --- LCNA box

The translation happens either in Internet, ISP router or Home Router.  
The primary target of the services are home users, that is, those that 
would never need translation or are pretty safe anyway.

If someone would like to use LCNA from the Internet, I'd suggest mandating 
IPv6; we cannot be held hostage by legacy IPv4/NAT (plus how these affect 
IPSEC) issues.

Therefore I think it might be safe to assume there are no unsurmountable 
problems w.r.t. IPSEC use.

--8<--
6. Security Consideration
    RFC3401 
--8<--
RFC3041 :-)

-- 
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: OKABE Nobuo <[email-masked]>
Date: Mon, 19 Nov 2001 15:16:47 +0900 (JST)

thank you for taking your time.

From: Pekka Savola <[email-masked]>
Subject: Re: I-D ACTION:draft-okabe-ipv6-lcna-minreq-00.txt
Date: Sat, 17 Nov 2001 15:05:56 +0200 (EET)

> MIPv6 is under much discussion as right now so the situation could change.

A kind of munimum host should not have mobility.
It means the host does not have to implement MIP6 related functions.
This is the reason why this draft does not mandate MIP6.

> long to get the next periodical advertiment.  RS is not such a complex 

This draft assumes that a minimum host is not a route but a host.
Therefor, router related ND functionaions should be ommited:
  - Sending router advertise messages 
  - Receiving router solicitation messages
  - Sending redirect messages 	  

Of course, the host must implement host-related ones:
  - Receiving RA messages
  - Sending RS messages
  - (Receiving REDIRECT messages)

> them up anyway.  

As you pointed it is our weak point as you a
Honestley speaking, we don't want to rely on any specific
transtion technology. 

> I think it's very safe to assume that IPv6 space the 

How long time-frame do you assume?
Your assumption may not work if someone want to develop
a LCNA for "right-now" business.

> would never need translation or are pretty safe anyway.

Please let me clarify the point.
Do you mean that almost communication happens between LCNAs
behind the home router?

> problems w.r.t. IPSEC use.

It is important for people who thinks LCNAs as a business seriousely
to work with legacy network. How should we deal with it?

> 6. Security Consideration

wow.... thanks.

--- nobuo

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Mon, 19 Nov 2001 15:38:12 +0900

> This is the reason why this draft does not mandate MIP6.

The problem is that if a mobile node try to connect the peer with the
home address destination option and the peer doesn't support the home
address destination option, these two can't communication forever.

This is because (at least current) MIP6 requires all the IPv6 nodes to
process the home address destination option (means to be mobility
aware) even though they are not mobile.  But, as Pekka have said
already, MIP6 need much discussion and such requirement may change...

P.S. KAME/MIP6 fallbacks to using CoA if the destination peer send
ICMP paramprob against the home address destination option.  Of course
this breaks mobility but very useful in transision period or may be
for such a minimum host okabe-san said.

---
Keiichi SHIMA
IIJ Research Laboratory  <[email-masked]>
KAME Project <[email-masked]>
--------------------------------------------------------------------
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: Pekka Savola <[email-masked]>
Date: Mon, 19 Nov 2001 09:15:09 +0200 (EET)

> This is the reason why this draft does not mandate MIP6.

Certain aspects of MIPv6 are, as currently being specified, a *MUST* for 
*EVERY* IPv6 node, whether it is mobile or stationary.  An example of this 
is the processing of Home Address Option.  There are more.  It is possible 
that this will change, but to which direction, it's difficult to say.

>   - (Receiving REDIRECT messages)

Sorry, I didn't read carefully enough.  I meant sending RS messages, which 
are already covered.

> a LCNA for "right-now" business.

Note that I said IPv6 space is fully global without [IPv6] NAT's.

That is, as long as the other node is speaking native IPv6, there will be 
no problems wrt. IPSEC.  How the other node gets this IPv6 connectivity is 
irrelevant, be it behind IPv4 NAT (e.g. via Shipworm), 6to4 or whatever.

> Do you mean that almost communication happens between LCNAs

Yes, I believe this is the case.  In this kind of closed network, IPSEC is 
not a *huge* problem.

There are arguably some uses for to be able to access LCNA boxes from the 
Internet, but you could mandate that pure IPv6 without translation is used 
there, so that IPSEC would non-problematic.

See below.

> to work with legacy network. How should we deal with it?

Let me try to clarify this.

In real world, the scenario would currently or in the near future be 
something like this:

(sorry for shoddy User A&B&C, ran out of space :-)

                                         .- Home User 1 (IPv4)
                             IPv4/IPv6  /                                             
Internet --- ISP router --- Home Router --- LCNA box    (IPv6)
 |     | \     	                        \
User A B  C                              '- Home User 2 (IPv6)
IPv4/6 4  v6                                        

(IPv6 connectivity can be native, 6to4, Shipworm from behind IPv4 NAT's, 
whatever, as long as it exists.

If Home User 2 wants to access LCNA, it works without problems, with or 
without IPSEC.

If Home User 1 wants to access LCNA, translation will be required.  
Translation would kill IPSEC, but as Home User 1 is in a "secure" 
environment" this is not a problem.  Only problem is that the translation 
MUST occur in the Home Router, not upstream.

If User A from the Internet wants to access LCNA, IPv6 can be used and 
IPSEC can be used.

If User B from the Internet wants to access LCNA, IPv4 would have to be 
used, but the packet would have to translated, and IPSEC would not be 
guaranteed.  This scenario will not work because any user from Internet 
cannot be trusted without IPSEC or similar precautions.

If User C from the Internet wants to access LCNA, IPv6 can be used and 
IPSEC can also be used fine.

So, the only issues I see are:
 - translation would have to occur within the secure domain, that is, home 
router.  Translation is required only if we want to allow access from home
IPv4-only nodes.
 - IPv4-only nodes from the Internet cannot access LCNA.  As we're talking 
about an _IPv6_ LCNA, I believe this is a reasonable assumption.  It's 
rather easy to get IPv6 access if you really want.

---

From: OKABE Nobuo <[email-masked]>
Date: Wed, 21 Nov 2001 09:54:52 +0900 (JST)

From: Pekka Savola <[email-masked]>
Subject: Re: I-D ACTION:draft-okabe-ipv6-lcna-minreq-00.txt
Date: Mon, 19 Nov 2001 09:15:09 +0200 (EET)

> that this will change, but to which direction, it's difficult to say.

"a *MUST* for *EVERY* IPv6 node" is very strong requirement.

LCNA also will have to process Home Address Option
if the above requirement is a consensus of IPNG (or IPNG and Mobileip?).
Have the consensus already been reached?

We also have to examine impacts on LCNA's specification, code size or so
when enabling to process Home Address Option.

> Note that I said IPv6 space is fully global without [IPv6] NAT's.

Sorry, I did not intend to say so.
I agree with you.

> IPSEC can also be used fine.

Thank you for your clarification.
That is very usefull for us.

> router.  Translation is required only if we want to allow access from home

It depends upon the specification of the home router.
But the discussion of home route is out of our scope.
So I would like to push it aside or another discussion.

> rather easy to get IPv6 access if you really want.

This might be an issue of LCNA deployment.
But it is out of the draft's scope.
so, I agree.

thanks,

---- nobuo

---

From: Jari Arkko <[email-masked]>
Date: Wed, 21 Nov 2001 11:06:27 +0200

>Have the consensus already been reached?

I think the situation is that the HOA has been stable and
there has been consensus, but recent discussions and drafts
have cast some doubt on the issue. I would say the fate of
the HOA is currently unclear and there is no consensus. I
think the possible outcomes are (1) we decide the HOA is
good and should stay as it is, (2) we decide the HOA can be
used, but only in the context of doing Route Optimization
(which would make the HOA optional in IPv6), and (3) we
decide to use something else than HOAs, such as some tunneling
scheme.

For further information, see

http://search.ietf.org/internet-drafts/draft-nordmark-mobileip-mipv6-hindsight-00.txt
http://search.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-security-00.txt
http://search.ietf.org/internet-drafts/draft-arkko-mipv6ro-secframework-00.txt

Jari