Re: FCIP: NAPTs Solution Proposal (issue from Irvine, CA Interim meeting)

[Ralph Weber <ralphoweber@compuserve.com>]

David,

You appear to be saying one of two things:

1) The NAPTs solution, as proposed, requires that FCIP eschew the
   use of group pre-shared keys, or
2) The problems with the best on offer FCIP NAPTs solution design
   are sufficient to convince the IESG that FCIP is justified in
   prohibiting the use of NAPTs.

Although time may have altered opinions, I will note that option
2) conforms to the position of several people on the FCIP development
team during the Irvine meeting. Certainly, option 2) greatly
simplifies the changes required in FCIP.

It is clear that you will object to ANY form of identification
that an FCIP Entity offers for one of the following reasons:

  a) Offering IP addresses is unacceptable because of NAPTs, and
  b) Offering any other value is unacceptable because it is not
     secure with group pre-shared keys.

Unless option 1) above is your real concern, it appears that the
FCIP development team has spent two months on a near fruitless
exercise, whose only benefit is a strong proof that FCIP should
not support NAPTs.

Ralph...

Black_David@emc.com wrote:

> > For those cases where a secure environment is required, the
> > new connection comes up through the normal IPSec authentication
> > and encryption processes.  As a result, the transmission of
> > the identifying world wide names is already transmitted in an
> > encrypted format, creatable only by the authenticated and
> > certified source and interpretable only by the authenticated
> > and certified destination.
>
> The assumption that there's a big on/off switch for
> security is not correct (e.g., suppose IPsec is running
> with integrity on and confidentiality off) and
> "authenticated and certified" is a peculiar concept for
> group pre-shared keys, a very likely deployment scenario.
> Also, IPsec has no clue about the WWN, and hence the IKE
> authentication is not linked to the WWN that has to be
> presented (a particular problem with group pre-shared keys,
> but also a risk even with certificates).  In other words,
> "authenticated and certified" doesn't place any restrictions
> on what WWN is presented.  Finally, solving
> an inband authentication problem by requiring that IPsec be
> used to encrypt the WWN is wildly excessive, and besides,
> the WWN has no secret contents- it's a public piece of
> configuration information.
>
> There is a solution in this general area, but it involves
> linking the WWN to the IKE identity that is authenticated.
> That's probably going to break any attempt to use existing
> off-the-shelf external IPsec gateways because gateways
> don't grok WWNs, and the FCIP implementations won't
> know what identity was used in the IKE authentication
> to the gateway.  This is all a bit peculiar because FC
> currently trust WWNs passed in various FC Login frames
> without authenticating them, but that's T11's area of
> responsibility putting this sort of thing into an IETF
> standard isn't going to be acceptable.
>
> > If the Fibre Channel fabric is also operating in a secure mode,
> > subsequent Fibre Channel authentication and certification
> > is performed using the standard FC SLAP mechanisms.
>
> Only on the first TCP connection, unless you plan to require
> taking the FCIP link down when the second TCP connection
> is added (which strikes me as highly counterproductive).
> The second connection just inherits the results of the SLAP
> performed on the first one, whether its entitled to or not.
>
> > In addition to this, there are a whole bunch of policy
> > restrictions that are verified as part of the creation
> > of subsequent connections.  While these are not necessarily
> > part of the security steps, they prevent the formation of
> > connections which do not meet the security rules.
>
> I'm not sure what you're referring to, but I suspect they
> don't help much here.
>
> > Assuming security mechanisms are properly implemented, where,
> > then, is the security hole?
>
> The fact that the WWN is not authenticated means that anyone
> who can set up an FCIP connection to an FCIP entity can tap
> into any existing FC traffic flowing on any connection through
> that FCIP entity.
>
> --David