Re: [savi] About draft-dong-savi-cga-header-02.txt

[Padmanabha Nallur <[e-mail]>]

Hi Alberto,

The main point of the CGA proposal is to avoid IP spoofing.
In order to avoid IP spoofing the source IP address checks must be performed
closer to the destination or destination network as opposed to implementing
these checks in the source network (e.g., SAVI).

The CGA proposal provides an alternative solution to prevent IP spoofing by
providing the checks that can be implemented in the destination endpoint or
destination network (actually anywhere in the network). We would like to
have as simple solution as possible and preferably even stateless solution.
This is the main goal of CGA proposal and it would be great if it can ALSO
be used in other situations (e.g., SAVI) as you mentioned below.

Validation of the IP address itself (like prefix check) is not the main goal
of the CGA proposal.


Thanks
Paddy Nallur

-----Original Message-----
From: Alberto Garc¨ªa [mailto:[e-mail]] 
Sent: Monday, July 20, 2009 3:29 AM
To: 'Dong Zhang'; 'Christian Vogt'; 'SAVI Mailing List'
Cc: 'Padmanabha Nallur 73868'
Subject: RE: [savi] About draft-dong-savi-cga-header-02.txt

Hi

|  -----Mensaje original-----
|  De: [e-mail] [mailto:[e-mail]] En nombre de
Dong
|  Zhang
|  Enviado el: lunes, 20 de julio de 2009 4:41
|  Para: Alberto_Garc¨ªa; 'Christian Vogt'; 'SAVI Mailing List'
|  CC: 'Padmanabha Nallur 73868'
|  Asunto: Re: [savi] About draft-dong-savi-cga-header-02.txt
|  
|  Hi Alberto,
|  Please check inline.
|  
|  Thank you.
|  
|  Alberto_Garc¨ªa 2009-07-17 Wrote:
|  >Hi
|  >
|  >|  -----Mensaje original-----
|  >|  De: [e-mail] [mailto:[e-mail]] En nombre de
|  Dong
|  >|  Zhang
|  >|  Enviado el: viernes, 17 de julio de 2009 8:50
|  >|  Para: Alberto_Garc?; 'Christian Vogt'; 'SAVI Mailing List'
|  >|  CC: 'Padmanabha Nallur 73868'
|  >|  Asunto: Re: [savi] About draft-dong-savi-cga-header-02.txt
|  >|
|  >|  Alberto_García 2009-07-16 Wrote:
|  >|  >|  I do not think it is a conflict. The difference is just how to
|  >|  >|  use CGA. For instance, the CGA proposal can be used in e2e, even
|  between
|  >|  >the
|  >|  >|  host
|  >|  >|  and the first-hop router. It can depend on the destination option
header.
|  >|  >
|  >|  >Shim6 allows transporting CGA information end-to-end. It does that
now, in
|  a
|  >|  >standard way. Why you should want to generate a yet-another-protocol
to
|  >|  >transport CGA information end-to-end?
|  >|  Thank you for the information.
|  >|  We will read Shim6. If it really does the relative job, we will be
glad to use it.
|  >|  >
|  >|  >Besides, what does such a protocol would have to do with SAVI?
|  >|  >If you want to use CGAs for providing security in the link of the
host and
|  >|  >the first-hop router, you should probably use the SEND protocol (see
|  >|  >draft-ietf-savi-send-00). Do you think there is something in the
SEND
|  >|  >protocol that does not suit with binding IPv6 addresses and link
layer
|  >|  >anchors, that could be improved?
|  >|  >And if you want to use the CGA for address validation further than
the first
|  >|  >hop routers, I see some reasons why you should not:  at that point
you
|  need
|  >|  >to validate prefixes, not host addresses, and CGA provides no
protection for
|  >|  >prefixes: any host can generate a valid CGA with whichever prefix it
wanted.
|  >|  >So just validating a CGA does not assure that the host is authorized
to use
|  >|  >that prefix.
|  >|  In the CGA-related information, it contains the signature. We think
it can
|  >|  protect the prefix. Right?
|  >
|  >Well, it does not prove that a host has been legitimately assigned a
prefix.
|  >CGAs, with a protocol transporting signatures made with the private key,
only
|  assure that once a host generates a given address, it is very very
difficult for
|  another host to use the same address. And yes, the protection includes
the
|  prefix: it is just not enough to find a key pair whose hash generates a
given
|  interface identifier, and then you can impersonate any host with the same
|  interface identifier in any network (i.e. with any prefix).
|  [Dong] Well, yes, we agree with this. CGA does not do identity
authentication.
|  We only validate the address so that someone else cannot use this IP
address.
|  We do not check for the IP address binding with a host  or a user or some
other
|  higher level entity and validate that.
|  
|  Just the fact that someone else cannot use the same address would give
the
|  benefits mentioned in the use cases within the draft.

I think the place to do this is in the first link. And the tool SEND + SAVI.
Outside the first link, I think it is too costly to do checks in a
per-address basis, and you need other tools (manual configuration, routing
info...) for validating prefixes... so just validate prefixes with this
tools.

|  
|  IMHO, we don't think even SAVI solutions need to validate the binding of
IP
|  address with users etc., only check if a certain IP address is used on a
specific
|  link.

Yes, of course. I was not talking at any point in "users". 
Again, to check the address, use SEND.

|  >
|  >But that says nothing about the legitimacy of ah host to use that
prefix.
|  >For example, give the prefix of your network, and I can generate
immediately
|  an CGA that claims to belong to your prefix: CGA = hash ( prefix | public
key |
|  etc). And I can use from my network, if the router (and some routers
above)
|  does not check source prefixes. Looking only at the CGA nobody can know
if my
|  host is authorized to use a prefix or not.
|  >So, CGA does not add anything to prefix protection. You have to provide
other
|  means to protect that.
|  I guess the ingress filtering could do this. And savi solutions are the
complement
|  for ingress filtering. This point has been discussed before.
|  >
|  >
|  >|  >
|  >|  >|  >
|  >|  >|  >What does this type of solutions has to do with SAVI,
considering that
|  >|  >the
|  >|  >|  >charter says: "No changes to hosts are allowed."? Isn't your
solution
|  >|  >|  >proposing a change to hosts?
|  >|  >|  Yes, the CGA proposal does not fit for the current charter quit
well to
|  >|  >some
|  >|  >|  extend.
|  >|  >|  The reason why we put the CGA-related info in the extension
header is
|  >|  >that it
|  >|  >|  has
|  >|  >|  the ability to provide a basic security for the source address
like AH &
|  >|  >ESP. The
|  >|  >
|  >|  >The CGA security model does not have much relationship with AH &
ESP.
|  Well,
|  >|  >all use keys, but besides that...
|  >|  I mean if we could take the CGA-related information in the extension
header,
|  >|  the packet will have AH, ESP and CGA for the basic security
characteristics,
|  >|  including integrity, confidentiality, and authentication.
|  >
|  >This is completely different stuff. It seems like generating an
opportunistic IKE
|  security context (a la SSL) for a communication, starting with the
public/private
|  key pair associated to the CGAs of two hosts. Then you should look at
|  http://tools.ietf.org/id/draft-laganier-ike-ipv6-cga-02.txt
|  I am a little confused here. I have already known this draft before. Are
you
|  comparing it with my another draft,
http://tools.ietf.org/id/draft-zhang-shen-sa-
|  cga-00.txt ?

I was not aware of your draft. I wasn't comparing anything, but, from the
title of your draft, yes it seems similar.

Regards,
Alberto

|  
|  
|  ------------------
|  Dong Zhang
|  2009-07-20