Re: [v6ops] [EXTERNAL] Re: Improving ND security

["Templin (US), Fred L" <[e-mail]>]

Hi Fernando,

> -----Original Message-----
> From: Fernando Gont [mailto:[e-mail]]
> Sent: Monday, August 03, 2020 11:53 AM
> To: Templin (US), Fred L <[e-mail]>; Pascal Thubert (pthubert) <[e-mail]>
> Cc: v6ops list <[e-mail]>; 6man <[e-mail]>
> Subject: Re: [v6ops] [EXTERNAL] Re: Improving ND security
> 
> This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and
> know that the content is safe.
> Hi, Fred,
> 
> On 3/8/20 13:45, Templin (US), Fred L wrote:
> [....]
> >> This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and
> >> know that the content is safe.
> >> On 3/8/20 11:22, Templin (US), Fred L wrote:
> >>> Here’s another think about SEND. RFC3971 SEND says that it works in
> >>> conjunction with Cryptographically Generated addresses (CGA) per RFC3972. But, CGAs are
> >>> cumbersome to work with as the source and destination addresses of IPv6 packets,
> >>> and SEND hints that it can be used without CGA but does not tell how to do so.
> >>
> >> Of the top of my head, CGAs are a core part of send.
> >
> > That is fine; we can accommodate CGAs in OMNI, cumbersome as they are.
> > I have this on my TODO list for after the adoption call.
> 
> Why "cumbersome"?



I realize the addresses are cryptographically-generated, which implies a security property
which is good. But, they would not be the primary link-local addresses that neighbor
nodes will know each other by - the CGAs will be found in the IPv6 ND message source
and destination addresses, while the primary addresses will be carried in an additional
IPv6 encapsulation header and would be the addresses that the NCEs are indexed by.
So, all the CGAs really are is placeholders in the IPv6 header to run security checks over.
They need not even be checked for uniqueness on the link, because it is the primary
addresses and not the CGAs which need to be maintained as unique.



> >>> But then, RFC4380 offers a “poor-man’s” alternative to SEND/CGA. It
> >>> places a message authentication code in the encapsulation headers of IPv6 ND messages so
> >>> that the messages can pass a rudimentary authentication check.
> >>
> >> You mean the Teredo spec? If so, I don't think it includes any sort of
> >> poor-man's SEND-CGA.
> >
> > It provides for message authentication,
> 
> But what's special about SEND/CGAs is that they tie the address to a key...



OK, that sounds good. So, we like that property but AFAICT that is about all the
CGA is good for in my application.




> > and it is widely-deployed which suggests
> > to me that the vendors who support it believe it is secure.
> 
> I'm sure others probably know better, but... I think Teredo is mostly MS
> + Miredo. (when it comes to implementation)
> 
> And Re: deployment, IIRC Teredo has been phased out.
> 
> 
> 
> > So, if it is secure enough for RFC4380, then shouldn't it also be secure enough for OMNI?
> 
> I believe Auth in Teredo is a totally different thing from SEND/CGAs.
> 
> Regarding OMIN, I Haven read the draft/spec, yet...
 


The usage we have for OMNI is that of an Internet-based Client sending an
authenticated, encapsulated, unicast RS message to an Internet-based Server
which then must authenticate the message. (The "link" in this case is the
Internet itself.) The encapsulation format is based on RFC4380 encapsulation
but with a different UDP port number than specified for RFC4380. A second
level of encapsulation is also added per RFC2473. The CGA of the Client is
in the IPv6 ND source address, "All-Routers" is in the IPv6 ND destination
address, the OMNI ULA of the Client is in the RFC2473 source address, and
either the OMNI ULA of the Server or Subnet Router Anycast is in the
RFC2473 destination address. The outer UDP/IP header has the Internet
source address of the Client and the Internet destination address of the
Server. That is a lot of addresses to carry around in a single packet, but if
we must use CGAs then we do what we have to do.

In the reverse direction, the Server must also include its CGA as the source
of the RA message, the CGA of the Client as the destination address, and
with the RFC2473 header having the Server's OMNI ULA as the source and
the OMNI ULA of the Client as the destination. The UDP/IP header has the
Internet addresses as before. Again, lots of addresses to juggle around due
to the need to include CGAs. 



> >>> So someone with
> >>> security experience please help me out here – is RFC4380 authentication an acceptably
> >>> secure  replacement for SEND/CGA that might be easier to work with and less
> >>> cumbersome?
> >>
> >> Nope. Tee point of CGAs is that they allow you to prove address
> >> ownership. There's nothing in RFC4380 that provides the same or similar
> >> functionality.
> >
> > Why do we have to prove address ownership
> 
> Well, that's one of the goals of SEND/CGAs. :-)
> 
> 
> > and use a whacky address format like CGA?
> 
> The *address format* is not really whacky. At the end of the day, it's a
> random number, with the specific property that it's part of the hash of
> a public key.
> 
> looking at a CGA, you probably wouldn't be able to tell CGA from RFC7217.




I think if you look inside the IPv6 ND message and find a CG option you can
infer that the address in the IPv6 header is a CGA.



> > There is nothing in the OMNI spec that needs or wants CGAs in any fashion
> > unless they are absolutely required for security. Isn't it enough to prove message
> > authentication using the mechanisms of RFC4380 without having to accommodate
> > the excess baggage of CGAs??
> 
> Both are different things.
> 
> One thing is to authenticate the contents of a message. And a different
> one is to be able to tell that one specific host is "authorized" to use
> one specific address...



The only reason I am hesitant is that it just seems that the usage of CGAs
envisioned for OMNI is just as a cryptographically-generated "bag of bits".
They are not used as indexes into the neighbor cache. They are not
examined by routers, bridges or switches, etc. They are simply payload
bits carried in a special place known as the IPv6 source and destination
address. Is that good enough?

Thanks - Fred




> --
> Fernando Gont
> e-mail: [e-mail] || [e-mail]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
>