Skip to main content

BGP IPsec Tunnel Encapsulation Attribute
draft-ietf-softwire-encaps-ipsec-03

Revision differences

Document history

Date Rev. By Action
2012-08-22
03 (System) post-migration administrative database adjustment to the No Objection position for Pasi Eronen
2012-08-22
03 (System) post-migration administrative database adjustment to the No Objection position for Jari Arkko
2012-08-22
03 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2009-05-01
03 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2009-04-30
03 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2009-04-30
03 (System) IANA Action state changed to In Progress from Waiting on Authors
2009-04-30
03 (System) IANA Action state changed to Waiting on Authors from In Progress
2009-04-29
03 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2009-04-28
03 (System) IANA Action state changed to In Progress
2009-04-28
03 Cindy Morgan IESG state changed to Approved-announcement sent
2009-04-28
03 Cindy Morgan IESG has approved the document
2009-04-28
03 Cindy Morgan Closed "Approve" ballot
2009-04-28
03 Ralph Droms [Ballot Position Update] New position, Yes, has been recorded by Ralph Droms
2009-04-28
03 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk
2009-04-28
03 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk
2009-04-13
03 Pasi Eronen [Ballot Position Update] Position for Pasi Eronen has been changed to No Objection from Discuss by Pasi Eronen
2009-04-07
03 Ralph Droms Responsible AD has been changed to Ralph Droms from Mark Townsley
2009-04-06
03 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-04-06
03 (System) New version available: draft-ietf-softwire-encaps-ipsec-03.txt
2009-03-24
03 Mark Townsley State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Mark Townsley
2009-03-24
03 Mark Townsley [Note]: 'Awaiting proposal from Pasi to address remaining security issue (see email thread in comment).' added by Mark Townsley
2009-03-24
03 Mark Townsley
That is in fact the problem .. the standard IPsec mechanisms are via a PKI. We need a solution that doesn't require PKI deployment.

-DWard …
That is in fact the problem .. the standard IPsec mechanisms are via a PKI. We need a solution that doesn't require PKI deployment.

-DWard

On Mar 24, 2009, at 2:45 PM, Lou Berger wrote:

