Subject: [karp] FW: Non IPSec Authentication mechanism for OSPFv3

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sat, 25 Sep 2010 06:05:11 +0530

Hi,
 
Currently OSPFv3 uses only IPSec for authentication. I have written a small draft that uses provides a different authentication mechanism - non IPSec based, for OSPFv3 as IPSec is generally considered inadequate for routing protocols. Would be great if folks can review and provide some feedback on this.
 
http://tools.ietf.org/html/draft-bhatia-karp-non-ipsec-ospfv3-auth-00

Cheers, Manav

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 24 Sep 2010 21:52:52 -0700

Hi Manav,

The idea is good. A few small points.

I think it would not be good to add a new next header value in IPv6
for OSPFv3 specific header. Forwarders not recognizing this could drop
the packet as malformed.

I think you should use
http://tools.ietf.org/html/draft-krishnan-ipv6-exthdr-08

It may be an RFC now, though I have not followed it along. I have
CC'ed Suresh Krishnan who has more idea of the same.

Thanks,
Vishwas

On Fri, Sep 24, 2010 at 5:35 PM, Bhatia, Manav (Manav)
<[email-masked]> wrote:
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
>

---

From: mark Brown <[email-masked]>
Date: Sat, 25 Sep 2010 16:21:14 +0530

I liked the idea explored in the draft and would like to see it really
progressed.

I dont think the problem that you are alluding to exists - extension
headers are by default only meant for the end nodes, so intermediate
routers should just skip them unless they're trying to deep inspect
the packet. In that case, when they come across an unrecognized
extension header, why cant they skip as many bytes as the header
length given in the extension header and resume the inspection? So,
the problem is not with the forwarders per se, but devices that want
to deep inspect the packets.

I see one potential problem with the solution though. End nodes that
dont support this extension header will reject these packets and send
out an ICMP error back to the source. Thus, its not backward
compatible. Also as a direct consequence, you (Manav this time) cannot
have a "transition mode" that you have described in the last paragraph
of Sec 4.5.

However one could argue, and i wouldnt disagree, that OSPFv3 is an
intra-domain protocol all under one administrative domain, so we could
work around this limitation of backward incompatibility.

Given that the original design of IPv6 extension headers itself is
flawed, i dont see how we can get past it without backward
compatibility issues.

Mark.

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sat, 25 Sep 2010 20:46:41 +0530

Hi Mark,
 
> I liked the idea explored in the draft and would like to see it really

Thanks!

> length given in the extension header and resume the inspection? So,

Vishwas is right. The intermediaries will not be able to process the packet as they will have no idea about where the unknown header ends and the next header begins. This is because there isnt any standard format for an IPv6 extension header. I have submitted a small companion draft (draft-bhatia-6man-update-ipv6-ext-hdr-00.txt) that attempts to fix this - it should be available in a day or two.

> have a "transition mode" that you have described in the last paragraph

This too gets addressed if we can fix up a standard format for an v6 extension header!

> flawed, i dont see how we can get past it without backward

Simple - we fix it! ;-)

Cheers, Manav

> >> Currently OSPFv3 uses only IPSec for authentication. I 
> have written a small draft that uses provides a different 
> authentication mechanism - non IPSec based, for OSPFv3 as 
> IPSec is generally considered inadequate for routing 
> protocols. Would be great if folks can review and provide 
> some feedback on this.
> >>
> >>

---

From: Sandra Murphy <[email-masked]>
Date: Sun, 26 Sep 2010 16:38:34 -0400 (Eastern Daylight Time)

Your introduction points to the impossibility of replay protection in 
IPsec managed SAs, and points to the vulnerabilities in ospf to replay 
attacks.  I was interested to see how you intended to handle replay in 
your alternative authentication mechanism.

I see that the packet format includes a sequence number, but I see no 
discussion on sending or receiving side of what one does for or with the 
sequence number.  I think that needs to be added.

I think there might be ticklish issues there, so this could be more than 
just a "incomplete text" comment.

--Sandy

---

From: Vishwas Manral <[email-masked]>
Date: Sun, 26 Sep 2010 14:08:13 -0700

Hi Manav,

Some more points to ponder.

1. As IP header has a payload length and OSPF has a packet length. You
can instrt the header just like in OSPF after the OSPFv3 packet within
the IP packet. You do not need a new header at all.

2. That said if you want to define a new header, what you need to take
care of is that we do not define a protocol specific header. We
instead state the limitations in IPsec and requirements generically in
OSPF and then try to make a generic authentication header (instead of
an OSPF specific Authentication header in IP. It is like each protocol
extension should try to use its own space rather than take IP type
space).

Thanks,
Vishwas

