Subject: [savi] SAVI agenda at IETF 75 - Please request slots by July 19

From: Christian Vogt <[email-masked]>
Date: Mon, 13 Jul 2009 22:27:37 -0700

Hi folks -

For those of you who wish to present at the SAVI session at IETF 75,
please send me a note.  Please do so before Sunday, July 19.

The SAVI session at IETF 75 is currently scheduled for 9:00 am on
Thursday, July 30, in room Cabaret of the IETF conference hotel.

- Christian

---

From: Frank Xia <[email-masked]>
Date: Tue, 14 Jul 2009 09:20:34 -0500

Hi Christian

We would like 10 minutes for our draft "SAVI for Delegated IPv6 Prefixes"
http://tools.ietf.org/id/draft-kaippallimalil-savi-dhcp-pd-00.txt which
seems to be  covered by current charter.

Please check the charter "Solutions are preferably based on 
observing user traffic,.., and DHCP Prefix Delegation protocols"

BR
Frank

----- Original Message ----- 
From: "Christian Vogt" <[email-masked]>
To: "SAVI Mailing List" <[email-masked]>
Sent: Tuesday, July 14, 2009 12:27 AM
Subject: [savi] SAVI agenda at IETF 75 - Please request slots by July 19

> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi

---

From: Dong Zhang <[email-masked]>
Date: Wed, 15 Jul 2009 10:50:08 +0800

Hi Christian,

May I ask for a time slot to depict the use cases of http://tools.ietf.org/id/draft-dong-savi-cga-header-02.txt if possible.
Although the proposal may beyond the charter now, we would like to share our consideration with everyone.

Many thanks.

>Thursday, July 30, in room Cabaret of the IETF conference hotel.

------------------				 
Dong Zhang

---

From: Alberto García <[email-masked]>
Date: Wed, 15 Jul 2009 11:33:55 +0200

Hi, 
I have joined lately to the list, so I don't know if this has been debated
before, but some questions arise to me:

Why do you need something different to RFC 5533 (Shim6) to transport "out of
the link" CGA-related information?

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?

Regards
Alberto

---

From: Dong Zhang <[email-masked]>
Date: Thu, 16 Jul 2009 10:18:35 +0800

Hi Alberto,

Thanks for your questions.
>the link" CGA-related information?
Because CGA has the good characteristic to prove the address ownership, we should 
use it if possible. 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. 
>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 we 
get the whole security in IP layer, including integrity, confidentiality and 
authentication.
>Alberto

------------------				 
Dong Zhang
2009-07-16

---

From: Alberto García <[email-masked]>
Date: Thu, 16 Jul 2009 11:24:19 +0200

Hi

|  -----Mensaje original-----
|  De: Dong Zhang [mailto:[email-masked]]
|  Enviado el: jueves, 16 de julio de 2009 4:19
|  Para: Alberto_Garc?; 'Christian Vogt'; 'SAVI Mailing List'
|  CC: 'Padmanabha Nallur 73868'
|  Asunto: Re: About draft-dong-savi-cga-header-02.txt
|  
|  Hi Alberto,
|  
|  Thanks for your questions.
|  Alberto 2009-07-15 Wrote:
|  >Hi,
|  >I have joined lately to the list, so I don't know if this has been
debated
|  >before, but some questions arise to me:
|  >
|  >Why do you need something different to RFC 5533 (Shim6) to transport
"out of
|  >the link" CGA-related information?
|  Because CGA has the good characteristic to prove the address ownership,
we
|  should use it if possible. 

I agree

|  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?

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.

|  >
|  >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...

|  we
|  get the whole security in IP layer, including integrity, confidentiality
and
|  authentication.

I think this is completely different stuff than SAVI. 

Regards,
Alberto

|  >
|  >Regards
|  >Alberto
|  >
|  
|  
|  ------------------
|  Dong Zhang
|  2009-07-16

---

From: Dong Zhang <[email-masked]>
Date: Fri, 17 Jul 2009 14:50:26 +0800

>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.
>So just validating a CGA does not assure that the host is authorized to use
In the CGA-related information, it contains the signature. We think it can 
protect the prefix. Right? 
>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.
>I think this is completely different stuff than SAVI. 
In any case, we are trying to see if someone else is impersonating (or using) 
the address. So savi is the closest in the current WGs. Of course, we are open to
looking at this and looking for interset in any related WG.
>Alberto

Thanks
------------------				 
Dong Zhang           
2009-07-17

---

From: Alberto García <[email-masked]>
Date: Fri, 17 Jul 2009 10:16:54 +0200

Hi

|  -----Mensaje original-----
|  De: [email-masked] [mailto:[email-masked]] 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).

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. 

|  >
|  >|  >
|  >|  >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

Regards
Alberto

|  >
|  >|  we
|  >|  get the whole security in IP layer, including integrity, confidentiality
|  >and
|  >|  authentication.
|  >
|  >I think this is completely different stuff than SAVI.
|  In any case, we are trying to see if someone else is impersonating (or using)
|  the address. So savi is the closest in the current WGs. Of course, we are open to
|  looking at this and looking for interset in any related WG.
|  >
|  >Regards,
|  >Alberto
|  >
|  
|  Thanks
|  ------------------
|  Dong Zhang
|  2009-07-17

---

From: Dong Zhang <[email-masked]>
Date: Mon, 20 Jul 2009 10:40:33 +0800

Hi Alberto,
Please check inline.