> Via standard ipsec mechanisms...
> -----Original Message-----
> From:  David Ward
>
> Date: Tue, 24 Mar 2009 12:27:15
> To: Lou Berger
> Cc: David Ward; ; Pasi Eronen; Mark Townsley; Alain Durand; Russ White; Ross Callon; Jari Arkko; Ralph Droms
> Subject: Re: [Fwd: Re: DISCUSS: draft-ietf-softwire-encaps-ipsec]
>
>
> I'll let Pasi explain in greater detail but, right now we have this
> situation:
>
> Peers X and Y
>
> - X requests an IPsec tunnel to Y
>
> - Y sends back some info so that X can verify
>
> - Everything goes or fails
>
> How did Y verify X's request initially?
>
> -DWard
>
> On Mar 24, 2009, at 12:17 PM, Lou Berger wrote:
>
>>
>> Dave,
>>    So the proposal is to replace the current " IPsec Tunnel
>> Authenticator" mechanism that can be used to validate the BGP next
>> hop with a new "fingerprint" mechanism.  Is this correct?
>>
>> Sure we can do this (assuming someone - Pasi? -  will write the
>> text) but I really don't understand what value is being added.  I'm
>> no security expert, so someone may have to explain what I'm missing.
>>
>> In the current scheme, we/softwires is providing *incremental*
>> information to all an softwires tunnel initiator to validate the the
>> remote endpoint is the softwires BGP node that advertised the next
>> hop and associated forwarding information.  In short, that the next
>> hop hasn't spoofed "softwires" information.
>>
>> As I understand it, in the above case existing standard IPsec
>> mechanisms provide the authentication mechanisms to ensure that "no
>> peer can randomly bring up a tunnel."  This is most certainly a
>> benefit, i.e., "... the benefits for L3VPN to avoid "other" peers
>> from joining a VPN as well."  So when we look at the two mechanisms
>> in combination (a) ipsec ensures that the tunnel is only
>> established / the VPN is only joined by authorized parties and (b)
>> softwires ensures that no authorized party masquerades as a
>> different authorized party / BGP next hop.
>>
>> I understand that utility of the above, but the operators/users I
>> talked to about this think that (a) is sufficient and won't use (b).
>>
>> Simply don't understand what value adding (c) "a softwires mechanism
>> for a softwires endpoint to validate an incoming tunnel against the
>> BGP membership" provides.  The folks I know who care about this
>> document will certainly never deploy this as the don't even what (b).
>>
>> I really think we're yet again defining a security mechanisms for
>> its own sake that will never be used.  I welcome hearing how I'm
>> mistaken. That said, if making this change allows the document to
>> progress, by all means, let's do it!
>>
>> Lou
>>
>>
>> On 3/24/2009 7:50 AM, David Ward wrote:
>>> All -
>>>
>>> Pasi and I chatted this morning and if we are to reuse the technology
>>> for L3VPN it would be best to have some requirements as Eric says:
>>>
>>> "Therefore the only possible security requirements that softwires
>>> can have
>>> are requirements having to do with the integrity of the encapsulation
>>> header, and with the authentication of the tunnel endpoints."
>>>
>>> On the auth of the endpoints, Pasi thinks that if we pass the
>>> fingerprints in a new BGP SAFI we are good to go. No PKI is necessary
>>> and public key crypto is available. This seems akin to other endpoint
>>> discovery mechanisms (e.g. L1VPN) and seems rather trivial to encode.
>>> The SAFI contains a list of fingerprints of possible endpoints and
>>> thus,
>>> no peer can randomly bring up a tunnel. Clearly you can see the
>>> benefits
>>> for L3VPN to avoid "other" peers from joining a VPN as well.
>>>
>>> Thoughts? Can we use this notion of passing a fingerprint list?
>>>
>>>
>>>
>>> -DWard
>>>
>>>
>>>
>>> On Mar 16, 2009, at 2:34 PM, Eric Rosen wrote:
>>>
>>>>
>>>>> for the "how does R2 authenticate R1" part, I'm waiting for a reply
>>>>> to my 2009-02-23 email.
>>>>
>>>> Let me review the security requirements, provide some historical
>>>> context,
>>>> and explain how we arrived at a scheme in which R2 doesn't
>>>> authenticate R1.
>>>>
>>>> The purpose of softwires is to take IPv4 traffic that is already
>>>> traveling
>>>> on the Internet, and to tunnel it across parts of the Internet
>>>> that only
>>>> support IPv6. Or to take IPv6 traffic that is already traveling on
>>>> the
>>>> Internet, and to tunnel it across parts of the Internet that only
>>>> support
>>>> IPv4.
>>>>
>>>> If the traffic itself has any confidentiality, integrity, or
>>>> authentication
>>>> requirements, then it had those requirements before it entered the
>>>> tunnel
>>>> and it will continue to have those requirements after it leaves the
>>>> tunnel.
>>>>
>>>> Therefore the only possible security requirements that softwires
>>>> can have
>>>> are requirements having to do with the integrity of the
>>>> encapsulation
>>>> header, and with the authentication of the tunnel endpoints.
>>>>
>>>> Any kind of Security Association, even one between unauthenticated
>>>> endpoints, can ensure integrity of the encapsulation header. So
>>>> the only
>>>> difficult problem is the authentication of the tunnel endpoints.
>>>>
>>>> This leads to some pragmatic difficulties.
>>>>
>>>> In some prior documents on tunneling (e.g., RFC 4023), when the
>>>> Security AD
>>>> made me put in something about IPsec, I made manual keying a MUST
>>>> IMPLEMENT,
>>>> and automated keying a mere OPTION. That way, the required security
>>>> mechanism is one that could at least be deployed, and there is no
>>>> requirement for an ISP to deploy a PKI. After all, no ISP is going
>>>> to
>>>> deploy an entire automated keying infrastructure just to
>>>> authenticate
>>>> tunnel
>>>> endpoints, so it hardly makes sense to require support for that.
>>>> (It's
>>>> also
>>>> true that no vendor will provide IPsec support, even with manual
>>>> keying,
>>>> merely because some RFC requires it, but requiring a PKI goes even
>>>> more into
>>>> the realm of science fiction.)
>>>>
>>>> Unfortunately, some of the past Security ADs took note of the fact
>>>> that it
>>>> doesn't make much sense, and is certainly not scalable, to use
>>>> manual
>>>> keying
>>>> in an environment where the tunnel endpoints are auto-discovered
>>>> through
>>>> BGP. I agree with this. So if one isn't going to use manual keying
>>>> and
>>>> one
>>>> isn't going to deploy a PKI infrastructure, the obvious inference
>>>> is that
>>>> IPsec is useless in an environment where we have automated
>>>> procedures,
>>>> based
>>>> on routing, for setting up router-to-router tunnels.
>>>>
>>>> When I presented this conclusion to the WG, Mark Townsley flew
>>>> into a
>>>> panic
>>>> and got Sam Hartman involved. Sam took this as a challenge, and
>>>> thought
>>>> that maybe we could come up with something that is better than
>>>> nothing. He
>>>> suggested that if a BGP update is being used to assign a particular
>>>> address
>>>> prefix to a secure tunnel, then the BGP update could carry the
>>>> hash of a
>>>> self-signed certificate belonging to the originator of the update.
>>>> This
>>>> developed into the scheme that is specified in the softwires drafts.
>>>>
>>>> First, here is a one paragraph of the entire softwires framework:
>>>>
>>>> Suppose that R1, R2, R3, and R4 are all border routers of some
>>>> Autonomous System. Suppose that R2 knows how to reach a
>>>> particular address A by sending any packet with A in its IP
>>>> destination address field to some other AS. Suppose that R1, R3,
>>>> and R4, when they get packets destined for A, need to tunnel those
>>>> packets to R2, so that R2 can send them on to the next AS. Then
>>>> R2 originates a BGP update specifying the address A (or some
>>>> "prefix" which is an initial sequence of the bits in A), and
>>>> specifying the sort of tunnel which any other border router of the
>>>> same AS should use in order to send the packets to R2. Let's call
>>>> this update "U".
>>>>
>>>> What sort of authentication does it make sense to have in this
>>>> scheme?
>>>>
>>>> In IP routing, one doesn't ever care where a packet came from, only
>>>> where it
>>>> is going. If R1, R3, and R4 learned, from BGP update U, that they
>>>> need to
>>>> tunnel certain traffic to R2, it makes sense to assure R1, R3, and
>>>> R4
>>>> that
>>>> the tunnel they are using really does terminate at the router (R2)
>>>> that
>>>> originated BGP update U. At least, that assures R1, R3, and R4
>>>> that they
>>>> are sending the data to the right place. The procedures in the draft
>>>> cover
>>>> this.
>>>>
>>>> When traffic emerges from a tunnel at R2, R2 doesn't really care
>>>> where
>>>> the
>>>> traffic came from; the most it cares about is that the head end of
>>>> the
>>>> tunnel is one of the routers that received the BGP Update U.
>>>>
>>>> However, since a BGP update does not necessarily pass unchanged as
>>>> it
>>>> goes
>>>> from one BGP speaker to another, it is difficult to see how to use
>>>> the
>>>> BGP-based softwires mechanism as part of a mutual authentication
>>>> scheme.
>>>>
>>>> That said, if you think the scheme is of no value unless the
>>>> tunnel tail
>>>> (R2) can authenticate the tunnel heads (e.g., R1), we could devise a
>>>> way for
>>>> R1 to pass its own public key hash in a BGP update. R2 could
>>>> originate an
>>>> update containing its own IP address and attach the hash to that.
>>>>
>>>> The problem with this is that when the plethora of security experts
>>>> starts
>>>> to review this, they will find additional issues and we'll end up
>>>> delaying
>>>> another year. This is a lot of delay for something that really
>>>> doesn't
>>>> make
>>>> much difference and that nobody really wants anyway.
>>>>
>>>> On another topic, the issue of why we specified the particular
>>>> hash we
>>>> did,
>>>> this is based on a recommendation from Tero Kivenen in December,
>>>> 2007. I
>>>> originally wrote just that the hash should be a non-reversible
>>>> hash of
>>>> the
>>>> of a certificate, and asked if there were a standard method for
>>>> producing
>>>> it. The reply:
>>>>
>>>> There is multiple ways to generate the hash. RFC4306 uses 2
>>>> method, FOR70 the Hash and URL encodings it uses SHA-1 hash of the
>>>> full certificate (this allows detecting whether you have exactly
>>>> correct certificate with same validity periods etc as other end).
>>>> For the certificate request payloads it uses the SHA-1 hash of the
>>>> public keys of the CA (this hash stays same even if the
>>>> certificate is re-enrolled with different validity periods but
>>>> still has same public key).
>>>>
>>>> I think you want to use the second one, as you do not really care
>>>> if the certificate is same you care if the public key is same. It
>>>> also stays same regardless if the host later changes self-signed
>>>> certificate to certificate which is signed by organization wide
>>>> key etc.
>>>>
>>>> You commented:
>>>>
>>>> If the IKE exchange will always use certificates (possibly
>>>> self-signed), I'd suggest using normal SHA-1 certificate
>>>> fingerprints (what e.g. web browsers and other management
>>>> systems currently display -- hash over entire certificate)
>>>> instead of the RFC 4306 approach (hash over SubjectPublicKeyInfo
>>>> structure only).
>>>>
>>>> I don't have enough security expertise to make an informed choice
>>>> between
>>>> these two procedures.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>
>
2009-03-24
03 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko
2009-03-23
03 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-03-23
02 (System) New version available: draft-ietf-softwire-encaps-ipsec-02.txt
2009-02-06
03 Mark Townsley State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Mark Townsley
2009-01-29
03 Cindy Morgan State Changes to IESG Evaluation::AD Followup from Waiting for AD Go-Ahead by Cindy Morgan
2009-01-29
03 (System) [Ballot Position Update] New position, No Objection, has been recorded for Dan Romascanu by IESG Secretary
2009-01-29
03 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2009-01-29
03 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2009-01-29
03 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2009-01-29
03 Jari Arkko
[Ballot discuss]
The abstract says:

  Currently support for GRE and L2TPv3
  tunnel types are defined.  This document defines support for IPsec
  tunnel …
