Subject: [savi] SAVI SEND RADV validation (was RE: I-D Action: draft-ietf-savi-send-08.txt)

From: Greg Daley <[email-masked]>
Date: Tue, 18 Sep 2012 04:35:25 +0000

Hi Marcelo and Alberto, 

Thanks for your work on this.

I am wondering how router validity can be ascertained by the SAVI devices when the only packets transmitted are:

S.3.3.2;
" The only messages the SEND SAVI device is required to generate for
      SEND SAVI operation are NUD_NSOL messages.  This also simplifies
      the state machine."

RFC 3971 relies not only upon the Cryptographically Generated Address (or other standalone signature) to validate the authorization of a router, but also Certificate Path Solicitation and Advertisement, which proves that a local routing authority has designated the device to be a router.

Reception of a RADV itself is not sufficient to prove the authorization, and SEND nodes have the potential to transmit an RA if misconfigured (or attacking).

Sincerely,

Greg Daley
Solutions Architect
Logicalis Australia Pty Ltd

m: +61 401 772 770
e: [email-masked]

www.au.logicalis.com

Level 6, 616 St Kilda Road 
Melbourne VIC 3004 Australia

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, 18 September 2012 12:12 AM
To: [email-masked]
Cc: [email-masked]
Subject: [savi] I-D Action: draft-ietf-savi-send-08.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Source Address Validation Improvements Working Group of the IETF.

	Title           : SEND-based Source-Address Validation Implementation
	Author(s)       : Marcelo Bagnulo
                          Alberto Garcia-Martinez
	Filename        : draft-ietf-savi-send-08.txt
	Pages           : 32
	Date            : 2012-09-17

Abstract:
   This memo describes SEND SAVI, a mechanism to provide source address
   validation using the SEND protocol.  The proposed mechanism is
   intended to complement ingress filtering techniques to provide a
   finer granularity on the control of the source addresses used.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-savi-send

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-savi-send-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-savi-send-08

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

---

From: Alberto García <[email-masked]>
Date: Tue, 18 Sep 2012 18:24:16 +0200

Hi Greg,
First of all, thanks for reading the draft.

|  -----Mensaje original-----
|  De: [email-masked] [mailto:[email-masked]] En nombre de
|  Greg Daley
|  Enviado el: martes, 18 de septiembre de 2012 6:35
|  Para: [email-masked]'
|  CC: [email-masked]; [email-masked]'
|  Asunto: [savi] SAVI SEND RADV validation (was RE: I-D Action: draft-ietf-
|  savi-send-08.txt)
|  
|  Hi Marcelo and Alberto,
|  
|  Thanks for your work on this.
|  
|  I am wondering how router validity can be ascertained by the SAVI devices
|  when the only packets transmitted are:
|  
|  
|  S.3.3.2;
|  " The only messages the SEND SAVI device is required to generate for
|        SEND SAVI operation are NUD_NSOL messages.  This also simplifies
|        the state machine."
|  
|  RFC 3971 relies not only upon the Cryptographically Generated Address (or
|  other standalone signature) to validate the authorization of a router,
but
|  also Certificate Path Solicitation and Advertisement, which proves that a
|  local routing authority has designated the device to be a router.
|  
|  Reception of a RADV itself is not sufficient to prove the authorization,
and
|  SEND nodes have the potential to transmit an RA if misconfigured (or
|  attacking).

I see your point, and I fully agree with it. In other places of the document
it is stated that CPS/CPAs are required to validate RADV messages:
In section '3.2.  SEND SAVI Device Configuration':
"[...]
   o the SEND SAVI device MUST be configured with at least one Trusted
      port to validate the Certification Paths that is used to validate
      router information.
   o  the SEND SAVI device MAY be configured with Certification Paths.
      The alternative is obtaining them by means of issuing
      Certification Path Solicitation messages, as detailed in the SEND
      specification [RFC3971]."

And in section 3.3.2
"  SEND SAVI devices MUST support the processing of validated CPA
   messages, sent in reply to CPS messages, to acquire certificates used
   to validate ND messages.  In order to process a CPA message received
   from a Validating port, an entry for the source address of the
   message MUST exist in the SEND SAVI Data Base.  CPA messages received
   from Trusted ports are always checked and processed."

Finally, we refer to 'validated RADV' all over the text, which of course
implies SEND validation depending on a Trust Anchor/Certification path.
So I think the draft does address the validation of RADV messages correctly.

This being said, I agree that the sentence you point out to can be more
precise. 
Do you think that the issue is fixed if we replace it with the following
text?:
"The only messages the SEND SAVI device is required to generate specifically
per each source IP  address, in order to determine the state of the port for
the considered address, are NUD_NSOL messages.  This also keeps the state
machine simple."

Regards, and thanks for your comment
Alberto