Thank you.

>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. A…
[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. 

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.
>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.
>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…
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 ? 

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

---

From: Alberto García <[email-masked]>
Date: Mon, 20 Jul 2009 12:28:47 +0200

Hi

|  -----Mensaje original-----
|  De: [email-masked] [mailto:[email-masked]] 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: [email-masked] [mailto:[email-masked]] 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

---

From: Alberto García <[email-masked]>
Date: Wed, 22 Jul 2009 16:16:21 +0200

Hi,

|  -----Mensaje original-----
|  De: Padmanabha Nallur [mailto:[email-masked]]
|  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!
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). 

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.

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:[email-masked]]
|  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: [email-masked] [mailto:[email-masked]] 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: [email-masked] [mailto:[email-masked]] 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

---

From: Dong Zhang <[email-masked]>
Date: Thu, 23 Jul 2009 11:03:39 +0800

Hi Alberto,
>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). 
We are aware of the cost of the computation and the a few possible DoS attacks.
Please read the section 8 and the security consideration in the draft. Would these remove your worry?

Thanks.
>.

---

From: Alberto García <[email-masked]>
Date: Fri, 24 Jul 2009 11:10:23 +0200

Hi Dong,

|  -----Mensaje original-----
|  De: [email-masked] [mailto:[email-masked]] En nombre de Dong
|  Zhang
|  Enviado el: jueves, 23 de julio de 2009 5:04
|  Para: Alberto_García; 'Padmanabha Nallur'
|  CC: 'SAVI Mailing List'; 'Christian Vogt'
|  Asunto: Re: [savi] About draft-dong-savi-cga-header-02.txt
|  
|  Hi Alberto,
|  Alberto_García 2009-07-22 Wrote:
|  >Hi,
|  >
|  >|  -----Mensaje original-----
|  >|  De: Padmanabha Nallur [mailto:[email-masked]]
|  >|  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!
|  >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).
|  We are aware of the cost of the computation and the a few possible DoS attacks.
|  Please read the section 8 and the security consideration in the draft. Would these
|  remove your worry?

Not really. 
As far as I understand, the three types of verification you propose (8.1, 8.2, 8.3) are allowed. 
If you allow 8.1, an host trying to DoS a victim's node will send a CGA Request, and the victim's node will answer with 'CGA Params, CGA Sig'. This costs the victim some CPU: the CGA Request includes a sequence number, and the CGA signature includes this sequence number, so it has to compute specifically for every packet sent.
To protect from this you say in 10: "When one host receives packets with CGA Request from a same source address repeatedly, it MUST refuse to return the CGA Params and CGA Signature." But, of course, a single attacker is going to use different addresses every time!  
So, IMHO, 8.1 introduces a new vulnerability that was not present before. You need to rate-limit the generation of this in general, not for any specific source, and then you should accept packets not protected.
So, if a node wants to impersonate another, first sends lots of requests to start the rate-limited mode, and then sends unprotected packets from a source to impersonate. And the purpose of the mechanism is defeated.

8.3 is almost Shim6. But, since with Shim6 a state is created, you don't need to convey the CGA information on every packet. Security is less (you are not requesting all the time the other end to prove it has the private key), but it may be enough for this purpose, since it was proved at the beginning the address ownership, and the will of the remote host to communicate. 
This is statefull, and intermediate routers could not perform any kind of filtering based on this information unless they trace the whole exchange. 
But I don't see which protection could be provided without state: you have included a sequence number and a request/response mechanism that use it (8.1, 8.2, 8.3), and it is a good approach because it protects against reply attacks. If intermediate routers are not aware of this exchange (because they work without state), they are prone to reply attacks. 
I really don't see a clear benefit/cost/security_risk balance for allowing routers in any intermediate location to perform such filtering.

8.2 is an in-between 8.1 - 8.3

Regards,
Alberto

|  
|  Thanks.
|  >
|  >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.
|  >
|  >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:[email-masked]]
|  >|  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: [email-masked] [mailto:[email-masked]] 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: [email-masked] [mailto:[email-masked]] 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
|  >
|  >.
|

---

From: Alberto García <[email-masked]>
Date: Fri, 24 Jul 2009 11:15:39 +0200

Hi Paddy

|  -----Mensaje original-----
|  De: Padmanabha Nallur [mailto:[email-masked]]
|  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:[email-masked]]
|  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:[email-masked]]
|  |  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:[email-masked]]
|  |  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: [email-masked] [mailto:[email-masked]] 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: [email-masked] [mailto:[email-masked]] 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

---

From: Padmanabha Nallur <[email-masked]>
Date: Mon, 20 Jul 2009 14:00:50 -0700

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:[email-masked]] 
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: [email-masked] [mailto:[email-masked]] 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: [email-masked] [mailto:[email-masked]] 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.

|  >
|  >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

---

From: Padmanabha Nallur <[email-masked]>
Date: Thu, 23 Jul 2009 13:55:58 -0700

Hi,

Please see inline with [Paddy2].

Thanks
Paddy Nallur

-----Original Message-----
From: Alberto García [mailto:[email-masked]] 
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:[email-masked]]
|  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., We would be very glad to receive any suggestions in
this direction.

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. Do you know, how much acceptance is there for the
Shim6 in the industry ? Any pointers would help us.

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 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:[email-masked]]
|  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: [email-masked] [mailto:[email-masked]] 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: [email-masked] [mailto:[email-masked]] 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