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

From: Pekka Savola <[email-masked]>
Date: Sat, 2 Mar 2002 12:44:16 +0200 (EET)

On Fri, 1 Mar 2002 [email-masked] wrote:
> 	Title		: Minimum Requirement of IPv6 for Low Cost Network 
>                           Appliance
> 	Author(s)	: N. OKABE et al.
> 	Filename	: draft-okabe-ipv6-lcna-minreq-01.txt
> 	Pages		: 20
> 	Date		: 28-Feb-02

A few comments in  addition to ones I sent for -00..

              Table 1. Resource restrictions of LCNA

   ===============+===============+==================+=======
                   Memory          CPU Performance    OS
   ===============+===============+==================+=======
    PC             >64MB           Pentium/64bits     Windows
   ---------------+---------------+------------------+-------
   PDA             2-8MB           RISC/32bits(50MHz) WinCE  
                                                      VxWorks
                                                      PalmOS 

==> I think it'd be policitally correct to _at least_ change 'Windows'
there to 'Any', and possibly add 'Others' to PDA section (e.g. I like
Linux and NetBSD on PDA's :-).

2.7 Security
    In Section 4 "Security for LCNA", we will regulate a baseline for
    guaranteeing that a minimum host can communicate securely. However,
    Denial of Service (DoS) and intrusion are out of scope.  So, we have
    to consider defending from DoS and/or intrusion in another place.   
    Also, the authentication of users is out of scope, because some     
    minimum hosts can omit a mechanism of user accounts.

==> intrusion out of scope?  What do you mean by that?
Auth?

2.8 Mobility support
    In this draft, we do not assume that LCNA itself moves on the
    network, but the processing from other nodes that operate as Mobile
    Nodes of Mobile IPv6 is mandatory.

==> I don't see why you force mobility but neglect security.

    - When it can recognize the extension header but does not support
      the options in it, it MUST perform error processing according to
	  the option number.

==> you mean s/extension header/destination options header/?  There is no 
processing defined by option number for extension headers.

    [Receiving]
    A minimum host SHOULD recognize it as a Hop-by-Hop Options Header,
    and  perform the processing according to the option and option
    number in it. Because this option is used for signaling and router
    alert, in order to control routers on the path, all nodes on the  
    transmission path have to interpret this header but do not need to
    interpret all options in it.

==> I don't understand your reasoning for router alert; LCNA's aren't 
routers by definition :-)

3.1.2 Routing Header
    [Sending]
    Following 3.1, minimum hosts do not send packets with this extension
    header.

    [Receiving]
    RFC regulates that if the Segment Left field has non-zero value in
    this header, the node has to forward the packet to the next
    intermediate node, even when the node is a host. But in the case of
    a minimum host, this forwarding MAY be omitted and be treated as an
    unsupported extension header, because only intermediate nodes (such
    as routers) and the destination node have to interpret this header.

==> please see draft-savola-ipv6-rh-hosts-00.txt

    <Optional>
    One exception is when the minimum host supports the mobile node
    function of Mobile IPv6. As Mobile IPv6 uses a Routing header for
    receiving packets destined to Mobile Node, this header MUST be   
    processed correctly. Another exception for sending this header is
    when using route optimization for communicating with Mobile IPv6 
    mobility agents. If route optimization is performed using binding
    update, the node MUST send packets with these extension headers. 

==> mobile-ip wg chairs just decided that the consensus was to define a 
new routing header type for MIPv6, so LCNA's might only need to process 
type 2 RH's.

3.1.3 Fragment Header

    If a minimum host satisfies the following conditions, the host MAY
    not send this extension header, and MAY treat one as an unsupported
    header when receiving it.

==> I'm not sure what the robustness principle would say about hosts that 
cannot defragment.

3.1.4 Destination Options Header
    A minimum host SHOULD recognize this header as Destination Options
    Header and perform processing according to the options and option 
    numbers in it. One exception is the handling of Home address
    destination option for Mobile IPv6. As mentioned in section 2.8,
    even if LCNA itself does not move, it has to process the packets
    sent from other mobile nodes. Therefore, the processing of Home 
    address option becomes mandatory. However, since final specification
    of Mobile IPv6 is not regulated yet, we omit the concrete regulation
    for LCNA now.

==> one does not need to interpret HAO if one wants to communicate with 
mobile node: then all the traffic would just have to go through the Home 
Agent.  In LCNA case, Home Agent would probably most often be in the home 
network, so nothing would be lost..

3.3 Neighbor Discovery for IP Version 6 (IPv6) (RFC2461) [22]
    In this draft, we assume that an LCNA has only one network
    Interface, but it does not inhibit multiple interfaces. When
    an LCNA is assumed to have multiple interfaces, the following
    considerations are necessary, which requires more resources. 

    - Source address selection

==> even with one interface, the LCNA has multiple addresses, so it 
obviously still needs source address selection (consider e.g. the case 
with link-local, site-local, 6to4 address, and native address).  It may 
not necessarily need to be as complex though.

3.5 Internet Control Message Protocol (ICMPv6) for the Internet Protocol
    Version 6 (IPv6) Specification (RFC2463) [24]

    On minimum hosts, ICMP used only by a router MAY be omitted (Table
    2). ICMPs for Echo Request/Reply and minimum error reporting MUST be
    supported.