[Ballot discuss]
The abstract says:

  Currently support for GRE and L2TPv3
  tunnel types are defined.  This document defines support for IPsec
  tunnel types.

The newest version of the SAFI document actually defines IP in IP, too.

The document says:

  Let R1 and R2 be two BGP speakers that may send data packets through
  R3, such that the data packets from R1 and from R2 may be received by
  R3 over the same interface.  Then if R3 has sent an update containing
  an Encapsulation SAFI, and if this update specifies an IPsec tunnel
  type, and if this update is received by R2, and an Encapsulation-SAFI
  with an IPsec tunnel type, SHOULD also be received by R1. 

Where is the SHOULD referring to? Is this a statement that if one
router receives a message it is also expected to be received by
another one? But BGP works in a p2p manner, so I don't see how this
is guaranteed. Or is this a statement that one of the routers
need to do something special, such as send Encapsulation AVPs?
If so, maybe the "SHOULD be received" needs to be rewritten
somehow.

But maybe I'm missing something here.

The document says:

  IPsec does not necessarily
  need to be required for control packets that are directly addressed
  to R3.

If BGP is used to negotiate that IPsec is needed on a particular
tunnel interface, it seems that it is impossible for that instance
of IPsec protection to protect BGP. Chicken and egg problem. Of course,
you could configure IPsec separately to protect BGP. My experience
is that if you do not tell the reader how the IPsec policies are
setup, the chances are that its not possible to set them up :-)
2009-01-29
03 Jari Arkko
[Ballot discuss]
The abstract says:

  Currently support for GRE and L2TPv3
  tunnel types are defined.  This document defines support for IPsec
  tunnel …