On Sun, Sep 26, 2010 at 1:38 PM, Sandra Murphy <[email-masked]> wrote:
> Your introduction points to the impossibility of replay protection in IPsec
> managed SAs, and points to the vulnerabilities in ospf to replay attacks.  I
> was interested to see how you intended to handle replay in your alternative
> authentication mechanism.
>
>> Currently OSPFv3 uses only IPSec for authentication. I have written a
>> small draft that uses provides a different authentication mechanism - non
>> IPSec based, for OSPFv3 as IPSec is generally considered inadequate for
>> routing protocols. Would be great if folks can review and provide some
>> feedback on this.
>>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Mon, 27 Sep 2010 05:18:04 +0530

Hi Vishwas,

> the IP packet. You do not need a new header at all.

I had thought of this, but this would have been too specific to OSPFv3. I am trying to address a generic protocol issue that uses Ipsec currently for integrity protection, and not specifically OSPF, which is precisely why I am calling the new header - "Generic Authentication Header". 

Section 5 also says the following:

5. Generic Authentication Mechanism
   
      The extension header described in this document can also be used
      by any other protocol that desires integrity protection. All it
      needs to do is to compute the digest over that protocol packet
      and carry it inside the Generic Authentication extension header
      as described in this document.

I took an example of OSPFv3 to illustrate how we could use this extension. I think this point (of this being a generic extension header) wasn't brought out well and I should pay some more emphasis on this.

> extension should try to use its own space rather than take IP type

Same as above.

Cheers, Manav

> have written a

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Mon, 27 Sep 2010 05:26:22 +0530

Hi Sandy,

> sequence number.  I think that needs to be added.

While I did add some text in Sec 4.4 on what the Sending side should do, I did not, as you noted, added equivalent text in Sec 4.5. Thanks for catching this! I'll fix this in the next revision.
> just a "incomplete text" comment.

Ok. Since the authentication scheme now falls back to what we are currently using in OSPFv2, it should, at least theoretically just work with whatever flaws exist in that scheme [described in detail in draft-ietf-opsec-routing-protocols-crypto-issues]. 

I'll add the text in the next revision and we'll see what issues come up.

Cheers, Manav

> > Currently OSPFv3 uses only IPSec for authentication. I have 
> written a small draft that uses provides a different

---

From: Sandra Murphy <[email-masked]>
Date: Sun, 26 Sep 2010 20:18:12 -0400 (Eastern Daylight Time)

In oppfv2, the crypto sequence number is kept in the "sending neighbor's 
data structure".  (Where a neighbor data structure is identified 
either by the neighbor's RouterID or its IP address).

THis protection isn't going to have a "sending neighbor" to work with - 
the sequence number will have to be related to the sending IP address.

You get to say if that would be equivalent as far as ospf would be 
concerned.  (I don't know what determines whether the neighbor data 
strcture is identified by RouterID.)

Or as far as other routing protocols would be concerned, if you are 
intending this to be generic.

--Sandy

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Mon, 27 Sep 2010 05:59:12 +0530

Hi Sandy,

> either by the neighbor's RouterID or its IP address).

It's the Router ID for both OSPFv2 and OSPFv3.

> strcture is identified by RouterID.)

We would recognize the neighbor based on the Router ID in OSPFv3 and its there that we will maintain the crypto sequence number. Should be just similar to OSPFv2.

> intending this to be generic.

Well, as long as other protocols can identify the source, they should have no issues in maintaining the crypto sequence number.

I believe I am getting the drift of what you're alluding to and will add some text about tying the sequence numbers to the sending router in next cut.

Cheers, Manav

> > While I did add some text in Sec 4.4 on what the Sending 
> side should do, I did not, as you noted, added equivalent 
> text in Sec 4.5. Thanks for catching this! I'll fix this in 
> the next revision.
> >>
> > Ok. Since the authentication scheme now falls back to what 
> we are currently using in OSPFv2, it should, at least 
> theoretically just work with whatever flaws exist in that 
> scheme [described in detail in 
> draft-ietf-opsec-routing-protocols-crypto-issues].
> >

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Mon, 27 Sep 2010 09:15:08 +0530

Hi Sandy and Vishwas,

I have quickly updated the draft based on your comments.

It can be viewed at http://www.ietf.org/staging/draft-bhatia-karp-non-ipsec-ospfv3-auth-01.txt till it gets announced in a day or two.

Would be great if you can review this and provide your feedback!

Cheers, Manav

> -----Original Message-----
> From: Sandra Murphy [mailto:[email-masked]] 
> Sent: Monday, September 27, 2010 5.48 AM
> To: Bhatia, Manav (Manav)
> Cc: [email-masked]
> Subject: RE: [karp] FW: Non IPSec Authentication mechanism for OSPFv3
>