==> this MUST includes rate-limiting of error replies, I hope?

		Table 2. Mandatory ICMP messages for LCNA
	===============+===============================+==========
	Type		Code                            Necessary?
	===============+===============================+==========
	1:		0: No route to destination	No
	Destination	1: Administratively Prohibited  No
	Unreachable	3: Address unreachable		No
	Message		4: port unreachable		Yes

==> depending on how MIPv6 goes, some of these (e.g. admin prohibit)
might become necessary too.

3.7 DNS Extensions to support IP version 6 (RFC1886) [26] and IPv6  
    Stateless DNS Discovery (draft-ietf-ipngwg-dns-discovery-02.txt)
    [27]

    The only function that is not supported in the current IPv6
    autoconfiguration is automatic discovery of DNS server. On this
    topic discussions are ongoing in IETF IPNG WG. If a standard is
    fixed, it might become a mandatory item for minimum hosts.    
    AAAA record is defined for transform from IPv6 name to IPv6   
    address. So, AAAA is currently mandatory for minimum host name
    resolution. Also, A6 record is currently proposed and discussed in
    IETF for an alternative of AAAA record.  We need to check the
    progress.

==> What about reverse lookups?  nibble-style, probably?  ip6.int or 
ip6.arpa, or both?

4.2 Security mechanism for LCNA
    For example, IPsec realizes security on the IP layer, which is
    transparent from the transport and/or application layer, so it can
    be a generic solution. On the other hand, IPsec does not work well
    with IP layer translation technology (such as NAT and IPv4/IPv6
    translator), which might be a restriction for the promotion of
    LCNAs.

==> I disagree with the latter: IMO it's ok to assume that people who want 
to connect remotely (when security is a MUST) to LCNA would use native 
IPv6.

4.3 Minimum security specification for LCNA
    
==> basically you seem to be saying it's okay to omit security (meaning 
encryption) if LCNA is so underpowered it can't handle it.  I disagree.  
Put a better chip on it or say something to the effect 'If proper[??] 
encryption and security is not implemented, the node MUST NOT have a 
global address'.

6.2 Management facilities for LCNAs

==> personally I think being able to remotely monitor the status of the 
system is a rather necessary feature.

7. Security Consideration
    As mentioned in 2.7, DOS and intrusion are out of the scope of this
    draft.

==> you cannot specify requirements while leaving these features out of 
scope.

10 Appendix: Example of IPSEC minimum requirements specification
[...]
    We believe that IPsec is an effective technology in order to  
    guarantee security of communication. That is the reason why we
    regulate the minimum IPsec specification in this draft.

==> this needs editing as the last sentence is obviously false.

    * Even though we regulate minimum IPsec as mandatory, no one uses
      it because there are no prospects to deploy it in the real 
      world. Therefore, it is WRONG to regulate the IPsec minimum
      specification as mandatory.

==> FUD.  IPsec works fine in closed environment (which is what LCNA would 
be used in): it's trivial to perform manual keying for all of your systems 
(e.g. two computers and a few LCNA's), or use something like IKE in a 
restricted domain.

Strangers accessing LCNA using IPsec is the problem you're referring to, 
but they shouldn't access it anyway. :-) 

(I didn't read the rest of the ipsec appendix).

HTH,

-- 
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: Atsushi INOUE <[email-masked]>
Date: Tue, 05 Mar 2002 15:08:35 +0900

Pekka, 

Here are the answers for IPsec/MIPv6 related questions.

>==> I don't see why you force mobility but neglect security.

We don't force mobility to LCNA itself, but at least LCNA have to 
handle packets from other Mobile Nodes.

>new routing header type for MIPv6, so LCNA's might only need to process 

I have not followed up MIPv6 discussion yet, but I understand 
LCNA-specific PH type might answer to the requirement.

>network, so nothing would be lost..

We have not made any specific assumption for the configuration of 
LCNA-involved network. The above discussion deeply depends on the 
distance between LCNA and its Home agent and the amount of traffic 
between them. In some case, your proposal might acceptable, but 
anyway, we have to propose network model for each solution.

Basically what is lacking in our draft is this "LCNA network 
models", which makes the Mobility/Security discussion very 
difficult, I think.

>to connect remotely (when security is a MUST) to LCNA would use native 

If your proposal is to specify that "When security is a MUST, do not 
use IPv4/IPv6 translator", that might be reasonable and IPsec can 
work on that.

But this kind of discussion is also to make a specific assumption to 
LCNA-involved network configuration.

So, I would like to say, 
When discussing about security/mobility of LCNA, let's having a 
network configuration disucussion before saying about specific 
solutions. 

>encryption and security is not implemented, the node MUST NOT have a 

What we are saying about security has two aspects,　
- 

>(e.g. two computers and a few LCNA's), or use something like IKE in a 

Yeah, in some specific network configuration IPsec works!
So, this is also falling into network configuration discussion.

For IPsec discussion, the ML thread of cellular draft says IPsec 
implementation have to be mandated. I think the discussion depends 
on what is the purpose of these (cellular/LCNA) node requirement 
drafts. If these drafts regulates baseline implementation of thease 
nodes for rather long-term, IPsec should be mandated in order to 
realize better security infrastructure. But if these drafts only 
aims to work as a kind of implementation guideline, the node 
vendors might feel that mandating IPsec might be tough because of 
poor resource performance (for IPsec) and security requireent for 
the application is not so high currently.

-- inoue

-- 
Atsushi INOUE mailto:[email-masked]