[Ballot discuss]
The abstract says:

  Currently support for GRE and L2TPv3
  tunnel types are defined.  This document defines support for IPsec
  tunnel types.

The newest version of the SAFI document actually defines IP in IP, too.

The document says:

  Let R1 and R2 be two BGP speakers that may send data packets through
  R3, such that the data packets from R1 and from R2 may be received by
  R3 over the same interface.  Then if R3 has sent an update containing
  an Encapsulation SAFI, and if this update specifies an IPsec tunnel
  type, and if this update is received by R2, and an Encapsulation-SAFI
  with an IPsec tunnel type, SHOULD also be received by R1. 

Where is the SHOULD referring to? Is this a statement that if one
router receives a message it is also expected to be received by
another one? But BGP works in a p2p manner, so I don't see how this
is guaranteed. Or is this a statement that one of the routers
need to do something special, such as send Encapsulation AVPs?
If so, maybe the "SHOULD be received" needs to be rewritten
somehow.

But maybe I'm missing something here.

The document says:

  IPsec does not necessarily
  need to be required for control packets that are directly addressed
  to R3.

If BGP is used to negotiate that IPsec is needed on a particular
tunnel interface, it seems that it is impossible for that instance
of IPsec protection to protect BGP. Chicken and egg problem. Of,
you could configure IPsec separately to protect BGP. My experience
is that if you do not tell the reader how the IPsec policies are
setup, the chances are that its not possible to set them up :-)
2009-01-29
03 Jari Arkko
[Ballot discuss]
The abstract says:

  Currently support for GRE and L2TPv3
  tunnel types are defined.  This document defines support for IPsec
  tunnel …
[Ballot discuss]
The abstract says:

  Currently support for GRE and L2TPv3
  tunnel types are defined.  This document defines support for IPsec
  tunnel types.

The newest version of the SAFI document actually defines IP in IP, too.

The document says:

  Let R1 and R2 be two BGP speakers that may send data packets through
  R3, such that the data packets from R1 and from R2 may be received by
  R3 over the same interface.  Then if R3 has sent an update containing
  an Encapsulation SAFI, and if this update specifies an IPsec tunnel
  type, and if this update is received by R2, and an Encapsulation-SAFI
  with an IPsec tunnel type, SHOULD also be received by R1. 