|  
|  Sincerely,
|  
|  Greg Daley
|  Solutions Architect
|  Logicalis Australia Pty Ltd
|  
|  m: +61 401 772 770
|  e: [email-masked]
|  
|  www.au.logicalis.com
|  
|  Level 6, 616 St Kilda Road
|  Melbourne VIC 3004 Australia
|  
|  
|  
|  
|  
|  -----Original Message-----
|  From: [email-masked] [mailto:[email-masked]] On Behalf Of
|  [email-masked]
|  Sent: Tuesday, 18 September 2012 12:12 AM
|  To: [email-masked]
|  Cc: [email-masked]
|  Subject: [savi] I-D Action: draft-ietf-savi-send-08.txt
|  
|  
|  A New Internet-Draft is available from the on-line Internet-Drafts
|  directories.
|   This draft is a work item of the Source Address Validation Improvements
|  Working Group of the IETF.
|  
|  	Title           : SEND-based Source-Address Validation
Implementation
|  	Author(s)       : Marcelo Bagnulo
|                            Alberto Garcia-Martinez
|  	Filename        : draft-ietf-savi-send-08.txt
|  	Pages           : 32
|  	Date            : 2012-09-17
|  
|  Abstract:
|     This memo describes SEND SAVI, a mechanism to provide source address
|     validation using the SEND protocol.  The proposed mechanism is
|     intended to complement ingress filtering techniques to provide a
|     finer granularity on the control of the source addresses used.
|  
|  
|  The IETF datatracker status page for this draft is:
|  https://datatracker.ietf.org/doc/draft-ietf-savi-send
|  
|  There's also a htmlized version available at:
|  http://tools.ietf.org/html/draft-ietf-savi-send-08
|  
|  A diff from the previous version is available at:
|  http://www.ietf.org/rfcdiff?url2=draft-ietf-savi-send-08
|  
|  
|  Internet-Drafts are also available by anonymous FTP at:
|  ftp://ftp.ietf.org/internet-drafts/
|  
|  _______________________________________________
|  savi mailing list
|  [email-masked]
|  https://www.ietf.org/mailman/listinfo/savi
|  _______________________________________________
|  savi mailing list
|  [email-masked]
|  https://www.ietf.org/mailman/listinfo/savi

---

From: Greg Daley <[email-masked]>
Date: Wed, 19 Sep 2012 02:58:06 +0000

Hi Alberto, 

Thanks for that.   I had missed the section on the trust paths in that pass. 

The clarifying statement is helpful.

Sincerely,

Greg 

-----Original Message-----
From: Alberto García [mailto:[email-masked]] 
Sent: Wednesday, 19 September 2012 2:24 AM
To: Greg Daley; [email-masked]
Cc: [email-masked]
Subject: RE: [savi] SAVI SEND RADV validation (was RE: I-D Action: draft-ietf-savi-send-08.txt)

Hi Greg,

|  -----Mensaje original-----
|  De: [email-masked] [mailto:[email-masked]] En nombre de  
| Greg Daley  Enviado el: martes, 18 de septiembre de 2012 6:35
|  Para: [email-masked]'
|  CC: [email-masked]; [email-masked]'
|  Asunto: [savi] SAVI SEND RADV validation (was RE: I-D Action: 
| draft-ietf-
|  savi-send-08.txt)
|  
|  Hi Marcelo and Alberto,
|  
|  Thanks for your work on this.
|  
|  I am wondering how router validity can be ascertained by the SAVI 
| devices  when the only packets transmitted are:
|  
|  
|  S.3.3.2;
|  " The only messages the SEND SAVI device is required to generate for
|        SEND SAVI operation are NUD_NSOL messages.  This also simplifies
|        the state machine."
|  
|  RFC 3971 relies not only upon the Cryptographically Generated Address 
| (or  other standalone signature) to validate the authorization of a 
| router,
but
|  also Certificate Path Solicitation and Advertisement, which proves 
| that a  local routing authority has designated the device to be a router.
|  
|  Reception of a RADV itself is not sufficient to prove the 
| authorization,
and
|  SEND nodes have the potential to transmit an RA if misconfigured (or  
| attacking).

I see your point, and I fully agree with it. In other places of the document it is stated that CPS/CPAs are required to validate RADV messages:

And in section 3.3.2

Finally, we refer to 'validated RADV' all over the text, which of course implies SEND validation depending on a Trust Anchor/Certification path.
So I think the draft does address the validation of RADV messages correctly.

This being said, I agree that the sentence you point out to can be more precise. 
Do you think that the issue is fixed if we replace it with the following
text?:
"The only messages the SEND SAVI device is required to generate specifically per each source IP  address, in order to determine the state of the port for the considered address, are NUD_NSOL messages.  This also keeps the state machine simple."

|  
|  Sincerely,
|  
|  Greg Daley
|  Solutions Architect
|  From: [email-masked] [mailto:[email-masked]] On Behalf 
| Of  [email-masked]
|   This draft is a work item of the Source Address Validation 
| Improvements  Working Group of the IETF.