Subject: RFC 2385 on IPv6

From: Jeroen Massar <[email-masked]>
Date: 16 Apr 2004 18:02:56 +0200

Hi,

With the current advent of sudden rise of MD5'd BGP requests due to
something not be undisclosed apparently I was looking at what routers
support this for IPv6 and apparently at least both Cisco and Juniper
can do this. 

But what draft/rfc/doc/... are they using?

In IPv6 we have this nice thing called extension headers.
If the RFC2385 scheme would be implemented on IPv6 I would
expect it to be a Destination Option.

In IPv4 it looks like:

no-md5: [ipv4 + tcp + data]
md5'ed: [ipv4 + tcp + md5hash + data]

Thus the 16 byte hash is stuck in the data part.
If a unsuspecting host gets this packet it expects
data in the portion where the hash now is in place.
For BGP this is not much of a problem, but it isn't
very applicable to other protocols.

In IPv6 we have the Destination Option where we could
stick the md5hash:

no-md5: [ipv6 + tcp + data]
md5'ed: [ipv6 + dstop-md5hash + tcp + data]

This would even allow one to configure a host to do:
 - when there has never been a md5hash, don't use it
 - if we've once seen a md5hash use it.

Allowing BGP sessions to be reconfigured on the fly
even out of sync of eachother as long as they use the
same passwords of course.

Is such a scheme documented somewhere, is this in use
or should we just play dirty and stick the md5hash in
front of the data section and let the host fight it out.

Greets,
 Jeroen

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 16 Apr 2004 20:53:40 +0200

> But what draft/rfc/doc/... are they using?

RFC2385. But you already knew that... The RFC doesn't mention IPv6, but 
nothing is specific to IPv4 so there shouldn't be any issues 
implementing it for IPv6. (Also note that there is nothing stopping 
anyone from exchanging IPv6 routing information over IPv4 transport.)

> expect it to be a Destination Option.

RFC2385 specifies a TCP option. I don't think it makes much sense to 
define a new option, as RFC2385 is already implemented and if something 
better is desired, why not simply use IPsec?

> data in the portion where the hash now is in place.

First of all, the hash is in the TCP header (I think you're confused by 
the description of the hash calculation), and second this mechanism 
must always be manually configured between two hosts so the 
"unsuspection host" scenario doesn't apply.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------