Where is the SHOULD referring to? Is this a statement that if one
router receives a message it is also expected to be received by
another one? But BGP works in a p2p manner, so I don't see how this
is guaranteed. Or is this a statement that one of the routers
need to do something special, such as send Encapsulation AVPs?
If so, maybe the "SHOULD be received" needs to be rewritten
somehow.

But maybe I'm missing something here.

The document says:

  IPsec does not necessarily
  need to be required for control packets that are directly addressed
  to R3.

If BGP is used to negotiate that IPsec is needed on a particular
tunnel interface, it seems that it is impossible for that instance
of IPsec protection to protect BGP. Chicken and egg problem. Of,
you could configure IPsec separately to protect BGP.
2009-01-29
03 Jari Arkko
[Ballot discuss]
The abstract says:

  Currently support for GRE and L2TPv3
  tunnel types are defined.  This document defines support for IPsec
  tunnel …
[Ballot discuss]
The abstract says:

  Currently support for GRE and L2TPv3
  tunnel types are defined.  This document defines support for IPsec
  tunnel types.

The newest version of the SAFI document actually defines IP in IP, too.
2009-01-29
03 Jari Arkko
[Ballot discuss]
The abstract says:

  Currently support for GRE and L2TPv3
  tunnel types are defined.  This document defines support for IPsec
  tunnel …
[Ballot discuss]
The abstract says:

  Currently support for GRE and L2TPv3
  tunnel types are defined.  This document defines support for IPsec
  tunnel types.

The newest version of the SAFI document actually defines IP in IP, too.

This document says:

  This document builds on [ENCAPS-SAFI] and defines
  support for IPsec tunnels.  Support is defined for IP Authentication
  Header in Tunnel-mode (AH), [RFC4302], and for IP Encapsulating
  Security Payload in Tunnel-mode (ESP), [RFC4303].  Support for IP-in-
  IP, [RFC2003], and MPLS-in-IP, [RFC4023] protected by IPsec Transport
  Mode is also defined.

But the -safi document says:

  This document defines the following types:

    - L2TPv3 over IP [RFC3931]: Tunnel Type = 1

    - GRE [RFC2784]: Tunnel Type = 2

    - IP in IP [RFC2003] [RFC4213]: Tunnel Type = 7

Which document defines IP in IP? There are two competing claims...
2009-01-29
03 Jari Arkko
[Ballot discuss]
Minor but annoying bug:

  Currently support for GRE and L2TPv3
  tunnel types are defined.  This document defines support for IPsec
  …
[Ballot discuss]
Minor but annoying bug:

  Currently support for GRE and L2TPv3
  tunnel types are defined.  This document defines support for IPsec
  tunnel types.

The newest version of the SAFI document actually defines IP in IP, too.
2009-01-29
03 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko
2009-01-29
03 Pasi Eronen
[Ballot discuss]
I have reviewed draft-ietf-softwire-encaps-ipsec-01. Overall, the
document looks good, but I have the following concerns that I'd like
to discuss before recommending approval …
[Ballot discuss]
I have reviewed draft-ietf-softwire-encaps-ipsec-01. Overall, the
document looks good, but I have the following concerns that I'd like
to discuss before recommending approval of the document:

- The document describes how the tunnel initiator (R1 in Section 3)
authenticates R2 (using the hash from the sub-TLV), but says nothing
about how R2 authenticates R1.

- The tunnel type values (3..6) identify some aspects of the IPsec SA
that will be used to protect the traffic, but not how the IPsec SA is
actually created.  Probably IKEv2 is meant, but we have (at least)
three other IPsec key management protocols as RFCs (IKEv1, KINK, and
Photuris). If it's not always IKEv2, the protocol to be used probably
should be given in some sub-TLV.

- The draft needs some text describing the SPD and PAD entries needed
for IKEv2 negotiation to succeed. I think this should be relatively
straightforward (once authenticating R1 is solved somehow).

Smaller comments:

- If the IKE exchange will always use certificates (possibly
self-signed), I'd suggest using normal SHA-1 certificate fingerprints
(what e.g. web browsers and other management systems currently display
-- hash over entire certificate) instead of the RFC 4306 approach
(hash over SubjectPublicKeyInfo structure only).

On the other hand, IKEv2 also has a "Raw RSA Key" type (although no
corresponding "Raw DSA Key" or "Raw ECDSA Key" types), which could be
used without generating self-signed certificates. But perhaps the
ability to use other algorithms than RSA makes certificates attractive
here.

- Values 5 (IP-in-IP with IPsec transport mode) and (MPLS-in-IP with
IPsec transport mode) don't identify which IPsec protocol (ESP or AH)
is to be used.  This is probably OK, as AH vs. ESP can be negotiated
by IKE -- but then we don't need two separate values 3 and 4 either.

