Pekka, Here are the answers for IPsec/MIPv6 related questions.
>On Fri, 1 Mar 2002 [EMAIL PROTECTED] 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.. > >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. We don't force mobility to LCNA itself, but at least LCNA have to handle packets from other Mobile Nodes. > <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. I have not followed up MIPv6 discussion yet, but I understand LCNA-specific PH type might answer to the requirement. >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.. 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. >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. 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. >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'. What we are saying about security has two aspects, - > * 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. 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 PROTECTED] -------------------------------------------------------------------- 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 PROTECTED] --------------------------------------------------------------------
