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

[Alberto García <[e-mail]>]

Hi Paddy

|  -----Mensaje original-----
|  De: Padmanabha Nallur [mailto:[e-mail]]
|  Enviado el: jueves, 23 de julio de 2009 22:56
|  Para: 'Alberto García'
|  CC: 'Dong Zhang'; 'Christian Vogt'; 'SAVI Mailing List'
|  Asunto: RE: [savi] About draft-dong-savi-cga-header-02.txt
|  
|  Hi,
|  
|  Please see inline with [Paddy2].
|  
|  Thanks
|  Paddy Nallur
|  
|  -----Original Message-----
|  From: Alberto García [mailto:[e-mail]]
|  Sent: Wednesday, July 22, 2009 7:16 AM
|  To: 'Padmanabha Nallur'
|  Cc: 'Dong Zhang'; 'Christian Vogt'; 'SAVI Mailing List'
|  Subject: RE: [savi] About draft-dong-savi-cga-header-02.txt
|  
|  Hi,
|  
|  |  -----Mensaje original-----
|  |  De: Padmanabha Nallur [mailto:[e-mail]]
|  |  Enviado el: lunes, 20 de julio de 2009 23:01
|  |  Para: 'Alberto García'
|  |  CC: 'Dong Zhang'; 'Christian Vogt'; 'SAVI Mailing List'
|  |  Asunto: RE: [savi] About draft-dong-savi-cga-header-02.txt
|  |
|  |  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.
|  
|  In my opinion, what you are proposing is dangerous. Let's consider
|  flood-based DoS (draft-ietf-savi-threat-scope-00.txt): an attacker wants to
|  exhaust the victim's resources by sending traffic to it. With your
|  mechanism, packets with false CGA information do not only consume TCP state,
|  memory for IP fragmentation... but they also force the host to spend a lot
|  of CPU in using public cryptography to check a CGA! This is what any
|  attacker would like: force hosts to do a lot of work for fake packets!
|  
|  [Paddy2] Yes, we are well aware of these problems having worked in this area
|  for several years. We are also looking at further simplifications like
|  making it stateless, performing the public/private key cryptography only for
|  the first packet etc., 

Statefull?

|  We would be very glad to receive any suggestions in
|  this direction.

Please see my previous email.

|  
|  This is why in Shim6 and HIP a 4-way handshake is performed: the initiator
|  must prove at least that the address is using is topologically valid (for
|  accounting purposes).
|  
|  [Paddy2] I took a quick look at Shim6 and it seems like it is meant to solve
|  a different problem than the one we are trying to. It looks incredibly
|  complex for CGA proposal. 

Yes, it solves a different problem. But there could be, if this approach is value (at least for the end host) an applicability statement for this use.
Don't think it is so complex in the part related to the initial exchange, which would be the part of the specification required. Of course, for this use no locator exchange would be required...

|  Do you know, how much acceptance is there for the
|  Shim6 in the industry ? Any pointers would help us.

Well, it is just standard from June 09... 
Although it is a bit outdated, you can find some pointers about implementations in http://www.shim6.org/


|  
|  
|  In addition, you propose not only perform this DoS-prone check not only in
|  the host, but  anywhere in the network. So any router should divert a packet
|  from the silicon fast path to the router CPU to check the CGA... That would
|  be double prize for the attacker: not only compromising a host, but the
|  whole communication pipe of a site.
|  
|  [Paddy2] We are not saying that this should be performed all over the
|  network. It CAN be done in selective locations without compromising the
|  device performance.

I think this has important problems, see previous email.

Regards,
Alberto

|  
|  I really don't see this.
|  
|  Regards,
|  Alberto
|  
|  |  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韆 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