- The text probably should allow more than one IPsec Tunnel
Authenticator sub-TLV in one attribute -- otherwise, it will be
difficult to ever change the key or certificate (or introduce new
Authenticator Types) without disrupting traffic. In this case, if
the certificate (or key) presented in IKE matches one of the sub-TLVs,
that would be considered successful.

- It seems RFC 4306 (and other key management protocols, if they're
supported) should be a normative reference.
2009-01-29
03 Pasi Eronen [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen
2009-01-29
03 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2009-01-28
03 Chris Newman
[Ballot comment]
It would be helpful to name both the registry "BGP" and the sub-registry
"Tunnel Encapsulation Attribute Tunnel Types" or "Tunnel Encapsulation Attribute Sub-TLVs" …
[Ballot comment]
It would be helpful to name both the registry "BGP" and the sub-registry
"Tunnel Encapsulation Attribute Tunnel Types" or "Tunnel Encapsulation Attribute Sub-TLVs" to help readers find the relevant IANA registries.
2009-01-28
03 Chris Newman [Ballot Position Update] Position for Chris Newman has been changed to No Objection from Discuss by Chris Newman
2009-01-28
03 Chris Newman [Ballot Position Update] New position, Discuss, has been recorded by Chris Newman
2009-01-28
03 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2009-01-28
03 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2009-01-28
03 Tim Polk
[Ballot discuss]
Julien Laganier's secdir review (16 December, 2008) has not recieved a response.
I have appended the body of the review to this discuss …
[Ballot discuss]
Julien Laganier's secdir review (16 December, 2008) has not recieved a response.
I have appended the body of the review to this discuss for expediency.  I support
his suggestion to add text about the tunnel types in the security considerations.  I
also found the highlighted text in section 3 confusing.

--- excerpt from secdir review -----

In section 2. "IPsec Tunnel Encapsulation Types"
------------------------------------------------

"
  Per [ENCAPS-SAFI], tunnel type is indicated in the Tunnel
  Encapsulation attribute. This document defines the following tunnel
  type values:

    - AH in Tunnel-mode: Tunnel Type = 3 [RFC4302]

    - ESP in Tunnel-mode: Tunnel Type = 4 [RFC4303]

    - IP-in-IP Tunnel with IPsec Transport Mode: Tunnel Type = 5
      [RFC4023]
"

I made the same comment for the softwire framework draft but I'm
repeating it here for completeness: The use of IPsec transport mode to
protect tunnels is diminished significantly compared to the protection
afforded by IPsec tunnel mode and thus it would be good to point that
out in the Security Considerations section of this document. For
example RFC 4301 includes the following paragraph:

"
                                                    [...] The access
  control functions that are an important part of IPsec are
  significantly limited in this context, as they cannot be applied to
  the end-to-end headers of the packets that traverse a transport mode
  SA used in this fashion.  Thus, this way of using transport mode
  should be evaluated carefully before being employed in a specific
  context.
"

In section 3 "Use of IPsec"
---------------------------

"
  If a R1 is a BGP speaker that receives an Encapsulation SAFI update
  from another BGP speaker, R2, then if R1 has any data packets for
  which R2 is the BGP next hop, R1 MUST initiate an IPsec SA of the
  specified "tunnel type", and all such data packets MUST be sent
  through that SA.

  Let R1 and R2 be two BGP speakers that may send data packets through
  R3, such that the data packets from R1 and from R2 may be received by
  R3 over the same interface.  Then if R3 has sent an update containing
  an Encapsulation SAFI, and if this update specifies an IPsec tunnel
  type, and if this update is received by R2, and an Encapsulation-SAFI
  with an IPsec tunnel type, SHOULD also be received by R1. [..]
"

Maybe this is just me but I have read the last sentence above 5 or 6
times and I have trouble to parse it. It seems to be some comas should
disappear. Would this rewording be appropriate:

"If R3 has sent an update containing an Encapsulation SAFI that
specifies an IPsec tunnel type to R2, then an update containing an
Encapsulation SAFI that specifies an IPsec tunnel SHOULD also be
received by R1" ?
2009-01-28
03 Tim Polk
[Ballot discuss]
Julien Laganier's secdir review (16 December, 2008) has not recieved a response.
I have appended the body of the review to this discuss …
[Ballot discuss]
Julien Laganier's secdir review (16 December, 2008) has not recieved a response.
I have appended the body of the review to this discuss for expediency.  I support
his suggestion to add text about the tunnel types in the security considerations.  I
also found the highlighted text in section 3 confusing.

In section 2. "IPsec Tunnel Encapsulation Types"
------------------------------------------------

"
  Per [ENCAPS-SAFI], tunnel type is indicated in the Tunnel
  Encapsulation attribute. This document defines the following tunnel
  type values:

    - AH in Tunnel-mode: Tunnel Type = 3 [RFC4302]

    - ESP in Tunnel-mode: Tunnel Type = 4 [RFC4303]

    - IP-in-IP Tunnel with IPsec Transport Mode: Tunnel Type = 5
      [RFC4023]
"

I made the same comment for the softwire framework draft but I'm
repeating it here for completeness: The use of IPsec transport mode to
protect tunnels is diminished significantly compared to the protection
afforded by IPsec tunnel mode and thus it would be good to point that
out in the Security Considerations section of this document. For
example RFC 4301 includes the following paragraph:

"
                                                    [...] The access
  control functions that are an important part of IPsec are
  significantly limited in this context, as they cannot be applied to
  the end-to-end headers of the packets that traverse a transport mode
  SA used in this fashion.  Thus, this way of using transport mode
  should be evaluated carefully before being employed in a specific
  context.
"

In section 3 "Use of IPsec"
---------------------------

"
  If a R1 is a BGP speaker that receives an Encapsulation SAFI update
  from another BGP speaker, R2, then if R1 has any data packets for
  which R2 is the BGP next hop, R1 MUST initiate an IPsec SA of the
  specified "tunnel type", and all such data packets MUST be sent
  through that SA.

  Let R1 and R2 be two BGP speakers that may send data packets through
  R3, such that the data packets from R1 and from R2 may be received by
  R3 over the same interface.  Then if R3 has sent an update containing
  an Encapsulation SAFI, and if this update specifies an IPsec tunnel
  type, and if this update is received by R2, and an Encapsulation-SAFI
  with an IPsec tunnel type, SHOULD also be received by R1. [..]
"

Maybe this is just me but I have read the last sentence above 5 or 6
times and I have trouble to parse it. It seems to be some comas should
disappear. Would this rewording be appropriate:

"If R3 has sent an update containing an Encapsulation SAFI that
specifies an IPsec tunnel type to R2, then an update containing an
Encapsulation SAFI that specifies an IPsec tunnel SHOULD also be
received by R1" ?
2009-01-28
03 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk
2009-01-28
03 Lars Eggert
[Ballot comment]
Section 2., paragraph 4:
>      - IP-in-IP Tunnel with IPsec Transport Mode: Tunnel Type = 5
>        [ …
[Ballot comment]
Section 2., paragraph 4:
>      - IP-in-IP Tunnel with IPsec Transport Mode: Tunnel Type = 5
>        [RFC4023]

  I think this reference should be to RFC2003 (or at least not to
  RFC4023, because that doesn't talk about IP-in-IP at all.)
2009-01-28
03 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2009-01-27
03 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2009-01-27
03 David Ward [Ballot Position Update] New position, Recuse, has been recorded by David Ward
2009-01-15
03 Samuel Weiler Request for Telechat review by SECDIR is assigned to Julien Laganier
2009-01-15
03 Samuel Weiler Request for Telechat review by SECDIR is assigned to Julien Laganier
2009-01-12
03 Mark Townsley Telechat date was changed to 2009-01-29 from 2009-02-12 by Mark Townsley
2009-01-12
03 Mark Townsley Telechat date was changed to 2009-02-12 from 2009-01-29 by Mark Townsley
2009-01-12
03 Mark Townsley Placed on agenda for telechat - 2009-01-29 by Mark Townsley
2008-12-18
03 Samuel Weiler Request for Early review by SECDIR Completed. Reviewer: Julien Laganier.
2008-12-15
03 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2008-12-11
03 Amanda Baber
IANA Last Call questions/comments:

- The SubTLV registry created by draft-ietf-softwire-encaps-safi-03.txt
does not have a "Tunnel Type" column, but the assignment in this
document seems …
IANA Last Call questions/comments:

- The SubTLV registry created by draft-ietf-softwire-encaps-safi-03.txt
does not have a "Tunnel Type" column, but the assignment in this
document seems to imply it does. Either this document is incorrect
in its requested assignment, the other document needs to be corrected
to add the column, or this document needs to request a modificiation
to the registry. Which do you prefer?

- In Section 4 you refer to the Authenticator Type in the SubTLV
and define authenticator type 1. Do you want to create a registry
of Authenticator Types?


Action 1:

Upon approval of this document, the IANA will make the following assignments
in the "Border Gateway Protocol (BGP) Parameters" registry located at
http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml
sub-registry "Tunnel TLVs"

Type Tunnel Name Reference
---- --------------- ---------
3 AH [RFC-softwire-encaps-ipsec-01]
4 ESP [RFC-softwire-encaps-ipsec-01]
5 IP-in-IP tunnel with IPsec Transport Mode [RFC-softwire-encaps-ipsec-01]
6 MPLS-in-IP with IPsec Transport Mode [RFC-softwire-encaps-ipsec-01]


Action 2:

Upon approval of this document, the IANA will make the following assignments
in the "Border Gateway Protocol (BGP) Parameters" registry located at
http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml
sub-registry "Tunnel Sub-TLVs"

SubType Sub-TLV name Reference
------- ------------- ---------
3 IPsec Tunnel Authenticator [RFC-softwire-encaps-ipsec-01]


We understand the above to be the only IANA Actions for this document.
2008-12-01
03 Amy Vezza Last call sent
2008-12-01
03 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2008-11-27
03 Mark Townsley [Ballot Position Update] New position, Yes, has been recorded for Mark Townsley
2008-11-27
03 Mark Townsley Ballot has been issued by Mark Townsley
2008-11-27
03 Mark Townsley Created "Approve" ballot
2008-11-27
03 Mark Townsley State Changes to Last Call Requested from AD Evaluation by Mark Townsley
2008-11-27
03 Mark Townsley Last Call was requested by Mark Townsley
2008-11-27
03 (System) Ballot writeup text was added
2008-11-27
03 (System) Last call text was added
2008-11-27
03 (System) Ballot approval text was added
2008-11-13
03 Mark Townsley State Changes to AD Evaluation from Publication Requested by Mark Townsley
2008-10-27
03 Cindy Morgan
draft-ietf-softwire-encaps-ipsec-01.txt

PROTO questionnaire for:
prepared by: Dave Ward (dward@cisco.com)

1.a) Have the chairs personally reviewed this version of the Internet
Draft (ID), and …
draft-ietf-softwire-encaps-ipsec-01.txt

PROTO questionnaire for:
prepared by: Dave Ward (dward@cisco.com)

1.a) Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready
to forward to the IESG for publication? Which chair is the WG
Chair Shepherd for this document?

Dave Ward

1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, internationalization,
XML, etc.)?

No.

1.d) Do you have any specific concerns/issues with this document
that
you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of
the
document, or have concerns whether there really is a need for
it. In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the
document, detail those concerns in the write-up.

No.

1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is strong WG consensus behind this document and no one that has
expressed concerns about its progression.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email to the Responsible Area Director. (It should be
separate email because this questionnaire will be entered into
the tracker).
No.

1.g) Have the chairs verified that the document checks out against
all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
Boilerplate checks are not enough; this check needs to be
thorough.

Yes.

1.h) Has the document split its references into normative and
informative? Are there normative references to IDs, where the
IDs are not also ready for advancement or are otherwise in an
unclear state? The RFC Editor will not publish an RFC with
normative references to IDs (will delay the publication until
all such IDs are also ready for RFC publicatioin). If the
normative references are behind, what is the strategy for their
completion? On a related matter, are there normative
references
that are downward references, as described in BCP 97, RFC 3967
RFC 3967 [RFC3967]? Listing these supports the Area
Director in
the Last Call downref procedure specified in RFC 3967.

The references are split into normative and informative.


Protocol write-up for:
by Dave Ward, dward@cisco.com

Technical Summary

The BGP Encapsulation Subsequence Address Family Identifiers (SAFI)
provides a method for the dynamic exchange of encapsulation
information, and the indication of encapsulation protocol types
to be
used for different next hops. Currently support for GRE and L2TPv3
tunnel types are defined. This document defines support for IPsec
tunnel types.


Working Group Summary

The SOFTWIRE WG supports the development and advancement of this
document.


Protocol Quality

This document was thoroughly reviewed by WG chairs and WG members,
including those with expertise in IPv4 to IPv6 transitions and
interworking.

Dave Ward is the WG chair shepherd. Mark Townsley is the
responsible Area
director.
2008-10-27
03 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2008-05-02
03 Samuel Weiler Request for Early review by SECDIR Completed. Reviewer: Tero Kivinen.
2008-05-01
01 (System) New version available: draft-ietf-softwire-encaps-ipsec-01.txt
2008-04-12
03 Samuel Weiler Request for Early review by SECDIR is assigned to Tero Kivinen
2008-04-12
03 Samuel Weiler Request for Early review by SECDIR is assigned to Tero Kivinen
2008-04-12
03 Samuel Weiler Request for Early review by SECDIR is assigned to Julien Laganier
2008-04-12
03 Samuel Weiler Request for Early review by SECDIR is assigned to Julien Laganier
2008-03-13
00 (System) New version available: draft-ietf-softwire-encaps-ipsec-00.txt